Smart contract programming languages should be easy to understand and unambiguous. Usually, such languages are written in formal computer languages comprised of expressions, operators, functions and variables. While they are already quite abstract and hard to understand because of that, the fact that components of a smart contract can be referenced by name partly from anywhere in the program sometimes makes it almost impossible to see how different parts interact and fit together.

We propose a language that is situated at a level where even untrained people are able to grasp it. Babbage is a visual programming language that consists of simple mechanical parts that interact with each other: Pipes, valves, rods and levers. Since components that want to interact with each other have to be physically close, the modularity of such systems is already guaranteed by design. Furthermore, people with no knowledge of programming languages have the chance to understand complex smart contracts.

There is an analogy between smart contract on Ethereum and a vending machine made of glass, put at a public place: Once it is created, it is not possible to modify it, except by pushing the buttons that are mounted at its exterior. Furthermore, everyone has the possibility to watch how it works internally. Note that open source software installed on cloud computers is similar, but there is still an important difference: You can take a look at the published source code, but you have no way to tell whether the server actually runs the same code. This is similar to a vending machine not made of glass: You can look at the blueprints, but you never know what the machine actually does.

If the machine is made of glass, it is (depending on its complexity) quite easy to see what will happen if you put a coin inside and then push a button. You can even see if the drink you want to buy is still available. Software running on servers tries to achieve a similar effect using easy to understand user interfaces, but in the end, you never know what will happen when you actually press a button labelled buy on a website.

We want to take this analogy further and build actual machines inside Ethereum. The benefits are that humans should be able to figure out how a mechanical machine works without much prior knowledge. Furthermore, it should be quite easy to see any possible way in which a switch (a variable in text-based programming languages) can be modified, because there has to be a physical connection to that switch. Finally, as Ether is modeled as a liquid flowing in pipes, you can directly see where it will go.

Also note that (software) engineers often resort to diagrams when they want to explain something. Admittedly, diagrams often simplify things and thus, a mechanical smart contract language might not be as expressive as a text-based language, but on the other hand, mechanisms that are so complex that they cannot be fully explained using a diagram should perhaps not be used for smart contracts anyway.

Let us start with an example. A smart contract that distributes all Ether sent to it equally among two addresses can be seen in Figure 1. The dashed outer line delimits the smart contract. Anything that comes from the environment or influences the environment has to cross the dashed line. Ether is a purple liquid that flows in pipes which always have a flowing direction. The smart contract has no way to store Ether, everything is just forwarded. Ether comes in at the top, at the entry that is unmarked. The exits at the bottom are labelled by addresses, so the Ether is forwarded to those addresses. Since there is no mechanism that could change the labels, these connections are permanent. The most interesting part of the smart contract is the splitter in the middle. It has an indicator that tells how much of the input Ether goes to the left exit and how much goes to the right exit. To help reading the indicator, the exact percentages are also written in numbers.

Figure 2: Smart contract that distributes all Ether sent to it among two addresses with a ratio modifiable from a certain address.

Let us now look at an extension of this simple splitter, the adjustable splitter, which can be seen in Figure 2. This contract has a small button or lever at the outside and an address written next to it telling that only this address is allowed to manipulate the button.

The basic idea of Babbage is to provide multiple gadgets that can be combined with each other, but only snap together in certain combinations. The final smart contract that is executed on the Ethereum Virtual Machine will of course not do a full physics simulation as that would be too expensive. Instead, the IDE will translate gadget combinations into smart contract code. At the same time, the IDE will make sure that unintended physical interactions like collisions between moving rods or levers are not possible. This is important since such collisions would not be modelled by the smart contract, but at the same time, humans looking at the diagram could expect them to actually happen. In general, all gadgets should be as simple and intuitive as possible. The examples provided in this document probably do not yet achieve the desired level of simplicity, but they provide a perspective on the general idea.