SNT disaster recovery questions

Looking ahead to network launch and SNT rolling out, I have a couple of questions about how disaster recovery would work for SNT balances, and other Safe Network based tokens.

There are 2 scenarios I have in mind that I’d like to know how they might play out;

  1. Network failure. If the network disintegrated due to some kind of buggy node software, and a network restart with fixed node software were required, how would balances from the pre-crash network be valid on the restarted network? Could it get tricky with transactions made during any network disintegration?

  2. If some bug meant illegitimate tokens were somehow accepted by the network / the network was tricked to mint additional SNT, would there be any way to ‘roll back’ once any exploit were discovered?

In both cases, with a blockchain, many people hold a record of balances at any given time, which makes it easy for a community to decide on a block height to roll back to.

Is there some kind of mechanism that is analogous to this to enable recover of balances etc in the event of disaster scenarios like those vaguely outlined here?

Just trying to start getting an understanding of how this might work in a blockchain-less distributed network!

6 Likes

I want to know about upgrades. How will it happen?

2 Likes

Does anyone know whether the scenarios I mentioned above could be potential killers for an agreed upon record of everyone’s holdings of SNT / other tokens on the Safe Network?

As these things have happened with blockchains, with the solution often being rollbacks, it’d be nice to know whether similar problems will not be possible with the Safe Network, or that a solution is possible without the option of rollbacks.

That is an excellent question and although we have not yet implemented such a rollback mechanism, I see an easy way to do so with our current transactions system.

As you said, on blockchains, the solution is a rollback to a previous block thus canceling everything that happened after it, including valid transactions!

We do not have a blockchain but the network as a whole holds a sharded DAG of Spends that starts from Genesis and goes recursively to all its descendants.

In the case of an attack, rolling back could simply mean cutting off the poisoned branches of the Spend DAG, and starting off from their valid ancestors (similar to the last valid block).

The difference with blockchains would be that only transactions related (descendants) to the poisonned Spends would be cancelled and not the valid ones that happened in the network as unlike blockchains our DAG has no notion of time.

In blockchain:

block1 -> block2 -> block3 ->block4

block3 is poisoned so we roll back

block1 -> block2 -> …

On SAFE: (Each CashNote has a corresponding Spend on the network)

                                        -> CashNote7
                                      /
Genesis -> CashNote1 -----> CashNote2 ---> CashNote5
                     \
                       ---> CashNote3 ---> CashNote6
                       \
                         -> CashNote4
                         
if Cashnote3 is poisoned, just cut the branch starting off cashnote3 
                                    

                                        -> CashNote7
                                      /
Genesis -> CashNote1 -----> CashNote2 ---> CashNote5
                     \
                       ---> ...
                       \
                         -> CashNote4
11 Likes

Thanks for this reply - great explanation, and reassuring to know there’s a way of recovering from that situation, and one that’s better than the blockchain alternative.

Is it also possible to download a full DAG that’s relevant to a particular balance & store it offline, so that in case of a network failure it could be proved that a valid balance were held?

Also, with the DAG is it possible to audit total supply?

9 Likes

Yes and yes. (Not implemented yet though, but the data is held by nodes and can be queried/uploaded using the API).

6 Likes