In particular, we’ll focus on three key areas of functionality:

Data coordination — How information and trust within a system is better distributed and allocated among stakeholders

Cryptoeconomic internal incentive layers — How is a system architected so that different stakeholders and users are motivated based on economic incentives to ensure functionality of a system eg. Game Theory and mechanism design.

Integration into the digital commoditization of assets — How the systems can integrate into a digital goods economy. In some nominal characterizations this is known as the token economy

Main goals of blockchain: what do businesses want to achieve with this technology?

Blockchains such as Ethereum have similar goals to their distributed leger counterparts. Identifying the goal of what businesses hope to achieve using blockchain technology can be a challenging approach, because like the internet in the 1990’s, businesses did not yet know how to conceptualize the use of the powerful tool. Similarly today, it is known that blockchain technology is capable of instantiating various functions, though how to architect those functions into a business solution requires further insights and assessments of the underlying capabilities.

The three main axes explored — processing and coordination of data, trusted and immutable records, and digitization of assets — are broad enough to encapsulate the primary usability of a blockchain while allowing for further extrapolation of those functions into business scenarios. By discussing these three aspects, it is possible to reveal the meaning behind why a business entity would want to use the technology.

Efficient processing and coordination of information

If improved distributed system design or database coordination is the sole purpose of a protocol or platform, then perhaps a blockchain is not necessarily what is needed. Blockchain platforms have traditionally promoted the concepts of better data coordination and distributed consensus mechanisms in which data is facilitated and transferred through a technology platform. While useful, a significant portion of these desired functional traits can be obtained through better coordination of a central database or improved distributed systems design. In this investigation, it is necessary to determine the extent to which platforms and protocols are trying to optimize existing data coordination functionality versus implementing new blockchain functionality. Blockchains are designed for more than just advanced data coordination.

Immutable/trusted record of the products and transactions

The original thesis around why we need blockchains revolved around the concept of digitizing trust. A theme promoted by Andrew Keys of ConsenSys is that “As the internet resulted in a digitization of information, blockchains result in the digitization of trust and agreements.” This meaningful thesis embodies the ethos of what blockchains hope to achieve while also paving the way for a further path. The additional variable would be the digitization of value. When value is attached to the trust that is implemented into a system, then certain alignment structures and incentive mechanisms will influence and incentivize proper behaviors within a system, resulting in a robust platform.

It is often the case that immutability is used synonymously with trust when designing a system ie because the system is immutable, it is trusted that bad things will not go unpunished. Though in our platform protocol assessment, it is important to also assess the mechanisms behind how a trusted system is implemented to ensure a business model that can be beneficial to users of a platform (further exploration through cryptoeconomics).

Digitalization of assets

The digitization of goods and assets is considered a primary goal for most blockchain or distributed ledger platforms. If businesses are looking for digitization of assets, a distributed ledger or coordination of a database is able to offer some capabilities though much consideration should be put into the accessibility of these digital goods. Because coordinated databases are essentially centrally run or distributed among a group or subgroups of counterparties via a legacy software paradigm, the levels of digitization may be limited based on the freedom that is afford by the digitizing platform. While the concept of digitizing goods sounds like a simple process, the different incentivisation dynamics and economic reasonings around how goods such as real estate, human attention or even electricity are digitized requires significant consideration into what type of platform would be responsible for the digitization as certain vendor platforms do exhibit degrees of “vendor lock-in” and reliance on a centrally managed platform in various instances.

Records and registries like titling systems and supply chains are also feasible via a distributed ledger system though their level of interaction with an economic incentive layer is fairly limited if reliant on a closed proprietary system, and a proliferation of those assets into a digital ecosystem or marketplace would be severely stunted if based on closed rails. A free market system that fully utilizes the various facets that the open market is able to provide is necessary to facilitate true digital goods in a constantly developing digital ecosystem.

Assessment of database coordination characteristics

Database Coordination: Characteristics

While in-depth analysis has been performed on the functionalities of these platforms in terms of characteristics like immutability, security, scalability, manageability, and performance, much more can be ascertained through understanding the foundations upon which the architectures are built.

