Ethereum, The Three Ps And Blockchain’s Future
~7 min read
Whether you believe in Bitcoin or not, the blockchain technology it’s premised on is generating buzz across virtually all industries (digital finance very much included). That isn’t the case because Bitcoin is particularly useful for these industries, but rather because developers are using blockchain to create innovative platforms and tools which could revolutionize how organizations approach computing.
One such platform that is plunging headfirst into the depths of commercial viability is Ethereum. Most of the time, the mentioning of Ethereum is in reference to the public Ethereum blockchain, which is the platform for the world’s third largest cryptocurrency. However, predicated on the same code that powers public Ethereum, it is possible for organizations to deploy their own private versions of the blockchain. This allows organizations to host data, apps, and business functions in a secure, decentralized environment which features all the interoperability and benefits of Ethereum. Proponents call this idea “Enterprise Ethereum”, and various groups have been formed to evangelize it.
The Enterprise Ethereum Alliance (EEA) is a standards-producing organization whose board members include major banks, tech companies and consulting firms. At Devcon4 last month, the organization released v2 of their Client Specification document, which establishes specifications for Enterprise Ethereum blockchain implementations. The EEA believes that these specifications, if adopted by developers, will guarantee interoperability between decentralized applications (dubbed as Dapps) on private versions of the Ethereum blockchain.
Without question, interoperability is an important factor not only for Ethereum adoption, but also for blockchain-based solutions at large. If Dapps on an Ethereum blockchain can conform to a single set of specs, they can more easily be tapped for complex, compatibility-dependent tasks (say, data migration for reporting across business departments, for instance).
There are practical reasons to keep things predictable, too; the EEA report’s authors point out that “interoperability allows enterprise users to leverage the widespread knowledge of Ethereum in the blockchain development community to minimize the learning curve for working with Enterprise Ethereum, and thus reduces risk when deploying an Enterprise Ethereum network." To put it simply: there is a lot less noise when everyone is singing from the same sheet of music.
So what will it take for Ethereum, or blockchain at large for that matter, to go from garage band to Bohemian Rhapsody? The EEA’s client spec introduces three requirements which Ethereum (read: blockchain) will need to address in order to be viable for use on the enterprise level for applications like digital finance projects (and they all helpfully begin with the letter P): Performance, Permissioning, and Privacy.
Performance Enhancing
“Ideally, increased usage of the network does not degrade its performance.” Vitalik Buterin, co-creator of Ethereum
Mr. Buterin has voiced his vision that Ethereum will eventually reach “Visa-scale transaction levels." Visa’s purported 24,000 transaction-per-second (tps) capability is seen by some as a high watermark for blockchains. If a blockchain-based finance solution is to be taken seriously, it must perform at least as well as our current centralized systems do. And while Visa’s 24-karat claim is only an upper ceiling based on potential server output (the effective real-world figure is closer to 1,700 tps), the point is that Visa has sufficient horsepower such that performance will never become an issue, no matter how many users want to transact on the network.
Ethereum needs to perform at or near Visa-scale if it is going to support applications for enterprise use. The EEA suggests that it may identify “enterprise appropriate transaction rates based on the needs of EEA-approved vertical business segments” and offer certifications of compliance for applications meeting their standards. But scalability is not just a sought-after feature for Ethereum. In fact, for any blockchain-based solution that hopes to reach even a modest level of adoption as a payment method, development platform, or smart contract framework, performance at scale is the grail.
Currently, the public Ethereum network processes between about 6 to 12 transactions per second — enough to amount to between half a million and a million daily transactions, but still markedly short of Visa’s capacity. To improve performance at scale, Ethereum may soon offer upgrades like sharding (in which changes to the blockchain are processed piecemeal, then validated by trusted nodes, improving efficiency).
Bitcoin enthusiasts, on the other hand, have implemented soft forks like Segwit and even hard forks a la Bitcoin Cash. Changes to improve performance often demand a tradeoff in the form of increased centralization, but for enterprise implementations, decentralization may be less of a “must” and more of a “nice-to-have." Some performance solutions could therefore gain popularity for enterprise implementations despite a lack of appetite for them on public Ethereum.
Politely Permissioning
“Enterprise Ethereum implementations [must] enable restricted operations based on user permissions and authentication schemes.” v2 of the EEA's Client Specification document
Permissioning is the idea that certain users (or groups of users) should have different levels of access to the blockchain. What makes it a pivotal feature is that, as the EEA report’s authors reminds, “permissioning and privacy are interrelated concepts”(45). (More on privacy later to come later).
With proper permissioning, information and tasks can be made available to those who need them, while system-altering changes can only be made by select actors. Access can be widened or curtailed. Accountability can be determined at a highly granular level. No one can act unilaterally without designation. It might sound reminiscent of your family computer’s security settings. But what makes this kind of permissioning different (and much, much more secure) is that permissioning on Enterprise Ethereum can be done via smart contracts.
Smart contracts are trusted, programmable instructions which automate processes in a decentralized system. In other words, users agree to the rules set forth by a smart contract, and then the contract automatically enforces those rules (including permissioning) and carries out previously agreed-to tasks. Per the EEA’s specs, permissioning is executed on the blockchain by placing each entity into one of four categories via smart contracts:
Participant
This entity is a user with a unique name and identifier. It can be given or stripped of an Ethereum account, and can endorse other participants. It can be used to track and direct what users do on the blockchain, and provides accountability in the form of an identity attached to actions on the blockchain.
Participant Group
This entity is a collection of participants, Members can be added to or removed from the group. There are various ways in which participants in a group can act on behalf of the group, as determined by the smart contract of the group in question. The Participant Group is useful for controlling server functions and for keeping track of who has access to what on the blockchain.
Network
This entity is a collection of participant groups. The Network smart contract determines which participant groups are allowed to connect to the blockchain, and how they can do so. The blockchain can therefore only be altered by certain members of certain participant groups with the correct permissions.
Permissioning Decider
This entity changes the permissions of Participants, Participant Groups, and the Network. It is itself a smart contract, and can include methods for itself to be changed under particular conditions.
The kind of permissioning called for by the EEA “bakes in” privacy into a blockchain implementation. If the agreed-to smart contracts work in conjunction with one another as intended by the system architecture, then enterprises can expect that the blockchain will be just as secure as any centralized system would be while still enjoying the benefits of decentralization.
Pardoning Privacy
“Privacy … refers to the ability to keep data confidential between parties privy to that transaction and to choose which details to provide about a party to one or more other parties.” v2 of the EEA's Client Specification document
Not so long ago, providers of cloud computing services faced a challenge similar to the one that blockchain’s proponents now contend with. They needed a way to convince customers who dealt in sensitive data that the cloud was a secure place, where their data couldn’t be accessed by just anyone. Whole industries (e.g., the healthcare, banking, and public sectors, to name a few) were reluctant to relinquish on-premise control over their data because, at the time, the idea of using someone else’s servers to host an organization’s data sounded like asking for trouble.
Fast forward a few years, and the cloud has effectively penetrated even the most privacy-obsessed sectors. An October 2015 survey of banking industry experts revealed that 74 percent of stakeholders believe the cloud will be a major factor in banking by 2021. 71 percent of healthcare experts answered similarly when asked about the same line of logic as it related to their industry. A 2016 report by Deloitte made the claim that “By 2020, a no-cloud policy will be as rare as a no-internet policy is today."
Attitudes are clearly shifting. By heralding innovative new features like fully homomorphic encryption (which enables cloud servers to process customer data without decryption) and brandishing heaps of security certification schemas, cloud providers have been able to effectively make the case to businesses of all stripes that the same tech which seemed too risky to them just a few years ago is now a safe and cost-effective option.
Blockchain could earn a place at the table in much the same way. It will require, however: an awareness and understanding of blockchain by a larger and more diverse audience; a promotion of innovative, real-world answers to the biggest doubts surrounding the tech by influential groups like the EEA and Hyperledger (with whom the EEA recently entered mutual membership); and a long-term outlook by all parties. It was unclear in 2006 what AWS would one day become, and even less so what it would do to shore up customer privacy; today, it is a $20 billion HIPAA-compliant heavyweight commanding a full third of the cloud infrastructure market.
A Formless Future?
Alongside permissioning and performance at scale, privacy measures as enumerated in the EEA’s specifications (e.g., off-chain trusted computing, encryption, or privacy levels) could in time earn enough of the public’s trust to make blockchain-based solutions the new normal. What difference could this make in digital finance?
The crystal ball has its third eye on the potential of smart contracts. With trustworthy contracts in place, processes like new clients on-boarding, verifying transactions, and expansion into markets could be automated. As security and privacy measures can be “baked in” to smart contracts on Ethereum, the need to spend resources on additional security measures is softened.
Furthermore, when implemented in a fashion consistent with the EEA’s vision, Enterprise Ethereum would give organizations advantages like interoperability between Dapps, common interfaces and APIs, and improved efficiency due to the distributed, decentralized architecture inherent to blockchain implementations. What is needed now, however, is the full investment by companies (whose membership in the EEA bestows upon it a degree of credibility) in the still-experimental tech of blockchain.
Image courtesy of [Chronicled](https://blog.chronicled.com/eachronicled-launches-quorum-blockchain-integration-at-enterprise-ethereum-alliance-kickoff-e8283eb15c1e)
Click here to subscribe and receive a weekly Mondato Insight direct to your inbox.
Baking Financial Literacy Into Product Strategy
Beyond The Binaries: Mobile Money Access Revisited