[derefr]

The "reusable for free" aspect is about building ecosystems. Abstractions that can be freely integrated with have low barriers to entry to existing complementary systems being updated to integrate with them, or with new systems evolving to wrap them or work in terms of them.

This (plus the fact that blockchain smart contracts are generally limited in size) has the effect of commoditizing much of any given design, instead of keeping it solely in the hands of whoever made it. Things don't remain proprietary; people build their own versions of each contract that are "compatible" per whatever ABI the ecosystem was relying on, and then the ecosystem generalizes its integrations to include those de-facto-ABI compatible systems as well.

And this makes the path from the development of a new experimental + proprietary + closed-world system that requires direct interaction through its own first-party frontend, through to what investment bankers would call "financialization" of the abstraction that system defines as a general-purpose category of financial instrument, very short on blockchains.

This means that in the modern day, there's often far more promise in how financialized a given system is likely to get, when that system starts off as a set of blockchain smart contracts, than when that system starts off as a proprietary brick-and-mortar financial vendor's firm-internal non-market-tradable security.

Meanwhile, the brick-and-mortar fi-tech firm to get their security financialized, they have to convince brick-and-mortar exchanges to carry it for trading; and then other vendors have to come along and copy that success (usually with all the same exchange-side friction + backroom dealings required); and then someone further has to come along and define an abstraction into existence for those live instruments to be reframed in terms of; and everyone has to faff about redoing how their systems work so that those instruments actually fit the abstraction, since the abstraction will be what financial regulations for the financialized security will be written in terms of, and so their own original versions of the security may end up legally non-compliant. And that whole process takes ages — especially if the fi-tech companies push back on the abstraction standard, insisting that their version should be permitted as a MAY option or grandfathered in somehow.

[mmooss]

We mostly agree on your points. As I said, the FOSS aspects (which you describe well) are of interest to "undercapitalized startups, amateur financial services, and hackers interested in innovation in this area."

I think my additional points are essential, however: Consumers (and the public) are not interested in rapid development of financial instruments, they are interested in integrity and availability. To them, 'rapid' is a negative. And status quo powers in the financial industry, the banks, are not interested for other reasons too.

Maybe the best thing to develop is a way to make blockchain financial instruments have integrity and availability to match the existing financial system. The integrity and availability are awful, with a high frequency of scams, arguably enabled by the 'rapid' development aspects. If integrity and availability could be integrated into the abstractions, there might be a lot more interest.

[vvpan]

Well eventually consumers don't really know how the system they are using works. Prediction markets run on blockchain but few people know this. Robinhood is offering trading in perpetuals of companies that haven't IPOed yet and you would not know.

[mmooss]

> Prediction markets run on blockchain

Why? It's not efficient computing. To give techy users confidence that their bets are immutable?

[derefr]

I get the sense that it's mostly that institutional HF/liquidity traders can trust that the system isn't unfairly advantaging anyone.

In a centralized system where trades are accepted in the order presented, HF/liquidity trading systems gain competitive edge by competing on speed-of-light trade-submission delay. This requires building FPGA-based trading logic colocated with the exchange hardware, or even accepting margin-capturing deals with the exchanges to have your bots run as workloads on the exchange's own hardware. This is a positional "rent-seeking contest", where nobody is gaining by competing, since all the resources are spent on the competition itself.

Blockchain architecture is designed in such a way that you can effectively trust a blockchain to have "nothing up its sleeve" in terms of how or when a submitted transaction will be accepted/linearized into the ledger. This is mostly due to blockchains (even proof-of-authority blockchains) being multi-region-distributed multi-master systems that must linearize their per-validator-node state using distributed consensus protocols; and which therefore have formalized rules for which transactions will be prioritized for inclusion, that are stated in terms of an abstract machine using things like tx fees and hash difficulty, rather than relying on any property of the underlying physical substrate of nodes and network connections (since such properties are ephemeral observations that can't be independently audited, whereas tx fees and hash difficulty are immutable properties computable upon the tx payload data [plus current chain state] itself.)

---

Mind you, you could totally have a centralized exchange with formalized abstract rules for how inbound trade orders will be linearized, that operate on some quantized timestep, and then ignore physical arrival time of orders within each timestep in favor of other well-specified factors.

But how would you prove to the traders on your platform that that's what you've built — i.e. that you didn't secretly prioritize certain trades over others (maybe faster trades, maybe something else), in a way where they can accept that guarantee, and so dedicate all of their budget to "actually trading", rather than feeling obligated to continue to spend much of their resources hunting for such hidden opportunities to bias the platform in their favor?

---

Blockchains do this by operating in such a way that it's basically impossible for the blockchain network as a whole to have the tx-acceptance-and-ordering semantics it has, without each individual node having the operational semantics you would expect of it. Nodes can (and do) prioritize their own txs for inclusion in blocks they validate themselves (which is fine, as the consensus algorithm ensures in one way or another that no validator can keep the advantage in validating more blocks.) But in all other ways, blockchain tx acceptance and ordering must be "fair": since you can spray the same tx across multiple validator nodes, and they'll each independently try to include it in the next block they produce, any one node biasing inclusion against your tx would just result in that node potentially losing out on collecting your tx's fees (i.e. being less profitable than a node without said bias), since another node will come along and build a block that does collect that fee. (In fact, in a chain-weight-based PoW consensus approach, if your biased block and the other node's unbiased block form sibling side-chains, the unbiased sidechain with its higher collected tx fees is "heavier", and so preferred by the network.)

Blockchain networks themselves would say they design things this way for transaction censorship resistance: since blockchains ensure txs land in blocks (and those blocks land in the canonical chain) through economic incentives, the system has to be designed to prohibit structural private bias against certain kinds of txs or blocks, since if such bias was permitted, those txs/blocks could be punished to the point that they'd just never be "profitable enough" to make it into the chain at all.

It just so happens that a trading platform being designed around "transaction censorship resistance", also inherently precludes the possibility of traders on that platform engaging in the rent-seeking contest of HFT. (To the point that you could hypothesize the converse: if a trading platform claims to be built on a blockchain-like substrate, but enables HFT, then you should worry about its censorship resistance!)

[mmooss]

Thanks. I would just add that exchanges have been sufficient for traders for centuries (millennia?) before blockchain, including high-frequency.

Can blockchain performance can keep up with high-frequency?: What if I buy an asset then want to sell it before the blockchain has registered the purchase, and then the next person wants to perform a transaction. Where's the proof then?

Even if we brute-force the resources to provide performance for a small exchange, could it scale up?

Maybe my understanding of blockchain performance is outdated or based on certain tech or situations. Or maybe it's a probem on the todo list (normal for a developing tech).