CIP-???? | Merkle Root of Transactions in Block Header

[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.

[colll78]

Please create a CIP for this instead of a CPS, and add the following:

Introduce a new field, txInfoVerifiedRootHashes to the ScriptContext, with the following type:

txInfoVerifiedRootHashes :: [(TransactionRootHash, Maturity)] 

Where Maturity is an integer that represents how old the block corresponding to that transaction root hash is, ie. 1 would mean that it is the transaction root hash associated with the previous block. Alternatively, if this places too much of a burden on nodes (ie. querying the TransactionRootHash from 200 blocks ago) then we can instead just allow this list to contain up to 10 root hashes from the previous 10 blocks (ie. only allowed values for maturity would be 1-10).

This provides smart contracts with access to the transaction root hashes associated with previous block, thus allows them to prove that some event occurred on the chain in the past ten blocks. This is extremely useful for sidechains, l2s, hydra, and general purpose DeFi protocols, and even governance (you can prove that a user voted on a proposal, delegated to a drep, or even delegated to a stake pool).

[rphair]

@colll78 [originally posted] Please create a CIP for this instead of a CIP

1. did you mean "instead of a CPS"?
2. why do you think "instead of" and not "in addition to"? If I had to choose one or the other, I would prefer a direct solution over a CPS: but at our last CIP meeting there was general agreement there are a wider variety of approaches to the problem than the one currently favoured in the document.

[colll78]

1. did you mean "instead of a CPS"?

Yes thank you

2. why do you think "instead of" and not "in addition to"? If I had to choose one or the other, I would prefer a direct solution over a CPS: but at our last CIP meeting there was general agreement there are a wider variety of approaches to the problem than the one currently favoured in the document.

This specifically talks about including information that makes concise inclusion proofs possible into the block header. There can be multiple proposals on what the information we introduce could contain, but ultimately, there can only be one accepted solution to this. We cannot bloat the block header with multiple fields that each are relevant for only a single inclusion proof scheme.

[ch1bo]

I'd like to second @perturbing and @colll78 in that this seems to be rather a starting point for a CIP than a CPS, because it is about the concrete solution idea of including a merkle tree root hash that commits to all block transactions in the block header.

There is a problem statement included, but this is also about enabling (or taking one step closer) to cryptographic light clients. The challenge of creating such light clients for Cardano is described in more detail in CPS-0019. Note though, that this might not be the only CIP needed to solve CPS-0019.

[rphair]

@aslesarenko the CIP meeting in the last hour, after last meeting (2 weeks ago) inclined to agree with the expert review above suggesting that this submission be reformed as a CIP, has now established that as a consensus. The material is strongly in favour of its most recommended solution, which makes much more sense than proposing roughly 5 parallel solutions when only adopting 1 of these would be a substantial, historically significant change.

So unless you point out a serious problem with this idea we would like you to please make the format & presentational changes to submit this as a CIP. Please let's continue in this branch (i.e. don't open up a new PR) and try as best as you can to preserve the blocks of text, now that several people have reviewed them & found them at least to be a good exposition of the approaches not taken (i.e. they would serve well in the Rationale).

Any other questions about recasting this as a CIP please ask them here. As is always recommended on the CIP repository, incremental commits rather than a "force push" would be much appreciated. I think once we see a properly formatted CIP for this material, editors would want to assign a candidate number: likely at the next CIP meeting (in 2 weeks' time) if ready by then.

[aslesarenko]

@colll78 please review and make necessary corrections. (@rphair ^)

[rphair]

It sounds like the author agrees to recast this as a CIP so I'll retitle the PR as such — to help keep review on track, with the title of the mainly proposed method (almost as originally submitted) — and will look forward to whatever rewrite @colll78 is able to provide that turns this into a CIP before its next review.

[ch1bo]

Note that this CIP is similar to block header changes needed for Leios (and Peras) and we should keep it in mind when we sketch the block header changes for those.

[rphair]

cc @colll78 on @ch1bo's #964 (comment) in hope the similarity to Leios / Peras constrains the forthcoming CIP so it can be rewritten more readily.