As Blockchain Proof-of-Concepts kick off around the world, entrepreneurs and enterprises alike are discovering the interoperability and scalability limitations of the solutions they’re attempting to create. Many of these applications require private transactions, permissioned frameworks, and payment agnostic structures that don’t naturally come boxed in with the Ethereum network.

The Ethereum network is not complete, but major improvements like the recent Metropolis update are due to arrive throughout the next few years. In the meantime however, Blockchain Architects and Technical leads need to re-frame the way they develop their blockchain-enabled technologies to best fit the constraining realities and requirements of the system they’re trying to fit into.

Amongst the many, lower-level concerns, here are a few obstacles that enterprise has had with Blockchain solutions:

  • The culture of enterprise has an innate unwillingness to accept public blockchains for network transaction confirmation or consensus
  • Many operational use cases for Blockchain have a need for processing transactions without fees via tokens or gas, as this doesn’t make sense for internal use cases to “charge yourself”
  • Ethereum, by itself, does not come with the permissioned frameworks necessary for applications to operate in enterprise environments
  • Financial culture (and legalese) prevent mainstream adoption and use of payment-focused tokens (for business to consumer applications)

To work through these obstacles, you’ll need to use Ethereum more as a consensus mechanism than a one-stop solution Blockchain architecture. Here are some actionable ways that you can use the security of the public blockchain while overcoming some of its (current) weaknesses:

  • Researching Ethereum fork networks that fit your transactional needs. Projects like Quorum and HydraChain
  • Heed the Ethereum wiki, as it has a detailed section on Consortium Chain Development including suggestions for consensus algorithms
  • Working w/ permissioned frameworks like Coco to make more robust Ethereum based blockchain networks (plug and play blockchain frameworks with enterprise-expected structures)

For payment agnostic blockchain considerations, researching projects like OmiseGo may assist with developing your future state network once the market matures. Teams like Storj are offering payment agnostic options in production with decentralized networks, so referencing their team’s approach may prove helpful as well.

Lastly, your team needs to break the “Web 2.0 forever” mindset. It’s great to be realistic with an MVP, but your team needs to think BIG. The Internet is changing — for the better — so there’s no time for small-time implementations that have a chance of being disrupted. Enterprise markets are thinking to small, sticking with short-term, operational solutions, rather than long-term market-making applications. Be the change — see what Blockchain needs and create it.


Author robbygreenfield

More posts by robbygreenfield