Developer Community Call (ACP-75) 06-13-2024

[meaghanfitzgerald]

ACP-75: Acceptance Proofs 06-13-2024 Meeting

Meeting Date/Time: 06-13-2024, 14:30 UTC
Meeting Duration: 1 hour
Moderator: Meaghan FitzGerald

Purpose of the Meeting

In this meeting, we will discuss the motivation from community teams and projects to add support for block acceptance proofs in consensus as proposed in ACP-75.

Who is invited?

Any protocol developer, ACP author, researcher, or Avalanche community member is invited to attend this meeting.

Links

# Form: Google Form
Youtube Link: video

Preparation Material

To ensure a high-quality discussion, please review the following materials prior to the meeting:

Mandatory

ACP-75 ReadMe
ACP-75 Discussion

Highly Recommended

Using Tendermint as a Finality Gadget

Agenda

Protocol engineers will present the motivation for adding acceptance proofs to consensus as well as the approach outlined in the ACP's ReadMe (linked above). There exist ways to produce a verifiable signature on the C-Chain, but this ACP would add support for producing this within AvalancheGo itself. The need for this functionality will be up for debate, and this aspect of the protocol's design will be open for discussion.

Meeting Notes

• Outside of added stability, why does the community want acceptance proofs?

  • Teams want to run Avalanche Subnets that theoretically can be verified on any network.
  • To post data to the DA service post-finalization with a generic finality solution.
  • Communicate finality to other execution environments for EVM and potentially other VMs.
  • Ability to generate acceptance proofs and aggregated signatures for proving block finality.
  • Proofs should be verifiable on Ethereum, Celestia, and other L1 networks.
  • The acceptance proof could be used as a finality gadget, similar to how tendermint does it.

• Is this meant for the EVM or any VM?

  • AvalancheGo would explicitly handle this, so any VM would be supported.

• Important to note:

  • A Subnet running on AvalancheGo can already generate verifiable proofs with a relayer. Subnet-EVM already has a supported implementation of this that can be made generic to deliver this ACP.
  • The C-chain currently supports posting blockhash warp messages.
  • To produce verifiable proofs, subnet will have to explicitly sync their validator set as well as the proof for blocks in order to send a copy of the validator set so that in each block, the verifier can confirm who was part of the decision to validate a block. Potentially solvable with a light client implementation.
  • Confirmations are currently designed to be sent to Subnet and P-chain separately, which might create inconsistencies with validator sets, making proving tricky.

• What signature scheme is currently enforced?

  • BLS-Multisignature with a bit vector, more info here: https://github.com/ava-labs/avalanchego/blob/master/vms/platformvm/warp/README.md#bls-multi-signatures-with-public-key-aggregation

• What is the latency for the proof to be generated? a.k.a. how frequently could a proof be produced?

  • After block is expected - that node would immediately be willing to sign acceptance certificate. So it just depends how aggressively you tune the relayer. If the relayer is trying to go as fast as possible, a rough estimation would be around <4s for delivery on an external chain, with the potential to be much faster.

• Proposal was made to split this ACP in two:

  • ACP 75.1: Unlocking acceptance proofs for broader use cases. Add server requests and implement a relayer to generate acceptance proofs for any chain.
  • ACP 75.2: Implementing signature aggregation for fault isolation. Requires info added around the ProposerVM header.