There are fundamentally two kinds of trust needed in Web 3: “Programmed Trust” ensured by consensus and “Cryptographic Trust” ensured by ZK. In this article, we will describe how these two pieces play a role and how the scaling of each will unlock a new era ready for mass adoption.
Industry’s trust in the consensus mechanism has laid a solid foundation for all development on top of blockchain. Without the networks of decentralized nodes obliged to consensus mechanisms ensuring that the networks will always be responsive and sufficiently secure, no dApps will ever be built in the first place.
In the case of PoS, computing parties interested in participating in the network will need to stake tokens into smart contracts, a type of programmed execution run by the validators, to ensure there will be no misbehavior, or else slashing happens and the staked token will be gone. In short, the economic value of the staked token restrains the validating participants from misbehavior.
With staking programmed into smart contracts, developers are then assured that Ethereum is a safe world to construct things on top of. Such “Programmed Trust” has functioned like a booster, fueling the developers to build with confidence, bootstrapping PoS networks like Ethereum to expand its ecosystem ferociously and ultimately reaching functionality escape velocity.
However, as essential as “Programmed Trust” is to a network, it is by far the hardest thing to obtain as it demands intense capital allocation (staking), and a tremendous amount of decentralized nodes willing to and capable of participating in the network. For example, Ethereum currently has close to a million validators. As a result, we have mainly seen Ethereum acting as the only center of consensus that is deemed sufficiently secure and decentralized. Furthermore, the difficulty in establishing such “Programmed Trust” hinders innovations since building dApps on top of Ethereum alone significantly limits the flexibility and capability of dApps.
To tackle this problem, EigenLayer has created a shared consensus layer to allow any network in need of its own distributed validators to leverage EigenLayer’s pooled security (aggregated by ETH stakers restaking ETH or LST to EigenLayer) to gain enough decentralized nodes with staked economic value to bootstrap network security. Put simply, networks can now “borrow” validators from Ethereum, on demand, to gain consensus integrity so that the service provided by such networks can be trusted and leveraged upon launch. By abstracting the need to build “Programmed Trust”, EigenLayer allows developers to consume trust and revolutionizes how networks build and bootstrap in the early stage, significantly lowering the cost of innovation, as well as the entry barrier.1
With EigenLayer, the number of innovations/networks is expected to grow exponentially. As “Programmed Trust” becomes widely commoditized, more networks can now bootstrap consensus in the very beginning to provide services to the masses. However, though consensus integrity is guaranteed, the performance of the network with “borrowed” nodes is not, since performance was never part of the package.
Sure, there will be sufficient staking (restaked from ETH stakers) and sufficient nodes (ETH validators and more), making the network secure and decentralized, but there still is the scalability issue. I am sure we are all familiar with the blockchain trilemma and understand the tradeoff here between scalability, security, and decentralization. Maximum decentralization demands a great number of validators vetting each and every transaction, increasing both censorship resistance and sadly, block generation time.
Thus, we believe the commoditization of “Programmed Trust”, on one hand, will certainly drive the emergence of innovative networks by granting sufficient security and decentralization as a service. On the other hand, it will also open up an entire market of new networks that will demand “Cryptographic Trust”, or in other words, ZK, to increase network processing throughput without compromising security.
More specifically, ZK executes off-chain complex functionalities that could require multiple smart contracts to fulfill, and then have network nodes execute only a single settlement contract based on the result and proof committed on-chain. Via this approach, ZK drastically compresses the computation needed from network nodes, granting networks the “Cryptographic Trust” to ensure a sufficient level of scalability in a trustless manner.
Besides scaling the network by reducing computation load, ZK also helps networks to be as decentralized as possible to capture more value. To clarify, let us make a distinction between the execution obligations of 1) network validators for running the blockchain, and 2) third party computing nodes for arbitrary executions.
For network validators, we believe these nodes should maximize their value in assuring the consensus of the network by being both the DA layer and the settlement layer. Using Ethereum as an example, the nodes of Ethereum have been increasing their value-add per validation by conducting mainly verification of settlements, rather than verification of transactions. In other words, with the same cost spent in one validation, Ethereum nodes add more value to Ethereum by settling.
The same concept applies to other networks as well. The nodes or the validators of the network shall mainly focus on ensuring the “Programmed Trust” for consensus to gain greater value-add, while leaving cumbersome computation to a party that provides “Cryptographic Trust” aka execution with integrity.
In short, we do believe by offering “Cryptographic Trust” for execution to abstract the computation burden away from all blockchain validators, ZK empowers blockchains to capture more value by doing less (i.e. focusing on executions that strengthen consensus).
As exemplified by Ethereum, in order to capture the value of consensus, networks need to be sufficiently decentralized and secure. However, the new networks that leverage EigenLayer’s “Programmed Trust” to bootstrap will most likely require specific and (perhaps high) infrastructure requirements for their network nodes, because if not, they could simply leverage the existing chains to build out their services. Yet, a high infrastructure requirement for nodes inevitably reduces the degree of decentralization, and in the case of EigenLayer, the unoccupied hardware capacity of some Ethereum validators can be limited, benefitting only those with powerful hardware and leading further to centralization.
Therefore, for networks to be decentralized and secured enough to capture the value of consensus, ZK could aim to take care of any complicated computation that might be previously designated to the network nodes, lowering the hardware requirement to ensure a wider representation in the network. In doing so, ZK also minimizes the potential risk and complexity of restaking by making solo staking more attractive, since lower hardware requirement implies weak validator friendliness. This mitigates operator centralization risks so that “Programmed Trust” could be further adopted at scale, and further hyperscale Ethereum for the better!
With ZK minimizing network overhead, pumping up value-add per node, and helping with network decentralization, we are certain that there will be an eventual bloom of adoption. To address such needs, our distributed proving infrastructure is therefore positioned to deliver specialized ZK computing, enabling networks (let it be co-processors, middlewares, dApps, or blockchains) to have the unprecedented flexibility to leverage ZK without having to worry about the underlying compute infrastructure (more details in this article). Together with EigenLayer, we are collectively abstracting away the need to build trust once for all and allowing developers to solely focus on shipping products for the first time in the industry.
Of course, EigenLayer does so much more - increasing the capital efficiency of stakers, utilizing the unoccupied hardware capacity of Eth validator, etc. But for the sake of this article, we will stick to the developers’ angle and how it creates a permissionless environment for more innovations to take place. ↩︎