TEA Project’s State Machine

How TEA Handles State Changes

In a typical blockchain, the default status of nodes in the network is that they’re untrusted. The lack of trust ends up being an expensive design decision for traditional blockchains. In blockchains like Bitcoin and Ethereum where the nodes don’t trust each other, all nodes will need to reproduce all states since the beginning genesis block. One consequence of traditional blockchains’ lack of trust is that the block size grows larger over time (as it needs to store all transactions that have ever occurred on the chain), which has an associated drag on transaction speed.

The TEA Project can quickly sync up its nodes through the trust built into its design. This conceptually is a major difference it has with traditional blockchains.

Because the onboard TPM chips of mining nodes allow attestation to be run on them, they can be guaranteed to be trustworthy and don’t need to sync up a historical ledger of all previous transactions. The TEA Project’s state machine only needs to store the resulting state change of transactions in RAM and not the transaction itself. Once all nodes are trustable, any node can get the latest state from a nearby node’s RAM. Syncing up to the latest state through reading a nearby node’s RAM is a quicker process than reconstructing the current state by recomputing and verifying the entire history from the very beginning.

In the TEA Project:

• Transactions are processed with the resulting state change stored in the RAM memory residing in the enclaves of type-A CML mining nodes.
• Only type-A CML nodes run the strong consistency state machine (including the SQL database instance).
• Every type-A CML node will have the same copy of the state in its memory.

All new transactions are already ordered through our use of GPS satellites (Proof of Time). Time can be proven accurate as the TPM chip onboard our layer-2 mining nodes helps ensure that the GPS module’s timing hasn’t been altered. Most importantly, our strong consistency state machine that runs through type-A CML mining nodes doesn’t need any consensus as there are no new blocks to wait for. Instead of blocks, new transactions land on a conveyor belt, and eventually everyone ends up with the same state. The TEA Project’s state machine functions just like a decentralized database that developers can use.

There are major benefits to TEA’s state machine and how it uses time as a root of trust.

• The TEA state machine updates continuously because there’s no block. There’s no need to wait every few seconds to get the consensus of all other nodes. All nodes have agreed on the time source from the atomic clock of GPS satellites.
• A new node joining the network doesn’t need to sync up from the very beginning of the genesis block. It just loads the current state from any nearby trusted state machine. The trust comes from the hardware and blockchain (layer-1) certification, not from self-verification from the block history, which means that syncing takes almost no time.

Ethereum’s State Machine is a Problem for Running DApps

We mentioned how developers would not have a database layer directly on the blockchain when they start developing on a blockchain like Ethereum. There’s no database layer in Ethereum by default outside of writing directly to the ledger, only custom solutions that run alongside Ethereum.

In Ethereum, it’s too expensive to store everything on the blockchain. All the nodes will need a copy of the blockchain ledger, and the blocks could become huge if they were to store the state changes of every running dApp. If we’re talking about eventually running complex apps on the blockchain, something as simple as moving the mouse on a computer is technically a state change.

Ethereum is technically NoSQL, where everything is stored on the ledger. You can think of blockchains like Ethereum that update their state through blocks to function like a piston engine (cycles), while the TEA Project runs like a turbojet engine (continuous). Anything more complex must be stored and run outside of Ethereum (for example, off-chain data storage using IPFS). In Ethereum, every node will get the same order of transactions as everyone has the same ledger.

So let’s revisit our developer looking to port their gaming app from the hosted cloud computing world to Web3 using Ethereum.

• The front-end for the dApp still uses DNS resolution for its domain and is still hosted on the cloud.
• They must write code for the smart contract logic, which doesn’t allow for the rich applications common in the web that we currently use.
• Because not everything can be written to the ledger, the gaming developer opts only to use the blockchain to track digital assets (i.e., the weapons owned by each character).

This means that the code they’ve written for their Ethereum smart contract will only write digital asset logic to the ledger. Meanwhile, the rest of the actual gameplay logic still remains on hosted cloud servers as the current state of decentralized blockchain doesn’t allow hosting such rich dApps.

We hope that developers onboarding to Web3 can use the TEA Project to fully decentralize their apps. Developers disappointed by the limitations of current blockchain design can turn to the TEA Project to replicate cloud computing speeds while still having their apps run decentralized.