Hyperledger Burrow - legal Smart Contract integration of the future

DIRECT-LINK

ABOUT HYPERLEDGER

Hyperledger is an open source collaborative effort created to advance cross-industry blockchain technologies. It is a global collaboration including leaders in finance, banking, Internet of Things, supply chains, manufacturing, and Technology. The Linux Foundation hosts Hyperledger under the foundation.

Hyperledger Burrow is one of the Hyperledger projects hosted by The Linux Foundation. Hyperledger Burrow was originally contributed by Monax and co-sponsored by Intel. Hyperledger Burrow provides a modular blockchain client with a permissioned smart contract interpreter partially developed to the specification of the Ethereum Virtual Machine (EVM).

What is Burrow

Hyperledger Burrow is a permissioned blockchain node that executes smart contract code following the Ethereum specification. Burrow is built for a multi-chain universe with application specific optimization in mind. Burrow as a node is constructed out of three main components: the consensus engine, the permissioned Ethereum virtual machine and the rpc gateway. More specifically Burrow consists of the following:

• Consensus Engine: Transactions are ordered and finalised with the Byzantine fault-tolerant Tendermint protocol. The Tendermint protocol provides high transaction throughput over a set of known validators and prevents the blockchain from forking.
• Application Blockchain Interface (ABCI): The smart contract application interfaces with the consensus engine over the ABCI. The ABCI allows for the consensus engine to remain agnostic from the smart contract application.
• Smart Contract Application: Transactions are validated and applied to the application state in the order that the consensus engine has finalised them. The application state consists of all accounts, the validator set and the name registry. Accounts in Burrow have permissions and either contain smart contract code or correspond to a public-private key pair. A transaction that calls on the smart contract code in a given account will activate the execution of that account’s code in a permissioned virtual machine.
• Permissioned Ethereum Virtual Machine: This virtual machine is built to observe the Ethereum operation code specification and additionally asserts the correct permissions have been granted. Permissioning is enforced through secure native functions and underlies all smart contract code. An arbitrary but finite amount of gas is handed out for every execution to ensure a finite execution duration - “You don’t need money to play, when you have permission to play”.
• Application Binary Interface (ABI): Transactions need to be formulated in a binary format that can be processed by the blockchain node. Current tooling provides functionality to compile, deploy and link solidity smart contracts and formulate transactions to call smart contracts on the chain.
• API Gateway: Burrow exposes REST and JSON-RPC endpoints to interact with the blockchain network and the application state through broadcasting transactions, or querying the current state of the application. Websockets allow subscribing to events, which is particularly valuable as the consensus engine and smart contract application can give unambiguously finalised results to transactions within one blocktime of about one second.

Monax - create & control your legal contracts

Turn contracts into the backbone of your business relationships. Gain clarity, know where to focus and fulfill contracts collaboratively.

Create agreements

Select, fill out a form then press create. You’ve made both a legally binding agreement and an auto-enforceable smart contract with just a couple of clicks. As simple as filling out a form.

Track every obligation

Track every contract and obligation in one place. Each event is permanently recorded on a blockchain - no more admin stress.

Fulfill

Visualise, monitor and control the execution of the contract throughout its entire life-cycle. Obtain the transparency you need to focus on your business.

Cut your legal spend with legal products

Lawyer tested legal templates at your fingertips. Obtain legal knowledge at affordable prices in the same way you buy anything else online.

Upgrade and automate your own templates

Add workflows to your own contract templates and turn them into facilitators for your business.

Blockchains

What is a Blockchain and why are these automated data management systems so cool?

What is a Blockchain?

Blockchains have their origins in cryptocurrency platforms, in particular bitcoin, where they represent historical records of verifiable monetary stake. They were designed in the first place to solve the double spending problem, that is, to establish consensus in a decentralized network over who owns what and what has already been spent.

Blockchains are authenticated records of the history of a network’s activity distributed among the users of the blockchain all around the globe. A blockchain enables secure storage of arbitrary information – in some cases, a token balance; in other systems more complex information – within the network simply by securing a set of private keys.

Modern blockchain designs are capable of storing arbitrary data and establishing permissions to modify that data through self-administering and self-executing scripts which are performed by a distributed virtual machine.These scripts are known as smart contracts, and they allow platform operators to define complex and fully customisable rules which govern the blockchain’s interaction with its users.

Characteristics of Blockchains

A blockchain network is a software network comprised of a set of users running a blockchain node.

All of the blockchain nodes in a given blockchain network are connected together so that they are collectively building and also interacting with a single authoritative ledger.

As such when we discuss the characteristics of a “blockchain” we are really discussing three different things:

1. What are the characteristics of a Blockchain Network?
2. What are the characteristics of a Blockchain Client?
3. What is a blockchain ledger?

Throughout this explainer, we will attempt to be precise as to which of these we are speaking to.

Area is not very interesting frankly. Blockchain ledgers are simply a record of transactions which have been broken into blocks and linked together using cryptographic digital signatures. It is the blockchain network and blockchain nodes which are much more interesting.

There are three areas where both blockchain networks and blockchain nodes stand out from their brethern data and process management solutions available to organizations:

• Blockchain clients and networks validate everything (great for compliance and auditors; not so great for fraudsters)
• Blockchain clients are highly independent (and thereby fault tolerant)
• Blockchain clients and networks are automated

Lets look at some of these characteristics.

Validation Within a Blockchain Network and Blockchain Clients

*A blockchain network carries out its functions automatically, through a process which is historically called “mining” or “forging,” but which we at Monax simply call validating.*

This process generally involves bundling the transactions which have come into the system during an established time, along with other parameters into a block of transactions and other data which is then placed into the chain of blocks.

Blockchain clients allow nodes on the network to have cryptographic verifiability over the data and state changes entered into the network out of the box. This level of verifiability can be added to a non-blockchain based database back end. The difference being whether the cryptographic certainty is a first class citizen of the network or whether it is an addon is likely irrelevant for many applications.

With respect to this “difference” there is likely no huge benefit which blockchain networks can provide that a properly constructed hub and spoke database architecture cannot provide outside of a convenience and ease of use function.

While blockchain networks present their own operational challenges to organizations seeking to use them, one thing they are extraordinarily good at is abstracting away digital signing algorithms, state changes, and the cryptographic verification of those into a coherent client for users.

Most modern databases store the world state of the data and keep the logs of transactions with the database as a separate “thing”. Blockchain clients, on the other hand, build the world state of the data from the blocks of authenticated transactions that are “chained” together over time.

Thus it is always immediately possible to tell if something is valid, as it must have come from a valid history, and everyone agrees completely on the sequence of valid history.

Independence of Nodes Within a Blockchain Network

