Vitalik yangi maqola: Ethereum protokolining mumkin bo‘lgan kelajagi The Verge

Aslida, bizga Ethereum konsensusining haqiqiylik isbotini olish uchun bir necha yil kerak bo‘ladi.

Original sarlavha：《Possible futures of the Ethereum protocol, part 4: The Verge》

Muallif: Vitalik Buterin

Tarjima: Mensh, ChainCatcher

 

Maxsus minnatdorchilik Justin Drake, Hsia-wei Wanp, Guillaume Ballet, Icinacio, Rosh Rudolf, Lev Soukhanoy Ryan Sean Adams va Uma Royga fikr va ko‘rib chiqishlari uchun.

Blockchainning eng kuchli funksiyalaridan biri shundaki, har kim o‘z kompyuterida tugun ishga tushirishi va blockchainning to‘g‘riligini tekshirishi mumkin. Hatto 9596 ta konsensus (PoW, PoS) ishlayotgan tugunlar birdaniga qoidalarni o‘zgartirishga rozi bo‘lib, yangi qoidalarga ko‘ra bloklar ishlab chiqarishni boshlasalar ham, to‘liq tekshiruvchi tugun ishlatayotgan har bir kishi bu zanjirni qabul qilmaydi. Bunday fitnaga kirmagan minterlar avtomatik ravishda eski qoidalarga amal qiladigan zanjirga birlashadi va shu zanjirni qurishda davom etadi, to‘liq tekshiruvchi foydalanuvchilar esa shu zanjirga amal qiladi.

Bu blockchain va markazlashtirilgan tizimlar o‘rtasidagi asosiy farqdir. Biroq, bu xususiyat amal qilishi uchun, to‘liq tekshiruvchi tugunni ishlatish yetarlicha odamlar uchun haqiqatan ham mumkin bo‘lishi kerak. Bu minterlar uchun ham (chunki agar minterlar zanjirni tekshirmasa, ular protokol qoidalarini bajarishga hissa qo‘shmaydi), oddiy foydalanuvchilar uchun ham to‘g‘ri. Bugungi kunda, oddiy noutbukda (shu maqolani yozayotgan noutbuk ham shunday) tugun ishga tushirish mumkin, lekin bu juda qiyin. The Verge aynan shu vaziyatni o‘zgartirishga intiladi: to‘liq tekshiruvchi zanjir hisoblash xarajatini arzonlashtirish, har bir mobil hamyon, brauzer hamyon, hatto aqlli soat ham default tarzda tekshiruvchi bo‘lishini ta’minlash.

The Verge 2023 yo‘l xaritasi

Boshida, "Verge" Ethereum holat saqlashini Verkle daraxtiga o‘tkazishni anglatardi — bu Ethereum bloklarini statussiz tekshirish imkonini beruvchi, ixcham isbotlarni ta’minlaydigan daraxt tuzilmasi. Tugun Ethereum blokini tekshirishi mumkin, lekin o‘z diskida hech qanday Ethereum holatini (hisob balanslari, kontrakt kodi, saqlash joyi va h.k.) saqlamasdan, buning evaziga bir necha yuz KB isbot ma’lumotlari va bir necha yuz millisekund qo‘shimcha vaqt sarflaydi. Hozirda, Verge yanada kengroq tasavvurga ega bo‘lib, Ethereum zanjirini maksimal resurs samaradorligi bilan tekshirishga qaratilgan: bu faqat statussiz tekshirish texnologiyalarini emas, balki barcha Ethereum bajarilishini SNARK yordamida tekshirishni ham o‘z ichiga oladi.

Butun zanjirni SNARK yordamida tekshirishga uzoq muddatli e’tibor qaratilishidan tashqari, yana bir yangi muammo — Verkle daraxti eng yaxshi texnologiyami yoki yo‘qligi bilan bog‘liq. Verkle daraxtlari kvant kompyuterlar hujumiga zaif, shuning uchun agar biz hozirgi KECCAK Merkle Patricia daraxtini Verkle daraxtiga almashtirsak, keyinchalik yana daraxtni almashtirishimizga to‘g‘ri keladi. Merkle daraxtining o‘z-o‘zini almashtirish usuli — Merkle tarmoqlarini ishlatishni butunlay o‘tkazib yuborib, STARK yordamida uni ikkilik daraxtga joylashtirish. Tarixan, xarajat va texnik murakkablik sababli bu usul amalga oshmaydigan deb hisoblangan. Ammo yaqinda, Starkware oddiy noutbukda ckcle STARKs yordamida har soniyada 1.7 million Poseidon hashini isbotladi va GKB kabi texnologiyalar tufayli ko‘proq "an’anaviy" hashlarni isbotlash vaqti ham tez qisqarmoqda. Shuning uchun, o‘tgan yil davomida "Verge" yanada ochiq bo‘lib, bir nechta imkoniyatlarga ega bo‘ldi.

The Verge: asosiy maqsadlar

• Statussiz mijoz: to‘liq tekshiruvchi mijoz va marker tugun uchun zarur bo‘lgan saqlash joyi bir necha GBdan oshmasligi kerak.
• (Uzoq muddatli) Aqlli soatda zanjirni to‘liq tekshirish (konsensus va bajarilish). Bir oz ma’lumot yuklab olish, SNARKni tekshirish, tamom.

Ushbu bobda

• Statussiz mijoz: Verkle yoki STARKs
• EVM bajarilishining haqiqiylik isboti
• Konsensusning haqiqiylik isboti

Statussiz tekshirish: Verkle yoki STARKs

Qanday muammoni hal qilmoqchimiz?

Bugungi kunda, Ethereum mijozlari bloklarni tekshirish uchun yuzlab gigabayt holat ma’lumotlarini saqlashi kerak va bu miqdor har yili ortib bormoqda. Asl holat ma’lumotlari har yili taxminan 30GBga ortadi, har bir mijoz esa samarali tarzda uchlikni yangilash uchun qo‘shimcha ma’lumotlarni saqlashi kerak.

