Інтерпретація SCP: парадигма інфраструктури, що не потребує довіри, поза формулою зведення

Автор: Вуюе, Geek Web3

**Вступ:**Ця стаття перспективно представить парадигму проектування інфраструктури Web3, яка виглядає дещо безглуздо - Парадигма консенсусу зберігання SCP (Парадигма консенсусу на основі сховища), хоча ця модель дизайну продукту теоретично значно відрізняється від основних модульних блокчейн-рішень, таких як Ethereum Rollup, але у простоті посадки та складності підключення до платформи Web2 здійсненність дуже висока Оскільки з самого початку він не мав наміру обмежуватися вузьким шляхом реалізації, як Rollup, він хотів використовувати ширший і відкритіший фреймворк для злиття платформи Web2 з інфраструктурою Web3, що, можна сказати, є відкритим мозком і творчим підходом. Вступ: У цій статті ми представимо дещо складну парадигму проектування інфраструктури Web3 – Storage Consensus Paradigm (SCP) Хоча ця модель дизайну продукту теоретично значно відрізняється від основних модульних блокчейн-рішень, таких як Ethereum Rollup, вона дуже здійсненна з точки зору простоти реалізації та складності підключення до платформ Web2, оскільки він не має наміру обмежуватися вузьким шляхом реалізації, як Rollup із самого початку, і хоче інтегрувати платформу Web2 та засоби Web3 з ширшою та відкритішою структурою, що, можна сказати, є відкритим та творчим підходом.

Тіло: Уявімо схему масштабування публічного ланцюга з наступними характеристиками:

• Він має швидкість, порівнянну з традиційними додатками або біржами Web2, що значно перевищує будь-яку публічну мережу, L2, rollup, сайдчейн тощо.
• Плата за газ відсутня, а вартість користування практично нульова.
• Висока безпека коштів, далеко за межами централізованих засобів, таких як біржі, поступається Rollup, але перевищує або дорівнює Sidechain.
• Той самий користувацький досвід, що й Web2, без будь-яких знань про публічні та приватні ключі блокчейну, гаманці, інфраструктуру тощо.

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

Однак, здається, ми не можемо придумати багато рішень, які можуть бути настільки повними, тому що насправді занадто мало мейнстрімних дискусій і практики.

Ми використовували дуже знайому тему масштабування як вступ вище, насправді, **SCP не обмежується масштабуванням, **його натхнення для дизайну походить від Bitcoin, Ethereum та інших рішень для масштабування публічних ланцюгів та обговорень спільноти. Його бачення та практичне застосування полягає у створенні нового покоління інфраструктури Trustless і навіть обчислювальної платформи зі структурою, відмінною від Blockchain. **

Основні компоненти SCP та принцип їх роботи

Взагалі кажучи, SCP також схожий на те, що спільноти Ethereum і Celestia називають «модульним блокчейном», з рівнем доступності даних, рівнем виконання, рівнем консенсусу, рівнем розрахунків та іншими модулями.

Рівень доступності даних: здійснюється широко відомою та перевіреною загальнодоступною мережею або сховищами як рівнем доступності даних, такими як Ethereum, Arweave, Celestia тощо. Виконавчий рівень: сервер, який отримує та виконує транзакції користувачів і надсилає дані про транзакції, підписані користувачами, на рівень DA пакетами, подібно до секвенсора Rollup. Однак виконавчий рівень не обов’язково повинен мати структуру зв’язаних списків у стилі Blockchain, це може бути повністю база даних Web2 + обчислювальна система, але вся обчислювальна система повинна бути з відкритим вихідним кодом і прозорою. Рівень консенсусу: він складається з групи вузлів, які витягують дані, надіслані на рівень DA рівнем виконання, і використовують той самий алгоритм, що й виконавчий рівень, для обчислення даних, щоб підтвердити, чи є результат, виведений на рівні виконання, правильним, і може використовуватися як резервування рівня виконання для запобігання катастрофам. Користувачі також можуть зчитувати дані, повернуті кожним вузлом на рівні консенсусу, щоб переконатися, що на рівні виконання немає шахрайства. Розрахунковий рівень: складається з групи вузлів та інших контрактів або адрес у ланцюжку, який використовується для обробки поведінки користувачів, які вносять депозити в SCP або виходять з SCP, дещо схожий на режим роботи мостів крос-чейн взаємодії. Вузол розрахункового рівня контролює функцію виведення депозитної адреси за допомогою контракту з мультипідписом або адреси на основі TSS. При внесенні депозиту користувач вносить активи на вказану Адресу ланцюжка, відправляє запит при виведенні, а Вузол Розрахункового рівня зчитує дані і видає активи через мультипідпис або TSS. Ступінь безпеки розрахункового рівня залежить від прийнятого механізму міжланцюгової взаємодії.

