Artikkeli
Rollupin datan saatavuus: miksi pelkkä tilatiiviste ei riitä?
Saatavuus ja soveltuvuus on varmistettava erikseen.
Avoimet rajat: OP-kuvaus perustuu dokumentaatioon: elävää verkkoa, versioita, asetuksia tai tapahtumia ei ole testattu; saatavuus ja erillissivun tarve ovat avoinna.
Lähteet luettu 28.10.2026. Teksti selittää toimintamalleja, eikä ole ohje varojen siirtämiseen.
Jos rollup ilmoittaa Ethereumille vain uuden tilan tiivisteen, tiiviste ei yksin kerro tarkistajalle, miten tila syntyi. Datan saatavuudessa kysytään, onko tarkistamiseen tarvittava data ollut osallistujien saatavilla. Se on eri kysymys kuin se, löytyykö sama historia vielä vuosien päästä arkistosta.2
Kun vertailet verkkojen turvallisuuskuvauksia, kysy, mistä riippumaton tarkistaja saa tiedot ja mihin toimijaan hän joutuu luottamaan. Pelkkä lause ”Ethereum turvaa verkon” ei vastaa tähän. Tiivisteen näkeminen ei todista, että tarvittava data on kenenkään saatavilla.
Erota kolme asiaa
Tiiviste tai sitoumus sitoo väitteen tiettyyn dataan tai tilaan, mutta ei anna sisältöä nähtäväksi.
Saatavuus koskee sitä, onko tarvittava data ollut käytettävissä tarkistusta varten. Se ei itsessään lupaa, että vanha data on noudettavissa ikuisesti.2
Kelpoisuus on eri kysymys: onko tilamuutos sääntöjen mukainen? Saatavilla oleva data mahdollistaa tarkistusta, mutta ei yksin todista tilan tai muutoksen oikeellisuutta. Hyödyllinen rekonstruktio voi järjestelmästä riippuen vaatia tapahtuma- tai tilapäivitysdatan lisäksi oikean lähtötilan, järjestyksen ja sovellettavat säännöt.2, 3, 4
Ajattele kirjanpitoa: loppusumman tiiviste voi sitoa esittäjän tulokseen, mutta ulkopuolinen ei voi itse laskea sitä uudelleen ilman tarvittavia kirjauksia ja lähtötietoja. Vertaus ei kuvaa yksittäisen verkon tarkkaa tietorakennetta.
Miksi todistusmalli vaikuttaa seuraukseen?
Optimistisessa mallissa tarkistajan pitää voida havaita virheellinen tilaväite ja osallistua sen haastamiseen. Datan saatavuuden lisäksi riitautuksen suoja riippuu muun muassa valppaasta ja käytännössä kykenevästä haastajasta, riittävästä toimintaikkunasta, haastajan transaktioiden pääsystä L1:een sekä riitasääntöjen ja sopimusten toiminnasta. Saatavilla oleva data ei yksin takaa, että virheellinen väite todella haastetaan ajoissa.3, 6
Kelpoisuustodistus puolestaan osoittaa määritellyn julkisen väitteen toteutettujen sääntöjen suhteen, olettaen muun muassa todistusjärjestelmän, verifierin ja sopimusten toimivan tarkoitetusti. Todistus ei itsessään toimita poisjätettyä dataa eikä takaa käyttäjän noston käytännön onnistumista. Sen kattavuus on tarkistettava kyseisestä järjestelmästä.2, 4, 9
Konkreettinen esimerkki: OP Stackin Ethereum-DA
OP:n dokumentaatio kuvaa standardikokoonpanon, jossa batcher julkaisee L2-dataa Ethereumiin blob-datana tai calldatana. Unsafe-lohko voi näkyä sekvensseriltä ennen kuin se on johdettu L1:stä. Safe-pää tarkoittaa, että siihen asti ulottuva L2-historia on johdettavissa kulloisestakin kanonisesta L1-ketjusta; oikeat solmut tarkistavat erät ja hylkäävät virheelliset. Pelkkä mielivaltaisten tavujen julkaisu ei siis automaattisesti tee tietystä tapahtumasta safe-tilassa olevaa.11, 13
Kun kelvollinen L2-lohko on johdettu kanoniseen Ethereum-ketjuun sisältyvästä tarvittavasta datasta, se voi kuulua safe-historiaan. L1:n uudelleenjärjestely voi muuttaa safe-päätä. Finalized-päähän asti ulottuva L2-historia on sen sijaan johdettavissa Ethereum-ketjun finalisoidusta osasta, protokollan ja L1-finaliteetin oletuksin.13
Nämä tilat kuvaavat L2-ketjua ja sen johtamista, eivät samaa asiaa kuin L1-noston käsittely. OP:n arkkitehtuurin mukaan fault-proof-järjestelmä ratkaisee, hyväksytäänkö L2-tilaa koskeva väite L1:ssä; hävinneen väitteen poistaminen ei itsessään järjestä L2-ketjua uudelleen. Standard Bridgen nostoviive on erillinen L2-tapahtuman finaliteetista. Älä päättele tästä, että jokaisen muun rollupin riitamekanismi toimisi samoin.6, 11
Tämä on dokumentoitu toimintamalli, ei reaaliaikainen mittaus tai lupaus juuri sinun tapahtumasi tilasta. Eri OP Stack -ketjujen asetuksia ei voi päätellä toisistaan. OP:n Alt-DA-dokumentaatio kuvaa vaihtoehtoista saatavuuskerrosta kokeellisena ominaisuutena, johon liittyy lisäluottamusoletuksia; se ei itsessään kerro jonkin ketjun tämänhetkistä konfiguraatiota.6, 12
Ethereum-blob ei tarkoita ikuista arkistointia. EIP-4844 kuvaa vähimmäissäilytysvaatimuksen, ei lupausta ikuisesta saatavuudesta tai datan katoamisesta täsmälleen tietyn ajan kuluttua. Kysy erikseen, kuka säilyttää vanhaa dataa ja mistä sen saa myöhemmin.7, 2
Entä jos data on muualla?
Ethereum.org erottaa onchain-dataan tukeutuvan ZK-rollupin validiumista, jossa kelpoisuustodistuksen rinnalla dataa pidetään Ethereum-pääverkon ulkopuolella. Käsitteiden käyttö vaihtelee, ja eri järjestelmien saatavuus- ja luottamusmallit pitää selvittää erikseen.4, 9
Joissakin malleissa komitea antaa saatavuutta koskevia todistuksia. Selvitä, ketkä osallistuvat, mitä heidän on tarkoitus säilyttää ja millä ehdoilla data toimitetaan. Komitean allekirjoitus ei ole sama asia kuin se, että jokainen käyttäjä olisi itse ladannut datan; se ei yksin kerro, toimiiko kyseisen järjestelmän poistumisreitti häiriössä.9
Mitä dokumentaatiosta kannattaa etsiä?
Kirjaa verkon tarkka nimi, käytössä olevat sopimusversiot ja dokumentaation päivämäärä. Selvitä erikseen datan julkaisupaikka, riippumattoman tarkistajan tarvitsemat tiedot ja säännöt, oikeus ja mahdollisuus riitauttaa, myöhempi arkistointi sekä käytössä oleva nosto- tai poistumisreitti. Pelkkä tilan kelpoisuustodistus ei vastaa historian noutamista koskevaan kysymykseen.2
Tarkistuslista ei korvaa käytännön testiä, ajantasaisten ketjuasetusten tarkistusta tai teknisen asiantuntijan arviota. Jos toteutusta on muutettu dokumentaation jälkeen, vanha kaavio voi kuvata eri järjestelmää kuin se, jota käytät.