Bu to‘liq tekshiruvchi Ethereum tugunini ishga tushira oladigan foydalanuvchilar sonini kamaytiradi: garchi barcha Ethereum holatini va hatto bir necha yillik tarixni saqlashga yetadigan katta disklar keng tarqalgan bo‘lsa-da, odamlar odatda bir necha yuz gigabaytli kompyuterlar sotib olishadi. Holat hajmi tugunni birinchi marta ishga tushirish jarayonini ham ancha qiyinlashtiradi: tugun butun holatni yuklab olishi kerak, bu esa bir necha soat yoki kun talab qilishi mumkin. Bu turli zanjirli ta’sirlarni keltirib chiqaradi. Masalan, bu tugun ishlab chiqaruvchilar uchun tugun sozlamalarini yangilashni ancha qiyinlashtiradi. Texnik jihatdan, bu to‘xtamasdan amalga oshirilishi mumkin — yangi mijozni ishga tushirish, uni sinxronlashtirishni kutish, so‘ng eski mijozni o‘chirib, kalitlarni ko‘chirish — lekin amalda bu juda murakkab.

Bu qanday ishlaydi?

Statussiz tekshirish — bu tugunlarga butun holatga ega bo‘lmasdan bloklarni tekshirish imkonini beradigan texnologiya. Buning o‘rniga, har bir blok bilan birga guvohlik (witness) keladi, unda quyidagilar mavjud: (i) blok foydalanadigan holatdagi aniq joylarning qiymati, kod, balans, saqlash; (ii) bu qiymatlarning to‘g‘riligini tasdiqlovchi kriptografik isbot.

Amalda, statussiz tekshirishni amalga oshirish uchun Ethereumning holat daraxti tuzilmasini o‘zgartirish kerak. Chunki hozirgi Merkle Patricia daraxti har qanday kriptografik isbot sxemasini, ayniqsa eng yomon holatda, amalga oshirish uchun juda noqulay. Bu "asl" Merkle tarmoqlari uchun ham, STARKga "o‘ralgan" variantlar uchun ham to‘g‘ri. Asosiy qiyinchiliklar MPTning ba’zi zaifliklaridan kelib chiqadi:

1. Bu olti tarmoqli daraxt (ya’ni har bir tugunda 16 ta bolalar tuguni bor). Bu shuni anglatadiki, hajmi N bo‘lgan daraxtda, bitta isbot o‘rtacha 32*(16-1)*log16(N) = 120*log2(N) bayt, yoki 2^32 elementli daraxtda taxminan 3840 bayt bo‘ladi. Ikkilik daraxt uchun esa faqat 32*(2-1)*log2(N) = 32*log2(N) bayt, yoki taxminan 1024 bayt kerak bo‘ladi.

2. Kod Merkle qilinmagan. Bu shuni anglatadiki, hisob kodi uchun har qanday kirishni isbotlash uchun butun kodni taqdim etish kerak, maksimal 24000 bayt.

 

Eng yomon holatni quyidagicha hisoblashimiz mumkin:

30000000 gas / 2400 (sovuq hisob o‘qish narxi) * (5 * 488 + 24000) = 330000000 bayt

Tarmoq xarajati biroz kamayadi (5*480 o‘rniga 8*480 ishlatiladi), chunki ko‘p tarmoqli bo‘lsa, yuqori qismi takrorlanadi. Lekin baribir, bir slotda yuklab olinadigan ma’lumotlar hajmi mutlaqo real emas. Agar biz STARK yordamida buni o‘rashga harakat qilsak, ikki muammoga duch kelamiz: (i) KECCAK STARK uchun nisbatan noqulay; (ii) 330MB ma’lumot KECCAK round funksiyasiga 5 million chaqiruvni isbotlashimiz kerakligini anglatadi, bu esa eng kuchli iste’molchi uskunalaridan tashqari barcha uskunalar uchun isbotlab bo‘lmas, hatto KECCAK uchun STARK isbotini samaraliroq qila olsak ham.

Agar biz to‘g‘ridan-to‘g‘ri o‘n oltilik daraxtni ikkilik daraxtga almashtirsak va kodni qo‘shimcha Merkle qilish bilan, eng yomon holat taxminan 30000000/2400*32*(32-14+8) = 10400000 bayt bo‘ladi (14 — 2^14 tarmoq uchun ortiqcha bitlar, 8 esa kod blokidagi bargga kirish isbotining uzunligi). E’tibor bering, bu gas narxini o‘zgartirishni talab qiladi, har bir kod blokiga kirish uchun alohida to‘lov; EIP-4762 shunday qiladi. 10.4 MB ancha yaxshi, lekin ko‘plab tugunlar uchun bir slotda yuklab olinadigan ma’lumotlar hali ham ko‘p. Shuning uchun, kuchliroq texnologiyalar kerak. Bu borada ikki yetakchi yechim bor: Verkle daraxtlari va STARKed ikkilik hash daraxtlari.

Verkle daraxtlari

Verkle daraxtlari elliptik egri asosidagi vektor majburiyatlari yordamida qisqaroq isbotlarni ta’minlaydi. Kalit shundaki, daraxt kengligi qanday bo‘lishidan qat’i nazar, har bir ota-bola munosabati uchun isbot qismi faqat 32 bayt. Daraxt kengligining yagona cheklovi — agar daraxt juda keng bo‘lsa, isbot hisoblash samaradorligi pasayadi. Ethereum uchun taklif qilingan kenglik 256.