Структура практики SCP

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

• Шар DA проекту використовує постійне сховище Arweave, яке є великим колом на діаграмі. Координатор, тобто виконавчий рівень. **Користувач надсилає транзакцію координатору, який виконує розрахунок і представляє результат, а потім пакетами надсилає вихідні вхідні дані користувача на рівень DA. Детектор, який витягує необроблені дані про транзакції, надіслані координатором, з Arweave і перевіряє дані та результати за допомогою алгоритму, узгодженого з координатором. Клієнт датчика також має відкритий вихідний код, і ним може керувати будь-хто.
• **Сторожі, група датчиків, які відповідають за мультипідпис системи виведення. **Запити на виведення коштів перевіряються та публікуються на основі даних про транзакції. Крім того, сторож також відповідає за підписання пропозиції.

Ми бачимо всю систему, і консенсус, якого вони досягають, є поза мережею, що є ядром парадигми консенсусу зберігання - він відмовляється від системи NodeConsensus у стилі блокчейну та дозволяє виконавчому рівню позбутися важкого процесу комунікації та підтвердження консенсусу, і потрібно лише виконувати роботу сервера, щоб досягти майже необмеженого TPS та економії. Це дуже схоже на Rollup, але SCP пішла іншим шляхом, ніж Rollup, намагаючись перейти від конкретного для масштабу сценарію використання до нової моделі переходу від Web2 до Web3. **

Згаданий вище координатор є сервером, але це не означає, що координатор може робити все, що йому заманеться. Подібно до секвенсера Rollup, після пакетного надсилання необроблених даних, надісланих користувачем, до Arweave, будь-хто може запустити програму-тестувальник, щоб перевірити їх і порівняти зі станом, повернутим координатором. В якійсь мірі це та ж ідея, що і нанесення написів. **

У цій архітектурі централізований сервер або база даних не є фундаментальною проблемою. Це ще один пункт парадигми SCP, який пов’язує і відокремлює два поняття “централізація” і “єдине ціле” - ** в системі без довіри можуть бути централізовані компоненти, ** навіть основний компонент, але це не впливає на загальну довіру.

Ми можемо вигукнути такий слоган - “Наступне покоління інфраструктури, що не потребує довіри, не повинно покладатися на протоколи консенсусу, а має бути системами з відкритим вихідним кодом і мережами вузлів P2P”.

Початковий намір людей винайти та використовувати блокчейн полягає в тому, щоб не довіряти, реєстр є послідовним, непідробним, відстежуваним та іншими клішованими основами, які чітко викладені в BitcoinWhite Paper. Але після Ethereum, будь то схема масштабування старого публічного ланцюга, або Rollup, або модульний Blockchain, у всіх сформувалося мислення: те, що ми робимо, має бути Blockchain (що складається з протоколу консенсусу Node), або Rollup, який здається ланцюговим рішенням (тільки є структура даних Blockchain, але Node не має прямого обміну повідомленнями Consensus).

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

Виконавчий шар

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

Нескінченне можливе середовище виконання

Теоретично середовище виконання на рівні виконання може бути виконано в будь-якій формі, а можливості безмежні, залежно від того, як команда проекту позиціонує свій проект:

*Обмін. На основі SCP може бути побудована відкрита, прозора біржа з високим TPS, яка може мати характеристики швидкості CEX і нульової вартості, зберігаючи при цьому децентралізацію DEX. Тут розмивається межа між CEX і DEX.

• Платіжна мережа. Аналогічно Alipay, PayPal тощо.
• Підтримка віртуальних машин/завантажувачів блокчейну/контрактів. Будь-який розробник може розгорнути на ньому будь-яку програму, поділитися всіма даними користувача з іншими програмами та працювати за інструкціями користувача.

SCP, шаблон проектування, що підтримує довільні середовища виконання, має свої унікальні переваги: йому більше не потрібно покладатися на певні компоненти з історичним багажем, особливо на концепцію “абстракції облікового запису”, створену спільнотою Ethereum, що за своєю суттю є небажаним для SCP.

