|
| 1 | +--- |
| 2 | +layout: post |
| 3 | +commentIssueId: 36 |
| 4 | +--- |
| 5 | +There's an |
| 6 | +[interesting post on scaling](https://blog.ethereum.org/2014/10/21/scalability-part-2-hypercubes/) |
| 7 | +by Vitalik Buterin over at the Ethereum blog. I always read these posts with |
| 8 | +excitement and a little trepidation, as I wonder if they'll come up with |
| 9 | +some scaling trick I missed for pettycoin... |
| 10 | + |
| 11 | +After several false starts, I rejected the idea of having multiple |
| 12 | +blockchains and special inter-shard messages, and this post provides a |
| 13 | +nice overview of the problems. In particular, the problem where a |
| 14 | +miner on one shard refuses to release the details of their block; |
| 15 | +others watching that block can complain, but by definition they're in |
| 16 | +the minority. Vitalik suggests randomly querying your peers, but that |
| 17 | +leaves you open to a Sybil attack, where the bad miner creates fake |
| 18 | +peers who talk to everyone, and then discloses enough of the unknown |
| 19 | +transactions to placate the majority. |
| 20 | + |
| 21 | +The key weakness of the sketch, however, is that Vitalik asserts that |
| 22 | +most transactions will be shard-local. That might be true of |
| 23 | +Ethereum, but it's not true of a bitcoin-like payment network. Even |
| 24 | +if we allow that those dealing with large numbers of transactions will |
| 25 | +sit on numerous shards, you still have most transactions crossing |
| 26 | +multiple boundaries. That means everyone wants to be neighbors, and |
| 27 | +if you're successful in discouraging them all you've done is increase |
| 28 | +messages until the point where scalability gains from sharding are |
| 29 | +defeated by the increase in transactions simply relaying messages for |
| 30 | +other nodes. |
| 31 | + |
| 32 | +In the end, pettycoin regretfully returned to a "miners must know all" |
| 33 | +model, but nodes can prove any mistakes they find. In particular, to |
| 34 | +address the data unavailabilty attack, miners must "prove" they know |
| 35 | +all the transactions in various previous blocks by hashing them with |
| 36 | +their own reward address. This is a slightly-ungainly[1] compromise, |
| 37 | +since we have 1 byte of hash for each shard in the previous |
| 38 | +(power-of-two-spaced) 10 blocks, and if a miner gets it wrong you need |
| 39 | +to send all the transactions in the incorrect shard to produce a |
| 40 | +proof. |
| 41 | + |
| 42 | +[1] ungainly: an irregular noun. My solution was "ungainly", your |
| 43 | +solution was "ugly", their solution was "a horrible hack". |
0 commit comments