MultiversX heeft de operaties op zijn mainnet opgeschort nadat een aanvaller probeerde een probleem met transaction atomicity in de virtual-machine-laag van het netwerk uit te buiten, waarbij ongeldige wijzigingen on-chain werden vastgelegd. Het team heeft de blockproductie offline gehaald, een patch in shadow fork-testing gezet en gezegd een gericht herstel te evalueren. Er is geen bevestigd verliesbedrag bekendgemaakt.

Wat MultiversX heeft bevestigd

• Het probleem hield verband met transaction atomicity.
• Ongeldige wijzigingen werden on-chain vastgelegd.
• De mainnet-operaties zijn opgeschort.
• Een patch is in shadow fork-testing gegaan.
• Een gericht herstel werd geëvalueerd.

Wat nog onbekend is

• Of gebruikers permanent fondsen hebben verloren.
• Welke accounts of contracten zijn getroffen.
• Hoe de aanvaller de storing veroorzaakte.
• Welke herstelmethode wordt gekozen.
• Wanneer alle diensten weer open zijn.

De stillegging bevroor het probleem – het maakte het niet ongedaan

In zijn incidentupdate zei MultiversX dat een aanvaller probeerde een atomicity-probleem in de virtual-machine-laag van het mainnet uit te buiten. Ontwikkelaars schortten de netwerkoperaties op terwijl ze de ontstane staatwijzigingen natracingen en een patch voorbereidden. Er was geen bevestigd verliesbedrag bekendgemaakt.

Het stoppen van de blockproductie voorkomt dat nieuwe transacties voortbouwen op gegevens die mogelijk al onjuist zijn. Het blokkeert ook een poging met dezelfde methode terwijl ingenieurs vaststellen welke saldi of contractitems zijn getroffen.

De pauze maakt de wijzigingen die het netwerk al heeft geaccepteerd niet ongedaan. Die gegevens blijven het startpunt dat door wallets, applicaties en bridges wordt gebruikt totdat MultiversX een herstelplan vaststelt.

Bij controle op 20 september classificeerde de statuspagina van MultiversX het systeem als gedeeltelijk verminderd. De openbare API, xPortal, Explorer, Wallet, Bridge, xExchange en xLaunchpad vertoonden verminderde prestaties, terwijl de gateway en de index als operationeel werden vermeld.

Die labels beschrijven individuele diensten en bevestigen niet dat de normale transactieverwerking is hervat. Het herstellen van de interfaces zou ook het onderliggende boekhoudprobleem niet oplossen. Om te begrijpen waarom, helpt het om bij transaction atomicity te beginnen.

Atomicity is de blockchain-versie van "alles of niets"

Een smart-contracttransactie kan verschillende samenhangende operaties bevatten. Eén saldo kan worden verlaagd, een andere verhoogd en een liquiditeitspool bijgewerkt. Atomische uitvoering vereist dat de volledige reeks slaagt voordat een van die wijzigingen permanent wordt.

Verwacht resultaat: elke vereiste stap slaagt en alle wijzigingen worden samen vastgelegd. Als een stap faalt, mag geen enkele wijziging van de transactie worden vastgelegd.

Atomicity-fout: één operatie faalt, maar een eerdere staatwijziging blijft bestaan. Het netwerk kan dan een gedeeltelijk resultaat vastleggen dat op zichzelf niet had mogen bestaan.

Dit is een vereenvoudigd voorbeeld van atomicity, geen reconstructie van het MultiversX-incident. Een kapotte transactie kan een accountsaldo, tokenvoorraad of contractrecord onverenigbaar laten met het beoogde resultaat. MultiversX heeft niet bekendgemaakt welk type gegevens is gewijzigd, dus er is niet genoeg bewijs om te zeggen dat de aanvaller tokens heeft gemaakt, een specifiek contract heeft leeggehaald of een bekend bedrag heeft gestolen.

Finaliteit bewijst overeenstemming, geen foutloze uitvoering

Blockchain-finaliteit betekent dat validators hebben overeengekomen welk blok en welke resulterende staat tot de canonieke chain behoren. Het bewijst niet dat de software die die staat berekende defectvrij was.

Validators voeren dezelfde protocolregels uit en vergelijken hun resultaten. Als die regels dezelfde fout bevatten op elke node, kunnen validators consistent overeenkomen over een uitkomst die het protocol nooit heeft bedoeld toe te staan. Consensus kan vaststellen welke staat het netwerk heeft geaccepteerd; het kan niet garanderen dat een softwarebug niet heeft geholpen die staat te produceren.

Het installeren van gecorrigeerde software voorkomt dat hetzelfde uitvoeringspadnieuw werkt, maar het bepaalt niet wat er moet gebeuren met de al vastgelegde wijzigingen. MultiversX moet de getroffen items identificeren en validators een reproduceerbare manier geven om te verifiëren dat niet-gerelateerde activiteit ongewijzigd blijft.

De shadow fork biedt een generale repetitie voordat het mainnet herstart

MultiversX heeft een patch voorbereid voor testing in een shadow fork-omgeving. Een shadow fork kopieert de relevante mainnet-geschiedenis en -staat naar een geïsoleerde omgeving, zodat ingenieurs echte netwerkomstandigheden kunnen reproduceren zonder te experimenteren met live saldi.

