The Digital Business Trilemma is a real phenomenon that is leading digital services towards a critical fork in the road, as was recently discussed in two blog posts written by Baseline Protocol community members (see here and here).
To quickly recap, the Digital Business Trilemma (DBT) states that only two of three characteristics can be met at the same time for all participating digital service consumers and providers:
- Decentralization
- Security
- Performance
DBT is a weaker version of the Blockchain Trilemma (BT) described by Ethereum’s founder, Vitalik Buterin. Unlike the BT, the DBT does not require global data consistency and integrity from all participants, whereas those principles are crucial to blockchains.
In the blogs published by Baseline Protocol community members, it was highlighted as a consequence of the DBT and the continuously increasing level of decentralization, that each participant must be able to do the following three things together to minimize the tradeoffs imposed by the trilemma:
1. Authenticate and authorize every other participant for every single digital business interaction at all times,
2. Prove and verify the authenticity, integrity, and correctness of every digital service transaction, and its associated supply chain of prior digital transactions informing and triggering said digital service transaction,
3. Minimize the exchange of sensitive data in a digital service transaction, ideally to zero.
These critical security requirements can be summarized as Zero Trust Multiparty Coordination under Zero-Knowledge (ZTMCZK).
As was outlined before, standard-compliant implementations of the Baseline Protocol offer a direct path to achieve ZTMCZK while also meeting other important enterprise security and business requirements. In this report, we will discuss what type of technologies would meet the above requirements. While there are existing established technologies and standards to meet requirement 1, requirements 2 and 3 are more difficult to satisfy as they deal with the provable correctness of digital transaction execution and data privacy.
Over the last 12 months however, multiple projects have developed scalable general-purpose (as opposed to domain specific) solutions which meet most, if not all, of the outlined key requirements. The most promising development is called zkEVM, short for zero-knowledge Ethereum Virtual Machine. The EVM is the execution engine of Ethereum and all Ethereum-compatible solutions from sidechains such as Polygon to Layer-2 scaling solutions such as Arbitrum. As the name suggests, zkEVMs are the execution framework in zero-knowledge Ethereum Layer 2 scaling solutions such as ConsenSys zkEVM, Hermez 2.0, zkSync, or Scroll.
The Baseline Protocol, Layer 2, And zkEVM
As Baseline Protocol Implementations (BPIs) typically utilize public Blockchains as part of the technology stack, a BPI behaves similarly to a zero-knowledge Layer 2 solution, except that BPIs do not typically involve the use of digital tokens. A zkEVM can therefore function as the standard-mandated execution engine of a BPI. Let’s now discuss why zkEVMs are so well suited for this purpose within a BPI.
Before we dive into details, and as a brief reminder, we will review what a zkEVM-Rollup looks like from a high level in the diagram below. It is important to note that any roll up follows the basic principles outlined here.
As seen above, zkEVMs operate in the same way a typical Layer 2 zk-rollup would. zkEVM rollups are faster and cheaper than transactions directly on Ethereum and just as secure – all the while processing Solidity Smart Contracts. Therefore, users can send Ethereum-type transactions from their favorite wallet, and developers can use the same Solidity Smart Contract development and deployment toolchain as they use with Ethereum. In essence, to use existing applications or create new ones, existing transaction execution logic in Solidity Smart Contracts can be reused, or written into new contracts where it can be executed by a zkEVM, just like the EVM does already. This is just what we want for a BPI – it is easy to use and familiar to program! The zkEVM even follows the high-level architecture framework of a BPI, as shown below for comparison. The only change required is to replace the word “CCSM” with the word “Ethereum” in the diagram below:
When taking a closer look, we find even more similarities between the zkEVM and Baseline Protocol Stack:
In the diagram above, the RPC corresponds to the BPI abstraction layer, with parts of the Sequencer and Synchronizer representing the CCSM abstraction layer. The processing layer is represented by the Aggregator, Prover, and state, whereas the Middleware consists of parts of the Sequencer, Aggregator and Synchronizer. Note that the smart contracts representing the bridge from Ethereum to the L2 and vice versa and the smart contract verifying the zk-proofs are present, but are not explicitly shown above, and will be discussed below as they are important.
The zkEVM Under the Hood
Let’s now take a look under the hood and see what each module does.
Synchronizer:
- Gets all the data from Smart Contracts (transactions, events & validity proofs) and stores it in a database accessible via JSON-RPC. The Synchronizer also handles possible Ethereum blockchain reorganizations.
Sequencer:
- Collects transactions, publishes them in a batch to Ethereum, and participates in consensus if there is more than one sequencer.
- Receives transaction fees (Ethereum plus L2) from the senders of the published transactions.
- Pays Ethereum Fees for submitting the block digest transaction to Ethereum) and, depending on pending batches, pays the L2 Fees to the Aggregator(s).
Aggregator:
- Processes transactions published by the Sequencer(s) and participates in consensus if more than one aggregator is present (ensuring a sufficiently decentralized aggregator).
- Builds the zk-Proof(s) using the Prover.
- Receives L2 Fees from the Sequencer(s).
Prover:
- Creates zk-validity-proofs for all zkEVM transaction batches. Note that every Aggregator will use a Prover to validate its transaction batch and provide Validity Proofs.
- This is the heart of zkEVM, as detailed later in the report.
Bridge Contracts on Ethereum and the L2:
- Smart Contracts to transfer/withdraw assets between the two layers, Ethereum and L2.
- A combination of two smart contracts; one deployed on Ethereum and the second one on the L2 itself.
- The Smart Contracts are identical except for where each is deployed. Layer 2 interoperability allows for a native mechanism to migrate assets between different L2s and is part of the bridge’s smart contract.
Verifier Contract on Ethereum:
- Verifies, via smart contract, any Ethereum-supported zk-proof, ensuring the validity of every batched transaction in the L2 block.
Now that we’ve broken down the structure of the zkEVM, it’s important to understand the heart of the zkEVM: the Prover. This component follows an interesting design pattern, namely the one of a single CPU microprocessor which is nothing but a combination of state machines:
It executes instructions the textbook way, as a single-CPU microprocessor would:
When translated to our zkEVM scenario, the Prover at a high-level design looks something like this:
The Prover State Machine, as shown above, is, therefore, a cluster of State Machines (SMs) to improve processing efficiency through built-for-purpose SMs:
- Main State Machine as the control unit functions primarily as a processing and Secondary State Machine manager that manages instruction sequences and passes them to secondary state machines based on the Ethereum opcode to be processed and its accompanying data values.
- Secondary State Machines, similar to the ALU(s) above, receive instructions from the main state machine and generate proofs for one thing only. (this applies to Binary operations, Storage operations, Memory operations, Arithmetic operations, and the like). Note that there are dependencies between secondary state machines, for instance between the Storage state machine and the Poseidon hash state machine.
Auxiliary State Machines like Padding or Memory Alignment, support secondary state machines in the same way that secondary state machines support the main state machine but are not shown in the figure above for the sake of simplicity in this presentation.
Note that the above architecture is specific to Polygon Hermez, and there are sometimes significant differences between specific zkEVM implementations. Those differences, however, do not matter until specific deployment scenarios are considered. We will discuss such scenarios in future reports.
Now that we’ve explained the Prover’s construction, let’s get to the good part – executing an Ethereum state change. Since an Ethereum smart contract function triggered by an Ethereum transaction can be represented as a sequence of opcodes applied to input data, we see that a state transition can be represented by that same series of zk-proofs – one for each opcode used to execute a smart contract command. These proofs are subsequently collected in a zk-proof batch for the Ethereum transaction, and another zk-proof of these zk-proofs is generated. These new zk-proofs are then batched into a block for each transaction in the block (based on the previously committed block by the sequencer), and a final zk-proof is generated for the entire block. This zk-proof is then committed to Ethereum as a validity-proof-of-correct-execution of all transactions in the L2 block. Subsequently, and before the L2 block is finalized, this zk-proof must be verified through the Verifier contract on Ethereum.
How It All Fits Together
When imagining the use of a zkEVM as the execution framework of a BPI, we think that similarly to Ethereum, the business logic in workflows will be represented as smart contract code lines executed through a zkEVM. When executing a business workflow, the only remaining problem lies in the fact that in order to maintain the integrity of smart contracts, transaction digests must be obfuscated. Unfortunately, the transaction digest posted by a sequencer to Ethereum does not automatically obfuscate transaction data. To preserve privacy of business workflow transactions this transaction digest must be replaced by a cryptographic commitment of the sequencer to the BPI block and its transactions, including the transaction sequence, before the zk-proofs are committed to Ethereum by the aggregator(s). Since the committed zk-proofs are verified on Ethereum, and thus finalized, all BPI transactions are provably correct as required by the Baseline Protocol standard.
The use of a zkEVM within a BPI implies a big upgrade to the development process that will be attractive to developers. Rather than worrying about proving business logic with handwritten zero knowledge circuits, the use of a zkEVM represents the chance to encode all business logic into smart contracts. By simply running this business logic through a zkEVM, arithmetization of that logic into zero knowledge circuits is abstracted as the zkEVM automatically proves the validity of the program’s execution. This will allow traditional web3 developers and enterprises to focus on easier endeavors such as writing Solidity code, and using Ethereum development and deployment toolchains, while the zkEVM handles the private and verifiably correct execution of business logic. Since this approach simplifies BPI development and usage, and allows for all the advantages of Ethereum without any of its perceived drawbacks, we believe that using the zkEVM as a BPI execution framework will greatly increase the adoption of the Baseline Protocol pattern.
See here to learn more about the Enterprise ZK R&D team or get in touch.
