Instant Function Calls Using Synchronized Cross-Blockchain Smart Contracts

Most current cross-blockchain approaches focus on exchanging or transferring tokens between networks. While some concepts foster smart contract invocations across blockchains, they require multiple transactions and operate asynchronously. We present a concept enabling instant smart contract calls by creating synchronized client contracts on arbitrary blockchains. Other smart contracts can query these client contracts on the target blockchain for retrieving information without requiring cross-chain message queues. With this, we reduce the dependency of smart contracts on their host blockchain, as remote contracts become available as read-only instances. The synchronization process does not require trust in the executing intermediary since Merkle proofs based on shared state roots are utilized to guarantee correct execution. We propose a novel concept called transition proofs for efficiently proving the correctness of state updates. The prototypical implementation permits smart contract synchronization between EVM-compatible blockchains. Our evaluation shows the approach’s applicability regarding execution costs and delay. Further, we conduct a case study by synchronizing one of the largest decentralized exchanges deployed to the Ethereum network.


Instant Function Calls Using Synchronized
Cross-Blockchain Smart Contracts

Martin Westerkamp and Axel Küpper
Abstract-Most current cross-blockchain approaches focus on exchanging or transferring tokens between networks.While some concepts foster smart contract invocations across blockchains, they require multiple transactions and operate asynchronously.We present a concept enabling instant smart contract calls by creating synchronized client contracts on arbitrary blockchains.Other smart contracts can query these client contracts on the target blockchain for retrieving information without requiring cross-chain message queues.With this, we reduce the dependency of smart contracts on their host blockchain, as remote contracts become available as read-only instances.The synchronization process does not require trust in the executing intermediary since Merkle proofs based on shared state roots are utilized to guarantee correct execution.We propose a novel concept called transition proofs for efficiently proving the correctness of state updates.The prototypical implementation permits smart contract synchronization between EVM-compatible blockchains.Our evaluation shows the approach's applicability regarding execution costs and delay.Further, we conduct a case study by synchronizing one of the largest decentralized exchanges deployed to the Ethereum network.

I. INTRODUCTION
D URING the last decade, blockchain technology has expe- rienced rapid development resulting in a growing number of blockchain networks.While novel forms of consensus algorithms [1], [2], [3] and smart contract execution environments [4] pose opportunities for a wide range of use cases, we observe an increasing fragmentation of applications across multiple blockchain networks.This tendency is contradictory to the initial proposition of smart contracts to provide decentralized and highly available applications, as it constitutes a new form of lock-in effect towards the host blockchain.Because the network is isolated, smart contracts are only interoperable with other smart contracts in the same network.Current proposals to enable cross-chain function calls entail multiple transactions on the initiating blockchain and cannot cater use cases that require instant responses.Furthermore, contracts need to be adjusted to support cross-blockchain calls, as specific message formats and fallback functions are required to process return values.
Due to the limitations of current cross-chain solutions, use cases that require up-to-date read-only access cannot be implemented efficiently.For example, registries such as the Ethereum Name Service (ENS) provide mappings between human-readable names and a plethora of attributes.These attributes may include account addresses of a set of blockchains.Hereby, a link is created between multiple wallets of a user on various blockchain networks that may be utilized for further processing or transfers.For instance, if a user decides to register a name on Ethereum [5] and stores his or her account addresses of Ethereum and Polkadot [6], this information is currently only available on Ethereum and cannot be used by applications hosted on the Polkadot network.By providing cross-chain access to such registries, users will be enabled to perform a single name registration on a blockchain of their choice and use it across multiple blockchain networks.
One of the most prominent application domains enabled by blockchain technology is Decentralized Finance (DeFi), which provides financial products without involving intermediaries.Most DeFi applications require trusted data, such as price feeds, that is typically delivered by oracles [7].As an alternative to external oracles, Automated Market Makers (AMMs) like Uniswap have proven to provide reliable on-chain price estimations [8].Up until now, only smart contracts hosted on the same blockchain as the AMM could benefit from the provided data.As a result, DeFi developers requiring oracles have two options when deploying applications.First, use the most suitable blockchain according to the requirements regardless of the oracle's location.As the decentralized price feed may not be available on that blockchain though, an external oracle is needed involving additional fees and trust implications [7].Second, the contract could be deployed to the same blockchain as the AMM, leading to a growing concentration of applications on a single ledger and thus scalability issues [9].Allowing smart contract queries across blockchain networks will permit hosting applications on the best-suited blockchain while retrieving data feeds cross-chain.
We enable such use cases and remedy shortcomings of isolated smart contract states by developing a novel concept called 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.State updates are synchronized by regularly applying storage proofs that are verified based on a trusted storage root.Our approach is agnostic to the storage root source and is thus applicable to chain relays, notary schemes, sharding as proposed for Ethereum 2.0 [2] or related concepts such as Polkadot [6] or Cosmos [10].As synchronizations can be initiated within the same block of a function call, applications can rely on recent states.While smart contract calls are currently limited to their host blockchain or shard, SmartSync provides synchronized replicas of remotely hosted smart contract instances.These replicas provide all view functions of the original contract.As a result, external contracts are enabled to execute the logic of a contract that was initially deployed on another blockchain network to retrieve verified information.To prove the concept's soundness, we provide a prototypical implementation of SmartSync 1and publish it under an open source license.
In this paper, we extend on the results that were previously published at the 2022 IEEE International Conference on Blockchain and Cryptocurrency (ICBC) [11].We propose a novel concept for synchronizing smart contracts across multiple blockchain networks and introduce a new form of state transition confirmation to facilitate trustless, lightweight state updates.A prototypical implementation is provided and published, including an off-chain client and respective smart contracts.The prototype is used to prove the concept's feasibility and evaluate implied operational costs.We extend our previous results by presenting a more detailed description of different techniques enabling cross-chain state roots since they constitute the foundation of SmartSync's security model.The related work section is extended and compares many concepts targeting similar objectives.Furthermore, we broaden our evaluation by presenting detailed results, including execution costs and delays.Finally, we introduce a use case study creating a smart contract fork and executing synchronization of an AMM on a public test network.

II. PRELIMINARIES
In this section, we first introduce common terms that are used in the following.After that, multiple approaches for providing state roots across blockchains are presented, as SmartSync utilizes derived Merkle proofs to enable trustless synchronizations.Third, different approaches to cross-chain smart contract portability are categorized.As a prerequisite for synchronizing smart contracts, stored information must be accessible across blockchains.Therefore, we present multiple approaches for providing state roots between blockchains.While multiple mechanisms for exchanging information exist, such as atomic swaps for trading tokens across blockchains [12], we subsequently focus on chain relays, as they facilitate retrieving a source blockchain's state in a verifiable manner [13].Even though notary schemes could provide similar results, we refrain from presenting their specifics due to their limited verifiability and refer to [14], [15], [16] for further details.Similarly, relay networks distribute Merkle roots to multiple linked blockchains, rendering them potential candidates for the proposed synchronization concept [6], [10], [17].

