Jedini Blockchain sa Native Podrškom za Rollup-ove na konsenzusnom sloju

“Odricanje od odgovornosti: Ovo je prevod člana Oasis zajednice. Ako želite da pročitate originalni članak, posetite: Oasis Network Architecture: Designed for Scaling”

Sloj 2 skalabilna rešenja su evoluira od “sidechain-ova” do “commitchain-ova”, “rollup-ova” i validatorskih bridge-va. “Rollup” se odnosi na pokretanje virutalnih mašina pametnih ugovora (VM) gde se stanje VM periodično proverava i commit-uje do blockchaina da bi pružio funkcionalnost pametnog ugovara uz smanjenu cenu troškova i veći protok, nasuprot pokretanju pametnih ugovara direktno na blockchain-u. Verifikacija se završava na blockchainu koji osigurava stanje promena, i računanje van chain-a dozvoljavaju pametnim ugovorima da se završavaju na većoj skali.

Nismo ih nazvali rollup-ovi, ali tako ParaTime Oasis Mreže ili računarski sloj rade.

Od svog početka, Oasis Mreža je odvajala računanje od konsenzusa po principu modularnog dizajna. Ovo odvajanje znači da ParaTime sloj samo vrši izvršavanje pametnog ugovara, a konsenzusni sloj samo vrši konsenzus, i oba su veoma uproštena. Ovo ima mnogo benificija, uključujući lakoću revizije, izolaciju grešaka, i smanjenju replikaciju računanja bez žrtvovanja sigurnosti. Odvajanje, računanja u (rollup) virtualnoj mašini i proveravanje i upisivanje rezultata u blockchain-u, je konkretno o čemu su rollup-ovi.

Oasis mreža nije samo mreža koja sama po sebi podržava rollups, arhitektura je optimizovana za rollups i samo za rollups: mreža obeshrabruje stavljanje generalnog računanja u konsenzusni sloj, i dozvoljava samo ugrađene ugovore da se pokrenu ovde. Ovi ugrađeni ugovori su validating bridge ugovori na rollup način. Dok je cilj dizajna Oasis arhitekture bio modularni blockchain Sloj-1 koji podržava pametne ugovore, moglo bi se reći da je rezultat te modularnosti Oasis konsenzus sloj, blockchain koji jedino podržava rollup-ove, pošto gledano kroz rollup perspektivu svi ParaTime-ovi su Sloj 2 rollup virtualne mašine.

Posebno, Oasis-ov validating bridge u konsenzusnom sloju koristi tehniku otpornu na prevare koja se zove “discrepancy detection” da bi se validirali rezultati iz računarskog sloja. Ova tehnika, rezultat kodizajna detekcija prevara i dizajna arhitekture sistema, koristi “bare metal proofs” koji su prosti i zbog toga od većeg poverenja jer postoji manje stvari koje mogu da krenu po zlu. Kao što ćemo da vidimo, jednostavnost bare metal proofs takođe daje ParaTime dizajnerima više prostora: implementiranje okruženja za izvršavanje pametnih ugovora gde su pametni ugovori sandbox-ovan native kod koji postaje izvodljiv, dajući prostora sistemu za unapređenje performansi izvan istvoremenog ParaTime izvršavanje.

Rekli bi da je Oasis mreža prva koja native podržava rollup-ove. I da “Sloj 1”/“Sloj 2” nomenklatura je nedovoljno opisna/precizna.

Nazovite ga konvergentni dizajn. Hajdemo da rasčlanimo šta sve ovo znači i da idemo u detalje.

Svojstva Rollup-a

Rollup-ovi su prvenstveno dizajnirani da ubrzaju procesovanje Ethereum pametnih ugovora. Preciznije, dizajnirani su da izvršavaju Ethereum pametne ugovore, ali u različitim, nezavisnim virutalnim mašinama, različitim od Ethereum Virtualne Mašine (EVM) na Ethereum Sloj 1 “base chain-u” da bi smanjio Sloj 1 workload. Sva izvršavanja ugovora se dešava na Sloj 2 rollup virtualnoj mašini. Jedini posao koji radi blockchain je validiranje izvršavanja rollup virtualne mašine koristeći “validating bridge” pametni ugovor. Obično, rollup virtualna mašina je instanca EVM, i u nekim dizajnima, npr., Arbitrum, rollup virtualna mašina je podešena da validira lakše u osnovnom chain-u. Dokle god je validacija u Sloju 1, jefitinije je nego pokretanje rollup pametnih ugovora direktno u Sloju 1, imamo veću efikasnost jer izvršavanje Sloj 2 mašine je zamišljeno da bude jeftinije. Ovo je srž rada rollup-ova i kako postižu skaliranje protoka transakcija.

