Integration Design
Last updated
Last updated
The diagram above illustrates how USL integrates with the NTT protocol as a custom attestation method. The infrastructure consists of a set of smart contracts deployed on source and destination chains, along with off-chain components for claim generation and validations. Below is a detailed breakdown of each component.
The NTT Manager Contract, found in the standard NTT protocol repository, offers a unified interface for cross-chain token transfers (burning/locking tokens on the source chain and minting on the destination chain), peer NTT Manager contract management on other chains and transceiver contract management.
When the user calls the transfer function to move tokens, the contract creates an NttManagerMessage object encoding the token transfer details. This object is then passed to all transceivers stored in the NTT Manager contract.
UslTransceiver ContractPi Squared has implemented the UslTransceiver as a custom transceiver for sending and receiving NttManagerMessage objects.
On the source chain, the UslTransceiver mimics the default WormholeTransceiver contract by packing the recipientNttManagerAddress on top of the NTTManagerMessage to construct the TransceiverMessage object. However, unlike the WormholeTransceiver which routes messages to the WormholeRelayer contract, the UslTransceiver routes the message to our USL contract Usl.sol, triggering the USL custom attestation.
On the destination chain, the UslTransceiver unpacks the TransceiverMessage and delivers the NttManagerMessage to the corresponding NttManager contract.
A single USL core contract is deployed on each chain. This contract is responsible for:
Emitting events to trigger off-chain claim generation components
Validating and parsing submitted claims.
Upon receiving a TransceiverMessage from the UslTransceiver, the USL core contract further packs the recipientTransceiverAddress and other destination chain information on top of the TransceiverMessage to construct the RelayMessage object.
This RelayMessage is stored in a map indexed by (userAddress, nonce). A view function is provided to retrieve the message from the map. Finally, an event is emitted to trigger the claim generator.
Unlike the Wormhole core contract, which includes the entire message in the event, a USL event contains only the calldata to invoke the view function for message retrieval (the message itself is stored in the contract).
When receiving a claim, the USL core contract first verifies the claim and its associated inclusion proof (demonstrating that the claim is included in the validated set of claims inside the USL). The USL core contract then parses the claim and delivers it to the corresponding transceiver contract.
The claim generator is a trustless component in the infrastructure. The generated claim encodes the fact that at blockX, the relay message stored in the relayMessages map with the key (address, nonce) is Y. In other words:
relayMessages(address, nonce) [blockX] = Y
The validity proof consists of Merkle proofs to construct the necessary blockchain state for executing the map's view functions.
The claim generator operates in 2 modes:
Auto mode: The claim generator monitors events emitted by the USL core contract on the source chain. Using the view function calldata encoded in the events, it queries existing full nodes of the source chain to generate claims and their associated proofs. These claims and proofs are then submitted to the USL for verification.
Manual mode: If the claim generation service is unavailable or compromised, users can choose to run the claim generator locally and submit the bridge transaction hash to the local service. This service then queries existing full nodes of the source chain to generate claims and their associated proofs, submitting them to the USL for verification. The manual mode serves as a last resort to address liveness issues, providing resilience in claim transmission.
Notably, the reconstructed blockchain state contains only the information necessary to ensure and verify claim correctness. Discarding irrelevant state information not only aids storage requirements but also captures the essence of claim correctness. This facilitates manual inspection of claims when needed and contributes to our effort to minimize the trust base.
From a security perspective, since the claim generator produces both a claim and its validity proof, it can only affect the bridge's liveness, not its security.
The relayer is a trustless component that queries the USL for validation claims and their inclusion proofs, then relays them to the destination chain. In worst case, users can relay the claims and proofs themselves.
This approach to cross-chain messaging introduces bleeding-edge innovations worth considering:
Elimination of Multiple Circuits
By employing a single ZK circuit for mathematics, the USL eliminates the need for multiple specialized circuits. This streamlines the verification process and reduces complexity compared to existing systems.
Flexible Trust Model
Validators have the flexibility to choose their preferred method of claim verification, whether by accepting zero-knowledge proofs (e.g., SNARKs, STARKs) or by re-executing the computation independently.
Scalability Through Independent Claim Verification
Claims are self-contained and independently verifiable, allowing for parallel processing and increased throughput without the need for validators to maintain full blockchain states.
Complementing Existing Infrastructure
The integration enhances the NTT framework by introducing a mathematically rigorous method of claim verification, broadening the spectrum of available attestation methods.
Mathematical Proofs as the Basis for Trust
Central to USL’s approach is the notion that computation itself is proof. Every computational claim is treated as a theorem, and by generating formal proofs of these claims using K and Matching Logic, USL ensures correctness by construction.
