light: brainstorm ways to get witnesses & hash/height

[melekes]

ways to get witnesses:

1. query public sentry node /net_info to get a list of full nodes
2. query multiple full nodes and combine results (a separate cmd?)

ways to get hash & height:

1. query multiple full nodes and compare their hashes:

$ curl -s https://233.123.0.140:26657:26657/commit | jq "{height: .result.signed_header.header.height, hash: .result.signed_header.commit.block_id.hash}"
{
  "height": "273",
  "hash": "188F4F36CBCD2C91B57509BBF231C777E79B52EE3E0D90D06B1A25EB16E6E23D"
}

https://docs.tendermint.com/master/tendermint-core/light-client-protocol.html#where-to-obtain-trusted-height-hash

[cmwaters]

Is this something that we would want to add to the lite2 module itself? We could combine all of these to create a 'quickstart' of the lite client

[melekes]

Refs #4583

[melekes]

Is this something that we would want to add to the lite2 module itself?

I guess so.

[tac0turtle]

I have been thinking about how to better this UX recently and the main thing I keep coming back to is adding it into the p2p layer by default and allowing rpc connections as a fallback. I'd say the client-UX around this is quite poor right now.

In the meantime, we could implement a simple crawler as you mention above.

[tac0turtle]

I would like to revisit the PR from @erikgrinaker (#4508). If we want to provide a nice experience we should hook the light client into the p2p network.

This is the approach many teams take because it provides a better UX. The reason for not accepting, leads to a greater maintenance burden, is a burden we should be willing to take, if it's truly a greater burden, instead of providing poor UX.

[erikgrinaker]

Yeah, I think @ebuchman voiced some support for this as well. It would be nice if it "just worked".

[erikgrinaker]

Note that even with a P2P transport, the user still needs to provide a trusted header hash and height, which needs to be obtained from "somewhere trusted".

[tac0turtle]

Note that even with a P2P transport, the user still needs to provide a trusted header hash and height, which needs to be obtained from "somewhere trusted".

Could this be on startup/in protocol?

I start a light client, feed it a seed node to populate my addrbook. My node asks multiple nodes for a header and hash at a relevant height and verifies they are the same. Input that as my trusted header and hash, only then start sequential/skipping verification.

My knowledge on the current light client is not vast, this is a scenario I have in my head that could easily be wrong.

[erikgrinaker]

Yes. In that case, the seed node you give would be your root of trust. If you provide an untrusted node, or a man-in-the-middle is able to pose as the trusted node, you're pretty much screwed.

I think having to obtain a trusted hash from e.g. a trusted block explorer or something is a bit safer than just trusting some random IP address on the Internet that was probably copy/pasted from some tutorial somewhere, but am open to discussing it.

[tac0turtle]

Yes. In that case, the seed node you give would be your root of trust. If you provide an untrusted node, or a man-in-the-middle is able to pose as the trusted node, you're pretty much screwed.

I think having to obtain a trusted hash from e.g. a trusted block explorer or something is a bit safer than just trusting some random IP address on the Internet that was probably copy/pasted from some tutorial somewhere, but am open to discussing it.

Yes agree with you, reducing the amount of input from primary, witness, height and hash to only height & hash would make a huge difference as this info is easier to come across.

We can think of further UX improvements if there is a want for it. If we were to introduce p2p into the light client it would already be a 10x improvement IMO.

[tac0turtle]

I attended a call on cosmos UX and state sync needing RPC nodes to start came up. It was asked what ways we can avoid needing this because getting RPC endpoints is difficult, currently.

[cmwaters]

I guess there could be two root causes to this a) lack of visibility of rpc endpoints or some sort of friction in obtaining a set of rpc endpoints and b) lack of trust / adoption in making a nodes rpc endpoints public

If b) is seen as the major problem then we should probably looking to improve security or the overall design of the RPC or (and I am largely for this) the inclusion of p2p support for light clients

If a) is the main problem then we need to start incentivising the advertising of endpoints (or at least make it easier for nodes to publicise their endpoints). Encouraging trusted block explorers to also list endpoints may also be helpful. I tend to think that @erikgrinaker is right. Having a single trusted endpoint (aka a seed node or something) although probably being the ultimate in terms of ease of use is definitely vulnerable and for a system that needs to secure a lot of value, I think we should definitely opt for the safer but more inconvenient road.

[cmwaters]

From a theoretical perspective, we must accept that Tendermint will always require these roots of trust that the rest of the network builds on top of (even full nodes need to trust other nodes). What we must ask ourselves therefore is how can we increase the likelihood that a point of trust is trustworthy. In a trustless system this is predominantly done through transparency of actions and financial accountability but even this doesn't full guarantee trustworthiness. What I'm trying to say is that this will always be a tradeoff between security and accessibility.

[tac0turtle]

We should introduce the light client into the p2p layer no matter what, light clients will need to be introduced into the p2p network in the near future anyways.

On the call we talked about how the RPC layer is a dos vector, yet we ask people to expose it.
The easiest mitigation we came up with is to use tmcrawl from @alexanderbez and display this info on some site, but we can't do this for every network