Shunday qilib, bitta tarmoqning isbotdagi hajmi 32 - 1og256(N) = 4*log2(N) baytga aylanadi. Shuning uchun, nazariy maksimal isbot hajmi taxminan 30000000 / 2400 *32* (32 -14 + 8) / 8 = 130000 bayt (holat bloklarining notekis taqsimoti tufayli haqiqiy natija biroz farq qiladi, lekin birinchi taxmin sifatida to‘g‘ri).

Yana bir eslatma: yuqoridagi barcha misollarda bu "eng yomon holat" aslida eng yomon holat emas: undan ham yomon holat — hujumchi ataylab daraxtda uzun umumiy prefiksga ega bo‘lgan ikki manzilni "qazib" olib, ulardan biridan ma’lumot o‘qiydi, bu esa eng yomon holatda tarmoq uzunligini 2 baravar oshirishi mumkin. Lekin hatto shunday bo‘lsa ham, Verkle daraxtining eng yomon isbot uzunligi 2.6MB, bu hozirgi eng yomon holatdagi tekshiruv ma’lumotiga deyarli teng.

Bundan tashqari, biz yana bir narsa qilamiz: "qo‘shni" saqlash joyiga kirish xarajatini juda arzon qilamiz: bu bir xil kontraktning ko‘plab kod bloklari yoki qo‘shni saqlash slotlari bo‘lishi mumkin. EIP-4762 qo‘shnichilik ta’rifini beradi va qo‘shni kirish uchun faqat 200 gas to‘lovini oladi. Qo‘shni kirishda, eng yomon holatda isbot hajmi 30000000 / 200*32 - 4800800 baytga aylanadi, bu ham taxminan bardoshlidir. Agar xavfsizlik uchun bu qiymatni kamaytirmoqchi bo‘lsak, qo‘shni kirish narxini biroz oshirishimiz mumkin.

STARKed ikkilik hash daraxti

Bu texnologiyaning mohiyati oddiy: siz faqat ikkilik daraxt tuzasiz, maksimal 10.4 MB isbot olasiz, blokdagi qiymatlarni isbotlaysiz, so‘ng isbot uchun STARKdan foydalanasiz. Shunday qilib, isbotning o‘zi faqat isbotlanayotgan ma’lumotlarni o‘z ichiga oladi, ustiga-ustak haqiqiy STARKdan 100-300kB doimiy xarajat qo‘shiladi.

Bu yerda asosiy muammo — tekshirish vaqti. Biz yuqoridagi kabi hisob-kitob qilamiz, faqat bayt emas, hash sonini hisoblaymiz. 10.4 MB blok 330000 hash degani. Agar hujumchi manzil daraxtida uzun umumiy prefiksga ega bo‘lgan manzillarni "qazib" olsa, eng yomon holatda hash soni 660000 ga yetadi. Agar har soniyada 200,000 hash isbotlansa, muammo yo‘q.

Poseidon hash funksiyasidan foydalanadigan oddiy noutbukda bu raqamlar allaqachon erishilgan, va Poseidon hash funksiyasi aynan STARK uchun qulaylik uchun ishlab chiqilgan. Lekin, Poseidon tizimi hali nisbatan yangi, shuning uchun ko‘pchilik uning xavfsizligiga ishonmaydi. Shuning uchun, ikki real yo‘l bor:

1. Poseidon uchun tezda ko‘plab xavfsizlik tahlillarini o‘tkazish va uni L1da joriy qilish uchun yetarlicha ishonch hosil qilish
2. SHA256 yoki BLAKE kabi "konservativ" hash funksiyalaridan foydalanish

Agar konservativ hash funksiyalarini isbotlash kerak bo‘lsa, Starkware’ning STARK doirasi bu maqola yozilayotgan paytda oddiy noutbukda har soniyada 10-30k hash isbotlay oladi. Lekin, STARK texnologiyasi tez rivojlanmoqda. Hatto bugun ham, GKR asosidagi texnologiyalar bu tezlikni 100-200k oralig‘iga olib chiqmoqda.

Blokdan tashqari guvohlik (witness) ishlatish holatlari

Blokni tekshirishdan tashqari, yana uchta muhim holat bor, ular uchun samaraliroq statussiz tekshirish kerak:

• Mempool: tranzaksiya uzatilganda, P2P tarmoqdagi tugunlar uni qayta uzatishdan oldin tranzaksiyaning haqiqiyligini tekshirishi kerak. Bugun tekshirishga imzo tekshirish, balans yetarliligi va prefiks to‘g‘riligi kiradi. Kelajakda (masalan, EIP-7701 kabi native account abstraction ishlatilsa), bu ba’zi EVM kodini ishga tushirishni talab qilishi mumkin, bu esa holatga kirishni o‘z ichiga oladi. Agar tugun statussiz bo‘lsa, tranzaksiya holat obyektining isboti bilan birga kelishi kerak.
• Inclusion list: bu taklif etilgan funksiya bo‘lib, (kichik va sodda bo‘lishi mumkin bo‘lgan) proof-of-stake validatorlariga keyingi blokka tranzaksiyani kiritishni majburlash imkonini beradi, (katta va murakkab bo‘lishi mumkin bo‘lgan) blok quruvchilarining xohishiga qaramay. Bu kuchlilarning blokcheynni tranzaksiyani kechiktirish orqali manipulyatsiya qilish imkoniyatini kamaytiradi. Lekin, validatorlar inclusion listdagi tranzaksiyaning haqiqiyligini tekshirish imkoniga ega bo‘lishi kerak.
• Yengil mijoz: agar foydalanuvchilar zanjirga hamyon orqali kirishini istasak (masalan, Metamask, Rainbow, Rabby va boshqalar), ular yengil mijoz (masalan, Helios) ishlatishi kerak. Helios asosiy moduli foydalanuvchiga tekshirilgan holat ildizini beradi. To‘liq ishonchsiz tajriba uchun, foydalanuvchi har bir RPC chaqiruvi uchun isbot taqdim qilishi kerak (masalan, eth_call so‘rovi uchun foydalanuvchi chaqiruvda kirilgan barcha holatni isbotlashi kerak).

