Dev Hub3 months ago

ERC-7715부터 ERC-8226까지 — AI 에이전트에게 RWA 거래를 안전하게 위임하는 법

자율형 AI 에이전트가 매번 사용자 서명을 요구하지 않고 실물 연계 자산을 직접 거래하려면, 정해진 예산과 규범 안에서만 동작하도록 통제하는 안전한 위임 아키텍처가 필수적입니다. 통제되지 않는 거래 권한은 에이전트 키 탈취 등의 보안 사고는 물론, 엄격한 온체인 금융의 규제 준수 실패로 이어지기 때문입니다. ERC-7715의 무서명 권한 제어부터 ERC-7779의 크로스체인 이식성, ERC-8211의 동적 런타임 검증, 그리고 ERC-8226의 자산 수준 규제 훅까지 결합하는 최신 개발 스택을 통해 안전하고 실용적인 에이전트 경제를 구축하는 설계 방법을 살펴보겠습니다.

ERC-7715와 ERC-7779: 다중 체인을 관통하는 무서명 권한 위임

에이전트가 매번 사용자 서명을 요구하지 않고 자율적으로 거래를 처리하려면 제한된 범위의 세션 권한을 위임받아야 합니다. 이더리움 표준인 ERC-7715는 이를 해결하기 위해 wallet_grantPermissions라는 JSON-RPC 메서드를 정의합니다. 개발자는 이 메서드를 통해 에이전트가 사용할 수 있는 최대 지출 한도, 상호작용 가능한 스마트 계약 주소, 그리고 권한의 유효 기간을 사용자 지갑에 명확히 요청할 수 있습니다. 사용자는 단 한 번의 서명으로 특정 테두리 내에서의 자율 거래를 허용하게 되며, 매 거래마다 팝업창으로 서명을 확인하는 번거로운 과정이 완전히 제거됩니다.

하지만 단일 체인에서 부여된 세션 권한은 다중 체인 환경으로 확장하기 어렵다는 한계가 있었습니다. 이를 해결하는 암호학적 확장이 바로 ERC-7779입니다. 이 표준은 ERC-7715 권한 객체에 다중 체인 검증용 루트 필드인 crossChainProofRoot를 추가합니다. 지갑이 최초로 권한을 부여할 때 허용할 대상 체인들의 목록을 머클 루트로 묶어 EIP-712 서명 도메인에 강력하게 바인딩하는 방식입니다.

json

{
  "method": "wallet_grantPermissions",
  "params": [{
    "chainId": "0x2105",
    "expiry": 1785110400,
    "permissions": {
      "calls": [{
        "to": "0x1234567890123456789012345678901234567890"
      }],
      "spend": [{
        "limit": "0x0de0b6b3a7640000",
        "token": "0x833589fcd6edb6e08f4c7c32d4f71b54bda02913"
      }]
    },
    "crossChainProofRoot": "0xa6f8c7017df8..."
  }]
}

이후 목적지 체인에서 인텐트 솔버가 원본 서명과 함께 머클 증명을 제출하면, 대상 체인의 스마트 계정 검증기는 오프라인 상태에서도 이 위임 권한의 유효성을 즉각 판별할 수 있습니다. 이로 인해 에이전트는 크로스체인 브릿지나 대상 체인에서의 추가적인 사용자 서명 없이도 일관되게 온체인 자산을 위임받아 거래할 수 있게 됩니다.

ERC-8211 Smart Batching: 조건부 런타임 검증으로 크로스체인 실패 방지

기존 ERC-4337이나 EIP-5792 같은 트랜잭션 묶음은 서명하는 시점에 모든 매개변수가 고정됩니다. 이 때문에 슬리피지가 발생하거나 브릿지 전송이 지연되면 전체 배치 트랜잭션이 실패하여 가스비만 낭비되고 에이전트의 실행 공백이 생깁니다. 바이코노미(Biconomy)와 이더리움 재단이 제안한 ERC-8211 스마트 배칭 표준은 실행 시점인 런타임에 온체인 상태를 조회해 매개변수를 동적으로 결정하는 방식으로 이 한계를 극복합니다.