В архітектурі SCP відсутня концепція абстракції облікового запису - ви можете вільно використовувати стандартні облікові записи Web2 та облікові записи на блокчейні. З цієї точки зору, багато зрілих сценаріїв використання Web2 не потребують переосмислення та створення для роботи безпосередньо з SCP. Це може бути перевагою SCP-об’єктів перед ролапами. **

Прозорість та асиметрія

Система облікових записів, згадана вище, і чутливі читачі повинні були помітити, що хоча SCP може скористатися перевагами системи облікових записів Web2, здається проблематичним використовувати її в тому вигляді, в якому вона є.

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

1. Реєстрація облікового запису: користувач вводить ім’я користувача та пароль на сторінці реєстрації програми. Для того, щоб захистити пароль користувача, сервер обробить пароль через хеш-функцію після його отримання. Щоб підвищити складність хешу та захиститися від атак райдужних таблиць, пароль кожного користувача зазвичай з’єднується з випадково згенерованим рядком рядків (так званих “salts”) і хешується разом. **Імена користувачів, солі, хеші зберігаються у відкритому вигляді в базі даних постачальника послуг і не є загальнодоступними. Але навіть незважаючи на це, необхідно додати сіль і безпечне лікування, одне для запобігання внутрішніх привидів, а інше для запобігання нападам.

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

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

Давайте розглянемо типову систему взаємодії Web3 Blockchain з користувачем:

1. Реєстрація облікового запису: Практично немає процесу реєстрації облікового запису, а також немає системи імені користувача та пароля. Аккаунт (адреса) не вимагає реєстрації, він існує природним чином, і той, хто володіє його приватним ключем, контролює аккаунт. Приватний ключ генерується Гаманцем випадковим чином локально і не включає процес створення мережі.

2. Логін користувача: Використання блокчейну не вимагає входу в систему, і більшість dApps не мають процесу входу, але підключаються до Гаманця. Деякі dApps вимагатимуть від користувачів підписання та верифікації після підключення до Гаманця, щоб переконатися, що користувач дійсно володіє приватним ключем, а не просто передає WalletAddress інтерфейсу.

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

Різниця між двома режимами обумовлена симетрією і асиметрією. В архітектурі сервер-користувач обидві сторони зберігають однакові секрети. В архітектурі Blockchain-User секрети зберігаються тільки у користувача.

Незважаючи на те, що виконавчий рівень SCP не може бути блокчейном, всі дані повинні бути синхронізовані з публічно видимим рівнем DA, тому метод аутентифікації входу та операції, що використовується SCP, повинен бути асиметричним. Однак, оскільки ми не хочемо мати громіздких дій і поганого досвіду, які впливають на масове впровадження, такі як дозвіл користувачам зберігати приватні ключі та використовувати гаманці, програми, побудовані на SCP, також мають гостру потребу у використанні традиційних ідентифікаційних паролів або тристоронніх логінів для автентифікації OAuth, тож як їх поєднати?

У зв’язку з асиметричною природою асиметричної криптографії та пар доказів з нульовим розголошенням, я передбачаю два можливі сценарії:

• Якщо Ви хочете використовувати систему ID-PASSWORD, Ви можете залишити цей модуль зберігання паролів поза SCP, щоб ніхто інший не міг його побачити. Виконавчий рівень SCP, як і раніше, використовує публічний та приватний ключі блокчейну та логіку роботи, без реєстрації, входу тощо. ID користувача фактично відповідає приватному ключу. **Звичайно, цей закритий ключ не може бути збережений на стороні проекту, і більш реалістичним рішенням є використання 2-3 MPC для вирішення проблеми централізованого зберігання, при цьому не дозволяючи користувачам використовувати закритий ключ. При використанні логіна OAuth, JWT (Json Web Token) може використовуватися як засіб автентифікації. **Цей метод буде трохи більш централізованим, ніж вищезазначений, оскільки, по суті, він повинен покладатися на сторонню службу входу, що надається виробниками Web2 як автентифікацію особи.

• Коли ви вперше входите в систему з третьою стороною, зареєструйте в системі поля, які представляють особу користувача та особу постачальника послуг. У подальших операціях користувача інструкція з експлуатації використовується як публічний вхід, а JWT в цілому використовується як таємний свідок для перевірки транзакції кожного користувача з ZKP.

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

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

Конфіденційність

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

Зарядити

