Special thanks to @ramonIsTweeing, @JesusLigero3, @0xIgnasi, @droak_ , @ETazou and @LearnWeb3DAO for feedback and support!

This report was written by @glazecl and @isqueeniee on 2023/05/12. Things might be changed over time.'

We have built a Q&A bot to help you understand the passage.

The importance of developer experience(DX) in blockchain projects is often overlooked or underemphasized, particularly in the early stages of new technologies that undergo continuous iterations. However, by considering the benefits of prioritizing developer experience, such as increasing developer adoption, enhancing developer productivity, improving community engagement, and long-term sustainability of projects, we aim to provide this analysis to offer insights into the current developer experience of each ZKRU.

Our goal is to raise awareness within the community and foster a collaborative learning environment where ZKRUs can share knowledge, encouraging collective growth in the Layer2 landscape.

Background Introduction

In recent months, we have witnessed significant launches from various ZKRUs, providing environments that enable smart contract deployments. The roll-out of Testnets or Mainnets marks a crucial phase in the blockchain development timeline.

Starknet launches Alpha Mainnet on Nov. 29th, 2022.

Scroll launches its Goerli Alpha Testnet on Feb. 27th, 2023.

zkSync launches zkSync Era Mainnet on Mar. 24th, 2023.

Polygon launches its zkEVM Mainnet Beta on Mar. 27th, 2023.

With all these significant developments paving the way for builders to create on ZK Rollups, it's a prime opportunity to delve into the unique experiences each ZKRU offers for developers. This article aims to shed light on the developer experience across the four ZKRU solutions above, analyzing the EVM compatibility and the overall developmental workflow.

Considering the fact that all ZK Rollups promote their EVM equivalents, our exploration of developer experience will commence from the vantage point of a Solidity engineer.

Detailed Dive into the Development Lifecycle

Open-source on GitHub

Overview

Open source enhances Developer Experience by promoting quality, security, and collaboration. Its transparency allows global developers to tackle bugs and security issues, leading to continuous software enhancements. It serves as a learning platform, offering access to various coding styles, advanced technologies, and industry standards, enriching the developer journey. Its customization aspect provides flexibility to modify the software as per specific needs. Lastly, open source encourages collaboration and innovation via diverse communities, driving project evolution and creative solutions.

Projects often open-source their code once key milestones are reached, typically when the code reaches at least an Alpha version. Codes still undergoing heavy development aren't ideal for open sourcing as they might not provide the expected benefits, such as quality enhancement, improved security, and collaborative learning. Thus, the number of open-source codes often correlates with the project development stage.

Here is an overview of the four ZKRUs.

Starkware operates two open-source accounts: StarkNet and StarkWare Libs, with a total of 47 repositories.

Polygon also has two open-source accounts, Polygon and Polygon zkEVM. On its GitHub profile page, it shows a detailed table about EVM compatibility. It runs official Ethereum test vectors on its zkEVM and passes 99.67% of the tests.

Scroll has forked many projects from Polkadot and Ethereum Applied ZK and customizes them based on these forked projects. Among the forked codebase, Scroll is the most Ethereum maxmist Layer2, as their proving systems and zkEVM circuits are closely related to Applied ZK.

Another interesting thing is that Scroll open-sources many crypto-related codebases, such as proving systems, crypto primitives, and aggregators. This shows their strong background in cryptography.

Language Choice

The following graph shows the lines of code per language for each ZKRU project. This illustrates the different language choices for the projects.

StarkNet

For StarkNet, Rust has the highest number of lines of code in the StarkNet repositories, with 109,262 LoC. Python is the second most used language, with 68,770 LoC. This demonstrates the extensive use of these languages in StarkNet projects.

zkSync Era

For zkSync Era, they have a lot of code because several of the repos are forked from large projects, like era-compiler-llvm and era-compiler-llvm-builder. Two forks have lots of Rust code. Rust is the number one language, taking up 3/4 of all the codebase. JS/TS has 40k lines, taking the second position. Without the two forks, Rust is still the primary language.

On all zkSync Era-related repos, the zkSync Era teams put the zkSync Era introduction at the top of the README file. This can build a stronger brand and increase exposure for zkSync Era.

Polygon zkEVM

For Polygon zkEVM, most of the code is written in C++. zkEVM-prover takes over 8 million lines of C++ code. Other languages only take around tens of thousands of lines of code.

If we exclude the prover projects, the majority of the code is Go, around 90k lines, which is 50% of the code. JS and Go are the two major languages for Polygon zkEVM.

Scroll

For Scroll, the dominant language is Rust, which is used for cryptography, explorer, and zkEVM. Go is used to build the node and RPC. Rust has the highest Lines of Code (LoC) among the listed languages, with a total of 585,446. Go has a significantly higher LoC compared to Python, TypeScript/JavaScript, C, and Solidity, with a total of 468,003.

