System Tests: Bonded ECDSA Keep

[nkuba]

Random Beacon Integration

• [ ] Call openKeepFeeEstimate and openKeep when Random Beacon clients are functional.

  After group selection beacon is called for a new random entry. When entry is ready the group selection seed is updated with the entry value in the BondedECDSAKeepFactory.

• [ ] Call openKeepFeeEstimate and openKeep when Random Beacon clients are not working.

  • fee estimate is returned
  • a keep is created successfully after providing the estimated fee

• [ ] Batch calls to Random Beacon: openKeepFeeEstimate and openKeep called n times quickly one after another

  • openKeepFeeEstimate should return the same value for each single call
  • openKeep should expect the same fee to be passed
  • all calls should succeed
  • the factory should be correctly reseed
  • reseed pool should have enough funds to trigger n-1 refunds

• [ ] Reseed BondedECDSAKeepFactory when there are no funds in the reseed pool

  • When entry is ready the group selection seed is updated with the entry value in the BondedECDSAKeepFactory.

• [ ] Reseed BondedECDSAKeepFactory when there is enough funds in the pool to reseed with no additional payment.

  • When entry is ready the group selection seed is updated with the entry value in the BondedECDSAKeepFactory.

• [ ] Reseed BondedECDSAKeepFactory with payment lower than estimated fee.

  • Transaction is rejected.

Open Keep

Positive scenarios

• [X] Request with minimum group size (1) and threshold = group size :x: https://github.com/keep-network/keep-ecdsa/issues/392

• [x] Request with group size # 3 and threshold = group size

• [ ] Request with maximum group size (16) and threshold = group size

• [x] Request with threshold = 1

• [x] Request with threshold = group size - 1

• [x] Request with threshold = group size

• [ ] Request n keeps at once:

  • [X] n = 10
  • [x] n = 50
  • [X] n = 100
  • [ ] n = 1000

• [x] Request keeps for two different Sanctioned Applications supported by at least one client at once

• [x] Signers that are not part of the keep ignore the request

  Verify logs.

Expected results:

• members keys submitted
• public key set for keep
• data stored in storage

Negative scenarios

• [x] Request with group size = 0

  • Request is rejected.

• [ ] Request with threshold = 0

  • Request is rejected.

• [x] Request with threshold = group size + 1

  • Request is rejected.

• [x] Call from not supported Sanctioned Application

  Call from address that is not backed by any operator as a Sanctioned Application.

  • Request should get rejected.

• [x] Request for group size greater than the number of registered clients

  • Request gets rejected.

Client Unavailability

• [x] Request when one of the clients selected to the group is down and threshold = group size

  Start a client so it's registered in the pool and close the client. Request a new keep where the client is on the list of selected members.

  • key generation fails
  • public key is not set on the Bonded ECDSA Keep contract
  • owner is able to seize the signer bonds.

• [x] Temporarily break a client while generating a group key when threshold = group size

• restart the client (pod)

• remove the client from kubernetes service

  • When client is back up it should continue key generation as it rejoins the process within a generation timeout.

• [x] Permanently break a client while generating a group key when threshold = group size

  Disable the client (pod)

  • Key generation should fail due to a timeout.

Sign

Positive scenarios

• [x] Request signature from keep with group size = 1 :x: https://github.com/keep-network/keep-ecdsa/issues/392

• [x] Request signature from keep with group size = 3

• [ ] Request signature from keep with maximum group size (16)

• [ ] Request signatures from n keeps at once:

  • [x] n = 10
  • [x] n = 50
  • [ ] n = 100
  • [ ]n = 1000

• [x] Request signatures for two different Sanctioned Applications from keeps supported by the same client

• [x] Signers that are not part of the keep ignore the request

  Verify logs.

Expected results:

• clients calculate a signature
• only one client submits a signature
• event is emitted

Negative scenarios

• [ ] Request signature before the public key is generated

  Request gets rejected, public key has not been set yet.

• [x] Request signature from a closed keep

  Request gets rejected, keep is not active.

• [x] Multiple concurrent executions for the same keep

  Request gets rejected, only one signing process at a time is possible.

Client Unavailability

• [x] Request when one of the signers is down and threshold = group size

  Close the client before new signature is requested. Start the client after other clients received signing request.

  • client starts and picks the signing requests from the contract state
  • signature calculation succeeds

• Request when one of the clients selected to the group is down and threshold = group size - 1 - ❗ THRESHOLD SIGNING IS NOT SUPPORTED

  Close the client before new signature is requested.

  • signature calculation succeeds
  • signature is submitted to the Bonded ECDSA Keep contract
  • owner is able to seize the signer bonds

• [x] Temporarily break a client while calculating a signature when threshold = group size

  • restart the client (pod)
  • remove the client from kubernetes service

  When client is back up it should continue signature calculation as it rejoins the process within a generation timeout.

• [ ] Permanently break a client while calculating a signature when threshold = group size

  • disable the client (pod)

  Key generation should fail due to a timeout.

Close Keep

• [x] Call closeKeep by the keep owner

  Clients should stop supporting the keep and archive their data

Seize Signer Bonds

• [x] Call seizeSignerBonds by the keep owner

  Clients should stop supporting the keep and archive it's data

Submit Signature Fraud

🚫 Blocked by https://github.com/keep-network/keep-core/issues/1588

To test these scenarios easier we should expect a network of 3 operator nodes and keeps with group size of 3.

Below tests should be executed for two situations:

1. operator is supporting just one keep
2. operator is supporting multiple keeps

• [ ] Submit valid signature fraud when one of keeps members operators has just a minimum stake

  • peers are not disconnected from the operator
  • client updates operator's status in the factory
  • operator address is not selected to any new keeps
  • the keep is still open
  • it is possible to request new signature from keep and operator serves these requests
  • other operator's keeps are still open
  • it is possible to request new signature from other keeps and operator serves these requests

• [ ] Submit valid signature fraud for operators that have multiplies of the minimum stake

  • peers are not disconnected from the operator
  • client updates operator's status in the factory
  • when called new keep opening the operator is selected to the keep
  • the keep is still open
  • it is possible to request new signature from keep and operator serves these requests
  • other operator's keeps are still open
  • it is possible to request new signature from other keeps and operator serves these requests

[nkuba]

Open Keep Request with threshold = 0 Request is rejected.

Keep is created and the public key is calculated.