[melekes]

I attended a call on cosmos UX and state sync needing RPC nodes to start came up. It was asked what ways we can avoid needing this because getting RPC endpoints is difficult, currently.

yep, this is a big problem!

We should introduce the light client into the p2p layer no matter what, light clients will need to be introduced into the p2p network in the near future anyways.

I agree.

What I'm trying to say is that this will always be a tradeoff between security and accessibility.

Maybe we should sacrifice security a bit for accessibility by querying the existing peers for height & hash and if all (or 2/3) agrees on them, we use it to seed light cilent.

[tac0turtle]

What I'm trying to say is that this will always be a tradeoff between security and accessibility.

Maybe we should sacrifice security a bit for accessibility by querying the existing peers for height & hash and if all (or 2/3) agrees on them, we use it to seed light cilent.

I don't follow how using peers is less secure? I would say it's more secure because the light client could easily sample more heights and hashes from peers for a trusted height than a human will. Maybe I am misunderstanding but I don't see a tradeoff here.

[cmwaters]

Depend on where you get your peers from

[cmwaters]

I guess another question is what path do we want to follow first:

Integrate the p2p layer into the light client and get the benefits from that.

or

Improve the design of the RPC layer so it is more secure, that more nodes use it and it is easier to find rpc endpoints

[tac0turtle]

I am for integration into the p2p layer because it is more secure and better UX than RPC. Expanding the RPC layer to be more robust and secure could lead down a rabbit hole of recreating systems like nignx within Tendermint, but it doesn't solve the part of finding RPC endpoints.

If we want to use light client verification for fast sync than light client in p2p is a must.

[melekes]

The difference is human knows what machines he can trust or not (e.g. X validator would probably be more trustworthy in human eyes because it's been operating for years versus some unknown IP) whereas one can try to do an eclipse attack on computer.

[cmwaters]

The only downfall with p2p road is that if the light client wants to run it's own rpc server it will still need rpc endpoints with which to source the information from before verifying. But perhaps this can be done through the p2p.

Anyway I'm hearing a lot of consensus on this, so what would need to be done to proceed, an ADR? (Didn't someone already do the implementation)

(also would it be wiser to wait till after the p2p refactor before addressing this?)

[melekes]

ADR would be nice

[erikgrinaker]

Anyway I'm hearing a lot of consensus on this

I tried to push this when I implemented state sync in March/April, through multiple discussions and dev calls, and the consensus then was to use RPC so the P2P PR (#4508) was rejected. Nothing has changed since then, the arguments are still exactly the same, so I'm not really sure why the consensus is now the opposite. I'd like to make sure we have actual consensus from all stakeholders before picking this back up again - I believe @brapse was opposed to this, as well as a few others at Informal, and I'd like to get @tessr's take as well.

would it be wiser to wait till after the p2p refactor before addressing this

Nah, that's more about infrastructure plumbing, and doesn't really affect the high-level reactors too much.

[cmwaters]

I'd like to make sure we have actual consensus from all stakeholders before picking this back up again

This makes sense. It would be amazing if we had some official mechanism for doing this. We could call it a Request For Consensus or a Request for Comments or maybe just abbreviate it to RFC

[tac0turtle]

Maybe we offer both? If no RPC endpoints are specified it falls back to p2p network?

The only downfall with p2p road is that if the light client wants to run it's own rpc server it will still need rpc endpoints with which to source the information from before verifying. But perhaps this can be done through the p2p.

This is a concern I have thought about, but it may be too early to start talking about it.

This makes sense. It would be amazing if we had some official mechanism for doing this. We could call it a Request For Consensus or a Request for Comments or maybe just abbreviate it to RFC

Like a blockchain?

CC'ing @jackzampolin into this because he brought it up yesterday I believe he is a good stakeholder to have here.

I didn't mean to ignite this conversation in such depth, my comment yesterday was more of a note from the call I attended. I needed to make that more clear.

[erikgrinaker]

This makes sense. It would be amazing if we had some official mechanism for doing this. We could call it a Request For Consensus or a Request for Comments or maybe just abbreviate it to RFC.

Sure, I'll try to write something up next week - I need to get some traction on the P2P work first.

[cmwaters]

That'd be awesome. I can also help if you want - although I probably lack sufficient context with respect to the p2p and what the implications would be.

[erikgrinaker]

Sure, feel free to look into it - it overlaps a bit with the backfill work, I suppose.

[hxrts]

Getting trusted endpoints is one objective of the chain registry project, which is being discussed as a service Gaia could offer. Main discussion is currently in the Interchain UX Working Group Telegram and the #chain-registry channel on Discord.

[tac0turtle]

Getting trusted endpoints is only part of the problem.

The UX around needing to go find these endpoints and add them to the config in order to start a node could be reworked. Ideally you only need to connect to a peer and then the light client uses the address book to query the needed information, IMO.

We will wait to see if this becomes a problem with users. I could be trying to pre-optimize something people are fine with.