Discuss architecture

[louisinger]

the first commit proposes an architecture that differs from the neutrino's one:

• neutrino-elements is not a full node like neutrino: it means that we never send message to other peers. The Peer interface aims to only fetch data. The idea is to be able to use an explorer (or a full node or whatever compliant to Peer interface) to get the data of the chain. In my opinion, it is not necessary to implement a full node to be able to use the compact block filter: we only need filters and block headers. Of course, later we could write an element's full node and use it as a "PeersPool".
• neutrino strongly coupled the ChainService (which sync the chain data) and the utxoScanner (uses block filters to find elements). Here I choose to use the Repository pattern in order to separate the service that fetches the data and the one that uses filters to find elements of the chain. The main idea is to be able to use UtxoScanner without running the PeersPool service if we already have a DB containing headers and filters.

cc @tiero @altafan @sekulicd

[altafan]

• neutrino-elements is not a full node like neutrino: it means that we never send message to other peers. The Peer interface aims to only fetch data. The idea is to be able to use an explorer (or a full node or whatever compliant to Peer interface) to get the data of the chain. In my opinion, it is not necessary to implement a full node to be able to use the compact block filter: we only need filters and block headers.

Don't think the node is essential for now. It is enough to connect to an elements node if needed. Abstracting this dependency behind the Peer interface was the right thing to do.

• neutrino strongly coupled the ChainService (which sync the chain data) and the utxoScanner (uses block filters to find elements). Here I choose to use the Repository pattern in order to separate the service that fetches the data and the one that uses filters to find elements of the chain. The main idea is to be able to use UtxoScanner without running the PeersPool service if we already have a DB containing headers and filters.

With this architecture, it is crucial for the UtxoScanner to perform only read operations against the repositories otherwise there might be conflicts with the write operations performed by the PeersPool. We should make an effort to avoid having conflict if the UtxoScanner has to write to the repo.

This makes me wonder what's the reason for this effort: why do we want the UtxoScanner to not be related to the PeersPool?

They are part of the same "light-neutrino" service, and their real usefulness should be running toghether in a standalone service in order to have a dedicated process interacting with the blockchain. This way, all those services depending on blockchain data could be lightened and interact with this service instead of doing the same things by their own.

[tiero]

why do we want the UtxoScanner to not be related to the PeersPool

The main benefit would be to run this services in heterogeneous setup like a browser if compiled to WASM for example.

Having a "pluggable" repository, would allow us to use localStorage for example.

[tiero]

FYI may be interesting using WebRTC for doing Bitcoin Peer calls https://github.com/mappum/webcoin via bridges https://github.com/mappum/webcoin-bridge

[tiero]

May be interesting

https://github.com/cloudhead/nakamoto

https://github.com/cloudhead/nakamoto/blob/master/docs/architecture.svg