pull down to refresh

Don't the UTREEXO bridge nodes need to be full blockchain archives?

From the docs

https://github.com/utreexo/utreexod

there is option to make bridgenode non archival, so the answer would appear to be no, certainly not EVERY bridgenode needs to be full archival. My poll question could be reformulated, "does any bridgenode need to be full archival?" Intuitively I am with justin_shocknet here and feel that the answer must be yes, and yet the docs are confusing.

A, there is the non archiving bridge node option and
B, (from the link above) " Since miners and nodes publish blocks and transactions without proofs, these nodes are needed to allow for utreexo nodes without a soft fork."
imples that if miners and nodes DID publish blocks and transactions with proofs, there would be no need for bridge nodes. I think probably there is still a need, but a different need than what the documentation is pointing at.

reply

This is all explained better in the utreexo bip

"there are three likely types of nodes:

Compact State Nodes (CSNs)
Bridge nodes
Archive nodes
CSNs have the goal of minimizing data storage and download while performing block validation. Archive and bridge nodes store more data and provide this data to CSNs.

Bridge nodes are nodes that can add inclusion proofs to mempool transactions, support the same set of messages as CSNs, and should in fact be indistinguishable from CSNs on the network. Archive nodes are able to serve the blocks and the inclusion proofs. However, they are not able to generate the inclusion proofs as they do not keep the full UTXO set.

Note that the archive and bridge capabilities of a node are separate; a bridge node can be bridge only, without previous block proof data, and an archive node doesn't need to be able to bridge.

The one exception to this flexibility is that archive nodes must provide both the blocks and the inclusion proofs. While theoretically possible to split these two resources, the blocks are quite small relative to the block proofs, and it simplifies clients to be able to rely on being able to request both over the same connection."

https://github.com/utreexo/biptreexo/blob/main/bip-0183.md

reply