Monitoring Protocol

The monitoring protocol governs the fault tolerance guarantees of Oyster Isolated Instances.

At a high level, a network of Auditors participate in the Isolated Instance protocol. Time is divided into Epochs $E$ of length $L_e$ with each Epoch further divided into $n$ Slots of length $e$ and each Slot into $m$ Ages of length $p$.

Hence,

$L_e = n * e, where$ $e = m * p$

SlotId for a slot number $s$ of epoch $E_i$ is calculated as

$SlotId = i * n + s$

AgeId for an age number $a$ of slot with id $SlotId$ is calculated as

$AgeId = SlotId * m + a$

Auditor Assignment & Auditing Mechanism

A random seed $R_{E_i}$ is generated every Epoch based on which Auditors are assigned Jobs they are required to audit for any given Slot. Separately, enclaves also generate a random seed $R_{T_i}$ at the start of every Epoch which they don't reveal until the end of the Epoch. In order to audit, Auditors send requests every Age to enclaves they are assigned for the corresponding Slot. The response is a function of $R_{T_i}$ and the enclaves are expected to respond back to Auditors along with an attestation within a prescribed time.

Data Submission

Auditors are required to submit the responses (after verifying the attestation but not submitting the attestation itself) sent by enclaves on-chain or report those that didn't respond (atleast with a valid attestaion). Similarly, the machine hosting the enclave is also required to query $R_{T_i}$ and post it on-chain along with an enclave attestation after the end of the epoch. TEE properties prevent $R_{T_i}$ from being leaked earlier preventing the Operator and Auditor from colluding and not fulfilling their duties. Failure on part of either the Auditor or Instance to post the required the data is a slashable event.

Response Verification

As the enclave responses are based on $R_{T_i}$ which is available and correct (as its attestation is verified on-chain), it can be verified whether the enclave responses submitted by the Auditors are correct. If any response is pointed out to be incorrect, the corresponding Auditor is slashed for not having verified the attestation accompanying the response or having sent a random response (and not actually performed the audit). The Auditor is thus subject to slashing if a submitted audit response is found out to be invalid.

Slashing Action

Finally, if a majority of Auditors are found to have reported any enclave to have been unavailable in any Age, the Operators are subject to slashing.