The Effect of a Blockchain Fork on Asset-Backed Tokens


If it forks you’re fried.

Asset-backed tokens are at serious risk for any blockchain network subject to a hard fork. In this article, we first explain types of forks, why they happen, and briefly discuss known issues surrounding forks. We then describe how a blockchain fork presents endangers asset-backed tokens and the challenge faced by an issuer of asset-backed tokens in distributed infrastructure.

BY Peter Jensen-Haxel and Byungkwon Lim

The Effect of a Blockchain Fork on Asset-Backed Tokens
v05, 2018.09.07
Peter Jensen-Haxel and Byungkwon Lim

A debate about blockchain governance and its future has begun. Last year has seen a number of large public blockchains networks split into separate networks, often due to a dispute over the underlying rules that should operate on the network. This split is referred to as a fork, of which there can be many types. A fork can represent an opportunity, for example where a new fork of Bitcoin called Bitcoin Cash was instantly valued by exchanges. But a fork can also represent a challenge or risk for a network and its community of users, for example as occurred when Ethereum split into Ethereum and Ethereum Classic. The main mechanism of carrying out a governance decision (or proposal) is what is referred to as a “hard fork”.

What is not readily apparent is that asset-backed tokens are at serious risk for any blockchain network subject to a hard fork. In this article, we first explain types of forks, why they happen, and briefly discuss known issues surrounding forks. We then describe how a blockchain fork presents endangers asset-backed tokens and the challenge faced by an issuer of asset-backed tokens in distributed infrastructure.

What Is a Fork?
A fork is a divergence that occurs in a blockchain, either in its code, its database (generally storing a transaction history), or both. Depending on one’s perspective, a blockchain fork represents a fresh beginning or an ominous choice; a new experiment or a rebellion.

There are different types of fork. First, there is what we will refer to as a code fork. A code fork is where the source code for a blockchain project is taken in two different directions. This is the closest to traditional usage of the term “fork” pre-dating blockchain, when the term was already used to describe the divergence of software code, and especially open source software code. In the context of blockchain, the “code” we are referring to is the code that runs on each node of the distributed network that validates transactions. That code contains the “rules” of the network, for example the algorithms for accepting transactions and forming them into blocks, communicating with other nodes, validating transactions, and achieving network consensus. This software is sometimes referred to as a client, or in the case of Ethereum, as a “virtual machine.”

Litecoin is an example of a pure code fork of Bitcoin. Although based on the Bitcoin source code, Litecoin changed certain algorithms and parameters. The two networks share no overlapping transaction history, as they were both initiated from their own origin block.

Second, there is a database fork. This is where the transaction history of a blockchain network diverges. For example, Bitcoin Cash utilized the existing history of Bitcoin to initiate a new cryptocurrency. Once initiated, however, the history of Bitcoin and Bitcoin Cash diverged. In other words, if one owned Bitcoin just before the split, they would own it on both networks after the split. However, they could then interpedently transfer the value on either network.

A code fork and a database fork are related. The initiators of Bitcoin Cash adopted changes to the Bitcoin codebase that were controversial in the broader Bitcoin community. Their fork represented both the database fork described above, and a subtle code fork.

As a brief note, a temporary database fork occurs each time two validation nodes independently claim to have added a valid block, for example where two Bitcoin nodes solve the proof-of-work puzzle before being able to communicate with one another. Two competing chains temporarily result not from a code update but as an edge case of the normal operation of the consensus mechanism. It is the function of the consensus mechanism to bring the distributed ledger back to consistency. In most systems, the chain to which a subsequent block is added (e.g., the longest chain) prevails. The shorter chain is automatically abandoned by the network. If the consensus mechanism is robust, this temporary fork does not create a diverging database and poses no practical threat to the network.

A code fork that occurs to a network that already has a transaction history can be a “hard fork” or a “soft fork.” A soft fork is backwards compatible with the old version of the code. Let’s say, as a simple example, that the protocol of a network is modified to reduce the block size from 1MB to 0.5MB. In this case, a new block containing 0.5MB of data will be accepted by the old version of the chain, but a new block with 1 MB of data will be rejected by the new version of the chain. Participants that did not update their software can participate in the network, but those participants’ functionality is affected. Particularly, non-upgrading miners will experience their mined blocks being rejected by the network. Therefore, over time, all participants are expected to (and will in all likelihood) upgrade the software and move over to the new chain. Until all participating nodes move over, the two chains will run concurrently.

