In the previous episode regarding proof of loss, I showed the main ideas which shape up my proof of concept (PoC). In summary, it has three main ingredients:
- Proof of Loss: proves your ownership with property that you lost.
- Revocable Property: makes your property possible to come back to you.
- Decentralized Risk: prevents “all” frauds of risks, creates a safe environment to you.
As my promises, I will try to dive into how I create “the transaction”, furthermore, I will explain whole my PoC via an available example, in this episode.
Otherwise, just the same as Nani, I don’t want to save anything. In this case, I don’t want to save the private key of my redundant account. Thus, this transaction must be possible to fill the receiver, which was provided in PoL, later. — cite from Recoverable Property part of Episode 1.
An important attribute of the transaction is able to be filled receiver, later. Why is it important? Let’s come back a little bit. The only one thing you have and you just want to have is Proof of Loss (PoL). However, my solution of recovering your property is to try to send your lost balance to a new account which will be provided in your PoL. As a result, we need to create this transaction in advance and somehow, you will be possible to fill receiver address into the transaction after you get PoL (theoretically, you can merely create a valid PoL when you lose your private key).
Essentially, the transaction must be possible to define the recipient after signature.
Maybe my explanation is a little bit lengthy, but I have to make sure that you understand what we are doing with PoL 🙂
It’s not a charm as you imaged, I just used a trick by smart contract. Let’s start with this idea:
You are about to move your family to a new place and you literally don’t know the address of new place. Poorly, you cannot just go there and move your furnitures later. You have to move those in advance without knowledge of the new address. Thus, you decide to send it to a logistic company while you are coming to the new place. After your come there, you just request the company to delivery your stuff to the new address that you have known.
As you can see, the basic idea that you send your balance to a specific-existed address which is an available-trustworthy smart contract and then this smart contract will “redirect” your balance to address which was provided in your PoC.
That seems to be very easy to think with your point view, but I’m such as a frozen-brain guy and well, it is literally wonderful to me 😱.
The example
You can find my github repo below, please make sure that you checked out the “for-blog” branch for matching with what I used here. If you wish to get more interesting, you can find a better code in “develop” branch.
In this part, I’m about to show you how this PoC works in code. I used Solidity programming language to implement a smart contract.
What are the purposes of this smart contract?
The main purposes of this smart contract are providing functions that help you can create PoL, validate/invalidate PoL and redirect your recoverable property in case.
With 3 main functions, namely recoverBalance (line 61), rejectPoL (line 75) and fallback function (line 102), we can build a simple PoL.
Firstly, we get recover Balance that help us to create a PoL. This function is payable function because every time you try to create a PoL, you must send with a deposit for anti-spam. Another condition is this PoL must be the first one, it means if PoL of your property is created, nobody will be able to create another PoL on the your property.
Nobody can create the second PoL on the same property.
The result of this function is very simple, a PoL will be recorded in smart contract with some information:
- receiver: this address will be filled in the transaction and it will be the valid receiver of recoverable property as soon as PoL is valid.
- initialBlock: the block number of Ethereum network, PoL is recorded at.
- deposit: the number of ether for deposit.
However, we need a mechanism to punish who is trying to create a fake PoL. With rejectPoL, the real owner can prove that the private key is still safe and get whole deposit from fake PoL as a penalty.
Nobody want to create a fake PoL because of punishment.
We can see that if owner proves the fake PoL successfully, the record of fake PoL will be cleaned, after that you can create another PoL normally.
Fallback is a kind of function that will be triggered when a random guy tries to send ether to smart contract. In this function, I did some validations and passed the parameters to a private function — approvePoL.
This is the magic I said 😅, the transaction can be filled receiver after signature.
The approvePoL function gets the receiver’s address from the valid PoL and uses send() function to redirect balance to receiver.
Come back to fallback function. By the time, entire approval progress is done correctly, the PoL will be cleaned.
Actually, we have to distribute dividend to holders but by being brief, I give it to you 👊 . Let taking a sit and doing some real code 🙌 .
The restrictions
At this time, I have met two big restrictions. To make this PoC more friendly, I have to solve both of them one way or another. The first problem is about the transaction and the way it have been created. The second one is about a possible attack vector.
The transaction can not be permanent
What I say here it may be not correct in Ethereum code, actually. But, to let every body be able to get an intuition of the restrictions, I need to explain those in a “zero-knowledge” way.
Come to the way the transaction have been created. Every time you create the transaction, the information about your current balance will be recorded in the transaction. After that, you buy something and your balance is changed. It leads to invalidate current state recorded in the transaction and makes entire the transaction invalid, of course. So, every time you change your balance or your account state, you need to recreate the transaction.
When a customer is a attacker
For instance, Charlie wants to use our system to protect his property. Charlie creates the transaction and divides into 3 pieces of share. Charlie sends a piece of share to victim holder named Victor and the rest to 2 holders that Charlie owned.
Here, we will punish all of the holders even though some of them do not take part in fraud. Because we want them to take a responsibility against for cheating, if they don’t, they’re just like attackers and punished. — cite from Decentralized Risk part of Episode 1.
Charlie pretends to lose his private key, create a PoL and wait for it valid. Coming to the term that more than half of holders consent to recreate the transaction and broadcast it, 2 holders owned by Charlie don’t do that and it becomes impossible for Victor to be able to recreate and broadcast the transaction. So all the holders include Victor will be punished. The deposits will be entirely sent to Charlie.
That’s a way Charlie can use for attacking Victor.
Conclusion on Proof of Loss Proof of Concept
My proof of loss proof of concept is just like a baby at the moment and as a result, I believe it still has many unexplored lacks of security that need to be covered. So, every comments, suggestions, advises… are very helpful to me and I really appreciate your contribution.
Now, I am going to find the solution for Charlie-attack. If I am lucky to find out any solution, I promise that I will share it in the extra episode (may be I will call that episode 3).
So, I have been shared my ideas, hope you can share you thought. Peace!!!
Thank you for reading about this proof of loss proof of concept. To learn more about what Kambria is building using blockchain, visit our platform here.
