Miners: Miners take blocks as inputs and search for a hash below the edit distance threshold for each block. To learn more about this process you can review Proof of Edit Distance.
Rovers: Attached to every miner a rover gathers blocks from member blockchains. Unlike a traditional blockchain client which connects to 25 peers a rover connects to 60-150 peers.
A blockchain reorganizes generally after two or more miners submit valid work. A block is orphaned if weighted by difficulty it is not the longest chain.
Consider two groups of miners (A, B) who are mining the crypto currencies on the Block Collider which are to keep it small only Bitcoin, Ethereum, and NEO. Both groups of miners A and B receive different Bitcoin blocks, group A receives a block that will end up an orphan (b0) and group B receives a block (b1) that will remain. In the future group B and group A receive (b2) which confirms (b0) is an orphan. At this point neither group knows if they possess an orphan and both begin mining.
What can happen?
- Option 1: Miner group A could find a valid block on top of b0 which becomes an orphan block.
- Option 2: Miner group B could find a valid block on top of b1.
Like Bitcoin and regardless of either option both groups cannot prove an orphan until--weighted by difficulty--a longer of the two is established. The chain length assertion function can be unique to each blockchains and is a part of the genesis file. Also keep in mind while this is happening there are blocks from blockchains with faster block times still entering the block Collider.
If Option 1 occurs miner group A submits the blocks of NEO, Ethereum, and the soon to be orphaned Bitcoin block with the discovered hash as proof of work to be confirmed by other Block Collider peers for the next block. All miners in group B accept the proof as it is correct at that time however since they also have a valid block they can update their headers to the height provided by the miner group A for NEO and Ethereum but instead of swapping out the other block submit proof of work using b1. Until b2 proves orphan status b1 or b0 can be accepted into the Block Collider as valid sequences of the chain.
If Option 2 occurs the resulting actions are the same. When the next block in Bitcoin (or anything chain for that matter) orphans the block held by miners in group A they adopt the previous hash of group B. Both potential orphan blocks remain and are stored within the Block Collider blockchain.
A fork permanently starts a new chain from a hex code, event, block number, flag etc.
There are two kinds of forks, a soft fork and a hard fork. A soft fork often called a “miner activated soft fork” is in almost all cases automatically consumed by the Block Collider. Unless there is technical customizations required, the Block Collider will select the chain by the consensus made by the peers from which it seeds blocks.
Hard forks require an additional layer of governance. Since hard fork changes may break core features of the member blockchain protocol, rovers seeding the blockchain may need an upgrade. To ensure stability in the early days the Block Collider team will manage which chain is the rightful next chain by signing the hash or target block of the correct next chain. After the managed period the community will cast weighted votes using a combination of hash power, Emblem balance, and length transaction outputs to add or remove blockchains.
In the event a member blockchain fails during the fork, the failure does not interrupt the mining process or other cross-chain operations. The failed blockchain’s last valid block remains the “head” of the failed blockchain until new data can be added.
During the first two years before the governance period the Block Collider team will maintain a “kill” switch hash which when signed with a block number causes miners to ignore a specific blockchain until the block number has passed. This is to protect against catastrophic events that crippled a blockchain and in effect could negatively harm the operation of the Block Collider.
Another solution we are exploring for managing multi-chain forks types is to rotate to a model similar to the "compact chain" purposed in Mimblewimble which would store the header states of all possible fork without retaining the data in a space efficient schema with OWAS or Schnorr signatures.
Updated 2 years ago