Analysing the google attack

Community Blog Posts
65

Ah, good clarification, thanks for pointing this out.

I’ve added this recursion to the relocation mechanism to the simulation.

The simulation defines ‘greater requirement’ as “prioritise sections with shorter prefixes and having less nodes to balance the network”. This may change in the future.

Tracking the number of neighbourhoods before the ‘best’ section is found gave these results (see neighbour_relocation_hops.go):

100K vaults (500K join interleaved with 400K depart)

hops occurances
   0 288
   1 220779
   2 39293
   3 41590

301950 total relocations

Most relocations are within the current neighbourhood (1 hop away, about 73% of the time). But there are about 27% of cases where the vault is relocated further than just the nearest neighbourhood (2 or 3 hops away).

Redoing Targeted Google Attack

The targeted google attack was retested with recursive-neighbour relocation (which should spread attacking vaults further afield and reduce their impact).

Targeted Recursive NetSize  Test 1       2       3       4       5 | Avg Pct
      No        No    100K  125776   98073  137955  103118   97975 | 52.7
     Yes        No    100K    1852    4893    2598    2366    3694 |  3.0
     Yes       Yes    100K    5631    4031    5514    3810    4494 |  4.5

An improvement for sure, but still the effect of concentrated targeted attack is quite significant.

Thanks again for clarifying the details of the relocation mechanism.

14 Likes