A blockchain network operates as a distributed data store, meaning there is no single master node within the network; rather, every node is an equal peer.

Every node in a blockchain network “assembles” its view of what the data is by ensuring that it has the full, and agreed set of transactions and applying those transactions as state transfer functions over the previous state of the data. In a hub and spoke architecture, the nodes within the network (usually) receive data updates from the hub rather than independently assembling what the world state of the data is via receiving the transactions and assembling the state locally.

This is roughly analogous to the difference between being told a fact in a class and performing a mathematical proof in class based on assumptions provided by a teacher. One only requires acceptance by the “receiver” while the other requires effort by the “assembler”.

The fundamental difference architecturally is, essentially, the “freedom” which the various nodes on the network have to tell clients which are hooked into them what the data is. This “freedom” is what blockchain-ers are (sometimes) referring to when they speak about the “decentralization” benefits of the blockchain node in question.

Automation Within a Blockchain Network and Blockchain Clients

A blockchain network validates data-driven transactions while also preventing the incorporation of unauthorised transactions.

Blockchains are (currently) non-shardable. This is a very important difference between blockchain and hub and spoke database architecture. There are theoretical options for addressing shardability, but it must be noted that currently these are theoretical in nature.

The practical effect of this non-shardability is that every full node on the network must individually perform the entirety of the computing effort required for the entire of the network. Redundantly, in order to check each other’s work.

While this may seem like overkill, it should be noted that it is significantly easier to run blockchain nodes in a “cloud-y” manner than it is hub and spoke databases. Hub and spoke databases scale vertically due to their design; on the other hand blockchain networks scale horizontally due to their design – which exactly how “cloud-y” applications are meant to scale.

If you need the data management solution to be easily spun up and distributed amongst nodes which are not fully integrated into infrastructure of the data management solution then a blockchain architecture is likely an appealing data management solution.

The fundamental difference architecturally is, essentially, that blockchain networks are going to be significantly more constrained in the amount of transaction processing they are able to perform because blockchain nodes are built to be independently redundant with respect to the data management functions; whereas hub and spoke databases can be built to operate using truly parallel computation.

Benefits of Blockchain Technology

What we have when abstracting a blockchain network to a certain level is a distributed, self-authenticating, time-stamped store of data. Indeed, the core design of a blockchain node is an elegant way in which to overcome many challenges in distributed systems.

Resilient Data Management System

Blockchain clients allow for the development of distributed systems which do not rely on what traditional databases call ‘master-slave’ clusters. This drastically increases the resiliency of blockchain networks as a data management solution.

In a blockchain network, there is not even a notion of master-slave relationships between the nodes in the cluster. Instead, blockchain networks utilize the idea of peer nodes and consensus models to resolve the current world state of the data.

This allows for a fluid membership to the “truth creating” consortium of computers which in turn increases fault tolerance and resiliency. Breaking the data-driven transactions into blocks allows the consensus of the database to be negotiated in a reasonable manner rather than on a per-transaction basis.

Increased Verifiability

In addition, blockchain networks allow for transactional certainty. Traditional databases store the current world state of the data, and if they are programmed to do so, have additional entries covering previous transactions within the data store. In addition, traditional databases are also able to maintain logs of the history of the interactions.

Blockchain networks are designed differently in that the logs of the transactions with the data set are used to formulate the world state of the data. The use of cryptographic authentication of time-stamped blocks of transactions allows the entire network the benefit of certainty of the entire transactional history.

The general blockchain design not only requires that the transactional history of the data store is captured, but that it is cryptographically certain once there is sufficient consensus within the network.

In other words, in a blockchain network if we know the state of the data at the genesis of the blockchain and we accept the state of the date at time.Now() we can be assured that there is one and only one way in which to get from the original state to the current state.

Types of Blockchain Clients

Blockchain clients generally fall into one of four quadrants. These quadrants vary based on two axes:

1. Is the blockchain network permissible?
2. Is the blockchain node optimized to do X?

The Optimization Spectrum

On the lower half of the quadrant are blockchain nodes which give application developers a clear and efficient way to verifiably track title transfers in a distributed environment.

Whether these blockchain nodes are permissioned or unpermissioned, they are a good fit for application developers seeking to build transfer mechanisms, clearing and settlement, and provenance applications.

In other words, they’re really interesting property auditors. These blockchain nodes – to some extent or another depending on the client in question – do provide some limited logic capabilities (bitcoin’s reference client, famously, has its multi-signature capacity which operates in a similar area to logic). However, they have been optimized to track movement of title over “property” from one node on the network to another.

On the upper half of the quadrant are blockchain nodes which give application developers a clear and efficient way to verifiably track business and governance process logic in a distributed environment.

Whether these blockchain nodes are permissioned or unpermissioned, they are a good fit for application developers seeking to build complicated business process automation applications.

In other words, they’re really interesting process auditors. Similarly to transaction optimized blockchain nodes, they have capabilities of supporting verifiable title transfers, but they have really been optimized to run arbitrary business logic.

The Permissioned Spectrum

On the left half of the quandrant are unpermissioned blockchain networks. These networks are formulated by a set of blockchain nodes which have been programmed with the unpermissioned blockchain network’s rule book.

These blockchain networks lack an access control layer and as such handle anti-spam and consensus via purely economic mechanisms.

We may not like to have to pay a bank a fee to update our address in their database, but if our bank operates using an unpermissioned blockchain network that’s basically what we’d have to do in order to overcome the necessary anti-spam protections (and other protections) which have been put in place to protect these networks.

These blockchain networks are the best solution for censorship resistance. If someone needs data to exist forever in a rock solid vault of math, then unpermissioned blockchain networks are the place for that data.

Unpermissioned blockchain networks also have public governance mechanisms, and have been designed to provide the data management backbone for a variety of applications. That means that they were probably not well suited for any one type of application. Depending on what application one is seeking to build this may be a benefit or a detriment.

On the right half of the quandrant are permissioned blockchain networks. These networks are formulated by a set of blockchain nodes which have been programmed with the permissioned blockchain network’s rule book.

Properly permissionable blockchain networks are usually based on the capabilities of nodes on the network which can be made fully public, or use whitelisting to control.

Permissionable blockchain networks are not susceptible to external attack by unknown actors because the blockchain nodes participating in the network will reject blocks from not-whitelisted nodes (if the blockchain node is running in “permissioned” mode for a particular blockchain network in question).

These networks also have performance advantages over public blockchain networks because they are only dealing with the functionality required for that network rather than all the functionality for a larger, unpermissioned network load.

Dual Integration

Putting the Contracts in Smart Contracts

Putting the Contracts in Smart Contracts

