Layer 2: nopea vahvistus ei tarkoita lopullista selvitystä
Kartoita tapahtumien hyväksyntä, datan julkaisu ja noston valmistuminen skaalausjärjestelmässä.
Nimeä tarkastelemasi vaihe
Käyttöliittymän nopea vahvistus voi tarkoittaa, että sekvensseri hyväksyi tapahtuman, ei sitä, että kaikki myöhemmät selvitysehdot täyttyivät. Layer 2 -järjestelmät tekevät työtä perusketjun ulkopuolella ja käyttävät lisämekanismeja tulosten selvittämiseen tai todentamiseen. Ethereumin skaalausdokumentaatio erottaa optimistiset lähestymistavat kelpoisuustodistuksiin perustuvista. Arkkitehtuuri määrää, mitä havainnoija voi turvallisesti päätellä kussakin vaiheessa.
Käytä tutkimusmuistiossa täsmällisiä tilamerkintöjä: lähetetty, operaattorin hyväksymä, erään sisällytetty, perusketjuun julkaistu, varmennettu tai riitautusajan päättänyt sekä nostettu. Kaikki järjestelmät eivät käytä täsmälleen näitä vaiheita, mutta niiden niputtaminen yhteen sanaan, vahvistettu, peittää pörsseille ja vakuuksien hoitajille tärkeitä toiminnallisia eroja.
Ymmärrä varmennustapojen ero
Optimistiset rollupit perustuvat mekanismeihin, joilla virheelliset tilaväitteet voidaan riitauttaa määritetyssä aikaikkunassa. Kelpoisuustodisteisiin perustuvat mallit toimittavat kryptografista näyttöä tilasiirtymistä, vaikka niiden datan saatavuus-, päivitys- ja toimintajärjestelyt on silti tarkastettava. Todistejärjestelmä on yksi turvallisuuden osa, ei kattava takuu jokaisesta sen ympärille rakennetusta sovelluksesta tai sillasta.
Käytännön harjoitus on kysyä, mitä tapahtuisi, jos operaattori toimittaisi virheellisen tuloksen, lopettaisi tapahtumien käsittelyn tai jättäisi tarvittavan palvelun tarjoamatta. Tunnista, mitkä toimijat voivat reagoida ja mitä tietoja ne tarvitsevat. Vastauksen tulee perustua käytössä olevan järjestelmän dokumentaatioon, ei koko luokan ihannoituun kuvaukseen.
Erota selvitysviive nostolikviditeetistä
Protokollan oma nosto voi edellyttää sen ehtojen täyttymisen odottamista. Kolmas likviditeetin tarjoaja voi tarjota varat aiemmin maksua vastaan ja siten toisen poistumisreitin. Tämä reitti muuttaa altistusta; se ei poista taustalla olevan protokollan selvitysehtoja. Kapasiteetti voi supistua stressissä juuri silloin, kun monet käyttäjät haluavat poistua aikaisin.
Kuvittele perusketjussa huomenna erääntyvä velvoite ja varat, joiden natiivi nosto kestää kuvitteellisessa järjestelmässä useita päiviä. Varat voivat olla arvokkaita, mutta niitä ei saa käyttöön vaaditussa aikataulussa. Nopean poistumisen tarjous on hyödyllistä näyttöä vain tarjouksessa mainitulle määrälle ja ajankohdalle. Sen ei pidä olettaa pysyvän saatavilla koko markkinan rynnätessä ulos.
Tutki hallintakeinoja ja infrastruktuuria
Sekvensserikeskittymä, päivitysavaimet, hätätilaneuvostot, todisteiden toimittaminen ja datan julkaiseminen ansaitsevat kukin oman rivinsä vertailussa. Järjestelmällä voi olla vahvat tapahtumien varmennussäännöt ja silti riippuvuus keskitetyistä operatiivisista palveluista. Katko voi vaikuttaa käytettävyyteen omistusta muuttamatta, mutta kaupankäynnin estyminen voi silti aiheuttaa taloudellista haittaa, jos positioita on muutettava kiireesti.
Tarkista, onko pakotetun sisällyttämisen tai vaihtoehtoisen poistumisen mekanismeja, kuka voi käyttää niitä ja mitkä ovat käytännön viiveet. Teoriassa saatavilla oleva poistumisreitti voi vaatia perusketjun maksuja, teknisiä vaiheita ja odotusaikoja. Dokumentoi nämä vaatimukset ei-teknisessä tutkimusharjoituksessa sen sijaan, että oletat luvattomuuden tarkoittavan vaivatonta tai välitöntä pääsyä.
Mittaa koko elinkaaren kustannus
Pienet tapahtumamaksut voivat olla arvokkaita, mutta täydellinen vertailu sisältää talletukset, nostot, sillat, kohdeverkon likviditeetin ja ajan, jolloin varat eivät ole käytettävissä. Strategialla, jossa on paljon paikallisia tapahtumia ja harvoin nostoja, on erilainen kuluprofiili kuin jatkuvasti verkkojen välillä varoja siirtävällä strategialla. Olennainen yksikkö on koko työnkulku, ei yksi sopivasti halpa toiminto.
Laadi aikajana normaalitilanteelle ja häiriötilanteelle. Kirjaa, mikä saldo on käytettävissä kussakin vaiheessa ja mitkä oletukset viivästyttäisivät seuraavaa askelta. Tämä tekee analyysistä hyödyllisen ilman ennustetta menestyvästä skaalausjärjestelmästä. Tekninen läpäisykyky, lopullisuus, likviditeetti ja sovellustokenin arvo ovat eri asioita, eikä niitä pidä esittää niin, että yhden paraneminen parantaa automaattisesti kaikkia muita.
Hyödyllinen loppuharjoitus on nimetä sama saldo kolmessa vaiheessa: paikallisesti käytettävissä, käytettävissä protokollan omaan poistumiseen ja käytettävissä kohdeketjussa. Erilliset aikaleimat tekevät likviditeettikatkokset näkyviksi. Jos määräaika osuu johonkin näistä katkoksista, positiolla on toiminnallinen rahoitusongelma, vaikka kaikki saldot lopulta selvitettäisiin oikein eikä pääomaa menetettäisi pysyvästi.
Tietojen saatavuus ei ole sama asia kuin pysyvä arkisto
Järjestelmän on voitava todentaa tilamuutos tarvittavien tietojen avulla. Se, että tiedot olivat saatavilla oikeaan aikaan, ei silti tarkoita, että jokainen palvelu säilyttäisi niitä ikuisesti. Ethereumin tietojen saatavuutta käsittelevä dokumentaatio erottaa saatavuuden historiallisten tietojen myöhemmästä hakemisesta.
Jaa kysymys kahteen: mitä verkko tarvitsee muutoksen hyväksymiseksi, ja mistä käyttäjä saa myöhemmin oman tapahtumahistoriansa? Molemmat ovat olennaisia, mutta eri syistä. Tietopalvelun puuttuva vanha näkymä ei sellaisenaan todista, ettei tapahtumaa olisi koskaan vahvistettu.
Kirjaa tutkimusmuistioon tapahtumatunnisteet, verkko, tarkasteluajankohta ja käytetty tietolähde. Älä päättele pelkän nopean sovellusvahvistuksen perusteella, että kaikki myöhemmän selvityksen tai noston edellytykset täyttyivät samalla hetkellä.
Testaa poistumisreitti ilman tavallista käyttöliittymää
Kuvitteellisessa häiriössä verkkosivusto katoaa, mutta sopimukset ja verkko jatkavat toimintaansa. Onko poistuminen edelleen dokumentoidusti mahdollista, ja mitä siihen tarvitaan? Protokollan sallima toiminto ja käyttäjän tosiasiallinen kyky suorittaa se ovat eri asioita.
Lisää karttaan mahdollinen välityspalvelu, sekvensseri, todistuspalvelu ja vastaanottava alusta. Poista yksi kerrallaan ja tarkista jäljelle jäävät vaiheet. Älä oleta jokaisella järjestelmällä olevan samanlaista nopeaa varareittiä tai sitä, että alusta tukisi kaikkia protokollan teknisiä toimintoja.
Raportoi erikseen havaittu toimivuus, dokumentoitu mahdollisuus ja testaamaton oletus. Näin muutaman sekunnin nopeusluku ei peitä sitä, kenestä lopullinen pääsy varoihin riippuu ja missä tilanteessa odotusaika voi muuttua.