🇸🇰 Overovanie transakcií bez prekvapení v systéme Cardano: 2. časť

Validácia transakcií v Alonzo sa vykonáva v dvoch fázach, aby sa zabezpečila spravodlivá odmena za validačnú prácu

No-surprises transaction validation: part 2

V našom predchádzajúcom blogovom príspevku sme sa venovali deterministickej povahe validácie transakcií a skriptov v účtovnej knihe Alonza, ktorá poskytuje istotu, že výsledok aplikácie transakcií a validácie skriptov na chaine možno presne predpovedať lokálne, ešte pred odoslaním transakcie.

Na základe záruk, ktoré poskytuje deterministický dizajn hlavnej knihy v Alonzo, sme implementovali špecifickú dvojfázovú schému overovania. Je navrhnutá tak, aby minimalizovala zdroje, ktoré uzly využívajú na validáciu sieťových transakcií a zároveň eliminovala neočakávané náklady pre používateľa. V tomto blogovom príspevku sa hlbšie venujeme tomu, ako dvojfázová validácia funguje.

V ére Shelley, Allegra a Mary bolo overovanie transakcií jednostupňovým procesom. Vplyv platnej transakcie na účtovnú knihu bol plne predvídateľný ešte pred jej použitím. Ak bola transakcia platná, bola zaradená do bloku a pridaná do účtovnej knihy. Ak nie, uzol ju po neúspešnom pokuse o validáciu odmietol a transakcia nebola zaradená do bloku. Uzly, ktoré overovali prichádzajúce transakcie, však spotrebovali čas a zdroje bez ohľadu na to, či transakcia skončila v bloku alebo nie.

Alonzo predstavuje skripty Plutusu, ktorých overenie môže vyžadovať podstatne viac prostriedkov v porovnaní s jednoduchými skriptami v predchádzajúcich obdobiach. Na riešenie problému uzlov, ktoré vynakladajú zdroje na validáciu skriptov transakcií, ktoré sú odmietnuté, zavádza Alonzo dvojfázový prístup validácie. Táto stratégia zachováva predvídateľný výsledok aplikácie transakcií do účtovnej knihy a zároveň zabezpečuje spravodlivú kompenzáciu uzlov za ich prácu a využitie zdrojov.

Dvojfázové overovanie transakcií

Overovanie transakcií v systéme Cardano je rozdelené do dvoch fáz. Hlavným dôvodom zavedenia dvojfázovej validácie je obmedziť množstvo nekompenzovanej validačnej práce uzlov. Každá fáza slúži na dosiahnutie tohto cieľa. Zhruba povedané, prvá fáza kontroluje, či je transakcia správne zostavená a či môže zaplatiť poplatok za jej spracovanie. V druhej fáze sa spustia skripty obsiahnuté v transakcii. Ak je transakcia platná podľa fázy 1, spustia sa skripty fázy 2. Ak fáza-1 zlyhá, nespustia sa žiadne skripty a transakcia sa okamžite zahodí.

Od uzlov sa teda očakáva, že do bloku pridajú spracovateľné transakcie, aj keď transakcie nie sú platné vo fáze 2. To znamená, že buď:

  • uzol vykoná malé množstvo nekompenzovanej práce, aby zistil, že transakcia nie je spracovateľná ale nevykoná sa žiadna nákladná validácia vo fáze 2, alebo
  • transakcia je spracovateľná. Uzol potom môže vykonať overenie skriptov vo fáze 2, označiť transakciu podľa toho či je uznaná za platnú alebo neplatnú vo fáze 2 a pridať ju do bloku. V oboch prípadoch bude uzol neskôr kompenzovaný za obe fázy validácie prostredníctvom poplatku alebo zábezpeky vybranej z tejto transakcie.

Očakáva sa, že zlyhanie fázy-2 by malo byť zriedkavé, pretože používateľ, ktorý predloží transakciu so zlyhanými skriptami, stratí ADU, pričom nič nedosiahne. Je to lokálne predvídateľná a teda preventívna udalosť. Fáza je požadovanou ochranou, ktorá zaručuje kompenzáciu za potenciálne náročné výpočty skriptov na zdroje.

Pozrime sa bližšie na špecifiká jednotlivých fáz.

Fáza 1

Prvá fáza validácie musí byť jednoduchá. Ak táto fáza zlyhá, uzol nedostane kompenzáciu za vykonanú prácu, pretože nemôže prijať poplatky za spracovanie nespracovaných transakcií.

Fáza 1 validácie overuje dve veci: či je transakcia správne zostavená a či je možné ju pridať do účtovnej knihy. Táto validácia zahŕňa nasledujúce kontroly a niektoré ďalšie:

  • platí správnu výšku poplatkov a poskytuje správnu výšku zábezpeky (t. j. ADY vybranej v prípade zlyhania skriptu, vysvetlené nižšie)
  • obsahuje všetky údaje potrebné na vykonanie skriptov Plutus
  • neprekračuje žiadne hranice stanovené v parametroch protokolu (týkajúce sa veľkosti výstupu atď.)
  • jeho vstupy sa vzťahujú na UTXO existujúce v účtovnej knihe
  • uvedený výpočtový rozpočet transakcie neprekračuje maximálny limit zdrojov na transakciu
  • kontroly integrity hash atď.

