Interpretation of EIP-5988 Proposal: Optimizing Compilation Time and On-Chain Space for L2 Interoperability

Source: Dark Side of the Moon, PANews Lab

As the Ethereum Shanghai upgrade approaches, various proposals related to it have emerged, hoping to be deployed alongside the upgrade. EIP-5988 has recently been submitted to the official Eips.ethereum webpage. The main purpose of EIP-5988 is to provide precompiled operations for various ZK communications with the mainnet, in order to save compilation time and on-chain space required for communication.

EIP-5988 primarily aims to solve communication issues between various L2 and L1. With this proposal, ZK-based L2 can maintain compatibility with the mainnet's security without compromising their proof efficiency, while OP-based L2 can further enhance settlement efficiency using the mainnet.

Moreover, EIP-5988 utilizes the Poseidon hash algorithm, which will serve as a unified precompiled proof generation method for various L2. This is also the first time a new algorithm potentially compatible with Ethereum may be introduced, having previously been attempted mainly in various L2, but its security has not been extensively tested in mainstream applications over a long period, which is a major point of controversy surrounding EIP-5988.

Connecting Communication Between L2s

In the description of EIP-5988, the most important aspect is the introduction of a new communication method between Layer 2s, packaging various Rollup scaling algorithms into a consistent compilation layer for the Ethereum mainnet to call upon, leveraging Ethereum's compatibility for communication among various Layer 2s.

Intuitively, this means that under solutions like STARK/SNARK, a precompiled measure will first be implemented. Once the proposal takes effect, it will establish a format conversion space for ZK proof generation. The Ethereum mainnet does not need to consider the specific source of messages; it only needs to determine whether they conform to the compilation format, allowing for acceptance or rejection operations.

Currently, there are widespread compatibility issues between L2 and the Ethereum mainnet. Taking ZK-based systems as an example, there are mainly two obstacles:

1. ZK systems have different technical paths; zk-SNARK and zk-STARK are the two more mainstream ones, and there is a lack of unified standards for interoperability between different instances.
2. L2 may choose self-developed languages, such as StarkWare's Cairo, which differs from the Solidity used by Ethereum, requiring mutual compilation for interoperability.

After the implementation of the unified precompiled layer, the message formats accepted by Ethereum will be standardized, and any incoming L2 data types will need to be pre-converted, thereby saving the transmission—waiting—response time between L2 and the mainnet.

Currently, before the unified precompiled layer takes effect, there are three ways for communication between L2s:

• CEX/DEX: First, tokens are transferred to exchanges that are compatible with more than two L2s. However, this only allows for asset conversion and does not enable direct message transmission.
• General Cross-Chain Bridges: These are built on top of traditional L1 cross-chain bridges, allowing for asset conversion and, in some cases, message transmission leveraging the mainnet.
• L2 Cross-Chain Bridges: Represented by Orbiter Finance, these primarily facilitate cross-chain operations among various Rollups and can be seen as a specific domain cross-chain bridge model.

The unified precompiled of EIP-5988 directly standardizes the data formats of various L2s, rather than providing a direct asset interoperability model across L2s. It remains an upgrade and expansion of the Ethereum mainnet, without compromising its security.

Leveraging the compatibility from the Ethereum mainnet will greatly enhance the interoperability of various L2s, aligning more closely with Ethereum's future modular upgrade approach.

Poseidon’s Power Awaits Verification

However, beyond its advantages, attention must also be paid to the issues surrounding the unified precompiled, which mainly focus on the "Poseidon" hash algorithm used, a central point of community discussion.

Essentially, the workflow of EIP-5988 introduces a new precompiled contract that implements functions used in the Poseidon cryptographic hash algorithm, enabling interoperability between EVM and ZK / Validity rollups, as well as introducing more flexible cryptographic hash primitives to EVM.

The main function of the hash algorithm is to convert various incoming numerical and non-numerical (text, images, etc.) data into a consistent encoding format, facilitating recognition and invocation by computers. In the field of cryptography, the most well-known application is the Merkle tree proof, which is essentially a hashed representation of a binary tree, widely used in various node communications, such as asset proofs between wallets and exchanges.

The Poseidon algorithm is not a brand new solution; at least Vitalik has previously introduced its main functions, and it has good compatibility with various ZK algorithms, which is a primary reason for this update focusing on Poseidon.

The Poseidon hash function was officially launched in 2019 and, compared to popular "traditional" hash functions (like SHA256 and Keccak), it has not undergone rigorous effectiveness and security testing. Some L2 or other applications have already used it in Ethereum and other blockchain networks, and so far, there have been no serious errors reported with the Poseidon algorithm.

Blockchain cases that have already used or plan to use the Poseidon algorithm include:

• StarkWare plans to use Poseidon as the main hash function for StarkNet and promises to add built-in Poseidon function capabilities in the Cairo language.
• Filecoin uses Poseidon for different Merkle tree proofs and for two-value commitment scenarios.
• Dusk Network uses Poseidon to establish a Zcash-like privacy protocol for transactions.
• Sovrin uses Poseidon for Merkle tree-based revocation transactions.
• Loopring uses Poseidon for private trading scenarios on Ethereum.
• Polygon employs Poseidon in the Hermez ZK-EVM.

The security of the Poseidon algorithm does not stem from design flaws but rather from a lack of verification in high-value scenarios of large-scale practical applications. If it is ultimately incorporated into the Ethereum mainnet, it will be its most significant application across the entire Ethereum and even the crypto ecosystem.

Conclusion

The vertical layering between Ethereum and Layer 2 scaling solutions has been established, but security and compatibility issues still exist between the layers. Therefore, various L2s are making extensive attempts to "leverage the security of the Ethereum mainnet and enhance their compatibility with the mainnet." However, while fostering the prosperity of the L2 ecosystem, this has also inadvertently triggered a fragmentation crisis among L2s.

This fragmentation of the ecosystem is not conducive to the long-term development of Ethereum and EVM. Competition among various L1s is ongoing, and how to bridge the ecological fragments has become a necessary measure that the Ethereum mainnet needs to actively undertake. Improving from the mainnet and requiring various L2s to undergo unified format conversion is its latest direction.

Regardless of whether EIP-5988 ultimately takes effect, this prosperity and fragmentation will persist in the long term, necessitating more improvement proposals to address the issues.