Auditing supply and balances in a future of pruned nodes

In future when the full historical ledger is large and individual users want to audit the ledger to confirm the total supply hasn’t changed will downloading a copy of a pruned ledger from a trusted 3rd party (eg one of the principal reps) still enable them to do this?

Also, if the supply was provably unchanged, could someone modify the pruned node account states to falsify an account balance in a way that the user could not verify the senders account balance independently of the rep node consensus when receiving a transaction? This would obviously be a process independent of the actual transaction which would be validated by the consensus.

In summary I’m trying to understand if there is a version of Bitcoin’s full node verification for Nano, but based on a pruned node with account states.

Although many details have to be worked out for allowing pruned nodes, here are some thoughts on your questions. With a node if you are able to get confirmed frontiers for all accounts and all pending blocks, you should be able to traverse across them summing up frontier balances and transfer amounts on pending blocks to confirm total supply remains, even on pruned nodes.

Once a node is in that pruned state it will continue to wait for consensus on blocks before marking them as confirmed in its ledger, so falsifying it shouldn't affect things network-wide. Perhaps it is worth expanding on your question though - are you asking how nodes would know if a pending block was valid if it was sent out at an earlier time but the sending account has had its account chain pruned since then (thus the previous to the pending is no longer available on the pruned nodes)?

2 Likes

Not so interested in whether the pending block was valid, more looking for an independent way to verify the supply and account balance if you don’t trust consensus.
I suppose if you have to download the pruned node from a trusted source that is taking part in consensus it’s probably a moot point.

In what scenario would you want to participate in the network while not trusting consensus though? That seems like the first requirement for participating in Nano: accepting that the generated consensus from the network through valid signatures on votes is what determines whether a transaction should be accepted.

Are you wondering about scenarios where a node may be isolated to connect to a majority of malicious peers? In that scenario, unless the malicious peers had more than 50% of the vote weight it wouldn't matter because you wouldn't see properly signed votes with enough weight to confirm transactions. So if you just use the consensus you see when connected to peers, then you should be fine.

When talking about whether you can verify the supply though, you would have to ensure you have all the frontiers and all pending blocks which are confirmed to attempt that. I believe that comes with its own difficulties when talking about pruned nodes, especially downloaded ones - what if you are missing an account and it isn't an active one on the network? You would only have a partial ledger until a transaction connected to that missing account.

1 Like

Simply looking for a coherent framework and way of responding to others analysing the protocol in comparison to alternatives with throttled ledgers like Bitcoin where a user can, in theory, audit the entire transaction history from genesis and the trust minimisation that this implies.

Yes, you can simply choose not to participate in Nano if you don’t trust the consensus. Maybe it simply comes down to that. Nano’s trust is minimised by spreading risk across validators.

Still feels like there’s room to have a clear and consistent response to the strength of assurance in terms of receipt. See https://medium.com/@nic__carter/unpacking-bitcoins-assurances-a3c98824d3f0

1 Like