Thanks everyone who participated in this discussion so far!
Beyond the Oracle solution Can presented, I’d like to present another solution that would likely work, and is most likely the optimal one.
First, touching on Can’s analysis - I started referring to this problem as the Extended Oracle Problem. The reasoning is - like with Oracles, we’re trying to move information from an untrusted source to a trusted one, in a verifiable way. Unlike Oracles in ‘classical’ blockchains, here the problem extends to on-chain data, which is usually trusted due to consensus.
This brings me to our solution. Intuitively, if a node’s enclave was aware of the chain’s consensus, it would be able to trust all contextual data coming from that chain (like block height, balance, etc…). This is the same argument why a given full node or even a light client trust blocks committed to the chain. Generally a light client puts a bit more trust in the network in that it only validates the easy stuff, but that is likely more than enough for our purposes. More formally, a node trusts the chain it’s seeing because of the following inductive argument around blocks:
Block height N=0 (genesis block):
- 2/3+ of genesis validators signed the genesis block data (genesis.json), which also included the initial distribution.
Assume we know/trust/verified the chain up to height N. Now for height N + 1
- Previous block is hash-linked to the current one (thus creating a sequential chain and preventing someone from proposing an arbitrary block with a different state)
- Current block is signed by 2/3+ of the validators (weighted by stake). We can trust the stake because we assume we know/trust the chain up to block height N
- All transactions in block N + 1 are valid (light clients don’t actually check this. This is fine).
A key point here is the chain of trust - everyone can start a new network with a new genesis.json and create many fake validators, but once a chain is up and has a current state/validator set, you will not accept just any block signed by anyone. It has to be proportional to 2/3+ of the stake as you know it. Based on this key insight, I believe that if we have a light client inside of the enclave, that starts from the beginning of the chain and continues to maintain a sealed state of the chain, then any data coming from the outside could be verified inside of the enclave before proceeding. This should therefore allow us to trust block height (time), balances, and other aspects inside of the enclave.
The one downside is that this solution is likely extremely complicated to develop, and needs to be carefully analyzed for correctness (both theoretically and from an implementation perspective). In practice, Oracles might be an easier way to go.