DLT Interoperability and More ⛓️#16 ⛓️ — SmartSync: Cross-Blockchain Smart Contract Interaction and Synchronization

In this series, we analyze papers on blockchain and interoperability.

This edition covers a paper on a blockchain interoperability use case.

➡️ Title: SmartSync: Cross-Blockchain Smart Contract Interaction and Synchronization
➡️ Authors: Martin Westerkamp, Axel Kupper

➡️ Paper source: https://ieeexplore.ieee.org/document/9805524/ (ICBC best paper award!!)

➡️ Background:

Background on blockchain interoperability can be found here.

➡️ Contributions:

• The authors propose a mechanism to create (target blockchain) client contracts, contracts that mirror the logic and state of the original instance (on a source blockchain), and enable on-chain function executions providing recent states.
• The correctness of state updates is validated using Merkle proofs.

💪 Strong points:

• The motivation is interesting: to allow cross-blockchain calls to provide instant responses (namely use cases that require up-to-date read-only), and to avoid a specific format and fallback function for cross-contract calls (which is not necessarily bad).
• An example of a use case are cross-blockchain smart contract queries where hosting applications can exist on the best-suited blockchain while retrieving data feeds cross-chain (useful for retrieving oracle information).

🤞 Suggestions for improvement:

• The state updates on the replica contract are synchronized by regularly applying storage proofs that are verified based on a trusted storage root. However, how does one certify that the trusted storage root is really trustable?
• It would be interesting to see how could forks be accounted for: what if a fork happens on the source blockchain? What is the procedure for updating it on the target blockchain?

🔥 Points of interest:

• Interestingly, this paper is an example of a partial blockchain migration, namely state, across homogeneous blockchains.
• The authors propose SmartSync for smart contract synchronization across blockchains. Here, a secondary contract is created on the target blockchain that reflects the logic and current state of a smart contract on the source blockchain.
• Merkle proofs are the powerhouse of the interoperability scheme for account-based blockchains like Ethereum. They map the whole state at time t to a storage root R. They allow proving that a smart contract holds a specific state (namely a specific key-value pair) and that an account exists (there is a Merkle proof that maps an account to the global state root).
• The authors define several levels for smart contract portability. Interestingly, we also defined one of the levels with the corresponding motivation in the introduction and page 51 of this document; and also in the Cacti whitepaper (section 3.11)

1. Syncing (read): a pair of smart contract instances exist in parallel in different chains; reasons to use this pattern include leveraging a feature a third-party blockchain offers while preserving the functionality of that contract (a contract on EVM-based chain X using the price oracle Uniswap).
2. Moving: this migrates a smart contract to a target blockchain and disables it on the source blockchain.
3. Syncing (read): the approach proposed by the authors, aiming to provide read access to a contract deployed on an external blockchain.

• The authors utilize the proxy pattern to decouple the contract state and the execution of the business logic, and at the same time decouple the migration and synchronization logic from the business logic.
• Contract synchronization can be done by using the resulting state (from applying transactions) to update the state — but this is not practical. Alternatively, we could trigger EOA transactions, where the state update would be encoded in that transaction. The contract would verify “the inclusion of each transaction on the source contract using a Merkle-proof attesting its inclusion in a block provided by the relay contract. Thereafter, the correct sequence is confirmed, i.e., no transaction may be skipped, and the submission must adhere to the correct order. By re-executing all transactions, the same state will be reached as on the source contract.”

To prove the existence of a particular key-value pair on a smart contract, two merkle proofs are needed: 1) the account proof that validates the inclusion of an account tuple within a block header, and 2) a storage proof that validates the inclusion of a key-value pair in the account state. Using these proofs allows proving the creation, updated and deletion of key-value pairs. This allows storage proofs to skip all intermediary changes and apply the verified final result.

• The authors use multi-proofs as a mechanism to prove several key-value updates using a single proof, for efficiency. See Figure 2 from the paper to have an idea of what a multi-proof is:

We can prove that keys 03 and 42 are included in this Merkle tree by providing nodes G, J, and C. While this scheme allows proving the inclusion of values efficiently, how do we prove completeness, i.e., that no key-value pair has been left out of the update (create, modify, delete)? With:

• Transition confirmations. Those are computed on-chain and verified against a multi-proof. The idea here is to link the current state encoded in a multi-proof to the primary state of the original state transition (of the source blockchain). Transition confirmations create a link to the original state by “replacing all values of the multi-proof’s key-value set with the original values of the state transition”. In particular, the original values on the source blockchain can be retrieved on the respective key location on the ledger and are effectively the values to be populated on the target blockchain.

🚀 What are the implications for our work?

• This work helps us build more secure blockchain interoperability middleware.