2.5 Dispute Resolution Contract (DRC) Factory

The APIS Dispute Resolution Contract (DRC) Factory was initially designed as a function within the Governance Contract, but was later separated into its own contract to ensure complete modularity, allowing for upgrades to the DRC when a less subjective resolution mechanism is able to be deployed, which should be the case as zero-knowledge-proofs continue to scale. The purpose of the DRC Factory is to allow API holders to vote specifically on events that have happened off-chain, namely whether a Node or Gateway provided a fraudulent or misrepresented endpoint, either to another Gateway or end-user client. API tokens staked in the GC can be used to stake in the DRC (and in the Optimistic Rollup Contract, as described in 2.6) simultaneously, although requiring the signing of an additional transaction on the Ethereum mainnet.

The DRC Factory utilizes customized, stake-driven voting functions, namely a function and a function through which an API token holder signals their vote with the staking of their API tokens. The Factory merges these functions with simple opcodes, namely CREATE2, to allow anyone to deploy a Dispute Resolution Sub-contract (DRS), whose address and state is stored in the DRC Factory as a key-value mapping; a DRS can either have one of two states in the DRC Factory contract: or . In light of due process, all DRS are defaulted as .

Figure 2.5.1: DRC Factory Simplified Architecture.

All DRSs have 7.52 days (50,000 Ethereum mainnet blocks) to resolve itself, after which, if still unresolved, the entire system forks into two separate universes, in a design very similar to Augur’s stale-state solution [18]. At that point, API token holders must decide which fork of the network to recognize as canonical, based on what they believe the proper Dispute Resolution Outcome should be.

A DRS’s only purpose is to resolve whether a transaction from the Optimistic Rollup Contract (ORC) as either or . To conduct a knowledgeable vote, API holders must be aware of the endpoint that was sent either from the Gateway to the User or the Node to the Gateway. Thus, every Payment Transaction in the Optimistic Rollup Contract has the structure: <Client Account Address, Client Account Signature, Server Account Address, Server Account Signature, Transaction Amount, Endpoint Hash, Nonce>, where the Client is the Payer (either an End-user Client or Gateway) and the Server is the Payee (either a Gateway or Node).

//    {
      struct PaymentTransaction {
               address client;
               signature client;
               address server;
               signature server;
               uint amount;
               string[] endpoint;
               uint nonce;
         }
            }
         } 

Figure 2.5.2: Customized Payment Transaction Structure

The Endpoint Hash provides the canonical truth of what the delivered endpoint, such that voters of a DRS can simply check the result of their Endpoint Hash of the requested endpoint against the Endpoint Hash in the transaction that has been challenged. If the voter’s Endpoint Hash matches that of the transaction, the voter will vote that the transaction was and consequently that DRS is ; if the voter’s Endpoint Hash does not match that of the transaction, the voter will vote that the transaction was and consequently that the DRS is .

In order to generate the Endpoint Hash, the voter must have access to the Endpoint that was sent to the requester. To achieve this, all APIS Nodes and Gateways default to store transmitted Endpoints for 7.52 days (50,000 Ethereum mainnet blocks), after which Nodes and Gateways can prune the full Endpoint data from their storage. Full Endpoint data (the Endpoint Hash represents this data) consists of: <ID>, a hash representation of the dataset from which the API was called; <DataType>, with two possible returns of GraphQL or REST; <MessageInputs>, the specific variables that were requested in the API call; and <MessageOutputs>, the specific responses to the variables that were requested, with both <MessageInputs> and <MessageOuputs> strored in equal size arrays, such that they can be counter-checked. Because of the blockchain’s inability to objectively verify whether a <MessageOutput> was the correct response to the <MessageInput>, dispute resolution is a subjective process, but with clear on-chain references to use as canons. If a DRS is settled as <True>, the server party (APIS Node or Gateway) that had been paid for the API request will have their API stake slashed, at a ratio of:

where x is their API tokens at stake, y is the time that their API stake has been locked in the Optimistic Rollup Contract (see 2.6 below), z is the number of offences that have been generated since that stake was deposited (starts to 1, increases by 1 every false offense, which will be recognizable both in the Node and Gateway State Tries in the ORC), and k = 0.326. Payments are not rolled back in the case of proven fraud by a Node or Gateway; instead, the slashed stake is distributed at the ratio of 10-90 between the client that was frauded and the group of parties that voted correctly, proportionate to the size of their vote. It requires a minimum stake of 1,000 API tokens to act as a Node or Gateway, although we believe that the most used Nodes and Gateways will have staked a significantly higher amount of API, as the more API at stake, the more trustworthy they will be, the more usage they will obtain.

If a challenge itself is fraudulent, and not the API request, the challenger will have their stake slashed: it requires a stake of 500 API tokens to initiate a challenge, to mitigate spam. While this may incur friction for people wishing to challenge, obtaining 500 API tokens is feasible due to its exchange liquidity, and the upside from a correct challenge is designed to exceed the gas costs by at least ten-fold. If a challenger is wrong, their stake is distributed at a ratio of 10/90 to the party who enacted the correct API request and the group of parties that voted correctly, proportionate to the size of their vote.

In order to challenge a challenge, a group of parties must stake at least one-and-a-half times the amount of funds currently staked on the other side of the vote, within 18.1 hours of the last challenge (5,000 Ethereum mainnet blocks). If the DRS is not resolved after 7.52 days (50,000 Ethereum mainnet blocks), the system forks, with individual users deciding which fork to support. The goal of forking is to encourage faster resolution, as it is likely the market will converge upon one of the forks at a least a 90-10 ratio, as is common with most public blockchain protocol forks.