feat: Solana Vault Swaps Elections

[ramizhasan111]

Pull Request

Closes: PRO-1521 , PRO-1522

Checklist

Please conduct a thorough self-review before opening the PR.

• I am confident that the code works.
• I have written sufficient tests.
• I have written and tested required migrations.
• I have updated documentation where appropriate.

Summary

• introduces elections for tracking vault swap accounts on Solana and handles initiating swaps and closing swap accounts.
• This impl make the other PR (feat: Open/Close Solana contract swap accounts #5321) redundant and so that PR is not needed anymore.

note: please ignore some of the naming around Contract Swaps. That will be fixed before merging. Renaming done.

[albert-llimos]

I just merged #5375 on top of this so it has the entire vault swap feature so it can be reviewed together (CCM, vaultSwapParameters).
The bouncer changes can be reviewed at the end after we merge this to the base Solana Vault branch if needed, no need to do here necessarily.

[dandanlen]

I still think all of the above logic could be in the close_accounts hook (could make it close_accounts(last_close_block_number, &mut known_accounts)).

This would also make it easier to mock and test.

[ramizhasan111]

depending on whether we were successfully able to close accounts, we have to set the unsynchronized state so it makes sense to have this logic here.

[kylezs]

If all the logic were in the close_accounts hook, then, we wouldn't need to have two separate hooks for get_number_of_available_sol_nonce_accounts and close_accounts - close accounts would already have access to it -> which makes it easier to mock and test, and for the writing of state, all you need is to return a result as is already the case, and just set the block number.

Then for testing this ElectoralSystem's on_finalize, it's very simple, you can just check "has hook been called" - we already have tests that do this for other ElectoralSystems so it would be very similar. Then you could also write tests for the close_accounts hook implementation itself, separately, and can do so just focussing on that logic, free from the needing to test everything in the context of the whole ElectoralSystem

Also if you pass in SolanaVaultSwapsVote could just have one hook function provided, since the api call would be out too

[ramizhasan111]

I considered moving all the logic concerning all three hooks inside one hook but realized it would not actually make testing easier. This is because in that case, writing the test for one big hook impl would then be difficult since the logic in hook impl calls external code (constructing apicall, accessing sol nonces etc). So we would have to mock those. So basically we are back where we started. We wanted to avoid create 3 mocks of 3 election hooks, instead we create one. However, that means we create those extra mocks while testing the hook impl so I dont think we gain anything. In fact, creating the mocks for the hook impl is even harder since we dont have a framework for it at the Runtime level. creating 3 mocks instead of one while writing tests for the on_finalize shouldnt be a big deal.

[kylezs]

Having the apicall construction be a separate trait function is probably reasonable, it's also kind of a different part of the flow, so conceptually could make things easier to follow. Though I think putting the get nonce and close accounts in one should definitely be simpler

[ramizhasan111]

I am not sure I understand what you mean. The apicall construction is inside the close_accounts function. trying to combine apicall construction and get nonces into one hook would mean we have to move the whole logic inside that hook which creates the problem of testability that I mentioned above.

In general, I think it is a pretty arbitrary and subjective choice here between having the logic in one place or splitting it. In the end logic is logic, one has to follow it to make sure it works. Its not like we don't have long pieces of logic inside single functions in other places in the codebase.

[kylezs]

Sorry, should've been clearer. I mean leaving initiate_vault_swap separate makes sense. But since the only reason we need the number of sol accounts is to decide whether we construct the close accounts call, seems to make sense to include it.

I'm not against having long pieces of logic, it's just about keeping conceptually similar things together and the boundaries between things clean. Happy to see how the tests look keeping it like this

[ramizhasan111]

yes of course but in this case we cant test the hook impl easily as i said before so it makes sense to keep it here since we want to test and keep the hook impl trivial.

[albert-llimos]

For visibility, after the two last PRs I merged into this PR, these are the last items to get this done:

• Finish tests on the SC ( test: solana vault swap electoral system tests #5382 and not sure if there's any more needed)
• Address some minor comments left
• Small change in the engine witnessing to not omit event accounts upon decoding error but rather submit the event account information to the SC to trigger the closure but without triggering a swap.

Afaik @ramizhasan111 is working on those 👌 . I will test the last item once completed.

[kylezs]

Still going through it, but thought I'd drop some comments now is looking good so far 👍

[kylezs]

If all the logic were in the close_accounts hook, then, we wouldn't need to have two separate hooks for get_number_of_available_sol_nonce_accounts and close_accounts - close accounts would already have access to it -> which makes it easier to mock and test, and for the writing of state, all you need is to return a result as is already the case, and just set the block number.

Then for testing this ElectoralSystem's on_finalize, it's very simple, you can just check "has hook been called" - we already have tests that do this for other ElectoralSystems so it would be very similar. Then you could also write tests for the close_accounts hook implementation itself, separately, and can do so just focussing on that logic, free from the needing to test everything in the context of the whole ElectoralSystem

Also if you pass in SolanaVaultSwapsVote could just have one hook function provided, since the api call would be out too

[ramizhasan111]

Apart from tests, which I am doing as another PR, this PR should be ready and I would like to merge it if there are no more open points.

[albert-llimos]

Just fyi, when this gets rebased I expect the Solana Vault swaps to fail because the encoding of cf_parameters have changed in main. I will fix that after the rebasing is done.

[kylezs]

For visibility @ramizhasan111 is going to do the missing migrations

[kylezs]

The upgrade test might pass without those version changes until you run it in the queue because it'll be put on top of main, which will then require them

[kylezs]

reminder: needs to be reverted before merge

[albert-llimos]

I'm looking into the Vault swap failures after upgrade.