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.
Consider two groups of miners (A, B) who are mining the crypto currencies on the Overline multichain 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 Overline.
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 Overline 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 Overline 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 Overline blockchain.
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 Overline. Unless there is technical customizations required, Overline 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 Overline 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 Overline 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 Overline.
Another solution we are exploring for managing multichain 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 months ago