Bu holatlarning barchasida umumiy jihat bor: ular ko‘p isbot talab qiladi, lekin har bir isbot kichik. Shuning uchun, ular uchun STARK isbotlari amalda ma’nosiz; eng real yondashuv — to‘g‘ridan-to‘g‘ri Merkle tarmoqlaridan foydalanish. Merkle tarmoqlarining yana bir afzalligi — yangilanadiganligi: agar sizda blok B ildiziga asoslangan holat obyektining isboti bo‘lsa, B2 sub-blok va uning guvohligi kelganda, isbotni B2 ildiziga yangilash mumkin. Verkle isbotlari ham tabiatan yangilanadi.

Mavjud tadqiqotlar bilan qanday bog‘liq:

• Verkle trees
• John Kuszmaul’ning Verkle daraxti haqidagi original maqolasi
• Starkware
• Poseidon2 paper
• Ajtai (lattice qiyinligiga asoslangan tezkor hash funksiyalari uchun muqobil)
• Verkle.info

Yana nima qilish mumkin?

Qolgan asosiy ishlar quyidagilar:

1. EIP-4762 natijalari bo‘yicha ko‘proq tahlil (statussiz gas narxi o‘zgarishi)

2. O‘tish dasturini yakunlash va sinovdan o‘tkazish bo‘yicha ko‘proq ish, bu statussiz muhitni joriy qilishdagi asosiy murakkablik

3. Poseidon, Ajtai va boshqa "STARK-friendly" hash funksiyalari bo‘yicha ko‘proq xavfsizlik tahlili

4. "Konservativ" (yoki "an’anaviy") hash uchun Binius yoki GKR asosidagi yondashuvlar kabi ultra samarali STARK protokoli funksiyalarini yanada rivojlantirish.

Bundan tashqari, tez orada quyidagi uch variantdan birini tanlashga qaror qilamiz: (i) Verkle daraxti, (ii) STARK-friendly hash funksiyasi va (iii) konservativ hash funksiyasi. Ularning xususiyatlari quyidagi jadvalda umumlashtirilgan:

Bu "asosiy raqamlar"dan tashqari, yana bir nechta muhim omillar bor:

• Bugungi kunda, Verkle daraxti kodi ancha yetuk. Verkle’dan boshqa kodlardan foydalanish joriy etishni kechiktiradi, ehtimol hard forkni ham kechiktiradi. Bu ham muammo emas, ayniqsa hash funksiyalarini tahlil qilish yoki validatorlarni joriy qilish uchun qo‘shimcha vaqt kerak bo‘lsa yoki Ethereumga boshqa muhim funksiyalarni tezroq kiritmoqchi bo‘lsak.
• Hash asosida holat ildizini yangilash Verkle daraxtiga qaraganda tezroq. Bu hash asosidagi yondashuvlar to‘liq tugunlar uchun sinxronizatsiya vaqtini qisqartiradi degani.
• Verkle daraxtlari guvohlik yangilashning qiziqarli xususiyatiga ega — Verkle guvohliklari yangilanadi. Bu xususiyat mempool, inclusion list va boshqa holatlar uchun foydali, shuningdek, amalga oshirish samaradorligini oshirishga yordam berishi mumkin: agar holat obyekti yangilansa, guvohlikning so‘nggi qatlamini o‘qimasdan oldingi qatlamini yangilash mumkin.
• Verkle daraxtlari SNARK isbotini qilishda qiyinroq. Agar isbot hajmini bir necha ming baytgacha qisqartirmoqchi bo‘lsak, Verkle isbotlari qiyinchilik tug‘diradi. Chunki Verkle isbotini tekshirishda ko‘plab 256 bitli amallar paydo bo‘ladi, bu esa isbot tizimidan katta xarajat yoki o‘z ichki tuzilmasida 256 bitli Verkle isbot qismini talab qiladi. Bu statussizlik uchun muammo emas, lekin ko‘proq qiyinchilik tug‘diradi.

Agar Verkle guvohlik yangilanishini kvantga chidamli va yetarlicha samarali usulda olishni istasak, yana bir yo‘l — lattice asosidagi Merkle daraxtidan foydalanish.

Agar eng yomon holatda isbot tizimi yetarlicha samarali bo‘lmasa, ko‘p o‘lchovli gas kabi kutilmagan vositadan foydalanishimiz mumkin: (i) calldata; (ii) hisoblash; (iii) holatga kirish va boshqa resurslar uchun alohida gas cheklovlari belgilash. Ko‘p o‘lchovli gas murakkablikni oshiradi, lekin evaziga o‘rtacha va eng yomon holat o‘rtasidagi nisbatni qat’iy cheklaydi. Ko‘p o‘lchovli gas bilan, nazariy maksimal tarmoq soni 12500dan, masalan, 3000gacha kamayishi mumkin. Bu BLAKE3ni bugun ham (zo‘rg‘a) yetarli qiladi.

Ko‘p o‘lchovli gas blok resurs cheklovlarini apparat resurs cheklovlariga yaqinlashtiradi

Yana bir kutilmagan vosita — holat ildizini blokdan keyingi slotga kechiktirish. Shunday qilib, holat ildizini hisoblash uchun to‘liq 12 soniya vaqtimiz bo‘ladi, bu eng ekstremal holatda ham har soniyada 60000 hash isbotlash uchun yetarli, bu esa yana BLAKE3ni zo‘rg‘a talabga javob beradi degan fikrga olib keladi.

Bu usulning kamchiligi — yengil mijoz uchun bir slot kechikish qo‘shiladi, lekin yanada aqlli texnologiyalar bu kechikishni faqat isbot yaratish kechikishigacha qisqartirishi mumkin. Masalan, isbot har qanday tugunda yaratilgach, darhol tarmoqqa uzatilishi mumkin, keyingi blokni kutmasdan.

