Blockchain is hot right now, not only as the underpinning of bitcoin, but because it has the promise to be a disruptive technology in multiple sectors. I started my exploration of how it will impact electricity’s transmission, distribution, and sale in “Bitcoin’s Hot But Blockchain For Cleantech Is Interesting,” and continue in this three-part series of articles on the nature of smart contracts based on blockchain technology.
Part 1, this one, lays out the technical and business underpinnings of smart contracts.
Part 2, “Blockchain Contracts for Electricity: Business Drivers,” lays out 9 factors which can be used to determine where smart contracts will shine and where they won’t.
Part 3, “Blockchain Contracts for Electricity: Sweet Spots,” looks at the implications for different business models in general and for the electrical generation and distribution business overall.
All articles on cleantech + blockchain are also being published on https://future-trends.cleantechnica.com/cleantech-blockchain/
The Nerdy Underpinnings
Skip this section if you only care about the implications of smart contracts for business, but it does provide context for why some of those implications exist. It only contains elements of relevance to the business discussion and it’s not nearly as nerdy as most explanations.
A smart contract is a computer program that runs on blockchain. Typically, that means it runs on the distributed computers which choose to support blockchains. In bitcoin and Ethereum terms, it runs on the computers of the miners. In Hyperledger, it runs on the consensus cloud and on the validators’ computers. Among other things, this means that a smart contract is running in a bunch of places at once and consuming computing resources. This isn’t parallelism, but multiplicity, and requires management so that excess resources aren’t consumed. Ethereum uses the concept of gas, which is the measure of the amount of resources a smart contract uses during execution, and provides some tools for management of it.
Smart contracts are typically constrained to the blockchain’s architecture. That means instructions are constrained to the size of a transaction in a block and variables are equally constrained to the size of a transaction. In Ethereum, that’s 256 bits or 32 bytes. Due to the nature of blockchain itself, the memory architecture is a stack, which means that it’s static. Modifying variables means adding a change to the top of the stack as a transaction.
This constraint also means that smart contracts can only see things which are entered into the blockchain by a transaction. If, for example, you wanted to use a US dollar exchange rate on a certain date, something which has a use I’ll explain later, an external program would have to read the exchange rate and insert it into a variable in the blockchain for the smart contract to read.
Cryptocurrencies are built on specific blockchain technologies. Smart contracts run on exactly the same blockchain technology and at heart only understand the cryptocurrency of the blockchain technology they execute on. If you run a smart contract on Ethereum, you can only use the ether cryptocurrency. Cryptocurrencies and their associated smart contracts are tightly coupled. For those following along with the series, this is in contrast to the loose coupling I articulate as a value proposition for innovation in “7 Reasons Why the Future is Electric,” but it may not be as important to innovation in this context and it is possible to hedge for at least one downside of this coupling regardless.
Last, but not least, is that transaction times vary from a likely minimum of 15 seconds in Ethereum to a likely minimum of close to 10 minutes in bitcoin and a potential maximum of hours in bitcoin in high-volume periods.
If your eyes crossed reading the above, trust me that reading the actual coding languages and approaches would make your eyes cross more. This is why templated contracts are starting to emerge, and why standardized contracts for specific types of services and products will emerge as webpages and in apps. After all, when you buy something on Amazon or check delivery status on UPS, you don’t write code to do it, you just use your computer or your phone.
The Business Underpinnings
A smart contract that involves contracting a payment for services to be rendered or a product to be delivered involves three separate accounts: a purchaser, a seller, and an escrow account. Escrow is a means of creating trust in a contract where there is none. In an escrow situation, a third party holds something of value from the purchaser until a certain condition is met by the seller, at which time they deliver the thing of value to the purchaser.
As an example: Jill wants to sell her guitar. Bob wants to buy it and is willing to pay $500 for it. Jill and Bob don’t know one another. They agree that they both trust John to hold the money until the guitar gets to Bob. Bob uses email money transfer to send $500 to John. When the guitar is delivered, Bob texts John that it has arrived and it’s as advertised. John uses email money transfer to send the $500 to Jill. If the guitar never arrives, then Bob gets his money back. Obviously, there are details missing in this simple example — such as delivery fees, transaction fees, a fee for John for his trouble, and a security measure to ensure that Bob doesn’t lie about not receiving the guitar, but that’s the basic idea.
In cryptocurrencies, the purchaser and seller accounts are called wallets, and typically the contract itself acts as an escrow account. I won’t bother stepping through the code and nuances, but those who are interested can look at this Ethereum example. The business implications are more interesting and will be explored in the next section.
The example above lists some missing details that smart contracts have to enable. Delivery fees to a delivery organization such as DHL or UPS have to be managed, and can be managed by adding the organization as another party to the smart contract if they have a wallet. Transaction fees start to abound in this model, as every shifting of coin is a transaction with a cost, such as Ethereum’s range of $0.50 to $1.50.
The escrow cost is the additional cost of moving the coin into the escrow-holding contract, which will be a lot lower than third-party escrow costs. For home sales in California, there are typically base costs of $175 to $250 plus $1.75 to $2.50 per thousand of the purchase price. For a $300,000 condo, that would mean $700 to $1,000 of fees to the escrow agent as well as any banking transaction fees. If that were transacted through Ethereum solely in ether, the escrow cost would be around a dollar.
What smart contracts don’t really support are typical payment terms, such as net 30 (which means payment of the net amount is due 30 days after receipt of invoice or bill). This is a very typical contractual type and we all have them with our cell phone providers, our electrical utilities, and the like. They are fundamental to most service delivery offerings. They are also fundamental to most delivery of goods for business purposes. Electronic commerce has trained us to think of delivered goods as being paid for at the time of order, but in business goods, delivery is contracted with more sophisticated payment terms. Frequently, ongoing order contracts for things such as natural gas for a combined-cycle gas generation plant are based on monthly delivery volume with month-end invoicing and net 30 terms.
Blockchain smart contracts aren’t all powerful. Their technical and business underpinnings are both two-edged swords.
The next article, “Blockchain Contracts for Electricity: Business Drivers,” lays out 9 factors which can be used to determine where smart contracts will shine and where they won’t. It will explore strengths and weaknesses and start to define where this contract will be of most value.
As always, I’ll be paying close attention to comments. If I’ve mischaracterized something or made other mistakes, please let me know. Similarly, if there are emerging smart contract examples or utilities accepting cryptocurrencies, point them out to me, especially in non-English language countries.