Rust has become the dominant language in several projects. It is used to build compilers, nodes, toolchains, CLI tools, and VMs. Rust is widely used in these types of projects because of the following characteristics:

1. Memory Safety: Rust makes it harder for developers to make mistakes that could cause a program to crash or behave unpredictably.
2. Efficient Multitasking: Rust is designed to handle many tasks at the same time (like a server handling many users) without causing errors.
3. No Extra Cost for Nice Code: Rust lets programmers write code that's easy to understand without making the program slower or less efficient.
4. Works Well with Other Code: Rust can work together with code written in C, a very common programming language, which makes it easier to use in different projects.
5. Control Over Resources: Rust gives developers a lot of control over the computer's resources, which means they can write code that runs efficiently and doesn't waste memory or processing power.
6. Good Tools: Rust comes with many built-in tools that make it easier to write, test, and share code.
7. Active Community: There are many active Rust users who contribute to improving the language and helping others learn how to use it.

Smart Contract Development Document

Overview

Layer2 smart contract development documents are critical for developer experience. These resources effectively bridge the gap between the intricate complexities of Layer2 solutions and the Ethereum Virtual Machine (EVM) compatible development ecosystem.

These vital documents illuminate the architecture and unique features of Layer2 solutions, including scalability enhancements, transaction speed improvements, cost reductions, interoperability, and account abstraction. This knowledge empowers developers, providing them with a profound understanding of how Layer2 solutions can amplify efficiency and usability and enable new use cases for their smart contracts.

For beginners in the field, these documents serve as a comprehensive orientation guide. They offer a panoramic view of the system, its components, and functionalities, thus simplifying their onboarding process.

Furthermore, these documents, through their lucid, step-by-step instructions and supplemented examples, streamline the learning curve, allowing newcomers to become proficient swiftly. They navigate developers through necessary tools, libraries, and APIs within the development environment, fostering a deeper familiarity with the system and its underlying structure.

Moreover, these documents highlight the best practices for writing, testing, and deploying smart contracts within a Layer2 environment. Such guidance acts as a roadmap for new developers, mitigating potential errors and amplifying their efficiency.

Here is a detailed analysis of documents for four ZK-Rollups.

These projects all provide good documentation with examples and explanations on important topics. However, there is still some room for improvement compared to tier-1 documentation from Vercel and Stripe:

• Include File Name and Path: At the start of any code blocks, always mention the file name and its path. This helps users know where to locate or place the code.

• Show CLI Execution Results: When providing command-line interface (CLI) instructions, include an example output of the commands. This helps users know what to expect and verify whether they've executed the command correctly.

• Limit Line Length for Code: Set a maximum line length for your code examples. This ensures that your code is easily readable without requiring horizontal scrolling.

• Use Realistic Examples: Instead of using placeholders or 'xxx', provide example contract addresses or secrets. This gives users a better sense of what kind of data they should be using.

• Project View for Complex Tutorials: For more complex tutorials, provide a project view on the side of the tutorial. Highlight corresponding parts of the code as users browse through the tutorial.

  

• Interactive Examples: Include interactive examples to help onboard developers quickly. This could be a playground where users can edit and run code snippets or cloud development environments.

• Organize Documentation: Make sure your documentation is well-structured and easy to navigate. Use clear headings, a table of contents, and breadcrumb navigation if possible.

• Keep It Updated: Ensure your documentation stays up-to-date as your project evolves. This might mean updating screenshots, revising code examples, or rewriting sections to reflect new features or changes.

Breakdown of Document Contents

StarkNet

StarkNet offers three types of documents to facilitate a smooth onboarding experience: Developer Documents, Tutorials, and Tools & Resources.

The Tools & Resources section encompasses all related libraries, frameworks, editor plugins, and templates, with a total of 27 tools listed in the documentation. This section is essential for developers looking to build on StarkNet's infrastructure.

Tutorials come in various formats, including source code, blog posts, and videos. Out of the 40 tutorials available, most are in video format. It is important to note that not all tutorials focus solely on smart contract development; some cover tech talks or explain core concepts, like Herodotus discussing storage proofs. While these may not be immediately helpful for developers looking to quickly start a project, they provide valuable insights into StarkNet's underlying technology.

Developer Documents serve as a comprehensive guide for smart contract developers, covering essential information such as:

• StarkNet's current versions

• Architecture and concepts

• Environment setup, smart contract development, and deployment

• Tools and important contract addresses

  
  

These documents consist of approximately 56 sections and around 35,000 words, providing an extensive knowledge base for developers. In addition to written content, StarkNet's documentation includes 1,147 lines of code to help developers learn through hands-on experience.