Bu yo‘l xaritasining boshqa qismlari bilan qanday o‘zaro ta’sir qiladi?

Statussiz muammoni hal qilish yakka stakingni ancha osonlashtiradi. Agar yakka staking uchun minimal balansni kamaytiradigan texnologiya bo‘lsa, masalan, Orbit SSF yoki ilova darajasidagi strategiyalar, masalan, squad staking, bu yanada mumkin bo‘ladi.

Agar bir vaqtda EOF joriy qilinsa, ko‘p o‘lchovli gas tahlili ancha osonlashadi. Chunki ko‘p o‘lchovli gasdagi asosiy bajarilish murakkabligi — barcha gasni ota chaqiruvga o‘tkazmaydigan bola chaqiruvlarni qayta ishlash. EOF esa bunday chaqiruvlarni noqonuniy qilib, bu muammoni ahamiyatsiz qiladi (va native account abstraction qisman gas uchun asosiy foydalanish holatiga protokol ichida muqobil beradi).

Statussiz tekshirish va tarixni eskirish o‘rtasida ham muhim sinergiya bor. Bugun, mijozlar deyarli 1TB tarixiy ma’lumotlarni saqlashi kerak; bu holat ma’lumotidan bir necha barobar ko‘p. Hatto mijoz statussiz bo‘lsa ham, agar mijoz tarixiy ma’lumotlarni saqlash majburiyatidan ozod qilinmasa, deyarli nol saqlashli mijoz orzusi amalga oshmaydi. Bu borada birinchi qadam — EIP-4444, bu ham tarixiy ma’lumotlarni torrents yoki Portal Networkda saqlashni anglatadi.

EVM bajarilishining haqiqiylik isboti

Qanday muammoni hal qilmoqchimiz?

Ethereum blokini tekshirishning uzoq muddatli maqsadi aniq — Ethereum blokini quyidagicha tekshirish mumkin bo‘lishi kerak: (i) blokni yuklab olish yoki hatto faqat blokdagi ma’lumot mavjudligi samplingining kichik qismini yuklab olish; (ii) blok haqiqiyligini tasdiqlovchi kichik isbotni tekshirish. Bu juda kam resurs talab qiladigan operatsiya bo‘lib, mobil mijoz, brauzer hamyonida, hatto boshqa zanjirda (ma’lumot mavjudligi qismi bo‘lmasa) amalga oshirilishi mumkin.

Bunga erishish uchun (i) konsensus qatlami (ya’ni, proof-of-stake) va (ii) bajarilish qatlami (ya’ni, EVM) uchun SNARK yoki STARK isboti kerak. Birinchisi o‘zi ham muammo, va konsensus qatlamini doimiy takomillashtirish jarayonida hal qilinadi (masalan, single-slot finality uchun). Ikkinchisi esa EVM bajarilishining isbotini talab qiladi.

Bu nima va qanday ishlaydi?

Formal tarzda, Ethereum spetsifikatsiyasida EVM holat o‘zgartirish funksiyasi sifatida aniqlangan: sizda oldingi holat S, blok B bor, siz keyingi holat S' = STF(S, B) ni hisoblayapsiz. Agar foydalanuvchi yengil mijoz ishlatsa, ular S va S'ni to‘liq egallamagan, hatto E ham emas; ular oldingi holat ildizi R, keyingi holat ildizi R' va blok hashiga H ega.

• Ommaviy kirish: oldingi holat ildizi R, keyingi holat ildizi R', blok hashi H
• Maxfiy kirish: blok tanasi B, blok Q kiradigan holatdagi obyektlar, blok Q' bajarilgandan keyingi obyektlar, holat isbotlari (masalan, Merkle tarmoqlari) P
• Talab 1: P — bu Q R tomonidan ifodalangan holatning ba’zi qismlarini o‘z ichiga olishini isbotlovchi haqiqiy isbot
• Talab 2: Agar STF Qda ishlatilsa, (i) bajarilish jarayoni faqat Q ichidagi obyektlarga kiradi, (ii) blok haqiqiy, (iii) natija Q'
• Talab 3: Agar Q' va P ma’lumotidan yangi holat ildizini qayta hisoblasak, R' hosil bo‘ladi

Agar shunday bo‘lsa, to‘liq tekshiruvchi Ethereum EVM bajarilishini yengil mijozda olish mumkin. Bu mijoz resurslarini ancha kamaytiradi. To‘liq tekshiruvchi Ethereum mijoziga erishish uchun konsensus bo‘yicha ham xuddi shunday ish qilish kerak.

EVM hisoblashining haqiqiylik isboti implementatsiyalari allaqachon mavjud va L2da keng qo‘llanilmoqda. Lekin EVM haqiqiylik isbotini L1da amalga oshirish uchun hali ko‘p ish qilish kerak.

Mavjud tadqiqotlar bilan qanday bog‘liq?

• EFPSE ZK-EVM (yaxshiroq variantlar mavjudligi sababli to‘xtatilgan)
• Zeth, EVMni RISC-0 ZK-VMga kompilyatsiya qiladi
• ZK-EVM formal verification loyihasi

Yana nima qilish mumkin?

Bugungi kunda, elektron hisob-kitob tizimining haqiqiylik isboti ikki jihatdan yetarli emas: xavfsizlik va tekshirish vaqti.

