Сырая скорость не является прорывом, предсказуемым включением, когда сеть загружена. Большинство людей это упускает, потому что они измеряют цепочки в средних значениях, а не в худших пяти минутах. Для строителей и пользователей это меняет «быстро ли?» на «какова моя вероятность приземлиться прямо сейчас?»
Я был достаточно много раз на волатильных сессиях, чтобы заметить закономерность: техническая система может «работать», в то время как пользователь все еще чувствует, как земля уходит из-под ног. В спокойные периоды все считают, что сборы — это просто строка затрат. В моменты ажиотажа сборы превращаются в инструмент времени, а время — это то, что отделяет победы от поражений. Одно небольшое наблюдение за тем, как мои друзья торгуют: фрустрация возрастает, когда кто-то платит и все еще чувствует себя случайным, а не когда они просто платят.
Представьте себе очень обычную ситуацию. Розничный трейдер управляет небольшой позицией с кредитным плечом и использует простое правило: если цена пробивает уровень, закройте немедленно и сбросьте. Происходит резкое движение, трейдер нажимает закрыть, и приложение показывает «отправлено». Но в то же время тысячи других людей обмениваются, настраивают обеспечение, отменяют заказы и делают то же самое «спасите меня» нажатие. Пространство блока становится ограниченным. В этот момент, если Fogo поддерживает приоритетные советы, трейдер не спрашивает о более низкой комиссии. Он спрашивает: «Какой совет делает это закрытие вероятным, чтобы оно было включено в следующий блок или два, вместо того чтобы отставать от толпы?» Проблема продукта становится вероятностью, а не ценообразованием.
Приоритетный совет - это платная полоса: вы платите, чтобы обойти очередь, а не чтобы изменить пункт назначения.
В условиях стресса цепочка нуждается в четком способе ранжирования срочности. Подумайте о состоянии сети как о двух частях. Во-первых, текущее состояние книги: кто что владеет и какие позиции или заказы существуют согласно приложениям, использующим цепочку. Во-вторых, публичная комната ожидания подписанных транзакций ("ожидаемый пул", то есть запросы, которые действительно подписаны, но еще не выполнены). Каждый блок принимает ограниченное количество из этих ожидающих запросов, выполняет их и публикует обновленное состояние. Это вся машина: выберите, выполните, обновите.
Поток транзакций - это то место, где важны приоритетные советы. Вы подписываете транзакцию, которая включает (1) ваше намерение («закрыть эту позицию», «отменить этот заказ», «обменять эту сумму») и (2) условия комиссии, которые вы готовы заплатить. Валидаторы проверяют вашу подпись и основную действительность (вы можете заплатить комиссию; формат транзакции правильный), затем производитель блока выбирает, какие ожидающие транзакции включить. В условиях перегрузки выбор становится экономическим выбором: если две действительные транзакции конкурируют за одно и то же ограниченное пространство, та, которая предлагает больше общей ценности (базовая комиссия плюс совет), обычно более привлекательна. Таким образом, совет не гарантирует успех, но может измеримо повысить ваши шансы на включение по сравнению с другими.
Тонкий момент в том, что включение не является тем же самым, что и результат. Даже если ваша транзакция "высокий совет", она все равно должна оставаться действительной в момент выполнения. Если рынок движется, состояние движется вместе с ним. Закрытие может потерпеть неудачу, если позиция уже ликвидирована, или если проверки риска больше не проходят, или если инструкции приложения предполагают цену, которая больше не существует. Именно поэтому время имеет зубы: более раннее выполнение означает, что вы взаимодействуете с более ранним состоянием, и более ранние состояния могут быть значительно другими во время быстрых движений. Приоритетные советы на практике дают вам лучшее место в очереди, чтобы коснуться состояния, которое вы хотите, прежде чем оно изменится.
Стимулы объясняют как силу, так и опасность. Производитель блока получает оплату за комиссии, поэтому логично предпочитать транзакции, которые платят больше за единицу пространства блока, если они действительны и следуют правилам протокола. Это соответствует срочным пользователям: вы платите, чтобы быть выбранным. Но это также создает предсказуемые режимы отказа. Один из них - это всплески комиссий, которые делают рутинные действия недоступными во время всплесков. Другой - это "угадывание комиссии", когда кошельки и пользователи переплачивают, потому что они не могут видеть истинный конкурентный ландшафт. Третий - это динамика войны ставок: боты могут постоянно перебивать ставки, чтобы защитить свои стратегии, превращая приоритет в гонку вооружений, которую обычные пользователи воспринимают как хаос. И есть человеческий режим отказа: если пользователь платит премию и все равно пропускает следующий блок, он интерпретирует это как сбой, даже если система действовала именно так, как задумано.
Что гарантировано, а что нет, должно быть четко указано. Совет может улучшить ваш относительный рейтинг, но он не может гарантировать «следующий блок», если спрос превышает емкость, если распространение неравномерно (некоторые валидаторы видят некоторые транзакции раньше других) или если ваша транзакция становится недействительной к моменту ее выполнения. Если протокол накладывает строгие ограничения на порядок, советы могут иметь ограниченное влияние; если порядок более гибкий, советы могут доминировать и казаться жесткими в условиях стресса. Каждый выбор дизайна имеет свои компромиссы, но ни один из них не превращает срочность в уверенность.
Утилита FOGO находится прямо на этом механизме. Комиссии - это то, как вы платите за выполнение и конкурируете за ограниченное пространство блока, когда это имеет значение. Стейкинг - это обязательство безопасности, которое выравнивает валидаторов, чтобы следовать правилам, потому что неправильное поведение рискует потерять ставленную стоимость и будущие награды. Управление - это предохранительный клапан: параметры, касающиеся ограничений блока, правил комиссии и любых ограничений на влияние совета, могут быть настроены со временем на основе реальной перегрузки и реальных пользовательских страданий, а не только теории.
Если сложные боты захватывают потоки заказов или валидаторы используют частные маршруты и особенности выбора, то один и тот же отображаемый совет может привести к различным результатам включения в разных всплесках.
Если бы вы разрабатывали UX кошелька на Fogo, представили бы вы совет как «дополнительные расходы» или как «дополнительная вероятность быстрого выполнения»?
