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

Form analysis 0 forms found in the DOM

Text 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