Xavfsiz haqiqiylik isboti SNARK haqiqatan ham EVM hisoblashini tekshirganini va hech qanday zaiflik yo‘qligini kafolatlashni talab qiladi. Xavfsizlikni oshirishning ikki asosiy texnologiyasi — ko‘p validator va formal verification. Ko‘p validator — bu bir nechta mustaqil haqiqiylik isboti implementatsiyalari bo‘lishi, xuddi bir nechta mijozlar bo‘lgani kabi, agar blok ushbu implementatsiyalarning yetarlicha katta qismi tomonidan isbotlansa, mijoz blokni qabul qiladi. Formal verification — bu odatda matematik teoremalarni isbotlash uchun ishlatiladigan vositalardan, masalan, Lean4dan foydalanib, haqiqiylik isboti faqat to‘g‘ri bajarilgan EVM spetsifikatsiyasini (masalan, EVM K semantics yoki python’da yozilgan Ethereum Execution Layer Specification (EELS)) qabul qilishini isbotlash.

Yetarlicha tez tekshirish vaqti — har qanday Ethereum bloki 4 soniyadan kam vaqtda tekshirilishi kerak. Bugun bu maqsaddan ancha uzoqmiz, lekin ikki yil oldingiga qaraganda ancha yaqinmiz. Bu maqsadga erishish uchun uch yo‘nalishda taraqqiyot kerak:

• Parallelizatsiya — hozirgi eng tez EVM validator o‘rtacha 15 soniyada Ethereum blokini isbotlaydi. Bu yuzlab GPUlar o‘rtasida parallelizatsiya orqali, so‘ng ularning ishini birlashtirish orqali amalga oshiriladi. Nazariy jihatdan, hisoblashni O(log(N)) vaqtda isbotlaydigan EVM validatorini yaratishni bilamiz: har bir bosqichni bitta GPU bajaradi, so‘ng "agregatsiya daraxti" qilinadi:

Buni amalga oshirishda qiyinchiliklar bor. Eng yomon holatda, ya’ni juda katta tranzaksiya butun blokni egallasa, hisoblashni bo‘lish operatsiyalar (EVM yoki RISC-V kabi past darajadagi VM opcode) bo‘yicha bo‘lish kerak. Virtual mashinaning "xotirasi" isbotning turli qismlari o‘rtasida bir xil bo‘lishini ta’minlash — amalga oshirishda asosiy muammo. Lekin, agar biz bunday rekursiv isbotni amalga oshira olsak, boshqa jihatlar yaxshilanishidan qat’i nazar, validator kechikish muammosi hal bo‘ladi.

• Isbot tizimi optimizatsiyasi — yangi isbot tizimlari, masalan, Orion, Binius, GRK va boshqalar, umumiy hisoblashni tekshirish vaqtini yana qisqartirishi mumkin.
• EVM gas narxining boshqa o‘zgarishlari — EVMda ko‘plab narsalarni optimallashtirish mumkin, ayniqsa eng yomon holatda validator uchun qulayroq qilish. Agar hujumchi validatorni o‘n daqiqa band qiladigan blok tuza olsa, oddiy Ethereum blokini 4 soniyada isbotlash yetarli emas. Zarur EVM o‘zgarishlari quyidagi toifalarga bo‘linadi:
• Gas narxining o‘zgarishi — agar operatsiyani isbotlash uzoq vaqt olsa, hisoblash tez bo‘lsa ham, gas narxi yuqori bo‘lishi kerak. EIP-7667 bu boradagi eng jiddiy muammoni hal qilish uchun taklif qilingan: u (an’anaviy) hash funksiyalarining gas narxini ancha oshiradi, chunki bu funksiyalarning opcode va precompiledlari nisbatan arzon. Bu gas narxining oshishini qoplash uchun, isbot narxi past bo‘lgan EVM opcode’larning gas narxini kamaytirish mumkin, o‘rtacha throughputni o‘zgartirmasdan.
• Ma’lumot tuzilmasini almashtirish — holat daraxtini STARK uchun qulayroq usulga almashtirishdan tashqari, tranzaksiya ro‘yxati, kvitansiya daraxti va boshqa isbot narxi yuqori tuzilmalarni ham almashtirish kerak. Etan Kisslingning tranzaksiya va kvitansiya tuzilmasini SSZga o‘tkazish bo‘yicha EIP — bu yo‘nalishda qilingan qadam.

Bundan tashqari, yuqoridagi ikki vosita (ko‘p o‘lchovli gas va kechiktirilgan holat ildizi) ham bu borada yordam beradi. Lekin, statussiz tekshirishdan farqli o‘laroq, bu ikki vositadan foydalanish hozirgi ehtiyojlarimizni qondirish uchun yetarli texnologiyaga ega ekanligimizni anglatadi, lekin to‘liq ZK-EVM tekshiruvi uchun ko‘proq ish kerak — faqat kamroq ish kerak bo‘ladi.

Yuqorida aytilmagan jihat — validator apparati: isbotlarni tezroq yaratish uchun GPU, FPGA va ASICdan foydalanish. Fabric Cryptography, Cysic va Accseal bu borada taraqqiyot qilayotgan uch kompaniya. Bu L2 uchun juda qimmatli, lekin L1 uchun hal qiluvchi omil bo‘lishi ehtimoldan yiroq, chunki L1 yuqori darajada markazsiz bo‘lishi kerak, bu esa isbot yaratish Ethereum foydalanuvchilari uchun yetarlicha ochiq bo‘lishi, bitta kompaniya apparatiga bog‘liq bo‘lmasligi kerak. L2 esa yanada agressiv muvozanat qilishi mumkin.

Bu sohalarda yana ko‘proq ish qilish kerak:

• Parallelizatsiya isbot tizimining turli qismlari "xotirani bo‘lishishi" (masalan, lookup table) mumkin bo‘lishini talab qiladi. Bunday qilish texnologiyasi bor, lekin amalga oshirish kerak.
• Eng yaxshi gas narxi o‘zgarishlarini aniqlash uchun ko‘proq tahlil qilish kerak, shunda eng yomon holatda tekshirish vaqti minimal bo‘ladi.
• Isbot tizimi bo‘yicha ko‘proq ish qilish kerak

Ehtimoliy narxlar:

