CIP-0164? | Ouroboros Linear Leios - Greater Transaction Throughput

[will-break-it]

(Rendered Version)

[rphair]

Looks practically ready for merge... perhaps because I know that at least one CIP editor has already reviewed this 😉 ... editors will introduce this & I would imagine assign a CIP number at the next CIP meeting: https://hackmd.io/@cip-editors/118

We'll still look forward to the usual review process, though I think this would be considered the definitive statement on the subject and so would be accepted as such. I think many others will have gone over this material already for clarity and readability, so for now these are just formatting recommendations that affect the body of CIP material as a whole. Everything in the document seems to flow & work well in a speed-read so far.

[rphair]

p.s. @will-break-it @ch1bo now that force-push #1078 (comment) is done, which I assume standardises the material, we should please continue without force-pushing since individual changes in this big document will need to be tracked so they don't need to be re-reviewed. 🙏 https://github.com/cardano-foundation/CIPs/blob/master/CIP-0001/README.md#1a-authors-open-a-pull-request

[fallen-icarus]

AFAIU hardforks are triggered by a special transaction submitted to the chain. Does it matter if this tx goes in an RB or an EB?

[WhatisRT]

No, HFs are triggered by the ratification of a governance action now, and this depends entirely on the ledger state at the epoch boundary. There is no need to revisit and HFC compatibility since none of the timings change.

[rphair]

Approving in continuation from #1078 (review) now that any problem I could find has been fixed with c2b9491.

[perturbing]

Hi all,

First of all, let me say how impressed I am with your work. The level of detail in this CIP is remarkable, and it’s clear that it reflects years of research, testing, benchmarking, and simulation. Truly outstanding work—thank you for putting this together!

Below you’ll find my review (I may add more comments later). As a disclaimer, given the size of this CIP, I wrote my feedback as I was reading through it. This means some of my questions may already be answered in later sections—apologies in advance if that’s the case. In addition, with CIPs of this scale, there is always room to go into more detail; some of my questions may therefore be trivial and not warrant any changes.

Finally, I have a couple of broader questions that didn’t neatly fit into any specific section:

What is the impact of EB’s and the CDDL changes on the snarkification of blocks for bridges?

Relatedly, how will these changes affect Mithril?

And lastly, where can I find more info on these certificates? I get the feeling their size highly depends on the committee size, and the verification of these certificates is also dependent on the local view of the node on the network, making reaching consensus harder (at least that is what my intuition is saying).

[rphair]

Well done @will-break-it and to all co-authors, contributors and reviewers since we could so readily confirm this as a candidate at today's CIP meeting... please rename the containing directory to CIP-0164 and update the "(Rendered Version)" link in the original posting. 🎉

@Crypto2099 (this time, though the issue has been highlighted by all editors in turn about other submissions) commented that these proposals must also be initially & generally understandable to the not-very-technical visitor (e.g. to approve in funding or hard-fork governance decisions) and so might have a level of lighter content served at the beginning... or perhaps even the deep detail shelved into a different document. These 2 prior discussions contain some of these considerations about prior Consensus proposals of equivalent length & depth:

• #1065 (comment)
• cardano-foundation/cf-cip-frontend#52

And yes @will-break-it we will happily support your suggestion at the meeting that we begin tagging reviewers in every relevant field... including those not specifically Consensus (@jpraynaud came to mind with interest in review from the Network side). Please invite reviewers to post all questions and suggestions here in the PR thread itself so these can form an ongoing checklist for review.

[rphair]

