The Easy Start dApp demostrates a fictional use case.
This kind of problem can be typically resolved using blockchain, MPC or FHE if the algorithm is simple enough. Unfortunetely, this AI algorithm is too complicated to run on any of these alternatives. This is just a simple example, with real world AI algorithms much more complicated than just image recognization. Many of the cases need to use TPU rather than CPU to run. How do we deal with this situation?
TEA is invented to resolve this type of problem.
Let's simplify the whole process into a few smaller steps.
Alice first needs to choose a TEA node has her delegator. If Alice runs her own TEA node, she should use her own node. If not, she can choose one of the well-known high credit score nodes as a delegator because those nodes are considered trustful. Let's assume that Alice chooses Dave as her delegator.
When Alice uploads her pictures in her browser, the TEA deployment tool generate a random AES key to encrypt Alice's picture set and upload the encrypted images to IPFS. IPFS will respond with a CID.
The AES key will be sent to Dave's TEA module using an RSA key generated by the TEA module's hardware. Only this TEA module can decrypt the AES key. That's why we don't need https; our solution provides a higher level of security and decentralization compared to https.
Besides the images themselves, Alice needs to write a description about her data. This content includes the pricing model, such as "pay-per-use" and the price.
Once the CID of the encrypted images and encrypted AES keys are posted to Dave's node, the deployment of data is completed.
Since code is simply a kind of data, just executable, deployment is similar to how data is deployed. However, because it is executable, we will need a capability checker to make sure the code will run in an appropriately capable environment.
Bob developed the Tensorflow algorithm and needs to compile it to WebAssembly (WASM) for the binary to work on the TEA network.
Asseume Bob's code needs some special hardware support (TPU for example). He needs to run a Capability Checker to make sure other nodes are capable of running his code. This checker is called CapChecker in our TEA Project. The CapChecker can either be a JSON format description file or a WASM executable code. Whoever wants to host Bob's code need to pass the CapChecking process.
Similar to the case with deploying data, Bob also need a description file stating the pricing model and the price.
Serverless is not a new concept. Typical Function-as-a-Service is also called Serverless. But when we say Serverless, we mean it. Because there is no server running, your code runs either on your own browser (your own trusted area) or a random TEA module (another trusted area protected by the TEA blockchain and hardware).
When you click the demo dApp link, you'll notice that your browser connects to an IPFS url with a CID as parameter. The CID is the IPFS Content ID of the entry point of the dApp front-end code. Actually the IPFS node doesn't matter, you can connect to any IPFS node, even your local host if you're running a local IPFS node. Only the CID matters. This is one of the key points of the IPFS protocol. You do not care which server your data is on as they are all the same. You only care about the content (CID = Content ID).
This idea also works in the TEA project. You do not care which TEA node runs your function; you only care that about the CID of the code and the CID of the data. The TEA project's consenssus protocol ensures the correct code runs against the correct data. The client running the code (dApp) and data gets the correct result. The worflow is airtight with no privacy leaking.
You've probably noticed the "Not Secure" message in your web browser's url field when using our network. That's because we use http, not https. The reason people use https it to protect data transfer between the browser and server. This is based on a basic assumption that the server is trustable. However, the TEA project doesn't have such an assumption. We do not trust servers, we only trust add-on hardware-protected TEA modules. In order to bypass the server we use end-to-end encryption between your browser and the TEA module. Therefore, the https makes no sense to us. Https also needs to get a Cert which we consider a centralized solution. We try to keep everything as decentralized as possible.
If you want to know more about "Not Secure", you can find more info in our FAQ section