Огляд:

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

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

· Для надання децентралізованого стандарту фронтенду команда EthStorage запропонувала протокол доступу web3://, який надає розробникам повний набір стандартів та інструментів для розгортання та доступу до коду фронтенду через смарт-контракти, а навіть файлові системи, який зараз став офіційним стандартом Ethereum.

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

Подяки: Дякуємо Фаусту з GeekWeb3, Жишонгу Пану з ChainFeeds, Брюсу з LXDAO, Чжи Чжоу та Лун Денгу з EthStorage за їх відгуки щодо цієї статті.

Фон та проблеми децентралізованого DAPP

Візія Ethereum - стати комп'ютером світу, а програми, побудовані на ньому, мають успадковувати його безпеку. Розробники потрібно лише розгорнути його один раз, і програма буде працювати на Ethereum завжди, і жодна сутність не зможе цензурити її або зловживати нею.

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

Загалом кажучи, децентралізована DAPP буде включати інтерфейс фронтенду, сервер бекенду та базу даних. Коли користувачі отримують доступ до інтерфейсу фронтенду, вони завантажують вміст фронтенду через браузер та службу доменних імен. Серед них:

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

· Back-end servers: Частково реалізовано за допомогою смарт-контрактів, деякі обчислювально інтенсивні завдання не можуть бути повністю реалізовані на ланцюжку.

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

Через вищезазначений аналіз ми бачимо, що лише деякі компоненти поточного децентралізованого DAPP були захищені Ethereum за допомогою смарт-контрактів, і система Ethereum далека від реалізації початкового бачення "децентралізованого світового комп'ютера".

В кінці 2023 року Віталік переглянув розвиток Ethereum та написав відгукнутий статтю "Зробіть Ethereum знову циферпанк", де обговорюється, як повинна повертатися спільнота Ethereum до концепції циферпанку. У статті він узагальнив цінності, якими повинен дотримуватися Ethereum, навіть більша спільнота Web3, та згадав дуже важливий момент:

Децентралізовані додатки повинні мінімізувати свою залежність від будь-якого окремого суб'єкта, щоб навіть якщо основні розробники DAPP зникнуть назавжди, додаток зможе продовжувати працювати.

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

Фронтенд та послуги доменних імен

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

Хакери можуть взламати сервер, щоб змінити фронтенд-код, і користувачі dApp втратять активи через використання злоякісного фронтенду. Ця проблема неодноразово виникала на останньому DeFi-літі, і ми не можемо не запитати: Чому фронтенд не може бути розгорнутим на Ethereum, як бекенд, щоб поведінка модифікації могла діяти лише через управління спільнотою та часові блокування?

Також, будь ласка, уявіть, якщо команда розробників Uniswap одного дня більше не оплачуватиме послуги своїх фронтенд-серверів та доменних імен, як користувачі Uniswap та LPs будуть використовувати Uniswap?

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

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

Сервер Backend

Тому що EVM може забезпечити середовище виконання з повним обсягом функцій Тьюрінга, більшість логіки бекенду може бути виконана на ланцюжку Ethereum. Ми можемо сказати, що додатки з розумним контрактом можуть повністю успадкувати безпеку Ethereum. Це лише через причини витрат, що деякі обчислювально-інтенсивні завдання не можуть бути виконані безпосередньо на ланцюжку.

Для вирішення цьої проблеми поточне дослідження полягає в тому, щоб використовувати ZK або OP для перенесення обчислення в оффчейн, а ланцюг Ethereum лише підтверджує результати обчислення, щоб розширити місткість на рівні обчислень. Деякі проекти, пов'язані з штучним інтелектом, довели цей метод до крайнощів, сподіваючись зв'язати супер-обчислювально інтенсивні завдання, такі як великі моделі штучного інтелекту, з блокчейнами, що заслуговує на нашу увагу.

База даних

Для баз даних EVM спочатку підтримує пари ключ-значення/KV сховище (Key Value Store), яке може охоплювати широкий спектр сценаріїв використання, але основна проблема полягає в тому, що вартість зберігання на ланцюжку є занадто високою.

Наскільки це дорого? Коли Ціна Газу становить 10 Гвей, потрібно більше 6,200 ETH, щоб зберегти 1 ГБ даних на ланцюжку, що перевищує 20 мільйонів доларів США! Очевидно, вартість зберігання стала основною проблемою децентралізації баз даних.

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

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

Ненадійне рішення для DAPP

Навколо того, як повністю базувати DAPP на Ethereum для розгортання та доступу, команда EthStorage запропонувала два рішення:

