Signals in the Noise: Simplifying Ethereum for Enterprises

Answers to common questions about public and private blockchains, scaling, energy usage, forks, and more.

I was at a lot of blockchain conferences in May (who wasn’t?!) representing PegaSys. With tons of newcomers in the blockchain world, it was not that surprising that there still remains a lot of confusion and misinformation around what “using” Ethereum really means. Many attendees were just asking for a definition of what Ethereum actually is. Cryptocurrency? Protocol? White paper? Finding the signal in the noise can be challenging, particularly as much of the Ethereum documentation is very technical and developer-focused. To help add some color and clarification, we put together the most common questions we heard from companies looking to build on Ethereum.

Isn’t Ethereum a public blockchain/cryptocurrency?

There is a public Ethereum blockchain, yes. That public blockchain has a native currency known as ether, which is used to fuel the massive public network that many teams are building on. But for now, most large enterprises are using private instances of Ethereum, which can be run using the same open-source software with some minor tweaks to the configuration.

There are also Ethereum solutions like Quorum that use Ethereum’s software and tooling with some slight modifications. Quorum is private by default and involves additional tools for security such as a secure enclave.

So what should I use — public or private networks?

Unless you want to trade an asset or need retail users immediately, private is a good place to start experimenting. A private network is still built using the same languages and tools as the public Ethereum blockchain, meaning users benefit from the depth and maturity of the ecosystem. In the near future, enterprises are likely to start using the public chain as a “notary” where data and agreements are certified (OpenLaw) or value stored in escrow, though many of these projects are still in pilot.

There are also a few enterprises doing specific cases on public Ethereum.Nivaura is known for doing settlement for various financial instruments. Hedge funds, banks, and other institutions are using it to transfer and store funds. Asset-backed tokens are growing rapidly, including real estate projects like Meridio.

Long term, many people in the Ethereum space see public and private networks converging, and some new projects like Clovyr are working to make this more likely.

I heard Ethereum has a maximum of 14 transactions per second?

Not quite. The public network targets to create a new block every 13 seconds, but block sizes can, and likely will, change based on custom parameters, primarily the gas limit. Extensive scaling efforts are also underway, including sharding, which PegaSys is highly focused on. Sharding will introduce exponential scalability.

There are also custom ways to speed Ethereum up in private networks:.

Proof of Authority (PoA). This includes using Proof of Authority consensus, which is currently run on Ethereum’s Rinkeby test network. Rinkeby reaches typically 44 t/s with hundreds of nodes.

Custom block time and gas limit. Lowering the block time by some factor will have an inverse multiple effect on t/s (halving block time will double throughput). At ConsenSys, we’ve experimented with very small networks of just a couple nodes with sub 1 second block times, reaching a maximum of 10,000 t/s (though with many issues, and tradeoffs will occur, such as uncles, syncs, etc). Increasing the gas limit will result in bigger blocks, potentially increasing the t/s, though this depends on the compute power of the network. Nonetheless, the point stands that 14 t/s is in no way a hard cap upper limit.

Doesn’t Ethereum use a ton of electricity?

Not necessarily. With a private network you can use PoA (or IBFT, described more below) which can create consensus without the need for a constantly increasing block difficulty.

If you want to use the public chain, that doesn’t mean running up a huge electricity bill either. The public network does use Proof of Work (like Bitcoin), with plans to transition to a less intensive algorithm (Proof of Stake). Infrastructure tools like Infura also allow you to run an application without your own node. This frees up developers to focus solely on building applications without having to worry too much about the protocol layer.

I heard about the DAO “fork.” Does that mean blockchain data can be changed any time?

Public blockchains in general can be forked by anyone, as they are open source software and anyone could edit certain lines of code to start running their own chain (hence the ability to create private networks for enterprise).

That said, the “canonical” Ethereum chain will have finality before too long, via an upgrade called Casper. The first upgrade is somewhat jokingly referred to as Casper the Friendly Finality Gadget (FFG), as a protocol change that will introduce settlement finality through confirmations from at least one-third of the nodes in the network every 100 blocks (~25 minutes). This will prevent any similar forks in the future.

In private blockchains, there are other ways to achieve settlement finality, typically through specific consensus algorithms. Istanbul Byzantine Fault Tolerance (IBFT) is a specific kind of consensus mechanism that uses multiple rounds of voting and works well for a “semi-trusted” environment such as enterprise networks. Kaleido has written a good overview of enterprise-relevant consensus algos here.

I read about some big hacking incidents. Is Ethereum more vulnerable than other chains?

Most of the well-known hacks were on exchanges, which are not part of the Ethereum blockchain directly. Instead, these exchanges hold ether (the native cryptocurrency) in various types of wallets, which makes them vulnerable if not secured properly.

Solidity is the main language used for writing decentralized applications and has been criticized because of its construction and the ease of making mistakes. This led to issues like the DAO and the Parity wallet bug. The Ethereum community is working on a few improvements for this:

Formal verification frameworks and services are being developed that allow for mathematical certainty over the security of a smart contract.

A number of security audit services exist (ConsenSys Diligence, Trail of Bits) that can review smart contracts for any potential bugs.

Open source security tools (Mythril) can help catch some errors before contracts are written.

Upgradeable contracts are now deployed on the network, allowing for some things to be fixed after initial deployment.

New languages (Vyper, Bamboo) as well as new verified compilers (Elle) and WASM compatibility (i.e. the EVM running any LLVM-supported language) are being worked on to provide alternatives to Solidity

Very specific DSLs are popping up with higher security assurances than before (AxLang)

In addition, private networks used by enterprises can still have much of the same safety perimeter used in the typical enterprise IT setting: firewalls, VPNs, CAs, etc. There are some challenges with the peer-to-peer nature of Ethereum due to IT firewalls (too many IP addresses), but this would primarily be a problem seen in large networks, while most private networks are being deployed on cloud platforms such as Azure or AWS anyway.

Who is the Enterprise Ethereum Alliance (EEA)? What do they do? Are they part of the Ethereum Foundation?

The EEA is a trade organization dedicated to creating an enterprise standard for Ethereum. It is currently the largest such consortium with over 500 members from a number of industries, and founding members included Microsoft, JPMorgan, and ConsenSys. The EEA recently announced its 1.0 version of the EntEth specification, leveraging input from many different industries and use cases, and creating a target for software vendors to build towards.

At a minimum, companies that want to use Ethereum should be able to escape single vendor lock-in, since if they build on any EEA-compliant protocol, their applications should be portable to other versions. PegaSys will be building protocols in line with the spec as well — if you’re interested in working with us, please reach out any time.

Special thanks for Goncalo Sa of ConsenSys Diligence and Mostafa Farghaly and Matthew English of PegaSys for input and feedback.