Verzegelde batches onder load: PolitiCap ECN-proeven Bangkok en Berlijn

geplaatst in: Uncategorized | 0

Twee regionale marktknooppunten sturen verzegelde en afgewezen trade-batches naar een centrale hub

We draaiden twee live production-proeven met regionale PolitiCap-ECN-nodes — één op een snelle LAN-rand (Bangkok), één op een trage WAN-rand (Berlijn). Het doel was geen marketingvolume, maar meten hoe MarketMaker-fills, DutchBud-ledgerzegels, batch-upload, afwijzing van vervalste zegels en operator-quarantaine zich gedragen onder echte load.

Dit is een 3DN engineering-stuk: cijfers uit onze metrics-store, waargenomen gedrag en ontwerpkeuzes die standhielden. Het bouwt voort op eerdere notities over pull-in-plaats-van-push regio-updates en ledger-gebonden trade-batches.

Waarom ECN-vertraging nog steeds telt (korte historische omweg)

Electronic communication networks zijn geen nieuw idee. Aandelenmarkten leerden decennia lang dat wie het orderboek eerst ziet een economisch wapen is. De Berliner Börse — en Europese venues breder — horen bij debatten over vertraagde quotes, versnipperde liquiditeit en misbruik van short selling dat floreerde wanneer het ene pad trager was dan het andere. Schandalen rond naked shorting en “fail-to-deliver” gingen nooit alleen over hebzucht; ze gingen over asymmetrische informatie in de tijd.

PolitiCap is een civiele marktsimulatie met virtuele credits (DutchBud-dibs), geen contante effectenbeurs. De engineeringles blijft: als een regionale node fills kan verzinnen die de hub moet geloven, of als lag tot een bevoorrecht beeld van de tape kan worden gemanipuleerd, bouw je het oude ECN-probleem in het klein na. Onze proeven testten het omgekeerde: alleen verzegelde batches, pull-software, en quarantaine wanneer de zegel faalt.

Wat we testten

Proef Randkarakter Belasting Tegenstander
Bangkok LAN-achtig pad naar de hub MarketMaker-volume mild → medium over ~1 uur Periodieke vervalste ledgerregels in de lokale outbox
Berlijn WAN-rand (trage software-pull; kB/s-klasse) Korte verzegelde MM-burst (~3 minuten, 28 fills) Zelfde vervalste injectie; auto-quarantaine

Beide nodes volgden dezelfde regels: lokale matching blijft lokaal; syndicatie naar de hub vereist een DutchBud-receipt (ledger_ref + HMAC ledger_code). De hub accepteert nooit “omdat de node het zei.”

Lokale MM-fill regionaal boek DutchBud-zegel HMAC-receipt Outbox-batch node → hub POST Hub-tape verify + opslaan Vervalste ledger_code hub weigert · optioneel auto-quarantaine urgente e-mail naar ECN-operator
Figuur 1. Gelukkig pad vs vervalste zegel. Lokale matching kan doorlopen; de globale tape accepteert geen ongetekende fictie.

Bangkok — ramp op een schoon pad

Opzet. Twee MarketMaker-bots crossen een demo-symbool op de Bangkok-API. Volume steeg van mild (~8 shares/min) naar medium (~40 shares/min) over ongeveer een uur, met kleine random spread op prijs en lot.

Zegels. Elke geslaagde cross vroeg een DutchBud-ledgerzegel voordat de fill in de syndicatie-outbox mocht. Op deze rand liep zegelverkeer via de geauthenticeerde hub-proxy (geen direct bank-poort op de regionale VLAN). Seal-succes volgde de MM-crosses tijdens de ramp.

Syndicatieresultaat. Hub-metrics en de syndicated-trade-tabel gaven hetzelfde beeld: in de orde van ~580 ledger-vertrouwde fills van Bangkok op de hub-tape (trust-label ledger). Batch-upload draaide op een korte interval (één minuut) zodat accept/reject zichtbaar bleef.

Tegenstander. Een apart proces injecteerde outbox-rijen met geraden ledger-referenties en -codes. Die reden mee in hetzelfde batch-kanaal. Hub-verify wees ze af. Ze werden nooit hub-tape. Dat is precies waarom batches aan DutchBud-receipts hangen en niet aan “het woord van de node.”

Bangkok — hub-ingest (orde van grootte) ~580 legit geaccepteerd vervalste rejects rogue / ongeldige zegels
Figuur 2. Bangkok: verzegelde volume domineert; vervalste zegels worden afgewezen (retries blazen reject-tellers op, niet de tape).

