Skip to main content

Provisioning an instance

Provider registration

The steps to register as a Provider are as follows:

  1. Providers determine the Instance Type of Instances they would like to offer on the Oyster Isolated Instance marketplace and the price (per second) they would like to charge for it.
  2. They feed in those details on the IsolatedInstanceRegistry contract by making a smart contract transaction.
  3. In order to successfully register, Providers are required to stake atleast StakePerJob POND tokens.

User request

The steps for a User to request an Instance is as follows:

  1. Users mention the Instance Type of Instances they would like to rent and the maximum price they are willing to pay for it.
  2. They add funds to an Escrow wallet as part of the transaction. The Escrow wallet is Job specific.
  3. Users have to specify the enclave url from which the provider can download the enclave image. The enclave image contains the application that’s to be run on the Instance along with auxiliary code. The url should always be reachable for Providers in order to start the enclave. It should thus be hosted on IPFS or a similar service.

Matching Users with Providers

Users are then matched with Providers in accordance with the following steps:

  1. The matching engine determines the Provider quoting the lowest price with atleast StakePerJob unlocked stake that has registered to provide an instance of the same type.
  2. Stake capacity of the chosen provider is locked by the StakePerJob amount to ensure that it can be slashed if the Provider misbehaves with the matched User and can’t overcommit (or double spend slashable stake) with multiple Users.
  3. Each such matched request for an Instance between a User and a Provider is considered a Job and is registered on the smart contract.

Post-matching

Once a Job has been created, Providers are expected to provision the instance for the User within the JobBootstrapping period. After the JobStartup period, Providers are subject to the monitoring protocol to ensure that they adhere to the protocol’s guarantees. Providers may be slashed and their Jobs reassigned to other Providers based on feedback received from Auditors.

Stopping a Job

A Job remains active and Providers are expected to keep providing the Instance to the User until the Escrow for the Job runs out of funds, the User sends a RequestToStopJob instruction, or the end of JobExitCoolDown period following the Provider’s RequestToExitJob instruction.

Reassigning a Job

If a Provider is slashed, the matching protocol between Users and Providers is re-executed while excluding the previously slashed Provider for the Job.