• Digital Transformation
  • Blockchain
  • Bitcoin
  • Digital Currencies

Transactive Energy Startups Do Not Care About Bitcoin—and Neither Should You

Johnathon de Villier
Sep 10, 2018

Cybersecurity

Blockchain is over hyped. It is customary to begin every article that touches on distributed ledger technologies (DLTs) with something along these lines, and that is because it's true. For most, even those that follow the industry, blockchain is still a black box. Input data, magic happens, output efficiency or cybersecurity or profit or insert desire here. Criticism and skepticism are warranted and necessary when presented with this too-good-to-be-true equation. There is, however, a persistent trend in blockchain reporting that refuses to die. It begins logically and ends in total confusion.

  • Step one: Energy-related use cases for blockchain, such as transactive energy (TE), require high transaction throughput (TPS)
  • Step two: Bitcoin uses around 7 TPS and Ethereum uses between 15 TPS and 20 TPS—both have low transaction throughput
  • Step three: Blockchain is therefore unsuitable for the use case in question

The problem is the assumption that because Ethereum and Bitcoin are the two most well-known and highest valued blockchain architectures, the success or failure of DLTs in energy must be related to their characteristics. In other words: all blockchains must behave like Ethereum and Bitcoin. This misunderstanding is both pervasive and wrong. I’ve heard variations of this misconception from conference speakers to utilities and corporate executives.

Throughput Myopia

In reality, DLTs exist in hundreds of permutations and configurations with performance characteristics (including TPS) varying hugely from one to another. DLT is a useful term because it encompasses all these variations. It is true that DLTs will behave similarly to cryptocurrencies and by extension Bitcoin and Ethereum in some industries—but that is not at all the case in energy.

Proof of Work Is Not the Only Way

Energy blockchain developers are generally aware of the energy system’s constraints, and the majority are building solutions on DLTs within those constraints. Consider the data in the following chart about 58 energy blockchain startups exploring TE as a potential use case.

58 Transactive Energy Vendors

58 Transactive Energy Vendors

(Source: Navigant Research)

Proof of Work (PoW) is the consensus mechanism that Bitcoin and Ethereum share (and the foundation of their decentralization and sluggishness). Only 15 TE vendors are building on PoW architectures, and of those, 14 are Ethereum. What about the loner? It is not Bitcoin—it is Dash, which uses a hybrid PoW model with a staking requirement. It should be clear why the specifics of Bitcoin do not belong in TE conversations.

What about Ethereum?

There are 14 TE startups building on Ethereum. But even so, its limits are not terribly relevant. When I speak to startups about why they chose Ethereum over other options, they say something like “it is a tried-and-true platform with a strong development sandbox” or “it has a robust, active community of developers,” or even “most of the limited pool of experienced blockchain developers are familiar with it." None of these responses is "Ethereum is the best platform for TE." Ethereum's advantages are its community and developer environment.

Some startups that used Ethereum early on have since changed platforms to escape high transaction fees and network congestion (e.g., MotionWerk, the company behind the Share&Charge EV charging platform). Look for other startups to do the same once they have a set of working tools and a reasonably stable business model.

It's Time to Move On

Blockchain and DLTs have many challenges ahead—private key management, edge verification, and workable business models are just a few. But for the industry to engage with these real barriers, our collective understanding of DLTs needs to develop some nuance. Let's start with the recognition that not all blockchains are created equal. The strengths and weaknesses of a given architecture need to be evaluated against the specific use case in question, and vice versa.