Open dckc opened 3 years ago
dckc
commented
3 years ago @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 https://github.com/rchain/rchain/issues/3380#issuecomment-829532413
But I don't see anything from that day in Log: Tech Governance - Google Docs
dckc
commented
2 years ago 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
commented
9 months ago 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
commented
9 months ago 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
jimscarver
commented
9 months ago 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 https://github.com/rchain/rchip-proposals/issues/35#issuecomment-1944291047, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAXFQELW3STDWK3OKWXAUEDYTTYKTAVCNFSM42ZMLCZKU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOJUGQZDSMJQGQ3Q . You are receiving this because you were mentioned.Message ID: @.***>
jimscarver
commented
9 months ago 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.
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