Особлива подяка Дену Фінлею, Карлу Флоершу, Девіду Хоффману та командам Scroll і SoulWallet за відгуки, рецензії та пропозиції.

По мірі того, як Ethereum переходить від молодої експериментальної технології до зрілого технологічного стеку, здатного забезпечити відкритий, глобальний і бездозвільний досвід для пересічних користувачів, є три основні технічні зміни, які стек повинен пройти приблизно одночасно:

• Перехід до масштабування L2 - всі переходять на рулони
• Перехід до безпеки гаманців - всі переходять на гаманці зі смарт-контрактами
• Перехід до приватності - забезпечення доступності грошових переказів із збереженням приватності, а також забезпечення того, щоб усі інші гаджети, які розробляються (соціальне відновлення, ідентичність, репутація), зберігали приватність.

Трикутник переходу екосистеми. Ви можете вибрати лише 3 з 3.

Без першого Ethereum зазнає невдачі, оскільки кожна транзакція коштує $3,75 ($82,48, якщо у нас буде ще один бичачий ривок), а кожен продукт, націлений на масовий ринок, неминуче забуває про ланцюжок і приймає централізовані обхідні шляхи для всього.

Без другої Ethereum зазнає невдачі, оскільки користувачам незручно зберігати свої кошти (і нефінансові активи), і всі переходять на централізовані біржі.

Без третього, Ethereum зазнає невдачі, тому що наявність всіх транзакцій (і POAP, і т.д.) у відкритому доступі для буквально кожного - це занадто велика жертва конфіденційності для багатьох користувачів, і всі переходять на централізовані рішення, які хоча б трохи приховують ваші дані.

Ці три переходи мають вирішальне значення з наведених вище причин. Але вони також є складними через необхідність інтенсивної координації для їх належного вирішення. Потребують поліпшення не тільки функції протоколу; в деяких випадках спосіб взаємодії з Ethereum повинен змінитися досить фундаментально, що вимагає глибоких змін з боку додатків і гаманців.

Три переходи докорінно змінять відносини між користувачами та адресами

У світі масштабування L2 користувачі будуть існувати на багатьох L2. Чи є ви членом ExampleDAO, яка живе на Оптимізмі? Тоді у вас є акаунт на Оптимізмі! Ви тримаєте CDP в системі стейблкоінів на ZkSync? Тоді у вас є обліковий запис на ZkSync! Ви колись пробували якийсь додаток, який випадково опинився на Какароті? Тоді у вас є акаунт на Kakarot! Часи, коли користувач мав лише одну адресу, минули.

У мене є ETH в чотирьох місцях, якщо вірити моєму гаманцю Brave Wallet. І так, Arbitrum та Arbitrum Nova відрізняються. Не хвилюйтеся, з часом все стане ще більш заплутаним!

Гаманці смарт-контрактів додають ще більшої складності, оскільки набагато складніше мати одну і ту ж адресу на L1 і різних L2. Сьогодні більшість користувачів використовують зовнішні акаунти, адреса яких є буквально хешем відкритого ключа, який використовується для перевірки підписів - тому між L1 і L2 нічого не змінюється. Однак з гаманцями смарт-контрактів зберігати одну адресу стає складніше. Хоча було зроблено багато роботи, щоб зробити адреси хешами коду, які можуть бути еквівалентними в різних мережах, зокрема CREATE2 і фабрика синглетонів ERC-2470, важко зробити так, щоб це працювало бездоганно. Деякі L2 (напр. "ZK-EVMsтипу 4 ") не зовсім еквівалентні EVM, часто замість них використовується Solidity або проміжна збірка, що перешкоджає хеш-еквівалентності. І навіть коли ви можете мати хеш-еквівалентність, можливість зміни власника гаманця через зміну ключа створює інші неінтуїтивні наслідки.

Конфіденційність вимагає, щоб кожен користувач мав ще більше адрес, і може навіть змінювати, з якими саме адресами ми маємо справу. Якщо пропозиції стелс-адрес ста нуть широко використовуваними, замість того, щоб кожен користувач мав лише кілька адрес або одну адресу на L2, користувачі можуть мати одну адресу на одну транзакцію. Інші схеми конфіденційності, навіть вже існуючі, такі як Tornado Cash, змінюють спосіб зберігання активів по-іншому: кошти багатьох користувачів зберігаються в одному смарт-контракті (а отже, за однією адресою). Щоб надіслати кошти конкретному користувачеві, користувачі повинні покладатися на власну внутрішню систему адресації схеми конфіденційності.

