To establish the hardware-level root of trust, we accept industry-proven technologies such as TPM chips, Amazon Nitro, or Intel SGX, with the requirement that they could respond to remote attestation of their integrity.
The following table lists the major enclave technologies and service providers.
|TEA Support||Technology||RoT Verification||Available for Rent as IaaS|
|Google Cloud/Azure Confidential Computing||On Roadmap||CPU based (AMD/Intel)||Centralized by cloud provider||Y|
|Secure enclave, e.g. SGX/SEV/TrustZone||On Roadmap||CPU based||Centralized by CPU manufacturer||N|
|Amazon Nitro||Completed||CPU based||Centralized by cloud provider||Y|
|Trusted Computing based on TPM||Software simulator completed||TPM based||Decentralized||N|
As of Nov. 2020, the TEA Project has completed the simulator of TCG2.0 compatible TPM. We completed the integration of Amazon Nitro into the TEA platform in Q2 of 2021. With Amazon Nitro being fully supported by the TEA network, miners do not need to build their own TEA Box (a mining machine powered by a TPM chip). They can simply rent an Amazon EC2 instance with Nitro support to start mining. Nitro is likely our first type of production-ready TEA node. After that, we will release a technical reference of TEA Box so that anyone can build their own or buy manufactured mining machines at a very low cost (our testing prototype cost less than $100).
In the TEA network, each trusted computing node has a root of trust (e.g. a key pair generated by the TPM manufacturer). The private key for this root of trust is held inside the hardware, and not known to anyone, including the manufacturer. The public key is disclosed and recorded on the blockchain. Periodically, the blockchain will run remote attestation by requesting a computational node to generate its hardware fingerprint and fingerprint of all the software modules running in the node, which need to be signed by the TPM’s private key before it is returned as the response to the attestation. Each attesting node would verify the signature and the PoT that have been returned. The results from all attesting nodes will run through the blockchain's consensus protocol before a final decision is made on whether the computing node still meets all the security requirements in order for it to remain on the network, and then record the results of the attestation on the blockchain. The diagram below shows the remote attestation process.
The different layers of software running in the computational node generate their own secrets, one after another, each using the parent layer’s key pairs so that all of them can pass cryptographic verifications. All the proofs chain up one after another to form the trust chain. The root of the chain is the hardware RoT. Because the public key of the RoT is stored in the blockchain publicly, anyone can easily verify any derived secrets by tracking back the chain-of-trust, and eventually verify the RoT using data recorded on the blockchain.
The blockchain in TEA is developed using Substrate. As explained before, we do not run our clients’ dApps directly on the blockchain. Instead, we only run Proof-of-Trust consensus on our layer 1 blockchain while dApps run inside the layer 2 TEA-runtime, i.e. the computational nodes. The PoT verifies the trustworthiness of every TEA-runtime to make sure all client tasks will run inside a qualified enclave.
This blockchain uses the GRANDPA consensus protocol, the same as what is used for the Polkadot Relay Chain.
GRANDPA is a probabilistic, asynchronous BFT protocol for blockchains. It's the first proof-of-concept of an asynchronous Byzantine Fault Tolerance (aBFT) consensus mechanism without randomization. Although not as efficient as some other protocols, it has several desirable features that make it worth considering. It supports a wide range of block frequency (from once every few hours to more than one block per second).
Because GRANDPA achieves consensus using asynchronous BFT rather than deterministic BFT, messages can be received by all nodes before they commit; as such, any number of messages can be re-sent by any node in the network, and all nodes can recover from message loss. In essence, it is a practical Byzantine fault tolerant consensus mechanism for asynchronous networks.
The consensus protocol uses VRF to select random Remote Attestation nodes (RA) to challenge the testee for attestation materials signed by hardware. If the majority (⅔) of RA nodes get a positive result from verifying the attestation material (positive means passing the verification), the consensus will mark this testee as “good to use.” Because only approved “good to use” nodes can be selected as RA nodes, as long as we can already have assurance that more than ⅔ TEA nodes are honest, we could trust the consensus result. To keep the ⅔ threshold, we need to bootstrap the network with clean nodes and control the birth rate of new nodes.
The blockchain is also used to store the essential trust data such as certifications and public keys, so that immutable records of such important information can be maintained securely and always be available for verification.
The TEA solution stack consists of the following components:
The TEA blockchain that is developed using Substrate from Parity. Currently, it generates a new block every six seconds, and uses the GRANDPA consensus protocol.
Hardware-based trusted computing environment, which can TPM-based as defined by the TCG2.0 specification, Amazon Nitro, and Inter SGX, etc.
TEA’s data storage uses IPFS/libp2p to form a peer-to-peer network. Because IPFS is publicly accessible, storing data on IPFS means everyone can access it as long as the content identifier (CID) is known. In order to protect the data, everything TEA stores in IPFS needs to be encrypted. The encryption key will never be stored in IPFS or any persistent media. It stays in the memory of the TEA modules.
TEA’s runtime environment is WebAssembly (wasm) that is specially configured to run inside a secure enclave. It is heavily inspired by and forked from the WaSCC framework by Kevin Hoffman.
The following diagram depicts TEA’s solution stack.
The TEA ecosystem uses a layer-1 blockchain to provide proof of trust, which requires traditional blockchain consensus. The actual computation tasks are carried out by layer-2 components that use hardware-based root-of-trust to achieve efficient trusted computing. Once computation is completed, layer-2 would trigger an oracle which in turn would trigger a smart contract on the layer-1 blockchain to execute in order to take care of the book-keeping and payments.
From another perspective, the TEA platform provides trust as a service for both blockchain and non-blockchain solutions, so that computation tasks can be delegated to nodes whose trustworthiness is attested and recorded on the TEA blockchain. TEA can provide both the proof-of-trust and the actual computation nodes. In addition, TEA can serve as a third-party to provide proof-of-trust, so that an organization that provides computing service to internal and external clients can provide proof that the computing tasks were run in secure environments, as evidenced by the remote attestations that are recorded on TEA’s layer-1 blockchain. The following diagram depicts how TEA can act as a provider of trust-as-a-service to multiple blockchains.
Like the Bitcoin network, the security of the TEA network is accomplished by both technologies and by economics.
Technology wise, similar to the chain-of-trust model in a public key infrastructure (PKI), the TEA network uses a chain of trust that is rooted in the secure hardware, and goes all the way to the top-level software involved in the execution of rich dApps. Any discrepancy in the trust chain would cause the computing node to be disqualified for running a task.
To protect against cyberattacks on individual nodes, we want to minimize the attack surface of each computing node on the network. We require that
Economics wise, the use of a blockchain to record trust information of computation nodes and the use of VRF to randomly select which node will lead the execution of a client’s computation job ensures that it would be very costly to attach the TEA network. We use token incentives to encourage a large number of participants to either run a node themselves, or stake their tokens with trusted nodes. The token staking mechanism would use economics to re-enforce well-behaving nodes. The expiration of the NFT associated with a node should mitigate the risk of a small number of nodes always staying on top of the “preferred nodes” list, and provide opportunities for new participants to join the network. This is similar to the “rotation of duties” principle in many organizations to protect against malicious participants.
TEA has two tokens. TEA and Camellia (CML).
TEA: the ticker of this token can be shortened as $T. It is a utility token. It is used by the network to pay miners, and by clients to pay for running their tasks (similar to gas in the Ethereum network). $T is a stable token pegged to the measurable computing resources such as CPU instructions, RAM size, network traffic, storage, etc. One of the advantages of $T is that it offers a stability in ways different than other asset classes. People often associate this word with immunity to market speculation and volatility, but when you think of stability more broadly there are many forms; one being stable on compute power and resource economy.
Camellia：this is a non-fungible token (NFT), so each CML is unique. Miners must purchase CML to “activate” their TEA node in order for the node to be eligible to run customers’ tasks and earn $T. Each CML token is used to record the credit score and profitability of the associated node. It is also used to record the type of computing node it is used to activate. Participants in the TEA ecosystem can stake their $T to a CML token. Essentially, the CML also acts as the ID mechanism for miners' nodes; if old machines fail, digital farmers will be able to switch machines using this. The associated CML captures all the staking information for that node. A miner can transfer a CML from one computing node to another, upon which time all credit scores and staking information are transferred. The computing node information for the CML will be updated accordingly (e.g. the technology may have changed from Amazon Nitro to TEA Box).
The delicate architecture of CML is what makes it a beautiful NFT. The way the system re-balances itself through nodes that die and credit scores incentivizes our farmers to upgrade their TEA technology stack will be critical in pushing out newer, more sophisticated technologies for everyone's benefit.
By giving a lifecycle mechanism CML, there will be better circulation for $T and more incentive for farmers to join in on this project. It’s not just about encouraging decentralization though; it's also important because of what blockchain was created as - an opportunity distribution from those who traditionally control finances or banking institutions towards everyone else.
DAO controls when to generate new CML tokens. Participants use $T to bid for the newly issued CML tokens. Once the bidding process is over, the $T tokens that have been received through auctioning the CML tokens will be disposed of by the DAO according to the rule set by the governance process.
Miners earn service fees in the form of $T tokens by both running routine network maintenance jobs and executing customers’ computing tasks assigned to them by the TEA network. Other participants can stake their $T tokens with computing nodes that they believe are most trustworthy and profitable. The $T tokens earned by a computing node for executing tasks for customers are shared with investors who have staked their $T tokens with CML, based on the staking slot positions of each investor.
Inside the DAO, the staked $T tokens give owners the right to vote for governance purposes.