Patterns for Blockchain Migration

06/01/2019 ∙ by HMN Dilum Bandara, et al. ∙ 0

With the rapid evolution of technological, economic, and regulatory landscapes, contemporary Blockchian platforms are all but certain to undergo major changes. Therefore, applications that rely on them will eventually need to migrate the Blockchain to remain competitive and secure, as well as to enhance the performance, cost efficiency, privacy, and regulatory compliance. However, the differences in data and smart contract representations, mode of hosting, transaction fees, and the need to preserve consistency, immutability, and data provenance introduce unique challenges over database migration. We first present a set of Blockchain migration scenarios and data fidelity levels using an illustrative example. We then derive a set of migration patterns to address those scenarios and above data management challenges. Finally, we demonstrate how the effort, cost, and risk of Blockchain migration can be minimized by choosing a suitable data fidelity level and proactive system design. Practical considerations and several research challenges are also highlighted.

READ FULL TEXT VIEW PDF
POST COMMENT

Comments

There are no comments yet.

Authors

page 1

page 2

page 3

page 4

This week in AI

Get the week's most popular data science and artificial intelligence research sent straight to your inbox every Saturday.

1 Introduction

Since the launch of Bitcoin a decade ago [1], an unprecedented number of Blockchain (BC) platforms with different designs, features, and operational models have emerged. While each claims its superiority over predecessors in terms of performance, security, or user backing, given application scenario, it is nontrivial to identify a fitting BC platform. However, not wanting to lose the early adopter advantage, even the Enterprise Information Systems (EISs) and Business Process Management Systems (BPMSs) are starting to adopt BC platforms [2], [3]. Alternatively, as the technological, economic, and regulatory landscapes are still evolving, it is quite unclear what BC platforms will make the cut in the the EIS and BPMS domains. Therefore, if the chosen BC turned out to be ill-suited, it might be difficult, costly, and insecure to change the BC due to the mode of hosting, incompatibilities in platforms, and BC properties such as consistency, immutability, and transparency. While migration is mostly an afterthought, it is imperative to know whether migration is a possibility and any caveats compared to database migration.

Migrating from one data store to another is inevitable for a long-running application [4], and BC-based applications – where BC provides a neutral platform to store data and execute Smart Contracts (SCs) – are no exception. For example, an application that uses a BC as the underlying data store may opt to move from a public BC to a private one to reduce transaction (TX) fees or enhance privacy. Moreover, with the emergence of more efficient, secure, and robust BC platforms, applications may want to change the BC to gain higher throughput, low latency, and fast finality [5]. Furthermore, business mergers and acquisitions, establishing/joining new consortia in cross-organizational processes, as well as regulatory changes [6] may force an organization to move into a consortium BC or BC as a Service (BaaS) platform. Business process reengineering, separation of internal and shared data, hardware swapping, consolidation, collapsing of a public BC platform due to an attack, change of platform fees and licensing, and lack of vendor support may also trigger a migration [6]. Gartner expects that “through 2021, 90% of the enterprise BC implementations will require replacement within 18 months to remain competitive and secure, and to avoid obsolescence”[7]. Alternatively, similar to running multiple databases, an organization may also adopt multiple BCs with different cost, performance, and workload characteristics, which might involve partial BC migration.

While database migration best practices [6], [8] and numerous patterns [4], [9], [10], [11] could be adopted for BC migration, BC brings in its own set of opportunities and challenges. On the one hand, a BC could be abstracted as a key-value store that maintains a set of states [12]. Thus, BC’s schema-less nature makes it easier to map from one BC to another. Moreover, the quality of data on BC is high due to data consistency provided by consensus and completeness provided by immutability. These characteristics also make it easier to reverse engineer the BC Access/API Layer (BAL) (see Figure 2) of the application in case the documentation is lost, or key developers have left the organization. Alternatively, BCs might include business logic in the form of SCs [12]. SCs are not only more expressive and complex than stored procedures but also specific to a BC platform. Thus, SCs may need to be rewritten for the target BC platform leading to high potential for errors despite significant time and cost needed to develop and test them. Moreover, global state, TX sequence, and history cannot be arbitrarily recreated on the target BC (e.g., public BC) due to the consensus process and the need to preserve data provenance. Furthermore, as TXs are digitally signed they may not be replayable across BCs without the access to private keys. Even when workarounds are possible, significant time and cost are required to migrate a large volume of accounts, assets, states, and TXs that are interrelated.

After all, BC is supposed to be immutable! Thus, getting users’ consensus prior to initiating any migration-related changes to BC software is paramount to the project’s success [6]. For example, both Bitcoin and Ethereum communities were split due to the disagreements over changes proposed to enhance the performance and recover from an attack, respectively. BC migration has to be a single-shot process as rollbacks are not possible due to immutability. Therefore, BC migration becomes a nontrivial and risky process [7] when the unique aspects of BCs are combined with high failure rates of database migration, despite decades of expertise, best practices, and patterns [6]. Nevertheless, as soon as data or implementations of EISs and BPMSs are on the BC, this concern of migration is relevant. In fact, BC migration is already happening [5], [13], [14], [15], [16], [17], and will be inevitable with time [7]. Therefore, it is imperative to answer the following research question:

What are the effective patterns for safeguarding data, programs, and processes when migrating from one BC to another?

In this paper, we first explain a set of BC migration scenarios and data fidelity levels using an illustrative example. The example is derived based on our BC experience, related work, and anticipated future needs. Second, we identified 13 patterns to achieve those BC migration scenarios under varying data fidelity levels. While six of these patterns are used in database migration, we highlight specific adaptations needed to support BC migration. Three other patterns from BC 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 each of the identified migration scenarios could be accomplished using the proposed patterns and data fidelity levels. In conclusion, while migration to a private or consortium BC could be achieved relatively easily, recreating full BC history on an existing public BCs is impractical. Nevertheless, the global state can still be recreated which is sufficient for most practical migration scenarios. Therefore, the success of BC migration boils down to choosing the correct data fidelity level that balances competing factors such as performance, cost, time, effort, granularity of data, security, privacy, and risk. Finally, we discuss practical considerations and research challenges.

The rest of the paper is organized as follows. Sec. 2 defines terminology and present the illustrative example. Migration scenarios and data fidelity levels are presented in Sec. 3, while patterns are proposed in Sec. 4. Migration pattern to scenario mapping and a set of use cases are presented in Sec. 5. Sec. 6 discusses practical considerations and research challenges. Concluding remarks are highlighted in Sec. 7.