A. Definitions
We base our concept on the assumption that two blockchain instances A and B exist in parallel and support the same execution environment for smart contracts.Information is only transmitted in one direction from A to B. Therefore, we also refer to A as source and B as target blockchain in the following.To exemplify the applicability of our concept, we presume an Ethereum-like implementation of state storage for our model [18].Thus, the model incorporates an accountbased model to represent the state rather than utilizing Unspent Transaction Outputs (UTXOs) [19].
Each blockchain is composed of a sequence of block headers H.We denote H A t as the head of blockchain A at time t and H A t+1 as the subsequent block header.Block headers hold information proving their validity according to the applied consensus algorithm and a reference to the current state.The global state is defined as the union of all account states.Each account is identified by an address and owned by external users or smart contracts.Every account holds a state that is composed of a set of key/value pairs f : K → V .
We define the state of contract C at time t and instantiated on blockchain A as The Merkle hash tree function m maps the entire state to a storage root R, so that m : represents the global state and the respective Merkle hash tree function maps an account

B. Multi-Proofs
Multi-proofs describe a mechanism for proving the inclusion of multiple values using a single proof and have been proposed to overcome inefficiencies when querying multiple values [20].While common Merkle proofs reflect a path within the respective Merkle tree, multi-proofs share nodes of paths and thus depict sub-trees with substituting hash values where the tree was pruned.As a result, a set of key-value pairs can be included in a proof (R( . The efficiency of multi-proofs depends on the index of the target leaf values.The more branches are shared, the more efficient a multi-proof becomes in comparison to single proofs.

C. Cross-Chain State Roots
Account-based blockchains represent their global state in Merkle trees [18].The tree's root is referred to as state root and enables proving the presence of a specific account state at a given time.Providing a state root of a primary blockchain to a secondary blockchain permits accessing the primary blockchain's state.In the following, we present three approaches for transferring state roots between blockchains: chain relays, sharding, and notary schemes.
1) Chain Relays: Chain relays reflect the consensus mechanism of a primary blockchain on a secondary blockchain [14].Block headers of a primary blockchain are submitted, validated, and stored on a secondary blockchain if the validation was successful according to the primary blockchain's consensus rules.In case of Proof-of-Work (PoW), a block header is deemed to be part of the primary main chain (i.e., to be final) after n headers have been validated subsequently, as it would become economically infeasible to mine n invalid blocks.The parameter n depends on the economic incentive mechanism of the primary blockchain as well as the desired level of security.As PoW-based blockchains typically do not guarantee finality, parameter n also reduces the risk of incorporating forks, as the likelihood of miners producing valid blocks based on a fork decreases with every block added to the leading chain [19].Once a block header is deemed final by the relay, it can be utilized to prove the inclusion of transactions, state or events within the primary blockchain on the secondary blockchain.As block headers comprise corresponding Merkle roots, the submission of Merkle proofs enables inclusion proofs without requiring trusted intermediaries.This mechanism is also referred to as Simplified Payment Verification (SPV) [19].While many chain relays exist [21], [22], [23], [24], we present a brief overview of the prominent chain relay techniques.BTC relay was the first chain relay in production, ETH Relay proposes an optimistic approach for Ethereum's consensus algorithm Ethash, Dogeethereum introduces zeroknowledge Bulletproofs to decrease on-chain validation complexity, zkRelay utilizes provably correct off-chain validation using zkSARKS incurring constant on-chain validation costs, NIPoPoWs demonstrates sublinear validation costs by using non-interactive proofs, and PoS Sidechains enabling relays for PoW-inspired Proof-of-Stake (PoS) blockchains.
BTC Relay: BTC Relay was the first chain relay to be deployed in a live setting and enables the submission of Bitcoin headers to Ethereum to prove the inclusion of transactions [25].In order to enable a one-way peg from Bitcoin towards Ethereum, participants upload Bitcoin block headers to a smart contract that validates the compliance with Bitcoin's consensus rules [25].Therefore, the submitted block header is only accepted and stored within the contract if it references a block header that has been successfully submitted before.BTC relay utilizes an incentive mechanism to compensate participants' gas costs for submitting block headers.However, the requirement of submitting every single intermediary header implies high overhead that is not compensated adequately.As a result, BTC Relay has stalled for more than 130 months since the last block has been submitted at the time of writing. 2 Catching up to the head of the Bitcoin blockchain would require more than 238,000 transactions accounting to about 194,000 gas each,3 a burden economically rational participants are not willing to take.
ETH Relay: ETH Relay constitutes a chain relay that links Ethereum with any blockchain supporting the Ethereum Virtual Machine (EVM) [26].Ethereum applies a memoryhard PoW algorithm to prevent centralization tendencies that originate from the use of customized hardware [18].The objective is to motivate a more extensive set of miners to participate as consumer hardware can be used efficiently.As a result, on-chain validation of Ethash is impractical as it must include proofs that correct memory operations have been conducted.As on-chain validation of memory-hard algorithms is complex, ETH Relay follows an optimistic approach and accepts block headers without verification.Submitted headers are blocked for a contesting period in which observers can challenge them.Only in case of a challenge, the submitted block header is validated on-chain, and the submitter is slashed if fraudulent behavior is detected.The optimistic approach taken by ETH Relay potentially decreases operational costs significantly, as costly validation operations are only conducted in case of misbehavior.Therefore, while targeting PoW consensus algorithms in its current proposal, its general concept is applicable to PoS chain relays as well.Yet, as the concept depends on observing intermediaries and sufficient incentivization for correct behavior, trust in transferred block headers is limited compared to full validation.
Dogethereum: In contrast to Bitcoin, the Dogecoin blockchain does not rely on SHA-256 for creating PoW [19], but on the memory-hard Scrypt algorithm to prevent the utilization of Application-Specific Integrated Circuits (ASICs) [27].As executing Scrypt within a smart contract is infeasible, Teutsch et al. [28] have proposed Dogethereum, which enables off-chain validation of Dogecoin's PoW using Bulletproofs.While the implemented mechanism facilitates batching multiple blocks for validation, the proof size of bulletproofs scales logarithmically with the computation's complexity [29].Therefore, instead of verifying the proof on-chain, Truebit [30] is used to minimize verification costs.Truebit permits advertising off-chain computations that are conducted by participants to retrieve bounties.Challengers are incentivized to find incorrect submissions and claim them on-chain.The challenged section of the computation is then validated on-chain and the honest entity earns the escrowed reward.Therefore, Truebit requires depositing a sufficient amount of collateral to incentivize participants.The correct execution requires constant monitoring of multiple distinct entities.While Dogethereum also proposes a mechanism of locking and unlocking assets to exchange them between ledgers, we refer to [28] for further reading, as it exceeds the focus of this work.
zkRelay: permits moving the validation of block headers off-chain through zkSNARKS [13].Batches of block headers are validated via an off-chain program that indicates the correctness of the included hash chain.Only the last block of each batch and a proof of the program execution's correctness are submitted to the relay contract.As a result, applying a batch size of 504 reduces execution costs by a factor of 187 compared to BTC Relay.
NIPoPoWs: Kiayias and Zindros [31] have proposed a sidechaining mechanism that is based on Non-Interactive Proofs of Proof-of-Works (NIPoPoWs) [32].NIPoPoWs permit constructing succinct proofs about predicates -or events -from regular blockchains.The proof size scales polylogarithmically to the number of blocks that have been mined at the time the event occurred [32].However, the source blockchain must support NIPoPoWs.In case no native support exists, it can be added to a ledger through a velvet fork [33].Thus, miners do not have to be aware of the fork and NIPoPoWs are implementable retrospectively.However, the source blockchain must support the proof mechanism.Furthermore, NIPoPoWs expect constant PoW difficulty and are therefore not applicable to blockchains like Bitcoin that adjust the difficulty to achieve relatively constant block mining rates [34].Nevertheless, NIPoPoWs provide promising sidechain mechanisms for PoS-based blockchains, as demonstrated by Gaži et al. [22].
Verilay: Verilay depicts a chain relay enabling the verification of PoS blockchains which apply a consensus algorithm that is based on Practical Byzantine Fault Tolerance (PBFT) [35].Since these blockchains typically provide guaranteed finality derived from participants' signatures, Verilay utilizes this property to provide efficient block header validation within a smart contract.The authors provide a prototypical implementation enabling the verification of Ethereum's consensus layer on any EVM-compatible blockchain.After blocks have been finalized according to the consensus algorithm, block headers can be transferred.Due to the finality guarantees, every preceding block is also trusted, allowing Verilay to skip blocks in the verification process, rendering the execution more efficient.
PoS Sidechains: Gaži et al. have proposed a sidechain mechanism for PoS-based blockchains that does validate block headers of the source blockchain, but operates on explicitly signed cross-chain transactions [22].A subset of the source blockchain's validator set is sampled to create certificates that notarize cross-chain transactions.The solution is tailored to cater to Nakamoto-inspired PoS blockchains such as Cardano.Thus, compared to Verilay, different assumptions are applied concerning finality and verifiability.Furthermore, while generalizable, the concept enables the specific use case of transferring tokens.In contrast, Verilay applies the source blockchain's consensus to maintain the source blockchain's security properties and enables inclusion proofs of arbitrary data.
Axelar: The Axelar network consists of multiple layers providing cross-blockchain interoperability [36].The Axelar blockchain is maintained by validators elected based on delegated Proof-of-Stake (dPoS) and depicts the system's core.It promotes a hub-and-spoke model to integrate heterogeneous blockchain networks.Validators run light clients of connected blockchains and attest to on-chain data using threshold signatures.As a result, state information like transaction data, storage roots, or events can be relayed efficiently between blockchains connected to the Axelar hub.Yet, the signature scheme requires coordination between validators and limits the number of validators.Axelar depicts a solution at the intersection between relay and notary schemes.
2) Sharding: The objective of blockchain sharding is to enhance throughput by distributing transactions and applications among multiple shards and processing them in parallel [37].While UTXO variants exist [37], [38], account-based implementations operate on a shared state root that is accessible through a hub blockchain [2], [6], [10].The shared state root subsumes the state of all connected shards and is relayed back from the hub to all shards.As a result, cross-shard applications are enabled by processing states, transactions or events through Merkle proofs derived from the shared state root.
3) Notary Schemes: The notary scheme is one of the most used techniques for achieving interoperability between distinct blockchain networks.It relies on intermediary entities retrieving data from a source blockchain, signing the given data, and writing it to a target blockchain [39].Because the protocol only requires signature validation, it is independent of the source blockchain's consensus algorithm, involves less validation costs, and can provide more timely data, compared to chain relays.Many variants exist, the simplest being a single trusted entity acting as a notary.The process may also be distributed to multiple entities in order to mitigate a single point of failure and spread the risk of misbehaving actors.Before relayed information is trusted, a minimum of signatures must be collected, for instance by using a multi-signature wallet or threshold signatures [16], [40].Similar to other cross-chain technologies, after data has been transmitted, applications must decide under what conditions the data can be trusted and utilized.For instance, Blockstream's Liquid protocol enables a Bitcoin sidechain using an N-out-of-M signature scheme operated by a preset federation [41].Cross-chain transactions are enabled by bridges such as Harmony's Horizon Bridge4 or Ronin Bridge. 5Here, external validators retrieve locking events emitted on a source chain by a dedicated smart contract and sign the transfer operations to unlock representations of the locked tokens on a target blockchain.
The deposit of collateral has been proposed to incentivize honest behavior in permissionless notary networks [42].Oracle implementations such as Astrea [43] or ChainLink [44] permit arbitrary participants to join the network by depositing some collateral.As soon as a user detects misconduct, it can be reported and reviewed by the rest of the users.If the misconduct is confirmed, a portion of the deposited collateral is taken and credited to the reporting entity.Blockchain protocols that take interoperability into account may utilize validators' deposits for multiple purposes.For instance, the Polygon network executes a bridge 6 to the Ethereum network and applies stake for PoS validation and cross-chain notarization.As an alternative to depositing collateral, Trusted Execution Environments (TEEs) are also used to map external data in a tamper-proof manner [45].While such oracle networks can create a gateway to arbitrary external data sources, enabling interoperability between blockchain networks is a common use case.
While notary schemes provide timely data exchange and low execution costs, their security is limited by the participants' correct behavior.In the recent past, attackers exploited multiple instances like the Harmony bridge and Ronin bridge.In the case of Ronin bridge, five out of nine signatures were required for executing a cross-chain asset transfer [46].Since a single organization held four keys and another delegating their voting rights to the first, only a single organization's IT system had to be compromised to retrieve the required private keys that were used to sign fraudulent transactions and capture about 600 million USD worth of tokens [47].The example shows that it is the small number of nodes in charge and the vulnerability of host systems that can pose a significant security risk.In contrast, chain relays execute full validation on the target blockchain and do thus not suffer from this risk at the cost of higher execution overhead in current implementations.

