2FA zk-rollups using SGX

[nanaknihal]

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.

@JustinDrake

• flexibility: Enclaves from non-Intel vendors (e.g. AMD SEV) can replace or be used in parallel to SGX enclaves.

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.

@pepesza

Consider rotating the keypair with every attestation. Add pubkey of the new keypair to the tuple signed on every attestation: (pre_state_root, post_state_root, block_root, new_pubkey). Smart contract will update 2FA key with new_pubkey.

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

• enclaves from multiple vendors in a multisig
• rotating keys every transaction

[chuazl]

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.

[Jommi]

This thinking is probably going to be tested in production real soon. Interesting to see what happens!

Why multi-prover matters. SGX as a possible solution.

[chuazl]

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…