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.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?
Note 2 important things:
Until then, there is nothing to check. I'm confident that someone has reached out over email though.
It's hard to respond without being able to read the source. Once there is source, there will maybe be more responses.
As it is unfinished and there is no source, it is at least not true yet. I'd be surprised if it stays at <50 rules but I'm always happy to be surprised.
As for big, it will depend on how it will be reviewed, maintained and built upon. We know that there are people working on
libbitcoinkerneland Voskuil & co are working on building outlibbitcoin's v3 ecosystem, so for now, those are ahead.Bottom line I look at it this way: if tomorrow I'd have to build something that validates blocks and is exposed to the public network, the options I'd have would be, in order:
bitcoind, i.e. an indexer and rpc method, or do something funky like changing fetch rules as is done for the fork observers.btcdmodulesAny other option - including for now
libbitcoinkernelandlibbitcoin- 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.Long overdue.
#1232826
cc: @optimism
Diversity never hurt a soul. When it comes to Bitcoin, we definitely need more of it.