Blockchain 2.0: Exchanging value in the physical and digital world, continuously and simultaneously

As machines are developing into intelligent autonomous machines, they drive their own buying choices. We must accept them as a new customer group with basic needs and change how products and services are designed, defined, communicated, priced and presented to them. Machines will develop their own ways (protocols) to communicate and discover services they need and exchange physical and digital value among each other. These new infrastructures and protocols might be built upon a combination of blockchain and AI/ML technology [1].

Maslow Pyramid for Human and Machine Needs Examples of basic physiological machine needs are energy, heating/cooling, consumable physical supplies, connectivity including data streams, (external) computing power and ongoing services. Many of these physiological needs are fulfilled by a liquid stream of a supply medium: electricity, gas or liquid fluid, usage based connectivity, real time data streams, time-based access to a physical service, a digital API or digital asset or usage based insurance services. A machine is giving either another supply medium or digital assets back in return for such a supply medium. This type of a continuous transaction among at least two or more machines is called a Liquid Supply Medium Exchange.

The concept of Liquid Supply Medium exchange can also be applied for human-machine transactions — think entertainment media stream streaming or usage based service — and hybrids teams of humans and machines.

This first part describes discrete blockchain payment methods including Ethereum or zCash and introduces some selected blockchain technology options such as Ethereum Raiden or µRaiden payment channels, Bitcoinlightning payment channels, or IOTA flash channels by using the practical example of Electric Vehicle (EV) Charging: Exchange of electric power and crypto-currency tokens between a charging pole and a vehicle.

We think that EV Charging is a typical use case as initial implementations of blockchain EV charging infrastructures have already been implemented including a Pan-European CV charging network over the last months by innogy SE and Motionwerk GmbH [2], [3], [4], [5]. This use case concept can be easily transferred to other examples as well.

In the second part of this article we describe an alternative approach to the blockchain payment channels by using digital asset transactions in blockchain databases (BigchainDB) and hybrid solutions in combination with payment channels. In addition we will introduce a new transaction type for digital twins of machines.

Liquid Supply Medium Exchange

In today's world fiat currencies, or cash, are the most liquid assets, because they can be "sold" for goods and services instantly with no loss of value. There is no wait for a suitable buyer of the cash. There is no trade-off between speed and value. It can be used immediately to perform economic actions like buying, selling, or paying debt, meeting immediate wants and needs. [6]

Today, digital and physical transfers are done via financial services involving banks by using fiat currencies. This (liquid) fiat money transfer system does not support Liquid Supply Medium Exchange in an effective way. There are always intermediaries and discrete processing steps required. The system is neither flexible nor (cost-)efficient enough — think of complex core baking and corporate ERP systems— nor protects the privacy of the parties involved in both, the new digital and the new machine economy.

In the new world where machines are continuously transacting physical and digital values a peer-to-peer (P2P) token streaming system is required. The adoption of today's discrete payment methods and Third Party Intermediary (TPI) Services will not work to automate micro-transactions among billions of machines (and with humans).

Continuous Liquid Supply Medium Exchange and P2P Token StreamingIn a simple case a physical or digital value is exchanged between two machines while a digital token of value is transferred simultaneously. This liquid supply medium exchange requires a continuous payment method.

Typical requirements of a continuous payment method are:

1. Transaction Privacy
2. Direct counterparty transactions among entities that have never met before (no need for ERP master or contract data systems)
3. Plug-and-Play for simple, fast and fair value exchange method
4. Eliminated or marginalized credit risks
5. (Almost) zero transaction costs
6. Scalable Transaction Layer
7. Proven cryptographic primitives and protocols
8. Partition-tolerant, off-line machine-to-machine transaction method
9. Automated service discovery

As of today, there is no scalable (peer-to-peer) payment method for either physical or digital continuous transactions. There will be very soon a huge demand for and working implementations of such a payment method.

The Electric Vehicle Charging Example

One of the easiest to understand examples of a Liquid Supply Medium Exchange is the Electric Vehicle Charging use case.

In today's world back-end systems are authenticating users, controlling the energy exchange, getting meter data from a charging pole and performing a financial transaction while involving financial services and roaming providers.

In the new machine world these back-end systems and processes will not exist any more. A pole and a vehicle with a crypto wallet are simply doing a direct counterparty physical and financial transaction at the same time that is executed on a decentral, privacy-preserving peer-to-peer infrastructure.

Discrete Payment Methods with Blockchain

We are now discussing a charging transaction between an electric vehicle (or its driver) and a charging pole. We assume that we can trust the charging pole (or its data oracle) that the meter reading data inside the EV charging pole are not tampered with. The public charging poles are registered on a public blockchain listing its service and reputation. This listing can be seen as a very basic form for Service Discovery.

