3 posts tagged with "security"

Issue Caused by Large Reference Scripts on Cardano Mainnet​

On 25th June 2025, a Cardano user inserted a series of transactions, each containing 194 large reference scripts onto the mainnet chain, funded from 3 wallets containing around 20K ada each. High deserialisation costs for these reference scripts impacted the node, resulting in network disruption to block producer nodes, an increase in network load, and some slowdown in transaction throughput.

The direct effect lasted about 12 hours until it was stopped by a community member, at a cost of 4603 ada to the user who had created the transactions. Overall, the network responded extemely well to the increased load, showing a high level of resilience, with some reduction in transaction throughput related to the overall high system load. The community response to the event was positive, praising the speed of response, the robustness of the Cardano network, the cohesion of the Cardano community, and its ability to diagnose and manage issues such as this.

Mitigations Deployed​

The general issue had already been identified, and a mitigation (costing for reference scripts) had been prepared as part of the Chang hard fork, but not yet deployed to mainnet. Based on the event, stronger mitigations were prepared, including restricting large reference scripts, and changing the cost model. These mitigations were deployed via node versions 8.9.4, 8.12.1 or 8.12.2, and incorporated into node version 9.0.0 or later for the Chang hard fork.

Public Reports on the Incident​

Coindesk Report

Nasdaq Report

Blocks from the future​

We identified two issues relating to "blocks from the future".

1. Blocks from the near future
2. Blocks from the far future

While blocks from the near future have been known to occur on mainnet as a result of clock skew/misconfiguration, there are no known instances on mainnet of blocks from the far future. In both cases, restarting an affected node would resolve the issue.

What is meant by a Block from the Future?​

A node considers a block to be from the future if its slot is ahead of the current slot. Ouroboros Praos mandates that all chains containing blocks from the future (at that time) are ignored during chain selection. As Praos assumes that all nodes have access to perfectly synchronized clocks, this will never cause nodes to disregard blocks that have been minted by other honest nodes. In an actual real-world deployment, this assumption is unrealistic due to the imperfections of protocols like NTP as well as leap seconds.

The issues that were identified meant that blocks from the future could potentially be used by malicious actors to create denial-of-service attacks.

Both issues were fixed by Cardano node 8.8 or later, and were eradicated at the Chang hard fork.

Further Details​

Report on Blocks from the Near Future

Report on Blocks from the Far Future

High level summary​

We have undertaken an initial high-level security analysis of the CIP-1694 design. We summarise the analysis and our responses here.

Initial CIP-1694 Security Analysis and Responses​

Section: The constitutional committee​

• “For example, if we consider the hypothetical Constitution rule "The Cardano network must always be able to produce new blocks" - In this example, if the governance action to reduce block size to 0 is passed, then there will be no way of passing or enacting further proposals. That is, this governance action is completely non-reversable. Suggestion: Instating a built-in mechanism that checks (and perhaps enforces) that the proposed governance actions, if passed, can be reverted in the future.

There is a 'guardrails document' in preparation which captures issues such as these. Some of them may be automatable, as suggested; others will need to be evaluated by humans.

Section: Size of the constitutional committee​

• A possible issue with very large committee sizes (or large number of proposals/voters in general) is that it may take longer to have votes appear on-chain, which in extreme cases may require longer voting periods.

Thanks. Yes, we’ve been thinking about this issue for a long time, see for example the section ‘Final safety measure, post bootstrapping’. We don’t consider this as an issue for the CC since they need to be elected while DReps can just register, so we expect the number of CC members to be much less than the number of DReps

Section: Terms​

• The following sentence is a bit awkward to read: “For example, a committee of size five with a threshold of 3/5 a minimum size of three and two expired members can still pass governance actions if two non-expired members vote Yes.” —> Suggestion: “For example, if we have a committee of size five with a threshold of 3/5, then a committee of three non-expired and two expired members can still pass governance actions if two non-expired members vote Yes.”

Thanks. Yes, that suggestion is a bit easier to read.

Section: Registered DReps​

• “Additionally, registered DReps will need to vote regularly to still be considered active.” - There is a minor issue with requiring “voting regularly”. That is, if there are no proposals to vote on for a long time, this means that no DRep can vote regularly (or they have to issue bogus proposals just to vote on them).

Thanks. We’ve added a mechanism to prevent that issue in the spec/code where if there’s nothing to vote on for an entire epoch, we increment the epoch that each DRep expires.

Section: Ratification​

• It is a bit unclear why protocol changes: network group and technical group are two separate groups.

These correspond exactly to the groups that are administered by the Parameter Committee.

• I didn’t understand the rationale for requiring 100% “Yes” votes to pass “Info” type governance actions? It seems they have the least potential to harm the system.

Yes, it’s not about harming the system, since Info actions have no direct effect on the operation of Cardano. The motivation is simply to record the actual level of support for the action.

Once an action is enacted it’s no longer possible to vote on it. So if there was e.g. a threshold of 50%, then there is no way of telling whether the support for it might eventually have reached 90% or higher if it was not immediately enacted when the threshold was reached.

Section: Content​

• For Hard-fork initiation, the changed parameters should probably also be required as part of Additional data.

Protocol parameters can be changed in arbitrary ways by the hard fork and new ones might be introduced, so anything this action pins down might not actually be the value that will be present after the hard fork.

Section: Protocol Parameter groups​

• It is a bit unclear to the reader what some of these parameters mean, for example: monetary expansion (rho) and treasury expansion (tau). Suggestion: Include brief explanations for the non-obvious parameters.

These are existing protocol parameters, described in e.g. https://cips.cardano.org/cips/cip9/9 or The Cardano Protocol Parameters Guide.

• With the current set of governance actions, it seems that it is not possible to add new types of protocol parameters, or categories of governance voting thresholds. Suggestion: Consider possibility of incorporating governance actions that allow addition of new protocol parameters, deletion of defunct protocol parameters, or modification of governance voting threshold categories.

All of this needs to be done via a hard fork. If we had an action that added a parameter then there is no way of giving it semantics anyway, since that must be done by logic in the code.

Section: Votes​

• Is a constitutional committee member also a DRep? If so, do they vote twice, once as a committee member and once as a DRep?

They may or may not be (and they could also be an SPO). Note that this is fine, since these are completely separate tallies. This is also not preventable, since we don’t have an on-chain mechanism for identity. And yes, each credential gets to vote on each action for all roles in the governance system it has.

Section: Separation of Hard Fork Initiation from Standard Protocol Parameter Changes​

• It is unclear whether there would be automated checks for whether a proposal is indeed a soft fork or hard fork, which would reduce human error in categorising proposals.

There is no on-chain mechanism that could enforce this, the best we could do is some kind of certificate. However, this may not be trustworthy, of course. We will consider this in future versions of Voltaire.

Section: Changes post Edinburgh workshop (July 2023)​

• “All governance actions are enacted one epoch after they are ratified.” - I’m not sure if this line is currently in the main body of the CIP?

It is, but it is phrased differently: ‘All governance actions are enacted on the epoch boundary after their ratification.’

Section: Reduced deposits for some government actions​

• Another downside of requiring endorsement from the constitutional committee is that this likely does not apply to constitutional committee-related proposals, such as no-confidence votes.

Indeed. We have no plans for this at the moment.