Як вийти з принципу Rollup та інтегрувати платформу Web2 із Web3 із ширшою та більш відкритою структурою?
Автор Wuyue, Geek Web3
**Вступ: **Ця стаття перспективно представить парадигму проектування інфраструктури Web3, яка здається дещо унікальною – Парадигма консенсусу на основі сховища (SCP). Хоча ця модель дизайну продукту теоретично сильно відрізняється від основної модульної блокчейн-рішень, таких як Ethereum Rollup, але це дуже здійсненно з точки зору простоти впровадження та простоти підключення до платформи Web2, оскільки він має З самого початку я не мав наміру обмежуватися вузьким шляхом впровадження, як Rollup. хотів використати ширшу та відкритішу структуру для інтеграції платформи Web2 і засобів Web3, що можна назвати розумовим широко відкритим, творчим підходом.
Текст: Уявімо рішення для розширення загальнодоступного ланцюга з такими характеристиками:
- Він має швидкість, яку можна порівняти з традиційними додатками або біржами Web2, значно перевищуючи будь-який публічний ланцюжок, L2, зведення, бічний ланцюг тощо.
- Плата за газ відсутня, а вартість використання майже 0.
- Захищеність коштів є високою, набагато перевищує рівень безпеки централізованих засобів, таких як біржі, поступається Rollup, але перевищує або дорівнює боковим мережам.
- Такий же досвід користувача, що й Web2, без будь-яких знань про відкритий і закритий ключі, гаманці, інфраструктуру тощо блокчейну.
Таке рішення справді дуже захоплююче: з одного боку, воно фактично досягло максимального розширення ємності; з іншого боку, воно також заклало дуже міцну основу для масового впровадження Web3, фактично усунувши розрив між Web2 і Web3 досвід використання.
Однак ми, здається, не можемо уявити, скільки рішень може бути настільки повним, тому що справді надто мало основних обговорень і практики.
Ми використали розширення, дуже знайому тему, як вступ вище. Насправді SCP не обмежується розширенням. Його дизайн натхненний планами розширення та обговореннями спільноти публічних мереж, таких як Bitcoin та Ethereum. Його бачення та практичне застосування полягає у створенні нового покоління надійної інфраструктури, навіть обчислювальної платформи без блокчейну. **
Основні компоненти та принципи роботи SCP
Загалом, SCP також схожий на те, що спільноти Ethereum і Celestia називають «модульним блокчейном». Він має модулі, такі як рівень доступності даних, рівень виконання, рівень консенсусу та рівень розрахунків.
- Рівень доступності даних: передбачається широко визнаним і перевіреним загальнодоступним ланцюгом або сховищем як рівень доступності даних, таким як Ethereum, Arweave, Celestia тощо.
- Рівень виконання: Сервер, який використовується для отримання транзакцій користувачів і їх виконання, і в той же час пакетно надсилає дані транзакцій, підписаних користувачем, на рівень DA, подібно до секвенсора Rollup. Але рівень виконання не обов’язково має структуру зв’язаного списку в стилі блокчейну.Це може повністю складатися з бази даних Web2 + обчислювальної системи, але вся обчислювальна система має бути з відкритим кодом і прозорою.
- Консенсусний рівень: Він складається з групи вузлів. Вони перетягують дані, надіслані виконавчим рівнем, на рівень DA та використовують той самий алгоритм, що й виконавчий рівень, щоб працювати з цими даними, щоб підтвердити, чи результат вивід рівня виконання є правильним і може використовуватися як надлишковість для запобігання катастрофам для рівня виконання. Користувачі також можуть читати дані, повернуті кожним вузлом на рівні консенсусу, щоб переконатися, що на рівні виконання немає шахрайства.
- Рівень розрахунків: Він складається з групи вузлів і контрактів або адрес в інших ланцюгах. Він використовується для обробки поведінки користувачів, які поповнюють рахунок на SCP або знімають гроші з SCP. Він дещо схожий на режим роботи поперечно-ланцюгового моста. Вузол розрахункового рівня контролює функцію вилучення адреси поповнення за допомогою багатознакових контрактів або адрес на основі TSS. Під час поповнення користувач вносить активи на вказану адресу в ланцюжку, а при знятті надсилається запит.Після того, як вузол розрахункового рівня зчитує дані, він звільняє активи через мультипідпис або TSS. Рівень безпеки рівня розрахунків залежить від прийнятого механізму крос-ланцюга.
Практична структура SCP
Ми можемо зрозуміти парадигму SCP через наступну структуру. Продукт, який відповідає структурі SCP, може мати такі основні функції, як поповнення, переказ, зняття, обмін тощо, і може бути розширений на цій основі. На малюнку нижче показана схема такого продукту:
- Рівень DA проекту використовує постійне сховище Arweave, велике коло на зображенні.
- **Координатор, рівень виконання. **Користувач надсилає транзакцію координатору, координатор виконує операцію та відображає результати операції, а потім пакетами надсилає вихідні вхідні дані користувача на рівень DA.
- Детектор отримує вихідні дані транзакції, надіслані координатором з Arweave, і використовує алгоритм, узгоджений з координатором, для перевірки даних і результатів. Клієнт детектора також має відкритий вихідний код і може запускатися будь-ким.
- **Сторожі, група тестувальників, які відповідають за мультипідпис системи виведення коштів. **Запити на зняття коштів будуть перевірені та опубліковані на основі даних транзакцій. Крім того, сторож також відповідає за підписання пропозиції.
Ми можемо бачити всю систему, і консенсус, якого вони досягли, розташований поза ланцюгом. Це ядро консенсусної парадигми зберігання — вона відмовляється від системи консенсусу вузлів у стилі блокчейну та звільняє рівень виконання від важкого консенсусу. процес підтвердження вимагає роботи лише одного сервера, завдяки чому досягається майже необмежений TPS і економія. Це дуже схоже на Rollup, але SCP пішов іншим шляхом від Rollup, перетворивши його з спеціального варіанту використання для розширення ємності на нову модель переходу від Web2 до Web3. **
Координатор, згаданий вище, є сервером, але це не означає, що координатор може робити все, що забажає. Подібно до сортувальника Rollup, після того, як вихідні дані, надіслані користувачами, надсилаються партіями на Arweave, будь-хто може запустити програму детектора, щоб перевірити їх і порівняти зі статусом, який повертає координатор. ** Певною мірою це точно так само, як ідея додатків із написами. **
За такої архітектури централізований сервер і база даних не становлять фундаментальної проблеми. Це також ще один пункт парадигми SCP, який пов’язує та роз’єднує дві концепції «централізації» та «єдиного об’єкта» - **У системі без довіри можуть бути централізовані компоненти, **це можуть бути навіть основні компоненти, але це не впливає на загальну недовірливість.
Ми можемо вигукнути такий слоган: «Наступне покоління надійної інфраструктури не повинно покладатися на консенсусні протоколи, а має бути системами з відкритим вихідним кодом і мережами вузлів P2P».
Початковий намір людей, які винаходять і використовують блокчейн, полягає в тому, щоб не довіряти послідовним бухгалтерським книгам, не підроблюваним, відстежуваним та іншим звичайним фундаментальним принципам, які чітко викладені в документі про біткойн. **Але після Ethereum, **незалежно від того, чи це план розширення старого публічного ланцюга, чи Rollup, чи модульний блокчейн, кожен сформував мислення: те, що ми робимо, має бути блокчейном (він складається з консенсусного протоколу вузлів) або таке рішення, як Rollup, яке виглядає як ланцюжок (воно просто має структуру даних блокчейну, але вузли не обмінюються безпосередньо консенсусними повідомленнями).
Але тепер, за допомогою структури на основі SCP, навіть якщо це не блокчейн, можна досягти ряду вимог, таких як надійність, узгодженість бухгалтерської книги, відсутність підробок, відстеження тощо. Звичайно, передумовою є те, що має бути більш чіткими деталями реалізації.
Рівень виконання
Рівень виконання є ключовим у всій системі. Він виконує обчислювальний процес усієї системи та визначає, які програми можна запускати в системі.
Нескінченні можливі середовища виконання
Теоретично середовище виконання на рівні виконання може мати будь-яку форму, і можливості безмежні, залежно від того, як сторона проекту позиціонує свій проект:
*Обмін. На основі SCP можна побудувати відкриту, прозору біржу з високим TPS. Ця біржа може не тільки мати характеристики швидкості та нульової вартості CEX, але й підтримувати децентралізацію DEX. Тут різниця між CEX і DEX стає розмитою.
- Платіжна мережа. Подібно до Alipay, PayPal тощо.
- Підтримка віртуальної машини/блокчейну для завантаження програм/контрактів. Будь-який розробник може розгорнути на ньому будь-яку програму, поділитися всіма даними користувача з іншими програмами та працювати згідно з інструкціями користувача.
**SCP, модель дизайну, яка підтримує довільне середовище виконання, має свої унікальні переваги: **Вам більше не потрібно покладатися на певні компоненти з історичним багажем, особливо на концепцію «абстракції облікового запису», унікальну для спільноти Ethereum, що дуже важливо Кажуть, що це не є необхідним від природи.
В архітектурі SCP немає поняття абстракції облікового запису – ви можете використовувати стандартні облікові записи Web2 і облікові записи блокчейну за бажанням. З цієї точки зору багато зрілих випадків використання Web2 можна безпосередньо використовувати на SCP без переосмислення та створення. Це може бути перевагою SCP порівняно з Rollup. **
Прозорість і асиметрія
Система облікових записів була згадана вище. Делікатні читачі повинні були виявити, що, хоча SCP може використовувати систему облікових записів Web2, здається, є проблеми з її використанням без змін.
Бо вся ця система абсолютно прозора! Пряме використання моделі взаємодії між користувачем і сервером спричинить серйозні проблеми, що призведе до втрати безпеки для всієї системи. Давайте спочатку розглянемо, як працює традиційна модель сервер-користувач:
1. Реєстрація облікового запису: Користувач вводить ім’я користувача та пароль на сторінці реєстрації програми. Щоб захистити пароль користувача, сервер обробляє пароль за допомогою хеш-функції після його отримання. Щоб збільшити складність хешу та захистити від атак веселкової таблиці, пароль кожного користувача часто об’єднується з випадково згенерованим рядком (званим «сіль») і хешується разом. **Ім’я користувача, сіль і хеш зберігаються відкритим текстом у базі даних постачальника послуг і не розголошуються. **Але незважаючи на це, засолювання та обробка безпеки все одно потрібні для запобігання інсайдерам і атакам.
**2. Вхід користувача: ** Користувачі вводять своє ім’я користувача та пароль у формі входу. Система порівнює хеш-значення обробленого пароля з хеш-значенням, яке зберігається в базі даних. Якщо два хеші збігаються, користувач ввів правильний пароль, і процес входу продовжується.
3. Аутентифікація операції: Після проходження автентифікації входу система створить сеанс для користувача. Як правило, інформація про сеанс зберігається на сервері, і сервер надсилає ідентифікатор (наприклад, маркер) у браузер або програму користувача. Користувачам більше не потрібно повторно вводити ім’я користувача та пароль під час наступних операцій: браузер або програма збережуть ідентифікатор і додадуть його до кожного запиту, щоб вказати, що вони мають дозвіл від пов’язаного сервера.
Давайте розглянемо типову систему взаємодії користувача з блокчейном Web3:
1. Реєстрація облікового запису: Фактично не існує процесу реєстрації облікового запису та системи імені користувача та пароля. Облікові записи (адреси) не потрібно реєструвати, вони існують природним чином, і той, хто має закритий ключ, контролює обліковий запис. Закритий ключ випадковим чином генерується локально гаманцем і не передбачає процесу підключення до мережі.
2. Вхід користувача: Використання блокчейну не потребує входу. Більшість dApps не мають процесу входу, але підключаються до гаманця. Деякі dApps вимагатимуть від користувачів виконувати перевірку підпису після підключення до гаманця, щоб переконатися, що користувач дійсно володіє закритим ключем, а не просто передавати адресу гаманця в інтерфейс.
**3. Автентифікація операції: ** Користувач безпосередньо надсилає підписані дані вузлу. Після перевірки вузол транслюватиме транзакцію всій мережі блокчейн. Після досягнення консенсусу мережі блокчейн операцію користувача буде підтверджено .
Різниця між двома модами спричинена симетрією та асиметрією. В архітектурі сервер-користувач обидві сторони зберігають однакові секрети. В архітектурі блокчейн-користувач лише користувач володіє секретом.
Хоча рівень виконання SCP може не бути блокчейном, усі дані повинні бути синхронізовані з загальнодоступним рівнем DA.** Тому методи входу та перевірки операцій, які використовує SCP, мають бути асиметричними. **Але оскільки ми не хочемо, щоб користувачі зберігали приватні ключі, використовували гаманці та інші громіздкі дії та поганий досвід, які впливають на широкомасштабне впровадження, також існує великий попит на програми, побудовані на SCP, які використовують традиційні ідентифікаційні паролі або OAuth тристороння автентифікація для входу. Отже, як поєднати обидва?
Через асиметричну природу асиметричної криптографії та докази з нульовим знанням, я передбачив два можливі рішення:
- Якщо ви хочете використовувати систему ID-пароль, ви можете не включати цей модуль збереження пароля в SCP, щоб він не був видимим для інших. Рівень виконання SCP все ще використовує облікові записи відкритого та приватного ключів і логіку роботи блокчейну, і немає реєстрації, входу тощо. **Ідентифікатор користувача фактично відповідає закритому ключу. **Звичайно, цей приватний ключ не можна зберегти на стороні проекту. Більш можливим рішенням є використання 2-3 MPC для вирішення проблеми централізованого зберігання, не дозволяючи користувачам брати на себе тягар використання приватних ключів.
- **Якщо для входу використовується OAuth, як метод автентифікації можна використовувати JWT (Json Web Token). **Цей метод буде дещо більш централізованим, ніж наведений вище, оскільки він по суті покладається на сторонню службу входу, яку надає основний виробник Web2 для автентифікації.
- Якщо для входу в систему вперше використовується стороння програма, зареєструйте поля в JWT, які представляють ідентифікатор користувача та ідентифікатор постачальника послуг у системі. У подальших операціях користувача інструкції з операцій використовуються як загальнодоступні дані, а JWT в цілому використовується як таємний свідок для перевірки кожної транзакції користувача з ZKP.
- Кожен JWT має обмеження терміну дії, і користувач також подасть заявку на новий JWT під час наступного входу, тому немає необхідності зберігати його постійно. Крім того, ця система також має покладатися на JWK, який можна розуміти як відкритий ключ, наданий виробником для перевірки JWK. Тож також варто вивчити, як ввести JWK у систему децентралізованим способом і як мати справу з ротацією закритих ключів у майбутньому.
**Незалежно від того, який метод використовується, витрати на розробку та обчислення вищі, ніж у традиційного методу, але це також необхідна плата за децентралізацію. **Звичайно, якщо сторона проекту не вважає, що екстремальна децентралізація необхідна, або якщо на різних етапах розробки є різні етапи, це нормально без цих проектів, тому що децентралізація не є чорно-білою, але є сіра зона між.
Конфіденційність
Проблеми прозорості, згадані вище, впливають не лише на парадигму взаємодії користувача, але й на дані користувача. Дані користувача відкриваються безпосередньо. Хоча це не проблема в блокчейні, це неприйнятно в деяких програмах, тому розробники також можуть створювати системи приватних транзакцій.
ПЛАТА
Ще один момент, який заслуговує на увагу, – як заряджається виконавчий рівень. Тому що подача даних на рівень DA також вимагає витрат, включаючи роботу власного сервера. Перша основна мета традиційного блокчейну, який стягує з користувачів плату за газ, полягає в тому, щоб запобігти пошкодженню користувачами мережі транзакцій шляхом здійснення великої кількості повторних транзакцій, а друга — сортувати транзакції на основі газу. Web2 не має подібних проблем, тому є лише базові поняття, такі як флуд і DDoS.
**Рівень виконання може налаштовувати різні стратегії заряджання, як-от повністю безкоштовний або частково заряджений.**Він також може отримувати прибуток від інших поведінок, таких як MEV (дуже зрілий у секвенсорі), ринкова діяльність тощо.
Опір цензурі
Рівень виконання не є стійким до цензури і теоретично може забороняти транзакції користувачів без обмежень. У Rollup стійкість до цензури може бути гарантована функцією примусового збору в контракті L1, тоді як бічний ланцюг або публічний ланцюг є повною розподіленою мережею блокчейнів, і її важко цензурувати.
**Наразі немає чіткого вирішення проблеми опору цензурі, яка є проблемою парадигми SCP. **
Рівень консенсусу
Цей рівень складається з вільних вузлів. Ці вузли активно не утворюють мережу, тому він не є консенсусним рівнем у строгому сенсі, а використовується лише для підтвердження поточного статусу рівня виконання зовнішньому світу (наприклад, користувачам).
Наприклад, якщо у вас є сумніви щодо працездатності цих вузлів, ви можете завантажити їхній клієнт-детектор, який запускатиме той самий програмний код, що й координатор. **
Однак це схоже на Rollup. Оскільки дані надсилаються пакетами, статус, який повертається користувачеві на рівні виконання, завжди є новішим, ніж на рівні DA. Це передбачає проблему попереднього підтвердження:
**Виконавчий рівень надає користувачам попередньо підтверджені, м’які кінцеві результати, **оскільки вони ще не надіслані на рівень DA;
**Консенсусний рівень надає користувачам жорстку остаточність. **Користувачів це може не особливо хвилювати, але для програм, таких як перехресні ланцюгові мости, необхідно дотримуватися жорсткої остаточності. Наприклад, система внесення та зняття коштів біржі не повірить даним, які транслюються за межами ланцюга секвенсором Rollup. Вона повинна дочекатися, поки дані будуть завантажені в Ethereum, перш ніж їх розпізнати.
Окрім використання для підтвердження результатів, консенсусний рівень також відіграє дуже важливу роль, яка є надлишковістю запобігання катастрофам для рівня виконання. **Якщо виконавчий рівень постійно страйкує та вчиняє серйозні злочини, теоретично будь-який консенсусний рівень може взяти на себе роботу виконавчого рівня та отримувати запити користувачів. Якщо виникає така серйозна ситуація, спільнота повинна вибрати стабільний і надійний вузол як сервер рівня виконання.
Осадовий шар
Оскільки SCP не є Rollup, він не може забезпечити безнадійне зняття коштів, яке не потребує ручного втручання та повністю базується на криптографії та коді смарт-контракту, як рівень розрахунків для зведення Rollup. **Рівень безпеки перехресного ланцюжкового мосту SCP такий самий, як і для перехресного ланцюгового мосту стороннього ланцюга або стороннього свідкового мосту. **Для вивільнення активів йому потрібні авторизовані менеджери з кількома підписами. Ми називаємо це режимом свідка .
Зробити мост-свідок максимально децентралізованим — це тема багатьох досліджень міжланцюгових мостів. Через обмежений простір ми не будемо вдаватися тут у подробиці. На практиці добре розроблена платформа SCP також повинна мати надійного партнера з децентралізованим мостом, що підтримує багато підписів.
**Хтось може запитати, чому SCP не використовує ланцюжок зі смарт-контрактами як рівень DA? **Це дозволяє створювати повністю надійний шар розрахунків на основі контракту.
У довгостроковій перспективі, поки будуть подолані деякі технічні труднощі, якщо рівень DA розмістити на рівні DA з такими контрактами, як Ethereum, і можна скласти відповідні контракти для перевірки, SCP також може отримати таку ж безпеку розрахунків, як Rollup. Не потрібно використовувати кілька підписів.
Але на практиці це може бути не найкращим вибором:
- Ethereum не використовується спеціально для зберігання даних, і ціна занадто висока в порівнянні з чистим публічним ланцюгом зберігання даних. **Для парадигми SCP достатньо низькі або фіксовані витрати на зберігання є вирішальними. **Тільки таким чином можливо підтримувати пропускну здатність рівня Web2.
2.** Це доводить, що систему дуже важко розробити, тому що SCP може не тільки симулювати EVM, але й реалізувати будь-яку логіку. **І коли ми подивимося на такі команди, як Optimism, чиї докази шахрайства досі відсутні в Інтернеті, і на те, наскільки складно розробити zkEVM, ми можемо уявити, що вкрай важко реалізувати докази різних систем на Ethereum.
Таким чином, **зведене рішення — це рішення, яке має кращу практичну здійсненність лише за певних обставин.**Якщо ви плануєте впровадити ширше та відкритіше рішення, позбутися системи EVM та інтегрувати більше функцій Web2, тоді Ethernet Ідея Fang Rollup не підходить.
**SCP — це не певний план розширення загальнодоступного ланцюга, а більша архітектура обчислювальної платформи Web3, тому, очевидно, немає необхідності слідувати ідеї Ethereum Layer 2. **
Зображення порівняння SCP та інших парадигм
