DLT Interoperability and More ⛓️#7 ⛓️ — LedgerView: Access-Control Views on Hyperledger Fabric
In this series, we analyze papers on blockchain and interoperability (and both).
This edition covers a recent paper on access control views.
➡️ Title: LedgerView: Access-Control Views on Hyperledger Fabric
➡️ Authors: Pingcheng Ruan Yaron Kanza, Beng Chin Ooi, Divesh Srivastava
The interest in blockchain views seems to be increasing. In our survey, we explore the applications of the research area of view integration (coming from databases and business process management) to blockchain. Abebe et. al have provided some insights on this concept, in their paper. More recently, we finished a paper formalizing the concept of view and defining several operations that can be applied to views. The work of Ruan and colleagues brings another perspective on blockchain views.
In today’s paper, an access-control view permits a user in a database to access a piece of information according to an access control policy. In access control jargon, the Policy Enforcement Point (PEP)is what our colleagues are decentralizing, by relying on the blockchain to manage access permissions. Other proposals decentralize, for example, the Policy Decision Point (PDP) or even client-access control system interaction.
(Although there are proposals for access control mechanisms based on self-sovereign identity as we do in our paper SSIBAC, the access control mechanism in this paper is centralized).
- LedgerView — a system that adds access control views to permissioned blockchains.
- Implementing the access-control views and role-based access control (RBAC) on Hyperledger Fabric (see for comparison an ABAC access control engine implementation as a smart contract)
💪 Strong points:
- This paper introduces all the necessary concepts in a clear and concise way.
- The paper has two mechanisms for implementing access control views, encryption and hashing.
- The paper has an open-source implementation (which is very robust in my opinion, please check it out!)
- The authors conduct a detailed, convincing evaluation. Throughput is around 800 transactions per second, while latency typically varies from 2 to 4 seconds.
- Not necessarily a limitation — because we cannot change the past - but, unfortunately, after an access control view is revealed, via encryption or hashing, it is no longer possible to keep the information private. What has been observed is locked, although access is effectively revoked.
- This scheme is very operation-intensive, namely when creating a unique private key for each private transaction.
🔥 Points of interest:
- The scheme relies on defining the public and private parts of a transaction. An access control view is an encrypted list of private keys, where each private key refers to a private part of a transaction. Users can give access to other users for the private part of the transaction by sharing the unique encryption key of the list of private keys. With each private key, each private transaction can be decrypted.
- Encryption vs Hashing: hashing is typically better if the amount of data is big, but requires participants to store the private data locally. The hash is published in the blockchain as proof because a user holding a piece of data D can hash it (using a certain salt that is also provided) and compare the resulting hash with the one stored in the blockchain. As the result of a hash function is a constant-size bit string, the size of the private data does not have an effect on the storage used in the blockchain per item. On the other hand, the bigger the encrypted data, the more storage it will consume on the blockchain.
- The authors provide an intuition why their access control views are sound and complete.
- The author “implemented the cross-blockchain transactions protocol of AHL  where each cross-blockchain transaction follows the two-phase commit (2PC) protocol. The main blockchain operates as a database transaction coordinator of 2PC”. This is very similar to what we have done with blockchain gateways in our paper Hermes.
🚀 How does it relate to our work at Técnico Lisboa, INESC-ID, and Blockdaemon? (views are my own and do not necessarily reflect the opinions of my employer)
- The study of blockchain views is very important to enable interoperability, as we state in our recent paper. We envision that there are use cases such as cross-chain modeling and visualization, blockchain migration, and audits that greatly benefit from this.
🚀 What are the implications for our work?
- This work puts our own work in perspective as we define related concepts. Our colleagues define access control views as mechanisms to selectively allow reading of private state. We define a blockchain view as a commitment to a set of states from a participant’s perspective.