2 Background

2.1 Definitions

We first define a set of terms related to BC data and migration.While most of these terms come from Ethereum and Bitcoin they are widely adopted by BC industry and research community and reused in [18], [19], [20]. These terms are defined to better express the illustrative example, BC migration scenarios, data fidelity levels, and patterns only.

A state is anything tracked by a BC such as the ownership and value of an asset, balance of an account, Unspent Transaction Output (UTXO), reputation, and an attribute of a physical object. An account (aka., address) is a reference/key to a state or SC, e.g., owner of an UTXO in Bitcoin [1] or balance of an Ethereum account [12]. Global state is the collection of all accounts and their current state(s) tracked by the BC. While SCs may also have embedded state, it is recommended to separate the state of SC code to enhance the upgradability and cost efficiency of SCs [21]. Hence, state also refers to a state used by a SC.

A transaction (TX) is used to initiate a valid state transition. For example, a TX can change the ownership of a title or debit cryptocurrency from one account and credit to another. A Smart Contract (SC) is a set of executable instructions that are activated in response to a TX. When executing, these instructions may change the state and generate new TXs. Similar to database TXs, BC TXs also perform complex operations on multiple states. However, they do not fully support CRUD operations and ACID properties [22]. History (aka., block history) is the collection of all blocks produced by the BC. Each block internally tracks all TXs, SCs, and resulting state after executing those TXs and SCs.

BC platform is a distinct piece of software such as Bitcoin, Ethereum, and Hyperledger. An execution of such a platform with specific permission and configuration is referred to as a BC instance. We consider scenarios where an application using on a BC instance, wants to either change the instance or the specific hardware it runs. The current BC instance is referred to as the source BC, and the one resulting after the change is referred to as the target BC. The source and target BCs could be the same or different instances with varying levels of permissions such as private, consortium, and public.

Different terms such as migration, transfer, conversion, and moving refer to the processes of copying data from the source data store to the target. Here we define BC migration as the process of recreating full or part of the accounts, states, TXs, SCs, and history on the target BC. Underneath this not only includes data transferring, but also distributed commutation, data exchange, and consensus across a large number of distributed nodes. We exclude BC reconfiguration and software upgrade scenarios where data remain backward compatible and within the same BC instance. For example, changing the consensus algorithm in Hyperledger Fabric while retaining the sate database [18] and soft forks where old blocks are still valid under updated state transition rules. While we also consider migration as a one-way process with no return [6], we consider the possibility of either continuing or decommissioning the source BC after the migration. This is necessary as a public BC may continue to operate even after one of the alt-coins coins move to its own BC instance [5], [16].

2.2 Motivating Application Scenario

Suppose a nonprofit hosted a concert to raise funds for its charity work. The nonprofit pledged to allocate at least 50% of the profit to the charity work. It puts $2,000 as the seed money hoping to recover it after meeting the pledge. If there was more profit, the nonprofit further planed to set-aside another 50% of it as next year’s seed money and use any balance for further charity work. Moreover, they reached to several sponsors and donors to further raise additional capital. Necessary expenses included the fees to key artists (other artists volunteered), venue, equipment, and marketing.

The nonprofit decided to use a BC, as it wants to be transparent on how the income and expenses are managed. Moreover, it hoped such transparency would attract more audience, sponsors, and donors. Pledge to charity work and recovery of seed money were defined as SCs. In case of a loss, the nonprofit planed to settle part of the dues to the venue and equipment from a future event. It decided to go with a public BC that was willing to wave off TX fees for tickets purchased via the BC. A budget was prepared, and double-entry bookkeeping style TX records were maintained using the BC. Therefore, a separate account was created for each budget item. A ConcertCoin was defined to minimize the impact of cryptocurrency fluctuation, potential errors and fraud, and enhance the traceability. Several exchanges also agreed to buy and sell ConcertCoins without a commission. Seed money was then converted to ConcertCoin and dispersed to accounts using a funding SC. Another set of SCs was defined to disperse the income as per the needs of budget items, ensure budget limits are met, and payments comply with spending rules.

The concert was an overwhelming success, partly due to its high transparency in handling finances and ensuring that committed funds go to the charity work. Eventually, the ledger was balanced, and all the payments, seed money, and next-year concert’s retention were settled as per the SCs. Given the overwhelming success of the concert and greater transparency it demonstrated, the nonprofit decided to use the BC for other fundraisers. It further planned to track the disbursement of aid and actions by the field staff, as there are known cases of unequal distribution of aid and misappropriation. However, it is also realized that the field staff may have intermittent connectivity to the Internet while on the field.

Soon after, the BC community stoped providing free TXs due to the increasing cost of Proof of Work (PoW). Consequently, exchanges are also forced to charge a commission for ConcertCoin conversions. Moreover, cost and performance problems are unlikely to be solved in the immediate future as the experimental Proof of Stake (PoS) protocol by the BC platform seem to be ineffective in reducing costs and enhancing performance while having high security. Given these circumstances and the need to integrate future fundraisers and internal activities the nonprofit decided to change the BC instance.

3 Blockchain Migration Scenarios

In this work, we assume that the decision to migrate is already made and the target BC is chosen based on the relative importance of factors such as performance, cost, time, effort, granularity of data, and privacy. We consider different choices for the target BC instance, such as preexisting or new; private, consortium, or public; and same or a different BC platform. We also consider the possibility of not decommissioning the source BC after the migration. At this point, the nonprofit has a few options such as to cash out and start anew, transfer only the closing balance(s), or transfer the global state and history to the target BC. Each option has its pros and cons, and may require changes to data and BAL based on how the state is represented, TXs are tracked, SCs are coded, history is preserved, and interoperability is preserved.

In the context of the above illustrative example and other potential use cases following data migration scenarios can be identified:

1. Transferring

– changes the hardware that the BC instance runs. For example, the nonprofit may transfer an on-premise BC instance to IaaS or BaaS cloud instance to gain the benefits of could computing. Offloading a BC instance to advanced hardware to gain high performance, e.g., in Internet of Things (IoT) and fog computing applications [23], is another example.

2. Upgrading

– creates a new BC instance to gain better performance, security, novel features, lower cost, and openness while losing backward compatibility. For example, the nonprofit may move from PoW to PoS version of the same BC platform to get better performance and cost efficiency [15].

3. Consolidating

