How
A tech-centric overview of Seismic
Last updated
A tech-centric overview of Seismic
Last updated
We've restructured the modern blockchain stack around secure hardware. The major components are as follows:
At the core of this stack is the secure enclave. The term describes a set of hardware components that provide confidentiality measures over data in use, protecting it from being read by any outside entity, including the host machine. Our secure enclave of choice is Intel TDX.
Our system uses TDX by cloning all the primary memory segments of the EVM. This results in a set of encrypted segments and a set of transparent segments, where the former can leverage the confidentiality properties of the underlying hardware.
Data flows between these segments with cloned storage opcodes. For example, the vanilla EVM has SLOAD / SSTORE to manage elements in storage, and our EVM adds CLOAD / CSTORE to manage elements in encrypted storage. The same pattern is applied to calldata, transient storage, and memory.
These segments allow us to know whether every element added to the stack is considered transparent or encrypted. Then it becomes a matter of tracking these elements to enforce rules over how they interact and how they should be handled by the execution loop.
Our github repositories hold the v0 implementation for this. Like every v0, it's a far cry from the final spec. Notably, the current implementation only clones the storage segment and does not keep track of element status in the stack. It compensates by treating all memory segments as encrypted. This heavy handed approach has major drawbacks in both UX and liveness. However, it's enough to test our core hypothesis around encrypting protocols while decreasing our time to market, which makes it a great fit for our first release.
We believe these enclaves are sufficient to support entire blockchain ecosystems. And with the current momentum behind confidential compute, we expect the rate of improvement only increases from here.
The language is a fork of . We added stype.
The execution client is a fork of , , and . We added encrypted storage and relevant opcodes.
The consensus middleware is . We used it off-the-shelf.
The consensus client is . We used it off-the-shelf.
The secure hardware build is a fork of manifests from flashbots. We added proxies.
The testing framework is a fork of . We added encrypted storage, along with the relevant opcodes.
The wallet client is an extension of . We added transaction types.
Notice, 99% of our stack is code written by the OS community. We're making sure to maintain this standard, which is why are fully open-source under an MIT License.
Our dependency on secure enclaves comes with strong trust assumptions. The most prominent one is on hardware confidentiality, which leaves us wary of . Our short-term mitigation for this is the restriction to cloud-based validators.
Though this assumption has led to in the past, we're cautiously optimistic about the most recent generation of VM-based enclaves like Intel's TDX and AMD's SEV-SNP. They function with an untrusted hypervisor and patch up major flaws present in the first generation.