Two smart contract examples are provided within the documentation:

1. A "Hello World" style example where calling the "hello" function results in the contract emitting a greeting event with the user's address.
2. A simple storage example where users can increase the balance defined in the storage with event emissions and retrieve the balance.

In the deployment example, StarkNet employs a command line approach rather than a script to deploy the contract. This method also demonstrates how to call smart contracts within the command line. However, the documentation does not include tests and front-end materials. For those interested in Vue.js frontend, ERC721, and unit testing with Protostar, related video tutorials are available in the Tutorials section.

Besides StarkNet docs, Cairo-related resources are on a different site.

zkSync Era

The zkSync Era documentation shares a similar structure with StarkNet, consisting of four main parts: Developer Docs, Tools and SDKs, Contracts and Links, and Tutorials.

The Developer Docs cover a range of topics, including Layer2 and zkSync Era concepts, smart contract development, verification, event handling, JSON-RPC API, related tools and SDKs, FAQs, changelogs, and contribution guidelines. Most of the tutorials and documents are presented in text format rather than video.

In total, there are 10 tools and SDKs listed in the documentation, with a more detailed focus on tools than StarkNet's documentation. The Contracts and Links section provides in-depth information on the usage and API of various tools, such as the JavaScript SDK, Hardhat, Blockchain Explorer, Compiler Toolchain, CLI, Python SDK, and Java SDK.

The zkSync Era documentation consists of 34 sections, approximately 57,000 words, and 6,800 lines of code to assist developers in getting started. There are five code examples provided, covering not only basic smart contract development and deployment but also more advanced topics such as verifying smart contracts, frontend development, Layer1 and Layer2 communication, account abstraction, and alternative token payments for gas/gasless transactions.

What sets zkSync Era apart is its focus on providing essential documents and tutorials that demonstrate how to utilize its unique features like Account Abstraction (AA). This approach can significantly spark a developer's creativity and encourage them to explore the full potential of zkSync Era.

Polygon zkEVM

The Polygon zkEVM developer documentation consists of guides and specifications, which provide comprehensive coverage for the ZKRU ecosystem. The specifications explain the designs of various products, such as the zkEVM and zkNode, while the guides teach developers how to use these tools effectively.

In total, there are 80 sections, 100,271 words, and 126 lines of code (LoC) in the documents. The content is presented through a combination of text, images, videos, and code blocks, with clear categorizations for Mainnet and Testnet codes. The documentation covers not only smart contract development but also essential components like zkEVM, zkNode, zkProver, zkAssembly, and PIL, encompassing all the basic tools in a ZKRU.

It's worth noting that Polygon's documentation differs from others in several aspects. Since zkEVM originated from Hermez, there are two separate documents: one on the Polygon website and another on the Hermez website, last updated in February. These documents cover similar topics but differ in content and organization. For this research, we will focus on the Polygon zkEVM documentation.

Interestingly, Polygon zkEVM does not provide any smart contract code examples. This is because developers do not require any special tools, including compilers, to develop on the ZKRU. As a result, the documentation emphasizes the ease of use and accessibility of the Polygon zkEVM ecosystem for developers.

Polygon offers different configurations for coding blocks. Developers can seamlessly switch between Mainnet and Testnet.

Scroll

The Scroll developer documentation focuses on writing smart contracts for Scroll. The portal and explorer are prominently displayed, making them easily accessible. In addition, the documentation features a section that lists all significant projects launched on Scroll, highlighting its strong ecosystem.

The user guide covers basic network usage, while the developer documentation consists of 10 sections, 3.7k words, and 136 lines of code. Interestingly, Scroll is the ZKRU that documents most frameworks. Although Polygon zkEVM also supports these frameworks, they are not explicitly listed in their documentation. Scroll's compatibility with five different frameworks is detailed in its documentation.

One notable aspect of Scroll is its emphasis on open-source contributions. The documentation includes a section on how to contribute to Scroll, introducing the main repositories and providing guidance on getting involved in Scroll development.

Both Scroll and Polygon zkEVM do not require additional compilers for development, so Scroll, like Polygon zkEVM, does not provide coding examples for developers to follow. However, Scroll offers a single deployment demo, allowing developers to gain hands-on experience with Scroll.

Community and Team Contributors

The number of contributors shows the engagement of the open-source community.

StarkNet

For StarkNet, there are a total of 25 contributors to the StarkNet docs. Four contributors did most of the work.

zkSync Era

For zkSync Era, there are a total of 65 contributors to the zkSync Era docs. Six contributors did most of the work.

Polygon zkEVM

For Polygon zkEVM, there are a total of four contributors to the Polygon docs. One of them did most of the work.

Scroll

