ERC-7683 меняется, и многие объяснения всё ещё описывают более раннюю версию стандарта. Текущий черновик ERC-7683 более ориентирован на резолверы. Вместо того чтобы принуждать каждый кросс-чейн протокол намерений к использованию одного общего эскроу-контракта, одной системы аукциона, одного механизма расчёта, одной модели авторизации или одной функции заполнения назначения, протоколы могут сохранять собственную архитектуру исполнения, одновременно предоставляя заказы решателям через общий слой резолюции. Это различие имеет значение. Заказ ERC-7683 по сути является предложением оплаты в обмен на выполнение определённого набора требований. Решатели, также называемые заполнителями, оценивают эти требования, определяют, какое исполнение необходимо, вкладывают капитал или газ и ожидают оплаты, если они корректно выполнят заказ. Текущая архитектура позволяет протоколу предоставлять непрозрачный, специфичный для протокола полезный груз вместе с контрактом резолвера. Этот резолвер преобразует полезный груз в общее представление, содержащее: • шаги исполнения • переменные • платежи • явные допущения Это даёт программируемым решателям стандартизированный способ понимать, что именно требуется для заказа, без необходимости реализовывать полностью уникальную логику для каждого протокола намерений. Модель исполнения после резолюции может раскрывать требования к расходованию токенов, требования к газу, временные ограничения, зависимости и поведение при откате. Переменные могут представлять адреса оплаты решателя, цепочки оплаты, выходные данные исполнения, вызывающие шаги, оффчейн-свидетели, запросы к контрактам и запросы событий. ERC-7683 также включает интероперабельные представления адресов через ERC-7930, привязывая контекст цепочки к адресу вместо полагания исключительно на традиционный 20-байтовый EVM-адрес. Однако существует важная граница безопасности. Стандартизация ERC-7683 не делает автоматически безопасным базовый протокол намерений. Контракты расчёта, мосты, системы передачи сообщений, токены, механизмы аукциона, оффчейн-сервисы, оракулы, блокировки ресурсов, защита от повторного воспроизведения, логика отмены, поведение при возврате и частичное заполнение остаются протокольно-специфичными рисками, если они явно не представлены через резолюционные требования или допущения. Безопасность резолвера поэтому критически важна. Резолвер должен корректно проверять свой протокольно-специфичный полезный груз и предоставлять представление, позволяющее корректно действующему решателю понять, что должно произойти и при каких допущениях оплата станет доступной. Правильный резолвер не может сделать небезопасную систему расчёта безопасной. И соответствующий формат заказа не устраняет риск для решателя. Заполнитель становится экономически уязвимым с момента предоставления разрешений, газа, капитала или транзакций до тех пор, пока ожидаемая оплата не станет финальной и доступной для расходования. Для пользователей ключевые точки проверки остаются практическими: • исходная цепочка • входной актив • цепочка назначения • получатель • ожидаемый выход • дедлайн • область авторизации • транзакция или типизированные данные, которые подписываются ERC-7683 естественным образом встраивается в более широкие системы намерений, такие как Open Intents Framework, но эти два понятия не взаимозаменяемы. ERC-7683 в первую очередь является слоем стандартизации для разрешения заказов, ориентированных на решателей. OIF — это более широкая инфраструктурная рамка, охватывающая создание намерений, решение, выполнение, расчёт, агрегацию и связанные компоненты. Наши последние исследования в TokenToolHub детально разбирают текущий дизайн ERC-7683, его отличия от предыдущих черновиков, жизненный цикл заказа, заполнителей, безопасность резолверов, шаги исполнения, платежи, допущения, интероперабельные адреса и риски решателей, остающиеся за пределами самого стандарта. Полный анализ: https://t.co/VK5Yb4wvJ3