Вступ:

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

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

• Він має швидкість, яка порівнюється з традиційними застосунками або обмінами Web2, що далеко перевершує будь-який громадський блокчейн, Layer 2 (L2), rollups, sidechains тощо.

• Не існує жодних комісій за газ, а вартість використання практично дорівнює нулю.

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

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

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

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

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

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

• Шар доступності даних: Обробляється широко визнаною та добре протестованою громадською блокчейн-мережею або засобами зберігання, що служать як шар доступності даних, наприклад Ethereum, Arweave, Celestia, тощо.

• Шар виконання: сервер, призначений для отримання транзакцій користувачів та їх виконання, а також пакетної відправки підписаних даних транзакцій на шар DA, схожий на послідовників у Rollups. Однак шар виконання не обов'язково повинен мати ланцюгову структуру у стилі блокчейну; він може бути цілком системою веб-бази даних + обчислювальна система, але вся обчислювальна система повинна бути відкритим джерелом з можливістю перевірки.

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

• Шар розрахунків: Складається з групи вузлів та контрактів або адрес на інших ланцюгах, відповідальних за обробку внесків користувачів у SCP або виведення з SCP, до певної міри схожих на операцію міжланцюжкових мостів. Вузли шару розрахунків контролюють функцію виведення адреси депозиту через контракти з багато підписами або адреси на основі TSS. Для внесків користувачі переказують активи на визначену адресу на своєму ланцюжку; для виведення вони відправляють запит, і після того, як вузли шару розрахунків прочитають дані, вони звільняють активи через багато підписів або TSS. Рівень безпеки шару розрахунків залежить від використаного механізму міжланцюжкового взаємодії.

SCP Практична структура

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

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

Ми бачимо, що консенсус, досягнутий усією системою, повністю поза мережею, що є ядром парадигми консенсусу щодо зберігання. Він відмовляється від системи консенсусу вузлів, типової для блокчейнів, звільняючи рівень виконання від обтяжливого процесу консенсусної комунікації та підтвердження. Це дозволяє йому ефективно функціонувати як єдиний сервер, тим самим досягаючи майже необмеженого TPS і економічної ефективності. Цей аспект дуже схожий на Rollups, але SCP (Storage Consensus Paradigm) йде іншим шляхом, ніж Rollups. SCP намагається перейти від специфічного для масштабування сценарію використання до нового перехідного режиму від Web2 до Web3. Вищезгаданий Координатор є сервером, але це не означає, що Координатор може діяти свавільно. Подібно до секвенсера в Rollups, після пакетного надсилання вихідних даних від користувачів на Arweave, будь-хто може запустити програму Detector, щоб перевірити їх і порівняти зі станом, який повертає Координатор. У певному сенсі це схоже на підхід додатків типу написів. У цій архітектурі централізований сервер або база даних не є фундаментальною проблемою. Це ще один пункт парадигми SCP: він відокремлює поняття «централізація» та «єдине ціле» — у системі, якій не довіряють, можуть існувати централізовані компоненти, навіть основний компонент, не впливаючи на загальну недовіру системи.

Ми можемо вигукнути такий слоган: «Наступне покоління інфраструктури, що не потребує довіри, не обов'язково має покладатися на протоколи консенсусу, але це має бути система з відкритим вихідним кодом із вузловою мережею Peer-to-Peer (P2P)». Початковий намір винаходу та використання блокчейну полягав у досягненні децентралізації, узгодженості реєстру, незмінності та відстежуваності, як прямо зазначено в технічному документі Bitcoin. Однак після Ethereum, будь то рішення для розширення старої публічної мережі, Rollup або модульні блокчейни, існувало фіксоване мислення: те, що ми створюємо, має бути або блокчейном (що складається з протоколів консенсусу вузлів), або чимось на кшталт Rollup (який, схоже, є ланцюжком зі структурами даних блокчейну, але без прямого обміну повідомленнями консенсусу між вузлами). Тепер, в рамках структури, заснованої на SCP (Stellar Consensus Protocol), очевидно, що навіть не будучи блокчейном, можна досягти децентралізації, узгодженості реєстру, незмінності та відстежуваності, за умови наявності більш чітких деталей реалізації.