• Xavfsizlik va validator vaqti: agar yanada agressiv hash funksiyasi, murakkabroq isbot tizimi yoki agressiv xavfsizlik taxminlari yoki boshqa dizayn tanlansa, validator vaqti qisqarishi mumkin.
• Markazsizlik va validator vaqti: jamiyat validator apparatining "spetsifikatsiyasi" bo‘yicha kelishib olishi kerak. Validatorlar yirik subyektlar bo‘lishi mumkinmi? Biz yuqori darajadagi iste’molchi noutbukda Ethereum blokini 4 soniyada isbotlashni xohlaymizmi? Yoki oraliq variant?
• Orqaga moslikni buzish darajasi: boshqa kamchiliklarni yanada agressiv gas narxi o‘zgarishlari bilan qoplash mumkin, lekin bu ayrim ilovalarning xarajatini nomutanosib oshirishi, ishlab chiquvchilarni kodni qayta yozish va qayta joylashtirishga majbur qilishi mumkin. Xuddi shu tarzda, bu ikki vosita ham o‘z murakkabligi va kamchiliklariga ega.

Bu yo‘l xaritasining boshqa qismlari bilan qanday o‘zaro ta’sir qiladi?

L1 EVM haqiqiylik isbotini amalga oshirish uchun zarur asosiy texnologiyalar asosan yana ikki soha bilan umumiy:

• L2 haqiqiylik isboti (ya’ni, "ZK rollup")
• Statussiz "STARK ikkilik hash isboti" usuli

L1da haqiqiylik isbotini muvaffaqiyatli amalga oshirish yakka stakingni osonlashtiradi: eng zaif kompyuterlar (shu jumladan, telefon yoki aqlli soat) ham staking qilishi mumkin. Bu yakka stakingning boshqa cheklovlarini (masalan, 32ETH minimal chegarasi) hal qilish qiymatini yanada oshiradi.

Bundan tashqari, L1 EVM haqiqiylik isboti L1 gas limitini ancha oshirishi mumkin.

Konsensusning haqiqiylik isboti

Qanday muammoni hal qilmoqchimiz?

Agar biz SNARK yordamida Ethereum blokini to‘liq tekshirmoqchi bo‘lsak, EVM bajarilishi yagona isbotlanishi kerak bo‘lgan qism emas. Bizga konsensusni ham isbotlash kerak, ya’ni tizimda depozitlar, yechib olishlar, imzolar, validator balanslarini yangilash va Ethereum proof-of-stake qismining boshqa elementlarini boshqaradigan qism.

Konsensus EVMga qaraganda ancha sodda, lekin muammo shundaki, bizda L2 EVM konvolyutsiyasi yo‘q, shuning uchun baribir asosiy ishni bajarish kerak. Shuning uchun, Ethereum konsensusini isbotlash implementatsiyasi "noldan" boshlanishi kerak, garchi isbot tizimi o‘zi umumiy ish asosida qurilishi mumkin.

Bu nima va qanday ishlaydi?

Beacon chain ham EVM kabi holat o‘zgartirish funksiyasi sifatida aniqlangan. Holat o‘zgartirish funksiyasi asosan uch qismdan iborat:

• ECADD (BLS imzolarini tekshirish uchun)
• Pairing (BLS imzolarini tekshirish uchun)
• SHA256 hash (holatni o‘qish va yangilash uchun)

Har bir blokda, har bir validator uchun 1-16 ta BLS12-381 ECADD isbotlash kerak (bir nechta bo‘lishi mumkin, chunki imzolar bir nechta to‘plamda bo‘lishi mumkin). Bu subset precomputation texnologiyasi yordamida bartaraf etilishi mumkin, shuning uchun har bir validator uchun bitta BLS12-381 ECADD isbotlash kerak deb aytish mumkin. Hozirda har bir slotda 30000 validator imzosi bor. Kelajakda, single-slot finality amalga oshirilganda, bu ikki yo‘nalishda o‘zgarishi mumkin: agar "brute force" yo‘li tanlansa, har bir slotda validatorlar soni 1 millionga yetishi mumkin. Shu bilan birga, Orbit SSF ishlatilsa, validatorlar soni 32768da yoki hatto 8192da qoladi.

BLS agregatsiyasi qanday ishlaydi: umumiy imzoni tekshirish uchun har bir ishtirokchi uchun bitta ECADD kerak, ECMUL emas. Lekin 30000 ta ECADD hali ham katta isbot hajmi.

Pairing bo‘yicha, hozirda har bir slotda maksimal 128 ta isbot bor, bu 128 ta pairingni tekshirish kerak degani. EIP-7549 va boshqa o‘zgartirishlar bilan har bir slotda 16 taga kamaytirish mumkin. Pairing soni kam, lekin xarajati juda yuqori: har bir pairingni bajarish (yoki isbotlash) ECADDga qaraganda minglab marta ko‘proq vaqt oladi.

BLS12-381 amallarini isbotlashdagi asosiy muammo — BLS12-381 maydon o‘lchamiga teng bo‘lgan egri yo‘qligi, bu har qanday isbot tizimiga katta xarajat qo‘shadi. Boshqa tomondan, Ethereum uchun taklif qilingan Verkle daraxti Bandersnatch egri asosida qurilgan, bu esa BLS12-381ni SNARK tizimida Verkle tarmoqlarini isbotlash uchun o‘z egri sifatida ishlatishga imkon beradi. Oddiy implementatsiya har soniyada 100 G1 qo‘shishni isbotlashi mumkin; isbot tezligini yetarlicha oshirish uchun, deyarli aniqki, GKR kabi ilg‘or texnologiyalar kerak bo‘ladi.

