Threshold-based Consensus
Consensus model tailor made for each consumer
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.
Bitcoin Oracle 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 each event to validate, all 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 non-trusted 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.
Bitcoin Bridge, for example, will be incorporating a mixture of required and optional validators (with 51% threshold) to secure its BRC20 bridge, which 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 bridge.
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 bridge.
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