A hard fork takes place when in the new version of the codebase is incompatible with the older version. Unless all participating nodes update the software, the non-updating nodes will create a separate chain that runs concurrently with the chain operating under the new code. If a sufficient number of validators and users continue to support a “minority” chain, the two competing chains and networks now run concurrently. In some cases, the minority may not last long. For example, even if a large number of miners initially support the old version of the chain but only a very small number of participants stay on it, the price of the native token or its liquidity may drop, and validators will be financially motivated to switch to the new chain (although miners may be able to switch back and forth as financial opportunities dictate.)

Now that we have seen an example, we can restate the relationship between a hard fork and a database fork: a hard fork on an existing network that is not unanimously adopted always forces a database fork..

In this article, we will focus on forks resulting from a change to the operation software which are the primary mechanism for updating and adapting existing networks including implementing governance-level actions. As we will see, hard forks have real-life consequences to network participants, especially for asset-backed tokens.

Why Does a Fork Happen?
A fork is simply part of the life for the open source blockchain architecture. A number of blockchains have experienced forks for a variety of reasons, but the common theme is that a fork is the only mechanism to implement a change to the software code of the blockchain. Because a blockchain is a decentralized, distributed operating system, any material rule change requires the release by software developers of a new or modified software to the community. For public blockchains, this is generally an open-source release. A unanimous agreement among all participating nodes is necessary to prevent a network fork.

A blockchain’s software code, like all software, occasionally has to be upgraded to fix bugs and patch holes. Let’s consider an upgrade that fixes a security flaw. A group of software developers write an updated version of the software. The developers post it where those operating nodes can easily find and download it. The nodes will generally update quickly, sometimes through coordinated effort (for example, a system-wide adoption of an upgrade at a pre-determined block height). Non-updating nodes will find themselves part of a dwindling network that users stop sending transactions to because the identity of the network is perceived to be the upgraded version. In this type of situation, the blockchain that operates on an old code will see decreasing transactions, validators, and will not likely be listed on an exchange. Once all validators have dropped out, new transactions are no longer accepted and there are no validators to create new blocks or even store the ledger of transactions in the abandoned fork.

In some cases, however, developers decide to propose changes to improve the functionality of the network, add a new functionality, or change the manner the network operates. For example, developers may decide to tune the consensus mechanism to trade security for speed, or increase the block size. Any such change may benefit one type of user at the expense of another. Other changes may be offensive to certain users, even if they result in benefits to almost all network participants. This is the political, people-driven governance process for deciding what code runs on the nodes, and which version of the ledger database is the “true history.”

Blockchain is a young technology in the process of evolving and improving. A fork is currently the only way to accomplish this evolution for a decentralized operating system. Therefore, a fork is the network-level governance mechanism. The Bitcoin blockchain has experienced approximately fifty hard forks with many of them quietly converging into one network we know as Bitcoin. A few hard forks have survived with the resulting new blockchain network. Bitcoin Cash was created to increase the block size and later added the smart contract functionality. Litecoin was introduced to implement a different proof-of-work algorithm and a faster block time. A fork is essentially a mechanism for developers to improve their blockchain operating system, or at least one more aligned to their philosophy of security, efficient, and decentralization. For example, the team behind Monero releases scheduled releases about every six months.

Occasionally, a hard fork is used to perceived injustice in the transaction history caused by a malicious actor. Ethereum’s DAO hack resulted in the split of the Ethereum blockchain. A hard fork was the only way to undo the theft, but a sufficient number of people controlling validation nodes objected to re-writing the transaction history for philosophical reasons, resulting in a data fork with a shared but diverging history: Ethereum and Ethereum Classic.

All participating nodes rarely agree to adopt the new version of the blockchain at the time of (or soon after) the fork, unless a fork is planned in advance and all nodes have signed up (also referred to as “signaled”) that they will adopt the update prior to the implementation. A short history of blockchain has shown that it is difficult to have all (or even a majority of) participating nodes agree on a large rule change prior to implementation. Even if a majority of the notes agree on a change, the dissenting nodes may stay with the existing codes, so that the blockchain may split into two.

Finally, as a general rule, a hard fork can always be initiated for a blockchain network that has thee properties: (i) the ledger is distributed across two or more independent nodes; (ii) the software code for validating transactions is open-source; (iii) a complete copy of the blockchain database publicly available. We believe this is true even for blockchain with enhanced privacy features, and even for networks which have proposed on-chain governance systems, such as Tezos.

What Are Known Problems with a Fork?

