This document is a Cardano Problem Definition (CPD), from which the Cardano Problem Statement (CPS): Ouroboros Randomness Manipulation is derived.
While the CPS is being structured for formal submission with a focus on accessibility, and alignment with the CIP process, this CPD retains the full depth of technical material that shaped the problem understanding. It preserves detailed modeling, cost definitions, and adversarial analysis that could not be fully included in the CPS due to scope and formatting constraints.
The CPD thus complements the CPS by serving as its technical foundation and extended reference, providing the complete analytical context behind the identified problem.
A well-designed consensus protocol is inherently modular, comprising multiple sub-protocols that collectively ensure security, efficiency, and decentralization. Among these, the Randomness Generation Sub-Protocol is pivotal in tackling the Coin-Flipping Problem—the challenge of generating fair, unbiased, and unpredictable randomness in a distributed environment.
This issue is especially critical in Ouroboros, where randomness underpins essential sub-protocols like leader election. A robust and tamper-resistant randomness mechanism is vital to maintaining the protocol’s security, fairness, and integrity.
This CPD delineates this challenge within the context of Ouroboros Praos, analyzing its approach and its vulnerability to grinding attacks, where adversaries attempt to manipulate leader election outcomes. The document offers:
- An analysis of attack vectors, their economic and computational prerequisites, and Cardano’s current resilience.
- A quantification of attack feasibility, highlighting escalation beyond a 20% stake threshold.
- Pivotal questions: Is manipulation occurring? What is Cardano’s vulnerability? How might threats be mitigated?
Rather than prescribing specific solutions, this CPD urges the Cardano community to take responsibility for addressing these risks, potentially through advancements in detection, stake distribution, or protocol design. It establishes a rigorous foundation for understanding these issues and solicits collaborative efforts to bolster Ouroboros’ resilience against evolving adversarial strategies.
This CPD undertakes a thorough examination of the Randomness Generation Sub-Protocol within the Ouroboros Praos, focusing on the Coin-Flipping Problem and its implications for the security of the Cardano blockchain. The principal findings are as follows:
- Randomness Mechanism: Ouroboros Praos utilizes VRFs for efficient randomness generation, yet this design exposes vulnerabilities to grinding attacks, wherein adversaries manipulate nonce values to influence leader election processes.
- Attack Feasibility: The likelihood and impact of successful attacks rise significantly when an adversary controls >20% of total stake (~4.36 billion ADA, March 2025), while lesser stakes render such efforts statistically improbable over extended periods.
- Economic Considerations: Acquiring substantial stake entails a significant financial commitment—on the order of billions of USD for a 20% share—further complicated by potential asset devaluation if an attack undermines network integrity.
-
Computational Requirements: Scenario analysis across varying grinding depths (
$\rho$ ) reveals a spectrum of feasibility:- Minor attacks (e.g. manipulating
$\rho=20$ blocks costs ~$56) are readily achievable. - Significant manipulations (e.g.
$\rho=50$ costs ~$3.1 billion) demand resources ranging from feasible to borderline infeasible, contingent upon adversary capabilities. - The cost disparity between the most resource-intensive scenario (Owl Survey) and the least (Ant Glance) is substantial, with a consistent ratio of
$\Delta \log_{10}(\text{Cost (USD)}) \sim 6.3$ , indicating that the strongest attack here considered, the Owl Survey scenario, costs approximately$10^{6.3}$ times more than the base and weakest attack, Ant Glance, driven by the significant influence of the adversary's strategy evaluation,$T_{\text{eval}}$ (simpled called the evaluation complexity), and their target window scope$w_T$ .
- Minor attacks (e.g. manipulating
The table below delineates the
| Feasibility Category | 🔵 Ant Glance | 🟠 Ant Patrol | 🟢 Owl Stare | 🔴 Owl Survey |
|---|---|---|---|---|
| 🟢 🌱 Trivial for Any Adversary | ||||
| 🟡 💰 Feasible with Standard Resources | ||||
| 🟠 🏭 Large-Scale Infrastructure Required | ||||
| 🔴 🚫 Borderline Infeasible | ||||
| 🔴 🚫 Infeasible |
✏️ Note: For a detailed explanation of these scenarios and their feasibility thresholds, refer to Section 3.5 - Scenarios within this CPD.
This document deliberately avoids advocating specific countermeasures, instead presenting these findings to highlight extant vulnerabilities and their associated costs. It is incumbent upon the Cardano community to assess and address these challenges, potentially through:
- Development of enhanced detection mechanisms,
- Improvement of stake pool diversity, or
- Introduction of protocol-level innovations.
Stakeholders are invited to engage with this CPD in its entirety to validate the analysis, deepen their comprehension, and assume ownership of subsequent solutions. Contributions are welcomed via the ongoing discourse at https://github.com/cardano-foundation/CIPs/pull/1009, aimed at collectively fortifying the Ouroboros protocol.
This section introduces the pertinent parts of the Cardano proof-of-stake consensus protocol. We focus on the randomness generation and leader selection processes and omit irrelevant protocol details.
A consensus protocol implements a robust transaction ledger if it maintains the ledger as a sequence of blocks, where each block is associated with a specific slot. Each slot can contain at most one ledger block, and this strict association ensures a well-defined and immutable ordering of transactions within the ledger.
The protocol must satisfy the two critical properties of Persistence and Liveness, which ensure that blocks and transactions are securely committed and cannot be easily manipulated by adversaries. These can be derived from fundamental chain properties which are used to explain how and why the leader election mechanism has been designed in this manner.
| Chain Property | Description |
|---|---|
| Common Prefix (CP) | Ensures consistency across honest parties by requiring that chains adopted by different honest nodes share a common prefix. |
| Existential Chain Quality (∃CQ) | Guarantees that at least one honestly-generated block appears in a portion of a sufficient length of the chain, ensuring honest contributions. |
| Chain Growth (CG) | Ensures that the blockchain extends at a minimum rate over time, preventing indefinite stalling by adversaries while maintaining progress based on the fraction of honest stakeholders producing blocks. |
Once a node of the system proclaims a certain transaction tx in the stable part of its ledger, all nodes, if queried, will either report tx in the same position of that ledger or report a stable ledger which is a prefix of that ledger. Here the notion of stability is a predicate that is parameterized by a security parameter
If all honest nodes in the system attempt to include a certain transaction then, after the passing of time corresponding to
Persistence and liveness can be derived from basic chain properties, provided that the protocol structures the ledger as a blockchain—a sequential data structure. The following key chain properties ensure that the blockchain behaves securely and efficiently:
Consider 2 chains
Where:
-
$C_1^{\lceil k \rceil}$ represents the chain obtained by removing the last$k$ blocks from$C_1$ . -
$\preceq$ denotes the prefix relation.
This ensures that the shorter chain is a prefix of the longer one, ensuring consistency across honest parties.
1.1.2.2 Existential Chain Quality (∃CQ): With parameter $s \in \mathbb{N}$ (Minimum Honest Block Inclusion Interval).
Consider a chain
1.1.2.3 Chain Growth (CG): With parameters $\tau \in (0, 1]$ (speed coefficient) and $s \in \mathbb{N}$ (Minimum Honest Block Inclusion Interval).
The Chain Growth (CG) property is a more general concept that combines both the speed of block production and the frequency of honest contributions. It uses two parameters:
Consider a chain
For example, if
The Coin-Flipping Problem is a fundamental challenge in distributed systems that require a fair, unbiased, and unpredictable source of randomness—without allowing any single participant to manipulate the outcome.
Consider a scenario where multiple untrusted parties must flip a coin and use the outcome, the concatenation of heads or tails, to reach a decision. The challenge is ensuring that:
- 🎲 The outcome remains random and unpredictable.
- 🔒 No participant can bias or influence the result in their favor.
- ⚖️ The process is fair and secure, even in the presence of dishonest or colluding actors.
In blockchain consensus protocols, randomness is crucial for leader election, committee selection, and cryptographic lotteries. If an adversary can bias the randomness, they can increase their influence over block production, delay settlements, or disrupt network security.
Various cryptographic techniques exist to address the coin-flipping problem in decentralized settings. These methods differ in security, efficiency, and resistance to adversarial manipulation.
| Approach | Pros | Cons |
|---|---|---|
| PVSS-Based Beacons (Ouroboros Classic, RandHound, Scrape, HydRand) |
✔ Strong randomness guarantees — output is indistinguishable from uniform. ✔ Resistant to last-mover bias — commitments prevent selective reveals. |
❌ High communication complexity — requires O(n²) messages. ❌ Vulnerable to adaptive adversaries — who may corrupt committee members. |
| Threshold Signature-Based Beacons (DFINITY) |
✔ Fast and non-interactive — requires only one round of communication. ✔ Resistant to last-mover bias — output is deterministic. |
❌ Group setup complexity — requires distributed key generation (DKG). ❌ No random number output in case of threshold signature generation failure. |
| Byzantine Agreement-Based Beacons (Algorand) |
✔ Finality guarantees — randomness is confirmed before the next epoch. ✔ Less entropy loss than Praos. |
❌ Requires multi-round communication — higher latency. ❌ Not designed for eventual consensus — better suited for BA-based protocols. |
| "VRF"-Based Beacons (Ethereum’s RANDAO Post-Merge, Ouroboros Praos, Genesis, Snow White) |
✔ Simple and efficient — low computational overhead. ✔ Fully decentralized — any participant can contribute randomness. |
❌ Vulnerable to last-revealer bias — the last participant can manipulate the final output. |
The Ouroboros family of protocols has evolved over time to optimize randomness generation while balancing security, efficiency, and decentralization. Initially, Ouroboros Classic used a secure multi-party computation (MPC) protocol with Publicly Verifiable Secret Sharing (PVSS) to ensure unbiased randomness. While providing strong security guarantees, PVSS required quadratic message exchanges between committee members, introducing significant communication overhead. This scalability bottleneck limited participation and hindered the decentralization of Cardano's consensus process.
Recognizing these limitations, Ouroboros Praos moved to a VRF-based randomness generation mechanism where each individual randomness contribution is generated with Verifiable Random Functions (VRFs). Here, each block includes a VRF value, that is a veriable random value that gas been deterministically computed from a fixed message. The random nonce for an epoch is then derived from the concatenation and hashing of all these values from a specific section of the previous epoch’s chain. This significantly reduces the communication complexity, which now becomes linear in the number of block producers, making randomness generation scalable and practical while maintaining adequate security properties.
However, this efficiency gain comes at a cost: the random nonce is now biasable as this protocol change introduces a limited avenue for randomness manipulation. Adversaries can attempt grinding attacks, evaluating multiple potential nonces and selectively influencing randomness outcomes. While constrained, this trade-off necessitates further countermeasures to limit adversarial influence while maintaining protocol scalability.
📌📌 More Details on VRFs – Expand to view the content.
Verifiable Random Functions (VRFs) are cryptographic primitives that produce a pseudorandom output along with a proof that the output was correctly generated from a given input and secret key.
BLS Signatures (Boneh–Lynn–Shacham) can be used as Verifiable Random Functions (VRFs) because they satisfy the core properties — Determinism, Pseudorandom and efficiently Verifiable - required of a VRF.
A BLS signature is indistinguishable from random without knowledge of the secret key, their signature is efficient and the signature generation is determistic and secure under standard cryptographic assumptions.
Ethereum RANDAO protocol was first based on a commit and reveal approach where each block producer would commit to random values in a first period, i.e. publish the hash of a locally generated random value during block proposal, before revealing them afterwards. As the latter period finished, all revealed values were combined, more specifically XORed, together to finally get the random nonce.
Ethereum's Post-Merge RANDAO protocol remains mostly the same, but instead of using a commit-reveal approach, each contributor generate randomness deterministically by using VRFs, making these values verifiable. These values are finally, as before, sequentially aggregated using XOR, forming the final randomness output used in validator shuffling and protocol randomness. This version of the protocol is very similar to Ouroboros Praos' where hashing is used instead of XOR to combine contributors' randomness together, and does not rely on commitees.
While decentralized and computationally lightweight, RANDAO still suffers from last-revealer bias, where the final proposers in an epoch can withhold their reveals to manipulate randomness. As such, Ethereum has spent some time studying Verifiable Delayed Functions (VDFs) to prevent the last revealer attack by relying on its sequentiality property. Subsequently, Ethereum decided against integrating Verifiable Delay Functions due to feasibility concerns, including the difficulty of practical deployment and the risk of centralization stemming from specialized hardware dependencies. They instead opted for a frequent reseeding mechanism to strengthen the commitee selection in order to mitigate biases which, unfortunately does not fully eliminate last-revealer manipulation concerns.
📌📌 More Details on VDFs – Expand to view the content.
VDFs are designed to provide unpredictable, verifiable randomness by requiring a sequential computation delay before revealing the output.
This makes them resistant to grinding attacks since adversaries cannot efficiently evaluate multiple outcomes. However, they introduce significant computational costs, require specialized hardware for efficient verification, and demand additional synchronization mechanisms.
Despite some security trade-offs, non-interactively combining VRFs was selected for Ouroboros Praos due to its balance between efficiency, scalability, and security. Unlike PVSS, we do not require a multi-party commit-reveal process or have quadratic communication overhead.
However, ongoing research continues to explore potential enhancements to mitigate grinding risks, including hybrid randomness beacons that combine VRFs with cryptographic delay mechanisms.
As Explained into DGKR18 - Ouroboros Praos_ An adaptively-secure, semi-synchronous proof-of-stake blockchain, Praos protocol presents the following basic characteristics :
-
Slot Leader Privacy: Only the selected leader knows they have been chosen as slot leader until they reveal themselves, often by publishing a proof. This minimizes the risk of targeted attacks against the leader since other network participants are unaware of the leader's identity during the selection process.
-
Verifiable Randomness: The selection process uses verifiable randomness functions (VRFs) to ensure that the leader is chosen fairly, unpredictably, and verifiably. The VRF output acts as a cryptographic proof that the selection was both random and valid, meaning others can verify it without needing to know the leader in advance.
-
Low Communication Overhead: Since the identity of the leader is hidden until the proof is revealed, Oblivious Leader Selection can reduce communication overhead and minimize the chance of network-level attacks, such as Distributed Denial of Service (DDoS) attacks, aimed at preventing the leader from performing their role.
Based on their local view, a party is capable of deciding, in a publicly verifiable way, whether they are permitted to produce the next block, they are called a slot leader. Assuming the block is valid, other parties update their local views by adopting the block, and proceed in this way continuously. At any moment, the probability of being permitted to issue a block is proportional to the relative stake a player has in the system, as reported by the blockchain itself :
- potentially, multiple slot leaders may be elected for a particular slot (forming a slot leader set);
- frequently, slots will have no leaders assigned to them; This is defined by the Active Slot Coefficient f
- a priori, only a slot leader is aware that it is indeed a leader for a given slot; this assignment is unknown to all the other stakeholders—including other slot leaders of the same slot—until the other stakeholders receive a valid block from this slot leader.
The VRF is used to generate randomness locally in the protocol, making the leader election process unpredictable. It ensures that:
- A participant is privately and verifiably selected to create a block for a given slot.
- The VRF output is both secret (only known to the selected leader) and verifiable (publicly checkable).
To determine whether a participant is the slot leader of
| Features | Mathematical Formula | Description |
|---|---|---|
| Slot Leader Proof | This function computes the leader eligibility proof using the VRF, based on the slot number and randomness nonce. | |
| Slot Leader Threshold | This function calculates the threshold for a participant's eligibility to be selected as a slot leader during |
|
| Eligibility Check | The leader proof is compared against a threshold to determine if the participant is eligible to create a block. | |
| Verification | Other nodes verify the correctness of the leader proof by recomputing it using the public VRF key and slot-specific input. |
| Where | |
|---|---|
| The current slot number. | |
| Eta, The randomness nonce used in |
|
| The node's secret (private) key. | |
| The node's public key. | |
| Generate a Certification with input | |
| Verify a Certification with input | |
| The concatenation of |
|
| The stake owned by the participant used in |
|
| The total stake in the system used in |
|
| The active slot coefficient (referred as |
📌📌 Relevant Implementation Code Snippets for This Section – Expand to view the content.
-- | The body of the header is the part which gets hashed to form the hash
-- chain.
data HeaderBody crypto = HeaderBody
{ -- | block number
hbBlockNo :: !BlockNo,
-- | block slot
hbSlotNo :: !SlotNo,
-- | Hash of the previous block header
hbPrev :: !(PrevHash crypto),
-- | verification key of block issuer
hbVk :: !(VKey 'BlockIssuer crypto),
-- | VRF verification key for block issuer
hbVrfVk :: !(VerKeyVRF crypto),
-- | Certified VRF value
hbVrfRes :: !(CertifiedVRF crypto InputVRF),
-- | Size of the block body
hbBodySize :: !Word32,
-- | Hash of block body
hbBodyHash :: !(Hash crypto EraIndependentBlockBody),
-- | operational certificate
hbOCert :: !(OCert crypto),
-- | protocol version
hbProtVer :: !ProtVer
}
deriving (Generic)
-- | Input to the verifiable random function. Consists of the hash of the slot
-- and the epoch nonce.
newtype InputVRF = InputVRF {unInputVRF :: Hash Blake2b_256 InputVRF}
deriving (Eq, Ord, Show, Generic)
deriving newtype (NoThunks, ToCBOR)
-- | Construct a unified VRF value
mkInputVRF ::
SlotNo ->
-- | Epoch nonce
Nonce ->
InputVRF
mkInputVRF (SlotNo slot) eNonce =
InputVRF
. Hash.castHash
. Hash.hashWith id
. runByteBuilder (8 + 32)
$ BS.word64BE slot
<> ( case eNonce of
NeutralNonce -> mempty
Nonce h -> BS.byteStringCopy (Hash.hashToBytes h)
)
-- | Assert that a natural is bounded by a certain value. Throws an error when
-- this is not the case.
assertBoundedNatural ::
-- | Maximum bound
Natural ->
-- | Value
Natural ->
BoundedNatural
assertBoundedNatural maxVal val =
if val <= maxVal
then UnsafeBoundedNatural maxVal val
else error $ show val <> " is greater than max value " <> show maxVal
-- | The output bytes of the VRF interpreted as a big endian natural number.
--
-- The range of this number is determined by the size of the VRF output bytes.
-- It is thus in the range @0 .. 2 ^ (8 * sizeOutputVRF proxy) - 1@.
--
getOutputVRFNatural :: OutputVRF v -> Natural
getOutputVRFNatural = bytesToNatural . getOutputVRFBytes
-- This is fast enough to use in production.
bytesToNatural :: ByteString -> Natural
bytesToNatural = GHC.naturalFromInteger . bytesToInteger
bytesToInteger :: ByteString -> Integer
bytesToInteger (BS.PS fp (GHC.I# off#) (GHC.I# len#)) =
-- This should be safe since we're simply reading from ByteString (which is
-- immutable) and GMP allocates a new memory for the Integer, i.e., there is
-- no mutation involved.
unsafeDupablePerformIO $
withForeignPtr fp $ \(GHC.Ptr addr#) ->
let addrOff# = addr# `GHC.plusAddr#` off#
in -- The last parmaeter (`1#`) tells the import function to use big
-- endian encoding.
importIntegerFromAddr addrOff# (GHC.int2Word# len#) 1#
where
importIntegerFromAddr :: Addr# -> Word# -> Int# -> IO Integer
#if __GLASGOW_HASKELL__ >= 900
-- Use the GHC version here because this is compiler dependent, and only indirectly lib dependent.
importIntegerFromAddr addr sz = integerFromAddr sz addr
#else
importIntegerFromAddr = GMP.importIntegerFromAddr
#endif
-- | Check that the certified VRF output, when used as a natural, is valid for
-- being slot leader.
checkLeaderValue ::
forall v.
VRF.VRFAlgorithm v =>
VRF.OutputVRF v ->
Rational ->
ActiveSlotCoeff ->
Bool
checkLeaderValue certVRF σ f =
checkLeaderNatValue (assertBoundedNatural certNatMax (VRF.getOutputVRFNatural certVRF)) σ f
where
certNatMax :: Natural
certNatMax = (2 :: Natural) ^ (8 * VRF.sizeOutputVRF certVRF)
-- | Check that the certified input natural is valid for being slot leader. This
-- means we check that
--
-- p < 1 - (1 - f)^σ
--
-- where p = certNat / certNatMax.
--
-- The calculation is done using the following optimization:
--
-- let q = 1 - p and c = ln(1 - f)
--
-- then p < 1 - (1 - f)^σ
-- <=> 1 / (1 - p) < exp(-σ * c)
-- <=> 1 / q < exp(-σ * c)
--
-- This can be efficiently be computed by `taylorExpCmp` which returns `ABOVE`
-- in case the reference value `1 / (1 - p)` is above the exponential function
-- at `-σ * c`, `BELOW` if it is below or `MaxReached` if it couldn't
-- conclusively compute this within the given iteration bounds.
--
-- Note that 1 1 1 certNatMax
-- --- = ----- = ---------------------------- = ----------------------
-- q 1 - p 1 - (certNat / certNatMax) (certNatMax - certNat)
checkLeaderNatValue ::
-- | Certified nat value
BoundedNatural ->
-- | Stake proportion
Rational ->
ActiveSlotCoeff ->
Bool
checkLeaderNatValue bn σ f =
if activeSlotVal f == maxBound
then -- If the active slot coefficient is equal to one,
-- then nearly every stake pool can produce a block every slot.
-- In this degenerate case, where ln (1-f) is not defined,
-- we let the VRF leader check always succeed.
-- This is a testing convenience, the active slot coefficient should not
-- bet set above one half otherwise.
True
else case taylorExpCmp 3 recip_q x of
ABOVE _ _ -> False
BELOW _ _ -> True
MaxReached _ -> False
where
c, recip_q, x :: FixedPoint
c = activeSlotLog f
recip_q = fromRational (toInteger certNatMax % toInteger (certNatMax - certNat))
x = -fromRational σ * c
certNatMax = bvMaxValue bn
certNat = bvValue bn
-- | Evolving nonce type.
data Nonce
= Nonce !(Hash Blake2b_256 Nonce)
| -- | Identity element
NeutralNonce
deriving (Eq, Generic, Ord, Show, NFData)
-- | Evolve the nonce
(⭒) :: Nonce -> Nonce -> Nonce
Nonce a ⭒ Nonce b =
Nonce . castHash $
hashWith id (hashToBytes a <> hashToBytes b)
x ⭒ NeutralNonce = x
NeutralNonce ⭒ x = x
-- | Hash the given value, using a serialisation function to turn it into bytes.
--
hashWith :: forall h a. HashAlgorithm h => (a -> ByteString) -> a -> Hash h a
hashWith serialise =
UnsafeHashRep
. packPinnedBytes
. digest (Proxy :: Proxy h)
. serialise
instance HashAlgorithm Blake2b_224 where
type SizeHash Blake2b_224 = 28
hashAlgorithmName _ = "blake2b_224"
digest _ = blake2b_libsodium 28
blake2b_libsodium :: Int -> B.ByteString -> B.ByteString
blake2b_libsodium size input =
BI.unsafeCreate size $ \outptr ->
B.useAsCStringLen input $ \(inptr, inputlen) -> do
res <- c_crypto_generichash_blake2b (castPtr outptr) (fromIntegral size) (castPtr inptr) (fromIntegral inputlen) nullPtr 0 -- we used unkeyed hash
unless (res == 0) $ do
errno <- getErrno
ioException $ errnoToIOError "digest @Blake2b: crypto_generichash_blake2b" errno Nothing Nothing
In Praos and Genesis, an epoch consists of 3 logical phases to compute these 2 key variables—active stake distribution and randomness beacon—by going through the following phases:
The sequential flow of these 3 phases is deliberately structured by designed :
| Id | Phase | Key Property | Description |
|---|---|---|---|
| 1. |
|
Chain Growth (CG for CP) | This phase must be long enough to satisfy the Chain Growth (CG) property, ensuring that each honest party's chain grows by at least |
| 2. | Honest Randomness in |
Existential Chain Quality (∃CQ) | After the Active Stake Distribution being stabilized to prevent adversaries from adjusting their stake in their favor, this phase must be sufficiently long to satisfy the Existential Chain Quality (∃CQ) property, which is parameterized by |
| 3. |
|
Chain Growth (CG for CP) | This phase must again be long enough to satisfy the Chain Growth (CG) property, ensuring that each honest party's chain grows by at least |
While there is no theoretical upper bound on the epoch size—since it is defined by social and practical considerations (e.g.,
The structure of an epoch is often described by the ratio 3:3:4:
- Phase 1 occupies 3 parts of the total epoch.
- Phase 2 also occupies 3 parts of the epoch (adjusted slightly to ensure the total reaches 10 parts in total.).
- Phase 3 takes up the remaining 4 parts of the epoch.
Note that the third phase is only longer than the first one to complete the epoch duration. Consequently, we can assume that the CG property is already reached at the ninth part of an epoch.
To select the slots leaders, which stake pool is eligible to produce and propose a slot's block, we need to rely on random numbers. As economic reward and transaction inclusion depends on these numbers, the generation of these number is of critical importance to the protocol and its security. We show in this section how these random numbers, or random nonces are defined.
Contrary to Section 1.2.3, where we first defined the random nonce as the hash of all VRF outputs, we adopt an iterative approach for the randomness generation in practice.
More particularly, the random nonces
| where | |
|---|---|
| The evolving nonce is initialized using the extra Entropy field defined in the protocol parameters. | |
| The VRF output generated by the |
|
| The concatenation of |
-
As multiple competing forks can exist at any given time, we also encounter multiple nonce candidates, denoted as
$\eta^\text{candidates}$ . More precisely, the nonce candidate of a specific fork for epoch$e$ is derived from the previous epoch’s nonce$\eta_{e-1}$ , the Verifiable Random Function (VRF) outputs from the candidate chain starting from epoch$e-2$ , and the VRF outputs of the fork itself up to the end of Phase 2 of epoch$e-1$ . -
These components together form a candidate nonce for epoch
$e$ , corresponding to the last derived evolving nonce$\eta^{\text{evolving}}_{\text{t}}$ at the conclusion of Phase 2 of epoch$e-1$ :
- This is the final nonce used to determine participant eligibility during epoch
$e$ . - The value of
$\eta_\text{e}$ is derived from the$\eta_e^\text{candidate}$ contained within the fork that is ultimately selected as the canonical chain at the conclusion of$\text{epoch}_{e-1}$ . - It originates from
$\eta_e^\text{candidate}$ concatenated with$\eta^\text{evolving}$ of the last block of the previous epoch followed by a BLAKE2b-256 hash computation , which becomes stabilized at the conclusion of$\text{epoch}_{e-1}$ and transitions into$\text{epoch}_e$ .
As one of these fork will become the canonical main chain, so will the candidate nonce. Hence, the epoch nonce
For a detailed formalization of the consensus mechanisms discussed herein, refer to the Consensus Specifications in the Cardano Formal Specifications repository maintained by IntersectMBO.
📌📌 Divergence with academic papers – Expand to view the content .
In the Ouroboros Praos paper, an epoch's random nonce is computed as the hash of the first blocks' VRF outputs, combined with some auxiliary information. This design ensures that individual random contributions are published on-chain, publicly verifiable, and that the final randomness computation
However, in practice, slight modifications were introduced to distribute the nonce generation cost across the network. This was achieved by iterative hashing, which not only balances the computational load but also ensures uniform block generation behavior regardless of a block's position within the epoch.
The nonce aggregates randomness from the entire epoch, rather than a limited subset as described in the academic version of the paper. When generating the nonce for epoch
-
VRF outputs from Phase 3 of epoch
$e-2$ -
VRF outputs from Phases 1 and 2 of epoch
$e-1$ - The previous epoch's nonce
$\eta_{e-1}$
This leads to the following iterative hashing process:
This approach contrasts with the simpler method from the paper, where only the VRF outputs of Phase 1 and 2 of epoch
📌📌 Relevant Implementation Code Snippets for This Section – Expand to view the content.
-- | Evolving nonce type.
data Nonce
= Nonce !(Hash Blake2b_256 Nonce)
| -- | Identity element
NeutralNonce
deriving (Eq, Generic, Ord, Show, NFData)
-- | Evolve the nonce
(⭒) :: Nonce -> Nonce -> Nonce
Nonce a ⭒ Nonce b =
Nonce . castHash $
hashWith id (hashToBytes a <> hashToBytes b)
x ⭒ NeutralNonce = x
NeutralNonce ⭒ x = x
-- | Hash the given value, using a serialisation function to turn it into bytes.
--
hashWith :: forall h a. HashAlgorithm h => (a -> ByteString) -> a -> Hash h a
hashWith serialise =
UnsafeHashRep
. packPinnedBytes
. digest (Proxy :: Proxy h)
. serialise
instance HashAlgorithm Blake2b_224 where
type SizeHash Blake2b_224 = 28
hashAlgorithmName _ = "blake2b_224"
digest _ = blake2b_libsodium 28
blake2b_libsodium :: Int -> B.ByteString -> B.ByteString
blake2b_libsodium size input =
BI.unsafeCreate size $ \outptr ->
B.useAsCStringLen input $ \(inptr, inputlen) -> do
res <- c_crypto_generichash_blake2b (castPtr outptr) (fromIntegral size) (castPtr inptr) (fromIntegral inputlen) nullPtr 0 -- we used unkeyed hash
unless (res == 0) $ do
errno <- getErrno
ioException $ errnoToIOError "digest @Blake2b: crypto_generichash_blake2b" errno Nothing Nothing
With Ouroboros Praos, as with Nakamoto consensus in general, transaction finality is probabilistic rather than immediate. This means a transaction isn't guaranteed to be permanently stored in the ledger when it's first included in a block. Instead, each additional block added on top strengthens its permanence, gradually decreasing the likelihood of a rollback.
Ouroboros Praos guarantees that after
The consensus layer operates with a structure that resembles a branching "tree" of blockchains before finality stabilizes:
Blockchain forks can happen for several reasons:
- Multiple slot leaders can be elected for a single slot, potentially resulting in the production of multiple blocks within that slot.
- Block propagation across the network takes time, causing nodes to have differing views of the current chain.
- Nodes can dynamically join or leave the network, which is a fundamental challenge in decentralized systems, affecting synchronization and consensus stability.
- An adversarial node is not obligated to agree with the most recent block (or series of blocks); it can instead choose to append its block to an earlier block in the chain.
Short forks, typically just a few blocks long, occur frequently and are usually non-problematic. The rolled-back blocks are often nearly identical, containing the same transactions, though they might be distributed differently among the blocks or have minor differences.
However, longer forks can have harmful consequences. For example, if an end-user (the recipient of funds) makes a decision—such as accepting payment and delivering goods to another user (the sender of the transaction)—based on a transaction that is later rolled back and does not reappear because it was invalid (e.g., due to double-spending a UTxO), it creates a risk of fraud.
This section describes the grinding attack, detailing its objectives, mechanics, and the adversary’s strategy to maximize its effectiveness.
We describe here the grinding attack Cardano's randomness generation protocol suffers from, from passively waiting for its chance or actively maximizing its attack surface, to choosing the best attack vector - stake distribution - to achieve its goal, be it maximizing rewards to controlling target blocks.
In its current version, Praos has a vulnerability where an adversary can manipulate the nonce
At the conclusion of Phase 2, when the
For example, if the adversary acts as the slot leader immediately before this phase transition, they can choose whether to produce a block or not. This decision grants them the ability to compute and compare two valid nonces - one with one fewer VRF update than the other -, evaluate different slot leader distributions for the upcoming epoch and potentially maximize their future gains at the cost of lesser rewards at this epoch. The more blocks the adversary controls before Phase 2's end, the more nonces they may grind and choose from, and the more critical the attack becomes. In essence, the adversary gains access to up to
This marks the beginning of a grinding attack, where the adversary's initial goal is to maximize the number of adversarial blocks at this critical juncture, either passively by waiting, or actively by reaching a snowball effect. By doing so, they expand the range of potential slot leader distributions they can choose from, significantly enhancing their influence over the protocol. We use the term "exposure" here because the adversary is first setting the stage for its attack.
This is the pivotal moment where the adversary's prior efforts pay off. They are now in a position with x blocks at the critical juncture. At this stage, the adversary can generate up to
As the adversary accumulates blocks, the attack's bottleneck swiftly shifts from waiting for enough blocks at the critical juncture to the computational power needed to compute enough nonces to achieve their goal.
Accumulating a significant number of leader slots at this position necessitates, except when owning a significant portion of the total stake, an underlying intent to exploit or destabilize the protocol. Achieving such a level of control requires significant coordination, making it highly unlikely to occur without deliberate adversarial motives. Once an attacker reaches this threshold, their objectives extend beyond a single exploit and diversify into various strategic threats.
Below is a non-exhaustive list of potential attack vectors, ranging from minor disruptions in system throughput to severe breaches that compromise the protocol’s integrity and structure.
Manipulating slot leader distributions to prioritize transactions that benefit the adversary or to extract higher fees.
Selectively excluding transactions from specific stakeholders to suppress competition or dissent.
Amplifying the influence of a small adversarial stake by targeting specific epoch transitions.
Creating and maintaining malicious forks to destabilize consensus or execute double-spend attacks.
Strategically delaying block confirmation to undermine trust in the protocol's settlement guarantees.
Exploiting control over slot leader distributions to reverse confirmed transactions and execute double-spends.
Using nonce selection to stall block production entirely, halting the protocol and causing network paralysis.
The Ethereum community recently published an insightful paper titled Forking the RANDAO: Manipulating Ethereum's Distributed Randomness Beacon. Since the system model used to analyze randomness manipulation in Ethereum is also applicable to Cardano, we will extensively reference their work to explore various manipulation strategies within the Cardano ecosystem.
A block can exist in one of four states:
-
H / Proposed – The validator successfully proposes a valid block, which is accepted by the supermajority of validators and included in the canonical chain. Honest validators always follow this behavior in our analysis, while adversarial validators may consider alternative strategies, such as withholding blocks.
-
R / Reorged – The validator proposes a valid block, but it ends up on a non-canonical branch of the blockchain. This block is no longer considered part of the main chain by the supermajority of the stake.
-
M / Missed – The validator fails to publish a block during its designated slot. For an honest validator, this typically results from connectivity issues or other operational failures.
-
P / Private – The validator constructs a block but does not immediately publish it during its assigned slot. Instead, an adversarial validator selectively shares the block with validators within its staking pool. Later, the private block may be introduced into the canonical chain by forking the next block—a strategy known as an ex-ante reorg attack. Alternatively, depending on the evolving chain state, the attacker may decide to withhold the block entirely, a tactic we refer to as regret.
Block statuses are denoted as
The adversary can selectively propose or miss blocks to manipulate
The manipulative power for
e.g : The adversary chooses option
To achieve the goal of maximizing
The adversary can choose between two forking strategies depending on when they act:
-
Preemptive Forking (Ex-Ante Reorging): The adversary forks before the randomness update, ensuring that only adversarial VRF contributions are included while honest ones are discarded. This allows them to manipulate
$\eta_e$ before it is finalized, biasing leader selection for the next epoch. -
Reactive Forking (Ex-Post Reorging): Instead of acting in advance, the adversary waits until all honest VRF contributions are revealed before deciding whether to fork. If the observed
$\eta_e$ is unfavorable, they publish an alternative chain, replacing the honest blocks and modifying the randomness post-facto.
Both strategies undermine fairness in leader election, with Preemptive Forking favoring proactive randomness manipulation and Reactive Forking enabling selective, informed chain reorganizations.
We define the heaviness of an interval as the percentage of blocks an adversary controls.
Let
We say that the interval is
An
The grinding power
Let
The grinding power for a given interval of size
Similarly, we define the grinding depth,
In a simplified model where the multi-slot leader feature is not considered, the probability an adversary with
where:
-
$\binom{x}{y}$ represents the number of ways to select$x$ blocks out of$y$ . -
$\text{stake}_A$ is the percentage of stake controlled by the adversary.
We can now define the expected grinding power
In Cardano mainnet, the nonce size used in the randomness beacon is 256 bits, meaning the theoretical maximum grinding power is
The grinding opportunity window
The end of Phase 2 happens after
Assuming the adversary controls the
N.B. Contrary to the grinding power that is upper-bounded by
-
Parameters:
-
$f$ : Active slot coefficient (e.g.,$\frac{1}{20}$ ), the fraction of slots with a leader. - Slot duration = 1 second.
-
✏️ Note: The code to generate this graph is available at ➡️ this link.
Let's consider the worst case where the adversary controls all trailing slots (
-
$w = 16$ :-
$w_O = \frac{16}{\frac{1}{20}} = 16 \cdot 20 = 320$ seconds (~5.3 minutes). - Starts at
$S_2 - w = 259,200 - 16 = 259,184$ , ends at$S_2 + \frac{1}{f} = 259,200 + 20 = 259,220$ (adjusted for reveal timing).
-
-
$w = 32$ :-
$w_O = \frac{32}{\frac{1}{20}} = 32 \cdot 20 = 640$ seconds (~10.7 minutes). - Starts at
$S_2 - w = 259,200 - 32 = 259,168$ , ends at$259,200 + 20 = 259,220$ .
-
-
$w = 256$ :-
$w_O = \frac{256}{\frac{1}{20}} = 256 \cdot 20 = 5,120$ seconds (~85.3 minutes). - Starts at
$S_2 - w = 259,200 - 256 = 258,944$ , ends at$259,200 + 20 = 259,220$ .
-
This sizing ensures the adversary has time to act before honest chain growth threatens even a length-1 chain, providing a practical and conservative bound for grinding feasibility.
We can moreover defined opportunity window with respect to the adversarial stake,
-
Parameters:
-
$f$ : Active slot coefficient (e.g.,$\frac{1}{20}$ ), the fraction of slots with a leader. -
$\text{stake}_A$ is the percentage of stake controlled by the adversary. - Slot duration = 1 second.
-
|
|
0.5 | 1 | 2 | 5 | 10 | 20 | 25 | 30 | 33 | 40 | 45 | 49 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|
2.02E-01 | 4.08E-01 | 8.33E-01 | 2.22E00 | 5.00E00 | 13.33E00 | 2.00E01 | 3.00E01 | 3.88E01 | 8.00E01 | 1.80E02 | 9.79E02 |
📌📌 More Details on the expectation's computation – Expand to view the content.
To compute the expectation of the opportunity window, we need to find the earliest slot starting from the end of Phase 2, such that the adversary controls a majority of slots in that interval (and before the chain has been set, that is before
More particularly, if we define each slot as a Benoulli random variable
We can make the problem symmetric by defining
\begin{align*}
\sum_{i=P}^{S2} X_i &\geq \frac{{S2} - P + 1}{2}\\
\sum_{i=P}^{S2} \frac{Y_i - 1}{2} &\geq \frac{{S2} - P + 1}{2}\\
\sum_{i=P}^{S2} Y_i &\geq 0
\end{align*}
By re-indexing, with
We can see this sum over
The position
Once the adversary obtains a potential candidate nonce (
We define the grinding target window
A grinding attempt is a single evaluation of a possible
Each attempt follows three key steps:
-
Computing a candidate
$\eta$ nonce by selectively revealing or withholding VRF outputs. -
Simulating the resulting slot leader distribution over the target window
$w_T$ . -
Evaluating the strategic benefit of choosing this
$\eta$ nonce for their attack objectives.
The number of grinding attempts an adversary can make is constrained by their grinding power
where the adversary dominates the suffix of size
Before an adversary can execute a grinding attack, they must first acquire enough stake, akin to buying an entry ticket to participate in a lottery.
In this case, the lottery is the leader election process, where the probability of winning a slot—and thus influencing the
Just like in a lottery, the more tickets an adversary buys (stake accumulated), the greater their chances of winning.
By securing a significant share of stake, they increase the likelihood of being selected as a slot leader in key trailing positions, providing the foundation needed to execute a grinding attack.
Thus, the first cost of a grinding attack is not computational but economic —the price of acquiring enough stake to play the lottery.
To estimate the cost of these entry tickets, we address the following question:
How many blocks can an adversary control on average with a given adversarial stake, ensuring a reasonable probability—such as at least one successful grinding opportunity within 10 years of continuous epoch-by-epoch execution in Cardano, where each epoch lasts 5 days?
Specifically, for a given adversarial stake, we seek the maximum
$X_A(w)$ for which the probability of obtaining a dominating$\alpha$ -heavy suffix$w_O$ is at least once over 10 years, meaning at least one occurrence within 3,650 epochs.N.B.: A 10-year period spans two full technological innovation cycles, significantly increasing the likelihood of disruptive advancements in cryptographic research, computing power, or consensus protocols. This timeframe provides a long enough horizon for:
- Assessing long-term adversarial feasibility and whether stake-based grinding remains viable at scale.
- Observing historical adversarial behaviors, particularly in decentralized networks with shifting governance dynamics.
- Giving the Cardano community sufficient time to introduce fundamental protocol-level improvements to Ouroboros that could completely mitigate or transform this issue.
We are computing here the expected number of grinding attempts for both the self-mixing and forking strategies.
We present here the average number of years required for an adversary with a stake of
(*) We make the simplification to consider the 21,600 blocks directly, that is: there is only 21,600 slots and to each to slot is exactly assigned one slot leader.
📌📌 More Details on Probabilities Here – Expand to view the content.
We display here the probabilities of an adversary with a stake of
|
|
0.5 | 1 | 2 | 5 | 10 | 20 | 25 | 30 | 33 | 40 | 45 | 49 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 5.00E-03 | 1.00E-02 | 2.00E-02 | 5.00E-02 | 1.00E-01 | 2.00E-01 | 2.50E-01 | 3.00E-01 | 3.30E-01 | 4.00E-01 | 4.50E-01 | 4.90E-01 | |
| 2.50E-05 | 1.00E-04 | 4.00E-04 | 2.50E-03 | 1.00E-02 | 4.00E-02 | 6.25E-02 | 9.00E-02 | 1.09E-01 | 1.60E-01 | 2.03E-01 | 2.40E-01 | |
| 6.25E-10 | 1.00E-08 | 1.60E-07 | 6.25E-06 | 1.00E-04 | 1.60E-03 | 3.91E-03 | 8.10E-03 | 1.19E-02 | 2.56E-02 | 4.10E-02 | 5.76E-02 | |
| 3.91E-19 | 1.00E-16 | 2.56E-14 | 3.91E-11 | 1.00E-08 | 2.56E-06 | 1.53E-05 | 6.56E-05 | 1.41E-04 | 6.55E-04 | 1.68E-03 | 3.32E-03 | |
| 1.53E-37 | 1.00E-32 | 6.55E-28 | 1.53E-21 | 1.00E-16 | 6.55E-12 | 2.33E-10 | 4.30E-09 | 1.98E-08 | 4.29E-07 | 2.83E-06 | 1.10E-05 | |
| 2.33E-74 | 1.00E-64 | 4.29E-55 | 2.33E-42 | 1.00E-32 | 4.29E-23 | 5.42E-20 | 1.85E-17 | 3.91E-16 | 1.84E-13 | 7.99E-12 | 1.22E-10 | |
| 5.42E-148 | 1.00E-128 | 1.84E-109 | 5.42E-84 | 1.00E-64 | 1.84E-45 | 2.94E-39 | 3.43E-34 | 1.53E-31 | 3.40E-26 | 6.39E-23 | 1.49E-20 | |
| 2.94E-295 | 1.00E-256 | 3.40E-218 | 2.94E-167 | 1.00E-128 | 3.40E-90 | 8.64E-78 | 1.18E-67 | 2.34E-62 | 1.16E-51 | 4.09E-45 | 2.21E-40 | |
| 0.00E+00 | 0.00E+00 | 0.00E+00 | 0.00E+00 | 1.00E-256 | 1.16E-179 | 7.46E-155 | 1.39E-134 | 5.49E-124 | 1.34E-102 | 1.67E-89 | 4.90E-80 |
We present the expected number (i.e., moment) of grinding attempts during self-mixing, which refers to trailing blocks within an epoch.
|
|
0.5 | 1 | 2 | 5 | 10 | 20 | 25 | 30 | 33 | 40 | 45 | 49 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 0.005 | 0.010 | 0.020 | 0.053 | 0.111 | 0.250 | 0.333 | 0.429 | 0.493 | 0.667 | 0.818 | 0.961 |
We conclude that the self-mixing attack is neither highly probable nor particularly critical.
We extend here the self-mixing strategy with forking and show how this renders the attack viable.
We first introduce the formula for the probability for an adversary having
As the formula is not computationally friendly, instead of showing numbers for an interval of size
📌📌 More Details on Probabilities Here – Expand to view the content.
We display here the probabilities of an adversary with a stake of
|
|
0.5 | 1 | 2 | 5 | 10 | 20 | 25 | 30 | 33 | 40 | 45 | 49 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 5.00E-03 | 1.00E-02 | 2.00E-02 | 5.00E-02 | 1.00E-01 | 2.00E-01 | 2.50E-01 | 3.00E-01 | 3.30E-01 | 4.00E-01 | 4.50E-01 | 4.90E-01 | |
| 2.50E-05 | 1.00E-04 | 4.00E-04 | 2.50E-03 | 1.00E-02 | 4.00E-02 | 6.25E-02 | 9.00E-02 | 1.09E-01 | 1.60E-01 | 2.03E-01 | 2.40E-01 | |
| 6.25E-10 | 1.00E-08 | 1.60E-07 | 6.25E-06 | 1.00E-04 | 1.60E-03 | 3.91E-03 | 8.10E-03 | 1.19E-02 | 2.56E-02 | 4.10E-02 | 5.76E-02 | |
| 3.91E-19 | 1.00E-16 | 2.56E-14 | 3.91E-11 | 1.00E-08 | 2.56E-06 | 1.53E-05 | 6.56E-05 | 1.41E-04 | 6.55E-04 | 1.68E-03 | 3.32E-03 | |
| 1.53E-37 | 1.00E-32 | 6.55E-28 | 1.53E-21 | 1.00E-16 | 6.55E-12 | 2.33E-10 | 4.30E-09 | 1.98E-08 | 4.29E-07 | 2.83E-06 | 1.10E-05 | |
| 2.33E-74 | 1.00E-64 | 4.29E-55 | 2.33E-42 | 1.00E-32 | 4.29E-23 | 5.42E-20 | 1.85E-17 | 3.91E-16 | 1.84E-13 | 7.99E-12 | 1.22E-10 | |
| 5.42E-148 | 1.00E-128 | 1.84E-109 | 5.42E-84 | 1.00E-64 | 1.84E-45 | 2.94E-39 | 3.43E-34 | 1.53E-31 | 3.40E-26 | 6.39E-23 | 1.49E-20 | |
| 2.94E-295 | 1.00E-256 | 3.40E-218 | 2.94E-167 | 1.00E-128 | 3.40E-90 | 8.64E-78 | 1.18E-67 | 2.34E-62 | 1.16E-51 | 4.09E-45 | 2.21E-40 | |
| 0.00E+00 | 0.00E+00 | 0.00E+00 | 0.00E+00 | 1.00E-256 | 1.16E-179 | 7.46E-155 | 1.39E-134 | 5.49E-124 | 1.34E-102 | 1.67E-89 | 4.90E-80 |
We now tabulatethe grinding power's expectation when looking at different precision
| 0.5% | 1.0% | 2.0% | 5.0% | 10.0% | 20.0% | 25.0% | 30.0% | 33.0% | 40.0% | 45.0% | 49.0% | |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 16 | 0.0203 | 0.0414 | 0.0857 | 0.242 | 0.636 | 3.49 | 8.86 | 22 | 36.8 | 108 | 209 | 334 |
| 32 | 0.0203 | 0.0414 | 0.0857 | 0.242 | 0.637 | 5.71 | 43.4 | 384 | 1,290 | 15,100 | 65,700 | 185,000 |
| 64 | 0.0203 | 0.0414 | 0.0857 | 0.242 | 0.637 | 8.93 | 1010 | 145,000 | 2.01e+06 | 3.56e+08 | 7.36e+09 | 6.06e+10 |
| 128 | 0.0203 | 0.0414 | 0.0857 | 0.242 | 0.637 | 13.6 | 786,000 | 2.92e+10 | 6.59e+12 | 2.44e+17 | 1.05e+20 | 6.87e+21 |
| 256 | 0.0203 | 0.0414 | 0.0857 | 0.242 | 0.637 | 20.2 | 6.98e+11 | 1.64e+21 | 9.6e+25 | 1.45e+35 | 2.48e+40 | 9.29e+43 |
| 512 | 0.0203 | 0.0414 | 0.0857 | 0.242 | 0.637 | 29.6 | 7.87e+23 | 7.19e+42 | 2.8e+52 | 6.59e+70 | 1.64e+81 | 1.79e+88 |
| 1024 | 0.0203 | 0.0414 | 0.0857 | 0.242 | 0.637 | 43 | 1.43e+48 | 1.94e+86 | 3.32e+105 | 1.84e+142 | 8.81e+162 | 7.03e+176 |
We can approximate the expected grinding power as an exponential function of the precision, i.e.
The details of the calculations underlying this table can be found in the following Google Spreadsheet: Details of Calculations.
For example, with 5% adversarial stake, it would take about 1800 years in average for an adversary to obtain an advantage of of exactly 4 blocks at the critical juncture.
N.B : This analysis does not account for recursion in addition to the forking and self-mixing strategy, so the curve should actually be even steeper than in the graph above.
This investment is non-trivial and serves as an implicit deterrent to attacks, as the adversary must weigh the risks of financial exposure against potential gains. While stake acquisition might appear as a sunk cost, it can, in some cases, be viewed as an active investment in the blockchain ecosystem. For instance, an adversary with a large stake may not only attempt manipulation but could also seek to benefit from staking rewards, governance influence, or other economic incentives, adding an additional layer of strategic decision-making.
Results suggests that crossing the 20% stake threshold dramatically increases an adversary’s probability of influencing leader elections. With such control, their ability to manipulate leader election outcomes becomes exponentially and primarily constrained by computational feasibility rather than probabilistic limitations.
As of March 1, 2025, acquiring a 20% stake in Cardano would require an investment exceeding 4.36 billion ADA, a substantial sum that introduces a fundamental game-theoretic disincentive:
- A successful attack could undermine the blockchain’s integrity, leading to loss of trust and stake devaluation.
- If the attack is detected, reputational damage, delegator withdrawals, or protocol-level countermeasures could make the adversary's stake significantly less valuable.
This reinforces transparency as a natural deterrent: publicly observable grinding attempts expose adversarial stake pool operators (SPOs) to severe economic and social consequences.
As previously explained, each attempt consists of three key steps:
-
Computing a candidate
$\eta$ nonce by selectively revealing or withholding VRF outputs. -
Simulating the resulting slot leader distribution over the target window
$w_T$ . -
Evaluating the strategic benefit of choosing this
$\eta$ nonce for adversarial objectives.
Let's analyze each of these steps.
We will denote this step as
Nonce generation consists of:
-
VRF Evaluation: Computes a candidate
$\eta$ nonce. -
$\ast$ Operation: Concatenation + BLAKE2b-256 hashing.
Since the VRF outputs can be precomputed, we can discard them from the computational cost of a grinding attack. As for the computational cost, as the hash functions are protected against extension attacks, we have to consider the average cost of hashing of all nonces when considering a fixed grinding depth
We make the assumption that hashing
N.B. We may drop the superscript
N.B. This represents the average time to compute a nonce. While each nonce can be computed in parallel, we cannot easily parallelize the generation of one nonce as the computation is sequential.
We will denote this step as
After generating a candidate nonce, the adversary must evaluate its impact on slot leader election over an target window
-
Computing VRF outputs for all slots in
$w_T$ of interest. - Evaluating the eligibilty of these values to know when the adversary is the slot leader.
Since leader eligibility is unknown in advance, the adversary must verify all slots in
Define:
-
$w_T$ → target window size (seconds). -
$T_{\mathsf{VRF}}$ → VRF evaluation time. -
$T_{\text{eligibility}}$ → Slot eligilibity check.
Each slot requires one VRF verification, leading to:
This represents the total time of the leader distribution evaluation. Once a nonce is computed, we can generate and check the eligibility of the VRF outputs in parallel.
We denote this step as
After simulating the leader election distribution, the adversary must determine whether the selected
- Assessing block production gains relative to honest stake.
- Estimating adversarial control over leader election.
- Comparing multiple nonces to select the most effective one.
Unlike previous steps, this phase does not perform a single deterministic computation but operates as an evaluation loop over a dataset of adversarial leader election scenarios. The attacker’s dataset includes:
- Nonce-to-leader mappings → which nonces yield better leadership control.
- Stake distributions → impact of adversarial stake on slot control.
- Slot timing predictions → evaluating when it's best to control a block.
- Secondary constraints → network conditions, latency factors, or additional attack-specific considerations.
Since this "database" of possible leader elections depends on adversarial strategies, the cost is too diverse to define precisely. While the exact cost varies, this step is compulsory and must be factored into the total grinding time.
The total grinding time is the sum of:
-
Nonce Generation (
$T_{\text{nonce}}$ ) → VRF evaluation + hashing. -
Slot Leader Simulation (
$T_{\text{distribution}}$ ) → Eligibility checks over$w_T$ . -
Strategic Evaluation (
$T_{\text{eval}}$ ) → Nonce selection analysis.
Expanding each term:
-
Nonce Generation: :
$T_{\text{nonce}} = \frac{\rho}{2} \cdot T_{\text{BLAKE2b}}$ -
Slot Leader Verification :
$T_{\text{verify}} = w_T \cdot ( T_{\mathsf{VRF}} + T_{\text{eligibility}} )$ -
Strategic Evaluation :
$T_{\text{eval}}$ (attack-dependent term)
Final expression:
Where:
-
$T_{\mathsf{VRF}}$ is the VRF evaluation time. -
$T_{\text{eligibility}}$ is the eligibility checktime. -
$T_{\text{BLAKE2b}}$ is the time for the hashing operation. -
$w_T$ is the target window size (seconds). -
$\rho$ is the grinding power. -
$T_{\text{eval}}$ is the nonce selection and evaluation time, which is attack-specific.
A grinding attack consists of multiple grinding attempts executed within the grinding opportunity window
We define the total attack time as:
where:
-
$\rho$ = grinding depth (bits of entropy the adversary can manipulate), -
$T_{\text{grinding}}$ = time required for one grinding attempt, -
$N_{\text{CPU}}$ = number of CPUs available for parallel execution.
For the attack to be feasible, this total time must fit within the grinding opportunity window
which leads to the lower bound on computational power (
From Section 3.3, the per-attempt grinding time is:
Substituting this into the inequality:
From previous sections, the grinding opportunity window is:
Substituting this into our equation:
Starting from the final expression at the end of the last section:
Using Cardano’s mainnet values:
-
$T_{\mathsf{VRF}} = 10^{-6}$ seconds (1 microsecond) – Time to evaluate a Verifiable Random Function. -
$T_{\text{BLAKE2b}} = 10^{-8}$ seconds (0.01 microseconds) – Time for a BLAKE2b-256 hash operation. -
$f = \frac{1}{20} = 0.05$ – Active slot coefficient. - Slot duration = 1 second.
Thus, the expression becomes:
where each step contributes as follows,
-
Nonce Generation: :
$5 \cdot 10^{-10} \cdot 2^{\rho-2}$ -
Slot Leader Verification :
$5 \cdot 10^{-8} \cdot w_T \cdot \rho^{-1} \cdot 2^{\rho-1} $ -
Strategic Evaluation :
$5 \cdot 10^{-2} \cdot T_{\text{eval}} \cdot \rho^{-1} \cdot 2^{\rho-1}$
The estimated number of CPUs required is:
-
$\rho$ : The number of blocks controlled by the adversary. -
$w_T$ : The target window (in seconds), ranging from short (e.g., 3600 s) to a full epoch (e.g., 432,000 s), as defined in Section 3.5 - Scenarios. -
$T_{\text{eval}}$ : The strategic evaluation time (in seconds), varying from 0 to 1, as explored in Section 3.5 - Scenarios.
This expression transitions the theoretical cost model into a practical estimate, with specific values for
Following the computational model from Section 3.4.2 - Estimated Formula Using Mainnet Cardano Parameters, we explore four scenarios to observe how randomness manipulation behaves across varying grinding depths
| Scenario | Description | ||
|---|---|---|---|
| Ant Glance | 0 (Low) | 0s | An ant quickly glancing at a small spot, representing simple evaluation (low |
| Ant Patrol | 0s (Low) | 5d (432,000 s) | An ant patrolling a wide area over time with simple instincts, representing simple evaluation (low |
| Owl Stare | 1s (High) | 0s | An owl staring intently at a small area with keen focus, representing complex evaluation (high |
| Owl Survey | 1s (High) | 5d (432,000 s) | An owl surveying a wide range with strategic awareness, representing complex evaluation (high |
The
| Scenario | |
|---|---|
| Ant Glance | |
| Ant Patrol | |
| Owl Stare | |
| Owl Survey |
✏️ Note: The code to generate this graph is available at ➡️ this link.
The maximal delta
The green line (Owl Stare), lies below the red line (Owl Survey), with a delta of approximately 0.16 in
At
-
Ant Glance (
$T_{\text{eval}} = 0$ ,$w_T = 0$ ):$N_{\text{CPU}} \approx 5.36 \cdot 10^{7}$ ,$\log_{10}(N_{\text{CPU}}) \approx 5.16$ -
Ant Patrol (
$T_{\text{eval}} = 0$ ,$w_T = 432{,}000$ ):$N_{\text{CPU}} \approx 6.32 \cdot 10^{9}$ ,$\log_{10}(N_{\text{CPU}}) \approx 11.40$ -
Owl Stare (
$T_{\text{eval}} = 1$ ,$w_T = 0$ ):$N_{\text{CPU}} \approx 1.65 \cdot 10^{10}$ ,$\log_{10}(N_{\text{CPU}}) \approx 11.77$ -
Owl Survey (
$T_{\text{eval}} = 1$ ,$w_T = 432{,}000$ ):$N_{\text{CPU}} \approx 2.37 \cdot 10^{11}$ ,$\log_{10}(N_{\text{CPU}}) \approx 11.92$
Building on the analysis in previous Section 3.5, we assessed the feasibility of grinding attacks by examining the computational resources (
To help readers understand the practicality of these attacks, we define feasibility thresholds based on economic and computational viability, as shown in the table below:
| Feasibility Category | Cost Range (USD) | Description |
|---|---|---|
| Trivial | < $10,000 | Representing an amount easily affordable by an individual with basic computing resources, such as a personal computer. |
| Feasible | $10,000 to $1,000,000 | Reflects costs that require a substantial financial commitment, typically beyond the reach of individuals but manageable for well-funded entities, such as tech startups, research groups, or organized crime syndicates, assuming access to mid-tier cloud computing resources or a dedicated server farm, necessitating a strategic investment that signals a serious intent to exploit the network. |
| Possible | $1,000,000 to $1,000,000,000 | Reflects costs that demand resources on the scale of large corporations, government agencies, or nation-states, implying the use of extensive computational infrastructure (e.g., data centers) and significant capital, suggesting an attack that requires coordinated effort and advanced planning, potentially involving millions of CPU hours or specialized hardware. |
| Borderline Infeasible | $1,000,000,000 to $1,000,000,000,000 | Indicates costs that approach the upper bounds of what global economies can sustain for a single project, requiring resources comparable to those of major international organizations or coalitions, pushing the limits of current computational and financial capabilities, and suggesting that such an endeavor would strain even well-resourced entities, making it highly improbable without global-scale coordination. |
| Infeasible | > $1,000,000,000,000 | Denotes costs exceeding 1 trillion usd, deemed infeasible because they surpass the total economic output or computational capacity available globally (e.g., estimated at |
The cost model uses the
Costs are estimated assuming a CPU rental price of AWS c5.large (Azure Standard_F2s_v2 (
The table below summarizes the feasibility for Owl Survey (
| CPUs Required (Log₁₀ Scale) | Estimated Cost (USD) | Feasibility | |
|---|---|---|---|
| 31 |
|
8,394.76 | Trivial for any adversary |
| 37 |
|
539,954 | Feasible with standard resources |
| 47 |
|
553.79 million | Possible with large-scale infrastructure |
| 48 |
|
1.107 billion | Borderline Infeasible, requires massive resources |
| 58 |
|
1.137 trillion | Infeasible, exceeds global computing capacity |
-
CPUs Required: Computed for Owl Survey at each
$\rho$ , rounded to the nearest order of magnitude for readability (exact values approximated). -
Cost: Assumes
$0.01$ per CPU-hour, scaled for the runtime$w_O = 20 (2\rho - 1)$ seconds. -
Feasibility: Assessed based on computational and economic viability, considering global computing resources (e.g.,
$\sim 10^{12}$ CPUs in modern data centers,$\sim 10^{15}$ CPUs globally as of March 11, 2025).
📌 Example Calculation for ρ = 50 (Owl Survey)
Let’s walk through the calculation for the Owl Survey scenario at
Step 1: Compute $N_{\text{CPU}}$
The formula for
N_{\text{CPU}} \geq 5 \cdot 10^{-10} \cdot 2^{\rho-2} + 7.16 \cdot 10^{-2} \cdot \frac{2^{\rho-1}}{\rho}
For
\begin{align*}
N_{\text{CPU}} &\geq 5 \cdot 10^{-10} \cdot 2^{48} + 7.16 \cdot 10^{-2} \cdot \frac{2^{49}}{50}\\
&\geq 8.06 \cdot 10^{11}
\end{align*}
In
\log_{10}(5 \cdot 10^{-10} \cdot 2^{48} + 7.16 \cdot 10^{-2} \cdot \frac{2^{49}}{50}) \approx 11.906
Step 2: Compute the Estimated Cost in USD
The cost is calculated as:
\text{Cost (USD)} = N_{\text{CPU}} \times \text{cost per CPU-hour} \times \text{runtime in hours}
-
Cost per CPU-hour:
$0.01,\text{USD}$ , -
Runtime:
$w_O = 20 \times (2\rho - 1)$ seconds, with$\rho=50$ :
w_O = 20 \times (2 \cdot 50 - 1) = 1,980 \, \text{seconds}, \quad \text{runtime} = \frac{1,980}{3600} \approx 0.55 \, \text{hours}
\text{Cost (USD)} = 8.06 \times 10^{11} \times 0.01 \times 0.55 \approx 4.43 \times 10^9 \approx 4.43 \, \text{billion}
Step 3: Determine Feasibility
The feasibility thresholds are:
-
Trivial: <
$10,000$ ($\log_{10} < 4$ ), -
Feasible:
$10,000$ to$1,000,000$ ($\log_{10} 4$ to 6), -
Possible:
$1,000,000$ to$1,000,000,000$ ($\log_{10} 6$ to 9), -
Borderline Infeasible:
$1,000,000,000$ to$1,000,000,000,000$ ($\log_{10} 9$ to 12), -
Infeasible: >
$1,000,000,000,000$ ($\log_{10} > 12$ ).
This scenario is thus Borderline Infeasible, as the cost of
✏️ Note: The code to generate this graph is available at ➡️ this link.
The cost difference between the most expensive scenario (Owl Survey) and the cheapest (Ant Glance) is significant, with a consistent
The table below shows the
| Feasibility Category | 🔵 Ant Glance | 🟠 Ant Patrol | 🟢 Owl Stare | 🔴 Owl Survey |
|---|---|---|---|---|
| 🟢 🌱 Trivial for Any Adversary | ||||
| 🟡 💰 Feasible with Standard Resources | ||||
| 🟠 🏭 Large-Scale Infrastructure Required | ||||
| 🔴 🚫 Borderline Infeasible | ||||
| 🔴 🚫 Infeasible |
-
KRD017 - Ouroboros- A provably secure proof-of-stake blockchain protocol
-
DGKR18 - Ouroboros Praos/ An adaptively-secure, semi-synchronous proof-of-stake blockchain
-
The combinatorics of the longest-chain rule: Linear consistency for proof-of-stake blockchains
-
Efficient Random Beacons with Adaptive Securityfor Ungrindable Blockchains
-
Forking the RANDAO: Manipulating Ethereum's Distributed Randomness Beacon
This CIP is licensed under Apache-2.0. READ