„Als niemand weet wie er op het cruciale moment de beslissingen neemt, verlies je tijd. En in een stilgelegde fabriek is tijd geld ”
Een cyberaanval is niet alleen een IT-probleem. Het is een bedrijfscrisis, met alles wat daarbij hoort: beslissingen die snel, onder druk en in een verslechterde situatie moeten worden genomen. En zoals elke crisis legt ook deze zowel organisatorische als technische tekortkomingen bloot.
Wat we in de praktijk steevast zien, is dat de situatie niet zozeer wordt verergerd door de geavanceerdheid van de aanval, maar door het gebrek aan voorbereiding bij degenen die erop moeten reageren. De cijfers spreken voor zich: 58 % van de bedrijven geeft toe niet te weten hoe ze moeten reageren op een cyberaanval en slechts 2 tot 4 % zegt echt voorbereid te zijn. Wat de incidentresponsplannen betreft: 45 % van de organisaties beschikt er niet over, en van degenen die er wel een hebben, werkt 42 % het nooit bij. Met andere woorden: de meeste industriële bedrijven zouden zonder stappenplan in een crisis terechtkomen. Algemeen directeur, financieel directeur, IT-directeur, productiedirecteur: iedereen heeft een specifieke rol te vervullen. Maar die rol moet wel al vastgelegd zijn voordat de crisis uitbreekt.
Wat er werkelijk gebeurt in de eerste uren
Nog voordat we het over crisisrespons hebben, is er een onderwerp dat vaak wordt onderschat: detectie. Aanvallers maken zichzelf niet bekend. Hun doel is om zo lang mogelijk onzichtbaar in het systeem te blijven (gemiddeld 2 tot 3 weken), zodat ze de tijd hebben om zich te verplaatsen, rechten te verwerven, de meest waardevolle activa te identificeren en hun kanalen voor gegevensdiefstal op te zetten. Pas als dit werk is voltooid, zetten ze de zichtbare aanval in gang: ransomware, versleuteling, blokkering.
Het gevolg: wanneer het bedrijf zich realiseert dat het is gecompromitteerd, is het vaak al te laat om de omvang van de inbreuk te beperken. Vandaar het cruciale belang van de juiste detectietools, waarmee een abnormale situatie kan worden geïdentificeerd voordat deze uit de hand loopt.
Vervolgens volgt de eerste, vaak verkeerde reflex: alles uitschakelen. De bedoeling is begrijpelijk – de verspreiding stoppen – maar het gevolg is contraproductief. Door de machines uit te schakelen, worden de tijdelijke geheugens gewist, en daarmee ook alle sporen die nodig zijn om de aanval te analyseren en de infectieroutes te identificeren. De juiste werkwijze is om de verbinding met het netwerk te verbrekenom de verspreiding te stoppen, zonder daarbij de stroomtoevoer naar de gecompromitteerde systemen uit te schakelen. Een technisch detail, maar wel een dat alles verandert voor het verdere verloop van het onderzoek.
Tijd: de variabele die iedereen onderschat
In een crisissituatie is tijd de grootste vijand. Elk uur dat verloren gaat met uitzoeken wie er beslist, wie wie belt en hoe er wordt gecommuniceerd, is geld dat wegvloeit en geloofwaardigheid die afbrokkelt.
Een stilgelegde fabriek produceert niet. Levert niet. Factureert niet. De boetes voor vertraging stapelen zich op, klanten worden ongeduldig, partners maken zich zorgen. En als het ERP-systeem is getroffen – dat centrale systeem dat bestellingen, productie, verzendingen en facturering coördineert – loopt de hele operationele keten tegelijkertijd vast. In de verwerkende industrie duurt deze stilstand gemiddeld 12 dagen. Twaalf dagen zonder te produceren, zonder te leveren, zonder te factureren.
Juist op dat moment maakt een goede voorbereiding het verschil. Een organisatie die heeft geanticipeerd, haar crisisprocessen heeft gedocumenteerd en haar teams heeft getraind, neemt haar beslissingen binnen enkele minuten, terwijl een andere organisatie daar uren over doet. En in deze context kunnen een paar gewonnen uren honderdduizenden euro’s besparen.
Wie doet wat: de rol van elke besluitvormer
Een cybercrisis is niet alleen een zaak van de IT-afdeling. Het is een gezamenlijke inspanning, waarbij elke besluitvormer een duidelijk afgebakend werkterrein heeft. Het probleem is dat deze rollen zelden al vóór de crisis zijn vastgelegd. Daardoor lopen we elkaar in de weg en verliezen we kostbare tijd aan geïmproviseerde afwegingen, terwijl iedereen zich juist op het essentiële zou moeten concentreren.
De CIO / CISO stuurt de technische respons aan: de omvang van de inbreuk vaststellen, de inperkingsprocedures activeren, de IT-teams en externe dienstverleners coördineren. Hij is degene die de operationele leiding over de crisis in handen heeft.
De productiedirecteur beslist wat doorgaat en wat wordt stopgezet. Welke productielijnen kunnen in beperkte modus worden gehandhaafd? Welke processen zijn absoluut cruciaal? Hij moet over deze vragen hebben nagedacht vóór de dag zelf, niet midden in de crisis.
De financieel directeur activeert de cyberverzekeringen, beoordeelt de financiële verliezen in realtime en beslist over nooduitgaven. Hij is ook degene die de vraag stelt die niemand wil horen: hoeveel kost het ons als we betalen, hoeveel kost het ons als we niet betalen?
De algemeen directeur is de crisismanager. Hij neemt beslissingen, treedt op als scheidsrechter en communiceert naar buiten toe: klanten, partners, aandeelhouders, toezichthouders. Zijn rol is niet technisch van aard. Hij is besluitvormer en vertegenwoordiger. En om deze rol goed te kunnen vervullen, moet hij al ruim van tevoren bij de voorbereiding betrokken zijn geweest.
Ookde communicatie- en HR-teams hebben een rol te spelen: het opstellen van boodschappen die zijn afgestemd op elke doelgroep (medewerkers, klanten, pers), en het beheren van de HR-aspecten die verband houden met het mobiliseren van de teams in crisissituaties. Als de communicatiesjablonen niet klaar zijn, verlies je een half uur aan het onder stress opstellen van wat in dertig minuten rust had kunnen worden voorbereid.
Wat er vóór de crisis op het spel staat
De echte vraag is niet „zullen we worden aangevallen?“, maar „wanneer?“. Cybercriminele groepen zijn tegenwoordig gestructureerd als echte bedrijven, met tools, processen en specialisaties. Er vinden dagelijks tientallen incidenten plaats. Voor een industriële onderneming is de kans om ooit het doelwit te worden geen theoretisch scenario.
Wat organisaties die er goed uitkomen onderscheidt van organisaties die wekenlang stil liggen, is slechts één ding: voorbereiding.
Concreet betekent dit drie dingen.
Documenteren. Van tevoren vaststellen welke systemen als eerste weer online moeten worden gebracht, vervolgens hoe het ERP-systeem opnieuw wordt opgestart, wie welke dienstverlener belt en wat het noodnummer is van de juiste contactpersoon. Deze informatie lijkt in normale omstandigheden vanzelfsprekend. Onder stress raakt men deze echter uit het oog.
Rollen vastleggen. Wie neemt de beslissingen in het crisiscentrum? Wie houdt het logboek bij? Wie regelt de logistiek? Zolang deze rollen niet op papier staan en bij iedereen bekend zijn, zal de crisis in verwarring worden aangepakt.
Testen. Een crisisplan op papier is altijd perfect. In de praktijk wijkt het af. Oefeningen maken het mogelijk om te controleren of de nummers kloppen, of de contracten met dienstverleners de juiste scenario’s dekken en of de teams goed reageren onder druk. Een niet-getest systeem is een onbetrouwbaar systeem. Toch voert slechts 30 % van de organisaties regelmatig tests en oefeningen uit, wat betekent dat 7 op de 10 bedrijven de tekortkomingen van hun plan pas zullen ontdekken op de dag dat ze zich geen fouten meer kunnen veroorloven.
NIS2 en ISO 27001: kaders om de voorbereiding te structureren
De regelgeving dwingt bedrijven steeds meer in deze richting. NIS2, waarvan de eisen bindend zijn voor bedrijven die eraan onderworpen zijn, schrijft expliciet voor dat er processen moeten worden gedefinieerd voor incidentbeheer, bedrijfscontinuïteit en herstel, en dat de doeltreffendheid daarvan regelmatig moet worden getest. Dit is geen optie, maar een verplichting.
De vrijwillige norm ISO 27001 biedt op haar beurt een structurerend kader om deze maturiteit op de lange termijn op te bouwen: vaststellen wat kritiek is, passende maatregelen invoeren, deze handhaven en voortdurend verbeteren.
In beide gevallen is de boodschap dezelfde: voorbereiding op een crisis kan niet zomaar worden geïmproviseerd. Deze moet worden opgebouwd, gedocumenteerd en getest, en hierbij is het management betrokken, niet alleen de IT-teams.
Cyberbeveiliging is een zaak van het management — geen IT-kwestie
Dit is misschien wel de belangrijkste boodschap om te onthouden. Cyberbeveiliging blijft maar al te vaak beperkt tot de serverruimte. Maar een cyberaanval die het ERP-systeem lamlegt, is een crisis die gevolgen heeft voor de productie, de financiën, de klantrelaties en de reputatie.Het is een zakelijk onderwerp dat op directieniveau moet worden behandeld.
Als het management dit onderwerp niet oppakt, blijft het onderbelicht, ondergefinancierd en onvoldoende voorbereid. En op de dag dat de crisis toeslaat – want die komt er zeker – zal niemand er echt klaar voor zijn.
Om op dit gebied begeleiding te krijgen, moet je samenwerken met partners die beide talen spreken: die van cyberbeveiliging en die van het ERP-systeem. Waar een externe cyberdeskundige eerst je ERP-omgeving moet begrijpen voordat hij deze kan controleren, beginnen TVH Consulting en haar dochteronderneming Fidens al vanuit de binnenkant. Een voorsprong die op de dag zelf het verschil kan maken.
Advanced Custom Fields is een WordPress-plug-in waarmee je extra inhoudsvelden kunt toevoegen aan je WordPress-bewerkingsschermen. Deze extra inhoudsvelden worden meestal ‘Custom Fields’ genoemd en stellen je in staat om sneller websites te bouwen en je klanten sneller wegwijs te maken. In deze handleiding leer je hoe je:
De ACF-plug-in te installeren
Nieuwe velden aan te maken
Veldinhoud aan te maken
velden in je thema weergeeft
Aangepaste berichttypen en taxonomieën te registreren
De basis
Aangepaste velden zijn een standaardonderdeel van WordPress en verschijnen op pagina’s, berichten en aangepaste berichttypen, maar de standaardinterface voor aangepaste velden is niet erg gebruiksvriendelijk. Als ACF is geïnstalleerd, kunt u zelf bepalen welke velden worden weergegeven en hoe ze eruitzien. U wilt bijvoorbeeld dat er een ‘Hero Image’ wordt geselecteerd voor uw startpagina. Je kunt ACF gebruiken om dit afbeeldingsveld eenvoudig aan te maken en weer te geven bij het bewerken van de startpagina! Hier zie je het verschil tussen standaard aangepaste velden en Advanced Custom Fields.
Nu je velden zijn aangemaakt, is het tijd om je inhoud te bewerken! Al onze velden zijn zeer intuïtief in gebruik en sluiten naadloos aan bij de stijl van het WordPress-beheerdersgedeelte. Je hoeft geen enkele actie te ondernemen om aangepaste velden weer te geven of te bewerken; ze verschijnen en werken net als de WP-velden `post_title` en `post_content`! Voer gewoon je inhoud in en werk het bericht bij!
Het weergeven van veldwaarden is het paradepaardje van ACF! Elke veldwaarde kan worden geretourneerd als een PHP-variabele of als HTML worden weergegeven via de magische functies`get_field()`en`the_field()`. Deze functies (naast vele andere) bieden een ontwikkelaarsvriendelijke manier om je WordPress-thema aan te passen zonder urenlang onze documentatie te hoeven doorlezen! Hier is wat voorbeeldcode om te zien hoe onze intuïtieve API werkt!
Dit is een uitstekende blogpost in het Engels. Ik heb nog nooit in mijn leven zo’n geweldige blogpost gezien.
MultilingualPress AutoTranslate stroomlijnt het vertaalproces voor meertalige WordPress-sites door de vertaling van WordPress-kernblokken, taxonomieën en reacties te automatiseren.
Deze functie ondersteunt naadloze inhoudsvertaling voor diverse elementen van een WordPress-site, waardoor berichten, pagina’s, aangepaste berichttypen, categorieën, tags en zelfs reacties automatisch worden vertaald.
Dankzij de integratie met toonaangevende aanbieders zoals DeepL, OpenAI en Amazon Translate zijn de vertalingen van hoge kwaliteit en contextgevoelig.
Het is alweer een tijdje geleden (bijna 3 maanden) sinds mijn laatste blogpost. Maar eindelijk ben ik terug, en laten we aan de slag gaan! Voortaan zullen mijn blogs zich voornamelijk richten op interessante onderzoeksartikelen op het gebied van LLM en GenAI. Ik zal probleemstellingen bespreken die ik in mijn dagelijks leven tegenkom, in wat we graag ‘story time’ noemen , zoals velen van jullie zich wellicht nog herinneren uit mijn eerdere blogs. Daarna ga ik dieper in op de technische aspecten van die probleemstellingen. Naast het toelichten van de onderzoeksartikelen zal ik ervaringen en praktische voorbeelden delen, en ik zal ook ingaan op technische details die in de artikelen wellicht overgeslagen worden, in de veronderstelling dat de lezer deze al kent. Laten we er dus in duiken!
Nog maar een paar dagen geleden kwam een bevriende familie bij ons op bezoek. Ze hebben een schattige dochter van 8 jaar. Het was 15 augustus, de Onafhankelijkheidsdag van India, en haar school had haar de opdracht gegeven een essay over Onafhankelijkheidsdag te schrijven met de strikte eis van ‘minstens 10.000 woorden’. Dat is echt heel veel! Ik weet echt niet of ik dit een essay of een miniboekje voor een 8-jarig kind moet noemen! Zoals gewoonlijk begonnen de ouders namens hun kind aan een concept te werken. Het eerste waar iedereen dan aan denkt, is ChatGPT of iets dergelijks. In eerste instantie waren de ouders heel ontspannen en dachten ze: „Laten we hier op 14 augustus, slechts een dag van tevoren, mee beginnen, want het is gewoon een kwestie van ‘het LLM-model een prompt geven’ en de output ontvangen.” Op de avond van 14 augustus deden ze precies dat, maar raad eens wat er gebeurde? Het model leverde weliswaar een goede output op, maar had moeite om de volgende aspecten te waarborgen: relevantie, nauwkeurigheid, samenhang, duidelijkheid, breedte en diepgang, en leeservaring. Bovendien, wanneer het model wordt gevraagd om strikt 10.000 woorden te produceren, herhaalt het de context en raakt het aanzienlijk uit de context.
Nu vragen jullie je misschien allemaal af: wat zijn deze zes dimensies? Laten we daarom verder lezen en ons verdiepen in de probleemstelling van „de beperkingen van de huidige grote taalmodellen (LLM’s) met lange context bij het genereren van ultralange outputs“. In deze blog verkennen we een interessant onderzoeksartikel met de titel „LONGWRITER: UNLEASHING 10,000+ WORD GENERATION FROM LONG CONTEXT LLMS“. Hoewel deze modellen invoer tot 100.000 tokens kunnen verwerken, hebben ze doorgaans moeite met het produceren van uitvoer die langer is dan 2.000 woorden. De belangrijkste reden voor deze beperking wordt toegeschreven aan de datasets voor supervised fine-tuning (SFT), die geen voorbeelden van lange uitvoer bevatten, waardoor het vermogen van de modellen om uitgebreide tekst te genereren wordt beperkt. Laten we in deze blog dus eens kijken naar de intrigerende techniek die de auteurs hebben gebruikt om lange outputreacties te verbeteren en ervoor te zorgen dat het leven van ouders in de toekomst gemakkelijker wordt! En hoe zit het met de kinderen? Tegenwoordig laat ik dat over aan het lot, gezien de vooruitgang in AI en de manier waarop het leven voor hen gemakkelijker is geworden door beperkt gebruik te maken van hun mentale capaciteiten! Maar goed, laten we aan de slag gaan.
Inleiding
Laten we nu eens ingaan op de kern van het artikel. Het begint met het belichten van een interessante uitdaging bij LLM’s met lange context. Deze modellen, die meer dan 100.000 tokens aan invoer kunnen verwerken, hebben nog steeds moeite met het genereren van uitvoer die langer is dan 2.000 woorden. Dit is een belangrijk probleem omdat in sommige gevallen meer dan 1% van de gebruikersverzoeken daadwerkelijk langere antwoorden nodig heeft.
Wat is het kernprobleem? De datasets voor supervised fine-tuning (SFT) waarmee deze modellen worden getraind, bevatten simpelweg niet genoeg voorbeelden van lange outputs. Dus hoewel de modellen in staat zijn om lange inputs te verwerken, zijn ze niet getraind om op een effectieve manier lange outputs te produceren. Deze beperking blijft bestaan omdat veel LLM’s op dezelfde datasets vertrouwen.
Om dit aan te pakken, introduceren de auteursAgentWrite — een nieuwe aanpak die deze modellen helpt langere teksten te genereren door de taak in kleinere delen op te splitsen. Deze methode kan de lengte van de output opvoeren tot 20.000 woorden, ver boven wat doorgaans mogelijk is.
Het artikel introduceert ook LongWriter-6k en LongBench-Write, een dataset en benchmark die zijn ontwikkeld om modellen te trainen en te testen op hun vermogen om deze ultralange teksten te genereren. Het idee is om de grenzen van wat LLM’s kunnen te verleggen, waardoor ze beter in staat zijn om taken uit te voeren die een uitgebreide output vereisen.
Laten we nu eens bekijken wat AgentWrite is en hoe het werkt:
Stap I: Plan Allereerst begint AgentWrite met een plan — net zoals je een artikel zou opzetten voordat je aan het schrijven begint. Het model maakt een gedetailleerde opzet op basis van de gegeven instructies, waarbij de hoofdinhoud wordt uiteengezet en het aantal woorden per sectie wordt gespecificeerd. Zie het als de routekaart van het model. Als het bijvoorbeeld de opdracht krijgt om een stuk van 30.000 woorden over het Romeinse Rijk te schrijven, zou het plan er ongeveer zo uit kunnen zien:
Paragraaf 1: Inleiding tot de oorsprong van het Romeinse Rijk (700 woorden)
Paragraaf 2: De stichting van het Romeinse Rijk (800 woorden)
…
Paragraaf 15: Samenvatting van de geschiedenis van het Romeinse Rijk (500 woorden)
Deze gestructureerde aanpak zorgt ervoor dat het model precies weet waar het naartoe gaat, waardoor het gemakkelijker wordt om de taak van het genereren van lange teksten te beheren. Hieronder kun je zien hoe de auteur de invoer heeft gestructureerd:
Samenvatting. Een puur peer-to-peer-versie van elektronisch geld zou het mogelijk maken om online betalingen rechtstreeks van de ene partij naar de andere te versturen zonder tussenkomst van een financiële instelling. Digitale handtekeningen bieden een deel van de oplossing, maar de belangrijkste voordelen gaan verloren als er er nog steeds een vertrouwde derde partij nodig is om dubbele uitgaven te voorkomen. Wij stellen een oplossing voor het dubbele-uitgavenprobleem voor met behulp van een peer-to-peer- netwerk. Het netwerk voorziet transacties van een tijdstempel door ze via hashing te verwerken in een doorlopende keten van op hash gebaseerde proof-of-work, waardoor een record ontstaat dat niet kan worden gewijzigd zonder de proof-of-work opnieuw uit te voeren. De langste keten dient niet alleen dient als bewijs van de volgorde van de waargenomen gebeurtenissen, maar ook als bewijs dat deze afkomstig is van de grootste pool van CPU-vermogen. Zolang een meerderheid van het CPU-vermogen wordt beheerst door knooppunten die niet samenwerken om het netwerk, zullen zij de langste keten genereren en aanvallers voorblijven. Het netwerk zelf vereist een minimale structuur. Berichten worden op basis van ‘best effort’-basis, en knooppunten kunnen het netwerk naar believen verlaten en er weer toe treden, waarbij ze de langste proof-of-work-keten accepteren als bewijs van wat er terwijl ze weg waren.
Inleiding
De handel op het internet is inmiddels bijna uitsluitend afhankelijk geworden van financiële instellingen die als vertrouwde derde partij fungeren voor het verwerken van elektronische betalingen te verwerken. Hoewel het systeem voor de meeste transacties, kampt het nog steeds met de inherente zwakheden van het op vertrouwen. Volledig onomkeerbare transacties zijn niet echt mogelijk, aangezien financiële instellingen niet kunnen vermijden om bij geschillen te bemiddelen. De kosten van bemiddeling verhogen de transactiekosten, waardoor de minimale praktische transactieomvang en de mogelijkheid voor kleine incidentele transacties, en er is een bredere kostenpost in het verlies van de mogelijkheid om onomkeerbare betalingen te verrichten voor onomkeerbare diensten. Met de mogelijkheid tot terugboeking neemt de behoefte aan vertrouwen toe. Handelaren moeten op hun hoede zijn voor hun klanten en hen lastigvallen met meer informatie dan ze anders nodig zouden hebben. Een bepaald percentage fraude wordt als onvermijdelijk. Deze kosten en onzekerheden bij betalingen kunnen worden vermeden door contant geld te gebruiken, maar er bestaat geen mechanisme om betalingen via een communicatiekanaal te verrichten zonder een vertrouwde partij
Wat nodig is, is een elektronisch betalingssysteem dat is gebaseerd op cryptografische bewijs in plaats van vertrouwen, waardoor twee bereidwillige partijen rechtstreeks met elkaar te handelen zonder dat daarvoor een vertrouwde derde partij nodig is. Transacties die computationeel onpraktisch zijn om ongedaan te maken, zouden zouden verkopers tegen fraude beschermen, en er zouden eenvoudig routinematige escrow-mechanismen worden geïmplementeerd om kopers te beschermen. In dit artikel stellen we een oplossing voor voor het probleem van dubbele besteding met behulp van een peer-to-peer gedistribueerde tijdstempelserver om een computationeel bewijs te genereren van de chronologische volgorde van transacties. Het systeem is veilig zolang eerlijke knooppunten gezamenlijk over meer CPU-vermogen beschikken dan welke samenwerkende groep knooppunten van aanvallers.
Transacties
We definiëren een elektronische munt als een keten van digitale handtekeningen. Elke eigenaar draagt de munt over aan de volgende door een hash van de vorige transactie en de openbare sleutel van de volgende eigenaar, en deze deze aan het einde van de munt toe te voegen. Een begunstigde kan de handtekeningen verifiëren om de eigendomsketen te verifiëren.
Het probleem is natuurlijk dat de begunstigde niet kan controleren of een van de eigenaren de munt niet dubbel heeft uitgegeven. Een veelgebruikte oplossing is het invoeren van een vertrouwde centrale autoriteit, of munt, in te schakelen die elke transactie controleert op dubbele besteding controleert. Na elke transactie moet de munt worden teruggegeven aan de munt om een nieuwe munt uit te geven, en alleen munten die rechtstreeks door de munt worden vertrouwd en worden niet dubbel uitgegeven. Het probleem met deze oplossing is dat het lot van het gehele geldsysteem afhangt van het bedrijf dat de muntfabriek beheert, waarbij elke transactie via hen moet verlopen, net net als bij een bank.
We hebben een manier nodig waarop de begunstigde kan weten dat de vorige eigenaren eerdere transacties hebben ondertekend. Voor onze doeleinden is de vroegste transactie die telt, dus latere pogingen tot dubbele besteding. De enige manier om de afwezigheid van een transactie is, is door op de hoogte te zijn van alle transacties. In het op de munt gebaseerde model was de munt op de hoogte van alle transacties en besloot welke het eerst was aangekomen. Om dit zonder een vertrouwde partij te realiseren, moeten transacties openbaar worden aangekondigd[^1], en we hebben een systeem nodig waarmee deelnemers overeenstemming kunnen bereiken over één enkele chronologie van de volgorde waarin ze zijn ontvangen. De begunstigde heeft bewijs nodig dat op het moment van elke transactie de meerderheid van de knooppunten ermee instemde dat deze als eerste was ontvangen.
Tijdstempelserver
De oplossing die wij voorstellen begint met een tijdstempelserver. Een tijdstempelserver werkt door een hash te genereren van een blok met items waaraan een tijdstempel moet worden toegevoegd en de hash op grote schaal publiceert, bijvoorbeeld in een krant of een Usenet- [^2][^3][^4][^5]. De tijdstempel bewijst dat de gegevens op dat moment hebben bestaan, uiteraard, om in de hash terecht te komen. Elke tijdstempel bevat het vorige tijdstempel in zijn hash, waardoor een keten ontstaat, waarbij elke nieuwe tijdstempel de voorgaande versterkt.
Proof-of-Work
Om een gedistribueerde tijdstempelserver op peer-to-peer-basis te implementeren, moeten we een proof-of-work-systeem gebruiken dat vergelijkbaar is met Adam Back’s Hashcash [^6], in plaats van krantenartikelen of Usenet-berichten. De proof-of-work houdt in het zoeken naar een waarde die, wanneer deze wordt gehasht, bijvoorbeeld met SHA-256, een hash oplevert met een aantal nulbits begint. De gemiddelde benodigde inspanning is exponentieel met het aantal vereiste nulbits en kan worden geverifieerd door het uitvoeren van één enkele hash.
Voor ons tijdstempelnetwerk implementeren we de proof-of-work door een nonce in het blok te verhogen totdat er een waarde wordt gevonden die de hash van het blok de vereiste nulbits oplevert. Zodra de CPU-inspanning is ingezet om aan de proof-of-work te voldoen, kan het blok niet gewijzigd zonder het werk opnieuw te doen. Aangezien er latere blokken aan worden gekoppeld, zou het werk om het blok te wijzigen inhouden dat alle blokken erna daarop
De proof-of-work lost ook het probleem op van het bepalen van de vertegenwoordiging bij besluitvorming door de meerderheid. Als de meerderheid gebaseerd zou zijn op ‘één IP-adres, één stem’, zou dit kunnen worden ondermijnd door iedereen die veel IP-adressen kan toewijzen. Proof-of-work komt in wezen neer op ‘één CPU, één stem’. De meerderheidsbesluit wordt vertegenwoordigd door de langste keten, waarin de meeste proof-of-work-inspanning heeft gekost. Als een meerderheid van de CPU-kracht in handen is van eerlijke knooppunten, zal de eerlijke keten het snelst groeien en zal alle concurrerende ketens achter zich laten. Om een eerder blok te wijzigen, zou een aanvaller zou de proof-of-work van dat blok en alle daaropvolgende blokken en vervolgens het werk van de eerlijke knooppunten inhalen en overtreffen. We zullen later laten zien dat de kans dat een langzamere aanvaller zijn achterstand inhaalt exponentieel afneemt naarmate er nieuwe blokken worden toegevoegd.
Om rekening te houden met de toenemende hardwaresnelheid en de wisselende belangstelling voor het draaien van knooppunten in de loop van de tijd, wordt de moeilijkheidsgraad van de proof-of-work bepaald door een voortschrijdend gemiddelde dat is afgestemd op een gemiddeld aantal blokken per uur. Als ze te snel worden gegenereerd, neemt de moeilijkheidsgraad toe.
Netwerk
De stappen om het netwerk te laten draaien zijn als volgt:
Nieuwe transacties worden naar alle knooppunten verzonden.
Elk knooppunt verzamelt nieuwe transacties in een blok.
Elk knooppunt probeert een moeilijk proof-of-work voor zijn blok te vinden.
Wanneer een knooppunt een proof-of-work vindt, verzendt het het blok naar alle knooppunten.
Knooppunten accepteren het blok alleen als alle transacties daarin geldig zijn en nog niet zijn uitgegeven.
Knooppunten geven aan dat ze het blok accepteren door te werken aan het creëren van het volgende blok in de keten, waarbij de hash van het geaccepteerde blok als de vorige hash.
Knooppunten beschouwen altijd de langste keten als de juiste en blijven werken aan het uitbreiden ervan. Als twee knooppunten tegelijkertijd verschillende versies van het volgende blok uitzenden, kunnen sommige knooppunten de ene of de andere. In dat geval werken ze aan de eerste die ze hebben ontvangen, maar slaan ze de andere tak op voor het geval deze langer wordt. De onbesliste situatie wordt opgelost wanneer het volgende proof-of-work wordt gevonden en één tak langer wordt; de knooppunten die aan de andere tak werkten, schakelen dan over naar de langere tak.
Nieuwe transactie-uitzendingen hoeven niet per se alle knooppunten te bereiken. Zolang ze maar veel knooppunten bereiken, zullen ze in een blok terechtkomen voordat . Het verzenden van blokken is ook tolerant ten opzichte van verloren gegane berichten. Als een knooppunt een blok niet ontvangt, zal het dit opvragen wanneer het het volgende blok ontvangt en beseft dat het er een heeft gemist.
Stimulans
Volgens afspraak is de eerste transactie in een blok een speciale transactie die een nieuwe munt in het leven roept die eigendom is van de maker van het blok. Dit vormt een stimulans voor knooppunten om het netwerk te ondersteunen, en biedt een manier om munten in eerste instantie in omloop te brengen, aangezien er geen centrale instantie is die ze uitgeeft. De gestage toevoeging van een constante hoeveelheid nieuwe munten is vergelijkbaar met goudzoekers die middelen inzetten om goud in omloop te brengen. In ons geval zijn het CPU-tijd en elektriciteit die worden besteed.
De stimulans kan ook worden gefinancierd met transactiekosten. Als de waarde van een transactie lager is dan de invoerwaarde, vormt het verschil een transactiekost die wordt toegevoegd aan de stimuleringswaarde van het blok waarin de transactie is opgenomen. Zodra een vooraf bepaald aantal munten in omloop zijn gebracht, kan de beloning volledig overgaan op transactiekosten en volledig inflatievrij zijn.
De beloning kan helpen om knooppunten aan te moedigen eerlijk te blijven. Als een hebzuchtige aanvaller erin slaagt meer CPU-vermogen te verzamelen dan alle eerlijke nodes, zou hij moeten kiezen tussen het gebruiken ervan om mensen op te lichten door zijn betalingen terug te stelen, of deze te gebruiken om nieuwe munten te genereren. Hij zou moeten ontdekken het winstgevender vinden om zich aan de regels te houden, regels die hem bevoordelen met meer nieuwe munten opleveren dan alle anderen samen, dan het systeem en de geldigheid van zijn eigen vermogen te ondermijnen.
Schijfruimte vrijmaken
Zodra de meest recente transactie van een munt onder voldoende blokken is begraven, eerdere transacties kunnen worden verwijderd om schijfruimte te besparen. Om dit mogelijk te maken zonder de hash van het blok te verstoren, worden transacties gehashed in een Merkle-boom[^7][^8][^9], waarbij alleen de root wordt opgenomen in de hash van het blok wordt opgenomen. Oude blokken kunnen vervolgens worden gecomprimeerd door takken van de boom af te snijden. De interne hashes hoeven niet te worden opgeslagen.
Een blokheader zonder transacties zou ongeveer 80 bytes groot zijn. Als we ervan uitgaan dat er elke 10 minuten blokken worden gegenereerd, dan is 80 bytes * 6 * 24 * 365 = 4,2 MB per jaar. Aangezien computersystemen in 2008 doorgaans werden verkocht met 2 GB RAM (stand van zaken in 2008), en gezien de voorspelling van de wet van Moore dat de huidige groei 1,2 GB per jaar voorspelt, zou opslag geen probleem moeten zijn, zelfs als de blokheaders in het geheugen moeten worden bewaard.
Vereenvoudigde betalingsverificatie
Het is mogelijk om betalingen te verifiëren zonder een volledige netwerknode te draaien. Een gebruiker hoeft alleen een kopie bij te houden van de blokheaders van de langste proof-of-work-keten, die hij kan verkrijgen door netwerkknooppunten te raadplegen totdat hij ervan overtuigd is dat hij de langste keten heeft, en de Merkle-tak verkrijgt die de transactie koppelt aan het blok waarin deze is getimed. Hij kan de transactie zelf controleren, maar door deze te koppelen aan een plek in de keten, kan hij zien dat een netwerkknooppunt deze heeft geaccepteerd, en dat blokken die daarna zijn toegevoegd, bevestigen bovendien dat het netwerk deze heeft geaccepteerd.
De verificatie is dus betrouwbaar zolang eerlijke knooppunten het netwerk beheersen, maar is kwetsbaarder als het netwerk wordt overmeesterd door een aanvaller wordt overgenomen. Hoewel netwerkknooppunten transacties zelf kunnen verifiëren, kan de vereenvoudigde methode worden misleid door verzonnen transacties worden misleid, zolang de aanvaller het netwerk blijft domineren. Een strategie om hiertegen bescherming te bieden, zou zijn om waarschuwingen van netwerkknooppunten te accepteren wanneer deze een ongeldig blok detecteren, waardoor de de software van de gebruiker ertoe aanzet het volledige blok en de gemelde transacties te downloaden om de inconsistentie te bevestigen. Bedrijven die regelmatig betalingen ontvangen zullen waarschijnlijk toch hun eigen knooppunten willen draaien voor meer onafhankelijke beveiliging en snellere verificatie.
Waarde combineren en splitsen
Hoewel het mogelijk zou zijn om munten afzonderlijk te verwerken, zou het onpraktisch om voor elke cent in een overboeking een aparte transactie te maken. Om waarde te kunnen splitsen en combineren, bevatten transacties meerdere inputs en outputs. Normaal gesproken is er ofwel één input afkomstig van een eerdere, grotere transactie of meerdere inputs die kleinere bedragen, en maximaal twee outputs: één voor de betaling en één die eventueel wisselgeld terugstort naar de afzender.
Opgemerkt moet worden dat „fan-out“, waarbij een transactie afhankelijk is van meerdere transacties, en die transacties weer van nog veel meer, hier geen probleem vormt. Het is nooit nodig om een volledige, op zichzelf staande kopie van de transactiegeschiedenis te extraheren.
Privacy
Het traditionele bankmodel waarborgt een zekere mate van privacy door de toegang tot informatie tot de betrokken partijen en de vertrouwde derde partij. De noodzaak om alle transacties openbaar te maken, sluit deze methode uit, maar privacy kan nog steeds worden gewaarborgd door de informatiestroom op een andere plaats te onderbreken: door openbare sleutels anoniem te houden. Het publiek kan zien dat iemand een bedrag naar iemand anders stuurt, maar zonder informatie die de transactie aan iemand koppelt. Dit is vergelijkbaar aan het niveau van informatie dat door effectenbeurzen wordt vrijgegeven, waar het tijdstip en omvang van individuele transacties, de “tape”, openbaar worden gemaakt, maar zonder dat wordt vermeld wie de partijen waren.
Als extra beveiliging moet voor elke transactie een nieuw sleutelpaar worden gebruikt transactie, om te voorkomen dat ze aan een gemeenschappelijke eigenaar kunnen worden gekoppeld. Een zekere mate koppeling is nog steeds onvermijdelijk bij transacties met meerdere inputs, die noodzakelijkerwijs onthullen dat de inputs eigendom waren van dezelfde eigenaar. Het risico is dat, als de eigenaar van een sleutel bekend wordt, deze koppeling ook andere transacties aan het licht kunnen brengen die aan dezelfde eigenaar toebehoorden.
Berekeningen
We beschouwen het scenario waarin een aanvaller probeert een alternatieve ketting te genereren die sneller is dan de eerlijke ketting. Zelfs als dit lukt, wordt het systeem hierdoor niet blootgesteld aan willekeurige wijzigingen, zoals het creëren van waarde uit het niets te creëren of geld weg te halen dat nooit aan de aanvaller. Knooppunten zullen een ongeldige transactie niet als betaling, en eerlijke knooppunten zullen nooit een blok accepteren waarin deze zijn opgenomen. Een aanvaller kan alleen proberen een van zijn eigen transacties te wijzigen om geld terug te krijgen dat hij onlangs heeft uitgegeven.
De wedloop tussen de eerlijke keten en de keten van een aanvaller kan worden gekenmerkt als een binomiale willekeurige wandeling. Het succes is dat de eerlijke keten met één blok wordt verlengd, waardoor de voorsprong met +1 toeneemt, en de mislukking is dat de keten van de aanvaller met één blok wordt verlengd, waardoor de achterstand met -1 afneemt.
De kans dat een aanvaller een bepaalde achterstand inhaalt, is vergelijkbaar met het ‘Gambler’s Ruin’-probleem. Stel dat een gokker met onbeperkt krediet met een achterstand begint en mogelijk een oneindig aantal pogingen om het break-evenpunt te bereiken. We kunnen de kans berekenen dat hij ooit het break-evenpunt bereikt, of dat een aanvaller ooit de eerlijke keten, als volgt[^10]:
| p = kans dat een eerlijk knooppunt het volgende blok vindt | q = kans dat de aanvaller het volgende blok vindt | qz = kans dat de aanvaller ooit zijn achterstand van z blokken inhaalt
$$begin{aligned} q_z = begin{cases} 1 & text{als } p leqslant q left(q/pright)^z & text{als } p > q end{cases} end{aligned}$$
Gezien onze aanname dat $p > q$, neemt de kans exponentieel af naarmate het aantal blokken waarmee de aanvaller een achterstand moet inhalen, toeneemt. Met de kansen tegen hem, worden zijn kansen, als hij niet al vroeg een gelukkige sprong naar voren maakt , worden zijn kansen verwaarloosbaar klein naarmate hij verder achterop raakt.
We bekijken nu hoe lang de ontvanger van een nieuwe transactie moet moet wachten voordat hij voldoende zeker is dat de afzender de transactie kan wijzigen. We gaan ervan uit dat de afzender een aanvaller is die de ontvanger een tijdje wil laten geloven dat hij hem heeft betaald, om vervolgens de betaling na zichzelf terug te betalen. De ontvanger zal worden gewaarschuwd wanneer dat gebeurt, maar de afzender hoopt dat het dan al te laat is
De ontvanger genereert een nieuw sleutelpaar en geeft de openbare sleutel aan de afzender kort voordat hij ondertekent. Dit voorkomt dat de afzender van tevoren een blokketen van tevoren kan voorbereiden door er continu aan te werken totdat hij het geluk heeft ver genoeg vooruit te zijn, om vervolgens de transactie op dat moment uit te voeren. Zodra de transactie is verzonden, begint de oneerlijke afzender in het geheim te werken aan een parallelle keten die een alternatieve versie van zijn transactie bevat.
De ontvanger wacht tot de transactie aan een blok is toegevoegd en er z blokken achter zijn gekoppeld. Hij weet niet precies hoeveel vooruitgang die de aanvaller heeft geboekt, maar ervan uitgaande dat de eerlijke blokken de gemiddelde verwachte tijd per blok hebben gekost, zal de potentiële voortgang van de aanvaller een Poisson-verdeling met een verwachtingswaarde:
$$lambda = z frac{q}{p}$$
Om de kans te berekenen dat de aanvaller nu nog zou kunnen inhalen, vermenigvuldigen we de Poisson-dichtheid voor elke hoeveelheid vooruitgang die hij zou kunnen hebben de kans dat hij vanaf dat punt zijn achterstand zou kunnen inhalen:
$$begin{aligned} sum _{k=0}^infty frac{lambda ^k e^{-lambda}}{k!} cdot begin{cases} left(q/pright)^{(z-p)} & text{als } k leqslant z 1 & text{als } k > z end{cases} end{aligned}$$
Herschikken om te voorkomen dat de oneindige staart van de verdeling moet worden opgeteld…
$$1 – sum _{k=0}^z frac{lambda ^k e^{-lambda}}{k!} left(1 – left(q/pright)^{(z-k)}right)$$
Omzetten naar C-code…
#include <math.h>
double AttackerSuccessProbability(double q, int z)
{
double p = 1.0 - q;
double lambda = z * (q / p);
double sum = 1.0;
int i, k;
for (k = 0; k <= z; k++)
{
double poisson = exp(-lambda);
for (i = 1; i <= k; i++)
poisson *= lambda / i;
sum -= poisson * (1 - pow(q / p, z - k));
}
return sum;
}
Als we enkele berekeningen uitvoeren, zien we dat de kans exponentieel afneemt met z.
We hebben een systeem voorgesteld voor elektronische transacties zonder gebruik te maken van vertrouwen. We zijn uitgegaan van het gebruikelijke raamwerk van munten op basis van digitale handtekeningen, dat een sterke controle op eigendom biedt, maar onvolledig is zonder een manier om dubbele uitgaven te voorkomen. Om dit op te lossen, hebben we hebben we een peer-to-peer-netwerk voorgesteld dat gebruikmaakt van proof-of-work om een openbare transactiegeschiedenis vast te leggen, die rekenkundig al snel onhaalbaar wordt voor een aanvaller om te wijzigen als eerlijke knooppunten de meerderheid van de CPU-kracht vermogen in handen hebben. Het netwerk is robuust in zijn ongestructureerde eenvoud. Knooppunten werken allemaal tegelijk, met weinig onderlinge afstemming. Ze hoeven niet geïdentificeerd te worden, aangezien berichten niet naar een bepaalde bestemming worden gerouteerd en alleen op basis van ‘best effort’ worden afgeleverd. Knooppunten kunnen het netwerk naar believen verlaten en zich weer aansluiten, waarbij ze de proof-of-work-keten accepteren als bewijs van wat er is gebeurd terwijl ze weg waren. Ze stemmen met hun CPU-vermogen, waarbij ze hun aanvaarding van geldige blokken tot uitdrukking brengen door deze verder uit te breiden en ongeldige blokken af te wijzen door te weigeren eraan te werken. Alle benodigde regels en prikkels kunnen met dit consensusmechanisme worden afgedwongen.
[^2]: H. Massias, X.S. Avila en J.-J. Quisquater, “Design of a veilige tijdstempeldienst met minimale vertrouwensvereisten,” In het 20e Symposium over Informatietheorie in de Benelux, mei 1999.
[^3]: S. Haber, W.S. Stornetta, “How to time-stamp a digital document van een tijdstempel voorzien”, in Journal of Cryptology, deel 3, nr. 2, pagina’s 99-111, 1991.
[^4]: D. Bayer, S. Haber, W.S. Stornetta, “Improving the efficiency en betrouwbaarheid van digitale tijdstempels”, in *Sequences II: Methods in Communication, Security and Computer Science, blz. 329-334, 1993.
[^5]: S. Haber, W.S. Stornetta, “Veilige namen voor bitstrings,” in Proceedings of the 4th ACM Conference on Computer and Communications Security, pagina’s 28-35, april 1997.
[^7]: R.C. Merkle, “Protocollen voor cryptosystemen met openbare sleutels,” in Proc. Symposium over beveiliging en privacy van 1980, IEEE Computer Society, pagina’s 122-133, april 1980.
[^8]: H. Massias, X.S. Avila en J.-J. Quisquater, “Ontwerp van een veilige tijdstempeldienst met minimale vertrouwensvereisten,” in 20e Symposium over Informatietheorie in de Benelux, mei 1999.
[^9]: S. Haber, W.S. Stornetta, „Veilige namen voor bitstrings”, in de verslagen van de 4e ACM-conferentie over Computer and Communicatiebeveiliging, pagina’s 28-35, april 1997.
[^10]: W. Feller, “Een inleiding tot de kansrekening en de toepassingen”, 1957.
