Skip to content
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.

Commit b5039e9

Browse files
committedOct 26, 2014
New post.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
1 parent 994552f commit b5039e9

File tree

1 file changed

+43
-0
lines changed

1 file changed

+43
-0
lines changed
 
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,43 @@
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

Comments
 (0)
Please sign in to comment.