Introducing Off-chain Computation to Smart Contract with Fat Contract by@shelvenzhou

Introducing Off-chain Computation to Smart Contract with Fat Contract

Phala is a trustless computing cloud whose miner nodes are all Secure Workers using secure enclaves. With this, individual developers can rent their own off-chain workers from Phala blockchain and enjoy the benefits. Fat Contract is meant to be written with Parity’s ink, except for the extensions we provide for Fat Contract. The key difference is where they are executed: the ink contract is executed by Substrate nodes and Fat Contract in pRuntime (runtime customed by Phala)
image
Shelven Zhou HackerNoon profile picture

Shelven Zhou

Lead Researcher of Phala Network

What is off-chain computation?

Before introducing the off-chain computation, let’s first learn about the on-chain computation model adopted by almost all the existing smart contracts.


figure 1. On-chain Execution of Transaction

figure 1. On-chain Execution of Transaction


Figure 1 shows the on-chain execution model. The on-chain execution itself is deterministic: the transaction is executed by all nodes and they must agree on the final state.


Such requirements on state consistency unavoidably introduce limitations: it is slow and expensive. More importantly, operations like network requests are forbidden since they can result in different final states on different nodes (network requests may fail on some nodes and succeed on others).


Figure 2. Off-chain Execution for Blockchain

Figure 2. Off-chain Execution for Blockchain


The off-chain execution was first proposed to satisfy the need for Oracle, i.e., to introduce the off-chain input like real-time BTC price from some exchanges during execution. Unlike on-chain execution, off-chain execution is conducted by a limited number of (sometimes only one) off-chain workers, so it also improves the performance and cost. Now the nodes only need to verify the execution results are really produced by these workers (it’s a bit like the rollups of a single transaction).


This model, unfortunately, also has limitations. The trust of off-chain workers is implied in this solution since the on-chain nodes can only know that these workers produce the results but not that they use the “right” off-chain input and do the execution faithfully. That’s why such a solution is usually only used by the chain development teams who host their own workers.

A step to trustless off-chain infrastructure

The key to the problem above is to find the “trusted” off-chain workers, and there are some candidates like verifiable computation methods like zero-knowledge proof, or hardware-based solutions like the secure enclave.


Phala is a trustless computing cloud whose miner nodes are all Secure Workers using secure enclaves. The secure enclave is usually implemented as a secure subsystem of modern processors and provides two important secure guarantees: confidentiality and execution integrity. This means that the malicious operators, even with physical access to the machines, cannot read the state in memory (since it is encrypted by dedicated chips), or manipulate the program execution to provide false results. With this, even the individual developers can rent their own off-chain workers from Phala blockchain and enjoy the benefits.


This drives us to design a new contract execution model, i.e., the Fat (PHAt) Contract, that is able to do off-chain computation. It is worth noting that we deliberately choose not to simply migrate EVM into a secure enclave since it was designed for on-chain execution and thus hard to extend.

Features and application scenarios

The Fat Contract is meant to be written with Parity’s ink!. From the developers’ perspective, there is little difference when writing ink! contract and Fat Contract, except for the extensions we provide for Fat Contract. The key difference is where they are executed: the ink! contract is executed by Substrate nodes and Fat Contract in pRuntime (runtime customed by Phala) in our off-chain Secure Workers. Obviously, Fat Contract enjoys all the benefits mentioned above.


Figure 3. Compare Fat Contract with Existing Smart Contract

Figure 3. Compare Fat Contract with Existing Smart Contract


With Fat Contract, it’s now possible to implement the applications that used to require creating a new chain with a single contract.

Figure 4. The application scenarios of Fat Contract

Figure 4. The application scenarios of Fat Contract


The model of Fat Contract

The design principle for Fat Contract is simple: while supporting the legacy on-chain execution logic, it tries to provide a full-functional off-chain execution environment with privacy, high performance, and necessary features like Internet access and storage. Our insight here is that only a small portion of the state (like token balance and NFT ownership) in DApps really needs to be persisted on-chain, that’s why we encourage developers to implement most of their logic off-chain.


Figure 5. An ink! / Fat Contract example

Figure 5. An ink! / Fat Contract example


Talk is cheap and let me show you some code. This is the Hello World contract from ink!. As promised, you can run it in Phala with no modifications. In this contract, the contract (on-chain) state is described by variable value. And based on whether the state will be changed, the following functions are divided into two classes, mutable (flip() function) and immutable (get() function). Correspondingly, we divide the user’s requests to these functions into Commands, which are sent to mutable functions and change the on-chain state, and Query, which are sent to immutable functions and leave the on-chain state unchanged.


Figure 6. Command execution in Fat Contract

Figure 6. Command execution in Fat Contract


Among them, the Command follows the traditional off-chain execution path, except that it is encrypted and can only be decrypted in secure enclaves. This means Command, like normal transactions, needs to be posted on-chain, packed into the block, and then synced to off-chain workers for execution. It can be a performance bottleneck so should be used with caution.


Figure 7. Query execution in Fat Contract

Figure 7. Query execution in Fat Contract


Query, on the other hand, is very different. First, it is directly sent to the Secure Worker just like Client/Server communication, so it is free of the latency of blockchain transactions and the gas fee for execution (you rent the worker instead of paying for each instruction in Query processing). Second, Query is meant to change the local (off-chain) state. We further empower it with the ability to read/write local cache and send HTTP requests, this means you can directly utilize all existing web services including data feeds, Telegram/Discord bot APIs, online storage like AWS, and more.


In other words, when you are writing functions for Query, it’s more like you are writing a normal server program instead of a smart contract. But this time, your “server program” is executed on a real decentralized cloud, and can use the blockchain as the root of trust: each Fat Contract is allocated a key pair with the public key published on-chain. This key pair proves the program identity and can be used to sign any messages to prove that they are really produced by a certificated contract and thus can be trusted. This enables attestation operation, which is the basis of Oracle, Decentralized Identity, and other interesting Web3 applications.

Now, why not get your hands dirty and try the Fat Contract yourself?


More Readings

  1. Blog: Introduction of Fat Contract
  2. Paper: Off-chaining Models and Approaches to Off-chain Computations
  3. Blog: Substrate off-chain workers: Secure and efficient computing-intensive tasks
  4. Blog: Off-Chain Computation Solutions for Ethereum Developers

Also Published Here

react to story with heart
react to story with light
react to story with boat
react to story with money
L O A D I N G
. . . comments & more!