Why does language design matter in the context of blockchain and other DLT?
Certainly, this is one of the criteria that should be closely evaluated when choosing a technology platform: millions of US Dollars worth of cryptocurrencies have already been stolen due to easily exploitable scripting languages.
A distributed ledger is a network of databases with some method of automatic reconciliation between them. This ensures that nodes do not hold conflicting information. Smart Contracts allow us to encode business logic as executable code that modifies the ledger state and is itself stored on the ledger. From now on we will refer to Smart Contracts as Workflows - as we believe it is a better and more accurate term.
Good Workflow Language Design
What makes a workflow scripting language a good workflow scripting language?
- Easy to understand by users
- Easy to analyze by computers
While this seems like a no-brainer, unfortunately, the reality is that many workflow scripting languages prioritize exactly the opposite criteria. They are either libraries (embedded domain specific languages) for existing programming languages such as Java or Python, or they are proper, stand-alone domain-specific languages that emulate full-fledged programming languages. Solidity, for example, features “multiple inheritance”, which is an object-oriented language feature that can be very hard to reason about (to understand the impact or result of the code that is written) even for advanced programmers.
Supposedly, it is unavoidable that computer programmers, no matter how intelligent, write software with bugs due to the complexity of programming languages. In light of this, it is obvious that confronting people with backgrounds in business and finance with this sort of complexity is just not a good idea. In fact, it is a very bad idea.
Another important factor to consider is machine analyzability. All mainstream programming languages are Turing-complete, which means that given an arbitrary program in such a language, we cannot determine whether the program will ever finish running. This is undesirable in the context of real-world assets and resources, where we absolutely want to be sure that our transactions will complete and computation is done accurately.
Furthermore, other, more complex and interesting analyses (e.g. payout by some date, given certain assumptions; eventual release of all funds; etc.) become intractable and difficult to solve in a normal programming language.
At Adjoint, we developed FCL, a Turing-incomplete workflow scripting language which is based around the principles of usability and analyzability. Workflows are constructed in an intuitive way using Petri-nets, which are a rigorous mathematical framework for concurrent processes, similar to flowcharts. The FCL compiler will check that the workflow is sound. In other words, it walks through the structure of the workflow and checks at any stage of the workflow’s execution, that the workflow can reach the intended end state.
Above, you can find a visual representation of a natural gas trade workflow. This graph is generated automatically from the source code of the underlying FCL workflow and helps visualize and communicate the possible courses of action during the execution of the workflow. Adjoint is investing heavily in the engineering of FCL. There are exciting features and tooling for more intuitive workflow development and more sophisticated analyses are on the horizon.