romanz / electrs

An efficient re-implementation of Electrum Server in Rust
MIT License
1.1k stars 407 forks source link

Feature: Separate daemon + rocksdb from electrs interface #1030

Open caniko opened 6 months ago

caniko commented 6 months ago

Is your feature request related to a problem? Please describe. I am considering forking the repository, but I only need the backend: The bitcoind daemon and rocksdb schema + configuration. electrs is monolithic, it shouldn't be.

Describe the solution you'd like A package focused entirely on the bitcoind daemon, and its storage. Currently, the only storage option is rocksdb; however, there could be other ones. The new package could be electrs-daemon.

Describe alternatives you've considered Just forking, and removing the components that I don't need.

Additional context None.

antonilol commented 6 months ago

+1 related to #765 but that pr in inactive (sent a message a year ago but no development since then there)

rust trait are really good for this, would be cool if you could choose your own storage backend (like started on in the linked pr) and choose the interface (electrum rpc, or something else?)

caniko commented 6 months ago

@antonilol, you could even have no interface, and have your workers open rocksdb directly. RocksDB supports concurrent reads, most on disk KVs do.

This is related in the way that it is a nice way to decouple the two entities/apps. One that deals with keeping an updated database, and the other as the electrum interface.

romanz commented 6 months ago

Concept ACK :)

I'll be happy to help with the design and review of this idea.

romanz commented 6 months ago

(and sorry for the delayed response...)

Kixunil commented 3 months ago

This is somewhat related to my idea of having an alternative chain-storing backend. The backend could maybe store some indices on its own and provide a stable interface to retrieve the data locally and remotely.

electrs itself doesn't do that much on top of storing data so I'm not convinced it's worth splitting up into individual daemons if one of them would be just translating json RPC to something else. It'd make more sense to have it as a crate that people could develop new stuff on top of.