How Far Are Lawyers From Drafting Smart Contracts?

I wrote in my last post that the “blockchain will alter the way we think about contracts and several types of legal documents will effectively be software-like.” This is a truism for many cryptocurrency enthusiasts.

Of course, I was referring to “smart contracts” even if I didn’t used the expression “smart contracts” for buzzword avoidance purposes. I suggested that some lawyers would be involved in drafting these “instruments”.

Before we start, there’s some confusion about what a “smart contract” actually means, and it’s at the root of a certain amount of similar confusion in the legal sphere about the immediate potential of blockchain technologies. The tech world comes up with a technology that has “contract” in its name, and, of course, lawyers then feel like they should be paying attention (rightfully so). But beware Maslow’s hammer. Drafting actual stand alone “contracts” (a lease, an IP licence, an insurance agreement, etc.) doesn’t look like the main thing serious Ethereum developers want to do. They are building actual platforms and applications (where “smart legal contracts” are only a component and not the end product). Trying to find an exact analogy in the blockchain to the traditional work of lawyers who draft contracts leads to a very incomplete picture of “smart contracts” in today’s context. This is true even if the person who coined (pun intended) the expression “smart contract” had a much more legal-specific thinking than present-day Ethereum developers (see in comparison the definition of “smart contract” in Ethereum’s most basic walkthrough). This is a longer take on this question.

This begs the question… how far are we from a world where lawyers draft smart contracts?

Assume – for the purpose of this post – that a smart contract is a computer program that automates parts or the entirety of an actual legal agreement and that instead of being deployed on a single computer or server, the code is distributed to, and runs on, a non-hierarchical network of computers (probably via a blockchain).

If you’re not sure you understand what a blockchain is, worry not (at least as far as your ability to understand this post is concerned). There are good explanations elsewhere (here, for instance).

Bitcoin is often the first place we look when talking about blockchain, so let’s start there.

Bitcoin allows you to create a certain number of complex transactions (i.e. more than just “Alice pays Bob X amount of Bitcoins”). These transactions could constitute an entire smart contract or the automation of a component of a smart contract using the Bitcoin scripting language (for instance an escrow transaction).

Chances are that in programming such complex transactions on the Bitcoin platform you would need to be able to do arithmetic operations. In Bitcoin’s scripting language, if you want to do something as basic as verifying that 2 + 7 – 3 + 1 evaluates to 7, you’ll need to write something like this:

2 7 OP_ADD 3 OP_SUB 1 OP_ADD 7 OP_EQUAL

(The example comes from here.)

Imagine drafting an agreement in this beautiful prose! Luckily, chances are you’ll never have to face this challenge. The Bitcoin blockchain purposefully employs a rather arcane and limited type of scripting language for efficiency and security reasons. You may have heard of Ethereum (including here on Slaw) and this is where it comes into the story. In 2013, the Ethereum white paper discussed the limitations of Bitcoin’s scripting language and proposed a new blockchain-based platform (Ethereum, that is) that allowed its users to build any type of application as opposed to the limited scope offered by Bitcoin’s scripting language.

To go back to our arithmetic example above, to check if 2 + 7 – 3 + 1 evaluates to 7 in Solidity (the most popular programming language on Ethereum at the present time, which is inspired in part by JavaScript), you’ll need to write something like this:

2 + 7 – 3 + 1 == 7

This, of course, is much easier to understand than the awful-looking line of Bitcoin scripting code above. Needless to say, you will need much more than this in your toolkit if you’re a lawyer who’s excited about learning how to code useful smart contracts. Where should we start?

I tried to play with Ethereum for a little while, but got frustrated by not finding the right tutorial, and the most promising one ended up not working because of material changes in Ethereum since its publication. I finally found this tutorial. It’s technical, but entirely worth the time if you want to understand a little bit better how development on Ethereum works. It’s much better than Ethereum’s own introduction at least for complete beginners. What we are taught to build in this tutorial is a simple voting application (i.e. you go on a webpage and select a person to vote for, the votes are counted and displayed, and all of the back end happens on the blockchain). A voting application doesn’t seem so much like a contract in the legal sense (although it’s easy to imagine that a “smart” shareholder agreement for instance would require a voting component) but at least we get to implement something on the platform and see what’s under the hood. The actual Solidity code of this application is here.

As you can see if you clicked on this last link, this is nothing less than actual computer code. This shouldn’t be surprising when you consider that this is coded in Solidity, which I already mentioned was a programming language. Maybe this was all obvious to you, but some may have had hopes upon seeing the perfectly understandable line of arithmetic code in Solidity above that these smart contracts would be closer to the types of contract lawyers usually draft. Judging from the above example, and from other examples (say this code for an options exchange) they are not.

What should lawyers do with this?

Of course, the technology will get better and easier to learn. Maybe someday we will be able to build smart contracts from dashboards with pre-coded components that require minimal understanding of the underlying technology (somebody is trying, or tried, something that goes in this direction). After all, you needed to be a serious geek to send an email in 1984 and yet today we all wish it would be a tad more complicated for at least a few people in our contact lists to send us instantaneous written communications. Technology will do its share to get blockchain-based systems closer to us by becoming gradually more convenient.

Yet, it remains that smart contracts are fundamentally about “programming” relationships on computers (under our working definition at least). Really there’s no escaping it: The answer to the question “how far are lawyers from coding smart contracts” depends on our willingness to learn programming.

I’ve seen Joshua Lennon (Joshua is too prolific for me to find the exact tweet) say something to the effect that lawyers learning code shouldn’t aim or expect to replace software programmers, the same way we wouldn’t expect a programmer who dabbles into law to give formal legal advice. I agree, but I hope it’s not condescending to say that this is not a reason not to encourage lawyers to get a solid grasp of core programming and IT concepts if they have a serious interest in working with bleeding-edge technology like blockchain. When I say “solid” I mean learning more than basic data types, operators, if-else statements and loops. You should add at least some understanding of basic algorithms, data structures (a bitcoin is fundamentally just that, a type of data structure) and a basis in cryptography (as the teachers of a cryptocurrency class say to “eat your cryptographic vegetables”).

In order to play a meaningful role in the development of blockchain-based technologies, we owe it to the public to create a legal profession with sufficient tech literacy, above and beyond what is typically understood to be included in the duty of technological competence in jurisdictions where this applies (i.e. “know enough not to mess up”).