Smart contracts are useful for automating many data-driven relationships. However, to be enforceable, smart contracts must work in existing legal frameworks where those frameworks already exist, removing a degree of uncertainty in enforcement. In order to bridge the gap between existing electronic contracts law and blockchain smart contracts, Monax offers dual integration. For more on smart contracts, see our explainer.

Dual integration is the process of integrating a specific legal contract into a specific smart contract running on a distributed data store, such as Monax. This allows parties to use established dispute resolution processes in the jurisdiction(s) of choice while also using a smart contract as the primary mechanism for administering the data-driven interaction that attends to the agreement between the parties.

Dual integration enables legal enforceability of smart contracts

The rationale behind dual integration is that for the forseeable future, legal systems are unlikely to resolve disputes stemming from smart contracts solely on the basis of their code. Courts will apply the defaults for similar prose agreements, an end that may not reflect the intention of the smart contracting parties. Because of the risks involved in enforcing smart contracts by code alone, we highly encourage all smart contract systems developers to utilize dual integration of some kind. Dual integration means that a smart contract will be linked to a document that can be enforced by a court.

Basic dual integration:

Deploy a smart contract that is capable of storing a checksum

1. Reference the chainId and contractAddress of the deployed smart contract in the final draft of the real world contract.
2. Execute the prose contract and produce its checksum (AKA “hash” or “digital fingerprint”)
3. Send a transaction storing the checksum of the prose contract into the smart contract.

That’s it. If those steps are followed then there will be a cryptographically-certain dual integration.

Once the dual integration process is finished the result will be a smart contract which references a specific fingerprint of a real world contract (this is called the hash of a file, or sometimes it is called the checksum of a file) and a real world contract which integrates the specific fingerprint of a smart contract (this utilizes the chainID of the distributed data store which the smart contract runs on as well as the contact Address of the specific smart contract). This circular reference ensures – to a cryptographic certainty – that the specific file which contains the real world contract and the specific smart contract both properly reference one another. Certainty – that the specific file which contains the real world contract and the specific smart contract both properly reference one another.

Ecosystem Applications

What are Ecosystem Applications and will these impact how we think of building software?

Applications that run on an ecosystem (or, network) level

Introduction

As our organizations move into the information age the low hanging fruit for process automation is to move the applications providing that automation away from being single participant operated and toward being operated by a network, or ecosystem of participants. Ecosystem applications seek to automate processes at the value chain level thereby providing a framework on which to build complicated and connected networks that seek to reduce costs and open new opportunities for value creation.

The Information Age Transformation

As we continue the march from the industrial age to the information age the tectonic plates of globally-focused businesses, digital nomads, and information abundance have combined to massively transform a range of industries already and are hardly finished. One of the most important changes is in how organizations manage data and processes.

These changes originally powered the first generation of collective process management tooling which was focused on providing the base business process automation for a given enterprise. This generation of tooling, led by companies like SAP, Oracle, and others, effectively leveraged economies of scale over data and data processing power which on-premise data centers could provide. This generation of software emphasized the enterprise as the center of the universe.

These same changes later powered the second generation of collective process management tooling which is focused on extending the benefits of software defined process automation into smaller businesses. This generation of tooling, led by companies like SalesForce, Xero, Github, and others, effectively leveraged economies of scale over data and data processing power which IaaS systems could provide (until they eventually needed their own data center). This generation of software emphasized the “App” (or, latterly, the “Platform”) as the center of part of the universe.

In our view we are entering into the third generation of collective process management tooling which will focus on extending the benefits of software defined relationships for businesses of many different sizes. This generation of tooling, which will be led by the companies we currently label “blockchain” and “smart contract” companies, will leverage the economies of redundancy over data and data processing power which networks of peers can provide. This generation of software will emphasize the “Ecosystem” as the center of part of the universe.

The Big Problems Previous Technologies Haven’t Effectively Solved

In order to move forward with the next generation of collective process management tooling, we need to understand what are the big challenges which businesses face.

One of the biggest changes is in the likely reduction in competitive economies of scale for producers of goods. Increasing equalization of labor and resources costs in a truly globalized economy are very likely to create a context where one of the great cost differentiators for the production and distribution of physical products is transportation. This is, in turn, likely to require many supply chains to move toward more connected producers hooked into a range of distribution networks from local to global in scope.

As 3D printing, makers shops, and manufacturing automation continues to equalize the ability of more connected producers to competitively build physical products and as technology such as automated air and ground transportation along with increased shipping efficiency continues to equalize the ability of more connected producers to competitively distribute physical products, it is highly likely that more connected producers will gain in relative power to larger producers for many types of goods in the future.

These vectors align in the direction that connected is hot and isolated is not. The problem is that connected has been hard to scale. By way of a simple example, a small business in some portion of the world can always list their products on the internet. By doing so they have an ability to find customers, prepare shippings, and deliver to a global customer base. This is elegant. Yet it is not totally realistic for the vast majority of small businesses.

Thus the theory behind EBay, Amazon, and Etsy’s successes – they act as the front office of a global customer base and the small business just needs to act as the back office (and also make good products). But Amazon, et al., do more than act as the front office. They also run “the platform” on which these small businesses can sell their goods. These “platforms” will list products, process transactions, provide customer servicing add-ons, or whatever suits the business of the platform.

So if we are truly in a globalized world where connected matters more than isolated, how do the connected effectively scale without having to rely on “the platform”? What if they want to run “the platform” themselves by banding together? As an ecosystem. How can they build applications that run on an ecosystem level, or, as we call them ecosystem applications?

Ecosystem Application Toolkit

The toolkit for ecosystem application builders includes many of the peer-to-peer technologies developed since the 1990’s and some that have been more recently developed.

Blockchains

The problem that  blockchain technology solves is not electronic P2P cash, nor is it settlement latency, it is the problem of attribution and ordering of inbound events; at an ecosystem level.

When we send someone a bitcoin, what are we “really” doing? Well, we’re signing a message which says that “I, keyholder of key X, am transferring title over this ‘object’ (in the example’s case, a bitcoin) to the keyholder of key Y.” Our signed message then is broadcast across the network. The network in turn analyzes this message to determine if the message has been properly signed, if the “sender” does indeed have title over ‘object’, and if it has the network transfers title over the “object” in question to the keyholder of key Y.

Of course, in bitcoin’s case, there is a censorship-resistant, permissionless network behind all of it, but that is not the interesting bit. The interesting bit is that the network, without relying on passwords or logins, is able to effectively attribute actions. Blockchains are forced to do this because passwords and logins cannot safely be “held” at a network level. In traditional software architecture, they can be safely “held” by an application that is designed to run under the control of a single entity. Yet, if we take away the assumption that there will be a single arbiter of the password then we need to utilize a different system for attribution.

