Upderstanding TApps Series

[kevingzhang]

Starting today, I will post a series of "understanding TApps" series. I will explain the basic concepts of TApp. Compare with traditional smart contract based DApps and traditional cloud-based web/mobile apps. It is a little bit technical but mainly on logic.
I will try to make non-technical person to understand the logic under the hood. If you have any question free feel to ask in this discussion board.

How do we define a DApp?

It is very hard to find an official definition of Decentralized Application (DApp) or Web3, and anyone can have their definition. Since there is a "D" in DApps, the basic criteria should be decentralization in each layer of its tech stack. Any application requires three layers: Computation, Storage, and Network. So all three layers need to be decentralized to qualify a DApp. In other words, if any centralized authority or personnel can decide to allow or disallow an application to be run, this application is not a dApp.

Today's so-called dApps are more or less a calculator if the future web3 is as powerful as the iPad. The main reason is that most dApps nowadays rely on Etherium smart contract as the backend. Smart contracts indeed decentralized the computing and app state, but this is the only decentralized layer of most dApps tech stack. Those dApps still need centralized web hosting, storage, and network from centralized cloud computing providers. Even for the backend part, most dApps still have a traditional server to handle most of the interactions with the front end. Only the account-related transactions are sent to Ethereum. This is a huge compromise because if some centralized authority ask the cloud provider to off-shelf a dApp, the dApp won't run at all.

What kind of apps can be considered full-stack decentralized?

First, there should not be any centralized server. Yeah, there are still servers that host the application logic, but individual miners own those servers. The miners are anonymous and make their business decision purely by their Return-on-Investment. As long as a few miners think hosting a dApp is profitable, they will do. Therefore the application will continue running, although anyone (including app developers themselves) cannot stop it from running.

Second, not only the computation but also the storage and network need to be decentralized. Due to the same motivation, miners would like to provide storage and network as long as profitable.

The application needs to be open-sourced so that any developer can maintain and upgrade even if the original owner decided to walk away.

Based on this definition, Bitcoin and a few other blockchains fall into this category, but most so-called dApps are not. They cannot be fully decentralized mainly because of the technical limitation of the blockchain itself, and more specifically, the consensus itself.

[kevingzhang]

Improvements on the existing consensus models

There are huge improvements that have been made since the first-day blockchain was invented. We can say it has been an evolution from an abacus to a calculator. Modern blockchain is much faster than the Bitcoin network, and however, it is still far behind the speed of cloud computing. It is harder and harder to make significant progress if we still only improve the existing consensus algorithm.

The best consensus is no consensus.

The core of blockchain is consensus algorithm. It makes the new state agreed by non-trusting partners. This magic comes with a cost. Compare with cloud computing that does not require trust-less consensus, blockchain runs too slow and too costy.
So in order to get the same speed and scalability of cloud computing yet remain decentralized, we have to find a new way to get consensus. Of course the best way is "no-consensus".

Finding the consensus from rules of physics

All existing consensus algorithms are based on math. No doubt rules of math are always the most trustable and reliable. Although the computing power has improved a lot and will keep improving, if we consider the cost of energy, the improvement cannot continue forever to reach the point equivalent to cloud computing. If we have to find entirely a new way to get rid of consensus, we cannot just look at the rules of math, and can we look for the rule of physics?

New roots of trust: Semiconductor, Time, and Blockchain

The consensus algorithms are so complicated and costly because they have to assume that other parties are bad actors. What if we can use a rule of physics as an external prerequisite so that the consensus can assume other parties can be trusted? This is what Trusted Computing technologies are doing. Trusted computing is complicated too, but since it relies on silicon semiconductors, there is no significant delay or energy waste. Trusted computing has been widely used in all kinds of computing devices, from the computer, cellphone to IoT devices. For more information on this, please read more on teaproject.org website.

Besides the semiconductors, we will need a place to store the "evidence" based on which the hardware (chips) can verify. This evidence is stored in the blockchain. Yes, you read it correctly. TEA has a blockchain. We internally call it "layer one". But this is very different than other blockchain projects.
We do not run an application on the blockchain. All applications are running on the so-called "layer two". The layer one blockchain only stores the "trust data" and basic validation to decide a node is trustable or compromised. So even a slow blockchain can handle like a piece of cake.

Besides silicon, blockchain, last but not least, the constant variable of our universe: Time.

Most consensus is designed to protect from time-related attacks. Most common, double spending or forerunning attack. Consensus needs to find a way to decide which transaction is earlier, which is later, because the timestamps from the transaction cannot be trusted. But what if we can find a way to get an accurate and trustable time stamp? In the TEA Project we use the time from GPS satellites because all GPS satellites have an atomic clock. GPS is widely used in our daily life. Using GPS to get an accurate time is almost free of charge. The only problem is how we can trust the time is correct? Well, do not forget we have the TPM hardware. We are using the Trusted Computing hardware to protect the time source. Problem solved.

Trusted computing hardware, trusted time, and blockchain are three roots of trust in the Tea Project. Tea Project builds the platform that hosts new kinds of dApps. To distinguish with traditional hybrid dApps, we call ours: TEA-Apps, or TApps in short.

[kevingzhang]

Three tiers of TApp tech stack