There are numerous recognized problems when a hard fork splits a blockchain network. As a practical matter, it is difficult for non-validator users who just hold tokens, by far the majority of users of the network, to contribute to the high-level governance discussion despite its financial impact. A recent influx of owners o Bitcoin and Ethereum don’t understand the networks can fork at all, or readily confuse tokens of divergent networks,such as Ethereum Classic (“ETC”) and Ethereum (“ETH”), or Bitcoin Cash (“BCH”) and Bitcoin (“BTC”). For example, some owners of BTC at the time of the BCH fork have not realized that they also own a corresponding amount of BCH. Some token holders may send the tokens on one of the two networks when they mean to send value on the other.

A major problem is the uncertainty leading up to the split. The SegWit2x update to Bitcoin, two years in the making, ultimately failed at its proposed launch. This uncertainty adds confusion to the market, which impacts the trading of tokens.

On the technology side, there are some exploits that can take advantage of informational asymmetries or confusion following a fork. For example, a malicious actor may steal some tokens by resorting to a “replay attack.” Where the new fork successfully diverges, it can also create security vulnerabilities for the progenitor fork, as the sponsors of Monero recently warned

These issues have been generally discussed in the context of native blockchain tokens that have no direct relationship to the physical world, like BTC and ETH. When BTC forked into BTC and BCH, each user who controls a Bitcoin private key received the same quantity of BCH as that of BTC. However, a digital asset of this type is not linked to any external asset or does not carry any intrinsic value. If a sufficient number of people agree that both tokens carry value, users will continue to hold and spend them, and validators will process transactions and receive the associated reward. Therefore, a hard fork of a blockchain having a purely digital token does not necessarily result in any serious adverse consequence for the users, and it may even result in a windfall.

However, a growing number of projects and enterprises are seeking to issue tokens tied to real-world assets. While many such tokenizations were proposed in the past, these projects are now entering the implementation phase. Blockchain governance based on open source code and shared transaction history creates risks that are not yet widely recognized.

What Will a Fork Do to Asset-Backed Tokens?
When the blockchain representing physical assets forks and new tokens are created under the forked chain, the physical assets do not get created out of thin air to match the new tokens. Which token represents ownership and control of the physical assets?

As an example, let’s consider a mining company that wants to issue gold bullions using the Ethereum platform as its issuing infrastructure. The company has the option to issue the tokens through Ethereum’s popular ERC20 standard. The company engages a third- party bank with a physical vault where the physical gold bullion is stored. Token holders can redeem one kilo of gold per token. Subsequently, Ethereum undergoes a hard fork resulting in two parallel chains. Almost certainly this happens for reasons that don’t concern the gold token, for example a debate such as EIP999 which proposed to switch from a proof-of-work validation system to proof-of-stake. As a result of a hard code fork being forced on a network that is already operating, an inevitable database fork occurs. All token holders, assuming they control private keys at the time of the fork, will receive two identical tokens, one on each diverging network. This includes not only the native ETH currency, but the ERC20 tokens as well. Now, there are twice the number of tokens in circulation, all linked to the gold bullion. There is no governance mechanism to solve this issue because it is not a problem Ethereum or any other open source architecture was designed to deal with.

The company cannot afford to sit idly and do nothing. Twice the number of tokens are in circulation as they have kilos of gold stored in their bank vault. The company now has to: (i) assess which fork is best for it and/or which is more likely to survive, (ii) issue a statement regarding which fork is the “true” ledger that will represent the physical gold bullions in the vault, (iii) warn users to stop trading before, during, and for a period after the fork, and/or (iv) may field angry complaints and/or defend lawsuits from those who sent or received transactions through the wrong fork, especially if that token is regulated by the SEC and/or CFTC. The company may also instruct the bank not to deliver or redeem gold bullions to a token holder until the smoke clears, which could be a while. If the gold tokens are traded on some exchanges, the company may ask the exchanges to stop trading (but such requests are inapplicable to decentralized exchanges). Incidentally, all these actions, including the assessment by the company about the ‘true network’ and the statement and warning issued by the company, amount to a form of central control. This central control would seem to undermine the decentralized value proposition of Ethereum or other open source architecture.

Let’s say that the company somehow picked the “right chain” that will succeed in the long run. But, until the other chain is abandoned, transactions have been sent to the now- abandoned chain. Holders who bought tokens through that chain after the fork may suffer financial losses if they cannot redeem their tokens for gold. The company’s business reputation is threatened, even if it is not legally liable for those losses.

