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.

IBM 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 IBM 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:

Throughout the Chaincode process flow, various interactions occur with System Chaincode, which runs within an executable peer process versus an isolated container. This is used to implement system behaviors without endorsement policies or lifecycle processes. System Chaincode does not go through the code lifecycle of normal Chaincode.

Two functions from the Shim API of the chaincode interface get implemented. The code is compiled and maintained by the peer. Chaincode is not affiliated with channels or orderers until the developer determines that they wish to further install the program.

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 IBM 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 & 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 IBM 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 DLT’s. Further insight regarding some of these interoperability interfaces will be further explored in Part 3 of the Blockchain vs DLT series.