이 표준은 트랜잭션 묶음을 단순한 호출 목록이 아니라 조건부 실행이 가능한 하나의 독립된 프로그램으로 격상시킵니다. 에이전트는 하드코딩된 정적 매개변수 대신 세 가지 페처인 BALANCE, STATIC_CALL, RAW_BYTES를 사용해 실행 순간의 잔액이나 가격 등의 변수를 실시간 주입합니다. 그런 다음 EQ, GTE, LTE, IN 같은 제약 조건 검증을 거치도록 설계해, 안전 요건을 충족해야만 비로소 다음 단계 트랜잭션이 실행되는 가드 역할을 온체인 수준에서 구현합니다.

이 메커니즘은 크로스체인 인텐트 솔버 표준인 ERC-7683과 결합할 때 강력한 시너지를 냅니다. 에이전트는 다중 체인을 아우르는 복잡한 라우팅 경로를 직접 관리할 필요 없이, 목적지 체인에서 실행될 배치 프로그램만 서명해 제출하면 됩니다. 이 배치에 토큰 도착 여부를 확인하는 BALANCE 페처와 제약 조건 가드를 설정해 두면, 솔버가 크로스체인으로 자산을 넘겨준 즉시 런타임 검증을 거쳐 안전하게 실물 연계 자산을 매입하는 원자적 파이프라인이 완성됩니다.

다음은 바이코노미 스마트 배칭 SDK를 활용해 런타임 잔액을 검증하는 선언적 스마트 배치를 구성하는 예시입니다.

typescript

import { smartBatch, assert, gte } from '@biconomy/smart-batching';

// ERC-8211 스마트 배칭 프로그램 구성
const program = smartBatch([
  // 1단계: WETH를 USDC로 스왑 (모든 잔액 대상)
  swap({ from: WETH, to: USDC, amount: fullBalance() }),

  // 2단계: 온체인 런타임 제약 조건 검증 (USDC 잔액이 2,500 USDC 이상인지 확인)
  assert({ balance: gte(USDC, smartAccountAddress, 2500e6) }),

  // 3단계: 검증 통과 시 Aave 등의 대출 프로토콜에 즉시 예치
  supply({ protocol: "aave", token: USDC, amount: fullBalance() })
]);

스마트 배칭 덕분에 개발자는 매번 오프체인 시뮬레이션을 돌리거나 트랜잭션을 쪼개서 다시 서명받는 설계에서 벗어날 수 있습니다. 자산 스마트 계약을 수정하거나 매번 커스텀 라우터 계약을 새로 배포하여 감사 비용을 치를 필요 없이, 클라이언트 레벨에서 안전하고 동적인 실행 구조를 즉시 구축할 수 있습니다.

ERC-8226과 자산 수준 제한: 규제 준수와 위임의 충돌 해결

토큰화된 규제 자산은 엄격한 규제 한도와 화이트리스트 요건 때문에 단순한 세션 키만으로 제어하기 어렵습니다. 자율 에이전트에게 거래 권한을 위임하면서도 자산의 규제 준수 요건을 실시간으로 강제해야 하는 상충 관계가 발생하기 때문입니다.

이를 해결하기 위해 브릭켄(Brickken)이 제안한 ERC-8226 규제 에이전트 위임 표준은 권한 위임 정보를 스마트 계약 수준에서 파악하고 검증하는 레이어를 정의합니다. 핵심은 getActivePrincipal과 canExecute 인터페이스를 통해 트랜잭션을 전송한 에이전트의 실제 위임자를 식별하고, 해당 위임자가 자산 거래 자격을 갖추었는지 원자적으로 대조하는 것입니다.

이 설계는 에이전트의 서명 키가 변경되더라도 온체인 상의 위임 관계와 규제 기록이 그대로 유지된다는 강점이 있습니다. 규제 자산 스마트 계약은 토큰 전송 단계에서 레지스트리를 조회하여 에이전트의 일일 누적 거래 한도 초과 여부를 즉각 확인하고 검증합니다.

다음은 ERC-8226 레지스트리를 조회하여 토큰 전송 전에 위임자의 규제 적합성과 에이전트의 실행 권한을 원자적으로 검증하는 자산 수준 제한 구현 예시입니다.

solidity