Як ми бачили, кожен з трьох переходів по-різному послаблює ментальну модель "один користувач ~= одна адреса", і деякі з цих ефектів впливають на складність виконання переходів. Дві особливі складності полягають у наступному:

1. Якщо ви хочете заплатити комусь, як ви отримаєте інформацію про те, як заплатити?
2. Якщо користувачі мають багато активів, що зберігаються в різних місцях у різних ланцюжках, як вони здійснюють ключові зміни та соціальне відновлення?

Три переходи та платежі в ланцюжку (і ідентичність)

У мене є монети на Scroll, і я хочу заплатити за каву (якщо "я" - це буквально я, автор цієї статті, то "кава" - це, звісно, метонімія до "зеленого чаю"). Ви продаєте мені каву, але налаштовані лише на отримання монет на Тайко. Що робити?

В основному є два рішення:

1. Гаманці-одержувачі (якими можуть бути як торговці, так і звичайні люди) дуже стараються підтримувати кожен L2 і мають певний автоматизований функціонал для асинхронної консолідації коштів.
2. Одержувач вказує свій L2 разом зі своєю адресою, і гаманець відправника автоматично переказує кошти на L2 одержувача через певну систему перехресних L2-зв'язків.

Звичайно, ці рішення можна комбінувати: одержувач надає список L2, які він готовий прийняти, а гаманець відправника розраховує оплату, яка може включати або прямий переказ, якщо йому пощастить, або перехресний L2-переказ.

Але це лише один з прикладів ключової проблеми, яку створюють ці три переходи: такі прості дії, як сплата комусь, починають вимагати набагато більше інформації, ніж просто 20-байтна адреса.

Перехід на гаманці смарт-контрактів, на щастя, не є великим навантаженням на систему адресації, але в інших частинах стека додатків все ще існують деякі технічні проблеми, які необхідно вирішити. Гаманці потрібно буде оновити, щоб переконатися, що вони не відправляють тільки 21000 gas разом з транзакцією, і ще важливіше буде переконатися, що сторона, яка отримує платіж, відстежує не тільки перекази ETH з EOA, але і ETH, відправлені за допомогою коду смарт-контракту. Додатки, які покладаються на припущення, що власник адреси є незмінним (наприклад NFT, які забороняють смарт-контракти для стягнення роялті) доведеться шукати інші способи досягнення своїх цілей. Гаманці смарт-контрактів також спростять деякі речі - зокрема, якщо хтось отримає лише токен ERC20, який не є ETH, він зможе використовувати пей-майстри ERC-4337 для оплати за газ цим токеном.

З іншого боку, приватність знову ставить серйозні виклики, з якими ми ще не впоралися. Початкова версія Tornado Cash не створювала жодних проблем, оскільки не підтримувала внутрішні перекази: користувачі могли лише вносити кошти в систему та виводити їх з неї. Однак після того, як ви зможете здійснювати внутрішні перекази, користувачам потрібно буде використовувати внутрішню схему адресації системи конфіденційності. На практиці, "платіжна інформація" користувача повинна містити (i) певний "публічний ключ", тобто зобов'язання зберігати таємницю, яку одержувач може використовувати для здійснення витрат, і (ii) спосіб відправника надсилати зашифровану інформацію, яку може розшифрувати лише одержувач, щоб допомогти одержувачу виявити платіж.

Протоколи стелс-адрес покладаються на концепцію мета-адрес, які працюють наступним чином: одна частина мета-адреси є прихованою версією ключа витрат відправника, а інша частина - ключем шифрування відправника (хоча мінімальна реалізація може встановити ці два ключі однаковими).

Схематичний огляд абстрактної схеми стелс-адреси, заснованої на шифруванні та ZK-SNARK'ах.

Ключовий урок тут полягає в тому, що в екосистемі, дружній до приватності, користувач матиме як публічні ключі витрат, так і публічні ключі шифрування, а "платіжна інформація" користувача повинна містити обидва ключі. Є й інші вагомі причини, окрім платежів, щоб розширюватися в цьому напрямку. Наприклад, якщо ми хочемо отримати зашифровану електронну пошту на основі Ethereum, користувачам потрібно буде публічно надати якийсь ключ шифрування. У "світі EOA" ми могли б повторно використовувати для цього ключі від облікових записів, але у світі безпечних смарт-гаманців з контрактами нам, ймовірно, слід мати для цього більш чіткий функціонал. Це також допоможе зробити ідентифікацію на основі Ethereum більш сумісною з децентралізованими екосистемами конфіденційності, що не належать до Ethereum, зокрема, з ключами PGP.

