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