Het DHT-netwerk

Hoe vinden honderden onafhankelijke servers zonder centrale directory elkaar, worden ze het eens over waar gegevens leven en routeren ze verzoeken efficiënt? Hashiverse gebruikt een Kademlia distributed hash table — dezelfde algoritmefamilie die door BitTorrent, IPFS en de peer-discoverylaag van Ethereum wordt gebruikt — aangepast voor de toegangspatronen van een sociaal netwerk.

De ring

Elke entiteit in Hashiverse — servers, gebruikers, berichten, hashtags — heeft een 256-bits identificator afgeleid van zijn Blake3-hash. Deze ID's leven op een ring: de adresruimte loopt rond bij 2256. "Afstand" tussen twee ID's is de XOR van hun bitpatronen, een metriek die de ring nuttige routingseigenschappen geeft.

Elke server onderhoudt verbindingen met andere servers waarvan de ID's qua XOR-afstand dichtbij de eigen ID liggen, plus verbindingen op exponentieel toenemende afstanden (de Kademlia k-buckets). Deze structuur betekent dat elke server een query in O(log n) hops kan routeren naar de server die het dichtst bij een gegeven doel-ID ligt, waarbij n het aantal servers in het netwerk is.

Bron: kademlia.rs

Waar gegevens wonen

Een bucket berichten wordt opgeslagen op de servers waarvan de ID's het dichtst bij het location_id van de bucket liggen — een hash afgeleid van het bucket-type, de basis-ID (gebruiker, hashtag of bericht) en het tijdvenster. Dit betekent:

Er is geen master-index. Geen server weet waar alles is. Elke server weet waar dingen in de buurt zijn, en hoe te routeren naar dingen die ver weg zijn.

Belastingverdeling

Populaire hashtags zouden een knelpunt zijn als alle berichten voor een hashtag voor onbepaalde tijd op dezelfde handvol servers terechtkwamen. Hashiverse verdeelt deze belasting met behulp van op tijdperken gebaseerde sleutelrotatie: de location-ID voor een hashtag-bucket verschuift in de loop van de tijd, dus verschillende tijdperken landen op verschillende delen van de ring — verschillende servers. Alle tijdlijn-location-ID's roteren op een maandelijkse cadans; maar drukkere tijdlijnen overlopen automatisch in buckets met toenemende granulariteit.

Het bucketsysteem is hiërarchisch: 1-maand-buckets verdelen zich in wekelijks, dan dagelijks, dan 6-uurs, uurlijks, 15-minuten, 5-minuten en 1-minuten-buckets. Het laden van de tijdlijn doorloopt deze hiërarchie recursief — beginnend grof en alleen drillen naar fijnere buckets waar inhoud bestaat. Een tijdlijn met spaarzame activiteit laadt goedkoop; een dichte tijdlijn laadt efficiënt omdat elke bucket parallel kan worden opgehaald.

Bron: buckets.rs, recursive_bucket_visitor.rs

Transportabstractie

Het protocol is transport-agnostisch. De TransportFactory, TransportServer en TransportServerHandler traits in hashiverse-lib/src/transport/ definiëren de interface; implementaties worden uitgewisseld zonder de protocol-logica aan te raken:

De integratietests benutten dit zwaar: een test die healinggedrag, DHT-routing of bericht-propagatie verifieert, kan volledig in het geheugen draaien met deterministische timing, geen poorten en geen opruimactie.

Test-harness-orkestratie

De test-harness-binary start een primaire server (voor bootstrap) plus een configureerbaar aantal secundaire servers in één enkel proces met behulp van Tokio's JoinSet, allemaal dezelfde annuleringstoken delend voor nette afsluiting. De HashiverseServer-orkestrator initialiseert Kademlia, spawnt transport-handlers en beheert peer-ontdekking.

Bron: hashiverse-integration-tests/src/bin/test_harness.rs