feat: add blockchain migration feature

[RafaelAPB]

This is work in progress - feedback is welcome

This pull request introduces the blockchain migration feature, which is highly dependent on how the consortium management is implemented. The approveMigration method will allow a stakeholder to agree on the migration, via the consortium maangement plugin.

Regarding the test, currently, it initializes a Besu blockchain migrator plugin. The idea is to submit transactions through Besu, capture the data they generate, and issue transactions against a target ledger (e.g., Quorum or Fabric). Finally, it should assert if the data migrated can be found at the target ledger.

How to test this feature (similar instructions to PR #123):
-checkout this branch
-cd to the project root
-npm run configure -
-run the test at packages/cactus-plugin-blockchain-migrator-besu/src/test/typescript/integration/plugin-ledger-blockchain-migrator-besu/data-migration/migrate-data-to-quorum.ts

[petermetz]

@RafaelAPB set it as a 'draft' PR in line with it being WIP still. If you open a non-draft PR that should in general mean that it's ready for the maintainers to invest the time to review it from top to bottom. Not a big issue at all, just wanted to clarify. :-)

[petermetz]

@RafaelAPB Tried to give this a spin, but it won't build, see errors below:

@hyperledger/cactus-plugin-blockchain-migrator-besu: packages/cactus-plugin-blockchain-migrator-besu/src/main/typescript/plugin-ledger-blockchain-migrator-besu.ts:92:39
@hyperledger/cactus-plugin-blockchain-migrator-besu: ERROR: 92:39  no-shadowed-variable  Shadowed name: 'migrationDepth'
@hyperledger/cactus-plugin-blockchain-migrator-besu: ERROR: 93:39  no-shadowed-variable  Shadowed name: 'migrationType'

[kikoncuo]

This should only work natively and without resigning transactions for blockchains which have the same transaction arquitecture.
(Quorum, Besu, Geth, OpenEthereum, Nethermint and other open implementations based on the EVM)

• We can do this resending the raw transactions
  That said, the networks may have to be configured in a specific way.
  The chainID should be the same in all the configured networks which is not usually done.
  This could potentially open users to replay attacks across different networks.

• Asking all users to re-sign their transactions (I believe this is the way proposed in the PR)
  It's the safest approach (Users can 100% guarantee that only the data they signed may be on chain)
  The challenge is that we would require all transactions to be broadcast in the same original order which means that all parties have to agree
  Some functions such as timestamped based operations may not work

There might be a better approach migrating the contract and manually pushing a checkpoint data and pausing/destroying the original contract. This would be faster but some extra work to build agreement of the state between the involved parties would need to be enforced. IE: requiring consensus on the validity of the migrated data by 2/3rds of the involved parties.

[RafaelAPB]

@kikoncuo thank you for the suggestions. That's an interesting path :) We can discuss further on the meetings

[kikoncuo]

Is this PR linked to an issue? if so, can you ping it on the main comment so we can track it better? (IE: Resolves #issueNumber)

[RafaelAPB]

@kikoncuo No, I don't think there's an issue on this.

[petermetz]

@RafaelAPB Are you still working on this one?

[RafaelAPB]

@petermetz yes - sorry for the infinite delay, but still working on the paper/feature :)

[petermetz]

@RafaelAPB No worries, I'm just taking a pass on all the PRs to make sure we don't have dead ones hanging around. If you are still working on it it's cool to keep it open IMO.