Bitcoin <> Blockchain <> Cryptocurrency, many folks talk like these words are synonyms. I prefer to refer to the family of technologies as Crypto-Chain (CC) here because not all blockchain is used for currency, and not all “blockchain” even uses blockchain.

Blockchain has its roots in the 1960s. Blockchain can be used to create a distributed consensus database, with plenty of hashing tossed in to make things secure, or to require access to two nodes to get to read a full transaction, or other ways to force concurrency / consensus. Consensus merely means that information is stored in multiple locations, so changes in less than half of the locations can be detected. The consensus requirement augments the hashing techniques to make the data “immutable.” There are multiple incompatible implementations of blockchain.

CC Applications address six types of problems when used as a distributed ledger in the Internet of Things:

1. Creating / Tracking Identity (IIoT). While we rely on government-assigned identities for people and for corporations, these must be created for systems and instances of applications.
2. Recording contracts. While we record contracts at the courthouse, CC track promised relations and actions between two identities in the ledger.
3. Reputation Management. Once we have immutable contracts, systems can track how well partner systems perform (derived from 1, 2).
4. Settlement. For many cryptocurrency users, only settlement, that is the exchange of currency between identities, is worth tracking.
5. Distributed consensus logging of any kind transaction or event. Overall system performance and reliability of distributed systems can be improved if telemetry of sensors and events can be tracked locally and immutably.
6. Secure channel communication. CC can use Identity and hashing to replace 3rd party certificates in TLS-similar communications.
   

While (4) Settlement receives the lion’s share of attention, all of these are necessary to reap full advantage of a CC technology.

Bitcoin is the best-known blockchain implementation that is used primarily to exchange cryptocurrency. Bitcoin was designed to be compute intensive.  Bitcoin is limited almost exclusively to settlement, and making it expensive to mine (create new coins) was a design goal. Bitcoin transactions have low transactions per second (TPS), and the TPS is getting lower as the underlying blockchain grows.

Ethereum is a more recent blockchain implementation, written to enable easier distributed processing. Ethereum consists of a virtual machine (EVM) and several scripting choices. Ethereum generally has a slightly better TPS than Bitcoin. Ethereum promises 25 TPS, but since the size of the chain has grown is rarely seen in the wild at better than 10 TPS. Almost all implementations Ethereum are cloud-based.

Hyperledger is blockchain implemented as a more general purpose database than either Bitcoin or Ethereum. While Hyperledger is offered as a service by IBM, it can also be run locally to support local tracking. Proponents have claimed 100 TPS; in any implementation, that will slow as the blockchain grows in size. Hyperledger has an early lead in logistics applications.

There is recently a strong interest in using “blockchain in logistics.” In concept, disconnected events could be tracked locally, without multiple expensive database connections [to a ship the middle of the Pacific]. All concerned parties could use the CC database when they get to shore, each trusting that each transaction was not changed since its creation because of the immutable consensus. Using CC in this way is seen as a way to squeeze the last fat out of the supply chain.

My interests are in using CC to create trusted control systems, that is, systems with a known identity and reputation, in systems that use Transactive Resource Management (TRM) to augment overall performance. TRM generalizes the model of Transactive Energy (TE) to apply to any commodity whose value is determined by time of delivery. In the US, the common transactive services based on the OASIS smart energy communication specifications are preferred. In Europe, it seems that the open source PowerMatcher is the best known open source model for Transactive Energy.

Transactive energy relies on using market dynamics to smooth power loads and optimize power quality within a system of systems. In a simple model, an off-grid microgrid needs to prevent the Air Conditioning and the Refrigerator from running at the same time. TE puts them each in a market, and each maximizes its own budget by not buying at the same time. In this way, spontaneous order smooths the load curve and keeps usage within bounds. A storage battery is a trader, buying low and selling high. Each microgrid can be operated by a micromarket.

Transactive integration does not require systems to know detailed control sequences about their peers; it only needs to know when they want to buy or sell. TRM applies the same principles and communications to other commodities, including capacity, thermal, water, data network traffic, etc.

I am watching closely a new CC project, IOTA, which is based on Tangle. Tangle uses directed asymmetric graphs instead of blockchain. Tangle supports forking a database, to rejoin later, which might be critical in IoT applications that may lose connections to the cloud. IOTA can operate without the cloud if an isolated market is desired. IOTA has been demonstrated running on devices as small as a Raspberry PI.

https://www.reddit.com/r/Iota/

[an error occurred while processing this directive]IOTA has no transaction fees. When I consider TRM inside an office building (10,000 IoT participants would not be a surprise) with transactions happening say once a second, the absence of transaction fees is a must.

It may be possible to manage collection of sensor data in IOTA as well, and stream it to the cloud when needed. Such a model is likely to offer better privacy protection than data gathering in the clouds. The immutability of the database will support auditing as needed. Such an implementation may scale better in cloud applications by using batch transfers to improve network traffic management.

The article below interviewed David Cohen, one of the founding members of the GridWise Architectural Council, on the use of IOTA in Transactive Energy.

https://solarmagazine.com/blockchain-trading-peer-to-peer-solar-energy-trading/

It would be easy to put off learning about CC, to consider that this is all too far in the future. This would be a mistake. The Brooklyn Microgrids, trading energy using Ethereum, have been up for more than a year. Someone who puts this off will be opting not to work with new commodity housing projects that incorporate this approach.

(https://www.greentechmedia.com/articles/read/sonnen-deal-storage-new-arizona-housing-development).

The time to for smart buildings developers to begin working with CC is now.

[an error occurred while processing this directive]
[Click Banner To Learn More]

[Home Page]  [The Automator]  [About]  [Subscribe ]  [Contact Us]