Should Developers Start Thinking Like Lawyers?
Should Developers Start Thinking Like Lawyers?
As blockchain begins to take root, it's important to consider - as with all code - the potential for misuse. Start protecting your work now by preparing ahead of time.
Join the DZone community and get the full member experience.Join For Free
Blockchain is certainly the rage. No matter the industry, you can’t seem to have a technology discussion before the topic is raised. According to Gartner’s latest hype cycle for emerging technologies, blockchain is approaching the peak. It is considered by Gartner as one of the ‘Key platform-enabling technologies to track.’ Approximately $1.4B has been invested in Blockchain just this year, according to PwC executive Seamus Cushley. While there is a lot of ‘hype vs reality’ discussions going on, there is no arguing that blockchain is being taken very seriously across industries and cannot be ignored.
In its simplest terms, blockchain, is a distributed ledger. However, the reality is much more complex than that. Some of my earlier blogs on blockchain examine some of those complexities (‘Blockchain – It’s So Much More than Bitcoin’, ‘Blockchain – You want me to trust a trustless system?’). One of those complexities is the concept of Smart Contracts in the blockchain eco-system.
What Is a Smart Contract?
The concept of ‘smart contracts’ actually pre-dates the blockchain. The term was originally coined (no pun intended) by computer scientist Nick Szabo back in the mid-90’s. He defined the concept as "a set of promises, specified in digital form, including protocols within which the parties perform on the other promises." A smart contract ultimately is code that defines an agreement between two parties based on certain conditions. When the conditions occur, the smart contract code is executed. The key to the smart contract is that it addresses four basic contract objectives
- Observability: Allow both parties to observe the execution of the contract (code).
- Verifiability: Allow either party to verify if and when the contract (code) has executed.
- Privacy: Guarantee only information necessary for execution of the contract (code) are revealed.
- Enforceability: Self-enforcing of the rules of the contract (code) to eliminate need to police the execution.
While the concept has been around for a while, blockchain now provides an ecosystem and framework to be able to address those objectives, and greatly enhances the capabilities and possible use case scenarios for blockchain.
Let’s take a simple scenario discussed frequently in this context: purchasing a digital copy of a song.
Let’s Buy a Song
When a song is sold, there are agreements in place to give a piece of that sale to various parties, the composer, the performer, the distributor to name a few. In the traditional model, the sale is tracked, information accumulated, and reports generated. These sales reports are used to generate the payment information for each of the individuals. There are lots of layers, and frequently disagreements ensue in the reporting of the sales and the payouts made to various individuals. Part of the reason for the complexity and delays is that each individual sale is a very small amount. The percentages even smaller. The overhead of executing micro-payments in existing systems is prohibitive.
Now imagine executing the sale in a blockchain ecosystem. Blockchain and micro-payments are a common scenario. In that ecosystem is a smart contract. It defines the percentages of a sale each individual is to receive, and where to send the amount. When a sale occurs, the contract is invoked, and each individual immediately receives their portion of the sale through the blockchain. Additionally, each individual has an indelible ledger of all the sales transactions to review and validate.
Blockchain Does Not Protect Against Bad Coding
As I was writing this blog, I was chatting with my son, who is a first-year law at the University of Michigan. While he was describing what he was studying and his class work, he described something that struck a chord. He talked about how that his class work isn’t coming up with the winning argument. It’s about coming up with possible arguments, and, more importantly, coming up with what the response and attacks on those arguments might be.
It reminded me of something I talk to our junior developers about and include in a training program for new associates. I tell them: when developing an API you will be exposing to others for consumption, it is imperative to practice what I call ‘defensive programming.’ You must look at your API, and how it could potentially be misused, intentionally or unintentionally. We all know the happy path scenarios in our code, and how we intend it to be used. That’s the easy part. The hard part is looking at our code dispassionately for the un-happy paths, and protecting from those scenarios.
Smart contracts in a blockchain environment ultimately are still just code, and subject to the same challenge. The high-profile issues with the DAO hack this past summer is a great example. The hackers leveraged a smart contract in the DAO Ethereum blockchain, and took advantage of a flaw in the code that allowed them to transfer $50M in assets to them. They didn’t, as some first thought, ‘hack the blockchain’. They examined the smart contract, saw a flaw, and executed on it, using the contract in a way the developer had not anticipated.
No Technology Negates the Need for Good Design and Planning
As many of you know, one of my mantras is ‘no technology negates the need for good design and planning’. Blockchain and smart contracts are no different. The combination of smart contracts in the blockchain ecosystem is a very powerful tool in helping to provide solutions to a multitude of business challenges and goals. The magic does not happen by itself. Simply creating a blockchain and a smart contract does not guarantee it cannot be intentionally or unintentionally be mis-used. It is up to us as technologists, to ‘think like a lawyer.’ They must not just come up with the contract that will solve the issue, but must look at the potential responses that could negate its value, or create unintended consequences. Then we can leverage the new tools in our toolkit to continue to provide value and solutions to the business.
Published at DZone with permission of Ed Featherston . See the original article here.
Opinions expressed by DZone contributors are their own.