LISK.BIKE: Engaging JS Developers with IoT & Blockchain

Lisk makes blockchain technology accessible to JavaScript developers, and Lisk.Bike – an open source bike sharing platform built by Blockchain030 at the Lisk Center Utrecht – makes Lisk and the LiskSDK accessible. By inspiring talented developers to start working on blockchain development, Lisk.Bike aims not only to benefit the Lisk ecosystem, but to grow the blockchain industry as a whole.

‍

With the start of 2020, it is time for an update on our progress, lessons learned, and a look forward to what this year will bring. In my previous article, I described that the primary goal of the Lisk.Bike project is to learn and share lessons about using Lisk custom transactions and the LiskSDK for building blockchain applications with only the need for JavaScript skills and toolset. This article starts with a simplified recap of how the Lisk.bike custom transactions work, followed by some challenges and how we addressed these since the start of the project. The article then takes a look at Kryha’s lockchain project, which has a use case similar to Lisk.Bike, but is built on Ethereum smart contracts. This not only helps to gain insights in the difference between using custom transactions vs. smart contracts, but also provides lessons on the important contexts of innovation that are valuable also to Lisk.Bike’s future. The article closes with some highlights of our workshop for JavaScript developers during LiskJS19, and an announcement of our plans to further engage the JavaScript community in blockchain development in 2020.

‍

Progress and lessons learned

LISK.BIKE: How do custom transactions work?

An important objective of the Lisk.Bike project is to contribute to a better understanding of how custom transactions can execute a given set of rules – or, business logic. For this purpose, let us take a look at some of the Lisk.Bike custom transactions, by taking a simplified example of using Lisk.Bike (for further details of the project and code, check out our complete repo on github) :

‍

Bob wants to rent a bike to get home from work. Of course, he already has a Lisk.Bike account, and deposited sufficient funds into his user account. He opens the Lisk.Bike application, locates an available bike just two blocks down the road and as he arrives at the bike, he presses the ‘start rental’ button. After riding the bike home, he locks the bike and automatically ends his rental

‍

As Bob presses the start rental button, the Mobile Lisk.Bike client/application:

1. Looks up the BikeID address in the Lisk.Bike blockchain to identify that the selected bikeID is (still) available by checking the bike’s asset property rentedBy: undefined.

2. Creates a custom transaction, which contains:

        1. A transfer of the required deposit from Bob’s account to the BikeID address;

        2. Updated asset properties to the BikeID account:             

                 rentedBy: Bob’s account
                 rentalStart: Current timestamp.

3. Signs the custom transaction with Bob’s private key.

4. Broadcasts the signed custom transaction to the Lisk.Bike blockchain.

‍

As the custom transaction is broadcasted among the Lisk.Bike nodes, the virtual lock server:

1. Observes the incoming deposit and updated rental status in the BikeID account, and:
2. Opens the lock by sending the open lock command to the smart lock corresponding with the BikeID, allowing Bob to ride the bike.

‍

As Bob arrives home and locks his bike, the virtual lock server:

1. Receives a signal that the lock is closed, and:
2. Creates a custom transaction which contains:

                   1. A transfer of the remaining deposit amount (deposit minus the rental costs calculated from rentalStart and rentalEnd timestamps) from BikeID address to Bob’s account.    

                   2. Updated asset properties to the BikeID account:

•                   rentalEnd: Current timestamp;
•                   rentedBy: undefined;
•                   Location: GPS latitude, longitude.

3. Signs the custom transaction with BikeID private key.

4. Broadcasts the signed custom transaction to the Lisk.Bike blockchain.

‍

The need for deposits

As the above transactions show, Lisk.Bike does require a deposit payment in order to start a rental. Readers of the introduction to Lisk.Bike may recall that one of the drivers of the Lisk.Bike use case actually was the annoyance of having to pay large deposits with each and every rental. But how else, can one be sure that someone returns the bike and pays for the rental? Of course, there still is a huge difference in needing to deposit a number of ‘Lisk.Bike coins’ from a (semi-) anonymous Lisk address, compared to handing over your creditcard and passport details.

‍

