🔐 Черный список, белый список, приостановка переводов, ограничения на объем сделок: в чем разница?
В первых двух статьях мы обсудили, почему цифровые активы могут быть ограничены и как проверить это с помощью обозревателя блокчейна, истории транзакций, исходного кода контракта и настроек доступа.
Сегодня мы углубимся в тему еще на один шаг.
Предположим, вы открыли контракт токена и обнаружили в нем такие функции, как управление адресами, приостановка переводов или ограничение объема сделок. Что именно они означают? Как они могут повлиять на обычных пользователей? И как определить связанные с ними реальные риски?
Прежде всего важно прояснить один момент:
Обнаружение механизма ограничения ещё не доказывает, что активы действительно ограничены; обнаружение административных прав ещё не доказывает злонамеренность проекта. Важны устройство механизма, объём полномочий, фактическое состояние и история его применения.
I. Чёрный список: почему некоторые адреса могут не иметь возможности переводить средства?
Механизм чёрного списка обычно используется для выявления адресов, участие которых в определённых операциях нужно ограничить.
Если логика переводов в контракте токена проверяет адреса по чёрному списку, адресам, внесённым в список, могут быть недоступны некоторые переводы.
Однако конкретное влияние зависит от того, как устроен контракт.
Например, одни правила могут запрещать адресам отправлять токены, а другие — также затрагивать получение токенов, торговлю или иные операции. Нельзя только на основании слов «есть чёрный список» заключать, что все связанные операции будут неудачными.
При проверке особое внимание следует уделить следующему:
действительно ли в контракте реализован механизм ограничения адресов;
какие роли вправе добавлять адреса и удалять их;
затрагивают ли правила отправку, получение или другие операции.
Подпадает ли целевой адрес в данный момент под действие соответствующих правил;
Могут ли исторические записи помочь подтвердить, происходили ли соответствующие действия.
Также следует учитывать, что названия функций в исходном коде контракта не всегда полностью отражают их фактическое поведение. Некоторые правила могут реализовываться косвенно через другие функции, поэтому необходимо анализировать конкретный код.
Главные вопросы о чёрном списке — не только есть ли он, но и кто может им управлять, как действуют правила и что именно они ограничивают.
II. Белый список: означает ли разрешение на торговлю отсутствие других ограничений?
Белый список обычно используется для указания адресов, которые могут участвовать в определённой операции.
Например, на определённом этапе некоторые токены могут разрешать торговлю только адресам, отвечающим заданным условиям. В этом случае адреса, не включённые в белый список, могут не иметь возможности выполнить соответствующую операцию.
Однако белый список не обязательно означает, что остальные адреса навсегда лишены возможности переводить средства. Он также не означает, что на адреса из белого списка не распространяются никакие ограничения.
Конкретная ситуация зависит от устройства контракта, текущего этапа и других условий и ограничений.
Нужно также проверить:
на какие операции распространяется белый список;
как адреса добавляют в список и удаляют из него;
кто обладает соответствующими административными правами;
ограничены ли правила белого списка по времени или условиям;
есть ли другие проверки переводов.
Например, даже адрес, соответствующий условиям белого списка, может не суметь совершить транзакцию из-за недостатка средств, комиссии или несоблюдения других условий контракта.
Поэтому не стоит упрощённо считать белый список «списком безопасных адресов» или только на основании его наличия делать вывод о каких-либо конкретных свойствах проекта.
Белый список определяет круг разрешённых действий в рамках конкретных правил, но не гарантирует безопасность активов или надёжность проекта в целом.
III. Приостановка переводов: что именно позволяет функция паузы?
Механизм паузы обычно позволяет временно остановить некоторые операции в контракте при определённых условиях.
В некоторых проектах токенов роли с соответствующими правами могут активировать функцию паузы, чтобы временно ограничить переводы в случае инцидента безопасности или при других особых обстоятельствах.
Такой механизм может дать время на решение проблемы, но при этом способен помешать пользователям нормально распоряжаться активами.
При оценке нужно разграничивать три вопроса:
Во-первых, есть ли в контракте функция паузы?
Это можно проверить по открытому исходному коду и связанным интерфейсам.
Во-вторых, активна ли функция паузы сейчас?
Само наличие функции паузы не доказывает, что контракт сейчас приостановлен. Это нужно проверять с учётом текущего состояния, истории транзакций и доступных записей о событиях.
В-третьих, кто вправе приостанавливать и возобновлять операции?
Если существуют администратор, владелец или другие особые роли, необходимо выяснить объём их полномочий и проверить, ограничены ли они механизмами вроде мультиподписи и таймлока.
Следует также помнить, что функция паузы может распространяться только на некоторые операции и не обязательно затрагивает все функции контракта.
Поэтому точнее не говорить «наличие функции паузы означает опасность», а сначала выяснить, что именно она контролирует, каково её текущее состояние и кто может её активировать.
IV. Ограничения объёма торгов: почему иногда можно перевести только часть средств?
В некоторых контрактах токенов могут быть установлены ограничения на сумму и частоту транзакций, количество хранимых токенов или другие условия.
Например, правило может ограничивать максимальную сумму одной транзакции или на определённом этапе устанавливать лимит на частоту торгов.
Однако такие правила есть не у всех токенов и они не обязательно рассчитываются одинаково.
Если пользователь обнаружил, что крупные транзакции не проходят, а мелкие проходят, ограничения по сумме могут стать одним из направлений расследования, но нельзя сразу считать их причиной.
Нужно также проверить баланс, комиссию, настройки проскальзывания, параметры транзакции, ликвидность и другие факторы, способные повлиять на её выполнение.
При проверке следует сопоставить исходный код контракта, сведения об ошибках транзакций и фактически действующие правила.
Ограничения объёма торгов могут влиять на способы использования активов, но сначала необходимо подтвердить, что такие правила действительно существуют, и разобраться в условиях их применения.
V. Обновляемые контракты: могут ли сегодняшние правила измениться в будущем?
В некоторых смарт-контрактах используется обновляемая архитектура, которая позволяет субъектам с соответствующими правами менять логику реализации контракта при соблюдении определённых условий.
Это означает, что видимые сейчас код и правила не обязательно полностью отражают всё возможное поведение контракта в будущем.
Но и здесь важно не допускать неверных выводов.
Обновляемый контракт не означает автоматически, что он небезопасен. Механизм обновления может использоваться для устранения уязвимостей, улучшения функций или настройки системы.
Обратить внимание следует на следующее:
использует ли контракт обновляемую архитектуру;
кто контролирует право на обновление;
ограничено ли обновление мультиподписью или таймлоком;
можно ли проверить историю обновлений;
могут ли пользователи своевременно узнавать об изменениях правил;
публикуются ли после обновления соответствующие пояснения или материалы аудита.
Если контракт можно обновлять, недостаточно изучить исходный код на какой-то один момент времени — нужно также учитывать права на обновление и последующие изменения.
VI. Как оценивать ситуацию, если присутствуют сразу несколько таких механизмов?
В реальных контрактах могут одновременно присутствовать разные механизмы.
Например, в одном контракте могут сочетаться функция паузы, правила управления адресами и обновляемая архитектура. Вместе эти функции могут образовывать более сложную систему полномочий.
Однако большое количество механизмов само по себе не означает, что риск обязательно выше. И наоборот: наличие мультиподписи, таймлока и отчёта об аудите не означает, что все риски устранены.
Разумнее оценивать ситуацию в совокупности по четырём аспектам:
1. Что это за механизм?
Установите его реальные функции, а не судите только по названию.
2. Кто им управляет?
Определите, кто вправе менять правила, управлять адресами или выполнять ключевые операции.
3. Каково его текущее состояние?
Сопоставьте состояние контракта, записи о транзакциях и историю событий, чтобы выяснить, действует ли этот механизм сейчас.
4. Достаточно ли доказательств?
Отделяйте факты, подтверждённые данными блокчейна или надёжными источниками, от предположений, требующих дальнейшей проверки.
Эти четыре вопроса помогают избежать двух крайностей: считать проект проблемным, увидев одну функцию, или прекращать проверку, услышав обещания проекта о безопасности.
VII. Вернёмся к ONEA: почему мы продолжаем обсуждать эти детали?
Ранее сообщество ONEA задавало вопросы о приватных ключах, правах в контрактах, прозрачности кода, аудитах безопасности и реальном ходе развития проекта.
Эти обсуждения отражают важную потребность: люди хотят понимать технические механизмы, а не просто слушать их описание.
Поэтому, рассказывая о ONEA или обсуждая любой Web3-проект, мы должны по возможности отделять технические понятия от информации, которую можно проверить.
Если какая-либо функция уже реализована, это следует подтверждать надёжными источниками, насколько это возможно.
Если какая-либо функция пока только запланирована, это нужно ясно обозначать, а не представлять её как уже запущенную.
Если наличие тех или иных прав или факт проведения аудита пока невозможно подтвердить, об этом также следует честно сказать.
Это не значит, что проект следует отвергать лишь из-за наличия полномочий. Важно понимать их назначение, границы и фактическое влияние.
VIII. В следующей статье применим эти методы оценки к реальным ситуациям
Мы рассмотрели пять распространённых механизмов: чёрный список, белый список, приостановку переводов, ограничения объёма торгов и обновляемые контракты.
Но теоретического объяснения недостаточно.
Как связать исходный код, настройки прав доступа, историю операций и текущее состояние, когда эти механизмы встречаются в реальном контракте? А если общедоступная информация неполна, как избежать ошибочных выводов?
В следующей статье мы продолжим разбирать, как с помощью конкретных данных из блокчейна оценивать фактическое влияние механизмов ограничений, и рассмотрим, какие сведения могут служить основанием для выводов, а что пока нельзя подтвердить.
Мы хотим, чтобы каждая статья приносила ясную пользу и помогала читателям задавать более глубокие вопросы.
Не ограничивайтесь вопросом о том, существует ли тот или иной механизм. Выясняйте, как он работает, кто им управляет и что он означает для пользователей.
Если вам близок такой подход к обсуждению, основанный на фактах, механизмах и доказательствах, следите за ONEA.
ОДНА СЕТЬ. ОДНО БУДУЩЕЕ. ОДИН МИР.
#ONEA #Web3 #Blockchain #SmartContracts #DigitalAssets
