pBridge, at the very high level, consists of two components – The Middle Layer Logic, which stores the transformed destination transaction messages in a Kafka queue, and the Multiparty Computation (MPC) based Threshold Signature Scheme Account, which ensures every destination transaction is executed collectively by a pool of Bridge Validators, maintaining decentralized, multi-party transaction signing.
Middle Layer Logic (MLL)¶
The Middle Layer Logic which basically reads the pSTAKE relevant transactions committing at the source chain, and creates raw transaction object to be executed at the destination chain. There are certain event emitters (smart contract-based events/Logs in Ethereum end, EventEmitter at Cosmos end) which keeps track of transactions in cosmos, which are parsed, and transformed using the middle layer logic, into Ethereum transaction which is then executed at the Ethereum chain, thereby executing transfer of value. The same operation happens at the Cosmos chain also, after reading events from Ethereum chain. The middle layer logic consists of set of transformation and optimization routines which are used to automatically create transactions for the destination chain. These routines comprise of transformation logic, batching of transactions, gas and speed optimizations etc. The MLL program is built in GoLang which executes in a secure, provable environment as a binary, ensuring immutable, verified transformations and destination transaction creation. For speed and optimization, these transformed transactions are stored as messages in Apache Kafka Queue.
Multiparty Computation (MPC)¶
The transaction is executed at the destination chain using a group of bridge validators collectively, so as to maintain decentralization. These bridge validators also happen to be a pool of whitelisted Cosmos PoS validators, who are selected as per several factors of assessment, to ensure only the most reputed and performant validators become part of operating the bridge. These validators collectively use a Multiparty Computation based account to collectively verify each transaction and provide their approval for transaction signing. If the threshold number of approvals are received, then the transaction is automatically signed and dispatched to the chain. The MPC based account also makes sure that validators can be dynamically added or removed as per their performance and legitimacy stats, all the while keeping the account address (and public key) the same. MPC accounts are much more sophisticated than multisig accounts since they can be scaled to any chain based bridging.
The following two schematics demonstrate both the flows of bridge operation. For transactions originating in the Ethereum end, like staking operation, the MLL will read the smart contract transaction and programmatically create a DELEGATE transaction at the cosmos end. This transaction is collectively signed by the pBridge validators. Satisfying threshold number of approvals leads to successfully signing and dispatching of the cosmos transaction, which performs staking at the protocol level. All this happens automatedly, in the background.
Figure 1: Staking Operation
For transactions originating in the Cosmos end, like wrapping operation, the MLL will parse the ATOM deposit operation in the pSTAKE MPC account, and programmatically create a transaction which calls the deposit function of smart contract at the Ethereum end. This transaction is collectively signed by the pBridge validators. Satisfying threshold number of approvals leads to successfully signing and dispatching of the Ethereum transaction, which issues pTOKENS to the Ethereum address of the user. All this happens automatedly, in the background.
Figure 2: Wrapping Operation