(p.s. to #1078 (review))

Substantial changes, with many more review points raised in the meantime, require reassessment at all levels.

[sterraf]

Below there are some more questions and suggestions; the main ones are:

• some questions about the simulations, specifically the assumptions underlying the distribution of Plutus budgets and the number of inputs of transactions, which are accompanied with some stats acquired from dbSync;
• adding a forefront clarification of which of the several competing Leios versions we are promoting in this PR (since many resources refer to other ones);
• the possibility of having a summary of the proposal, highlighting some salient points;

plus some minor observations/corrections.

[sterraf]

The linked benchmark still refers to IBs.

[bwbush]

The two technical reports are snapshots of the research results as of the time the report was written. The first technical report predates the variant of Leios described in the CIP, so it does indeed refer to IBs and other concepts that are not present in the Linear Leios of the CIP.

[sterraf]

This link still refers to IBs

[bwbush]

The two technical reports are snapshots of the research results as of the time the report was written. The first technical report predates the variant of Leios described in the CIP, so it does indeed refer to IBs and other concepts that are not present in the Linear Leios of the CIP.

[dcoutts]

So here's a worry that I voiced in the (non-quorate) TSC meeting yesterday:

As I understand it, the pivot from "full fat" Leios to Linear Leios is/was motivated by feedback that the Cardano ecosystem (in particular DApp and wallet authors) would not be ready within the expected 1-2 year development and deployment time frame. Specifically, the changes to the ledger to allow full concurrent Leios would be hard to adapt to quickly. And thus the team decided to pivot to a non-concurrent (hence linear) design that does not involve any of the ledger changes.

And so the idea is that Linear Leios is an intermediate stepping stone to full Leios. And we (i.e. the community) still will want full Leios because 100 TPS is great as an intermediate level of performance, but not enough for the long term. Linear Leios involves a lot of the same mechanisms as full concurrent Leios and so the development time from Linear to full will be less than getting to full Leios from a standing start (though of course going directly for full Leios now would be quicker than going via Linear Leios due to paying double overheads).

So now my worry is this: the deployment of Linear Leios may not in fact be an intermediate stepping stone to the deployment of full Leios. Deploying Linear Leios does not get us any closer to getting those DAps and wallets etc any closer to being ready for full Leios. It gets the node code closer, but not the ecosystem, and it is the ecosystem that was supposedly the blocker for doing full Leios.

Suppose for the sake of argument that it will take the ecosystem 2 years to get ready from the point where a fully functional testnet is up and running. If we do Linear Leios now and have that deployed in 2 years, and then start full Leios (lets say taking 1 more year), then we still do not start getting the ecosystem ready for full Leios for 3 years from now, and thus we cannot deploy full Leios for 5 years from now. That's not great. (I recall Mr Hoskinson saying shortly after he fired me that he wanted Leios in f'ing 2026 not 2028.)

With my TSC hat on: this pivot from concurrent to linear Leios is a major strategic issue for Cardano as a whole, and will affect things for the next several years. I think it would be wise to bring that strategy question to the TSC to get advice. Review the evidence with the TSC: what evidence do we have about the perceived ecosystem compatibility issue (the TSC has not seen this evidence); what is the best way to address that problem; how can we manage a transition and what intermediate points are plausible and useful.

My own view is that we should take the ecosystem compatibility issue seriously and try to take an approach that lets the ecosystem start getting ready as soon as possible, so that we can deploy full Leios as soon as possible once the ecosystem is ready. Of course intermediate performance improvements until then are also very welcome, but we should also make progress towards the end goal.

What might that look like? Thoughts:

• Keep iterating on the concurrent Leios design to minimise the complexity of the full ledger changes.
• Focus design effort on the transitional period: introducing ledger changes early (before protocol changes) in a way that allows users to opt in and transition their applications. For example, introduce labelled/sharded UTxOs but leave the default as unlabelled so nothing breaks initially.
• Have a transitional period on mainnet where sharing is available but not compulsory, and allow Leios to be deployed with 1 shard. At the same time, have fully sharded testnets for people to test on. This allows applications to be transitioned without a flag day.
• Once enough applications (DApps, wallets etc) have had enough time to transition, without a hard fork increase the shards via protocol parameter changes.
• Try to keep a compatibility shard: more or less equivalent to current ledger on Praos, where users that have not transitioned can keep working, but will be subject to congestion. Incentive to move to full sharing to take advantage of the greater bandwidth available.
• If we're lucky with the design compatibility we could even deploy sharded Leios early and let the eager users start using shards early while most users remain on the compatibility shard. This might be only for applications that don't have to rely on end-user wallets being ready yet.
• Really pay attention to the node IPC interfaces so that downstream applications that do not need to know about the Leios chain structure do not need to know. The full Leios ledger still gets linearised and so in principle can be interpreted by any client that can interpret the existing chain's block bodies (i.e. without trying to validate the block headers). This would allow us to carry the existing node clients (indexers, block explorers, wallets etc) with no or minimal changes.

