Design Considerations
Design Considerations - Metaoracle
Last updated
Design Considerations - Metaoracle
Last updated
To be able to manage requests, Oracle services often develop co-chains or blockchains, then interface onto one or more of these. While this approach enables expansion beyond a single blockchain, it also necessitates a larger technological infrastructure than designing for a single blockchain alone.
We deliberately chose to concentrate on creating an autonomous network while constructing METAO. With a dispersed group of nodes, Metaoracle may therefore be categorized as a Layer-2 network. As a result, the time to market will be significantly shortened, and security will be prioritized more so than if Metaoracle had been built as a Layer 1 network. Because the distributed nodes may interface onto different blockchains as needed, this does not restrict Metaoracle.
The degree of decentralisation (also known as participation permission) is still another factor. While Metaoracle isn't a blockchain in and of itself, it is quite similar in that it is a distributed system of nodes and data providers working together to alter the status of the blockchain. As a result, it is necessary to decide what degree of permission, if any, should be granted.
On one end of the spectrum, a permission Oracle service may demand that only a small number of these known feed providers provide feeds in addition to knowing who the feed provider is. A permissionless service, on the other hand, won't care who signs up to give feeds and won't even demand it.
The Metaoracle team agrees with the writers above that some kind of authorization is required, especially at first, but feels that decentralization should take place as much as feasible. A deposit mechanism is used to do this, and to take part, Node runners must stake and deposit a particular quantity of network tokens. This increases the entrance barrier to make being a malevolent actor or a subpar service as unappealing as possible. Additionally, community members will be able to elect or remove feed providers using aggregated data streams. In this approach, (until the community agrees differently) only institutional feed providers who can ensure high-quality data can participate.