D. Smart Contract Portability
The term smart contract portability subsumes mechanisms that enable the migration of smart contracts between blockchain instances, including logic and state.Smart contracts are typically hosted on a single blockchain and inherit its security and performance properties.As a prerequisite for smart contract portability, source and target blockchains must support the same execution environment.We distinguish three types of smart contract portability: forks, moves, and the novel synchronization scheme presented in this paper.
1) Smart Contract Forks: Similar to blockchain forks, smart contract forks describe the creation of a second instance that exists in parallel to the original instance and is based on a shared history [48].Smart contract forks are typically created on a second blockchain instance to overcome shortcomings of the primary host blockchain.Reasons for creating smart contract forks on different blockchains are manifold: • Incentives of validators (or miners) of the host blockchain may not be aligned with those of smart contract users.While validators typically intend to receive high rewards, smart contract users seek high throughput, short waiting times, and low fees.become available for a given use case.Thus, migrating the contract to the novel network is desirable to benefit from higher throughput, lower fees, etc.To create a smart contract fork, the executing entity first retrieves the stored bytecode and state.The state does not necessarily have to reflect the latest state but can also be retrieved from a preceding block, depending on the intention.While the bytecode is easily retrievable using any synchronized full-node client, the state must be reconstructed, i.e., all key/value pairs must be retrieved.Prior work suggested reconstructing the state by retrieving all transactions sent to the target contract to observe each state transition [48].The current state is rebuilt by applying all state transitions consecutively.This process introduces significant overhead if many transactions have modified the contract state.Today, node client implementations provide more elaborate traceability functions that permit retrieving all occupied keys of a smart contract.In our synchronization concept, we use this mechanism to facilitate rapid contract forks during the initialization phase before synchronization.
2) Smart Contracts Moves: Fynn et al. have proposed a mechanism for moving smart contracts between ledgers [9].In contrast to smart contract forks, where two or more instances of a contract exist in parallel, a smart contract move suspends the primary contract before enabling the secondary instance.The authors propose dedicated instructions to the virtual machine to facilitate preconditional locking and unlocking of migrated contracts.Beneficial to users is the decreased risk of dispersion across multiple instances.On the downside, moving contracts is only feasible for authorized entities and users must adhere to the move decision.Compared to this approach, smart contract forks favor the risk of fragmentation over centralization.

