The Case for Graphical Smart Contract Editors
Blockchain smart contracts enable the programmatic, trustful execution of some logic or transaction. Because of their unique affordances, I believe smart contracts will become a critical part of the global digital infrastructure, similar to APIs. In order to realize this future, smart contracts must become more reliable, secure, and easier to create. Graphical smart contract editors are part of the solution. As the foremost smart contract platform, Ethereum should have competing implementations.
According to their inventor, Nick Szabo, smart contracts are “a set of promises, specified in digital form, including protocols within which the parties perform on these promises.” In Ethereum, smart contracts do not have to fulfill contractual purposes, but here I will focus on the use cases emphasized by Szabo’s original definition.
Ethereum smart contracts are computer programs that execute in the environment of the Ethereum blockchain. As with traditional legal contracts, many Ethereum smart contracts are semantically similar, e.g. “Send money from a to b if x,” or “Issue i tokens and place them in the wallet of the minter, c.” This partly accounts for the existence of template libraries like OpenZeppelin; why write a new ERC20 token contract if one already exists? Incorporating common functionality into libraries is ubiquitous in software, and an important vector for best practices in the industry. However, to maximize the usage of smart contracts, engineering skills cannot remain a prerequisite for their creation.
Understanding the transactional logic encoded by a smart contract should suffice to create it. For example, if a user wants to create an escrow contract, they should only have to identify the parties and a custodian or oracle. At present, for all the democratizing aspirations of Ethereum, only technical users can write smart contracts. The solution is to add a graphical user interface (GUI). By enabling non-programmers to create and deploy smart contracts, the Ethereum ecosystem can flourish.
Graphical smart contract editors can be implemented at different levels of abstraction. At one extreme, syntactic primitives are represented as graphical shapes that fit together in a drag-and-drop interface. EtherScripter, a Google Blockly implementation of Serpent, serves as an example. At the other extreme, the user enters the necessary data, e.g. the name and total amount of an ERC20 token, into a form.
Exactly where an editor belongs on this spectrum depends largely on the level of customization required for its intended use. If an ERC20 token is all that’s necessary, a form would suffice. If the contract encodes more complex logic, a flow- or model-based editor, similar to Blueprints in Unreal Engine 4, is probably more suitable. EtherScripter, meanwhile, isn’t useless merely because it implements Serpent, but because syntactic graphical editors are useless in production contexts. For technical users, they’re less convenient than text, and for non-technical users, they’re hardly more intelligible than text. Consequently, complex bespoke or novel functionality will remain the domain of engineers. With the appropriate tools, end-users can handle everything else.
Graphical smart contract editors will not only democratize smart contract creation, but also promote smart contract reliability and security. Since they are computer programs, buggy smart contracts are inevitable. Nevertheless, the present state of smart contract security is unacceptable. High-profile failures such as the Parity multi-sig wallets discourage private and institutional users alike. Graphical editors will necessarily generate template code, and only the best analyzed and tested code need be used. OpenZeppelin is an obvious candidate for graphical implementation.
Creating an ideal editor will require intimate knowledge of its users. Before those users exist, the only course is to build and ask questions later. Taking stock of the rote tasks of Solidity developers may hint at the appropriate level of abstraction. Beyond that, beginning is a matter of choosing a reasonable framework to build with. There are as yet no market-ready offerings in this space, but some projects, such as Hyperledger Composer, are well on their way. With its unparalleled developer community, Ethereum can still take the lead.
Graphical Solidity editors will allow non-technical users to create and deploy smart contracts, while also promoting smart contract security and reliability in the Ethereum ecosystem. At worst, new niche use cases become possible. At best, millions of users are empowered to bring Ethereum to bear on their business problems. The time to democratize smart contract creation is now.