Picking the wrong fork, the one that ends up dying, is a nightmare scenario for the company. The company either stops its business until it is sure the fork will survive, or prays it picked correctly. The company cannot issue new tokens on the chain it didn’t pick. It cannot switch to the successful chain because it cannot call up customers who redeemed tokens for physical gold bullion to ask for the gold back in order to align the state of the physical world with the ultimately successful fork that was not originally selected. If the issuer guessed wrong, its tokenization breaks down and its business halts, or more likely collapses. Given the fundamental traits of blockchain, the company simply has no way to deal with a fork forced on its gold-backed token. Enterprises that want to issue tokens generally want to maintain and build relationships with their customers. They are centralized organizations who have almost exclusively relied on centralized service providers to serve customers. Losing control over technology infrastructure is an unacceptable risk for most business enterprises.

A company may believe its asset-backed token will be more successful if the company cannot unilaterally exert influence over users and tokens, which could also impact the token’s value. However, as we have seen, the company must unilaterally decide on the outcome of any fork. The purported benefit of decentralization is diminished, if not destroyed. On the other hand, the company wants to leverage its social capital and expand trust in its brand. This goodwill is accruing to the organization as a centralized entity. The company may want to assure the users that its platform will be secure and preserve the value of tokens, because the platform operates on a blockchain. Here arises the tension. The company has little control over the infrastructure of the host chain on which its own network is built.

If a company is properly advised on the potential risks from using an open source platform to issue a token or build a blockchain application, it will seek to protect itself by presenting users with a terms of service including a long, detailed risk disclosures statement and a broad liability waiver. It is not clear whether the sponsors of the DAO that forked Ethereum would have been able to escape liabilities based on such risk disclosures and disclaimers, but one cannot help but believe that they almost predicted that something might go wrong. The disclosure and disclaimer about the fork risk may or may not absolve the company, but they will, at a minimum, plaster-over the elegance of blockchain technology that otherwise function well among communities who don’t need to be responsible for infrastructure and who don’t care about representing real-world assets.

A fork cannot happen in all blockchains. It does not happen to a privately sponsored, permissioned blockchain which is tightly controlled by the sponsor. But then, if the sponsor exercises significant control over the validator node software code, that blockchain is antithetical to a fundamental philosophy of the distributed ledgers. A private chain controlled by its sponsor may expose participants to transaction censorship or closed participation. Satoshi Nakamoto attempted to prevent this through the design of Bitcoin. For example, the sponsor may impose new fees for the use of the network. The sponsor may introduce a new, but defective software. Users may wonder what the sponsor could do to benefit itself at the expense of the network users or benefit some of the users at the expense of others. A private blockchain may still generate some benefits for its users, even if the network is solely maintained by a central authority. For example, a private chain can reduce transaction and production costs by making transactions more efficient and transparent. It is then simply an extension of a centrally controlled ledger system with increased efficiency, transparency and, in some cases, immutability. Ideally, a private, permissioned chain should include some counterbalance to offset centralization risk. Otherwise, this private chain may just be seen as a convenient shared database, or an extension of the old business platform disguised the hype (and sadled with the overhead) of blockchain technology.

Infrastructure control and responsibility go hand-in-hand
The consequence of a fork is an obvious example of the governance issue faced by a blockchain platform based on an open source architecture, but it highlights a broader issue for centralized organizations relying on it. Let’s go back to the gold bullion blockchain built on Ethereum. What when the next unforeseen event occurs to the network? For example, what if a new DAPP (e.g., Crypto Kitties) congests the entire Ethereum at the time that the price of gold is plummeting? The issuer will have to explain why its users cannot sell their tokens. The token issuer will be held responsible as a central organization, because it selected the form of shared infrastructure.

Just as many ETH buyers do not understand the difference between Ethereum and Ethereum Classic, it is likely that most will not see risk in the political dynamics of network validation nodes operators. These operators are ultimately responsible for safekeeping the ownership records of users, yet have no obligation to the enterprise issuer of an asset-backed token, or even the holders of those tokens.

Any distributed blockchain built on an open source code faces a range of governance challenges and is subject to a hard fork. A token sponsor using this network (i.e., a centralized token issuer) cannot be certain of the future of its tokens, and is at significant risk each time the network forks. Second, it is almost impossible for the issuer of an asset-backed token to take responsibility for a distributed blockchain in a way that will meet its legal requirements and the expectations of its customers under existing and evolving standards.
Stay tuned…

Leave a Reply