2

My question is related to the usage of bitfields in data availability system, described in https://spec.polkadot.network/chapter-anv. Polkadot uses bitfields to know if a relay-chain block is stored by an adequate number of validators. I was wondering why they do not use threshold signatures? That would be one signature per block, and it is enough to show that 2/3 of the validators are storing the data. Is there any advantage of bitfields (other than knowing who is storing the data)? Also, is the information on who is storing the data used somewhere?

I am aware that bitfields provide accountability, i.e., it is possible to know which validators claim to have the data. However, considering the vast majority of validators (>2/3) has the data, a data requester can easily find a validator having the data (since the probability of a random validator having the data is already >1/2).

I am not aware of any other use of accountability in the current system. If accountability is ignored, wouldn't it be cheaper to store a threshold signature, rather than the bitfields?

Improve this question

1 Answer 1

Reset to default
0

We lack concensus on availability bitfields in the sense that validator could report different bitfields, maybe because one validator sends different bitfields to every other validator. We therefore have no shared message which validators could threshold sign.

We do collect sets of bitfields on the relay chain, but block production has forks. We therefore do not have concensus upon bitfields even after they appear on-chain. We do implicitly sign all the bitfields in grandpa, and could do threshold signing in beefy, but this comes quite late.

In other words, we'd need a blockchain plus three-round finality gadget merely for concensus upon the bitfields, so that's effectively like 4 n signatures per block. Why bother?

Instead we mitigate relay chain forks using softer methods, and operate upon each fork when necessary, so then we liberate the (availability) cores faster. If we waited then any stall would freeze parachains too, which maybe limits our migration of relay chain functionality to parachains.

Also, is the information on who is storing the data used somewhere?

Yes, we already have pairwise connections between all validators of course, but afaik we still only attempt downloads from nodes who say they have their chunk. We've nobody coordinating the transfers like trackers do in bittorrent, so the transpose of all the bitfields acts like tracker data for us.

Ideally we should've pushed this bittorrent analogy deeper into the code, but everyone loves their not-invented-here.

I am not aware of any other use of accountability in the current system.

We want BEEFY signatures to be accountable because bridges use them. And regular threshold signatures cannot really be accountable.

wouldn't it be cheaper to store a threshold signature, rather than the bitfields?

Afaik storage costs are irrelevant, but..

Afaik there is no reason anybody but polkadot validators cares about availability in polkadot. In principle, one could archive some "stripped" version of polkadot blocks which only contained candidate recipets and their inclusion/enaction remarks, but no bitfields. A BEEFY proof would represent validity for these, so availability could be forgotten entirely.

Improve this answer
4
  • Thanks for the answer! Since the aggregated bitfields stored in blocks are not signed, wouldn't it be an attack vector regarding the availability claims? E.g., a malicious validator falsely claiming all bitfield items are available (stored by 2/3 validators).
    – Oguzhan Ersoy
    Commented Feb 26 at 9:01
  • In polkadot, no all validators check the signatures. If you mean in my hypothetical "stripped" block idea. No: Assuming 2/3rd hoenst, there exists a finalized block where everything was signed, given they signed the BEEFY statments, but the "stripped" block is a light client proof of the block without all that stuff. Anyways, my point is that whatever you do to threshold sign would look like this stripped block at some level, because you'd need all the concensus machenery to get there.
    – Jeff Burdges
    Commented Feb 28 at 20:38
  • My comment was mainly about the ensuring the availability of the blocks (without the collection of the signatures). I assume that is done by the random validator checks.
    – Oguzhan Ersoy
    Commented Mar 14 at 18:25
  • We place the bitfields on the relay chain, so all validators check all those signatures. Approvals checks by 30ish validators ensure validity, but we can trust the signed bitfields thanks to our 2/3 honesty assumption. We've no availability sampling because this causes a worse undecodable ratio of 1/4th, vs our 2/3rd.
    – Jeff Burdges
    Commented Mar 16 at 18:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.