Boson Consensus - A Scalable Blockchain Consensus Algorithm

[qizhou]

Let me clarify the question a bit more: “cross-shard transaction lost” means that the destination shard cannot find the output of the cross-shard transaction from the source shard, where the output may be called “receipt” or “deposit” (or more general, cross-shard transaction message) in different languages.

If cross-shard transaction is lost, it means the nodes of the destination shard cannot access the block data of the source shard. In our current design, we suggest

• All nodes running a full node (as defined in Secion III-D of the Boson paper) and thus unless all nodes are down, any node can access source shard data. The network will probably start like this when the shard numbers are small. Note that such node can be implemented as a cluster so that the node itself can scale horizontally;
• A node may just run a partial node that only runs part of shards, which do not include the source shard. To access the cross-shard tx, this node will be a light-client of the source shard.

Furthermore, I would project the network in the long term may look like from https://ethresear.ch/t/some-observations-on-eth2-0-validators-and-super-full-node/6241?u=qizhou:

@qizhou

Taking M=1024M = 1024 , and V=100V = 100 as an example, a network offering the middle ground may like

• 30~30 super-full node clusters are run by pools, banks, large organizations, groups of trusted blockchain fans, etc, and maintain the full ledgers of all shards.
• 500~500 partial-full node clusters are run by smaller pools, organizations. A partial-full node cluster will process the ledgers of several shards of interest, and run as light clients of other shards (using SPV and/or data fraud and availability detection to process cross-shard message and increase security)
• 10000~10000 single-shard node in the network for solo miners or a developer that is interested in dapp in a shard). The cost of such node is expected to be 1.2x-1.5x cost as current Ethereum (with 0.2x~0.5x for processing cross-shard messages)

Note that the network is completely permissionless, and a node operator is free to run in any type of nodes/clusters.

And some details of guarantee of some important properties cross-shard transaction can be found here https://ethresear.ch/t/moving-eth-between-shards-the-problem-statement/6597/8?u=qizhou:

@qizhou

I would like to share our thoughts on moving native token between shards, which are close to the solutions (2) and (5) with the following features:

• Guaranteed and ordered delivery via incentives : A cross-shard receipt will be incentivized to be eventually processed at destination shard.
• DoS attack prevention : Even the attacks may send lots of transactions to one shard from other shards, the system would continue to work.
• Happen-before guarantee : A cross-shard receipt will be always processed at the destination shard after the original token was spent from the source shard.

Please let me know if this answers your question. Thanks!