Skip to main content
Skip to main content

Статья

Web2 и Web3 в одном цикле поставки

On-chain и off-chain — это не два проекта. Когда одна команда ведёт продуктовый UX и смарт-контракты внутри одного ритма майлстоунов, стыки между ними перестают быть местом, где всё ломается.

Опубликовано

Web3Web2Architecture

Стык — вот где чаще всего ломаются Web3-продукты

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

Когда этими двумя половинами владеют разные команды с разными интересами, стык становится местом, где предположения тихо расходятся. Мы ведём их как один цикл поставки. Один ритм майлстоунов покрывает и on-chain логику, и off-chain продукт, поэтому интеграция никогда не становится сюрпризом, который обнаруживают поздно.

Одна команда, две поверхности, один стандарт готовности

Относиться к on-chain и off-chain как к одной системе — не значит их смешивать. Это значит держать обе части под одним определением готовности. Смарт-контракт не готов, потому что компилируется; экран не готов, потому что отрисовался. Обе части готовы, когда работают вместе в окружении, близком к production, и проходят одну и ту же верификацию.

На практике это выглядит как стек, где типизированный SDK или API-слой стоит между контрактами и продуктом, чтобы приложение общалось со стабильной поверхностью, а не лезло в детали блокчейна повсюду. Контракты могут развиваться, UI может развиваться, а стык между ними — это контракт, который реально можно тестировать.

Верификация должна пересекать границу блокчейна

Off-chain код получает деплой и цикл исправлений за минуты. On-chain код — нет: ошибка, которая уехала, может быть необратимой и публичной. Эта асимметрия — причина, по которой гейт релиза для Web3-продукта не может заканчиваться на приложении. Проверки должны покрывать границу: что контракт ведёт себя по спецификации, что приложение обрабатывает состояния, которые порождает реальная сеть, и что совместимость кошельков держится на тех клиентах, которыми реально пользуются.

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

Результат — продукт, а не куча деталей

Когда один цикл несёт обе поверхности, вы перестаёте выпускать «контракт и приложение, которые общаются друг с другом», и начинаете выпускать один продукт. Онбординг ощущается как обычная регистрация, хотя в нём участвует кошелёк. У транзакции в ожидании есть продуманное состояние, а не спиннер, который врёт. Off-chain опыт прячет те части блокчейна, которые должны быть скрыты, и показывает те, которые должны быть видны.

Web3 не обязан ощущаться как Web3 для того, кто им пользуется. Ведение обеих половин в одном цикле поставки — самый надёжный найденный нами способ сделать так, чтобы сила on-chain ощущалась как обычный продукт, которому можно доверять.

Есть проект на примете?

20 минут — обсудим вашу задачу и дадим честную оценку. Без обязательств.