babylonlabs-io / babylon-contract

CosmWasm smart contracts for Babylon integration
Other
10 stars 7 forks source link

Generated data sometimes fails tests #28

Closed maurolacy closed 3 months ago

maurolacy commented 3 months ago

@maurolacy cloned issue babylonchain/babylon-contract#210 on 2024-07-10:

When generating / updating test data via (cargo run-script gen-data) sometimes the some of the generated data fails to pass some tests.

Seen:

  1. eots package tests failure:

thread 'tests::test_serialize' panicked at packages/eots/src/lib.rs:304:9:

assertion `left == right` failed

  left: ProjectivePoint { x: FieldElement(FieldElementImpl { value: FieldElement5x52([2427446910402982, 3860010447655577, 410507808423617, 2344833731812313, 199643482667270]), magnitude: 1, normalized: false }), y: FieldElement(FieldElementImpl { value: FieldElement5x52([1466140312109882, 3067110026448929, 199459779230833, 703147724770631, 142883586316376]), magnitude: 1, normalized: false }), z: FieldElement(FieldElementImpl { value: FieldElement5x52([4192240590702103, 3153959074478655, 4203168725353950, 934490870437560, 129237448056190]), magnitude: 1, normalized: false }) }

 right: ProjectivePoint { x: FieldElement(FieldElementImpl { value: FieldElement5x52([4144976769790275, 978306446817734, 2593816116418957, 1090197061387468, 19253057113762]), magnitude: 1, normalized: true }), y: FieldElement(FieldElementImpl { value: FieldElement5x52([48168643486914, 562151235855225, 3775863086928370, 2594970314998774, 153050320893096]), magnitude: 1, normalized: true }), z: FieldElement(FieldElementImpl { value: FieldElement5x52([1, 0, 0, 0, 0]), magnitude: 1, normalized: true }) }

stack backtrace:

   ...

   4: eots::tests::test_serialize

             at ./src/lib.rs:304:9

   5: eots::tests::test_serialize::{{closure}}
  1. btc-staking contract test failure (delegations):

Note: The delegations tests failure is simply because the delegations store key is the staking tx hash. The hash depends on the staking tx's content, but its lexicographical order doesn't depend on the staking tx's lexicographical order.

Let's solve this by comparing test results with the original delegations sorted by their staking tx hash. (done)

Re-generating the data a couple of times solves the issue.

maurolacy commented 3 months ago

Seems that EOTS datagen is stripping the y-coordinate parity information from both the pubkey and pubrand projective points.

Seems this "even" behaviour comes originally from the btcd package. ~Will try upgrading it to the latest version~ (upgraded to latest compatible version of btcec (v2.3.3)).

Let's discuss offline about the best way to handle this incompatibility.

SebastianElvis commented 3 months ago

https://github.com/babylonlabs-io/babylon-contract/tree/fix/eots-gen-data reproduce