Bridging

Cross-Chain Messaging

The design of the Wischain protocol, particularly its Ethereum-equivalence, facilitates secure cross-chain messaging. This is achieved through the use of Merkle proofs, which ensure the integrity and validity of data being communicated across different chains.

Mechanism of Cross-Chain Messaging

Wischain utilizes a robust framework to store block hashes from each connected blockchain. Specifically, it deploys two smart contracts dedicated to managing the world state roots of the respective chains:

1. WischainL1: This contract is deployed on Ethereum and is responsible for storing the Layer 2 (L2) world state root.

2. WischainL2: Deployed on Wischain, this contract stores the Layer 1 (L1) world state root.

Whenever an L2 block is generated on Wischain, the world state root of the corresponding L1 block is recorded in the WischainL2 contract through an anchor transaction. To maintain the integrity of this process, the world state root is included as part of the proof data submitted with each block. This ensures that only valid L1 world state roots are synchronized to L2, preventing any malicious attempts to introduce fake data.

Conversely, the L2 world state root is stored in the WischainL1 contract using the syncChainData function call within the LibVerifying library.

By implementing this mechanism, Wischain automatically synchronizes world state roots across chains, thereby enabling efficient and secure cross-chain messaging. This feature is crucial for maintaining coherence and reliability in multi-chain environments, allowing different blockchains to communicate effectively while ensuring the authenticity of the data being exchanged.

The Signal Service

The Wischain Signal Service is a smart contract that operates on both Layer 1 (L1) and Layer 2 (L2) of the Wischain ecosystem, providing a valuable tool for decentralized application (dApp) developers. This service leverages Merkle proofs to facilitate secure cross-chain messaging, enabling reliable communication between different blockchain environments.

Key Features

The Signal Service allows developers to:

• Store Signals: Developers can send messages (signals) that are securely stored within the service.

• Check Signal Status: Users can verify whether a signal was sent from a specific address.

• Verify Signal Receipt: One of the critical functions of the service is verifySignalReceived, which authenticates the receipt of signals across chains.

Understanding verifySignalReceived

To understand how the verifySignalReceived function operates, it’s essential to recognize that the Wischain protocol manages two key contracts:

1. WischainL1: Deployed on Ethereum, this contract maintains the latest world state roots from the Wischain L2 environment.

2. WischainL2: Deployed on Wischain, this contract tracks the most recent world state roots from the Ethereum environment.

The verifySignalReceived function can confirm on either chain that a signal was sent to the Signal Service on the opposing chain. This process involves the user or dApp calling the eth_getProof function, which generates a Merkle proof.

Generating a Merkle Proof

To utilize eth_getProof, you need to provide the following parameters:

• The Signal: This is the data you want to prove exists within the storage root of a specific block on the chain.

• The Address of the Signal Service: The contract address where the signal is stored.

• The Block Number: This is optional; if not provided, the function defaults to the latest block number.

When you call eth_getProof, it will return a Merkle proof, which includes necessary sibling hashes and the block height. Together with the signal, this information can reconstruct the Merkle storage root of the block being referenced.

Assuming that the state roots maintained by WischainL1 and WischainL2 are accurate, this process allows for reliable cross-chain messaging.

Example Workflow

Here’s a step-by-step example of how cross-chain messaging works using the Wischain Signal Service:

1. Send a Message: A user sends a message on a source chain, which is then stored on the Signal Service.

2. Generate a Proof: The user calls eth_getProof, which generates proof that the message was indeed sent on the source chain.

3. Verify Receipt: The user then calls verifySignalReceived on the destination chain’s Signal Service. This function verifies the Merkle proof, looking up the block hash where the message was originally stored. Using the sibling hashes from the Merkle proof, it rebuilds the Merkle root to confirm that the signal was included, indicating successful transmission.

By following these steps, users can easily send and confirm cross-chain messages. If you're interested in seeing how this works in practice, there’s a simple dApp that demonstrates these concepts. You can check it out here.

Overview of the Wischain Bridge

The Wischain Bridge consists of a collection of smart contracts and a user-friendly web application that facilitates the transfer of testnet ETH, as well as ERC-20, ERC-1155, and ERC-721 tokens between the Ethereum blockchain and the Wischain network. This bridge serves as a specific implementation built upon the foundational principles of the Wischain core protocol, utilizing the signal service that allows developers to create their own bridge solutions.

How the Wischain Bridge Functions

The functionality of the Wischain Bridge can be summarized through the following key components:

1. Smart Contracts: These are deployed on both the Ethereum and Wischain networks, managing the locking and releasing of tokens. When a user wants to transfer tokens, the smart contract on the originating chain locks the tokens, ensuring they are not spent elsewhere.

2. Frontend Web Application: This user interface allows users to easily interact with the bridge. Users can initiate token transfers, monitor the status of their transactions, and manage their assets seamlessly between the two networks.