– combines two or more existing BCs to a single target BC. An example case is the merging of two businesses where BC-based applications are consolidated by migrating one of the BC instances to the other. Concert application moving to another existing BC to get the benefits similar to upgrading can also be considered as consolidation.

4. Splitting

– forks off one or more target BCs and partition global state across them. For example, the concert application running on the public BC can declare independence by forking off its own BC and moving all its assets to the new instance. Similarly, different tenants’ states could be split into multiple BCs to scale multi-tenant BCs horizontally [24].

5. Sharding

– logically splits the source BC such that each subset of the global state is maintained only on a different set of nodes. For example, the nonprofit’s remote workers could use a shard hosted among their mobile devices while on the field. Also, a shard could be placed close to sensors in IoT applications to reduce latency.

6. Archiving

– creates a full archive of block history on the target BC. For example, the nonprofit may create an archive, as the source BC prunes old blocks to reduce storage or go out of business. Moreover, it can be used to redirect additional load on the source BC due to TX validation, auditing, data analytics, and public access TXs to a different BC instance. Also, in banking and finance industry, TX history must be typically retained for seven years [25].

Differences between the source and target BCs platforms, their existence, and mode of deployment determine what and how data can be extracted from the source and recreated on the target. Moreover, as per the third golden rule of Morris’s data migration [6] “no one needs, wants, or will pay for perfect data”. However, in the context of BC, absolute correctness of asset ownership, data provenance, and SCs are essential to gain complete trust. Also, TX history may need to retained for years [25]. Therefore, given a migration scenario, it is imperative to identify what data to migrate and what to retain on the source BC while finding the right balance among retaining trust, preserving auditability, data granularity, data utility, BC constraints, persistence, and cost and time to migrate. Thus, while moving to the target BC, the nonprofit may decide to migrate data at different levels of fidelity as follows:

Figure 1: Blockchain data fidelity levels.
1. Fresh Start

– Start a new application round/instance without migrating any BC data. For example, the nonprofit could cash out ConcertCoins and disregard BC state, SCs, and history of the source BC. Next year, it can start the concert application anew on a different BC instance.

2. State Only

– Migrate a chosen subset of states that is essential to transact during the next application round to the target BC. For example, the nonprofit could transfer next year’s seed money to the new BC instance. It may also be necessary to transfer the closing balance of each budget item when there are different commitments (in case of a loss), or when different spending rules are attached to budget items (e.g., money given by a donor).

3. State and Transactions

– Migrate both the chosen states and associated TXs. For example, in addition to recreating closing balance(s), it may be necessary to lookup past TXs on the target BC. Thus, both the states and TXs need to be migrated.

4. Genesis and Transactions

– Initial state and all subsequent TXs are migrated to the target BC to recreate state and full history. This enables the nonprofit to preserve the integrity of the data and facilitate auditing by recreating state and history on the target BC.

5. Blockchain History

– Full history of source BC (including state, TXs, SCs, and block headers) are migrated to the target BC for load shedding read-only queries, transparency, or auditing.

As shown in Figure 1, completeness of the data migrated to the target BC increases as we go down the levels. All related SCs also need to be migrated with the data chosen as per the selected fidelity level. Whereas migration of BC history include all SCs.

4 Blockchain Migration Patterns

Many contradictory constraints need to be overcome while migrating data under the above scenarios and fidelity levels. While each migration scenario is unique, we can always learn from the commonly occurring problems and recurring solutions to those. These reusable solutions can be formulated as a set of technology and implementation independent patterns. Patterns demonstrate techniques and strategies to meet the typical and specific requirements of a BC migration project while minimizing risk and cost.

We explain the patterns in the context of migration architecture illustrated in Figure 2. Similar to in database migration, we envision the migration team will utilize a tool (either developed in-house or off-the-shelf) to simplify the migration process and reduce the risk. Migration tool could follow the Extract, Transform, and Load (ETL) phases [10], [26] to recreate data on the target BC. However, these phases may be interchanged as per the chosen set of migration patterns. For example, a state could be transformed as a token on the source BC before extraction. Moreover, due to the need to preserve consistency and accountability in BC, any transformation of data must be recorded on either the source or target BC. Thus, most transformations in BC happen within a BC rather than in a separate staging area. Scattered arrows in the figure indicate this. Due to the incompatibilities between the source and target BCs’ data types, specific changes may be needed at the BAL [11].Changes may be required even for different instances of the same BC platform. For example, a TX identifier (ID) in Ethereum changes when the nonce, receiver’s account, or offered TX fee is different [12]. Therefore, BAL needs to track any changes to IDs during the migration. Such mapping is already used in BC applications, as application-level references are different from the BC IDs. For example, a username used by a Decentralized Application (DApp) needs to be mapped to the user’s public key. Therefore, the application-level reference to BC ID mapping database – typically maintained in the BAL – also needs to be updated during the migration (see IDs DB and flow of IDs in Figure 2).

Figure 2: Migration architecture.

Figure 3 shows the proposed BC migration patterns and their relationships. These patterns are derived out of our experience in multiple BC projects and related work. Patterns are grouped based on their relevance to ETL phases, SC migration, and non-functional aspects. Seven of those patterns are new (shaded in Figure 3) while the other six are adopted from database migration. We also included measure migration quality [4], off-chain data storage [21], and encrypting on-chain data [21] patterns from related work, as they are required to enhance the non-functional aspects of BC migration. For example, it is expensive and impractical to recreate a large set of TXs and block history on a target BC that is public. In such cases, the off-chain data storage pattern could be used to add a Proof of Existence (PoE) entry (by storing the TX and block history outside the BC and adding its hash to the target BC) to ensure integrity and accountability. Similarly, while migrating sensitive data to a target BC that is public, encrypting on-chain data pattern could be used to enhance data confidentiality. The measure migration quality pattern uses metrics to define success criteria as per the set application and organizational objectives. Next, we describe the patterns using the extended pattern form in [27].

Figure 3: Overview of patterns.

4.1 Pattern 1 – Snapshotting

Summary

: Get a snapshot of the global state and SCs on the source BC.

Context

: Accounts, states, and SCs used by the concert application need to be migrated to the target BC. Concert application is currently active; hence, states keep changing due to the arrival of new TXs.

Problem

: How to get a complete list of states and SCs on the source BC before migration?

Forces