This technology, in combination with the ordering and timestamping functionalities that validators provide, solves the first problem ecosystem applications have: the problem of who did what when.

When blockchains are analyzed under this paradigm, their BFT consensus algorithms (implemented in a variety of ways) and their PKI provide a nice abstraction for application makers to begin building applications that run on an ecosystem level and need to know, well, who did what when in a reliable, resilient manner.

What’s the key difference in how blockchains and more simple fault-tolerant databases (such as rethink, riak or etcd) which are also able to solve the problem of who did what when? The difference is an assumption about the network configuration. These fault-tolerant database technologies assume that the network is controlled by a single entity. Raft, the consensus engine used by these databases, is what’s known as fault tolerant - or FT - rather than byzantine fault tolerant - or BFT. The difference between FT and BFT is important. The primary difference is a diffusion of power over who is the final arbiter of who did what when.

BFT databases do not assume that there is a single entity controlling who did what when. While it is true that modern, fast, blockchain technology is much closer to rethink, riak, or etcd in how they approach a number of underlying technical problems than they are to bitcoind, even the newer, faster chains do not relax the assumption that the data is going to be held across entities rather than within entities.

This is exactly why they are one important tool for opening up a range of new applications – applications that run cohesively at an ecosystem level.

Learn more about blockchain technology.

The attribution problem that blockchains solve is insufficient, alone, to actually be able to build coherent applications that run on an ecosystem level beyond very simple applications; such as moving electronic cash from one person to another.

Smart Contracts

The next problem that needs to be solved is deterministic computation. This is the problem that the “thing” the community currently calls smart contracts solves. The problem that smart contract technology solves is not escrowing funds, it is the problem of is computation happening in an agreed manner.

What do we mean by deterministic computation? We mean that all participants in the ecosystem need to be able to compute something and achieve the same result.

This sounds rather easy at first blush, doesn’t it? Isn’t that what computers are supposed to do? It is indeed, for the most part, what computers do. However, computers are designed to perform computation, not deterministic computation. Let’s look at the two major sources of non-determinism in an effort to understand why we need to control them in order to avail ourselves of a method to build ecosystem applications.

The first major source of non-determinism is randomness. Every programming language has a way to “make” a random number so that one can perform operations on it. Programmers use these random numbers to accomplish a variety of programming tasks. And yet, if one were to allow randomness within a strongly deterministic system of computation, all the members of the ecosystem who were running the application would “make” a different random number as the basis for the computation task. This means they would then have a different outcome for the entire computational sequence which depended on the random number. When one is trying to ensure that computation achieves exactly the same result across the ecosystem that is a bug, not a feature.

The second major source of non-determinism is time. Every programming language also has a sense of time. This allows programmers to do stuff like get timeNow() and add a few days to create a filter of upcoming events. This is all well and good, but it is unlikely that the members of the ecosystem will have their computer clocks so finely tuned that they are exactly the same – down to the millisecond. One of the features that we design for when thinking about ecosystem applications, is that they can and should be verifiable by later in time participants. For example, if the ecosystem is in a highly regulated industry, then auditors for the various participants in the ecosystem may need to perform an audit on the year’s activities. The timeNow() at the end of the year will very much not equal the timeNow() when the computation was originally performed. This will result in auditors getting a different result.

If we can take these sources of non-determinism out of the computation layer, then we can build systems where multiple actors in an ecosystem can, in real time or later in time, verify and notarize that a computation has happened in an agreed manner. But in order to “verify and notarize” a computational sequence, we must have deterministic computation.

The other problem that smart contract technology solves, is a distribution problem. In order for ecosystem participants to perform the computation, they need to have the computational sequence. In “normal” computing we solve this by either: (a) installing applications on a given device; or (b) all connecting to the same cluster of devices where an application has been installed and is running.

But with ecosystem applications, we typically solve this in a different way. We often, but not always, put the application’s logic “on” the blockchain. We use the high evidentiary characteristics blockchain tech gives us, (or, as we say, who did what when) along with a smart contracts interpreter (often called, a VM (for virtual machine)) to not have to worry about downloading and installing these computational sequences. We simply connect in to the ecosystem’s network and go!

Learn more about smart contract technology.

While blockchains (providing us who did what when) and smart contracts (providing us deterministic computation) are two tools that give ecosystem application builders two main capabilities necessary for building ecosystem applications, we still have a few more base requirements to really enable this technology to flourish. Namely we need to solve content and privacy.

Data Lakes

In applications that are built on traditional architecture we can have content which resides on a single device or a cluster of devices that is under the control of a single entity. If that entity decides, for whatever reason, to stop servicing an application or stop serving particular content, it can so decide unilaterally. However, when we are building applications meant to exist outside the control of a single participant within the ecosystem, we cannot make such an assumption. This is where the IPFS project’s thoughts about the permanent web are so crucial.

How we will deliver and store content within our ecosystem application is only one portion of the content problem. The other is how we “relate” to it. In other words, how do we know that “this is ‘it’” whatever “it” may be. In computational terms this is solved by content addressable storage and it is the one of the key components for how to think about designing ecosystem applications. No matter how we deliver and store content, we need to be addressing the content with precision.

Content addressable storage gives us, in general, assurances that “this is ‘it’”. In traditional architecture when we are retrieving files from a remote server (to download an app, or to load a web page), there is always a risk that either the remote server was hacked in some way, or the file was “swapped” while it was on the wire between the remote server and your device. Depending on whether we trust the pipes and/or whether we trust the remote servers’ credentials (that it is, e.g., Apple, Inc. is the company behind apple.com) we may need to take further actions to ensure that what was downloaded is “it”. While proper use of SSL alone solves many of these problems it doesn’t solve them all.

Although SSL is a well worn system, if we want to be very careful that “this is ‘it’” what we do is after we download a file from the internet we take its hash (which can be thought of as the “fingerprint” of a file) and compare that hash to one that has been provided by the publisher. This allows us to (if we trust the publisher) ensure that what we downloaded is what the publisher produced. When dealing with content addressable storage, which is local to your device, you can have assurances that the file was not “swapped” and that the file is pointing at what the network would like one to point at, because in most content addressable systems we reference data by its hash.

Point-to-Point Messaging

The final, major, challenge is around privacy. There are two types of privacy which are necessary to examine. The first one is a me only type of privacy. This means that there need to be things which are known only to me. We typically define these as secrets. Secrets are things like one’s private keys, or logins, or other information which should be available only to you. Those things are necessary for ecosystem applications. Within the Bitcoin world, wallet software provides a very valid me only privacy function. There are a range of possible options for how to build generic ecosystem applications while also enabling me only privacy. However, mostly ecosystem applications only need to “interface” with the generics so these will not be covered in great detail here.

