Light client

[magik6k]

Currently lotus nodes can be either "full nodes" or "lite nodes".

Full nodes sync the chain fully, require a lot of resources, but are fast and don't need to trust any other nodes.

Lite nodes are not syncing the chain at all, but require very little resources. A downside in that they need to trust their, potentially centralized, gateway nodes with all chain state.

There seems to be a place for an in-between solution, "light nodes" (potentially better name needed):

• Fundamentally those would be full nodes with a few small modifications:
  • No state compute checks in chain sync
  • This works because the most important sync checks have 900 epoch lookback - which means that if we can trust the power table 900 epochs ago, and we're syncing a block from a miner that was in that power table, that miner has a lot at stake / it's really expensive for them to produce a block with wrong state.
  • To actually fool us into syncing a bad chain, a potentially large portion of the mining power would need to collude, producing tipsets with invalid state for a long time, which isn't impossible, just very expensive.
  • This means that it should be safe to skip checking state in nodes which are only doing low-value actions (sending small amounts of fil, making deals)
  • Using bitswap to fetch missing state blocks
  • No local mempool (that requires full local state; sending messages is still possible, but it's not possible to create blocks)

[Kubuxu]

This works because the most important sync checks have 900 epoch lookback - which means that if we can trust the power table 900 epochs ago, and we're syncing a block from a miner that was in that power table, that miner has a lot at stake / it's really expensive for them to produce a block with wrong state.

I'm not convinced that this works. Let's say that you securely bootstrap to the current head with epoch A (a way to do that isn't covered by the proposal). At epoch A+1, the adversary performs an illegal state transition giving himself 10x the network power, by injecting faux replicas into a state of a previously shelved miner actor. At the epoch A+901, the adversary starts to mine and quickly overtakes the legitimate chain in chain weight. The Light Client does not differentiate between correct and incorrect state transitions so they would switch to the chain of the adversary.

[jennijuju]

@sa8 shared this SoK on light clients for reference: https://eprint.iacr.org/2021/1657.pdf that might worth 👁️

[sa8]

I'm not sure I fully understood the proposal neither, although I do agree with Kuba's point about fooling a light client. The SoK above provides a nice overview of the research in this space, although for Filecoin solutions may be need to be adapted slightly due to the storage requirements.

[ZenGround0]

It is a nice property that if a Light Client can somehow do an initial secure bootstrap all power table skullduggery can be traced back to a staked miner from the initial trusted power table. If we introduced a new variant of consensus slashing that somehow disallowed the worst forms of power table manipulation then the threat of consensus slashing could deter @Kubuxu's above attack.

As a starting proposal if a miner signs a block at epoch X with a power table claim that differs more than some threshold from the claim in the main chain then that miner is slashed. We'd need to refine this to be careful about recoveries and faults causing slashes of miners on legitimate forks.

[Kubuxu]

As a starting proposal if a miner signs a block at epoch X with a power table claim that differs more than some threshold from the claim in the main chain then that miner is slashed

An issue with that is that you just slashed my 10TB miner (it can lie in wait to trigger the attack) which doesn't carry a high cost. You also slashed it on a legit chain, meaning my illegitimate chain still exists and is valid. Remember that I don't have to reveal my illegitimate chain until it already has a greater weight than a canonical chain. Secondly, whatever slashing mechanism we devise, there is a window of time between illegitimate chain existence being revealed to it being slashed in some manner. This window is when attacks on light nodes can happen.

[ZenGround0]

An issue with that is that you just slashed my 10TB miner (it can lie in wait to trigger the attack) which doesn't carry a high cost.

I think this is counter to the key point I'm making. If I understand the attack scenario some attacker miner needs to actually win a legit election as verified by the light client in order to provide the light client with a block with a bad state with a bad power table that balloons the power of the small miner lying in wait. It is this block that I'm proposing making slashable. It could be the 10 TB miner doing this step but only with proportionally low likelihood.

You also slashed it on a legit chain, meaning my illegitimate chain still exists and is valid.

there is a window of time between illegitimate chain existence being revealed to it being slashed in some manner.

Agree with both of these. The idea is to create a deterrent but the attack will still happen if its worth the risk.

[jennijuju]

https://twitter.com/NoahCitron/status/1589739389545914368?s=20&t=i66Q5jrdr7toyaEogjg4YQ might be interesting