Scroll does not open-source its document repository. They are in the process of open-sourcing it, and it will be ready in the near future.

StarkNet

For StarkNet, the documentation has been most active during the launch of Alpha Mainnet. In the past month, eight authors worked on the documentation. They pushed 39 commits to the codebase and 103 commits to all branches. 40 files have changed, and there have been 9,351 additions and 12,886 deletions. There are now two open pull requests and one new issue.

zkSync Era

For zkSync Era, in the past month, 13 authors have pushed 58 commits to the main branch and 116 commits to all branches. On the main branch, 83 files have changed, and there have been 4,472 additions and 2,590 deletions. There is now one open issue and eight open pull requests.

Polygon zkEVM

For Polygon, in the past month, four authors have pushed 43 commits to the main branch and 46 commits to all branches. On the main branch, 125 files have changed, and there have been 1,274 additions and 552 deletions. They merged 17 pull requests, and there are three open pull requests now.

Here is a detailed commit timeline. zkSync Era and StarkNet started working on the documentation last year and update it frequently.

Coding Experience

Overview

After reviewing the documents, developers start writing code during the development phase. The coding experience greatly shapes the development experience.

The coding experience depends on the toolchains, editor experience, and frameworks.

Related toolchains determine whether it is easy to set up a local development environment, debug, and run the code.

Editor experience determines the speed of coding. A good editor experience should include clear syntax highlighting, definitions, and auto-completion.

Frameworks provide a structured environment that significantly accelerates the development process. They come with pre-configured functionalities and reusable libraries, which developers can leverage to write smart contracts efficiently without having to code every function from scratch. Truffle was a popular choice in the past, but now Hardhat and Foundry are more popular.

Remix support can help developers quickly get their hands dirty without setting up their own environments. Currently, this cloud-native development experience only works for the backend smart contracts. It still needs improvements to accommodate Dapp development, which includes both smart contracts and front end.

Hands-on Coding Experience

StarkNet

On StarkNet, there are Warp compilers that compile Solidity code to Cairo, but native Cairo offers a better development experience.

Following the official docs, developers may encounter several issues:

• The Cairo-lang tools do not work for the latest Python version.
• The doc suggests using Pyenv to install Python v3.9.0, but this version does not work for M1 Mac. I switched to Python v3.9.13.
• The recommended way to install Cairo v1.0 is by compiling from the source code. Hopefully, this can be improved in the official release.

The VSCode Cairo plugins only offer basic functions. They are still under development. Here is a screenshot of the example code in the doc with syntax highlighting enabled. The highlight is very basic and does not offer any advanced features, like jumping to definitions/references and refactoring. Also, the formatter does not seem to work correctly.

zkSync Era

zkSync Era and Polygon zkEVM provide a similar experience for writing Vyper and Solidity. Although Remix does not support zkSync Era and Polygon zkEVM, the AI IDE Atlas enables coding and deployment directly within the browser.

Scroll

Scroll provides a smooth experience for writing Vyper and Solidity. It is compatible with the existing Solidity ecosystem.

Framework & SDK Support

StarkNet

StarkNet currently supports three frameworks:

• StarkNet Plugin for Hardhat
• Nile, written in Rust and built by OpenZeppelin
• Protostar, written in Python, helps developers test, compile, and install smart contracts

With Hardhat, developers can easily access the functionality through command lines and use JS to test and deploy Cairo smart contracts.

Nile has fewer features compared to StarkNet. It provides CLI tools to compile, deploy, and interact with blockchains.

Protostar has all the features that developing smart contracts needs. It supports testing, compiling, installing dependencies, and interacting with blockchains.

zkSync Era

zkSync Era provides plugins for popular frameworks like Hardhat and Foundry. The Hardhat plugins support compilation, deployment, testing, and verification.

zkSync Era also provides Java, Python, Go, Swift, and Typescript SDKs to interact with zkSync Era.

zkSync Era also has a basic CLI tool to deposit, withdraw, and create Hardhat projects.

Polygon zkEVM & Scroll

Polygon zkEVM and Scroll are compatible with all existing tools from Ethereum. They offer the smoothest experience to existing Solidity developers.

Compilers & Executions

Overview

Compilers are software that translates high-level programming languages into machine-level code that computers can execute. In this research, we focus on the compilers that translate Solidity into machine-level code that zk(E)VM can execute. This ensures EVM compatibility. Developers can leverage their existing knowledge and tools without needing to learn new languages or practices.

Polygon zkEVM and Scroll support almost all OPCODEs. Everything that works on Ethereum will probably work on zkEVM and Scroll.

Compiler Speed

StarkNet

With the Cairo compiler in StarkNet, we were able to compile the example contracts in 0.2 seconds.