Zapazite kako povrh Sloj 1 blockchain-a, može postojati mnogo Sloj 2 virutalnih mašina. Ne postoje arhitektonski limiti drugi nego protok validacija na Sloju 1. Što su efikasniji validirajući bridge ugovori i što manje izvršavanja non-bridge pametnih ugovora na Sloj 1 blockchain-u, više rollup-ova je podržano. Očigledno, može biti validirajućih bridge-type ugovora koji su pokrenuti unutar rollup-a takođe, ali postoje limiti na ove rekurzije o kojima nećemo sada.

Većina rollup dizajna commit-uju podatke transakcija na osnovni chain prvo i kasnije commit-uju rezultantno stanje rollup virtualne mašine u narede trasnakcije. Ovo pruža transakciji order finality, i na neki način, rešava problem dostupnosti podataka jer stanje rollup virtualne mašine može da bude rekonsturisano iz podataka transakcija po cenu ponovnog pokretanja svih transakcija od početka nastanka rollup virtualne mašine. Validirajući mostovi mogu biti generalizovani, sa off-chain state skladištem koje može da se proveri koristeći Merkle proofs tako da je odvojeno rešenje podataka moguće, npr., podaci transakcija mogu da se kriptografski sažmu na sličan način kao što stanje virtualne mašine, smanjuje Sloj 1 troškove skladištenja, odvajanje dostupnosti, pružanje off-chain skladišta, od autentifikacije podataka. Ovo ima kompromis sa validacijom: problem privremene dostupnosti protoka podataka — jer pristup input podacima potreban za verifikaciju može biti spor — što može da uspori validaciju.

Način na koji rollup-ovi rade validacije virtualne mašine dolazi u dve forme:

• Optimistični rollup-ovi, gde su claimed execution rezultati javno postavljani i potencijalno izazvani
• zk rollups gde se koriste SNARKs za konstrukciju proof of correctness.

Ključna razlika je da se optimistični rollups koriste “fraud proof-ovi” gde challenger-i skupljaju dokaze da dokažu da je claimed execution rezultat netačan ili lažan, i zk rollup-ovi koriste “validity proof” koji egzekutori objavljuju zajedno sa stanjem rollup vitualne mašine, i validirajući bridge pametni ugovori verifikuju correctness of the proof. U oba slučaja, vreme potrebno da bi se omogućilo učesnicima da vide novo stanje i da ili otkriju da je stanje netačno i konstruišu fraud proof-ovi, u slučaju optimističnih rollup-ova; ili da izvrše proof verification algoritam da odbije predloženo rešenje kao netačno, u slučaju zk rollup-ova. Iako se čini kao mala razlika, u oba slučaja, posao mora da bude završen da bi se konstruisao fraud proof-ovi ili da bi se proverila da je validity proof tačan. Razlika je da tipično fraud proof-ovi uključuju ponovno izvršavanje transakcija, dok validity proof provera bi trebalo da bude jeftinija, koristeći kriptografske tehnike(probabilističi proverljivi dokazi; SNARK-ovi). U praksi, kriptografske tehnike uključuju značajane komplikacije i (još uvek) ne mogu da generalizuju do izvršavanja arbitrarnih pametnih ugovora.

Pazite, opšte gledano, rollup virtualne mašine nemaju kompatibilnost sa Ethereum-om, niti mehanizmi validacije moraju da se pokreću povrh Ethereum-a. Bilo koje decentralizovano računanje bi prošlo, proširivajući svoju sigurnost na rollup virtualnih mašina. Naravno, imajući rollup Ethereum kompatibilnu mašinu čini lakim za port-ovanje postojećih EVM kodova.

Ukusi Fraud Proof-ova

Da biste razumeli zašto sistem za detekciju prevare Oasis Mreže i kodizajn arhitekture sistema reuzltiraju većom efikasnošću i generalnijim šemama, moramo prvo da diskutujemo različite vrste fraud proof-ova.

