A Light Client Needs Peers, and This Deployment Has None. Two of Its Checks Already Work Anyway

The point of one

A full node downloads everything and checks everything. A light client downloads headers and checks proofs, so a phone, a browser or a small service can decide for itself instead of believing whoever answered.

The premise is plural. You ask several independent peers and compare, because a single source that lies to you is indistinguishable from a single source that does not.

Two of its checks already work here, and they were re-run for this page

Walk the canonical chain and confirm each block's parent hash equals the previous block's hash.

Twelve consecutive blocks were fetched. Eleven links checked, eleven intact, and the canonical head's hash equals the newest block's.

And a block's transaction digest can be recomputed from the block's own transaction list, which this estate did and published.

Those are real, they need no account, and they need no trust in us. They are also the easy two.

The three that do not work, and why each fails

was this block agreed? no certificate is published could I check the certificate if it were? the validator listing returns no public keys is this account, identifier or credential really in that state? no endpoint returns a proof

Note that the first two are one problem in two parts. Publishing a certificate without the keys to check it against would look like progress and deliver none.

And underneath all of that, there are no peers

This deployment does not run a peer-to-peer network. The mode it runs builds an in-process channel network, four engines inside one program, which is why the process owns exactly one listening socket.

So a light client here would have exactly one thing to talk to: the same endpoint everyone already uses.

A light client whose only source is the endpoint it exists to avoid trusting is a more complicated way of trusting it. That is the real blocker, and it sits underneath the missing artefacts rather than beside them.

Which gives a fix order, and it is not the obvious one

The obvious order is: publish the certificate, publish the keys, add a proof endpoint, write the client.

The useful order starts earlier: an independently operated node. Until a second party runs one, every artefact you publish is still one party's word, and a light client comparing one source with itself proves nothing.

None of the four steps is wasted. Doing them in the wrong order produces a component that looks like verification and is not.

And the honest sizing, again

Nothing on this network is worth attacking. Four validators, one operator, one process, no value.

The reason to care now is that the ordering above is a design decision and design decisions get cheaper the earlier they are taken. A light client written against an interface that never published a certificate will have to be rewritten when one appears.

What you can check yourself

solidus_canonHead, then solidus_getBlockBySeq downward, comparing each parent_hash with the previous block's hash

They match at every step. Then look for a signature, a signer list, a public key or a proof in any of those responses, and note there is none.