bridgetest.tusima.network
Open in
urlscan Pro
76.76.21.61
Public Scan
URL:
https://bridgetest.tusima.network/
Submission: On December 30 via api from US — Scanned from DE
Submission: On December 30 via api from US — Scanned from DE
Form analysis
0 forms found in the DOMText Content
Asset Message Faucet Docs Connect Wallet Tutorial: How to Use zkBridge P r i v a t e S a f e T r u s t l e s s M u l t i - c h a i n I n t e r o p e r a b i l i t y Protocol Powered by Cross-Chain Communication Protocol //Sending message import { ISender } from "interfaces/IBridge.sol"; ISender sender = Isender(<'Tusima zkBridge Router Address'>); sender.send( 56,// Destination chain id 0x......,// Receiver contract address on destination chain "Hello world"// Your message ); //Receiving message import { IReceiver } from "interfaces/IBridge.sol"; contract Receiver is IReceiver { function handleMSG( uint32 sourceChainId, address sourceAddr, bytes memory msg ) internal override { // Handle your message } } Information Cross-Chain Asset Cross-Chain Cross-Chain Airdrop Cross-chain airdrop Cross-Chain ENS Resolution Cross-Chain Asset Verification More … Core workflow To transmit trustworthy information between two blockchains without relying on a trusted intermediary, we can achieve this by verifying the consensus of the source chain within the execution environment of the destination chain. This capability is enabled by zk (zero-knowledge proof) technology. ApplicationContractSend(Msg)Block HeaderSource ChainCross ChainEventOperatorProofHeader}RelayerMsgMerkle Proof}Target ChainVerify & StoreMerkle rootVerify & Execute MsgTarget Contract Waiting for consensus proof The operator generates a zero-knowledge 'consensus proof' to demonstrate that there are a sufficient number of validators who have signed on this block within the light client protocol. Afterward, the light client is updated on the destination chain. How it works Waiting for block confirmation After the transaction is sent, the cross-chain message relay takes place once the consensus on the source chain is completed. Waiting for the relayer to verify and update The relayer sends transactions to execute the sent messages and verifies, through the Merkle proof in the light client, that the message was indeed sent on the source chain. Then, it waits for the light client to update. Cross-Chain Asset Verification Cross-Chain ENS Resolution Cross-Chain Airdrop Information Cross-Chain App Asset cross -chain Cross-chain airdrop Why choose Tusima Bridge ? 01 Security On-chain light clients do not depend on third-party services to confirm the validity of cross-chain transactions. This eliminates any need for trust assumptions and hinges entirely on the security provided by the underlying chain's consensus. 02 Permissionless The Ethereum zk light client is permissionless. Anyone can update our light client by generating zkSNARK consensus proofs. 03 Privacy Our provision of fine-grained privacy extension services to Web3 through the stealth address model addresses the requirements for both privacy protection and compliance policies. 04 Efficiency We've conceived and executed the deVirgo proof system with the primary aim of greatly expediting the generation of block header proofs. By incorporating proof validation, relay messages can now swiftly conclude, facilitating the rapid processing of remote blockchain data. 05 Decentralization zkBridge has established a decentralized proof-generation network, allowing any node to autonomously join the network for tasks like relaying block headers, generating proofs, and earning rewards. 06 Scalability Applications can access verified block headers via updated program contracts, execute functions tailored to their specific needs, and enable a wide array of applications built on top of zkBridge. 07 Universality The block header relay network and proof scheme in zkBridge are applicable universally to blockchains that support light client protocol synchronization of block headers. Copyright © 2023 Tusimalabs. All Rights Reserved