Problems to solve when building blockchain products
Blockchain is getting adopted widely in different domains and the reason behind is that it solves the problem of mistrust, control, and authenticity by providing
- Trust
- Decentralization
- Immutability
It is being used to solve these problems in a wide variety of use cases like healthcare, supply chain management, insurance, payments, review systems, and much more. Many people who are trying to build products on top of the blockchain especially on Ethereum, they will face similar issues as we have faced, I wanted to discuss a few problems that we solved so it can help other to come up with their own solution.
We solved multiples problems while building the product, let's discuss a few of them today.
- Blockchain Write operations are slow.
- Optimize Write operation cost as it includes blockchain transaction fees based on the amount of data stored and operations executed.
- Payment transfer of token/coin is also a write operation so, the sender or receiver needs to bear the transaction cost of the transfer, you need to batch multiple transfers to minimize the overall blockchain transaction fee.
- Since write operations are slow UX needs to come up with non-blocking flows accordingly.
Blockchain Write operations are slow.
The blockchain write operation can be painfully slow as it takes time for a transaction to reach consensus and get accepted and can sometimes take minutes. If you are designing a real-time product, this can be blocker.
When you submit a write transaction to the blockchain, we want to continue with our operation marking the transaction in IN_PROGRESS and get notified later once the transaction is accepted by blockchain.
We solved these problems by using a copy of blockchain data in centralized storage and thus keeping it in sync with the blockchain. Users can always verify the data from blockchain if needed as read operations are free.
Using a publisher-subscriber pattern we notify the service consumers once the blockchain transaction is accepted. After consuming the events they can change the status of write operation from IN_PROGRESS to SUCCESS, and store the latest data for later use.
While writing your contract you need to make sure you are enabling event emitting capability in your contract.
This architecture also helped us to do all sorts of operations in our platform based on events happening on our blockchain contract. Also for reads, let’s say Infura(way to connect to ethereum network) is down we can continue read operation using our local store.
Write operation includes blockchain transaction fees based on the amount of data stored and operations executed.
Blockchain write operations are charged based on the amount of data we store and a number of operations executed.
So if your product needs to store an enormous volume of data on the blockchain you will end up giving high transaction fees for your write operations.
Here IPFS which is also a decentralized network comes to our rescue. The InterPlanetary File System (IPFS) is a protocol and peer-to-peer network for storing and sharing data in a distributed file system.
Files stored in IPFS are immutable and it returns a hash as your file address. Instead of storing all your data in the blockchain you can store the data in IPFS and store the file address in the blockchain.
Minimize Blockchain Transaction fee for multiple token/coin transfer between two parties
Each transfer between two parties involves a write operation on the blockchain that means transaction fees need to be paid and either user or service provider needs to pay for it.
Transaction Cost is always paid by the transaction initiator
What if there are doing multiple transfers? Involved parties will want to minimize the transaction fees associated with each transfer.
To solve this, we leveraged the concept of off-chain transactions in the form of payment channels. A payment channel is a kind of payment gateway established between two parties here let's say here user and service provider.
A channel is uniquely established using two payment addresses. A user can put money into the channel specifying the expiry time. To take out the money service provider need to have a signature (need to store somewhere off-chain) from the user which includes the signed amount, the amount he can take out. Also, if the channel is past expiry time a user can take money out of it.
Now let's walk through an example.
Service Provider is providing some service at 1 Unit per call, so if the user makes 5 calls.
There are two options:
- Without the channel, the user needs to transfer the token/coin 5 times incurring transaction fees 5 times.
- Using channel he can put 5 tokens in the channel before starting the call and proceed as mentioned below.
To make the first call he will pass the signature to a service provider having signed amount (1) saying I am allowing the service provider to take 1 token from the channel, the service provider will store this signature and allow the service call to happen.
When the user makes the second call, he will pass the signature with the last signed amount (1) + current call amount (1), so he will pass the signature with the signed amount (2), similarly, for the third call, he will pass the signature with 2(last signed amount) +1 (current call amount) i.e. 3.
A service provider using this signature can take the signed amount (3) out of the channel at any point in time. Here, he can take out money after 3 calls, which will mean that he needs to initiate blockchain write operation and pay a transaction fee, but he will do only one operation instead of 3 individual operations hence minimizing the transaction cost.
All these solutions can vary differently based on use cases. Please let us know if you have any ideas to solve these problems differently
Before we close this, I need to thank Raam, Anand, Sridhar helping me to come up with this post.