Ще один момент, який викликає занепокоєння, є тим, як заряджається виконавчий рівень. Це пов’язано з тим, що існують також витрати, пов’язані з подачею даних на рівень DA, включаючи роботу власних серверів. Перша основна мета традиційного блокчейну для стягнення з користувачів плати за газ полягає в тому, щоб уникнути того, щоб користувачі проводили по великій кількості повторюваних транзакцій, щоб порушити роботу мережі транзакцій, а друга полягає в тому, щоб сортувати транзакції відповідно до газу. Web2 не має подібних проблем, тому є лише базові поняття, такі як флуди та DDoS.

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

Опір цензурі

Рівень виконання не стійкий до цензури і теоретично може відхиляти транзакції користувачів на невизначений термін. У Rollup стійкість до цензури може бути гарантована функцією примусової агрегації контракту L1, тоді як Sidechain або публічний ланцюг є повноцінною розподіленою мережею Blockchain, яку також важко перевірити.

** Наразі не існує чіткого вирішення проблеми опору цензурі, яка є проблемою парадигми SCP. **

Рівень консенсусу

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

Наприклад, якщо у вас є сумніви щодо стану здоров’я цих вузлів, ви можете завантажити їх клієнт-детектор, який запускає той самий програмний код, що й координатор. **

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

Виконавчий рівень дає користувачеві результат попереднього підтвердження та м’якої фіналізації, оскільки він ще не був відправлений на рівень DA;

** Рівень консенсусу надає користувачам жорстку остаточність. Користувачі можуть не особливо перейматися цим, але для таких додатків, як мости крос-чейн взаємодії, необхідно дотримуватися жорсткої завершеності. Наприклад, система депозиту та виведення коштів біржі не довірятиме даним, що транслюються серіалізатором Rollup поза мережею, і повинна чекати, поки ці дані будуть завантажені в Ethereum, перш ніж вони будуть визнані.

Окрім того, що рівень консенсусу використовується для підтвердження результатів, важливу роль відіграє також рівень консенсусу, який є резервуванням катастроф як рівнем виконання. **Якщо рівень виконання завдає постійного удару і завдає серйозного зла, то теоретично будь-який рівень консенсусу може взяти на себе роботу виконавчого рівня та отримувати запити користувачів. Якщо станеться така серйозна ситуація, спільнота повинна вибрати стабільний і надійний вузол як сервер для виконавчого рівня.

Розрахунковий рівень

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

Децентралізація мосту свідків, наскільки це можливо, є предметом багатьох досліджень крос-чейн взаємодії. У зв’язку з обмеженням простору я не буду тут зупинятися на ньому. Добре спроектована платформа SCP також повинна мати авторитетних партнерів з мультипідписом Decentralization Bridge на практиці.

Можна запитати, чому SCP не використовує ланцюжки зі смарт-контрактами як рівень DA? Це може створити розрахунковий рівень, який дає контракти та повністю не викликає довіри.

У довгостроковій перспективі, до тих пір, поки будуть подолані деякі технічні труднощі, якщо рівень DA буде розміщений на рівні DA з такими контрактами, як Ethereum, і буде побудований відповідний контракт на перевірку, SCP також може отримати таку ж безпеку розрахунків, як і Rollup, без необхідності використання мультипідпису.

Але на практиці це не обов’язково оптимально:**

1. Ethereum спеціально не використовується для збереження даних, і ціна занадто висока в порівнянні з публічним ланцюжком чистого зберігання даних. Для парадигми SCP досить низька або фіксована вартість зберігання має вирішальне значення. Тільки так можна підтримувати пропускну здатність на рівні Web2.

2. Довести, що система дуже складна в розробці, адже SCP може не тільки імітувати ЕВМ, а й реалізовувати будь-яку логіку. ** Дивлячись на той факт, що такі команди, як Optimism, все ще не в мережі для доказів шахрайства, і складність розробки zkEVM, ми можемо уявити, що реалізувати докази різних систем на Ethereum надзвичайно складно.

Тому рішення Rollup є кращим лише в конкретних ситуаціях, і якщо ви плануєте впровадити ширший і відкритіший підхід, який відходить від системи EVM до більшої кількості функцій Web2, ідея Ethereum Rollup не підходить.

**SCP – це не схема масштабування публічного ланцюга, а більша архітектура обчислювальної платформи Web3, тому, очевидно, немає необхідності слідувати ідеї рівня 2 Ethereum. **

Діаграма, що порівнює SCP з іншими парадигмами