Три переходи та відновлення ключів

Стандартний спосіб впровадження ключових змін та соціального відновлення у світі з багатьма адресами на користувача полягає в тому, що користувачі просто запускають процедуру відновлення на кожній адресі окремо. Це можна зробити в один клік: гаманець може містити програмне забезпечення для виконання процедури відновлення за всіма адресами користувача одночасно. Однак навіть з такими спрощеннями UX наївне багатоадресне відновлення має три проблеми:

1. Недоцільність витрат на газ: тут все зрозуміло.
2. Контрфактичні адреси: адреси, для яких смарт-контракт ще не опублікований (на практиці це буде означати рахунок, з якого ви ще не відправляли кошти). Ви, як користувач, маєте потенційно необмежену кількість контрфактичних адрес: одну або більше на кожному L2, включаючи L2, які ще не існують, і цілий інший нескінченний набір контрфактичних адрес, що виникають за допомогою схем стелс-адрес.
3. Конфіденційність: якщо користувач навмисно має багато адрес, щоб не пов'язувати їх один з одним, він, звичайно, не захоче публічно пов'язувати їх всі, відновлюючи їх одночасно або приблизно в один і той же час!

Вирішити ці проблеми складно. На щастя, існує дещо елегантне рішення, яке працює досить добре: архітектура, яка розділяє логіку верифікації та зберігання активів.

Кожен користувач має контракт зі сховищем ключів, яке існує в одному місці (це може бути як основна мережа, так і певний L2). Таким чином, користувачі мають адреси на різних L2, де логіка перевірки кожної з цих адрес є вказівником на контракт зі сховищем ключів. Витрати з цих адрес вимагатимуть підтвердження, яке буде включено до контракту на зберігання ключів і показуватиме поточні (або, що більш реалістично, зовсім нещодавні) витрати відкритого ключа.

Доведення може бути реалізовано кількома способами:

• Прямий доступ L1 тільки для читання всередині L2. Можна модифікувати L2 так, щоб вони могли безпосередньо зчитувати стан L1. Якщо контракт зі сховищем знаходиться на L1, це означає, що контракти всередині L2 можуть отримати доступ до сховища "безкоштовно"
• Меркле розгалужується. Гілки Меркла можуть доводити стан L1 для L2, або стан L2 для L1, або ви можете комбінувати ці два способи, щоб довести частину стану одного L2 для іншого L2. Основним недоліком доказів Меркла є високі витрати на газ через довжину доказу: потенційно 5 кБ для доказу, хоча в майбутньому цей показник зменшиться до < 1 кБ завдяки деревам Веркле.
• ZK-SNARKs. Ви можете зменшити витрати на передачу даних, використовуючи ZK-SNARK гілки Merkle замість самої гілки. Можна побудувати методи позаланцюгової агрегації (наприклад, на основі EIP-4337), щоб один єдиний ZK-SNARK перевіряв усі крос-ланцюгові докази стану в блоці.
• Зобов'язання в тенге. Або L2, або схеми, побудовані на їх основі, можуть запровадити послідовну систему адресації, що дозволяє докази стану всередині цієї системи мати довжину всього 48 байт. Як і у випадку з ZK-SNARK, схема з декількома доказами може об'єднати всі ці докази в один доказ на блок.

Якщо ми хочемо уникнути створення одного підтвердження на кожну транзакцію, ми можемо реалізувати більш легку схему, яка вимагає лише крос-L2 підтвердження для відновлення. Витрати з облікового запису залежатимуть від витратного ключа, відповідний публічний ключ якого зберігається в цьому обліковому записі, але для його відновлення потрібна транзакція, яка копіює поточний витратний_публічний ключ у сховищі ключів. Кошти на контрфактичних адресах безпечні, навіть якщо ваші старі ключі не є безпечними: "активація" контрфактичної адреси, щоб перетворити її на робочий контракт, вимагатиме створення перехресного L2-доказу для копіювання поверх поточного spending_pubkey. У цій темі на форумі Safe описано, як може працювати подібна архітектура.

Щоб додати приватності такій схемі, ми просто шифруємо вказівник, а всі доведення виконуємо всередині ZK-SNARKs:

З більшою кількістю роботи (напр. використовуючи <a href="https://notes.ethereum.org/@vbuterin/non_index_revealing_proof"> this роботу як відправну точку), ми також могли б прибрати більшу частину складності ZK-SNARK і створити більш просту схему на основі KZG.

Ці схеми можуть ускладнюватися. З іншого боку, між ними існує багато потенційних синергій. Наприклад, концепція "контрактів на зберігання ключів" також може бути рішенням проблеми "адрес", згаданої в попередньому розділі: якщо ми хочемо, щоб користувачі мали постійні адреси, які не змінюються кожного разу, коли користувач оновлює ключ, ми можемо внести стелс-мета-адреси, ключі шифрування та іншу інформацію в контракт на зберігання ключів, і використовувати адресу контракту на зберігання ключів як "адресу" користувача.

Багато вторинної інфраструктури потребує оновлення

Використання ENS є дорогим. Сьогодні, у червні 2023 року, ситуація не така вже й погана: плата за транзакцію значна, але все ще порівнянна з платою за домен ENS. Реєстрація zuzalu.eth обійшлася мені приблизно в $27, з яких $11 - комісія за транзакцію. Але якщо у нас буде ще один бичачий ринок, гонорари злетять до небес. Навіть без підвищення ціни ETH, повернення плати за газ до 200 gwei призведе до збільшення податкового збору за реєстрацію домену до $104. Отже, якщо ми хочемо, щоб люди дійсно використовували ENS, особливо для таких випадків використання, як децентралізовані соціальні мережі, де користувачі вимагають майже безкоштовної реєстрації (і плата за домен ENS не є проблемою, оскільки ці платформи пропонують своїм користувачам субдомени), нам потрібно, щоб ENS працювала на L2.

На щастя, команда ENS активізувалася, і ENS на L2 дійсно відбувається! ERC-3668 (також відомий як "стандарт CCIP") разом з ENSIP-10 забезпечує можливість автоматичної перевірки субдоменів ENS на будь-якому L2. Стандарт CCIP вимагає створення смарт-контракту, який описує метод перевірки доказів даних на L2, а також домен (наприклад, домену). Optinames використовує ecc.eth) можна поставити під контроль такого контракту. Після того, як контракт CCIP контролює ecc.eth на L1, доступ до певного субдомену.ecc.eth автоматично передбачає пошук і перевірку доказу (напр. Merkle branch) держави в L2, яка фактично зберігає цей конкретний субдомен.

Насправді отримання доказів передбачає перехід до списку URL-адрес, що зберігаються в контракті, що схоже на централізацію, хоча я б стверджував, що це не так: це модель довіри 1 з N (недійсні докази відловлюються логікою перевірки у функції зворотного виклику CCIP-контракту, і поки хоча б одна з URL-адрес повертає дійсний доказ, ви в безпеці). Список URL-адрес може містити десятки з них.

Зусилля ENS CCIP - це історія успіху, і її слід розглядати як ознаку того, що радикальні реформи, яких ми потребуємо, насправді можливі. Але є ще багато інших реформ на рівні додатків, які потрібно буде зробити. Кілька прикладів:

• Багато додатків залежать від користувачів, які надають позаланцюгові підписи. З рахунками, що належать зовнішнім користувачам (EOA), це легко зробити. ERC-1271 надає стандартизований спосіб зробити це для гаманців смарт-контрактів. Однак, багато додатків все ще не підтримують ERC-1271; їм доведеться це зробити.
• Даппи, які використовують питання "чи це EOA?" для дискримінації користувачів і контрактів (наприклад, для запобігання передачі або примусового стягнення роялті), будуть зламані. Загалом, я не раджу намагатися знайти тут суто технічне рішення; з'ясування того, чи є конкретна передача криптографічного контролю передачею бенефіціарної власності, є складною проблемою і, ймовірно, не може бути вирішене без звернення до якихось позамережевих механізмів, керованих співтовариством. Швидше за все, програми повинні будуть менше покладатися на запобігання переказам, а більше - на такі методи, як податки Харбергера.
• Взаємодія гаманців з витратами та ключами шифрування має бути вдосконалена. В даний час гаманці часто використовують детерміновані підписи для генерації ключів для конкретних додатків: підписання стандартного nonce (наприклад, хешу імені додатку) закритим ключем EOA генерує детерміноване значення, яке не може бути згенероване без закритого ключа, і тому є безпечним в суто технічному сенсі. Однак ці методи є "непрозорими" для гаманця, не дозволяючи йому здійснювати перевірку безпеки на рівні користувацького інтерфейсу. У більш зрілій екосистемі підписання, шифрування та пов'язані з ними функції повинні будуть оброблятися гаманцями більш чітко.
• Легкі клієнти (напр. Helios) доведеться перевіряти L2, а не лише L1. Сьогодні легкі клієнти зосереджені на перевірці дійсності заголовків L1 (використовуючи протокол синхронізації легких клієнтів), а також на перевірці гілок Меркла стану L1 і транзакцій, що вкорінені в заголовку L1. Завтра їм також потрібно буде перевірити доказ стану L2, корінь якого знаходиться в корені стану, що зберігається в L1 (більш просунута версія цього завдання буде розглядати попередні підтвердження L2).

