Introduction
While working at Status I have come to realize that the path to decentralization is only brought forward by making any network, more accessible. This would require minimal bandwidth usage as well as compute utilization.
In discussions and debates surrounding the optimal type of zk-EVM, a significant oversight often arises with regards to the perpetuation of critical security vulnerabilities within the existing tooling that accompanies the pursuit of "compatibility." Although creating an entirely new ecosystem of tooling for a novel high-level language that compiles to bytecode is undeniably challenging, it becomes necessary to broaden the scope of decentralization, a fundamental principle in the space.
How type 4 zk-evm's differ from the rest
Type 4 zk-evm's take one major requirement out of the game, "compatibility". With this, they are able to make use of specialized languages, which are optimized to be faster at proving, which have the following advantages -
- more efficient transaction validation
- reduced risk of delays due to block processing
- throughput of the network
which ultimately all lead to better user experience. If the user experience is great, then it is almost guaranteed that the network will attract more users and node operators over time, increasing the decentralization.
How some disadvantages are truly the strengths
The main disadvantages of type-4 systems that come to mind are -
- lacking compatibility with existing ethereum applications
- lack of capability to use shared infra
- lack of tooling
There are ways to convert these disadvantages into strengths, as explained -
-
lacking compatibility with existing ethereum applications
Compatibility is not a concern for teams that would be zero-ing in on a specific chain for their use-case. It is worth the engineering effort to rewrite parts of a protocol to support a chain which will bring in more value. However, teams generally do not have this bandwidth, and efforts must be taken to ease the process for them. There are a handful of applications which use inline bytecode in their contracts, which would most likely not be necessary for type 4 zk-evm's, making the engineer's life easier in the long run, in terms of maintenance of such a codebase.
-
lack of capability to use shared infra
Shared infrastructure does offer advantages for Type-1 and Type-2 zk-EVMs, but it also brings along the risk of inheriting security flaws from the existing infrastructure. However, when specialized infrastructure is employed, although there is still a possibility of security issues, they can be audited by multiple teams, thereby reducing the overall risk exposure. By subjecting the specialized infrastructure to rigorous security audits, the chances of vulnerabilities can be minimized, providing increased confidence in the security of the zk-EVM system.
-
lack of tooling
The absence of tooling for a Type 4 system can be mitigated by implementing bounty programs, which attract a new set of engineers to contribute and harness the benefits of available open-source resources. In contrast, other types of zk-EVM systems often face challenges in codebase retention and maintenance due to developers frequently transitioning between different systems.
What's it looking like for type-4 systems now?
zkSync Era is a type-4 zk-evm with solidity support. A dune dashboard shows that it has 633M USD TVL as on this date. While most of the addresses belong to airdrop farmers, it is only after the airdrop that we will see actual use of this network. Another dashboard shows that the median transaction fee is 0.29 USD, which is lower than other zk-evm networks. Ultimately, this will drive user adoption, and with better tooling, is a very viable competitor in the space.
Thanks for reading!