Architecture

CoopHive Layers

Components of the CoopHive Protocol, from Smart Contracts to SaaS

At the core of CoopHive is an SDK that allows anybody to create a token for a distributed computing network.

One layer above are the smart contracts that handle all the financial flows of the economy – payments, staking and slashing, the storing of deals, results, and mediation, etc.

One layer above that are the services that comprise the components of the network. Clients (job creators) and compute nodes (resource provider), mediators (which eventually can comprise any node in the network), and solvers, which act as market-makers.

At the highest layer is the Value Services Layer, for example a user-facing SaaS that allows users to pay for jobs on the network with Stripe. The goal is to have this layer abstract away the complexities of using Web3, providing consumers with a streamlined Web 2 experience.

CoopHive Architecture

Architecture of CoopHive

Job Lifecycle The lifecycle of a job looks like the following:

1. Job and/or resource offers are posted to the orderbook

2. The solver finds a potential match of a job and a resource offer

3. The solver proposes a deal to the client and compute node

4. The client and compute node agree to the deal by sending transactions to the smart contract

   1. As part of agreeing to the deal, they also post the relevant collateral

      1. The client deposits payment and timeout collateral

      2. The compute node deposits timeout collateral

5. If the compute node does not post the result within the agreed-upon time frame, it loses its timeout collateral, and the process stops here

6. The compute node computes the result of the job using an executor like Bacalhau

7. The compute node posts the CID of the result on-chain

   1. The compute node is refunded its timeout collateral, and deposits its cheating collateral

8. The client can either accept the result, or request mediation

   1. If the client accepts the result

      1. The compute node is refunded its cheating collateral

      2. The compute node is paid

      3. The client is refunded it timeout collateral

      4. The client is refunded its payment collateral minus the cost of the job

   2. If the client requests mediation, then a mediation protocol is invoked according to the agreed-upon terms of the deal

      1. If the mediation protocol determines that the compute node computed the result correctly

         1. The same steps occur as if the client accepted the result, except the client also pays a mediation fee

      2. If the mediation protocol determines that the compute node did not compute the result correctly

         1. The compute node is not paid, and has its cheating collateral slashed

         2. The client is refunded their timeout and payment collateral

         3. The compute node’s cheating collateral is allocated to the mediators

   3. The result of the mediation is posted on-chain

CoopHive Services

Services in the CoopHive Ecosystem

Clients and compute nodes send job and resource offers, respectively, to an entity known as a solver, which acts as a market-maker by proposing matches to participants in the network. If the client and compute node both agree to the deal, they send transactions to the smart contract. Since blockchains are based on public key infrastructure (PKI), only the corresponding owners could have signed the transactions (unless their keys were stolen). This market-making process also maintains decentralization, since clients and compute nodes have the final say on whether they agree to a deal or not.

In order to assure compute nodes that they will be paid if they compute correctly, and clients that the results they receive will be correct, both clients and compute nodes must place deposits as part of the process of making a deal and submitting a result. Smart contracts mediate financial interactions between nodes, including when the client wants to check whether a compute node has done the computation correctly.

A record of deals, results, and potentially mediation is recorded on-chain. The deals, results, and mediation consist of data that the smart contract needs to be on-chain (e.g. price per instruction), as well as mostly IPFS CID hashes. This way, all necessary data and metadata is stored on-chain, with all data that does not need to be stored on-chain being stored off-chain. Additionally, this makes the protocol much easier to upgrade incrementally, as very few changes will need to be made directly to the smart contract architecture, compared to if all data was being stored on-chain.