2

In Bitcoin the PoW mining has very little overhead in terms of bandwidth. The miners simply need to produce the PoW, which I believe is 32 bytes per 10 minutes.

In Casper I understand every validator can vouch for a block by signing it. Assuming the signatures are ECDSA with 80 bits of security, then each signature is 320 bits. If there are 1000 PoS nodes signing each block, that is 320,000 bits (40kB) per block.

If blocks come out every 17 seconds that is 84MB every 10 minutes, several orders of magnitude above the 32 bytes per 10 minutes in Bitcoin.

Are my numbers correct/reasonable? What is the expected network overhead for Casper's PoS mining? Does this affect blockchain bloat?

1

It is not yet known what network and storage overhead will be.

At present the protocol is expected to see a maximum of 256 participating nodes for a given block. However the votes maybe encrypted, use zero knowledge proofs, and/or use a different signature schemes. A longer blocktime may also be viable if casper facilitates concurrency and/or progressive confirmations.

  • 1
    Can you provide a source for the maximum of 256 participating nodes? – Randomblue Feb 14 '16 at 10:22
1

So for every bonded validator node we have bandwidth overhead that is linear in the number of bonded validators, and in the number of blocks. This means that for the network we have overhead that is quadratic in the number of bonded validators.

Vitalik especially has been looking for efficiency gains to reduce Casper's overhead. The O(N^2) network overhead, however, is fundamentally necessary for quick finality, so it's here to stay. This will put an upper bound on how many bonded validators we'll end up having. However, this does not contribute to blockchain bloat: we can forget the blockchain after state finality.

We don't actually need to have very large numbers of bonded validators at any time, until we adopt a sharding solution - the gas/sec capacity of a single-chain does not increase when you add miners/validators.

BTW, I'm hoping that the latency will be ~4s in the first release of Casper, but to move to ~1s or ~0.5s ASAP. Yes, it is possible - Casper can have arbitrarily low latency (to the first tx receipt, or "confirmation") if it can tolerate arbitrarily high overhead :P

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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