Lisk Bills: HQ’s Walkthrough of the first PoC
In a brilliant effort showcasing Lisk’s custom transactions as the “creative spark” that will drive the growth of the ecosystem, Michiel Mulders, writing in the official Lisk Blog, introduced the community to Lisk Bills. This proof-of-concept blockchain application utilizes the Alpha SDK in a “Keep It Simple and Stupid Approach” that defines the transactional relationship between a client and a freelancer. The end product is a minimal React front-end that lets the freelancer send an invoice to the client who is then able to pay the invoice.
Two custom transactions – an Invoice Transaction, which extends the Base Transaction and a Payment Transaction, which extends the Transfer Transaction – are created on the blockchain. So, when Bob the client goes looking for a freelance graphic designer for his website logo, he is impressed by Alice’s portfolio. He hires her immediately and after a few days, she gets back to him with an interesting design. All that remains is for Bob to pay the invoice she sends. Bob, however, insists on using Lisk Bills to pay the invoice.
This is because he believes blockchain technology will ease the process. His previous experience with contract disputes makes him want to eliminate human error by using Lisk Bills as the proof for the invoice. This way, freelancers he works with are able to log into the application with a secure passphrase and send him an invoice by filling out the Client, Amount, and Description Fields. A peek under the hood shows that these fields trigger the custom Invoice Transaction. After the class extension, a transaction fee is defined.
The process begins by calling the parent method for the prepare function, which loads the sender’s data from the StateStore object. This function then caches that data to be able to deduct the transaction fee (1 LSK) in the apply step. Next, the transaction’s asset correctness is checked in the validateAsset function. If everything is in order, the Invoice Transaction finally arrives at the applyAsset function where the loaded account adds the following data to its asset field: 1) invoice count 2) invoice ID stored in invoicesSent array.
When the client received the invoice in his wallet, he has to fill in the Invoice ID, Recipient address, and Amount fields to fulfill the invoice. Under the hood, this creates yet another custom transaction called the Payment Transaction, which inherits from the default Transfer Transaction. As Mulders explains, this custom transaction “holds logic to verify the transferred amount is at least equal to the RequestedAmount“. It also requires the client to specify the invoice ID. “If the transferred amount is too low or the invoice ID just doesn’t exist, the transaction fails”.
You can find additional technical details for both custom transactions on the official Lisk Blog. A webinar featuring Rachel Black, Michiel Mulders, Vit Stanislav, and Lucas Silvestre, has been released to help everyone learn while doing.
———————————————-
Lisk Magazine is a project supported by Lisk Italian Group and EliteX.
Support our work, vote for Lisk Magazine.