III. SMART CONTRACT SYNCHRONIZATION
The objective of smart contract synchronization is to provide instant read-only access to a contract that was initially deployed to another blockchain.Instant access is characterized as on-chain function invocation that terminates in a single transaction.A secondary contract is created on the target blockchain that mirrors the original source contract.Hereby, the smart contract's functionality and state becomes available to other smart contracts on the secondary blockchain for retrieving information, e.g., through getter methods, while changing its state is prevented.Consequently, smart contracts hosted on a remote blockchain can be used within a single transaction, as the state migration finalized previously.Furthermore, complex queries can be achieved on-chain following the original contract logic.
As a prerequisite, a smart contract fork is created to migrate logic and current state of the target contract onto a secondary blockchain.In contrast to smart contract forks, however, only those functions are callable that do not modify the state.We present a synchronization mechanism that ensures only valid state updates are applied.

A. Synchronization Conditions
As the contract state may divert from the forked instance over time, a mechanism for synchronizing the state is required.Given the decentralized nature of blockchain applications, we derive the following conditions that must be met to guarantee valid state updates: • Equality: The secondary contract's state must reflect a state of the primary that was valid at a given point in time according to the source blockchain's consensus rules.to be met at the time of synchronization.The frequency must be defined by the referencing contract, as different applications may have distinct needs in terms of timeliness.

B. Initialization Process
Before a smart contract can be synchronized, its state and logic must be duplicated via a smart contract fork.While prior work relied on external validation [48] in the process, we introduce a verifiable migration scheme that utilizes a trusted state root.Before the source contract's state can be applied on the target blockchain, its bytecode and state must be retrieved either by replaying past transactions or using a blockchain client's extended database access.
Contract separation: First, the original contract is split into dedicated logic and proxy contracts.The proxy contract maintains the contract state and delegates all function calls to the logic contract, which in turn executes function logic based on the proxy contract state.This pattern enables the implementation of migration and synchronization logic within the proxy contract while keeping the source contract's logic separated.Hereby, the contract logic's validity is maintained, as it is not modified.The proxy contract supplies setter methods that enable distributing the initialization over multiple transactions.After the entire state was replicated, the function cannot be invoked anymore, ensuring the state's integrity.For further details on how to prevent future invocations without polluting the proxy contract's state, we refer to [48].
Verification: While external verification of the resulting state was required previously, we introduce a mechanism that ensures validity on-chain.For this purpose, a dedicated SmartSync contract is introduced on the target blockchain that traces and verifies all migrated smart contracts from a specific source blockchain.After successfully migrating a contract, a transaction is submitted to the SmartSync contract indicating the migration is finished.To prove its correctness, two Merkle proofs are submitted: (R(H A t ), C A t ) and (R(H B t+x ), C B t+x ), where x ≥ 1.They both depict account proofs indicating the existence of a specific account tuple on the respective blockchain.The first proof guarantees the submission of a correct contract state and is verified using the source blockchain's state root.The second proof confirms the correct application of the contract's source state on blockchain B. We assume header H B t+x is available to the contract as an historic state.For instance, Ethereum permits accessing header hashes of the 256 most recent blocks [18].In case the target ledger does not provide the respective block hash to smart contracts, the contract state's Merkle root can be computed within the SmartSync contract during submission.

C. Synchronization Process
The objective of smart contract synchronization is to provide a secondary instance of a smart contract on a remote blockchain.The contract state is synchronized regularly, providing access to its current state to arbitrary contracts on the secondary blockchain.The synchronization process is unidirectional, thus, the primary contract remains unaffected of derived synchronized contracts.Furthermore, the secondary contract's state is only modifiable by proving the state was obtained from the primary contract.As a prerequisite, we assume a smart contract fork is created and verified as depicted in Section III-B.To capture all conditions and challenges for smart contract synchronization, we first introduce a naïve approach and elaborate our concept based on it in the following.
1) Naïve Approach: The state of smart contracts is the result of executed contract logic that is triggered by transactions.As the objective of smart contract synchronization is to replicate the primary contract's state and the state is derived from transactions, it is intuitive to record all past transactions sent to the contract on the primary blockchain and apply them on the secondary blockchain.For instance, Figure 1 illustrates a contract C A that is forked and deployed to blockchain B. In the following, three transactions are sent to C A modifying its state.To reflect the resulting state on C B , all three transactions would have to be executed sequentially on blockchain B. The synchronization contract first verifies the inclusion of each transaction on A using a Merkle-proof attesting its inclusion in a block that is 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.However, multiple challenges exist following such an approach.
Transactions cannot be re-executed natively, as the account matching the signing key pair either does not exist on the target blockchain or is likely to be in a distinct state, compared to the source blockchain.Furthermore, corresponding accounts must hold sufficient funds to compensate for transaction fees, and a linked nonce is incremented every time a transaction is sent.Thus, all accounts that have sent transactions to contract C on blockchain A must hold sufficient funds and be in an equivalent state.In addition, transactions are targeted to a specific address necessitating equivalent addresses on both blockchains.As these requirements can never be guaranteed, native execution of source transactions is not applicable.
Alternatively, transactions could be executed in an emulated environment.For instance, in case of Ethereum, the EVM could be implemented within a smart contract that executes every transaction decoupled from the sender's account state and contract address on the target blockchain.However, such emulation will come at the cost of increased complexity and Fig. 2. Left: Merkle tree of an account state derived from source chain.Center: Multi-proof of an updated state: 0x03 is deleted (red), 0x42 is modified (yellow) and 0x02 is added (green).Right: Transition Confirmation calculated on the target chain.thus execution costs.Despite the inherent additional fees for synchronization, it cannot be guaranteed that all transactions can be replicated, as the limit of execution steps within a block may be exceeded.As a result, an attacker could create a transaction executing complex logic to prevent its replication on the target ledger, effectively stalling contract synchronization.
Replaying every single transaction also incurs overhead with regards to storage operations.Figure 1 presents an example where variable a is first changed from six to seven before being changed back to six.While the result is equivalent, these operations cannot be subsumed and must be executed sequentially.Moreover, to prove the inclusion of every transaction, respective storage roots must be provided by the relay contract.As a result, optimized concepts that reproduce only a subset of historic storage roots, such as zkRelay [13], cannot be utilized, inducing overhead during synchronization.
2) Verifiable State Updates: We present a method that utilizes state proofs for synchronizing contract states across blockchains to solve the shortcomings of simple transaction replication.Instead of proving the inclusion of transactions sent to the source contract, the resulting state is used for updates.To prove the presence of a particular key-value pair in the contract state, two Merkle proofs are required.First, the account proof (R(H A t ), C A t ) documents the inclusion of an account tuple within a block header H, where R(H A t ) is the global state root at time t.Second, storage proofs notarize the inclusion of a specific key-value pair (R(C A t ), (k , v )) in the account state, where R(C A t ) is the account state root at time t.Applying these proofs on the target ledger permits proving the addition, change, or deletion of single key-value pairs.Proving the result of executed transactions rather than replaying state transitions results in more efficient state updates in case of multiple write operations at a single key location.For instance, Figure 1 depicts multiple updates of multiple values.Utilizing storage proofs permits to skip all intermediary changes and apply the verified final result.
The application of single key-value proofs meets all conditions defined in Section III-A but Completeness.Equality is met as the combination of account and storage proof ensures the presented key-value pair existed on blockchain A at some time.Only updates newer than the previous update are accepted.Succession and Trustlessness are established via the utilized state root.Furthermore, anyone can submit account and storage proofs, rendering the entire process open and verifiable.Completeness, however, is not assured, as storage proofs are independent from each other.An attacker could submit only a subset of state updates to induce an inconsistent state.While it would be impossible to add variables that are not part of the source contract, delete variables that haven't been deleted or modify values that haven't been modified, concealing a subset of state updates poses a serious vulnerability.Figure 2 depicts a state transition S (C A t ) → S (C A t+x ), where x > 0 and includes three updates.To fully capture the state transition, all three updates must be applied via dedicated storage proofs.However, this would require trust in the executing entity and therefore violate the Trustlessness condition.Moreover, submitting a single storage proof for each modification creates considerable overhead, as each proof must be verified independently.To overcome both issues, we introduce transition confirmations based on multi-proofs.
3) Multi-Proofs: Since state updates typically include multiple storage values that need to be updated, multi-proofs depict an efficient mechanism for proving the presence of many key-value pairs using a single proof.For instance, to prove the inclusion of keys 0x00 and 0x03 in Figure 2, only the leaf values and two branch hashes of the next two layers of the tree are required.
While multi-proofs increase efficiency, they do not solve the threat of withholding parts of the resulting state.Thus, completeness cannot be guaranteed.Attackers could submit valid multi-proofs including only a subset of key-value pairs involved in the original state transition.Updating the secondary contract state by applying a multi-proof could thus result in an inconsistent state.

