Skip to main content

Registration of the Matching Engine

Anyone can run the Matching Engine as an enclave inside an Oyster Node.

  1. The Kalypso Smart Contract admin first whitelists the enclave image built from a desirable codebase. Everytime the Matching Engine’s logic (which includes the Matching Protocol) is to be updated, the whitelisted image is also updated to enforce the new logic.
  2. Once someone rents an Oyster Node and loads the whitelisted enclave image of the Matching Engine, it registers on-chain by providing an enclave attestation along with its public key (hereafter referred to as the Matching Engine’s public key).
  3. If the whitelisted image is updated or if the Oyster Node running the Matching Engine stops working, a new enclave can register by providing an attestation and updating the public key.

At the moment, there can only be 1 node operating the Matching Engine at any given moment. Redundant nodes preserve the Matching Engine’s private key to tackle scenarios like node failures and logic upgrades. This is important to make sure Requests with encrypted private inputs can be matched and processed by Generators. In the future, once scaling becomes a bottleneck, the architecture can be updated to allow for multiple Matching Engines to coexist.