I realise this is over-simplified. I know (from being on the design team) that there is more complexity than this, but I hope it illustrates a plausible strategy.

[berewt]

With my TSC hat on: this pivot from concurrent to linear Leios is a major strategic issue for Cardano as a whole, and will affect things for the next several years. I think it would be wise to bring that strategy question to the TSC to get advice. Review the evidence with the TSC: what evidence do we have about the perceived ecosystem compatibility issue (the TSC has not seen this evidence); what is the best way to address that problem; how can we manage a transition and what intermediate points are plausible and useful.

As a TSC member, I want to emphasise that this is not (at the moment at least) an official TSC statement.

[dcoutts]

As a TSC member, I want to emphasise that this is not (at the moment at least) an official TSC statement.

Yes indeed. It's my opinion.

[fallen-icarus]

As I understand it, the pivot from "full fat" Leios to Linear Leios is/was motivated by feedback that the Cardano ecosystem (in particular DApp and wallet authors) would not be ready within the expected 1-2 year development and deployment time frame. Specifically, the changes to the ledger to allow full concurrent Leios would be hard to adapt to quickly. And thus the team decided to pivot to a non-concurrent (hence linear) design that does not involve any of the ledger changes.

Is this the motivation? I thought the motivation was that handling UTxO contention in a concurrent setting is currently an unsolved problem. Linear Leios gives Cardano a noticeable throughput boost while giving more time to figure how to best address it.

[dcoutts]

@fallen-icarus perhaps you could elaborate on what you think that problem is/was/would be?

[fallen-icarus]

@Quantumplation had a good blog post (Transaction Conflicts section) explaining the technical trade-offs when handling conflicting transactions.

I should add that I am coming from the perspective that:

• The current DeFi paradigm is a bunch of isolated dApps. It is extremely rare for a single transaction to involve more than one dApp. However, I do not think the future will/should be like this. The eUTxO model enables composing dApps together in a single tx and there are tremendous economic benefits to supporting this. I created a prototype wallet with a transaction cart, and I'm currently working with Lace on a transaction cart UI/UX for them. You can see the demo of my prototype on youtube here.
• UTxO contention is not possible to eliminate. Trying to do so will actually backfire. Instead, we should handle it using fee markets as much as possible. UTxOs are economic resources and we should address it the same way TradFi handles contention over limited resources: using price.

I gave a seminar to the CF earlier this year discussing how I think it is actually possible to successfully launch a DeFi Order Book using a built-in fee market for UTxO contention on limit orders. This order book is actually able to share its liquidity with all other dApps so dApps don't need their own liquidity pools anymore; we can have a single, unified liquidity source but this requires composing dApps together with the order book in the same transaction.

In order for my vision for Cardano's DeFi to successfully play out, I need three things:

1. Fee Determinism - In order for the DeFi Order Book to work properly, we need bots competing to match limit orders when possible against other limit orders and existing AMMs. But if the bots don't know ahead of time what their operating costs will be, they won't do this and therefore limit orders won't get executed when their prices are hit.
2. Failing Transactions Should Have No Cost - The issue is predictable operating costs again. If a bot has to pay fees even for failing transactions, they will lose more money than they make. They will prefer not to help facilitate the order book and limit orders will not get executed when their prices are hit.
3. dApp Composability Should Not Be Obstructed - As long as dApps can be composed in the same transaction, the DeFi order book is able to share its liquidity with all other dApps (this is explained in the seminar).

