Priority CIP's for late 2022/Early 2023

[Benjmhart]

I want to draw attention to some CIP's that would offer significant improvements to the developer experience - and a short description of what those changes will be.

at the end i also include some efforts that do not yet have a drafted CIP, but have been part of discussions and may soon receive a CIP of their own.

• Plutus Script Type Uniformization - Currently, a great deal of indirection is necessary in order to do stateful minting of tokens, something as simple as counting the total minted tokens requires multiple scripts. This would allow the various script types to be composed into a single script, bringing Cardano smart contracts closer to the notion of smart contracts from other ecosystems, which can mint or hold tokens while managing internal state.

• Bitwise Primitives for Plutus - This allows for efficient computation on chain - as may be relevant for data structures, cryptography, and Zero-Knowledge-Proof verification, similar to most other languages.

• ECDSA and Schnorr Signature verification in Plutus - This adds a new efficient cryptographic curve primitive to the plutus language - these signature schemes are heavily used within the Bitcoin and Ethereum ecosystems for transaction signing and certain varieties of Zero-Knowledge-Proof. This primitive can make protocol interoperability much easier, especially for bridge and cross-chain protocols

• Preserve the Submitter's Ordering of Transaction Inputs - This simplifies the developer's experience when writing smart contracts. When preparing a transaction off-chain, the submitter (or rather, the developer writing the tx building code) can make certain assumptions about the ordering of UTXO inputs to the transaction, which are not currently respected onchain. simplifying this allows the onchain code to be slightly more efficient, and more intuitive when compared with the offchain code that generates it.

Honorable Mentions include two efforts for which there is not currently a CIP, but may be viable for plutus v4:

• Atomic Multi-transactions for composable non-custodial financial transactions
• Input endorsers adjustments for patterns that can improve offchain transaction building.
• Now that blockfrost is open source: a blockfrost registry (similar to the Freeloaderz submit-api registry)

These represent next steps to reducing the stumbling-blocks of working with Plutus from any language/APi (PlutusTx, Helios, Plutarch, Pluto, etc), which require changes the the language version or the ledger. However there are a number of efforts which do not require changes to Cardano in order for them to succeed and be beneficial:

• Smart Contract Blueprints - This creates a standard for programmatic discovery of a smart contract and easily inspecting its interface.

[Benjmhart]

i would be remiss if i didn't also mention Smart Contract Software License

[jhofp]

What about CIP-0381 | Plutus support for Pairings over BLS12_381 and CIP-2551? | Ed25519 Elliptic Curve Group Primitives in Plutus Core?

They are very much needed for supporting ZKP related projects.

[WhatisRT]

I'd like to point to the discussion of cardano-foundation/CIPs#231. I believe this CIP doesn't actually help but makes things worse.

[colll78]

esn't actually help but makes things worse.

You wouldn't feel that way if you saw the codebase of any of the DEXs. The crazy non-sense they all do (that introduces a ton of complexity and room for vulnerabilities) to reconstruct the necessary of inputs within the transaction is actually revolting, and the DEXs that don't do this ugly reconstruction can only fit roughly half as many requests in a batch. In addition to the absolutely massive efficiency benefits, it actually solves the double satisfaction issue, because you can match the corresponding outputs based on their indices (ie input at index 1 must correspond to output at index 1).