Стан зводных рашэнняў для ўзаемадзеяння

Як энтузіяст экасістэмы, арыентаванай на аб'яднанне, мяне заўсёды цікавілі рашэнні, якія паляпшаюць узаемадзеянне аб'яднання. Больш за тое, адзінай прычынай, па якой я стварыў гэтую даследчую справаздачу, было прасоўванне ў гэтай галіне. Тады я зразумеў, што напісанне артыкулаў - выдатны спосаб замацаваць сваё разуменне пэўнай тэмы і дапамагчы людзям зразумець яе, і вось я тут. паведамлення аб важнасці ўзаемадзеяння Паколькі кожны дзень у крыптаграфіі вучацца новыя рэчы, павінна здацца відавочным, што сёння я лічу бачанне эпохі мяне як даволі састарэлае. З пункту гледжання філасофіі POV я па-ранейшаму прытрымліваюся таго ж бачання**: узаемадзеянне сумяшчальнасці з'яўляецца абсалютна важным для будучыні Ethereum**, і ўся экасістэма павінна працаваць над рашэннямі, якія яе паляпшаюць. Аднак з POV тэхналогій я даведаўся шмат новых ідэй на гэтую тэму і змяніў сваё меркаванне наконт некаторых рэчаў. «ўзаемадзеянне зводнага пакета мае вырашальнае значэнне для будучыні Ethereum» Каб зразумець прыведзены ніжэй матэрыял, карысна мець базавыя ўяўленні аб зводных пакетах і праблеме іх узаемадзеяння. Калі вы гэтага не зробіце, мой артыкул - выдатнае ўвядзенне. “Dr. Dankshard або Як я навучыўся перастаць турбавацца і палюбіць зводныя пакеты“ Мерхаба! Сёння вечар 13 лістапада, першы дзень . Як вялікі прыхільнік , я вырашыў наведаць zkSync Connect як сваё першае мерапрыемства на гэтым саміце, першае ў маім жыцці. Там я пазнаёмілася з хлопцам, і мы разам накіраваліся ў «Mosyo Coffee», як сказана на Luma-старонцы zkCafe. У тым раёне іх было двое, і толькі да вечара мы знайшлі патрэбнае месца. Devconnect Istanbul ZkSync Было значна цямней, чым на фота вышэй, і ліў дождж. Застаўшыся ля краю даху, на якім размяшчаўся фудкорт, і выпіўшы кавы, якую мы набылі за бясплатныя жэтоны на , я распавёў свайму новаму сябру пра сваю ідэю праекта хакатона. Clave Ёсць «міні-акаўнты»: уліковыя запісы , логіка пацверджання якіх заключаецца не ў праверцы подпісу, а ў існаванні хэша аперацыі ў адзіным мосце ўваходных паштовых скрынь на яго L2. Хэш павінен быць адпраўлены з бацькоўскага адраса ў пэўнай зыходнай ланцужку. Бацькоўскі адрас - гэта ваш асноўны разумны кашалёк на любым L2 або Ethereum L1. Каб узаемадзейнічаць з іншым L2, вы: ERC-4337 Разгарніце на ім міні-рахунак і ўсталюйце галоўны кашалёк у якасці бацькоўскага адрасу. Любы можа зрабіць разгортванне; такім чынам, ён можа фінансавацца пратаколам або вашым пастаўшчыком кашалька. Адпраўце хэш карыстальніцкай аперацыі, якую вы хочаце адправіць, у паштовую скрыню на вашым L2 і ўсталюйце ідэнтыфікатар ланцужка прызначэння. Гэты хэш аб'ядноўваецца з іншымі хэшамі і адпраўляецца ў L1. Смарт-кантракт на L1 перанакіроўвае гэты пакет у пункт прызначэння L2, а мост паштовай скрыні разгрупоўвае хэшы, каб міні-акаўнты маглі іх чытаць. Адпраўнік дадае невялікую плату да свайго хэша, каб стымуляваць ініцыятараў транзакцый па смарт-кантрактах пратаколу. Калі хэш дасягае пункта прызначэння L2, вы адпраўляеце карыстальніцкую аперацыю ў мемпул AA на гэтым L2. Выкарыстоўваючы стандарт ERC-4337, нам не трэба паўторна ўкараняць уласны міні-рахунак mempool, а пратакол можна лёгка інтэграваць у кашалькі з ужо існуючай кодавай базай. Карацей кажучы, я збіраўся стварыць мост на аснове L1, які адпраўляе транзакцыі з разумнага кашалька на вашым L2 на любы L2, з якім вы хочаце ўзаемадзейнічаць. У канчатковым выніку я амаль рэалізаваў гэта на хакатоне, але не змог скончыць з-за невялікага вопыту і працы ў адзіночку. Патлумачыўшы гэта сябру, ён спытаў мяне: Чаму б проста не змяніць сетку ў сваім кашальку і не выкарыстоўваць токен-брыджы для перамяшчэння неабходных сродкаў у патрэбную сетку? : гэта абсалютна варыянт, калі вы выкарыстоўваеце кашалёк EOA. Кашалькі EOA дзейнічаюць аднолькава ва ўсіх сетках EVM і маюць адзін і той жа адрас, таму вы можаце адпраўляць транзакцыі ва ўсіх з іх, проста змяніўшы сетку ў наладах кашалька. Я адказаў Аднак гэтая вобласць пераходзіць да разумных уліковых запісаў, заснаваных на абстракцыях уліковых запісаў. Гэтыя ўліковыя запісы дазваляюць нам праграмна дадаваць любую функцыянальнасць, якую мы хочам, у нашы кашалькі: Подпісы P256 дазваляюць выкарыстоўваць для падпісання транзакцый. бяспечныя чыпы ў нашых тэлефонах Дзякуючы сацыяльнаму аднаўленню мы можам дадаць нашых сваякоў у якасці апекуноў, упаўнаважаных аднаўляць нашы кашалькі, ухіляючы небяспечныя пачатковыя фразы. Тэхналогія Paymaster дазваляе нам аплачваць плату за газ любымі сімваламі або нават . прымушаць кагосьці плаціць за нас Калі квантавыя кампутары пачынаюць парушаць класічныя схемы подпісаў, мы можам проста змяніць схему ў нашых кашальках AA на квантава-бяспечную, не ствараючы новы кашалёк. Гэты спіс можна працягваць бясконца, так як дазваляе нам выкарыстоўваць выкананыя праграмы ў якасці паўнавартасных кашалькоў. Але ўсё гэта мае сваю цану: нельга лёгка перанесці кашалькі ў іншую ланцужок, таму што, акрамя перамяшчэння сродкаў праз мост, гэта патрабуе пераразмеркавання ўсяго ўліковага запісу з усімі ключамі, апекунамі і наладамі. У некаторых выпадках гэта можа быць занадта складаным або нават немагчымым; скажам, у зводных пакетах, якія не падтрымліваюць (гэтая схема подпісу можа быць занадта дарагой для выкарыстання). абстракцыя акаўнта прэкампіляцыю P256 Таму я склаў гэты пратакол. Па сутнасці, у вас ёсць уліковыя запісы AA на многіх L2. Каб адправіць транзакцыю ад іх, вы павінны пацвердзіць свой намер, даслаўшы яе хэш з вашага галоўнага ўліковага запісу на пэўным L2 на гэтыя «міні-рахункі» праз мост L1. Фактычна, такім чынам вы не пазбаўляецеся ад некалькіх кашалькоў; вы проста пераносіце ўсю логіку праверкі ў адзіны «бацькоўскі» ўліковы запіс. Яшчэ адна цікавая дэталь такога пратаколу заключаецца ў тым, што ён забяспечвае ўзаемадзеянне не толькі з L2, але і з усімі L1 (сайдчэйны), якія маюць замацаваныя масты з Ethereum - Polygon PoS, Ronin, Gnosis і Avalanche - гэта тое, пра што я магу думаць. Аднак ён быў распрацаваны як , так што гэта проста цікавы тэхналагічны факт. пратакол узаемадзеяння, арыентаваны на згортванне Хоць ідэя праекта была даволі разумнай, практычная рэалізацыя мела істотны недахоп: . Увесь дызайн абапіраецца на падлучаныя да Ethereum L1. Асаблівасць Rollup Bridges заключаецца ў тым, што яны даказваюць свой стан сваім смарт-кантрактам на Ethereum, каб успадкаваць яго бяспеку. Як вы ўжо маглі ведаць, аптымістычны і ЗК-верыфікацыя - два найбольш папулярныя спосабы зрабіць гэта. хуткасць кананічныя згортваюцца масты, Аптымістычная праверка працуе, адкрываючы «акно выкліку», звычайна каля сямі дзён, у якім прэтэндэнты могуць адправіць , які паказвае на любую несапраўдную частку пакета транзакцый. Калі гэтае пацвярджэнне сапраўднае, зводны пакет рэарганізуе свой блокчейн, каб выдаліць гэты пакет. Пасля сямі дзён без доказаў махлярства партыя аўтаматычна лічыцца сапраўднай, і ўсе паведамленні і зняцце сродкаў завяршаюцца на Ethereum. доказ махлярства Вы, напэўна, ужо зразумелі. З-за сямідзённай затрымкі ў адпраўцы паведамленняў на L1 адпраўка міжланцуговых транзакцый з аптымістычнага зводнага пакета з'яўляецца ідэяй. чаму? Што ж, ты будзеш чакаць абмену DEX тыдзень? Што будзе з цаной да гэтага часу? жудаснай Адпраўка крос-ланцуговых транзакцый аптымістычны звод нашмат лепш. Нягледзячы на тое, што секвенсор OP Stack чакае некалькі блокаў перад апрацоўкай паведамлення, каб звесці да мінімуму магчымасць рэарганізацыі, чаканне некалькіх хвілін вашай транзакцыі ўжо збольшага прымальна для некаторых задач. у Больш за тое, супольнасць Ethereum у цяперашні час працуе над , што дазволіць завяршаць кожны блок асобна, робячы іх незваротнымі да наступнага блока. Пасля яго рэалізацыі перадача паведамленняў з L1 на L2 зойме каля 12 секунд. канчатковасцю ў адзін слот Размяшчэнне такіх акаўнтаў на ZK rollups было б лепш, але ўсё роўна не вельмі зручна. Як мы бачым са статыстыкі ніжэй, ZKsync Era завяршаецца за 21 гадзіну, Linea за 5 гадзін, за 9 гадзін і г.д. Starknet Але чаму гэта так? Ці не хуткая генерацыя доказаў ZK на магутных кластарах? Карацей кажучы, ёсць дзве праблемы: Некаторыя зводныя пакеты ZK, такія як ZKsync Era, усталёўваюць затрымкі выканання, каб савет бяспекі меў час вярнуць некаторыя пакеты ў выпадку памылкі ў іх сістэме доказаў. zkEVM - гэта сапраўды складаная тэхналогія, і з-за гэтай складанасці імавернасная прадухіленне памылак з выкарыстаннем некалькіх сістэм праверкі адначасова пакуль што немагчыма. Нягледзячы на тое, што праверка доказу ZK вельмі лёгкая ў параўнанні з вылічэннямі, якія яна даказвае, праверка ў ланцужку ўсё яшчэ даволі дарагая. У залежнасці ад сістэмы доказаў, гэта можа заняць да мільёна газаў на праверку. Прымаючы сярэднюю цану на газ у 9 gwei і сённяшнія цэны ETH, адзін доказ каштуе каля 30 долараў толькі для праверкі на L1. Сучасныя зводныя пакеты ZK мінімізуюць гэтыя выдаткі, ствараючы адзін доказ для многіх партый адзін раз за пэўны прамежак часу, але гэта запавольвае хуткасць канчатковасці моста. Стварэнне партыі і праверка кожнага блока складае 30 долараў за блок або . Пры 100 TPS гэта складае каля $0,025 за транзакцыю толькі для выдаткаў на праверку. І мы таксама павінны стварыць доказ і апублікаваць партыю ў ланцужку! 216 000 долараў у дзень Чакаць транзакцыю адну-дзве гадзіны ўсё яшчэ занадта доўга. Што мы можам з гэтым зрабіць? Перш за ўсё, давайце забудзем мой васьмімесячны праект хакатона і паспрабуем ліквідаваць разумовую мадэль, паводле якой кожная транзакцыя павінна ініцыявацца з нашага галоўнага разумнага кашалька. Чаму нам увогуле трэба дзяліцца логікай разумнага кашалька ў кожным звароце? Чаму б нам проста не стварыць часовыя EOA, перавесці туды сродкі з нашага асноўнага разумнага кашалька, выканаць пэўную працу, якую мы хочам зрабіць, і не перавесці тое, што засталося? Мой (або любы іншы смарт-кашалёк, які вы выкарыстоўваеце) мае Secure Enclave падпісанне і сацыяльнае аднаўленне, так што я заўсёды магу быць у бяспецы за свае сродкі там, нават калі я згублю свой тэлефон. І каго хвалюе, што адбываецца з гэтымі часовымі ўліковымі запісамі? Я ўжо зрабіў свае справы з імі; зараз усе сродкі на маёй Клаве. Clave Аднак у гэтага падыходу ёсць фундаментальная праблема: здагадка, што вы не можаце выкарыстоўваць адзін і той жа кашалёк у іншых сетках на рэгулярнай аснове, моцна абмяжоўвае колькасць задач, якія вы можаце выконваць у іх. Напрыклад, вы не можаце: Стварыце дэпазіт на мясцовай платформе , таму што вы не можаце перанесці яго ў асноўную сетку крэдытавання (у дадзеным выпадку ZKsync Era) Атрымайце токены, якія не маюць заменнага эквіваленту ў вашай асноўнай сетцы (напрыклад, калі яны адчаканены ў гэтай сетцы) Удзельнічайце ў лакальным DAO, таму што вашы галасы павінны заставацца ў гэтым часовым акаўнце. Па сутнасці, усё, што вы можаце зрабіць як карыстальнік, - гэта размеркаваць сродкі паміж некалькімі атрымальнікамі без пераходу кожны раз і атрымаць лепшую ліквіднасць для абмену на токен, які можа быць перакінуты назад у вашу асноўную сетку. Такім чынам, каб зрабіць гэтыя кашалькі карыснымі, мы павінны атрымаць да іх доступ, выкарыстоўваючы тыя ж правілы, якія мы выкарыстоўваем на нашых асноўных смарт-кашальках - бяспечныя анклавы, сацыяльнае аднаўленне і г.д. Такім чынам, мы вяртаемся да ідэі вышэй і яе невыканальнасці. Аднак ёсць , які можа надаць гэтым міні-рахункам толькі ўласцівасці нашага галоўнага кашалька: магчымы паліятыў аднаўлення Мы ствараем тыя ж міні-рахункі, якія апісаны раней, але дазваляем адным ключом адпраўляць транзакцыі з іх непасрэдна. Наш бацькоўскі кашалёк цяпер можа змяніць гэты ключ праз мост на аснове L1 або прымусіць міні-рахунак счытваць яго са стану бацькоўскага L2. Такім чынам, калі часовы ключ згублены, бацькоўскі кашалёк можа ініцыяваць змену ключа праз павольны, але атамарны мост на аснове L1. Атамарнасць — уласцівасць дзеяння, якое не дапускае яго збою падчас выканання. Альбо гэта не было ініцыявана, альбо гэта было зроблена. Масты на аснове L1 з'яўляюцца атамарнымі, таму што паведамленне не можа быць страчана, калі яно адпраўлена. Заказ, даступнасць і сапраўднасць гарантаваны Ethereum L1. Гэта значна лепш! Цяпер звычайныя транзакцыі патрабуюць толькі часу для пераадолення токенаў. Пасля таго, як токены знаходзяцца ў месцы прызначэння, адпраўка транзакцый адбываецца так хутка, як калі б гэта была ваша галоўная сетка. Калі вы страціце ключ, вам давядзецца чакаць ад некалькіх гадзін да сямі дзён, у залежнасці ад ланцужка вашага бацькоўскага кашалька, але вы не будзеце выкарыстоўваць яго вельмі часта, так што кампраміс прымальны для большасці выпадкаў выкарыстання. Акрамя таго, гэта магчыма рэалізаваць у кашальках нават сёння. Я нават зрабіў , але яна зусім не бяспечная і не гатовая да вытворчасці і прызначана толькі для візуалізацыі. сваю ўласную рэалізацыю Падобная тэхніка выкарыстоўваецца ў ф'ючэрсных гандлёвых платформах Web3: вы ўхваляеце токен у пары (звычайна USDC) для смарт-кантракту і прызначаеце часовы ключ для выдаткаў, які захоўваецца на інтэрфейсе платформы. Гэта дазваляе карыстальнікам выконваць хуткія дзеянні, не падпісваючы кожнае дзеянне сваім асноўным кашальком. Калі вы зменіце прыладу або ачысціце даныя ў браўзеры, вы можаце проста пераназначыць ключ з дапамогай асноўнага кашалька. Але, як і ва ўсім у крыптаграфіі, гэты падыход таксама не ідэальны. Ён мае два недахопы: Нягледзячы на тое, што міні-рахункі могуць быць сумяшчальнымі з ERC-4337 і, такім чынам, падтрымліваць усе яго функцыі, такія як пакетаванне, плацельшчыкі, ліміты выдаткаў і г.д., гэтыя функцыі больш не ўспадкоўваюцца ад бацькоўскага ўліковага запісу. Фактычна, бацькоўскі ўліковы запіс дзейнічае як адзіны апякун сацыяльнага аднаўлення для міні-акаўнта, але апекуном з'яўляецца сам карыстальнік. Маркернае пераадоленне павінна быць выканана з дапамогай знешніх перамычак. З ініцыяцыяй крос-ланцужкоў транзакцый мы можам пераносіць нашы токены з паведамленнем, прымаючы іх практычна 1:1 атамарным спосабам. Аднак з такім рашэннем гэта больш не варыянт, таму знешні мост - адзіны хуткі варыянт, які застаўся. Нягледзячы на тое, што сучасныя масты , яны а) бяруць камісію, якая можа быць , б) не з'яўляюцца атамарнымі і не наследуюць уласцівасці бяспекі Ethereum. Асабліва важна звярнуць увагу на . могуць пераводзіць сродкі за некалькі секунд вельмі высокай пры вялікіх пераводах ўласцівасці бяспекі блокчейн-мастоў Выкарыстанне знешніх мастоў для перадачы токенаў збольшага прымальна, у адрозненне ад іх выкарыстання для перадачы паведамленняў для кіравання міні-акаўнтамі. Прычына іх горшых выпадкаў, верагодна, з-за нападу на іх: горшае, што можа здарыцца, гэта тое, што вы не атрымаеце дасланыя вамі токены. У такім выпадку вы губляеце X токенаў, якія хацелі аб'яднаць, і пераключаецеся на іншы мост. Пры пераадоленні токенаў горшае, што можа здарыцца, гэта тое, што ўсе вашы міні-акаўнты могуць быць скрадзеныя шляхам перадачы паведамленняў, якія імітуюць сябе праз мост. У такім выпадку вы губляеце свае кашалькі ва ўсіх ланцужках з усім іх коштам, акрамя асноўнага. У абмене паведамленнямі паміж уліковымі запісамі Такім чынам, спадзявацца на знешнія масты для пераадолення токенаў з'яўляецца ў значнай ступені варыянтам, пакуль у вас няма эфектыўнага спосабу аб'яднаць іх атамарным спосабам з дапамогай L1. Фактычна гэта варыянт, які сёння выкарыстоўваюць многія карыстальнікі, якія ўзаемадзейнічаюць з ланцужкамі збору. Выкажам здагадку, што мы хочам усе транзакцыі ў адным месцы, напрыклад, для ўласнай перадачы токенаў паміж уліковымі запісамі або праверкі подпісаў з дапамогай унікальнай папярэдняй кампіляцыі. У такім выпадку мы сутыкаемся з павольнай канчатковасцю сённяшніх збораў ZK. Вернемся на некаторы час, каб падумаць, што можна палепшыць з дапамогай папярэдняй тэхнікі. праверыць Чаму агрэгаты маюць павольную канчатковасць моста? Мы возьмем нарошчванне ZK у якасці мэты, таму што ў аптымістычных прычына ўжо відавочная: Сістэмы доказу ZK для паўнавартасных асяроддзяў віртуальных машын складаныя, асабліва калі асяроддзе не з'яўляецца ZK-дружалюбным (EVM). Такім чынам, вялікая верагоднасць таго, што яны будуць утрымліваць памылкі. Множныя сістэмы доказаў могуць прадухіліць гэта, але іх вельмі складана рэалізаваць, і стварэнне некалькіх доказаў для адной партыі можа быць занадта павольным і дарагім. У якасці абыходнага шляху каманды згортвання ўключаюць затрымкі выканання, што дазваляе ім адкаціць ланцужок у экстранай сітуацыі. Гэта тое, што запавольвае канчатковасць моста ў некаторых аб'яднаннях (напрыклад, ZKsync Era). Прапанова новага стану і ZK, які даказвае яго L1, - гэта даволі дарагія задачы, таму, каб мінімізаваць выдаткі, секвенсоры зводных файлаў робяць гэта кожныя некалькі гадзін, а не кожны блок. Аднак ёсць выключэнне; , але а) праверка доказаў па-ранейшаму праводзіцца кожныя некалькі гадзін, таму яна застаецца неправеранай, і б) Scroll з'яўляецца адным з для выкарыстання сёння. Scroll прапаноўвае стан прыкладна кожную хвіліну самых дарагіх назапашвальных пакетаў Калі мы перафразуем гэта яшчэ больш проста, то праблемы ў даказванні выдаткаў і праверцы выдаткаў. Давайце разгледзім кожную праблему і спосабы яе вырашэння. Па сутнасці, наша задача складаецца ў тым, каб зрабіць так, каб наш разумны кашалёк на звароце хутка ўзаемадзейнічаў з іншымі назапашваннямі без дадатковых дапушчэнняў даверу, выкліканых знешнімі мастамі. Разумныя кашалькі звычайна складаюцца з некалькіх звычайных функцый АА - плацельшчыкі, сацыяльнае аднаўленне, бяспечныя анклавы, ліміты выдаткаў і г.д., і асноўная аперацыя, якая дазваляе нам адпраўляць транзакцыі ў ланцужку з іх. Навошта нам асноўная аперацыя, калі мы хочам выкарыстоўваць іншыя зборы з кашалька? Таму што ён, верагодна, размешчаны ў шматмэтавым зборы — Arbitrum, Base, ZKsync Era — і мы таксама хочам узаемадзейнічаць з карыстальнікамі і смарт-кантрактамі ў гэтым зборы. У гэтым канкрэтным выпадку было б сэнсам проста выкарыстоўваць знешнія токен-брыджы. Проста заменіце задачу, напрыклад, узаемадзеяннем з dApp у тым жа зборы і іншым. Гэтая ўніверсальнасць - гэта тое, што ўносіць складанасць у сістэму доказаў збораў. Праверка стану ўсёй віртуальнай машыны з вялікай колькасцю смарт-кантрактаў і транзакцый, якія адбываюцца кожную секунду, з'яўляецца даволі складанай задачай. Мы хочам выконваць два тыпы задач, якія патрабуюць абсалютна рознага набору функцый у зводным пакете: для транзакцыі ў ланцужку гэта хуткае ўключэнне L2, нізкія зборы L2 і шырокія функцыянальныя магчымасці віртуальнай машыны, а для транзакцыі з некалькімі зводнымі працэсамі , гэта хуткі канчатковы мост. і створым зводны пакет, які можа апрацоўваць толькі разумныя ўліковыя запісы і абмен паведамленнямі на іншыя L2? Прыкладна ў часы Devconnect Istanbul Віталік Бутерин прапанаваў падобную тэхніку пад назвай «зборка сховішча ключоў». Мы абмяркуем гэта далей. Але што, калі мы проста пазбавімся ад віртуальнай машыны Аб'яднанне сховішча ключоў Ідэя складаецца ў тым, каб стварыць зборны пакет ZK, які можа захоўваць толькі ключы ўліковага запісу і змяняць іх з дапамогай іншага ключа. Гэты збор перамяшчае корань дрэва Merkle, які змяшчае ўсе гэтыя ключы, на L1. Затым, калі вы хочаце адправіць транзакцыю з аднаго са сваіх разумных уліковых запісаў на L2, вы ствараеце доказ Merkle вашага бягучага ключа, і ваш уліковы запіс спраўджвае яго з коранем сховішча ключоў, даступным на L1. Цяпер ён ведае ваш ключ і можа выкарыстоўваць яго для праверкі вашых подпісаў. Такая зборка вельмі простая, і можна лёгка рэалізаваць некалькі сістэм доказаў, таму ключы, якія захоўваюцца ў ёй, на самай справе такія ж бяспечныя, як і L1. Акрамя арыгінальнага дызайну Віталіка, ёсць тры вядучыя для зводных сховішчаў ключоў: Падыход складаецца ў тым, каб захоўваць даныя сховішча ключоў на L1, але дазваляць абнаўляць іх з іх зводнага пакета zkEVM. Для гэтага яны ўводзяць прэкампіляцыю L1SLOAD, якая дазваляе танна чытаць сховішча L1. Затым уліковыя запісы AA на іншых L2 могуць чытаць гэтыя даныя, каб сінхранізаваць сваю канфігурацыю — ключы, апекуны і г.д. Scroll вывучае тэхніку, пры якой толькі корань стану захоўваецца на L1, але транзакцыі паслядоўна выконваюцца з выкарыстаннем даных выклікаў, таму дрэва заўсёды можна перабудаваць. Чакаецца, што ўліковыя запісы на L2 будуць атрымліваць бягучыя ключы з дапамогай доказаў Merkle. Базавая каманда Дызайн вельмі падобны да дызайну Base або Vitalik, але ён выкарыстоўвае ўласную структуру «мікразборак» са спецыялізаванымі мінімальнымі віртуальнымі машынамі. Stackr Наогул кажучы, яны адрозніваюцца колькасцю задач, якія дэлегуюцца апрацоўцы па-за ланцужком (іншымі словамі, колькі рэчаў знаходзіцца на L2), і дэталямі іх рэалізацыі. Мы можам пашырыць гэтую ідэю далей, апрацоўваючы , але і . Гэта таксама не было б значна складаней у вылічальным плане; па сутнасці, нам трэба толькі вырашаць наступныя задачы: не толькі ключы ўсю логіку разумнага ўліковага запісу уліковыя запісы ў зводным сховішчы ключоў павінны мець магчымасць апавяшчаць L1 аб сваім намеры транзакцыі. Захоўваць усю транзакцыю на L1 не патрабуецца; чагосьці накшталт кораня дрэва Merkle з усімі хэшамі карыстальніцкіх аперацый было б дастаткова. Затым усё, што трэба для адпраўкі транзакцыі з міні-рахунку, - гэта счытванне кораня з L2 прызначэння і стварэнне доказу таго, што пэўная аперацыя AA сапраўды была запытана з бацькоўскага ўліковага запісу. Адпраўка даных у L1: Карыстальнік падпісвае хэш карыстальніцкай аперацыі, якую ён хоча выканаць у пэўным зводным пакете. Аб'яднанне сховішча ключоў правярае подпіс, каб пацвердзіць намер, і дадае хэш у дрэва, каб затым адправіць яго ў L1. Дастаткова некалькіх схем подпісаў, такіх як , і . Праверкі подпісаў: ECDSA P256 квантава-бяспечных прымусьце іншыя, спецыяльна выбраныя ўліковыя запісы, званыя «апекунамі», прагаласаваць за змяненне ключа ва ўліковым запісе карыстальніка. Карыстальнік можа ўсталяваць апекуноў і парог і запытаць іх аб аднаўленні ў выпадку страты ключа. Мы таксама можам рэалізаваць або альтэрнатыўныя схемы апекуна, такія як , ZK-OTP або , каб пашырыць сацыяльнае аднаўленне за межамі карыстальнікаў зводнага пакета. Сацыяльнае аднаўленне: аднаўленне на аснове вета ZK-Email Web Proofs у выпадку крадзяжу кашалька правілы расходавання, якія кантралююцца апекунамі, могуць значна паменшыць патэнцыйныя страты да таго, як карыстальнік верне кашалёк. Гэтая функцыя таксама карысная для эканоміі сродкаў або, напрыклад, для стварэння кашалькоў для дзяцей - бацькі могуць адправіць дапамогу і абмежаваць, колькі яе можна выдаткаваць, каб дзіця магло навучыцца эканоміць. Правілы выдаткаў: гэта можа здацца непатрэбным, але магчымасць захоўваць крыпту зводным сховішчы ключоў рэзка павышае бяспеку актываў карыстальнікаў, не падзяляючы іх на некалькі міні-рахункаў. Акрамя таго, гэта дазваляе выкарыстоўваць мноства функцый, якія паляпшаюць карыстацкі досвед: Баланс токенаў: ў набор можа прапаноўваць бясплатныя транзакцыі для прыцягнення новых карыстальнікаў або дазваляць ім аплачваць камісію любым токенам, а не толькі ETH. Таксама можа быць рэалізавана больш складаная логіка плацельшчыка — напрыклад, секвенсор можа браць плату з свопу ў іншай ланцужку, калі ён падлучаны да зводнага сховішча ключоў. Плацельшчыкі: акрамя імгненнай адпраўкі сродкаў паміж карыстальнікамі аб'яднання, прамыя пераводы таксама карысныя для рэалізацыі мастоў на аснове намераў з іншымі аб'яднаннямі, якія маюць занадта павольную канчатковасць, каб выкарыстоўваць L1 для пераходу з міні-ўліковага запісу на бацькоўскі ўліковы запіс у зводным сховішчы ключоў. Такім чынам, зводнае сховішча ключоў можа па сутнасці дзейнічаць як цэнтр для таннай перадачы токенаў паміж міні-акаўнтамі на дзясятках розных L2. Унутраныя перадачы токенаў: Такая сістэма значна прасцейшая тэхнічна, чым поўная віртуальная машына ўнутры зводнага пакета, таму магчыма ствараць доказы для некалькіх сістэм доказаў адначасова, і складанасць стварэння доказаў будзе значна меншай. Аднак праверка доказаў па-ранейшаму застаецца праблемай. Як мы падлічылі раней, яго кошт газу можа складаць да 1 мільёна газу або ~25-50 долараў у залежнасці ад цаны на газ. Гэты кошт фіксаваны і не залежыць ад колькасці транзакцый у пакете. Гэта азначае, што калі транзакцый занадта мала, плата за кожную транзакцыю можа быць вельмі высокай. Ёсць два асноўных спосабу паменшыць гэты кошт: Выраўнаваны пласт - гэта EigenLayer AVS, які выкарыстоўвае аператараў паўторнай стаўкі для таннай праверкі доказаў ZK. Калі вы не знаёмыя з EigenLayer, гэта спрошчанае рэзюмэ таго, як правяраюцца доказы ў Aligned: Aligned Карыстальнік адпраўляе ў сетку запыт праверкі доказаў і плаціць за гэта; Выраўнаваныя аператары, кожны з якіх з'яўляецца валідатарам Ethereum з прывязанымі дэпазітамі, правяраюць доказ на сваіх вузлах і падпісваюць яго сапраўднасць; Калі 2/3 аператараў падпісваюцца для доказу, сукупны подпіс адпраўляецца і правяраецца на Ethereum L1. Калі несапраўднае пацвярджэнне дасягнула канчатковага характару, валідатары, якія падпісаліся на яго, могуць быць скарочаны шляхам праверкі ў ланцужку. Такім чынам, доказ атрымлівае эканамічную бяспеку, роўную 2/3 ад агульнай долі аператараў Aligned. У гэтага падыходу ёсць відавочны недахоп - Ethereum больш не гарантуе сапраўднасць доказаў. Калі TVL брыджа згортвання вышэй за 2/3 ад агульнай стаўкі Aligned, атакаваць яго становіцца выгадна. І паколькі мы гаворым пра затрымку канчатковасці ў 1-2 блокі, мы не можам аптымістычна прадухіліць атаку. Тым не менш, гэта можа быць адносна бяспечным варыянтам, калі назапашванне не становіцца занадта вялікім. Калі гэта адбудзецца, попыт на транзакцыі ўжо можа зрабіць праверку доказаў L1 вартай. Згодна з дакументамі, праверка доказу ZK з дапамогай Aligned каштуе каля 3000 газаў, што амаль бясплатна нават для Ethereum L1. Слаі агрэгацыі доказаў Калі вам нязручна ўводзіць у сістэму дадатковыя здагадкі даверу або ваш пратакол ужо стаў занадта вялікім, але попыт на яго транзакцыі не стаў, ёсць альтэрнатыва. Каманды ZK і rollup нядаўна пачалі актыўна працаваць над пратаколамі агрэгацыі доказаў. Калі вы не вельмі знаёмыя з ZK, агрэгацыя доказаў - гэта калі доказ ZK даказвае сапраўднасць іншага доказу ZK (які, у сваю чаргу, можа даказаць іншы доказ і г.д.), такім чынам, «аб'ядноўваючы» іх у адзіны доказ і па сутнасці, пераносячы ўсе свае выдаткі на праверку на выдаткі на пацверджанне. Засталося праверыць адзінае доказ ZK у ланцужку і пераканацца ў сапраўднасці ўсіх іншых доказаў ZK, якія ён даказвае. Фу! Праверка доказу ZK у ланцужку. Аб'яднанне доказаў мае сэнс, калі выдаткі на праверку вышэй, чым на агрэгаванне доказаў. Гэта значыць, агрэгацыя становіцца прыбытковай, калі кошт стварэння доказу для дзесяці доказаў і яго праверкі меншы, чым незалежная праверка гэтых дзесяці доказаў. Гэта яшчэ больш карысна ў Ethereum L1, які моцна абмежаваны вылічальнай магутнасцю. У залежнасці ад сістэмы доказаў, увесь блок можа ўтрымліваць толькі , за выключэннем усіх іншых дзеянняў у ланцужку. каля 100 праверак доказаў Як правіла, існуе два тыпу пратаколаў агрэгацыі доказаў: такія праекты звычайна падтрымліваюць некалькі найбольш папулярных пратаколаў ZK (Groth16, Halo2, Plonky), на аснове якіх будуецца большасць схем ZK і бярэ плату за апрацоўку. Затым dApps, якім патрэбныя доказы, выяўляюць даныя з пратаколу і апрацоўваюць іх самастойна. , якая зараз распрацоўваецца, робіць менавіта гэта. Aligned таксама працуе над так званай , якая таксама з'яўляецца сістэмай агрэгацыі доказаў. Агрэгацыя агульнага прызначэння (Універсальная): Універсальная сістэма агрэгацыі доказаў Nebra праверкай у «павольным рэжыме» падобна сумеснай паслядоўнасці ў аптымістычных зводных, зводныя ZK са сваімі стэкамі працуюць на агульных мастах з аб'яднанымі доказамі стану для кожнага зводнага ZK у мосце. Гэта не толькі дазваляе сінхронную кампазіцыю ўнутры стэка ў духу агульнай паслядоўнасці, але і мінімізуе выдаткі на праверку доказаў. Магчыма, вы чулі пра ад Polygon або ад ZKsync, якія з'яўляюцца агульнымі зводнымі мастамі, якія працуюць на агрэгацыі доказаў унутры моста. Аб'яднанне агульных зводных мастоў: AggLayer Hyperbridge Перавагі універсальных сістэм агрэгацыі ў тым, што яны не залежаць ад праектаў і спецыялізуюцца толькі на самім працэсе агрэгацыі, што забяспечвае даволі хуткую праверку доказаў і нізкі кошт. Акрамя таго, верагодна, што ў яго не будзе навучальных колаў з-за адсутнасці кампанента моста. Агрэгаваныя зводныя масты, у сваю чаргу, карысныя для зводнага сховішча ключоў, каб мець сінхронную кампазіцыю з ужо існуючым стэкам зводных. Напрыклад, , 13 праектаў у цяперашні час пабудаваны з выкарыстаннем Polygon CDK, а 11 выкарыстоўваюць ZK Stack. Калі ўсе яны падключаюцца да агульнага моста агрэгавання доказаў, падключэнне зводнага сховішча ключоў да аднаго з іх адкрые бесперашкоднае ўзаемадзеянне з многімі L2, нават не дакранаючыся L1. Каб гэта працавала, мост павінен падтрымліваць іншую логіку пераходу стану для сваіх L2, таму што логіка зводнага сховішча ключоў адрозніваецца ад іншых L2 у ім. па дадзеных L2BEAT Аднак гэтыя масты звычайна мадэрнізуюцца і кантралююцца яго DAO або саветам бяспекі. Праектам збору сховішча ключоў можа быць непрыемна аддаваць свой суверэнітэт аператарам моста, да якога яны падключаны. Акрамя таго, масты могуць уводзіць затрымкі выканання ў якасці меры засцярогі пры трэніровачных колах, падобна таму, як ZKsync Era працуе цяпер, што па сутнасці забівае ўсю эфектыўнасць гэтага дызайну зводнага сховішча ключоў. Такім чынам, зборкі сховішча ключоў, як і любыя іншыя зборы ZK, могуць мінімізаваць выдаткі на праверку доказаў і нават аб'яднаць гэта з сінхроннай кампазіцыяй з ужо існуючым стэкам зборкі. Эфектыўнае пераадоленне на аснове намераў з аб'яднаннем "Keystore+". Як абмяркоўвалася раней, пераход ад L2 да L1 - не адзіная праблема. Большасць зводных секвенсоров таксама ўжываюць затрымкі для перадачы паведамленняў з L1 на L2. Гэта таму, што калі блок Ethereum створаны, ён яшчэ не канчатковы і можа быць адменены на працягу наступных ~64 блокаў (дзве эпохі, каля 13 хвілін). Гэтыя рэарганізацыі адбываюцца з-за затрымкі сеткі, у выніку чаго некаторыя прапановы з'яўляюцца ў сетцы занадта позна, калі некаторыя вузлы ўжо лічаць іх прапушчанымі. Нягледзячы на тое, што за два блокі , каманды зборкі па-ранейшаму не жадаюць рызыкаваць, звязаныя з прапушчанымі паведамленнямі, і ўжываць затрымкі для пераходу з L1. Гэтыя затрымкі складаюць усяго каля 1 хвіліны ў некаторых аб'яднаннях ( , ), але могуць дасягаць да 6 хвілін, як у , або нават патрабаваць канчатковасці L1, як у . большасць рэарганізацый не глыбей (рэарганізацыя з сямі блокаў нават з'явілася ў навінах два гады таму) OP Stack ZK Stack Arbitrum Linea Супольнасць Ethereum , што дазволіць кожны блок фіналізаваць незалежна, а не адзін раз у эпоху. Але мы можам з упэўненасцю сказаць, што ў першым квартале 2025 года, так што пройдзе як мінімум год, перш чым SSF будзе ўкаранёны. актыўна працуе над Single-Slot Finality наступнае абнаўленне Pectra не плануецца Калі камандзе, якая рэалізуе гэты пашыраны дызайн зводнага сховішча ключоў, не задавальняе такая затрымка транзакцый, яна можа рэалізаваць паліятыў, апісаны раней. Кожны міні-рахунак мае ключ, упаўнаважаны для адпраўкі транзакцый або выкарыстоўвае статычны ключ са сховішчы ключоў (паводле арыгінальнага дызайну Віталіка), але кіраванне ўліковым запісам па-ранейшаму ажыццяўляецца на асноўнай уліковай запісе сховішчы ключоў. Пасля ўкаранення SSF на L1 зводны пакет можа выдаліць аўтарызаваныя ключы расходавання, і карыстальнікі атрымаюць усю функцыянальнасць наладкі AA без значнага зніжэння хуткасці. Я згодны з Алексам тут; 15-секундная затрымка абсалютна прымальная, тым больш, што аперацыя з'яўляецца атамарнай пасля завяршэння транзакцыі збору сховішча ключоў на L1. Калі казаць пра перадачы токенаў, кашалькі атрымальнікаў могуць нават рэалізаваць статус «У чаканні» на ўзроўні карыстацкага інтэрфейсу. Аднак перакрыжаваныя перадачы токенаў па-ранейшаму ўяўляюць праблему. Калі мы ўкараняем сховішчы токенаў у назапашаным сховішчы ключоў, перадача токенаў з яго зойме ад 1 да 15 хвілін, у залежнасці ад назапашанага атрымальніка. Калі мы гэтага не зробім, раздзяленне балансаў карыстальнікаў на міні-рахункі на некалькіх L2 можа выклікаць пагрозу бяспецы і нават заблакаваць некаторыя актывы ў неліквідных L2, пераход ад якіх можа каштаваць занадта дорага або заняць занадта шмат часу. У якасці альтэрнатывы мы можам інтэграваць мост, заснаваны на намерах, у аб'яднанне і разгарнуць яго на ўсіх астатніх аб'яднаннях або нават паўторна выкарыстоўваць існуючую інфраструктуру, напрыклад, пратаколы, сумяшчальныя з . Мы коратка абмяркуем масты намераў у наступным раздзеле. ERC-7683 Што такое мост на аснове намераў? Большасць існуючых міжланцужных мастоў заснавана на пратаколах абмену паведамленнямі. Напрыклад, выкарыстоўвае для перадачы паведамленняў аб дэпазітах у ланцугі прызначэння, абапіраючыся на яго як на крыніцу даверу. Калі вы адпраўляеце токены праз такія масты, яны блакуюць вашыя токены з аднаго боку і адпраўляюць паведамленне аб вашым дэпазіце з іншага боку, і сховішча там разблакуе для вас адпаведную колькасць токенаў. Stargate LayerZero , у сваю чаргу, не адпраўляюць паведамленні паміж двума ланцужкамі. Замест гэтага сродкі, якія адпраўляюцца, замыкаюцца ў сховішчы як «заказ паміж ланцужкамі», і тады кожны можа выканаць заказ, адправіўшы запытаную колькасць токенаў па ланцужку прызначэння. Той, хто выконвае заказ, можа запатрабаваць заблакіраваныя токены з зыходнага ланцужка, калі сховішча ў ім атрымае інфармацыю аб канчатковым стане ланцужка прызначэння і зможа пацвердзіць перадачу. Масты на аснове намераў Гэта можа адбыцца альбо ў чаканні завяршэння мэты (моста) ланцужка прызначэння, альбо праз нейкі знешні пратакол аракула. Напрыклад, для атрымання стану яшчэ не завершаных L2. Across выкарыстоўвае аптымістычны аракул UMA У гэтым сцэнары Ethereum L1 выкарыстоўваецца ў якасці крыніцы даверу. Некаторыя пратаколы, такія як Across, замест гэтага выкарыстоўваюць знешнія аракулы. Фактычны дызайн можа адрознівацца ў існуючых праектах; адлюстроўваецца толькі агульная ідэя. Мы можам выкарыстоўваць той жа дызайн для гэтых пашыраных зводных сховішчаў ключоў, каб рэалізаваць ненадзейнае, хуткае і таннае двухбаковае пераадоленне паміж сховішчам ключоў і ўсімі іншымі L2. Хуткая канчатковасць моста дазваляе іншых L2 быць амаль бясплатнымі, таму што пацвярджэнне выканання на L2 займае ўсяго некалькі хвілін. заказам на аснове намераў ад Заказы са сховішчы ключоў, верагодна, таксама будуць таннымі, паколькі ліквіднасць на L2 можа быць адносна хутка пададзена праз сховішча ключоў. Такім чынам, такая зводная канструкцыя сховішча ключоў можа стаць цэнтрам для пераадолення на аснове намераў, дазваляючы карыстальнікам адпраўляць транзакцыі імгненна, а не за некалькі хвілін, не плацячы амаль нічога за пераадоленне. Каманда зборнай можа таксама забяспечыць ліквіднасць для пераадолення праз сховішча ключоў 1:1, і гэта не будзе каштаваць ім шмат. Адзіная назва ENS для ўсіх ланцугоў Уявіце сабе, што ў вас ёсць адно , якое вырашае ўсе вашы міні-акаўнты, незалежна ад таго, у якой ланцужку знаходзіцца атрымальнік. Гэтая канструкцыя робіць гэта магчымым. як? імя карыстальніка.eth Паколькі мы ўжо ведаем адрас нашага асноўнага ўліковага запісу сховішча ключоў, мы можам выкарыстоўваць і каб зрабіць адрасы нашых міні-акаўнтаў аднолькавымі ва ўсіх ланцужках EVM, эквівалентных байткаду, нават уключаючы Ethereum L1. Затым мы ўсталёўваем уніфікаваны адрас у рэзолверы ENS, і наша імя працуе ва ўсіх EVM L2. шматланцуговыя фабрыкі CREATE2, Аднак ёсць два выключных выпадку: Для іх мы можам стварыць уласны адрас у адпаведнасці з іх правіламі CREATE2 і дадаць яго ў ENS з іх ідэнтыфікатарамі ланцужкоў у адпаведнасці з . Неэквівалентныя байт-коду EVM, такія як ZK Stack. ENSIP-11 Для іх такая ж логіка, але замест гэтага мы дадаем іх уласныя адрасы ў ENS у адпаведнасці з . Не-EVM L2, напрыклад наша сховішча ключоў. ENSIP-9 Нягледзячы на тое, што гэты падыход вельмі зручны для UX, гэты падыход патрабуе шмат дарагіх вылічэнняў і захоўвання на L1, таму што імёны і адрасы захоўваюцца ў рэзолверах L1. Гэтую праблему можна вырашыць з дапамогай , але я прыдумаў іншую, больш эфектыўную логіку дазволу ў ланцужку: CCIP Read Кожны ўліковы запіс у сховішчы ключоў рэгіструецца і індэксуецца хэшам імя ENS (зарэгістраваным пад адзіным імем ENS з карыстальніцкім распознавальнікам). Калі яго паддамен вырашаны, кантракт рэзолвера правярае, ці існуе ўліковы запіс з такім хэшам імя ў зборцы, і выкарыстоўвае хэш імя для стварэння адрасоў міні-рахункаў на аснове . CREATE2 Калі яны будуць разгорнуты, яны запытаюць у L1 даныя сховішча ключоў з якім яны былі разгорнуты. Гэта можа быць сам намер транзакцыі або проста бягучы ключ подпісу, у залежнасці ад рэалізацыі сховішча ключоў. Такім чынам, мы атрымліваем уліковыя запісы сховішча ключоў, кожны з імем ENS, які вызначае сябе і яго міні-акаўнты пры кожным зборы. Гэтыя міні-рахункі, у сваю чаргу, таксама будуць абапірацца на імя ENS пры праверцы транзакцыі з выкарыстаннем зводнага сховішча ключоў. , якія адносяцца да хэша імя, ** Механізмы паслядоўнасці ў зводных пакетах «Keystore+». Паколькі канчатковасць моста для пашыранага зводнага сховішча ключоў павінна складаць некалькі блокаў L1, мы таксама можам цалкам пазбавіцца ад цэнтралізаваных секвенсараў, ператварыўшы яго ў зводны пакет. Як мы ўжо абмяркоўвалі раней, ~12 секунд хуткасці транзакцыі з'яўляецца прымальным для сярэдняга карыстальніка, але паслядоўнасць на аснове зробіць зборку значна больш устойлівай да цэнзуры і адзінкавых кропак адмовы. Варта ўлічыць, што пры секвеніраванні на аснове ўнутраныя транзакцыі будуць займаць столькі ж часу, колькі і знешнія (за выключэннем часу на дасягненне L2). Гэта можа быць непрымальна для некаторых каманд, паколькі цэнтралізаваная паслядоўнасць робіць усе ўнутраныя аперацыі імгненнымі. Альтэрнатыўныя зводныя рашэнні ўзаемадзеяння або: чаму я не згадаў агульную паслядоўнасць Я напісаў увесь артыкул пра ZK rollups і ZK technology. Гэта тлумачыцца тым, што аптымістычныя зборы прынцыпова не могуць мець хуткай аб'ектыўнай канчатковасці, і такая ўласцівасць даступная толькі з дапамогай ZK. Сённяшнія аптымістычныя агрэгаты разумеюць сваю замкнёную пазіцыю і актыўна даследуюць магчымасць інтэграцыі арыентаваных на сапраўднасць канструкцый у свае стэкі, адсюль, напрыклад, . нядаўняе партнёрства Optimism і RISC Zero Аптымістычны дызайн прынцыпова абмежавальны ў тым сэнсе, што ён ніколі не будзе працаваць з іншымі зводнымі пакетамі. Аднак сумяшчальнасць аптымістычнай экасістэме хутка развіваецца. Асноўнай тэхналогіяй для забеспячэння ўзаемадзеяння аптымістычных зводных пакетаў з'яўляецца . Прасцей кажучы, гэта механізм, пры якім секвенсор можа ствараць пакет для некалькіх зводных пакетаў адначасова. Калі якая-небудзь транзакцыя ў любым з паслядоўных збораў несапраўдная, усю партыю можна аспрэчыць і адмяніць. у сумесная паслядоўнасць Гэта надае ўсім партыям гэтай «мегапартыі» атамарную ўласцівасць — або ўсе партыі сапраўдныя, або ніводнай. Гэта, у сваю чаргу, дазваляе атамарна сінхронную кампазіцыю ўнутры партыі. Атамны — таму што нішто ў пакете не можа быць несапраўдным, калі ён сапраўдны, сінхронны — таму што ўвесь абмен паведамленнямі знаходзіцца ўнутры пакета, які апрацоўваецца адначасова ўсімі вузламі зводных пакетаў. Гэтая тэхналогія ў асноўным ператварае ўсе зборы ў пэўным аптымістычным стэку ў адзін вялікі сегментаваны збор. Чаму толькі адзін стос, а не ўсе? Таму што для таго, каб гэта працавала, зводныя пакеты павінны быць падлучаны да аднаго моста. Кожны стэк мае свой уласны мост, і няма надзейнага спосабу ствараць партыі ў некалькіх мастах адначасова. Гэта азначае, што агульная паслядоўнасць дазваляе OP Mainnet бесперашкодна ўзаемадзейнічаць з Base і Zora, але не з Arbitrum або Metis, і наадварот. Такая кансалідацыя стварае небяспечную сітуацыю ў экасістэме rollup. Новыя зводныя пакеты маюць магчымасць або далучыцца да існуючага стэка і інтэгравацца з ім, але не з кім-небудзь яшчэ, АБО будаваць на аснове ZK і інтэгравацца з кім заўгодна, акрамя стэка вышэй. Цяпер такога выбару няма, таму што агульная паслядоўнасць яшчэ недаступная, і кожны зборны пакет OP Stack або Arbitrum Orbit незалежны і мае ўласны мост. Аднак, калі яны аб'ядноўваюцца, яны ўтвараюць два цвёрдыя арганізмы ў экасістэме, кожны з якіх утрымлівае . каля 40% ад агульнага L2s TVL «Добра. Калі яны будуць трымаць пераважную большасць агульнага ТВЛ, чаму б нам не пазбавіцца ад ЗК і не пабудаваць іх?» Перш за ўсё, агульныя секвенсоры - гэта велізарны драйвер цэнтралізацыі. Калі вы запускаеце секвенсор OP Mainnet, вашы пакеты не будуць уключаць транзакцыі з іншых зводных пакетаў у стэку; вы будзеце зарабляць менш на ганарарах і ў канчатковым выніку вас зацямняць буйныя камерцыйныя секвенсоры, якія могуць апрацоўваць увесь стэк у сваіх партыях. Аднак найбольш важнай праблемай з'яўляецца тое, што ў такім выпадку экасістэма згортвання замыкаецца ў якія пераследуюць свае ўласныя інтарэсы, імкнуцца ўстанавіць большы кантроль над капіталам і затрымліваюць тэхналагічны прагрэс у экасістэме. У такім выпадку нам давядзецца мець справу з тым, што Ethereum раздушаны ў асобную вобласць, дзе піяр і ўнутрывідавая барацьба маюць значэнне, а не тэхналогіі, якія сапраўды змяняюць свет. алігапалістычных імперыях, . Імперыі спрабуюць захапіць і злавіць карыстальніка ў агароджаным садзе; інструменты выконваюць сваю задачу, але ў іншым выпадку ўзаемадзейнічаюць з больш шырокай адкрытай экасістэмай», — «Стварайце прылады, а не імперыі Віталік Бутэрын «Чым агрэгаванне агульных мастоў у ZK лепшае за аптымістычную агульную паслядоўнасць?» У агульных мастах ZK rollups паслядоўнасць можа быць зроблена незалежна ад іншых rollups у мосце. Кожны звод можа мець уласны секвенсор або рэалізаваць агульную паслядоўнасць. , якія сцвярджаюць выніковы корань стану пасля ўсіх паслядоўных пакетаў і даказваюць гэта з дапамогай ZK, - гэта тыя, хто займаецца агрэгацыяй. Прапаноўшчыкі Больш за тое, характарыстыка адносна хуткай аб'ектыўнай канчатковасці ў зводных пакетах ZK не робіць іх замкнёнымі ў сваёй экасістэме, незалежна ад таго, наколькі вялікай яна расце або наколькі цэнтралізаванай. Калі ZK будзе развіты да ўзроўню, пры якім можна будзе хутка ствараць вялікія доказы zkVM для некалькіх сістэм доказаў, усе зводныя стэкі на аснове ZK будуць узаемадзейнічаць амаль бесперашкодна, гэтак жа, як тэарэтычнае звядзенне сховішча ключоў, апісанае вышэй, адпраўляе транзакцыі ва ўсіх іншых зборах за L1 блокі. «Але чаму аптымістычныя зборы ўсё яшчэ існуюць, калі яны такія злыя, і ёсць альтэрнатыва ў зборах ZK?» У нашай суполцы даследчыкаў і высокатэхнічных людзей кансенсус заключаецца ў тым, што ZK з'яўляецца лепшым рашэннем для маштабавання. І вы са здзіўленнем зразумееце, што для звычайных карыстальнікаў і будаўнікоў аптымістычныя роллапы нашмат лепш, чым ЗК! Як так? : існуе добра наладжаная экасістэма. Усе платформы ведаюць, што такое Arbitrum і Base, dApps заўсёды маюць высокую ліквіднасць, а UX духмяны. Паспрабуйце назваць прыкладанне на Base, і вы імгненна ўспомніце , , , (цяпер эксклюзіў для Solana), розныя калекцыі NFT, ZKP2P. Нават Mirror першапачаткова падтрымліваў толькі зводныя пакеты OP Stack для чаканкі. Паспрабуйце назваць прыкладанне на ZKsync Era. Для карыстальнікаў Friend.tech Farcaster Daimo Time.fun Э-э-э... : існуе абсалютная эквівалентнасць Ethereum, таму ўся інфраструктура форкаў Ethereum і EVM працуе адразу. Акрамя таго, дакументацыя скрупулёзна вызначае і тлумачыць усе асаблівасці і інструменты аптымістычных згортванняў. Ёсць шмат падручнікаў, курсаў, марафонаў, адносін з распрацоўшчыкамі і гэтак далей. Для распрацоўшчыка З іншага боку, ёсць zkEVM гадавой даўнасці, не ўсе з якіх нават маюць эквівалентнасць байт-коду. Усе яны маюць і цяжкасцей, якія ўзнікаюць на іх аснове. Яны ў асноўным дрэнна задакументаваныя, і існуе значная залежнасць ад існуючай інфраструктуры, якая практычна не сумяшчальная з сеткамі. Аўдыт «сумяшчальных» віртуальных машын вельмі складаны і дарагі, і вам нават не трэба спытаць ChatGPT. доўгі спіс адрозненняў Зборныя пакеты ZK не маюць экасістэмы. Тут няма прыкладанняў для выкарыстання, сацыяльных сетак, папулярных NFT або токенаў, і ўся дзейнасць зводзіцца да аэрадропнай фермы. Вы ледзь знойдзеце ліквіднасць для пар, якія не ўваходзяць у топ-10 экасістэмы Ethereum, і пачынае паказваць зборныя ZK, калі вы стамляецеся пракручваць. Для карыстальнікаў: DefiLlama «Але аптымістычныя зводныя праграмы насамрэч выйграюць дзякуючы сумяшчальнасці з існуючай інфраструктурай. Як ZK rollups можа перамагчы іх у гэтым?» Вам неабавязкова ўводзіць эквівалентнасць байт-коду або папярэднюю кампіляцыю , каб прыцягнуць распрацоўшчыкаў і дзейнасць на вашу платформу. ZK rollups не павінны быць лепшымі ў гэтым плане. Замест гэтага, у іх хуткай канчатковасці і сумяшчальнасці, цалкам гарызантальнай маштабаванасці, фундаментальна больш высокай бяспецы і дэцэнтралізацыі. Гэта тое, што трэба выкарыстоўваць у праектах у экасістэме ZK rollups, каб зрабіць іх выгаднымі ў экасістэме. blake2f Я напісаў гэты артыкул, каб скласці поўную карціну ўсіх гэтых тэхналогій, у тым ліку ZK rollups, якія з'явіліся і развіліся ў гэтай галіне за гэты час, і паказаць, як іх можна выкарыстоўваць для вырашэння самай важнай сучаснай праблемы ў гэтай галіне — сумяшчальнасці rollup. Мы павінны прыняць ZK і яго бязмежныя перавагі. Мы павінны выкарыстоўваць іх у сваіх інтарэсах, каб ствараць рэчы, якія набліжаюць нас да таго, каб зрабіць Web3 месцам для ўсіх у свеце. Магчыма, гэта самая вялікая параўнальная табліца, якую я калі-небудзь рабіў. Нядзіўна — за апошні год супольнасць Ethereum прыдумала шмат новых ідэй і тэхналогій, якія можна гнутка камбінаваць і маніпуляваць імі для стварэння цалкам новых рашэнняў, якія вырашаюць самыя вострыя праблемы ў гэтай галіне, нават з існуючымі тэхналогіямі. Так, я па-ранейшаму перакананы, што сумяшчальнасць зводных пакетаў з'яўляецца самай актуальнай праблемай, якая перашкаджае нам падключыць увесь свет да Web3. Маштабаванне ўжо не так актуальна — 4844 дазваляе нам апрацоўваць да тысячы транзакцый у секунду, што параўнальна з фінансавай актыўнасцю ў найбуйнейшых краінах свету; Хутка з'явіцца , які яшчэ больш павялічыць гэта. Аднак фрагментацыя па-ранейшаму ўяўляе сур'ёзную пагрозу для экасістэмы Ethereum. Незалежна ад таго, наколькі буйной яна будзе расці, экасістэма павінна выглядаць не як тузін асобных імперый, а як адзін вялікі механізм. Такія розныя, але такія аднолькавыя. PeerDAS Мы не рана, і гэты артыкул павінен паказаць вам гэта. Мы павінны выкарыстоўваць усе нашы сілы для распрацоўкі працоўных сістэм, якія дапамагаюць узаемадзейнічаць гіганцкай экасістэме L2. Гэта магчыма прама цяпер. Неўзабаве вы зможаце ўдзельнічаць у любых DAO і адпраўляць любыя актывы ў ENS, уладальнік якіх знаходзіцца ў некалькіх тысячах кіламетраў ад вас. Нельга замяняць геаграфічныя межы лічбавымі. Калі вам спадабалася гэтая праца, вы згодны з яе тэзісам, даведаліся нешта новае або хочаце распаўсюдзіць гэтае паведамленне далей — падзяліцеся ім у сацыяльных сетках, пакіньце каментарыі і больш расказвайце пра важнасць узаемадзеяння зводных пакетаў. Дзякуй за чытанне. Заўвага аўтара: версія гэтага артыкула была раней апублікаваная . тут