Scalability is the proving ground where clever designs go to

Question

Scalability is the proving ground where clever designs go to

die. One thing we talk about at @kadena_io is the "earnings report problem" to illustrate how so many seemingly attractive approaches fall over in real world use, coming from experience scaling trading exchanges. \1

Next time somebody's touting a system design that magically handles any load, the earnings report problem will usually reveal the weaknesses therein. Remember that scalability isn't raw speed but the ability to throw more resources at a problem without falling over. \2

A fundamental problem in scaling is data localization. (This is the real "sharding" problem in distributed systems, not the tortured crypto version). A stock exchange might scale on symbol: one node does the As (AAPL etc), one does Bs, Cs etc. Simple and effective right? \3

Sharding in symbol is great ... until Apple releases it's earnings report. All of a sudden, ALL your volume is on AAPL. All your nodes handling the rest of the alphabet sit idle while your poor node for the As grinds to a halt under overwhelming load. \4

How does this apply to blockchain? Simple, especially on modern/DeFi chains, but even look at Bitcoin. Today you can send a tx that draws from UTXOs anywhere in BTC history. If you scaled BTC naively, it would be trivial for an attacker to take you down with a single tx. \5

It's a sure sign of BS when projects don't have a simple story for data localization, meaning "the data needs to be where you need it when you need it." Earnings day means AAPL needs to be pretty much everywhere. In blockchains it can become an attack vector for DOS. \6

Next time you hear somebody bragging about a scaling approach (that hasn't shipped yet natch), ask how they handle data localization, and be ready for blank stares or total magical mumbo jumbo. Ask them how they'd handle the earnings report problem. \7

DAG designs, distributed hash tables, UTXO-based, atomic composability all fall apart with this simple test. The single hardest part of any distributed system is moving data around to where it's needed. \8

Let's take ETH 2.0's 1000+ chain design, which magically transacts across shards in a single atomic unit. How exactly is data localization handled here? Good luck getting a straight answer to what happens when you airdrop to 1000 accounts that are localized to different nodes. \9

Meanwhile, @kadena_io 's answer is simple: braided chains. Each is independent but securely linked to the other. It is up to the dapp dev to pick a localization strategy that fits the bill. Don't forget, you need Pact to make moving data safe and effortless. \10

In other words @kadena_io doesn't limit how you scale your dapp, but gives you rock-solid tools to do it with. We scaled $KDA (it's just a Pact contract after all) so this is real technology not promises. We're excited to see what devs deliver! Build the future on @kadena_io \end