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.