Does asynchronous processing of "change" blocks mean that block confirmation is non-deterministic?

I'm just trying to think through a possible scenario. Suppose I am bootstrapping a node and receiving a large torrent of incoming transaction data from the network. It seems to me that I cannot know what is the current voting weight assigned to all reps until I have processed every block in the lattice. Once I know the frontier state of every chain in the lattice, then I know how much weight is assigned to every representative.

But... what if there are forked versions of some important change blocks (delegating relatively large amounts of vote weight)? It seems like a circular problem. I could not resolve the fork until I knew how much weight had voted for each side of the fork. But I could not know precisely how much weight had voted for each side until I had processed the full lattice up to that point in time. That raises another issue, in that Nano does not really have any concept analogous to "time" the way that single-chain ledgers do. If the ledger is asynchronous, doesn't that mean that I can process the blocks in any order? What if I cement blocks from account A, B and C first, which gives 60% vote-weight to forked-block X, while if I had cemented blocks from accounts D, E and F first, 60% vote-weight might have gone to forked-block Y? If I had been there to witness it in real time, I might have seen that the voting weight only shifted to reps favouring forked-block X after forked-block Y had already been cemented. But since I could not observe it in real time, I had no way to know which change blocks were already in effect at the time of the fork. Even if I have access to every block and every vote since the start of the lattice, I can't absolutely guarantee that I will end up with the same ledger state as someone else if we don't process the blocks in the same order.

My understanding (based on reading here: unofficial · georgehara/nano Wiki · GitHub) is that this difficulty is currently being resolved by providing a hard-coded set of initial voting weights within the node software. Those voting weights are then used to bootstrap the process. This strikes me as a serious point of centralisation in the protocol. It means that to bootstrap on to the network, you simply have to pick a trusted entity to tell you which reps have the most vote weight. If the weights they give you exclude weight that was legitimately assigned to other reps, and then the reps that DO have weight vote against blocks that delegate weight away from them, how would you know that something was amiss? It seems like the only way would be for people to cry foul on social media and start organising a fork. But that would obviously be a contentious mess.

If I am understanding all of that correctly, then bootstrapping onto Nano requires trust in a specific source of information. It's as if the only way to bootstrap onto the Bitcoin network was to ask some trusted entity to pinky-swear to you which block was the current official chain tip.

My big question is: am I understanding the mechanism correctly? Or am I missing some critical piece of the puzzle?

P.S. I should clarify that I understand this is mostly a theoretical issue. Yes, large swings in voting weight are very uncommon. A set of starting vote weights that is "roughly" correct is very likely to give the same lattice state as everyone else. It just seems to me that it is not "guaranteed" in the strict sense that two people with the same (a) genesis block; (b) consensus rules; and (c) available data will always reach the same conclusion about the state of the Bitcoin ledger.

Blocks exist in the chain of a single account but receives also have links, and you can't process different blocks from the same chain in parallel. That said "link" blocks also have to be cemented before you can cement the receive. Anything different from that and you'd have gaps in the lattice.
The votes aren't reissued, the blocks are just broadcast again to you, so in a way they are final, by the time you arrive forks are already resolved, there's no conflicts in the chain for you to count weight a second time.
And no node will tell you "here, I have X weight, trust me", no, you'll have to count the weights yourself, but again, when you arrive there are no forks.

Just to clarify the question a bit, I have drawn up a diagram of a potential race condition that I believe can occur in the asynchronous lattice structure. Depending whether change-rep blocks that happen around the time of a fork are processed before or after the fork is processed, the outcome of the vote may appear different to different nodes. The result would be that different nodes may have inconsistent ledgers, some thinking fork A had the majority vote while others think that fork B had the majority.

If this is true, then the only way to resolve it would be through manual intervention. There would be no objective answer to the question of which side of the fork should "win".

I do not know the mechanism well, but from what I know a new node does not need them to know how a particular TX went, what they need and the current state of the situation, therefore the border blocks and the and the balance of each account. to know the history you should download the transactions from historical nodes and you should assume that that particular tx has been confirmed by the network that existed at its time

Confirmation isn't just the first one to 67%, it's 67% more vote weight than any competing fork

That's true, but it doesn't eliminate the problem. It makes the issue more unlikely to occur, but that's not a guarantee. All it means is that a larger amount of vote weight would have to move from reps voting for fork-side A to reps voting for fork-side B in the roughly the same time window when the fork is broadcast.

Yes, it's very unlikely that 30-40% of the vote weight would all shift at once like that. But not impossible. Binance alone has nearly 30% of the weight. What if Binance decides (for whatever reason) that they are no longer going to run their own rep and delegates their cold-wallet weight to the Nano Foundation. That could be a 30% swing. A fork that happened at the same moment may genuinely be subject to this race condition.

I've been thinking it through, and I do see a solution to this problem. Basically, the community could publish proofs of the inconsistent ledger status caused by the forked blocks. Once we were aware which accounts were affected, we could agree as a community on a specific order to process the blocks (so that we would all determine the fork outcome using the same vote weight distribution). The obvious non-political order would be to just order the blocks by their hashes.

That would work. But it's pretty cumbersome. It would probably take a few days to resolve the fork.

It could theoretically also be automated, but it will probably never be a common enough occurrence to bother automating, especially since accounts that did not have forks at the time of the big vote-weight change are unaffected.

Can someone confirm whether this is why the required quorum increased from 51% to 67% when some forks were accidentally cemented?

If not, then why was that change made?

2 Likes