Harden fetching of light blocks inside enclave

[martintomazic]

Context

Both RONLs and ROFL run consensus verifier inside the enclave with the embedded trust root. In case the light blocks are not available on the host local storage, they are fetched from the remote peers.

In #6526 the number of light providers was increased from 2 to 10. With i. max 3 retries before the process aborts and ii. single primary provider peer refresh if all providers fail (tryProviders), light blocks are now fetched from at least 12 peers compared to old 4 peers, before the runtime process aborts and later restarts.

Problem

Problem 1: We have cca 40 peers and only few of them might have ligth blocks, so ideally we try them all before aborting.
Problem 2: Peer fedback is not propagated out of enclave in case of invalid light blocks.

Possible solutions

1. Replace more than primary provider inside tryProviders if none of the providers responds.
   • Check that this does not somehow affect light client logic that expects static peers.
2. Extend RHP with request IDs and give enclave option to submit feedback.
   • Likely with smart client-server interaction and a bit of caching we might get rid of IDs as suggested by @peternose.
3. Use host as proxy and do peer validation/feedback on the host side, e.g. oasis-node: Independent consensus light history and pruning #6430. Obviously enclave still does its own validation.

[martintomazic]

In addition, if node has configured persistent peers, p2p clients should probably prioritize such peers, or include at least one from this set for every multi-peer request.

E.g. for the light providers we could probably prioritize persistent peers if configured.

[martintomazic]

To have some concrete numbers I checked the current mainnet network from the normal client node, by fetching light blocks from all connected light protocol peers every minute:

For height 26_000_000 results are actually quite good, 14 out of 42 peers were able to respond :

{"caller":"provider.go:64","level":"info","module":"light-peer-count","msg":"light count","responded":14,"total_peers":42,"ts":"2026-05-26T19:42:36.334991331Z"}

For comparison for height 24612496 (3 months older) only 3 peers responded:

{"caller":"provider.go:64","level":"info","module":"light-peer-count","msg":"light count","responded":3,"total_peers":41,"ts":"2026-05-26T19:50:11.352633149Z"}

Regardless we should work on hardening it as more nodes may start pruning.