Lag 2: hurtig bekræftelse er ikke det samme som endelig afvikling
Kortlæg transaktionsaccept, offentliggørelse af data og afslutning af udbetalinger i et skaleringssystem.
Navngiv det trin, du observerer
En hurtig bekræftelse i brugerfladen kan betyde, at en sequencer har accepteret en transaktion, ikke at alle senere afviklingsbetingelser er opfyldt. Lag 2-systemer udfører arbejde uden for basiskæden og bruger yderligere mekanismer til at afvikle eller verificere resultater. Ethereums skaleringsdokumentation skelner mellem optimistiske tilgange og tilgange med gyldighedsbeviser. Arkitekturen afgør, hvad en observatør sikkert kan udlede på hvert trin.
Brug præcise betegnelser i et analysenotat: indsendt, accepteret af operatøren, inkluderet i en batch, offentliggjort på basiskæden, verificeret eller afsluttet indsigelsesperiode samt hævet. Ikke alle systemer bruger netop disse stadier, men at sammenfatte dem i ét ord, bekræftet, skjuler operationelle forskelle, der er vigtige for børser og sikkerhedsforvaltere.
Forstå forskellen i verificering
Optimistiske rollups bygger på mekanismer til at anfægte forkerte tilstandspåstande inden for et defineret tidsvindue. Konstruktioner med gyldighedsbeviser indsender kryptografisk dokumentation for tilstandsovergange, men deres datatilgængelighed, opgraderinger og operationelle ordninger kræver stadig undersøgelse. Et bevissystem er én sikkerhedskomponent, ikke en generel garanti for alle applikationer eller broer bygget omkring det.
Den praktiske øvelse er at spørge, hvad der ville ske, hvis en operatør indsendte et forkert resultat, stoppede behandlingen af transaktioner eller tilbageholdt en nødvendig tjeneste. Identificer, hvilke aktører der kan reagere, og hvilke oplysninger de har brug for. Svaret bør komme fra dokumentationen for det implementerede system, ikke fra en idealiseret beskrivelse af den brede kategori.
Adskil afviklingsforsinkelse fra udbetalingslikviditet
En hævning via protokollens egen mekanisme kan kræve ventetid på dens betingelser. En ekstern likviditetsudbyder kan tilbyde midler tidligere mod et gebyr og dermed reelt give en anden exitrute. Den rute ændrer eksponeringen; den får ikke den underliggende protokols afviklingsbetingelser til at forsvinde. Kapaciteten kan falde under stress netop, når mange brugere ønsker en tidlig exit.
Forestil dig en forpligtelse, der forfalder i morgen på basiskæden, og aktiver, hvis almindelige udbetaling tager flere dage i et hypotetisk system. Disse aktiver kan være værdifulde, men utilgængelige på det krævede tidspunkt. Et tilbud på hurtig exit er kun nyttig evidens for det beløb og tidspunkt, der faktisk er tilbudt. Det bør ikke antages at forblive tilgængeligt under et markedsomfattende stormløb.
Undersøg kontrolmekanismer og infrastruktur
Koncentration af sequencere, opgraderingsnøgler, nødråd, indsendelse af beviser og offentliggørelse af data fortjener hver sin række i en sammenligning. Et system kan have stærke regler for transaktionsverifikation og samtidig være afhængigt af centraliserede driftstjenester. Et nedbrud kan påvirke tilgængeligheden uden at ændre ejerskabet, men manglende mulighed for at handle kan stadig give økonomisk skade, hvis positioner kræver hurtig justering.
Kontrollér, om tvungen inkludering eller alternative exitmekanismer findes, hvem der kan bruge dem, og hvilke praktiske forsinkelser de medfører. En teoretisk tilgængelig flugtvej kan kræve gebyrer på basiskæden, tekniske trin og ventetider. I en ikke-teknisk analyseøvelse skal du dokumentere disse krav frem for at antage, at ordet tilladelsesfri betyder ubesværet eller øjeblikkelig adgang.
Mål de samlede omkostninger gennem hele levetiden
Lave transaktionsgebyrer kan være værdifulde, men en fuldstændig sammenligning omfatter indskud, udbetalinger, brug af bridges, likviditet på destinationen og tid, hvor midlerne er utilgængelige. En strategi med hyppige lokale transaktioner og sjældne udbetalinger har en anden omkostningsprofil end en, der konstant flytter midler mellem netværk. Den relevante enhed er hele arbejdsgangen, ikke én bekvemt billig handling.
Lav en tidslinje for et normalt tilfælde og et nedbrudstilfælde. Registrér, hvilken beholdning der kan bruges på hvert tidspunkt, og hvilke antagelser der ville forsinke næste trin. Det gør analysen nyttig uden at forudsige, hvilket skaleringssystem der får succes. Teknisk gennemløb, endelig afvikling, likviditet og applikationstokenens værdi er forskellige emner og bør ikke fremstilles, som om en forbedring af ét automatisk forbedrer alle de andre.
En nyttig afsluttende øvelse er at mærke den samme saldo på tre tidspunkter: anvendelig lokalt, tilgængelig for exit via protokollens egen mekanisme og anvendelig på destinationskæden. Særskilte tidsstempler gør likviditetsgab synlige. Hvis en frist ligger inden for et af disse gab, har positionen et praktisk finansieringsproblem, selv om alle saldi til sidst afvikles korrekt, og ingen hovedstol går permanent tabt.
Placér hver bekræftelse på sin egen tidslinje
En fiktiv app viser »bekræftet« klokken 14. Data offentliggøres senere på basiskæden, og betingelserne for et udtræk opfyldes endnu senere. Forløbet kan være helt normalt. Fejlen består i at tillægge den første meddelelse samme betydning som alle de efterfølgende trin.
Registrér lokal modtagelse, inkludering, datapublicering, bevis- eller indsigelseskrav og endelig tilgængelighed hver for sig. Ethereums dokumentation om optimistiske rollups beskriver indsigelsesmekanismen i den model. Andre konstruktioner anvender andre verifikationsforløb; én fast ventetid passer ikke alle løsninger.
Spørg til sidst, hvilken beslutning der skal træffes. At acceptere en mindre betaling, flytte sikkerhed eller konstatere endelig afvikling kræver ikke nødvendigvis samme dokumentation. »Hurtigere« bliver først præcist, når du navngiver det trin, der går hurtigere, og de betingelser, som stadig mangler.
Protokollens udgang og udbyderens udbetaling er forskellige led
Et netværk kan teknisk tillade udtræk, samtidig med at en platform har sat indbetalinger eller udbetalinger på pause. En udbyder kan også kreditere kundens konto, før den underliggende afvikling er afsluttet. En synlig saldo fortæller ikke automatisk, hvem der bærer den resterende risiko.
Fjern den sædvanlige hjemmeside fra et diagram, men lad kontrakterne og netværket fungere. Kræver den dokumenterede udgang hjemmesiden, en relætjeneste, en operatør eller en særskilt transaktion? Fjern derefter sequenceren og stil spørgsmålet igen. Antag ikke, at alle systemer har en lige enkel eller øjeblikkelig reservevej.
Adskil det, protokollen tillader, det, tjenesten understøtter, og det, brugeren faktisk kan gennemføre. En uprøvet teknisk mulighed er endnu ikke en dokumenteret brugbar udgang. Den forskel siger mere om robusthed end ét tal for transaktionspris eller hastighed.