Existing reference implementations via blockchains are using for example Ethereum smart contracts [3], [4]. With these smart contracts discrete payments methods are adopted by using escrow payments and a neutral smart contract business logic to release the escrow payment to the charging pole and the vehicle after the physical charging process is finished (or the escrow balance is zero).

The escrow payment release is calculated based on validated smart meter energy data that is delivered by a data oracle into the smart contract. Transactions credit risks for the charging pole and the vehicle are mitigated by the neutral smart contract business logic.

High-level Ethereum Smart Contract Transaction for EV CharingIn current practical implementations, connecting entire charging infrastructures, individual charging poles are aggregated on a gateway level and the gateway is connected to the blockchain. For the time being, in this retrofitting case the infrastructure is trusted form the pole to the gateway.

A variety of blockchain tokens can be used including native crypto currencies such as BTC or ETH or asset-backed ERC 20 tokes such as Crypto USD/EUR/RMB (linked to bank escrow via a payment gateway) or tokenized physical assets or ICO tokens.

Discrete Payment Method with TEEs for Off-chain Smart Contract Business Logic and zCash Shielded Transactions

One extremely important aspect for transactions is transaction privacy [7] [8]. We pretty much like the concepts using of modern cryptography for privacy-preserving coins such as zCash or Monero. We now focus on zCash and its underlying zero-knowledge proof cryptography.

An alternative approach to the above described on-chain smart contracts is the of use trusted execution environments (TEE) and the deployment of smart contract business logic in the TEE. A TEE is registered on the blockchain and gets its own zCash wallet to store escrow payments. The off-chain business logic is then releasing the escrow payment to the two parties based on authenticated oracle data from the charging pole about the value of the physical transaction.

In an early zCash concept discussion options for this privacy-enabled escrow mechanism using zk-SNARKS were identified [9].

It should be understood that it is possible to add Zcash-style privacy to any blockchain. In fact, Zcash itself is effectively a Bitcoin-style blockchain with the zero-knowledge security layer (ZSL) added. Transparent transactions take place on the Bitcoin layer and shielded transactions take place on the ZSL layer.

So, people are starting to add ZSL to Ethereum, and thereby benefit from its full Solidity smart contract capabilities. Ethereum and Zcash communities are doing research in this directions. However, for the purpose of the post we will focus a practical approach for privacy-enabled machine transactions. We think it would be simpler (right now) to replace the blockchain escrow wallet by an off-chain Trusted Execution Environment (TEE) with a pre-compiled contract that the parties can call via the blockchain.

In the EV charging transaction example, the vehicle (or the driver) want to charge her battery while not disclosing the identities. The public charging pole is registered on a public blockchain listing its service.

Option 1) Transparent Escrow

The Driver must unshield the deposit funds to place them in TEE escrow. This will reveal to a third party observer that (a) a charging interaction is taking place, and (b) how much has been deposited in escrow. It will also be apparent to a third party observer if an escrow timeout occurs. However, the identities of the Driver and Pole are protected (the payments from the Escrow Address that split the deposit between the Driver and the Pole will be shielded).

Option 2) Shielded Escrow

All funds transfers will be shielded, and no information regarding the charging interaction will be available to a third party observer. Implementing the Shielded Escrow is not yet possible because this option requires making changes to the cryptographic circuit in the Zcash source code.

Notes:

• Further considerations and limitations regarding zCash and an alternative implementation with the HAWK protocol are laid out in the ADDENDUM.
• Teechain, a combination of TEEs and payment channels, is also a compelling concept for secure and scalable payment channels which is briefly laid out in the ADDENDUM as well.

P2P Token Streaming Payment with Blockchains

In general, a smart contract discrete payment method is complex, not yet scalable and requires payment of gas fees to public chain networks.

P2P Token Streaming

An alternative solution is to use P2P token streaming instead of discrete escrow payments.

Example of a Liquid Supply Medium Exchange with P2P Token StreamingIn the P2P token streaming one of the entities starts to stream either one micro-energy package or micro-token asset which is released by a module in one of the entities. A measuring module in the other entity (e.g. meter reading or token wallet account balance query) is confirming the inflow and releasing a micro-energy package or a micro token respectively. A control unit in at least one of the entities synchronizes energy and token streams.

The same unit might synchronize the streams with other external factors such as control signals from grid control systems or dynamic pricing data from local power markets. This approach takes availability, volatility and price of (renewable) energy in power grids into consideration. Depending on the situation and the transaction agreement with the vehicle the control unit might reverse the token streams and feed energy back into the grid in case of constrained local energy supply.

