search

spacemeshos / research

Spacemesh research tasks tracking issues
2 stars 0 forks source link

Light client support #46

Open lrettig opened 4 years ago

lrettig commented 4 years ago

This is a nice to have. It would enable things like atomic swaps with other chains, or joining a "federation" such as Cosmos. What would it take to have light client support?

CC @iddo333 @noamnelke @avive

tal-m commented 4 years ago

I thought lite clients meant something different... clients that can l verify transactions without completely trusting a full node or running one themselves.

@lrettig Could you expand on what properties we would need in order to support these things?

lrettig commented 4 years ago

Iddo wrote some ideas about how to do this in this thread, copying here for posterity:

what’s needed for lite client (including use-cases such as offchain atomic swap with another system) is the tree authentication path and the proof of confirmations. This proof of confirmations is indeed much easier with a blockchain, and in particular with PoW-based blockchain. One idea regarding how to do this is that an ATX will endorse an old state (that the validators committed to and no one challenged), and honest miners will vote against blocks whose ATX endorsed a bad state, so the lite client could validate NIPoSTs of multiple ATXs at the later epoch (the more NIPoSTs that the lite client validates, the higher the confidence that she achieves). Note that this requires validating PoET path(s) that go to genesis, which is the equivalent of lite client in Bitcoin that maintains all the headers since genesis (to avoid precomputation attacks).

noamnelke commented 4 years ago

@lrettig This doesn't really answer @tal-m's question (for me, at least). This is a possible solution, but it's hard to criticize it or suggest alternatives if we don't know what's needed and why...

Atomic swaps require programmability (e.g. having a hash preimage unlock funds + time locks for a timeout mechanism) and that's about it, as far as I can tell.

Off chain atomic swaps require payment channels. I'm not 100% sure about what properties the payment channel mechanism must support, most likely the same as above (conditioning a transaction on presenting a hash preimage + a timeout mechanism).

All of these things aren't related to light clients at all. You need to be able to know that a transaction is confirmed (for the on chain version), how you know is orthogonal (via merkle proofs or running a full node).

For off chain swaps you need to run the payment channel client (again, full node backed or otherwise).

I think you mentioned something about Cosmos or something, which I know nothing about - so if light clients are a requirement for interoperating with it I'd love to learn why.

lrettig commented 4 years ago

clients that can verify transactions without completely trusting a full node or running one themselves

Yes, this is also my definition of light client.

it's hard to criticize it or suggest alternatives if we don't know what's needed and why

Offhand, I can think of four reasons light client support is desirable:

  1. It makes it easier to run a node that is neither a full node nor an "API client" node on resource constrained devices such as mobile phones. I recognize that this never took off in Bitcoin or in Ethereum but I still think it's an ideal that we should strive to at least make possible.

  2. Interoperability with other chains--see note below about IBC.

  3. Avoiding what @iddo333 refers to as "angry bloggers" - i.e., marketing/spin

  4. Future possibilities that I'm failing to think of ("unknown unknowns"). Not a strong argument in favor of prioritizing light client support today, granted, but I think it is an argument in favor of erecting obstacles to doing so later unnecessarily.

I think you mentioned something about Cosmos or something, which I know nothing about - so if light clients are a requirement for interoperating with it I'd love to learn why.

I'm not an expert on this topic but at a high level, the most common way for one chain to trustlessly exchange data and/or value with another chain is for each chain to act as a light client of the other. Based on my limited understanding this includes both basic atomic swaps as well as more robust protocols such as IBC (which underpins Cosmos). There's a lot more useful information here; see in particular these docs:

lrettig commented 4 years ago

I'd add enabling sidechains to the list. There's more information in this paper, see sections 1 and 2.