Scheduler scheduling execution of sgx / confidential contracts

[willscott]

Right now, we have the notion of a single committee.

As we get confidential contracts, we'll need another pass at the scheduler, either to have a second 'parallel sgx chain', or to allow each individual sgx runtime / contract to get scheduled to a node.

[kostko]

I think the current plan is for thr confidential runtime to just register as a different runtime. Since the scheduler and roothash support multiple runtimes, things shoulf just work as long as we keep these separate.

[willscott]

Once we have multiple enclaves / contracts, it would be great to start thinking about how we imagine that will work

[kostko]

As discussed in the current core confidentiality RFC the plan is:

• Two runtimes registered with the registry: confidential and non-confidential.
• Each runtime has a distinct "runtime-id".
• Each runtime has a distinct compute committee (some compute nodes only run the confidential runtime, some only run the non-confidential runtime as we currently don't support multiple runtimes per worker).
• Each runtime has distinct roothash state.

Everything we need for this should already be supported (minus the TEE work which is part of #979), we may need to debug some issues as we haven't really tested with such configuration (see #1062 for adding E2E tests with multiple runtimes).

[kostko]

Oh and for gateways - we likely need to run two gateways as these are completely distinct chains.

[willscott]

I guess i'm also interested in how we go from this first pass at supporting sgx to a merged chain. Having a sense of how we hope to do that will make it easier to decide whether to have the next version of web3c built in a way that expects being back at a merged gateway or not.

[ryscheng-mobile]

Potential dup - rfc for core confidentiality addresses some of this already

[kostko]

Note that the Core Confidentiality RFC assumes completely separate chains (roothash states) due to the discussion that we had in the RFC.