Checkpoints: potential loss of deposits during downtime

[wwestgarth]

Problem encountered

#7751 handles the case where any deposits made during network downtime would be lost when the network was restored from a snapshot. This could happen, for example during a protocol-upgrade.

It is suspected that the same thing could happen with checkpoints since the last seen eth block for the collateral bridge is not saved in the checkpoint. The flow would be:

• a checkpoint is taken
• time moves forward and a deposit it made which is picked up by the network
• we start the network from the checkpoint
• the deposit is not seen after the restart, and is never picked up by the vega chain.

It would be good to have a system-test to confirm this to be true.

Observed behaviour

A clear and concise description of how the system is behaving.

Expected behaviour

A clear and concise description of what you expected to happen.

System response

Describe what the system response was, include the output from the command, automation, or else.

Steps to reproduce

Manual

Steps to reproduce the behaviour manually:

1. Go to '...'
2. Click on '....'
3. Scroll down to '....'
4. See error

Automation

Link to automation and explanation on how to run it to reproduce the problem/bug

Evidence

Logs

If applicable, add logs and/or screenshots to help explain your problem.

Additional context

Add any other context about the problem here including; system version numbers, components affected.

Definition of Done

ℹ️ Not every issue will need every item checked, however, every item on this list should be properly considered and actioned to meet the DoD.

Before Merging

• Code refactored to meet SOLID and other code design principles
• Code is compilation error, warning, and hint free
• Carry out a basic happy path end-to-end check of the new code
• All APIs are documented so auto-generated documentation is created
• All bug recreation steps can be followed without presenting the original error/bug
• All Unit, Integration and BVT tests are passing
• Implementation is peer reviewed (coding standards, meeting acceptance criteria, code/design quality)
• Create front end or console tickets with feature labels (should be done when starting the work if dependencies known i.e. API changes)

After Merging

• Move development ticket to Done if there is NO requirement for new system-tests
• Resolve any issues with broken system-tests
• Create documentation tickets with feature labels if functionality has changed, or is a new feature