Hi,<br /><br />Sharing the code for a small side project of mine, bitcoin backbone<br />a natively multi process full node written in rust, wrapping the core's<br />libbitcoinkernel (v27.0 iirc). This is full demo code for now, though<br />it got to the point where blocks can be downloaded from a vanilla bitcoind<br />peer and the heap of C / Rust / CPP code built correctly on both ARM <br />(Darwin) and x86_64 (Debian 12) platforms. The whole build system is<br />still a huge bunch of dirty hacks, but it's done without binding generator<br />or whatever. That's good to keep the build toolchain strictly minimal.<br /><br />Architecture is for now one main process (`backbone`) running the<br />libbitcoinkernel and orchestrating connections with traffic network<br />dedicated process (`block-relay` and `addr-relay`). Configurations<br />is very basic and I've not tested on all networks so far (reg, main,<br />test, etc).<br /><br />Code can be download here (head commit 689e9df60)<br /><br />git clone git://bitcoinbackbone.org:/public-release.git<br /><br />Few lines of feedbacks on the libbitcoinkernel. First and foremost,<br />a pure C API is very fruitful for crossing the boundaries between<br />the different langages memory model. While in theory, you can e.g<br />write your CPP code in Rust code, in practice a lot of CPP abstractions<br />doesn't map well equivalently in Rust (--or whatever other langs). For<br />now, hacked a custom C API on top of the libbitcoinkernel with basic<br />block processing and chainman init/shutdown, though the ideal one<br />would keep all the state on the CPP side. And allow multi-threaded<br />code access on top.<br /><br />Second, while writing the block-relay process I figure out that<br />for some data structs one might be willing to check the syntax <br />structure of the headers by calling the libbitcoinkernel methods<br />as pre-checks __before_ to pass full blocks to the main validation<br />one. So you could have multiple same-version shared libbitcoinkernel<br />code in you're different process, one with the chain state the other<br />"empty". That way you can verify a subset of the consensus rule, without<br />re-implementing the rules in your other lang, at the risk of f*kcing them<br />up or deviating.<br /><br />Third, I've not starrted really to work on tx-relay, but there is the<br />question of validating at some moment the transactions you're receiving <br />against the spent UTXO to verify the "spent" UTXOs are indeed part of<br />your latest validated UTXO sets. In a multi-process setup, this UTXO set<br />state might not be fully live in the same memory space and there are<br />indeed challenge to that correctly. There are few hacks I'm brooding on,<br />in the style of utreexo, though here you don't need proofs as it's in<br />the same "full node" boundary. It's an interesting question.<br /><br />Keep building.<br /><br />Cheers,<br />Antoine<br />OTS hash: 3c8c398a8730539303767a20b1408dd887cb955ae9d602590c57277dd52f645f

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &quot;Bitcoin Development Mailing List&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an email to <a href="mailto:bitcoindev+unsubscribe@googlegroups.com">bitcoindev+unsubscribe@googlegroups.com</a>.<br />
To view this discussion visit <a href="https://groups.google.com/d/msgid/bitcoindev/9812cde0-7bbb-41a6-8e3b-8a5d446c1b3cn%40googlegroups.com?utm_medium=email&utm_source=footer">https://groups.google.com/d/msgid/bitcoindev/9812cde0-7bbb-41a6-8e3b-8a5d446c1b3cn%40googlegroups.com</a>.<br />