
Request for Comments (RFC) — это процесс, в ходе которого организации открыто собирают отзывы от общественности или заинтересованных участников до утверждения предложения или плана. Его цель — учесть разные интересы и возможные риски, чтобы повысить качество и реализуемость решения.
В управлении термин «governance» означает, как сообщество или организация принимает и реализует решения по ключевым вопросам. RFC обычно применяются перед изменением правил, корректировкой комиссий, техническими апгрейдами или крупными расходами. Каналы для RFC могут включать официальные объявления на сайте, форумы, онлайн-формы или встречи. В отличие от прямого голосования, RFC делают акцент на открытых обсуждениях и сборе фактов; голосование проводится после завершения обсуждений.
RFC — это сам процесс, а RFC draft — документ, используемый для его проведения. RFC draft обычно содержит структуру с описанием предпосылок, текущей ситуации, предлагаемых изменений и перечнем вопросов для сбора обратной связи по каждому пункту.
На практике регуляторы или платформы часто публикуют RFC draft перед введением новых правил и приглашают заинтересованных лиц дать ответы по каждому пункту. Web3-проекты также выпускают RFC draft перед крупными техническими обновлениями или изменениями правил, чтобы минимизировать недопонимание и упростить отслеживание отзывов и изменений.
RFC играют ключевую роль в управлении Web3, поскольку децентрализация строится на широком участии и достижении консенсуса, а изменения технических или экономических правил могут иметь долгосрочные и масштабные последствия.
Например, DAOs (Decentralized Autonomous Organizations) — это сообщества, которыми коллективно управляют держатели токенов или участники через голосование on-chain или off-chain. Без предварительного сбора отзывов через RFC изменения в распределении средств, структуре комиссий или параметрах протокола могут привести к непредвиденным последствиям. Открытые обсуждения позволяют сообществу заранее выявлять риски, предоставлять данные и альтернативные решения, а также обеспечивать легитимность и прозрачность последующего голосования и реализации.
По состоянию на 2024 год многие крупные DAOs используют двухэтапный процесс: сначала собирают отзывы, затем проводят голосование по важным предложениям. Такой подход снижает количество процедурных споров и фрагментацию управления.
В DAO RFC обычно сочетают форумы сообщества и инструменты голосования. Процесс включает предварительное обсуждение, подготовку документа RFC, сбор отзывов, внесение изменений, голосование и исполнение решения.
Шаг 1: Начать предварительное обсуждение на форуме сообщества. Участники описывают проблему и ожидаемое влияние, чтобы собрать первые мнения.
Шаг 2: Подготовить RFC draft. В отдельные пункты вынести исходную информацию, предлагаемые изменения, риски и альтернативы для целевой обратной связи.
Шаг 3: Собрать отзывы и доработать draft. Четко представить доказательства и источники данных, ответить на возражения, при необходимости провести пилотные проекты или симуляции.
Шаг 4: Провести temperature check или голосование в Snapshot. Snapshot — популярный off-chain инструмент для голосования, позволяющий сообществу оценить настроение без затрат на gas.
Шаг 5: Провести официальное on-chain голосование и реализовать решение. Итоговые решения и изменения внедряются через смарт-контракты, которые автоматически обеспечивают выполнение правил.
В процессе EIP (Ethereum Improvement Proposal) в Ethereum RFC присутствуют на всех этапах — от подачи до внедрения. EIP — это предложение по изменению протокола Ethereum или стандартов уровня приложений.
Авторы сначала отправляют draft на GitHub — платформу для совместной работы и управления версиями кода. Затем сообщество и команды клиентов обсуждают техническую реализуемость, риски и стратегии внедрения на форумах и в репозиториях. После сбора широкой обратной связи предложение тестируется на тестовых сетях, после чего команды клиентов и core-разработчики решают, внедрять ли его. Изменения, затрагивающие комиссии или форматы транзакций, часто проходят публичное обсуждение и несколько этапов тестирования.
В сообществе Gate RFC размещаются в Центре объявлений, каналах сообщества и во время голосований. Часто обсуждаемые темы — пояснения к правилам перед запуском новых функций, корректировка структуры комиссий и сбор отзывов по предложениям сообщества.
При участии всегда проверяйте официальные каналы объявлений Gate для подтверждения источника и сроков, чтобы избежать фишинговых ссылок. При изменениях, влияющих на активы или торговые механизмы, рекомендуется давать структурированный отзыв — описывать исходные данные, проблемы, предложения и ожидаемое влияние, а также отслеживать дальнейшие обновления и уведомления о внедрении.
Для участия в RFC не требуется техническое образование, но необходима тщательная подготовка и ясная коммуникация.
Шаг 1: Проверьте подлинность источника. Убедитесь, что объявление опубликовано на официальном или доверенном канале сообщества, проверив доменное имя, номер объявления и сроки.
Шаг 2: Внимательно прочитайте RFC draft. Выделите ключевые предлагаемые изменения и определите потенциально затронутых пользователей или сценарии.
Шаг 3: Подготовьте доказательства и примеры. Используйте данные, скриншоты процессов или реальный опыт пользователей для обоснования своих предложений.
Шаг 4: Отправьте отзыв через указанные каналы. Ответьте на форуме, заполните форму обратной связи или приложите свою точку зрения при голосовании в Snapshot.
Шаг 5: Ведите учет и отслеживайте процесс. Сохраняйте ссылки и временные метки для отслеживания обновлений и статуса внедрения; при необходимости предоставляйте дополнительную информацию.
RFC — это не окончательное решение, а открытое обсуждение; голосование и реализация происходят на следующих этапах. Частое заблуждение — считать результаты обсуждения окончательными решениями или игнорировать альтернативные мнения.
Ключевые риски:
Эффективные RFC имеют четко определенные рамки и сроки, настроенные каналы обратной связи и механизмы внедрения, а также прозрачные обновления с объяснением решений после завершения процесса.
Достоверные источники, конкретное описание проблем, раскрытие данных и прозрачность рисков способствуют качественным обсуждениям. Если организаторы объясняют, почему определенные предложения не были приняты, и предлагают альтернативы или дальнейшие шаги, участники могут объективно оценить прозрачность и подотчетность управления.
RFC делают обсуждения до принятия решений публичными, минимизируя риски и повышая качество исполнения за счет активного вовлечения заинтересованных сторон. В управлении Web3 — от DAO до Ethereum — они играют центральную роль в развитии протоколов и корректировке правил в сообществах бирж. Чтобы максимально повлиять на процесс: проверяйте достоверность источников, структурируйте обратную связь, отслеживайте статус внедрения и соблюдайте осторожность при подписании транзакций или взаимодействии с предложениями для защиты средств.
RFC — это весь процесс сбора отзывов; RFC draft — конкретный документ, используемый в этом процессе. Проще говоря: draft — рабочая версия для комментариев или голосования сообщества. Первый — это действие, второй — его инструмент; они тесно связаны, но фокусируются на разных аспектах.
Начните с изучения контекста: прочитайте резюме и цели RFC draft. Затем давайте конкретные отзывы — избегайте общих комментариев, указывайте области для улучшения или возможные проблемы. В завершение участвуйте в дальнейших обсуждениях; следите за официальными ответами и изменениями, чтобы ваш вклад имел реальное влияние.
Цель RFC — собрать коллективную экспертизу, но не каждое предложение может быть принято. Основные причины отказа: несоответствие целям проекта, техническая невозможность или низкая поддержка со стороны заинтересованных лиц. Важна прозрачность — эффективное управление объясняет, почему те или иные предложения были приняты или отклонены.
Хороший RFC draft должен четко описывать предпосылки проблемы, предлагаемое содержание и потенциальное влияние. Проверьте, указаны ли цели явно, изменения — конкретны и измеримы, учтена ли обратная совместимость, а также обосновано ли окно для обратной связи. Draft с размытыми или поспешными формулировками обычно менее качественны.
Сначала проверьте, был ли ваш отзыв зафиксирован (просмотрите официальные логи обсуждений). Если он учтен, но не принят, вы можете запросить обоснование решения. Если его действительно упустили, изложите свою позицию при голосовании по управлению или повторите ее на следующих этапах — последовательная, аргументированная позиция обычно эффективнее единичного комментария.



Что такое Request for Comments?