• протокол доступу web3://: Вирішення проблеми з тим, як використовувати смарт-контракти для розгортання та доступу до фронтенд коду, навіть файлових систем.
• Протокол зберігання EthStorage рівня 2: Наслідуючи безпеку Ethereum, він значно зменшує накладні витрати на зберігання.

протокол доступу web3://

web3:// можна розуміти як децентралізовану версію http://. Схожий на http URL, який отримує доступ до централізованих ресурсів, вказуючи IP-адресу сервера або доменне ім'я, URL web3 повинен вказати адресу смарт-контракту або доменне ім'я ENS для доступу до ресурсів, збережених на ньому.

Ми можемо розгорнути весь фронтенд веб-сайту в розумний контракт і отримати до нього доступ через web3://! Ви можете порівняти різницю між ними:

На даний момент web3:// став офіційним стандартом Ethereum (ERC-4804). Якщо ви хочете дізнатися більше про вміст протоколу доступу web3://, ви можете відвідати його офіційний веб-сайт. Для кращого управління файлами в смарт-контрактах ми запропонували ERC-5018, який імітує набір інтерфейсів файлової системи в смарт-контрактах, щоб ви могли завантажити упаковану папку з фронтенд кодом до смарт-контракту через ethfs-cli і отримувати доступ до цього веб-сайту через web3://.

Якщо вас зацікавить, ви можете слідувати посібнику, щоб завершити просте розгортання децентралізованої програми та отримати доступ.

З веб-протоколом доступу web3:// ми дійсно можемо зробити фронтенд додатків (dApp) з атрибутом "Код - це закон". Для розробників, одного разу розгорнутого, цей фронтенд буде виконуватися завжди. Уявіть, якщо Uniswap labs також розгорне свій фронтенд на Ethereum, то навіть якщо команда захоче цензурувати та обмежити користувачів на рівні фронтенду, вона не зможе завадити людям використовувати її фронтенд, розгорнутий на Ethereum.

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

EthStorage шар протоколу зберігання рівня 2

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

Користувачі завантажують дані, які потрібно зберегти в Ethereum через BLOB EIP-4844. Смарт-контракт EthStorage записує лише хеш-значення даних у BLOB, що ефективно зменшує витрати на зберігання.

У той самий час вузол зберігання другого рівня завантажить відповідні дані BLOB на локальний диск і використовуватиме PoRA (доказ випадкового доступу) та ZK для надсилання доказу зберігання контракту на Ethereum для перевірки. Контракт повинен використовувати раніше записаний хеш Blob, щоб підтвердити, чи відповідає ZK-доказ, завантажений вузлом зберігання, тому, щоб підтвердити, що вузол зберігання в мережі другого рівня дійсно зберігає ці дані.

Конкретний процес виглядає наступним чином:

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

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

На даний момент EthStorage отримав офіційні Гранти Ethereum та розгорнув публічний тестовий мережу на Sepolia. Кожен може приєднатися.

Огляд та перспективи

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

EthStorage запропонував два рішення цієї проблеми: протокол доступу web3:// вирішує проблему використання смарт-контрактів для розгортання та доступу до фронтенду; протокол зберігання другого рівня EthStorage вирішує проблему високих витрат на зберігання.

Для реалізації початкової візії Ethereum ми вважаємо, що він еволюціонує у децентралізований веб-сервер, а децентралізовані додатки в екосистемі розгортають всі свої компоненти на Ethereum. Чи то код back-end, фронт-енд або дані, після розгортання код може працювати постійно, а дані можуть бути постійно доступні, перетворюючись на дійсно незупинний Dapp.

Громадська тестова мережа EthStorage наразі проводить другу інцентивну кампанію. Зацікавлені члени спільноти можуть слідувати посібнику, щоб завершити розгортання своєї першої додатку Unstoppable Dapp та отримати доступ!

Заява:

1. Ця стаття відтворена з [ Гік Веб3], авторське право належить оригінальному автору [EthStorage Team], якщо у вас є які-небудь зауваження стосовно перевидання, будь ласка, зв'яжітьсяКоманда Gate Learn ), команда якнайшвидше вирішить це відповідно до відповідних процедур.

2. Відмова від відповідальності: Погляди та думки, висловлені в цій статті, представляють лише особисті погляди автора і не становлять жодної інвестиційної поради.

3. Інші мовні версії статті перекладені командою Gate Learn і не згадуються вGate.io) перекладена стаття не може бути відтворена, поширена або узята з плагіатом.