feat(protocol): support SGX proofs

[adaki2004]

First PoC - basically verifier does not do attestation verification on-chain - just a signature check.

A set of initial ( addToRegistry() ) trusted enclaves identified uniquely by their (initial) ECDSA public key can sign data.

In our case exactly this:

return keccak256(
            abi.encode(
                evidence.metaHash,
                evidence.parentHash,
                evidence.blockHash,
                evidence.signalRoot,
                evidence.graffiti,
                assignedProver,
                newPubKey
            )
        );

Once public key is used by an enclave another has to be used next time.

Let me know if this is what we discussed or not.

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
bridge-ui-v2-a5	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Oct 17, 2023 6:11am
taiko-mono-bridge-ui-grimsvotn	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Oct 17, 2023 6:11am
website	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Oct 17, 2023 6:11am

2 Ignored Deployments

Name	Status	Preview	Comments	Updated (UTC)
bridge-ui-v2-internal	⬜️ Ignored (Inspect)	Visit Preview		Oct 17, 2023 6:11am
geth-diff	⬜️ Ignored (Inspect)	Visit Preview		Oct 17, 2023 6:11am

[codecov]

Codecov Report

❗ No coverage uploaded for pull request base (improve_bridge_cide@e329280). Click here to learn what that means.
The diff coverage is n/a.

❗ Current head 16b336d differs from pull request most recent head 111d47e. Consider uploading reports for the commit 111d47e to get more accurate results

@@                  Coverage Diff                   @@
##             improve_bridge_cide   #14851   +/-   ##
======================================================
  Coverage                       ?   39.80%           
======================================================
  Files                          ?      113           
  Lines                          ?     5283           
  Branches                       ?      113           
======================================================
  Hits                           ?     2103           
  Misses                         ?     3044           
  Partials                       ?      136           

Flag	Coverage Δ		*Carryforward flag
bridge-ui	93.94% <0.00%> (?)		Carriedforward from 29bfd96
eventindexer	19.36% <0.00%> (?)
relayer	42.86% <0.00%> (?)

*This pull request uses carry forward flags. Click here to find out more.

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

[Brechtpd]

Looks good! Just some refactoring suggestions.

[dantaik]

I need to learn more about SGX, but it seems no public keys are associated with those from Intel.

[Brechtpd]

I need to learn more about SGX, but it seems no public keys are associated with those from Intel.

The public/private keys are generated inside the SGX program and so we have full flexibility of what what we can use to verify proofs, after verifying the attestation that the program is running safely.

[dantaik]

In cases of bug fixes then everything is transparent except for provers who will need to update their software which will contain the necessary information I'd assume. In case of hard forks the block ranges will be part of the node. I don't think there's a difference between the different prover types (zk, SGX) of how versions will be handled. zk has the verification keys, SGX currently has the "bootstrap nodes", or when we can verify the attestations onchain that will define the version for the SGX verifier.

If I understand correctly, the ZK keys which can be calculated from the circuit codebase, but the SGX "bootstrap nodes" setup cannot be verified and has to be trusted. If there is also an image ID that can be verified by using the guest program such as zeth, then the solution is more trustworthy. But I guess it is hard to achieve?

[Brechtpd]

They are pretty similar in that to verify the verification keys in the zk verifier contract, you would indeed have to verify the code and regenerate the same verification keys and check if they match the ones in the smart contract. Registering those verification keys is itself a trusted process, because the smart contract cannot verify if those keys are correct. But it is verifiable.

With SGX you would have to check the source code, and then generate the MRENCLAVE value which is the hash of the program being run, and then verify the that the remote attestation published for the bootstrap node matches the expected MRENCLAVE. The trusted process here is that those bootstrap nodes are being registered to the smart contract without the smart contract verifying that they are indeed running the correct program. But as long as the remote attestations of those bootstrap nodes are made available offchain, anybody can verify them so it's exactly the same as with the zk verifier.

The only benefit of being able to verify the remote attestations onchain is that there is no dependency on those bootstrap nodes, so it's potentially more decentralized because those bootstrap nodes may refuse verifying other SGX instances or they may go offline. But even with onchain remote attestation verification, setting the expected MRENCLAVE for the smart contract verifying the remote attestation verification would be a trusted step, so nothing really changes to the security or the trustlessness of the process. Both approaches are as verifiable and as trustless as the other, and are the same here as for the zk verifier.

[dantaik]

They are pretty similar in that to verify the verification keys in the zk verifier contract, you would indeed have to verify the code and regenerate the same verification keys and check if they match the ones in the smart contract. Registering those verification keys is itself a trusted process, because the smart contract cannot verify if those keys are correct. But it is verifiable.

With SGX you would have to check the source code, and then generate the MRENCLAVE value which is the hash of the program being run, and then verify the that the remote attestation published for the bootstrap node matches the expected MRENCLAVE. The trusted process here is that those bootstrap nodes are being registered to the smart contract without the smart contract verifying that they are indeed running the correct program. But as long as the remote attestations of those bootstrap nodes are made available offchain, anybody can verify them so it's exactly the same as with the zk verifier.

The only benefit of being able to verify the remote attestations onchain is that there is no dependency on those bootstrap nodes, so it's potentially more decentralized because those bootstrap nodes may refuse verifying other SGX instances or they may go offline. But even with onchain remote attestation verification, setting the expected MRENCLAVE for the smart contract verifying the remote attestation verification would be a trusted step, so nothing really changes to the security or the trustlessness of the process. Both approaches are as verifiable and as trustless as the other, and are the same here as for the zk verifier.

I think a trusted set up of MRENCLAVE is acceptable as long as it is verifiable by third parties. Is it possible to achieve this without onchain remote attestation verification?

[Brechtpd]

Yes, because onchain remote attestation verification does not make any difference.

1. MRENCLAVE: hash of code/data that is run in SGX
2. Remote attestation: Verifies that the SGX instance is running the MRENCLAVE program correctly in SGX
3. We bind the SGX instance to an initial public key

No need for any trusted setup or onchain remote attestation verification, it is as trustless as registering the verification keys for the zk circuits (ignoring the trust in intel of course).