Condor rc3 #142
Condor rc3 #142
Conversation
* Update to recent (post 1.69) nightly * Build without LLVM sign extensions * Satisfy clippy
* Update to recent (post 1.69) nightly * Build without LLVM sign extensions * Satisfy clippy
* native eventing * change_event_mode * native eventing done
…ondor-rc3 # Conflicts: # cep18/src/main.rs # cep18/src/modalities.rs # tests/src/migration.rs
…dor-rc3 # Conflicts: # tests/src/utility/installer_request_builders.rs
…age, should have been this way to begin with
|
The current approach relies on a user-provided key map, which introduces the risk of errors and could be cumbersome for larger migrations. Also, it doesn't account for potential "race" if the contract is used post condor and before/while the migration process. I'd like to propose an alternative "on-demand" migration. This approach would:
This eliminates the need for a manual key map and reduces the risk of errors. While it might add some complexity, I believe it offers a more robust and scalable solution. I'm happy to discuss it and see your point of view. @deuszex @gRoussac |
|
@sczembor That is the so collad "lazy migration" that we have discussed already on our meetings on which you are also present, and as I've said on the mentioned meetings, these decision will go through the proper chain of command, when the relevant personnel are available. |
|
Closing in favour of another PR |
2.0.0-rc3 compatible.
Migration entrypoints for balance and allowance keys to move from old Key formats to new ones (AddressableEntity).
Events:
EventsMode::CES events included (forked original to update to rc3).
EventsMode::Native events included (Casper Native events).
EventsMode::NativeNCES (uses both Native and CES eventing).
Compiles on latest rust.
Added 1.5.6 fixture(state snapshot) to test migration from 1.5.6 to 2.0.0-rc3.
TODO: Fixture guide/tutorial.
Added entrypoint:
migrate_user_allowance_keys:migrate_user_balance_keysmigrate_user_sec_keysThe above entrypoints change the stored keys from the old style (Key::Hash/Key::Account) to the new one (Key::AddressableEntity) which will be used in the contract going forward. The entrypoints also take
eventsandrevertboolean arguments. Supplyingfalseto theeventsargument turns the eventing off during the current calling of the entrypoint, since the size of the events can be rather large depending on number of arguments provided. Supplyingtrueas therevertargument on the other hand will cause the call to immediately revert upon meeting an error, which may help in determining the point of failure if encountered one.change_events_mode(needs testing): to change the events mode without needing to upgrade the whole contract.