ACP-75: Acceptance Proofs

[avalanche-foundation-admin]

Introduces support for a proof of a block’s acceptance in consensus.

https://github.com/avalanche-foundation/ACPs/blob/main/ACPs/75-acceptance-proofs/README.md

[Primata]

Acceptance Proofs are somewhat aligned with Layer 2s needs for compatibility but apparently it needs more guarantees on staking and finality. One example use case is Data Availability where For Layer 2 solutions utilizing subnet Snowman consensus, achieving a hard finality is crucial for operations like posting data blobs to DA layers. A finality gadget would facilitate more reliable and timely data posting, something critical for the operation of networks utilizing DAs and a meta/probabilistic-finality wouldn't suffice.

[aaronbuchwald]

The C-Chain currently provides with the following process:

1. Run snow consensus (probabilistic)
2. When a node accepts via Snow, it's willing to produce a Warp signature over the accepted block hash

To verify a block was accepted, an aggregate Warp signature is produced over the block hash, which can be delivered via getVerifiedWarpBlockHash https://github.com/avalanche-foundation/ACPs/tree/main/ACPs/30-avalanche-warp-x-evm#precompile-solidity-interface.

This is handled by the VM (Subnet-EVM/Coreth) rather than consensus itself. This ACP would add support for producing this as a post-consensus step within the consensus code itself as well.

Both ACP-30 (already implemented) and ACP-75 should produce the exact same guarantee.

Curious if either or both of these work for you? I assume the main benefit of ACP-75 is that it's provided a bit more out of the box, although we could factor out the backend of ACP-30 as well, so that it could be more easily integrated into any VM.

[aaronbuchwald]

Could you elaborate more on what you mean by "staking and finality" ?

Do you mean a deterministic proof ie. a multi-signature that can be verified or a complete deterministic consensus protocol run after the fact (something like https://forum.cosmos.network/t/using-tendermint-as-a-finality-gadget/3821) ?

[erwindassen]

After this call and with some time to think I do feel a bit worried regarding implementing this and deploying something like this for mainnet on very block. To be honest the subnet resiliency use case feels a bit weak to me and I can see stronger use cases outside of this (light clients being a major one). Depending on the use cases it could be possible to implement this as an external protocol service no? Much like warp messages themselves (acceptance proofs as I understand are in fact essentially warp messages of a specific type) that are also handled externally and with relayers.

Are these worries warranted? How can an O(N) protocol be deployed for mainnet for proofs for every block? I mean, I do hope Mainnet eventually reach 10s of thousands of validators! 🙂

[joshua-kim]

Left some answers, let me know your thoughts.

To be honest the subnet resiliency use case feels a bit weak to me

We have had this issue occur previously on subnets and it's just an example of a way we can use acceptance proofs to get rid of a long-standing concern where subnets want to be more failure isolated from the P-Chain (want to operate under a failure mode where in the worst-case the subnet can still produce blocks but not update its validator set).

I can see stronger use cases outside of this (light clients being a major one).

Yeah this is a use-case I can see being very relevant.

Depending on the use cases it could be possible to implement this as an external protocol service no? Much like warp messages themselves (acceptance proofs as I understand are in fact essentially warp messages of a specific type) that are also handled externally and with relayers.

Yes, technically there are many valid acceptance proofs and we could allow some entity external to Avalanche aggregate them if we wanted to.

Are these worries warranted? How can an O(N) protocol be deployed for mainnet for proofs for every block? I mean, I do hope Mainnet eventually reach 10s of thousands of validators! 🙂

Yes, this is a very valid concern and it's why we probably won't be producing proofs at every block. If we wanted to produce an acceptance proof at every block, we would probably need the consensus protocol to natively support this (which would require a switch to another consensus protocol and we don't need to do this to unblock this feature). We could consider having some way for a subnet to tune how frequently proofs are produced (maybe as a subnet parameter, or maybe there's some api exposed into the VM that lets you start an aggregation job) so that the subnet/vm is able to define when proofs are generated.