1 Introduction
In 2008, Satoshi Nakamoto (Reference Nakamoto2008) proposed a method that would allow untrusted parties to transact value without the intervention of a third party. The technology underlying blockchain implementations had been known for more than 30 years, but it took the eclectic thinking of Nakamoto to create a new kind of data repository that solved a very important missing link in e-commerce (Haber and Stornetta, 1990). All financial transactions relied upon the intervention of a trusted third party.Footnote 1 Prior to the Nakamoto paper, the internet was principally a global information publishing environment.Footnote 2
The missing link was whether it was possible to transfer value in non-face-to-face transactions over the telecommunications infrastructure without the need of a trusted third party. Nakamoto’s solution meant the parties did not even need to know the identity of the other party to the transaction.Footnote 3 All that is required is some benefit without the need to authenticate either party to the transaction (Catalini and Gans, Reference Catalini and Gans2019). Although Nakamoto’s solution for bitcoin is elegant, there are issues that have caused many organizations to investigate the ways of improving the commercial usefulness of the blockchain concept (Flood and Robb, Reference Flood and Robb2017).
Even though the Nakamoto paper was initially published on a narrow group list server dedicated to cryptography, what set the paper apart from other technical papers was that Nakamoto and his or her collaborators eventually implemented the bitcoin concept, with the software first released on Sourceforge in January 2009. The concept was slow to develop, but by 2012, a group of New York bankers became aware of the paper and immediately identified that instead of a so-called coin being transacted a simple value concept could be substituted.Footnote 4 Both law and economics have each for more than 100 years understood that all property from a conceptual perspective comprises a bundle of rights (Coase, Reference Coase1960). Hence, there has been increasing interest in the possibilities of blockchain deployments globally across many industries.
Nakamoto did not actually use the term ‘blockchain’ in the paper but instead employed the phrase ‘chain of blocks’. It is important in discussing ‘blockchain’ that there is a common understanding as to its meaning. For the purposes of this paper, the National Institute of Standards and Technology (NIST) definition is adopted (Yaga et al., Reference Yaga, Mell, Roby and Scarfone2018: ii):
Blockchains are immutable digital ledger systems implemented in a distributed fashion (i.e. without a central repository) and usually without a central authority. At their most basic level, they enable a community of users to record transactions in a ledger that is public to that community, such that no transaction can be changed once published.
Since blockchains are developed through community protocols without central authority, we can say there is an ‘anarchic’ state of affairs—because of its Hydra like growth—with respect to blockchains raising questions about standards around interoperability. This is important as even the Governor of the Bank of England has said blockchain is the start of the fourth information revolution that will eventually impact every economy globally (Herian, Reference Herian2018).
This paper interrogates three key issues that are the most pressing from a practical perspective as opposed to technical. They are as follows:
1. Blockchain governance through standardization to assist in advancing the uptake of blockchain usage and security of keys.
2. Smart contracts need defined or uniform characteristics to assist commerce by improving the efficiency and efficacy of commercial transactions.
3. Interoperability between blockchains is a persistent issue from a commercial perspective. There are many blockchain deployments that support smart contract execution such as Cardano, Ethereum, and EOS. How interoperability is settled remains an open question, and the development of standards will assist this process.
We take two lessons from Risius and Spohrer (Reference Risius and Spohrer2017: 404–405), which are that their ‘analysis revealed that there are only scarce examples of empirical and theory-driven research’. And, furthermore,
analyzing contributions of the distinct disciplines revealed that there is little multidisciplinary research to reflect the ramifications of blockchain systems that extend far beyond technological issues into economy and society. We are convinced that collaborations across disciplinary borders are fruitful and actually necessary for meaningful research on blockchain systems.
In this article, we take an interdisciplinary approach and we also recognize the necessity for more empirical research. In the next section, we start by examining the sociological and economic aspects of standards and how they can substantially advance the diffusion of new technologies.
2 The development and implementation of standards in blockchain
Timmermans and Epstein (Reference Timmermans and Epstein2010: 71) define standardization as
a process of constructing uniformities across time and space, through the generation of agreed-upon rules. The standards thereby created tend to span more than one community of practice or activity site; they make things work together over distance or heterogeneous metrics; and they are usually backed up by external bodies of some sort, such as professional organizations, manufacturers’ associations, or the state.
Standards are voluntary statements that set out specifications, procedures, and guidelines that aim to ensure products, services, and systems are safe, consistent, and reliable.Footnote 5 They often substitute for state action when states are reluctant to be involved, but they are now an essential and fully incorporated part of the global economy. Marx (Reference Marx1867) noted the relentless growth of world markets and their need to push away from distinctiveness towards homogeneity.Footnote 6 Institutional theory shows us that the very diffusion of standards across organizations leads towards eventual compliance with legal standards (Edelman, Reference Edelman1992). Governments and courts can and do become involved in both the creation and enforcement of standards. Yet, it is important to note that the creation of standards is a social act and therefore is always contested because of competing interests. The crucial aspect is gaining consensus among the stakeholders in order for standards to emerge. But standards setting is not a one-time event as Lampland and Star (Reference Lampland and Star2009) have shown, ‘tinkering, repairing, subverting, or circumventing prescriptions of the standard are necessary to make standards work’. Standards setting therefore is a continuing process, which is especially so with blockchain.
A important issue at hand with blockchain diffusion is that the technology is still developing and is currently fluid. For example, the consensus protocols for Bitcoin and Ethereum involve proof of work. This protocol takes advantage of the random characteristic of cryptographic hashes.Footnote 7 That is, knowing a document’s structure, one cannot, by looking at the document, predetermine what hash will result. Likewise, in looking at a hash, it is impossible to determine which document produced the hash. Furthermore, every hash should be equivalent to the ‘DNA’ of the document in that every meaningful document must create its own unique hash and thus collisions should be mathematically improbable. Finally, every document no matter its length or structure will result in a fixed length set of bits known as a hash. For example, the SHA256 algorithm will result in a hash length of 256 bits no matter what the length of the original input document may have been. That is, if the Bible and the Complete Works of Shakespeare were each operated on by the SHA256 algorithm, the result would be two distinct hash results other than each hash would be represented as a fixed length string of 256 bits.
The problem with the proof of work structure is that it is a brute force mechanism which is time consuming and thus energy inefficient (Vries, Reference de Vries2018). To solve this issue, there have recently been proposed several alternative consensus protocols involving proof of stake (PoS).Footnote 8 The principal benefit of a PoS solution is that it is energy efficient with an increased rate of transaction capability. For example, in the Ouroboros PoS protocol, which is being implemented in the Cardano blockchain, the network members elect a subset of members known as ‘Slot Leaders’ to mine the next block. It is important that some form of entropy for the selection of slot leaders is achieved by having a randomization factor included in the selection process. A further benefit is that if PoS is properly implemented, it should overcome any possibility for the evolution of a dominant party or the collusion of several players,Footnote 9 whose combination would control greater than 50% of the block determination capability.Footnote 10
There are other consensus protocols and, with certainty, more will be developed. For example, Hyperledger Sawtooth, based on the use of Intel SGX as a trusted execution environment, which Proof of Elapsed Time (PoET) consensus protocol uses.Footnote 11 The advantage of PoET is that most of the calculations occur within the security of a trusted hardware chip, which is an improvement over present solutions such as proof of work.Footnote 12
Despite the uncertainty of settled consensus protocols, which is a fundamental component of most blockchain deployments, standards can still play a role in assisting in specifying a selection mechanism for each of the proposed consensus protocols. However, standards development can be slow and time consuming and blockchain development waits for nothing. New developments arise weekly, and it is not uncommon for standards to take years to be approved.
2.1 Governance, standards, and the tragedy of the anti-commons
As we have seen in the first decade of blockchain development, failures of governance in blockchain and associated cryptocurrency areas can hamper the advancement of distributed ledger technology. The Segwit issue within the Bitcoin environment is a prime example (Pepijn, Reference Pepijn2017). Heller (Reference Heller1998) illustrated, in the ‘Tragedy of the Anti-Commons’, that if an asset is subject to multiple interests through which any party having an interest can veto or impede an advancement of the technology, then this will adversely impact the future development of the technology. Therefore, given blockchain is a distributed ledger technology, it is highly probable that contests over its bearing are inevitable, if not ineluctable.
It is possible for majority arrangements to be implemented, but even this can create concerns for anyone who does not agree with the decision. The forking of Bitcoin and Bitcoin Cash is a clear example of consensus failing to emerge, along with the forking of Ether and Ether classic (Zhang, Reference Zhang2018). If organizations or individuals cannot agree to a fork, then new blockchain structures emerge which compete with the originals.
2.2 Data governance
A distributed data repository itself causes compliance issues for organizations. They need to exercise care within the architecture of a blockchain environment to ensure that confidentiality and privacy are not compromized (Risius and Spohrer, Reference Risius and Spohrer2017: 399). Distributed frameworks across multiple parties give rise to problems in data governance. And these are of special concern since the activation of the European Union’s General Data Protection Rules (GDPR), which came into force in May 2018.Footnote 13
One method of compliance with the GDPR is to ensure that the blockchain itself does not actually hold any personal identifiable information (PII). This can be achieved by having all PII stored off-chain in a separate data repository and for an application to be stored on the blockchain that can interrogate the off-chain repository for business purposes. This problem is further compounded when multiple organizations form a consortium to use private blockchain networks. Each member would have to agree to a common standard of data management and governance.Footnote 14 In dealing with these top-level issues, the impact on exiting members would give rise to various compliance requirements depending on the information stored within the consortium blockchain itself. Thus, blockchain architecture needs careful design so that sensitive corporate information is stored off-chain but remains accessible through the blockchain environment.
Exiting members are further restricted owing to the blockchain data structure which will prevent any single member from removing their reference data from the network. Nor would it be possible for the continuing member parties to request the exiting party to remove the continuing member parties’ data from the exiting party’s instance of the blockchain at the date of exit. Some form of exit agreement would be necessary to coordinate exits from the network and its dissolutions. With peer to peer networks, the exiting party’s instance of the blockchain will necessitate exclusion from further appending of data after the exit. Further complicating factors include what happens to smart contracts already deployed and destined to continue to transact (Szabo, Reference Szabo1996). How would individual instances of smart contracts be terminated, if possible, without damaging the blockchain?
2.3 Key security
The blockchain environment has been described as a ‘trustless’ mechanism. The basis for this position is that neither party needs to necessarily know the other transacting party. Therefore, they do not need to trust the other party in order to effect the financial aspects of the transaction. This has a strong theoretical attraction, but each party must have confidence in the technology that is used in the transaction. McCullagh has argued that in electronic transactions, before parties can have confidence in any technology, they must possess an initial trust in the technology (McCullagh, Reference McCullagh1998). Thus, trust is crucial in the successful deployments of new technologies.
In common with other forms of technology, security is essential. Blockchain’s use of public and private keys has the potential to intensify the problems associated with password protection that already beset many individuals and organizations. While public keys enable the pursuit of transactions, private keys are meant to be personal and wholly private. With the advancement and development of blockchain technology, a fundamental aspect of the technology is the protection of the private key that is used to carry out transactions on the blockchain. Most implementations of blockchain whether bitcoin or other financially based deployments do not adequately protect the private key which is essential for all transactions.
The problem of key security in blockchain is analogous to password security in online banking. The use of password managers and two-factor authentication provide extra levels of protection, but ultimately, it is the user’s responsibility to ensure proper security. The crucial distinction between online banking and blockchain use is that banking deposits are brought under regulatory insurance mandates, whereas, for example, Bitcoin deposits are not insured. As long as keys, however encrypted, are stored on machines connected to the internet, they are vulnerable to hacking attempts.Footnote 15 At present, the most secure method of storing and isolating the private key from attacks is to use offline hardware security modules or hardware wallets, but they also possess their own security issues. There have been published incidents where hackers have cracked the security of a hardware wallet and surreptitiously copied the private key. To create confidence in the generation and storage of the key pair for blockchain usage, the hardware wallet should meet a recognized standard so that transaction integrity is accomplished. One such standard is FIPS 140-2 level 3 certification, which is a US Government security module certification program with level 3 being dedicated to hardware security module security. Very few hardware wallet providers have this certification.Footnote 16
2.4 Smart contracts, security, and enforceability
In 1996 when Nick Szabo published his proposal for smart contracts, the underlying technology had not been developed (Szabo, Reference Szabo1996), but since the advent of blockchain and the introduction of the Ethereum platform in 2015, smart contracts have become in part a reality.Footnote 17 Szabo saw smart contracts as a way of embedding security into hardware and software and have been described as ‘user defined programs running on top of a blockchain’. As originally conceptualized by him (Szabo, Reference Szabo1996)
a smart contract is a computerized transaction protocol that executes the terms of a contract. The general objectives are to satisfy common contractual conditions (such as payment terms, liens, confidentiality, and even enforcement), minimize exceptions both malicious and accidental, and minimize the need for trusted intermediaries. Related economic goals include lowering fraud loss, arbitrations and enforcement costs, and other transaction costs.
The testing issue with smart contracts is that they are neither smart nor a contract.Footnote 18 A contract is essentially an agreement between two or more legal entities that will be enforced by law. Instead, here the smart contract code will be implemented and enforced by the blockchain. For public policy reasons, smart contract code will, if there is a dispute, be reviewed by the courts to ensure that the code does not execute in a manner that offends current legal policy. For example, the courts will enforce liquidated damages clauses, but they will not enforce penalty clauses. An enforceable liquid damages clause is one where the parties agree at the time of contracting as being a genuine pre-estimate of the possible ensuing damage that could occur in case of a breach. Szabo’s aim was to make a breach of contract expensive for the breacher (Szabo, Reference Szabo1996). Such a position is not acceptable to the courts for public policy reasons. First, it is not possible to oust the court’s jurisdiction by encoding the contract to make it inaccessible. Second, as Keane J, in Lucio Robert Paciocco & Anor v Australian and New Zealand Banking Group Limited stated:
Equity regards a collateral provision designed to provide an incentive to perform a principal obligation as objectionable on the ground that its enforcement was unnecessary to give the promise the benefit of the substance of the transaction.Footnote 19
Furthermore, Lords Neuberger and Sumption in Cavendish Square Holding BV v Talal El Makdessi stated the following:
The true test is whether the impugned provision is a secondary obligation which imposes a detriment on the contract-breaker out of all proportion to any legitimate interest of the innocent party in the enforcement of the primary obligation. The innocent party can have no proper interest in simply punishing the defaulter. His interest is in performance or in some appropriate alternative to performance.Footnote 20
Consequently, for smart contract code to be enforceable at law, it must not strictly follow the Szabo proposal as such a position will be struck down as unenforceable at law. Essentially, the courts would not assist in the enforcement of contract provisions that are interpreted as oppressive.
Since smart contract code is technically self-sufficient, once it has been invoked, it executes based upon certain events either occurring or failing to occur. If the result of a smart contract code is determined to be a penalty, and so unenforceable, there needs to be a way of correcting the output written to the blockchain, taking into account the immutability of data written to the blockchain. The solution could be a court order compelling a party to prepare correcting code which will write a new record to the blockchain, without the need for a fork. In addition, there would have to be a termination mechanism incorporated into the code, so no further records are written. But this too raises issues, especially if the contracts involve a one-to-many relationship and only one of the parties is actually disadvantaged, though it is difficult to see how this could in actuality occur.
The most basic issue with smart contract code is the assumption that there will be no errors in the code. Complexity, in any coded solution, always creates the possibility for errors to be included. In May 2016, the DAO code, a special smart contract that tried to establish the first Decentralized Autonomous Organization, was released on the Ethereum blockchain and that particular code had major vulnerabilities which caused the Ethereum stakeholders to implement a hard fork (Hinkes, Reference Hinkes2016). This was controversial at the time as many participants in the Ethereum blockchain believed code represented ‘law’, and therefore it was against their beliefs that the Ethereum blockchain should be forked. The code, however, contained a known bug that ultimately allowed one of the DAO’s participants to divert 3.6 million ether (ETH), roughly valued at 50 million, into a ‘child DAO’ controlled only by that participant. To the credit of the Ethereum hierarchy, they decided to implement a hard fork so that all persons who were adversely affected by the vulnerability did not lose their investments. If this action had not taken place, it would most likely have resulted in the first court case dealing with the failure of a smart contract.
There are real possibilities that smart contracts will not only interact with the particular blockchain in which they are embedded but could also interact with other blockchains. Consequently, interoperability becomes a potential major issue for commerce because commercial contracts can be impacted by third parties who are not privy to the principal contract.
3 Interoperability of blockchains
It is reasonable to forecast that there will be multiple blockchains because of their decentralized nature, and multiple environments are already being created, for example, Cardano, NEM, Ethereum, and Hyperledger. And interoperability across blockchains will become a core requirement both from mechanical and value levels (Hardjono et al., Reference Hardjono, Lipton and Pentland2018). NIST (Yaga et al., Reference Yaga, Mell, Roby and Scarfone2018: 1) has defined ‘interoperable blockchain architecture’ as
An interoperable blockchain architecture is a composition of distinguishable blockchain systems, each representing a distributed data ledger, where transaction execution may span multiple blockchain systems, and where data recorded in one blockchain is reachable and verifiable by another possibly foreign transaction in a semantically compatible manner.
Interoperability is not simple because it will depend on how data are stored on blockchains. Further, interoperability will need to contend with off-chain data sources and will be subjected to data ownership and access policies invoked by owners of data sets (Ribitzky et al., Reference Ribitzky, St. Clair, Houlding, McFarlane, Ahier, Gould, Flannery, Pupo and Clauson2018).
According to Buterin (Reference Buterin2016)
The benefit of interoperability is that it should open up a world where moving assets from one platform to another, or payment-versus-payment and payment-versus-delivery schemes or accessing information from one chain inside another (e.g. ‘identity chains’ and payment systems may be a plausible link) becomes easy and even implementable by third parties without any additional effort required from the operators of the base blockchain protocols.
Within this context, the most likely mechanisms for moving assets will be smart contracts and we examine some of the many external factors that influence the performance of contracts and smart contracts. We should point out that this area of research is relatively underpopulated compared to others in blockchain (see Risius and Spohrer, Reference Risius and Spohrer2017: 402–403, Table 4).
3.1 Interoperable mechanisms and interference of contracts
The performance and outcome of any contract are affected by both internal and external factors. For example, even an instantaneous contract can be affected. If an instantaneous contract is a sale of goods contract where a consumer purchases goods from a merchant, then for the most part, the transaction is completed in a moment. The consumer usually pays over some money (consideration), and the merchant delivers and transfers title in the goods to the consumer. The basic terms of such a contract are that an offer is made by the consumer and the merchant accepts the offer and in consideration of payment delivers the subject matter and title, both of which occur instantaneously. In effect, the contract is formed and completed immediately—buying a chocolate bar in a 711 store is an instance of such a contract—but that is not the end of the contract.
There are occasions when regulators recall goods, post-completion, which reverses the entire contract, for example, children’s toys being dangerously manufactured or food items that have been open to tampering. Usually, consumer contracts have basic implied terms that the goods or services delivered are of merchantable quality. The result is that goods or services must be in good working order for a reasonable time post-completion of the contract. If they are defective and such defects are discovered after completion, then the implied term will come into force that may result in a requirement to rectify the defect or the merchant may be required to refund the price to the consumer.
In addition to instantaneous contracts are longitudinal contracts, sometimes known as executory contracts, where performance is executed over a period. Examples of longitudinal contracts include loan agreements or mortgages where borrowers agree to pay the loan over a period of years and provide a security to support the loan. Other examples are contracts for services where a contract to build a rail tunnel over a 130-week period would be classified as longitudinal.
Longitudinal contracts by their nature are prone to interference by external events which can substantially impact performance. Because of this, it is common for longitudinal contracts to contain force majeure clauses, also known as ‘Act of God’ clauses. These clauses consider external events that are outside the reasonable control of either party. For instance, in dealing with a rail tunnel construction agreement, the contract may provide for 24 hour tunnelling, but such tunnelling may adversely affect adjoining properties, and the owners of these properties might obtain injunctions to restrict tunnelling to 16 hours per day.Footnote 21 Since the external event would obviously prolong the delivery of the tunnel, the contract could be subjected to the legal doctrine of frustration that would end the entire performance of the contract.
If smart contracts are to meet the business requirements of traditional transactional activity, then they should be designed to accommodate impacts of external factors. The question is how would a smart contract operating on blockchain A be able to take into account external events that are recorded on another blockchain environment, blockchain B. Suppose blockchain B is an oracle operated by a trusted third party that collects trusted information such as meteorological or geological data including tremor data covering earthquakes. The smart contract on blockchain A will want to be able to read data stored on blockchain B as it would be important for determining whether force majeure events have occurred. Hileman and Rauchs (Reference Hileman and Rauchs2017) identified the current lack of interoperability between different blockchain frameworks as a major business concern. They argue that interoperability generally falls into two main categories: cross-chain interoperability and enterprise system integration and interoperability.
3.2 Interactions between cross chains
This section only discusses the first category as the second concerns issues extraneous to blockchains and therefore lies outside the scope of this paper. The first category involves the technical connection between separate blockchains that facilitate cross-chain communication, interaction, and value transfer. For Hileman and Rauchs (Reference Hileman and Rauchs2017), the solution for implementing interoperability between separate blockchains is a common inter-chain messaging protocol (CICMP), which involves the development of a CICMP, based either on an existing ISO protocol or an emerging dominant industry framework or application. Examples of the latter include Ripple’s ‘Interledger Protocol’, the Cosmos ‘Network Zones Project’, and the Polkadot Project, which is a complementary protocol to Cosmos that enables different blockchains to leave their silos and interact seamlessly. It relies on relay chains and para-chains which can be deployed through its protocol to build bridging chains for interoperability.
Cross-chain capability is still in its infancy technologically. And if secure and trusted cross-chain connectivity is not achieved, then this will become a major impediment in gaining the full benefit of blockchain technology. One potential solution proposed, in addition to that outlined above, is the adoption of anonymous multi-hop locks (AMHL) (Malavolta et al., Reference Malavolta, Moreno-Sanchez, Schneidewind, Kate and Maffei2019). AMHLs prevent the inevitability of wormhole attacks in off-chain payment channel networks where the numbers of intermediaries grow. The problem is that as transactions time out instead of committed coins being reimbursed, the attacker is able to steal the fees without leaving a trace (Malavolta et al., Reference Malavolta, Moreno-Sanchez, Schneidewind, Kate and Maffei2019: 4). AMHLs have possibilities beyond payment channel networks, especially where interoperability is the crucial issue. Furthermore, as the proposed technologies are embryonic, the problems around ensuring stability in standards, which we discussed above, are pervasive.
3.3 Sidechains and interoperability
Sidechains are relatively new emerging mechanisms that enable digital tokens associated with one blockchain to securely interact with separate blockchains and then be moved back to the original blockchain, if and when needed (Dilley et al., Reference Dilley, Poelstra, Wilkins, Piekarska, Gorlick and Friedenbach2017). Their essential property is that they are separate blockchains linked to parent blockchains via a two-way pegs that permit digital tokens to be interchangeable and moved across chains at fixed deterministic exchange rates and operate by using simple payment verification proofs (Back et al., Reference Back, Corallo, Dashjr, Friedenbach, Maxwell, Miller, Poelstra, Timón and Wuille2014).
The development of interoperability is still in its infancy and much work remains to be undertaken. It is doubtful that one organization would be able to solve this issue because it would require concerted effort by many industry organizations and academic researchers to specify a viable commercial solution that would be robust in a commercial environment. There are some interesting examples where interoperability across systems is being achieved, but they are being carried out on and with centralized databases rather than decentralized ones (Margulies et al., Reference Margulies, McCallie, Elkowitz and Ribitzky1990). It is likely a solution will arise from both collaboration among and competition between different entities and institutions, some of which could be international standard setting organizations such as the ISO or the ITU. Ribitzky et al. (Reference Ribitzky, St. Clair, Houlding, McFarlane, Ahier, Gould, Flannery, Pupo and Clauson2018) explored the potential for blockchain in healthcare, and while they believe it can be disruptive and transformative, its budding status cannot yet realize the full range of opportunities.Footnote 22
4 Conclusion
Blockchain in its current configuration has much in its favour, given the creativity of the community, but because of its position within a decentralized community, agreements on future developments are contingent on the community pulling together at crucial junctures. Thus far, progress here is limited as we have indicated. We identified three areas of concern where some form of standards will be necessary to enable future development. The first is blockchain governance that includes standards, data, and key security. There are many problems with the establishment of standards. As we have emphasized above, standards are constantly contested, even in non-blockchain worlds, but the characteristically fraught nature of the blockchain community increases the difficulties. Even when standards are established, and accord subsists, there is no guarantee they will remain stable. The second problem concerns smart contracts where the optimism for ‘code as law’ in the blockchain community does not yet harmonize with the law of contracts and lawyers’ communities. To achieve some conformity between the two will require greater understanding between the legal and blockchain communities, which remains open. The final area of concern is interoperability between blockchains. This is as much a technological problem as it is a social problem. With many differing solutions being promulgated, it is difficult to determine if consensus is feasible. How choices and selections will be made again remains open. While our brief has not to produce solutions, but rather to suggest areas for future research, our problem identification of key issues illustrates where solutions must be found. As Risius and Spohrer (Reference Risius and Spohrer2017) state, there is scant empirical research on these issues as yet. This is the agenda for the future.
Blockchain is a community of contradictions, oppositions, alliances, and sometimes consensus. There is no way to bring the different factions together yet. The underlying political philosophy of blockchain is very much anarcho-capitalist (Flood and Robb, Reference Flood and Robb2017), which places blockchain in the libertarian camp, one that is essentially anti-state and pro-individual. As business becomes more involved in developing and deploying blockchain, its roots should have less influence over its future.
Acknowledgements
The authors would like to thank the following persons for their useful comments in the preparation of this paper: Alan Davidson, John Humphrey, Mark Staples, Sandy Maitland, Burt Tregub, Rick Skibo, and the two anonymous reviewers.
