2. vrstva: rychlé potvrzení není totéž co konečné vypořádání
Zmapujte přijetí transakce, zveřejnění dat a dokončení výběru v systému škálování.
Pojmenujte fázi, kterou pozorujete
Rychlé potvrzení v rozhraní může znamenat, že sekvencer přijal transakci, nikoli že jsou splněny všechny pozdější podmínky vypořádání. Systémy 2. vrstvy provádějí práci mimo základní řetězec a používají další mechanismy k vypořádání nebo ověření výsledků. Dokumentace škálování Etherea rozlišuje optimistické přístupy a přístupy s důkazem platnosti. Architektura určuje, co může pozorovatel v každé fázi bezpečně vyvodit.
Ve výzkumném záznamu používejte přesná označení: odesláno, přijato provozovatelem, zahrnuto do dávky, zveřejněno na základním řetězci, ověřeno nebo po skončení lhůty pro námitky a vybráno. Ne každý systém používá přesně tyto fáze, ale jejich sloučení do jediného slova „potvrzeno“ skrývá provozní rozdíly důležité pro burzy a správce zajištění.
Pochopte rozdíl v ověřování
Optimistické rollupy spoléhají na mechanismy napadení nesprávných tvrzení o stavu v definovaném okně. Modely s důkazy validity předkládají kryptografické důkazy přechodů stavu, jejich dostupnost dat, aktualizační a provozní uspořádání však stále vyžadují prověření. Důkazový systém je jednou složkou bezpečnosti, nikoli plošnou zárukou každé aplikace nebo mostu kolem něj.
Praktickým cvičením je ptát se, co by se stalo, kdyby provozovatel předložil nesprávný výsledek, přestal zpracovávat transakce nebo neposkytl některou požadovanou službu. Určete, kteří aktéři mohou reagovat a jaké informace potřebují. Odpověď by měla vycházet z dokumentace nasazeného systému, nikoli z idealizovaného popisu široké kategorie.
Oddělte zpoždění vypořádání od likvidity pro výběry
Nativní výběr může vyžadovat čekání na splnění podmínek protokolu. Externí poskytovatel likvidity může nabídnout prostředky dříve za poplatek, čímž fakticky poskytuje jinou cestu výstupu. Tato cesta mění expozici; neodstraňuje podmínky vypořádání podkladového protokolu. Kapacita se může při napětí zmenšit právě tehdy, když chce mnoho uživatelů vystoupit dříve.
Představte si závazek splatný zítra na základním řetězci a aktiva, jejichž nativní výběr v hypotetickém systému trvá několik dní. Tato aktiva mohou být hodnotná, ale nedostupná v požadovaném termínu. Kotace rychlého výstupu je užitečným důkazem jen pro skutečně kotované množství a čas. Nelze předpokládat, že zůstane dostupná při celotržním náporu.
Prověřte kontrolní mechanismy a infrastrukturu
Koncentrace sekvencerů, klíče pro aktualizace, nouzové rady, předkládání důkazů a zveřejňování dat si zaslouží samostatné řádky srovnání. Systém může mít silná pravidla ověřování transakcí a přitom záviset na centralizovaných provozních službách. Výpadek může ovlivnit dostupnost bez změny vlastnictví, ale nemožnost provádět transakce může přesto způsobit finanční újmu, pokud pozice potřebují naléhavou úpravu.
Prověřte, zda existuje vynucené zařazení transakce nebo alternativní mechanismy výstupu, kdo je může využít a jaká jsou praktická zpoždění. Teoreticky dostupná úniková cesta může vyžadovat poplatky základního řetězce, technické kroky a čekací lhůty. V netechnickém výzkumném cvičení tyto požadavky zdokumentujte, místo abyste předpokládali, že výraz bez povolení znamená snadný nebo okamžitý přístup.
Měřte náklady celého životního cyklu
Nízké transakční poplatky mohou být cenné, ale úplné porovnání zahrnuje vklady, výběry, přesuny přes mosty, likviditu v cíli a dobu nedostupnosti prostředků. Strategie s častými místními transakcemi a vzácnými výběry má jiný nákladový profil než strategie, která neustále přesouvá prostředky mezi sítěmi. Relevantní jednotkou je celý pracovní postup, nikoli jedna příhodně levná operace.
Vytvořte časovou osu běžného případu a výpadku. Zaznamenejte, který zůstatek je v každém okamžiku použitelný a jaké předpoklady by další krok zdržely. Díky tomu je analýza užitečná, aniž předpovídá, který škálovací systém uspěje. Technická propustnost, finalita, likvidita a hodnota aplikačního tokenu jsou odlišná témata a neměla by být prezentována tak, jako by zlepšení jednoho automaticky zlepšovalo všechna ostatní.
Užitečným závěrečným cvičením je označit stejný zůstatek ve třech okamžicích: použitelný lokálně, dostupný pro nativní výstup a použitelný na cílovém řetězci. Přiřazení samostatných časových údajů zviditelní mezery v likviditě. Pokud termín spadá do některé z těchto mezer, pozice má provozní problém s financováním, i když se každý zůstatek nakonec správně vypořádá a žádná jistina se trvale neztratí.
Dostupnost dat není totéž co trvalý archiv
Pro ověření změny stavu jsou nutná příslušná data. Skutečnost, že byla dostupná v rozhodný okamžik, neznamená, že je každá služba uchová navždy. Dokumentace dostupnosti dat Etherea odlišuje dostupnost pro ověření od pozdějšího vyhledávání historie.
Položte dvě otázky: co síť potřebuje k přijetí změny a odkud uživatel později získá doklady o svých operacích? Obě jsou důležité z jiného důvodu. Chybějící starý záznam v jednom rozhraní ještě neprokazuje, že transakce nebyla potvrzena.
Uchovávejte identifikátory, síť, datum kontroly a zdroj údajů. Rychlé oznámení v aplikaci samo nepotvrzuje, že ve stejnou chvíli skončilo veškeré vypořádání a byly splněny podmínky výběru.
Prověřte výstup bez běžného webového rozhraní
V hypotetickém výpadku zmizí web, ale kontrakty a síť fungují dále. Je zdokumentována jiná použitelná cesta výstupu a co vyžaduje? Možnost na úrovni protokolu není totožná s praktickou schopností uživatele ji uskutečnit.
Do mapy přidejte zprostředkující službu, sekvencer, důkazní mechanismus a přijímající platformu. Odebírejte jednotlivé části a sledujte zbývající kroky. Nepředpokládejte, že každé řešení nabízí stejně rychlou nouzovou cestu nebo že platforma podporuje všechny technické možnosti sítě.
Rozlišujte pozorovanou funkčnost, dokumentovanou možnost a neověřený předpoklad. Atraktivní údaj o několika sekundách pak nezakryje, na kom závisí konečný přístup k prostředkům a za jakých okolností se čekání může prodloužit.