Unsolved Problems in Blockchain Sharding
medium.com
medium.com
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.
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.
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!
Both have on disk data well over a TB. And it's early days. This stuff is getting progressively less feasible to run for normal users as more users start using this and start adding their own transactions. Long term, sharding is not going to be optional.
Once we have infinite power from practical fusion we can mine coins for cheap.
And when quantum computers are common you can update the chain or do sharding in no time at all.
Lol this misunderstands both current problems with blockchains and the potential total of quantum computers...
It's basically impossible to do a full Ethereum validation now, all the nodes are just assuming recent blocks are valid.
Does the Fisherman approach involve validators randomly checking other validators for phony transactions?
Will validators be incentivized to do this?
Is that why they are called fisherman? Because honest validators are "fishing" around for opportunities to catch invalid transactions and increase their stakes?
How long is the challenge period currently being discussed?
The other attack vector that the fisherman opens, "grieving" attacks, whereby malicious nodes launch a series of false reports, knowingly sacrificing their stakes presumably to overwhelm the system and push through a double-spend or phony token mint or something.
Am I interpreting how this attack works correctly?
Has any thought been given to making the challenge period as long as it needs to be to process all challenges, and incentivizing goodwill from those affected by the slowdowns with a fractional return of the slashed stakes... Maybe like a reverse gas cost? Is that insane?
Are we now free-floating, hoping to find a new solution to the double-spend problem on a fragmented system?
Cryptocurrencies are just simple accounting systems and they run on general purpose computers, so no and no.
I don't think this whole direction works unless you can find an approach that doesn't add much complexity or even simplifies things in some way. I feel the same way about byzantine proof of stake schemes.
This is definitely an engineering intuition that I have, but I think I can ground it to some extent in thermodynamics and learning theory. If the universe isn't mandating complexity, it's superfluous.