To make StarkNet compatible with EVM, Warp translates Solidity code to Cairo code. However, Warp does not support all features in Solidity due to technical issues. For example, low-level calls will never be supported, even though they are widely used in many big Solidity projects. Developers use low-level calls to save gas and implement certain functions. If Solidity developers plan to fork any projects, they still need to put effort into the migration process.

Additionally, the Cairo code output by Warp is longer than handwritten Cairo code and is hard to read. Although WarpV2 is an improvement from V1, there is still a big gap between handwritten files. It takes Warp 0.93 seconds to transpile a simple storage contract, but there are still many problems with using it in big projects.

zkSync Era

In the zkSync Era, zkSolc is the compiler for Solidity. It takes around 0.6 seconds to compile a standard simple storage contract.

While compiling a Uni V2 code, it takes around 1.6 seconds to compile 12 Solidity files. It works out of the box, although it outputs some warnings. For example, block.timestamp refers to the timestamp of a block and actually refers to the timestamp of the whole batch that will be sent to L1 (meaning, the timestamp of this batch started being processed).

Scroll & Polygon zkEVM

For Scroll and Polygon zkEVM, they don't have customized compilers. They have the same experience as using Solidity compilers.

Compiler & Execution Compatibility to EVM

StarkNet

In StarkNet, Warp is not integrated into any tools yet. Developers need to write their own scripts to compile multiple Solidity files.

I used Uniswap V2 code to test the functionality of Warp. It did not work out of the box. I received lots of incompatible warnings.

Kakarot is working on a new EVM-compatible approach for StarkNet. Kakarot offers an Ethereum Virtual Machine (EVM) written in Cairo. As an EVM, Kakarot can execute EVM bytecode programs, enabling the running of Ethereum smart contracts on StarkNet.

It now supports all OPCODEs from EVM. This approach offers better compatibility. This would be the only EVM-compatible solution on StarkNet in a short period of time. It is backed by Vitalik and StarWare.

Kakarot delivers an exceptionally seamless Solidity development experience. Compatible with all existing Ethereum toolings, such as compilers, Remix, and Hardhat, Kakarot stands at the forefront of Ethereum development.

It boasts customized RPC servers that mirror the deployment experience on the EVM. This ensures a smooth transition for developers familiar with Ethereum's ecosystem.

Additionally, to effectively parse and index EVM-style transactions on Kakarot, the team collaborates closely with established StarkNet explorers. This collaboration focuses on creating custom functions, which are integral to achieving reliable and efficient transaction queries.

The cost of executing an EVM program would be 2-10x more expensive than executing native Cairo programs but will still be significantly cheaper than Layer1. The gas token on the Kakarot would be StarkNet native tokens or ETH.

The Kakarot team started to implement it in October 2022. At the end of 2022, Kakarot had 100% of EVM OPCODEs implemented. In May 2023, Kakarot achieved 100% bytecode equivalence and implemented 8 out of 9 EVM precompiles.

In the landscape of zkEVM, we anticipate Kakarot to elevate the current StarkNet Solidity development experience, bringing it to a level comparable with Polygon and Scroll. This advancement would not only promote the StarkNet ecosystem but also contribute significantly to the overall growth and dynamism of the zkEVM ecosystem.

zkSync Era

zkSync Era does perform slightly differently for around 25 OPCODEs. These OPCODEs work, but developers need to be aware of how they are being processed.

In the current zkSolc, it will output the following warning/errors when compiling solidity code:

• Use ecrecover to validate the signature of a user account.
• Use <address payable>.send/transfer(<X>) without providing the gas amount.
• Uses the extcodesize.
• Check for tx.origin.
• Check for block.timestamp, block.number.
• Internal function pointers are not supported in EVM legacy assembly pipeline, like SELFDESTRUCT, CALLCODE, PC, and EXTCODECOPY.

Three out of nine precompiles are currently supported. Supported precompiles are ecrecover, keccak256, and sha256.

Polygon zkEVM

Polygon zkEVM does not have a special compiler. It uses standard solidity compilers. It achieves over 99% of EVM equivalence. This is measured by running EVM test vectors. There are some differences between several OPCODEs:

• selfdestruct
• extcodehash
• difficulty
• blockhash
• number

For precompiles, ecRecover and identity are presently supported.

Scroll

Scroll does not have a compiler. It uses standard Solidity compilers. There are some differences in several OPCODEs:

• Blockhash
• COINBASE
• Difficulty/ Pervrandao
• selfdestruct
• push0

Three out of nine precompiles are not currently supported. Calls to SHA2-256 (address 0x2), RIPEMD-160 (address 0x3), and blake2f (address 0x9) will revert.

Testing

Overview

