search

celestiaorg / celestia-specs

Celestia Specifications
Creative Commons Zero v1.0 Universal
51 stars 14 forks source link

Storage node & protocol #3

Open liamsi opened 4 years ago

liamsi commented 4 years ago

We need to define the public API and the protocol to interact with a storage node.

This also plays into data availability (which might be started being spec'ed out in #2) as consensus participants (validators) that do not want to be storage nodes themselves will need to query them for data availability.

Quoting musalbas here:

So there should be an option to run: a) validator that is also a storage node b) storage node only c) validator that just uses data availability proofs(update: not planned anymore) d) light clients that use data availability proofs

liamsi commented 4 years ago

c) validator that just uses data availability proofs

Question: this was still assuming that there is no state in the LL main chain? Wouldn't validators still verify validity of transactions while they could only use data availability proofs for the messages the transactions pay for (@musalbas).

also ref: https://github.com/lazyledger/lazyledger-specs/issues/22 and https://github.com/lazyledger/lazyledger-core/issues/35

musalbas commented 4 years ago

I consider the LL token app to logically be an optimistic rollup sidechain. Therefore validators can just download the latest state root for it and accept state transition fraud proofs.

liamsi commented 3 years ago

Update on the above: while you could still argue that the LL token app will be treated as an ORU chain in the sense that clients could accept state transition fraud proofs, this does not hold for validators who will download all Tx (and actually all block data) and hence do not need to care about state fraud proofs.