oasisprotocol / oasisprotocol/oasis-core
oasis-node/status: Correctly show light client status
Nobody has claimed this yet.
- Dominant language
- Go
- Stars
- 369
- Forks
- 151
- Avg merge
- 1d 3h
- Merged PRs (30d)
- 6
Description
What
oasis-node control status should display the local light client status.
This client is created for the:
Motivation
This would be useful to monitor stateless client (e.g. was missing this during #6385), or possibly consensus state sync.
Existing status
Current light client status is confusing / incorrect:
"light_client": {
"latest_height": 0,
"latest_hash": "0000000000000000000000000000000000000000000000000000000000000000",
"latest_time": "0001-01-01T00:00:00Z",
"oldest_height": 0,
"oldest_hash": "0000000000000000000000000000000000000000000000000000000000000000",
"oldest_time": "0001-01-01T00:00:00Z",
"peer_ids": [
"12D3KooWHjqvFidQgDcw24A88KX1oaPjvqiLq6X8nPi4zMnSCDu6",
"12D3KooWKTvsowgyv3WRTVm2dvEBtxpKsshWKtKJmGriGDPdzRBM"
]
},
Concretely this is not even light client, but an actual wrapper over the remote providers.
Moreover, the linked documentation is a bit misleading as trusted blocks are not obtained from the local consensus backend?
Solution:
Two statuses:
- One for the the actual local light client (if applicable depending on the mode/config).
- One for the consensus light service (
consensusAPI.LightService), where we should probably get rid of anything but the remote providers peer ids.- Albeit I am confused why not use full node consensus backend here over remote providers?
Any preference for nesting and naming?
Btw where is the light client serve part? I don't see any like for other protocols so I assume CometBFT full nodes serve this by default?
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with oasis-node control status and the linked Go entry points in consensus/cometbft/light/client.go, consensus/cometbft/cometbft.go, full/full.go, and light/service.go. Trace which status currently wraps remote providers, then separate the local light-client status from consensus LightService data. Done means both statuses accurately reflect their respective components and naming or nesting is settled.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go
- Domain
- blockchain, cli
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 38/100