Comment on page
Design Considerations
Oracle services tend to generally build out co-chains or blockchains to be able to handle requests, and then interface onto one or more blockchains. While this method allows for growth beyond a single blockchain, the technical infrastructure required is greater than building specifically for a single blockchain.
When designing Gora, we made the intentional choice to focus on building an independent network. Therefore, GoraNetwork may be categorized as a Layer-2 network, with a distributed set of nodes. This means a much faster time to market, and a greater focus on security by reducing the number of attack vectors than building GoraNetwork as a Layer 1 network. This does not limit GoraNetwork, as the distributed nodes can interface with other blockchains as necessary.
Another consideration in the level of decentralization (aka permission to participate). Although GoraNetwork is not in and of itself a blockchain, it is very similar in that it is a distributed system of nodes and data providers, working together to affect the blockchain state - and as such, a level of permission, if any, needs to be determined.
On one spectrum, an permissioned Oracle service can require knowledge the feed provider is, and only a select number of these known feed providers to submit feeds. On the other end of the spectrum, a permissionless service will neither require nor care who signs up to provide feeds.
In their article “When Permissioned Blockchains Deliver More Decentralization Than Permissionless” (Bakos et al.)[1], the authors make a compelling argument that “while distributed architectures may enable open access and decentralized control, they do not preordain these outcomes…permissionless access may result in essentially centralized control, while permissioned systems may be able to better support decentralized control”. What this means is just because a system is built to be decentralized and distributed, it will take time to get there, largely due to malicious forces or large actors with economies of scale taking over at before the network is able to achieve network effects.
The Gora team believes that decentralizing as much as possible is essential but agrees with the authors above that some form of permission is necessary, especially at the beginning. This is implemented via a deposit mechanism, where Node runners must stake and deposit a certain amount of network tokens to participate. This raises the barrier to entry, with the goal being to make being a malicious actor or a poor-quality provider as unattractive as possible. Furthermore, aggregated data feeds will allow community members to vote in or vote out feed providers. This way, only feed providers that are institutional and can guarantee high quality data are allowed to participate (unless the community decides otherwise).
The oracle problem, at its core, means having to trust an entity in a world that should be considered trustless. It could be argued that the only real solution to this problem would be to conduct all activities that an oracle provides onto the blockchain. For example, if ALGOs were only ever exchanged for USDC on-chain, and USDC was only ever spent by individuals on chain, the exchange price of USDC/Algo may be determined on the blockchain, hence solving the oracle problem. However, basketball cannot be played on the blockchain, nor does the blockchain have a weather system.
One possible solution might be having everyone watching the game input the score on the blockchain, but what if the loser of a match has more fans, and feel like they deserved a penalty? With the advent of social media, coordinated social ‘spamming’ a system can and does go viral such as the ‘Bum rush the charts’ campaign to influence iTunes charts[2], or meme-fueled GameStop buying frenzy meant mainly to bankrupt large hedge funds[3].
By such definitions, the oracle problem may be considered unsolvable. While a detailed analysis of the oracle problem is outside the scope of this document, an alternative to such a strict definition is that as long as data is sourced from multiple reliable sources, and poor quality or malicious participants stand to lose much more than they gain (in addition to having a high cost barrier to entry), the system should remain secure. In fact, almost all major blockchains are designed as such.
[1] Bakos, Yannis and Halaburda, Hanna and Mueller-Bloch, Christoph, When Permissioned Blockchains Deliver More Decentralization Than Permissionless (September 25, 2019). Communications of the ACM, Available at SSRN: https://ssrn.com/abstract=3715596 or http://dx.doi.org/10.2139/ssrn.3715596
[2] Gilliatt, N., & Gilliatt, N. (2007, March 21). Distributed viral social media spam. Social Media Today. https://www.socialmediatoday.com/content/distributed-viral-social-media-spam
[3] Darbyshire, M. (2021, October 18). Almost 900,000 accounts traded GameStop at peak of meme stock craze. Financial Times. https://www.ft.com/content/df758a2a-6caf-4d5f-ab70-bb5815922b91
Last modified 1mo ago