Introduction
Hi Everyone. This is Omar - the Head of BD at Matter Labs where I am contributing to scaling zkSync by bringing great developers and communities together. At zkSync we are very excited by the prospect of Treasure DAO vision towards its own network of gaming chains. We would like to propose the ZK Stack to get started on this future with Treasure Chain as the layer 2. This would give Treasure DAO the ability to expand vertically with game or app specific layer 3 chains that settle on the layer 2 Treasure Chain. All of this powered by the most performant Ethereum scaling technology, ZK Stack.
Through our meaningful discussions with the Treasure team and the community, we have gained valuable insights into the desires for a technologically advanced, highly scalable, and adaptable platform, with the added benefit of remarkably low transaction costs.
Our engagement with Treasure began with a shared enthusiasm for gaming and NFTs, and it has been a pleasure to gain understanding of how our visions resonate with those of Treasure DAO. Our interactions with the Treasure team and insights into the requirements have been instrumental in shaping this proposal. The essence of this proposal is to present a comprehensive view of our technical solutions, while discussions between the Treasure team and Matter Labs will focus on aligning support for Business Development and Marketing.
In-depth discussions with community members and the Treasure team underscore the strategic value of Treasure Chain for Treasure DAO. It’s viewed not just as a narrative enhancer but also as a pivotal business development tool. The implementation of Treasure Chain could be a catalyst in driving the overall progress of the Treasure ecosystem to the wider gaming audience. Let’s dive into an in-depth overview of ZK Stack’s alignment with Treasure’s vision and requirements, transforming the way we perceive decentralized gaming and NFTs.
Modularity of the ZK Stack
ZK Stack is a free and open-source modular framework for building sovereign ZK-powered chains. This framework will power the zkSync ecosystem of shared users and liquidity across many hyperchains. The first steps of this vision will be coming to life in Q1 as the shared bridge reaches mainnet. The shared bridge is the central connection from L2 and L3 hyperchains to Ethereum and is what enables unified liquidity across the ecosystem. To learn more about zkSync’s scalability and hyperchain vision, check this blog post. More technical details on hyperchains and how hyperbridging and the shared bridge work can be found in our technical documentation here and here.
Native Token
We are very close to enabling ZK Stack hyperchains to select their own native gas token. We are closely working with the Lambda Class team on this implementation and it is due this quarter. This would mean that the Treasure Chain could have $MAGIC as its gas token or any other ERC20 token it chooses.
Choice of DA Layer
Running a ZK Stack hyperchain in validium mode will allow Treasure Chain to select from a variety of third party DA layers. We plan to have integrations complete with Celestia, EiginDA, Avail to name a few by the end of this quarter. With zkPorter there is also the optionality to run your own DA layer as part of the validium portion of zkPorter
Can scale horizontally or vertically
Power up new hyperchains to tap into horizontal scale (green), while maintaining the same seamless connectivity with all other chains both at the L2 and L3 level (blue).
Choice of sequencer
Operators of the ZK Stack will have many choices for their sequencer. They can opt to use the standard centralized sequencer or our soon to be released decentralized sequencer. To further optimize for a gaming network there can also be the option to utilize a shared sequencer that can be shared by specific L3s that sit on top of the Treasure Chain. Currently, however, there are no localized shared sequencer solutions that are being developed in the market. We do recognize that a shared sequencer that is only utilized by a common network of games is more optimal than a global shared sequencer that anyone can utilize. To drive technical innovation in gaming we would be happy to work with Treasure Chain to find a suitable technology partner that can help to build a local shared sequencer optimized for gaming L3s.
Scalability and Performance
Throughput (TPS) for each individual hyperchain
Current: Proven to handle 150 TPS under high load scenarios for prolonged periods of time
Inscriptions are digital artifacts that are created within transaction calldata, counter to ERC-721/1155 tokens (NFTs) which store data in contract storage. Inscriptions gained popularity on EVM networks following their huge popularity on Bitcoin. As a result of this, many EVM networks have been ‘spammed’ with inscription transactions.
On December 16, the inscriptions craze came to zkSync Era in force, leading to the network handling ~150 TPS for nearly 14 hours and peaking at 187 TPS, all while maintaing an average transaction cost of ~$0.12.
Inscriptions craze proves stark contrast between Ethereum rollups by Blockworks offers an excellent overview of these inscription events, with a particularly important focus on how ZK Rollups such as zkSync Era have an advantage over other networks.
zkSync Era: Inscriptions Transaction Volume
H2 2024: We have a new VM currently under testing that can get up to 1000 TPS for the average DEX swap. All ZK Stack hyperchains will be able to seamlessly upgrade to the new VM once it goes live on testnet and mainnet
The cheapest Layer 2 rollup thanks to industry leading proof zk proof system
Boojum is zkSync Era’s new proof system, designed for world-class proving performance and reducing hardware requirements for decentralization. zkSync Era was upgraded to the Boojum proof system on December 4, 2023. This upgrade wasn’t only for the proof system, it also included items such as L1 calldata compression, larger batch sizes, and verifier optimizations.
Looking at the 30 days pre- and post-upgrade, zkSync Era saw a -52% reduction in L2 transaction fees, +54% increase in L1 batch size, and -40% reduction in L1 verifier gas usage (data can be found on Dune). This has led to zkSync Era regularly having the lowest transaction fees of any Ethereum L2 as shown on growthepie.xyz
As L1 data costs are one of the most expensive parts of operating a Layer 2 network, the data used per transaction is a critical metric to monitor. Prior to Boojum, zkSync Era averaged ~200 bytes per L2 transaction. After Boojum, the average is less than 80 bytes per L2 transaction as can be seen in the figure below.
An excellent X (Twitter) thread from 0xtaetaehoho at 1kx gives more insights into the effects of the Boojum upgade:
Additional upgrades planned for end of Q1 to further reduce transaction costs
We plan to get transaction costs for an ERC20 transfer down to $0.01 in rollup mode with some additional system upgrades planned for the next 2-4 months. However, in validium mode where Treasure DAO uses a third party DA layer such as Celestia or EigenDA this transaction cost can get down to <$0.01. Below are the planned upgrades
- EIP 4844: This is not a differentiator and will improve all rollups
- Increasing the L1 batch size to handle many more transactions. This is a fairly significant upgrade detailed as following:
One of the most impactful methods for reducing transaction fees on any Layer 2 network is to increase the number of transactions in each batch that gets posted to L1, thereby amortizing costs over more transactions. Most L2s post full transaction data to L1, but zkSync Era only posts the final state changes (state diffs) to L1. When many transactions touch the same storage slots, this state diff approach enables zkSync Era to have very large batches, offering extremely low transaction fees.
Batches on zkSync Era are closed for three reasons: reaching limits on L1 pubdata size, computational gas, or number of transactions. Prior to Boojum, zkSync often closed batches based on reaching L1 pubdata limits. After adding data compression and a few other improvements, batches are now most often closed by reaching computational gas limits. In Q1 2024, we will significantly increase the computational gas limit such that it is no longer our limiting factor in having bigger batches.
Once the batch size is dynamic you can create a flat gas fee simply by increasing or decreasing the size of the L1 batch based on the gas volatility of the DA layer and Ethereum. This is highly critical for gaming applications where users expect the fees to be stable even when traffic on other connected networks is high.
Blocktime
Current blocktime on zkSync is usually 1 second or less. We intend to continue block time to be below or at 1 second even with our decentralized sequencer.
Decentralized Sequencer
We already have a decenralized sequencer design and are on the path to decentralization very soon. The decentralized sequencer design in the ZK Stack will allow all $MAGIC token holders to earn yield as participants Treasure Chain.
In addition, as development of the stack progresses and we add in the ability for transactions to leverage zkPorter volition mode, Treasure Chain can whitelist its validator set to run this DA system as a separate responsibility to sequencing.
More information on our decentralized sequencer will be coming out soon.
Improved UX through native-AA
To quote Vitalik: “Good user experience is not about the average case, it is about the worst case” User experience in the space is still one of the biggest obstacles to greater adoption.
- All accounts are smart contracts on Era. This opens a wide variety of designs for developers to most importantly improve blockchain UX and build unique blockchain-augmented features for apps. These are features that users are accustomed to in Web2, but were previously only possible through custodial services in Web3.
- With native AA we are breaking out of this shell.
- Some examples include: Paymasters (below), new account signers by Clave* (also below), session keys, and account admin controls for recovery, backups and/or a dead-man switch.
- For more content on native AA on zkSync, we recommend this post by the Clave team.
Custom Signers: With accounts supporting EIP1271, applications can use different signers to control accounts — for example, the Clave platform allows anyone to use the secure element of their mobile phone as the main signer for their public address. Paymasters: All transaction types have a pre-defined field for Paymaster addresses, meaning paymasters work for both externally owned (EOA) and smart contract account (SCA) types. Paymasters allow application developers flexibility in customizing payment mechanisms. Most frequently they are used by zkSync Era apps to pay gas in stablecoins, or supplement gasless transactions (see the gas in USDC tutorial here).
- Note: EIP4337 adds this functionality to the app layer. This requires a separate mempool managed by relayer services (at added costs) and implies Paymasters cannot be used for both EOAs and SCAs. On Era there is a unified mempool for both EOA and SCAs.
State Differences vs. Full Call Data (Transaction Data)
zkSync is a State-diff rollup (SDR) while all other Layer 2 EVMs are Transaction Data rollups which store all transaction input data as call data to the DA layer.
SDRs are rollups that post state differences across an aggregated batch of transactions to Ethereum L1. For the EVM, as transaction batches grow larger, the per transaction data posted to L1 diminishes to a constant that is much smaller than that of transaction-data rollups. For example, during the stress-test event of high in-flood of inscriptions, zkSync saw a reduction of calldata per transaction down to as low as 10 bytes per transaction. In contrast, transaction-data rollups like Arbitrum, Optimism, and Polygon zkEVM, typically see around 100 bytes per transaction for normal traffic. As we start to push the boundaries of scale and throughput DA no longer becomes the bottleneck, execution does. From 1kx On Trust Minimization and Horizontal Scaling:
With the ZK Stack the Treasure Chain gets the best of both worlds. Choice of reducing DA bottleneck by using a third party DA layer such as Celestia or EigenDA in Validium mode AND the benefit of horizontally scaling execution that a SDR provides. No other Layer 2 solution can provide both. This difference becomes more pronounced with the following examples:
- The more transactions you can fit into a batch
- Oracle updates are much cheaper at higher frequencies because they only impact 1 storage slot which you can update many times for the price of just one update within a batch
- Onchain privacy and ZK becomes much more affordable because you don’t need to send the full transaction input data just the state difference
- Approve and sign transactions in one single click with batched transactions while saving on transactions fees. Normally this would incur higher transactions fees because it is two transactions. With state-diffs, however, you only have to pay for one storage slot change and not two. This creates an improved UX while keeping costs low. For further details please see here.
EVM Equivalence
zkSync Era is currently a Type 4 language-compatible zkEVM. In the very near future, a Type 2 EVM-equivalent implementation will be introduced that works in tandem with the current network. This gives developers the option of deploying smart contracts with the Type 4 system to achieve maximal performance and access features such as Native Account Abstraction, or deploy with the Type 2 system for maximal compatibility with EVM and the accompanying toolchain. You won’t need two different chains for this, both Types would be available at contract deployment within the same chain. This makes for easy migration of existing contracts and gives developers the ability to then start building with the more performant Type 4 which will have cheaper transaction fees since it is highly optimized for zkEVM.
Governance and Economic Alignment
Independence within Ethereum
The entire ZK Stack code base is open-source under MIT license and recently completed the largest C4Arena bounty ever, with $1.1m offered in rewards. The system is designed such that any adopting community can maintain full technical and economic sovereignty, yet natively co-exist using hyperbridging.
Roadmap influence
A primary purpose of the team at Matter Labs is as a core developer of the ZK Stack, however it is not to be the sole entity that decides on the future of the ZK Stack.
This is specifically why the ZK Stack is open-sourced, and why we are making an effort to work with individual communities to onboard to the ZK Stack — each conversation we have that may lead to the adoption of the stack onboards a new co-development partner and key stakeholder that contributes to the bedrock of our community. It is especially important for us to follow our credo and ensure that members of the community can influence the direction of our technology.
Specific governing processes and the method by which stakeholders influence the roadmap will be determined in the coming months, and will be largely dependent on the decentralization of other components of the system.
Contribution Incentives
We are pleased to share that an independent ecosystem funding and governance program is being developed (expected later this quarter) for the benefit of zkSync and its participants. The purpose of this program will be to determine how grants are allocated to projects building on zkSync, especially those significant collaboration projects that directly align with the broader strategic goals of the zkSync ecosystem and the ZK Credo.
You can expect additional public announcements to come in the following weeks and months on how we will be supporting innovation in the zkSync ecosystem.
We recognize the significance of transparency and look forward keeping everyone informed on our progress.