Equilibrium Infra Bulletin #20: Aggregated Blockchains, Polygon's Type 1 zkEVM prover, and Tx Fee Mechanisms on Solana vs Ethereum
Equilibrium Labs builds the state-of-the-art of decentralized infrastructure. We are a global team of ~30 people who tackle challenges around security, privacy, and scaling.
Research, Articles and Industry News:
📚 Aggregated Blockchains - Recommended by Hannes:
The article by Brendan from Polygon explains the reasoning behind building the AggLayer and explains the design in more detail. It’s based on two assumptions:
No single chain, whether L1 or L2, can support the throughput required to reach internet-level scale (challenges the integrated/monolithic view)
Scaling blockchains means scaling access to liquidity and shared state. Adding blockspace via multiple chains doesn’t work if it fragments liquidity (challenges the modular view)
If both are true, then scaling blockchains is equivalent to scaling access to shared state and liquidity across many chains. This is what AggLayer aims to do, with two key components:
Pre-confirmations from AggLayer: Rather than waiting for full finality from Ethereum (12 mins + proof generation time) - chains using AggLayer can provide pre-confirmations before settling to Ethereum. This idea is similar to Near’s Fast Finality Layer, but the security guarantees differ; Near relies on economic security from EigenLayer operators (which are slashed if proven to be malicious once transactions settle on Ethereum), whereas Polygon’s AggLayer relies on proof aggregation.
Proof aggregation as a safety feature: The aggregated proof enforces that dependent chain states and bundles are consistent - ensuring that a rollup state can't be settled on Ethereum if it relies on an invalid state from another chain. If inconsistent, the rollup state is rolled back (or if it’s an atomic swap, the swap fails) - leading to weaker liveness guarantees. To deter bad behavior, malicious rollups are punished either through slashing or by being ejected from the AggLayer.
Visual representation of the AggLayer and proof aggregation (source)
Ultimately, each chain needs to navigate this tradeoff in latency and liveness guarantees. For example, chain A might choose to interoperate with chain B after the pre-confirmation step to get low-latency cross-chain transactions, while requiring full Ethereum settlement from chain C. This introduces some flexibility and enables rollups to be subjective about which chains they trust more than others.
Key takeaway: The AggLayer aims to provide better UX and faster settlement for cross-rollup communications by providing soft confirmations and later settling an aggregated proof to Ethereum. The aggregated proof acts as a safety feature which enforces that dependent chain states and bundles are consistent. The idea is similar to Near’s FFL, but the security mechanisms differ (economic security vs cryptographic security). Other chains are building similar solutions, such as zkSync’s hyperbridge, which enable smooth interoperability within their ecosystem. Ultimately, common standards are needed to break down the siloes and enable smooth interoperability between all rollups (and later all chains).
📚 Upgrade Every EVM Chain to ZK: Introducing the Type 1 Prover - Recommended by Joakim:
Polygon Labs and research organization Toposware have collaborated on upgrading the existing Polygon zkEVM prover to type 1 mode, which is the most compatible with Ethereum and the EVM. It supports all opcodes and precompiles in the Shanghai EVM hard fork (soon the upcoming Cancun hard fork) and enables proving actual Ethereum mainnet blocks. Existing EVM chains can easily transform into a validity L2, without even requiring modification to existing EVM clients. This all fits into the AggLayer thesis presented above, where the value proposition of the AggLayer grows the more chains are using it.
A few things worth highlighting:
Based on the numbers provided by Polygon, the cost of proving an Ethereum block with the type 1 zkEVM prover is ~$0.2-0.5 with tx level costs between $0.002-0.003. For reference, Polygon claims this is 36x more cost-efficient than using RISC Zero’s Zeth in an apples-to-apples comparison using consumer hardware, and 10x otherwise. Additional cost reductions are expected through further optimization as well as the release of Plonky3.
Cost and performance benchmark for proving Ethereum blocks using the Polgyon zkEVM type 1 prover (source) The implementation is optimized to provide fast proving times on generally available cloud instances and does not require GPUs or special hardware. It’s also built to easily scale across multiple physical computers (horizontal scaling) to reduce latency. For example, by doubling the amount of physical computers, the time to generate proofs can be reduced by half, while still incurring the same total runtime.
Key Takeaway: The release of Polygon’s type 1 zkEVM prover supports all current opcodes & precompiles and allows proving Ethereum blocks. This is a big milestone for the wider space, but especially the ZK space, as a type 1 prover was considered prohibitively expensive not too long ago. If we zoom out and look at the bigger picture - it only seems a matter of time before we transition from economic security and verification through re-execution, to ZK-based systems due to their superior efficiency (bringing cost-benefits to users) and better interoperability features.
📚 Solana & Ethereum Transaction Fee Mechanisms: Proposals to Improve Solana’s TFM - Recommended by Hannes:
The transaction fee mechanism (TFM) determines which transactions are included in a given block, the fees that a transaction pays, and how accumulated fees are distributed. Ethereum and Solana differ in many different ways and both chains can learn from each other. This post focuses on comparing transaction fee mechanisms between the two chains and explores what Solana could learn from Ethereum (and other chains).
Comparison of general metrics between Ethereum and Solana (source) Some of the main shortcomings of the current Solana TFM include:
Incentive to spam: Transaction ordering on Solana is somewhat FIFO (as blocks get built continuously) in addition to being subject to non-determinism from both network jitter and randomized thread allocation. Solana currently has four different threads (relating to parallel execution) to which transactions get randomly allocated. This incentivizes arbitrageurs to spam transactions to maximize inclusion probability and provides less reliable prioritization guarantees than on Ethereum - ultimately leading to a lot of wasted compute.
Solana validators waste more than 58% of their time processing failed arbitrages (source) Inefficient compute unit (CU) usage and requests: The base fee for each transaction on Solana is a fixed 5,000 Lamports/signature, regardless of the actual compute required (a tx with 1.4m CUs has the same base fee as one with 100k CUs). Hence, it doesn’t incentivize optimizing programs to use CUs as efficiently as possible and might lead to an overestimation of the expected usage of CUs. Compare this to Ethereum’s dynamic base fee that floats based on trailing market demand and is linear to the amount of compute required (gas consumed).
50/50 Burn/Validator Payout: On Solana, 50% of both the base and priority fee is burned, while the other 50% goes to the validator. This is different from Ethereum’s model, where 100% of the priority fee goes to the leader to avoid off-chain dealings. A similar model has been proposed for Solana, but not yet approved.
Comparison of the burn vs validator allocation split between fees (source)
Some propositions that aim to tackle these issues include a multidimensional fee market which would bring more efficient pricing of resources as well as an exponential fee for write lock accounts to reduce spam and enable more efficient network utilization. One example of a two-dimensional fee market is EIP-4844, where data blobs are priced separately from Ethereum execution gas.
Key Takeaway: The transaction fee mechanism decides how to allocate the scarce resource of finite blockspace among users. While there is a lot of positive about Solana, it’s still a WIP (as is every other chain) and there are several known problems around the TFM. Many of these problems are currently being actively worked on, but new mechanisms take time to plan, coordinate with the community, test, and implement. In addition, simply porting over existing mechanisms from Ethereum doesn’t work due to the unique engineering and performance goals of Solana, but other chains can still act as inspiration for the design.
Personal Recommendations From Our Team:
📚 Reading: Read, Write, Own - Chris Dixon: Even though we think a better definition for web3 is read, write, verify (rather than own), Chris has done a great job of pulling together a comprehensive overview of the ideas behind the space!
🎧 Listening: Myele Manzanza - Something Old Something New: The New Zealand-born drummer and composer manages to switch seamlessly between styles while still adding his flair to it all. His new album “Crisis and Opportunities Vol 4” is out now.
💡 Other: Tree-Based Computing: For the nature lovers out there, this post provides an unironic overview of how to upgrade your work-view by strapping a computer to a tree 🌲