The second type of privacy is a come over here I want to tell you a secret type of privacy. Because within ecosystems, we don’t necessarily assume that all participants need/want/have_a_right to have all the information about all the things. This is where point-to-point messaging systems and an authenticated public key infrastructure (a PKI) with a given identity mechanism comes into play. Private message queues give us the come over here ... a secret part of the whole problem. An authenticated PKI solves the **I** want to tell **you** part of the whole problem. Point-to-point messaging gives us the final piece of what, at least theoretically, is a complete look at the major components necessary to build most ecosystem applications.

Legal Engineering

Legal engineering is the practice of writing smart contracts that automate legally-enforceable rights and obligations.

Monax Legal Engineering

Legal engineering is the combination of legal design and software engineering. Legal engineering enables, among other things, automation of rights and obligations in smart contracts.

Usually, legal rights and obligations are set out in “inert” paper documents which must be read and interpreted, and acted on, by people. This takes a lot of time and effort. In today’s increasingly data-driven world, it makes much more sense for contractual obligations to be represented in code and processed at least in part by computers - improving adherence, easing compliance, and automating performance.

The increasing need for automated data-driven solutions across multiple business verticals means an opportunity to create ecosystem applications: programs, platforms and solutions that enable businesses, governments, organizations and individuals to automate their network interactions via smart contract rules. Drafting the rules of commercial interactions is traditionally the job of a lawyer. In a data-driven ecosystem, it’s the job of legal engineers.

Blockchains are legal tech

The advent of distributed ledger technology and blockchains has enabled writing smart contracts that can execute the terms of a contract, make decisions, store information and interact with other smart contracts. For a more in-depth explanation of blockchains and smart contracts, please see our blockchains and smart contract explainers.

At Monax, “legal engineering” means writing smart contracts that leverage the capabilities of ecosystem application technology to automate complex legal transactions, resulting in greater efficiency and lower transaction costs. Use cases we have seen pursued include automating the gathering of evidence, management of money and property, automation of property registerss, and automation of audit for trade and supply chain finance. Indeed almost any financial standard can be modelled in smart contracts (SWIFT, for example, built several prototypes, including a bond and ISO 20022 messaging, with our software).

Some people call this “fintech.” We think these use cases actually show that smart contracts and the blockchains that run them are legal tech. Smart contracts allow breakthrough use cases like true delivery-versus-payment in securities settlement and sorely needed trade finance processing like reliable invoice tracking and letters of credit. To build these and other complex use cases requires engineers who understand the formal requirements of transactional law which governs these types of transactions. Hence, legal engineering.

Law and code, evolving together

Smart contract solutions with pre-existing legal contexts, like financial, insurance and commercial models, must comply fully with existing laws. This is not a principle all blockchain (particularly cryptocurrency) startups are necessarily committed to. For the legal engineers at Monax, however, using blockchains in a legally correct way is foundational.

Legal systems provide many tools for achieving people’s commercial intention with certainty, for example, contract law.

Today the law is evolving at global scale, in code. Interoperable systems, rather than dark data pools, are the commercial information models of the future. Legal systems do not evolve at the same pace as technology; to ensure that your encoded agreements will be recognized by courts today, we recommend Dual Integration. For more on Dual Integration, see our brief explainer.

Enabling humans to make decisions and commitments today

With careful prospective legal engineering, entities can create smart contract relationships in code that self-execute contractual intent while functioning within broader commercial realities.

Legal engineering smart contracts means configuring reliable future events in code, enabling humans to make decisions and commitments today. In order to serve industrial needs, smart contracts must be built by a team with deep understanding of coding systems and legal systems, as well as the vision to put it together. Monax legal engineers are experienced lawyers and developers with the technical know-how to bring smart contract use cases to life.

Permissioned Blockchains

What is a Permissioned Blockchain and why are these automated data management systems so cool?

The “DNA” of a permissioned blockchain network is no different than the “DNA” of an unpermissioned blockchain network. With the exception of one gene that has been mutated.

Properly permissioned blockchain networks differ from unpermissioned blockchain networks solely based on the presence (or absence) of an access control layer built into the blockchain nodes.

The first primary difference between a properly conceived permissioned blockchain network and an unpermissioned blockchain network is whether the participants in the network have an ability to restrict who can participate in the consensus mechanism of the blockchain’s network.

Permissioned blockchain networks allow the network to appoint a group of participants in the network who are given the express authority to provide the validation of blocks of transactions. Or, to participate in the consensus mechanism.

The second primary difference between a properly conceived permissioned blockchain network and an unpermissioned blockchain network is whether the participants in the network have an ability to restrict who can create smart contracts (if the blockchain node is logic optimized) and/or transact on the blockchain network.

Together, at Monax, we call these capabilities based permissions. We used these principles in laying the foundations for our most recent project, the Agreements Network.

The Benefits of Permissioned Blockchain Networks

To understand the benefits of permissioned blockchain networks to their participants, we must consider the relative advantages which they have vis a vis their unpermissioned cousins.

We must also consider the relative advantages which permissioned blockchain networks have vis a vis their cousins on the other side of the spectrum: hub and spoke distributed databases.

Permissioned Blockchain Networks are More Performant Than Unpermissioned Blockchain Networks

Blockchain networks in general are not very performant. But one can get betterperformance from a single blockchain network by limiting what that network is actually trying to manage. In any blockchain network, all the full nodes on the network perform all of the computation redundantly rather than in a segregated (traditional parallel computing) fashion.

So, when one is running a full node on a public blockchain network one is performing all of the computation for all of the applications running on the entire network. Should that single blockchain network explode in popularity, this will be a ton of computing power you would devote to managing the computational effort for not the application you are trying to use.

Now for many, that is exactly the point, that all the applications are being ran by all of the full nodes. And it definitely makes sense for some applications. Yet, it doesn’t make sense for every application. Particularly those applications which are enterprise in nature and need to have increased performance.

Permissioned blockchain networks do not abrogate the requirement that every full node on the network perform all of the computation for all of the network. Effectively these networks are breaking the computation requirements for a given meta-network into segments which only apply to that particular application.

A permissioned blockchain network will be more performant than an unpermissioned blockchain network for a given application because each node will only need to perform the computation necessary to support that given application, but it will also be significantly slower than scripting languages and hub and spoke databases.

Governance Over A Permissioned Blockchain Network is Clearly Defined

Unpermissioned blockchain networks are public spaces and as such have all the challenges of public goods governance when it comes to ensuring the networks evolution via updates to its rulebook or mechanisms of interaction. As a consequence, innovation is slow to be adopted by these networks; and their security and consensus models have challenges evolving.

