Author Topic: Backup strategie for delegates - idea  (Read 2310 times)

0 Members and 1 Guest are viewing this topic.

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12922
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BitShares: xeroc
  • GitHub: xeroc
I see .. thanks for the explanation .. makes sense

Was worth a try ..

Offline emski

  • Hero Member
  • *****
  • Posts: 1282
    • View Profile
    • http://lnkd.in/nPbhxG
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.

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12922
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BitShares: xeroc
  • GitHub: xeroc
How so?
both nodes ise different keys to sign blocks and only one key is valid in the network

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.

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

Offline emski

  • Hero Member
  • *****
  • Posts: 1282
    • View Profile
    • http://lnkd.in/nPbhxG


It will still produce fork if there is no network connectivity between backup and original delegate.

How so?
both nodes ise different keys to sign blocks and only one key is valid in the network

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.

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12922
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BitShares: xeroc
  • GitHub: xeroc


It will still produce fork if there is no network connectivity between backup and original delegate.

How so?
both nodes ise different keys to sign blocks and only one key is valid in the network

Offline emski

  • Hero Member
  • *****
  • Posts: 1282
    • View Profile
    • http://lnkd.in/nPbhxG
It will still produce fork if there is no network connectivity between backup and original delegate.
I saw a solution to this using 3 nodes and requiring 2 out of 3 nodes to sign a block. However it is still impractical and missing a block is not that much of a deal. Instant notification is sufficient in that case.

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12922
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BitShares: xeroc
  • GitHub: xeroc
Hey friends,

Lying in bed I came up with an idea that might "solve" the issue with backup
delegates producing forks accidentally.

TL;DR; use the update_active_key feature on failure of the master node

so basically, the delegate signs blocks with its active key and not the owner
key (TODO: check with BM about this).
I assume you have two machines with the delegates owner key imported. both are
in sync regarding the "list of active keys" and the corresponding private keys.

Now, when the master note is not reachable by the backup node anymore (due to
unkown reasons) but you cannot be sure that the master node is maybe still
active and connected to the network, you could end up with two delegates
signing a block which forks the network. This is status quo and the biggest
problems for the backup strategy.

Now I think we can solve this by the following:
1) the backup node thinks the master node is offline
2) the backup node creates a new key active key for the delegate and enables block production
   this key can be produced in a way that the master node has no chance of figuring it out.
3) thus, the master node is UNABLE to continue producing blocks. Its simply not
   allowed to produce blocks with an obsolete key (don't ask me what the master
   node does in this situation, maybe crash)
4) the end result however is a backup machine that solely is allowed to produce
   blocks.

This can be extended to a set of backup machines by scanning all transactions
which change the active key of a particular delegate. Different backup
delegates can jump in on different delays if any node before it "fails to
deliver" a valid block. (reminds me of RAFT)

Thoughts?