Auditing Mechanism

Enclave Setup

At the beginning of every Epoch, each Enclave generates a random seed $R_{T_i}$ internally which is not exposed to anyone until $a$ seconds after the end of the Epoch. The host machine on which the Enclave is running can query the random seed $R_{T_i}$ after $a$ seconds (SeedQueryBufferPeriod) of the end of the epoch, along with an attestation signed by the enclave. The host machine has to submit the random seed $R_{T_i}$ on-chain within $k$ seconds (SeedSubmissionPeriod) after it can be queried (that is, within $a+k$ seconds after the end of the epoch). If the host machine fails to submit the random seed $R_{T_i}$, the Enclave is considered to be offline and Tokens staked against the enclave are slashed.

Auditing Technique

During each Age, the auditor subset [$A_{T_i}$] assigned to the enclave $T_i$ for the corresponding Slot sends audit requests to the enclave $T_i$ to ensure its availability. The audit requests are sent through a secure channel that is established using a protocol such as TLS to ensure that host can't distinguish an audit request from a user request. The random seed $R_{T_i}$ is used by the enclave $T_i$ to generate a response to the audit request. It calculates a 1-bit response as follows:

$$keccak256(auditor\_address + AgeId + R_{T_i})/2^{255}$$

The above response by the enclave $T_i$ to the audit request is required to be submitted on-chain by the Auditor within $q$ seconds (AuditResponseSubmissionPeriod) of the end of the age to prove that the audit was actually done. If the enclave $T_i$ does not respond to the audit request, then it is considered to be offline and reported as such on-chain by the auditor. In case neither the response nor the offline status is reported on-chain by the auditor, then the auditor is assumed to be offline and the POND tokens staked are slashed for inactivity.