[First Protocol HCU] Benchnet Testing

[jordanschalm]

Problem Definition

This issue enumerates test cases for testing the Protocol HCU / Upgrade process on Benchnet, defined here.

Test Cases - Protocol HCU Upgrade Process

• A. Test with n>=2 ENs running sv2, m=1 ENs running sv1 when ProtocolStateVersionUpgrade is emitted
  • ENs running sv1 will produce an inconsistent receipt. Since we require 2 consistent receipts for sealing, we should tolerate <=1 EN running sv1.
  • We should make sure (e.g. by temporarily halting the ENs with sv2) that this test would fail in case 1 receipt is sufficient for sealing.
  • Expected outcome: Upgrade succeeds, EN running sv1 halts after upgrade
  • Test Notes 1
• B. Test with n consensus nodes, m consensus nodes running sv1 when ProtocolStateVersionUpgrade is emitted while m consensus nodes run sv2, with m << n
  • Expected outcome: SNs running sv1 should halt when the upgrade occurs; upgrade should succeed.
• C. Test with >0 collection/verification nodes running sv1 when ProtocolStateVersionUpgrade is emitted
  • Expected outcome: LN/VNs running sv1 should halt when upgrade occurs; upgrade should succeed
  • Test Notes
• D. Test with an insufficient number of verification nodes running sv2 when ProtocolStateVersionUpgrade is emitted, so that happy-path sealing cannot continue
  • Expected outcome: upgrade should succeed and emergency sealing should keep the network alive
  • Test Notes
• E. Test running mix of sv1/sv2 for several epochs before ProtocolStateVersionUpgrade is emitted
  • This also tests the DKG end state migration with non-empty v1 DKG end states.
  • Expected outcome: epoch transitions succeed (sv2 is backward-compatible) and eventual upgrade succeeds
  • Test Notes 1 Test Notes 2
• F. Test upgrading contracts (step 4) multiple epochs after ProtocolStateVersionUpgrade is emitted (and after upgrade actually occurs)
  • Expected outcome: epoch transitions succeed (sv2 is backward-compatible) and eventual upgrade succeeds
  • Test Notes