Taxa tServices in a Nutshell
We are creating a technical blog series to illustrate the basics of Taxa’s core concepts and know-how to help developers start off developing on the Taxa platform. In the first post of this series, we are introducing the design and uses of Taxa tServices.
Problem Statement
If blockchains could reach one million transactions-per-second, is that all we need to bring more use cases for smart contracts?
Besides scalability, current smart contract systems have several drawbacks that are roadblocks to their real-world adoption:
Time and space resources: On-chain resources for smart contracts are very expensive due to the consensus mechanism. This makes them unsuitable for complex business logic or computations.
Privacy: Public blockchains replicate the states and computations across the entire network to achieve consensus. On-chain privacy solutions such as zk-SNARK come with a high cost on performance.
Functionality: While smart contracts can handle blockchain transactions with simple logic, they were never meant to handle complex applications which require rich functionalities.
User interaction: Non-interactive design and long response latency are unsuitable for many real-world use cases.
Introducing Taxa tServices
Taxa Network is designed to be the new “business logic layer” because it provides unmatched computing performance, confidentiality and developability. In this way, the blockchain layer can do what it does best, form consensus and store persistent immutable states, while the business logic layer can do what it does best, offering privacy-preserving, high-performance business logic to develop and execute off-the-chain while interacting with the consensus layer. That’s the motivation behind Taxa’s Trusted Services: tServices.
Taxa tServices are the service applications running on the off-chain Taxa Network, differ from on-chain (i.e., layer 1) smart contracts in the following ways:
- tServices are interactive. Users communicate with a tService using a request-response based protocol without having to wait for confirmation. This interactive behavior offers more possibilities for smart contracts when compared to non-interactive dApps solely based on layer-1 computation.
- tServices are stateless. tServices focus on the off-chain business logic and will only communicate with blockchains to store the final states. The relationship between Taxa Network and blockchains is like a backend service to a database.
By utilizing the Trusted Execution Environment (TEE) technologies, tService guarantees the following without relying on the consensus mechanisms on blockchains:
- The confidentiality of application data — the secret data is not only sealed against an external attacker, but also against the Taxa node operators.
- The integrity of the execution process — anyone including the Taxa node operator cannot temper the computation process and the result.
- The verifiability of the application code — a user can always guarantee a node is executing the exact code he/she desires.
The detailed TEE-related mechanisms and protocols of Taxa Network will be discussed in a forthcoming article.
Build Your First Interactive Web3 Application
Let’s begin with the Hello World tService example, Yao’s Millionaires’ problem.
There are two millionaires, Alice and Bob, who are interested in knowing which of them is richer without revealing their actual wealth.
To solve the The Millionaire Problem, we want a mutually-trusted 3rd party (aka TTP). Smart contracts are designed for trust, however they lack privacy which makes this a difficult problem.
To implement such a privacy-preserving mutually-trusted 3rd party on Taxa Network, the logic is very straightforward under an interactive, privacy-preserving tService:
- Step 1: Both parties submit their secret values to a tService, which serves as a “judge” to compare their values while maintaining their privacy. They will also both notify the tService whom they want to compare their wealth to. (This is an entrance called “/submit_value”)
- Step 2: After both parties have submitted their values, they can request results from the “judge”. (This is an entrance called “/get_results”)
Let’s look into the code. First, on Taxa Network, every tService entrance is identified via a URL. Here is an example:
taxa://QmWPypqFkmHYEwB61g8FNmGLvXAGraLZ6yzxM4qG61g6nz/submit_value
The “address” part of the URL is the hash of the tService Python code (multihash format, IPFS compatible) called AppID. Requests that point to the same AppID will always refer to the same code. Following the AppID is the entry function defined in the tService code.
Users will send requests with the target URL to the Taxa Network and receive responses. The private data is contained in a secret field in both request and response. This is the basic interaction model between the users and Taxa Network.
Line 4 and line 12 showed the standard way to declare a request handling function in Pyxa — our TEE-based Python runtime environment with built-in service development framework.
Line 6: Users could attach JSON-formatted data in their requests. If they do, Pyxa will map the data to a dictionary object: taxa.request.data.
Similarly, the users can output any data by using a taxa.response method.
Note: The entire tService Python code is interpreted and executed inside an hardware-isolated memory region called enclave, protected by the TEE technology. The code is transparent and verifiable to every user, while the request/response data is opt-out privacy — confidential by default — unless the user manually reveals it. Only the user and the enclave have access to the request/response plaintext. Anyone else, including the service provider (i.e., Taxa node operator), won’t be able to decrypt the plaintext data.
Below is a sample request sent by a participant in the Hello World tService:
{
"function": "/submit_value",
"header": {"src": "user", "type": "text/plain"},
"code": "",
"taxaVersion": "0",
"contentTransferEncoding": "base64",
"data": "LQIqyFkj0waGT1x1109XFkMr1OoYwCZmfFbCwO4MSX4=",
"appId": "QmWPypqFkmHYEwB61g8FNmGLvXAGraLZ6yzxM4qG61g6nz",
}Line 9: Although Taxa Network is stateless, we do support a temporary storage feature called session to allow developers better handling of the application contexts. On our devnet, the session is a key-value pair based data structure that will be purged after seven days. The session is good for maintaining the context during a user interaction cycle, but should not be relied on for permanent storage. Developers should prepare exception handling for the circumstances in which the session is missing. While the session exists, Taxa guarantees its integrity and confidentiality.
Session files will be encrypted and stored on Taxa nodes (by TEE’s native security storage feature), and only the authorized enclave can decrypt it and recover the application data. The session object’s domain of access is bonded to the AppID and isolated from the other AppIDs.
There is no deployment necessary for tServices. Protocol-wise, users are supposed to carry the tService code inside a “code” field in their request due to the stateless nature of Taxa Network. Engineering-wise, the Taxa nodes will cache previously executed tService code and only require users to initialize a request with the AppID when a cache exists.
Next, both users connect to Taxa Network and execute the TEE’s native remote attestation protocol, acquiring a master encryption key to encrypt/decrypt the data field inside response/request. Afterwards, they will send the request with the tService URL to Taxa Network, using a RESTful API service enabled on Taxa Nodes. Details on how to do this will be included in our developer documentation.
Conclusion
In this article, we introduced Taxa tServices, the highly developable, blockchain agnostic, TEE-enabled interactive services from a simple example. In future tech blogs, we will introduce the layer-1 communication mechanisms in tServices, tServices development standards, and the new possibilities for dApps with a layered design powered by tServices. Stay tuned!
Upcoming Taxa Devnet Release
The upcoming Taxa Devnet release shall include the following three components:
Taxa tServices Development Framework: Pyxa
The Python development environment built into Taxa Node’s TEE is called Pyxa. Pyxa is a special subset of Python which is highly optimized for security and privacy. The syntax of the language is based on Python 2.7 in the current Pyxa 0.1 version, with slightly different runtime semantics.
Pyxa has rich third-party library support, which is essential for building real-world applications. The devnet will support basic mathematics, crypto libraries, and we will keep iterating new libraries in the upcoming releases.
Taxa Client Python SDK
A Python library that allows easy development of end-user applications. It will include essential features such as attestation with Taxa Network, client key management, and request/response protocol support.
Taxa Devnet
Service infrastructure based on Taxa Network’s TEE-enabled trusted computing nodes.
Resources
Do you know Taxa is on Discord? Join the technical discussions here: https://discordapp.com/invite/BusRMXf.
