State Aggregation

Disclaimer: This is a summary of patterns we have observed during our research and should not be considered any form of technical or investment advice. Also, the given “known examples” do not imply they are the best implementations of the said pattern or any superior to any other implementation of the pattern not listed.

Summary

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

Context

Application has a large number of accounts and states. Extracting all states from the source blockchain and recreating them on the target blockchain is both costly and time-consuming. The list of states to be migrated is given in the snapshot or application-level reference to blockchain identifier mapping database.

Problem

How to extract and recreate a large number of states while minimizing the time and cost

Forces

• Size – A large number of accounts and their states to be migrated to the target blockchain.
• Latency – Time to extract and recreate the states is proportional to the number of accounts and their states.
• Cost – On a public blockchain, each state transfer/update needs to pay a transaction or exchange fee. The fee could also be proportional to the size of the state.
• Consistency – Must capture all accounts and states on the source blockchain. Any transformation of data before/after the migration must not violate consistency property.
• Accountability – Any data transformed to simplify the migration must be recorded with proof.

Solution

Transfer all cryptocurrency/tokens to a single account, such that only the closing balance needs to be migrated. The following figure shows the sequence of activities required to perform such an aggregation of state. To aggregate blockchain native assets, first, create a new account on the source blockchain. To aggregate states embedded in smart contracts, deploy a new Smart Contract (SC). Both cases will produce a new address (aggregateAddress). Then get the users’ consent to transfer their states by signing a transaction with the current state as payload and aggregateAddress as the recipient. Next, submit the signed transaction to the source blockchain. Finally, trigger the aggregate function at the aggregateAddress.

The summation of native assets will be atomically performed once a transaction is executed. Hence, native asserts do not need a separate aggregate function. Smart contracts could be used to perform more generic aggregation scenarios. For example, a smart contract can aggregate fungible tokens, similar to native assets. Non-fungible tokens that could be mapped to a set of binary states can be concatenated to a bitmap represented as a single state. In a more general case, n set of states could be aggregated to m set of states (m << n), e.g., closing account balance vs. closing balances of each budget item. Once the aggregate function is called, it must lock the account or smart contract using the token burning pattern to prevent further aggregations.

When a user holds the private key, he/she needs to sign the transfer transaction via the application or wallet software. It is pragmatic for the migration tool to submit transactions to the blockchain on behalf of the users, as it can track the transactions and trigger the aggregate function as soon as all the transactions are included. In practice, this is achieved by integrating the Blockchain Access/API Layer (BAL) or user wallet with the migration tool. Either the application-level reference to blockchain identifier mapping database (i.e., ID database) or snapshot can be used to find the list of accounts and their states to be aggregated.

Unless the application can work with the aggregated state(s) on the target blockchain (e.g., closing balance), the state needs to be disaggregated to match the states that were on the source blockchain. Disaggregation could be achieved by running relevant inverse functions and smart contracts on the target blockchain, e.g., cryptocurrency/tokens can be split into multiple accounts as per the state recorded in the snapshot. Aggregation or disaggregation could also be performed after extracting states from the source blockchain depending on the transaction fees, performance, and complexity of functions. Loss of accountability due to such external transformations can be overcome by adding the list of aggregations as a Proof of Exist (PoE) entry to the blockchain.

Transaction fees need to be paid in public blockchains to transfer states and run the aggregate function. While public blockchain users typically bear this cost, sometimes they are reimbursed while recreating the state on the target blockchain. Alternatively, the migration tool could top-up/reimburse user accounts before/after the state transfer as in NEO.

Benefits

• Size and Latency – The number of accounts, their states, data size, and latency to extract and recreate are reduced.
• Consistency and Accountability – Consensus and the ability to record aggregation/disaggregation operations within the blockchain provide greater consistency and accountability compared to database migration.

Drawbacks

• Cost – In public blockchains, the cost could be reduced as transactions required for aggregation within the same blockchain is typically lower than the exchange fees or inter-blockchain transactions. However, the cost depends on the internal and external transaction fees, as well as the complexity and number of transactions and smart contracts required for aggregation/disaggregation. Transaction fees need to be either paid separately or could be deducted from the native assets being aggregated.
• Aggregatable – While this pattern works on any blockchain, it works only on states that could be reduced to a single or a few values.

Related patterns

1. Aggregation can be performed before or after snapshotting and before token burning. Moreover, the set of states to be aggregated can be found using the snapshotting pattern.
2. Exchange transfer, establish genesis, and state initialisation patterns could rely on this pattern to reduce the number of accounts and states to recreate.
3. The blockchain anchor is needed to add a PoE entry when the aggregation is performed outside the source blockchain.

Known uses

• Aggregation is used while bootstrapping a token on the target blockchain. For example, Storj and Binance used the aggregated token balance from their source blockchains to set the initial balance of ERC-20 and BEP-2 token contracts, respectively.
• This pattern was also used in Ethereum DAO hard fork to aggregate blocked funds and transfer them back to the users.
• When the Bitcoin network is less congested, multiple UTXOs can be aggregated to produce a single UTXO by paying a small transaction fee. The resulting UTXO can be later spent during times of high network congestion while paying lower traction fee, as the overall transaction size is reduced.