AFAIU there is currently no known solution that satisfies all three:

• Forcing failing transactions to still pay fees directly violates (2).
• Coloring/sharding seems to violate (3). What happens if the order book's limit orders are using "blue" and another dApp is using "red"? Can they still be composed?

Back in June, I suggested using an auction model (on the Leios' discord):

1. A tx creator would add an extra collision fee.
2. If there is no tx conflict, only the normal tx fee is taken.
3. If tx's conflict, the UTxOs would go to the tx that had the highest collision fee specified (i.e., it goes to the highest bidder).

---

I should also add that I think we need to build DeFi in layers (also discussed in the seminar). The order book would operate on Cardano's L1, but it would not support high-frequency trading. That high-throughput activity should happen on an L2 that occasionally settles against the L1's order book. Therefore, the L1 does not need to scale to 10,000+ tps. Current TradFi settlement demand (including its stock markets through the DTCC) is handled by approximately 5,000 tps.

[Quantumplation]

I'll try to produce an update blog post that talks about linear leios

[mpizenberg]

Deploying Linear Leios does not get us any closer to getting those DAps and wallets etc any closer to being ready for full Leios. It gets the node code closer, but not the ecosystem, and it is the ecosystem that was supposedly the blocker for doing full Leios.

IMO it’s a very wrong theory for many reasons. I’m saying this as someone who have built a full offchain framework from scratch. As I understand it, full Leios will have many challenges on the ecosystem side. Some are related to concurrency, some are related to other things, such as handling higher throughput, where one must learn to specialize in the subpart of the network activity relevant for their dapp. Or such as being able to deal with longer time from Tx submission to block insertion, while still giving great UX by leveraging other Cardano properties such as determinism. These are example challenges that the ecosystem will have to learn to tackle better with linear Leios, earlier than with full Leios.

Second, this time period in which this simplified Leios is being developed is also a time during which node diversity is improving. Meaning all the languages used by people building dapps, which are not Haskell, are getting better tools during this period. Not providing good tooling for the community using languages used by the community is one of the original reasons why Dapps builders have such a hard time in Cardano everytime things changes in the core node / ledger / etc. And the year it will take to bring this simplified Leios will be a time during which the Cardano ecosystem will grow and improve and be much more ready to tackle something like full Leios.

Finally, we don’t know how long full Leios will take, and honestly that’s the thing that worries me most. It’s like sometimes Cardano engineers and researchers forget that this all experiment will only work if the economics are aligned. And 3 more years with average capacity at 2 TPS will be the death of Cardano, plainly and simply.

For all these reasons, I personally welcome this simplified Leios warmly!

[will-break-it]

Why Linear Leios?

I am opening this thread to have a more scoped discussion on specific issues that have been raised by reviewers, particularly by @dcoutts in his latest review.
Thank you for taking the time to share such a thoughtful and detailed perspective.

Also thanks to @fallen-icarus ¹ and @mpizenberg ² for adding valuable insights to this discussion.

Throughput and Performance Considerations

“...we (i.e. the community) still will want full Leios because 100 TPS is great as an intermediate level of performance, but not enough for the long term.”

While this reflects a valid concern raised by @dcoutts in his capacity as a TSC member, the 100 TPS figure appears to be a conservative estimate rather than a fixed community consensus.
Based on simulations, the upper bound for Linear Leios is closer to 300 TxkB/s, which depending on average transaction size, is substantially higher than 100 TPS:

Avg Tx Size (bytes)	TPS @ 50 Tx kB/s	TPS @ 100 Tx kB/s	TPS @ 200 Tx kB/s	TPS @ 300 Tx kB/s
300 B	166.7	333.3	666.7	1 000
500 B	100	200	400	600
800 B	62.5	125	250	375
1 000 B	50	100	200	300
1 200 B	41.7	83.3	166.7	250
1 600 B	31.3	62.5	125	187.5

This performance comfortably exceeds current network needs and achieves economic sustainability, as shown in Figure 2 of the CIP.
Linear Leios crosses the breakeven threshold (~50 Tx kB/s assuming ~1400 B txs), while Praos does not. This means that Linear Leios not only improves scalability, but also sustainability in the medium term.

We’ve also invested significant effort comparing protocol variants and trade-offs, available here.

If higher throughput is considered essential, it would be valuable to define what specific performance target is required and why, since higher throughput typically comes at the cost of:

• increased latency (due to additional protocol stages),
• more complex conflict resolution, or
• fragmented liquidity from UTxO sharding.

Front- vs. Back-loading Ecosystem Costs

“We should take the ecosystem compatibility issue seriously and let the ecosystem start getting ready as soon as possible…”

Absolutely - and that’s precisely the rationale for Linear Leios.

There’s an inherent trade-off between introducing a radically different sharded ledger early (with significant complexity and adoption overhead) versus delivering an incremental upgrade that achieves most of the performance benefits while keeping existing infrastructure compatible.

A sharded ledger - by design - requires the ecosystem to rethink liquidity management, and cross-shard dApp interactions.
For example, multi-dApp transactions relying on shared UTxO liquidity would face major design challenges in a fully sharded environment.

Linear Leios, on the other hand:

• avoids UTxO fragmentation,
• avoids transaction conflicts, and
• keeps downstream applications compatible with minimal or no changes.

This approach allows the node, wallet, and dApp ecosystems to evolve and mature incrementally, rather than absorbing a massive protocol shift all at once.

Moreover, as @mpizenberg pointed out, this period of Linear Leios development coincides with significant tooling and node diversity improvements across languages - something the ecosystem urgently needs before tackling a more complex ledger.
Without this maturity, deploying a highly concurrent, sharded system too early could easily outpace the readiness of both developers and tools, leading to slower adoption and fragmentation.

Finally, there’s an economic argument: scaling capacity prematurely does not guarantee demand.
A high fixed-cost, high-throughput system without corresponding transaction volume can actually harm long-term sustainability.
Linear Leios mitigates this risk by adapting throughput dynamically (through adaptive announcing, voting & certification of EBs) to current network demand.

On dApp Composability and Transaction Conflicts

Building on @Quantumplation’s excellent blog post and the follow-up discussion on Leios trade-offs:

The future of Cardano DeFi should not remain a collection of isolated dApps.
The eUTxO model uniquely enables cross-dApp composition within a single transaction - a property we must preserve and encourage.

Attempting to completely eliminate UTxO contention or shard it away risks undermining this composability.

---

Linear Leios is not a detour - it’s a strategic building block.

In other words, Linear Leios is the pragmatic path:
it gets us closer to the end goal by keeping the system live, sustainable, and evolvable - rather than risking multi-year stalls or premature complexity.

cc @ch1bo @fallen-icarus @mpizenberg @Quantumplation

[ch1bo]

FYI, we had found a bug in the simulator a couple weeks back and just re-created the key simulation results already in the CIP in commit bd8bd57. See cardano-scaling#22 for more details.

In short, we included transactions twice erroneously. The effective throughput increased and congestion is only starting at around 300 TxkB/s load. This corresponds with the expected capacity given by the current parameterization.

Overall, the system appears well-behaving overall under varying loads and demand exceeding capacity as these further studies show: cardano-scaling#24. Comments are welcome if can clarify things further or you disagree.

Thanks @bwbush and @SupernaviX for your work on this 👏

[wolf31o2]

I added a section about Clients to the document after the Network section. I don't want to distract from the main focus, but I think it's important that we agree on at least the Ouroboros mini-protocol changes for node-to-client.

cardano-scaling#25

[will-break-it]

Front-Running in Linear Leios vs Ouroboros Praos

Opening this thread to directly address the recent community concern that Linear Leios is significantly more vulnerable to front-running/MEV than Praos, and that full/parallel Leios would largely solve the problem.

That claim is not correct.
Any protocol delivering 30-60× higher throughput will necessarily create proportionally more ordering-dependent value. That is not a flaw, it is the entire point.

Linear Leios actually has fewer front-running vectors than the full/parallel design (no decoupled IB stage, no separate EB production cadence).

Most importantly, the protocol has one extremely strong, built-in incentive that keeps ordering-sensitive transactions exactly as safe as they are in Praos today.

The Incentive

If a slot leader puts a high-value ordering opportunity (a "V-tx") in an Endorser Block, the very next leader can skip the certificate with zero risk and steal the entire opportunity for themselves.

→ No rational slot leader will ever do that.
→ Certified EBs therefore contain almost exclusively non-sensitive bulk traffic (B-tx).
→ All ordering-sensitive traffic (large swaps, liquidations, oracle updates, competitive mints etc.) is automatically forced into RBs and retains exactly the same front-running resistance as Praos.

This works perfectly with Cardano’s batcher AMMs too - the batcher is the one who extracts value, so the incentive to keep valuable batches in RBs is unchanged.

Complex / Plutus-heavy dApps

The incentive to skip still exists in theory, but is negligible in practice:

• Skipping only pays if the stolen value > total EB fees
  → expected to be extremely rare.
• Per-transaction Plutus budget is raised ~10× globally
  → most currently-tight scripts now fit in RBs.
• Truly heavy workloads are almost always non-sensitive (B-tx)
  → no reason to skip.
• Private submission to trusted SPOs remains available for guaranteed RB inclusion.

Bottom line

Linear Leios does not weaken front-running resistance in any meaningful way. It cleanly separates sensitive and non-sensitive traffic by itself, using a very strong economic incentives, while giving the ecosystem vastly more capacity for everything else.

We would very much welcome concrete counter-examples - specific dApps, scripts, or realistic scenarios - that would actually be worse off under Linear Leios than under current Praos.

Thanks - let’s keep the discussion here on the CIP.

cc @ch1bo @pagio @KtorZ @fallen-icarus @dcoutts

[fallen-icarus]

@will-break-it Can you provide any links to where this concern has been mentioned?

[will-break-it]

There have been multiple sources, one is this video and a CIP Editor meeting chat discussion two weeks ago.

[fallen-icarus]

I've now watched the video twice, and I actually agree with @dcoutts and Neil's concern.

The core of the problem comes down to the fact that Linear Leios enables instant gratification for bad behavior while Full Leios does not. In Linear Leios, if a malicious SPO sees an EB with a profitable trade, it can:

1. Ignore the EB.
2. Create its own tx that takes advantage of the profitable trade (a replacement attack).
3. Add this new MEV tx into the Praos block instead of the EB certificate.
4. Profit as soon as the block is confirmed by the network.

With Full Leios, this instant gratification is not possible. If a malicious SPO sees an EB with a profitable trade, that SPO can't simply add their own version of that tx into the RB. Instead, they must add it to an IB and send it through the entire Leios pipeline for a future SPO to possibly place in an RB. This is because in Full Leios, RBs can only hold EBs, not individual txs.

The increased concern about front-running directly follows from this difference in design. Right now, an SPO can only see what is inside their mempool - about 200 kb. To find a profitable MEV opportunity, they only have 200 kbs of txs to look through. But with Linear Leios, the EB block gives them an extra 10 mb or more. That is 500x more information at their disposal. Odds of finding a profitable MEV opportunity sky-rocket and the instant gratification possible with Linear Leios make it possible to take advantage of any opportunities found in this extra 10 mb of txs.

Again, in Full Leios, the SPO sees more data too but they can't take advantage of it due to the way txs actually get included in RBs.

---

@will-break-it I think there are a few issues with your rebuttal:

If a slot leader puts a high-value ordering opportunity (a "V-tx") in an Endorser Block, the very next leader can skip the certificate with zero risk and steal the entire opportunity for themselves.

→ No rational slot leader will ever do that.
→ Certified EBs therefore contain almost exclusively non-sensitive bulk traffic (B-tx).

An honest SPO is not a "rational slot leader". An honest SPO should be indifferent to the txs they place in a block/EB. If they act the way you say, they are being malicious by biasing the way txs get processed. Some SPOs certainly will, but of the 2,000+ block producers on Cardano, how many are acting honestly (i.e., indifferently) to the txs they see? In reality, I think it is actually very likely for valuable txs to appear in EBs. The only way this isn't true is if all SPOs start participating in MEV (i.e., acting "rationally" according to your definition).

→ All ordering-sensitive traffic (large swaps, liquidations, oracle updates, competitive mints etc.) is automatically forced into RBs and retains exactly the same front-running resistance as Praos.

This would actually be terrible and completely undermine the benefit of Leios! You are basically saying only normal sending/staking txs can go in EBs; all DeFi txs are relegated to Praos blocks. Yet the overwhelming majority of txs will be DeFi txs. So the demand that actually needs the higher Leios throughput is stuck with the 90 kb block limit of Praos! What we need is exactly the opposite of what you describe.

The incentive to skip still exists in theory, but is negligible in practice:

Skipping only pays if the stolen value > total EB fees
→ expected to be extremely rare.

I don't think this is realistic either because it ignores the fact that the EB fees are split among the entire newtork (delegators + SPOs). An EB of about 10 mb could hold about 600 txs. If each tx pays a fee of 0.2 ADA, that's 120 ADA for this EB. This SPO's share is likely less than 1 ADA.

Now consider a DeFi order book where the limit orders can be chained together like this. This arbitrage opportunity would be a single tx that easily pays more than the fees from an EB. So in reality, profitable opportunities will likely be quite common.

Truly heavy workloads are almost always non-sensitive (B-tx)
→ no reason to skip.

Are they? IMHO it is the opposite. The valuable txs are always DeFi txs which are always heavier than the normal txs by virtue of the latter not using smart contracts.

---

Please lmk if I am misunderstanding something. If my understanding is correct, this seems like a pretty serious design flaw...

[colll78]

Per-transaction Plutus budget is raised ~10× globally
→ most currently-tight scripts now fit in RBs.

This is unsound. We cannot raise the per transaction Plutus budget for Leios so long as the network can be attacked such that it reverts into Praos and the raised budget doesn't apply to Praos.

[pagio]

@fallen-icarus Thanks for the explanation. I admit I understood your suggestion to be to have this mechanism run inside the protocol. I find you idea really interesting and think that this could be part of the solution.

Having said that, with any type of such a mechanism/social contract one should be careful to avoid making it gameable. E.g., in a situation where SPO participation is somewhat low and a malicious SPO controls the certification process (say the certification threshold is 60%, the honest parties control 58%, the attacker controls 3%), the attacker can decide which SPOs get to see a certified EB and which not. Further, by strategically releasing its votes late, it can make it look as if a certified EB was available to the targeted RB producer, and lead people moving out of the target pool.

[fallen-icarus]

I completely agree about the game-ability risk. However, AFAIU, doesn't Cardano's private leader schedule prevent the attack you mention? How can the attacker target anyone if they don't know who will make the next RB? If the attacker signs the cert and sends it to even a single honest SPO, wouldn't it just get propagated to everyone else automatically? So wouldn't the attacker need to withhold the cert from everyone? But if they did that, can't the honest SPOs corroborate each other that they never saw a cert that met the threshold in time?

[pagio]

If the attacker signs the cert and sends it to even a single honest SPO, wouldn't it just get propagated to everyone else automatically?

@fallen-icarus Propagation is not automatic. It takes some time for certificate to diffuse around the network. This is the window an attacker would try to take advantage off, by sending his votes (and thus the certificate in some sense) at the right time to say half the network see it as on time and the other half see it as delayed.

doesn't Cardano's private leader schedule prevent the attack you mention?

The attack is based on the attacker observing the block and then reacting (i.e., voting). So the private schedule does not help much in this case.

[ch1bo]

I like that we are exploring multiple solution ideas and tread lightly how to improve the situation here, for any incentive changes (or even changes to chain selection) would often have bigger than anticipated impact in system dynamics.

---

Also, may I draw attention to the recently updated threat model of linear leios in which you find characterization of various threats including "omission and manipulation" as well as "data withholding", both should cover what has been mentioned in the last couple of comments. Note that it only covers the protocol as-proposed and any additional incentive mechanism would need to be considered in this framework too. Looking forward to any contributions to this!

[fallen-icarus]

@pagio The attack you describe would not work in the system I am imagining. Consider an entirely off-chain Mithril-based Availability Monitoring system. Whenever an RB contains txs instead of an EB cert, a poll can go out to all SPOs: "Did you see an EB cert that met the X% stake threshold before it was time to produce that RB?" To declare the RB producer's action as malicious, the poll would need to achieve the same stake threshold as the EB certificate itself. So your scenario would fail because the poll would not meet the required threshold of "Yes".

Some important points about the monitoring system (as I see it):

• It is purely off-chain. It has no impact on consensus and requires no changes to the Linear Leios protocol.
• It is for observation only. It is just a community tool for logging and transparency.
• Data can be pruned regularly. The results are only needed for short-term accountability. We don't need it to replay the chain.

This mithril-based polling system may also be useful for observing other parts of the distributed system.

[rphair]

@will-break-it @ch1bo this PR ended up back on the CIP Meeting agenda yesterday from this CIP Discord response — and though a Leois CIP PR general review didn't take place as expected, we did submit this question that was offered as a review topic:

how the recent Mainnet incident has affected experts' view of finality and how the proposed changes would have affected the nature of response that was possible

The consequence of the different approach to finality in this version of Leios, if I understood it correctly from those at the meeting who responded (including @Ryun1), would have been that the erroneous transaction at the root of the "Mainnet incident" could have been accepted as final and might therefore have become a permanent chain feature that other tooling (db-sync I think was mentioned to have difficulties) would have had to work around perpetually.

This made the editors consider that at least the comparison of different approaches to Leios — especially as they would shorten times to finality — should be included in the CIP under perhaps a heading of "disaster recovery" or other failure scenarios in which this might be considered a disadvantage rather than a pure advantage.

[ch1bo]

@rphair Thanks for bringing this up here and sorry again for not being on that call, I could have given my viewpoint in the meeting already:

Leios, as currently proposed, does not change the chain selection rule. That means that existence of a certificate would not bias a node whether to select one or another chain.

Concretely for the mainnet incident:

• I'm not sure whether there was 75%+ online stake on the pig chain (including the too long hash) for a certificate to reach threshold, but let's assume there was
• This would just have made the pig chain have more transaction capacity while blocks are built for it.
• As the stake moved to the chicken chain (running nodes without the bug), would have quickly made that fall below the threshold and eventually not produce blocks anymore (chain quality dropping).
• Then, once the chain on chicken grew longer than on pig, the chain selection rule would have picked the longer chain.

In conclusion, my understanding is that all of it would have exactly worked the same way with Leios as it were with Praos alone.

CC @Ryun1

---

That being said, I very much think that Peras (CIP-140) could have had an influence: In my understanding, boosted chains are preferred in chain selection and reduce the number of blocks until finality (a fixed 2160 blocks on mainnet Praos). However, we saw chain quality drop significantly on both chains during the incident and I think there is a requirement for certain chain quality of Peras to be active.

Anyone please correct me if I'm wrong, ideally on a new discussion thread about Peras, for it is out of scope here.