# Overheard at TEE Salon
Attestation allows us to verify that a Trusted Execution Environment is running on trusted hardware. Ergo, any computation performed within the secure enclave inherits properties of integrity and confidentiality secured by the TEE. In this post, we talk about:
- What exactly is verifying an attestation report
- A better interface for composable attestation verification
- How we already have a Web3-based TEE attestation framework today

# Bottlenecks so far

Currently, blockchain systems that deploy TEEs run into the same set of problems. Attestation is often thought of as a monolithic thing, which makes it hard to use. There is a shortfall in the documentation and work being done to build in the space not only around how TEEs can be applied to Web3, but in relation to TEE themselves. In our own experience building Automata DCAP v3, a Solidity verifier, we encountered the following problems:

- Customized logic tailored to specific workloads
- Each project having to deploy their own verification contracts
- Attestation collaterals not maintained in a distributed manner

# TEE attestation moves (entirely!) on-chain

The good news is that:

- Attestation verification can be composable
- Decentralized repository ease attestation overheads
- Solutions today are already live

To understand what exactly we did, let’s take a look at the anatomy of how what attestation looks like: verify(quote) -> bool
This forces us to perform all verification and validation in the same step, and requires us to have the collateral maintained in one place (mostly). Which places significant stress and constraints on how projects can work with TEEs. Therefore we need to understand what we mean by verifying the remote attestation:

1. Establishing the authenticity of the attestation report
2. Validating that the content specific to a particular workload

The attestation report has both information that proves the authenticity of the report and information about the workload (that it is valid). By extending the same logic, we can break the verification process down into two steps:

1. `verify(quote) -> verified_result`
2. `downstream(verified_result) -> bool`

Now we are now able to do far more interesting things. The overlapping constraints between both steps can be addressed by having the bulk of the attestation workflow be handled in the first step. Downstream users take it further by customizing the business logic based on their own needs.

In such a way attestation verification becomes composable:

`verifyAndAttest(quote)`

# ZK for attestation aggregation

Having broken down the attestation workflow, this flexibility allows for a far better interface and more intuition around the developer experience. But even with these advantages, attestation verification is still held back by the hefty costs of its on-chain environment.

That was a problem we set out to fix using ZK. By our own measurements, we spent about 3 million gas verifying a single DCAP quote. Using RISC Zero, we reduced that amount to 350K gas for a single quote verification. Which is great!

Therefore, we now expect the attestation workflow to look like:

`verifyAndAttestOnChain(quote)`
`verifyAndAttestFromZkProof(journal, seal)`
# On-chain PCCS to complete workflow

The DCAP attestation verification workflow for Intel SGX relies on the Provisioning Certification Caching Service (PCCS), which caches attestation collaterals for access. In its current state, each project has to configure their own caching service each time they run the attestation workflow. Quote generation and verification remains on the local platform, maintenance is a constant challenge, and the process is painfully inefficient.

Over time it was clear that we can afford to be more thoughtful about how we implement PCCS infrastructure.

We therefore made a decision to bring PCCS on-chain.

A decentralized repository means projects now have a common library where collaterals can be reused and stored on-chain for quote generation/verification. Going forward, we hope for on-chain PCCS to form a shared base for all projects when interacting with TEEs on attestation verification. On-chain PCCS is:

- Transparent; workflow is recorded and managed on-chain by smart contracts
- Collaborative; contributors can upload collaterals to update missing or expired ones
- Composable; Collaterals are reusable. Developers don’t have to reconfigure their tech stack for each single attestation/verification

*Many thanks to the Flashbots team for organizing TEE Salon and for the invite, even if intern wasn't actually invited.*