Simulation Proof-ovi

Način na koji optimistični rollup sistemi poput Arbitrum-a i Optimism-a rade je tako što challenger-i koji tvrde da je računanje pogrešno dostave fraud proof. Fraud proof treba da pokaže da je računanje koje je dovelo do pogrešnog rezultatnog stanja divirgentno od pravilnog izvršavanja virtualne mašine u VM instrukcijama, što se može “lako” proveriti koristeći rollup simulator virtualne mašine koji je pokrenut na osnovnom chain-u.

Ovo nije lako. Kompleksnost je ogromna. Ovo spaja instrukcije rollup virtualne mašine sa validirajućim bridge ugovornom implementacijom. Ključ je biti u mogućnosti proveriti izvršavanje koja nije simulacija potpunog izvršavanja rollup virtualne mašine, jer bi ovo bilo preskupo u gasu. Umesto, challenger-i bi trebalo da pruže neosporiv dokaz da je izvršena tvrdnja output rollup-a VM stanja nije izvršena na pravi način pokazujući na tačne VM instrukcije, koristeći bisection comparing execution stanje i Merkle proofs. Proof građenje može biti završeno offline, validiranjem bridge ugovora — proverom da se zaista izvršila indikovana VM instrukcija koja se nije pridržavala VM semantike.

Da bi ovo radilo, validirajući bridge ugovori moraju da simuliraju bilo koju rollup VM instrukciju. Osiguravajući tačnost simulatora i semantička jedanakost pravog rollup-a VM je tehnički izazovna. Dok kompleksnost simulatora zavisi na kompleksnosti VM kompleta instrukcija, verovatno je potrebno mnogo godina truda da bi se konsturisao tačan i čvrst simulator, kao u slučaju Arbitrum-a i Optimism-a.

Od Challenger-a koji tvrdi da se desila prevara se očekuje da dostave dokaz prevare zajedno sa zahtevom za ispravku rezultata. Ako je fraudulent execution trace F različit od tačnog execution trace u neko vreme t_0, challenger može da konstruiše execution trace C koji je različit od tačnog trace-a u nekom daljem vremenu t_1> t_0 i da prijavi fraud proof koji će uspešno promeniti F ali je sam po sebi fraudulent rezultat. Tako, fraud proof protiv F ne dokazuje da je C tačan, i uspešan challenge sa različitim rezultatima bi trebalo da restartuje challenge submission sat tako da C može da bude izazvano. Uspešan challenge nije definitivan dokaz da je rezultat povezan sa C tačan bez dodatne provere od strane drugih verifier-a

Prednost simulation proof-a je ta da su precizni, pod pretpostavkom da sve radi, sigurni smo da kad je rezultat netačan jer su VM semantike prekršene. Ipak, validating bridge je izvršavanje pametnih ugovora na blockchain-u, i tačnost rezultata je samo verovatno, bilo da se izvršavanje na konsenzusu dešavaju na PoW ili PoS chain-u. U prvom slučaju, šansa za uspešni napad su 50%+ε ; u drugom slučaju. šansa ⅔ ukupnog stake dolazi pod kontrolu Byzantine actor-a. U oba slučaja, postoji šansa common-mode failure-a poput zero-day vulnerability-a u blockchain kodu ili operativni sistem koji omogućava različite widespread failure-e.) Zato što je fraud proof provera probabilistička, prednost imanja determinističkog proof-a je više teoretska nego stvarna.

Bare Metal Proof-ovi

Šta mislimo sa “bare metal proof-ovima”? Bare metal proof šema:

• Mora biti snažan. Proof-ovi mogu biti probabilistički po prirodi (poput ZKPs), sa mogućnošću da izaberu sigurnosne parametre da bi šansa za grešku bila što bliže nuli prema potrebi,
• Trebalo bi da radi sa bilo kojom (determinističkom) virutalnom mapinom bez adaptacija specifičnih za mašinu, uključujući VM-e koje su proste ekstenzije običnih instruction-set arhitektura poput x86–64. Šema bi trebala da omogućava pokretanje sandbox native binarnog koda (sa restrikcijom da izbegava nedeterminističko ponašanje) potpuno, “bare metal” brzina, sa ekstenzijama blockchain instrukcijama kao funkcionalni call-ovi.

