Main > Stakeholder Proposals
Backup strategie for delegates - idea
xeroc:
I see .. thanks for the explanation .. makes sense
Was worth a try ..
emski:
Blockchain does not have consistent state. There could be many versions of last X blocks (called forks).
Even if your backup delegate submits a transaction changing the delegate's active key this could be on a different fork than the main delegate. It could work only if you submit the active key change sufficient number of blocks in advance.
For example the following situation:
Whole network is divided in two groups without network connection between them. We have the primary delegate signing blocks in Group 1 and the Backup Delegate signing block in Group 2 (with different active key). This is undesired behavior due to many reasons. And such situation could occur not only by completely isolating 2 groups of nodes.
xeroc:
--- Quote from: emski on October 12, 2014, 11:08:51 am ---
--- Quote from: xeroc on October 12, 2014, 09:37:21 am ---How so?
both nodes ise different keys to sign blocks and only one key is valid in the network
--- End quote ---
One chain is the normal signed by the original delegate.
The other chain contains the updated key with the backup delegate's sigunature.
The next delegate in the round should pick one of the chains. This is still a fork.
--- End quote ---
From my understanding, changing the active key of a delegate involves sending a transaction to the network .. as the transaction is picked up by another delegate and added to the blockchain it is made valid .. now only the delegate with the updated key can sign transactions.
what happens at the original node:
- either it is still connected to the network, receives the "change active key" transaction and thus decides to stop signing blocks
- or it does not see the transaction and continues signing blocks with the obsolete key .. in that case it will be disconnected from the network automatically as the signatures are invalid from the other user's point of view
What am I missing here? The blockchain has a consistent state regarding the 'valid' key .. and only one delegate has the valid key
emski:
--- Quote from: xeroc on October 12, 2014, 09:37:21 am ---
--- Quote from: emski on October 11, 2014, 11:29:09 pm ---It will still produce fork if there is no network connectivity between backup and original delegate.
--- End quote ---
How so?
both nodes ise different keys to sign blocks and only one key is valid in the network
--- End quote ---
One chain is the normal signed by the original delegate.
The other chain contains the updated key with the backup delegate's sigunature.
The next delegate in the round should pick one of the chains. This is still a fork.
xeroc:
--- Quote from: emski on October 11, 2014, 11:29:09 pm ---It will still produce fork if there is no network connectivity between backup and original delegate.
--- End quote ---
How so?
both nodes ise different keys to sign blocks and only one key is valid in the network
Navigation
[0] Message Index
[#] Next page
Go to full version