Pred pridaním prichádzajúcej transakcie do mempoolu (a prípadne do bloku) musí uzol vykonať všetky overovacie kontroly fázy 1. Ak niektorá z týchto kontrol zlyhá, transakcia sa odmietne bez zaradenia do bloku a neúčtujú sa žiadne poplatky. V predchádzajúcich obdobiach to bola jediná fáza validácie a Cardano takto riešilo všetky zlyhania validácie.

Od poctivých, nekompromitovaných uzlov sa neočakáva, že budú zámerne vytvárať nespracovateľné transakcie. Uzly môžu tiež zrušiť spojenia vykonávajúce nepriateľské šírenie neplatných transakcií vo fáze 1.

Fáza 2

V druhej fáze overovania sa používajú skripty Plutus, ktoré môžu byť výpočtovo náročnejšie. Preto sa po úspešnom alebo neúspešnom ukončení druhej fázy účtujú poplatky. Vyzbieraná ADA ide do banku poplatkov a tak kompenzuje uzly za zdroje použité v procese validácie.

Úspešná validácia vo fáze 1 nezaručuje, že všetky transakcie sú spracovateľné, iba to, že je možné vybrať zábezpeku. Vo fáze-2 sa vykonáva validácia skriptu Plutus a na základe výsledku validácie sa rozhoduje, či sa vykoná úplné spracovanie alebo len výber zábezpeky:

  • úplné uplatnenie transakcie (jediná možnosť pred Alonzom) - ak skripty Plutus validujú všetky akcie transakcie,
  • vybrať kolaterál ADA a ignorovať zvyšok transakcie - ak jeden zo skriptov Plutusu zlyhá .

Pripomeňme si, že overovanie skriptov má lokálne predvídateľný výsledok a je zaručené, že sa ukončí. Používatelia môžu lokálne skontrolovať výsledky validácie skriptov a medzi poctivými uzlami nedôjde k nezhode o tom, ako spracovať danú transakciu a skripty v nej.

Kolaterál

Aj ak sa skripty neoveria, musíme uzly za ich prácu odmeniť. Nemôžeme však len tak zobrať peniaze zo vstupov transakcií, pretože tie mohli byť uzamknuté pomocou skriptov - tých, ktoré zlyhali! Namiesto toho teda Alonzo zavádza špeciálne ustanovenie na tento účel. Zábezpeka transakcie je suma v ADA, ktorá sa vyberie ako poplatok v prípade zlyhania overovania skriptov vo fáze 2. V spracovateľnej transakcii musí byť táto suma aspoň určitým percentom poplatku za transakciu, ktorá je uvedená v parametri protokolu.

Táto suma sa uvádza v čase zostavovania transakcie. Nie priamo, ale pridaním kolaterálnych vstupov do transakcie. Celkový zostatok v UTXO zodpovedajúci týmto špeciálne označeným vstupom je suma kolaterálu transakcie. Tieto UTXO musia mať adresy verejného kľúča (nie skriptu) a neobsahujú žiadne iné tokeny ako ADA.

Zábezpekové vstupy sa z účtovnej knihy UTXO odstránia len ak niektorý skript neuspeje v 2. fáze validácie. Ak všetky skripty prejdú, vyberie sa určená suma transakčného poplatku, ako v predchádzajúcich érach. Konkrétne táto suma pochádza z bežných, nekolaterálnych vstupov a kolaterálne vstupy sa jednoducho ignorujú. A dobrá správa! Je povolené používať tie isté vstupy ako kolaterál a aj regulárne vstupy, pretože z UTXO sa vždy odstráni len jedna z týchto dvoch množín.

Pri zachovaní integrity transakcie zohrávajú dôležitú úlohu aj podpisy potrebné na overenie čerpania kolaterálnych vstupov. Robia to tým, že zabraňujú protivníkom zmeniť jej obsah tak, aby bola naďalej spracovateľná, ale aby neprešla overením v 2. fáze. Príkladom môže byť protivník, ktorý nahradí kupujúceho. Na vykonanie takejto zmeny sa vyžadujú podpisy držiteľov zabezpečovacích kľúčov. Držitelia záložných kľúčov sú tiež jediní používatelia, ktorí môžu stratiť ADU, ak validácia skriptu zlyhá.

Keďže vyhodnotenie skriptu je deterministické, držitelia zabezpečovacích kľúčov môžu lokálne skontrolovať, či transakcia prejde overením fázy 2 v reťazci, skôr ako ju podpíšu. Ak áno, môžu si byť istí, že sa tak stane aj na reťazci a o svoj kolaterál určite neprídu. Používateľ konajúci v dobrej viere by o svoj kolaterál nikdy nemal prísť. Znamená to tiež, že môžu opakovane použiť rovnaké vstupy kolaterálu pre viacero transakcií a mať istotu, že kolaterál nebude vybratý.

Keďže sme spustili verejnú testovaciu sieť Alonzo, vítame všetkých používateľov a vývojárov, aby ju posúdili zostavením a spustením skriptov Plutusu. Viac informácií sa môžete dozvedieť na špecializovanom úložisku Alonzo testnet alebo diskutovať o témach Plutus a Alonzo s našou rôznorodou komunitou.


Pôvodný článok: No-surprises transaction validation: part 2 - IOHK Blog

Napísala Polina Vinpgradova z IOHK - preklad @Martin.M