Skip to content

README overstates ASN/geographic diversity enforcement #151

Description

@dirvine

Summary

While researching the Autonomi agent skill/node-operation guidance, I found a potential README/code truth mismatch in ant-node around Sybil/geographic diversity enforcement.

The README currently describes protections such as:

  • multi-layer Sybil resistance including subnet, ASN, geographic, and node-age machinery;
  • a Per ASN limit;
  • 7-region geographic distribution;
  • close groups constructed with geographic diversity requirements;
  • nodes from the same ASN/organisation not holding multiple replicas of the same data.

Current origin/main appears to enforce only exact-IP and subnet diversity in the live code path.

What I checked

Repos/refs checked locally after fetching origin/main:

  • WithAutonomi/ant-node origin/main at fb7494e84dd02f664fce83cebd210a4c73ddcfe2
  • saorsa-labs/saorsa-core origin/main at 180454671b87debcb2afbd83f2d8126c41b0dd02
  • WithAutonomi/ant-protocol origin/main at 34c11cb9f626290b18263ebe8e10e172e5523424

Relevant current implementation notes:

  • saorsa-core/src/security.rs defines IPDiversityConfig with only:
    • max_per_ip
    • max_per_subnet
  • Comments describe this as a two-tier model: exact IP plus subnet (/24 IPv4, /48 IPv6).
  • saorsa-core/src/dht/core_engine.rs appears to enforce those two IP/subnet limits when adding DHT peers.
  • BgpGeoProvider exists in saorsa-core/src/bgp_geo_provider.rs, and TransportHandle constructs/stores/passes it, but the connection lifecycle parameter is named _geo_provider and I did not find a current call path where ASN/geographic data affects admission, rewards, close-group construction, or replica placement.

So the README appears to describe either intended/future design or stale behaviour, rather than current enforcement.

Why this matters

The mismatch can mislead operator guidance and agent skills. For example, an Autonomi/Fae skill should not teach agents to optimise for ASN/geographic/7-region reward or placement rules if the running release only enforces exact-IP/subnet diversity.

Current safe wording for operator guidance would be something like:

Operators should avoid concentrating many nodes behind the same public IP or subnet. Current code enforces exact-IP and subnet diversity limits. Geographic/ASN distribution is good network hygiene and may be intended future protection, but should not be presented as active reward/placement enforcement unless verified in live source.

Suggested resolution

Either:

  1. update the README to mark ASN/geographic/7-region/node-age machinery as planned/future/aspirational if it is not currently enforced; or
  2. link to the implementation path/branch if it is live elsewhere; or
  3. wire the documented ASN/geographic enforcement into the current code path and add tests proving it affects admission/placement/rewards as intended.

Related note: constants used by operator docs/skills should preferably be fetched/checked from live source rather than hardcoded in prose. Current ant-protocol/src/chunk.rs has CLOSE_GROUP_SIZE = 7 and CLOSE_GROUP_MAJORITY = 4, while nearby docs/reads can drift across versions.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions