Оригинальное название: 7 проверок работоспособности перед разработкой токена
Автор: Гай Вуоллет
Составил: Кэти Гу, Odaily Planet Daily.
Токены — это новый мощный примитив, который можно определить разными способами. Область разработки токенов обширна, но мы все еще находимся на ранних стадиях исследований.
На самом деле многие команды изо всех сил пытаются найти «правильный» дизайн токенов для своих проектов. Однако в отрасли отсутствует проверенная основа проектирования, поэтому последующие поколения постоянно сталкиваются с теми же проблемами, что и их предшественники. К счастью, есть (несколько) ранних примеров успешного дизайна токенов. Наиболее эффективные модели токенов имеют элементы, уникальные для своих целей, но большинство несовершенных конструкций токенов имеют некоторые общие ошибки. Поэтому в этой статье мы обсудим, почему нам следует рассматривать исследование и разработку токенов, а не просто «экономику токенов», и перечислим семь советов, как избежать ошибок.
#1 Уточните цели дизайна токена
Самая большая проблема в дизайне токенов заключается в том, как построить сложную модель токена, прежде чем цель станет ясна. Первым шагом должно быть определение цели и обеспечение ее полного понимания всей командой: что это такое, почему это важно и чего вы действительно хотите достичь? Неспособность четко определить цели часто приводит к перепроектированию и пустой трате времени. Наличие четких целей также помогает избежать проблемы «создания экономики токенов ради разработки экономики токенов», что является распространенным явлением в некоторых проектах экономики токенов.
Кроме того, цель должна быть связана с самим токеном, но об этом часто упускают из виду. Примеры четких целей включают в себя:
Разработайте игру с использованием модели токенов, обеспечивающей оптимальную масштабируемость и поддержку моделирования.
Протокол DeFi надеется разработать модель токенов, которая разумно распределяет риск между участниками.
Разработка протокола репутации, гарантирующего деньги, не может напрямую заменить репутацию (например, путем отделения ликвидности от сигналов репутации).
Спроектируйте сеть хранения, обеспечивающую доступность файлов с низкой задержкой.
Разработайте сеть ставок, обеспечивающую максимальную экономическую безопасность.
Разработайте механизм управления, который выявит истинные предпочтения пользователей или максимизирует участие.
Список можно продолжать и продолжать. Пусть токен поддерживает любой вариант использования и достигает любой цели, а не наоборот.
Так как же начать определять четкую цель? Четко определенные цели обычно исходят из «миссии проекта». Хотя «миссия проекта» имеет тенденцию быть высокоуровневой и абстрактной, цели должны быть конкретными и сведены к их самой базовой форме.
В качестве примера возьмем EIP-1559. Рафгарден сформулировал четкую цель EIP-1559: «EIP-1559 должен улучшить взаимодействие с пользователем за счет простой оценки затрат в форме «явного наилучшего предложения» вне периодов быстрого роста спроса».
Далее он предложил еще одну четкую цель: «Можем ли мы перепроектировать механизм комиссии за транзакцию Ethereum, чтобы сделать установление цен на транзакционный газ более «мягким», как при покупках на Amazon? Идеалом является механизм публикации цен, который означает механизм, который каждый пользователь может принять или отказаться от цены на газ».
Общим в обоих примерах является то, что вы формулируете цель высокого уровня, приводите соответствующую аналогию, чтобы помочь другим понять вашу цель, а затем переходите к обрисовке проектного решения, которое лучше всего соответствует этой цели.
#2 Оценивайте существующую работу на основе фундаментальных принципов
Создавая что-то новое, лучше всего начать с того, что уже существует. Когда вы оцениваете существующие протоколы и существующую литературу, их следует оценивать объективно, исходя из их технических достоинств.
Модели токенов часто оцениваются на основе цены токена или популярности связанного с ним проекта. Эти факторы могут быть не связаны со способностью модели токена достигать заявленных целей. Оценка, популярность или другие упрощенные способы оценки модели токена могут привести к тому, что разработчики пойдут в обход. Если вы предполагаете, что другие модели токенов функционируют правильно, хотя на самом деле это не так, вы можете создать «испорченную» модель токенов.
#3 Уточните свои предположения
Проясните свои предположения. Когда вы сосредотачиваетесь на создании монеты, легко принять базовые предположения как нечто само собой разумеющееся. Также легко исказить предположения, которые вы на самом деле делаете.
Возьмем, к примеру, новый протокол, который предполагает, что узким местом его аппаратного обеспечения является скорость вычислений. Включение этого предположения в модель токена (например, путем ограничения стоимости оборудования, необходимого для участия в протоколе) может помочь привести проект в соответствие с желаемым поведением.
Однако если разработчики протоколов и токенов не выражают четко свои предположения или высказанные ими предположения неверны. Участники, которые знают об этом несоответствии, имеют возможность извлечь выгоду из протокола. Хакерами обычно являются люди, которые понимают систему лучше, чем люди, которые ее изначально создали.
Разъяснение ваших предположений поможет людям понять дизайн вашего токена и убедиться, что он работает правильно. Если вы не ясно изложите свою гипотезу, вы не сможете ее проверить.
#4 Проверьте свои предположения
Есть поговорка: «Не то, чего вы не знаете, создает вам проблемы, а то, в чем вы убеждены».
Модели токенов часто делают ряд предположений. Этот подход частично исходит из византийского системного дизайна, который послужил источником вдохновения для блокчейна. Система делает предположение и строит функцию, которая, если предположение верно, гарантирует определенный результат. Например, Биткойн гарантирует активность в синхронной сетевой модели, гарантируя согласованность, если 51% хеш-мощности в сети является честным. Несколько небольших блокчейнов подверглись атакам 51%, что нарушило ряд предположений о честности, требуемых консенсусом Сатоши для правильного функционирования блокчейнов.
Разработчики токенов могут проверить свои предположения различными способами. Строгое статистическое моделирование, часто в форме агентных моделей, может помочь проверить эти гипотезы. Гипотезы о поведении пользователей также часто можно проверить, поговорив с пользователями, а еще лучше, наблюдая за тем, что люди на самом деле делают (а не рассказывая, что они делают). Вероятность успешной проверки выше, особенно в случае стимулированных тестовых сетей, которые дают эмпирические результаты в изолированной среде. Формальная проверка или интенсивный аудит также помогут гарантировать, что кодовая база работает должным образом.
№ 5. Определите «абстрактные барьеры»
«Барьер абстракции» — это интерфейс между различными уровнями системы или протокола. Он используется для разделения различных компонентов системы, позволяя проектировать, внедрять и модифицировать каждый компонент независимо. Четкие барьеры абстракции полезны во всех областях разработки, особенно в разработке программного обеспечения, но они еще более необходимы для децентрализованной разработки и больших команд, создающих сложные системы, которые ни один человек не может понять.
При разработке токенов целью устранения барьеров абстракции является минимизация сложности. Уменьшение (внутренних) зависимостей между различными компонентами модели токена может привести к более чистому коду, меньшему количеству ошибок и улучшению дизайна токенов.
Например, многие блокчейны создаются крупными инженерными командами. Команда может сделать предположения о стоимости оборудования с течением времени и использовать их для определения того, сколько майнеров внесут оборудование в блокчейн по заданной цене токена. Если другая команда полагается на цену токена в качестве параметра, но не знает предположений первой команды о стоимости оборудования, они могут легко сделать противоречивые предположения.
На уровне приложения четкие барьеры абстракции имеют решающее значение для достижения возможности компоновки. По мере того, как все больше протоколов будут комбинироваться друг с другом, возможность адаптации, создания, расширения и ремиксов будет становиться только более важной. Большие композиции открывают больше возможностей, но и большую сложность. Когда приложения хотят компоновать, они должны понимать детали протокола композиции, который они используют.
Непрозрачные предположения и интерфейсы могут иногда приводить к неясным ошибкам, особенно в ранних протоколах DeFi. Барьеры нечеткой абстракции также повышают эффективность взаимодействия между командами, работающими над различными компонентами протокола, тем самым продлевая время разработки. Неопределенные барьеры абстракции также увеличивают сложность протокола, затрудняя полное понимание его механики.
Создавая четкие абстрактные барьеры, разработчики токенов могут легче предсказать, как конкретные изменения повлияют на каждую часть дизайна токена. Четкие барьеры абстракции также упрощают расширение токена или протокола и создают более инклюзивное и масштабируемое сообщество Builder.
#6 Уменьшить зависимость от внешних параметров
Внешние параметры не являются присущими системе, но могут влиять на общую производительность и успех, например, стоимость вычислительных ресурсов, объем транзакций или задержка на ранних этапах создания модели токена.
Но когда модель токена работает только тогда, когда параметры находятся в ограниченном диапазоне, может произойти неожиданное поведение. Например, протокол, который продает услуги и предоставляет скидки в виде фиксированного вознаграждения в виде токенов, может стоить больше, чем стоимость услуги, если цена токена неожиданно высока. В этом случае вполне рентабельно приобрести неограниченное количество услуг протокола, что позволит в полной мере воспользоваться преимуществами и услугами токенов.
Или, возьмем другой пример: децентрализованные сети часто полагаются на криптографические алгоритмы или вычислительные головоломки, которые сложно, но возможно решить. Сложность обычно зависит от экзогенной переменной, например, от того, насколько быстро компьютер может вычислить хэш-функцию или доказательство с нулевым разглашением. Например, существует протокол, который предполагает, насколько быстро может быть вычислена данная хеш-функция, и соответственно выплачивает вознаграждение в виде токенов. Если кто-то изобретет новый способ более быстрого вычисления хеш-функции или просто располагает огромными ресурсами для решения проблемы, непропорциональными его фактической работе в системе, он может быть вознагражден неожиданно огромными токенами.
#7 Повторная проверка предположений
Разработка токена должна быть похожа на разработку состязательной системы. Поведение пользователя изменится по мере изменения способа работы токена.
Распространенной ошибкой является корректировка модели токена без обеспечения того, чтобы произвольное поведение пользователя по-прежнему приводило к приемлемым результатам. Не думайте, что поведение пользователей останется прежним из-за изменений в модели токена. Обычно такого рода ошибки случаются на поздних стадиях процесса проектирования, когда кто-то потратил много времени на определение цели токена, его функциональность и проверку, чтобы убедиться, что он работает должным образом. Затем они выявили особый случай и изменили дизайн токена, чтобы он соответствовал ему, но забыли перепроверить всю модель токена. Фиксируя один частный случай, они создают другой (или несколько других) непредвиденные последствия.
Помните, что не позволяйте своей тяжелой работе пропадать даром: всякий раз, когда проект меняет свою модель токена, повторно проверяйте, что она работает так, как ожидалось.