Packaging Complexity and System Complexity in Vitalik System Design

1 Introduction

One of the main goals of the Ethereum protocol design is to reduce complexity: to keep the protocol as simple as possible while maintaining chain functionality and efficient performance .

Most of the Ethereum protocols were designed from 2014 to 2016. The protocols themselves are not perfect, and they have been working on reducing the complexity of the Ethereum protocol.

One of the difficulties is defining complexity itself. One way is to split it into 2 dimensions to consider:

• 1) encapsulated complexity: When the system has subsystems, although the subsystems are complex internally, they expose a simple interface to the outside world.
• 2) systemic complexity. Systemic complexity: When different parts of the system cannot be split cleanly, there are complex interactions between the parts.

2. BLS signature vs Schnorr signature

For details, please refer to the blog:

• ECDSA VS Schnorr signature VS BLS signature

BLS and Schnorr are two popular cryptographic signature mechanisms based on elliptic curves.

The BLS signature looks mathematically simple:

• BLS signature: $\sigma =H\left(m\right)\ast k$
• BLS 验 签 ：$e\left(\right[1],\sigma )\stackrel{?}{=}e\left(H\right(m),K)$

where $H$ is the hash function,$m$ is the message to be signed,$k$ and$K$ is the signer's private key and public key.
BLS signatures look simple, but the real complexity is hidden in$In\; the\; definition\; of\; the\; e$ function:elliptic curve pairings.

BLS signatures require pairing elliptic curves, while Schnorr signatures only require basic elliptic curves . But the signature and verification logic of Schnorr signatures is more complicated:

• Schnorr signature: the message to be signed is $M$：

  • Select random value $k$
  • Let $r=g^k$
  • 令$e=H(r||M)$ , where$||$ means splicing,$r$ is represented as a bit string.
  • 令$s=k-$
    The complete signature of$x$$e$$(s,e)$ pair。

• Schnorr signature verification:

  • 令$r_{}=g^s{y}^e$
  • 令$e_{}=H(r_{}||M)$
    若$e_{}=e$ , the signature is passed.

Which signature is easier? It depends on what you focus on. BLS signatures have a lot of technical complexity, but that complexity is hidden in $below\; the\; definition\; of\; the\; e$ function. if$The\; e$ function is regarded as a black box, and the BLS signature is indeed very simple. Whereas Schnorr signatures have less total complexity, BLS signatures have more pieces, allowing for subtle interactions with the outside world. Such as:

• 1) Realize BLS multi-signature (for 2 secret keys $k_1,k_2$signatures) is easy: only ${\sigma }_1+{\sigma }_2$. However, Schnorr multi-signature requires 2 rounds of interaction, and also needs to consider dealing with Key Cancellation Attack .
• 2) Schnorr signatures need to generate random numbers, while BLS signatures do not require random numbers.

Elliptic curve pairings are a powerful "complexity sponge" that contains a lot of encapsulation complexity inside, but the overall solution has less system complexity.

Similarly, for KZG commitments (requiring pairings) , it has more complex internal logic than inner product arguments (not requiring pairings).

3. Cryptography vs Cryptoeconomics

Many chains need to be designed with Cryptography vs Cryptoeconomics in mind. For rollups , the choice is between validity proofs (aka ZK-SNARKs) and fraud proofs.

ZK-SNARKs are complex technologies. But the working principle behind ZK-SNARK can be explained clearly in a blog post. In ZK-SNARKs, verifying certain computations requires many times more complexity than the computations themselves. This is why ZK-SNARKs for the EVM are still in development, and fraud proofs for the EVM are in beta.

• Efficient implementation of ZK-SNARK requires various challenges such as circuit design with special optimization + use of unfamiliar programming languages.
• Fraud proofs are simpler in nature: if someone challenges it, you just run the corresponding computation directly on-chain. A binary-search mechanism is sometimes added for efficiency, but this does not add much complexity.

Although ZK-SNARKs are complex, they are packaging complexity. And relatively low complexity fraud proofs, which is the system complexity.

Examples of system complexity in fraud proofs are:

• 1) Careful incentive engineering is required to avoid the Verifier dilemma .
• 2) If implemented in the consensus layer, additional transaction types need to be defined for fraud proofs, and the situation when multiple actors are competing to submit fraud proofs at the same time needs to be considered.
• 3) Depends on synchronous network.
• 4) Support censorship attack, can also be used to commit theft.
• 5) Rollups based on fraud proofs require liquidity providiers to support instant withdrawals.

For the above reasons, and from the perspective of the complexity of cryptographic schemes, ZK-SNARKs have longer-term security: ZK-SNARKs have are more complicated parts that some people have to think about, but they have fewer dangling caveats that everyone has to think about.

4. Other examples

• Proof of work (Nakamoto consensus): With low encapsulation complexity, the mechanism is very simple and easy to understand, but has higher system complexity (like selfish mining attacks ).
• Hash functions: High encapsulation complexity, but very low system complexity that is easy to understand.
• Random shuffling algorithm: The shuffling algorithm can:
  • For internal complexities (like Whisk ), with easy-to-understand gun randomness.
  • is internally simple, but has weaker randomness and is more difficult to analyze (high system complexity).
• Miner extractable value ( MEV ): A very powerful protocol that supports complex transactions, but is very simple internally, and these complex transactions can have high system complexity and affect block production incentives in an unconventional way.
• Verkle trees: Verkle trees have some encapsulation complexity, but they are actually a bit more complicated than Merkle hash trees. However, on systems, Verkle trees provide a relatively clean-and-simple interface for a key-value map. The main system complexity "leak" is that it is possible for an attacker to manipulate the tree such that a particular value has a very long branch, but this risk is the same for Verkle trees and Merkle trees.

5. How to balance package complexity and system complexity

Choosing low package complexity also means low system complexity in most cases. Some packaging complexity also affects system complexity.

Taking the two-level state tree of Ethereum as an example, it is a tree of account objects, and each account object has its own storage tree:

The structure of the two-level state tree of Ethereum is complex, and its complexity is seen at the beginning. It seems to be well encapsulated, and the rest of the protocol reads/writes to the two-level state tree through a key/value store, so there is no need to pay attention to the specific structure of the tree.
But then, this encapsulation complexity has a systemic effect: accounts can have arbitrarily large storage trees, which means that there is no way to reliably expect a particular piece of state (eg, "all accounts starting with 0x1234") to have predictable size. This makes it harder to slice state into pieces, complicates synchronization protocol design, and attempts to distribute the storage process .
Why does encapsulation complexity become system complexity? Because the interface has changed.
How to solve it? The current recommendation is to use a Verkle tree instead , with a well-balanced single-layer design for that Verkle tree.

In fact, in the process of packaging complexity and system complexity trade-off, more practical tests can be balanced.

References

[1] Vitalik February 2022 blog Encapsulated vs systemic complexity in protocol design