Bonbori Consensus Model
Cross-chain messaging and consensus layer for all and any off-chain computation engines
Bonbori is a cross-chain messaging and consensus layer for all and any off-chain computation engines that builds on Bitcoin.
Bonbori provides infrastructure that
allows two or more off-chain computation engines on Bitcoin to exchange messages, and
provides the consensus model to validate such cross-chain messages.
The consensus is deemed to have reached when a minimum threshold (i.e. "m-of-n") of the relevant community agree to a particular event.
End consumers can then verify the consensus before making a decision or taking an action with respect to that particular event, thus enhancing the security assumptions.
For example, Bonbori secures Brotocol. When Brotocol identifies a particular cross-chain transfer to process, it pulls the relevant consensus data from Bonbori, verify them using its smart contract before processing them on the relevant destination chain.
Flexible threshold-based consensus model
Using the "on-demand" consensus data, dapps and other end consumers of such data can reach the consensus based on a minimum threshold (i.e. "m-of-n") of the relevant community agree to a particular event.
Bonbori provides a consensus model framework that allows the end consumer to customise their consensus model by optimising across the trust and the security budget.
Each end consumer may specify a number of required (i.e. trusted) and optional (i.e. non-trusted) validators as its consensus model.
For example, for each event to validate, the end consumer may specify that the required validators must agree and a certain threshold (say 51%) of all validators (including required and optional) must agree.
A fast derivation of consensus is achieved through Threshold Sampling among nodes.
Some may choose to have only required validators, in which case, effectively, a federated concensus model is run. In this case, a trust element is introduced to eliminate the security budget constraint.
Some others may choose to have only optional validators, but with staking/slashing mechanism. In this case, the security budget enabled by the staking/slashing mechanism means the consensus model can be run trustlessly.
Threshold Sampling
Threshold sampling allows Bonbori to derive consensus from the network of nodes without having to download all the consensus data from its data layer. Bonbori engages in several rounds of random sampling for subset of the network and, with each successful round, consensus confidence grows. When Bonbori achieves a set confidence threshold, an event is deemed to have reached consensus, subject to validation by all trusted nodes.
Example - Brotocol
Brotocol is a key component of any projects building on Bitcoin that abstracts the difference between L1 and L2 from the user experience, i.e. providing the "native-like” Bitcoin DeFi experience on L1, whereby users can use native BTC or L1 assets issued on Bitcoin to interact with L2 smart contracts.
Brotocol is bi-directional or “two-way” bridge, meaning you can freely transfer assets between Bitcoin and its L2s and vice versa.
Brotocol incorporates a mixture of required and optional validators to secure its infrastructure, where the consensus (100% threshold) of the required validators must be met to validate the consensus (51% threshold) reached by all the validators.
This model brings the following benefits:
It lowers the barrier to entry to join the validator network, encouraging more members of its community to participate in securing the Brotocol infrastructure.
Security budget is replaced with a set of trusted validators, which essentially acts as the secondary check against the consensus derived from the network.
Larger part of the incentives can be allocated to encouraging the community to join and actively participate in securing the network.
Smaller part of the incentives needs to be alloacted to the "insurance" fund.
51% threshold and the lower barrier to entry to join the network means it is expensive for the required validators to take over the validator network.
Likewise, malicious actors cannot take over the validator network even if they own all optional validators (which is very unlikely) unless they also take over every required validator.
Last updated