[DRAFT] Quill: Making Optimism and Superchain A Polyglot Smart Contract Ecosystem

🏹 Mission Requests
, ,
1

Delegate Mission Request Summary:

Make Optimism and the Superchain a polyglot smart contract ecosystem for developers by enabling the support for conventional languages such as Rust, C++, Python, etc., for smart contract development on any OP Stack chain. This can be achieved by introducing a sidecar runtime system that allows for the compilation of LLVM IR to the MIPS architecture, to support and interoperate with the EVM. This sidecar runtime system will be called Quill, an intended homage to the Ether’s Phoenix.

S5 Intent Please list the Intent your Request aligns with here: Intent #2: Grow the Superchain

Proposing Delegate: PizzaKnight | Mawuko.eth

Proposal Tier: Fledgling Tier

Baseline grant amount: 250K OP

Should this Foundation Mission be fulfilled by one or multiple applicants: Up to 3 applicants

Submit by: To be set by Grants Council

Selection by: To be set by Grants Council

Start date: Q1 2024 (February 25, 2024)

Completion date: Q4 2024. (December 31, 2024)

Specification

How will this Delegate Mission Request help accomplish the above Intent?

  • By making the Optimism and Superchain ecosystems capable of supporting multiple popular(and pre-blockchain) programming languages for smart contract development, the criteria for smart contract developers expands beyond the sphere of the blockchain-specific developer base into that of the traditional tech scene(which is home to the majority of software developers in the world…

What is required to execute this Delegate Mission Request?

  • A runtime system that permits the compilation of LLVM IR to MIPS architecture and is compatible with Optimism’s Canon. Additionally, this runtime system should be interoperable with the existing EVM system in the OP Stack.

How should the Token House measure progress towards this Mission?

  • A working prototype of this system that compiles LLVM IR down to MIPS instruction set in Cannon.
  • A working prototype that is able to interface with the EVM
  • A testnet OP Stack chain that is fully integrated with the prototype runtime system
  • Initial launch of a dedicated library to add support for popular high-level languages such as Rust.
  • An initial set of test smart contract code that leverages the new runtime system and interoperates with EVM-based smart contracts in the same system.

How should badgeholders measure impact upon completion of this Mission?

  • The number and growth of smart contracts based on this new runtime that are deployed in OP Stack chains.
  • The number and growth of developers actively making contributions with smart contract code.
  • The number and growth of developers with a professional background in traditional tech companies.
  • The number and growth of new apps that specifically leverage the new runtime system.
  • The number and growth of existing apps that integrate the new runtime system into parts of their app.

Have you engaged a Grant-as-a-service provider for this Mission Request?
No

Has anyone other than the Proposing Delegate contributed to this Mission Request? No

2 Likes
2

Hi @mawuko

I want to confirm that you are one of the top 100 delegates enabled to create a mission request.

If that is correct, then I suggest this mission be “Intent 1: Progress towards technical decentralization” so the Developer Advisory Board can pick it up and approve it.

1 Like
3

I am an employee of OP Labs and speaking on my own behalf.

Hello @mawuko. Thanks for creating a mission request. Can you clarify what problems this solution solves? What are concrete numbers on projected growth that you see from it?

Are you also sure this is technically feasible? My my current understanding, LLMV does not support the version of MIPS that Cannon supports. So this is not technically possible without updating Cannon to support a more modern version of MIPS.

Asterisc is a more modern fault proof VM that targets RISC-V. This is a more future proof ISA compared to MIPS, which is on life support. The goal is to have multiproof which will allow for the OP Stack to operate stage 2 rollups securely. Quill would greatly complicate the ability to run both Cannon and Asterisc in parallel. How would you address this?

Also how does gas metering work under your proposal? In my opinion a project of this scope should have a completed specification beforehand.

It is also unclear to me if allowing for smart contracts to be written in arbitrary languages is a feature. It is already difficult enough to write and audit secure Solidity code.

1 Like
4

Hi @Gonna.eth

I am not one of the top 100 delegates enabled to create a mission request. It is my hope that one of such enabled delegates takes an interest in this proposal to vouch for it, and push it forward.

Regarding the intent, I believe this proposal is well positioned in the Intent #2 category which focuses on Growing the Superchain in ways such as building developer tooling that improve users; ability to build, test, and deploy.

Quill essentially enables this by supplementing the existing EVM on OP Stack chains with an auxiliary runtime. This runtime allows the use of more popular languages and toolsets, such as Rust, for application development.

I hope this feedback is helpful. If it’s not too late (though I fear it is), I would appreciate your assistance in advancing this proposal for further consideration."

1 Like
5

Hey @tynes

Thanks for the interest in this proposal and the very good questions.

Can you clarify what problems this solution solves?

Today, developers looking to build within the Superchain are limited to the EVM and EVM-based high-level offerings like Solidity, Vyper, etc. This doesn’t change even if they’re able to run their own OP Stack chain.

Enterprises and other organisations interested in constructing their blockchain systems using the OP Stack may choose to avoid the framework. This decision stems from concerns about the unfamiliarity and overhead that their core teams and infrastructures would encounter while assimilating with the EVM system. This is particularly likely given there are alternative frameworks available that can readily cater to their diverse yet conventional software development needs, allowing them to build applications with languages like Rust, Go, etc.

Quill repurposes the underlying MIPS instruction set that Optimism will be relying on for its fault proofs to offer an aux runtime environment, as a sidecar to the existing EVM.

What are concrete numbers on projected growth that you see from it?

Globally, there are at least:

  • 3M devs that use Rust
  • 5M devs that use C++
  • 7M devs that use .NET
    The list goes on. The projected growth is to be able establish a developer platform capable enough of attracting at least 0.01% of these devs(not counting enterprises) from each camp, to the entire Superchain.

Are you also sure this is technically feasible?

AFAICT, all that’s really needed is being able to compile LLVM IR down to MIPS instruction set, something which is possible for all versions of the MIPS architecture(even MIPS I).

My my current understanding, LLMV does not support the version of MIPS that Cannon supports.

Naive research on my part has suggested that Optimism either uses MIPS III or MIPS IV, something that needs clarifying.

So this is not technically possible without updating Cannon to support a more modern version of MIPS.

As much I doubt this will be critically doubt this will be required, it’s safe to say that all versions of MIPS are backwards compatible so we can rest assured we probably won’t be breaking much(if anything at all).

Asterisc is a more modern fault proof VM that targets RISC-V. This is a more future proof ISA compared to MIPS, which is on life support. The goal is to have multiproof which will allow for the OP Stack to operate stage 2 rollups securely. Quill would greatly complicate the ability to run both Cannon and Asterisc in parallel. How would you address this?

The key infrastructure here is the underlying architecture having support for the LLVM IR infrastructure. RISC-V has this.

Optimism’s MIPS system is active and will have every opportunity to be a testing and refinement ground for Quill such that should the day come for such a switch over, this Asterisc system and the ecosystem around will at least be better familiar with Quill and its dependencies.

We address by establishing meaningful comms, and aligning maintenance and improvements, among all contributors within this area, MIPS and RISC-V systems for Optimism.

Also how does gas metering work under your proposal?

The appropriate cost models and parameters will have to be drawn up along the way, under the guidance of the Optimism Collective, OPLabs, and other key relevant stakeholders and contributors.

In my opinion a project of this scope should have a completed specification beforehand.

It was my understanding that making a mission was the first step in garnering interests and attracting the appropriate contributors to begin architecting the needed specifications to make Quill possible.

It is also unclear to me if allowing for smart contracts to be written in arbitrary languages is a feature. It is already difficult enough to write and audit secure Solidity code.

There are more language stacks out there with far more mature and advanced suites and toolkits for testing and auditing than Solidity and the EVM in general. I think this is a good opportunity to introduce them into our ecosystem.

Regardless the language, there’s always the path for setting up healthy and ergonomic guidelines and techniques for developers who use them within the Quill environment. Plus, there’ll be avenues to design DSLs from these arbitrary languages that will better curated for the OP Stack blockchain environment.

Hope this offers some insight into what can be achieved with this mission.

Worth noting that this will not only benefit Optimism, but every other OP Stack chain that is yet to be built.

image

1 Like