:

  • Consistency – Must capture all accounts, states, and SCs on the source BC. However, BC is anonymous where it does not track ownership of accounts and states of an application.

  • Distributed – Getting a globally consistent view of a distributed system is hard. As TXs may originate from any node, it is difficult to freeze all TXs precisely at the same time.

  • Finality – A state change may not be confirmed immediately after a TX is included in a block.

  • Latency – Time to collect global state and SCs are proportional to the number of accounts, their states, and SCs.

Solution

: First, decide on block numbers (time is not a good indicator due to clock synchronization issues) to initiate the migration and to freeze all TXs. Second, inform all instances of the BAL or BC nodes when to freeze sufficiently in advance. Third, when the block number to initiate migration is reached, extract all relevant accounts and their states/SCs. If only the application-specific data is migrated, relevant accounts can be found from the IDs DB. Fourth, recreate the collected states/SCs on the target BC using related migration patterns. Fifth, when the block number to freeze TXs is reached, stop processing all TXs related to the application (or all TXs if entire BC to be migrated). Then wait till the time for finality (also specified as a block number). Sixth, go through all the blocks generated after the block number that initiated the migration while extracting the states/SCs that got updated, their accounts, and related TXs. Finally, recreate the updated states/SCs on the target BC either by initializing them or replaying new TXs. Optionally add a PoE entry to either source (if not decommissioned after migration) or target BC to indicate the block number and hash of the snapshot data using the off-chain data storage pattern.

Consequences

:

  • Consistency and integrity are preserved as all related BC activities are feezed and the snapshot is created after the time to finality.

  • As BCs are immutable, all state/SC updated after a given block number can be easily identified by traversing over the recent blocks. Therefore, TXs need to freeze while getting a snapshot of only the states/SCs that were updated after the initial migration and recreating them on the target BC. Thus, a snapshot on a BC can be made relatively faster than in a database, which needs to freeze all TXs due to the difficulty in determining data that got changed when the migration process begins.

  • Latency depends on the time to finality, as well as time to extract and recreate the state/SCs on the target BC, which is proportional to the number of states and SCs to migrate. Hence, this is more desirable when the source BC is private, or the application does not interact with any external state.

Related patterns

: State transform patterns such as state aggregation and token burning, as well as state and TX load patterns such as establish genesis, hard fork, state initialization, and exchange transfer patterns could use the snapshot to decide on what accounts and states to act on. Off-chain data storage pattern is needed to add a PoE entry of snapshot.

Known use

: Snapshotting is a commonly used while bootstrapping Bitcoin alt-coins (i.e., alternative currency on a BC platform)[28]. EOS [29] and Tron [15] alt-coins that moved away from Ethereum also used snapshots.

4.2 Pattern 2 – State Aggregation

Summary

: Aggregate a set of states into a single (or a few) state.

Context

: Concert application has a large number of accounts and states. Therefore, extracting all states from source BC and recreating them on target BC is both costly and time-consuming.

Problem

: How to extract and recreate all states more efficiently?

Forces

:

  • Size – Large number of accounts and states to be transferred.

  • Cost – Each account/state to transfer needs to pay TX or exchange fees if the BC is public. The cost could also be proportional to the size/value of the state.

  • Latency – Time to transfer accounts and their assets is proportional to the number of accounts and states.

  • Consistency – Must capture all accounts and states on the source BC. While recreating the state on target BC can happen at different fidelity levels, any transformations done to data before and after the migration must not violate any consistency property.

  • Accountability – Any data transformation to simplify migration must be recorded with proof.

Solution

: Create a new account(s) on the source BC. Then aggregate all or subset of states to that account(s), e.g., transfer all cryptocurrencies to one account. SCs may be injected to the source BC to support more complex aggregation scenarios. For example, a set of binary states can be concatenated as a bitmap represented using one or more states. In a more general case n set of sates could be aggregated to m set of states (), e.g., closing account balance vs. closing balances of each budget item. The list of accounts to be aggregated can be determined from the IDs DB.

Unless the application can work with the aggregated state(s) on the target BC (e.g., closing balance), the state needs to be disaggregated to match the states that were in the source BC. This could be achieved by running relevant inverse functions and SCs, e.g., splitting assets to multiple accounts as per the state recorded in the snapshot.

Consequences

:

  • The number of accounts, their states to extract and recreate, data size, and latency to migrate are reduced. This pattern works only for states that can be reduced to a single or a few values.

  • Consensus and the ability to record aggregation/disaggregation operations within the BC provide greater consistency and accountability in BCs compared to database migration.

  • The cost could be reduced as TXs required for aggregation and disaggregation within the same BC is typically lower than exchange fees or inter-BC TXs. However, this depends on the internal and external TX fees, as well as the complexity and number of TXs required for aggregation and disaggregation.

  • Aggregation could also be performed after extracting state from the source BC depending on TX fees, BC performance, and complexity of aggregation/disaggregation functions. Loss of accountability due to such external transformations can be overcome by adding a PoE entry of snapshots and the list of aggregations to either of the BCs.

Related patterns

: Aggregation can be performed before/after snapshotting and before token burning. Relevant state and TX load patterns could rely on aggregation to reduce the number of accounts and states to recreate. Off-chain data storage pattern is needed to add a PoE entry if aggregation happens outside the source BC.

Known use

: Transferring only the closing balances from one application round to another. In Bitcoin, multiple UTXOs can be given as input to produce a single UTXO send either to itself or another account while reducing TX fees [30]. Used in Ethereum DOA fork to aggregate blocked funds and transfer them back to users [31].

4.3 Pattern 3 – Token Burning

Summary

: Make state on the source BC unusable before the migration.

Context

: Because the source BC used by the nonprofit is public, it is not decommissioned after the migration. Therefore, any state left in the source BC could be misused (e.g., double spending).

Problem

: How to guarantee that migration does not lead to potential misuse of states or SCs?

Forces

:

  • Immutability – Accounts, their states, and SCs cannot be deleted as BC is immutable.

  • Consistency – If the source BC is not decommissioned, states and SCs could be used in both the BCs leading to misuse such as double-spending attacks [32]. Any transformation of data to prevent misuse must not violate consistency properties.

  • Accountability – Any data transformation to prevent misuse must be recorded with proof.

Solution

: Make the states and SCs on the source BC unusable. Transfer states such as cryptocurrency, tokens, and titles to a designated or un-usable account. Also, set states to a terminating state. Delete tokens using the SCs that created them. Similarly, SCs can call the self-destruct function or initiate a series of TXs that lead to a terminating state. Such attempts to make a state unusable is referred to as token burning.

