Preventing Replays with TEEs

[MuffinsThaCat]

I wrote an article: https://medium.com/@oraclethaacat/short-post-on-preventing-replays-with-tees-d9faa83ebba5

The key point highlights other design approaches which have built a light client in the enclave to ensure the TEE only executes the VM in a valid context corresponding to the actual blockchain state. The blockchain tells the enclave what to do. But take a look at the downside of this — for something that takes microseconds to do — it takes seconds to be told to do it(the full network round trip requiring the light client to get the state of the blockchain before it knows what to execute).

Paralleled with another approach of opportunistically executing transactions before they reach the entire network which could be much faster but can lead to rollbacks of state in cross-regional transactions(similar to traditional finance).

These discrepancies are handled by the blockchain using FIFO and rely on getting a "time proof" from multiple servers to get the earliest submitted proof.

[owenwahlgren]

interesting read! a few considerations:

• TEE attestation protocols need clear integration paths with time oracles
• Security model for time server selection requires careful design
• Performance impact of time verification needs benchmarking

Overall it is a compelling exploration of a critical challenge in blockchain infrastructure with a promising direction for future research.
The hybrid TEE-blockchain model is particularly intriguing for regulated use cases. Would love to see a proof of concept implementation on an Avalanche L1!