Many tools have been invented and implemented for proper data coordination within distributed systems. One example would be heavy emphasis on tools like Hadoop and the various ensembles in this ecosystem including Spark, Hive, and Zookeeper. A reliance on these products show a heavy integration of distributed system tools and protocols. Further parallels can be shown in protocols such as Tendermint, a BPFT consensus engine being designed with similar functionalities as tools like Apache Zookeeper. Internally there has also been research along the lines of event sourcing databases which can replicate several functionalities desired from a coordinated data sharing system.

Through assessing tools like Apache Kafka and how the data streaming service is able to achieve significant levels of throughput in an enterprise setting, we can demarcate the functional differences between a blockchain and a distributed ledger based on varying levels of dependency on these database coordination and optimization tools in terms of the foundational concepts. Implementations of Ethereum including Plasma are utilizing tools like MapReduce to augment certain mapping functionalities on top of a UTXO and account based model while also reducing components into merkle proofs, though it is important to realize that the base layer of the protocol is still reliant upon Ethereum as the root blockchain. By decomposing these details, further insight can be obtained on how best to assess technological characteristics of these software platforms.

Data Coordination: Platform Comparison

IBM Fabric

Through a deep dive into Fabric architecture, it can be determined that the platform has created an intricate development environment focused on allowing superior throughput based on detailed configurations of the software architecture for optimal performance in a distributed systems environment. The movement of chaincode between the client and a network of distributed endorsing peer nodes along with the transaction mechanisms and transfer of receipts that satisfy endorsement policies is effective in the closed system, while the gossip protocol that propagates transactions within private channels allows for the coordination of large datasets. While the infrastructure is robust and capable, additional consideration should be put into the thought process of how the architecture was designed to allow multilateral coordination structures where there may eventually be a factorial of channels involved in a network which can be difficult to manage.

Figure 2: Hyperledger Fabric Architecture

This figure demonstrates some of the architectural configuration of Fabric and how components are organized into a system designed for advanced information processing and maximum transaction throughput.

The main idea is that channels provide opportunities for moving transactions along within the platform. In looking at the architecture, the function of ordering service nodes (OSNs) serve to record transactions in the Apache Kafka ordering service. In the data streaming ecosystem, Kafka is a powerful tool with capabilities of appending various forms of transactions into separate Kafka clusters and eventually partitions.

In this setup, data is able to be distributed across clusters to formulate a distributed storage platform that can record the data structures that are sometimes referred to as “blocks” or blobs within the Fabric definition of “state” in the context of their key/value store configuration. A conceptualization to acknowledge within this software framework is that all of the participants and data structures within this ecosystem are native in that they function primarily alongside other users within this software ecosystem.

Figure 3: Apache Kafka

Source: Apache Kafka

Fabric does in fact employ a ledger-type substructure that deploys certain hash linked data stores, though it should be recognized that the configuration of the hashes does not follow the original architectural design affiliated with a blockchain system derived from Bitcoin or Ethereum. While data blobs are batched and undergo deliver events to eventually create a hash link of the transactions, it must be understood that this process does not necessarily transition the data into a modification of the system’s state. Rather, the blocks are configured in a way that the information is stored in a database type structure with different instances of hashes.

In the Fabric ecosystem, deliver events are called blocks while chaincode goes through deploy events to eventually secure the data within the chainpartitions of the ordering service structure. The configuration of the data-structures and modules of this system are able to allow transaction throughput that would be expected of the distributed database architecture, though it should be acknowledged, that asset-code coordination is still a challenge that has not been completely solved within the Fabric ecosystem as assets and value do not necessarily have a digital representation that can be coordinated within the ledger.

R3 Corda

R3 Corda is built on an environment that does not claim to a blockchain, but rather a decentralized database that utilizes various forms of structural reconfiguration toward building a system that would primarily be used by banks and other institutions for their processes. The platform borrows heavily from the UTXO model used in bitcoin transactions where state is defined by a series of inputs and outputs and the varying reconfigurations of the inputs can dictate the state of the output.

The R3 Corda architectural framework relies upon a nodal structure that is reliant on submodules called notaries that help maintain the validity of a network similar to validator structures in other platforms that abstract the function of consensus. Nodes are accompanied by relational databases that are appended within the data-structures allowing for querying using SQL. Transaction communication is restricted within subprotocols called flows.

