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

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

Объяснять риски через понятный контекст транзакций

Одно из предлагаемых изменений — улучшить стандартный опыт разработки в части объяснения рисков пользователям. Команды Web3 часто уделяют значительное внимание кошелькам, мостам, стимулам и механике протоколов, тогда как обычный пользователь по-прежнему сталкивается с непонятными запросами и должен сам определять, какие действия безопасны.

Ключевым улучшением стало бы добавление более понятного для человека контекста транзакций непосредственно в приложения и кошельки. Вместо отображения только “approve” или “sign” кошельки и приложения могли бы давать объяснение простым языком: какое разрешение предоставляется, какой актив подвергается риску, можно ли отменить действие и зачем приложение его запрашивает.

Аргумент состоит в том, что такая ясность может казаться рутинной, но именно такая рутинная ясность и нужна сектору. В ChainClarity работа по переводу криптовалютных whitepaper на простой английский выявила схожую проблему по всей отрасли: технические пользователи понимают систему, массовые пользователи понимают маркетинг, а опасный разрыв находится между ними.

Если Web3 должен достичь более широкого внедрения, понимание нельзя считать необязательным. Пользователь, который понимает совершаемое действие, с меньшей вероятностью станет жертвой мошенничества, с меньшей вероятностью будет винить всю категорию за негативный опыт и с большей вероятностью вернется.

Повысить уровни абстракции Web3

Еще один предлагаемый сдвиг — создание стандартных уровней абстракции, которые отделяют сложность криптографических операций на back end от пользовательского опыта на front end. Web3 часто описывают как третью итерацию интернета, но его среда разработки по-прежнему требует от многих команд управления низкоуровневыми инфраструктурными вопросами на уровне приложений.

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

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

Пока децентрализованные back end не станут для конечных пользователей такими же непрозрачными, как API облачных баз данных, корпоративное внедрение может оставаться экспериментом, а не отражением структурных решений. Цель состоит в том, чтобы помочь компаниям решать проблемы координации без добавления ответственности за управление базовой инфраструктурой.

Начинать с потребности клиента

Некоторые разработчики утверждают, что многие проекты Web3 по-прежнему начинаются с неправильного вопроса: “Какой блокчейн нам использовать?” В Zibtek команды участвовали в таких обсуждениях и пришли к выводу, что это часто неверная отправная точка.

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

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

Сделать комиссии предсказуемыми и ограниченными

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

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

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

Обеспечить почти мгновенную финальность

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

Финальность за один слот или почти мгновенная финальность также должны сочетаться со строгими правилами slashing и четкими ограничениями на реорганизации. Исследования должны учитывать поведение, связанное с MEV, которое может вызывать задержки и откаты. Более широкая цель — поддерживать архитектуры, повышающие скорость при сохранении распределения власти.

Объединить сети через открытые стандарты

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

Инструменты, такие как SDK, наборы тестов и фаззеры, должны поставляться вместе со стандартом, чтобы приложения могли запускаться быстрее. Для пользователей результатом стал бы более плавный опыт вместо фрагментированной среды из отдельных изолированных систем. Разработчики призывают отрасль создавать и принимать открытые межсетевые стандарты.

Включить удобную приватность по умолчанию

Публичные блокчейны раскрывают значительные объемы пользовательских данных. Встроенные инструменты zero-knowledge могут скрывать суммы транзакций и связи, при этом доказывая, что необходимые правила были соблюдены. Ключи выборочного раскрытия позволили бы пользователям показывать аудиторам конкретные факты, не раскрывая все детали.

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

Создать безопасные обратно совместимые обновления

Обновления могут нарушать работу приложений и разделять сообщества. Более сильный процесс управления и обновления должен защищать существующие контракты при внедрении новых версий. Версионированный код, feature flags и opt-in модули могут позволить приложениям переходить в своем собственном темпе.

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