Гаманці повинні будуть захищати як активи, так і дані

Сьогодні гаманці займаються захистом активів. Все живе в ланцюжку, і єдине, що повинен захищати гаманець, - це приватний ключ, який в даний момент охороняє ці активи. Якщо ви зміните ключ, наступного дня ви зможете безпечно опублікувати свій попередній закритий ключ в Інтернеті. Однак у світі ZK це вже не так: гаманець не просто захищає облікові дані для автентифікації, він також зберігає ваші дані.

Перші ознаки такого світу ми побачили з Zupass, системою ідентифікації на основі ZK-SNARK, яка використовувалася в Зузалу. Користувачі мали приватний ключ, який вони використовували для автентифікації в системі, за допомогою якого можна було робити базові докази на кшталт "довести, що я є жителем Зузалу, не розкриваючи, якого саме". Але на систему Zupass також почали надбудовувати інші додатки, зокрема, марки (версія POAPs від Zupass).

Одна з моїх численних печаток Zupass, яка підтверджує, що я є гордим членом Team Cat.

Ключова перевага печаток над POAP полягає в тому, що вони є приватними: ви зберігаєте дані локально, і ви лише надаєте комусь печатку (або певні обчислення над печатками), якщо хочете, щоб вони мали цю інформацію про вас. Але це створює додатковий ризик: якщо ви втратите цю інформацію, ви втратите свої марки.

Звичайно, проблему зберігання даних можна звести до проблеми зберігання єдиного ключа шифрування: якась третя сторона (або навіть ланцюжок) може зберігати зашифровану копію даних. Це має зручну перевагу в тому, що ваші дії не змінюють ключ шифрування, а отже, не вимагають жодної взаємодії з системою, яка зберігає ваш ключ шифрування в безпеці. Але навіть якщо ви втратите ключ шифрування, ви втратите все. А з іншого боку, якщо хтось бачить ваш ключ шифрування, він бачить все, що було зашифровано цим ключем.

