oasisprotocol / oasisprotocol/oasis-core

oasis-node/status: Correctly show light client status

Open
#6,388 0 comments 0 reactions 0 assignees View on GitHub

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:

  1. stateless client node - see
  2. full node's state sync see

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:

  1. One for the the actual local light client (if applicable depending on the mode/config).
  2. 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

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.