Enterprises which are seeking to put in place business process automation in consortium’s need a network that is capable of moving in different directions and that can be optimized for different ideas than a public network would likely be optimized to achieve.

Permissioned blockchain networks allow for transparent governance within the consortium only. While this, at times, can be a challenge, it is certainly less of a challenge to ensure evolution of the network in question than where the network was unpermissioned and subject to public goods governance challenges.

In this sense, permissioned blockchain networks can be used iteratively to accomplish very specific business problems and optimized to achieve those solutions rather than having to be built for only the lowest common denominator.

The end result is that it is easier to marry the specific business challenges and governance over business processes to the data management solution used by the network.

Permissioned Blockchains’ Are More Cost Effective

Public blockchain networks are costly to deal with for a simple reason: spam control. Public blockchain networks of logic optimized blockchain nodes (e.g., the Ethereum network) has a pricing structure which is linked to computation operations.

So every time a contract needs to go into a loop, users of that contract must pay to run that loop. How much users are required to pay will be determined by how many times the contract must iterate through the loop. The more times through the loop, the more computational operations will be required, and the more money must be spent.

What happens on such a network if users do not send enough money to a contract when they interact with it? That transaction does not happen. Plain and simple. There is a valid reason for why these networks have such rules: if a contract has an infinite loop in it and they did not have a pay-per-computing-operation mechanism a single contract could seize up the entire network by throwing all of the full nodes into an infinite loop.

Controlling this attack vector on a permissioned blockchain network can happen in a very different manner than having to rely on market and pricing dynamics.

Security for Permissioned Blockchain Networks

There is a fallacy heard now and again that permissioned blockchain networks are significantly less secure than unpermissioned blockchain networks which have an economic incentive to “mine” and protect the integrity of data. When people say that permissioned blockchain networks don’t have the same level of security as unpermissioned blockchain networks sometimes they are equating blockchain networks _without_ permissioning systems to “permissioned” blockchain networks.

These are very different things indeed. A blockchain network which does not have an access control layer baked in as a first class citizen of its clients is a very different animal than a blockchain network which is able to expressly whitelists those that are able to participate in various network tasks such as validation, contract creation, and the like. An adversary which is able to get into the VPN (assuming this was the architecture for claiming the network was “permissioned”) and connect into the blockchain network could potentially attack the network using increased mining capacity.

For the rest of this explainer we’ll be talking about blockchain networks made up of blockchain node’s who have an access control layer baked in as a first class citizen.

Securing Unpermissioned Blockchain Networks

Unpermissioned blockchain networks such as bitcoin use distributed computing power to process and verify transactions broadcast upon them. The network, being aware of the history of all transactions, engages in a process of continual, automated database management and transaction verification through the voluntary provision of computing power, in a process which many blockchainers call “mining”, but we call “validating”.

Providers of this computing power – known as “miners” or “validators” – solve complex computational problems, which (in the case of mining) is done in exchange for the reward of cryptographic tokens (such as bitcoins) which the network hopes will become valuable over time due to their scarcity and/or their usability. This provides an incentive to continue securing the network, although there are certain risks – such as inter-miner collusion to incorporate false transactions into the blockchain – that the model also presents.

The security model of public blockchain networks is not the overall amount of computing power as many suspect. Rather the security model is based on the non-predictive distribution of power over block creation among nodes unlikely to collude .

In other words the security model for unpermissioned blockchain networks is the relative distribution of the pie slices rather than the overall size of the pie.

The overall size of the pie does provide a barrier to entry and also a barrier to quickly acquiring a sufficiency of the non-predictive distribution of power over block creation.

Securing Permissioned Blockchain Networks

The security model for permissioned blockchain networks is very similar, namely it is the non-predictive distribution of power over block creation among nodes unlikely to collude.

Only, in a permissioned blockchain network the barrier to entry, and/or barrier to control, are provided either out of band by a previous or emergent agreement; added to the genesis block of the blockchain network and/or updated over time as different evolutions of the network become necessary.

A possible attack vector at this point for overtaking a permissioned blockchain is thieving (or brute forcing) of 2/3rds of the private keys for the validator set. This attack vector is extremely unlikely it must be reinforced, however it is mathematically possible.

The Issue of Trust

Many of the advantages and disadvantages of blockchain architecture stem from the idea that nodes on the network are not necessarily trustworthy. Most blockchains are designed to withstand untrustworthy nodes within the network via their consensus mechanism. This design parameter, however, begets some limitations.

The idea which many blockchain advocates take from the consensus protocol is the idea of extended trustlessness to an ever wider range of the overall application, of which the blockchain is providing one piece. While the idea of increased certainty and verifiability is, indeed, appealing, the idea of moving to a fully trustless environment presents many challenges.

Examining Trustlessness

“Trustless” is largely a misnomer – and too much of it is not necessarily a good thing. Even the most ardent advocate of Bitcoin, the most prominent “trustless” network, will extend trust regularly to a certain extent, whether to the banks and payment processors which process their fiat currency transactions when they purchase Bitcoin, to the manufacturers of their computers and operating systems on which they run the Bitcoin client, and to the Bitcoin Core developers themselves.

Further, it is not necessarily always the case that trust is a pain point for consumers. When dealing with a bank, for example, consumers trust that deposits or funds held on account are safely kept; where these are not, other mechanisms such as insurance or deposit guarantees are available to secure them. When using web-based applications such as social networks and e-mail, consumers rely on the provider of those services to back up and secure their data.

Indeed, if trust vis-a-vis data and financial services providers were truly a vexing pain point for most consumers, there would be a rush of hosting providers for ownCloud and email-in-a-box solutions along with a drastic increase in transactional volume of non-fiat currency. While we see limited upticks in adoption some of those systems, there is by no means a rush.

Finally, “trustlessness” ignores the fact that in commerce, mistakes are made and a degree of human discretion is usually required to remedy these mistakes. Mechanisms that run completely automously and which cannot be broken also cannot be fixed. It is not as if trustworthiness is a new problem. Entire industries have been developed to handle the boundaries and rules of various points along the the trust-to-trustlessness spectrum – not the least of which is the legal system, which operates as a potent safeguard for consumers and commercial entities alike.

For the vast majority of commercial entities, legal norms provide a material constraining mechanism which bounds the actions which that entity can take. While there are indeed challenges which remain to broaden access to justice, and while we feel that things do need to improve, it does not follow that one should throw out hundreds of years of legal and commercial norms simply because we now have elliptic curve cryptography and cryptoeconomics.

From Trustless to Verifiable

