Proof of Work

In Hashiverse is proof of work geen blockchain-feature — het is een spamfilter dat geen poortwachter nodig heeft. In plaats van een centrale autoriteit te vereisen die beslist wie wat mag doen, zorgt PoW ervoor dat elke actie een echte kost in berekening met zich meedraagt. Kwaadwillenden die het netwerk met afval willen overspoelen moeten voor elk stukje ervan betalen, terwijl legitieme gebruikers een kost betalen die te klein is om op te merken.

PoW wordt niet op één plek in het systeem gebruikt. Het is door elke laag heen geweven, met de kost geschaald aan het potentieel voor misbruik bij elke laag.

RPC-envelope-PoW

Elk verzoek dat naar een server wordt gestuurd moet een geldige PoW-oplossing bevatten: een salt zodat Blake3(timestamp || salt || payload_hash) een minimum aantal leidende nul-bits heeft. Het minimum wordt ingesteld door Config.POW_MINIMUM_PER_ENVELOPE. Servers wijzen elk verzoek dat aan deze drempel niet voldoet af voordat de payload wordt verwerkt.

Dit is de eerste verdedigingslinie tegen DDoS. Een aanvrager kan geen tienduizend rommel-verzoeken per seconde sturen — elk verzoek vereist echte berekening. De tijdstempel in de PoW-input voorkomt replay-aanvallen; een oplossing die een uur geleden is berekend is nu niet geldig.

Bron: rpc.rs

Server-identiteit-PoW

Het aanmaken van een server-identiteit vereist het vinden van sleutelparen zodat de resulterende server-ID een voldoende aantal leidende nul-bits in zijn Blake3-hash heeft. Dit duurt enkele uren op standaardhardware. Je kunt geen tienduizend nepservers in seconden opstarten. De PoW-kost van het aanmaken van servers is het mechanisme dat Sybil-aanvallen op de DHT-ring duur maakt zonder dat een centrale autoriteit nieuwe servers hoeft goed te keuren.

Bron: server_id.rs

Bericht-indienings-PoW

Een bericht indienen is een twee-fase-protocol: Claim dan Commit. De claim-fase vereist PoW en reserveert een indieningsslot. De commit-fase levert de werkelijke inhoud. Dit voorkomt een klasse aanvallen waarbij een tegenstander servers overspoelt met grote payloads zonder vooraf werk te doen.

Posten naar hashtag-servers en posten naar antwoord-servers vereist eerdere indiening bij je eigen tijdlijn-servers (op dit moment minstens drie servers) voordat het rehash-bericht wordt gepubliceerd, wat een extra barrière toevoegt aan bulk-spam-versterking. Hoe vaker je naar je eigen tijdlijn post, hoe meer PoW je voor indiening moet doen.

Bron: hashiverse-lib/src/protocol/posting/, hashiverse-server/src/server/handlers/

Interactie-PoW en feedback-rangschikking

Elke interactie — like, dislike, melding — vereist PoW bovenop de basis RPC-envelope-vereiste. De PoW achter een feedbacksignaal bepaalt zijn gewicht in de schademetrieken van het netwerk: signalen met hogere PoW hebben de voorkeur boven signalen met lagere PoW voor hetzelfde (post, feedback type)-paar. Een netwerkbreed maximum wordt onderhouden en over servers heen geheeld.

Dit creëert een interessante speltheorie: je kunt de signaalsterkte van een feedback verhogen door meer berekening te investeren. Een gebruiker die sterk om een stuk inhoud geeft — een journalist die een gevaarlijk bericht markeert, een gemeenschapslid dat een waardevol bericht versterkt — kan echt computationeel gewicht achter zijn signaal leggen. Het cumulatieve signaal van duizenden of miljoenen matige-PoW-interacties zal echter zwaarder wegen dan een enkel hoge-PoW-signaal van een tegenstander die de rangschikking probeert te manipuleren.

Bron: encoded_post_feedback.rs, post_bundle_feedback_healing.rs

PoW-algoritme-ontwerp

In plaats van een enkele hash-functie te gebruiken (wat ASIC-optimalisatie uitnodigt), ketent Hashiverse PoW meerdere algoritmen in een pseudo-willekeurige volgorde afgeleid van de input. Een geldige PoW-oplossing moet alle algoritmen in de keten hebben doorlopen. Dit verhoogt de lat voor gespecialiseerde hardware: een ASIC die snel is in Blake3 maar traag in SHA3 zal worden uitgeschakeld door een algemene CPU die alle algoritmen efficiënt verwerkt.