Smart contract development is complicated and expensive. In contrast to writing smart contracts in Solidity, modeling smart contracts as graphical state machines has a lot of advantages. You can focus on business logic instead of struggling with technical details and even non-programmers can understand what your contract is doing.
You can generate bullet-proof Solidity code and don’t need audits anymore. And you can easily switch the platform or target language for different smart contract code.
We use the open-source version of YAKINDU Statechart Tools to model smart contracts as state machines. This way, you can test the model with the simulator and ultimately generate Solidity code out of it.
Smart contract development for blockchains is complicated. If you want to develop smart contracts for the Ethereum blockchain, you have to learn a completely new programming language like Solidity. If you successfully managed to write and test your first smart contract, the next hurdle follows: Since you can’t update your smart contract once it is deployed to the main net anymore, someone has to ensure that the smart contract code is bulletproof against attacks.
While there are really good resources about known attack vectors, it takes a lot of experience to find those kinds of security holes in smart contracts.
The past has shown that smart contracts are hacked frequently and funds were stolen. Since the tools to secure smart contracts are not yet mature enough to find all possible security flaws you need a smart contract audit. There are only a few experts around that are able to code review smart contracts in a way that you can deploy without causing you sleepless nights. And this is the second problem with smart contract development - It is expensive.
This combination makes it tremendously difficult for individuals or small startups to develop high-quality smart contracts.
Two years ago, we started with the development of YAKINDU Solidity Tools — an integrated development environment that provides features like context-sensitive help, smart code proposals, quick fixes, refactorings, templates, and live validation.
This year, we extracted the core functionality to a so-called Language Server that can be reused in a lot of editors like Atom or Visual Studio Code. While this improves the developer experience a lot, this can not be the end of the story.
As we are also the developers of YAKINDU Statechart Tools — a modeling environment for state machines — we did a bit of research on how state machines can ease the development of smart contract and started to integrate our language server into YAKINDU Statechart Tools.
This basically means that we can access built-in features of Solidity like global variables, constants, and functions while modeling the state machine.
The integrated simulation engine allows verifying the behavior of the model. And the smart contract Solidity code is generated out of the model with a single button -click.
Most software developers believe that state machines are more complex than they actually are and tend to avoid them in their daily work. This is no surprise — state machines often have the reputation of being too complex and academic for practical use.
If you have a look at the Wikipedia article about finite state machines there are terms like a mathematical model of computation, deterministic (DFA) and non-deterministic (NFA, GNFA) automata and powerset construction. This does not sound like fun, right?
In fact, state machines as we will use them here for smart contract development have nothing in common with their academic counterpart — they are an effective way of developing software for a lot of different applications.
For example, they are frequently used in the embedded systems domain to model reactive systems like cars or airplanes. A reactive system is a system that reacts to events from the outside world triggered by sensors or human-machine-interfaces, like an elevator or a coffee machine.
A smart contract is nothing different. A transaction from the outside world triggers a change to the internal state of the smart contract.
The basic building blocks of a state machine are states and transitions. A state machine consists of a finite number of states. The machine is in only one state at a time, this state is referred to as the active state. It can change from one state to another state through a trigger or if a certain condition holds.
As an example, we developed a smart contract that we want to use for license management. This use case is very well suited for blockchains since the license holder remains in control over the license agreement as long as the contract is not terminated.
One smart contract maintains the lifecycle of a single license. After creation, the license enters the Valid state with an initial budget of 10 Tokens. There are two different interfaces to interact with the smart contract.
The owner of the license can add budget to extend the license period. The license manager can collect license fees on a regular basis based on the time period.
If no more budget is available, the license enters the Invalid state until a new budget is added to the contract. The license owner can terminate the contract at any time and will receive the remaining budget.
Have a look at the image above. I think the model is more comprehensive and easier to understand than 500 lines of Solidity code.
First of all, you can model a smart contract at a higher level of abstraction. When hiding all the technical details you can focus on the domain logic you want to develop. The graphical state machines are even understandable by people who do not have programming experience at all.
Focus on your business model — not on technical details or programming languages.
The generated smart contract code has a higher quality. Once it is ensured, that a code generator generates correct and safe code, you do not have to audit every single contract that is generated with this code generator. This will reduce the hurdles for small innovative startups as well as for big companies to migrate their business case to blockchain technology.
Models are platform-independent. Through the use of different code generators, you can generate a smart contract for different languages like Solidity, Vyper or Yul. Or maybe in the future, there will be another blockchain that is as powerful as Ethereum.
Good to know that you can reuse your models to generate a smart contract for another blockchain.
You can execute and test the models. You can easily execute the models with the built-in simulator to verify that the model behaves as expected before deploying it on the blockchain.
The tool is still in early development and the code generator is not ready for production, yet. Generating high-quality contract code is a quite ambitious task but we hope that we will have a working prototype available for download soon!
Let us know what you think about our approach of model-driven smart contract development in the comments. In the meantime, you can visit our website and follow @yakindu on Twitter.
(Disclosure: The Author is a Developer at YAKINDU Tools)