Compared to Ethereum based smart contract DApp, TApp is closer to traditional cloud-based applications in the tech stack. It has a three-tiers architect too. The front-end, backend, and database(state). This design is not only to make developers easier migrate cloud-based application to tApp, but also make real rich-business application possible in decentralized manner. That is why we also call tApps the Rich DApps.
Although we still have three tiers but every tier is very different than the cloud-based tech stack.

Front end

Let's use web application as an example. Mobile application is very similar. All the front end code is no longer hosted by a web server. Instead, they are hosted in IPFS decentralized storage. When developers build the front end code, they upload to IPFS and update the CID to the layer one blockchain. Anyone can load the front end code from any IPFS node to his browser. Since all Tea Project miner nodes are also IPFS nodes. As long as there is one node running, you can get the front end code, does not matter which one. So the front end is fully decentralized.

Back end

As I mentioned above, there is no web server that hosts front-end code. But there is still a backend server to handle the API call from the browser. The backend logic complies into WebAssembly actors that loads into type-B CML nodes. (CML is the Tea Project NFT, it presents the miner. There are A, B, and C types. For more details, please go to teaproject.org). Since every type B CML node can host the backend logic, it doesn't matter which backend server the browser connects. When front-end js/wasm code starts, it will select any B nodes that a bootstrap suggested. Usually, a fast response type B node will be chosen as this browser's backend server. When a user has a query or command to the backend, this server and its WebAssembly code will handle the business logic. This workflow is what a typical Application Server is supposed to do in a cloud-based tech stack. We are the same. We only additional require the logic to be compiled into WebAssembly format and loaded into a hardware-protected enclave.
The backend doesn't store data. It is pure functional logic. All states will be handled by two types of databases. A CRDT database and a set of distributed state machine replications.

Database

The backend server only handle logic, any application state needs to be query or update at the database tier. Although we call it database tier, but this tier is actually not a database but two types of data storage solutions. One is CRDT database. Another is distributed state machine replications.
In most applications, the business logic allows CRDT storage. CRDT stands for Conflict-free replication data type. In our current version, we use OrbitDb based on IPFS. CRDT, as it is named, it is conflict-free. Data is not stored in blockchain but IPFS. Replicas can merge the data conflicts to get an eventual consistency without blocking. However, not all business logic storage can be handled by CRDT. Some of them cannot conflict-free. It has to be strong consistency between replications. In this case, the distributed state machine replications with Proof of Time take place.
Each state machine replication will need to put the transaction into "conveyer" sorted by trusted timestamp. Constant sync between conveyer will make sure every replication get the same transaction order. So after transaction execution, each state machine will be updated to the new state consistently.

[geopor]

The best consensus is no consensus
This is a good topic for a longer post about how different crypto project achieve consensus.

The TEA Project could be characterized as using its layer-1 for Proof of Trust (PoT) data.

[geopor]

how we can trust the time is correct? Well, do not forget we have the TPM hardware. We are using the Trusted Computing hardware to protect the time source. Problem solved.

So could the TEA Project's use of TPM be characterized as:

• TPM chips ensure mining machines are configured as advertised (i.e. the hardware hasn't been modified without the owner knowing). Once they pass (or fail) this test (and is continually monitored by Remote Attestation) the mining node gets PoT data sent to layer-1 recording its trustworthiness.
• Blockchains must decide which transactions to confirm in a reliable order. TPM chips ensure that the hardware that the remote nodes' GPS relies on (atomic clocks) hasn't been altered/hacked. Proof of Time makes timestamps trustable to prevent issues like front-running transactions / double-spending. Front-running transactions happens on decentralized exchanges all the time, I sometimes am the victom of it - I buy 10 ETH on Uniswap with USDC. A bot sees my transaction in the memepool and buys ETH right before my 10 ETH purchase goes through (the bot uses high gas). The bot then sell to me immediately after and pockets the skimmed amount. I assume this isn't what you're referring to in terms of front running?
• TPM provides a protected enclave where code and data can interact in layer-2 in a zero-knowledge fashion. Two questions about this:

1. Will the size of the enclaves be an impediment as all the WASM code (and data it interacts on) has to fit inside the enclave? Something like my Ledger Nano only has 32Kb for its enclave size which limits the types of apps I can use on it.
2. TPM assures that the hardware config is as reported. But what about the WASM code, are there any safeguards in place against bad code? What if a health monitor dApp is outputting the data it's interacting with to a remote server unencrypted, how to safeguard against that.

[geopor]

Anyone can load the front end code from any IPFS node to his browser. Since all Tea Project miner nodes are also IPFS nodes.

Are there any improvements / innovations in decentralized name services to move away from centralized DNS / domain names to access resources?

[geopor]

OrbitDb based on IPFS. CRDT, as it is named, it is conflict-free. Data is not stored in blockchain but IPFS. Replicas can merge the data conflicts to get an eventual consistency without blocking. However, not all business logic storage can be handled by CRDT. Some of them cannot conflict-free. It has to be strong consistency between replications. In this case, the distributed state machine replications with Proof of Time take place.
Each state machine replication will need to put the transaction into "conveyer" sorted by trusted timestamp.

We do have an article already including illustrations about the conveyor belt but this is a somewhat difficult topic to understand and the article is a bit long, maybe we could make an explainer video for it?

[kevingzhang]

agree. Once the coding part is completed we should have a new set of videos.