<img src="https://ws.zoominfo.com/pixel/DyC6M8AFFyV7A9DOjJMa" width="1" height="1" style="display: none;">

    Permissions and Privacy in Distributed Ledgers

    Feb 4, 2019 / by BlocWatch

    When blockchains and Distributed Ledger Technologies (DLT) first appeared, one of their biggest appeals was that they allowed anyone to verify and validate ledger data. While that’s still a big appeal, DLTs are increasingly being implemented with access restrictions, which allows them to operate much more efficiently. For some use cases, adding access control would be a deal-breaker, but for others, it can be a big plus.

    There are two main dimensions to consider with access control on the blockchain: public vs private, and permissionless vs permissioned. These dimensions can be mixed and matched, so that you can have public and permissionless ledgers, public and permissioned ledgers, or private and permissioned ledgers (the combination of private and permissionless is possible, too, though rare).

    Dimension 1: Public vs Private

    The first dimension to consider is public vs private. A public blockchain allows anyone to read the ledger; a private blockchain requires passing through some access-control boundary in order to access the ledger, such as connecting to a private network, or being authenticated by a trusted identity service.

    Public blockchains are like a democracy in that everyone can participate, and the correct version of the ledger (or other governance questions) is determined by majority rule. Because anyone can participate, public blockchains typically have a large user base. As long as no single organization controls 50% or more of the nodes in the blockchain network, no entity can roll back transactions or otherwise tamper with the ledger. Since the ledger data is public and immutable, public blockchains are ideal for use cases where broad-spectrum trust and transparency is paramount, such as cryptocurrencies.

    Private blockchains are ideal for smaller use cases where a barrier to ledger access is acceptable, or even desirable. For example, a ledger that tracks shipments in an oil or gas pipeline is a good example of a blockchain that will be used much less by the broad public than a popular cryptocurrency – maybe only a few thousand users will ever connect to it, and those users will likely have no qualms about going through some sort of registration/authentication process in order to gain access. Keeping a blockchain private allows its maintainers (who typically would be a consortium of businesses, regulators, and other oversight bodies) to roll back transactions in case bad data was written to the ledger, and to limit malicious activity by pre-screening participants.

    Dimension 2: Permissionless vs Permissioned

    Permissionless vs permissioned is the second dimension to look at. A permissionless blockchain allows anyone with access to the blockchain at all to have full reign to read from the ledger and propose transactions; a permissioned blockchain allows certain restrictions to be placed on the ability of each participant to read and interact with the ledger.

    Permissionless blockchains are a natural fit for strongly decentralized and pseudo-anonymous ledgers. If some of the data on a ledger is sensitive or confidential, however, a permissioned blockchain would be more appropriate, where blockchain-level access control could be used to restrict access to that data.

    Another important reason to use a permissioned blockchain is to restrict the participants who are authorized to propose or validate transactions, update the ledger, or update the configuration of the blockchain itself. By limiting such functionality to a smaller set of authorized participants, a blockchain can greatly increase the throughput and scalability of the system while dramatically lowering its resource consumption.

    Now let’s look at how these two dimensions can be combined:

    Combination 1: Public and Permissionless

    Bitcoin, like most of the popular cryptocurrencies, is public and permissionless. Anyone can view the entire ledger, and anyone can propose a transaction. Transactions are validated and written to the ledger by majority rule. There are no restrictions about who can run a node, connect to the network, or mine blocks. Applications like Bitcoin, which need to be fully transparent and globally available, are a good fit for public and permissionless ledgers.

    Combination 2: Public and Permissioned

    Ethereum currently is run as a public and permissionless ledger. However, over the next few years Ethereum is planning to transition from a Proof of Work system to Proof of Stake – this transition will put Ethereum in the public and permissioned category. Only participants who “stake” Ether will be permitted to validate transactions and write to the ledger. Everyone will still have unrestricted access to view the ledger, so it will remain a public blockchain.

    Becoming a permissioned system will allow Ethereum to operate much more efficiently, using much less electricity to validate transactions, and lowering transaction latency. Applications like Ethereum, which allow global public read access, but which restrict who can perform certain operations, are a good fit for public and permissioned ledgers.

    Combination 3: Private and Permissioned

    Although a number of private and permissioned ledgers are available today, they are by definition not publicly accessible. In order to gain access to them, you first must be granted access to the blockchain network in general, and then granted specific permissions to interact with the ledger. For example, with a private and permissioned ledger that tracks shipments in a gas pipeline, the gas producers and shippers would be granted permission to read and write updates to their own shipments in the ledger, but not to any one else’s shipments. Regulators and other oversight bodies would be granted permission to read the entire ledger, but would not be granted permission to write to it.

    Private and permissioned ledgers are ideal for B2B and other enterprise applications, where a relatively limited number of participants (ie thousands instead of millions) transact with each other under well-defined usage patterns. By placing constraints on the pool of participants and their access rights and abilities, the ledger can be run much more efficiently and conveniently.

    Tags: Permissions, Privacy

    Written by BlocWatch