We have explored Automata’s onchain collateral management in Flashwares viii: dstack meets on-chain PCCS and ZK SNARK proofs of attestations as one of the best ways to manage collateral for TDX - TCBInfos, PCS and the like.
Managing the collateral in a transparent way is crucial to any project that aims to be auditable in any serious way – one trivial way to see that’s the case is to remind ourselves that Intel has removed TCBInfo entries from their centralized service (~19th-ish of September), which not only leads to inability to verify existing platforms, it also makes it impossible to verify previous attestations should have been verified successfully.
There seems to be an agreement in the web3 tee community that onchain management of collateral is the way to go - but there is still one last bit left: how do we agree on a single source of truth?
Why I think having a single source of truth is important is for two reasons:
If there’s duplication, it’ll be a security nightmare to keep all of the instances up to date, not to mention that there will be a significant cost to updating collateral data across all possible chains
we would have to individually integrate all possible chains, or risk fragmenting the community by having multiple disjoint features available on different chains (think light clients in TEEs)
Couple of requirements that come to mind for a unified onchain source of collateral:
Lightweight: fast to synchronize and with small resource requirements
Should work in any TEE (in particular SGX)
Truly distributed and based on web3 TEE community consensus
Censorship resistant
Not prohibitively expensive
Why I’m stressing the requirement for a lightweight solution, is that we will need to gather collateral in all kinds of settings - on end user’s machines, on tiny TEE instances - and we will need those collaterals to be readily available at a moment’s notice.
I come asking questions and I don’t have any answers. My intuition points me in two possible directions:
Use a light client friendly chain that we all agree will be good enough to use across all use cases that come to mind
Build a canonical TEE-based indexer specifically for collateral management on a chain we all know and love but is not very light client friendly
The above does not aim to improve on verifying attestations themselves, but rather only on the availability of collateral. For verification either offchain or Automata’s ZK proofs should be already a great solution, assuming we have a good source of collateral.
While I do think pushing for light clients on Ethereum mainnet is a good idea, and that Ethereum mainnet would be the best place to host this data – it doesn’t seem to likely happen in any acceptable timeline. Eth’s PoS is simply not very light client friendly
I think we need something that will work right now - and will work well enough for the next two years or so. I wouldn’t pick a chain that isn’t at least somewhat secure and decentralized.
Two ways forward that I see that could get us somewhere is:
Launch a chain purpose made for collateral management, say with permissionless validators but permissioned smart contract deployments
Launch collateral management on Ethereum, and provide access to those through a TEE-based client/indexer
Both have some downsides, but could work well enough maybe.
I agree, this is a single source of truth problem.
I’d prefer to have the source of the collateral agreed upon by consensus on mainchain. For any situation where it’s not expensive and doesn’t impose security implications, this collateral would be fetched.
At the same time, I don’t see why we should limit the collateral data being distributed both decentralized as well as centralized. This requires to have the consensus agree on the collateral, say every day, and sign it including a timestamp. It also requires the collateral receiver to be aware of the true current time, otherwise the receiver can be served with old collateral. And of course finally any attestation logic would need to have a way to verify the consensus signature hardcoded.
The data can then be distributed wherever you want, everybody agreed what’s the source of truth. If you’ve picked a data source that isn’t up to date, your attestations will fail, so you’d better get them up to date or decide to use a different data source.
We should seek to provide
a spec that describes how a collateral data endpoint should provide data
at least one easy and fast way to access the collateral data.
So basically regarding your concerns;
you won’t have security risks, because the consensus provides a timestamp and any proper attestation logic will fail if the collateral data it is looking at isn’t recent.
it’s the responsibility of the t-app developer to choose the right data source. We recommend mainchain if possible or our centralized service for convenience. If you’d rather want to use the data source from your favourite L2 or anywhere else, GL but keep it up to date!
I agree with having a single source of truth for TEE collateral. Given the security and neutrality the community may demand, Ethereum mainnet is a perfect place for that. A few thoughts from my side:
Light client: Although Ethereum is not light client friendly, an easy walk around mentioned by @mateusz is to simply run some full nodes in a TEE, so the RPC provided by the full node is credible enough to provide the latest block tip hash. It enables any client to verifiably fetch the collateral info.
I expect there will be some AVS to signal the right block tip as an alternative to the full light client.
It’s possible to put the full indexer of the collateral service into TEE. However, as we are going to rely on this group of TEE to serve collaterals, the service itself has to still rely on Intel to give out the collateral when bootstrapping. I’d not consider it a big problem because it’s more or less an one off job. Auditors can independently verify the deployment.
Governance of the revocation: Intel updates the TCB info periodically, but they are often slower than the release of the vulnerabilities. My impression is that, it’s pretty common that the affected TCB can be kept for months before Intel enforces the revocation of the TCB. In this case, a DAO managed revocation list would be very helpful. I know that the Automata team has expressed the willing to maintain it. If it can become a DAO, we (the Phala team) is also willing to join and contribute to it.
