A Trust Framework For Blockchain Apps Design

  • (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.
Table 1 : Existing “level of trust” between players (rent-a-car example)
  1. 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.
  2. 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.
Table 2 — “desirable level of trust”; in green changes related with payments and in blue related with information registry.
Currency ownsership scenarios.
  • 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.
State notorisation 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 ?
Relation of Levels of Trust and On-chain activity.
Table 3 — “Intrinsic” trust level Vs “desirable” level
  • 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.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
AppCoins Official

AppCoins Official

The first ICO serving 200 million users to create a trusted economy without intermediaries. Supported by Aptoide App Store. Learn more: https://appcoins.io/