CPU. Hub- en ledgerhosts lieten bij mild–medium tempo geen noemenswaardige compute-piek zien. HMAC-SHA256 voor receipts is goedkoop naast database-commits en HTTP. Historische “hash is duur”-verhalen (proof-of-work mining) zijn een ander werktype.

Berlijn — WAN-rand, korte burst, quarantaine

Randkarakter. De Berlijnse node zit op een beperkt WAN-pad. Software-self-update over die link zit in kilobytes per seconde — prima voor catalogusdelta’s en trade-JSON, pijnlijk voor multi-megabyte binaries. Production-verwachting blijft: nodes pullen; operators accepteren WAN-fysica.

Belasting. Een korte MarketMaker-burst leverde 28 lokaal verzegelde crosses in enkele minuten. Zegels liepen weer via de hub-proxy naar DutchBud.

Eerste batch. Bij de eerste geslaagde upload accepteerde de hub verzegelde rijen en wees de vervalste metgezel af.

Quarantaine. Door het duidelijke forged-seal-signaal zette de hub Berlijn automatisch in quarantaine:

  • Verdere trade-POSTs van die node-API-key kregen 403 — geen nieuwe syndicate-writes.
  • De geregistreerde operator kreeg een urgente e-mail (reden + bewijs).
  • Lokale matching werd niet expres vertraagd. Quarantaine straft uplink-privilege, niet broker-latency op het regionale boek.

Lift en de valdeur. Na opheffen van quarantaine terwijl er nog een leftover rogue-outboxrij naast already-consumed legit-receipts lag, mengde de volgende flush replay-rejects met één vervalste rij — auto-quarantaine opnieuw, plus een tweede operator-mail. Correcte security, licht komische ops. We verscherpten auto-quarantaine zodat die alleen trapt wanneer alle rejects in een batch rogue-stijl zijn.

MM-burst 28 verzegelde fills Batch #1 accept + reject rogue Quarantaine 403 + e-mail Lift ops-opschoning Outbox blijft retrien tijdens quarantaine — hub-weigering is bewust, geen stille drop.
Figuur 3. Berlijnse tijdlijn: burst → gemengde batch → quarantaine → operator-mail → gecontroleerde lift.

Wat de metrics-store liet zien

  • Node-identity gauges (draaiende build vs hub-latest, laatste hello) bleven continu voor Bangkok en Berlijn zodra beide de trial-build meldden.
  • Hub-ingest-counters scheidden kind=legit vs kind=rogue en result=accepted|rejected.
  • Node-upload-counters leven op het node-proces; WAN-edges die we niet scrapen kleuren geen “node upload”-paneel, ook als logs elke minuut POSTs tonen. Hub-ingest blijft dan de bron van waarheid.
  • Quarantaine-retries blazen hub-reject-totals op; de syndicated-trade-tabel groeit daar niet door.

Gesyndiceerde rijen droegen trust ledger. Bangkok leverde het bulk verzegelde volume; Berlijn de burst die vóór quarantaine doorkwam.

Ontwerpconclusies

  1. Pull wint op trage of deels onbeheerde netwerken. De hub heeft geen deploy-credentials op de rand nodig.
  2. Zegels zijn de trust-root; API-keys zijn alleen monden. Iedereen met een node-key kan een batch POSTen. Alleen DutchBud-HMAC maakt woorden geldig op de hub-tape.
  3. Rogue of gecompromitteerde keys krijgen uplink-isolatie + mail, geen klant-DoS. Lokale brokers expres vertragen zou attacker-aligned zijn.
  4. Historisch ECN-lag-misbruik is een herinnering, geen feature. PolitiCap blijft expres saai: geen globale tape zonder zegel.
  5. Ops-hygiëne telt even zwaar als crypto. Leftover forged outbox na een incident vuurt alarmen opnieuw af. Purge, dan lift.

Wat we daarna meten

Langere multi-node ramps, scrape van elke trusted edge waar netwerkpolicy het toelaat, reputatie voor high-trust operators, en dashboards die batch-events als counts behandelen in plaats van continue rates. De fabric is klaar voor meer volume; de volgende bottleneck wordt opslag en menselijke ops, niet hashen.

PolitiCap hoort bij de 3DN family — work · money · politics — met DutchBud als closed-loop ledger voor virtuele credits. Als je infrastructure eerlijk moet houden over netwerken die je niet volledig bezit, is pull-plus-seal een patroon om te stelen.

Geef een reactie

Je e-mailadres wordt niet gepubliceerd. Vereiste velden zijn gemarkeerd met *