Итог:

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

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

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

· Для снижения затрат на хранение данных в цепочке Ethereum команда EthStorage разработала вторичный протокол хранения EthStorage, который использует PoRA (Proof of Random Access) и доказательство нулевого знания для существенного снижения накладных расходов на хранение, сохраняя при этом безопасность первого уровня Ethereum.

Благодарности: Спасибо Фаусту из GeekWeb3, Жишонгу Пану из ChainFeeds, Брюсу из LXDAO, Ци Чжоу и Лунь Денгу из EthStorage за их отзывы об этой статье.

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

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

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

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

· Фронт-энд и услуги по доменным именам: Большинство из них не развернуты и не доступны через смарт-контракты. Функции, предоставляемые блокчейном, такие как избегание отказов в работе из-за единой точки отказа, неизменяемость кода, антицензура и управление сообществом, не отражены в этой части фронт-энда.

· Серверы бэк-энда: Частично реализованные смарт-контрактами, некоторые вычислительно интенсивные задачи не могут быть полностью выполнены on-chain.

· База данных: Частично реализована смарт-контрактами. Из-за высоких затрат на хранение на цепочке DAPP по-прежнему использует внеланцевые решения хранения при большом объеме данных.

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

В конце 2023 года Виталик просмотрел развитие Ethereum и написал очень отзывчивую статью "Сделать Ethereum снова кайферпанк", в которой обсуждается, как сообщество Ethereum должно вернуться к концепции кайферпанка. В статье он подвел итоги ценностей, которым должно следовать Ethereum, и даже более крупное сообщество Web3, и упомянул очень важный момент:

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

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

Сервисы фронт-энда и доменных имен

Среди нескольких компонентов децентрализованных приложений наиболее централизованными являются фронт-енд и услуги доменных имен. В настоящее время большинство фронт-ендов dApp используют централизованные серверы. Владельцы проекта могут в любое время изменить код фронт-енда без участия сообщества или временных блокировок. Безопасность этой части далека от безопасности смарт-контрактов, развернутых на Ethereum.

Хакеры могут взломать сервер для изменения кода фронт-энда, и пользователи dApp потеряют активы из-за использования зловредного фронт-энда. Эта проблема неоднократно возникала в прошлом лете DeFi, и мы не можем не спросить: Почему фронт-энд не может быть развернут на Ethereum, как бэк-энд, чтобы поведение изменения могло происходить только через управление сообществом и временные блокировки?

Также, пожалуйста, представьте, что если команда разработчиков Uniswap однажды перестанет оплачивать услуги своих фронтенд-серверов и доменных имён, каким образом пользователи и LP Uniswap будут использовать Uniswap?

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

Кроме того, поскольку оператором фронт-энда Uniswap является Uniswap Labs, они увеличили проверку списка токенов, чтобы удовлетворить надзор, что противопоставляется умным контрактам, развернутым на Ethereum, поскольку никто не может изменять умные контракты по своему усмотрению. Поэтому токены, проверенные на фронт-энде, все равно могут взаимодействовать на уровне контракта, что показывает важность кода on-chain для сопротивления цензуре.

Сервер

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

Для решения этой проблемы текущее исследование направлено на использование ZK или OP для передачи вычислений на внебиржевую цепочку, а цепочка Ethereum лишь подтверждает результаты вычислений, чтобы расширить возможности на уровне вычислений. Некоторые проекты, связанные с искусственным интеллектом, довели этот метод до предела, надеясь связать сверхвычислительно-интенсивные задачи, такие как большие модели искусственного интеллекта, с блокчейнами, что заслуживает нашего внимания.

База данных

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

На сколько это дорого? При цене газа в 10 Гвей понадобится более 6 200 ETH, чтобы хранить 1 ГБ данных на цепочке, что превышает 20 миллионов долларов США! Очевидно, стоимость хранения стала основной проблемой децентрализации баз данных.

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

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

Ненадежное решение для DAPP

Команда EthStorage предложила два решения по развертыванию и доступу к DAPP, полностью основанным на Ethereum:

• протокол доступа 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.

Протокол хранения уровня 2 EthStorage

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

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

Одновременно узел хранения второго уровня загрузит соответствующие данные BLOB на локальный диск и использует PoRA (Proof of Random Access) и ZK для представления доказательства хранения контракту на Ethereum для верификации. Контракту необходимо использовать заранее записанный хэш Blob для подтверждения соответствия ZK-доказательства, загруженного узлом хранения, чтобы подтвердить, что узел хранения в сети второго уровня действительно хранит эти данные.

Конкретный процесс выглядит следующим образом:

Для разработчиков интерфейс для загрузки и получения данных очень прост:

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

В настоящее время EthStorage получила официальные гранты Ethereum и развернула общественную тестовую сеть на Sepolia. Все желающие могут присоединиться.

Сводка и перспективы

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

EthStorage предложил два решения этой проблемы: протокол доступа web3:// решает проблему использования смарт-контрактов для развертывания и доступа к фронт-енду; протокол второго уровня хранения EthStorage решает проблему высоких затрат на хранение.

Для реализации первоначального видения Ethereum мы считаем, что он эволюционирует в децентрализованный веб-сервер, и децентрализованные приложения в экосистеме развернут все свои компоненты на Ethereum. Будь то код бэк-энда, фронт-энда или данные, после развертывания код может работать постоянно, а данные можно получить постоянно, превращаясь в действительно неудержимое Dapp.

Публичная тестовая сеть EthStorage в настоящее время проводит свою вторую инцентивную кампанию. Заинтересованные члены сообщества могут следовать Руководству, чтобы завершить развертывание своего первого недоступного Dapp и получить доступ!

Заявление:

1. Эта статья воспроизведена с [GateГик Веб3], авторские права принадлежат оригинальному автору [Команда EthStorage], если у вас есть возражения к перепечатке, пожалуйста, свяжитесь Команда Gate Learn), команда обработает это как можно скорее в соответствии с соответствующими процедурами.

2. Отказ от ответственности: Взгляды и мнения, выраженные в этой статье, представляют только личные взгляды автора и не являются инвестиционными советами.

3. Другие языковые версии статьи переводятся командой Gate Learn и не упоминаются в Gate.io), переведенная статья не может быть воспроизведена, распространена или использована в качестве источника.