This audit separates the peer-to-peer mechanics used to discover chain data from the consensus rules that decide which chain is valid. It focuses on headers/block acquisition, inventory requests, previous-block linkage, most-work chain selection, orphan handling, and the evidence needed to measure synchronization performance.
Reviewed VTA source maintains chainActive and compares chain work when selecting the best known chain.
The previously audited inventory/getdata/block message path provides the transport layer for block acquisition.
Block processing requires the previous-block relationship before a block can become part of the active chain.
No controlled full-node initial-sync benchmark has been executed.
| Area | Reviewed finding | Status |
|---|---|---|
| Peer handshake | Version/verack establishes the peer messaging session used by later synchronization traffic. | Cross-audited |
| Inventory / requests | The P2P message layer provides inventory announcements and getdata requests for object transfer. | Cross-audited |
| Previous-block linkage | Block processing uses the previous-block relationship when connecting a candidate block to chain state. | Source path |
| PoW validation | Candidate blocks pass proof-of-work validation before becoming accepted chain data. | Previously verified |
| Chain work | CBlockIndexWorkComparator orders competing chains using nChainWork, with sequence ordering as a secondary comparison. | Source evidence |
| Active chain | chainActive represents the selected active chain after chain-state transitions. | Source evidence |
| Orphan blocks | Missing-parent blocks enter an orphan-related processing path; exact release-pinned storage and retry details require deeper source tracing. | Needs deeper pin |
| Headers-first synchronization | A modern headers-first download claim should not be inferred for this legacy codebase without release-specific message/state tracing. | Not asserted |
| Initial sync speed | No controlled clean-node synchronization timing, bandwidth, CPU or disk benchmark has been performed. | Not measured |
| Network-wide sync status | The user's local height is not treated as the current network-wide height. | Evidence rule |
Peers provide candidate chain data. Acquisition itself is not proof of validity.
PoW, header rules, transactions and chain-state rules determine whether candidate data can be accepted.
Competing valid candidates are compared through chain-work logic rather than by simply trusting peer height.
No claim is made about current network synchronization speed or peer-to-peer download efficiency.
1. Pin exact VTA Core release / commit. 2. Start a clean disposable node with no existing chainstate. 3. Record peer count and connection times. 4. Capture version/verack and synchronization-related messages. 5. Record inventory / request sequence. 6. Record first received block and first accepted block. 7. Verify previous-block linkage for sampled blocks. 8. Record validation failures separately from transport failures. 9. Create a controlled competing branch and observe chain-work selection. 10. Deliver a child block before its parent and observe orphan recovery. 11. Measure blocks/hour, bytes received, CPU and disk activity. 12. Repeat with different peer counts. 13. Compare clean-node sync time across exact releases. 14. Never use the production wallet directory for destructive sync experiments.