Het team kan de patch toepassen, de getroffen reeks opnieuw afspelen en een voorgesteld herstel testen voordat validators het op het mainnet installeren. Dat proces zou moeten vaststellen:

• Of nodes dezelfde herstelde staat berekenen.
• Of niet-getroffen saldi ongewijzigd blijven.
• Of applicaties de gecorrigeerde gegevens correct lezen.
• Of bridges en exchanges hun gegevens kunnen afstemmen.
• Of validators kunnen herstarten zonder concurrerende chains te produceren.

Het slagen voor die tests zou niet automatisch elke dienst heropenen. Implementatie vereist nog steeds coördinatie tussen validators, exchanges, bridges en de infrastructuurproviders die gebruikers en applicaties met MultiversX verbinden.

Gericht herstel zou het terugdraaien van de hele chain vermijden

MultiversX zei een gericht herstel te evalueren dat bedoeld is om de beëindigde transactiegeschiedenis en legitieme gebruikersgegevens te behouden, terwijl alleen de met het incident verband houdende wijzigingen worden aangepakt. Het project heeft niet uitgelegd hoe die correctie zou worden geïmplementeerd.

Gerichte staatcorrectie. Alleen saldi, contractopslag of andere met het incident verband houdende gegevens zouden worden hersteld, en niet-gerelateerde transacties kunnen in de beëindigde geschiedenis blijven. De belangrijkste moeilijkheid is bewijzen dat de correctie elke ongeldige wijziging omvat – en niets anders.

Brede chain-rollback. Het netwerk zou terugkeren naar een eerder blok en van daaruit herbouwen. Transacties die na dat punt zijn voltooid, kunnen verdwijnen, zelfs als ze geen verband hadden met het incident. De belangrijkste moeilijkheid is dat legitieme overboekingen en applicatie-activiteit mogelijk moeten worden herhaald of afgestemd.

De kosten van een bredere rollback waren zichtbaar na de Tectonic-exploit, toen Cronos-validators bijna 11.000 blokken verwijderden die bijna twee uur besloegen. De rollback maakte het grootste deel van de aan het incident gerelateerde leningen die nog op Cronos stonden genoteerd ongedaan, maarakte ook niet-gerelateerde transacties uit die periode ongedaan. De twee incidenten hebben verschillende oorzaken; het Cronos-voorbeeld is hier relevant omdat het de bijkomende kosten toont van het terugdraaien van een gedeeld grootboek.

MultiversX zegt een beperktere reparatie te overwegen, maar heeft nog niet laten zien hoe de getroffen gegevens zouden worden geïsoleerd. Een gerichte reparatie zou de oorspronkelijke blokken niet per se verwijderen: de transactiegeschiedenis kan zichtbaar blijven terwijl een gecoördineerde protocolwijziging de staat vaststelt die applicaties en validators na de herstart zullen erkennen. De methode kan pas goed worden beoordeeld wanneer MultiversX zijn herstelontwerp publiceert.

Wat MultiversX-gebruikers moeten doen tijdens de pauze

Voor gewone houders is de eenvoudigste instructie: wachten. MultiversX heeft gebruikers niet gevraagd tokens te migreren, wallets te verbinden met een herstelwebsite of een correctietransactie goed te keuren.

• Dien geen transacties in of zend ze niet opnieuw uit.
• Stort of neem geen EGLD of ESDT op via exchanges.
• Vermijd het verplaatsen van die activa via cross-chain bridges.
• Bewaar de transactiehash van alles wat vlak voor de stillegging is ingediend.
• Negeer herstellinks, migraties en ongevraagde supportberichten.
• Wacht tot zowel MultiversX als het betreffende platform de heropening bevestigt.

Een netwerkreparatie zou worden aangenomen door validators en infrastructuurbeheerders. Het zou niet vereisen dat gebruikers seed phrases onthullen of activa naar een nieuw adres sturen.

Wallets en explorers hebben mogelijk ook tijd nodig om te hersynchroniseren nadat de blockproductie is hervat. Een verouderd saldo of een ontbrekende recente transactie in een interface zou op zichzelf niet aantonen dat de onderliggende activa zijn veranderd.

Een herstart moet verifieerbaar zijn

Het herstarten van de blockproductie herstelt de beschikbaarheid, maar beantwoordt op zichzelf niet de finaliteitsvraag. MultiversX moet nog bekendmaken welke accounts of contracten zijn getroffen, hoe de herstelde staat is berekend en hoe validators onafhankelijk tot hetzelfde resultaat zijn gekomen.

Als dat aantoont dat alleen aan het incident gerelateerde wijzigingen zijn gecorrigeerd, kan een gericht herstel meer legitieme activiteit behouden dan een brede rollback. Zonder dat kan het netwerk hervatten terwijl gebruikers niet kunnen verifiëren waarom sommige beëindigde wijzigingen zijn gewijzigd en andere zijn behouden.

Dit artikel wordt uitsluitend ter informatie verstrekt en vormt geen financieel of beleggingsadvies. Netwerkomstandigheden en herstinstructies kunnen veranderen naarmate MultiversX verdere updates uitbrengt.