The auditing mechanism works as follows: after the client accepts the result from the slave, and given that the client decides not to double-check that result, it still forwards the slave's ``pledge'' packet to the special auditor server.
The auditor is the only trusted server that does not have a slave
set, and therefore does not handle any double-checking requests
from clients; its only duty is to check the validity of
``pledge'' packets, by re-executing the read request in the
packet and comparing the secure hash of the result to the hash in
the packet. The auditor is allowed to lag behind when executing
write requests; it executes a write only after it has audited all
the read requests for the
that precedes that
write. In fact, in order to take into account possible network
delays, the auditor can move to a new
only
after a sufficiently large time interval (more than
)
has elapsed since the rest of the trusted servers
have moved to that same
.
This ensures that
at that point no client will accept any more read results for the
previous
.
Here we assume clients accept
read results only after they have forwarded the corresponding
pledges to the auditor.
The auditor has several advantages over the slaves it has to verify, which allow it to achieve a much higher throughput when (re)executing read operations: first the auditor does not have to produce digital signatures (slaves on the other hand have to digitally sign a ``pledge'' packet for every client request they execute). Second, the auditor does not have to send any answers back to the clients. Third, since the auditor knows in advance all the operations it has to re-execute, it can, for certain types of applications (for example databases), employ query optimization mechanisms (cache results in the simplest case). Finally, because the auditor needs not to worry about client latency, it can spread its work so it minimizes idle time. Assuming that read requests show daily peak patterns (few requests at 3AM in the night for example), it is possible that the auditor will seriously lag behind during peak hours, but catch up during the night. However, it is essential that in the long run the auditor is able to keep up with the amount of reads it has to verify. If the auditor is over-used, the solution is to either add extra auditors, or weaken the security guarantees by verifying only a randomly chosen fraction of all reads.