Improving the Chia smart contract developing experience

Status and Challenges:

A complete Chia smart contract essentially consists of two parts, one is pure function instructions compiled from Chialisp into CLVM (which are the low-level instructions that can be executed directly on the virtual machine), and the other is responsible for solving All I/O operations(including network, time, file, etc.) that cannot be handled by Chialisp pure functions, this part can be written in python (such as the official client) or JS (e.g. pawket.app).

Now, we are facing the challenges:

  1. Anyone writing a Chia smart contract must use at least two languages and understand the mechanism of how these two languages work together. As well as the different ways of doing the same thing on both languages, and how can we overcome the potential differences (such as hashing, modulo, group addition, etc.);
  2. Different clients with different programming languages would have different implementations to communicate with smart contracts, one would be required to reimplement most of the code. For example, the python code of the official client is good and open-sourced, however, it shows insufficient help for me to reimplement Pawket.app with JS. The would block Chia be widely adopted;

Existing Solution:

  1. Functional languages encapsulate IO(which brings side effects) by introducing IO Monad (treat it as a black box that does not care about the specific content, the box itself remains unchanged, so there will be no side effects for the pure function), so as to maintain the form of pure functions, but still need to rely on the framework itself to deal with side effects (using functions that allow side effects in Haskell, and using JS to deal with side effects in Elm), in the Chia scenario, the work of dealing with side effects is handed over to the client;
  2. Cardano utilized EUTXO + Haskell, which is very similar to Chia. They have developed a compatible JS, but with a limited syntax which is the almost same structure as Haskell. The other two customize languages are still hugely similar to the Haskell code;

One way to solve the problem:

One way to solve the problem is to create a special programming language (or more importantly, a compiler and its toolchain), for example, a C-like language (including JS, Solidity, etc.) can be used, during the compilation process, it can (semi-)automatically do the following:

  1. Identify the callings to the functions that have side effects, and extract them as inputs;
  2. The pure function part is compiled into CLVM and executed on-chain, and the code with side effects is compiled into the code that deploys cross-platform;

Difficulty:

The overall idea is very simple, but there will be obvious obstacles in the implementation:

  1. How to effectively identify side-effect functions and their scope, avoid aggressive scope, and the crucial verification code may be taken away from the on-chain code (the on-chain code is the key to ensuring that the program works correctly);
  2. When the original program introduces side effects, how the formal proof to take place, or at least a basic mechanism should be prepared for formal proof, which is essential parts to ensure that the program will work flawlessly after the compilation;
  3. The original program is written in imperative programming form. How to convert it into a program suitable for a functional virtual machine without greatly affecting the execution efficiency is also difficult and needs to be proved;

Here are my some rough thoughts, your feedback is greatly welcome.

6 Likes

This is a great proposal! Will there be more developers research it together! :grinning: