By Brecht. Thanks to Cecilia and Dani for review.
In this article, we aim to explain in more detail how Gwyneth works, or at least will likely work as Gwyneth is still under heavy development. For a less technical introduction, please refer to the Gwyneth introduction article. For a more in-depth explanation, please refer to the design doc (though this document is often outdated!).
Let’s start with listing the core properties/functionality again and take it from there.
We also give some more details about some of the practicalities:
A. Block proposing and proving
B. Value capture
C. Infrastructure
D. Interoperability with other (based) rollups
Gwyneth on the most basic level is a horizontal scaling solution for Ethereum. Gwyneth is a network of multiple identical Ethereum equivalent L2s with some additional functionality to make it easy to do cross-chain calls. In this way, developers can still easily make things look like a single chain. The function of each L2 is to add extra parallel processing and storage capacity to the Gwyneth network. This keeps hardware requirements for a single L2 low, while the throughput of the whole network theoretically does not have any limitations.
In the rest of the article, when we talk about an L2, we refer to one of these L2s in the Gwyneth network.
All Gwyneth L2s can directly access each other synchronously. They can also access L1 synchronously if the L1 proposer supports this. With “access”, we mean to read and write all states as if they are part of the same chain. From the user’s perspective, it looks like the transactions run on a single chain. The user creates a single transaction and pays the fee as usual. The gas price changes with the specific L2 on which the current part of the transaction is running.
We introduce L2 synchronous composability with a new precompile called XCALLOPTIONS. This precompile allows a smart contract to define the target chain of the first following (DELEGATE)CALL. The precompile switches the execution environment to the state of the specific chain, including the basefee.
For a stateless prover to prove this behavior, the required input is all the state commitments of all the accessed chains. We verify the different chain states with Merkle Proofs, and update the states upon verification. The output is then the updated state commitments.
For a builder to execute these cross-chain transactions, the latest state for each chain needs to be known. Users specify the accessed chains as part of the transaction, which informs builders of the required chain states. If a non-specified chain is used, the transaction reverts with the user still paying for the executed part. This prevents a DOS attack on builders, because they would have to simulate each transaction to know the required chain states.
Scalability