Consequences

:

  • Consistency, accountability, and immutability are preserved as all state changes are done within the source BC. When recreating states on the target BC, proof of burn [33] on the source BC can be verified.

  • The same can be done for SCs if their state were stored separately [21] or they could self destruct. Else, it should be possible to generate a specific TX sequence that sets the SC’s state to a terminating state.

  • Fees apply to TXs that make state and SCs unusable.

Related patterns

: Snapshotting and state aggregation patterns could be used before token burning. State and TX load patterns can verify burned state before initializing a new state.

Known use

: Binance [13], Kin [14], Qubicle [16], and Safex [17] used token burning while migrating from Ethereum or Bitcoin to their own chains. It is also used while bootstrapping alt-coins in Bitcoin [33]. EOS inter-BC communication also uses token burning [19].

4.4 Pattern 4 – Mapping Table

Summary

: Replace account, TX, and SC IDs to match the corresponding entries in the target BC.

Context

: Concert application uses a database to map human-readable references to BC specific account, TX, and SC IDs. However, it is difficult to recreate the same IDs on the target BC.

Problem

: How can the application continue to access migrated accounts, TXs, and SCs?

Forces

:

  • Platform dependence – Account, TX, and SC IDs tend to be BC platform specific, and depend on the time (or block number) and order that they were initiated.

  • Accountability – Any changes to application reference to BC ID mapping must be recorded with proof.

Solution

: Collect new IDs while creating new accounts, replaying TXs, and redeploying SCs on the target BC. Then update the corresponding entries in the IDs DB. Optionally add a PoE entry to either source or target BC (one with better immutability and security), using off-chain data storage pattern, to record how the IDs DB was updated.

Consequences

:

  • TX IDs database in the BAL needs to be updated. If the application was not designed to handle any ID mapping application-level changes may be needed.

  • When IDs change immutability is lost. However, both integrity and accountability can be preserved by storing the mapping table in BC as a PoE entry. While mapping tables are typically pre-created in database migration [26], they need to be dynamic in BC migration, as IDs are assigned while recreating states, TXs, and SCs.

  • If the state aggregation pattern is used, mapping can be done only after the disaggregation.

Related patterns

: Mapping is needed if the state and TX load patterns result in updating IDs. Off-chain data storage pattern is needed to add a PoE entry for updated IDs DB.

Known use

: Mapping is needed when the length of account IDs and public keys are different across platforms, e.g., while Hyperledg keys are 256-bit, Ethereum calculates Keccak256 hash of a 512-bit public key and then use only the rightmost 160-bits as address [12].

4.5 Pattern 5 – Node Sync

Summary

: Creates a clone of a BC node.

Context

: The nonprofit wants to add new nodes or swap nodes to change physical location, improve performance, or create multiple instances of the source BC.

Problem

: How to clone a BC?

Forces

:

  • Size – A BC may contain a large number of accounts, states, and SCs. Moreover, history may consist of a large number of blocks amounting to hundreds of GBs or more.

  • Latency – Given the large size of the global state and history, time to make a copy could be very long. Moreover, applying all TXs and running SCs to recreate and confirm global state take time.

  • Consistency – It is difficult to create a complete copy of a BC node, as the system is distributed, new blocks are being built continuously, time to finality, and propagation delays.

Solution

: Install the same BC platform (or an updated version that is backward compatible) on a new node. Then initiate the new node by adding other members of the source BC platform. Allow the platform-specific sync tool to synchronize both the global state and block data structure with other BC nodes. After synchronization, the node may also apply all the TXs from the genesis to rebuild the global state and verify its correctness. Once the node is successfully verified, configure the node to accept new TXs. If the objective is to swap nodes, decommission source BC. Whereas if the objective is to create multiple BC instances, reconfigure the new node(s) to behave as an independent BC.

Consequences

:

  • No state, history, and IDs are lost or changed in the process ensuring immutability and consistency.

  • Time to synchronize a large volume of state and history could vary from hours to days. It depends on bandwidth, IO, and CPU limitations, as well as ongoing transactions on the source BC. Time can be substantially reduced by synchronizing only the ledger state data structure (i.e., state only data fidelity level).

  • Compared to cloning databases which require some form of freezing to ensure consistency, BC sync tools rely on asynchronous messaging, immutability to identify states/SCs updated after a given block number, and consensus to provide consistency.

  • Works only when the source and target BCs are compatible and target node(s) is new.

Related patterns

: Used in sharding pattern to clone either the entire BC (prior to sharding) or clone only the shard (after sharding) to new nodes.

Known use

: Ethereum supports different node options such as full node and archival nodes, as well as download options such as full, fast, and light [34]. Similarly, Bitcoin supports full node and thin clients [33].

4.6 Pattern 6 – Establish Genesis

Summary

: Set the genesis block of the target BC.

Context

: Concert application has a large number of accounts and states all of which need to be recreated on the target BC. The nonprofit has decided to spin up a new BC instance as the target and use ConcertCoin as the native asset.

Problem

: How to load state to the target BC?

Forces

:

  • Size – A large number of accounts and their states to be initiated on the target BC.

  • Cost – Each account creation and state assignment needs to pay a TX fee. The cost could also be proportional to the size/value of state.

  • Latency – Time to create accounts and initialize their states is proportional to the number of accounts and states.

  • Consistency – States such as BC native assets cannot be arbitrarily created and have to be transferred from one account to another, i.e., migration must preserve system invariants.

  • Accountability – Creations of new accounts and initiation of state on the target BC must be recorded with proof.

Solution

: Save the list of accounts and states to migrate as a genesis state file. Then use the file to build the genesis/first block of the target BC.

Consequences

:

  • This pattern works with any new instance of a BC and any state including BC native assets.

  • Migration can be performed fast with no cost.

  • If new states do not fit to a single block, aggregation pattern can be used to reduce genesis state.

  • Accountability is preserved when combined with snapshotting (with PoE) or token burning patterns.

  • If the source and target IDs are different mapping table pattern is needed to update IDs DB.

Related patterns

: State extract and transform patterns could be used to identify and reduce the state to include in the genesis block. The mapping table pattern is needed when the source and target IDs are different.

Known use

: Genesis block is used to specify the initial distribution of native assets in the BC. Also, used in Binance Chain migration [13].

4.7 Pattern 7 – Hard Fork

Summary

: Change the global state of the target BC.

Context