With the synchronization of the energy and token streams the credit risks is dependent on the micro-energy package or micro-token value which is released first. This "Plug-and-Play" approach results in infinitesimal small credit risk or a marginalization of the credit risk.

We all might understand that the CV Charging Examples can be generalized to other continuous payment examples inducing for instance time-based access to physical or digital assets or real time data streams.

There are different options how to establish a P2P Token Streaming for Liquid Supply Medium Exchange with existing blockchain technology.

Token Streaming via State and Payment Channels using Ethereum Raiden and µRaiden Network

One continuous payment method requirement for a Liquid Supply Medium Exchange is scalability. In case of a public blockchain networks like Bitcoin and Ethereum — which rely on proof-of-work for mining — the payment throughput handling capacity is limited and P2P token streaming is not possible.

The scalability requirement can be realized by using a permissioned blockchain network, which relies on consensus algorithms such as PBFT, Proof-of-Authority or Proof-of-Stake. However these permissioned networks are also not designed to run multiple token streaming sessions on chain in parallel.

One possible other (future) solution is usage of Raiden payment channels, which enable direct token streaming interactions between participating nodes [10]. A first implementation that is focused on one-to-many channels is µRaiden Network which is already operational now. There is future Raiden Raiden Network will support bi-directional multi-hop payment channels. The team is right now working on multi-hop path-routing protocols. The µRaiden Network supports already today many-to-one uni-directional payment channels. With µRaiden a retrofitted EV charging infrastructure with one µRaiden node at the EV charging gateway level can be supported to allow token streaming for one-directional charging transactions.

As on these networks the transactions happen instantly and do not have to be mined on the main blockchain the payment channel transactions are much more scalable. This results in the following technical features:

• Instant Payment — Payments do not need block confirmations on the main chain, and are instant and atomic. Payment channels can be used for device-to-device transaction or in any scenario where instant payments are needed.
• Micropayments and Mircro-Token Streams — Using payment channels high frequency micro payments with zero transaction fees can be enabled whereas Bitcoin / public Ethereum blockchains have a fixed per-transaction fee, which makes micro-payments impractical.
• M2M interactions — For the EV charging use case that leverage internet-connected devices the support for machine-to-machine payments and automated micro-payment services is be required. Payment channel transactions are conducted off the blockchain without delegation of trust and ownership, allowing users to conduct nearly unlimited transactions between other devices.

In general state channels — state channels as an abstraction of payment channels, allowing to have off-chain common transactions, not only Token payments — work by establishing a multi-signature address between two participating nodes on the main blockchain network. For spending both parties need to agree on the target balance. The current balance is stored on the participants side (not on the chain) as the most recent transaction signed by both parties, spending from the channel address. Any number of payment transactions or asset transfers are possible between any of the nodes provided exchange of secure cryptographic hash is fulfilled, while the custodianship of the funds is still with the main blockchain.

These state or payment channels can be chained together, to allow for multi-hop token transfers or payments between parties, which are not directly linked in a bidirectional payment channel (core feature of the Raiden Network). The bidirectional payment channel will support a bidirectional EV charging process in which energy can be released by a vehicle battery in order to inject energy in a (public) when energy supply is not fulfilling energy demand.

In order to increase the reliability of the charging process micro-payments can be released from the car's wallet to the charging pole depending on delivered energy packages and the charging pole will continue the process. At any point of time if the payments stops or the wallet runs out of funds the charging will also stop. Thus, numerous such micro-transactions are possible which need not be handled by the main blockchain network. One of the options on how to use the Raiden Network for this scenario is depicted above.

Here is how the Raiden Network will enable the micro-payment process (asset transfers).

• The micro-payment asset transfer is initiated on the main chain (if no channel is already present or a path is not found).
• Transfer Manager gets Channel info from Asset Manager, transfers are registered on Channel
• Off-chain bi-directional asset transfers are accomplished after validating nonce and security details (especially by a signature signed by the private key, making it as secure as Blockchain transactions)
• At any time the channel can be closed by either of the parties
• On-chain smart contracts facilitates the settlement

Raiden and µRaiden can be used to establish a payment channel framework for fast & free off-chain ERC20 token transfers. This enables to stream Crypto USD, EUR, RMB or ICO tokens [11] [12] as well as wrapped ETH(WETH) uni-directionally between two parties. µRaiden is already deployed on the Ethereum mainnet and will soon release version 0.2.0. This payment channel method also requires a deposit/escrow on each channel.

