Proof of Transparency
Aside from solving the double spending problem, the Bitcoin block-chain also gives anyone the ability to provide valuable proof of transparency. Proof of transparency can be created by providing insight into asset inputs and outputs (income and expenditures) of a party, which can be used to validate that it’s asset balance sheet is correct. That party can also be requested to account for any of their asset inputs and especially outputs.
By providing proof of transparency a party increases it’s accountability and thus it’s reputation of doing honest business. It can be used to show that for example no fraud or fractional reserve banking is taking place. A random example of an organization providing bitcoin proof of transparency can be found here.
Because the Bitcoin block-chain is itself a public ledger, providing proof of transparency is very easy. Although the SAFE network appears to solve the double spending problem very elegantly, it is not a public ledger and is thus not natively capable of facilitating the provision of proof of transparency. Since the ability to provide proof of transparency can have real value, the purpose of this thread is to explore how this ability might be realized on top of the SAFE network using a distributed application.
Public ledgers
In the introduction we established that in order to provide a proof of transparency, a public ledger is required. For this discussion, let’s define a public ledger as a chronologically ordered list of inputs and outputs of assets which is validated by asymmetric cryptography. The SAFE network natively provides this cryptographic validity, as well as a base data structure for transferable digital assets called StructuredData.
Linked lists
The data structure StructuredData can also be used to create the public ledger that we require. Three properties of StructuredData are especially relevant here:
- The address (unique ID in SAFE) of a StructuredData object can be chosen freely
- A StructuredData object can contain or point to any data
- A StructuredData object can have one or more owners
Given these properties, we can use StructuredData objects as nodes to create a (doubly) linked list. You can think of a node as a block in a block-chain. Forward references can be established by setting a rule that the address of node n+1 is defined by the hash of node n. Since addresses are unique and creating a StructuredData object is an atomic action, we don’t have to worry about the double spending problem. Appending a node to the linked list thus operates on a first come, first serve basis. A backward reference can be included in the data field. This way, when given any random node in the linked list, all other nodes in the list can be retrieved from the SAFE network independently.
To prevent anyone breaking the linked list by later modifying the data of a node (which would change the hash) another rule should be that a node is only valid if it’s immutable. Immutability of a StructuredData object can be achieved by setting the owner field to an non-existing owner (a value that isn’t a public key with a private key counterpart). If a node with a real owner is appended to the linked list, this node is mutable, considered invalid and consequently bypassed by continuing the list using the hash of the hash of the last valid node. If an invalid node is also found under that address, then it continues with the hash of the hash of the hash of the last valid node, and so on. Since the cost of uploading a StructuredData object is equal to the cost of uploading 1 MB, spamming a ledger is inherently cost-ineffective.
Proof of Transaction
Now that we have established how a distributed (doubly) linked list can work on SAFE, we can use this linked list to create a public ledger. All that is required is that participants put proof of their transaction(s) in the data fields of the nodes that they append to the linked list.
When transferring a digital asset (implemented using a StructuredData object) on the SAFE network, the close groups handling the transaction create a temporary receipt of the transaction. This receipt can be saved by the previous owner of the transferred asset, and because it is a cryptographic proof that the transaction happened, it is perfect for our public ledger.
Practical usage
Because for proof of transparency only the inputs and outputs of the aspiring transparent party in question are relevant, it is not necessary that multiple parties share the same ledger. Every party can start their very own public ledger. Such a party first creates an initial node on the SAFE network, and then publishes that node’s address as the head of their public ledger. In the initial node they can put one or more public keys that serve as their asset account addresses used in that ledger. These public keys could also be published on their website/portal and/or integrated in their webshop and such.
Now anyone can send assets to the appropriate public key, get the transaction receipt from the SAFE network, grab the head node of the public ledger, hash that node and GET the resulting address to see if the next node already exists. If it doesn’t exist, they can PUT under that address their own node containing the receipt. If it does exist, they hash again what they received from the network, and GET the resulting address again. This repeats until an address is found which is not yet in use.
Similarly, when the party to whom the ledger belongs transfers assets internally or away to third parties, they also append the receipts of those transactions to the ledger.
Audit
To audit the asset balance sheet of a party using such a public ledger, anyone can run a simple script that walks through the entire public ledger to construct the current balance sheet in local memory. Once the balance sheet is constructed, all the relevant assets records (StructuredData objects) can be GET from the SAFE network and their owner fields compared with the known public keys of the party under audit. This way inconsistencies between the ledger and SAFE’s native records can be detected.
Notes
- The speed of appending nodes (receipts) to a public ledger approximates the network speed of one GET plus one PUT. I personally expect this to be under a second.
- Despite there being cost to appending a receipt to a public ledger, clients and partners have an incentive to do so, since it gives their transaction legitimacy.
- A party using a public ledger (or anyone else for that matter) could periodically (or continuously) publish the hash of the last known node of the ledger on their website to reduce the effort required of clients and partners to append a receipt to the ledger.
- Since every party can use their own public ledger, scalability problems may be far less serious than on a shared ledger such as a block-chain.
- Combined with public name registrations, it could become common practice that transparent parties will principally avoid creating asset outputs to unknown/unregistered parties.
Edit for additional notes:
- The transparent party has a strong incentive to publish the receipt of an incoming transaction even if the sender did not. This is because the sender could save the receipt locally, time-stamp it somehow (for example publishing the hash on a blockchain), and then after some time show the world proof that the supposed transparent party is accepting transactions under the radar, and thus destroying the party’s reputation of transparency.
- A ledger can also be privately shared or be hybrid privately shared and public. A select group of investors for example could share a key with which they encrypt the receipts of their transfers. Only those in the possession of all keys used to encrypt any of the receipts in the ledger can be fully validate the asset balance sheet.
Special thanks to @Traktion for the interesting discussions and ideas in other threads leading to this concept!