LayerZero inclusion proof library will require an upgrade for SSZ support

[sambacha]

LayerZero proofs will require an upgrade

This goes to the further complication of running our own oracle, as the current default configuration uses MPT inclusion proofs for the receipts root.

This study aims to examine the potential impact of Ethereum Improvement Proposals
(EIPs) 6404 and 6466, which propose the modification of Merkle-Patricia Trie (MPT)
commitments for transactions and receipts, respectively. Importantly, this entails a
change in the serialization algorithm, from Recursive Length Prefix (RLP) format to the
Simple Serialize (SSZ) format for the Receipts and Transactions containers. In turn, this
changes the Receipts Root and Transactions Root fields in the execution layer headers.
A primary concern is that this transition could disrupt contracts that rely on RLP for proofs
on data committed to the Ethereum mainnet. These contracts may include critical parts
of decentralized bridges, which generate proofs about some log that was emitted in
historical transactions.¹

LayerZero: The default inclusion proof library can be updated to reflect the new SSZ commitment for the receipts root.

https://library.dedaub.com/ethereum/tx/0x000a6ea51c873a9cc7283e8a96e3f4b09d4425c4dec78023d5f3d82a9031e129
https://library.dedaub.com/ethereum/address/0x462f7ec57c6492b983a8c8322b4369a7f149b859/source?line=488
https://library.dedaub.com/ethereum/address/0x462f7ec57c6492b983a8c8322b4369a7f149b859/source?line=399

It should also be noted that the LayerZero case is a bit more complicated-due to its highly-configurable nature (applications can have their own relayer, oracles and validation library), any protocols that have a custom configuration might also need to perform some form of update to their on-chain transaction validation logic and even to their oracles.

Footnotes

1. EIPs-6404 and 6466: An Impact Study on the Transition to SSZ for Existing Contracts Relying on Proofs of RLP-Encoded Data, June 14, 2023 ↩