ERC-7683 змінюється, і багато пояснень все ще описують попередню версію стандарту. Поточний чернетка ERC-7683 більш орієнтована на резолвери. Замість того, щоб змушувати кожен крос-чейн інтент-протокол використовувати один спільний ескроу-контракт, одну систему аукціонів, один механізм розрахунків, одну модель авторизації чи одну функцію заповнення призначення, протоколи можуть зберігати власну архітектуру виконання, одночасно відкриваючи замовлення для розв’язувачів через спільний резолверний шар. Ця відмінність має значення. Замовлення ERC-7683 є суттєво пропозицією оплати за виконання певного набору вимог. Розв’язувачі, також відомі як заповнювачі, оцінюють ці вимоги, визначають, яке виконання необхідне, залучають капітал чи газ і очікують оплату, якщо вони правильно виконають замовлення. Поточна архітектура дозволяє протоколу відкривати непрозорий, специфічний для протоколу пакет даних разом із резолверним контрактом. Цей резолвер перетворює пакет даних на загальну репрезентацію, що містить: • кроки виконання • змінні • платежі • явні припущення Це надає програмованим розв’язувачам стандартизований спосіб розуміння того, що саме вимагає замовлення, без необхідності реалізовувати повністю унікальну логіку для кожного інтент-протоколу. Модель виконання після резолюції може виявляти вимоги до витрат токенів, вимоги до газу, часові обмеження, залежності та поведінку при скасуванні. Змінні можуть представляти адреси оплати розв’язувача, ланцюги оплати, вихідні дані виконання, викликачі кроків, поза-ланцюгових свідків, запити до контрактів та запити подій. ERC-7683 також інтегрує взаємодію адрес через ERC-7930, прив’язуючи контекст ланцюга до адреси замість залежності лише від звичайної 20-байтової EVM-адреси. Але існує важлива межа безпеки. Стандартизація ERC-7683 автоматично не робить базовий інтент-протокол безпечним. Контракти розрахунків, мости, системи передачі повідомлень, токени, механізми аукціону, поза-ланцюгові сервіси, оракули, блокування ресурсів, захист від повторного виконання, логіка скасування, поведінка повернення коштів та часткове заповнення залишаються протокольно-специфічними ризиками, якщо їх не представито явно через резольвовані вимоги чи припущення. Тому безпека резолвера є критично важливою. Резолвер має правильно валідувати свій протокольно-специфічний пакет даних і виявляти репрезентацію, яка дозволяє коректно діючому розв’язувачевi зрозуміти, що має відбутися та за яких припущень оплата стане доступною. Правильний резолвер не може зробити небезпечну систему розрахунків безпечною. І відповідний формат замовлення не усуває ризики для розв’язувача. Заповнювач стає економічно виставленим на ризик з моменту надання дозволів, газу, капіталу чи транзакцій до моменту, поки очікувана оплата не стане фінальною та витратною. Для користувачів ключовими точками перевірки залишаються практичні: • початковий ланцюг • вхідний актив • ланцюг призначення • одержувач • очікуваний вихід • термін • дозволений обсяг авторизації • транзакція чи типовані дані, які підписуються ERC-7683 також природно поєднується з більш широкими інтент-системами, такими як Open Intents Framework, але це не взаємозамінні концепції. ERC-7683 є переважно шаром стандартизації для резолюції замовлень з боку розв’язувача. OIF — це ширший інфраструктурний фреймворк, що охоплює походження інтенту, розв’язування, виконання, розрахунки, агрегацію та пов’язані компоненти. Наше останнє дослідження TokenToolHub детально аналізує поточний дизайн ERC-7683, його відмінності від попередніх чернеток, життєвий цикл замовлення, заповнювачi, безпеку резолвера, кроки виконання, платежi, припущення, взаємодействуючi адреси та ризики розв’язувача, якi залишаються поза межами самого стандарту. Повний аналiз: https://t.co/VK5Yb4wvJ3