Specifično, ovi zahtevi znače da sistem baziran na bare metal fraud proof-i će biti mnogo prostiji nego sistemi bazirani na simulation proof-u. Validirajući bridge ugovor ne treba pristup stanju rollup virutalne mašine, jer proveravanje stanja zahteva znanje Merklized data struktura i kako da se provere, što rollup VM specificira: ovo bi uvelo potrebu za interfejsom/mehanizmom za blockchain da ima pristup rollup stanju i napravi module interface kompleksnijim. Dalje, nije potreban VM specifičan instruction-level simulation. Izbegavanje (nepotrebne) kompleksnost je važan cilj sigurnosti jer kompleksnost olakšava pojavu grešaka.

Interesantno, zbog zahteva da fraud proof šeme budu generalnije, to takođe smanjuje ograničenja na dizajn rollup virtualnih mašina. Dok možemo da nastavimo da pišemo pametne ugovore u jeziku koji kompilira do bytecode-a i koristeći bytecode interpreratore kao virtualne mašine (što čini lakšim skupljanje Merkalized execution trace-a), nismo više ograničeni ovim pristupom. Naprednije i efikasnije tehnike mogu da se primene tako da postoji ogroman prostor za unapređenje efikasnosti pametnih ugovora. Na primer, instrukcije virtualne mašine/bytecode-ovi mogu da se kompliraju do koda mašine i pokrenu na Software Fault Isolation (SFI) sandbox-u poput RLBox, postižući skoro native kod performans.

Oasis ParaTime-ovi

U slučaju Oasis-a, razdvajanje izvršavanje pametnih ugovora od konsenzusa znači da završavamo sa rollup dizajnom. Postoji EVM-kompatibilni ParaTime, Emerald ParaTime, između ostalih koji pokreću Rust-zasnovane pametne ugovore, koji svi koriste jedan, ugrađeni, objektno orijentisani, validirajući pametni ugovor. Nijedan drugi blockchain ne ograničava osnovni lanac da vrši samo rollup validacije ugovora.

Discrepancy Detection Fraud Proof-ovi

Pomenuli smo ranije da Oasis pokreće samo ugrađene ugovore validacije u konsenzusnom sloju. Trenutno, ovo je bare metal fraud-proof style bridge validiranja gde korisitmo tehniku poznatu kao “discrepancy detection” da bismo detektovali prevaru i, ako je detektujemo, “discrepancy resolution” je reši. Ključna ideja iza “discrepancy detection” je ta da budemo više efikasni u otkrivanju prevera nego u prepravcu prevara, slično kako dodatni redundant bit u teoriji kodiranja mogu da se koriste da detektuju više grešaka nego što mogu da poprave. Pod pretpostavkom da egzibituju failure independence, kompromitovanje izvršavanja jedne node nepomaže kompromitovanju drugih, npr., potplaćivanje zaposlenih, pogađanje njihovih šifri, itd., možemo da koristimo manje računarske komitete gde zahtevamo da svi pristignu u isti rezultat izvršavanja pametnog ugovora.

Praktična sigurnost ovog dizajna je laka za razumevanje. Komitet-bazirani dizajn pruža javno znane parametre bezbednosti, veličinu komiteta, što izvršava ugovore u polusinhronizovanom maniru tako da korisnici znaju i broj provera kao i kada će provere biti završene, članovi komiteta imaju SLA i mogu biti kažnjeni ako nisu dostupni. Ovo je nasuprot optimističnih rollup-ova, gde korisnik čeka fiksno vreme na nepoznat broj potencijalnih challnger-a ili da verifikuje računanja sam. Zapazite da dizajn ne isključuje članove van komiteta za prijavu fraud proof-ova, čak i “kasne” fraud proofs od članova van komiteta mogu biti ispraćeni, videti checkpointing sekciju ovog članka ispod, tako da validacija nije završena.

Kada se nepoklapanje desi, discrepancy resolution/recovery phase se dešava. Za polu-sinhronizovane rezultate komiteta, odmah pokrećemo veći komitet da otkrije koji je rezultat pravi. Veličina ovog komiteta rezolucije je mnogo veća — rezolucija može biti pokrenuta od strane celog komiteta, na primer — tako da će biti poverenja u rezultatima. Dok je ovo skuplje u polju repliciranja računanja i komunikacije, to je okej: ovo bi trebalo da se radi ekstremno retko, i cena je amortizovana svim slučajevima kada rezolucija nije potrebna.

