Shardcoin - A Blockchain Partitioning / Sharding proposal

[crazy_rabbit]

I think the question is what problem does this really solve? One reason Bitcoin gains value is because it becomes a more and more scarce over time. Opening up new "shards" to mine might *seem* like it gives a new wave of people a chance to get rich in the future, but it's no different then an alt-chain really. If you can send "shard" coins to the main blockchain, it's just another chain hence, coin. One of the fundamental basics of Bitcoin is that the inflation is predetermined and limited. "Shards" just opens the chain to hyperinflation. The idea is contrary to the whole point, IMHO.

 

[1714869779]

1714869779

[1714869779]

1714869779

[1714869779]

1714869779

[BoardGameCoin]

The problem that it solves would be ONLY transaction volume handling. If bitcoin grows much more, miners will have a lot of churn updating blocks to include the new transactions from the last few seconds. We're not too far off from the max size of a block. The way I envision this happening does not include any new coins for the miners of the shard, and so financing it is one of the problems to solve.

-bgc

[ripper234]

I think the question is what problem does this really solve? One reason Bitcoin gains value is because it becomes a more and more scarce over time. Opening up new "shards" to mine might *seem* like it gives a new wave of people a chance to get rich in the future, but it's no different then an alt-chain really. If you can send "shard" coins to the main blockchain, it's just another chain hence, coin. One of the fundamental basics of Bitcoin is that the inflation is predetermined and limited. "Shards" just opens the chain to hyperinflation. The idea is contrary to the whole point, IMHO.

The problem being attacked is how to scale the blockchain to world scale.

If it could be implemented like a stock split somehow, that would be ideal. Stocks split don't devalue the stocks, they just play with the numbers a bit - owner of $10,000 worth of Apple stocks will remain in possession of $10,000 worth of the stocks after a split.

[edmundedgar]

When I saw this question about sharding, my initial reaction was "No, the blockchain can't be split into shards".

But, on second and third thought - the major problem that I see is that you have to be able to send funds between the different shards. What if you could just trade, via an easy API, coins from one shards into coins of another shard, and then send those to the recipient?

Let's call this hypothetical concept Shardcoin. We would launch 10,000 new blockchains, and miners could choose randomly which chain they want to work on at any given time, reducing their bandwidth/memory footprint by a factor of 10,000.

Now, each of these miners, and other players in the market, would create exchanges between the different chains. I'm suggesting miners may double as exchanges because they're always-on servers ... no reason not to bundle an exchange there too (it won't be obligatory of course).

In order to send money:
 - Suppose I have 100 coins on Shard 17, and I want to send them to some address on Shard 9971.
 - I generate a new address for myself on Shard 9971.
 - Suppose the current exchange rate between these shards is 1 Shard17Coin = 0.8 Shard9971Coin.
 - I find someone willing to trade, and in one atomic tx, send him my 100 Shard17Coins, in exchange for 80 Shard9971Coins, minus his commision. Again, this is done atomically, so I don't really need to trust him to "hold my money" or anything like that.
 - I now am the proud owner of 79 Shard9971Coins, which I can send to my original target.

I'm not following the other scalability suggestions, so this all might be redundant if a better solution is proposed & implemented. But at least as a thought experiment, I rather like it. I see two major issues:

 - Fluctuation in the relative values of the different ShardCoins.
 - Adoption/network effect. Since there is effectively zero change Bitcoin will be dropped in favor of ShardCoin, this will never pick up enough steam to be successful. Bitcoin is already Too Big to Fail IMO.

A major point that's important to get across is that this is 100% compatible with the Bitcoin protocol - no changes whatsoever are needed. In fact, this proposal can work across crypto-currencies - so we could have p2p exchanges of Bitcoin, Litecoin & ShardCoins all working seamlessly together.

If I've got this right, since addresses are basically just key pairs, you wouldn't need to send your coins to an _address_ on Shard 9971. All addresses would work on all the shards. That reduces the risk that different shards will have different values, because the vendor asks you to pay X coins to address xyz, they wouldn't know which shard the money would be coming in on. If all the coins on all the shards buy the same amount of stuff, they all have the same value.

So if you had 100 coins on Shard 17, you could just send them to a vendor's address on Shard 17. When the vendor wanted to spend them, they would also send those coins on Shard 17. Most of the time you wouldn't need to make atomic transactions across chains or anything difficult like that. Obviously everybody's client would need access to enough data to do SPV on all the shards it had coins on.

The fact that the money was split into different Shards could mostly be hidden from the end-user, in the same way that it currently hides the fact that your coins are made up of different amounts in different outputs. The only time you'd have a problem would be when you wanted to send 100 coins at once, but you had 40 coins on Shard 17 and 60 coins on Shard 9971. In that case you'd have two options:
1) Send two transactions, one on Shard 17 and the other on Shard 9971. The vendor will give you your stuff when they get both. (Again the client could take care of this without bothering you about it.)
2) If you need the whole payment in one transaction for some reason (maybe it's a fancy escrow contract or something), _then_ you have to swap with somebody on one of the other shards.

(2) may not turn out to be too important if (1) works well, but trading between shards wouldn't _necessarily_ have to be a clever atomic p2p thing. It could just be the equivalent of the current mixing operations - you send someone with a good reputation some coins on Shard 9971, and they send you some back on Shard 17. You might also have the client set to do these operations in the background to defragment itself and consolidate your coins among a smaller number of shards. Obviously having lots of people routinely taking part in mixing operations for routine, non-illegal purposes has some anonymity benefits, too...

Clearly there's a bit of inconvenience there compared to the current arrangement, but the advantage is that it would allow Bitcoin (or ShardCoin, if Bitcoin didn't want to do this) to scale unto infinity. Whereas right now everyone seems to think there's a point _somewhere_  where you can't scale because blocks get too big to transmit fast enough, or you run into some other limitation and fees go up to choke off demand. (People disagree about where this point is, and whether the community should decide by fiat or just let the miners figure it out.)