Де-факто рішення Zupass полягало в тому, щоб заохотити людей зберігати свої ключі на декількох пристроях (наприклад, на смартфонах, планшетних комп'ютерах). ноутбук і телефон), оскільки ймовірність того, що вони втратять доступ до всіх пристроїв одночасно, мізерно мала. Ми могли б піти ще далі і використовувати секретний доступ для зберігання ключа, розділеного між кількома хранителями.

Таке соціальне відновлення через MPC не є достатнім рішенням для гаманців, оскільки це означає, що не лише нинішні опікуни, а й попередні опікуни можуть вступити в змову з метою крадіжки ваших активів, що є неприйнятно високим ризиком. Але витік даних, як правило, є меншим ризиком, ніж повна втрата активів, і той, хто використовує дані з високими вимогами до конфіденційності, завжди може прийняти більший ризик втрати, якщо не створить резервну копію ключа, пов'язаного з цими вимогами до приватності.

Щоб не перевантажувати користувача візантійською системою декількох шляхів відновлення, гаманці, які підтримують соціальне відновлення, ймовірно, повинні будуть керувати як відновленням активів, так і відновленням ключів шифрування.

Повернення до ідентичності

Однією зі спільних рис цих змін є те, що концепція "адреси", криптографічного ідентифікатора, який ви використовуєте для представлення "вас" в ланцюжку, повинна буде радикально змінитися. "Інструкції, як зі мною взаємодіяти" більше не будуть просто ETH-адресою; вони повинні бути в тій чи іншій формі комбінацією декількох адрес на декількох L2, стелс-мета-адрес, ключів шифрування та інших даних.

Один із способів зробити це - зробити ENS вашим ідентифікатором: ваш запис ENS може містити всю цю інформацію, і якщо ви надішлете комусь bob.eth (або bob.ecc.eth, або...), вони могли б шукати і бачити все про те, як платити і взаємодіяти з вами, включаючи більш складні міждоменні способи і способи збереження конфіденційності.

Але цей підхід, орієнтований на ENS, має дві слабкі сторони:

• Занадто багато речей пов'язано з твоїм ім'ям. Твоє ім'я - це не ти, твоє ім'я - це один з багатьох твоїх атрибутів. Повинна бути можливість змінити ім'я, не змінюючи весь профіль особи і не оновлюючи цілу купу записів у багатьох додатках.
• Ви не можете мати неправдивих імен, які не відповідають дійсності. Однією з ключових UX-функцій будь-якого блокчейну є можливість надсилати монети людям, які ще не взаємодіяли з ланцюжком. Без такого функціоналу виникає пастка-22: взаємодія з ланцюжком вимагає сплати комісії за транзакції, а для цього потрібно... вже мати монети. ETH-адреси, включаючи адреси смарт-контрактів з CREATE2, мають цю функцію. Імена ENS не мають, тому що якщо два Боба вирішують, що вони є bob.ecc.eth, то обидва вирішують поза ланцюжком, що вони є bob.ecc.eth, немає можливості вибрати, хто з них отримає ім'я.

Одним з можливих рішень є включення більшої кількості речей до контракту на зберігання ключів, згаданого в архітектурі раніше в цьому пості. Контракт на зберігання ключів може містити всю різноманітну інформацію про вас і про те, як з вами взаємодіяти (а у випадку CCIP частина цієї інформації може бути поза мережею), і користувачі використовуватимуть свої контракти на зберігання ключів як основний ідентифікатор. Але фактичні активи, які вони отримують, зберігатимуться в найрізноманітніших місцях. Контракти сховища не прив'язані до імені, і вони є контрфактичними: ви можете згенерувати адресу, яка достовірно може бути ініціалізована лише контрактом сховища, що має певні фіксовані початкові параметри.

Інша категорія рішень пов'язана з повною відмовою від концепції адрес, звернених до користувача, в дусі платіжного протоколу Bitcoin. Одна з ідей полягає в тому, щоб більше покладатися на прямі канали зв'язку між відправником і одержувачем; наприклад, відправник може надіслати посилання на претензію (у вигляді URL-адреси або QR-коду), яке одержувач може використати для прийняття платежу за власним бажанням.

Незалежно від того, хто діє першим - відправник чи одержувач, більша довіра до гаманців, які безпосередньо генерують актуальну платіжну інформацію в режимі реального часу, може зменшити тертя. Тим не менш, постійні ідентифікатори зручні (особливо з ENS), а припущення про прямий зв'язок між відправником і одержувачем на практиці є дуже складним, тому ми можемо побачити комбінацію різних методів.

У всіх цих проектах першочерговим завданням є збереження децентралізації та зрозумілості для користувачів. Ми повинні переконатися, що користувачі мають легкий доступ до актуальної інформації про те, які їхні поточні активи і які повідомлення були опубліковані і призначені для них. Ці погляди повинні залежати від відкритих інструментів, а не від пропрієтарних рішень. Потрібно буде докласти чимало зусиль, щоб уникнути перетворення складної платіжної інфраструктури на непрозору "вежу абстракцій", в якій розробникам буде важко зрозуміти, що відбувається, і адаптувати її до нових умов. Незважаючи на труднощі, досягнення масштабованості, безпеки гаманців і конфіденційності для звичайних користувачів є вирішальним для майбутнього Ethereum. Йдеться не лише про технічну можливість, а й про фактичну доступність для звичайних користувачів. Ми повинні піднятися, щоб відповісти на цей виклик.

Відмова від відповідальності:.

1. Ця стаття передрукована з сайту[vitalik], всі авторські права належать первинному автору[Віталіку Бутеріну]. Якщо у вас є заперечення щодо цього передруку, будь ласка, зв'яжіться з командою Gate Learn, і вони оперативно його опрацюють.
2. Відмова від відповідальності: Погляди та думки, висловлені в цій статті, належать виключно автору і не є інвестиційною порадою.
3. Переклади статті іншими мовами виконані командою Gate Learn. Якщо не зазначено інше, копіювання, розповсюдження або плагіат перекладених статей заборонені.