The challenge of connecting IoT and blockchain

A more fundamental challenge lied in connecting the smart-lock firmware and its commands (e.g. open lock or update GPS location) to our blockchain protocol. Not only is the lock firmware poorly documented, making interacting with the lock and figuring out all the commands a time consuming task in itself, it also cannot be altered. Thus, the lock would not be able to run any blockchain software, and we needed to find another way to connect the lock’s commands to our custom blockchain transactions.

This is why we needed a ‘Virtual Lock Server’ (VLS) to translate incoming custom transactions into commands that the lock can understand and perform, as can also be noted in the transactions described above. Initially, we started with one VLS managing all the locks in the ecosystem. This VLS would keep track of the blockchain addresses corresponding to the smart locks (based on the IMEI numbers of their SIM cards). For example, in step 5 and 6 above, the VLS recognises a deposit on the BikeID public address, and sends the open lock command to the corresponding lock over GPRS. So far so good, but it gets more tricky with the opposite flow, where the lock needs to broadcast information to the blockchain, for example when updating its new rental status and GPS location in sept 8-10. Because the lock cannot sign any blockchain transactions itself, it needs to send its location to the VLS, which then creates, signs, and broadcasts the transaction on the blockchain. In order to do so, the VLS needed not only an overview of the locks and their corresponding public addresses, but also of their private keys. So much for decentralisation and security! Luckily, this was easily solved by having each participant that wishes to onboard one or more bikes on the Lisk.Bike platform run their private VLS to manage the operations, private keys, and funds of their bikes – instead of using one central VLS.

Clearly, this is less than ideal. While setting up the VLS is not complicated, it may still be a significant hurdle for participants to overcome. And given that their bikes need to be responsive at all times – imagine an end rental transaction not being processed because the owner shut down his VLS – participants need to have their VLS online permanently, for example by running it on a VPS. Of course, this VPS will also need to run a Lisk.Bike side chain node, because how else is the VLS supposed to read any incoming rental transactions?

Of course, for Lisk.Bike 2.0 we could explore several possibilities to move away from the VLS. For example, we could modify the hardware and replace the circuitboard with one that is actually able to run full Lisk.Bike nodes. Another interesting option worth exploring would be to use Slock.it’s Incubed Client for connecting #IoT devices to the blockchain. Finally, Gimly is currently working with Tangem, manufacturer of new ‘chip-to-chain’ NFC chips to implement these in IOT and blockchain based solutions. These chips can sign and store encrypted data, and sign blockchain transactions directly – without the need for an external server or other third (proprietary) layer (keep an eye on gimly.io and Medium to learn later this year). In a sense, implementing this technology in Lisk.Bike would create truly ‘autonomous bikes’ that can earn their own money, pay for their own maintenance or even pay for new bikes – their offspring.

‍

What about Smart Contracts?

As mentioned in the introduction of Lisk.Bike, the project is built on Lisk primarily for the purpose of learning more about working with custom transactions and using JavaScript to build blockchain solutions with the LiskSDK – not because Lisk custom transactions are necessarily the most suitable technology for this use case. A very different approach – and in blockchain terms a more conventional one – is the use of smart contracts, most often running on Ethereum. Kryha’s lockchain, for example, is a great example of a bicycle sharing platform that is powered by Ethereum smart contracts. In this section, we’ll discuss some general differences between smart contracts and custom transactions, and what lessons for Lisk.Bike we can learn from Kryha’s implementation of smart contracts in a bike sharing platform.

‍

Custom Transaction vs Smart Contracts

With smart contracts, business logic is executed within a programmed contract, and not on-chain as it is with custom transactions. An Ethereum contract has an address where it can receive transactions of ETH or other ERC tokens, as well as messages containing all kinds of data. The code in the contract address defines what the outcome of the transactions and data should be, and once the contract is deployed on the Ethereum network the code will be automatically executed by every node on the Ethereum network. To take an example of a bicycle sharing platform; smart contracts could check that all requirements in the code are met – e.g. that a user has made the correct deposit, that the bike is available, or whether the bike is properly parked and in good condition – after which the rental is activated and any payments are executed automatically.

