by Maria Christofi (Trusted Labs) and Aline Gouget (Gemalto)
Use blockchain technologies while keeping the control of the transparency you provide!
An important property of blockchain technologies is that trust is distributed between all blockchain network members. When anyone can be a member of this network, it is about a permissionless model, whereas when access to the network is allowed only to entities that belong to a defined consortium, it is a permissioned model. We focus here on one key topic for blockchain technologies: the sharing of trust beyond the choice of the consensus protocol.
One main characteristic of blockchain technology is that it enables maintenance of a continuously-growing list of ordered records, called blocks, on which there is a consensus. Each block is timestamped, linked to previous blocks using cryptography and contains one or several “transactions” that have been “verified” by the blockchain members. "Transaction" should be understood in a broad sense to be adapted to many use-cases. For example, a Bitcoin transaction is related to the digital money transfer using pseudonyms, but a transaction can also be a simple exchange of assets, described into a smart contract, or it can be almost “everything”, e.g., a hash of data for internal logs or proof of anteriority [1]. Then, depending on the use-case, data fields have to be categorised, i.e., data fields publicly shared, data fields shared only within the blockchain consortium, data fields shared only with identified entities and data fields that have to be kept confidential (and not shared with anyone). The meaning of “verified” must also be taken in a very broad sense, as illustrated by the three cases below.
Data protection can have different meanings depending on the use-case, e.g., authentication of the data source, authentication of people accessing it, securitisation of the data transport or of the storage. Moreover, different notions of privacy properties may have to be supported depending on the use-case and on the data fields’ classification.
Let's have a look at three use-cases that illustrate the shades of “transparency” that can be provided by blockchain technologies.
Case 1: Bitcoin transaction.
Data is shared publicly in a permissionless ledger. This is an example with almost maximal transparency by a full delegation of the verification steps to the blockchain network. Indeed, all the steps of the transaction verification (i.e., amount/balance verification, signature authenticity verification, detection of double-spending) as well as the insertion into the ledger are done by the blockchain network. Regarding privacy properties, only the pseudonymity of payer/payee is claimed to be supported. However, this privacy property is quite weak and it is possible to extract some information by analysing the graph of transactions, e.g., [2]. For Case 1, the ledger is auditable with independently-verifiable proof-of-time, at any time by anybody.
Case 2: Smart contracts with confidential formula based on zero-knowledge proof of knowledge techniques, e.g., [3].
This use-case can be relevant for both permissionless and permissioned networks. In both models, only the stakeholders involved in the smart contract have access to the exact formula that will be used to compute the final amount of the transaction. The rules of the smart contract are shared inside the blockchain network but the formula that will be used to compute the final amount of the contract is kept confidential; this formula is embedded into the smart contract in an encrypted form. Then, when the smart contract is executed, the payer and/or the payee reveal the final amount of the transaction while proving that this amount is compliant with the encrypted formula contained within the smart contract, without disclosing the formula. This privacy feature is important, especially for business relationships where the rules may change from one customer to another. All these features could be formally verified to increase the assurance and trust in transaction verification. For Case 2, the ledger is also auditable at any time by any member of the blockchain network.
Case 3: Records of private financial transactions by disclosing only hash of the transaction data.
This use-case is more suitable for use with a permissioned model where the blockchain network can take responsibility for authenticating the data source. Then, it is guaranteed that only data provided by authenticated sources have been added to the permissioned ledger while transaction data remain confidential (except for the stakeholders involved in the transaction). However, financial data could be shared a posteriori, e.g., to a judge to enable transaction verifications and anchoring into the ledger.
These use-cases illustrate that it is not necessary to choose between full worldwide transparency and transparency only within a consortium, but several levels of transparency can be considered depending on the use-cases needs and especially concerning the classification of data fields, possibly using a hierarchy of consortia. The aim of our work is to provide recommendations for designing customised transparency depending on the use-case.
References:
[1] A. Buldas, A. Kroonmaa and R. Laanoja: “Keyless Signatures' Infrastructure: How to Build Global Distributed Hash-Trees”, Cryptology ePrint Archive, Report 2013/834, 2013.
[2] D. Ron et A. Shamir: “Quantitative analysis of the full Bitcoin transaction graph”, Financial Cryptography, 2013.
[3] A. E. Kosba, et al.: “Hawk: The Blockchain Model of Cryptography and Privacy-Preserving Smart Contracts”, IEEE Symposium on Security and Privacy 2016, 2016.
Please contact:
Maria Christofi, Trusted Labs, France
Aline Gouget, Gemalto, France
