Webb Protocol¶
The Webb protocol is a private bridge protocol building on top of the chainbridge and Tornado cash protocols. It combines these architectures to create an interoperable privacy set to enable cross-chain private transactions with scalable privacy. More tokens on a particular bridge and more chains connected on a particular bridge only serve to increase the amount of privacy provided by that particular bridge.
Bridge Functionality - Roadmap¶
A privacy bridge provides a novel primitive for constructing private applications on top. While we consider a private bridge protocol for asset transfers below, we can also consider generalizations of this to build interoperable and private applications. The buildout of non-financial components of the protocol are not roadmapped but may be worked on in the future, at hackathons, and more.
We aim to build out a private bridge protocol for asset transfers in stages, starting with the most primitive use case of transferring and targetting extensions that compose nicely with existing DeFi primitives such as yield aggregators and lending solutions.
Version 1 - Shared privacy bridge functionality¶
The first functionality of the protocol is cross-chain, private bridging of Webb wrapped assets. The goal here is to simply provide a protocol for wrapping a base, origin asset into a Webb wrapped asset that can be transferred privately across chains.
Version 1.X - Governance functionality¶
The second functionality of the protocol is to integrate governance functionality to allow Webb tokenholders to govern the set of whitelisted origin assets that can be wrapped into a particular bridge's Webb wrapped asset. This is motivated primarily by the ability to scale privacy sets across tokens by aggregating and unifying similar liquidity under a common representation, e.g. the particular Webb wrapped asset.
Version 2 - Stable Swap bridges¶
With basic functionality and governance in tact, we can create a cross-chain stable swapping pool. We aim to go live with this architecture after the previous versions are built out.
Version 3 - Yield Delegation¶
With an expressive infrastructure in tact, we can continue to expand the scope of what's possible with these interoperable, privacy sets. This bridge protocol allows users to earn yield while contributing to a compatible yield-bearing privacy set. The goal here is to lend out the underlying liquidity to DeFi protocols on each side of the bridge, taking on more risk and also earning more yield in the form of other DeFi assets.
Relayer Functionality - Roadmap¶
Bridges are networked applications that span multiple blockchains and must be aware of events and/or state occurring across this network. The endponts of these bridges (e.g. the smart contracts / core protocol logic) are denoted Anchors in our system. These Anchors are required by definition to know about various parts of the state of other anchors, particularly the ones they're connected to across a particular bridge.
The backbone of any bridge is made up of the relayers -- otherwise denomted validators, relayers, authorities, nodes, etc. -- that maintain the liveliness of the bridge protocol. Relayers, as their name entails, relay information for a connected set of Anchors on a bridge. This information is then used to update the state of each Anchor and allow applications to reference, both privately and potentially not, properties of data stored across the other connected Anchors.
We aim to build a relayer infrastructure that gradually improves in its performance, efficiency, and overall security. We do this in stages by first building the necessary infrastructure to listen to events across a connected set of Anchors and react properly across a Bridge to preserve the liveness of the protocol.
Version 1 - Multi-sig governance functionality¶
The first iteration of the bridge relayer is responsible for event listening and transaction execution. - Event listening across a set of connected anchors to learn of new deposits on a Bridge. - Proposal creation and vote submission over the Bridge's governance process. - Data replication and an API for inspecting Anchor state off-chain.
Version 2 - Multi-party Threshold governance functionality¶
We then plan to integrate a DKG into a Substrate node for future governance purposes. - Direct integration into a (currently) Substrate chain or potentially other blockchain node (Cosmos-SDK) - Bootstraps off existing validator set and participates in consensus. - Execution of a distributed key generation protocol to generate a threshold key.
Version 3 - Auxiliary staking and punishment functionality¶
We will integrate the DKG directly into the Bridge governance system, allowing the bridge to be governed by a threshold key (or many).
- Integrate staking mechanism over finality authorities for registering local key matter.
- Integrate punishment mechanism over improper behavior in the DKG.
- Develop an on-chain pallet to govern the threshold and generate threshold signatures of Bridge.sol governance transactions.