The promise of Ethereum is based primarily on the capabilities it delivers for the creation and execution of “trustless” smart contracts. Smart contracts, the narrative goes, execute autonomously and predictably, such that parties engaging through them do not need to trust one another to fulfill their respective contractual obligations. The outcomes of a smart contract, such as the flow of funds between contract parties, are triggered automatically when specific predetermined events occur. There are no expensive, time consuming and soul depleting legal shenanigans required to get counterparties to comply.
One obstacle that exists in fulfilling this vision of “trustless” smart contracts is the requirement for execution rules that are transparent to all participants. With legal contracts, the execution rules are written in a natural language such as English and can, some abstruse legalese notwithstanding, be understood by most literate humans. For smart contracts on the Ethereum blockchain the rules are written in bytecode, which can be understood and executed by Ethereum nodes, but is illegible for humans.
The source code, which is compiled into bytecode, can be interpreted by developers such that it can provide at least some measure of transparency if made available. This brings us to the first suggestion for promoting contract transparency:
Include, on the blockchain, the source code and compiler version that was used to generate the contract bytecode.
Ideally, the source code should be annotated with comments to facilitate interpretation. Including the compiler version serves to bind the source code to the bytecode, so that it can be establish that the source code included was indeed used to generate the contract executing bytecode.
Ok, so now we have provided the source code and bound it to the executing bytecode… Unfortunately, contracting parties who are not qualified to, or do not wish to invest the time and effort necessary to fully understand the contract conditions based on an analysis of source code still find themselves in the position of having to trust counterparties or developers. A user friendly way is needed to accurately represent execution rules so that their interpretation can be made accessible to a broader audience.
We could create text or graphical descriptions of the contract conditions from the source code, but these would not be authoritative. A non-authoritative description could shed light on the contents of a contract but, once again, participants would need to trust that the description accurately represents the contract rules. What we need is a user friendly description that also authoritatively describes the contract rules (i.e. the description is the contract).
Enter Model Driven Development (MDD). A visual model such as a BPMN and/or DMN diagram could be used to generate the contract source code via a process-engine. Just as source code can be bound to bytecode, so also can a BPMN and/or DMN visual model, represented in XML, be bound to the generated source code by including the process engine version. As of today, I am not aware of any implementation of this idea in connection with Ethereum (or other) smart contracts, but it seems to me it to be an idea that is worth pursuing for the sake of boosting the transparency, and therefore the trust, enjoyed by smart contracts.