Шар виконання

Шар виконання є важливим в усій системі, оскільки він виконує обчислювальні процеси системи та визначає типи додатків, які можуть працювати в системі.

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

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

1. Біржі. Використовуючи SCP, можна побудувати публічну, прозору біржу з високими швидкостями транзакцій на секунду (TPS), поєднуючи швидкі, безкоштовні функції Централізованої біржі (CEX) та децентралізацію Децентралізованої біржі (DEX). Тут розмита грань між CEX та DEX.

2. Платіжні мережі. Подібно до Alipay, PayPal тощо.

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

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

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

Система облікових записів була згадана вище, і спостережливі читачі могли помітити, що хоча SCP (Протокол консенсусу Stellar) може використовувати систему облікових записів Web2, використання її в такому вигляді видається проблематичним. Це тому, що вся система є повністю прозорою! Пряме використання моделі взаємодії користувач-сервер з Web2 призводить до серйозних проблем з безпекою, що робить систему абсолютно небезпечною. Давайте розглянемо, як працює традиційна модель сервер-користувач:

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

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

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

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

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

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

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

Відмінність між цими двома режимами викликана симетричними та асиметричними факторами. У архітектурі сервер-користувач обидві сторони мають однаковий секрет. У блокчейн-користувацькій архітектурі лише користувач має секрет. Хоча прошарок виконання SCP (Платформа Смарт-контрактів) може не бути блокчейном, всі дані повинні бути синхронізовані на публічно видимий шар DA (Доступність даних). Тому методи входу та перевірки операцій SCP повинні бути асиметричними. Однак, щоб уникнути незручних дій, таких як управління приватними ключами та використання гаманців, які можуть заважати широкому поширенню через поганий досвід користувача, існує великий попит на традиційні ID-паролі або OAuth сторонні аутентифікаційні входи в додатки, побудовані на SCP. Так як по асиметричній природі криптографії та доказів нуль-знань, я уявляю два можливих рішення:

• Якщо бажана система ID-пароля, модуль зберігання пароля може бути виключений з SCP, зробивши його невидимим для інших. Всередині шару виконання SCP все ще використовується громадсько-приватні облікові записи блокчейну та операційна логіка, без реєстрації або входу. Фактично ідентифікатор користувача відповідав би приватному ключу. Цей приватний ключ, звичайно, не повинен зберігатися стороною проекту. Можливим рішенням є використання 2-3 MPC (багатосторонні обчислення) для вирішення проблеми централізованого зберігання, не навантажуючи користувача використанням приватного ключа.
• При підтримці входу OAuth можна використовувати JWT (JSON Web Token) як засіб ідентифікації. Цей метод трохи більш централізований, ніж вищезазначений, оскільки він суттєво покладається на служби входу від сторонніх веб-гігантів Web2 для підтвердження ідентичності.
• Перший раз, коли використовується вхід через сторонній сервіс, поля JWT, які представляють ідентичності користувача та постачальника послуг, реєструються в системі. У подальших операціях користувача команда операції розглядається як публічний ввід, тоді як JWT в цілому є таємним свідком, використовуючи ZKP (докази нульового знання) для перевірки кожної транзакції користувача.
• Кожен JWT має обмеження терміну дії, і користувачі будуть запитувати новий JWT наступного разу, коли вони увійдуть в систему, тому немає потреби в постійному зберіганні. Крім того, ця система ґрунтується на JWK (JSON Web Key), який можна розглядати як публічний ключ, наданий гігантами для перевірки JWK. Те, як JWK децентралізовано вводиться в систему, а також методи майбутньої зміни приватного ключа, також варто дослідити.

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

