This litepaper touches on the security of Goracle at a very high level. Nearing mainnet launch, an in depth review of Goracle's security mechanisms will be published in the full whitepaper.
Goracle has four main themes surrounding security:
- Network consensus
- Trust model
- Data integrity
- Crypto-economic Security
Goracle security is centered around Pure Proof of Stake (PPoS). The core assumption is that a majority of the token holders will participate honestly in the protocol. This is implemented by tracking token balances as an Algorand standard asset (ASA) and validating votes inside of a layer-1 Algorand smart contract (ASC1).
In order for a token holder to participate in network consensus, they must run a node and stake any amount of tokens. These tokens will be used to determine how each node’s votes are weighted. The tokens can be withdrawn some amount of time after the node has last voted. The node runner is rewarded for network participation, they gain tokens from voting on oracle requests.
The basic unit within the protocol is an oracle request, the request contains information such as the request type, parameters if needed, and the destination for the oracle response. For each request a new block of data is proposed by a random node. This block is voted on by the network, votes are weighted according to each node’s stake. When a vote threshold is reached the block of data is committed to the network in the form of an inner transaction to the designated destination. The votes for each block are tracked and validated on-chain so the Goracle consensus process inherits the security and reliability of the Algorand layer-1.
The core Goracle protocol is trustless and permissionless. Participation is proportional to stake in the protocol token, participation rules are enforced on the Algorand blockchain, which is similarly trustless and permissionless.
The consensus process dictates that there is no single trusted entity in the network, rather the output of the network is decided by a random aggregate of the majority, so trust is distributed proportionally among token holders.
All protocols start out with some level of centralization. Goracle protocol aims to release features on a quarterly basis that will ensure full decentralization within 1 year of launch.
In order to ensure that oracle data is accurate the protocol makes some assumptions about what is considered correct or not and what potential states of failure the consumer needs to be aware of. In order to support multiple use cases, there are two basic request types in the core protocol: aggregated and direct.
The default request type for decentralized data is an aggregated request. This queries several different feeds for the same data and aggregates the result. This is useful for data that needs to be decentralized. The aggregation logic can be specified depending on the consumer use case. An aggregated request can be trustlessly queried and written to the network, however the consumer must trust the aggregate result of the feed providers as dictated by the aggregation logic.
For data that can be centralized, or only has a single source, a direct request will query a single specified source and write the result on-chain. A direct request can be trustlessly written to the network, however the consumer must trust the source of the data.
Data is considered time-sensitive by default, so if the network cannot come to consensus within a specified number of rounds then that request is forfeit.
For oracle requests that output a persistent value, a timestamp indicating when the result was last updated should be available for the consumer to check in their logic.
The Goracle whitepaper goes in-depth regarding the simulations surrounding aggregation logic.
As a proof of stake based consensus protocol, Goracle is susceptible to sybil attacks. The economic design of Goracle 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 end up spending more money than they stand to gain. To dominate and attack the network, 66% of tokens need to be bought out. In the first 2-3 years, at least 33% of stake will be by industry partners such as Algorand, 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 Goracle whitepaper will go into detail on the modelling of this relationship.
Price in relationship to how much supply a single entity can accumulate