3. Signal Service: This integral component of the Wischain protocol enables real-time communication between the bridge’s smart contracts on Ethereum and Wischain. The signal service ensures that both sides of the bridge are synchronized and that the transfer process is secure and efficient.

Flow of Token Transfers

To illustrate how the Wischain Bridge operates, consider the following flowchart that outlines the process of transferring tokens between Ethereum and Wischain using the signal service:

• Initiation: A user initiates a transfer from the frontend application, selecting the token type and amount to be transferred.

• Locking Tokens: The corresponding smart contract on Ethereum locks the specified amount of tokens, preventing their use until the transfer is completed.

• Signal Dispatch: The signal service is triggered, notifying the Wischain network that a transfer has been initiated.

• Minting or Release: Upon confirmation from the Wischain network, the bridge's smart contract will either mint equivalent tokens on Wischain or release the locked tokens on Ethereum.

• Completion: The user receives the transferred tokens on the desired network, completing the transaction.

By utilizing this architecture, the Wischain Bridge provides a robust and flexible solution for transferring assets between the Ethereum blockchain and the Wischain network, fostering interoperability and expanding the utility of tokens across both ecosystems.

How Does Ether Bridging Work?

Wischain's bridging mechanism leverages the Signal Service, providing a seamless user experience for transferring Ether between chains. Below is an overview of the user flow when using Wischain's bridge:

1. User Initiation: The user begins the process by sending their Ether to the Bridge contract.

2. Locking Ether: Upon receiving the funds, the Bridge contract locks the Ether and records a message by invoking the sendSignal(message) function on the SignalService contract.

3. Receiving Ether: The user (or another designated party) can receive Ether on the destination chain, contingent upon providing a valid Merkle proof that the message was successfully received on the source chain.

Bridging Ether: Two Scenarios

There are two primary methods to bridge Ether using Wischain:

1. Ether-Only Transfer: The user directly interacts with the Bridge contract by calling the sendMessage function.

2. Token Transfer with Ether: In this scenario, the user interacts with the ERCXXXVault (which supports ERC20, ERC721, and ERC1155 tokens) for transferring tokens. If the user fills the message.value field during this process, Ether will also be included in the bridging operation.

How Does ERC-20 (or ERC-721, ERC-1155) Bridging Work?

ERC-20 tokens originate from a canonical chain. To facilitate the transfer of a token to a different chain, a new BridgedERC20 contract must be deployed on the destination chain.

Bridging from the Canonical Chain to the Destination Chain

Here’s a step-by-step overview of transferring ERC-20 (and similarly ERC-721 and ERC-1155) tokens from the source chain to the destination chain:

1. Deployment of Contract: A contract for the ERC-20 (or ERC-721, ERC-1155) token must first be deployed on the destination chain. This is automatically handled by the ERC20Vault if it has not already been deployed.

2. Token Transfer: The user calls the sendToken function on the source chain's ERC20Vault. This action transfers the specified amount by utilizing the safeTransferFrom function on the canonical ERC-20 contract on the source chain to the ERC20Vault.

3. Sending a Message: The vault contract, via the Bridge, communicates with the Signal Service on the source chain, sending a message containing metadata about the bridge request. Crucially, this message includes the calldata for the onMessageInvocation() method.

4. Processing the Message: On the destination chain, the message is processed by submitting a Merkle proof (generated from the source chain) to verify that the message is included in the state of the source chain's Signal Service. After confirmation and checks, it attempts to invoke the onMessageInvocation() method, which mints the ERC-20 (or ERC-721, ERC-1155) tokens on the BridgedERC20 contract for the specified address on the destination chain.

Bridging from the Destination Chain Back to the Canonical Chain

To transfer a bridged token from the destination chain back to the canonical chain, the process is as follows:

1. Existing Contract: A contract for the ERC-20 (or ERC-721, ERC-1155) already exists on the canonical chain, so there is no need to deploy a new contract.

2. Burning Tokens: The user calls the sendToken function on the source chain's token vault contract, which burns the ERC-20 tokens on the BridgedERC20 contract.

3. Sending a Message: The vault contract, via the Bridge, again sends a message to the Signal Service on the source chain. This message includes metadata related to the bridge request and the calldata for the onMessageInvocation() method.

4. Processing the Message: On the canonical chain, the message is processed by submitting a Merkle proof (generated from the source chain) to verify that it is included in the state of the source chain's Signal Service. After verification and checks, the system invokes the onMessageInvocation() method encoded in the message, transferring the specified amount from the destination chain's TokenVault to the designated address.

Conclusion

The Wischain bridging process combines advanced cryptographic techniques and a well-structured architecture to ensure secure and efficient transfers of Ether and tokens across chains. By utilizing the Signal Service and following a clear protocol, Wischain enables seamless cross-chain interactions while maintaining the integrity and security of the underlying assets.