Проблеми конфіденційності

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

Комісії

Як збирає плату за виконавчий шар - це ще один пункт цікавості. Подання даних в шар доступності даних (DA) також супроводжується витратами, включаючи операцію власних серверів. Основна мета збору плати за газ у традиційних блокчейнах - запобігання користувачам спаму мережу численними зайвими транзакціями, замовлення транзакцій на основі плати за газ є вторинною. У Web2 подібні занепокоєння не існують, існують лише базові концепції, такі як затоплення та атаки DDoS. Виконавчий шар може настроїти різноманітні стратегії збору плати, такі як повністю безкоштовно чи частково зборні, або отримувати прибуток від інших дій, таких як Максимальна вилучена вартість (MEV), яка вже дуже зріла в послідовниках та ринкових діяльностях.

Стійкість до цензури

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

Шар консенсусу

Цей рівень складається з слабо пов'язаних вузлів, які не утворюють активно мережу, тому він не є строго консенсусним рівнем, а просто підтверджує поточний стан виконавчого рівня зовнішньому світу (наприклад, користувачам). Наприклад, якщо ви сумніваєтеся в робочому стані цих вузлів, ви можете завантажити їх клієнт-детектор, який запускає той же програмний код, що і координатор. Однак, як і у випадку зі зведеннями, оскільки дані надсилаються пакетами, стан, який повертає користувачам виконавчий рівень, завжди актуальніший, ніж на рівні DA. Це пов'язано з проблемою попереднього підтвердження: рівень виконання надає користувачам результати попереднього підтвердження, м'якої остаточності, оскільки вони ще не були надіслані на рівень DA; У той час як рівень консенсусу забезпечує жорстку остаточність. Користувачі можуть бути не особливо стурбовані цим, але для таких застосувань, як кросчейн-мости, необхідно дотримуватися жорсткої завершеності. Наприклад, система депозиту та зняття коштів бірж не довіряє даним, що транслюються офчейн секвенсерами Rollup; вони чекають, поки ці дані з'являться на Ethereum перед прийняттям. Окрім підтвердження результатів, рівень консенсусу також відіграє вирішальну роль як резервування катастрофи для рівня виконання. Якщо рівень виконання назавжди перестає працювати або діє зловмисно, теоретично будь-який рівень консенсусу може взяти на себе роботу виконавчого рівня та приймати запити користувачів. Якщо виникає така серйозна ситуація, спільнота повинна вибрати стабільні та надійні вузли як сервери рівня виконання.

Служба розрахунків

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

Зробити міст свідків максимально децентралізованим є темою дослідження для багатьох кросчейн-мостів. У зв'язку з обмеженим простором, це не буде детально описано тут. Добре спроектована платформа SCP на практиці також повинна мати авторитетних партнерів з децентралізованого мосту з мультипідписом. Хтось може запитати, чому SCP не використовує ланцюжок зі смарт-контрактами як рівень DA? Це дозволило б створити безнадійні рівні розрахунків на основі контрактів. У довгостроковій перспективі, долаючи деякі технічні труднощі, якщо рівень DA розмістити на Ethereum або інших рівнях DA з підтримкою контрактів і можна побудувати відповідні контракти на верифікацію, SCP також може досягти такої ж безпеки розрахунків, як і Rollup, без необхідності мультипідпису.

На практиці це може бути не найкращим вибором:

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

2. Розробка систем доказів є надзвичайно складною, оскільки в SCP можна не лише моделювати EVM (Ethereum Virtual Machine), але й реалізувати будь-яку логіку. З урахуванням поточного стану проектів, таких як Optimism, де їх докази шахрайства ще не випущені, і складності розробки zkEVM (нульової знання Ethereum Virtual Machine), можна уявити надзвичайну складність при впровадженні різних систем доказів на Ethereum.

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

Ілюстрація порівнює SCP з іншими парадигмами

Disclaimer：

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