2022-12-24.md

Monthly reporting to Catalyst submitted 2022-12-24

Period between 2022-11-23 and 2022-12-24 inclusive

• These reports: https://github.com/rphair/cip-editing
• GitHub activity overview: https://github.com/rphair
• Cardano Forum overview: https://forum.cardano.org/u/COSDpool
• Discord invite to CIP Editors Meetings: https://discord.gg/kyaTyzkBqd

Quantitative contributions

CIP pull requests @rphair involved in, by last update time = 47 in this period

CIP issues @rphair involved in, by last update time = 20 in this period

Cardano Forum CIP topics @COSDpool posted in since beginning of period = 3 addressed in this period

CIP team progress

Open pull requests (https://github.com/cardano-foundation/CIPs/pulls) = 57

Open issues (https://github.com/cardano-foundation/CIPs/issues) = 26

Qualitative contributions

Massive group effort under way to convert old to new CIP standard - since existing documents will have to be converted into new format to ensure they match the new standard and have headers consistent enough to be machine-readable (to produce the automatically generated cips.cardano.org web site).

Expanded Discord community "social" discussion of CIPs beyond CIP-50 to another high-participation proposals: CIP-1694 (Voltaire & Governance).

Also personally very active in suggesting the CPS standard as a way of presenting Cardano issues which diverge enough from the CIP "solution" model to be presented as topics for long-term discussion and documentation of alternative solutions (see GitHub repo with documents marked CPS-).

End of 2022 shows 200 CIP PR's filed in 2022.  As summarised here for the CIP & Governance group on Matrix (following this Cardano Foundation Twitter post)

There have been exactly 200 pull requests submitted so far in 2022: https://github.com/cardano-foundation/CIPs/pulls?page=8&q=is%3Apr+created%3A%3E%3D2022-01-01

So maybe they factored out "trivial" pull requests (technical problems, software dependency flagging) and maybe the administrative PR's like editing the minutes we used to produce (not all of these were tagged as "housekeeping").  Doing a sample of the first 50 (2 of the 8 GitHub pages) I tallied, marking as "community" any PR with an author who I don't recognise from CF or IOG, and "institutional" otherwise):

• community, new CIP/CPS: 20 (40%)
• community, update to CIP/CPS: 11 (22%)
• institutional, new CIP/CPS: 6 (12%)
• institutional, update to CIP/CPS: 1 (2%)
• administrative, automated, aborted without review: 12 (24%)

Notes: I'm counting updates to existing CIPs by the affiliation of the PR submitter (not the original author).  Also counting Sebastien as "community" now that representing third-party company dcSpark & neither including them nor MLabs as "institutional".  The final figure suggests that in fact 1/4 of PRs are administrative & that's why the official count was less than the total number of PRs.

Anyway I think this is a resounding YES to the suggestion that the Cardano Community is hugely significant in the CIP process. 😍

2022-12-06 CIP Editors Meeting #59 (17:00 UTC)

("MY INPUT" is as of about 3 hours before the meeting)

Triage

CIP-0036 | Change rewards address field for Fund 10 (cardano-foundation/CIPs#373) (Ryun1 / Ryan Williams)

• MY INPUT
  • Running about a month.  Endorsed by Catalyst insiders (Martin Lang)
  • commented about some unexplained items here, and he's working on it (cardano-foundation/CIPs#373 (comment))
    • "catalyst pot" is answered, but "link to resolution" is NOT.
  • SUGGEST MAYBE we tag "Waiting for Author" while that's forthcoming?
• Ryan's come into meeting & has "format public announcement" in the works.
  • Also commented on GitHub.
• KT: Team is also working on registering Catalyst as a CIP category.

CIP-???? | Decentralized WebRTC dApp-Wallet Communication (cardano-foundation/CIPs#395) (Fabian Bormann / Jaime Caso)

• MY INPUT
  • Really unique approach to decentralisation based on Torrent principle to locate endpoints... contrary to WalletConnect which requires a centralised STUN/TURN server (for pinhole as in SIP?)
    • this was a centralisation problem in SIP as well.
  • Author has taken my suggestion to remove implementation code from CIP & link to it in separate repository(cardano-foundation/CIPs#395 (review))
  • One security reservation that appears to be addressed by author.
  • Robust, detailed, realistic Path to Active!
  • SUGGESTING we promote this to a candidate (POSTED in my review)
• to move into wallet providers, since they would have to be included.
  • TO ASK FOR (if not backup from wallet providers.
  • WILL ASSIGN NUMBER. TO TAG KT.
  • (KT beat me to the above posting)

CIP-0020 | Adding encrypted message specification (cardano-foundation/CIPs#394) (Adam Dean [new author, crypto2099] / Martin Lang [submitter])

• MY INPUT
  • Isn't just about "encryption" but also a more general update for CIP-0020, WRT:
    • participating dApps
    • proofreading & fixed headings
  • REVIEWED but wondering if support for encrypt needs a separate:
    • Path to Active (though the rest of the CIP is Active already)
    • whether support by each dApp needs to be indicated separately.
• KT (HE POSTED ALREADY) will ask them TO move to a separate CIP.
  • Would make it easier to indicate compliance for the additional part of the standard.
  • Can re-use parts of CIP-0020 (by reference).

CPS-???? | On chain dApp and script audits (cardano-foundation/CIPs#393) (matiwinnetou / Mateusz Czeladka)

• MY INPUT
  • Begun peer review.
  • One review response indicates there are still "open questions".
  • IOHK rep has doubts about certification authority & whether they would accept it.
• TO TAG for Simon Thompson's team to have a look at it...
  • index with CIP-0052 that came in today... since getting keys, can they also ask what they think about the audit standard?

CPS-???? | Properly burning NFTs / tokens (cardano-foundation/CIPs#392) (matiwinnetou / Mateusz Czeladka)

• MY INPUT
  • It's more of a WISH than a statement of the problem.
  • I suggested to author that this remain as Draft github status, but he's promoted it anyway even though the CPS is every thin.
    • So I can't just "bounce" it back to Draft status but it doesn't look ready to be posted as a candidate either.
  • TO POST this suggestion if well received at the meeting.
• KT says there IS a protocol means of doing this already (a "sink address"?)
  • I don't understand means of handling "locked assets".
  • POSTED: ASKED him to provide more concrete use cases; life cycles of what a "burn" process could be?... agreed at meeting to be a bit thin as-is, still like a "draft"
• Not detailed enough to assign a number (yet).
• It's a bit like a feature request for wallets, rather than general Cardano problem.

CIP-???? | Merkelised Plutus Scripts (cardano-foundation/CIPs#385) (Las Safin)

• MY INPUT
  • Getting robust peer review.
  • Has already "absorbed" another CIP ((cardano-foundation/CIPs#354 = Parameterised Reference Scripts), closed by author in favour of this one (cardano-foundation/CIPs#385 (comment))
  • SUGGESTING we promote this to a candidate.
• Path to Active seems thin?  Author "will implement it himself"
  • Good to assign number to it.

CIP-???? | Tune Parameters minPoolCost and K (MY AGENDA ITEM) (cardano-foundation/CIPs#387) (ADARobinHood = pseudonym, anonymous email server)

• MY EXPLANATION
  • Change the minPoolCost from 340 ADA/epoch to 10 ADA/epoch and raise K from 500 to 2000.
  • Includes some graphs plotting pool stake with yield, apparently to demonstrate what is "fair".
• MY INPUT
  • Competes with author's own merged (https://github.com/cardano-foundation/CIPs/tree/master/CIP-0074 = Set minPoolCost to 0) which has a Path to Active not mentioning K at all.
  • His justification for this: wants to provide "alternatives"
  • MY OPINION: this is either:
    • a single CIP, with a Path to Active indicating 2 different forks in the road... then this should be an update to an existing
    • a CPS, if the problem is that loosely defined: "not recommended" because it basically diminishes the urgency of a protocol update that SPOs have been pushing for a couple of years now.
  • POSTED blocking review based on this (cardano-foundation/CIPs#387 (review)) - this PR should be a CIP-0074 update.
  • NOT POSTED: encouraging discussion in CIP Discord > RSS thread, where I feel it would be a bit thin compared to other mathematical / scientific treaments & reviewers.
• Rather than more proposals, would make more sense to have more communication between IO and SPOs.  Until then it doesn't matter how many of these proposals are made.
  • POSTED (cardano-foundation/CIPs#387 (comment)) WE (not the author necessarily) NEED TO STATE PROBLEM CLEARLY [KT recommends CPS] about how to have discussion of proposal parameters IN THE FIRST PLACE.

Review

CIP-???? | Extended Local Chain Sync Protocol - SEE BELOW

• Looks important but still also looks like a draft.

CIP-???? | Implement Ouroboros Leios to increase Cardano throughput - SEE BELOW

• Postponed with only 13 minutes to go.

CIP-???? | Tiered Pricing Protocol - SEE BELOW

• Postponed with only 13 minutes to go.

Last Check

CIP-0051? | Preserve submitter's ordering of transaction inputs (cardano-foundation/CIPs#231)

• Q: still retains "(move to next meeting)" from LAST meeting!
• MY INPUT
  • I positively reviewed it, because it was on the implementation schedule as a key feature, but Plutus team said they're NOT going to implement it... and a "step in the wrong direction"
  • MY SUGGESTION: therefore this should be CLOSED, not merged?
    • already tagged Deprecated last week.

CIP-0048? | NFT metadata [721] references and payloads (cardano-foundation/CIPs#249) (Jack-0 = a zero, not an O ... of 9000 pool)

• MY INPUT
  • Incorporated a lot of feedback and factored out an unpopular component (NFT metadata extension tag) (cardano-foundation/CIPs#343)
    • That in turn updates CIP-0025, a hugely popular standard: so moving that one ahead could be a bit tricky.
  • Its implementation depends on this metadata extension, though.
    • Yet it was argued in the PR that the extension was not required.
  • But this one itself doesn't harm anything & could be merged if:
    • the non-standard info in the preamble is fixed.
    • clean up non-standard headers to follow the new CIP-0001.
    • Status set to Proposed
    • Path to active: if necessary, indicate that adoption of the CIP-0025 extended metadata (whether merged into CIP-0025 or not) is a dependency.
• KT would like to see this discussed but can't really be merged as is (for reason I mentioned).
  • TO NOTE that if "Extended Metadata" is a dependency, which depends on CIP25, then effectively it's a dependedncy here and we need to include smaug/alessandro as in the discussion before moving ahead with this one.

CIP-0069? | Plutus Script Type Uniformization

• MY INPUT - may be ready to merge now that there's a Path to Active.
  • Q; ASK:
    • is the (1-line) Path to Active detailed enough?
    • Does it answer questions about WHO will be implementing it?
  • Still waiting for answers to above questions.

2022-11-29 CIP editor meeting #58 (09:30 UTC)

common threads among great number of new CIPs -

• governance + blockchain upgrades + pricing structures (IOG all behind)
• managed token & smart contract behaviour beyond scope of Cardano's design goals
  • Enforceable royalties #378
  • Smart tokens #382
• users with "pet peeves" jumping into governance discussions & promoting some off-topic ideas (debatably outside the scope of the CIP process)

Triage

("MY INPUT" is as of about 3 hours before the meeting)

CPS-???? | Metadata Discoverability and Trust (cardano-foundation/CIPs#371) (ehanoc = Bruno Martins)

• MY INPUT
  • Addresses questions of metadata authenticity which implies an on-chain standard for identity (?)
  • no engagement yet but thumbs-upped by a couple people at IO
  • abstraction of "chain entities" could apply to other CIPs that address KYC and identity for individuals & stake pools (POSTED)
  • a broad problem with lots of approaches so should stay open in the background for a while... a general & interesting enough problem that makes sense to have it as CPS #1.
• would help to see what parts of the problem HAVE been covered.
• Merging is ready once CIP -1 (CPS definition) is merged itself!

CIP-???? | Transaction Serialization Deprecation Cycle (cardano-foundation/CIPs#372) (Jared Corduan)

• MY INPUT
  • Basically a standard for version control for transaction formatting.
  • I recommended some cosmetic changes, which have been made.
  • I think the CIP number "pi" - now that humour has been noted - can be changed into an ordinary "?" to make it more machine-readable if needed.
• So far since Shelly the Tx format has been backwards compatible... but has left Tx data structure & logic to handle it inefficient.
• It's the result from Ledger team's engaging with community (devs).
• NOTE we don't have a category for Ledger ("accountability" in this case means accountability FOR REVIEW rather than production.. and the "Core" category is too general)
• WILL assign candidate number.

CPS-???? | Pointer Address Removal (cardano-foundation/CIPs#374) (Andrew Westberg)

• MY INPUT
  • I believe (and suggested 18 days ago) that this CPS is so straightforward and essential that it should be converted into a CIP and given a Path to Active consistent with GitHub comments that have already been made so far.
  • POSTED Keeping it as a CPS would merely be a way of delaying the process, while in fact it's a prerequisite for Leios so had to be more officially acknowledged.
• Consensus is that this can be turned into a CIP.

CIP-???? | Extended Local Chain Sync Protocol (cardano-foundation/CIPs#375) (Erik de Castro Lopo)

• MY INPUT
  • Effectively simplifies production of the ledger state, avoiding horrendous RAM usage and bugs.
  • Also eliminates redundancy in keeping ledger state with cardano-db-sync (as mentioned in "Current Situation")
  • Developers support this idea (thumbs-ups).
  • TO MARK "Waiting for Author"?  Author hasn't responded to review comments in a couple of weeks...
  • Users support this idea because of the grotesque amount of memory it takes to dump the ledger state (serious, long-term issue for node #3691)
  • MY COMMENT just cosmetic & spelling... but to say it should be a Candidate CIP because of its importance.
  • PROMOTE TO CANDIDATE because of official endorsement.
• First CIP on networking protocols (also new Category?)

CIP-???? | Enforceable royalties (cardano-foundation/CIPs#378)

• MY INPUT
  • major NFT contributors have already weighed in on this; negative response because "whitelisting" will lead to centratlisation and inefficiency... I agree for the same reason.
  • Have POSTED request to remove CIP #79 which HAS BEEN IGNORED.
  • NOT POSTED - since MPJ already did (which got a lot of support) - this would make a good CPS if people have noted the problem but can't fully accept the proposed solution... there are lots of counter-proposals which could/should be collated into a CPS at some point.
  • Relates to MPJ's rejected CIP for spending policies #336 - with similar rationale for rejection.
  • in short IT BELONGS AS A CPS since that's as far as the community discussion ever got.
• mentioned in meeting with suggestion that we delay assigning a CIP number: at least in time to consider whether it would be better as a CPS.

CIP-???? | Implement Ouroboros Leios to increase Cardano throughput (cardano-foundation/CIPs#379)

• MY INPUT
  • This is a wrapper for the Leios "discussion paper" (Duncan principal author) which I'm not qualified to review (all I could do is invite Duncan to the meeting today)
  • I believe this is what they were talking about last year as "pipelining" and more generally in computer science as "diffusion pipelining".
  • relates to different block types - so coupled with new CIP "Tiered Pricing" (and says so in proposal: https://github.com/abailly-iohk/CIPs/tree/tiered-pricing-protocol/CIP-XXXX#integration-with-ouroboros-leios) - by separately pricing Ranking blocks (RB) Endorsement blocks (EB) Input blocks (IB)
  • PROMOTE TO CANDIDATE because of official endorsement.
• problem: it's a PDF instead of reviewable text.
  • maybe not a problem since most of the paper is PROSE (not really subject to review)
  • this will be turned into a research paper... Kevin Hammond confirms this is RESOLVED since it's being added to GitHub repository.
  • Pandoc can be used to integrate them (I also suggested HackMD like we used for CIP-0001 review)
• Kevin calls the Leois document a "Divine Document" (above reproach?) accompanying a LONG development process.
• Duncan is also creating a public repository for Ouroboros Leios (Kevin says)

CIP-1694? | A proposal for entering the Voltaire phase (cardano-foundation/CIPs#380)

• MY INPUT
  • The most massively discussed & commented about all the CIP submissions in the last 3 weeks.
  • Has invited some off-topic discussions about governance: the "off topic" parts I believe come from a confusion of "governance" with GOVERNMENT especially its conventional notions of crime & punishment.
    • Links to discussions Cardano Forum also relate it to personal agendas about the Cardano Foundation as if it were to be regulated by "governance" proposals (naturally outside the CIP process).
    • My suggestion is to recognise and ignore anything that doesn't relate specifically to procedures for blockchain governance for the Cardano protocol... HAVE NOT POSTED THIS except to recommend it on the Cardano Forum itself.
    • SOME POINTS ARE VALID by example of how to define & implement a "Constitution".
• TO CREATE an Discord Thread like we did for CIP50.

CIP-???? | Tiered Pricing Protocol (cardano-foundation/CIPs#381) (Arnaud Bailly IS HERE TODAY)

• MY INPUT
  • PROMOTE TO CANDIDATE because of official endorsement.
  • IN MEANTIME - I don't think it's enough to say "the pricing algorithm will be determined": What are algorithmic designs?  If known, what are the input values, tuneable parameters, and output values?  At least some shell of an algorithm has to be provided even if all details aren't determined yet.
    • I didn't post this yet because I can't tell if existing
  • MY SUGGESTION tag "Wating for Author" ... IF he doesn't attend the meeting... because he hasn't responded to reviews after 12 days.
• Review will be coming up.

CPS-???? | Smart tokens (cardano-foundation/CIPs#382) (szist = Istvan Szentandrasi)

• MY INPUT
  • DEV REVIEW ARE NEGATIVE just as in related proposal "Enforceable royalties #378"
    • I posted that comparison here: cardano-foundation/CIPs#382 (review)
  • since it's only a CPS I see no harm in letting it stand... even though same reservations.
  • There are 2 separate authors... so if this merges as a CPS perhaps they could be combined?
  • POSTED that suggestion: cardano-foundation/CIPs#382 (comment)

CIP-1775? | Delegated Spending Authorizations (cardano-foundation/CIPs#383)

• MY INPUT
  • Mark funds as "tentatively spent" for use by contracts & apps.
  • substantial editing has been done & it's ready for re-review and marking whatever conversations have been resolved.
  • I'm not qualified enough to mark it as such or to know if additional work is required on the author's part.
• Sebastien says "overlap" with his own "arbitray spending CIP" that he proposed... so we've asked him to comment on it (so far he was just on Twitter with author)

CIP-0068 | Make more economic and contract-friendly (cardano-foundation/CIPs#377) )

• MY INPUT
  • To facilitate CIP68 compliance for an "aggregator for token metadata"
  • CIP68 author has already been feeding back (I don't understand technical issue); no further discussion for 2 weeks.
  • (my note: CIP itself = "metadata standard for native assets making use of output datums not only for NFTs but any asset class")
  • MY RECOMMENDATION (ALREADY POSTED) Author admits "changes are very opinionated"... if there isn't agreement about this and/or determined beyond scope of CIP68... to convert it into a CPS: cardano-foundation/CIPs#377 (comment)
• I DIDN'T GET A CHANGE TO SUBMIT THE ABOVE at the meeting... but OK since already posted.  Re-suggested it here: cardano-foundation/CIPs#377 (comment)

CIP-0036 | Change rewards address field for Fund 10 (cardano-foundation/CIPs#373) (Ryun1 - Ryan Williams)

• MY INPUT
  • Update voting registration with "regular" addresses so MIR (instantaneous rewards) not required anymore (so can pay from addresses other than the treasury itself)
  • No editorial review yet: a good review from Martin Lang, with all conversations resolved... so I believe this is ready for KtorZ technical sign-off & pass (marked as such).
  • POSTED Although this requires changes to wallets in production I would forego the usual "Path to Active" because with IO's official endorsement it seems that wallets starting with Daedalus would be forced to implement the change quickly & as a matter of course.
  • POSTED - approved pending KtorZ tech review & author posting some verification that IO is going to do things this way.
• Principals including Kevin Hammond are debating this in the CIP meeting.

Last Check

CIP-0001 - ADDED LAST MINUTE TO AGENDA since really need to move forward

• I'd been waiting for KtorZ to merge it officially.
• TODO once it's merged to modify all pending CIPs... and maybe old ones?
  • This will also break existing formats and the web site (in the meantime)
• KtorZ will create a top-level issue & we can each take on the edits, as our time permits, checklist style (each one gets a button "create to issue")

CIP-0051? | Preserve submitter's ordering of transaction inputs (cardano-foundation/CIPs#231)

• MY INPUT
  • No responses from author but IO has endorsed it here, so I've approved it.
  • TO RECOMMEND merge should be pending "cleaning up document" as KtorZ & MPJ recommended... if so, would it help to tag "Waiting for Author" even though it's already considered official as-is?

CIP-0048? | NFT metadata references and payloads (cardano-foundation/CIPs#249)

• RUNNING OUT OF TIME no discussion

CIP-0069? | Plutus Script Type Uniformization (cardano-foundation/CIPs#321)

• MY INPUT
• OK to go ahead but no priority to implement it so far: therefore needs Path to Active.