v0.2 concept (**DO NOT MERGE**)

[hu55a1n1]

Summary

This is a complete redesign of the enclave code. The idea is to merge parts of this new design (that we're happy with) separately in smaller PRs.

Design goals

• Make it easier to implement app enclaves.
• Be generic and flexible but provide sane default types where possible.
• Make assumptions to ease DevX but allow devs to customize if required - e.g. assume 1 request per handler and 1 event per request.
• Extract reusable code into the framework.

Design

• Clearly define untrusted/secure parts of the code. (Host v/s enclave separation - code such as websocket event listening, tx sending, etc. need not happen in enclave.)
• Idiomatic rust - use towers of abstraction, dependency injection, and well-known patterns where possible.
• Handlers are defined as async trait impls and are agnostic to underlying transport/protocol.
• Event handler v/s request handler distinction. (i.e. request handlers implement actual business logic and event handlers implement logic to create a request from/upon an event).
• Abstract away protocol-level logic such as sequence number consistency check, etc.

System component diagram

flowchart LR
    %% ------------------------
    %% MAIN DIAGRAM STRUCTURE
    %% ------------------------
    subgraph "TEE machine"
        subgraph "Host (untrusted)"
            H["Host (implements trait Host)"]
            Evt["Event handlers (implement Handler<ChainClient>)"]
            CC["ChainClient (implements trait ChainClient)"]
            GRPC["gRPC"]
        end

        subgraph "Enclave (secure)"
            En["Enclave (implements trait Enclave)"]
            KM["KeyManager (implements trait KeyManager)"]

            R["Request handlers (implement Handler<Enclave>)"]

            subgraph "Storage"
                TS["TypedStore<K> (extends KvStore<K, V>)"]
                S["Storage backend (e.g. InMemory, ORAM, File, etc.)"]
            end

            subgraph "Attestation"
                Att["Attestor (implements trait Attestor)"]
                G["Gramine (Intel SGX libs)"]
            end
        end
    end

    subgraph "Web"
        BC["Blockchain"]
        U["User"]
    end

    %% ------------------------
    %% CONNECTIONS
    %% ------------------------
    U --> GRPC
    H --> Evt
    H --> R
    H <-->|"serve(url)/listen(events)"| BC
    CC -->|"query(...)"| BC
    CC -->|"send_tx(...)"| BC
    GRPC --> R
    En --> Att
    En --> KM
    En --> TS
    R --> En
    Evt --> CC
    Att -->|"quote/mr_enclave"| G
    TS -->|"set/get/delete"| S

    %% ------------------------
    %% STYLE CLASSES
    %% ------------------------
    classDef untrusted fill:#ffe6e6,stroke:#c43b3b,stroke-width:1px,color:#4d4d4d
    classDef secure fill:#e6ffe6,stroke:#3bc43b,stroke-width:1px,color:#4d4d4d
    classDef web fill:#e6f2ff,stroke:#3b7dc4,stroke-width:1px,color:#4d4d4d
    classDef special fill:#fff5e6,stroke:#c49b3b,stroke-width:1px,color:#4d4d4d
    classDef store fill:#f9e6ff,stroke:#a73bc4,stroke-width:1px,color:#4d4d4d

    %% ------------------------
    %% APPLY CLASSES
    %% ------------------------
    class H,Evt,CC,GRPC untrusted
    class En,KM,R secure
    class BC,U web
    class Att,G special
    class TS,S store

Loading

Deployment workflow

• start enclave
• enclave deploys contract (maybe embed contract wasm bin in enclave at build time?)
  • So only one enclave is tied to a contract
  • Also the enclave no longer needs to listen for gRPC instantiate req
• enclave listens for events
• all on-chain message handlers (including core ones) must emit events
• events are the primary form of interaction from contract to enclave

Lifecycle of a msg

• user sends msg to contract
• contract triggers event
• event picked up by enclave host
• host constructs enclave request
• host calls enclave with request
• enclave handles request and returns response to host
• host send response to chain

gRPC and tonic stuff is really not required

• app doesn’t need it at all
• core can also just use the ws framework
• instantiate msg is a special case because it’s sent directly to the enclave but we can get around this by having the enclave itself deploy/instantiate the contract

App dev only needs to specify two things

• Which events are they interested in and how to put together all relevant data provably (i.e. the host)
• Which requests do each of those events trigger and handlers for them (i.e. the enclave code)
• queue semantics to automate more stuff in the future