# Introduction CoopHive is a two-sided marketplace for computing resources. It allows clients to run arbitrary Docker containers or WASM images over arbitrary data, from IoT devices all the way up to GPU servers. It does this by leveraging the Bacalhau distributed computing platform, which was developed to have native compute capabilities over IPFS CIDs, and can also run computations over S3. Since CoopHive is a trustless and permissionless protocol, it has mechanisms for verification and mediation to resolve disputes, thus maintaining a reliable marketplace. At the core of CoopHive are a series of deals, results, and, when necessary, mediations. This flexible structure accommodates a wide array of computational tasks, from simple data processing to AI model inference. Users can negotiate terms (deals), submit jobs, receive outputs (results), and engage in a fair dispute resolution process (mediations) if discrepancies arise. This flexibility ensures that CoopHive can adapt to the evolving needs of its users. Additionally, CoopHive features pluggable mediation protocols. This means in the process of arriving at a deal, clients and compute nodes can select or develop mediation mechanisms that best fit their specific requirements, ensuring that dispute resolution is both effective and aligned with the unique nuances of each task. This pluggability is key to maintaining trust and efficiency within the marketplace, catering to the diverse preferences and needs of its user base. CoopHive has many applications, like AI inference, ZKP generation, computations over sensor data, privacy-preserving computations, supply chain management, compute sharing, hardware profiling, public goods computing, and more. See the [Whitepaper](/coophive/whitepaper)for more information. # 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. # Whitepaper {% hint style="warning" %} Please note that this version of the Whitepaper is out-of-date. Check back here, or follow our social media channels, for updates on the new version. {% endhint %} {% file src="/files/KjMu9N5ELRY8rkkgFztH" %} # Install CoopHive ## CoopHive CoopHive is a two-sided marketplace for computational resources. It enables users to run computational workloads in a permissionless protocol, where anyone can get paid to connect their compute nodes to the network and run jobs. It uses an EVM-compatible blockchain to manage agreed job state and payment and use [bacalhau](https://www.bacalhau.org/) to manage the compute nodes. ## Getting started ### Halcyon Testnet The testnet has a base curency of ETH and you will also get HIVE to pay for jobs (and nodes to stake). Metamask: ``` Network name: CoopHive Halcyon testnet New RPC URL: http://halcyon.co-ophive.network:8545 Chain ID: 1337 Currency symbol: ETH Block explorer URL: (leave blank) ``` #### Fund your Wallet with ETH and HIVE To obtain funds, go to The faucet will give you both ETH (to pay for gas) and HIVE (to stake and pay for jobs). ### Install CLI Download the latest release of `hive` for your platform. Both the amd64/x86\_64 and arm64 variants of macOS and Linux are supported. (If you are on Apple Silicon, you'll want arm64). Nb: to check your version use `which hive` - if an old version run `rm ` to remove that path then reinstall newest version The commands below will automatically detect your OS and processor architecture and download the correct build for your machine. ``` # Detect your machine's architecture and set it as $OSARCH OSARCH=$(uname -m | awk '{if ($0 ~ /arm64|aarch64/) print "arm64"; else if ($0 ~ /x86_64|amd64/) print "amd64"; else print "unsupported_arch"}') && export OSARCH # Detect your operating system and set it as $OSNAME OSNAME=$(uname -s | awk '{if ($1 == "Darwin") print "darwin"; else if ($1 == "Linux") print "linux"; else print "unsupported_os"}') && export OSNAME ``` Then Download & Install ``` # Download the latest production build curl -sSL -o hive https://github.com/CoopHive/coophive/releases/download/v0.1.0-f58afae/hive-$OSNAME-$OSARCH # Make executable and install it chmod +x hive sudo mv hive /usr/local/bin/hive ``` You can also, at your option, choose to compile `hive` using Go and install it that way on any machine that supports the Go toolchain. ### Run a Job ``` export WEB3_PRIVATE_KEY= ``` (or arrange for the key to be in your environment in a more secure way that doesn't get written to your shell history) #### Cows ``` hive run cowsay:v0.0.1 -i Message="moo" ``` #### SDXL ``` hive run sdxl:v0.2.9 -i PromptEnv="PROMPT=a new hexagonal beehive in the halcyon fields of springtime" ``` Not working? Try `rm -rf /tmp/coophive/data/repos` uninstall hive path and reinstall from the start ### Run a Node, Earn HIVE ``` hive resource-provider --offer-cpu 1 --offer-ram 1024 --offer-gpu 0 --offer-count 1 ``` systemd units & more details [here](https://github.com/CoopHive/coophive/blob/main/ARCHITECTURE.md) ## Available Modules Check the github releases page for each module or just use the git hash as the tag. * [sdxl](https://github.com/CoopHive/coophive-module-sdxl) * [cowsay](https://github.com/CoopHive/coophive-module-cowsay) More coming soon! ## Write a Module A module is just a git repo. Module versions are just git tags. In your repo, create a file called `module.coophive` See [cowsay](https://github.com/CoopHive/coophive-module-cowsay) for example This is a json template with Go text/template style `{{.Message}}` sections which will be replaced by hive with json encoded inputs to modules. You can also do fancy things with go templates like setting defaults, see cowsay for example. While developing a module, you can use the git hash to test it. Pass inputs as: ``` hive run github.com/username/repo:tag -i Message=moo ``` Inputs are a map of strings to strings. **YOU MUST MAKE YOUR MODULE DETERMINISTIC** Tips: * Make the output reproducible, for example for the diffusers library, see [here](https://huggingface.co/docs/diffusers/using-diffusers/reproducibility) * Strip timestamps and time measurements out of the output, including to stdout/stderr * Don't read any sources of entropy (e.g. /dev/random) * When referencing docker images, you MUST specify their sha256 hashes, as shown in this example If your module is not deterministic, compute providers will not adopt it and blacklist your module #### Writing Advanced Modules 1. `subt`: The `subt` function allows for substitutions in your template. This function is a workaround for the lack of direct substitution support in the module. It implements the [printf](https://pkg.go.dev/text/template#Template.Funcs) function under the hood, which allows you to format strings with placeholders.
Usage The \`subt\` function can be used in the same way as the \`printf\` function in Go. You pass in a format string, followed by values that correspond to the placeholders in the format string. \`\`\` const templateText = \` {{ subt "Hello %s" .name }} \` \`\`\`
# Clients # Quick Start This is a quick start guide for using CoopHive with a MetaMask wallet. Instructions are similar for most other wallets. ## Step 1: Set Up the Wallet Install the [MetaMask extension](https://metamask.io/download/). ## Step 2: Add the CoopHive Testnet Network 1. Open the MetaMask extension 2. Click on the network button dropdown at the upper left corner of the extension 3. Choose "Add Network" at the bottom 4. Choose "Add a network manually", which is located below all of the default options 5. Enter the CoopHive Testnet details below, then click save ``` Network name: CoopHive v0 testnet New RPC URL: http://halcyon.co-ophive.network:8545 Chain ID: 1337 Currency symbol: ETH Block explorer URL: (leave blank) ``` ## Step 3: Fund Your Wallet Go to [the faucet](http://halcyon-faucet.co-ophive.network:8085) to get ETH and HIVE using the same address you connected with in Step 1. ## Step 4: Add Private Key to Environment For example, 
export WEB3_PRIVATE_KEY=<your private key>
Alternatively, arrange for the key to be in your environment in a way that doesn't get written to your shell history. ## Step 5: Hello World 1. Run the following command: ```bash hive run cowsay:v0.0.1 -i Message="hello world" ``` 2. Wait for the job to be submitted to the solver, the solver to return a match, the deal to be agreed upon, the job to run, and for the results to be returned.
3. View your results using one of the options.
# Compute Nodes # Quick Start The testnet has a base currency of ETH, as well as a token called HIVE. HIVE is used for payments and collateralization. ## Prerequisites * A private key and funds for the testnet * See the instructions in [Quick Start](/user-guide/clients/quick-start) to set up MetaMask and use the faucet to receive initial funds * Linux (latest Ubuntu LTS recommended) * Docker * Nvidia GPU * Nvidia drivers * Nvidia docker drivers ### Install Bacalhau ``` cd /tmp wget https://github.com/bacalhau-project/bacalhau/releases/download/v1.0.3/bacalhau_v1.0.3_linux_amd64.tar.gz tar xfv bacalhau_v1.0.3_linux_amd64.tar.gz sudo mv bacalhau /usr/bin/bacalhau sudo mkdir -p /app/data/ipfs sudo chown -R $USER /app/data ``` ### Install CoopHive ``` curl -sSL -o hive https://github.com/CoopHive/hive/releases/download/v0.1.12/hive-linux-amd64 chmod +x hive sudo mv hive /usr/bin/ ``` ### Write .env file Create a .env file for your node. `/app/coophive/resource-provider-gpu.env` should contain: ```bash WEB3_PRIVATE_KEY= ``` Caution: do not use the same key for both client and compute node, even for testing. ### Install systemd unit for Bacalhau Open `/etc/systemd/system/bacalhau.service` and paste the following: ``` [Unit] Description=CoopHive v0 After=network-online.target Wants=network-online.target systemd-networkd-wait-online.service [Service] Environment="LOG_TYPE=json" Environment="LOG_LEVEL=debug" Environment="HOME=/app/coophive" Environment="BACALHAU_SERVE_IPFS_PATH=/app/data/ipfs" Restart=always RestartSec=5s ExecStart=/usr/bin/bacalhau serve --node-type compute,requester --peer none --private-internal-ipfs=false [Install] WantedBy=multi-user.target ``` ### Install systemd unit for GPU provider Open `/etc/systemd/system/coophive-resource-provider.service` and paste the following: ``` [Unit] Description=CoopHive v0 Resource Provider GPU After=network-online.target Wants=network-online.target systemd-networkd-wait-online.service [Service] Environment="LOG_TYPE=json" Environment="LOG_LEVEL=debug" Environment="HOME=/app/coophive" Environment="OFFER_GPU=1" EnvironmentFile=/app/coophive/resource-provider-gpu.env Restart=always RestartSec=5s ExecStart=/usr/bin/coophive resource-provider [Install] WantedBy=multi-user.target ``` Reload `systemd`'s units/daemons. This needs to be repeated if the `systemd` files above are modified. ``` sudo systemctl daemon-reload ``` Start `systemd` units: ``` sudo systemctl start bacalhau sudo systemctl start coophive-resource-provider ``` Use `systemctl` to check the status, and debug with `journalctl` if needed. For example, `sudo journalctl -uf coophive-resource-provider` will stream the output from your CoopHive node. Records of the resource provider accepting jobs can be found in the logs. ## Security ### Allowlisting Modules Set the environment variable `OFFER_MODULES` in the GPU provider to a comma separated list of module names of allowed modules. # Solver # Quick Start \ # Job Modules ## What is a CoopHive Module? A CoopHive module is a git repository structured using predefined templates and inputs to run computational jobs on the network. ## How Are Modules Structured? 1. Create a git repository for your CoopHive module. The module's versions will be identified using their git tags. 2. In the module's repository, create a file named `module.coophive`. This file will serve as a JSON template with Go text/template style sections, like `{{.Message}}`, which will be replaced by CoopHive with JSON-encoded inputs. 3. Alternatively, use Go templates to set defaults and perform other template-related operations. Some examples can be found [here](https://github.com/orgs/CoopHive/repositories). ## Handling Inputs Inputs are passed to your CoopHive module as a key/value pairs. For example: ```bash hive run github.com/username/repo:tag -i Message=moo ``` ## Tips for Deterministic Outputs Try to follow the following recommendations to increase the chances that your CoopHive module will be deterministic: * Make the output of your module reproducible * Strip timestamps and time measurements from the output, including to stdout and stderr * Avoid reading from sources of entropy, such as /dev/random * When referencing Docker images, specify their sha256 hashes ## # Game-Theoretic Verifiable Computing # Writings These documents provide a background for the ongoing research on CoopHive. They are primarily focused on the game theory and cryptoeconomics of the protocol, and include an introduction to verifiable computing, an overview of the specific problems we are tackling, a brief overview of prior work, a description of our approach, and mechanisms that we plan to test in simulation. # Verifiable Computing ## Verifiable Computing Basics Verifiable computing is dedicated to ensuring that outsourced computations (that is, computations that are not done locally) are done correctly. In some scenarios, it cannot be assumed that the node to which a job is being outsourced will compute the result honestly, or that it is not faulty. Moreover, verifying the result should have less overhead than computing the result in the first place. While blockchains provide safety and liveness, the massive replication of computation becomes too costly when that level of security is not needed. There is a difference between global consensus, which is necessary in blockchain environments, and local consensus, which is more suited for two-sided marketplaces. In global consensus, all nodes need to be convinced that every computation was done correctly. In contrast, in local consensus, only a small number of nodes - potentially only one node, the client - needs to be convinced that a computation was done correctly. Ostensibly, for a two-sided marketplace, this implies that only a client really needs to be convinced that a computation was done correctly. However, these computations are not done in isolation, and the interrelation between a client choosing one node repeatedly versus many different nodes, and the mathematics behind those decisions, as well as the need to create a protocol that any client can come along to with no prior experience and trust that cheating is disincentivized, implies the creation of a global game that, while not requiring global consensus in the traditional sense, emulates it in some manner. ## Approaches to Verifiable Computing ### Cryptographic Approaches One way to ensure that computations were done correctly is by using cryptographic methods. There are a number of cryptographic approaches for verifiable computation, including #### Interactive Proof (IP) * In interactive proofs, verification of a statement is modeled as an interaction between a prover and a verifier. The goal of the prover is to convince the verifier that the statement is true, even when the verifier does not have the computation resources to do the computation itself. * The protocol must satisfy completeness (if the statement is true, an honest verifier will be convinced) and soundness (if the statement is false, the prover cannot convince the verifier except with some negligible probability). #### Zero-Knowledge Proof (ZKP) * Zero-knowledge proofs are a type of interactive proof where the verifier learns nothing about private inputs of the computation, other than that the outputs were computed correctly from the all the inputs (some of which may be public/known to the verifier). * A ZKP can be made non-interactive, in which case it is called a Non-Interactive Zero-Knowlege Proof (NIZK). Two common variants of NIZKs are zk-SNARKs (zero-knowledge Succinct Non-interactive Argument of Knowledge) and zk-STARKs (zero-knowledge Scalable Transparent Argument of Knowledge). * Like IPs, ZKPs must also satisfy the requirements of completeness and soundness. #### Multi-Party Computation (MPC) * Multi-party computation allows multiple parties to jointly compute a function over their individual inputs without any party revealing its input to other parties. The main objectives of MPC are privacy (parties should learn known about each others' inputs), security (some level of anti-collusion preventing malicious attempts to learn information), functionality (the ability to compute functions over data), and robustness (the protocol should work correctly even in the presence of malicious behavior or faults). ### Trusted Execution Environment (TEE) * Trusted Execution Environments are secure and isolated enclaves, where code and data inside of the enclave are insulated from the rest of the system, including the operating system, applications, and other enclaves. The goal is to maintain both the confidentiality and the integrity of the code and data. ### Verification-via-Replication Verification-via-replication - often described using the adjective "optimistic" in the blockchain world - relies on recomputing the computation to check whether the end result is the same. The benefits of this method are that it is the easiest to understand, and in some sense, the easiest to implement. In contrast to the other approaches, verification-via-replication often requires reliance on game-theoretic mechanisms such as collateral slashing, reputation, and other methods. This can become a bit complex when trying to counter collusion between the nodes that are computing the results. One of the downsides of this approach is, of course, the extra effort expended on recomputing computations. However, with proper incentives, the overhead of this can be reduced dramatically. It is also important to keep in mind that the overhead of this approach is much lower that cryptographic methods, which usually have much higher overhead. ## Our Approach We opt for verification-via-replication as a first approach, for the reasons that it is simple to understand, has less overhead than cryptographic approaches, and has an attack surface that can be economically modeled and analyzed. This has the downside of making private computations difficult. While the inputs and outputs of jobs can be encrypted so that only the client and compute node can see the code and data, this still leaves the client vulnerable to having their information leaked. Future approaches can incorporate SLAs and eventually support for homomorphic encryption to deal with this issue. # Problem Statement ## The Problem ### Problem Setup The setup is a trustless, permissionless, two-sided marketplace for compute, where clients can purchase compute services from compute nodes. Trustless means that by default, the protocol does not assume that any particular node behaves in a trustworthy manner, and that each node should be considered as rationally self-interested (note that this excludes intentionally malicious behavior). Permissionless means that any node can join or leave the network at will. Matches for compute jobs are made off-chain, with the resulting deals and results recorded on-chain. Both clients and compute nodes need to agree to matches before they become deals, and make deposits to the protocol to enable rewards and punishments. Results are verified using verification-via-replication, and clients can check the results of any job after it has been completed, but before it needs to pay. It does so by calling upon a mediation protocol. The mediation protocol is the ultimate source of truth, and the outcome of the mediation protocol determines how payouts to nodes are made. The issue of preventing fake results in the presence of a Trusted Third Party (TTP) as a mediator is effectively a solved problem (for example, see the section on prior verification-via-replication protocols, though there is much more literature on this topic). Given the assumption that the mediation protocol is the source of truth, we can treat the mediation protocol as a TTP. Since the fake results problem is basically already solved in this case, the cheating problem reduces down to solving the collusion problem within the mediation protocol. (Note, however, that we will address both cheating and collusion; the framework described here exists to conceptually simplify the problem.) This is a typical scenario of a Byzantine environment, and we can use well-established approaches to Byzantine Fault Tolerance when invoking mediation. However, most BFT algorithms and cryptographic methods rely on assumptions regarding some fraction of honest nodes. The problem is that rational, utility-maximizing agents can still collude, even in a mediation consortium, in order to converge on incorrect results. One the one hand, we could assume that some fraction of nodes are honest, as is often done. One the other hand, can we do better? ## Problem Statement ### Task The task is to find the mechanisms that incentivizes all nodes to behave honestly. ### Adversary model All agents in the protocol are utility-maximizing. This will be elucidated in a subsequent section. Most of the literature has focused on the case where compute nodes are dishonest. However, the client can also behave dishonestly in some manner that maximizes their utility. For example, if the client has some level of control over the choice of mediator, and dishonest nodes have their collateral slashed, the client could collude with the mediator in order to deem a correct result incorrect and get a cut of the honest compute node's collateral. ### What is a good solution? "Good" solutions can take a number of forms: 1. Nodes never have an incentive to be dishonest. 2. Nodes have an incentive to be dishonest that goes to zero as a function of the parameters of the protocol. 3. (1) or (2), but under some simplifying assumptions, such as there being some fraction of honest nodes within every mediation protocol. A good solution would achieve any of these goals. Alternatively, another valuable outcome of this research would be to discover under what assumptions these goals can or cannot be met, or if the goals are even possible to achieve at all. ### Mechanisms for achieving these goals There are a number of ways that these goals may be achieved. The approach will be to construct a digital twin of the protocol and test a number of different mechanisms in simulation. These mechanisms include variations on mediation protocols, collateralization, staking, taxes and jackpots, and others; see the Mechanisms to Explore section for details. # Prior Protocols Before explaining our approach, we give a short overview of three prior approaches to verification-via-replication distributed computing protocols: Truebit, Modicum, and Smart Contract Counter-Collusion. We will outline potential improvements, and how our work builds on top of, and differs from, prior work. ## [Truebit](https://arxiv.org/pdf/1908.04756.pdf) Truebit is a protocol for outsourcing computation from blockchains, built using smart contracts on top of Ethereum. The original potential use cases were trustless mining pools, trustless bridges, scaling transaction throughput, and, scalable “on-chain” storage. Since its goal are to scale on-chain computation, it aims for global consensus: "Since there exist no trusted parties on Ethereum’s network, by symmetry we must allow any party to be hired to solve any computational task, and similarly anyone should be able to challenge a Solver’s outcome of a computational task. The latter requirement ensures that TrueBit operates by **unanimous consensus**." (emphasis added) The components of Truebit are Miners, Task Givers, Solvers, Verifiers, and Judges. In order to incentivize checking results, random errors are forced into computations, with jackpots awarded to those who find them. These jackpots are funded by taxes on computations. The verification game consists of a series of rounds, where in each round, a smaller and smaller subset of the computation is checked. Eventually, only one instruction is used to determine the whether a Solver or Verifier is correct: ["In fact, only one instruction line is used in a verification game. There will be a part of the program code where there is a discrepancy between the Solver and the Verifier. The instruction of that discrepancy point is used to verify who is right."](https://truebit.io/guide/truebit-structure/) The authors claim that Sybil attacks are mitigated by pairwise Sybil-resistance between the parties of Task Givers, Solvers, and Verifiers, with Judges and Referees, whose roles are played by Miners, assumed to function as intended. Likewise, they claim that attacks to get bogus solutions on-chain by scaring off Verifiers are mitigated by the economics of deposits, taxes, and jackpot rewards. Additionally, a cartel of Solvers who absorb losses until they find a task with a forced error, upon which time they will receive the jackpot, will lose money in the long-term, since the expected Solver deposit per task is higher than the expected jackpot per task. Addressing another attack, the authors claim that an attack involving a flood of Challengers who try to take as much of the jackpot reward resulting from a forced error as possible is mitigated by having the total jackpot reward decrease as the number of Challengers increases. ### Challenges * Does not scale to large/complicated/arbitrary computations * No formal theorems or proofs, no simulations, many plausible but unsubstatiated claims, especially regarding collusion * Everything is done on-chain * This model does not work well with two-sided marketplaces, because * It aims for global consensus, where any node is allowed to do the computation, whereas in two-sided marketplaces, clients need to be able to choose which nodes they are paying to do the computation * Clients may have time restrictions on their computations, and cannot wait for cases where their computations were injected with forced errors * No accounting for repeated games ### Takeaways * Taxes and jackpots are a valuable tool to create a global game that affects local outcomes * Provides a list of potential client attacks ## [Modicum](https://www.researchgate.net/profile/Aron-Laszka/publication/341640091_Mechanisms_for_Outsourcing_Computation_via_a_Decentralized_Market/links/5f14736b299bf1e548c3712a/Mechanisms-for-Outsourcing-Computation-via-a-Decentralized-Market.pdf) The original version of [Modicum](https://www.researchgate.net/profile/Aron-Laszka/publication/341640091_Mechanisms_for_Outsourcing_Computation_via_a_Decentralized_Market/links/5f14736b299bf1e548c3712a/Mechanisms-for-Outsourcing-Computation-via-a-Decentralized-Market.pdf) had five key components: Job Creators (JC), Resource Providers (RP), Solvers (market makers), Mediators (agreed-upon third parties for mediation), and Directories (file systems, which we have replaced with IPFS and Docker registries). Job Creators are clients, the ones who have computations that need to be done and are willing to pay. Resource Providers are those with computational resources that they are willing to rent out for the right price. Solvers are market-makers; they match the offers from JCs and RPs. Mediators are third parties trusted by both JCs and RPs to arbitrate disagreements. The Directories are network storage services available to both JCs and RPs. Job Creators are only allowed to submit deterministic jobs to the protocol. The Mediator exists to check for non-deterministic tasks submitted by the Job Creator (which can be used by the Job Creator as an attack vector to get free results), and fake results returned by the Resource Provider. The method for determining whether a job is deterministic or not is for the Mediator to run a job n times and check to see whether it receives different answers. Modicum combines two separate ideas: checking the result from a Resource Provider to see if it is correct, and checking a result from a job submitted by a Job Creator to see if the job was deterministic or not. This implies that there is no capability for a client to simply check whether a result is correct or not, without the possibility of its collateral being slashed. An alternative to trusting the Mediator (to act as a TTP) by having it run a job n times is having a consortium of n Mediators each run the task a single time. However, this adds the complication of achieving consensus in that consortium. The issue of the Resource Provider and Mediator colluding to return a fake result is not addressed by this protocol. The authors allow for a Job Creator or Resource Provider to remove a Mediator from their list of trusted Mediators if they no longer trust it. However, that still leaves room to cheat at least once, and ideally this should be disincentivized from the outset. There is also the issue of collateralization. The Modicum protocol, as well as a number of other protocols, assume (approximate) guesses as to the cost of jobs in advance, so that nodes can deposit the correct amount of collateral. However, doing so is fraught with complications; we provide an alternative approach in the Mechanisms to Explore section. ### Challenges * The Mediator is basically a trusted third party * Client cannot simply check a result without being slashed, which is a consequence of the client attack model * No accounting for repeated games ### Takeaways * Potential client attack, though one that can be mitigated by technical means * The client has benefit of getting correct results, which needs to be accounted for in simulation * Useful prototype for a two-sided marketplace (the [follow-up paper](https://par.nsf.gov/servlets/purl/10355144) for stream processing applications is also useful) ## [Smart Contract Counter-Collusion](https://arxiv.org/pdf/1708.01171.pdf) The authors determine that cryptographic methods for verifiable computation are too expensive for real-world scenarios. For that reason, they rely on verification-via-replication. The scenario is one in which a client *simultaneously* outsources computation to two clouds, where those two clouds deposit collateral into smart contracts in such a way to create a game between them, where the game incentivizes doing the computation honestly. The central challenge that the authors tackle is the issue of collusion - that is, what if the two clouds collude on an incorrect answer? In contrast to Modicum, the client is assumed to be honest, and in contrast to Truebit, a trusted third part (TTP) is used to handle disputes. ### Three Contracts The authors use a series of three contracts to counter collusion. The first game is an induced Prisoner's Dilemma - to avoid the two clouds colluding, one cloud can be rewarded the other cloud's deposit (minus payment to the TTP for resolving the dispute) if the former returned the correct result and the latter did not. Thus, each cloud is better off giving the other cloud fake results while computing the correct result itself. This contract is called the **Prisoner's contract**. It is analogous to the equilibrium in the classic prisoner's dilemma being defection <> computing honest result and giving other node fake result if offered to collude. However, the clouds can agree to collude via a smart contract as well. They could do this by both depositing another amount into a contract, where the leader of the collusion must add a bribe (less than its cost of computing) to the contract as well (disregarding the bribe, both clouds deposit the same amount of collateral). The deposit is such that the clouds have more of an incentive to follow the collusion strategy than to deviate from it. This contract is called the **Colluder's contract**. In order to counteract the Colluder's contract, a **Traitor's contract** is used to avoid this scenario by incentivizing the clouds to report the Colluder's contract. The basic concept is that the traitor cloud indeed reports the agreed-upon collusion result to the client in order to avoid the punishment in the Colluder's contract, but also honestly computes and returns the result to the client in order to avoid the punishment of the Prisoner's contract. The client must also put down a deposit in the Traitor's contract. Only the first cloud to report the Colluder's contract gets rewarded. The signing and reporting of the contracts must happen in a particular order in order for this process to work. The authors prove that these games individually and together lead to a sequential equilibrium (which is stronger than a Nash equilibrium), meaning that it is optimal not only in terms of the whole game, but at every information set (basically the set of options each player has at every turn). ### Challenges * A Colluder's contract can be signed on different chains (or even off-chain). In order to mitigate this, the Traitor's contracts would have to become cross-chain (which is a major technical challenge), not to mention the possibility of cryptographically secure contracts (e.g. MPC contracts) where one of the parties alone would not be able to prove the existence of this contract * Relies on trusted third party to resolve disputes * Every task is replicated (that is, two copies of each job are always computed) * Assumes client is honest * Assumes amount of collateral known beforehand * No accounting for repeated games * It is well known that in the repeated Prisoner's dilemma, depending on the assumptions, cooperation becomes the equilibrium ### Takeaways * The contracts and the payoffs that they induce offer a valuable toolbox to think about the problem of collusion * The contracts offer, in a restricted setting, an ironclad way (assuming the proofs are correct) of preventing collusion # Autonomous Agents ## Utility Maximization A core assumption in much of game theory is that agents are utility-maximizing. That is, agents are completely rational actors, and are able to execute exactly the behavior that maximizes their return, however "return" is defined in the given context. However, we know that in real life, humans are not completely rational, and are not capable of perfect execution of actions. In that light, how can we look at the game-theoretic approaches in the last section? Either we can try to account for the irrational behavior of humans, or we can try to emulate the behavior of utility-maximizing agents. While there is a large amount of game-theoretic literature dedicated to the former, we opt for the latter for reasons that will become clear below. While this problem setting - verifiable computation by way of game theory - is different than many game theoretic settings, we can draw inspiration from commonly used concepts like the [revelation principle](https://en.wikipedia.org/wiki/Revelation_principle) and [strategyproofness](https://en.wikipedia.org/wiki/Strategyproofness). Both strategyproofness and the revelation principle are centered around the idea of incentivizing agents to truthfully report their preferences. Most approaches in the literature rely on analytic methods to determine what rational agents will do by analyzing their payoffs as a function of their preferences, the behaviors of other agents, and the mechanism under analysis. Ultimately, we are also aiming to find (a) mechanism(s) that lead(s) to an equilibrium where all agents choose to not cheat and not collude. ## Autonomous Agents Note that the actual environment of a two-sided marketplace for distributed computation is extremely complicated (e.g. the heterogeneity of hardware, types of computation, latencies and bandwidths, etc.). Any theoretical/analytic approach to the problem that is actually correct should also work in simulation, so we opt for a simulation-driven approach. The way that we can emulate perfectly rational behavior is by training autonomous agents to act on behalf of their human owners in a utility-maximizing manner. At that point, the challenge is to design the global game to drive the probability of cheating to zero - ideally, to make it be equal to zero - which is no small feat in a trustless and permissionless environment. However, the simplifying assumption that we are in fact operating with utility-maximizing agents conceptually simplifies the problem immensely. The process begins by creating a digital twin of a two-sided marketplace. In this environment, autonomous agents acting on behalf of client and compute nodes will be trained to maximize returns based on data gathered in simulation. For now, we will elide maximizing returns by optimizing scheduling, though this is a future topic of interest. We will use techniques primarily from the field of multi-agent reinforcement learning in order to train the agents. The precise methods we will use (e.g. modes of training and execution, homogenous vs. heterogenous agents, choice of equilibrium, self-play vs. mixed-play, value-based vs. policy-based learning, etc.) will be determined in the course of building the simulation. See the [pre-print](https://www.marl-book.com/) by Albrecht, Christianos, and Schäfer for our reference text. At a minimum, the action space for an autonomous agent representing a compute node should be to cheat or not to cheat, and to collude or not collude within a mediation protocol. The observable environment for nodes on the network should include all data stored on the blockchain - that is, the sequence of deals, results, and mediations - as well as the information in the orderbook. While the orderbook will be off-chain, we model in the digital twin the orderbook acting as a centralized, single source of truth that all agents have access to. In the long-term, nodes will have (potentially non-identical) local information regarding other job and resource offers on the network. Further work may explore agents forming beliefs about the hardware and strategies of other agents, but that is beyond the scope of the current work. ## First Principles Approach We conclude with two "axioms" upon which we will base our simulations: 1. Every agent attempts to maximize its utility, including cheating and/or colluding if necessary. 2. All other components of the game should lead to a "good" solution, as defined in the problem statement. # Mechanisms To Explore The following is a list of mechanisms that we are currently considering exploring in order to mitigate attacks. Note that some of these mechanisms clearly would not be able to deter cheating and collusion alone. However, in combination with other mechanisms, they may achieve the goals. In this sense, they should be thought of as modules, optionally composable with each other. ## Mediation Clients call upon a mediation protocol in order to verify the results of a node. There are several variations of the structure of the mediation protocol; the following parameters can be varied: 1. The number of nodes in the mediation protocol. 2. If more than two nodes in the mediation consortium, the consensus threshold that determines which result is the one considered to be correct. 3. How the nodes are chosen. * For example, we may want as a baseline the same constraint as in Modicum - that only mediators that both the client and the compute node mutually trust can be used for mediation. * Even with this baseline, there is still a question of how to choose the node(s) - it can be random, be determined by an auction, or any other method. 4. Recursive mediation - that is, if there is no consensus in the consortium, do another mediation. * There is a large space of possibilities regarding how to execute this. * There needs to be a limit to the number of nodes this recursive process can use. For example, the set of potential nodes can be the same as the set of mutually trusted mediators, as described above. 5. Other methods discussed here, such as taxes and jackpots, as well as staking and prediction markets, can be incorporated into the mediation protocol. ## Collateralization There are a number of different types of collateral that need to be included in the protocol. The client needs to deposit collateral so that the compute node knows that it can be paid. For computations where the cost is known up front, this is simple. However, it becomes complicated for arbitrary compute; the client might not have put up enough collateral initially, so there may have to be a back-and-forth between client and compute node where the latter halts the computation until the former deposits more collateral or simply cancels the computation and pays for the partially computed result. If the client does not pay, then the compute node can invoke a mediation process. The compute node needs to deposit several types of collateral. 1. Collateral in case they timeout. * This is put up as part of the deal agreement - that is, when the deal is posted on-chain. 2. Collateral in case they cheat. * The way that the compute node will convey the amount of collateral they will deposit to indicate that they will not cheat is via a collateral multiplier. The compute node commits to a multiple of whatever they will charge the client ahead of time as part of the deal agreement. The actual collateral is put up after the result is computed and sent to the client. This simplifies immensely the task of determining how much collateral to deposit for arbitrary computations. 3. Collateral in case they don't do the computation at the rate they said they would. This is closely related to timeout collateral. * Ideally, this is a way of enforcing deadlines on jobs. * It is not necessary to make this collateral slashing binary - for example, a late result can be still be rewarded. * It is enforceable if, for example, the compute node says that they will do X WASM instructions/time. However, technical limitations may make this unrealistic, and it needs to be tested. One possible way to overcome collusion is to require super high collateral for some particular nodes against each other that that even discount factors very favorable to collusion would not incentivize collusion, even when accounting for repeated games. While this is not a part of anti-cheating mechanisms, collateral pooling could lower capital requirements for collateralization. High capital requirements are a second-order concern, but will become a higher priority once robust anti-cheating mechanisms are implemented. ## Taxes and Jackpots (inspiration from Truebit) Taking inspiration from the taxes and jackpots scheme used in Truebit, deals can be taxed, with those taxes going to a jackpot that is then used to reward nodes via some distribution protocol determined by the mediation process. For this, we want to be able to take any fraction of the jackpot(s) and distribute it arbitrarily to arbitary nodes (perhaps even those not involved in the mediation process). This is a particularly interesting approach because the taxation + jackpots mechanism inherently create a global game that impacts local outcomes. While it may lead to potential collusion attacks, the tool alone is very useful, especially in conjunction with some other the other methods mentioned here. Modeling it in simulation would also provide the opportunity to test some of the hypotheses in the Truebit paper. This method may also be useful in creating a robust platform where some clients do not care to check their results. That is, if some clients do not check results in general, it may be difficult to assert that the network is secure. Taxes and jackpots may be a way to address this. ## Prediction/Replication Markets Prediction markets have been well-studied in a variety of different fields. More recently, a type of prediction market called a replication market has been explored in the context of replicability in science. With this inspiration, it may be possible that allowing nodes to make bets regarding the replicability of the computations of nodes may be useful in mitigating cheating. For example, nodes with a low prediction for replicability may act as a signal for that node's reputation and encourage it to behave honestly. It is possible to overlay this mechanism on top of taxes, allowing nodes to choose where their taxes go in the prediction market. Additionally, since Automated Market Makers are closely related to prediction markets, we can leverage many DeFi tools in this context. ## Staking behind nodes Allow users to stake behind nodes. This is similar to prediction markets, but with slightly different economics. Like with prediction markets, it may be possible to tax users and then allow them to choose which nodes they stake behind. Overall, this approach is similar to delegated Proof-of-Stake. ## Announcing successful cheating Can a node announcing that it successfully cheated (and thereby receiving a reward) benefit the robustness of the protocol? How much would this node have to be rewarded? ## Frequency of checks How often should a client check results? Clearly it is related to the amount of collateral that the other node deposits, how much they value getting true/false results, reputation, and so on. This is a parameter that the client would need to learn to maximize its own utility. ## Reputation The ledger can maintain a record, for each compute node, of the number of jobs the compute node has completed, the number of times its results were checked, and the number of times those results were replicated successfully. All other nodes (client and compute) could locally run some arbitrary function over these numbers to determine how reputable they find that node. ## Storing Inputs/Outputs Results can only be replicated for as long as the inputs are stored somewhere. The client, compute node, or some other entity can pay for storing the inputs/outputs of jobs. The longer they are stored, the more time there is to check the results, which affects things like collateralization, the frequency of checks, etc. This is related to, but not totally overlaping with, the amount of time that a node might have to wait before getting paid, which is the same time interval that a client has to check a result. However, checking the result after the node gets paid and receives back its collateral may still be possible, with other penalty schemes (or reward schemes, for example, coming from jackpots). ## Anti-Collusion via Obfuscation Colluding requires the following knowledge in order to enforce the parameters of the collusion. 1. The public keys of the nodes participating in collusion. 2. The results that were posted by those public keys. 3. The payouts to the public keys. In order to sign a collusion contract to begin with, the public keys must be known. However, in a mediation protocol with enough nodes, it may be possible to obscure (2) and (3) by 1. Having nodes submit results to the mediation protocol in an obscured/anonymous way 2. Have nodes be paid out according to the results of the mediation protocol in an obscured/anonymous way If these two criteria can be met, then a mediation protocol based on them might be capable of imitating the game-theoretic outcomes seen in the Smart Contract Counter-Collusion paper. There have been many decades of cryptography and security research focusing on similar problems to these. It may be the case that it is already possible to do this; otherwise, there is a large amount of ongoing research on the topics of privacy-preserving transactions, and much prior work in the flavor of secret-sharing/MPC/Tor/Monero/ZKPs that could enable this. # Talks # FIL Dev Summit, Reykjavík, September 2023 {% embed url="" %} CoopHive: An Adversary First Approach to Game Theoretic Verifiable Computing {% endembed %} # CoD Summit, Boston, May 2023 {% embed url="" %} # Autonomous Agents # Valory Crypto x AI Mini Conference, July 2023 {% embed url="" %}