Managing a Shared Ledger: New CIP-Like Process?

COSDpool · 28 April 2025 12:39

@JSHyCS it’s great news that you’ve joined the forum after introducing the community to the rapid progress towards alternative nodes. Anyone wishing to follow the more technical details of this can bookmark this candidate CIP and follow the links to related CIP and Ledger discussion:

CIP-0154? | Orthogonal Certificates #1021

Most readers would interpret this statement to mean the CIP process is “hard to understand” or “difficult to observe”. It is neither of these things because

absolutely everything about it, including everything editors do, is explained in nontechnical terminology here: Cardano Improvement Proposals (CIPs): Wiki
anyone who wants to follow CIP statuses & evolution can subscribe at the top bar to get 100% notified of all activity in their own interests by email: more effectively & efficiently than X or any other means of social networking.

So @JSHyCS please correct me if I’m wrong but what you meant is: It’s practically impossible for architects, developers, innovators and subject matter experts to follow the CIP process for every change they make or plan. You are right about that and just last week this issue was posted, which just as you’ve said centers on how Ledger changes might be catalogued effectively under current circumstances:

github.com/cardano-foundation/CIPs

Ledger rule changes: documentation & consistency?

opened 12:57PM - 22 Apr 25 UTC

waalge

Category: Ledger State: Triage

Someone sent me a message to inform me that a dapp what I wrote no longer works.… The breakage is due to a change in ledger rules. Specifically the one corresponding to https://input-output-hk.github.io/cardano-js-sdk/enums/_cardano_sdk_core.TxSubmissionErrorCode.html#ConflictingInputsAndReferences Essentially the dapp involves a CIP 68 style "updateable" state, that doubles as linked list lexicographically sorted by token name. To insert a new item in the list, you "update" the token that will precede it. The initial entry of the list, has blank token name (excluding CIP67 tag) . This entry's datum contains information that controls additional behaviour of how a new item can be inserted into the list. As a result, for any insert, the validator expects to find this token in reference inputs. Under the change to ledger rules, this breaks for the first insert. In fact, for every insert in which the first token is spent. There are numerous elementary ways the dapp can be modified adhere to the new ledger rules. But had the dapp already been deployed, that would be irrelevant. Reading from the distance, I'm guessing significant efforts have been made to futureproof Plutus. Its kinda all for not so much if Ledger rules can just break your dapp anyway. I frequently make assumptions on ledger rules. For example, - MinAda was no longer required, then a bunch of stuff I've written would no longer work, such as ```aiken expect [_ , (hash, name, amount) ] = value |> assets.flatten ``` - Inputs are lexicographically sorted. (An example utilising this is a bit more involved) It is very helpful relying on things being enforced by the ledger. And very unhelpful when these change. From memory this is not the first time this is has happened. As far as I know, there is no "Ledger rules we promise you can assume" list out there. Is there?

The Ledger / (multi) Node specification is another application that would be served by a standards review process — likely with benefits from also using GitHub — that would resemble CIPs but provide a more lightweight & granular contribution mechanism.

This goal was already discussed late last year when CIPs were proposed for Governance propositions: and, despite the legitimacy it was suggested this would provide, was ruled out in practical discussion for these reasons: https://github.com/cardano-foundation/CIPs/issues/937#issuecomment-2476061813

… mainly due to the necessarily long, slow lifecycle of CIPs that you can see here:

… and so of course your own reasons above would also suggest a different process. The goal I think would be to accommodate the CIP Process’ goals of accountability without the lengths of time & documentation requirements for “improvements” that CIP peer review imposes for “standards”.

cc @ch1bo @arnaud @rkuhn @whatisRT @ryun1 @Crypto2099_Corp

Topic		Replies	Views
Announcement: Cardano Improvement Proposals (CIP1) transitioning to ‘proposed’ status CIPs stake-pools , devops , cip , proposals	19	2697	16 July 2020
What happened in CIPs last week? CIPs	50	8919	15 October 2023
Node diversity workshop - April 2025 Node Development	9	456	8 May 2025
Seeking Feedback on a CIP Idea CIPs	34	2847	23 November 2024
:es: Avances en la gobernanza de Cardano: Aportaciones de la comunidad, era Voltaire y actualizaciones del CIP-1694 Educación cardano , catalyst , catalyst-dreps , governanza , cip-1694	11	1368	16 August 2023

Managing a Shared Ledger: New CIP-Like Process?

Related topics