A Trust Framework For Blockchain Apps Design
Much have been spoken about Blockchain scalability. It is commonly accepted that existing blockchains cannot yet support the demanding requirements of existing businesses with millions of transactions per day. This post challenges that idea.
Trust is not an absolute value. Every business has to find the optimal trade-off between “trust” and “on-chain activity”.
This framework contributes with tools in two dimensions:
Level of Trust. For each business case, there is an “intrinsic” level of trust between the players and a “desirable” level of trust (needed for the transaction to occur). “On-chain activity” bridges the two levels of trust.
On-chain activity. Blockchain can be used in various ways, but two of them correspond to 99% of existing use cases:
— “Currency ownership”: the user has the custody and has control over the “digital money” owned. “Store-of-value” and “payments” are different applications leveraged by currency ownership.
— “State notarisation”: the certification that a certain state occurred in a specific moment of time.
The optimal trade-off is the one that reaches the “level of trust” required for the business to be carried on, while minimizing the “on-chain activity”.
The relations between economical actors can be classified by the level of trust between them. Levels of trust can be subjective and evaluated in different dimensions: “How much information do I have?”, “What is the liability of a faulty behaviour?”,…
The trust and risk evaluation was always part of doing business. In the past, when the “intrinsic” trust was not enough to conduct business, two things happened: the business was aborted or there was a “middleman” involvement that both parties can trust. Blockchain is a technology that plays that role and that can be used to raise the “intrinsic” trust level up to the “desirable” level.
The assessment of trust can be performed is 3 levels:
- (2) Trust: a party trusts the other enough to conduct the business.
- (1) Lack of Trust: although signs exists that the other party is trustworthy, those signs may not be enough.
- (0) No Trust: parties don’t trust each other.
The Trust function is bi-directional. One party may trust the other but the opposite may not be true.
Let’s imagine the case of renting a car through a third party site. There are three players: the driver, the site and the rent-a-car company. What is the level of trust between them?
Table 1 reflects a possible network of trust relations. For example, the Driver may have lack of trust (1) for the Website (that he never used before but have heard of) and also have lack of trust (2) for the Rent-a-car (an international brand that he used before but that he has some previous complications regarding car damages reimbursements). The Website may not trust at all the Driver but trusts Rent-a-car. And finaly, the Rent-a-car may not trust at all the Driver and has lack of trust for the Website, which is an affiliate partnership with limited track record.
For the rent-a-car business to happened, some conditions have to be in placed, regarding the trust between players:
- Payment transactions: 1) Website has to be sure that the Driver pays the renting and that, if something goes wrong, the Driver can pay the damages until a certain threshold. 2) The website has to pay the renting fee to Rent-a-car.
- Information registry: 1) Driver, Website and Rent-a-car want to have a confirmation that the reservation is done 2) Driver wants to have an acknowledgement that the car was delivered in good conditions, to avoid future claims.
The above conditions can be reflected in the “desirable level of trust”:
For the business to happen, mechanisms to raise the level of trust from table 1 to table 2 must happened. Currently, without blockchain, it happens with Credit Card intermediation (payment flows and security deposit), PDF receipts (reservation confirmation) and paper signatures (car delivery without damages).
As a technology, Blockchain can be used in various ways. In this section, we summarise the most common uses.
On-chain Activity — Currency ownership
The ownership of currency is as old as the existence of money. If with physical money (coins and notes), you have total control as in the limit you don’t need to ask authorisation or depend on a third party to use it. The downside is that you cannot use it for digital applications, like paying the rent-a-car in a website. On the other hand, credit card, Paypal and bank accounts can be used in digital use cases but you don’t have control over it. The lack of flexibility limits the use cases. For instance, peer-to-peer transfers on credit card is impossible.
Cryptocurrencies, as digital money, will become increasingly popular because it merges the benefits of the two worlds: flexibility for digital and on-line payments and control/ownership of the currency.
Different currency ownership scenarios can be defined in 4 levels:
- No control: a third party controls your currency and you cannot use it without authorisation; all the information related (balance, movements,…) is centralized.
- Acknowledgement of existence: you don’t control the currency owned by you (as its control is done by a third party) but the balance and movements are registered in the blockchain and can be verified.
- Escrow: you don’t control your money, but neither the third party that you are doing business with. There is a escrow entity (like a smart contract) that depending on certain conditions, release the money.
- Full custody: you fully control your money; for instance, you have the private keys required to make transfers from your crypto wallet with no other dependency other than the blockchain infra-structure you are using.
The requirements of blockchain features are very different across the four levels. With no control you don’t have activity at all, and with full custody you have a set of “expensive” (time & money) blockchain operations.
On-chain Activity — State notarisation
Besides “store of value”, blockchain is a technology that enables “store of state”. It is often seen as immutable ledger that cannot be tampered. The ledger allows a “state notarization” where a proof of a certain information is stored and can be later retrieved.
The registration of information is not necessarily performed in the same way everytime. Different scenarios:
- One party registry: a centralised approach where one organisation (Paypal, credit card processor) is sole responsible of keeping the information.
- Proof-of-state using the blockchain has two different dimensions:
- Self-contained Vs Digest: is the information stored in the blockchain self-contained and it expresses all the information? Or is there a signature (a digest, a hash of the message) that is stored in the blockchain but we still rely on a third party to keep the original information ? For instance, we can store all the renting information (car, date, price, name of the driver) on the blockchain or, as an alternative, we can register only a signature of the transaction which requires less space. The signature of the transaction can be used later by any of the parties to prove that it happened, but the original information has to be kept by the parties. Signature of the transaction is done using “hashes” (cryptographic functions) and consolidated data structures (like “merkle trees”)
- Real-time Vs time-delayed: do I need to write immediately the information to the blockchain or can it be done once a hour or once a day ?
Depending on the business requirements, you can choose the “state notarisation” most suitable for your case. Demanding scenarios (“real-time”, “self-contained”) will imply higher blockchain costs.
Although it can be more complex and take in account other business factors, affinity between levels of trust and on-chain activity requirements can be found:
When designing a blockchain app (Dapp) for the rent-a-car business case, the goal is to increase the Level of Trust as presented in Table 1 and Table 2.
One possible implementation would be using Ethereum network:
Approach 1: Proper use of blockchain
Driver pays upfront the renting fee to the website using Ether. The payment is done through a smart contract that: 1) stores the money until the rent is finished 2) stores a security deposit to support possible damages 3) registers in the blockchain all the information (date, car model, driver, …) about the reservation 4) when the renting is over, implements the revenue share between the website and the rent-a-car and returns the security deposit to the driver 5) registers a record that the car has been successfully returned.
The above implementation has costs related with the number of operations and storing space of the smart contract used. In a $200 transaction like this, it can be up to $5 to $20, depending on the Ethereum network fee at that time. For a smaller payment, this cost would be even harder to support.
What is the strictly needed on-chain activity that we need? Table 3 show us that not all the trust relations are the same. Can we leverage the intrinsic existent trust relations (starting point, table 1) to reduce the on-chain activity?
With the help of Table 3, we can see that website “trusts” rent-a-car and “driver” and “rent-a-car” have some trust in “website”.
We could then try other approach regarding on-chain activity:
Approach 2: Adapted use of the blockchain
Driver pays upfront the renting fee / security deposit to the website using Ether. The payment is done through a smart contract that: 1) stores the renting fee / security deposit 2) registers in the blockchain a digest of all the reservation information (date, car model, driver, …) and sends an email with the information, plus the block of the blockchain where the digest is stored 4) when the renting is over, returns the pledge to the driver 5) once a month, the revenue share to be paid to the website and rent-a-car is distributed 6) once a hour, registers a “root hash” of the “merkle tree” of all cars returned and send email information to the drivers with the block of the blockchain where the digest is stored.
In the above design, the trade-off was chosen:
- Currency ownership | Escrow: the money is not transferred imediately to the rent-a-car. It is under the smart contract escrow for a period of time, or even kept under the control of the Website.
- State notarisation | Digest & Time-delayed: only a transaction digest is stored, being the original information kept by the parties; once every hour this digest is written and not in real time.
Relaxing the above requirements, will reduce one or two orders of magnitude the cost and time taken in your transactions.
Conclusion
The bad news. Both layer 1 and layer 2 blockchain scalability approaches will take time. Layer 2 payment channels (Lightning network, Raiden) will probably take 1 or 2 years to get in a kind of stable form. Other layer 2 approaches, like Plasma, will take even more than that. Layer 1 sharding and proof-of-stake will take at least 3 to 5 years.
The good news. You likely don’t need 5,000 TPS. The key is to understand what degrees of flexibility on-chain activity can provide and adapt it to the Level of Trust strictly needed by your business.
Originally published at medium.com on December 7, 2018.
