eqlabs / polkadot-light-client-spec Goto Github PK

Overall, the spec seems to be sparse and lacks details on several key components of the light-client. Components like ... light-weight interactions with GRANDPA and BABE (and Sassafras in future) for the light client have not been addressed

Components like ... local host storage ... for the light client have not been addressed

Fix:

No discussion of embedding runtime environments to run on-chain wasm blobs. How would the compiled targets (for different platforms) interface with the embedded runtime environments.

Furthermore, the document could be improved by adding justification to the design choices. For example,
"We will use hash_map with serialization/deserialization to hold the blockchain state." in Implementation.md
Missing details, especially on the limits of using a hashmap. What were the other options considered? would there not be any non-persistence issues? AFAIK, other node implementations use a Database for similar tasks.

A global review of the document

• consistent formatting, headings
• the language, i.e., native speaker check
• expansion of any areas that might need it (more text is (almost) always welcome)
• check structure flow, proper hierarchy where appropriate

Components like Runtime/execution environments, ... for the light client have not been addressed

It would also be interesting to gain insights into the disadvantages of implementing in C++ and the major pain points the team expects

Fix concern:

Missing a clear comparison of required components between Light-Client and Full Node. Ideally describe a spectrum of functionalities that a light-client can support.

Feedback text from Polkadot regarding grant submission, specific to JSON-RPC methods:

1. Transactions related methods missing.
2. Cleanest way to integrate with the browser is implementing the SC extension protocol here.
3. We are aware that the JRPC interface is unstable, but for completeness would make sense to add the other RPC methods to the minimal set.
4. Also, please details in stages of implementation.

Fix:

Mentions three initial RPC methods to be implemented. Would this suffice? Justification would be appreciated.

Fix:

Details of the required crypto libs missing; nice to have: assessment of using the heavy crypto libs in a resource constrained light-client.

Fix:

No mention of chains to be supported (e.g. Polkadot, Kusama, Parachains)

Similarly, it is mentioned:
“Boost::asio used as the main event loop” - Diagram
Why does ASIO satisfy the requirements at hand? What would the Callback Graph of the event-driven system look like? What are the event triggers?