These flows are comparable to the channel architecture that is seen in IBM Fabric where only individual parties privy to the transactions are able to access the information. Classes undergo transformations that result in state machines called fibers or co-routines. The architecture relies on flows communicating with sub-flows and interacting with libraries of flows that have predefined functions within the confines of the platform. Additionally, there is a self-contained identity layer within Corda that allows varying degrees of access control within the overall network.

While R3 Corda has openly stated that it does not intend to be a blockchain, it should be taken into consideration that the reconfiguration of the concept of a distributed database to a decentralized database does rely fairly significantly upon traditional database systems. While the system is architected around novel data-structures and different compositions of how a distributed system is organized, the platform does have data allocation in mind and does find various ways to optimize the functions of a data distribution system. One thing to keep in mind is that because the system is limited to certain facets of data coordination in the confines of a specific architecture, integration into actual blockchain systems has been sacrificed as modularity and interoperability were not implemented for the original design.

Figure 4: R3 Corda Workflow

Figure details: the workflow of transactions within Corda and how Input states and Output states are moved through the system and how documentation is appended into the workflow process.

Ethereum

The Ethereum ecosystem is built from a combination of private blockchain and public blockchain ecosystems. The public chain does not have anywhere near the throughput and data processing capabilities as described in the data coordination context so should not be assessed based on those capabilities. When assessing this aspect of Ethereum, it makes the most sense to synthesize the different nuances of the network topology of private instantiations of Ethereum.

The Ethereum Yellow Paper adamantly decrees a set of specifications on what constitutes Ethereum as well as the technical particularization of the codebase. Due to this strict adherence to the blueprints of this protocol, forks of Ethereum, as well as consortium implementations, do resemble the original substrate upon which the technology is built. In fact, the same specifications are continuous whether in a proof of work, proof of authority, or proof of stake implementation because the protocols are considered progeny of the same Ethereum Virtual Machine (EVM) specifications.

Modified architectures still specify alignment with the original EVM. Key changes in platforms like Quorum include an alteration of the consensus mechanism, modification of global state roots to accommodate private and public states, alterations of State Patricia Merkle tries, and additional modules to handle private transactions. The architecture allows this software to maintain the lineage and data structures from the original Ethereum configuration while also offering increased transaction throughput via the alterations. In addition to the improved data transaction optimization that Quorum provides, the capability of coordinating and integrating with public Ethereum environments via tools like Plasma, Truebit, and Cosmos provide additional extensibility to the protocol.

Through technical evaluations of tools like Plasma and formats of obtaining consensus in Casper, it is apparent that database management tools like MapReduce and Abstract Rewrite Systems will be implemented in Ethereum. In Plasma, MapReduce is an integral part of assembling the coordination of an account-based system and a bitmap-UTXO commitment structure of a multichain setup.

The orchestrated transaction processing paradigm using the interplay between rootchains, plasma chains, and child chains through a combination of fraud-proof mechanism designs and fidelity bond incentive structures help satisfy dynamics between the block-withholding and mass withdrawal surfaces. It also allows for further cryptoeconomic structures to be filled using mechanisms from systems like Casper or Truebit for mirroring concepts used in erasure coding in terms of the data availability problem that is prevalent in the space. For a multichain architecture, Ethereum would be able to combine the database coordination and throughput capabilities of a distributed database system with the public chain compatible capabilities of an actual blockchain.

Database Coordination: Conclusion

A viable conclusion regarding the database coordination spectrum of capabilities would be that IBM has superior database management toolsets due to a reliance on traditional database and distributed systems software architecture, based on the overall monolithic design and substantially resource-intensive process that went into building Fabric. R3 Corda is still further defining its capabilities, while offering several coordination services to banks and financial institutions in a private reconfiguration of nuances from the bitcoin protocol. Ethereum, while designed for public chain compatibility, does not have the raw database processing capabilities of IBM Fabric, though it does have certain coordination schematics within the context of scalability for enterprise use cases that Fabric does not have.

Private instantiations of Ethereum and complementary clients are able to act as the architectural building blocks upon which larger systems can be built, based on modular design that adheres to a comparatively unix-based philosophy. The Ethereum related codebases are designed to rival the transaction throughput capabilities of the database platforms like Fabric while allowing functionality that is nonexistent in both Corda and Fabric, though complementary relationships can also be explored across platforms. The main differentiating factors may be further elucidated from assessments of the subsequent factors.