4) Transition Confirmations:
The objective of transition confirmations is to guarantee Completeness.Thus, the entire state transition result must be captured, including all create, update, and delete operations.Transition confirmations are not submitted externally, but computed on-chain based on a multi-proof.As the state of the source contract is not accessible from the target ledger, 7  ).Therefore, they are retrievable by reading from the respective key location on the ledger.While the multi-proof's values are substituted, the actual paths remain equivalent.Hereby, it is ensured that the entire state was captured, as withheld state updates would be reflected in changed paths.The computed transition confirmation depicts a valid multi-proof of the initial state S (C B t+x ) if all changed values of the state transitions are reflected in the submitted multi-proof: Thus, the transition confirmation is validated equivalently to a multi-proof.We expect the computed Merkle root to equal the previous state's Merkle root if all changes were captured and different otherwise, as illustrated in Figure 2. The rationale is that a multi-proof is a pruned version of the original Merkle tree and includes those key-value pairs that have been modified during a state transition.Withholding a subset of updates will be disclosed by this kind of transition check, as the withheld set is captured in a hashed branch: When computing the transition confirmation's Merkle root, it becomes evident that the result is different from the original root in case the submitted multi-proof is incomplete.While the sole validation of a multi-proof could not capture the state transition depicted in Figure 2, the computed transition confirmation ensures correct state updates.For instance, let us assume an attacker submits a multi-proof including state updates at keys 0x03 and 0x24 but withholding the value addition at key 0x02.To create a transition confirmation, the values at key locations 0x03 and 0x42 are read from the target ledger and inserted in the multi-proof to build the transition confirmation.As Node P remains unaffected, the tree root would be calculated from nodes B and P instead of B and C, resulting in a hash different to A. Thus, it becomes evident that an incomplete multi-proof was passed and the state update is aborted.

5) Workflow:
The combination of account proof, multi proof and on-chain computed transition confirmation enables verifiable state replication of smart contracts across multiple blockchain instances.In the following, we depict the required steps to synchronize state updates from a primary contract to a secondary client contract hosted on a remote blockchain.The entire workflow is illustrated in Figure 3.
The process is initiated by any entity motivated to update an expired state on the target blockchain.Motivation may be intrinsic as a depending smart contract of interest requires a recent state or it may be triggered externally through a monetary incentive system.As external incentive layers exceed the focus of this work, we refer to [25], [26], [30] for further reading and leave its application on the presented concept for future work.The external entity runs a SmartSync client having access to client nodes of blockchains A and B.
After retrieving the account proof from the source client, all transactions sent to the smart contract since the last update are retrieved and replayed locally (Steps 1-3).Replaying respective transactions results in a set of key-value pairs representing the consequential state update.Thereafter, a storage proof is retrieved from the source node for each key-value pair (Step 4) and combined to a multi-proof (Step 5).Both, account and multi-proof are submitted to the proxy contract on the target blockchain in Step 6.The account proof verification takes place within the proxy contract and presumes a respective block header to be available within the relay contract.In case the block header is unavailable, the relay contract must be updated accordingly before starting the synchronization process.After verifying the multi-proof, it is used for creating the transition confirmation that ensures all state updates are included in the multi-proof (Steps 7-8).While the multiproof utilizes the Merkle root stored in the passed account proof, i.e., the new storage root, the transition confirmation is based on the current storage root that is stored within the smart contract and updated for each synchronization.If the transition confirmation is deemed valid, the state updates included in the multi-proof are applied to the proxy state (Steps 9-10).
Utilizing the resulting storage state of the source contract permits subsuming multiple transactions, reducing storage and execution costs.In case the state update is too large to be executed within a single transaction, a previous state subsuming less transactions must be utilized first.

IV. EVALUATION
To evaluate SmartSync, a prototypical implementation of the concept was created that permits forking and synchronizing smart contracts between blockchains supporting the EVM.The implementation is published under an open source license.The prototype provides a client including a command-line interface to retrieve states and proofs from the source blockchain, create corresponding multi-proofs, and submit them to the target blockchain.Furthermore, a proxy contract is supplied that retrieves, validates, and applies state updates, delegates readonly function calls to the logic contract, and prevents write operations other than synchronizations.To prevent the delegation of function calls that would modify the state, the execution context must be static.Currently, there is no native operation for retrieving the execution context within the EVM, a corresponding Ethereum Improvement Proposal (EIP) is under review at the time of writing.Until EIP 29708 is implemented, we utilize a workaround prosed in the EIP description that involves emitting an event to check whether the transaction can change the state.If the operation fails, the context is deemed static and non-static otherwise.When retrieving a function call, the proxy contract's fallback function is executed, as it is the default operation in case the function signature is unknown.The fallback function checks whether the execution context is static and delegates the call to the logic contract.Hereby, the executed logic operates on the state of the proxy contract that is a replica of the source contract.

