Stop owning, start streaming and sharing physical products
In the digital realm there has been a strong shift from owning products to using services. We don’t buy music anymore, but we listen to music with Spotify. We don’t own servers anymore, but we use storage and compute from Amazon Web Services. Instead of owning a product and having to take care of maintenance and all these complexities, we only pay for their usage.
In the physical world this trend has not been as profound, although there are surely examples. An early example was the „Power-by-the-hour“ business model invented by Rolls Royce. Instead of selling an airplane engine, they billed for flight hours. These business models align the interests of manufacturer and customer, decrease capital costs for the customer and provide a continuous revenue stream to the manufacturer. Connected products allow to bring these business models to many more product categories, since usage of the products can be tracked in real-time.
Still, accounting and billing can be a challenge. In particular if the product can be used by different customers or if we look beyond the developed world to developing countries with rudimentary financial infrastructure.
Decentralized digital currencies like Bitcoin and Ether have promised to provide an electronic cash equivalent which allows to provide ad-hoc payments of any size without complex contracting, accounting and billing. However, it has turned out that using the base network directly for payments is costly and rather slow. Hence, we are very excited about the development of higher layer networks that finally allow for instant payments on the order of cents and even less. This enables the streaming of payments. For the customer this means that there is no need for long term contracts, there is no need for large pre-payments that might be hard to reclaim if the product does not work as expected. Also there is less need to share personal information. For the business, accounting simplifies tremendously, and there is no need to collect money. Also not having to store customer's personal information for accounting and billing reasons decreases the liabilities stemming from the new General Data Protection Regulation (GDPR) by a lot.
We decided to evaluate the state of the furthest developed "Layer 2" payment technology, the Lightning Network, by implementing a pay per use model for Bosch's successful autonomous lawn mower Indego.
The Case
For the autonomous lawn mower the case might be not so much about high capital costs, but more about the potential to be shared with neighbors. A lawn mower is idle most of the time and could be used to earn some extra money.
What if a lawn mower would be payable by default
What if a lawn mower would be payable by default. As an owner you could make your lawn mower available via setting in your smartphone app. Someone with a garden could search for a lawn mower close by, pay some money into a smart contract as a deposit, get the lawn mower, and the lawn mower will start mowing. The lawn mower (or its owner) can be paid minute by minute if the rentee is not sure about the performance of the mower. Thus, the financial risks for rentee and renter are minimized. Finally, the mower has to be returned in time in order to reclaim the deposit.
Goal of the Evaluation
The evaluation is not so much about the particular use case, but about the state of the technology. We have made early investigations into the concept of paying connected devices by using decentralized digital currencies (you can read about it here, here and here)and the concept of sharing connected devices by using smart contracts. However, decentralized digital currencies moved by base layer transactions have turned out rather expensive and slow. Hence, they are not able to provide the required instant micropayments for trust-minimized economic interactions between software agents. So called "Layer 2" technologies are promising to close this gap. From an engineering perspective, the most advanced "Layer 2" technology is the Lightning Network which is based on the Bitcoin network and its derivatives. The goal of this project was to get exposure to the current state of the technology, its implementations and their interplay. Furthermore, we wanted to get an idea of the required computational resources. Therefore, we tried to put as much of our technology stack as possible on a Raspberry Pi 3.
A Brief Primer on Lightning
The Lightning Network is an advancement of the early idea of payment channels. Payment channels allow a large of number of tiny and instant off-chain payments with only two on-chain transactions. You open a channel with a counterpart (one transaction) by commiting some money. Then you'll be able to update the balance with transactions that can be kept private between you and your counterparty. You can accept these balance update as final and hence payments become fast and cheap. Each transaction that gets exchanged is a valid Bitcoin transaction and can be submitted to the Blockchain. However, the protocol is structured that you can get penalized if you submit another than the latest transaction you agreed upon.
The Lightning Network adds the idea of trustlessly routing payments between channels. Imagine you have a channel with your Bitcoin exchange and your Bitcoin exchange has a channel with the New York Times, then you could make a trustless instant micropayment to the New York Times without having a direct channel.
A very good introduction to the mechanics of the Lightning Network can be found in a series of articles by Aaron van Wirdum.
You can have a look at the current topology of the Lightning Network here.
Architecture
Although Indego has a Cloud backend, we deliberately chose to set up a local architecture. Therefore, we augmented the Indego directly with a Raspberry Pi. The Indego provides a serial interface via USB for testing and troubleshooting. Based on the serial interface we implemented a small web server to expose parts of the serial interface as a REST API.
The business logic was implemented in the Lightning Mower Application which interacts with an abstraction of a Lightning client, the mower API, and serves a web app for user interaction.
The are currently three major implementations of Lightning Network clients:
- c-Lightning
- LND
- Eclair
We decided to use c-Lightning as a client implementation, since there is a helpful wrapper called Lightning Charge available which provides many useful services as REST APIs, as well as web hooks. Lightning Charge simplifies the process to accept Lightning payments in web application tremendously.
Since we also wanted to test the interoperability between the different Lightning implementations, we used the Eclair Android Wallet for manual Lighting payments to the mower.
As illustrated in the following figure, most of the technology stack runs on a local Raspberry Pi. The only main building block that we decided to run on a more powerful remote server is the Bitcoin Core client. In principle, a light client implementation is sufficient for an interface to the Bitcoin network for a Lighting client. With a light client the operation on a Raspberry Pi 3 should be easily manageable. However, currently only LND has (experimental) support for a light client implementation. In contrast to a regular Bitcoin client (i.e. a full node) which verifies, broadcasts and stores transactions and blocks, a light client downloads only block headers (80 bytes per block instead of 1+ MB) and Merkle proofs for transactions of interest (+ some overhead for privacy reasons).
Implemented Flow and User Experience
We implemented a stripped down version of the case presented above. Essentially, we implemented a way to pay the Indego per second in order to demonstrate the possibility for instant micropayments.
The Lightning Mower Web App has an admin interface and a customer interface. The admin interface allows to set a price and the customer interface allows to set the timeframe for renting. The Web App then shows a freshly generated Lighting payment address as a QR Code or opens a Lightning enabled wallet if installed on the customer's device.
For the demo, we pre-opened a Lighting channel between our Eclair Android Wallet and the c-Lightning node on the Raspberry Pi. After that payments are instant and the mower begins mowing.
Learnings and Outlook
Implementations of the Lightning Network are finally becoming usable and may provide the basis for pay-per-use schemes of digital services and physical devices. Once a channel is set up, payment become cheap, instant and easy. In fact payments on the order of 0.00005 EUR become possible. However setting up a channel (as well as closing) may take tens of minutes to hours and costs on the order of 10 cents. Having a channel with a specific lawn mower probably does not make too much sense. However, as explained earlier, Lightning payments can be routed across channels. One possible scenario would be Bosch providing a Lightning payment hub for their products, such that a customer would only need a single channel with Bosch to be able to pay a multitude of products and services. The important thing however is that, while this would be very convenient, it is not mandatory. You could still pay directly or you could start being a hub.
It will be interesting to see if the Lightning Network will continue to increase traction (or solutions tied to other platforms such as State Channels, Perun, or Plasma for Ethereum). If the technology gets widespread adoption, we could make the shift to streaming payments and a lot of business and accounting processes could be simplified.
We continue to stay close to this paradigm change. Contact us to discuss the potential of straming your products.
Bosch Digital Solution is a Think Tank and solutions provider based at ETH Zurich. We are working closely together with the Bosch IoT Labs, the Bosch Economy of Things R&D project, and Bosch Business Units. We provide end-to-end solutions. From innovative proof of concepts to scalable products, and from secure hardware to reliable cloud services. Visit us at https://bosch-digital.ch
