staking: verify staking/slashing tx relationship in staking requests

[SebastianElvis]

First step of #7

This PR adds verification on the relationship between staking/slashing tx in staking requests using babylon_btcstaking::tx_verify::check_transactions. This also involves further refactoring of datagen library, and a bug fix in taproot pk script generation where we mistakenly used secp256k1 FFI that bloats contract size.

NOTE: this PR still results in a wasm contract slightly bigger than the standard 800 KB. There are two ways to go ahead before optimisation is in place:

1. merge it into a feature branch for full validation for now, optimise in subsequent PRs, or
2. merge it into main, but before that add a Rust feature to allow to enable/disable the full validation

I'm inclined to 2 but open to other ideas cc @maurolacy @gusin13

---

TODOs before ready:

• fixing size of BTC staking contract (current it's 1.9MB)
• making all tests use corresponding parameters in datagen

[SebastianElvis]

Some debugging on the contract size: the contract size bloats due to taproot script utilities in Bitcoin library, specifically two things:

• Usage of TaprootBuilder
• Usage of p2tr

This is further due to that the process involves secp256k1 operations which are all implemented in C++. That's also the reason why twiggy shows that the dominator is data not some code paths.

Now trying to replace them with something else
UPDATE: fixed in 5deb5c5 (#46)

[gusin13]

nice work!

[gusin13]

NOTE: this PR still results in a wasm contract slightly bigger than the standard 800 KB. There are two ways to go ahead before optimisation is in place:

merge it into a feature branch for full validation for now, optimise in subsequent PRs, or
merge it into main, but before that add a Rust feature to allow to enable/disable the full validation

i'd prefer opt2 as well i.e "merge in main", qq regarding that though - why do we need to enable/disable the validation, shouldn't it always be enabled?

[SebastianElvis]

why do we need to enable/disable the validation, shouldn't it always be enabled?

There is a trade-off between

• the overhead / gas cost of maintaining Babylon contracts
• the trust assumption that a consumer chain made on Babylon

If we enable all verifications, then all operations on Babylon contracts will be quite expensive, but the integration is trustless. If we disable it, operations become cheaper but the consumer side trusts information sent from Babylon.

[SebastianElvis]

i'd prefer opt2 as well i.e "merge in main"

OK make sense, updated the CI to include a new feature full-validation in BTC staking contract. Now

• By default this full-validation is false false meaning that contracts do not perform full validations. I modified test commands / CI to enable full validation when executing unit tests.
• I also modified Cargo.toml such that cargo optimize will output both btc_staking.wasm and btc_staking-full-validation.wasm

Please take a look to see if this approach makes sense

[SebastianElvis]

After some offline discussions, it's better to have a single compiled wasm binary rather than compiling all of them. This is not trivial and created #55 for now. Merging this PR