a16z: 7 советов по избежанию недостатков в дизайне токенов

Оригинальное название: 7 проверок здравого смысла перед проектированием токена

Автор: Гай Уолетт

Составитель: Кэти Гу, Odaily 星球日报

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

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

#1 Четко определить цели проектирования токена

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

Кроме того, цели должны быть сосредоточены вокруг самого токена, но это часто игнорируется. Примеры четких целей включают:

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

• Протокол DeFi хочет спроектировать модель токена, которая разумно распределяет риски между участниками.

• Проектирование репутационного протокола, который не может напрямую заменить репутацию (например, путем разделения ликвидности и репутационных сигналов).

• Проектирование сети хранения, которая может гарантировать доступность файлов с низкой задержкой.

• Проектирование сети стейкинга, которая может обеспечить максимальную экономическую безопасность.

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

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

Так как же начать определять четкую цель? Четко определенные цели обычно исходят из "миссии проекта". Хотя "миссия проекта" часто является высокоуровневой и абстрактной, цели должны быть конкретными и упрощенными до самых основных форм.

Возьмем, к примеру, EIP-1559. Ясная формулировка одной из целей EIP-1559 от Roughgarden: "EIP-1559 должен улучшить пользовательский опыт в периоды быстрого роста спроса в форме 'очевидной лучшей ставки' с помощью простых оценок затрат."

Он также предложил другую четкую цель: "Можем ли мы переработать механизм транзакционных сборов Ethereum так, чтобы установка цены газа для транзакций была 'гладкой', как покупки на Amazon? Идеально, если бы это была механика публикации цен, что означает механизм, который предоставляет каждому пользователю возможность принять или отказаться от цены газа."

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

#2 Оценка существующих работ на основе основных принципов

При создании нового полезно начинать с изучения существующего. Когда вы оцениваете существующие протоколы и литературу, следует объективно оценивать их на основе их технических достоинств.

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

#3 Проясните ваши предположения

Четко выражайте свои предположения. Когда вы сосредотачиваетесь на создании токена, легко принимать основные предположения как должное. Также легко неправильно выразить ваши истинные предположения.

Например, новый протокол предполагает, что его аппаратное ограничение — это скорость вычислений. Включение этого предположения в модель токена (например, путем ограничения стоимости аппаратного обеспечения, необходимого для участия в протоколе) может помочь согласовать дизайн с ожидаемым поведением.

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

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

#4 Проверьте ваши предположения

Существует пословица: "Не то, что вы не знаете, ставит вас в затруднительное положение. А то, в чем вы уверены, но это не так."

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

Дизайнеры токенов могут проверять свои предположения различными способами. Строгое статистическое моделирование, обычно в форме моделей на основе агентов, может помочь протестировать эти предположения. Предположения о поведении пользователей также могут быть проверены путем общения с пользователями, лучше всего — наблюдая за тем, что люди на самом деле делают (а не говорят, что они делают). Таким образом, вероятность успешной проверки выше, особенно через стимулы тестовых сетей, которые генерируют опытные результаты в песочнице. Официальная проверка или интенсивный аудит также помогут гарантировать, что кодовая база работает так, как ожидалось.

#5 Четко определить "абстрактные барьеры"

"Абстрактные барьеры" (abstraction barrier) — это интерфейсы между различными уровнями системы или протокола. Они используются для разделения различных компонентов системы, позволяя независимо проектировать, реализовывать и модифицировать каждый компонент. Четкие абстрактные барьеры полезны во всех областях инженерии, особенно в области проектирования программного обеспечения, но они особенно необходимы для децентрализованной разработки и крупных команд, создающих сложные системы, которые отдельные участники не могут понять.

В проектировании токенов цель устранения абстрактных барьеров — минимизация сложности. Снижение (внутренних) зависимостей между различными компонентами модели токена может привести к более лаконичному коду, меньшему количеству ошибок и лучшему дизайну токена.

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

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

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

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

#6 Сокращение зависимости от внешних параметров

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

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

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

#7 Переоценка предположений

Проектирование токена должно быть похоже на проектирование противостоящей системы. Поведение пользователей будет меняться по мере изменения работы токена.

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

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