CPS-???? | Lack of Concise Transaction Inclusion Proofs

[aslesarenko]

Minotaur, a sub-project of Partner Chains, utilizes light clients to follow state changes on integrated blockchains through a trust-minimized state bridge.

Previously, we implemented a proof of concept for Ethereum, using its existing features to enable this design. Our goal was to replicate a similar approach for Cardano using Mithril. However, both Cardano and Mithril currently lack certain features necessary for achieving parity with the Ethereum implementation.

This CPS describes the missing component on the Cardano side.

---

(rendered proposal)

[Ryun1]

Hey @aslesarenko

Thanks for this proposal, I really enjoyed reading it.

One high level scoping comment to add;

Is using merkle trees within block header the only solution to this problem?
I feel that this CPS may be re-scoped partly, to focus solely on the problem of creating compact transaction inclusion proofs
Then the 'solution CIP' can propose a specification of merkle proofs in block header.

[rphair]

coming up for introduction (not detailed review) at biweekly CIP meeting in a half-hour's time - @aslesarenko you are welcome to attend: https://hackmd.io/@cip-editors/104

[aslesarenko]

I feel that this CPS may be re-scoped partly, to focus solely on the problem of creating compact transaction inclusion proofs

@Ryun1, yes, this is the essence of what it will enable once implemented. And such proofs in turn will enable lots of use cases.

@rphair, just got to this message, too late for the meeting. BTW, I couldn't find the info on how to attend it (is it a scheduled Meets call?).

[rphair]

@aslesarenko you can subscribe for notifications & scheduling here (https://lu.ma/cardano-cip) and follow this Discord invitation (https://discord.gg/J8sGdCuKhs) ... see CIP Wiki > Key links & resources

[rphair]

At today's CIP meeting we didn't have the opportunity to resolve the issue about "scope" in the last couple substantial comments above: since the content defines the problem (as per a CPS) but its title suggests a particular solution (as per a CIP solving that CPS).

I made the suggestion that only the title itself might be overly specific, and that the rest of the document roundly covers a number of solutions and should itself be considered a valid CPS already.

Rather than mark this Unconfirmed (as sounding too specific for a CPS) or Confirmed with the current title (perhaps requiring you to produce a CIP implementing the favoured solution), therefore I suggested:

• to retitle this PR & document with a more general title that covers all the implied solutions
• to leave this marked Triage to ensure we settle the scope & title questions no later than the next CIP meeting: where it will also be on the agenda & which you @aslesarenko are now subscribed to attend.

[colll78]

Ergo has this (Merkle-root of transactions in block header), see here. This is incredibly useful for interoperability (especially the Bitcoin / Cardano BitVMX zero-knowledge bridge work), L2s (Midgard) and even state channels (Hydra).

By having this on Cardano L1, it would allow Midgard instances to see / prove events that happened in other (whitelisted / known) Midgard instances via the Cardano L1 block information. This is an incredibly power feature that would allow us to design applications that are able to read, consume and react to events across the Cardano L1 (and all Cardano based L2s). Even more so, this allows us to easily create dApps that are interoperable with other dApps on the L1 across multiple transactions, (ie. An insurance protocol that automatically reinforces users' collateral positions if they are at risk of liquidations or pays out an insurance claims if a token (ie. stablecoin) drops in value by X% over Y period of time).

Please, please, please can we make this happen.

[rphair]

Following from @aslesarenko's introduction at tonight's CIP meeting and #964 (review) plus @Crypto2099's specific recommendations, we've agreed to give this a number pending the assignment of a more general title that doesn't overtly favour the "Merkle Root" specifically as the solution for the identified interoperability problem.

@aslesarenko we look forward to confirming a new title (maybe something simpler like "transaction inclusion proofs in block header") and then we can assign a number and change it to Confirmed status.

[aslesarenko]

@rphair, abstracting from a concrete implementation the following key points nevertheless should be reflected in the title:

1. Header should contain short digest (hash) which authenticates transaction in the block body and cryptographically connects the header with the transactions.
2. Its presence should enable short inclusion proofs for any individual transaction of the block.

So, here are the variants, which don't assume any specific implementation approach:

• Header-Level Digest/Commitment to Enable Concise Inclusion Proofs
• Short Transaction Inclusion Proofs via Cryptographic Digests in Block Headers
• Missing Commitment in Block Header for Compact Transaction Inclusion Proofs
• Compact Transaction Inclusion Proofs Through a Header-Based Digest

[rphair]

Thanks @aslesarenko for considering the naming issue. The editors brainstormed — also considering the typical / maximum CIP world length you can observe here — and came up with (courtesy of @Ryun1):

• Lack of Concise Block Inclusion Proofs

This has the advantage of immediately getting the human reader's attention if they have encountered or considered this problem: whether coming from Cardano or elsewhere.

[aslesarenko]

@rphair I read "Block Inclusion Proofs" as "proofs that block is included somewhere" or "proofs about blocks", where as problem is to have "proofs about transactions" or "proof that transaction is included".

So, how about "Lack of Concise Transaction Inclusion Proofs"?

[rphair]

@aslesarenko that's the same thing I was thinking. Yes, let's use the latter 🙏

[perturbing]

I think this higly overlaps with CPS-0019

[perturbing]

This problem statement already poses a solution, namely the addition of a data structure like a merkle tree to each block.

I think what you are trying to abstract to is twofold:

1. The desire to proof if a block is onchain
2. Given a block and such a proof, easily extract data from it to prove usefull statements.

A usefull statement that you suggest is getting transactions, but this is just an example.

How much of this aligns with this CPS?

[aslesarenko]

addition of a data structure like a merkle tree to each block

Nope, I only propose to add tree root hash to block header, the tree itself is not stored as it is not necessary.

The tree root hash is different from a simple hash because it enables partial authentication of block content (with per transaction granularity, but other data can also be supported).
In particular, having a full block it is possible to create a compact proof containing individual transaction + merkle path to the root hash. This path is the key, because it is compact and can be verified against what is stored in the header.

How much of this aligns with #942 CPS?

If implemented, this proposal will simplify implementation of both light clients for Cardano + many L2 dApps on top of Cardano.