Privacy in the blockchain and crypto space has become a trending narrative in recent times, but its roots are not new. Conceptualized at Berkeley in 2018, Oasis emerged as a privacy-first L1 blockchain protocol with architectural and infrastructural choices that set it apart. https://oasis.net/blog/understand-oasis-network-technology

Separating consensus from the execution layer that achieves scalability with multiple parallel runtimes (paratimes)
Adopting the secure enclave mechanism of trusted execution environments (TEEs) to bring confidentiality

Over the past few years, Oasis has built and strengthened its tech stack to align with its vision for smart privacy in web3, and now, also in AI, which enables transparency where it matters and confidentiality where it counts.

Sapphire - first and only production-ready confidential EVM, which acts as the runtime on-chain logic
ROFL - runtime off-chain logic that scales confidential computation while providing confidentiality and verifiability on-chain

As a result, we can now have trust designed to include history, transparency, and continuous verification. But how does this all translate into user value?

There is no doubt that the crypto scene distinctly differs from blockchain's infrastructural identity. Here, user economy is defined by applicability and utility, not architecture. So, a directional shift in tandem with a continued core focus on privacy was needed, and Oasis has answered the call.

Every year, Oasis unveiled technical roadmaps and worked on developing the tech stack accordingly. This year, Oasis has decided to build something that highlights the utility of its own technology. This has also been reflected in the reimagining of the website - simplified and elegant.

As Oasis positions itself as the privacy layer for the next-gen web3 and AI, the first chapter of this new future is Privana - the one-stop solution for private DeFi. It enables automation with full self-custody and provides value through MEV-protected cross-chain swaps, confidential trades, and smart yields. This underlines Oasis's belief in its privacy infrastructure to deliver value with a consumer-facing application layer.

This new direction is not an isolated move. It runs parallel to Oasis, supporting old and new partners in their builds with its privacy engine. Since the close of last year and the first half of the new one, there have been several high-profile collaborations underlining Oasis's continual commitment to privacy.

What do you think of this new way that the Oasis vision and mission for privacy is unfolding? What other areas do you think Oasis can impact? Let's discuss in the comments.

Recently, I have been looking into one of the privacy-preserving techniques - trusted execution environments (TEEs), as a foundational solution for blockchain security. The viability of verifiable TEEs deserves a deeper dive than what some privacy advocates believe.

Zero-knowledge proofs (ZKPs) are arguably among the most popular privacy-preserving techniques, especially being favoured by Ethereum and other L2s. Earlier, TEEs received little traction, even as other techniques such as fully homomorphic encryption (FHE), secure multi-party computation (sMPC), federated learning (FL), etc, also gained prominence.

However, as the R&D shows, TEEs are beginning to get more serious attention and are becoming the optimal infrastructure for the privacy layer of next-gen web3 and AI.

Remote Attestation: Essential TEE Ingredient

TEEs are hardware-based secure enclaves that function as a black box for smart contracts. The data input and result output remain encrypted, and decryption and data processing happen only inside the TEEs - making it tamper-proof and inaccessible to even the node operator or application developer.

So, how integral is remote attestation for the verifiability? Short answer, extremely. Attestation in tandem with reproducible builds critically enhances the integrity and trust for TEEs, as this ensures that software built from the same source code always produces identical binaries.

Virtual machines (VMs) and cryptography are crucial components of the technology, and the simple fact is that protocols need remote attestation to mitigate vulnerabilities. What Oasis's Foundation Director, Jernej Kos, has to say in his technical analysis of the remote attestation process is a relevant starting point.

Why Attestation Is Still Not Enough

New research discusses what is beyond simple attestation. But before examining this stance, it is important to note what TEEs give. These are the facts, and they are undisputed.

Code runs privately, and off-chip states are fully encrypted. This ensures isolated execution.
CPUs have built-in cryptographic keys used for data encryption and the signing of attestation messages. This gives per-CPU root of trust.
Third parties get proof of a specific binary code running in a specific enclave. This is remote attestation.

Let's now examine why attestations still fall short of delivering complete trust.

What Attestation Actually Proves

How many of us are actual hardware security experts? Even then, verifying an SGX/TDX quote is a stiff challenge. Only those with domain knowledge will understand talks of parsing a multi-KB binary blob, extracting fields, fetching collateral, checking FMSPC, interpreting TCB status, validating cert chains, etc. As a result, the security model runs a high risk of collapse.

Even when someone successfully executes the whole process, the fact remains that the validation is true only for one moment, and not guaranteed for other times when the verification is not run. This means:

The measurement was correct then
The hardware Trusted Computing Base (TCB) was acceptable then
The quote presented by the operator was applicable then

https://preview.redd.it/j0zs2ceygvwg1.png?width=800&format=png&auto=webp&s=74a7795ac64008815a61b162b28fda94f4b64732

It is important to understand that the points noted in the image's right column are assumptions only. So, anyone who is checking is only getting raw attestation data feeds and a row of green checkmarks that do not prove verification is complete. The burden of proof simply rests on the user, and anyone who is not an expert would not know any different.

Plugging the Trust Gaps

A deep dive into TEEs that claim and pass as verified would reveal critical gaps.

Freshness & Liveness: A validated quote is not refreshed automatically. A new quote needs to be specifically invoked to replace the old, pre-verified one.
State Continuity & Anti-Rollback: Data needs to be ascertained as current for the attested code by anchoring the enclave to a live ledger. This prevents a malicious host from simulating live data by restarting an enclave and feeding old data that is no longer in an encrypted state.
TCB governance: Recent security exploits demonstrated that manufacturers might consider physical attacks (wiretapping, battering ram) out of scope while assessing threat models. This calls for newer, more stringent policies with continuous checks and additional on-chain measures to deal with outdated or insecure "trusted" CPUs.
Operator Binding: Attestation verifies what is running in the code, but there is no accountability for who is running that code. Binding the hardware’s cryptographic identity to a slashable, on-chain operator identity would make malicious acts economically untenable.
Upgrade history: A transparent history engenders data confidentiality. So, instead of only a current secure version, there needs to be a trackable record of valid attested versions, checking code continuity, bug fixes, etc.
Code Provenance: Reproducible builds are crucial as they ensure anyone can independently compile the code and verify that its hash matches the deployed version.
Policy enforcement: There needs to be clearly defined, unequivocal policies that are enforced to define what verified TEEs mean, covering all aspects of which binary should run, which hardware is acceptable, re-attestation frequency, approved locations, etc.

Consensus as Verifier

The architectural design of the TEEs requires sufficient infrastructure support to address the trust gaps. From what I understand, a Byzantine Fault Tolerance (BFT) attestation-verifier network is very handy in this respect. Here's my reasoning.

Ideally, every client should be parsing every code all the time, but that is not feasible. The BFT model directly addresses this, as the trust in the validity of attestation is established by the consensus of many. The process works like this:

Stake-bearing, slashable nodes submit enclave attestations and verification evidence.
A fault-tolerant set of validators collectively verifies hardware TCB, measurements, policies, freshness, etc.
Consensus agreement on verified identities, operators, and attestation policies becomes the on-chain state.

The USP? When anyone can verifiably query the on-chain state, attestations stop being static and complex and become usable on-chain signals.

Final words

Oasis is a prominent example of the type of BFT attestation-verifier network I have been talking about here. Although it is just one example, the principle applies to all who choose TEEs as the go-to privacy-preserving technique.

TEEs can be truly secure enclaves, countering untrusted environments with architectural resilience. What is simply needed is to move away from mere isolated black boxes and implement provable processes that ensure integrated, verifiable digital sanctums within larger trust systems.

u/DC600A