: Concert application has a large number of accounts and states all of which need to be recreated on the target BC. The nonprofit has chosen an existing private or consortium BC as the target.

Problem

: Same as pattern six.

Forces

: Same as pattern six.

Solution

: First, save the list of accounts and states to migrate as a state file. Second, notify the BC software on all nodes to include the state file at a set block number. Once the specified block number is reached, append the new states into the ledger. Due to the arbitrary addition of new states blocks produced before and after the software update are incompatible. Such a change in BC state transition rules is referred to as a hard fork [31].

Consequences

:

  • Can be used with any existing BC where users’ consensus can be reached to initiate a hard fork [31], e.g., private and consortium BCs.

  • Source and target BCs do not need to be compatible. Also, works with any state and no TX fees are involved.

  • Accountability is preserved when combined with snapshotting (with PoE) or token burning patterns.

  • If the new states do not fit a single block, aggregation pattern can be used to reduce the state size.

  • Any node that misses the update will no longer be part of the same BC.

  • If the source and target IDs are different mapping table pattern is needed to update IDs DB.

Related patterns

: Same as pattern six.

Known use

: Ethereum used a hard fork to recover cryptocurrency lost due to the DOA attack [31]. This also resulted in splitting Ethereum into Ethereum and Ethereum Classic BCs.

4.8 Pattern 8 – State Initialization

Summary

: Initialize/recreate state on the target BC.

Context

: Concert application has a large number of accounts and states all of which need to be recreated on the target BC. The nonprofit has chosen an existing public BC as the target.

Problem

: Same as pattern six.

Forces

: Same as pattern six.

Solution

: Create a new account on the target BC for each account to be migrated from the source BC. If state aggregation pattern is used and accounts do not need to be disaggregated on target BC, use aggregated results to determine the accounts to create. Then, based on the original or aggregated state generate a set of TXs to set the state of each new account.

Consequences

:

  • This pattern works with any target BC regardless of its compatibility with the source BC or existence.

  • Accountability and consistency are preserved when combined with snapshotting or token burning patterns.

  • The pattern works only for states that can be arbitrarily created, e.g., tokens generated by SCs. Whereas states such as BC native assets cannot be initiated this way.

  • If the account state is large, a large set of TXs is needed to create accounts and set their initial state increasing the cost and latency.

Related patterns

: Same as pattern six.

Known use

: Digital tokens and account funding in BC use this approach. Also used in Kin [14], Qubicles [16], and Safex [17] migration.

4.9 Pattern 9 – Exchange Transfer

Summary

: Transfer state via an exchange.

Context

: Concert application has a large number of accounts and states all of which need to be recreated on the target BC. The nonprofit has chosen an existing public BC as the target and ConcertCoins are to be converted to its native assets.

Problem

: Same as pattern six.

Forces

: Same as pattern six.

Solution

: First, register both source and target BCs with a cryptocurrency/token exchange. Second, if the exchange does not support a particular state, tokenize the state to a format supported by the exchange, e.g., ERC 20 token in Ethereum. Third, transfer state/tokens to the exchange’s account on source BC. Fourth, create relevant accounts on the target BC. Finally, on the target BC, get the exchange to disperse the state/tokens to new accounts from its own account.

Consequences

:

  • This pattern works with both BC native assets and tokens on any BC platform given that both BCs are listed on the chosen exchange(s).

  • Because the state is transferred from the exchange’s account and all TXs are recorded in the BC better consistency and accountability can be achieved.

  • Both individual and bulk transfers of accounts are possible. Cost and latency are proportional to the number of accounts and size of their state to transfer.

  • Exchanges charge TX fees and apply varying state/asset conversion rates leading to loss of some states during the transfer.

Related patterns

: Same as pattern six.

Known use

: Interledger transfers tokens across multiple BCs using a distributed set of exchanges connected via a common protocol [35]. Tron [29] and VeChain [36] used exchanges during their migration from Ethereum.

4.10 Pattern 10 – Transaction Replay

Summary

: Replay TXs on the target BC to recreate both state and history.

Context

: Concert application has a large number of accounts, states, TXs, and SCs. All of which need to be recreated on the target BC while preserving the history of state changes. The initial state is already recreated on the target BC.

Problem

: How to recreate both the state and history on the target BC?

Forces

:

  • Size – Large number of TXs need to be executed on the target BC.

  • Cost – Fees need to be paid for each TX if the target is a public BC. The cost could also be proportional to the size/value of states and complexity of SCs executed.

  • Latency – Time to execute TXs is proportional to the number of TXs and complexity of SCs.

  • Consistency – Order of TXs replayed on the target BC must be same as the source BC. Moreover, the application may have sent/received TXs to/from accounts that are external to the application, e.g., BC users buying concert tickets.

Solution

: Using the IDs DB first identify the list of accounts, SCs, and all TXs related to those. Second, group related TXs together. Third, concurrently replay each independent group of TXs while sequentially replaying TXs within a group to preserve interdependences. If a TX fails, retry until success before playing the next sequential TX. Next dependent TX can be replayed only when the finality of the previous TX is confirmed. If abstraction is acceptable, also aggregate TXs. For example, e.g., payments from and can be abstracted as . If TXs are aggregated details need to be also added to BC either as TX log-data or PoE entry.

Consequences

:

  • This pattern works with any target BC regardless of whether it is new, pre-exists, or compatible.

  • Latency depends on the target BC’s throughput, time to finality, and concurrent transaction limit, as well as interdependencies among TXs.

  • Could be cost prohibitive on a public BC as fees are proportional to the number of TXs and data size. The cost could be reduced by aggregating TXs.

  • When the signature format of the two BC instances are different TXs need to be re-signed prior to replaying on the target BC.

Related patterns

: State load and SC patterns need to be used prior to TX replay to recreate accounts, states, and SCs on the target BC. The mapping table pattern is needed when the source and target IDs are different.

Known use

: After Bitcoin and Ethereum hard forks that spit each platform into two instances, TX replay has been used as an attack to double spend and change the state on both BC instances [32] (which can be prevented by token burning).

4.11 Pattern 11 – Sharding

Summary

: Logically partition the source BC.

Context

: The nonprofit plans to extend the application to include field staff who have intermittent connectivity while on the field. The chosen target BC supports shading.

Problem

: How to partition a set of states without losing BC properties?

Forces