A. Execution Costs
The application of smart contract synchronization entails execution costs on the target blockchain.As SmartSync is agnostic to the state root's source, we neglect the evaluation of corresponding application costs.Ethereum measures execution costs by assigning a fee called gas to every operation of the EVM [18].Multiple contracts are deployed and synchronized to determine the gas costs of synchronization operations.Each contract holds a mapping of different sizes, resulting in storage tries of variable depth.
First, we analyze the costs of updating a single value depending on its index in the Merkle tree.As indicated in Figure 4(a), the costs increase with the value's storage height within the tree, as the corresponding Merkle proof requires more nodes to be submitted.Each additional node results in increasing costs for parameter size and proof validation.Large contract storage sizes lead to deeper Merkle trees and thus drive synchronization costs.Furthermore, execution costs depend on the node types included in the Merkle proof.Ethereum utilizes modified Merkle Patricia trees to store values [18].We observe that proofs containing more extension nodes are cheaper than those containing branch nodes, as depicted in Figure 4(a) for heights three to six.Since branches contain up to 17 elements, more bytes must be passed compared to extension nodes holding two items.
Second, we evaluate the gas costs when updating multiple values in a single synchronization transaction.As for single values, updates incur less gas costs for smaller storage sizes, as illustrated in Figure 4(b).Synchronization costs per value decrease with an increasing number of values subsumed in a single transaction.Thus, gas costs increase sub-linearly.As multi-proofs share nodes of the original Merkle tree, fewer nodes have to be submitted and validated the more nodes are shared.The effect can particularly be observed when a large share of the total storage is modified since many nodes in the Merkle tree are shared, as illustrated by the storage size of 100 in Figure 4(b).
While no other concept exists permitting instant read-only calls, General Purpose Atomic Crosschain Transactions (GPACT) allow asynchronous cross-chain calls (see Section VI) [17].Since GPACT function calls are conceptually most similar to cross-chain synchronization, we use Authorized licensed use limited to the terms of the applicable license agreement with IEEE.Restrictions apply.it as a baseline to evaluate our approach.Reading a value using GPACT is independent of the smart contract storage and requires 495,049 gas.In contrast, the transaction costs for synchronizing smart contracts depend on the storage size and number of values updated.For instance, updating a single value at a storage size of ten requires 471,334 gas and is thus comparable to GPACT.Updating multiple values drives costs.For example, updating all ten values stored in a smart contract calls for 883,397 gas.Therefore, the costs for smart contract synchronization are only higher compared to GPACT if multiple values are updated but enable instant on-chain calls on the target blockchain.

B. Synchronization Delay
Time-critical applications rely on a low delay.Therefore, we measure the latency of synchronization updates, including the retrieval of state proofs, computation of multi-proofs, and execution on the target blockchain.The benchmark was executed on a machine equipped with an Intel Xeon CPU E3-1230 v6 @ 3.50 GHz and 64 GB memory.Source and target blockchains are private Ethereum networks performing instant mining.Instant mining describes the creation of the next block upon transaction retrieval [49].We measure the delay based on different contract storage sizes and investigate the impact of the target value's storage height within the Merkle tree.Our results show that updating a single value takes between 64 ms and 69 ms for storage size 10, 83 ms and 99 ms for storage size 100, and 342 ms and 421 ms for storage size 1000, as illustrated in Figure 5(a).We observe that the storage size significantly impacts the delay, while the target value's location within the Merkle tree is negligible.The delay in retrieving an entry from the database depends on the Merkle tree size and motivates EIP 1884, 9 which suggests reprising the SLOAD opcode.Therefore, our findings are aligned with the blockchain client-dependent delays.
Since we expect more than one key-value pair to be affected by updates in most cases, the approach's delay is measured based on the number of migrated values.Figure 5(b) depicts the delay in synchronizing key-value pair batches within three storage sizes.The migration of 10 values requires 71 ms for storage size 10, 120 ms for storage size 100, and 511 ms for storage size 1,000.Thus, we observe the same pattern for updating a single value; the synchronization delay depends on the underlying storage size.The delay develops approximately linearly.The synchronization of 100 values leads to a delay of 406 ms for a storage size of 100 and 1,449 ms for a storage size of 1,000.As the involved latency remains well within the block mining times of most blockchain networks, the concept is suitable for applications requiring timely updates.
The measured delay only accounts for the synchronization process using a local test network.The delay depends on the mining rate, network utilization, and the defined gas price when using production environments.
Compared to GPACT, the latency of smart contract synchronizations is expected to be lower since they do not require signaling messages [17].While no exact time measures are available for GPACT, at least three blocks are mined before a value can be read, as messages are sent sequentially.In contrast, smart contract synchronizations could be conducted with a delay of only a single block if supported by the applied state root transfer protocol, such as sharding or notary schemes.

V. CASE STUDY: AMM-BASED CROSS-CHAIN ORACLE
This section presents a use case study to evaluate our concept on one of the most used applications executed by programmable blockchain networks.While the roots of blockchain technology lie in decentralized digital cies [19], Decentralized Finance (DeFi) generalizes this concept to create an alternative the present financial system by Authorized licensed use limited to terms of the applicable agreement with IEEE.Restrictions apply.

