RChain light client? Merkle tree to transactions? (IBC for RChain?)

[dckc]

In most popular blockchains I know of, there's a light client specification - a way that a client can verify any transaction given a recent block header and a merkle proof. Does RChain supply something analagous?

zsluedem/transaction-server shows how to find REV transfers from com events in RChain blocks. Is there something analagous to a merkle proof for these transactions (or the com events that define them)?

As shown in this IBC relayer diagram, a light client for each blockchain is needed in order to relay between them. If we had an RChain light client, we could use IBC to participate in Gravity, a bridge to Ethereum.

See also cross-chain peg; e.g. to Agoric · Issue #12 · rchain-community/rstake

cc @zsluedem @tgrospic @jimscarver

[dckc]

@tgrospic do remember much of our discussion from 2021-04-29? If you find a moment to jot down what you remember, that would be great.

Also, if you could ask @leithaus about this, I'd appreciate it.

We have notes in rchain/rchain#3380 (comment)

But I don't see anything from that day in Log: Tech Governance - Google Docs

[dckc]

I found a rust implementation of merkle proofs. For my reference, if nothing else:

https://github.com/confio/ics23/blob/master/rust/src/ics23.rs

cosmos community spec:
https://github.com/cosmos/ibc/blob/master/spec/core/ics-023-vector-commitments/README.md

[faddat]

Hey Dan, I figured that this is possible, we just have to make some determinations about what RChain considers to be finality.

Even in situations with rather latent finality, I do think that it is possible to build fully compliant IBC light clients.

Gets more difficult as finalization is either more latent or more variable, but it seems to me that even if the latency is like 2 hours, as long as there is some confirmable sense of finality, you can build a light client.

[dckc]

rchain's finality is more like tendermint than bitcoin. 2/3rds safety condition blah blah.
but it's a DAG, not just a chain, so there's not just a latest finalized block but a finalized "fringe"

According to my notes, most of what I know comes from Vlad's devcon 3 talk

• Casper the Friendly GHOST: A correct-by-construction blockchain 2017

[jimscarver]

the simple way to determine finality is to read blocks from an observer. There are several developments changing finality and we want to be independent from them. Update: Opps. I'm stating the obvious, the light client is an observer. Guess I missed the point....

…

On Wed, Feb 14, 2024 at 12:32 PM Jacob Gadikian ***@***.***> wrote: Hey Dan, I figured that this is possible, we just have to make some determinations about what RChain considers to be finality. Even in situations with rather latent finality, I do think that it is possible to build fully compliant IBC light clients. Gets more difficult as finalization is either more latent or more variable, but it seems to me that even if the latency is like 2 hours, as long as there is some confirmable sense of finality, you can build a light client. — Reply to this email directly, view it on GitHub <#35 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAXFQELW3STDWK3OKWXAUEDYTTYKTAVCNFSM42ZMLCZKU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOJUGQZDSMJQGQ3Q> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[jimscarver]

For those contributing who don't want to run their own rnode the only node running I know of is rhobot,net.

RHOBOTNET = {
'observerBase': {'url': 'https://', 'host': 'rnodeapi.rhobot.net', 'port': 443},
'validatorBase': {'url': 'https://', 'host': 'rnodeapi.rhobot.net', 'port': 443, 'num': 1},
'adminBase': {'url': 'https://', 'host': 'rnodeadmin.rhobot.net', 'port': 443}
}

Send me your rev address to receive rhobotrev.
Access using metamask at https://rgov.rhobot.net
The server log is at https://rhobot.net/rnode-log

The first new testnet is likely to be running is BigSur, still using round robin propose.