AV
Принцип длинной цепочки не отменяется при вступлении в силу dip8,а остается запасным вариантом,в случае если чейнлокс не придут к консенсусу.Далее много текста.
Самое важное в конце.Если вдруг кворумы мастернод не придут к общему консенсусу для подписания одного и того же блока в течение нескольких попыток,будет задействован старый принцип длиной цепи.
Signing attempts
When a new valid block is received by a masternode, it must invoke the DIP007 SignIfMember operation.
The request id for the operation is hash(prevBlockHash, attemptNum) and the message hash is the hash of the new block (newBlockHash). The first time this is attempted, attemptNum must be set to 0.
In most cases, the majority of the LLMQ will sign the same message hash in the first attempt and thus find consensus. This can be checked with the DIP007 HasRecoveredSig operation. This will even hold true in most cases where 2 competing blocks are being propagated inside the network, as only one is able to reach more LLMQ members faster than the other and thus gain a majority in the signing request.
In some cases however, it is possible that no majority can be reached in the first attempt. This could happen if too many members of the LLMQ are malfunctioning or if more than two blocks are competing. If this happens, a second signing request with an incremented attemptNum value must be initiated. To check for a failed attempt, the DIP007 IsMajorityPossible operation must be used. An attempt is also considered as failed when it did not succeed after some timeout.
On failure, another signing request with an incremented attemptNum value should be initiated. The new request should use the message hash returned by the DIP007 GetMostSignedSessionoperation, which is the hash of the block which had the most signatures in the last attempt. After a few attempts, a request should result in a recovered threshold signature which indicates consensus has been reached.
Finalization of signed blocks
After a signing attempt has succeeded, another LLMQ must sign the successful attempt. This is only performed once for each prevBlockHash and thus either succeeds or fails without performing additional attempts.
The request id is prevBlockHash and the message hash is the block hash of the previously successful attempt.
After a LLMQ member has successfully recovered the final ChainLocks signature, it must create a P2P message and propagate it to all nodes. When a new block has been successfully signed by a LLMQ and the CLSIG message is received by a node, it should ensure that only this block is locally accepted as the next block.
If an alternative block for the same height is received, it must be invalidated and removed from the currently active chain since a signed block has already been received. If the correct block is already present locally, its chain should be activated as the new active chain. If the correct block is not known locally, it must wait for this block to arrive and request it from other nodes if necessary.
If a block has been received locally and no CLSIGmessage has been received yet, it should be handled the same way it was handled before the introduction of ChainLocks. This means the longest-chain and first-seen rules must be applied. When the CLSIG message for this (or another) block is later received, the above logic must be applied.
Самое важное в конце.Если вдруг кворумы мастернод не придут к общему консенсусу для подписания одного и того же блока в течение нескольких попыток,будет задействован старый принцип длиной цепи.
Signing attempts
When a new valid block is received by a masternode, it must invoke the DIP007 SignIfMember operation.
The request id for the operation is hash(prevBlockHash, attemptNum) and the message hash is the hash of the new block (newBlockHash). The first time this is attempted, attemptNum must be set to 0.
In most cases, the majority of the LLMQ will sign the same message hash in the first attempt and thus find consensus. This can be checked with the DIP007 HasRecoveredSig operation. This will even hold true in most cases where 2 competing blocks are being propagated inside the network, as only one is able to reach more LLMQ members faster than the other and thus gain a majority in the signing request.
In some cases however, it is possible that no majority can be reached in the first attempt. This could happen if too many members of the LLMQ are malfunctioning or if more than two blocks are competing. If this happens, a second signing request with an incremented attemptNum value must be initiated. To check for a failed attempt, the DIP007 IsMajorityPossible operation must be used. An attempt is also considered as failed when it did not succeed after some timeout.
On failure, another signing request with an incremented attemptNum value should be initiated. The new request should use the message hash returned by the DIP007 GetMostSignedSessionoperation, which is the hash of the block which had the most signatures in the last attempt. After a few attempts, a request should result in a recovered threshold signature which indicates consensus has been reached.
Finalization of signed blocks
After a signing attempt has succeeded, another LLMQ must sign the successful attempt. This is only performed once for each prevBlockHash and thus either succeeds or fails without performing additional attempts.
The request id is prevBlockHash and the message hash is the block hash of the previously successful attempt.
After a LLMQ member has successfully recovered the final ChainLocks signature, it must create a P2P message and propagate it to all nodes. When a new block has been successfully signed by a LLMQ and the CLSIG message is received by a node, it should ensure that only this block is locally accepted as the next block.
If an alternative block for the same height is received, it must be invalidated and removed from the currently active chain since a signed block has already been received. If the correct block is already present locally, its chain should be activated as the new active chain. If the correct block is not known locally, it must wait for this block to arrive and request it from other nodes if necessary.
If a block has been received locally and no CLSIGmessage has been received yet, it should be handled the same way it was handled before the introduction of ChainLocks. This means the longest-chain and first-seen rules must be applied. When the CLSIG message for this (or another) block is later received, the above logic must be applied.
Все супер, но если есть два блока и один MN валидировали, а второй получил блок выше?
