We are running our own BNS node to build our application using block-stack. We are creating subdomains for our users by running our own registrar. I am going through BNS Forks (https://docs.blockstack.org/core/naming/forks.html) documentation and there are use-cases I would like to understand:
What all possible cases might result in BNS node fork? Is it always the code upgrade or Can an honest node result into fork due to any factor like network split or any ambiguous transaction on bitcoin blockchain?
How to identify and resolve such cases? What would be corrective action once the fork is identified?
Additionally, subdomain states are not stored on-chain, having said that as per documentation atlas network ensures user’s strong ownership once subdomain is created.
From ownership and data integrity standpoint, is there any difference b/w names data and subdomain data (stored in Atlas or Gaia)?
You alter the consensus rules in your BNS node, causing it to diverge from the others
Blockstack’s transaction-processing is entirely deterministic – if two BNS nodes see the same sequence of Bitcoin transactions and follow the same rules, they’ll each arrive at the same name state.
The consensus hash – a rolling digest over all transactions accepted by the node – is used to identify which fork a node belongs to. You can get your consensus hash via the /v1/info or /v1/blockchains/bitcoin/consensus endpoints, and you can see the PBC node’s consensus hash on core.blockstack.org. Nodes that have different consensus hashes for the same block height are on different forks, and will not talk to each other.
Each batch of subdomain operations (registration, update, transfer) are anchored to an on-chain name’s NAME_UPDATE transaction. If two BNS nodes process the same sequence of Bitcoin transactions AND receive the same set of name zone files, they will derive the same subdomain name state (I distinguish between sequence and set because unlike transactions, it doesn’t matter what order a node gets its zone files in – it only matters that it receives them at all).
There are a few subtle differences between on-chain and off-chain name management, as listed in the documentation.
If the on-chain NAME_UPDATE happens in a different fork than your node, your node won’t see any off-chain names that it creates or updates.
If Bitcoin undergoes an unexpected deep chainsplit, we will configure our nodes to follow the fork with the most PoW (i.e. the fork that becomes the canonical fork). This was the stance we took back when Bitcoin was facing a contentious fork over Segwit, and we continue to hold this stance.
If you modify your node to follow different consensus rules, then you’re on your own – you’ll have your own fork to maintain.