An important difference between working with smart contracts or custom transactions lies also in how the business logic could be changed or updated. With custom transactions, if one were to make any changes or updates in the business logic, one would need to change the custom transactions. Because all nodes need to understand the same transactions, this requires a restart of every node. With smart contracts, there is no way to change the code once it is deployed, but one can deploy a new and updated contract. Because the new contract is deployed on the network and follows the same structure and language as all other contracts, this doesn’t require a restart of any blockchain nodes.

‍

Bike sharing with smart contracts: Kryha's Lockchain

Lockchain – blockchain minus the ‘b’; pun (un)intended? – is Kryha’s bike sharing solution running on Ethereum, developed together with IoT R&D company TWTG and the bike company X.bike. To be sure, lockchain is a completely different ballgame from Lisk.Bike and much further developed. While lockchain also started as a research project to explore possibilities to combine IoT and blockchain technologies, it is partly funded by The Netherlands Enterprise Agency (the RVO) for further development, and is meant to be launched in the city of Amsterdam. Unfortunately, this means that the project is not open source and that detailed information on the project is hard to find. Luckily, exceptions are this Medium post by Kryha, and a graduation thesis on designing blockchain based bike sharing solutions (de Witt, 2019), providing us with some technical as well as contextual insights.

‍

Connecting IoT hardware to Ehtereum vs LISK.BIKE nodes

Kryha describes how they faced challenges in connecting their lock to the Ethereum blockchain, similar to our challenges with Lisk.Bike. They too played with the idea of running full nodes on every lock, but they had to conclude that running full Ethereum nodes was unfeasible. Instead, they opted for a challenge-response scheme and cryptographically secured communication between lock, user, and smart contract in the blockchain network via the user’s phone bluetooth connection and mobile client. This raises the question whether it would be equally unfeasible to deploy Lisk.Bike nodes in the lock firmware in the future, as it was to run full Ethereum nodes on lockchain? Clearly, running Lisk.Bike nodes that only include Lisk.Bike transactions is a huge difference from running a complete Ethereum network in the lock’s firmware.

‍

Context of Innovation: Complying to local regulations and stakeholders' needs

De Witt (2019), describes how the lockchain business case and need to accommodate the municipalities needs and interests affected the ultimate design of the bike sharing solution. The project needed to comply with various local regulations. For example, no-parking zones for bicycles needed to remain enforceable and users’ personal information needed to remain accessible, for example in case of violations. Moreover, regulations do not allow consumers to commercially rent out their property in the public space without a permit. This led to the redefinition of the sharing solution, resulting in a transformation from a completely decentralised and autonomous solution into a blockchain powered but semi-centralised solution. These are valuable lessons that we will need to take into account when working towards Lisk.Bike 2.0 in the future.

‍

LISK: Engaging the Javascript community

The strongest selling point of Lisk and the LiskSDK, is that it makes blockchain technology accessible for JavaScript developers. With Lisk.Bike, we aim to make the LiskSDK accessible. For this purpose, we have organised two Lisk.Bike workshops for javascript developers interested to learn more about blockchain and about the LiskSDK. In the Lisk Center Utrecht, we hosted a workshop during the Hands-on Techday with blockchain030 , Rabobank and hybrix. In the Lisk HQ Berlin, we hosted a workshop during LiskJS2019 conference. With these workshops, we helped javascript developers get acquainted with using the LiskSDK for building a blockchain application in a playful and interactive manner.

‍

In 2020, Blockchain030, Gimly, and the Lisk Center Utrecht aim to continue leveraging the Lisk technology to introduce the huge community of JavaScript developers to blockchcain technology in 2020. By inspiring talented developers to start working on blockchain development, the LiskSDK will not only benefit the Lisk ecosystem, but will grow the blockchain industry as a whole. For this reason, we are excited to announce our upcoming JavaScript meets Blockchain conference:

• What: Blockchain, Lisk + JavaScript conference
• When: March 21, 9am - 5pm
• Where: Lisk Center Utrecht, the Netherlands
• How: sign up on meetup, and get the €25 refunded in $Lisk upon conference attendance

‍