This point is very interesting, and to expand on it I think a multisig or TSS involving multiple enclave vendors could add an additional layer of security, arguably even 3FA.
Especially combined with this, I imagine it is significantly difficult or at least prohibitively expensive to attack multiple architectures and in the span of a single transaction.
There are attacks which can fake attestations of bad enclaves, so I don’t think key rotation alone would prevent those on a single architecture, but I’m not sure how easy it is to perform such attacks on multiple enclave architectures at once before one patches it.
This seems strictly better than a SNARK alone, especially with
I think in general for any use cases that focuses on integrity more than confidentiality, then the more alternate implementations, the better, because each implementation provides an additional check. N-of-N comprises are needed basically.
However, if only 1-of-N compromises are required (say in certain types of designs that focuses on confidentiality) where a single compromise would result in the secret leaking, then more might not be better.
Yep… I do think it will be tested in production reaaaal soon. I’m also interested to see what happens
BTW. We recently just released our block builder and the associated libraries…
ok… “reaaaaal soon” ™ turned out to be 4 months later. XD but its better late then never.
For some weird reason it seems like I can’t add links in the post… but you can find the post on X or our blog @ blog.ata.network
we have also opensourced the implementation of the sgx-prover. again, check out the blogpost for the link.
as for the sgx attestation verification, it is done on-chain.
While SGX 2FA can be removed, the question is how easy and practical its implementation is. Can this removal be done without additional security risks or significant complications?
I’m glad to see someone introduce the concept of “enclave” and consider a decentralized SGX to address the challenges.
Where can I see more research and specific plans?
Interested
We have registration-based SGX (i.e. we need to manually trust your prover) in Taiko testnet at the moment Katla Testnet (Alpha-6) is now live! — Taiko Labs and we’re working on decentralizing that process.
How do you address the potential community concerns regarding the reputation of SGX and its perceived weaknesses while promoting its integration as a pragmatic hedge for zk-rollup SNARK vulnerabilities?
