The trust model and cryptography

There are three main components to the overall trust model which are established to provide the privacy and veracity guarantees: verification of software which powers the nodes, verification of the application code (and configuration) which the nodes run on behalf of application developers, and verification of the identities of application end-users.

Verifiability of the network

The network is comprised of entirely of nodes running inside of trusted execution environments. Any application developer, or interested third-party, can run the build process for the node software and produce measurements that capture the full state of the application software, linux kernel, and RAMFS disk state. These measurements are used throughout the trust architecture to ensure that all parties can verify and audit the exact mechanisms of the network.

All communications channel with any node, whether from the application, or end-users - will always confirm these measurements match expectations through a process of remote attestation provided by the hardware infrastructure.

We also understand not all parties will have the expertise or resources to audit the software in it's entirety so any post 1.0 versions of the node software will be released alongside audits from established third-parties.

This cryptographic attestation process of the node software is also used to secure trust between each node. Nodes must prove to the existing network that they are running exactly the same code, in the same configuration, before they become data replicas or run computational workloads.

The architecture of the node software assumes everything external to itself (or a verified network peers) is untrustworthy - including its parent host and the operator of the infrastructure. This means all communication with outside services must be cryptographically secure based on a root of trust which is shipped as part of the auditable/verifiable codebase.

Verifiability of application code

The above process provides provability over the software of the nodes comprising the network - however, we now need a mechanism to ensure that the code supplied by application developers is equally verifiable. To accomplish this - the network performs the entire build process for any application code supplied by dApp developers inside the TEE. Network nodes will only execute code which it has either built itself - or build artefacts which have been code-signed by one of their verified peers.

The build target for this code is the WASM component model and Proven nodes provide virtualised capabilities to the guest code through WASIP2 interfaces. In addition - specialised components for interacting with encrypted storage, the messaging bus, and querying or submitting transactions to the Radix DLT are provided to the guest as components they can import and utilise within their application code.

To achieve full visibility and end-to-end trust - the Proven Network publicly hosts and makes available the complete build log and all inputs (IE source code). The configuration of messaging and storage (who owns/can access what) and which external services can be accessed (via an explicit capabilities based firewall) - are frozen into the build step. Private environment variables may be used (e.g. API keys) and their presence (but not contents) are also explicitly frozen into the auditable output.

Application developers can update the code and configuration or their apps as frequently as required - but this invalidates any existing end-user sessions. This ensures end-users always reconfirm that they trust the current version of the application, before changes can interact with any state keyed by their identity.

Verifiability of end-user identity

Secure verification of end-user identity is highly important inside the Proven Network as all identity-based access to [private] storage resources relies on this.

Unlike other confidential compute platforms - the Proven Network uses no independent notion of identity. Instead, we delegate identity completely to the native Radix DLT Persona system and use ROLA as part of our session-level cryptographic bindings between users and any application when users log in using the standard Radix Connect button.

This allows both the developer and user experience to be completely seamless, with no new exogenous private key material to safeguard.

If the current session signing key a user has for a particular application is lost - generating a new one is as simple as logging in with the Radix Connect button again. The proofs from the ROLA handshake, with the Proven Network, will grant access to the same private storage resources in the new session given the same Radix Persona is used.

Further documentation will be created - but the session creation process can be thought of as a 4-way binding between a user device-generated Ed25519 key, the proofs originated through their wallet by the ROLA process, remote attestation of the TEE environment, and the current version of the application code/configuration. This process is completely abstracted by our developer SDKs, but ensure a high-degree of trust between parties, with assurances no party can unilaterally "change the rules" in some manner not explicitly opted-into (with all information available.)