[ZAVAX Bridge] Review Designs to move out of BLS in favor of FROST

[pacu]

Research on BLS requirements 2hs

[pacu]

April 11th 2024 4hs

• Review of ZavaX architecture docs
• BLS to FROST: note that signer warden is a Coordinator
• [Meta] replace Wardens with Guardians

[pacu]

April 15th 2024

• Rename HW wallet model for a generic term This change is intended to remove brand specific on hardware wallet used for self-custody
• users won't specifically authorize the fees, it will only verify them and authorize/ reject the transaction
• replace wallet brands for a generic term, plus fee changes:
• We remove wallet names because transparent address for funding the bridging address of the users can be done from any wallet that allows the user to send t-funds. A ccording to ZIP-317, fees are subject to the amount of inputs and outputs used in a transaction so the users won't specifically authorize the fees, it will only verify them and authorize/ reject the transaction
• Changes to architecture README
• renamed wardens to guardians, added FROST as terms to use, added references to ZIP-317 fees
• Add FROST reference to the learning list

• add FROST DKG to Maintain guardians Sequence

  This adds the DKG sequence from the FROST book to the mainting guardians sequence. A follow up commit must updete the graphics and the steps of the communication diagrams. This illustrates how DKG is carried out with frost. ZavaX consensus engine acts as FROST DKG monitoring party which can call an abort sequence if any errors or misbehaviors occur

[pacu]

April 17th 2024

• Renaming .wsd files that mentioned wardens to reference guardians

• rename user story file that referenced wardens

• Remove reference to hardware wallet brand

• Add FROST to wallet bridge migration sequence

  a ZavaX Agent initiates the process by calling the ZavaX Consensus Engine with the transaction plan for migrating to a new bridge wallet. The ZCE will act as a FROST coordinator to notify potential Guardians that will be part of the signature. A minimum of t >= threshold is required to sign this transaction.

  The ZA initiating the operation may or may not be a participant although it would be highly likely that it is. For enhanced security the ZCE could choose to exclude the initiating ZA. Although, this would be less useful as t and n total signers are larger since the percentage that a single signer represents would decrease.

  The ZCE will be also responsible of halting or restarting the signature scheme when any signer misbehaves and to report success or failures to the initiating ZA.

  ZA finally submits the signed transaction to Zebra

• rename Ledger entity to HW Wallet removing branding

• Change refs to Zcash wallet brands to generic name

• adding FROST signature sequence to Bridge ZEC.z

  This change adds one extra step to the Maintain guardians FROST signature sequence that includes a broadcast message from the ZCE acting as a coordinator to poll for potential signers from the "current guardians" set. At least t guardians must respond to reach the threshold.

  Bridge ZEC.z sequence diagram also reproduces this sequence. all the steps are the same since a ZA initiates a transaction signature sequence.

[pacu]

April 23rd 2024

Met with Kit and we reviewed the diagrams We generated new png for the wsd diagrams They will review the changes and we will regroup Tuesday April 30th.

[pacu]

May 2nd

Met w/ Kit and team. We discussed about the architecture. They'll review the changes I sent and we will schedule a call or request feedback from ZF's FROST team.

[pacu]

From Red.Dev

"Hi ZCG Committee, Pacu asked me to contact you and confirm to you that he has done the work exactly as he describes here. https://github.com/pacu/zwcd/issues/118 Huge help, and a pleasure to work with. Thanks to ZCG for approving this work for him as it has helped push the ZavaX project forward."