As I mentioned in a Take two weeks ago, I believe the risk (or opportunity, based on your viewpoint) of protocol ossification is somewhat overstated, at least at this current moment.
Indeed, the frequency of soft forks has considerably diminished over the years, with the last one being Taproot in 2021. However, this appears to be more related to a lack of enthusiasm regarding the suggested upgrades since then, rather than an absence of an efficient method for executing protocol upgrades. (Although that issue is not entirely resolved either.)
Bitcoin Core developers typically receive funding without conditions or are fully volunteers, implying they are not obligated to work on any particular area of the codebase. Consequently, their focus and efforts will be directed towards whatever they find most engaging or significant to address. Up to now, that hasn’t been any of the soft fork initiatives: the various covenant-style opcodes are not clearly viewed as offering the kind of innovative use cases that warrant prioritization, and although Drivechains sound impressive in theory, their primary disadvantage remains that miners can ultimately misappropriate coins from them.
Nonetheless, even if Bitcoin Core developers lack interest, it doesn’t imply that upgrading Bitcoin is unfeasible. For better or worse, anyone equipped with the necessary expertise (admittedly not a low threshold) can always implement a soft fork through an alternative client, even as a user activated soft fork (UASF). Yet, despite occasional murmurs, no one has accomplished this yet.
I suspect this is at least partly because the advocates of these soft forks are not convinced that a UASF would actually succeed. And if a UASF wouldn’t succeed, perhaps the upgrade is not worth pursuing in the first place…
This article is a Take. The views expressed are solely those of the author and do not necessarily reflect those of BTC Inc or Bitcoin Magazine.