Dobitak efikasnosti je zbog primene brzog puta/sporog puta optimizacije običnog sistemskog dizajna. Verovatni slučaj bez prevare/neslaganja se završava efikasno, i malo verovatni slučaj gde trebamo da odredimo koji od dva ili više neskladnih rezultata je tačan može biti sporiji. Videti ovde za detaljne o parametrima bezbednosti.

Konsenzus sloj Oasis Mreže ne pokreće generalne pametne ugovore. Umesto, pravimo validating bridge funkcionalnost koje je inače instancirana kao pametni ugovor na Ethereum-zasnovanom rollup-u. Koristimo detekciju neslaganja da bismo validirali rezultate noda u sloju za računanje (ParaTime) zato što je efikasnije i opštije.

Da biste razumeli zašto je detekcija neslaganje efikasnija, uzmimo u obzir očekivano vreme koje je potrebno pre nego random selekcija računarskih članova komiteta omogući protivniku da kompromituje računanje. Ako od ukupnih 100 kandidata najviše 33 su Byzantine i mi random izaberemo 20 koji će služiti kao računarski komitet, čak i da se novi komitet bira po stopi od 100 000 po satu, protivnik koji kontroliše tih 33 Byzantine node će trebati da čeka 1066 godina pre nego što potpuni Byzantine komitet bude izabran i može da se iskoristi za napad na sistem. Obična Byzantine fault šema tolerancija može da koristi 100 puta replikaciju da bi došli do konsenzusa; ovde, mi repliciramo računanje samo 20 puta.

Detalji tehničke analize računice i zašto je discrepancy detection efikasniji mogu biti pronađeni ovde u appendix-u u našem whitepaper.

Zato što discrepancy detection samo poredi rezultate računanja, generalnije je nego bilo koja šema koja zahteva uporedbu među stanja putem single stepped izvršavanje, pristup koji koriste većina optimistic rollup dizajnova. Rad koji je potreban da završi discrepancy detection validirajući bridge ugovor u konsenzusnom sloju je mali, čineći ga lakšim da se proizvoljno poveća sistem pokretajući mnogo ParaTime-ova istovremeno za paralelno izvršavanje.

Proširivost za druge fraud/validity proof šeme

Zapazite, da dok konsenzus sloj Oasis Mreže ima ugrađen discrepancy detection, i dalje je arhitektonski proširiv da implementira druge rollup egzekucione tehnike validacije. Još uvek ne vidimo potrebu za tim.

Ako/kada zk-rollup proof šeme sazreju dovoljno za generalno računanje, zkSNARK verifier će biti odličan dodatak; jer su ugrađeni validirajući bridge-vi implementirani u pokretu, trebali bi da rade mnogo brže nego Solidity pametni ugovori.

Postoji još varijacija/dimenzija u fraud proof dizajn prostoru koje nisu pokrivene ovde. Pogledajte ovde za više informacija o fraud proof dizajnu.

Checkpointing

Discrepancy detection nam omogućava da podesimo parametar veličine komiteta da bismo bili sigurni u verovatnoću da ceo komitet neće biti kompromitovan. Ostaju dva problema:

1. Discrepancy Detection — ako se samo radi za komitet računanja, nije potpuno otvoren, jer da bi se kvalifikovali kao kandidati za računarsku nodu resurs limiti poput stake-a se zahtevaju da bi se sprečili Sybil napadi.
2. Common-Mode Failure-i, poput programerskih greški na Oasis Mreži ili Linux kernel-u, mogu dozvoliti neslaganjima da koriste zero-day compromise da preuzmu sva računanja — i konsenzus! — node mreže.

Briga o programerskim grešaka postoje za bilo koju mrežu, naravno, i nije unikatna za Oasis. Zapravo, verujemo da kod kvalitet Oasisa i procesi revizije su među najboljima.

Oktlanjanje zero-day vulnerability-a je teško. Zaista, poput svih software sistema, nijedan blockchain nema generalno rešenje osim možda hard fork-a. U Oasis-u, razmišljamo o katastrofičnim nesrećama — ekstremno malo verovatnim scenarijima poput all-committee compromise, zero-day vulnerability exploitation / common-mode failures, itd. —tako što razlikujemo transaction order determination itransaction result determination i dozvoljavamo bilo kome da izazove rezultate transakcija.

