3

One of the issues of PoS as far as I understand is the randomness that selects a staker. Ouroboros Praos, and also BABE use VRFs (Verifiable Random Functions) to assign primary and secondary leaders roles to block producers. What's special about this is that only the individual block producer knows whether they're gonna win a block, making targeted attacks infeasible. All good so far.

If I understand correctly, secondary leaders exist in case primaries are not available for any reason (whether it's network latency issue, or being offline). Basically to solve the liveliness problem. BABE chooses the longest chain by finding the most primaries in a chain.

Longest chain is the one with most primaries

Let's say I'm a bad block producer, and I want to produce a certain outcome on the blockchain. What prevents me from doing that by:

  1. Producing the block, and keeping it with me (not broadcasting it)
  2. Waiting for the secondary producer to publish
  3. If I like the outcome, I keep it, otherwise, I publish my block and overwrite it

I can even see Sassafras having the same issue, because it pre-publishes the list of producers to eliminate the probability of having missing producers in slots (the current problem with BABE). What if a producer holds off publishing their block and waits for the next producer in order to publish and then overwrites their work if they don't like it? Same issue with primary and secondary producers.

This is an attack that's prevented in bitcoin by giving all miners the same strength/chainwork per block height. Basically the chainwork is a function of the difficulty, not the inverse of the hash of a block.

3
  • Thanks for the interesting question! I just have a quick clarification: Why would a primary leader want to withhold their block? in other words, what do you concretely mean by "If I like to outcome" in the enumeration above? In my understanding, losing the reward + fees should disincentive this behaviour in practical terms.
    – Iker
    Commented Jul 1, 2022 at 11:40
  • 1
    @Iker It all depends on the gain they'd be getting out of that move. For example, if they are seeking some random value generated through the block. Or if someone is doing a trade on-chain basing their gain on MEV (miner extracted value) for that transaction is higher than the block reward. Basically, the idea is that the miner should only have one shot at getting a block, and any additional ones should incur high cost. We cannot imagine all incentives, but we cannot deny their presence. On bitcoin, the cost of this move is mining another block on top of the original block. Commented Jul 1, 2022 at 12:56
  • I see your point,I thanks for the comment.
    – Iker
    Commented Jul 1, 2022 at 13:27

1 Answer 1

1

Praos has a performance & resource utilization problem, not a liveness problem. BABE's secondary slots, and Sassafras, make the chain faster & more efficient.

As proven by the Praos paper, we never care if some block producers carry out this "attack", only if too many do. It's tricky however because we intuitively think about attackers as being malicious together, while our results often say less than 1/2 or 1/3 byzantine.

In other words, are these protocols secure if all block producers are malicious, but no more than 1/3rd form cartels together? Although some work exists, there is afaik no analysis proving exactly this for Praos or any byzantine agreement protocol. Instead, there are results after you add economic assumptions, which makes sense because this requires the cartels goals differ. We do know bicoin's consensus collapses after enough halvings within the cartels model, due to their stupid economics.

We believe Sassafras admits simpler analysis, and should be stronger, in the cartels model, for two reasons:

Any (semi-)SSLE like Sassafras admits only one block per slot, which also means fewer blocks always reduces total rewards. Although important, I kinda dislike the second bit here for polkadot because we'll be cheaper by making as much of the validator rewards as possible to go for approval checks of parachain blocks.

In sassafras, we'll eventually build tor-like circuits through which users send tx almost to block producers, bypassing the memepool. We could then make block producers "own" tx via half-aggregation aka pre-batching of signatures, snarks, etc. If we've both advancements, then skipping others' block merely excludes the contained tx entirely, but does not permit attackers to benefit from those tx. This looks powerful.

As an aside, Tor does not pay relay operators, largely because they believe altruism mitigates these economic concerns, and they've a worse threat model than blockchains, but this assumption remains hotly debated.

5
  • Thank you for the answer. Two follow-ups, if you don't mind: 1. Can you please point me to the part in Ouroboros Praos paper that shows that this attack is only dangerous if many do it, and 2. What does SSLE mean? Commented Jul 1, 2022 at 10:37
  • It's the whole paper that defines the problem and proves this, but most action happens in section 4, which culminates with Theorem 8. There exist other papers which do this analysis in a perhaps nicer ways, like using martingales or markov processes. Commented Jul 1, 2022 at 12:24
  • SSLE = Secret Single Leader Election Commented Jul 1, 2022 at 12:25
  • From the paper, theorem 8, I honestly don't understand how alpha-dominated, alpha being the stake fraction, means that it's secure. It just means that the most damage a staker can do is bounded by an alpha fraction of slots of the blockchain, which can be really significant. If I understand correctly, it just means that this is a trade-off that's accepted anyway. The trade-off is: "as long as the staker can't corrupt a fraction of the blockchain that isn't longer than his stake, we're good". Am I getting this right? Commented Jul 1, 2022 at 13:52
  • It only needs to be good enough so the epoch randomness winds up good enough to keep going, i.e. "like the outcome" means "corrupt the randomness" in Praos. You might "like the outcome" for other reasons, but they all translate into using randomness (in)correctly. At worst you need tools like github.com/kobigurk/aggregatable-dkg but sometimes you prove something simpler works. Commented Sep 19, 2022 at 8:28

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.