Dr. Christian Reitwiessner proposes to make executable distributed code contracts (EDCCs), or smart contracts, simpler to understand.
Reitwiessner spoke on a number of topics at Devcon3 in Cancun. On November 2, during his talk, “Babbage: A mechanical smart contract language,” he focused on ways to more easily expose the functionality of EDCCs. With Babbage, Reitwiessner said, “You’re encouraged to create machines that look simple and are easy to explain.” The “machines” he’s referring to are actually visual representations of EDCCs.
Tiny pieces of code can be hidden anywhere in EDCCs, potentially leading to huge security flaws if they go unnoticed. Reitwiessner gave an example of a line of code that simply read “lock equals false.” That seemingly innocuous phrase actually makes it possible for someone else to meet certain conditions and open the contract, even after the contract’s controller believes it is locked and safe. Once that happens, the contents of that contract can be transferred out.
“Anywhere in the smart contract you hide this tiny line that says ‘lock equals false’ – If you want to find out whether it is possible to only lock the smart contract once and not unlock it later, you have to analyze the full thing and find every occurrence of the word locked inside the smart contract, and I would say this is a general problem of any text-based programming language This is the dash we use – that variables can be referenced just by stating their name from anywhere. That’s not 100 percent true for all programming language but I guess the idea is there in all text-based programming language.”
Reitwiessner went on to discuss how the naming conventions for programming functions are commonly written in a natural language. He says that while most people agree this language will be English, not everyone speaks English and so it represents a barrier to non-English speakers, particularly when it comes to catching little flaws like that piece of code earlier. To drive the point home, he showed an EDCC written in Gaelic and invited the crowd to analyze it for faults; none could.
Another of Reitwiessner’s examples likens the Ethereum Virtual Machine to a soda machine:
“Imagine you have a soda vending machine that is somewhere in the public. Anyone can walk up to it and buy soda from it … this soda machine is made of glass and this means everyone … can see whether there are actually still drinks inside before interacting with it … You can even see whether there is still change inside the machine … you see whether it makes sense to pay with large coins or small. You can even try to see how it works.”
The analogy of the soda machine is appropriate for the idea that Babbage represents. As Reitwiessner proceeded to display a Babbage contract, which is a visual configuration of “valves,” “tanks,” and “pipes” representing EDCCs, it makes sense. All the pieces of the contract’s code can be visually represented. Ether flows between various tanks that are controlled by levers representing the code that would govern such transactions. An array of increasingly complex multi-signature contracts were shown in such diagrams, proving that the underlying code, which allows Ether to flow between various parties based on consent, can be visually represented.
Visualization with Babbage may aid developers to create more practical EDCCs that are easier to audit and thereby function well. “This is, for now, just a common concept. I welcome everyone to join the discussion.” Babbage has a Google group where Reitwiessner hopes others will contribute and help the project grow.