PS Scuse the thread necromancy.

[ripper234]

If I've got this right, since addresses are basically just key pairs, you wouldn't need to send your coins to an _address_ on Shard 9971. All addresses would work on all the shards. That reduces the risk that different shards will have different values, because the vendor asks you to pay X coins to address xyz, they wouldn't know which shard the money would be coming in on. If all the coins on all the shards buy the same amount of stuff, they all have the same value.

So if you had 100 coins on Shard 17, you could just send them to a vendor's address on Shard 17. When the vendor wanted to spend them, they would also send those coins on Shard 17. Most of the time you wouldn't need to make atomic transactions across chains or anything difficult like that. Obviously everybody's client would need access to enough data to do SPV on all the shards it had coins on.

It's a good question how the coins will behave economics wise. I mean it's possible some shards will have different kinds of activity - perhaps SatoshiDice like services would only work on a few shards, while other will be reserved for different activities. Or perhaps the shards will mostly just behave the same. Perhaps more coins will be lost on some shards than in others, thus increasing the value of the remaining cords from those shards.

There is no way to guarantee the same value for all shards, I think it's an interesting experiment to perform. If I were into launching altcoins I would perhaps do that myself - it's a simple matter to launch 1000 different shards, all equivalent to bitcoin except the starting nonce.

[edmundedgar]

If I've got this right, since addresses are basically just key pairs, you wouldn't need to send your coins to an _address_ on Shard 9971. All addresses would work on all the shards. That reduces the risk that different shards will have different values, because the vendor asks you to pay X coins to address xyz, they wouldn't know which shard the money would be coming in on. If all the coins on all the shards buy the same amount of stuff, they all have the same value.

So if you had 100 coins on Shard 17, you could just send them to a vendor's address on Shard 17. When the vendor wanted to spend them, they would also send those coins on Shard 17. Most of the time you wouldn't need to make atomic transactions across chains or anything difficult like that. Obviously everybody's client would need access to enough data to do SPV on all the shards it had coins on.

It's a good question how the coins will behave economics wise. I mean it's possible some shards will have different kinds of activity - perhaps SatoshiDice like services would only work on a few shards, while other will be reserved for different activities. Or perhaps the shards will mostly just behave the same. Perhaps more coins will be lost on some shards than in others, thus increasing the value of the remaining cords from those shards.

There is no way to guarantee the same value for all shards, I think it's an interesting experiment to perform. If I were into launching altcoins I would perhaps do that myself - it's a simple matter to launch 1000 different shards, all equivalent to bitcoin except the starting nonce.

I suppose it would be possible that some services would actually ask people to use particular shards, but it's not really clear they'd have much advantage from making their users jump through the extra hoop. I suppose it's possible that people would somehow decide that some shards were worth less than others, and that would become a self-fulfilling prophecy; I remember in Central Asia in the mid-90s people had somehow decided that older US dollars were worth less than new ones, so they were.

But to fend that kind of thing off I think you'd have to design it with the goal of making distribution of coins among the shards as arbitrary as possible. If you were starting with Bitcoin, you'd split the chain when it got too big and assign outputs to one or the other at random, rather than doing what people on this thread suggested and having different shards for different purposes.

[TierNolan]

- I find someone willing to trade, and in one atomic tx, send him my 100 Shard17Coins, in exchange for 80 Shard9971Coins, minus his commision. Again, this is done atomically, so I don't really need to trust him to "hold my money" or anything like that.

How do you do it atomically, if miners aren't monitoring all chains?

[ripper234]

- I find someone willing to trade, and in one atomic tx, send him my 100 Shard17Coins, in exchange for 80 Shard9971Coins, minus his commision. Again, this is done atomically, so I don't really need to trust him to "hold my money" or anything like that.

How do you do it atomically, if miners aren't monitoring all chains?

Atomic cross-chain trading is solvable for entirely different alt chains, so cross-shard trading is just a private case.

I must admit I do not fully understand Mike Hearns' explanation as presented, I suggest we use the wiki page to develop and clarify the solution as needed.