Я потратил выходные, тестируя домен identity по идентичности Ньютона против хранилища, которое я сам настроил в песочном окружении — такого, где перед любым депозитом или снятием требуется проверка соответствия инвестора. Мой план был простым и немного противодействующим: пройти проверку один раз, а затем посмотреть, насколько далеко я смогу зайти, выполняя действия, которые должны были потребовать повторной проверки. Я хотел найти уязвимость.
Точка входа была нарочито обыденной. Я подключил кошелёк, прошёл проверку соответствия, которую требовала политика identity Ньютона, и получил одобрение. Ничего драматичного: тот же сценарий, через который прошёл бы любой, кто размещает реальные средства в регулируемом хранилище. Я внёс небольшую сумму, наблюдал за подтверждением транзакции и начал планировать ту часть, которая меня действительно интересовала: что происходит при следующем действии — том, которое, как я предполагал, должно было просто унаследовать доверие от первой проверки.
То, что произошло на самом деле, удивило меня — в основном потому, что это должно было быть вполне предсказуемо, если бы я перед тестированием внимательнее подумал об архитектуре Newton. Я попытался вывести средства спустя несколько часов, ожидая, что все пройдет быстро, ведь я уже все проверил. Вместо этого политика заново оценила соответствие в рамках именно той транзакции: она снова проверила те же условия, а не относилась к моему прежнему одобрению как к постоянным учетным данным. Это не было процессом с высокой степенью трения: проверка шла в фоне как часть авторизации транзакции, но это была реальная переоценка, а не «флаг уже проверено», протаскиваемый автоматически из кэша.
Я попытался провести второй тест после этого, смоделировав смену юрисдикции для того же кошелька, чтобы проверить, сможет ли система обнаружить учетные данные, которые фактически устарели между моим пополнением и следующим действием. Система это сделала. Вывод, который должен был пройти при моем исходном статусе соответствия, был заблокирован при обновленном статусе: соответствие оценивалось заново, непосредственно в момент транзакции, а не по какому-то статусу, который у меня был несколько часов назад, когда я впервые подключился.
Для меня поворотным моментом стало не само блокирование — множество систем может блокировать транзакцию. Дело было в осознании того, что в этой архитектуре идентичность рассматривается как условие, проверяемое в момент каждого действия, а не как бейдж, выданный один раз и которому можно доверять бесконечно. Большинство onchain-систем идентичности, которые я тестировал, работают как стойка ресепшн: проверяют на входе, выдают пропуск — и дальше человек может свободно действовать. Домен идентичности Newton устроен больше как здание, в котором лифт сам по себе не откроется на неправильный этаж, независимо от того, как давно вы получили бейдж и насколько законным он выглядел на тот момент.
Это важнее, чем звучит, потому что отказ, который эта система предотвращает, — это ровно тот тип проблемы, который не проявляется ни в демо, ни в презентации, — он всплывает спустя месяцы, когда учетные данные тихо устаревают и никто не замечает, потому что система больше никогда не удосужилась проверить. Модель «стойка ресепшн» удобна, пока не наступает момент, когда меняется юрисдикция, или истекает период верификации, или сдвигается регуляторное требование — и у системы нет механизма, чтобы поймать что-либо из этого, потому что она перестала смотреть после первого одобрения.
Честный компромисс, который я заметил во время тестирования, — это трение (фрикция). Переоценка соответствия при каждой транзакции добавляет небольшую дополнительную ступень, которую полностью пропускает модель «одна единственная верификация», и для хранилища, которое обрабатывает высокий объем транзакций, этот оверхед — реальная стоимость, а не гипотетическая. Стоит ли это трение того с точки зрения безопасности — зависит целиком от того, что именно поставлено на карту в конкретном vault: стратегия с низкими рисками может разумно терпеть более мягкую модель, тогда как регулируемый vault формата RWA почти наверняка не должен.
Есть еще вопрос, на который я не смог дать полностью ответ, опираясь только на среду песочницы: как домен идентичности ведет себя, когда одновременно взаимодействуют несколько условий — например, смена юрисдикции происходит в тот же момент, когда слой верификации находится в процессе продления, скажем, а не как в моих аккуратных тестах с одним параметром. Реальные пользователи не меняют один набор учетных данных за раз в контролируемом порядке — они накапливают неразбериху из пересекающихся изменений, и система, которая хорошо справляется с одним чистым тестовым сценарием, не обязана так же хорошо обрабатывать три пересекающихся крайних случая. Именно эту часть не может окончательно прояснить даже уикенд песочных тестов, и именно она важнее всего, когда речь идет о реальном капитале и реальных пользователях, а не о намеренно враждебном тестовом аккаунте.
Домен идентичности Newton оценивает соответствие как текущее условие, привязанное к каждой транзакции, а не как учетные данные, которым можно доверять бесконечно после одного единственного проверки. Это структурно иной подход, чем тот, как сегодня все еще работает большинство систем верификации onchain. То, чего я все еще не знаю после уикенда тестов, — как масштабируется накладные расходы на переоценку, когда хранилище (vault) обрабатывает тысячи транзакций в час, а не те несколько, которые я прогонял в песочнице.