성공적인 에이전트 트랜잭션도 권한 검사에서 실패할 수 있는 이유

AI 에이전트가 트랜잭션을 제출합니다. 이는 롤백 없이 실행되며, 대시보드에는 “Success”로 표시됩니다.

하지만 이 레이블은 중요한 질문에 대한 답을 남겨둡니다: 에이전트가 사용자가 승인한 호출을 실제로 실행했는가?

가상의 스왑(swap)을 고려해 봅시다. 사용자는 출력물을 지갑 A로 보내도록 하는 calldata를 승인합니다. 관찰된 트랜잭션은 동일한 체인, 실행기(executor), 그리고 nonce를 사용하지만, 출력물을 지갑 B로 지정하는 다른 calldata를 사용합니다.

이 경우 권한 비교가 실패하더라도 실행 자체는 완료될 수 있습니다.

트랜잭션 검토에는 세 가지 별도의 결과가 필요합니다:

• 증거 유효성(Evidence validity): 영수증(receipt), 서명(signatures), 해시(hashes) 및 지원되는 관계(supported relationships)가 검토자의 신뢰할 수 있는 구성 하에서 검증을 통과하는가?
• 실행 결과(Execution outcome): 증거는 어떤 실행 상태를 보고하는가?
• 권한 준수(Authorization compliance): 연관된 실행이 지원되는 검사 내의 서명된 권한과 일치하는가?

따라서 PriorSeal receipt v3에서 검증자 요약은 다음과 같을 수 있습니다:

{
  "valid": true,
  "code": "OK",
...
}

이것은 실제 트랜잭션 기록이 아닌 예시적인 결과입니다.

발급자(issuer)는 불일치에 대한 기록에 서명했습니다. 검증자는 관찰된 호출이 권한과 달랐음을 확인하면서도 해당 기록을 수락할 수 있습니다. calldata의 예에서, 영수증의 준수 이유에는 CALLDATA_MISMATCH가 포함됩니다.

영수증에 서명 후 수정하는 것은 다른 문제입니다: 그 무결성 검증이 실패할 것입니다.

이러한 결과들을 애플리케이션 내에서 분리하여 유지해야 합니다.

다음은 로컬 검증기(local verifier)를 사용한 간단한 통합 개요입니다:

import { verifyReceiptLocally } from 'priorseal-sdk/verifier';

const result = await verifyReceiptLocally(receipt, {
...

애플리케이션은 내보낸 receipt, 독립적으로 확인된 발급자 키, 그리고 예상되는 배포 대상(deployment audience)을 제공합니다. 가져온 번들에 포함된 키가 스스로의 신뢰성을 확립하는 것은 아닙니다.

SDK verifier 문서(https://github.com/imokokok/PriorSeal/blob/main/sdk/README.md)에는 지원되는 검사 항목들이 설명되어 있습니다. ERC-1271 권한 및 EVM 앵커 증거는 추가적인 체인 상태 검증을 요구할 수 있습니다. 로컬 verifier는 이러한 요구 사항들을 명시적으로 보고합니다.

“평가 불가(Not assessable)” 역시 인터페이스에서 별도의 위치를 차지해야 합니다.

증거 누락, 불충분한 최종성(finality), 리오거나이징(reorg), 또는 관련 없는 트랜잭션은 verifier가 권한 준수 여부를 평가하는 것을 막을 수 있습니다. 이러한 경우들은 NOT_ASSESSABLE로 유지되어야 합니다.

예상되는 체인, 실행자(executor), 그리고 논스(nonce)를 가지고 있지만 calldata가 변경된 것이 확인된 트랜잭션은 다른 결과를 제공합니다: 귀속 가능한 불일치(attributable mismatch)입니다.

이러한 구분들은 또한 권한 검토와 시장 위험 평가가 여전히 분리되어 있는 이유도 설명해 줍니다. 승인된 거래라 할지라도 경제적으로 나쁜 결과를 초래할 수 있습니다. Insight는 오라클 및 위험 평가를 제공하고; PriorSeal은 권한 및 실행 증거를 제공합니다. 이들의 결합 워크플로우는 두 범위 모두를 보존합니다.

영수증(receipt)은 검토 가능한 증거들을 기록합니다. 승인되지 않은 트랜잭션을 방지하는 것 또한 서명 및 제출 경로가 권한 검사를 강제해야 함을 의미합니다.

만약 귀하의 애플리케이션이 현재 하나의 “성공” 배지를 표시한다면, 실행은 완료되었지만 권한 비교에 실패했을 때 사용자는 무엇을 보게 될까요?