While trustlessness is a tricky subject commercially for all the reasons discussed above, increasing the verifiability of data-driven interactions is a goal which all entities and organizations – whether commercial, corporate, not-for-profit, or individual – can benefit from. This is why, at Monax, we prefer to focus on increasing verifiability within distributed systems rather than engaging in largely philosophical debates about the quantum of trust.

When it comes to increasing verifiability for all parties to a given data-driven interaction, there are few technologies currently invented which match blockchains.

For more on verifiable business process automation between stakeholders please see our smart contracts explainer.

The Benefits of Permissioned Blockchain Networks

To understand the benefits of permissioned blockchain networks to their participants, we must consider the relative advantages which they have vis a vis their unpermissioned cousins.

We must also consider the relative advantages which permissioned blockchain networks have vis a vis their cousins on the other side of the spectrum: hub and spoke distributed databases.

Permissioned Blockchain Networks are More Performant Than Unpermissioned Blockchain Networks

Blockchain networks in general are not very performant. But one can get betterperformance from a single blockchain network by limiting what that network is actually trying to manage. In any blockchain network, all the full nodes on the network perform all of the computation redundantly rather than in a segregated (traditional parallel computing) fashion.

So, when one is running a full node on a public blockchain network one is performing all of the computation for all of the applications running on the entire network. Should that single blockchain network explode in popularity, this will be a ton of computing power you would devote to managing the computational effort for not the application you are trying to use.

Now for many, that is exactly the point, that all the applications are being ran by all of the full nodes. And it definitely makes sense for some applications. Yet, it doesn’t make sense for every application. Particularly those applications which are enterprise in nature and need to have increased performance.

Permissioned blockchain networks do not abrogate the requirement that every full node on the network perform all of the computation for all of the network. Effectively these networks are breaking the computation requirements for a given meta-network into segments which only apply to that particular application.

A permissioned blockchain network will be more performant than an unpermissioned blockchain network for a given application because each node will only need to perform the computation necessary to support that given application, but it will also be significantly slower than scripting languages and hub and spoke databases.

Governance Over A Permissioned Blockchain Network is Clearly Defined

Unpermissioned blockchain networks are public spaces and as such have all the challenges of public goods governance when it comes to ensuring the networks evolution via updates to its rulebook or mechanisms of interaction. As a consequence, innovation is slow to be adopted by these networks; and their security and consensus models have challenges evolving.

Enterprises which are seeking to put in place business process automation in consortium’s need a network that is capable of moving in different directions and that can be optimized for different ideas than a public network would likely be optimized to achieve.

Permissioned blockchain networks allow for transparent governance within the consortium only. While this, at times, can be a challenge, it is certainly less of a challenge to ensure evolution of the network in question than where the network was unpermissioned and subject to public goods governance challenges.

In this sense, permissioned blockchain networks can be used iteratively to accomplish very specific business problems and optimized to achieve those solutions rather than having to be built for only the lowest common denominator.

The end result is that it is easier to marry the specific business challenges and governance over business processes to the data management solution used by the network.

Permissioned Blockchains’ Are More Cost Effective

Public blockchain networks are costly to deal with for a simple reason: spam control. Public blockchain networks of logic optimized blockchain nodes (e.g., the Ethereum network) has a pricing structure which is linked to computation operations.

So every time a contract needs to go into a loop, users of that contract must pay to run that loop. How much users are required to pay will be determined by how many times the contract must iterate through the loop. The more times through the loop, the more computational operations will be required, and the more money must be spent.

What happens on such a network if users do not send enough money to a contract when they interact with it? That transaction does not happen. Plain and simple. There is a valid reason for why these networks have such rules: if a contract has an infinite loop in it and they did not have a pay-per-computing-operation mechanism a single contract could seize up the entire network by throwing all of the full nodes into an infinite loop.

Controlling this attack vector on a permissioned blockchain network can happen in a very different manner than having to rely on market and pricing dynamics.

Security for Permissioned Blockchain Networks

There is a fallacy heard now and again that permissioned blockchain networks are significantly less secure than unpermissioned blockchain networks which have an economic incentive to “mine” and protect the integrity of data. When people say that permissioned blockchain networks don’t have the same level of security as unpermissioned blockchain networks sometimes they are equating blockchain networks _without_ permissioning systems to “permissioned” blockchain networks.

These are very different things indeed. A blockchain network which does not have an access control layer baked in as a first class citizen of its clients is a very different animal than a blockchain network which is able to expressly whitelists those that are able to participate in various network tasks such as validation, contract creation, and the like. An adversary which is able to get into the VPN (assuming this was the architecture for claiming the network was “permissioned”) and connect into the blockchain network could potentially attack the network using increased mining capacity.

For the rest of this explainer we’ll be talking about blockchain networks made up of blockchain node’s who have an access control layer baked in as a first class citizen.

Securing Unpermissioned Blockchain Networks

Unpermissioned blockchain networks such as bitcoin use distributed computing power to process and verify transactions broadcast upon them. The network, being aware of the history of all transactions, engages in a process of continual, automated database management and transaction verification through the voluntary provision of computing power, in a process which many blockchainers call “mining”, but we call “validating”.

Providers of this computing power – known as “miners” or “validators” – solve complex computational problems, which (in the case of mining) is done in exchange for the reward of cryptographic tokens (such as bitcoins) which the network hopes will become valuable over time due to their scarcity and/or their usability. This provides an incentive to continue securing the network, although there are certain risks – such as inter-miner collusion to incorporate false transactions into the blockchain – that the model also presents.

The security model of public blockchain networks is not the overall amount of computing power as many suspect. Rather the security model is based on the non-predictive distribution of power over block creation among nodes unlikely to collude .

In other words the security model for unpermissioned blockchain networks is the relative distribution of the pie slices rather than the overall size of the pie.

The overall size of the pie does provide a barrier to entry and also a barrier to quickly acquiring a sufficiency of the non-predictive distribution of power over block creation.

Securing Permissioned Blockchain Networks

The security model for permissioned blockchain networks is very similar, namely it is the non-predictive distribution of power over block creation among nodes unlikely to collude.

Only, in a permissioned blockchain network the barrier to entry, and/or barrier to control, are provided either out of band by a previous or emergent agreement; added to the genesis block of the blockchain network and/or updated over time as different evolutions of the network become necessary.

A possible attack vector at this point for overtaking a permissioned blockchain is thieving (or brute forcing) of 2/3rds of the private keys for the validator set. This attack vector is extremely unlikely it must be reinforced, however it is mathematically possible.

The Issue of Trust

Many of the advantages and disadvantages of blockchain architecture stem from the idea that nodes on the network are not necessarily trustworthy. Most blockchains are designed to withstand untrustworthy nodes within the network via their consensus mechanism. This design parameter, however, begets some limitations.

