THORChain's Bifröst protocol today is a substantial different design from the original concept and other bridges.
The Bifröst does not seek to prove an event observed and reported actually did occur via validation.
Instead THORChain only seeks "observation consensus"
The Bifröst does not seek to prove an event observed and reported actually did occur via validation.
Instead THORChain only seeks "observation consensus"
Nodes are connected to a plurality of chains. Everytime they see a transaction concerning a THORChain vault, the bundle up their observation into a witness transaction.
A client sits between each chain-node and the Observer, which abstracts away chain nuances
A client sits between each chain-node and the Observer, which abstracts away chain nuances
The witness transaction object looks like the following, where, no matter the originating chain, all witness transactions are the same.
If all nodes report the same transaction, it is then finalised in the state machine.
At this point it can be acted on (swap ordering, validation, refunding, etc)
At this point it can be acted on (swap ordering, validation, refunding, etc)
After being acted on and generating a state change, a "Transaction Out" is then assigned to an outgoing vault and queued.
The "txOutItem" looks like the following, and once again is chain-agnostic. It doesn't care what chain it is going back on.
The "txOutItem" looks like the following, and once again is chain-agnostic. It doesn't care what chain it is going back on.
Once queued, the chain client converts the TxOutItem back into a chain-specific transaction that the TSS routine picks up on and signs.
It is then finally broadcast back to the external chain by all nodes.
It is then finally broadcast back to the external chain by all nodes.
In summary:
* No validation is required, observed events are assumed correct via consensus
* Chain client bundles events into a standardised witness tx
* Finalised witness transactions create state changes
* State changes cause TxOut generation
* TSS signs TxOut items
* No validation is required, observed events are assumed correct via consensus
* Chain client bundles events into a standardised witness tx
* Finalised witness transactions create state changes
* State changes cause TxOut generation
* TSS signs TxOut items
This system is:
* Scalable to many chains
* Abstracts away chain nuances
* BFT secure at every phase
* Economically secure
The team refer to it as "1-way state pegs" because only state is transferred to THORChain.
* Scalable to many chains
* Abstracts away chain nuances
* BFT secure at every phase
* Economically secure
The team refer to it as "1-way state pegs" because only state is transferred to THORChain.
The only downside to this approach is it is relatively bandwidth heavy:
* A single inbound transaction will necessarily cause 100 witness transactions with 100 nodes
However, old witness transactions can be pruned off, and native Rune asset reduces bandwidth.
* A single inbound transaction will necessarily cause 100 witness transactions with 100 nodes
However, old witness transactions can be pruned off, and native Rune asset reduces bandwidth.
Additionally, the team have spoken about "internal arbitrage", where pool<>pool arbitrage can occur with only using native transactions (and not need the Bifrost).
This is possible with asymmetrical staking/unstaking: assets can be moved between pools with no external tx
This is possible with asymmetrical staking/unstaking: assets can be moved between pools with no external tx
