Skip to main content

Registration of Executors

Executor registers on the Common Chain by specifying the following parameters:

  • The Enclave Key along with an attestation
  • The amount of stakes to be deposited
  • The compute capacity available in terms of number of jobs that can be executed in parallel
  • The address of the operator owning the executor
  • The execution environment identifier
  • The signature from the enclave, signing the compute capacity, owner address and execution environment, signed using the Enclave Key

Signatures generated with the Executor Enclave Key are used to verify the computations performed.

Execution Environments​

Lack of distinction between high-end and low-end setups can result in the selection of nodes that are either overly powerful and unnecessarily expensive, or too weak to complete the request within the required time. This impacts both the reliability of task completion and the competitiveness of nodes to operate efficiently in the marketplace.

Oyster achieves a clear distinction between high-end and low-end setups through the implementation of execution environments. This system categorizes nodes based on metrics such as computational power, storage capacity, network speed, runtime environments, and other relevant factors.

The implementation of this system involves two parts:

1. Registration

Execution environments are initially defined based on specific performance metrics. For instance, Tier 1 is designated for high-end setups with superior computational power and storage, Tier 2 for mid-range setups, and Tier 3 for low-end setups. During node registration, operators must submit their execution environment, validated and signed by the executor enclave itself.

2. Specifying the Setup

When users submit requests, they specify the execution environment they wish to use. This choice heavily depends on the code they want to execute and the machine requirements. By doing so, high-complexity jobs are directed toward high-end nodes, while low-complexity jobs are handled by lower-tier nodes. The pricing model is tier-based, with higher tiers incurring greater costs. Additionally, there are incentives for registering Executors in different environments when capacity approaches its limits.

Executor Draining​

Once an Executor's draining process is initiated by its owner, it will no longer be assigned any requests to execute. An Executor is deemed drained only when all assigned requests are either completed or slashed. The operator can either deregister the drained Executor or withdraw its stakes. This policy ensures that Executors always maintain deposits for potential slashing. Additionally, Executors can be revived after being drained and can resume participation in request assignments.