Testing is a vital aspect of smart contract development that ensures the quality, functionality, and reliability of smart contracts. It involves validating that each feature behaves as intended and identifying any bugs or issues that need fixing before deployment. By conducting thorough testing, developers can be confident that the software will perform correctly under various scenarios and conditions. This process not only safeguards against potential malfunctions that could impact the user experience but also helps maintain the smart contracts’ integrity and security. Testing also informs developers about potential enhancements or optimizations, contributing to the continuous improvement of smart contracts.

Tenderly is one of the best debugging tools for smart contract development. It provides smart contract execution simulation, a debugger, a gas profiler, forks, and alerting to help developers build better Dapps. However, these functions currently do not support these ZKRUs.

Testing Toolchain

StarkNet

In a hidden link on the StarkNet documentation website, StarkNet mentions tests. It gives an example of initializing the network, deploying the contracts, and implementing one unit test.

StarkNet testing relies on the StarkNet library for blockchain initializations, deployments, and interactions with blockchains. Pytest is used as a testing library. In Cairo1, developers can write unit tests in Cairo with the Cairo test runner.

Developers can also use Starknet.js and other JS testing libraries, like Chai and Mocha, to implement tests for smart contracts. Hardhat is also supported by StarkNet.

The document does not provide any information about setting up local test environments. There is no official support for any node containers.

zkSync Era

zkSync Era supports running a local Testnet instance with one command line. It starts with three Docker containers: Postgres, a local Geth node, and a zkSync Era node. In the test network, there are some rich wallets with a large amount of ETH. Developers can import private keys to access these accounts.

Test libraries like Mocha and Chai are supported.

Polygon zkEVM & Scroll

Polygon zkEVM and Scroll are compatible with all existing Solidity toolchains, which offer a very smooth testing experience.

Deployment

Overview

Deployment processes are crucial in the smart contract development lifecycle, providing automated, consistent, and reliable processes to deploy smart contracts from development to on-chain environments. Good deployment tools can significantly ease the burden of manual deployment tasks, thus speeding up delivery times and reducing human error.

Hands-on Deployment Experience

StarkNet

The deployment for StarkNet takes two steps:

• Declare
• Deploy

Developers first declare their contracts and initialize the contracts later. This theoretically brings better reusability. If developers are forking completely identical smart contracts, developers can skip the declaration and deploy the contracts with the class hash which represents the declaration. If developers try to declare completely identical smart contracts, the program will raise a hard-to-read error log. Developers can find the class hash in it. To declare the example contracts, it takes around 12s.

Before declaration and deployment manually with CLI tools, developers also need to set the environment variables manually. It is easy to forget with the help of configuration files.

The StarkScan gets some bugs when jumping around transactions. It does not show the transaction status correctly without a refresh.

zkSync Era

zkSync Era supports deploying smart contracts with Hardhats. To make the deployment experience smoother, developers can integrate deposit from Layer1 to Layer2 into scripts. In this way, developers do not need to manually bridge gas tokens from Ethereum to zkSync.

It takes around 7s to deploy smart contracts to the testnet.

The zkSync Era Block Explorer provides basic functions for zkSync Era.

Polygon zkEVM, Scroll

Polygon and Scroll can reuse all EVM tech stacks to do the deployment. It runs very smoothly and fast. Developers can almost instantly check the deployed contract. The block explorer offers the same experience as developers on Ethereum.

Highlight New Features

The blockchain landscape is rapidly evolving, and Layer2 solutions are playing a crucial role in addressing the challenges of scalability, efficiency, and user experience. ZKRUs are still in their early stages but have shown immense potential in unlocking new possibilities for developers.

By offering groundbreaking innovations like state-diff, seamless Layer1 and Layer2 communication, and account abstraction, ZKRUs are enabling developers to create innovative projects that push the boundaries of what is achievable with blockchain. These advanced features not only enhance the capabilities of decentralized applications but also pave the way for the mainstream adoption of blockchain technology.

State-diff

StarkNet and zkSync Era use the state-diff technique, which in theory, can yield lower fees. They publish only state diffs rather than transaction inputs, which allows for data compression and reduced storage costs. This would benefit game developers.

Polygon zkEVM publishes all transaction inputs on-chain, relying on expected reductions in data storage costs in the coming years.

Layer1 <> Layer2 Communication

Most ZKRUs provide Layer1 <> Layer2 communication features. For example, zkSync Era gives a governance example utilizing Layer1 <> Layer2 communication. On Layer1, contracts can initiate a Layer2 contract execution. On Layer2, Layer2 contracts can only send a message to a Layer1 contract. Then we can handle the received message on Layer1. Similarly, Polygon gives a coding example about an nft-bridge using the messages property to share information between L1 and L2 polygon zkEVM.

Account Abstraction

