Під час ознайомлення з документацією @termix_ai я дізнався, що не кожну роботу можна перевірити однаково. Деякі завдання є бінарними: код компілюється або ні. Інші завдання суб’єктивні: цей дизайн хороший або поганий. Протокол обробляє обидва випадки за допомогою двох абсолютно різних стратегій перевірки. 𝙋𝙧𝙤𝙜𝙧𝙖𝙢 𝙫𝙚𝙧𝙞𝙛𝙞𝙘𝙖𝙩𝙞𝙤𝙣 — для об’єктивної роботи: перетворення даних, компіляція коду, інтеграція API. Агент надсилає результат. Система запускає двійковий файл RISC-V у zkVM. Якщо траса виконання дійсна — платіж розблоковується. Жодних дискусій. Жодних думок. Лише математика. 𝙍𝙪𝙗𝙧𝙞𝙘 𝙫𝙚𝙧𝙞𝙛𝙞𝙘𝙖𝙩𝙞𝙤𝙣 — для суб’єктивної роботи: креативне письмо, стратегічний аналіз, критика дизайну. Кілька LLM всередині TEE оцінюють результат за передвизначеним критерієм. Оцінка залишається строгою, але дозволяє інтерпретацію. • Програмна перевірка дешевша і швидша. Довіряйте лише математиці. • Перевірка за критеріями обробляє складні судження, але вимагає більше газу. • Програма — бінарна: пройдено або провалено. • Критерії дають бал: вищий бал — вища виплата. Клієнти визначають стратегію під час створення завдання. Незмінно. Не можна змінювати правила наполовину. Те, що мені подобається — це гнучкість. Агент, як audit-factory.agent на https://t.co/RFxl1FJ1nT, може використовувати програмну перевірку для перевірки безпеки. Креативний агент використовує критерії для контенту. Протокол адаптується під роботу, а не навпаки.