TABLE I TIME AND GAS REQUIRED FOR FORKING A MAJOR AMM
circumventing centralized actors.The objective is to create an open, censorship-resistant market that enables the flexible composition of financial instruments [7].The increasing investment illustrates the growing interest in DeFi protocols.While the investment size was around 700 million USD at the beginning of 2020, the amount grew to over 100 billion USD by September 2021 [50].DeFi applications such as decentralized stable coins, like MakerDAO's DAI, 10 or lending platforms, like Compound, 11 require reliable price feeds through data oracles [7].While external data sources may be used as price oracles, respective feeds suffer from centralization tendencies, data manipulation, complex incentive mechanisms, and additional transaction costs.Yet, one of the most prominent DeFi applications, Decentralized Exchanges (DEXs), depict an alternative to external data sources by providing an on-chain price estimate derived from past trades [51].This allows a decentralized price feed that provides data on-chain instead of requiring external data.As of today, Automated Market Makers (AMMs) depict the most popular type of DEXs.Instead of relying on order books, liquidity providers provide tokens of trading pairs that can be exchanged for a fee [52].High deposits reduce the risk of manipulation to exploit dependent protocols.Therefore, sufficient liquidity must be ensured that may not be provided by AMMs deployed to the identical blockchain as the target application.Smart contract synchronizations offer a mechanism for securely retrieving smart contract states across blockchain networks.As a result, DeFi applications can be deployed to the best-suited blockchain while relying on a decentralized price feed supplied on another blockchain.
Uniswap is one of the largest AMMs by total locked volume [53].For this reason, it is well suited to act as a price oracle.To evaluate the applicability of smart contract synchronization in a real-world use case, we fork and synchronize one of the most popular Uniswap trading pair contracts, according to Uniswap's pair tracker, 12 that enables swapping WBTC against ETH.The source contract 13 is hosted on Ethereum's main network and we intend to create a synchronized version on Ethereum's Görli Testnet.
In the first step, the SmartSync client forks the source contract.Table I depicts the delay and required gas for each step of the process.The initial state comprises 20,831 key-value pairs.The blockchain client only permits retrieving the contract's keys and values separately.Instead of retrieving the value of every key used by the smart contract individually, the storage proofs for all keys are retrieved, which include the respective values.Our experiments with the OpenEthereum client have shown that proof retrieval involves a shorter delay than iterative value retrieval, even though the process entails a delay that is more than twice as long as key retrieval.The delay in contract deployment mainly reflects the target network's mining rate.After retrieving the state, it is applied to the proxy contract 14 on the target blockchain using 70 transactions, where the gas limit is set to eight million.Since the target blockchain is configured to a maximum gas limit of 30 million, larger transactions would be possible.However, since the submitted transactions compete with those of other users, larger transactions may not be considered by miners, so a gas limit of eight million constitutes a compromise between delay and gas costs.Every transaction includes up to 300 keyvalue pairs, and the average gas usage is around seven million.Since forking a smart contract is a one-time procedure, the required time of about 442 seconds is considered viable.Yet, the involved costs of almost 500 million gas constitute a challenge for some applications when applied to a blockchain such as the Ethereum main net, since 483, 383, 735 Gas * 12 Gwei Gas = 5, 800, 604, 820 Gwei = 5, 80060482 ETH , which corresponds to 10,271.30USD at a price of 1.770,73 USD for 1 ETH.Since many alternative blockchains supporting the EVM and incorporating lower gas fees exist, their utilization will also reduce the entrance barrier.
After the smart contract fork was successfully executed using block 14,926,123 of Ethereum's main net, transactions have modified the source state.Therefore, we execute the synchronization to update the target contract to the state of source block 14,926,556.Thus, the synchronization step includes 433 blocks of the source blockchain.The overall state transition affects eight key-value pairs, which are updated.Two options exist to retrieve the delta between the current and updated state: retrieving all transactions that have modified the contract state or querying the entire contract state to compute differentials.Our experiments have shown that the latter approach results in lower delays when upgrading between more than tens of blocks.We, therefore, retrieve the source and target state, as indicated in Table II.The most significant delay is produced by computing the differentials, which includes retrieving every value for retrieved keys and creating the multiproof.The delay induced by the synchronization transaction reflects the target blockchain's network dissemination time and mining rate.The overall delay of 288.42 seconds is relatively high but may be reduced by reducing the included blocks or replaying transactions as soon as they occur on the source ledger.The required gas costs sum up to 4, 626, 942 Gas * 12 Gwei Gas = 55, 523, 304Gwei = 0, 055523304ETH , which corresponds to about 98,32 USD at the mentioned exchange rate.
Our results show the applicability of smart contract synchronization to AMMs for creating cross-chain price oracles. 14Proxy contract: 0x1E2681f92da88212524cD05D3102BEacbE1Da240.
Authorized licensed use limited to the terms of the applicable license agreement with IEEE.Restrictions apply.

TABLE II TIME AND GAS REQUIRED FOR SYNCHRONIZING A MAJOR AMM
Whether the costs are feasible depends on the given use case and target blockchain.While the total delay seems significant, it is still below the finality constraints of many blockchains.Thus, the synchronization process could be triggered while waiting for finality.For instance, Ethereum's consensus layer requires six to twelve minutes until a block is deemed final [54].

A. Orchestration Blockchain
HyperService is a concept for enabling cross-chain smart contract invocations [58].The approach includes a domainspecific language that generates decentralized applications utilizing multiple interacting smart contracts deployed to separate blockchain networks.A state model is created to track the global application state on a dedicated blockchain for crosschain communication.Thus, a hub blockchain orchestrates cross-chain smart contract interaction.
With General Message Passing (GMP), the Axelar network provides a protocol for cross-chain function calls between blockchains connected to a hub [59].The implementation supports calling functions of EVM-based contracts.Every connected blockchain maintains a gateway contract receiving cross-chain function calls.When the gateway contract is called, the sender pays fees using the source blockchain's native token.Validators collect requested function calls and convert the paid asset to the target blockchain's native token for compensating transaction fees.
While enabling a wide range of smart contract interaction, orchestration blockchains do not permit querying smart contracts instantly.Every function call requires multiple transactions on multiple blockchains.In addition, the blockchain hub creates overhead and may create a bottleneck if many blockchain networks and respective applications are attached.

B. Direct Invocation
Instead of relying on a central hub, multiple relayers may act as intermediaries to proxy function calls between distinct blockchain networks.Nissl et al. have proposed a concept that enables cross-chain function calls but does not implement an abstraction layer and does not require a mediating blockchain to orchestrate interaction [60].Instead, smart contract invocations are executed by intermediaries and checked by validators who finalize transactions.Intermediaries bid on the right to execute cross-chain function calls to receive a reward, overcompensating execution costs on the target blockchain.A similar process is implemented for validators.In case misbehavior is observed, deposited funds are reduced.While the concept permits cross-chain function calls, multiple contract invocations and waiting times are required.Furthermore, the approach is only secure under economic assumptions, while SmartSync derives its security from Merkle proofs and a trusted state root.Chainbridge15 constitutes a similar protocol but relies on a trusted federation rather than economic safeguarding.
With GPACT, Robinson and Ramesh have proposed a protocol for cross-chain function calls that is agnostic to the applied communication technique [17].Thus, the verification of emitted events may depend on external signers of events or block header, an intermediary blockchain, or chain relays.Before actual function invocation, the execution is simulated of-chain, and a call graph including expected return values is returned.Initiating the cross-chain function call involves the registration on the first affected blockchain, including the call graph.After that, the functions are called sequentially, verifying whether the preceding transactions terminated successfully.Function calls are only deemed successful if the returned value is equivalent to the expected value retrieved during the simulation.All functions altering the state lock the contract until the entire call graph has been executed and state updates are applied atomically.Since the approach is based on emitted events, even queries that do not modify the contract state require function invocations, resulting in increased latency and execution costs, compared to concepts that use SPVs.Furthermore, return values must match a pre-computed simulation which may be impossible for use cases that rely on volatile data such as price oracles.In comparison, SmartSync permits instant readonly function calls of synchronized contracts but cannot invoke functions across blockchains.

C. Message-Based
Instead of intermediaries invoking smart contract functions directly, message-based protocols mediate using outgoing and incoming message queues.Smart contracts sending crosschain messages must prepare respective messages and be able to process incoming messages.A message could, for example, include a notification that a token has been locked and cause a receiving token contract to issue a wrapped representation.
The Cross-Chain Messaging Protocol (XCMP) 16 enables sending messages between shards in the Polkadot ecosystem [6].To send cross-shard messages, a smart contract emits a message that is stored in its host shard's outgoing queue.The validators of Polkadot's relay chain, which acts as a central hub, are responsible for distributing messages to the incoming queues of destination shards.Thus, the incoming message can be processed with a single relay chain block delay.After the process is finished, it is registered in the relay chain.As a result, the protocol enables very timely processing of cross-chain messaging, even though asynchronous.Therefore, smart contracts hosted on another shard cannot interact synchronously.In addition, XCMP is only applicable to sharded blockchain networks relying on a shared trust model and is not transferable to a heterogeneous setting.
In contrast, the Interblockchain Communication Protocol (IBC) protocol enables sending messages between heterogeneous blockchain networks [61].Therefore, message broadcasting is not limited to sharded blockchain networks organized in a hub-and-spoke fashion but applicable to any pair of networks allowing the implementation of relays.Messages are mediated by relayers who prove the correct settlement based on chain relays.Therefore, bidirectional chain relays are required to enable communication between two blockchain networks, and security guarantees are bound to the host blockchain network.The protocol defines interfaces for implementing chain relays-also called clients-and is agnostic to applied consensus algorithms, as long as eventual finality is provided.So-called connections are established between blockchains to guarantee messages' correct ordering and prevent re-execution of respective message queues.Smart contracts communicate via channels that define the semantics of application-specific communication, e.g., if message ordering is required.A connection can serve an arbitrary number of channels.If no direct connection exists, a route via intermediary blockchains can be established to deliver messages.Due to the abstraction of interfaces, the IBC protocol can cater to various blockchain implementations.While it has been initially proposed for communication via the Cosmos relay chain, the Hyperledger YUI 17 project implements the protocol for a diverse set of blockchains, namely Hyperledger Fabric, Hyperledger Besu, and Corda.
Similar to the IBC, the Layer Zero protocol permits transferring messages between heterogeneous networks [62].Crosschain messages are collected, and their existence is proven on the receiving blockchain using Merkle proofs based on previously relayed block headers.Yet, the protocol suggests using oracle networks like Chainlink instead of chain relays to provide block headers in a cost-efficient fashion.