Account abstraction is another exciting feature. zkSync Era provides AA natively. Accounts in zkSync Era can initiate transactions, like an EOA, but can also have arbitrary logic implemented in them, like a smart contract. Since zkSync implements AA natively, accounts do not need additional proxy contracts. Even regular EOAs can have gasless payments, which is not possible in just EIP-4337. Polygon zkEVM and Scroll implement AA compatible with EVM. StarkNet is also working on account abstraction. It seeks to realize both signature abstraction and payment abstraction.

We Can Do Better

During the course of this research, we have come to appreciate the tremendous efforts exerted by these ZKRU projects in continuously improving the products and support they offer to developers. However, considering that we are still in the early stages of blockchain adoption and face a relatively small pool of developers, the dedication to enhancing the developer experience will undoubtedly facilitate the projects in attracting future developers and ultimately shaping the future of this industry.

There are some common tips for a better development lifecycle support:

1. Documentation and Understanding:

• Quality Documentation: Comprehensive, clear, and up-to-date documentation is essential for a better developer experience. Ensure documentation completeness, clarity, inclusion of examples, and regular updates.
• Intuitive API Design: APIs should be consistent, intuitive, and well-documented. Evaluate API design based on the clarity and accessibility of the API documentation, as well as ease of accomplishing common tasks.
• Full API Reference and Change Log: Provide a detailed API reference with functions, parameters, return values, and error codes. Maintain a change log to track updates, new features, bug fixes, and deprecated features.
• Case Studies: Showcase examples of the product's applications to inspire and educate developers on solving problems effectively.
• Smooth Onboarding Experience: Streamline the time it takes for new developers to get started by simplifying environment setup, explaining core concepts, and facilitating the creation of basic applications.

1. Usability and Efficiency:

• Usability of Tools: Ensure that the provided tools are user-friendly and intuitive. Measure ease of use by assessing the time it takes developers to perform common tasks.
• Error Messages and Debugging Support: Improve the developer experience with helpful error messages and robust debugging support. You can measure this by intentionally creating common errors and checking how helpful the system's responses are.
• Integration and Compatibility: Evaluate how well the tool or platform integrates with other commonly used tools in the ecosystem.

1. Transparency and Updates:

• Product Status: Timely updates on operational issues, maintenance schedules, and system outages help developers to plan their work effectively.

With the rapid technological evolution in the Web3 space, maintaining a consistently high level of developer experience in a scalable and sustainable manner presents a notable challenge for Web3 projects.

To address this challenge down the road, we recommend projects to explore two directions: leveraging AI to enhance automation and productivity, reducing the need for extensive human resource investment, and harnessing the power of the community by incentivizing contributions.

• AI-powered assistance: Generating and maintaining extensive documentation can be resource-intensive. Large language models may help developers to write and maintain high-quality documents. Furthermore, AI-driven QA bots can provide prompt and accurate answers to developers' queries, further enhancing their experience.
• Incentivize community engagement: To foster community engagement, projects can provide a variety of incentives, both financial and non-financial. For instance, bounty-like programs can be expanded to include contributions in code, codebase testing, documentation improvements, translation work, and invaluable firsthand feedback, which comes directly from users and reflects the real needs that can guide the project team in refining their product. This approach not only has the potential to enhance the quality of resources but also helps in reducing maintenance costs. Acknowledging contributions through active community channels like Discord, Github, newsletters, and others instills a sense of appreciation and motivation among community members.

By emphasizing developer-centric design and offering a compelling developer experience with a joint effort from the community, we can foster a vibrant and inclusive developer ecosystem in Web3 world!

Testing Environment

• M1 Max, 32 GB Memory
• Cairo-lang-compiler v1.0.0-alpha.6
• Python v3.9.13
• Node v16.15.0

Appendix

StarkNet ZKRU GitHub Repos

1. get-starknet: Wallet connector between StarkNet and dApp.
2. starkgate-contracts: Bridge between StarkNet and L1.
3. starkNet-P2P-spec: Specification of P2P protocol for StarkNet nodes.
4. StarkNet-token
5. Cairo: Rust-written compiler for Cairo.
6. StarkNet-api
7. Papyrus: StarkNet full node written in Rust.
8. Blockfier: Rust implementation of the transaction-executing component in the StarkNet sequencer, responsible for creating state diffs and blocks.
9. StarkNet-specs: Specifications for StarkNet implementation and interaction.
10. Starkware-crypto-utils: Signatures, keys, and Pedersen hash on STARK-friendly elliptic curve.
11. Cairo-lang

zkSync Era ZKRU GitHub Repos