The idea which many blockchain advocates take from the consensus protocol is the idea of extended trustlessness to an ever wider range of the overall application, of which the blockchain is providing one piece. While the idea of increased certainty and verifiability is, indeed, appealing, the idea of moving to a fully trustless environment presents many challenges.

Examining Trustlessness

“Trustless” is largely a misnomer – and too much of it is not necessarily a good thing. Even the most ardent advocate of Bitcoin, the most prominent “trustless” network, will extend trust regularly to a certain extent, whether to the banks and payment processors which process their fiat currency transactions when they purchase Bitcoin, to the manufacturers of their computers and operating systems on which they run the Bitcoin client, and to the Bitcoin Core developers themselves.

Further, it is not necessarily always the case that trust is a pain point for consumers. When dealing with a bank, for example, consumers trust that deposits or funds held on account are safely kept; where these are not, other mechanisms such as insurance or deposit guarantees are available to secure them. When using web-based applications such as social networks and e-mail, consumers rely on the provider of those services to back up and secure their data.

Indeed, if trust vis-a-vis data and financial services providers were truly a vexing pain point for most consumers, there would be a rush of hosting providers for ownCloud and email-in-a-box solutions along with a drastic increase in transactional volume of non-fiat currency. While we see limited upticks in adoption some of those systems, there is by no means a rush.

Finally, “trustlessness” ignores the fact that in commerce, mistakes are made and a degree of human discretion is usually required to remedy these mistakes. Mechanisms that run completely automously and which cannot be broken also cannot be fixed. It is not as if trustworthiness is a new problem. Entire industries have been developed to handle the boundaries and rules of various points along the the trust-to-trustlessness spectrum – not the least of which is the legal system, which operates as a potent safeguard for consumers and commercial entities alike.

For the vast majority of commercial entities, legal norms provide a material constraining mechanism which bounds the actions which that entity can take. While there are indeed challenges which remain to broaden access to justice, and while we feel that things do need to improve, it does not follow that one should throw out hundreds of years of legal and commercial norms simply because we now have elliptic curve cryptography and cryptoeconomics.

From Trustless to Verifiable

While trustlessness is a tricky subject commercially for all the reasons discussed above, increasing the verifiability of data-driven interactions is a goal which all entities and organizations – whether commercial, corporate, not-for-profit, or individual – can benefit from. This is why, at Monax, we prefer to focus on increasing verifiability within distributed systems rather than engaging in largely philosophical debates about the quantum of trust.

When it comes to increasing verifiability for all parties to a given data-driven interaction, there are few technologies currently invented which match blockchains.

For more on verifiable business process automation between stakeholders please see our smart contracts explainer.

Smart Contracts v. Tokenized Approaches

When are smart contracts better than tokenized approaches to blockchaining?

Smart Contracts Give Us Verifiable Process

Smart contracts, which are really scripts that have been saved onto a blockchain and operate in a distributed manner via all of the participants in the network, are a game changer for commercial and governance processes. Smart contracts give organizations the ability to put in place process which can be executed sequentially, safely, on any machine, and remain completely verifiable – down to the individual computation process.

This is increasingly important as the information age and other various forces distribute work geographically but also increase enterprise’s compliance requirements to ensure that certain processes comply with certain metrics.

The Issue of Tokens

Current blockchain design largely focuses on providing its utility in the enterprise context via “tokenization”.

The Advantages of Tokens

Tokens on a blockchain are interesting indeed. These tokens can be used to formulate a system where the tokens represent value or represent other assets.

Either way, what is happening generally with the token based systems is that they are tracking title over something. Indeed, the “something” varies, but the general idea is that these systems are simply tracking pieces of property and the transactions in their blockchains represent verifiable title transfer from one participant in the system to another.

The Disadvantages of Tokens

There are a few challenges to crafting blockchain backed systems which overly rely upon tokenization. The primary challenge is that title transfer over “something” is rarely the interesting, or, indeed, the important parts of a particular deal in most cases. Generally, processes of checks and balances are necessary to be satisfied prior to title transfer in almost any modern commercial context one could imagine.

While these checks and balances may be able to be automated (or at least tracked) in a smart contract based network, there is no general mechanism for handling these checks and balances in many blockchain designs (permissioned or public) which generally fall under the “transaction optimized” category.

For these reasons, at Monax we feel that smart contracts represent a massive leap forward while tokenized blockchain systems alone are moderately interesting.

The Flexibility of Smart Contracts

When one deals with a tokenized approach generally one is taking business logic and putting into a set of blockchain nodes all connected to the same blockchain network. Distributing changes to the business logic required that the entire network accept those changes and update their blockchain nodes.

In a logic optimized blockchain node and its relevant network one simply needs to deploy smart contracts via one connected blockchain node to update the business logic of the application.

This is a massive boon for flexibility; particularly while prototyping quick solutions.

The Modularity of Smart Contracts

Smart contracts are also modular. This gives them inherent advantages over tokenized approaches as they can be more easily mixed and matched in a coherent fashion.

Agreements Network

What is the Agreements Network? The Agreements Network is the legal layer for the networked world.

Automation is coming to law, meaning a sea-change for an industry accustomed to solving bespoke, individual problems rather than reproducible, systemic problems. Software products that enable scalable, compliant, automated and verifiable legal processes are necessary infrastructure for high-volume, valuable interactions and relationships. The Agreements Network is a foundation for open legal processes that will drive exponential growth in global networks. Blockchain and smart contracts present a unique market-making opportunity to turn legal processes into products. The Agreements Network meets a ubiquitous, yet previously unaddressed, market for legal product at scale, whether through support of new commercial use cases, automation of traditional legal services, or designing innovative access to justice tools. For users who want to grow their value propositions, this is great news! Legal issues have long been a hurdle for business and individual growth, creating expensive blocks to profitable operations. Huge segments of the population are unserved by the gap between law, businesses and individuals. It doesn’t have to be this way. Businesses will be profitably served by legal products that make contracting, compliance, and operations easier, at global scale. Legal products must be carefully designed for product-market fit. Lawyers are the best people to build needed legal products but they need help bridging their technical skills gaps. The Agreements Network provides this bridge with a no-code blockchain and smart contracts solution for producing, consuming, and earning revenue with legal products. The Agreements Network removes legal roadblocks that hamper business growth and replaces them with decentralized infrastructure—creating a smooth path for launching innovative tech products with a legal component. The Agreements Network provides an easy technological solution for lawyers to seize this opportunity by creating products with the assets they already have: legal know-how. Early adopters of the Agreements Network, including lawyers, companies and individuals, will gain a tremendous competitive advantage as smart contracts begin to disrupt traditional legal practice.