Lag 2: rask bekreftelse er ikke det samme som endelig oppgjør
Kartlegg transaksjonsaksept, datapublisering og fullføring av uttak gjennom et skaleringssystem.
Navngi trinnet du observerer
En rask bekreftelse i grensesnittet kan bety at en sekvenserer har akseptert en transaksjon, ikke at alle senere oppgjørsvilkår er oppfylt. Lag 2-systemer utfører arbeid utenfor grunnkjeden og bruker ytterligere mekanismer til å gjøre opp eller verifisere resultater. Ethereums skaleringsdokumentasjon skiller mellom optimistiske tilnærminger og tilnærminger basert på gyldighetsbevis. Arkitekturen avgjør hva en observatør trygt kan utlede på hvert trinn.
Bruk presise betegnelser i et analysenotat: sendt inn, akseptert av operatøren, inkludert i en gruppe, publisert på basiskjeden, verifisert eller ferdig med innsigelsesperioden, og tatt ut. Ikke alle systemer bruker akkurat disse trinnene, men å slå dem sammen til ett ord, bekreftet, skjuler operasjonelle forskjeller som betyr noe for børser og sikkerhetsforvaltere.
Forstå forskjellen i verifisering
Optimistiske rollups bygger på mekanismer for å bestride feilaktige tilstandspåstander innenfor et definert tidsvindu. Utforminger med gyldighetsbevis sender inn kryptografisk dokumentasjon for tilstandsoverganger, men datatilgjengelighet, oppgraderings- og driftsordninger må fortsatt undersøkes. Et bevissystem er én del av sikkerheten, ikke en generell garanti for enhver applikasjon eller bro bygget rundt det.
Den praktiske øvelsen er å spørre hva som ville skje hvis en operatør sendte inn et feil resultat, sluttet å behandle transaksjoner eller holdt tilbake en nødvendig tjeneste. Identifiser hvilke aktører som kan reagere, og hvilken informasjon de trenger. Svaret bør komme fra dokumentasjonen til det faktisk implementerte systemet, ikke fra en idealisert beskrivelse av den brede kategorien.
Skill oppgjørsforsinkelse fra uttakslikviditet
Et uttak gjennom protokollens egen mekanisme kan kreve venting på protokollvilkår. En tredjeparts likviditetstilbyder kan tilby midler tidligere mot et gebyr, og gir dermed en annen utgangsrute. Ruten endrer eksponeringen; den får ikke den underliggende protokollens oppgjørsvilkår til å forsvinne. Kapasiteten kan krympe under stress nettopp når mange brukere ønsker tidlig utgang.
Se for deg en forpliktelse som forfaller i morgen på grunnkjeden, og eiendeler der uttak gjennom systemets egen mekanisme tar flere dager i et hypotetisk system. Eiendelene kan være verdifulle, men utilgjengelige når de trengs. Et tilbud om rask uttreden er bare relevant dokumentasjon for beløpet og tidspunktet det faktisk gjelder. Det bør ikke antas å forbli tilgjengelig når hele markedet skynder seg ut.
Undersøk kontroller og infrastruktur
Konsentrasjon av sekvensører, oppgraderingsnøkler, beredskapsråd, innsending av bevis og publisering av data fortjener egne rader i en sammenligning. Et system kan ha sterke regler for transaksjonskontroll og samtidig være avhengig av sentraliserte driftstjenester. Et avbrudd kan påvirke tilgjengeligheten uten å endre eierskap, men manglende mulighet til å handle kan likevel gi økonomisk skade hvis posisjoner må justeres raskt.
Kontroller om tvungen inkludering eller alternative uttredelsesmekanismer finnes, hvem som kan bruke dem, og de praktiske forsinkelsene. En teoretisk tilgjengelig rømningsvei kan kreve gebyrer på basiskjeden, tekniske trinn og ventetider. I en ikke-teknisk analyseøvelse bør disse kravene dokumenteres i stedet for å anta at ordet tillatelsesfri betyr enkel eller umiddelbar tilgang.
Mål kostnaden gjennom hele livsløpet
Lave transaksjonsgebyrer kan være verdifulle, men en fullstendig sammenligning inkluderer innskudd, uttak, brooverføringer, likviditet på målnettverket og tiden midlene er utilgjengelige. En strategi med hyppige lokale transaksjoner og sjeldne uttak har en annen kostnadsprofil enn en som stadig flytter midler mellom nettverk. Den relevante enheten er hele arbeidsflyten, ikke én beleilig billig operasjon.
Lag en tidslinje for et normalt forløp og et forløp med driftsavbrudd. Noter hvilken saldo som kan brukes på hvert tidspunkt, og hvilke forutsetninger som ville forsinke neste trinn. Dette gjør analysen nyttig uten å forutsi hvilket skaleringssystem som vil lykkes. Teknisk gjennomstrømning, endelig oppgjør, likviditet og verdien av applikasjonstokener er separate temaer og bør ikke fremstilles som om forbedring av ett automatisk forbedrer alle de andre.
En nyttig sluttøvelse er å merke den samme saldoen på tre tidspunkter: brukbar lokalt, tilgjengelig for uttak gjennom protokollens egen mekanisme og brukbar på målkjeden. Separate tidsstempler synliggjør likviditetsgap. Hvis en frist faller i et av gapene, har posisjonen et operasjonelt finansieringsproblem selv om alle saldoer til slutt gjøres opp riktig og ingen hovedstol går permanent tapt.
Sett hver bekreftelse inn på en tidslinje
En fiktiv app viser «bekreftet» klokken 20. Data publiseres på basiskjeden senere, og uttaksvilkårene oppfylles etterpå. Hele prosessen kan være normal. Feilen er å gi første melding samme betydning som alle senere trinn. Ethereum beskriver innsigelsesprosessen i optimistiske rollups; andre modeller bruker annen verifisering.
Noter lokal mottakelse, inkludering, datapublisering, bevis- eller innsigelseskrav og endelig tilgjengelighet hver for seg. Skill observerte tidspunkt fra anslag. Én universell ventetid passer ikke alle nettverk, broer og uttaksveier.
Spør deretter hvilken beslutning brukeren skal ta. Å godta en liten betaling, flytte sikkerhet og fastslå endelig oppgjør krever ikke samme dokumentasjon. «Rask» gir først mening når det raskere trinnet og gjenstående betingelser er spesifisert.
Protokollens utgang er ikke alltid tilbyderens utbetaling
Et nettverk kan tillate uttak teknisk mens en plattform stanser innskudd eller utbetalinger. En tilbyder kan også kreditere en konto før alle underliggende oppgjørstrinn er ferdige. Synlig saldo viser ikke automatisk hvem som bærer den gjenværende risikoen.
Fjern den vanlige nettsiden fra diagrammet, men la kontrakter og nettverk fungere. Trenger dokumentert utgang nettsiden, en relétjeneste, en operatør eller en egen transaksjon? Fjern deretter sekvensereren og spør igjen. Ikke anta at alle systemer har samme enkle eller umiddelbare reservevei.
Skill hva protokollen tillater, hva tjenesten støtter og hva brukeren faktisk kan gjennomføre. En ukontrollert teknisk mulighet er ikke ennå en pålitelig utgang. Dette skillet sier mer om robusthet enn ett tall for hastighet eller kostnad.