Proposal: remove the proxy altogether for transfers and MTCS

[hu55a1n1]

Summary

The contract-proxy-enclave design where devs are expected to write all 3 of these components (and ensure they're consistent) is error-prone and leads to bad devX. I propose we get rid of the proxy entirely (atleast for early versions of quartz) and instead move that logic into the enclave itself, such that the enclave talks directly with the smart contract.

Problem statement

Our main reason for the proxy AFAICT is to minimize the attack surface by preventing the enclave from making network calls. So we introduce a proxy bin (running on the host) that the enclave talks to (over files/gRPC) and the proxy connects to a blockchain node on the internet and facilitates communication between the enclave and the smart contract.

Why should the enclave and the smart contract communicate?

1. Handshake - the enclave and the contract must pair with each other such that the contract verifies the RA for the secret generated on the enclave and the enclave must verify a proof-of-publication of the public key.
2. Smart contract must be able to trigger execution on the enclave (this basically involves events)
3. Enclave must be able to query & obtain on-chain data for execution (with light client and merkle proofs)
4. Enclave must be able to submit the results of the execution to the contract with a proof of integrity (e.g. RA; EPID RA means we must make an additional network call to go from an enclave generated quote to a Intel attested report)

Why is this complicated?

The proxy must be app context aware so it cannot be a generic/universal bin that just works for all apps because it must know which events to listen to and what on-chain data to query (and how to get proofs for them).

Proposal

• Allow the enclave to talk directly to the smart contract so we no longer need the proxy.
• IIUC, the attack surface arguement doesn't apply because we're alreading checking a proof-of-publication/integrity ourselves, so it should be fine to let the enclave make network calls. (Is this correct? Are there other attacks that we should be concerned about?)
• We can always add the proxy in the future if we decide to. We can also implement the proxy generically as an abstraction of the networking layer/stack. (basically as a interceptor)
• This does however complicate the core logic (a bit) because the handshake must be handled inside of core quartz.
• Also, the enclave will now contain networking code that is not exactly business logic. But this also means that the RA attests to this code which is nice for audits and integrity proofs.

(cc: @ebuchman, @amiller)

[thanethomson]

I'd love for there to be one less major component to a Quartz app 🙂

@amiller, could you please help us understand if/why we'd really need the proxy in the first place? I also don't really understand the threat model that necessitated its introduction.

[thanethomson]

Looks like we've agreed to remove the proxy during Discourse today. What does "done" look like for this issue?

[hu55a1n1]

What does "done" look like for this issue?

I think this is done when we no longer have a listen.sh script (or quartz listen command). So we basically move all listen.sh logic into the enclave. This includes ->

• Listening for specific smart contract events over websockets
• Querying on-chain data with light-client/merkle proofs
• Submitting computation output directly to the smart contract (e.g. send transaction using wasmd)

A related improvement (optional, low prio future work) could be to move all handshake.sh logic into the enclave. This includes ->

• enclave starts handshake as soon as it is up and terminates if it fails to do so.
• so the flow would be ->

$ quartz deploy 
# deploys smart contract
$ quartz start 
# enclave runs
# enclave instantiates contract 
# enclave performs handshake

[davekaj]

Blocked by #70 as we want the listen script to be updated to DCAP, and we want to put that in the enclave (i.e. remove the proxy)

[dangush]

#174 waiting for review

[davekaj]

Closed by #174