Spike: "Fast node/balance only" support
Overview
We currently need a full node + indexer to provide all tx history and balances, but some nodes are hard to maintain, or just don't easily support this and have no blockbook support. This would be an attempt to provide minimum data required for the web client to support a chain (ie. balance + send ability, no tx history or balance history)
References and additional details
BNB/BSC would be the first two candidates.
- BNB has tx history issues that would be resolved
- BSC is a POS and very expensive to run/maintain
Acceptance Criteria
- LOE backend to provide balance (including token balance)
- LOE frontend to plumb through only balance/broadcast and still render the app "correctly"
Need By Date
No response
Screenshots/Mockups
No response
Estimated effort
No response
The effort and risks vary between different client implementations:
- For
geth-based nodes, the only difference is starting the node with an additional flag:geth --syncmode light. There is a risk of not finding enough peers to stay in sync. Light nodes can still provide us with tx history or balance history data, however, they need to request them from other blockchain nodes. This introduces an additional network hop. If we assume that the node stays in sync this shouldn't be an issue, latency increase should not increase to be noticeable by the end user. Per geth docs:
Data can be requested from this light Geth instance in the same way as for a full node
...
Instead of fetching the data from a local database as in a full node, the light Geth instance requests the data from full-node peers.
For BSC, the situation gets more complex. BNB Beacon Chain does list support for running Light clients, but docs do not mention that option for BNB Smart Chain.
Still, because it's a fork of geth, it does unofficially support light mode. Unfortunately, there's plenty of reported problems, including reports of not finding enough peers to sync:
https://github.com/bnb-chain/bsc/issues/1049 https://github.com/bnb-chain/bsc/issues/702
Relevant "docs" for setting up a light client: https://gist.github.com/rfikki/e2a8c47f4460668557b1e3ec8bae9c11
To summarize:
- It seems that for our use case light nodes support all necessary features of full nodes, so not
webchanges should be necessary - LOE for geth nodes: 1d
- LOE for bsc nodes: 1-3d with little guarantee of success
@kaladinlight - curious if we should leave this open further exploration or its been ruled out already?
@kaladinlight - curious if we should leave this open further exploration or its been ruled out already?
Keep open for further exploration please. Thanks!
Closing as there has been no additional thought or talk about this recently and our direction has changed quite a bit (deep vs wide approach)