Performance optimisations for the committee hash update

[szg251]

Issue by: gege251 Original date: 2022-10-12 13:23:47 UTC Originally opened as: mlabs-haskell/trustless-sidechain/issues/242 Original assignees: Status on 2023-06-20: open

---

Description

As described in input-output-hk/trustless-sidechain#223, we have some performance regression:

• Before, we were able to initialise committees of size 100, but now we can't.
• I believe this is because the new spec forces us to compute the aggregate keys on chain since the redeemer does not provide it
• so that's what's taking a bunch of extra compute power Presumably, to fix this, we could change the redeemer to

  data UpdateCommitteeRedeemer = UpdateCommitteeRedeemer
  { signatures :: [ByteString]
  , newCommitteeHash :: ByteString
  , committeePubKeys :: [SidechainPubKey]
  , previousMerkleRoot :: Maybe ByteString
  }

  and update the UpdateCommitteeHashMessage to

  data UpdateCommitteeMessage = UpdateCommitteeMessage
  { sidechainParams :: SidechainParams
  , newCommitteePubKeys :: ByteString -- hash of lexicographically sorted public keys
  , previousMerkleRoot :: Maybe ByteString
  -- ^ last Merkle root inserted on chain (Merkle root for the last sidechain epoch)
  }

Also, we can't have committees of 100 people because the saveRoot endpoint runs into performance issues. Perhaps it would be worth optimizing our onchain verifyMultiSig function.

Blocked By

input-output-hk/trustless-sidechain#223

Goals

• [ ] being able to initialise and update a committee of 100 members

Tests

Links

• meta-task input-output-hk/trustless-sidechain#181

[szg251]

Comment by: gege251 Original date: 2022-10-12 15:24:40 UTC

---

UPDATE: this is quite low priority at the moment, the current goal is to build an MVP, and it's okay if it can only handle fewer committee members

[szg251]

Comment by: gege251 Original date: 2022-10-12 15:24:40 UTC

---

UPDATE: this is quite low priority at the moment, the current goal is to build an MVP, and it's okay if it can only handle fewer committee members

[jstolarek]

Possibly related to #64