SHA256 hash uchun, hozirgi eng yomon holat — epoch transition block, butun validator short balance tree va ko‘plab validator balanslari yangilanadi. Har bir validatorning short balance tree’si faqat bitta bayt, shuning uchun 1 MB ma’lumot qayta hash qilinadi. Bu 32768 ta SHA256 chaqiruviga teng. Agar mingta validator balansi thresholddan yuqori yoki past bo‘lsa, validator yozuvlaridagi effective balance yangilanadi, bu mingta Merkle tarmog‘iga teng, shuning uchun o‘n mingta hash kerak bo‘lishi mumkin. Shuffle mexanizmi har bir validator uchun 90 bit (11 MB ma’lumot) talab qiladi, lekin bu epochning istalgan vaqtida hisoblanishi mumkin. Single-slot finalityda bu raqamlar o‘zgarishi mumkin. Shuffle kerak bo‘lmaydi, lekin Orbit uni qisman qaytarishi mumkin.

Yana bir muammo — har bir blokni tekshirish uchun barcha validator holatini, jumladan, public keylarni qayta olish kerak. 1 million validator uchun faqat public keylarni o‘qish 48 million bayt, ustiga-ustak Merkle tarmoqlari. Bu har bir epoch uchun millionlab hashlarni talab qiladi. Agar biz PoS haqiqiyligini isbotlashimiz kerak bo‘lsa, real usul — isbot tizimida alohida ma’lumot tuzilmasini saqlash, u samarali qidiruv va yangilanishni isbotlash uchun optimallashtirilgan bo‘lishi kerak.

Xulosa qilib aytganda, muammolar ko‘p. Bu muammolarni eng samarali hal qilish uchun, beacon chainni chuqur qayta loyihalash kerak bo‘lishi mumkin, bu single-slot finalityga o‘tish bilan birga amalga oshiriladi. Bunday qayta loyihalash quyidagilarni o‘z ichiga olishi mumkin:

• Hash funksiyasini o‘zgartirish: hozirda "to‘liq" SHA256 hash ishlatiladi, shuning uchun padding sababli har bir chaqiruv ikki marta asosiy compression function chaqiruviga to‘g‘ri keladi. Agar SHA256 compression function ishlatilsa, kamida 2 barobar yutuq bo‘ladi. Agar Poseidon ishlatilsa, 100 barobar yutuq bo‘lishi mumkin, bu barcha muammolarimizni (kamida hash bo‘yicha) hal qiladi: har soniyada 1.7 million hash (54MB), hatto 1 million validator yozuvini bir necha soniyada "o‘qish" mumkin.
• Agar Orbit bo‘lsa, shuffle qilingan validator yozuvlarini to‘g‘ridan-to‘g‘ri saqlash: agar ma’lum miqdordagi validatorlar (masalan, 8192 yoki 32768) slot uchun komitet sifatida tanlansa, ularni holatda yonma-yon joylashtirish, shunda barcha validator public keylarini isbotga o‘qish uchun minimal hash kerak bo‘ladi. Bu barcha balans yangilanishlarini ham samarali qiladi.
• Imzo agregatsiyasi: har qanday yuqori samarali imzo agregatsiyasi sxemasi rekursiv isbotni o‘z ichiga oladi, tarmoqdagi turli tugunlar imzo subto‘plamlari uchun oraliq isbot qiladi. Bu isbot ishini tarmoqdagi bir nechta tugunlarga bo‘lib beradi, "yakuniy isbotlovchi" ishini ancha kamaytiradi.
• Boshqa imzo sxemalari: Lamport+ Merkle imzolari uchun imzoni tekshirish uchun 256 + 32 hash kerak; 32768 imzo qiluvchi uchun 9437184 hash. Imzo sxemasini optimallashtirgach, bu natijani kichik doimiy omil bilan yaxshilash mumkin. Agar Poseidon ishlatilsa, bu bitta slot ichida isbotlanadi. Lekin amalda, rekursiv agregatsiya sxemasi tezroq bo‘ladi.

Mavjud tadqiqotlar bilan qanday bog‘liq?

• Ethereum konsensusining qisqa isboti (faqat sync komitet uchun)
• SP1 ichidagi qisqa Helios
• Qisqa BLS12-381 precompiled
• Halo2 asosidagi BLS agregat imzo tekshiruvi

Yana nima qilish kerak, qanday muvozanat:

Aslida, bizga Ethereum konsensusining haqiqiylik isbotini olish uchun bir necha yil kerak bo‘ladi. Bu single-slot finality, Orbit, imzo algoritmini o‘zgartirish va xavfsizlik tahlili uchun zarur vaqt bilan deyarli bir xil, xavfsizlik tahlili esa Poseidon kabi "agressiv" hash funksiyalaridan foydalanishga yetarlicha ishonch hosil qilish uchun kerak. Shuning uchun, eng oqilona yondashuv — bu boshqa muammolarni hal qilish va ularni hal qilayotganda STARK uchun qulaylikni hisobga olish.

Asosiy muvozanat, ehtimol, operatsiyalar ketma-ketligida, Ethereum konsensus qatlamini isloh qilishda bosqichma-bosqich va ko‘proq "bir yo‘la ko‘p narsani o‘zgartirish" usullari o‘rtasida bo‘ladi. EVM uchun bosqichma-bosqich yondashuv mantiqan to‘g‘ri, chunki u orqaga moslikka kamroq ta’sir qiladi. Konsensus qatlami uchun esa, orqaga moslik ta’siri kamroq, va beacon chainni qurishning turli tafsilotlarini yanada "to‘liq" qayta ko‘rib chiqish, SNARK uchun qulaylikni optimal tarzda oshirish uchun foydali bo‘lishi mumkin.

Bu yo‘l xaritasining boshqa qismlari bilan qanday o‘zaro ta’sir qiladi?

Ethereum PoSni uzoq muddatli qayta loyihalashda, STARK uchun qulaylik birinchi o‘rinda bo‘lishi kerak, ayniqsa single-slot finality, Orbit, imzo sxemasi o‘zgarishi va imzo agregatsiyasi uchun.