CIP-0177? | Ouroboros Tachys - Faster Cardano partner chains#1149
CIP-0177? | Ouroboros Tachys - Faster Cardano partner chains#1149dcoutts wants to merge 17 commits intocardano-foundation:masterfrom
Conversation
Initial draft of a new CIP
|
From a pure consensus perspective I understand the rationale and it makes sense. I wonder if we shouldn't consider the impact of a public schedule on other attacks, as it gives total guarantees to an attacker on when they will benefit from a favourable schedule. What is more questionable to me is the need of integrating the complexity of a variant that isn't targeting mainnet as part of the main code base. The CIP mentioned a partner chain settings or eventual independent chains that would benefit from the different tradeoff. For these reasons, I think this variant shouldn't be standardised as part of the CIP process. A PR to the Cardano-node could make the required modularisation to enable reutilisation of the codebase at "no cost" outside, with a lighter burden for the Cardano codebase. It isn't a quality concern, it's a relevance one. |
|
Thanks @berewt. As you know, I am not a commercial person, but as I understand it, the value proposition to Cardano users / ada holders looks like this:
This CIP is only one building block. It does not attempt to cover the full story of partner chains, including bridging (which is part of the mechanism of such partner chains). If one accepts the argument that it's useful and of benefit to Cardano, then there is clear benefit to having a CIP to ensure interoperability between multiple Cardano implementations that want to support this protocol variant.
I realise this isn't something we can demonstrate yet, but my expectation (having spent quite some time on the design and reviewing the existing Haskell node consensus code) is that the changes involved will not be a great upfront cost and will be a minimal ongoing maintenance cost.
The code is already highly modular. There is a type class for (Ouroboros shaped) consensus protocols. Praos is one such instance. Tachys would be another. This is part of why I think the development, integration and maintenance costs will be reasonable. |
rphair
left a comment
rphair
left a comment
There was a problem hiding this comment.
@dcoutts @berewt I would be in favour of including this in the CIP process mainly for the reasons that @dcoutts responds with: which were similar to my own impressions after reading the introduction earlier. That will be one of the first review points of course: to ensure the other editors agree with me about it being within CIP scope.
I'm marking this for Triage for introduction & review of these basic properties at our next CIP meeting: https://hackmd.io/@cip-editors/128
Especially given that we have other Ouroboros extensions & variants that might not be guaranteed to reach the Mainnet (e.g. CIP-0161) I would definitely argue that partner-chain schemes like this should be considered among Cardano's capabilities for commercial & perhaps academic purposes.
@colll78 @ch1bo it would be great if you could bring your perspective on partner chains (and other technical impressions) to this CIP review & spreading the word about this PR in case others are interested.
rphair
added
State: Triage
Yes, partner chains exists already (or are about to, as Midnight is about to launch), and can indeed bring it. On (3) though, I would advocate that if it's through from a tech perspective, one could argue that it was the major reason of the economical struggle of Ethereum, especially when L2s offer very similar services than the L1.
But the whole point of partner chains should be to foster diversity. I would understand that we specify how they interact with Cardano, but the specification of their internal, if any, is a matter of the specific chains that use a specific variant.
I agree that the change shouldn't be that impactful. At the same time, integrating it in the core of Cardano means that it's one more variant to consider for every change. I take as an example the section of the CIP about the upcoming extension to Praos. Do we need to add a thorough analysis of the impact of Tachys to all the consensus overlay/changes in the consensus protocol in the future?
It reinforces my idea that it could live in a separate codebase, don't interfere with Cardano, and not be a CIP. |
There was a problem hiding this comment.
Thank you, @dcoutts, for the CIP. I appreciate that this has been written by humans—a good read!
Am I correct that this is experimental work and the goal of this CIP is two fold;
- Get feedback on the proposed consensus/ledger changes of Tachys?
- Do a temperature check on what non-mainnet code can be added to the Intersect-owned codebases (and thus maintained by them)
For 1, could you please specify what security model you are aiming for? Given that there is no spec yet, it's difficult to make definite statements, but I think that by making the slot leader schedule public, we break adaptive security in general, as an adversary knows what will happen. And with that, possibly many security properties that we rely on currently in other parts. An example of such a property is grinding on the randomness, but I expect more things to break.
Also note that in CIP-0084 we have some requirements, one of which is
Though proposals can be accepted solely on the basis of peer and Ledger team review, some areas (e.g. changes to the incentives model) might only considered ready for implementation if accompanied by an opinion from an expert designated by the implementor (e.g. with a proper game theoretic analysis).
Though it is not explicitly mentioned (perhaps we should @lehins @WhatisRT ?), the latter requirement implies some indication of the security of the changes. Now it might be that you are not aiming to add this level of security, since this is an L2, but making that clear in the document is important. An open question that I would like to pose to the ledger reviewers is, would we allow the addition of possible insecure code that is never used on mainnet? My fear here is that it introduces a false sense of security.
For 2, let me start by saying that I think this is also a governance question. And as a CIP editor, I do not like to touch this much, as I am not elected via that. Thus, I would just like to ask a question to highlight a nuance that I see. Given that this CIP gets implemented, should mainnet code be blocked by possible incompatibilities (this is a hidden risk) with Tachys?
Lastly, in many CIPs we argue the need for certain changes by explicitly mentioning which parties will benefit from a change. Examples of this are CIP-0127 (RIPEMD hash) or CIP-0133 (MSM plutus builtin). Does this CIP also have a partner chain in mind that needs this change, or is this just there to facilitate any partner chain in general?
|
|
||
| The Tachýs slot leader schedule assigns a single SPO identity to each slot within an epoch. This can be computed independently for any slot number within the epoch. It works as follows. | ||
|
|
||
| For a given epoch with a known epoch nonce, and for a given slot number we compute a pseudo-random sample value. This sample value is used to select from a (cumulative) stake distribution, to determine an SPO identifier. |
There was a problem hiding this comment.
Making the slot leader schedule public breaks adaptive security. This opens the door to grinding attacks where an adversary can influence the epoch nonce, which Tachys still relies on.
There was a problem hiding this comment.
Just to make this attack more concrete: In Praos there is a cutoff point in the epoch (I believe at 3/4 of the epoch), and all the randomness before it is used for the next epoch. If I know who the last person will be to add to this randomness, I know exactly who to corrupt to influence it.
There was a problem hiding this comment.
I think it would be great to explore this and I'd be happy to add a subsection with our explanation. Ideally I'd like to explain it so that other readers will understand it, which I appreciate is hard since it's a technical topic.
I'll try and draft something and see what you think. In particular I'll start with trying to explain what adaptive security is in the first place (with static and adaptive adversaries).
There was a problem hiding this comment.
Nice, so far I think that your definitions about what currently is running on mainnet, like the clear separation of authentication vs authorization, are great!
There was a problem hiding this comment.
cc @nhenin @rrtoledo (in case interested in presentation of grinding issue & Phalanx itself) https://github.com/dcoutts/CIPs/blob/dcoutts/ouroboros-tachys/CIP-XXXX/README.md#relationship-to-other-proposed-ouroboros-protocols
There was a problem hiding this comment.
And this relates to my remark about whether we should add something to a code base that models a different (stronger) security model, as it gives a false sense of security (not a good practice).
It is worth noting that the existing reference implementation of Cardano includes code for several different protocols, with different security models:
- PBFT -- "permissive" BFT: a transitional protocol used during the Byron reboot. The early part of the mainnet chain is validated using this protocol's validity rules.
- TPraos -- "transitional" Praos: a transitional protocol used during the Shelley era while SPOs were still coming online. It combined a BFT round robin schedule for "core" block producers with a Praos private slot leader schedule, with a parameter to control the fraction of blocks from each. Thus this had a partially public / partially private slot leader schedule. This was also therefore not secure against an adaptive adversary that corrupts the old core block producers.
- Praos
- OBFT -- Ouroboros BFT, but actually just a cut-down simplified version, not the one from the paper. It just uses the Ouroboros longest chain rule in combination with a round robin schedule. Obviously this is only intended for use against a 30% adversary.
The first three of these are used on mainnet (for current or historical parts of the chain). Anyone can use them in the older era in test nets or partner chains. Hopefully they are aware of the security trade-offs! I don't think we make this as clear as we could do.
IMO, following the Unix philosophy, cardano-node should focus on one thing and do that really well: securing the Cardano mainnet. We have a great history of taking security seriously and being the slow but methodical chain; let's not throw that overboard.
Obviously we've always taken security seriously, but with accommodations and compromises to practicality and resource constraints (see for example the ongoing saga with the lack of proper KES). I would say we don't follow a Unix philosophy of do a single thing, but rather we always tried to make the code modular. This allows multiple protocols, multiple ledgers. And we have taken advantage of that flexibility, even on mainnet by having several variations over the years. We also originally designed the code with non-mainnet applications in mind. We demoed a "pokemon" ledger, and as noted above the code includes a BFT demo protocol. This has been carried in the codebase for years without significant maintenance cost (because the code is structured in a modular way).
There was a problem hiding this comment.
The first three of these are used on mainnet
FWIW, I have just recently asked in the consensus working group why there is still block production code for old consensus protocols (and the Byron era). It's entirely possible that things that are not needed to re-validate mainnet to be dropped from cardano-node (the implementation you have been speaking about here I suppose). And if OBFT was never used, that is a good candidate of code to be dropped too. (I just opened an issue about it)
There was a problem hiding this comment.
Hi everyone, I saw you started talking a bit more about grinding so I thought that I could give my opinion there. :)
Regardless of whether the adaptive security model is realistic or not, and even without relying on this model, we demonstrated in the CIP with @nhenin that grinding attacks are possible. We did so without full knowledge of what the adversary can and want to do (can they DDOS, corrupt... ?), only with some probabilistic analysis.
The 50% limit is simply a limit/hypothesis chosen to prove when you have security. It does not mean there is a "hey no fair" rule in practice of course, simply that theoretically we do not know how much and cannot guarantee security when an adversarsy has more, and so restrain the security argument to that case. You have to put a limit somewhere if you want to argue about security and come up with an efficient protocol, that is pretty much all that there is to it.
For grinding more specifically, you can grind with much less stake than that. The chances of having a "natural", "passive" grinding attacks become superlinear after 20% or 30% stake iirc. But there are "active" ways to increase your attack chances (by snowballing over several epochs, not considering consecutive last blocks but simple majority over a period if you fork, etc.).
Public elections are inherently more risky in blockchains as you have more information. If you think with the adaptive security model in mind, the adversary does not have to corrupt someone at random but can target it directly. That is much easier and effective, but still might not sound really realistic.
For grinding attacks more specifically, we do not need something as strong as corruption though. Simply DDOSing enough block producers, or preventing block transmission for example, to get a a high enough majority of blocks at the end of an epoch is sufficient.
To stress it again, we technically do not need to own the last consecutive blocks at the end of the epoch for a grinding attack, a majority of block at the end is sufficient. Knowing who are the block producers, the adversary can increase their majority efficiently and have their blocks be the de facto blocks ones (for instance by DDOSing block producers or preventing block transmission).
There was a problem hiding this comment.
Thanks @rrtoledo. I should say that I've always been an advocate for the anti-grinding approach. Indeed I've often argued that we should just do anti-grinding and not bother with Peras (which has much higher cost and complexity). I read your Phalanx CIP recently. It's great to see this work progressing well. It should be a good complement to Peras, and I think should also complement Tachys well too.
My "hey no fair" comment was not about a limit in general (which is of course reasonable) but about contrasting the awesome power of an adaptive adversary with the existing 50% assumption. An adaptive adversary is so powerful that it makes the 50% rule look like an artificial limit (which it should not be since corrupting parties should actually be hard).
I totally take the point about DDoS and grinding, and that not requiring compromising parties. We make the point in the CIP text that alternative DDoS mitigation is necessary when giving up the DDoS mitigation of a private schedule (though this is already needed for smaller networks with fewer validators). I didn't want to make this CIP be about how to operate a partner chain in general, but perhaps it's worth outlining how alternative conventional DDoS mitigation can work in smaller networks.
To stress it again, we technically do not need to own the last consecutive blocks at the end of the epoch for a grinding attack, a majority of block at the end is sufficient.
Oh. I missed that bit. If a party that is not under the attacker's control makes the final nonce contribution before the running nonce is frozen for the next epoch, how can the attacker predict the leader schedule and then make choices? By the time the last nonce contribution is made (not by the attacker), the attacker doesn't get any more choices. I'm missing something.
Do you want to speculate about the combination of a public leader schedule with effective anti-grinding measures? That might be informative to the discussion here.
There was a problem hiding this comment.
My "hey no fair" comment was not about a limit in general (which is of course reasonable) but about contrasting the awesome power of an adaptive adversary with the existing 50% assumption. An adaptive adversary is so powerful that it makes the 50% rule look like an artificial limit (which it should not be since corrupting parties should actually be hard).
Oh sorry, I misunderstood what you said then. That's the limit of writing vs speaking. :)
I totally take the point about DDoS and grinding, and that not requiring compromising parties. We make the point in the CIP text that alternative DDoS mitigation is necessary when giving up the DDoS mitigation of a private schedule (though this is already needed for smaller networks with fewer validators). I didn't want to make this CIP be about how to operate a partner chain in general, but perhaps it's worth outlining how alternative conventional DDoS mitigation can work in smaller networks.
I understand. DDOS mitigations are for sure necessary but I am unsure whether they are enough on their own. Attackers have the initiative (zero-day attacks) and defence is often only reactive. That is why having a careful analysis, of the security of course but also potential reputational and economical risks, is crucial.
Oh. I missed that bit. If a party that is not under the attacker's control makes the final nonce contribution before the running nonce is frozen for the next epoch, how can the attacker predict the leader schedule and then make choices? By the time the last nonce contribution is made (not by the attacker), the attacker doesn't get any more choices. I'm missing something.
The attacker could simply create a fork in private. Since they control a majority of blocks, this would be the longest chain and would be recognized as the main chain. To avoid getting contibutions on top of it, they only need to reveal it at the right time, that is after the last contributor appended their contributions to the other fork they are aware of.
Do you want to speculate about the combination of a public leader schedule with effective anti-grinding measures? That might be informative to the discussion here.
I am afraid that I am not a consensus expert, so this would be uncharted territory to me. Anti-grinding measures aims only at increasing the cost of grinding attacks, to render them economically inefficient. This does not mean there are no other attack vectors though. On top of my head, for instance, this additional information could help an adversary in preventing the generation of enough VDFs that the network cannot catch up and so breaking (part of) anti-grinding. I am not saying this is a siginificant risk, but it is a (perhaps negligeable) possibility.
|
I'd like to weigh in from an ecosystem perspective, as someone working on Cardano partner chain infrastructure at Apex Fusion. |
|
Thanks @FilipBl4gojevic for the answer :) I'll add another review once the spec is more refined and defines the security model it is aiming for.
Not demanding, just interested and suggesting 😀 The CIP process is an open process; I am here to facilitate that. |
|
I meant demand like market demand, not that you are demanding 😄 |
And use only latin script for the title: Tachys rather than Tachýs. This is to aid searchability. Though for now we'll continue to use Tachýs in the body text.
The standard form is for a license statement to be included as part of the copyright notice.
CIP-0001 calls for long section names for the motivation and rationale, and the order of the sections is significant. I had originally put the rationale after the motivation and before the specification as I thought the argument flowed better that way, but following the standard template is important. Put the table of contents in a collapsible section.
Suggestion from Thomas.
It was so far the decision for any work that wasn't critical for the maintenance of the node: we need to keep in the codebase what is need for Cardano mainnet operation, and this only. I don't see how having it outside of the code base can be a worse alternative.
Which makes the maintenance cost of Tachys clearer, and decoupled from the cost of the L1. If the fork drift, it's an educated choice of the Partnerchain ecosystem to drift.
Yes, it is a tokenomic issue I agree, but again, we start with the technicalities, from a perspective that will objectively leads to L2 very similar to L1, without having the beginning of a tokenomic proposal.
That's where I strongly disagree. As clearly stated in the CIP, it doesn't aim to replace the Cardano consensus. It's an Ouroboros variant, but not a Cardano one. These partner chains, at the moment, have no connection to Cardano, may never have. But it still put a burden on Cardano
I don't say that you don't want a standard, I say that it isn't related to Cardano. Looking at Apex here is what I can see on the Apex fusion main page "At the core of Apex Fusion's ecosystem lies the layer 1 Prime Chain, the beating heart of Apex Fusion."
It's a modularity problem. If we consider only the mainnet variant in future upgrade, we can compose networks that are insecure, which would be highly damaging. I suppose that this is why @dcoutts mentioned the relationship of Tachys with Phalanx, Peras and Leios, to prove that the addition wouldn't be harmful (and that would still need to be investigated further as pointed out by @perturbing)
I would love to get clarity on this. As I stated earlier, the Apex Fusion narrative is explicitly to build an L1 at the core of its ecosystem. The more I read it, the more it sounds like "Apex wants to peg on the Cardano ecosystem to fund its roadmap, and tangently, Cardano will benefit from it". It's okay, there can be synergies, but it isn't a reason to put the maintenance burden on the ecosystem, which this CIP opens the door to. |
I think this discussion suggests that there is a section of the motivation that is missing and that I should add. As the CIP already states, a motivation for Cardano-Cardano partner chains is to gain the benefits of reusing the existing software to run the nodes and the large ecosystem of other software for using and interacting with the chain. This is a massive cost saving and allows relatively poorly resourced groups to deploy partner chains. But an (unstated) corollary of this that people deploying Cardano-Cardano partner chains want to be able to maintain compatibility with mainnet on an ongoing basis. They do not want to freeze all the tools at a single point in time and then have to carry the maintenance burden of those tools from that point onwards (which in any case may be impossible for tools that are not self-hosted). This means it is not sufficient to simply take the code base of one of the existing Cardano implementations, add in the extra protocol and go off into the glorious future without perturbing the "main" codebase any further. Cardano-Cardano partner chains need to be able to follow future hard forks on mainnet (with some reasonable delay) so that they can take advantage of new features and to maintain ongoing compatibility with the tooling and DApp ecosystem. This means that to minimise overall community maintenance costs Tachys does need to be integrated into one or more mainline code bases. Of course the modularity of the existing node codebases and the relatively surgical nature of the changes involved means the shared maintenance cost should be very low. Maintaining the changes externally would be a much higher overall cost and would raise the barrier for people to try out partner chain deployments. |
I would not say this is experimental, but rather this CIP is the first public step.
|
|
It's worth pointing out that partner chains using the Cardano mainnet tools is a win-win situation. Partner chains obviously reduce their upfront cost. But it's also beneficial for Cardano: a wider user base makes it more attractive to develop tools, maintenance burden can be shared, and innovations triggered by partner chains feed back to Cardano. It's the classic benefit of the open source model. |
|
I think these latest points summarise my concerns. If the partner chains models is "we built for cheap on top of your codebase, to do so we put an extra burden on your standard, but you'll be rewarded in tooling", it's a no go for me. But even fixing this doesn't make the idea of introducing another block schedule in the same codebase move away. We're basically introducing a software product line on Cardano, which is known for its testing complexity and challenges. |
dcoutts
changed the title
|
@berewt It's totally reasonable to be sceptical of the partner chain model. For my part, I'm still sceptical about blockchains generally. I still work on them because I hope they will become clearly socially useful. A lot of other very smart people are very keen on the partner chain model though. In particular IOG is betting its future on one such partner chain. And in the Ethereum world, Vitalik is declaring that partner chains are the way to go, over other L2 solutions.
If that were true I would agree with you, but I think it's not. The argument (made by other smart people, not me) is that partner chains, like other L2s like hydra & midgard, are directly useful. It's not merely about spreading development/maintenance costs. The argument is that an L2 and parter-chain ecosystem brings utility and demand to the main chain too. Traditionally that improves the price too. But I think we are getting off topic. I would humbly suggest that this is a business / social question that should ultimately be decided by the DReps, not by you or me. The DReps are in the proper position within the community to take a view on whether it is worth Cardano following a partner chains strategy, and funding and maintaining it. In this CIP context our scope should be about whether this is a clear, sane self-consistent specification. Whether we all agree it's a good strategy is very interesting but ultimately has to be decided in a different forum. I would appreciate your opinion on my suggestion above to add an additional subsection to the motivation. |
|
@perturbing When I first started looking at this topic I tried to find the protocol that your colleagues worked on some years ago with a public leader schedule. As I recall, it was work done some time after Praos was published and the idea was that it would be complement to Praos, but with a speed/security trade-off from using a public leader schedule. And of course it had a cool Greek name which meant something like "fast". I talked to Alexander Russell but he could not remember anything about it. Certainly it never got as far as a paper. I think it got dropped due to lack of interest/demand. Perhaps you can talk to your IOR colleagues and dredge up anything on that project. It might help us all greatly with the adaptive security issue. |
I am not sure; I was not around when the ancient texts were written ;) One interesting paper that comes to mind and was published after that time, is this one; this might spark some insight. It's on the boundary of committee selection without randomness (public) with the addition of a smaller group performing some lottery. I believe that this has both a local variant and a global one. @bwbush might know what the global one is (or if I am entirely wrong). |
|
This is a very minimal, but high impact idea. If people want to take partner chains seriously, this is as clear of a win as I can imagine. The hard work to abstract the |
|
Okay, so let set aside the discussion on the value of partner chains, and economical aspects. Cardano might benefit or not from these partnerchains, it's (at the moment) unknown. As I read you, it's not a big engineering and maintenance burden. A suggestion then would be to enable it for a few partnerchains, through a fork. Then, once the benefit of mutualised maintenance is proven, we can merge it. It would solve my problem about adding complexity for a feature that can be implemented out of the critical path. Such a roadmap could be added to the implementation plan. |
|
This is the tradeoff that every chain which specializes in throughput (bandwidth and latency) makes. Solana, Tempo, and so on, if you want to maximalize throughput you need to publicly broadcast who the block producer is. While the exact approach in this CIP may not be sound to introduce to the Cardano mainnet, it certainly is possible to have a publicly known block producer without substantial sacrifices to security / DDoS issues. In practice, how this is achieved is not via theoretical security (because the issues are inherent to the design of revealing the block producer and thus unavoidable from this perspective) but instead from practical security engineering. In practice, you can mitigate DDoS attacks using many of the same engineering techniques that are used in traditional distributed systems software. I encourage that we give this some thought and consider trading off the private slot leader property for Cardano as I don't believe the value provided by this property justifies the sacrifice in bandwidth and latency. |
|
While I appreciate the motivation of this CIP, it seems to make an implicit assumption about the future: many L2s and partner chains will actually want to be "cardano-like" (e.g., Plutus, eUTxO ledger, etc.). I've been arguing for a long time that most L2s and partner chains should specialize to specific niches: Midnight for privacy, Hyperliquid for HFT, etc. Economics is all about specialized entities working together; a heterogeneous system. Yet this CIP seems to be implicitly arguing that there is significant demand for a homogeneous system. I don't share this belief and I think the empirical evidence backs me up: it has been years of faster general-purpose L2s and yet blockchain is arguably no closer to mass adoption than 5 years ago. Conversely, Hyperliquid launched as a specialized layer and captured a huge market share very quickly. It might be harsh, but I will go so far as to say: most fast general-purpose L2s have a bad product-market fit. If we implement this and most L2s and partner chains opt not to use it because that is what is best for their product-market fit, this would be a waste. My stance is we wait on this until the market clearly starts demanding it (i.e., many more than just Apex). Please lmk if I'm misunderstanding something. |
We absolutely so want a heterogeneous system. Your belief that L2s and partnerchains should specialize to specific niches is not in conflict with that at all. You can specialize for a specific niche and still build on the same core-stack. You can have a huge variance in features and functionality while building on the same core tech stack. This is exactly the core contribution that L2s and partner-chains provide to the L1, namely, that they all contribute to the same infrastructure, and same core tech stack, when a sidechain or an L2 makes a novel innovation or improvement on the underlying tech stack, if the impact is meaningful those innovations are propagated upstream and eventually make their way into the L1. Hyperliquid has around 4b TVL, this is a drop in the water compared to Arbitrum, Base or other more aligned L2s which contribute directly to the progress of the L1. We absolutely should encourage L2s and partner-chains to develop on the same core-stack and keep their niche features modular and compartmentalized so that all the money that goes into the improvement of infra and tech in these chains, by construction, goes into the improvement of the infrastructure and core tech stack of Cardano. |
rather than partially addressed for a related context. There's a view that these CPSs are specifically for mainnet and it confuses matters to interpret these problem statements in the context of Cardano chains other than mainnet.
@berewt I have updated the abstract and a second reference to one of the CPSs. The only references to the CPSs are now the following: In the abstract:
In the motivation:
and
and in the references section:
|
|
@berewt I'm not sure how to address the rest of your concerns you express above about confusion with partner chains vs main chain. It is simply something we'll have to deal with collectively. But I'm optimistic that that's totally doable. It would appear partner chains are coming, and we'll have to manage. The DReps recently approved the Intersect product committee's Cardano 2030 vision:
That includes several L2 / partner chain things. Quoting all the relevant excerpts I could find from the vision doc above (2nd link):
As this CIP says in its motivation, the use cases for L2s like hydra/midgard and L1-as-L2 / partner chains overlap quite a bit. And with greater throughput and lower latency that overlap is greater and there's more cases where the partner chain approach can fit the use case. And the L1-as-L2 approach brings lots of the advantages that L1s already have. The vision doc above for example mentions L2 solutions with L1 security. This is obviously easier to achieve by using L1 tech. And furthermore, partner chains already exist and more are coming. There are two in Apex Fusion, Midnight is coming. I understand that Charles has been advocating partner chains heavily and I understand IOG expect Midnight to be their first partner chain but not their last. So I think it's something we just need to deal with, and try and make the tech as good as we can. |
I'm deeply sorry if I didn't convey my opinion wrongly. It is not about being against partner chain. It's just that what is described here isn't a partner chain. It's about a different slot ownership mechanism, that has nothing to do with the main chain.
That's my major argument against the fact that we can use the term of partnerchain at this stage within this CIP. It introduces no connection to the L1. It may come with further CIPs (and introduces extra complexity to the codebase) but it isn't there yet.
It isn't a L1 as L2 approach. It's a "let's add complexity to Cardano to enable creation of others L1s and maybe they'll be L2" approach. Which again, could be avoided by modularising the node and enabling the slot ownership change outside of the codebase.
And they exist without CIPs, which proves that it's possible. |
|
@kevinhammond, in the CIP editor meeting I mentioned you can ping me; please do so via GH to keep it public (I do not wish to be in the Apex Fusion Slack via my work email). Just for clarity, I hope I did not give the impression that I am willing to work on improving this CIP, just as a reviewer. As I said before, once this work has progressed, I'll happily review it again. |
|
Hi @perturbing . I really wanted to set up a short call so we could sort out exactly what you wanted in a security model, since I think you have something specific in mind (rather than a general threat model, which will be application-specific to a greater or lesser extent - each partner chain will have its own risk profile). That will be faster than iterating via GH (with the risk of misunderstanding/confusion). But if you prefer to discuss it here or we allow sufficient time for a detailed discussion in a future CIP editors' meeting, that's fine, of course. I would say that it's interesting to have to consider non-mainnet situations. One size definitely does not fit all. |
|
@dcoutts suggests the question may mainly be about deployment assumptions (eg permissioned versus permissionless settings) and how they impact security assumptions. I think it's likely that many partner chains would be permissioned, of course (as with the initial Midnight deployment, or the Catalyst voting chain), but we can explore that |
|
In a comment above I outlined some of the main comments / feedback / concerns. I want to address some of them.
These two points are important and remain a live issue. Further thought and discussion is needed here, probably leading to some additions to the CIP text. @perturbing You have also asked for more detail in the specification. I appreciate that you've not wanted to be too prescriptive, but I would also appreciate if you could clarify what you're asking for (so we don't waste time doing things that are not useful). For example, our implementation plan says we will produce a formal spec delta, in line with CIP-0084. Are you asking for that to be included up front in this CIP?
The question of maintenance costs or friction within node implementations is an important one. While it is an important issue, I would argue that it is out of scope for a CIP discussion (except perhaps to the extent that changes to the specification might make implementations easier). The CIP is about the specification, not about node implementations. CIPs are not expected to prescribe the details of how to implement them, and do not oblige anyone to do so. It is an important issue for implementations however and there must be a point where the issue is addressed. There are two reasonable points where this can be addressed for the specific case of the node reference implementation:
My own expectation is that we will be able to demonstrate an integration strategy that other developers who work on the reference node's consensus layer will find reasonable. I obviously cannot demonstrate that right now. So it's hard to fully allay fears of maintenance costs at this stage. That's another practical reason why this CIP stage is not the right stage use as a check on maintenance costs. It can't be checked without doing most of the work (which itself needs a treasury proposal to do). And although we cannot fully demonstrate an integration strategy at this stage, we can solicit expert opinion from people who have worked on this code about their expectations given the spec. So far, that includes the CIP authors themselves and @JaredCorduan's positive feedback above.
There are two aspects to this:
Point 2 is out of scope for a CIP as discussed above, but should be considered along with the general maintenance question at the appropriate stage, as also discussed above. On point 1, this is much the same concern about any protocol CIP / extension and future ones. One reassuring aspect for Tachys is the minimal nature of the changes in the formal spec: just changing the schedule within the authorisation rule. This reduces the chance of accidental and unforeseen interactions. Another important point (related to point 2) is that we can't expect the "tail to wag the dog". That is, even within the context of an implementation like the reference implementation it would not be reasonable to block introduction of protocol changes to mainnet due to potential incompatibilities for partner chains. Nobody would expect that. As I argue above, right stage to discuss the costs, benefits and a maintenance strategy is when a funding proposal is put to DReps.
It is obviously the case that partner chains can (have been and will be) deployed without needing extra specifications. I think it is reasonably clear however that when there are variations that are used in partner chains that are not used on the main chain, then the deployment of such partner chains themselves will benefit from clear specifications, for all the usual reasons that specifications are a good idea, including:
One can also imagine useful informational CIPs on how to configure, parameterise and deploy partner chains. Since there's general consensus that L2s can bring value to L1 and ada holders, then having better designed and built L2s does that job better. So if specs benefit the quality of L2s and L2s can benefit the L1 and the community more broadly then L2 specs also benefit the community. Having L2 CIPs within the same CIP process (rather than forcing them to run their own process) gives wider visibility and more review. CIP-0001 says:
Up to now, that word "ecosystem" has been interpreted by CIP authors and editors (including formerly myself) to include plenty of things other than just the node or blockchain. It includes many wallet-related CIPs. It includes CIPs for interaction not just between wallets and the chain, but between wallets and users or wallets and other software (DApps etc). It includes CIPs about conventions on how to match up off-chain information with on-chain metadata (which is a very one-way dependency). These are all part of the ecosystem. One can easily imagine CIPs that could provide specs for L2s like hydra or midguard: for how they interact with each other (to allow multiple implementations to interoperate), or standards for how clients should interact with the L2. I think it's very likely there would be consensus that such CIPs are well within the Cardano ecosystem and within the scope of the CIP process. Partner chains are an evolving part of the ecosystem, but functionally they fall into much the same category as other L2s. The 2030 vision document that the DReps voted for clearly includes L2s as part of the Cardano ecosystem. One could imagine a scheme where the chain has one spec process, wallets have their own, and L2s or other categories within the ecosystem have their own. But that's not the process we have at the moment. We include everything together. In my view, that's the better approach for now: given the limited volunteer time and review bandwidth it's better to keep things together to reduce overheads, maximise visibility etc.
This is an interesting question but would be out of scope for this CIP. This CIP is about a protocol to use on partner chains, not an informational CIP providing guidance on how to deploy partner chains. Such a CIP would indeed be useful to the community.
See also the product committee's 2030 vision which has some points about how to help L2s and parter chains bring value to the main chain. These issues are beyond the scope of this CIP though.
The CIP text outlines the stakeholders, and for the most part those are also the parties that can benefit: anyone who wants to deploy or use a partner chain. It is not about any single party. It's part of an effort to make it easy for anyone in the community to deploy partner chains at low cost and with wide applicability, consistent with the product committee's vision of partner chains / L2 solutions. And indirectly, if the hypothesis that L2s can drive demand and return value to the main chain is correct, then ada holders in general can benefit.
In summary the answer is:
It would certainly be possible to deploy partner chains using a more-or-less permissioned model. As the CIP states in the motivation section, there are massive benefits to preserving ecosystem compatibility (tooling etc). So even though in some cases a protocol like BFT would be a more targeted solution, it would not preserve ecosystem compatibility. Stake-based protocols are flexible enough to encode/emulate permissioned schemes, which allows us to stick to just one general mechanism (the existing Cardano SPO stake based system). |
|
@berewt I'm genuinely struggling to follow your perspective.
Right this CIP does not describe partner chains. It describes a protocol variation to use on partner chains. Partner chains are related to the main chain and are part of the Cardano ecosystem, and are thus in scope for CIPs.
You're welcome to propose to the CF and the CIP editors that the CIP process should be split up into multiple spaces. That's not the process we have right now, and personally I don't think it would be a good use of scant reviewer resources. I'm unclear why you think that the existence of partner chains will add significant evaluation challenges to new CIPs, or why segregating partnerchain CIPs would improve that.
This is an implementation question not a specification question, so is out of the domain of CIPs.
I'm not introducing or defining the term partner chain. I believe it was Charles who coined the term. As I understand his definition, they very much have a connection to the L1. And I understand one of the reasons he chose the term "partner chain" was to contrast with the previous term "side chain": to emphasise the connection of the partner chain to the main chain. I don't see that it is necessary to first have a CIP to define what partner chains are. Though I do agree such a CIP could be useful to establish clarity and consensus. I would welcome such a CIP.
You're talking about implementations not specifications. Also, the CIP very literally is talking about the approach of using an L1 as an L2. It is exactly what the motivation section says. You're welcome to argue that there can be leakage and that it's also possible to deploy other independent L1s that do not act as L2s. That was true before this CIP and will remain true afterwards. Suppose, for the sake of argument, that consensus amongst the DReps was to fund partner chain implementations for the benefit of the community and that they decided the best approach was to do so by reusing the reference implementation libraries and making a different node implementation. The community would still want and benefit from this CIP. Nothing in this CIP text would change except the implementation plan. The specification would be the same. The implementation plan I wrote down is the one that I think brings to the community the greatest value and the lowest total cost of ownership. Thus, that is the plan that I would propose to the DReps. If the consensus amongst DReps is to fund a more expensive solution, then I would go with that consensus. In the first instance however the right thing to do is propose an approach that I (and my co-author) think has the best value for money for the community. Perhaps part of the difference in perspective here is that you are thinking about the node reference implementation as community owned and maintained, but partner chains as something "other", something that other people ought to pay for and hence any shared cost is freeloading. We (my co-author and I) do not take that perspective. We will propose to the community via the DReps to fund improvements to make partner chains easier/cheaper to deploy and to cover a wider range of use cases, to the benefit of anyone and everyone in the Cardano community. Thus we see partner chain implementation and maintenance as part of the total cost of (ecosystem) ownership for the community, rather than coming from a separate private pot of money.
This seems a facetious point. Obviously one can deploy partner chains without proposing specifications. The reasons for and benefits of specifications generally are hardly disputed, and we've set out the reasons for a specification of this protocol specifically. |
I know that you also referred to CIP-0001 to justify it. If we consider that every specification of every solutions in the ecosystem should be part of the CIP, and if everybody sticks to it, editors will cry. I would be supportive of clarifying it to change to Cardano or specification that helps the interoperability of the ecosystem. Interoperability standards matter to everyone in the community, implementation details of a specific solutions matters to the community that uses this solution and should probably not be there.
I thought I explained it already. This CIP would introduce a variation to the formal specification, to introduce a new variant. This variant being part of the formal specification, we need to consider the two variants (the main one and Tachys) for every further change. Would another CIP follow the same path, we'll have to do so for 4 variants. And so on.
In the context of the CIP process, you are.
You're right. But the CIP introduces a complexity that any implementation cannot easily avoid if they want to stick to the spec.
Without discussing how it relates to the L1? I don't see how it can achieve it. It's about how we can create a different network using Tachys, which doesn't have any connection to Cardano, aside the design choice.
The implementation plan is one of the motivation of my comments. The other, again, is that change to the formal definition will oblige us to consider the variant in future work.
No. I hope my explanation about my concern about variability makes things clearer.
It isn't facetious. The main question is whether the CIP process is the right place for partner chain specification. My point is that, so far, all the CIP were either on the definition of mainnet features or on interoperability features. We would have had a CIP for every the standardisation of every piece of software in the ecosystem, we would have been swamped under CIPs. |
|
I reread the CIP and gave it more thought, I am not convinced Tachys is secure as it’s currently formulated. The CIP reads like it’s operating in the same world as Praos: an open, hostile network where one really has to assume adaptive attackers. But the moment we make the leader schedule public, you give up a big chunk of what Praos's private schedule is buying you, and a few attack surfaces get bigger: Bribery / MEV: If everyone knows who’s producing the next blocks, bribery and censorship become much easier to target. You don’t have to throw lots of money at it; an attacker knows exactly who to lean on and pressure, and moreover, they know exactly when! Grinding: Grinding is a concern in both Praos and Tachys, but Tachys makes the consequences much more “actionable”. An attacker can directly look at the resulting public schedule, decide if it’s favorable, and then invest effort accordingly. Note that besides knowing that an adversary gets more slots, the adversary now also knows that someone honest gets fewer slots! In Praos, a lot of that stays fuzzy because leadership is still hidden behind private VRF outcomes. In Praos, the informational entropy is designed to stay high throughout the protocol, whereas in Tachys it does not exist (information is public). Off topic: 3blue1brown has a good YT video on this! For anyone interested, see " Solving Wordle using information theory" 🤓 Liveness: Public pool registration plus a public schedule makes leaders easy to target. And this “smaller topology” goal (to reduce Δ and run with a leader every slot) makes this worse, not better: fewer producers and less decentralization shrink the attacker’s search space and make sustained disruption more realistic. So I believe the problems above stem from the CIP mixing two different worlds: it sounds like an open, adversarial protocol, but it also leans on a BFT-ish deployment story (“small topology, few producers, strong ops”) that the protocol itself doesn’t enforce. That’s not a coherent stance. Either we explicitly adopt and enforce those deployment constraints, or we need to bring back some form of unpredictability / committee mechanism so it can stand up in a genuinely hostile environment. As I see it, and as the CIP itself describes it, Tachys is the result of the need to produce a cheap L2 (by wanting to reuse the code as much as possible), but in doing so, it creates an unsound L2. Perhaps it's good to try to make Tachys a permissioned system; that would perhaps solve the security issues, though that would imply more code changes and introduce incompatibility across mainnet tooling. You can't have it both ways in life 😢 And is a version of Hydra not a good fit for this? It has the aim to be a permissioned L2 that looks and feels as close to Cardano as possible ("isomorphic statechannels"). @Quantumplation is also working on a more persistent version of a hydra head that never closes. |
Thank you for exposing your concerns here, @perturbing. We'll discuss your points and respond properly once we have done so. Different use cases will have different security requirements, of course, and absolute security is not possible, so it's really a matter of finding the right balance against other desiderata (throughput, latency, finality etc). |
@perturbing I want to check we're on the same page. I think here you are referring to (D)DoS attacks right? Either from parties with or without stake. If so, then we are outside the realm of theoretical discourse, since Ouroboros Classic and Praos don't have this in their network model. They both allow the adversary to reorder network messages in each round, and Praos allows the adversary to delay messages by up to Delta. Neither allow the adversary to block messages arbitrarily. If we're in the realm of discourse of practical matters, then we can talk about the various (D)DoS prevention measures that are and can be taken in real networks. We're pretty confident that we have a good story on DDoS prevention, both for Praos (current mainnet) and Tachys. The effect of these measures is that any successful (sufficiently large) DDoS attack can prevent transactions and blocks being diffused between end users and block producers, but cannot prevent any honest block producer from diffusing blocks to all other honest block producers (within the usual Delta). Being adaptive doesn't help the DDoS attacker in this case: they still have to target all (or overwhelming majority of) relays to prevent users submitting transactions or receiving blocks. |
I don't believe this is a serious issue. The only thing you can really bribe them to do is reorder transactions in the mempool, and this is relatively useless in Cardano. 99% of malicious MEV is sandwich attacks, which are impossible at the protocol level on Cardano because the order in which DeFi intents are processed is determined at the dApp level not at the protocol level as they are on Ethereum. So really you could just reorder to determine who wins in a UTxO contention battle, and there are dozens of other ways a malicious party who is determined to win UTxO contention battles could do this for much cheaper. Also if an SPO was willing to accept bribes to reorder transactions, they could do that now, the current architecture doesn't have any defense against this, they could just choose to broadcast a proof that they are the currently elected block producer and are accepting bribes.
We make huge architectural sacrifices to solve DDoS mitigation at the architectural level (by keeping slot leader private) but DDoS mitigation doesn’t need to be solved at the architectural level. It can be solved at the engineering implementation level and that way we don’t have to make architectural tradeoffs for properties we can get at for free at the implementation level. The meta for modern chains is to have a public block producer; even in Ethereum, which is extremely conservative and heavily focused on liveness guarantees, the block producer schedule is public (derivable from the beacon chain state), moreover, most block producer broadcast when they are the current block producer because of all the markets around block-space supply. It's absolutely insane how much we sacrifice architecturally to mitigate a problem that has thousands of battletested mitigations that have no cost and are used in almost every piece of software in existence. Again I urge the CIP author or anyone to reframe the CIP as a proposal to make this change to Cardano directly. It doesn't make sense to have anything related to the consensus or architecture of partner chains in the CIP process. |
|
Here is a potential use case based on this CIP that could bring value to the L1 and align the CIP with the 2030 vision and strategy for Cardano. L1-Secured Partner Chains: Economic Alignment Through TachysThe public slot leader schedule in Tachys opens up an interesting architectural opportunity beyond the performance benefits described in this CIP. Concept: Partner chains could use Cardano mainnet's stake distribution to compute their Tachys leadership schedule, rather than bootstrapping independent stake. How it works:
Benefits:
Treasury integration: Partner chains could donate native tokens to Cardano's multi-asset treasury, enabling governance to fund development across the entire ecosystem using partner This creates a flywheel where partner chain success directly benefits L1 stakeholders, making ADA delegation more valuable and partner chains more secure. I've written up the full architecture with economic flows, governance integration, and implementation considerations here: Would love feedback on whether this L1-secured model is worth exploring alongside or instead of independent partner chain stake distributions. |
Yes, this is an interesting point of discussion. The security model does change, of course, but the tradeoff may be acceptable in practice (significant increase in transaction volume/fees and reduction in settlement time). DDoS at the network level might well be handled externally to the protocol as a practical measure (e.g. it can be made very difficult for pools that are using data centre infrastructure). With a public leader schedule, it also becomes possible to monitor pool behaviour (has it made the blocks that it was allocated?), and there are presumably no slot battles in the model that has been described and every block that is made on time should appear on chain (which should appeal to operators). |
This is absolutely one way that Tachys can be used and looks like a sensible suggestion to me. We will discuss this. I personally see it as a moral obligation for partner chains/L2s to deliver value to the L1. This seems like a good way to extract that value. |
Ethereum is currently considering moving away from the public leader schedule to a private one. Take a look at EIP-7441.
Using data center infrastructure should not be a requirement for being a Cardano SPO. Sorry to shill my own work, but any talk about making Cardano's L1 leader schedule public for throughput reasons needs to consider this post I wrote called Slow Blockchains are Better. It is getting really confusing figuring out if this discussion is about a public schedule on Cardano or a partner chain. If it is the latter, I would really appreciate it if the L1 discussion moved to its own thread. |
@fallen-icarus @dcoutts the editors & observers at the last CIP meeting also noticed that the discussions here have falled into these 2 distinct categories. It might therefore be appropriate that this CIP be divided into two: one proposal for the public schedule & another to promote the sidechain compatibility. |
This EIP is dead and is not being considered as part of Ethereum's roadmap. You can note that it was proposed in 2023-09-01 and has been marked as stagnant and is not part of any of the current roadmaps or even up for discussion at this point. |
I'll make sure this gets passed on. Obviously, any discussion of the protocol needs to consider its intended purpose(s), but there are definitely some broader discussions that have been opened up in the comments. Some of these might be addressed via eg the CPS process? |
|
@rrtoledo @perturbing I'm writing up a new section on security, and trying to do it justice. One thing this new section clarifies is that we assume a non-adaptive adversary (as in Ouroboros Classic). Our proposed model is that of Ouroboros Classic, with Praos-style Delta message delays (since that appears unproblematic). One thing that is not clear to me, and I hope you can perhaps advise me on, is the grinding issue. I was going to write that Tachys makes a trade-off in grinding resistance (and then talk about measures we can take to mitigate that). But actually it is not at all obvious that it does sacrifice grinding resistance, at least when we have a non-adaptive adversary. I reviewed the Praos proofs (to the extent that I'm qualified, which is quite limited) in Section 5 about the resettable leaky beacon and all that. It's not at all clear here where it relies on the slot leader schedule being private. In particular, the proof for Theorem 11 is pretty direct. It assumes the leaky beacon functionality with the r parameter. The proof relies on the usual blockchain properties of chain growth etc. Obviously the proofs of the usual blockchain properties for Praos assume an adaptive adversary and a private leader schedule, but it looks like the proof of Theorem 11 is sufficiently modular that one could substitute the equivalents for Ouroboros Classic (with the non-adaptive adversary and a private leader schedule). Then it goes on to prove that the VRF-based scheme does implement the leaky beacon functionality. In particular, the r-reset leaky beacon doesn't make any distinction about which blocks the adversary may try to use, it's just about r resets in total. It doesn't appear to make any assumption or argument about the unpredictability of successfully getting the last N blocks before the nonce is finalised, or anything like that. It's just about the grinding power of the adversary limiting the adversary to r resets. So as best I can see, this proof looks like it's independent of whether the slot leader is public or private. Do you think I'm missing anything here? An alternative way to implement the leaky beacon functionality could be to use the VRF scheme in combination with an anti-grinding mechanism. Use the VRF scheme to produce independent random samples. And then separately assume a limit r on the number of resets, using an effective anti-grinding mechanism. One would then hope to instantiate this with Phalax, paramaterised so that the number of grinding attempts matches up with r. This should give a fairly direct implementation of the r-reset leaky beacon and not depend on the choice of private or public slot leader schedule (assuming a non-adaptive adversary). So personally I speculate that it may be sufficient to have a non-adaptive adversary and have Theorem 11 still hold. But we will probably propose something more conservative than that. We're thinking of two alternatives: 1. assume an effective anti-grinding mechanism that limits the adversary to r-resets (which we would hope to discharge using Phalanx); or 2. assume only up to 20% adversarial stake (20% selected based on the analysis in CPS-0021). Thoughts or comments welcome. |
@rphair We welcome discussion on public slot leader schedules as it applies to Cardano mainnet. We would also encourage IOR to release its prior research on this topic to inform public discussion. @kantp and I feel however that at this stage it is too early to make any proposal about public schedules on Cardano mainnet. We are comfortable with the proposal in this draft CIP to use Tachys for partner chains. We do not at this stage plan to broaden the scope of this CIP to include mainnet or file an additional one about mainnet. (ed.: addressing latter part of @fallen-icarus #1149 (comment)) |
|
@disassembler writes:
This is a very reasonable idea. It's also very close to the design for sidechains that was proposed by the IOHK researchers many years ago (back when IOHK was aiming for trustless sidechains rather than trusted bridges). It's not a simple engineering task however. There were two basic designs that the researchers proposed at the time:
I always favoured the second design, and what you are suggesting @disassembler is very much in line with that approach too. In summary, I think it's a good idea that could benefit many partner chains, but it is an independent complementary idea. So it may well make sense to try it, but one would want to centre a project around it, and it would need its own CIP and funding etc. |
It is intended to be read with the same meaning as in the existing Cardano ledger spec docs.
Attempt to address the feedback that there should be clearer security assumptions.
|
@rrtoledo @perturbing @rphair We have added a major new subsection on security considerations. This subsection is now longer than the entire rest of the specification section! 😄 We have tried to address the feedback that there should be more clarity on the security assumptions. In particular we cover the issues of adaptive corruption, grinding and denial-of-service. |
|
@dcoutts that looks good & provides good support for the security-related topics that came up in online & meeting review. (cc @colll78 @ch1bo @kevinhammond who have also expressed opinions about these security topics) For reviewers, link to entirely new section (from new heading Security Considerations up to the same level heading No hard fork): https://github.com/dcoutts/CIPs/blob/dcoutts/ouroboros-tachys/CIP-0177/README.md#security-considerations |
13 participants
This CIP proposes a specification for Ouroboros Tachýs: a variant of the Ouroboros protocol that uses a public slot leader schedule. Compared to Ouroboros Praos, Ouroboros Tachýs would achieve higher transaction throughput and lower transaction finality times. This protocol is not intended for use on the Cardano mainnet, but for use in Cardano-Cardano partner chains: that is partner chains to the Cardano mainnet that reuse Cardano implementations but with different Genesis and protocol parameters.
The advantage of this Ouroboros variant would be a higher block production rate: approximately 4 times higher compared to Ouroboros Praos. This leads directly to 4x higher TPS and substantially lower transaction finality times. Although the protocol is different, for tools and applications that use the blockchain it would remain highly compatible, allowing the reuse of existing and future Cardano tooling.
The main disadvantage of Tachýs compared to Praos would be not having the DDoS resistance that Praos provides. For partner chains intended to have relatively few block producers, the DDoS resistance Praos provides is of limited benefit. Other forms of DDoS resistance are required, and are possible.
This CIP addresses the problems of settlement speed and transaction throughput for the use case of partner chains. These are related to the problems of settlement speed and transaction throughput for the Cardano mainnet identified in CPS-0017 and CPS-0018.
Rendered version of the latest document