Topic: Shardcoin - A Blockchain Partitioning / Sharding proposal - page 2. (Read 3900 times)

If the shards are designed in advance to recognize each other, you don't need to mess with exchange rates and finding someone to trade with you.

All you need is a modification that new coins can be created in a shard, if there is a transaction that destroys coins in another shard and encodes information about the receiving shard and address. So to send coins from shard 1 to shard 2 you destroy them on shard 1, and broadcast a transaction on shard 2 where the input is a reference to the transaction from shard 1, together with its entire Merkle branch.

Nodes will need the entire blockchain of their shard, as well as block headers of all shards, and Merkle branches of every transaction from another shard to theirs. So instead of all transactions, they need (1/N) of transactions plus branches of (1/N) of the transactions. If a transaction is 500B and a Merkle branch is 1.5KB this can be an improvement even without N too large. But they also need N times the block headers.

All shards will be merge-mined with each other.

As a further optimization, instead of all block headers you could have headers of only X% of the shards. Then to send a transaction you need to find someone in the target shard which has the headers for the source shard.

I think I like this idea. And I wonder if the above ideas can be integrated into a more seamless way to shard the blockchain.

Another idea: Maybe it will be good to recommend to people to choose a shard based on geographical location. So local transactions can be done with the least latency and without crossing shards.

This requires a more precise stating.
What I suggest is different - a complete, symmetrical sharding without hierarchies.

You would probably get some value-drift between shards in the same way that 1EUR doesn't buy the same amount in different countries, so there would probably be a secondary exchange market. Also, it would take ~log(n) extra confirms so moving money between shards would take sometime without a secondary exchange.

-bgc

I should clarify: The way I view this is a hierarchical sharding where exchanges between shards occur at the next level in the hierarchy. Only the top level shard generates coins, but it also hashes in its view of the next lower shards' blockchains so a doublespend is just as hard as the highest level's hash rate. I'll write/code this up at some point...

-bgc

I don't see how this works. You create an address for yourself on each shard. Now, you get your first coins from somewhere. These coins are on one specific shards, because you don't want to broadcast each action on each shard - that would be pointless.

So now, you only have Shard17Coins, but have zero Shard9971Coins. How do you get Shard9971Coins without exchanging them? Remember, the chains are completely separate.

No exchange rate necessary: Simply make an address on each shard and send to yourself.

For me, this is on the critical path for wide bitcoin adoption. There are many different possible approaches, but it will become necessary in order to support even modest transaction volume.

-bgc

I think the design needs to be able to transfer coins between the shards to work. 10000 exchange rates is a bit too much. Even a very slow transfer between different chains would work.

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.