Need help with using SecretPath or want to discuss use cases for your dApp? Please ask in the Secret Network Telegram or Discord.
SecretPath is a protocol for lightweight, secure, privacy preserving message-passing between chains. Its purpose is to serve as a critical building block for bringing private data onchain in a useful yet privacy-preserving manner.
In technical terms, SecretPath is a message passing system for non-malleable, trustless interchain message passing. In more practical terms, SecretPath enables public chains to call arbitrary functions on private compute chains while preserving the privacy of the inputs and validity of the outputs. SecretPath is built using a primitive that we call TNLS ("Transport Network Layer Security") which is effectively a blockchain derivative of the TLS protocol.
SecretPath itself does not store or compute over data. Rather, it connects public blockchains and their applications to privacy-preserving computation networks. This design allows public blockchain applications to build and operate private computation contracts on privacy-preserving chains while keeping their primary smart contract logic and liquidity on public blockchains.
Ultimately, SecretPath enables the building of new applications that combine the transparency, UX, and latency benefits of public blockchains with the trust-minimized and private computation features of privacy-preserving blockchains.
The following sections provide a detailed technical overview of the current relayer and gateway architecture for SecretPath.
To get an overview of the Architecture go here: Architecture Overview
If you like to use SecretVRF in the most elegant way for you as an EVM developer, go here:VRF Developer Tutorial
To review supported EVM chains, go here: Supported Networks
As an user and developer, all you need to know is how to send messages to one gateway/receive messages from a gateway, which will be covered in those respective documentation sections. More tutorials with encrypted payloads are coming soon.
As a maintainer, you might want to look more closely at the relayer section of the codebase as well here: https://github.com/SecretSaturn/SecretPath
You can try a demo of SecretPath that bridges Secret VRF into EVMs here: vrfdemo.secretsaturn.net
This documentation was adapted from https://fortress-labs.gitbook.io/snakepath, courtesy of Leor Fishman.
SecretPath consists of two core primitives: relayers and gateways.
Gateways are the onchain smart contracts that handle the broadcasting, receipt, packaging, and verification of messages. Gateways are also the mechanism by which application developers will interface with the SecretPath protocol.
These gateways are relatively simple and generic, primarily consisting of two capabilities. First, gateways can handle signature operations. For gateways on public blockchains, that means verification; for those on privacy-preserving blockchains, that means verification as well as signing. Second, gateways handle serdes operations: converting contract inputs into correctly formatted packets and vice versa.
Relayers watch for messages on one chain and then call another chain with that message. For SecretPath, the primary security-related concern is liveness, not resistance to node collusion or censorship. The relayer is not tasked with relaying funds/tokens from one chain to another, but rather with watching for encrypted messages that need to be passed. The relayer does not have access to encryption keys that can decrypt these messages or signing keys to generate new valid ones, meaning that the relayer cannot compromise the data in security or correctness.
The most a relayer can do is to not transmit the data as requested, which would cause liveness problems for the network, but would not compromise user funds, smart contract applications, or sensitive data. This also makes the requirements for running a relayer significantly lower: a relayer needs only to be able to watch for transactions on host chains and create transactions on destination chains based on those host chain transactions.
Gateways are the onchain smart contracts that handle the broadcasting, receipt, packaging, and verification of messages. Gateways are also the mechanism by which application developers will interface with the SecretPath protocol.These gateways are relatively simple and generic, primarily consisting of three capabilities.
First, gateways can handle signature operations. For gateways on public blockchains, that means verification; for those on privacy-preserving blockchains, that means verification as well as signing.
Second, gateways handle serialize/deserialize operations: converting contract inputs into correctly formatted packets and vice versa.
Third, gateways on privacy-preserving chains can re-encrypt their inputs under the key of the final compute contract.
For more background on how the high-level architecture of SecretPath differs from that of other interoperability networks, see section 4 of the Snakepath whitepaper.
To use SecretVRF (Random Number Generation) over SecretPath please checkout this tutorial .
If you like to use Encrypted Payloads to store data in a KV store, please look at the .
Here you'll find a more in-depth overview with a detailed description of what the two core primitives (Gateways & Relayers) do. First, let us give you the core idea on what SecretPath really hinges on.
The core idea of SecretPath is the following:
The "master private gateway" is a confidential smart contract living on Secret Network.
Since this contract is confidential by default , we can store a (secret) private key, which only this smart contract can use to sign messages/packets and is unknown to the operators or to any contract administrators.
The only trust assumption that we have for this bridge model to work is therefore that the private key does not leak out the TEE (trusted execution environment)/confidential computation environment. In case the TEE breaks and that private signing keys could potentially leak, the encryption and verification keys can be rotated to new ones, keeping the bridge intact. Since we only rely on a smart contract to handle the core bridging functionality, we call this trustless. Some may argue that since we are using TEE's, we are not completely trustless but instead trust-minimized.
Everything else around this "master private gateway" is untrusted. We only use a lot of consistency checks and hashing to ensure that data weren't manipulated along any transmission path.
As outlined in the overview, the primary functions of the Gateway are:
For the "master public gateway" that is on a public blockchain, that means only verification of signatures. In our case, this public gateways verifies all secp256k1 signatures signed by the user or by the master private gateway.
The private master gateway does verification of the secp256k1 signed and encrypted user payloads. It also signs all outgoing messages using secp256k1 so that other user made private contracts as well as the public gateway contract can verify the validity of the message/packet.
Both gateways also handle serialize/deserialize operations. They convert contract inputs into correctly formatted packets and vice versa, while also doing the appropiate conversions between base64 (mainly used for secret) and hex (mainly used for EVMs) inputs.
Third, gateways on privacy-preserving chains can re-encrypt their inputs under the key of the final compute contract. The master private gateway can handle encrypted or unencrypted payloads. In the case of encrypted payloads, the payload is encrypted using a shared key that is generated via ECDH from a users randomly generated private key and the gateways encryption public key. We use the well known Chacha20-Poly1305 to do the symmetric encryption using that shared key.