Support slashing & simply data structure for phase 2

[jrwbabylonlab]

What’s changed in this PR:

• Added two new methods to support slashing functionality.
• Removed the Delegation interface from the code. This decision was made after implementing the EOI transaction in simple-staking. The original design of the Delegation object and the Staking/Observable classes were well-suited for phase-1 delegation, where transactions were created one by one (i.e., stakingTx -> Unbonding -> Withdrawal). However, in phase-2, we create multiple transactions within a single operation (EOI), and there is no delegation present at the time of EOI creation. Therefore, moving common fields into the class constructor has proven to be a more efficient approach, allowing us to generate multiple types of transactions with fewer input fields being passed around.

[KonradStaniec]

Few minor comments nothing blocking.

Though I would strongly consider naming adjustments in slashing transactions building functions.

[jrwbabylonlab]

@KonradStaniec @gitferry do we actually need this outputIndex?

It seems that i could rebuild the stakingOutput by doing below

// Build outputs
const scriptTree: Taptree = [
  {
    output: scripts.slashingScript,
  },
  [{ output: scripts.unbondingScript }, { output: scripts.timelockScript }],
];

// Create an pay-2-taproot (p2tr) output using the staking script
const stakingOutput = payments.p2tr({
  internalPubkey,
  scriptTree,
  network,
});

then grab the stakingOutput.address and check each of the stakingTx output, see if it matches?

[KonradStaniec]

in theory you could do that, thought isn't it simpler to use stakingOutputIndex if you already have it ? I think we already store it in Babylon node database and return it in queries to avoid such re-creation.

[jrwbabylonlab]

@KonradStaniec
In phase-1, yes, but No in phase-2 as i don't have it at the time of EOI creation.

[vitsalis]

lgtm, nice work! Did not check the tests due to bandwidth constraints, let me know if there's something specific there you would like me to take a look at.

[vitsalis]

Note for a future development. It would be interesting to see this class be able to identify the staking transaction by itself for unbonding/withdrawal transactions in order to avoid having the transactions passed as parameters and risking having a transaction that does not correspond to the params passed in the constructor.

i.e. the class always has access to all the information to build all transactions by default, and each instance of this class corresponds to all the staking paths starting from a unique staking transaction.

[vitsalis]

Why do we have the option to avoid setting the slashing parameters?

[jrwbabylonlab]

Backwards compatibility with Observable, there is no slashing params in phase-1