VII. DISCUSSION
Different use cases have specific requirements for the refresh period of smart contracts.For instance, DeFi applications typically rely on up-to-date data, while registries such as the ENS do not change regularly.SmartSync can cater to both use cases, given the storage root is updated in time.Chain relay and target contract can be updated in the same block as the calling contract execution to provide the most recent state.In case SmartSync is applied to provide accessibility across shards, the utilization of synchronized contracts may behave equivalently to locally hosted contracts.
Synchronized smart contracts may also depend on other smart contracts.Synchronizing only a single contract without considering dependencies could lead to unexpected behavior.Therefore, all referenced contracts and libraries must be migrated and synchronized.Previous work on smart contract forks proposed the analysis of logic and state during migration and recursively deploying dependencies [48].As contract addresses change during deployment, they are substituted for each reference.Replacing addresses in the state results in a distinct state and thus Merkle root, leading to complex verification during deployment.In the case of synchronizations, the same mechanism could be applied.As the contract's Merkle root is deemed valid after migration, the computed transition confirmation also utilizes a valid root and does not need to be modified to create valid results.Therefore, the presented concept is applicable even if reference addresses were replaced during the initial migration.
SmartSync promotes read-only access for synchronized smart contracts and does not provide cross-chain write operations.While other approaches target such write access [17], [60], multiple steps, including locking, are required to maintain atomicity.As a result, the process is timeintensive and may lead to additional overhead if the timeout period is exceeded.Therefore, our solution leaves the responsibility of invoking transactions across multiple blockchains to the external application.Depending smart contracts hosted on another blockchain network are put in the desired state that is subsequently proven on the target blockchain.With this, the resulting state becomes accessible through simple function calls.Time-consuming locking mechanisms are mitigated, and instant function execution is enabled on the target blockchain.
The synchronization scheme assumes that the source and target blockchain share the same execution environment, for instance, the EVM.Furthermore, the smart contract storage must use the same Merkle tree variant to guarantee correct state updates.Different execution environments or storage methods prohibit trustless transition proofs and are, therefore, out of the scope of this work.
While our evaluation focused on the EVM and the Ethereum blockchain, the solution is not limited to these protocols.In addition to classic blockchain networks, smart contract synchronization could also be performed on scalability solutions allowing smart contract execution like sidechains and layer-2 solutions.
Sidechains are pegged to another blockchain but may provide enhanced throughput and lower transaction fees [63].For instance, Polygon's PoS chain 18 provides a bridge to the Ethereum main net and offers the execution of EVM contracts.While the scalability of updating states is aligned with our evaluation when using such sidechains, transaction costs can be significantly lower compared to the main chain.In addition, other contracts deployed to sidechains may require instant read-only access to referenced contracts.Therefore, the synchronization of smart contracts can act as an enabler to those contracts using sidechains for scalability reasons while utilizing main chain contracts.
The execution costs of smart contract synchronizations constitute a challenge to their adoption.Layer-2 concepts propose off-loading transaction execution from the blockchain to increase throughput and decrease costs [64].Multiple approaches exist.For instance, optimistic rollups allow the offchain execution of transactions, while observers can challenge the results if misconduct is detected [65].Another concept that recently gained traction is using zero-knowledge proofs to guarantee correct off-chain transaction execution [65].Since transactions do not have to be executed by all network participants but only a small set, layer-2 concepts generally scale well and incur less execution costs.However, data availability is a challenge and typically depicts one of the main cost drivers if storage is performed by the host blockchain, for example, by using transaction call data.Therefore, smart contract synchronizations would particularly benefit from the efficient validation of Merkle proofs.Although zero-knowledge-proofbased layer-2 solutions such as zkSync 2.0 are still in their test phase, they depict a promising scalability solution in future implementations of smart contract synchronizations, as they facilitate the efficient execution of EVM contracts.

VIII. CONCLUSION
In this paper, we presented SmartSync, a novel concept for synchronizing smart contracts across multiple blockchain networks.The state of a remotely hosted smart contract is synchronized periodically in a verifiable manner.No trust in executing entities is required, enabling all participants to perform state updates.Furthermore, we introduced transition confirmations that prove correct smart contract state transitions on a secondary blockchain based on a multi-proof.As the entire smart contract is migrated from the source blockchain, the contract's state and logic become accessible on the target network.Hereby, instant read-only function calls by depending smart contracts are rendered possible, facilitating use cases such as cross-chain registries or oracles.Our open source implementation proves the concept's soundness and demonstrates timely updates of contract states.The conducted case study shows the applicability of smart contract forks and synchronization even for large contract states.
In the future, the presented solution will foster overarching architectures that include off-chain components as well as on-chain workflows executed on multiple blockchains.Providing atomicity within such workflows depicts a potential task for future research.Required state updates are initiated sequentially and become available after synchronization.Thus, SmartSync constitutes a foundation for applications that utilize smart contracts across multiple blockchain networks.

Fig. 1 .
Fig. 1.Simplified contract state capturing the initial migration and synchronization of a diverted state.Green highlighting indicates transaction triggered value changes, purple illustrates the initial fork state and blue marks synchronized values.

Fig. 3 .
Fig.3.Synchronization workflow of SmartSync.The client retrieves state changes and respective proofs to compute a multi-proof.The multi-proof is submitted to the target chain that computes the transition confirmation and validates both.

Fig. 4 .
Fig. 4. Gas costs of synchronization processes including different update set sizes.

Fig. 5 .
Fig. 5. Time required for synchronization including different update set sizes.
cates inclusion of respective key-value pairs given the Merkle root, but fails to create a link to the previous state S (C A t ).Transition confirmations create such a link by replacing all values of the multi-proof's key-value set with the original values of the state transition.The original values are available during the computation, as they constitute the target contract's current state S (C A t ) = S (C B t+x t ) → S (C A t+y ), where y > x > 0. The submitted multiproof (R(C A t+y ), {(k 1 , v 1 ), (k 2 , v 2 ), . . ., (k n , v n )}) indi-