The ability to establish P2P token streaming capabilities among machines, is currently being explored by companies such as slock.it (Universal Sharing Network), Energy Web Foundation and Motionwerk GmbH.

Similar solutions can be envisioned with the Bitcoin Lightning network as well. Key differences are that Raiden is not limited to the underlying native token of Ethereum as the BTC lightning channels are. Another difference is that Raiden uses another approach to lock token. Raiden locks tokens via Smart Contracts and is not using a combination of segregated witness specifications, multi-signature commitment transactions, hash and time locks as used in lightning and thus is easier to understand and maintain.

IOTA DAG Tangle Flash Channel

IOTA Foundation introduced a first scalable distributed ledger architecture that has no transaction fees and is able to execute transactions in the Internet of Things system. The "no transaction fee feature" makes the IOTA DAG tangle an interesting option for P2P token streaming implementations.

To further improve scalability, IOTA flash channels, a bi-directional off-Tangle payment channel enabling instantaneous, high-throughput transactions, has been introduced [13].

Flash channels are similar to Raiden and Lightning. They are an early IOTA technology implementation that provides a method for parties to transact at high frequency without waiting for each transaction to confirm on the public IOTA network. The technology still needs to be validated in field tests and in reviews of the underlying cryptographic and game theory model of the main Tangle.

IOTA Smart City EV Charging and Payment Simulation (Source: IOTA Foundation)Flash channels reduce the per-transaction overhead to a negligible level by creating signed, feeless transactions. This results in a more plug-and-play type of EV charging implementation without any smart contracts.

The elimination of a smart contract in this approach should not be underestimated in order to achieve a simple, interoperable transaction protocol that does not depend on mining of blocks.

During the token streaming the channel does not need to be connected to the main network until the channels are closed which provides an off-line, partition tolerant capability for future implementations.

Another aspect is that the transaction identities are created on the fly buy using one-time signatures which masks the identities involved in the payment transactions for privacy purposes.

Elaad and Enexis in The Netherlands are exploring the application of IOTA for EV charging [14]. Bosch is exploring the use of IOTA for a variety of mobility use cases including a wallet in a car and other IoT applications. The IOTA foundation is currently running simulations for EV charging to evaluate the technical performance [15] [16].

Conclusion

P2P token streaming is an innovative payment method for liquid supply medium exchange of physical and digital media. It relies on an infrastructure network and a protocol that is providing the token streaming service.

This new payment method is eliminating credit risks as well as intermediaries. In addition it eliminates escrow business logic somewhere else. Typical escrow business logic is run by today's complex ERP and payment systems, a third party, a smart contract or a trusted computing enclave.

The P2P token streaming is built upon a simple principle: Lock something on the main chain and assign it a connected system with a (much cheaper) consensus algorithm.

Inter-blockchain protocols such as cosmos, interledger, plasma, polkadot or sidechains are using similar mechanisms. These protocols can be understood as forms of (more complex) streaming channels among blockchains.

P2P token streaming is an interoperable Plug-and-Play payment method for direct counterparty transactions with (almost) zero transaction costs at (almost) no credit risks. P2P token streaming will drive significant innovation for the 4th industrial revolution while enabling an efficient supply medium exchange among machines and humans.

Outlook Liquid Supply Medium Exchange for Machines PART 2

In the second part of this article we will introduce the concept of token streaming among digital twins, i.e. the digital representation of physical objects, machines and humans. This concept enables entirely new transaction systems for the 4th industrial revolution.

We will also describe a powerful alternative solution for P2P token streaming and liquid supply medium exchange using digital assets in Blockchain Databases such as BigchainDB, the interlegder protocol and its integration with Ethereum and IOTA and other existing payment channels concepts.

We acknowledge the help of and the discussions with our valued colleagues Jack Gavigan, Heiko Hees, Alexander Culum and Dominik Schiener to write this article.

About the Authors:

Dr. Carsten Stöcker is founder of Spherity GmbH. Spherity is a scalable decentral platform for the 4th industrial revolution providing secure identities and digital twins bridging the physical, biological and digital spheres.

Carsten.Stoecker@spherity.com | Twitter: Carsten Stöcker

Dimitri de Jonghe is co-founder and Technical Architect of Spherity GmbH. He worked as head of application engineering at BigchainDB and is now one of the core protocol designers for Ocean Protocol.

Dimi@bigchaindb.com

Dr. Michael Rüther is CFO/COO and co-founder of Spherity GmbH. Prior to joining Spherity Michael founded two ventures in the IT and innovation space. Michael has a cross-industry technology background.

Michael.Ruether@spherity.com