How
A tech-centric overview of Seismic
An open-source stack
We're restructuring the modern blockchain stack around secure hardware. The major components are as follows:
The language is a fork of solidity. We added
stype.The consensus middleware is omni. We used it off-the-shelf.
The consensus client is cometbft. We used it off-the-shelf.
The secure hardware build is a fork of yocto manifests from flashbots. We added proxies.
The testing framework is a fork of foundry. We added encrypted storage, along with the relevant opcodes.
The wallet client is an extension of viem. 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 all of our repositories are fully open-source under an MIT License.
Built around secure enclaves
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.
With these trust assumptions
Our dependency on secure enclaves comes with strong trust assumptions. The most prominent one is on hardware confidentiality, which leaves us wary of side-channel attacks. Our short-term mitigation for this is the restriction to cloud-based validators.
Though this assumption has led to many issues 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.
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.
Last updated