Я потратил некоторое время на борьбу с этим, и это как раз тот случай интеграционной странности, которая застает врасплох, даже когда по документам всё выглядит правильно. Вы разворачиваете контракт, подключаете его к Newton, задаёте адрес контракта Policy, чтобы он был явно виден в блокчейне, и считаете, что всё готово. Затем вы пытаетесь валидировать attestation — и… ничего. Это просто не работает, причём часто без громкой ошибки, которая указывала бы, куда копать.
Происходит вот что: Ньютон разбивает общую схему на два шага, которые ощущаются так, будто должны быть одним. Сначала вы указываете вашему клиенту на контракт Policy, вызывая что-то вроде setPolicyAddress. Он сохраняет адрес и, возможно, выполняет проверку версии, если вы владелец, но на этом всё. На самом деле он не включает никакие правила политики и не даёт тот самый идентификатор, который важен для валидации.
Второй шаг — там и происходит «магия» (или разочарование). Вам нужно зарегистрировать реальную конфигурацию политики через setPolicy или её внутреннюю версию. Именно это закрепляет ваши конкретные правила — время истечения, параметры и всё остальное — и возвращает настоящий policyId. Пока вы этого не сделаете, ваш контракт будет лежать с policyId, равным нулю, хотя адрес выглядит идеально.
Каждая получаемая вами аттестация несёт собственный policyId. Логика валидации Newton проверяет, что этот идентификатор совпадает с тем, что зарегистрировано у вас, вместе с проверкой подписи и кворума. Поэтому если ID отсутствует или не совпадает, всё отрабатывает тихо — и в результате ничего не проходит. Другие функции вашего контракта могут работать нормально, но всё, что защищено валидацией аттестаций, остаётся заблокированным.
Мне правда нравится логика этого разделения. Оно не даёт системе случайно активироваться до того, как вы действительно будете готовы. Это не просто «вот адрес» — это «вот полностью настроенная политика, по которой можно проверять аттестации». Такой явный «передаточный» этап ощущается как умная мера безопасности в мире, где слишком свободные значения по умолчанию могут создавать реальные головные боли.
При этом оно создаёт скрытое неполное состояние, которое трудно заметить. Деплой проходит успешно, адреса корректно появляются в обозревателях, и вам может показаться, что вы уже закончили. Проблема даёт о себе знать только тогда, когда вы начинаете тестировать реальные сценарии. Большинство багов кричит сразу — откатами (reverts) или отсутствующими частями; этот же ждёт, пока вы зайдёте дальше по дороге.
Если вы работаете с Newton, полезно рассматривать этот шаг регистрации как обязательный и после него обязательно проверить, что есть корректный policyId. Небольшая дополнительная проверка во время деплоя позже сэкономит массу времени и нервов. В итоге это решение, которое делает ставку на ясность и осознанность, а не на бесшовное удобство — и, честно говоря, это, возможно, именно то, что вам нужно, когда вы имеете дело с аттестациями, которые контролируют доступ и права. Как только вы усваиваете двухшаговый ритуал, это перестаёт ощущаться как ловушка и начинает выглядеть как надёжный страховочный барьер.
@NewtonProtocol $NEWT #Newt #OilPriceFalls #KoreanWonWeakestSince2009 #JDVanceDisclosesBTCHoldings #KoreanWonWeakestSince2009 #BitcoinSlidesTo$59250
