People [sadly] put a lot of "exotic" cryptography/distributed systems under the term "blockchain" eg. If you want to do byzantine agreement with sub quadratic message complexity, where do you look it up? If you want to do high throughput threshold signing, where do you look it up?

An allergic reaction to the term "blockchain" is to miss the forrest for the trees... and I would imagine the authors share the same point of view.

"Rule of law" isn't a thing in much of the world. Not understanding is one thing but what's with the arrogance of many living in more stable economies? In a place like Nigeria, holding funds in self custody as USD-pegged stablecoins for example is one of the safest and most conservative ways to save. People would rather the US Federal Reserve take that seignorage, because they don't trust their own government.

https://en.wikipedia.org/wiki/Cryptocurrency_in_Nigeria

Or look at Zimbabwe just two days ago. There goes 40% of your savings in that new supposedly gold-backed fiat currency...

https://www.bbc.com/news/articles/c8el4kgk98eo

> the wanton abandonment of the rule of law we see in that space in practice

This applies only to the laws of the legacy states, not the laws of mathematics.

Blockchains are a highly lawful place in this sense.

> the rise of machine learning (ML)

Adding to your point that we had the decentralized "future" promised by blockchains in the 90s, "Machine Learning" is a field older than computers. Every decade it gets a new buzzword painted on (now it's "AI"), but in the end it's all just applied statistics, linear algebra, and optimization.

I didn't really infer that meaning. It sounds more like an innocent transition sentence and not necessarily the _only_ universal solution to that problem.

For some reason, there is no current software implementation of a "globally consensus-replicated, peer-to-peer, append-only, signed-message log store, with Turing-complete programmable matviews that pump by reducing over the store's log messages as CQRS commands per some set of validity rules"... other than the ones that are also permissionless to transact upon, and thereby are "blockchains."

I find that almost all (non-blockchain-space) tech people who find "blockchains" interesting as a concept, and see potential use-cases for them in system architecture design, are actually thinking about the uses of this taxonomic parent category — whether they realize it or not.

But the only way to currently talk about this concept — in a way that doesn't require you to first give an extensive definition of the idea you're talking about — is to use the word "blockchain", even though that's not precisely what you mean.

Since there's no software system that's just one of these things, without also being a blockchain, there's no word we've invented to talk about the set of such software systems.

If someone came along and actually made a piece of software that was all the things a blockchain is, except for the "open submission of transactions, with spam control using eStamps that necessitate the introduction of a whole economy into the system that it doesn't otherwise require" part, I think it'd become a huge thing among tech crowds, and "blockchains" as infra systems would be completely forgotten about in favor of (whatever name these parent-category systems would be given once we have any to talk about.)

Sadly, I think there's very little interest in doing this, for two reasons:

1. Anyone who builds such a system knows that with just a little bit of extra implementation effort, they can introduce such an economy, turning their thingy into a "blockchain", and potentially making a bajillion dollars by being the first one in the door of that new economy as it grows with usage.

2. Most blockchain node software is designed to be flexible-enough in its definition of a blockchain network, that it can be flexed toward being used in a "Proof-of-Authority" network implementation that doesn't actually have an internal economy. And, because blockchain node software has a lot of engineering effort already invested into it, vs. systems of this parent category that have none yet — it makes a lot of sense, as a systems engineer who just wants an infra component to slap into place, to use blockchain-node software for these use-cases, configured into a Proof-of-Authority mode where the economy logic is vestigial. It feels like an "overkill" solution, but the alternative would be DIYing a parent-category system and having to learn all the Hard Lessons that blockchain-software engineers already figured out about non-repudiability, storage architectures amenable to state garbage-collection, scalable consensus mechanisms that don't halt-and-catch-fire during hard-fork network upgrades, etc.

> What are the authors smoking?

no mention of drinking from the money-matters-most crowd .. how convenient

Isn't the basic idea that one blockchain runs the code to be able to (1) "Look up" a trade price, (2) Okay it with both users, (3) Then simply make the two transactions?

The code is (or should be) fully auditied and there is absolutly no chance for anyone to "steal assests while in transit", in fact, I'm hard pressed to even understand what you mean by "steal in transit"?

The authors may sound "hand-wavy" about it only because its a solved problem.

Some ad-hoc feedback on [4]:

- You don't explain that BFT in SMR is also a property of pre-blockchain 1990's permissioned systems such as PBFT or (Byzantine) Paxos. You don't distinguish between LCR + PoW (Nakamoto consensus) systems and PBFT + PoS systems that have much better latency and finality properties.

- You suggest a "governed" list of signers. If this is permissioned, then this might be a system that's "as good as it gets" in terms of low-latency, high-throughput SMR, and could be well-governed (law abiding). But then I'd eschew the blockchain moniker, as that's so tainted with fraud and BS.

- The "Introduction for crypto skeptics" does nothing to alleviate the crypto skeptics' concerns.

- You claim that updating protocols used by multiple parties is "obviously time and resource consuming" (correctly, in my view), then claim that smart contracts can somehow solve this (incorrectly, in my view) without any motivation or explanation or evidence whatsoever, except to say that "automating the process" is more efficient. Yes, obviously automating processes is more efficient than doing them manually, but how do smart contracts allow you to automate the process of updating a protocol when new circumstances arise?

[dead]

[dead]

Thing is, the underlying central chains getting so expensive that nobody wants to use them for everyday transactions.

So, offloading is the only way to make them usable again.

I off-ramp only every second month because of absurd gas costs on Ethereum.