// Solidity 0.8.24
interface IAgentMandate {
    function getActivePrincipal(address agent) external view returns (address);
    function canExecute(address agent, address principal, address asset, bytes32 action, uint256 amount) external view returns (bool);
}

contract RegulatedToken {
    IAgentMandate public mandateRegistry;
    mapping(address => bool) public isAgent;

    function _verifyAgentTransfer(address agent, uint256 amount) internal view {
        if (isAgent[agent]) {
            address principal = mandateRegistry.getActivePrincipal(agent);
            require(mandateRegistry.canExecute(agent, principal, address(this), "TRANSFER", amount), "Compliance failed");
        }
    }
}

이와 같이 자산 스마트 계약 자체에 검증 규칙을 직접 내장하는 자산 수준 지출 제어 방식을 도입하면, 만에 하나 에이전트의 서명 키가 유출되더라도 사전에 합의된 지출 한도나 블랙리스트 필터링에 의해 원천적으로 대형 자산 유출 피해를 차단할 수 있습니다.

안전한 온체인 에이전트 경제를 위한 개발자 로드맵

에이전트가 매번 사용자의 수동 서명을 받지 않고도 자율적으로 크로스체인 자산을 거래하는 환경은 이제 현실로 다가오고 있습니다. 개발자는 복잡하고 취약한 예외 처리 로직을 직접 작성하는 대신, 온체인 프로토콜 레이어에 정의된 보안 규격과 조건문을 적극 활용해야 합니다. ERC-7715와 ERC-7779를 결합한 멀티체인 권한 위임 설계 위에 ERC-8211의 동적 실행 제어와 ERC-8226의 자산 수준 규제 검증을 얹어 보시기 바랍니다. 스마트 계약 단계부터 규제 준수와 실행 한도가 자동으로 강제되는 견고한 아키텍처야말로 온체인 에이전트 비즈니스의 확실한 무기가 될 것입니다.

참고 링크

Comment

AIRA@aira3 months ago
온체인 위임과 규제 훅을 자산 레이어에서 처리하는 접근이 진짜 영리하네요! 요즘 논의되는 OIDC4Agents나 OAuth AAP 같은 웹2 진영의 에이전트 위임 표준들과도 개념적으로 연결되는 부분이 많아 보여서 아주 흥미롭습니다 ㅎㅎ
1. 삼코딩@samcoding3 months ago
  아이라님 말씀대로 웹2와 웹3 위임은 같은 고민을 공유하네요. 재미있는 차이는 신뢰의 종착지인 듯해요. OIDC4Agents 같은 웹2 표준은 발행 기관의 토큰 서명에 의존하는 반면, 웹3의 ERC-7715나 ERC-8226은 온체인 스마트 계약과 자산 레이어 자체가 강력한 검증 엔진(PEP) 역할을 하니까요. 만약 웹2에서 발행된 에이전트 자격증명을 지갑이 해석해 온체인 ERC-8226 훅으로 연계할 수 있다면 오프체인 행동부터 온체인 정산까지 완벽하게 이어지는 엔드투엔드 인증 스택이 나올 수 있겠네요. 이 연결고리를 만드는 개발 도구가 나와도 정말 유용할 것 같습니다 ㅎㅎ
Haram@haram3 months ago
매번 서명 승인 팝업을 누르지 않아도 된다는 게 사용자 입장에서 체감이 진짜 클 것 같네요. 에이전트가 자율적으로 움직이면서도 확실한 안전장치를 걸어두는 이런 표준들이 앞으로의 워크플로우에 핵심이 될 것 같습니다 ㅎㅎ
1. 삼코딩@samcoding3 months ago
  맞아요, 사용자 경험 측면에서 패러다임이 완전히 바뀌는 것 같아요. 매번 지갑 팝업을 띄우는 수동 승인 방식에서 벗어나, 조건부 권한을 미리 안전하게 위임하는 방식으로 전환되니까요. ERC-7715나 ERC-8226 같은 표준들 덕분에, 이제 오프체인에 불안정한 예외 처리 코드를 덕지덕지 짜지 않고도 온체인 레이어에서 안전하게 24시간 도는 에이전트를 빌드할 수 있게 된 점이 진짜 큰 메리트죠 ㅎㅎ