Patterns for Blockchain Migration
With the rapid evolution of technological, economic, and regulatory landscapes, contemporary blockchains are all but certain to undergo major changes. In fact, Gartner predicts that "through 2021, 90% of the enterprise blockchain implementations will require replacement within 18 months to remain competitive and secure, and to avoid obsolescence." Yet, not wanting to lose the early adopter advantage, even enterprises are jumping on the blockchain bandwagon. However, it’s quite unclear which blockchain platforms will make the cut in the domain. Therefore, if the chosen blockchain turns out to be ill-suited, it might be difficult, costly, and risky to change it due to the incompatibilities in platforms, mode of hosting, and blockchain properties such as consistency, immutability, and openness. Thus, in our preprint, "Patterns for Blockchain Migration," we answer the question “What are effective patterns for safeguarding data, programs, and processes when migrating from one blockchain to another?”
With the emergence of more efficient, secure, and robust blockchain platforms, applications may want to change the blockchain used to gain higher throughput, low latency, and fast finality. Moreover, an application that uses a blockchain as the underlying data store may opt to move from a public blockchain to a private one to reduce transaction fees or enhance privacy. Also, business mergers and acquisitions, establishing/joining a new consortium, and regulatory changes may force an enterprise to move into a consortium blockchain or Blockchain as a Service (BaaS) platform. Business process reengineering, separation of internal and shared data, consolidation, collapsing of a public blockchain platform (e.g., due to an attack), and change of blockchain platform fees and licensing terms may also trigger migration in an enterprise setting.
Compared to database migration, blockchain comes with its own set of opportunities and challenges. On the one hand, blockchain's schema-less nature (such as key-value store) makes the mapping between blockchains relatively easy. Moreover, the quality of data on a blockchain can be high due to the data consistency and completeness provided by consensus and immutability, respectively. Optionally, blockchains might include business logic in the form of smart contracts. Smart contracts aren’t only more expressive and complex than stored procedures but also specific to a blockchain platform. Thus, they may need to be rewritten for the target blockchain platform leading to potential errors despite significant time and cost needed to develop and test them. Moreover, global state, transaction sequence, and history can't be arbitrarily recreated on the target blockchain due to the consensus process and the need to preserve consistency and data provenance. Furthermore, as transactions are digitally signed, they can’t be replayed across blockchains without access to private keys. Blockchain migration must be a single-shot process as rollbacks are difficult due to immutability. Therefore, blockchain migration becomes a nontrivial, costly, and risky process, especially when the unique aspects of blockchains are combined with high failure rates of database migration. Blockchain migration is already happening and some of the well-known cases include Vechain, Binance, Tron, Safex, Qubicles, Kin, Gifto and Deloitte.
We first explain a set of blockchain migration scenarios and data fidelity levels using an illustrative example. The example is derived from our blockchain project experience, related work, and anticipated future needs. Second, we identify 13 patterns to achieve those blockchain migration scenarios under varying data fidelity levels. While six of these patterns are used in database migration, we highlight specific adaptations needed to support blockchain migration. Three other patterns from blockchain and database literature are also adopted to address non-functional aspects such as quality of migrated data, cost, and privacy. Third, using the illustrative example, we discuss how the proposed patterns and data fidelity levels could be used to address the identified migration scenarios and data management challenges.
We conclude by explaining that, while migrating to a private or consortium blockchain could be achieved relatively easily, recreating full blockchain history on an existing public blockchain is impractical. Nevertheless, the global state can still be recreated, which is sufficient for most practical migration scenarios. Therefore, the success of blockchain migration boils down to choosing the correct data fidelity level that balances competing factors such as performance, cost, time, granularity of data, transparency, security, privacy, and risk. Some of the unsolved problems around blockchain migration are identifying the best data fidelity level for a given application scenario, lack of access to private keys, confirming the correctness of translated smart contracts, best practices to simplify future migration scenarios, and handling user permissions.
We believe our findings will help blockchain application designers, consultants, and researchers to be more aware of the feasibility and caveats of migration, as they push the frontier of blockchains and their applications. We welcome comments on our patterns and further examples.
Figure – Overview of patterns
Dilum Bandara - Data 61, CSIRO, Australia
Xiwei Xu - Data 61, CSIRO, Australia
Ingo Weber - Technische Universität Berlin, Germany