Enterprise blockchain : opportunity and Obstacles. How Aergo paving the way!!

I believe that enterprise blockchains operate under different assumptions and environments from public, generic blockchains. With the deployment of Coinstack, Blocko gained first-hand exposure to the reality of enterprise blockchain adoptions.

• Unlike public blockchain users, who usually operate blockchain nodes on commodity hardware, businesses tend to run blockchain on server grade hardware with vast computing power and storage.

• Businesses want to run blockchain not only on cloud, but on private cloud and bare metal machines as well. The functionalities provided by private cloud and bare metal environments differ significantly from public cloud services.
• While public blockchain users run blockchain nodes at small number, businesses want to run a large number of blockchain nodes in order to take advantage of horizontal scalability and availability.

• Businesses need more control and functionalities related to the administration of blockchain than public blockchain users. • While most of applications running on public blockchain are self-contained or dependent only on assets on the blockchain itself, businesses want to connect applications running on blockchain with many external and internal systems such as e-mail, SMS, databases, LDAP, and public data.

I explore below a number of other key attributes we believe that are integral to enterprise focused blockchains.

SCALABILITY: Since enterprise blockchain users typically have better access to hardware in terms of both quantity and quality, enterprise blockchain implementations need to scale both horizontally and vertically.

INTEROPERABILITY :Enterprise environments tend to depend on diverse range of technologies accumulated through years of operation and enterprise blockchain implementations need to work with both modern, standard interfaces such as OAuth and old, propriety interfaces such as Active Directory.

DEVELOPMENT ENVIRONMENT: Since the majority of enterprise development tend to be project focused, there is little room for experimenting and learning new languages and tools for the developers; instead of forcing developers to learn new languages to create smart contracts, enterprise implementations need to allow developers to leverage their existing knowledge and experience with familiar toolchain. At the same time, certain resources web developers take for granted, such as unlimited internet access, are not available for enterprise developers. As a result, enterprise blockchain implementations need to supply a more comprehensive development environment with IDEs, SDKs, and reference architectures than public blockchain implementations.

DATA PRIVACY: Businesses face pressures to ensure stringent data security in terms of confidential information and also customer / employee personal data. Often the desire for data security is a more important consideration than the immutability and integrity of data provided by blockchain. While one way to achieve data security on public blockchains is to implement an encryption and decryption layer at the application level. enterprise blockchain implementations need to provide a more robust, holistic approach to securing data.

PROVISIONING AND ADMINISTRATION: While web developers are happy to use Vagrant or Docker on their laptops, enterprise IT is more comfortable with bigger guns like Tivoli Provisioning Manager, OpenStack, or Kubernetes. Enterprise blockchain implementations need to support integration with existing technology for provisioning and managing in enterprise IT and provide much richer suite of functionalities for 6 administration. Export and import, backing up the data, monitoring, logging, and data migration are typical features overlooked by public blockchain implementations, but important in the enterprise environment.

STRUCTURED AND UNSTRUCTURED DATA STORAGE: Smart contracts provide the foundation of functionality on both public blockchain and enterprise blockchain. Unlike dApps built on public blockchains with their access to cloud-based storage and CDN providers, dApps on enterprise blockchains need to be more self-reliant and enterprise blockchain implementations need to accommodate them with rich functionality for both structured and unstructured data storage.

AERGO is designed to be a holistic, multi-purpose platform, that bridges the gap between public blockchains and private blockchains. In order to be effective under both environments, AERGO is intended to be compact, yet flexible in design. In order to service multi-tenant workloads with potentially millions of concurrent users accessing the same set of nodes, AERGO intends to borrow many concepts from both traditional database designs and distributed computing.

DISTRIBUTED DIRECTORY Distributed Directory (DD) is a core functionality that is intended to be used as a building block for the whole AERGO implementation. Each DD in a repository is proposed to manage an independent, isolated namespace. Each namespace contains information about different branches and tags residing in the repository, as well as the validity of various identifiers on the blockchain. Each DD is intended to be a blockchain on its own, with its own genesis block and the best block. Unlike conventional blocks, DD blocks are limited in size with a relatively long creation interval between them; since DDs are used for managing metadata, they need to be compact. DD is comparable to data dictionaries in databases, zookeeper for Hadoop, or etcd for CoreOS in its role and functionality.

a. Tree of Life (ToL) The ToL namespace of a DD is proposed to contain information about all the branches in the repository, as well as their genesis blocks or root blocks. The information about tags are managed inside the ToL namespace as well. As a result, the ToL namespace contains information about the best block of each branch as well; since the HEAD tag continuously keeps track of the best block of each branch.

b. Distributed Directory Service (DDS) The DDS namespace is proposed to contain entries for different entities on blockchain; their public keys and validity, as well as associated roles and permissions. The DDS namespace is intended to serve as the basis for access control for AERGO repositories. Each entity can represent either a client-actor or a server certificate. For entities with server certificates, DDS can serve as both Certificate Revocation List and a DNS with routing information. AERGOFS, the proposed distributed file system component of AERGO, is intended to be dependent on DDS, since DDS keeps track of data volumes consisting each AERGOFS instance. In turn, AERGOFS can be used for storing blocks and indexes for different branches in the repository. The DDS namespace forms the basis of identity for nodes to participate in the core consensus process as well.

CONSENSUS ALGORITHM

a. Core Consensus The core consensus algorithm is intended to be used for building the DDS. The core consensus algorithm and the DDS are mutually dependent, since the core consensus algorithm needs to access the DDS within the DD to enable mining new blocks. The proposed core consensus algorithm of AERGO is Delegated Proof of Stake (DPOS)5 . DPOS is the preferred consensus model because, in summary: • We believe it provides the scalability and the simplicity of operation required by a core consensus; and • DPOS operates under the assumption that block reorganizations can happen, which means it is an optimal algorithm for powering the underlying infrastructure of AERGO.

b. User-Defined Consensus By default, each repository uses the core consensus. Since AERGO intends to provide a pluggable architecture for consensus algorithm as well, different consensus algorithm modules can be used in place of the core consensus. Notably, RAFT (for development) and PBFT (for strict-ordering) are useful for developing and running different services. Using the same toolchain for building smart contracts, a user-defined consensus algorithm can be used for each repository as well. The user-defined logic can govern how following events are occurred and managed in the blockchain.

• Block creation and its permission
• Block transmission and priorities

Since block branching and merging can be perceived as block reorganization events as well, the same policy for block reorganization is used for distributed version control as well. From version control perspective, the block reorganization policy is called “Consistent Merging.”

SMART CONTRACTS : AERGO supports a multi-paradigm, plugin-based smart contract infrastructure. Each contract can be executed or queried by a client-actor or another smart contract instance. Since AERGO provides a permissive interface with maximum interoperability between smart contract implementations, contracts written for Ethereum Virtual Machine, Fabric Chaincode, or AERGOSQL can be used with each other.