:

  • Security – Any partitioning of state should not lead to potential misuse or inconsistencies. If the number of BC nodes is split across shards, security of the BC reduces as the number of nodes involved in consensus is small [37].

  • Availability – It should be possible to send and receive TXs from any account and SC.

  • Performance – Given an address of a state, it takes time to identify the shard holding that state. This reduces throughput and increases latency.

Solution

: Form groups of nodes such that each group has approximately the same number of nodes. Then configure each set as a shard and assign a subset of the global state based on the chosen sharding policy. A soft fork is typically required at a set block number to initiate these changes.

Consequences

:

  • Different shading policies lead to different properties and performance [37]. For example, account ID based shading makes it easier to find the relevant shard; shading based on the frequency of TXs among accounts enhances throughput and reduces latency; and nodes’ location-based shading reduces latency. Also, overall performance is determined by inter-shard consensus protocol. While sharding in databases results in separate database instances sharding in BCs happens within the same BC instance.

  • By adding more nodes per shard security can be enhanced [37].

  • Cloning new nodes take hours to days. If the target BC is new, sharding can be used only after recreating accounts, state, and SCs on the target BC.

Related patterns

: State load patterns are needed to initiate state and SCs on new nodes before sharding is activated.

Known use

: Zilliqa [38], R3 Corda [39], and Ethereum 2.0 [37] use sharding.

4.12 Pattern 12 – Virtual Machine Emulation

Summary

: Allow SC written in one language to run on another BC platform.

Context

: Concert application uses a set of SCs and associated states which need to be usable on the target BC. The target BC platform could run/emulate the Virtual Machine (VM) or container used to execute SCs.

Problem

: How to run a SC written for one BC platform on another?

Forces

:

  • Correctness – It is difficult to guarantee that the rewritten SC behaves exactly like the original SC.

  • Fidelity – Not all SC languages are Turing complete. Thus, it may not be possible to recreate the same behavior using a different SC language.

  • Time and cost – It is time-consuming hence costly to rewrite and test SCs.

Solution

: If the target BC allows importing a VM/container, copy the entire VM/container into the target BC. Instead, if its own VM/container is provided that supports source BC’s SC language, extract and copy the required SC’s binary code. If the SC’s state is handled separately from the contract itself, use a suitable state load pattern to recreate the state on the target BC.

Consequences

:

  • Execution behavior of the original SC is preserved. Consistency can be improved by verifying SCs on the source BC before migration.

  • Saves time and introduce no cost as no code reverse engineering, translation, and testing are needed.

  • Works only when the target BC platform can emulate VM/container of the source BC.

Related patterns

: When emulation is not possible use SC translation pattern.

Known use

: Ethereum VM (EVM) bytecode can run on Hyperledger [40]. Deloitte moving SCs from Ethereum to VeChain is another example [41].

4.13 Pattern 13 – Smart Contract Translation

Summary

: Translate SC code from one language to another.

Context

: Concert application uses a set of SCs and associated states which need to be usable on the target BC. SC language of the target BC is not interoperable.

Problem

: Same as pattern 12.

Forces

: Same as pattern 12.

Solution

: First, verify that each SC on the source BC is produced by the respective source code. If SC language is a compiled one, re-compile the source code and verify whether it produces the same binary code stored on the source BC. If source code is not available, reverse engineer the SC code. Second, translate the source code (e.g., using a tool or manually). Third, deploy the new SC on the target BC. If the SC’s state is handled separately from the contract itself, use a suitable state load pattern to recreate the state on the target BC. Optionally add original, translated, and binary codes to BC to establish PoE.

Consequences

:

  • The solution works for any BC platform that has a SC language rich enough to recreate the same behavior.

  • Time and cost can be reduced via automated translation.

  • It is difficult to guarantee that the translated SC exhibits the same behavior. Correctness and consistency can be improved by verifying the source code before translation.

  • Having access to the original source code or ability to reverse engineer binary code is essential.

Related patterns

: VM emulation pattern is preferred when applicable. PoE entry of SC code can be added using the off-chain data storage pattern.

Known use

: Tools are available to translate among SC language, e.g., Ethereum Solidity to Hyperledger Javascript translation tool is presented in [42]. Counterparty enables running Ethereum SCs on Bitcoin by modifying the Solidity code [43].

5 Mapping Patterns to Migration Scenarios

Table 1 shows how the proposed patterns map to the above migration scenarios. Given the six migration scenarios, five data fidelity levels, and 16 patterns, the potential solution space is large. Therefore, we present a selected set of use cases from the illustrative example that combines a mix of migration scenarios, data fidelity levels, and BC platforms and hosting modes. We then discuss how a migration plan for a specific situation could be achieved using a selected set of patterns.

[47mm]PatternScenario

Transferring

Upgrading

Consolidating

Splitting

Sharding

Archiving

Snapshotting
State Aggregation
Token Burning
Mapping Table
Node Sync ? ? ?
Establish Genesis ? ? ? ?
Hard Fork ? ?
State Initialization
Exchange Transfer
Transaction Replay ?
Sharding
Virtual Machine Emulation ? ?
Smart Contract Translation
Measure Migration Quality
Off-Chain Data Storage
Encrypting On-Chain Data
Legend: Applicable (✓), Maybe applicable (?), Not applicable (–)
Table 1: Pattern to migration scenario mapping.

Suppose the nonprofit decided to spin up a private BC instance of the same BC platform and migrate its own data. This is an example of the splitting scenarios which can be achieved by spinning up a new BC instance and recreating data using most of the migration patterns. State extract and transform patterns, as well as state initialization and establish genesis patterns can be used to accurately determine, efficiently recreate, and consistently transfer state to the new BC instance. TX replay pattern can be used to establish history. Hard fork, VM emulation, and SC translation patterns are not needed as the target BC is new and compatible. Sharding does not apply as there are two different BC instances. As the BC instance is private, the exchange-transfer pattern is not desirable due to the cost of using a public exchange. However, the migration tool may act as a private exchange and simulate the state/token transfer between the two BCs using a common protocol [35]. Similarly, encrypting on-chain data pattern is not essential as the target BC is private. Node sync could also be used where the new nodes can be reconfigured to act as a different BC instance after cloning. However, if the private BC instance is to be setup using a BaaS, node sync and establish genesis patterns may not work as the third-party managing BaaS may not provide node-level access limiting finer control on BC software, data, storage, and inter-node communication. Therefore, these patterns are marked as may be applicable.

