Way Network Architecture
Last updated
Last updated
We adopt a modular architecture design so that different applications can easily integrate with Way Network, including 3 routes and 4 components (Sender and Receiver smart contracts, zkRelayer, Luggage, and IMTP).
There are three routes in this architecture as the following:
Core Route by zkRelayer
Upper Route by Way Luggage
Lower Route by Way IMTP
The core routing of the zkRelayer functionality is provided by the block header relay network, which is only trusted for livenes. It relays block headers from the source chain along with proofs of correctness, messages, and payloads on the target chain. The receiver verifies and accepts the proof submitted by zkRelayer.
The Receiver contract maintains a list of recent block headers and properly updates it after validating proofs submitted by zkRelayer; it exposes a simple and application-agnostic API from which application smart contracts can obtain the latest block headers of the source blockchain header, and build application-specific logic on top of it.
Applications that rely on zkRelayer usually deploy a pair of contracts, a Sender contract on the source chain and a Receiver contract on the target chain. The Receiver contract can call the updater contract to obtain the block headers of the source chain and perform application-specific tasks.
The Message on Chain A is transformed into a Merkle Tree Proof and then send to zkSpark and Groth16, so that the Merkle Tree Proof can be compressed much smaller than the original one and then this small proof with 130B size will be sent to the on-chain verifier.
Way Network has 512 validators which are light open-source programs. These validators are responsible to deliver the Block Number, Block Information, and their signatures to the mempool. They are not grouped into a chain structure, so they are not nodes. They are subscribers and all the public block information will be sent to zkSpark and Groth16 to generate a small proof with 130B size. Then this proof generated by zkHeaderRelayer will be sent to the on-chain verifier to do double-check with the proof generated by the zkMessageRelayer. There is a Signer list smart contract deployed on Chain B with an automatic wheeling mechanism. The right signers with good credit will be rewarded and the wrong signers will be published and removed from the list.
