Protecting the Enterprise: Permissioning Features in Pantheon

DISCLAIMER: As of September 2019, the Ethereum client formerly known as Pantheon was submitted to the Hyperledger Project of the Linux foundation, and is now known as Hyperledger Besu. In October 2020 PegaSys was renamed to Quorum.

We strongly believe that extending the capabilities of public Ethereum with permissions mechanisms will greatly improve the adoption of Ethereum amongst enterprise users and consortium blockchains. Pantheon 1.0 is compliant with most of the permissions requirements of the EEA v2.0 specifications, with Pantheon 1.1 extending this even further.

Node-Level and Account-Level Permissioning on the Ethereum Blockchain

In our recent article on IBFT 2.0, we discussed some of the current challenges with Proof of Authority (PoA) consensus mechanisms and proposed a solution in the implementation of IBFT 2.0 and its use in a consortium blockchain. Another key requirement for enterprises operating a private network is the ability to restrict participants from transacting in the network so you can be confident that you are not exposing private, confidential data. With these requirements in mind, PegaSys has implemented permissioning features in its Ethereum client for the Pantheon 1.0 release as part of our long term goal to meet best practices for permissions and access control in Enterprise Ethereum.

When operating on the public Ethereum mainnet, all nodes have the ability to interact with any other node on the network. Built within Pantheon, and other Ethereum clients, is the ability to specify a network other than mainnet. An example of this type of private network is a consortium of organisations that want to send transactions among one another. Without the ability to restrict which nodes can communicate with you, any Ethereum client would be able to connect if they were aware of your specific configurations. A permissions mechanism allows for safety and control over the nodes as well as the ability of Ethereum accounts to communicate with an individual node. This is a key part of PegaSys’ vision of creating software for large, decentralized consortiums that are building and deploying blockchain solutions.

To help secure consortium networks, PegaSys has implemented two forms of permissioning in Pantheon 1.0: node-level permissions and Ethereum account-level permissions. We will discuss each in more detail, and also preview some of the smart contract permissions we plan to release in Pantheon 1.1.

Node-Level Permissions

In Pantheon, node-level permissions allow an Ethereum node to restrict which other nodes it is willing to peer with (i.e. communicate with in any form). This restricted list is a called a whitelist. Using this whitelist, a consortium can specify exactly which nodes it is willing to let into its network, and any communication from external parties will therefore be rejected.

In the 1.0 release of Pantheon, node-level permissioning is provided off-chain, which means each Ethereum node in the consortium network will have its own whitelist of nodes it is allowed to communicate with. However, solely implementing node-level permissions in an Ethereum client is not a trustless solution. Each Ethereum node is still responsible for communicating with its own peers and has no control or view of who other nodes in the network are talking to. It is possible that a bad actor in such a network could violate the network governance agreed on, and act as a proxy to other nodes, regardless of off-chain or on-chain permissions being used.

Node-level permissions are still a useful system of governance to control connections to an individual node. However paired with additional features such as account-level permissions, they enable a more complete permissioned, private consortium chain to operate in a trustless environment.

Account-Level Permissions

Account-level permissions can be used as another mechanism and area of network governance in a consortium blockchain. Account-level permissions restrict which Ethereum accounts can transact on the network, and what types of transactions each is allowed to make.

Using account permissions in Pantheon 1.0, a consortium blockchain can limit which accounts a node accepts transactions from, and which it rejects. This capability can be used to meet a variety of use cases, from limiting the interaction that a bad actor can have on a network to restricting the ability to submit transaction to certain users in a consortium, for example, an administrator account with access to an Ethereum wallet to create smart contracts or transfer funds, and an end user account with only the ability to do read-only queries against the blockchain.

The whitelist of allowed accounts is maintained locally at each node (i.e. each node is responsible for the transaction that it processes). This “filtering” of transactions takes place at 3 layers:

1. A transaction that is received via JSON-RPC API
2. A transaction that is propagated between peers (limited by peers on the nodes whitelist)
3. A transaction that is being mined into a block

It is important to note that transactions that are already included in a block produced by another node are not currently restricted.

Looking Ahead

Our Pantheon 1.1 release in April will also support a smart contract-based permissioning solution which will allow for a single source of truth to be used between all nodes in a consortium blockchain. This feature along with the account-level and node-level permissions will provide enterprises with a suite of permission features to enable secure networks.

We strongly believe that extending the capabilities of public Ethereum with permissions mechanisms will greatly improve the adoption of Ethereum amongst enterprise users and consortium blockchains. Pantheon 1.0 is compliant with most of the permissions requirements of the EEA v2.0 specifications, with Pantheon 1.1 extending this even further. We are committed to working with the Enterprise Ethereum Alliance and its members to continue to create a permissions scheme that is widely adopted, addresses the needs of the enterprise community, meets regulatory concerns, and helps bring about the transformative power of Ethereum.

PegaSys is a thought leader in the Enterprise Ethereum space. Want to join the team? Check out our list of open roles.