Macroprogramming smart contract systems

This project set out to build upon existing research in the programming of smart contract systems. It entailed creating a language that could describe both on-chain and off-chain computation and data, while abstracting low-level communication between platforms. The terms ‘on-chain’ and ‘off-chain’ refer to blockchain transactions and transactions occurring through other channels, respectively.

Existing smart contract languages are limited to describing code that runs entirely on the blockchain. However, most applications would require code that could run on multiple blockchains and interact with the real world at off-chain locations. The proposed solution consists in writing separate code for different platforms, with custom communication. It was also deemed appropriate to run trusted code off-chain to improve the scalability performance and privacy of the on-chain protocol.

The chosen approach would allow programmers to write a single program description, enabling the language compiler to manage the rest. The compiler would then target code for both the on-chain and the off-chain platforms. Moreover, the inbuilt Oracle system would handle the low-level communication between the platforms for real-time communication. The programmer would then be able to focus entirely on the functionality of the smart contract, while the rest would be abstracted out.

The target location of the code was specified using the programming tags, defined in the language. The language features were carefully chosen on the basis of two related experiments. The selection also entailed analysing the domain of existing smart contracts, and the sustainability tags for specifying code locations

The developed language would allow programmers to describe functions running both on-chain and off-chain. Programmers would also be able to describe data by defining a model and specifying the target location for each data attribute. The language was evaluated with reference to language theory and by comparing it to the current domain languages.

The outcome of the aforementioned analysis indicated that the designed language would require significantly less code to write such systems, while providing a unified view of the entire system. In view of a lack of developer feedback, it was not possible to obtain a watertight verdict on the proposed language. Nevertheless, this drawback could prove to be the motivation for further work in the area, or improving the language itself.