3 ms·

I am (perhaps naively) wondering whether a blockchain can be sharded hierarchically instead. Each shard works like a channel like in the Lightning Network and

I am (perhaps naively) wondering whether a blockchain can be sharded hierarchically instead. Each shard works like a channel like in the Lightning Network and the channel can have sub-channels, this means the channels all have their own blockchain, i. e. they are blockchain shards. To verify a transaction from A to B it's like a tree walk from a tree node A to the other tree node B. First verify the channel A is in, then go to the parent channel till the common parent channel is reached then descend again to the partner B's channel, verifying on each step ascending and descending.

SkidanovAlex 8y ago
That is somewhat similar to what Vlad Zamfir's sharding is doing (https://medium.com/nearprotocol/so-what-exactly-is-vlads-sharding-poc-doing-37e538177ed9 https://medium.com/nearprotocol/so-what-exactly-is-vlads-sha...) For a given transaction you'd only need to verify log(n) chains, but the problems from the top level post remain. The question is how you verify the transaction in a given chain. If you verify the entire chain, than you are expected to end up verifying all the chains (since ultimately cross shard transactions will be coming from all shards), removing any benefit from sharding. If you somehow trust that the shards were doing their job properly, then you need to somehow deal with shards being corrupted.
- _nalply 8y ago
  I am probably naive again, but it seems for me that you don't need to verify other transactions, only the one between A and B. You could ignore the shards/channels not affected by the transaction. Another optimisation would be that for example an exchange tries to pull all its local transactions into the same channel. Or people join the retail's channel before paying. The idea is to avoid ascending as much as possible. In other words, a variant of Lightning Network!

SkidanovAlex 8y ago

That is somewhat similar to what Vlad Zamfir's sharding is doing (https://medium.com/nearprotocol/so-what-exactly-is-vlads-sharding-poc-doing-37e538177ed9 https://medium.com/nearprotocol/so-what-exactly-is-vlads-sha...) For a given transaction you'd only need to verify log(n) chains, but the problems from the top level post remain. The question is how you verify the transaction in a given chain. If you verify the entire chain, than you are expected to end up verifying all the chains (since ultimately cross shard transactions will be coming from all shards), removing any benefit from sharding. If you somehow trust that the shards were doing their job properly, then you need to somehow deal with shards being corrupted.

_nalply 8y ago
I am probably naive again, but it seems for me that you don't need to verify other transactions, only the one between A and B. You could ignore the shards/channels not affected by the transaction. Another optimisation would be that for example an exchange tries to pull all its local transactions into the same channel. Or people join the retail's channel before paying. The idea is to avoid ascending as much as possible. In other words, a variant of Lightning Network!