This was [posted](https://groups.google.com/g/bitcoindev/c/qMN_hy9g774/m/HRw6hokOAQAJ to the Bitcoin Mailing list a few days ago, but nobody has responded yet.
Hornet Node [3] is a consensus-compatible Bitcoin client designed from the ground up to be modular, rigorous, efficient, and modern. Developed with reference to Bitcoin Core's behavior but without any copied code or external dependencies, it is an independent passion project to express the elegance of the Bitcoin protocol in idiomatic modern C++.
Hornet enforces a strict one-way dependency graph (no cycles) between its hierarchical modules or layers, each of which is contained in its own folder and namespace. Each layer may only depend on the layers below itself. For example,hornet::protocolis the layer that defines protocol-specific types like BlockHeader.hornet::consensusis a layer above that may accesshornet::protocol. Buthornet::data, which contains data structures like the timechain itself is abovehornet::consensus, so consensus logic has no knowledge of these implementation details. This structural discipline prevents code sprawl and limits dependency surface keeping consensus logic tight.
Remarkably, we can express the full set of Bitcoin's header, transaction, and block validation rules in fewer than 50 lines of executable idiomatic C++, where each rule encapsulates one semantic criterion of consensus. The code below is a fully executable and performant implementation of Bitcoin's validation logic.
These compact C++ rulesets demonstrate that Bitcoin’s consensus can be expressed declaratively, without hidden state or side effects, and still execute at full performance on mainnet. Yet C++ remains a general-purpose language: it allows styles that drift from this discipline, and its semantics are not tailored to formal reasoning. To go further, we introduce Hornet DSL: a purpose-built language that encodes consensus rules unambiguously and enforces constraints by design.
What is it the kids say? Big, if true?
libbitcoinkerneland Voskuil & co are working on building outlibbitcoin's v3 ecosystem, so for now, those are ahead.bitcoind, i.e. an indexer and rpc method, or do something funky like changing fetch rules as is done for the fork observers.btcdmoduleslibbitcoinkernelandlibbitcoin- would need to be deployed as a (whitelisted) private node behind a bitcoind. I've similarly done this in the past when building tools withbitcoinj,bitcore- eventoshi- and so on (and is also how I initially ranbtcd, until 2020 or so), simply because these either don't implement the whole thing, or aren't battle tested.