Closed yangby-cryptape closed 1 year ago
Patch coverage: 45.73
% and project coverage change: -9.64
:warning:
Comparison is base (
98dfe2a
) 79.35% compared to head (e51a708
) 69.71%.
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.
Commits
refactor: move some data from peer state to peer itself
Why? Some data are not belongs to the peer state, when state was changed, those data should keep as before.
N.B. Rename many
peer
topeer_index
sincepeer
andpeer_index
are different things.refactor: refactor peer state to be a state machine
.some()
to distinguish the peer state.The complexity of that struct grows exponentially.
refactor: better judgment for timeout
Remove several TODO.
chore(deps): bump ckb from 0.106.0 to 0.108.0
feat: check block filter hashes
First, the light client will try to connect more than
max_outband_peers
peers.If a check point was confirmed by more than
max_outband_peers / 2
peers and there are more thancheck_point_interval
blocks between it and the last proved number, we finalized it and store it in to disk.N.B. A finalized check point could not roll back! Since it's a long fork.
Denote those lists as
[L]
(called as "latest block filter hashes" in the code).If light client want to get block filters for blocks which start number is
N
:If
N
is less than the finalized check point number, and it is between the check pointM
and check pointM+1
, light client will request the hashes between check pointM
and check pointM+1
(called as "cached block filter hashes" in the code). After all hashes were downloaded, then light client will request the block filters and checks them with those hashes.If
N
is greater than the finalized check point number, then light client will only request the block filters which were confirmed by more thanmax_outband_peers / 2
peers in[L]
, and check those block filters with hashes in[L]
.TODO