CPS-0019? | Light Client Protocols

[cleanerm5]

Hi,

There are a few activities ongoing that require the development of so called light client protocols for Cardano. The ones that came to my awareness are:

• the IBC implementation of CF (https://github.com/cardano-foundation/cardano-ibc-incubator)
• the Bitcoin-Cardano bridge proposed by BitcoinOS and with the general approach described in this paper (https://assets-global.website-files.com/661e3b1622f7c56970b07a4c/662a7a89ce097389c876db57_BitSNARK__Grail.pdf)
• the IOG research work on trust-minimized light client based wallets

There are various ways how to implement light clients on Cardano (whereas because of the core protocol not providing so called state proofs out of the box, there is no canonical light client design available for Cardano at the moment). In that sense, I wanted to create a common point of reference and problem description with this CPS to which concrete light client designs can refer to when they are documented as a CIP.

At least for the IBC implementation we plan to document the Mithril based light client as a CIP and the same would make sense for the respective light client protocol to be developed for a Bitcoin-Cardano bridge (in case the bridge follows a light client based security model), because both designs can be used for other use cases as well.

Any feedback is highly appreciated.

Kind regards

---

(rendered latest version)

[rphair]

Thanks, I'm marking Triage to begin discussion of this at the next CIP meeting (https://hackmd.io/@cip-editors/102) if not earlier in this thread.

This will be an introduction of the CPS, rather than a full review, but I would also plan to discuss the scope enough to see if a category of Network rather than Tools would be appropriate. @cleanerm5 you have obviously put a lot of thought into applications so I would hope you can come to this meeting in a week's time to answer this question first.

[rphair]

Confirmed as candidate in CIP meeting today: pending a title revision that reflects not a standard / framework for "light client protocols" but rather a means of incorporating these into the main protocol with proofs (as @colll78 pointed out).

Ordinarily we would wait for a title accurately representing the CIP scope, but given the high profile concurrent work that relates to this CIP we decided to put the number through immediately.

Please @cleanerm5 rename the directory to CPS-0019 and re-link your original comment to the new pathname of the latest proposal in your branch. 🎉

[EzequielPostan]

This was a nice reading, thank you for the document.
I may add a comment/question. Is it actually the role of light clients to improve the finality properties of Cardano (or any underlying chain)? I can understand the challenge of finality for application development, but I wanted to ask if the protocols to generate state proofs (as defined in the document) should be mixed with underlying consensus finality management

[polinavino]

FYI - There is a "Light Client Service" section in the following CIP about nested transactions

The idea is that batching transactions in a specific way, called Nested Transactions (plus some extra versatility for script use), allows users to engage in an LC protocol which is NOT about the LC querying a service provide for blockchain data, but instead, an LC asks the SP to help them build a transaction that satisfies some properties

#862

[rphair]

@cleanerm5 this was hanging in limbo for a period from the unresolved query in #942 (comment) ... I'm cleaning through similarly "waiting for response" candidates that we can still promote and I think yours was actually ready long ago.

@Ryun1 @Crypto2099 @perturbing it's especially important that we have a proper CPS container at least for Mithril & all others enumerated here which may have CIPs for them. Though I'm not an expert reviewer I can find no fault with this document nor how it paves the way for development in this field... so marking Last Check for next CIP meeting in 2 days' time (https://hackmd.io/@cip-editors/113) to merge unless some fault is identified.

Note

@cleanerm5 @polinavino if you can consider at the last minute including candidate #862 as suggested in #942 (comment) then please contribute an editorial suggestion... otherwise we will leave it to a later PR update if relevant.

[rphair]

@cleanerm5 after feedback from yesterday's CIP meeting I'm putting this back in Confirmed status (= active review but not ready to merge) due to an expressed opinion that the technical accuracy and precision aren't currently enough to reflect the importance that Mithril will have to Cardano.

@perturbing can post specifics & in the meantime we'll watch here for developments. Any review or response from the Mithril team would also be appreciated here (not sure who to tag... maybe @cleanerm5 you could help?). All editors agreed this is a vital CPS for Cardano and will be ready to keep this document moving towards merge when possible.