A Base két leállását egy sequencerben lévő hiba okozta

A Base egyetlen sequencerrel működik, ezért a hiba teljesen megakasztotta a blokkgyártást 116, majd 20 percre.

Röviden:

• A Base mérnökei szombaton a blokképítési logikában találtak hibásan megmaradó journal state-et.
• Csütörtökön 116 percre, pénteken 20 percre állt le az új layer-2 blokkok gyártása.
• A sequencerekre telepített patch után infrastruktúraproblémák és race condition lassították a helyreállást.
• Az L2beat adatai szerint a Base közel 11 milliárd dollárnyi értékkel a második legnagyobb layer-2.

Egy hibás tranzakció után akadt meg a blokkgyártás

A Base leállás közvetlen kiváltó oka egy érvénytelen tranzakció volt, amelynél a blokképítő ugyan hibát jelzett a végrehajtás során, de nem takarította ki megfelelően az addig felhalmozott belső állapotot.

A Base mérnöki csapata úgy írta le a hibát, hogy a tranzakció által érintett számlák és tárhelyhelyek adatai benne maradtak a naplózott állapotban. Emiatt a rendszer egy hibás blokk környékén elakadt, és az új layer-2 blokkok gyártása nem tudott folytatódni.

A gyakorlatban ez nem lassulást, hanem teljes megállást jelentett. A sequencer és a validator node-ok sem tudtak továbblépni az érvénytelen blokkon, amíg a sorrendezés helyre nem állt.

Mit mutat a Base leállás az egy sequenceres működésről?

Az egy sequenceres felépítés miatt a Base esetében egyetlen hiba is elég volt ahhoz, hogy a teljes blokkgyártás megálljon. A sequencer dönti el, milyen sorrendben kerülnek be a tranzakciók, vagyis ha ez az elem elakad, a lánc többi része sem tud normálisan haladni.

Ez a működés nemcsak a Base sajátossága. Hasonló sequencerhez kötődő leállások korábban más layer-2 hálózatoknál is előfordultak, köztük az Arbitrum, az OP Mainnet és a zkSync Era esetében.

A tét azért nagyobb, mert a Base az L2beat adatai alapján a második legnagyobb layer-2 hálózat, közel 11 milliárd dollárnyi biztosított értékkel. Egy ilyen infrastruktúránál a rövidebb kiesések is sok alkalmazást és felhasználót érinthetnek.

A patch nem oldotta meg azonnal a helyreállítás gondjait

A Base mérnökei a sequencerek javításával kezelték az eredeti hibát, hogy a végrehajtás közben a naplózott állapot megfelelően frissüljön. Ez azonban nem jelentette azt, hogy a hálózat azonnal visszaállt volna a megszokott működésre.

A helyreállítás a csapat beszámolója alapján tovább tartott a vártnál, mert közben olyan infrastruktúraproblémák is jelentkeztek, amelyek nem az eredeti hibából fakadtak. Ezek lassították a beavatkozást, miközben a főhálózat továbbra sem tudott új blokkokat gyártani.

A második kieséshez a rendszer újraindítása után kialakuló race condition vezetett. Ez megakadályozta, hogy a sequencerek utolérjék a hálózat állapotát, így a pénteki incidens már egy újabb, rövidebb leállásként jelent meg.

A korábbi hibák után több tesztet és jobb újraindítást terveznek

A Base csapata a következő lépésként több protokollszintű fuzz testinget tervez. Ez olyan tesztelési módszer, amely nagy mennyiségű véletlen, hibás vagy váratlan bemenettel próbálja előhozni azokat a hibákat, amelyek normál tesztelésnél rejtve maradhatnak.

A másik tervezett irány a kíméletesebb helyreállítási folyamat. A cél az, hogy egy hasonló incidensnél a validator node-oknak ne kelljen kézi újraindításra várniuk, hanem a rendszer nagyobb részben magától tudjon visszarendeződni.

A háttérben az is ott van, hogy a mostani nem az első ilyen eset volt a Base történetében. A hálózat 2024 szeptemberében 17 percre, 2025 augusztusában pedig nagyjából fél órára állt le sequencerhez kapcsolódó probléma miatt.

Hogyan értelmezzük ezt a hírt?

Mi úgy látjuk, a Base két leállása nem azt mutatja, hogy a hálózat használhatatlan lenne, hanem azt, hogy egy közel 11 milliárd dollárnyi értéket biztosító layer-2 esetében már kevés az „elég jól működik” szintű infrastruktúra. A 116 perces, majd 20 perces blokkgyártási szünet különösen azért fontos jelzés, mert nem egy perifériás elem hibázott, hanem az egy sequenceres működés szűk keresztmetszete vált láthatóvá.

A Base csapata gyorsan azonosította a hibát, patch-et telepített, és a fuzz testing, valamint a kíméletesebb helyreállítás irányába lépne tovább. Ez jó irány, de szerintünk a tanulság egyértelmű: a layer-2 hálózatok következő nagy versenye nemcsak a díjakról és a sebességről szól majd, hanem arról is, mennyire bírják a váratlan hibákat központi megállási pont nélkül. Egy ekkora hálózatnál az üzemeltetési megbízhatóság már nem háttértechnikai részlet, hanem a bizalom egyik alapja.

Mit érdemes még tudni?

Mi az a sequencer egy layer-2 hálózatban?

A sequencer az a komponens, amely összegyűjti és sorrendbe rendezi a layer-2 tranzakciókat, mielőtt azok blokkba kerülnek. Ha egy hálózat egyetlen sequencerre támaszkodik, annak hibája az egész blokkgyártást megakaszthatja.

Mit jelent a journal state?

A journal state a végrehajtás közben naplózott ideiglenes állapot, amely rögzíti, milyen számlákhoz és tárhelyhelyekhez nyúlt hozzá egy tranzakció. Ha egy hibás tranzakció után ez nem törlődik vagy frissül megfelelően, a rendszer rossz állapotból próbálhat tovább dolgozni.

Mi az a fuzz testing?

A fuzz testing olyan tesztelési módszer, amely véletlen, hibás vagy szokatlan bemenetek nagy tömegével próbál rejtett hibákat előhozni. Blokklánc-protokolloknál azért hasznos, mert olyan szélsőséges helyzeteket is szimulálhat, amelyek normál teszteknél nem derülnének ki.

Mit jelent a race condition?

A race condition olyan szoftverhiba, amikor több folyamat időzítése vagy sorrendje miatt a rendszer kiszámíthatatlan állapotba kerülhet. Ez különösen elosztott rendszereknél veszélyes, mert ugyanazok az elemek más-más pillanatban eltérő állapotot láthatnak.

Kapcsolódó hírek

• Decrypt – Coinbase-Backed Ethereum Network Base Recovers After Block Production Issue
• The Block – Base suffers second mainnet stall in two days
• CoinDesk – Coinbase and OKX try to lure in Binance’s EU users after it failed to secure a MiCA license