Alternatively, suppose the nonprofit decided to move to a private and incompatible BC instance to get better performance and features. In this case, both upgrading and splitting scenarios apply together, as only the application-related data are moved to an incompatible BC platform. Therefore, the applicable patterns depend on the constraints of each scenario. For example, the node sync pattern does not apply as the target BC is incompatible, whereas hard fork pattern is not needed as the instance is new. Applicability of the establish genesis pattern depends on whether the target instance is a BaaS solution or not. The VM emulation pattern is preferred when it is supported by the target BC. Else, the only way to guarantee that SCs can run on the target BC is to use SC translation pattern with either tool-based or manual translation.

In another scenario, suppose the nonprofit decided to use an existing but incompatible public BC as the target. In this case, both consolidating and splitting scenarios apply together. Node sync, establish genesis, and hard fork patterns do not apply, as the target BC platform is incompatible, already established, and public. While the SC translation pattern is still applicable, the applicability of VM emulation pattern depends on the target BC platform. Different data fidelity levels could be used under upgrading, consolidating, and splitting scenarios. Therefore, the measure migration quality pattern should be used in all three scenarios to ensure that the desired subset of data was migrated as per the BC constraints, as well as application and organizational objectives. For example, the nonprofit may choose to manage next year’s concert budget using fresh start, state only, or genesis and TXs data fidelity levels. Moreover, off-chain data storage and encrypting on-chain data patterns could be used to enhance the transparency and privacy, respectively.

Sharding scenario applies when the nonprofit’s remote workers are given access to a subset of BC data on their mobile devices. The accounts and SCs that they frequently interact while on the field can be moved to a shard hosted using the mobile devices. This can be achieved using the sharding pattern. Prior to sharding, new nodes (including mobile devices) need to be added to the BC to enhance security [37]. Therefore, the node sync pattern can be used to clone such nodes. Transferring scenario can be achieved by installing the same BC platform and then cloning a set of new nodes (either on-premise or on the cloud) with the source BC using the node sync pattern. Finally, these nodes can be reconfigured to run as a separate BC instance. However, if the target is a BaaS instance or the platform-specific sync tool does not work on the chosen hardware, snapshotting, mapping table, state initialization, hard fork, and TX replay patterns can be used to recreate states on new nodes. Applicability of the establish genesis pattern depends on the chosen BaaS solution. Non-functional patterns also apply depending on the chosen data fidelity level, cost, and privacy goals. While these use cases consider migrating only the concert application’s BC data (example assumes source BC is public), proposed patterns could be used to migrate an entire BC.

6 Discussion

Next, we briefly discuss practical considerations and research challenges in BC migration. Migration is relatively straightforward when the target BC is a new instance, as it provides greater flexibility in synchronizing or recreating data using node sync, establish genesis, and hard fork patterns. Whereas preexisting BCs, especially the public ones, require extensive efforts to recreate state and replay TXs using snapshotting, token burning, state initialization, exchange transfer, and TX replay patterns. Such efforts take time and introduce additional fees to aggregate states, burn tokens, exchange tokens, and replay TXs. Thus, to compensate for any loss of assets/states during the migration [17], accounts need to be funded with sufficient assets before/after the migration [44]. Due to the differences in key lengths and TX formats, as well as lack of access to private keys and state of external accounts, it is problematic to replay signed TXs. When accounts are pre-created on the target BC TXs could be signed again using the new private keys before replaying. However, this breaks accountability unless at least mapping between the old and new public keys are not tracked as PoE entries. Still, assigning BC native assets to emulate external accounts on a public BC is a problem because both their private keys and assets are inaccessible.

Time and cost of migration can be reduced using the state aggregation and TX replay patterns depending on the chosen data fidelity level. Therefore, while moving into an existing BC it is desirable to choose the level of data fidelity that is sufficient to continue the application. Source BC can continue to provide access to historic data if not decommissioned. Otherwise, TXs and block data can be added to the target BC as a set of PoE entries using the off-chain data storage pattern while substantially reducing the cost and time to migrate. Due to the Nakamoto consensus [1], preference to include high fee paying TXs in a block, and network dynamics, recreating the same state by replaying a large sequence of TXs is difficult. Therefore, risk of migration failure increases with the increasing number of TXs and their interdependencies. Moreover, if the migration fails abruptly, it is next to impossible to rollback on a public BC. While trial migration on a test BC instance of the same BC platform is essential to reduce risk, final migration has to be one shot [10]. Thus, aggregation and the choice of appropriate data fidelity level are also essential to mitigate migration failure due to the large volume of states and TXs to recreate. The risk could be further reduced by migrating one state/SC at a time, which fits well with patterns like exchange transfer [17]. Also, by not replaying TXs we can overcome issues related to signed TXs and external accounts. In conclusion, while the global state can be recreated on any target BC with reasonable effort and time, it is desirable not to recreate full history unless otherwise absolutely necessary.

Translating and testing SCs are not only time and cost prohibitive (even with automated translation) but also provide no guarantees on the exact behavior. While many high-level SC languages are still being proposed, they seem to be opting to a few instruction set architectures [20], [36], [45]. Therefore, reuse of SCs at the VM emulation and bytecode level is preferred, as it could guarantee exact behavior at a much lower cost. To apply the token-burning pattern for SCs, it is essential that SCs store state separately or implement a self-destruct function before being deployed on the source BC. Similarly, having an IDs DB is essential to handle the change of IDs during the migration. Else, the migration will require significant changes to the BAL or even the application. Further, the use of states that can be aggregated and tokenized is useful. Therefore, proactive system design, data management, and use of best practices are essential to simplify future migration scenarios of EIS and BPMSs.

7 Summary

While BCs are designed to be immutable, many technical, economic, and regulatory-level changes will make it essential for an application to migrate from one BC instance to another. In this paper, we outlined the need for BC migration in EISs and BPMSs. We introduced seven new patterns and nine others adapted from the literature to address six migration scenarios and BC-specific data management challenges. We further identified five data fidelity levels to balance competing factors such as application’s minimum requirements, performance, cost, time, effort, security, and privacy reduce the costs and risks of BC migration. While BC migration is expected to be difficult and costly, we show that most migration scenarios can be achieved within a reasonable time and cost by choosing a data fidelity level that satisfies application’s minimum requirements. Identifying the best data fidelity level for a given application scenario, handling signed TXs with external accounts, confirming the correctness of translated SCs, best practices to simplify future migration, handling user permissions, and preserving data provenance are some of the challenges worth further research.

References