| 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!) |
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).