This is Part 2 of a two-part comparative analysis of Ethereum, Hyperledger Fabric, and R3 Corda. Read Part 1 of Blockchain vs. DLTs.
Blockchain vs. Distributed Ledger Technology Platforms
It should be acknowledged that if database coordination and more efficient allocation of code is the desired functionality of a system, then blockchain may not necessarily be the solution for which an organization is looking. Distributed ledger technology (DLT) systems like Hyperledger Fabric or R3 Corda are capable of similar functionalities as blockchain systems, but it should be taken into consideration that blockchains are a separate subset of distributed ledgers that have additional functionality beyond code coordination. Blockchains are capable of functions that distributed ledgers are not in terms of instantiation of digital value based on the composition of the system.
In this document, architectural considerations will be explored that identify the aspects that contribute toward blockchain functionality. An examination would be that perhaps there is a tradeoff between what blockchains are able to accomplish and what DLT’s provide. DLT was meant for transaction processing in a shared trusted environment while true blockchains were designed to sacrifice the need for a trusted setup in order to achieve high fidelity and immutability of accounts. Aspects of high fidelity and immutability are integral for the success of properly digitizing assets. The analysis from this document will overlay architectural components across business processes in order to further elucidate these technological nuances across platforms.
Comparisons will be made based on several key distinguishing features that exist within the software platforms. The main areas that will be explored in this document include:
State: The state refers to the main unit of logic that code can be comprised of in order to facilitate the representation of information in a computing environment. While state can have various meanings in different contexts, the use of state within the blockchain and distributed ledger environment consists of the current configuration of a data structure’s ontological characteristic.
Transactions: Within a blockchain environment, transactions are considered the computational events that can lead to the generation of state or state transitions that occur within the development ecosystem. Transactions can either initiate contracts or call upon pre-existing contracts.
Smart Contracts: In assessing a blockchain platform from an architectural perspective, it is important to determine the structure of the smart contract code and how it functions in relation to the actual blockchain network topology. Smart contracts are considered the individual units of code that execute actions within the platform ecosystem.
The following table shows a brief overview of the main differences between the various technological features of the respective platforms.
I. State
Ethereum
As an ecosystem with shared distributed configurations, Ethereum instantiates the concept of “State” via a configuration of objects called “Accounts.” There are two types of accounts in Ethereum:
Contract Accounts — accounts controlled by contract code
Externally Owned Accounts — accounts controlled by a private key
Ethereum uses the concept of World State which is a mapping of account addresses and account states. The State_Root is a Patricia Merkle Tree root of the amalgamation of accounts in the system. And within the accounts, the contract states are also organized in this Patricia Merkle Tree data structure. The root hash of the state can be used to secure the identity of the data in the merkle tree allowing replication throughout the network which ultimately results in the theoretical immutability of the system.
Commentary
The functionality that the Ethereum World State creates is a trustless system that allows the instantiation of value in a digital format. Sources of digital representational worth that is native to the token economy can been derived from the composition of accounts and sub-data structures of Ethereum; the same way that logic gates are able to instantiate functional algorithms in traditional engineering.
Platforms derived off of Ethereum, including Ethereum clients and private implementations are able to benefit from this instantiation of worth by convictions to these standards in regard to state preservation and logic implementation. Platforms that fail to instantiate one of these logical value based functionalities will not be able to facilitate the creation of true decentralized digital asset values.
Hyperledger Fabric
In Hyperledger Fabric, state is preserved in a database structure with a reliance on key/value stores for the state. The interaction between Chaincode programs and how they are installed into the platform topology allow commands and actions to be issued into the system. These actions result in updates to the datastores as transactions result in updates to the state that is known as the ledger. The ledger is formulated as a shared distributed database that provides users with superior access to information and transactions that occur within the distributed computing environment. State is nested within the database environment via traditional software development tools:
LevelDB creates a key/value database
CouchDB would hold the Document JSON database
In the State Database, the latest version values for keys in the chain transaction log are stored as key/value pairs. Key values known as the World State are indexed for a view into the transaction logs that exist within the channel architecture. CouchDB acts as a separate database process that receives updates from the chaincode API’s.
Commentary
Hyperledger Fabric has created a process that supersedes key tenets of a blockchain system in exchange for achieving high throughput state transitions. The use of the current architecture allows states to be easier modified and manifested within a traditional software schema, resulting in read/write access. Though the arrangement of state within the Fabric environment is efficient, it lacks the capability to instantiate value in a public decentralized ecosystem, the same way that a true blockchain like Ethereum or Bitcoin would be able to do. The movement of data in the software environment of Fabric is indicative of what a distributed database is capable. The creation of digital assets within Fabric would essentially be digital information stored in a database that is controlled by the controlling parties or groups within a consortium without adherence to the economic structure of the digital goods.
R3 Corda
In R3 Corda, State is based off of sequencing and versioning of different datasets within the platform architecture. In the system, the Network maintains a Vault, which is a database that stores the historic states that are tracked within the system. In Corda, state is considered to include opaque data that is comparable to a disk file that is not necessarily updated, though rather used to generate new successors. This system acts as a series of modified and resurfaced state updates within an environment controlled and shared by the users.
In Corda, states are considered classes that store data. Classes are implementations of the “ContractState” interface which acts as the interoperability layer within the platform. The certain “State” datafields can include:
Issuance
Owner
faceValue and Amount<Issued<Currency>>
maturityDate
The format of this design was to allow the appendation of data in a chain of events allowing the capability to track the provenance of where data comes from in the controlled environment. Provenance is controlled by the members of the consortium that have certain access controls to the software platform. Using this setup, banks and financial institutions will be able to maximize efficiency in terms of processing information in a shared ledger ecosystem. Data can be better moved and processed between organizations while reducing the need for substantial trust between untrusted counterparties.
Commentary
This architectural setup is similarly able to process shared data in a semi-trusted environment where counterparties do not need to fully trust each other. Data can be successfully processed and appended into what Corda considers state, though the platform lacks the components of a blockchain system that can disclose unambiguous value. In Corda, state is not a logical construct, though rather pieces of information appended into a database-like ledger. While assets can be digitized and stored within the spent and unspent state format, the assets will not be able to be distinct units of value similar to how Bitcoin, Ethereum and the token economy create new markets, although the banking software could be a good trusted setup that can help act as an attestation hub for secure nonpublic information, similar to how the banking system currently works today.
II. Transactions
Ethereum is a transaction based machine ecosystem where the global state of transactions are stored within the blocks. When transactions occur, state transitions result into new states of the system. This process sacrifices the speed of fast database transaction processing for the integrity of a system that emblematizes the state as well as the transaction that led to that state within the blockchain Patricia Merkle Tree data structure configuration.
There are two types of transactions:
Message calls
Contract creations.
Transactions include an internal mechanism of value transfer. Value transfer inside contract accounts result in changes of state. Because the system is based off of the transfer of value between smart contracts that exist between transaction execution events, the various compartmentalized states can be used to instantiate high fidelity business logic and agreements.
Commentary
The key distinguishing feature of Ethereum is that transactions are used as the individual units of process within the Ethereum blockchain environment, and through this configuration keep a permanent record of transactional states within the system. Ethereum is capable of both traditional distributed ledger database related technological capabilities as well as coupling the desired trust with digital value. Technologies derived off of the Ethereum blockchain are able to group transactions and business logic into blocks of a blockchain. Business functionality derived from this setup include:
True digital economy
Digital goods and assets controlled by economic incentives as opposed to organizational/monopolistic incentives
Interaction interface between private institutions and the public digital economy
The architecture of Ethereum allows affiliated platforms to be able to instantiate cryptoeconomic incentive layers into the system. This means that various incentive layers and mechanism designs can be created to secure the overall network, versus a reliance on centrally controlled services provided by traditional software designs. This cryptoeconomic incentive layer can be applied to both the digital goods economy as well as the interface layer between private and public versions of a blockchain platform.
Hyperledger Fabric
All transactions are executed within the Fabric multichannel architecture to ensure high transaction throughput within the trusted environment. Transactions are appended to a shared ledger that exists within the runtime environment. With this architecture, Fabric allows read/write access and amenability to their software environment, allowing mainframe-like functionality and usability. It is known that SQL databases are several orders of magnitude more performant than any blockchain that is currently available, and the configuration of Fabric borrows a lot from paradigms used in traditional database tools allowing for the superior transaction throughput.
There are two types of transactions:
Deploy transactions — create new chain code. Installs chaincode into the software development environment
Invoke transactions — invokes previously created chaincode and the corresponding functions. When this is successfully executed, the chaincode fulfills a function and introduces changes to the state
Invoke functions result in ‘get’ or ‘set’ transactions
In order to maximize efficient data processing and superior speeds, individual transactions AKA blobs are batched by an Apache Kafka Ordering Service and outputted as “blocks” through a deliver event. The transactions (blobs) are ordered by the Apache Kafka Ordering Service and appended to the Kafka partitions. What this means is that the Fabric architecture sacrifices the integrity and data fidelity of a true blockchain system in order to obtain faster transaction processing and throughput within a trusted data streaming environment as apparent from the use of the Apache Kafka Ordering Service.
Commentary
Though the system utilizes blockchain-esque terminology, this is not a blockchain in the traditional sense, in that there is no preservation of state and complementary transactions in a Patricia Merkle Tree data structure. Hyperledger Fabric is a DLT, not a blockchain. The architecture of Fabric was designed for superior transaction processing as can be seen from the appending of data blobs into the Kafka data streaming ordering service. Because this is achieved in a trusted environment, executions can freely occur in the system. The use of this configuration in a value transfer system would not be ideal, considering that all trust would need to be attributed directly to one software architecture from one single entity as opposed to a shared ecosystem or protocol. As can be seen from the technical documents, Fabric has architecturally renounced data integrity and security achieved in blockchain platforms in order to gain superior processing between the transaction components.
R3 Corda
In R3 Corda, transactions are considered proposals to update the database Vault, which can be referred to as the ledger. Transactions must be executed in an environment where notaries can validate that they are not double spent and that they are signed by necessary parties. This is similar to the concept used in the bitcoin ecosystem, though the avoidance of double spending is facilitated by a trusted system.
There are two basic types of transactions:
Notary-change transactions — these are executed to cycle through notaries in the system. Notaries will prevent double spending and can validate transactions
Provide uniqueness consensus
General transactions — used for everything else
Transactions are proposed updates to the state of the database environment that require signatures to be validated from other parties within the system. In order for a transaction to be valid, it must:
Be signed by the involved parties
Get validated by the contract code that determines the transaction
The use of the UTXO-like model in a shared database environment allows the Corda platform to control the state as well as the transitions. Use of the Notary and various interactions between Flows and Cordapps in the network configuration show a shared distributed environment where state is preserved in a data format integral to the system architecture. The use of transactions to navigate the instantiation of states within the Node-based environment between Flows as well as the Cordapps that get programmed into nodes, indicate a viable means to execute state changes into a ledger.
Commentary
For the formation of digital assets, users and counterparties depends upon the trust of the overall Corda platform. While acting as a strong trusted shared distributed ledger system for keeping sensitive financial data, the system acts in accordance with various standards that exist in the banking ecosystem. The platform provides:
Superior storage of nonpublic financial data
Trusted setup for non trusting financial institutions
Advanced vaulting of business interactions
The architectural diagrams involving flows and runtime environments between nodes show that Corda was designed to partition access between the trusted members of its consortium platform. Though capable of certain aspects of usability, R3 Corda lacks functionality inherent in being a universal substrate for economic, social, and political value transfer, due to a lack of a cryptoeconomic incentive layer as well as a public digital asset environment. Because the system is closed, it lacks the necessary rails and technological traits for building an economic incentive driven ecosystem around. R3 Corda is most likely best used for certain facets of traditional banking infrastructure, though not digital asset creation.
III. Smart Contracts
Ethereum
In Ethereum, smart contracts are written in high level programming languages like solidity, LLL, or Viper and compiled into EVM bytecode, allowing binaries to be executed by the Ethereum Virtual Machine (EVM). Nodes in the Ethereum network run their own EVM implementation which acts as a runtime environment for smart contracts in the Ethereum ecosystem. State and transactions leading to state transitions are emblemized into the world state of the Ethereum blockchain through replication by the EVM, resulting in a system that can implement incorruptible trust on an array of spectrums.
The EVM acts as a runtime environment to recursively execute state transitions in order to compute the system state and machine state as it loops through the transactions.
System state = Ethereum global state
Machine state = business logic of contract accounts & code replicated in EVM runtime
As all smart contract code is replicated by all nodes in the EVM, Ethereum blockchain and related instantiations are able to preserve the validity of the code to ensure the consistency of the contracts. Consistency of the contracts contribute to the practical immutability of the Ethereum blockchain and its affiliated clients and implementations. Smart contracts on Ethereum bind the entire ecosystem together through instantiating transactions that eventually result in transitions to new states within the overall virtual machine environment.
Commentary
Because implementations of the EVM adhere strictly to the specifications as designated in the Ethereum Yellow Paper, different instantiations of Ethereum (public, private, and consortium) are capable of interoperability as determined from the common compilation of high level languages — in the form of smart contracts — into Ethereum bytecode by the EVM. From this disposition of Ethereum, it is able to act as the intermediary layer between various facets of large institutional private data facilities and the public digital goods economy that is currently evolving and coming to fruition from the recent creation of the token economy.
By allowing this functionality between Ethereum chains, entire interoperable systems can be built that allocate economic finality between systems of data coordination and processing in private Ethereum platforms to digital goods on the public chain. Smart contracts on Ethereum incapsulate programmable logic within these systems and allows developers to interact with the Ethereum Virtual Machine through transactions that create new state environments within the technological infrastructure. As comprehensive use cases develop within interoperable public chain, private chain, and consortium chain environments, the smart contracts used in Ethereum will be able to bind the systems together under a common logical interface.
Hyperledger Fabric
Chaincode is not necessarily a smart contract deployed in an account-based blockchain, but rather a program that is installed and which subsequently implements an interface through an API. The API interface requires the code based instructions to direct business logic and functionality throughout the system, similar to a traditional software development environment. Methods affiliated with the API include:
Init — initiation of application states
Invoke — processing transaction proposals
Chaincode must implement interfaces from the API:
Chaincode interface
ChaincodeStubInterface
In Hyperledger Fabric, chaincode is run in secured Docker containers, where it is isolated from processes executed by the endorsing peer. The code is normally written in Go or Node.js, allowing interaction that handles the business logic. A nuance to keep in mind is that the Fabric chaincode is not replicated by the nodes within the ecosystem the same way that it is expected of a true blockchain architecture.Chaincode is initially installed on Peers then instantiated into channels. The process flow is detailed in the following diagrams:
Chaincode can be configured to create assets that ultimately act as key-value pairs that are stored on the ledger database. The workflow of sending initiation commands and invoking the transactions are detailed in the above diagram in terms of how commands are moved through the system. The business logic is encoded within the rules of the network and invoked through client-side applications. The type of code coordination and interaction is very indicative of traditional software development through the reliances on traditional functions and initiation interfaces.
Commentary
The movement of Chaincode through this network configuration allows for a streamlined organization of the system. The software architecture is primed for acting as a very efficient command and control structure in terms of distributing data and organizing the software development environment for certain enterprise use cases. As can be discerned from the package, install, instantiate, and upgrade setup, this architecture was designed to optimize the necessary touchpoints required to process code. The necessary API interfaces as transactions get processed is highly reminiscent of traditional software design. Areas of note:
Monolithic architecture for maximum control
Secured business interaction between counterparties
Centrally coordinated processing for transaction throughput
Chaincode is more of a system of commands than it is a smart contract language that gets replicated by a blockchain. As the Hyperledger Fabric ecosystem has a vibrant set of strong characteristics in terms of functionality and design as a distributed ledger, the system does in fact lack the inherent qualities of a true blockchain system. As a tool that is usable for integrating with legacy infrastructure and paradigms, Fabric is effective due to its adherence to pre-existing software standards as can be deduced from the architectural design as described above.
Where Fabric gains in functionality in terms of its system that is somewhat emblematic of systems designed around large mainframes and data centers, it loses in other aspects in terms of distributed connection to economic factors of computation as can be accessed in an inherently decentralized digital token economy. If Fabric were to integrate into a true blockchain environment, it would fit well as a secure distributed database environment that validates information prior to interaction with a public blockchain ecosystem.
R3 Corda
In Corda, smart contracts are considered classes that implement the Contract interface. Smart Contracts are written in Java/Kotlin and are compiled through the Java Virtual Machine (JVM), which is the computing machine that the code is executed within. The main function used in the contracts is the “verify” function.
Code runs on the JVM where transactions are processed through the notarization system, and business logic is restricted within Flows that can house and insulate the business process between different counterparties.
Smart contract components:
Executable code
Validates changes in transactions
State Objects
Data held on the ledger
Current state of a contract
Uses inputs and outputs of transactions
Commands
Additional data
Used to instruct executable contract code
Java and Kotlin code gets compiled down into identical bytecode via the JVM. Commands pass additional data that does not exist in the state into the contract code. Commands act as data structures with attached public keys used to sign transactions, though it should be acknowledged that contracts do not work directly with the digital signatures. Contracts within this environment are replicated throughout the system in the context of how Flows are willing to coordinate between trusted parties.
Commentary
The contract code fits the needs of use cases within the Corda environment, and is able to accomplish the necessary functions of transaction throughput. Limitations include interoperability with other ecosystems. In order for systems to interoperate with Corda, they would need to utilize the Corda contract code framework designed around the closed DLT. Unlike a true blockchain platform like Ethereum which can act as the interoperability layer between economic processes and functions between private instantiations and public instantiations, Corda limits itself by being more focused on processes within a closed system. The use of the JVM is innovative though the instance is insulated within the Corda ecosystem. In this scenario, Corda gains transaction processing in a secured environment while sacrificing the ability to interoperate and coordinate between different blockchain environments like an interoperable system would be able to do.
IV. Conclusion and Assessment
Based on our analysis, the key distinguishing factors that Ethereum is able to implement beyond what is capable of DLT are:
Digital asset or token economy
Cryptoeconomic incentive layers in the protocol
Interoperability between consortium and public blockchains
While DLT’s like R3 Corda and Hyperledger Fabric are able to achieve functionality on the shared database management and transaction processing lifecycle, it is not guaranteed that they will be able to achieve the key functionalities as described above. These platforms are not flawed, but rather limited in their architectural configuration for exhibiting some of the pure use cases that only true blockchains are able to assert.
Blockchain technologies are designed to couple the trust instantiated within them alongside the tangible value that is created from that trust. Only through a true platform built from the core fundamentals of a blockchain will social, political and economic systems be able to be foundationally consecrated within the infrastructure of a software protocol. While DLT focused database management platforms can integrate and interoperate with a blockchain platform, the rails upon which value transfers and coordination of this trust will be built, must be a blockchain that embodies the core tenets of trust, immutability, integrity, and information fidelity.
What this analysis reveals is not that certain systems are better than others, but rather they are useful in different capacities. The ability of DLT platforms to act as private distributed databases with high transaction throughput and functionality, allow them to act as trusted systems that can interoperate within a blockchain platform when certain facets of private information are necessary for assessment, such as banking/financial data or sensitive information pertaining to the inner workings of a private institution that should not be revealed to the public. The various business models for how to utilize these sources of private data affiliated with DLT are still in development and should be iterated upon with blockchain interfaces in mind as a decentralized digital value system is necessary for some of the interactions between blockchains and DLTs.
Connect with our blockchain experts
Our global Solutions team offers blockchain training, strategic advisory, implementation services, and partnership opportunities. Contact Us