[PoC] Using a different approach for storying operations in an OperationsRegistry which saves gas

[peculiarity]

The idea is to experiment with a different approach to verify our operations ( actions execution ).
There is the file test/tmp/OpenWithoutOperationRegistry.test.ts which contains couple of scenarios.
There are also some variations of the OperationExecutor and OperationStorage and OperationsRegistry. You can find these files under contracts/core/tmp/*

• *HotHash
  The files that end with *HotHash are part of the version that doesn't use OperationsRegistry at all.
  We simply pass a hash to the operation and at the end of the operation execution we verify if the executed actions are indeed the ones that were supposed to be execute and if they are in the correct order. A drawback of this approach is that we are still transparent but the user signing the transaction must read the hash that's being passed when signing, decode all the action hashes, concatenated them manually, hash the concatenated value and verify if it is indeed the one provided to the method.

• *ColdHash
  The files that end with *ColdHash are part of the version that does use a modified version ofOperationsRegistry. It simply stores a hash of the operation ( keccak256(<concatenated_action_hashesh>)) . THe user can verify in advance what actions are used for a given operation and thus when signing the transaction it's enough to check if the hash passed to executeOp method corresponds to any of the hashesh within the repository.

The pros and cons of the the methods:

• *HotHash approach removes the need to store anything onchain. That saves us the burden to generate hashes and send transactions ( spend funds )
• *HotHash requires the user to be tech savvy and know how to decode data. It will take some time until they verify the transaciton data before signing the transaction itself and for some cases speed of execution is crucial.
• *ColdHash requires the user to be tech savvy and know how to decode data. Nonetheless the user can still verify the data in advance what actions are included for that hash. When the time comes for the transaction to be signed, it will be relatively fast. All they have to do is see if the hash is in the OperationsRegistry.
• ColdHash approach forces us to generate hashes offline and add them onchain which will require us to spend funds.
• Both approaches allow us to send only the action that will be executed. No need to send actions that are going to be skipped.
• We have to generate hashes of the permutionation ( variant ) of an operation offchain which might be complex.

Gas optimization mainly happens from the fact that we don't setup in the beginning of the transaction the 2 arrays of actions and optional inside OperationStorage. We simply concatenate current action's hash into a storage variable in OperationStorage and at the end of the operatin we simply check if the hashed value is the same as the one being provided to the method or from the OperationsRegistry

[peculiarity]

Some more details in the notion page https://www.notion.so/oazo/Research-09517742334942a490a0942ec1842c1c?p=59d6abfbd747440dbbe6d2604328241d&showMoveTo=true