1. Era-zk_evm: zkEVM implementation for Era.
2. Zksync-cli: CLI tools that bootstrap new projects and support deposit/withdraw on L1 <> zkSync Era Testnet.
3. Harhat-zksync: A collection of 5 Hardhat plugins for zkSync Era.
4. Era-compiler-llvm-builder: The builder of the zkEVM fork of the LLVM framework.
5. Era-compiler-vyper: The zkEVM Vyper compiler.
6. Era-system-contracts: Contracts that instantiate some recurring actions on the protocol level.
7. Era-zksync_tester: Assembly runner for zkEVM testing.
8. Era-compiler-tester: zkEVM compilers integration test framework.
9. Era-compiler-llvm: The zkEVM fork for the LLVM framework.
10. Era-compiler-solidity: The zkEVM Solidity compiler.
11. Era-compiler-llvm-context: The shared LLVM IR generator logic of the compilers for zkEVM.
12. Era-zkEVM-assembly: The zkEVM assembly tools.
13. Era-contracts: Smart contract submodule for zkSync Era.
14. ZkSync-era
15. local-setup: zkSync local development setup.
16. V2-testnet-contracts: Core zkSync smart contracts on testnet.
17. Era-heavy-ops-service: CPU/GPU Based Prover for zkSync Era.
18. Era-sync_vm: Circuit Implementation of zkVM for zkSync Era.
19. Era-zkevm_opcode_defs: Definitions of zkEVM opcodes.
20. Solidity_plonk_verifier: Solidity verifier for Plonk.

Polygon zkEVM ZKRU GitHub Repos

1. Pil-stark: Generate a STARK from a PIL. PIL is the language for Polygon Hermez.
2. zkEVM-node: Go implementation of a node that operates the Polygon zkEVM Network.
3. zkEVM-prover: Prover for zkEVM.
4. zkEVM-bridge-service: A backend service written in Go, that enables clients, like the web UI, to interact with the bridge smart contract by providing Merkleproofs.
5. zkEVM-rom: ******zkASM source code of the zkEVM. zkASM is the assembly code for the zkEVM.
6. PIL Compiler: Polynomials identity language compiler.
7. zkEVM-comms-protocol: Emulate the real zk-prover interface and functionality
8. zkEVM-proverjs: zkEVM proof generator reference written in Javascript
9. zkEVM-testvectors: Test vectors for polygon-hermez zkevm implementation
10. zkEVM-commonjs: Javascript library implementing common utilities for polygon-hermez zkevm
11. pilcom-vscode: Syntax highlight for PIL
12. zkasmcom-vscode: Syntax highlight for zkASM language
13. ShplonkJS: shPLONK javascript implementation
14. zkASMCom: Compiles zkasm file to a json ready for the zkExecutor
15. zkEVM-contracts: Smart contract implementation which will be used by the polygon-hermez zkevm
16. Piltools: PIL Tools in C++ to verify and browse in evaluations
17. zkEVM-stroage-rom: Compiles .zkasm storage to a json file****
18. spearbit-ethereum-state-tests: Test for different Ethereum clients

Scroll ZKRU GitHub Repos

1. Go-ethereum: Forked from Ethereum, ZK-Rollup adapts the Go Ethereum to run as Layer2 Sequencer
2. zkEVM-circutis: Forked from Ethereum Applied ZK, circuits for zkEVM
3. MPT-circuit: MPT Circuit
4. zkEVM-specs: Forked from Ethereum Applied ZK, zkEVM specifications
5. scroll-zkEVM
6. zkTrie: Wrap go ethereum into rust
7. Halo2: Forked from Ethereum Applied ZK, proving system
8. Halo2 lib: Forked from Ethereum Applied ZK, Halo2 library
9. Posedion-circuit: Poseidon hash circuit and primitives
10. Snark-verifier: Forked from axiom-crypto, Generic (S)NARK verifier
11. web3go: Forked from openWeb3, golang SDK for supporting all Ethereum RPC
12. Frontier: Forked from Polkadot, Ethereum compatibility layer
13. Halo2curves: Forked from Ethereum Applied ZK, BN256 pairing library that implements original traits from zkcrypto
14. Trace-dumper: Deploy contract and call contract api and get trace store into file just in one cmd
15. Poseidon: Forked from Ethereum Applied ZK, poseidon is built to be used in SNARK and non native recursion friendly transcript for Halo2
16. Halo2-snark-aggregator: Halo2 Circuit Aggregation
17. Substrate: Forked from Polkadot, a framework to help start a blockchain
18. Rpc-gateway: Forked from Conflux, RPC for scroll
19. Rollup-explorer-backend: Scroll explorer

Reference

https://polygon.technology/blog/pricing-gas-in-polygon-zkevm

https://docs.starknet.io/documentation/starknet_versions/limits_and_triggers/

https://book.starknet.io/

https://cairo-book.github.io/

https://www.argent.xyz/blog/the-era-of-account-abstraction/