Šta ovo znači? Dodajemo secure logging periodičnih state checkpoint hash-ova i transaction ordering. Ovi podaci olakšavju da se replay-uje transakcija sa dobro poznatog checkpoint-a nakon što je katastrofalna greška identifikovana putem challange-a i oslovljenja.

Logging treba da bude monotonski/finalan jer uključujemo širok spekar napada/gubitak kontrole kriptografskih ključeva kao i potencijalnih failure modova. Ovo stanje može da se postigne pisanjem log-a do distribuiranih append-only ledger-a poput drugih blockchain-ova, npr., Ethereum; pisanjem fizičkom append-only medijumu, npr., a continuous-feed printer; pisanjem na write-once mediju (CD-R/DVD-R); pisanjem na mediju koji se periodično kopira na off-line backup servise; itd. Pisanje Ethereum-u će koristi Ethereum-ov finality da bi u suštini timestamp-ovala log record stavaranje, gde pisanje drugim append-only mehanizmima će zahtevati verifikaciju, npr., upoređivanje nezavisnih kopija, da mediji nisu nova nego izmenjena kopija legitimnog log-a. Videti Shades of Finality paper (uskoro će izaći) za dublju diskusiju order finality transakcije i state value finality.

Kada je ovo završeno, bilo ko može da izazove rezultate sa sloja računanja, čak nakon što je discrepancy detection prihvatio rezultate. Ovo znači da katastrofalne greške poput potpunog Byzantine komiteta ili zero-day vulnerability-a mogu da se reše ako se detektuju na vreme. Dok god postoji validan checkpoint stanja koji je pre katastrofalne greške, imamo poznato dobro stanje koje može da se koristi kao osnova za oporavak.

Preporučena polisa za nošenje sa katastrofalnom greškom je da se poštuje red transakcija. Ovo znači da ako challanger dokaže da je netačno stanje tranzicije izvršeno, možemo da replay logged transakcije prijavljene nakon da bi dobro poznato stanje izračunalo tačno trenutno stanje koristeći koliko god potrebno replikacija/verifikacija. Poput discrepancy detection-a dozovljavajući efikasni brzi put za nemanje discrepancy case protiv skupljih šema za nečeste slučajeve kada je neslaganje detektovano, checkpoint i replay da bi se oporavili od katastrofalnih grešaka mogu da budu skupi jer takve katastrofalne greške su očekivane da budu ekstremno malo verovatne.

Rezime

Arhitektura Oasis Mreže rezultira iz kodizajna između detekcije prevara i arhitekture sistema. Ovo modularno razdvajanje dužnosti između računarskog i konsenzusnog sloja, sa interfejsom između njih sačinjena je od prostih i efikasnih bare-meta fraud proof šema

Prednost Oasis dizajna:

• Čista, modularna arhitektura, čineći dizajn lakšim za razumevanje nego monolitični dizajnovi. Modularnost se prevodi u čistiju implementaciju, što čini revizije sigurnosti lakšim.
• Efikasna detekcija prevara, sa eksplicitnim sigurnosnim parametrima koji omogućavaju ParaTime dizajnerima da biraju odgovarajuće parametre za svoju primenu.
• Bare-metal fraud dokazi omogućavaju buduće razvoje visoko performansnog okruženja za izvršavanje pametnih ugovora poput sandbox-ovanog native koda, pravljenje računanja- ili pametni ugovori sa mnogo podataka izvodljivi u budućnosti
• Korisnici poznaju donju granicu kako se nezavisna verifikacija dešava, umesto da se nadaju da su validatori dostupni/operacioni tokom izazovnog perioda, kao u slučaju optimistic rollup-ova.

Rezultat je da je Oasis Mreža rollup-sličan blockchain, gde konsenzusni sloj samo pokreće validirajuće bridge ugovore. Više ParaTime-ova — nezavisne rollup virutalne mašine — imaju uspeh u pokretanju povrh Oasis konsenzus mreže. Trenutno,  pruža EVM-kompatiblna izvršavanja pametnih ugovora i  koji će pružiti okruženje za izvršavanje poverljivih pametnih ugovora, kada izađeu u Q1 2022.