Protocol Security
Metaoracle Security
Last updated
Metaoracle Security
Last updated
This Whitepaper touches on the security of Metaoracle at a very high level. Nearing mainnet launch, an in-depth review of Metaoracle's security mechanisms will be published in this whitepaper.
Metaoracle has four main themes surrounding security:
Network consensus
Trust model
Data integrity
Crypto-economic security
Pure Proof of Stake (PPoS) is the foundation of Metaoracle security. The fundamental premise is that the majority of token holders will feign participation in the protocol. Voting is verified inside of a layer-1 Binance smart contract (BSC1), and token balances are tracked as a Binance standard asset (BSA).
A token holder must host a node and stake any number of tokens to take part in network consensus. The weighting of each node's votes will be based on these tokens. Sometime after the node's most recent vote, the tokens can be removed. The node runner receives tokens for participating in the network and votes on Oracle requests.
The fundamental building block of the protocol is an oracle request, which includes details like the kind of request, any necessary arguments, and the location of the oracle answer. A random node will offer a fresh block of data for each request. The network votes on this block, and the weight of each vote is determined by the stake of each node. The block of data is committed to the network in the form of an inner transaction to the specified destination after a vote threshold is met. The Metaoracle consensus mechanism inherits the security and dependability of the Binance layer-1 since the votes for each block are logged and verified on-chain.
The fundamental Metaoracle protocol lacks both trust and authorization. Participation restrictions are implemented on the equally trustless and permissionless Binance blockchain, with participation proportionate to holdings in the protocol token.
Since the network's output is determined by a random aggregation of the majority rather than by a single trusted entity, as required by the consensus process, trust is dispersed evenly among token holders.
All protocols start with some level of centralization. Metaoracle protocol aims to release features every quarter that will ensure full decentralization within 1 year of launch.
The protocol makes various assumptions about what is deemed right or not and what potential states of failure the consumer has to be aware of to guarantee that Oracle data is true. The core protocol has two fundamental request types: aggregated and direct, which allow it to handle a variety of use cases.
Aggregated requests are the standard request type for decentralized data. This searches across many feeds for the same data and aggregates the findings. For data that has to be decentralized, this is helpful. Depending on the customer use case, the aggregation logic can be customized. The network can be queried and written to with confidence in response to an aggregated request, but the consumer must have confidence in the feed providers' aggregate results as determined by the aggregation logic.
A direct request will query a single specified source and write the response on-chain for data that can be centralized or has just one source. Although a direct request can be written to the network in an untrusted manner, the consumer still has to have faith in the data's source.
Data is automatically categorized as time-sensitive, so if the network cannot reach an agreement within a predetermined number of rounds, the request is forfeited.
A timestamp indicating when the result was most recently updated should be provided for consumers to check in their logic for Oracle queries that produce permanent values.
The simulations including aggregating logic are covered in great detail in the Metaoracle whitepaper.
As a proof of stake-based consensus protocol, Metaoracle is susceptible to Sybil attacks. The economic design of Metaoracle is intended to ensure that the token is as decentralized as possible, with tokens only being released in return for those performing platform activities, or in return for activities that grow the network. Furthermore, the use of vesting schedules and market makers ensures that any adversary that tries to attack the system by buying up the majority of tokens to stake ends up spending more money than they stand to gain. To dominate and attack the network, 30% of tokens need to be bought out. In the first 2-3 years, at least 10% of the stake will be by industry partners, making buying up the supply impossible. Furthermore, an adversary that does attempt will face an exponentially increasing price. The chart below simulates the price action of the token, based on how much supply a single entity accumulates. The Metaoracle whitepaper will go into detail on the modelling of this relationship.
