Protocol Design

Feed Providers

Feed providers are the entrypoint for external data into the protocol. A feed provider can be specified with the URL to a JSON API. Data from different feed providers can be aggregated as part of a single oracle request. Feed providers can be unaware of the Gora protocol, as long as they provide a JSON API that can be consumed publicly. If feed providers want to collect a fee for providing data on Gora, they can insert a proprietary piece of middleware in front of their JSON API. This middleware validates that a fee payment has been made to the API provider in exchange for using data from the API.

Events

Consumers use events to communicate with the protocol. Each event is generated by sending a blockchain request of the corresponding event type to the main Gora contract. Events trigger various actions within the node runner and update the protocol state.

• Request: Request events are used to trigger single non-recurring blocks, for example to get the outcome of a one-time event, or to execute a computation.

• Subscription: Subscription events are used to register recurring requests, they are a superset of request events and contain additional parameters to specify when a new request is generated as part of the subscription.

Nodes

Nodes are the backbone of the network and function in a similar capacity to Algorand participation nodes with some key differences. Gora nodes are peer-to-peer and propagate information across the network using a customized version of a gossip protocol. It is assumed that node runners are running a node client implementation that conforms to the protocol specification. Nodes are responsible for listening to Gora events from the blockchain, responding to those events by triggering new blocks if applicable, and maintaining the state of the protocol.

New blocks are generated when a request event is received, or when a new request is generated internally in response to a subscription threshold being triggered. Each node generates a hash based on their private participation key, along with a block proposal. These are broadcast to the rest of the network and the other nodes agree on a single proposal from the proposer with the lowest hash. The block proposal contains information about the request that is being responded to, the voting contract on which to conduct the on-chain vote, and the data that is being proposed as the response to the request. Once a single proposal has been agreed on by the network, the on-chain vote begins. According to the voting contract selected, there will be a different random seed for each block, this seed is used to randomly determine the committee of participants who can participate in the vote for this block. Votes are sent to the voting contract, where committee membership is checked through a VRF proof that the participant must supply, and votes are tallied according to the hash of the block that each participant voted for. Votes are weighed according to each participant’s stake (I.E. total amount of tokens locked up in the main contract that participant has signaled as staked), and when the vote threshold is reached for a block hash, that block is committed to the destination that was specified in the originating request.