FetchBlock is actually implemented through chain-sync?

[eyeinsky]

It looks like fetch block is actually implemented through local chain-sync, I wonder whether the Block-Fetch mini-protocol in cardano-node did not work as expected, or does it not add any real value? I.e I guess if the Block-Fetch mini-protocol isn't inclusive in the first block in the range then it indeed doesn't add much.

[KtorZ]

Kupo assumes the presence of a local node (and thus, use of the local client protocols) mainly for two reasons:

1. Kupo doesn't redo any validation. It assumes the data is already checked, which isn't a guarantee we get from the block-fetch. Because DApps and other critical software may rely on the accuracy of the index built by Kupo, it would be potentially catastrophic to get and trust invalidated data from a remote data point.

2. It's actually an order of magnitude faster to fetch data through the local chain sync. So because of the first reason and because we assume the presence of a local node, there's truly no reason to go through TCP + block fetch.

[eyeinsky]

Hmm, are the blocks not validated by the node regardless of how you get them?

Regarding connection method, I think both protocols can be run over both a local socket (a file) or over the network (TCP). Though am currently unsure on whether all node-to-client and node-to-node protocols are served over both methods.

Anyway, I was just looking at Kupo's code base to see if it uses the block-fetch mini-protocol, use case being just getting a single block from the node. The downside with using chain-sync for that is that I would actually need to find the block before the one I want, and then do the query. And to find the block before, I either need to have a copy of all block headers (up to the block I want) or use some external source to find that info, both rather unergonomic. :(

[KtorZ]

Hmm, are the blocks not validated by the node regardless of how you get them?

Yes, but I cannot trust a remote node that isn't under my control! This is dangerous pattern, especially for an indexer which then becomes a source of trust for many applications down the line.

Regarding connection method, I think both protocols can be run over both a local socket (a file) or over the network (TCP). Though am currently unsure

In theory yes, in practice, no. There's (purposely I've been told) no support for running node-to-client protocols over TCP precisely because it breaks the security model boundary. On a node-to-client connection, nodes and clients are expected to have a trusted connection. The choice is debatable as this is mostly a question of infrastructure and how you chose to deploy it in the end. It could very much be that a node and kupo are part of the same infrastructure and connecting via secured connection bearers, which would be fine.

And to find the block before, I either need to have a copy of all block headers (up to the block I want) or use some external source to find that info

Kupo does that for you very well. It already indexes all checkpoints of the chain and has an API geared towards accessing checkpoints ancestors. For example, say that there's a checkpoint at slot 42, one at slot 48 and you already have the one at slot 48 but wants to know what the checkpoint before. You can ask for /checkpoints/47 and will be returned the nearest ancestor downwards, so the checkpoint at 42.

Having said that, I concede that there's a possible use-case for supporting node-to-node, with the proper disclaimer in place.