Improved Interoperability, Flexible Permissioning and More: The EEA V3 Client Spec
DISCLAIMER: As of September 2019, Pantheon has been renamed to Hyperledger Besu. In posts prior to September 2019, we refer to the Ethereum client as Pantheon.
On Monday, the EEA released Version 3 of the EEA Client Specification with numerous clarifications and some notable improvements. PegaSys is proud to have been a part of developing the EEA Client Specification. Congratulations and thanks to all members on releasing V3, and to Chris McKay and Sally MacFarlane for their work on this piece.
Download the client specification here.
With this release, we see two of the most significant changes to the specification since version 1: the adoption of the Clique proof of authority consensus mechanism; and the introduction of flexible interfaces for on-chain permissioning.
Clique Proof of Authority
Including Clique as a reference proof of authority mechanism means we can provide blockchains run by different but interoperable clients without the cost of proof of work. One of the major tenets of Ethereum is distribution of trust. A key part of that is being able to use different client implementations on the same network. Until now, the only consensus mechanism consistently implemented across multiple clients was the Ethash proof of work mechanism. With a proof of authority mechanism in the client specification, we can now safely propose blockchains that allow a more even distribution of control, without fear of vendor lock in or risking faults that can appear from using a single client implementation.
Flexible On-Chain Permissioning
The second major milestone is the overhaul of the permissioning requirements in the specification. V3 introduces two interfaces for account and node permissioning managed on-chain. While the previous requirements in the specification also operated on-chain, they were very restrictive, imposing a permissioning model that was not always the best fit for the intended use case. The new interfaces allow custom permissioning models to be defined in smart contracts that multiple client implementations can operate without the need to customise every client.
The new node permissioning interface can restrict access by a combination of a node’s public key, and the internet address it is communicating from. Leveraging this, nodes can be restricted to allow participation only from selected network ranges giving us a degree of control over the transport network beyond just the nodes identity. Rules can also restrict communication to subsets of nodes, allowing a set of core nodes to be defined as the backbone of an enterprise blockchain.
The account permissioning interface provides robust flexibility to control the actions taken by accounts with almost any attribute of a transaction being subject to permissioning. Basic account permissions can state which accounts can participate in the blockchain and which contracts or accounts they can interact with. Limitations can be imposed on value transfers with restrictions on how much can be transferred between specified accounts. Gas prices and limits can be restricted to enforce minimum or maximum gas commitments or provide flexible gas limits that depend on who sends the transaction. The model can restrict which accounts can create contracts or execute code on existing ones, allowing for faulty contracts to be blacklisted. This flexibility opens a whole new realm of possibilities for how an enterprise Ethereum network might be controlled.
With these new flexible interfaces, operators have free reign to define the administrative mechanism for their permissioning model as they see fit. Depending on the intended use case, permissioning can be controlled by a central authoritative board of super users, an openly democratic voting system, or a mechanism that applies a mix of these concepts with administrators defined for groups of rules. Whatever the requirements of the network operators, the Ethereum client implementations no longer stand as an impediment to these designs. New clients can participate in these networks without requiring custom work from the various implementers.
At PegaSys we are extremely excited by the new opportunities these changes open up. We have included support in the Pantheon client for on-chain node permissioning since version 1.1, and are planning to support on-chain account permissioning in our upcoming 1.2 release.