There are some clear upsides to having multiple implementations based on libbitcoinkernel that Carl Dong highlights in this short presentation on libbitcoinkernel.
There are multiple approaches that can be experimented with (including rewriting a subsystem in a different language like Rust) when an alternative implementation doesn't have to worry about falling out of consensus with Bitcoin Core. Currently there can only be one approach widely used on the network because of Bitcoin Core's dominance and general perception that it is the reference implementation.
The stringent review culture required not to introduce bugs into the consensus engine often leaks into other subsystems that aren't as security critical (e.g. GUI, tests). It is very difficult to define contrasting review processes depending on the subsystem when they are all part of the same project. Hence reviewers and maintainers have needed to push back against scope creep because the project is already too large to sustain a monoculture that generally runs on well reasoned NACKs preventing a change from being merged.
James O'Beirne highlighted some of the potential downsides though on Twitter.
I have a few arrows pointing in opposite directions on this one. On one hand, I think having multiple "shell" implementations (shared libbitcoinkernel used by different networking + mempool + ui designs) is very important because multiple teams doing parallel construction/cross-validation is good/resilient and forward progress on mempool and other important problems is stuck in the mud because it's hard to gather technical consensus to the point of merge.
These important problems become harder and harder to reason about in the abstract, and need to be actually tried to gauge efficacy in the real world. Hard to do experimentation in the wild given the sacred nature of Core.
But, on the other hand, there are some issues with multiple implementations beyond the classic "but consensus bug can come from non-obvious implementation details:"
Policy, not just consensus has a very real impact on e.g. network splits, or unupgraded miners not mining bad blocks after a soft fork due to no standardness. Having many implementations running around significantly complicates this especially if they exist to experiment with policy.
Part of the benefit of Core as the sole implementation is that it's easier in practical terms to consolidate eyeballs and do review over a single process/codebase. Review maximalism: if you have Core and some other project that's double the overhead to stay on top of changes.
There are probably more arrows pointing in either direction, and this is tough to reason about. In any case I'll keep reviewing and advocating for libbitcoinkernel because it's the clear way forward in either case.
Carl Dong added on Twitter that even if alternative implementations don't end up getting built around libbitcoinkernel it still brings many benefits:
In the unfortunate event that there doesn’t end up being alternative implementations built on top of libbitcoinkernel, the modularization of the codebase as a result of the effort will have been well-worth the trouble.
It will have achieved what orionwl pointed out here: “What kind of frustrates me, personally, is that we didn't manage to clearly separate out the consensus parts. Not to a library (which would be useful for rust-bitcoin et al), but also not even to a separate directory.”
libbitcoinkernel can actually do one better than having a separate directory: after phase 1, any unintentional re-entaglement of consensus and non-consensus code will make themselves obvious to devs and reviewers by triggering linker errors.
You can get bonuses upto $100 FREE BONUS when you:
💰 Install these recommended apps:
💲 SocialGood - 100% Crypto Back on Everyday Shopping
💲 xPortal - The DeFi For The Next Billion
💲 CryptoTab Browser - Lightweight, fast, and ready to mine!
💰 Register on these recommended exchanges:
🟡 Binance🟡 Bitfinex🟡 Bitmart🟡 Bittrex🟡 Bitget
🟡 CoinEx🟡 Crypto.com🟡 Gate.io🟡 Huobi🟡 Kucoin.
Comments