EIP-5792 Wallet Call API: 배치·기능 탐색·원자성 이해하기

온체인 작업 하나를 끝내려고 지갑 승인창을 여러 번 누르다 보면 무엇을 승인했는지 놓치기 쉬워요. EIP-5792는 디앱(dApp)이 여러 호출을 순서대로 묶어 지갑에 한 번에 요청하도록 만든 인터페이스 표준입니다. 다만 화면이 짧아졌다고 자동으로 안전해지는 것은 아니에요. EIP-5792 Wallet Call API를 이해하는 일은 실용적인 크립토 지갑 보안의 일부입니다.

이 글에서는 최종 표준이 된 EIP-5792, wallet_sendCalls, 기능 탐색, 배치 상태 확인과 원자성(Atomicity)의 차이를 설명해요. 정보 제공 목적이며 투자 조언(NFA)이 아닙니다. 배치에는 되돌릴 수 없는 승인·전송·컨트랙트 호출이 들어갈 수 있으니 모든 행동을 확인하고, 잃어도 되는 금액만 사용하며 스스로 조사하세요(DYOR).

EIP-5792 Wallet Call API란 무엇인가요?

EIP-5792는 지갑용 JSON-RPC 메서드 네 가지를 정의한 최종(Final) 이더리움 인터페이스 표준이에요.

• wallet_sendCalls: 여러 온체인 쓰기 호출을 배치로 제출하도록 지갑에 요청해요.
• wallet_getCallsStatus: 제출한 배치의 상태와 관련 영수증(Receipt)을 조회해요.
• wallet_showCallsStatus: 알려진 배치 정보를 지갑 화면에 표시하도록 요청해요.
• wallet_getCapabilities: 특정 계정이 각 체인에서 지원하는 기능을 확인해요.

기존 eth_sendTransaction을 확장하기보다 현대적인 지갑과 디앱의 역할을 분리한 인터페이스입니다. 하나의 구현 방식만 강제하지 않아요. 일반 외부 소유 계정(EOA) 지갑은 비원자적 배치를 여러 트랜잭션으로 보낼 수 있고, 스마트 계정(Smart Account)은 여러 호출을 하나의 트랜잭션 안에서 실행할 수도 있어요.

택배 기사에게 여러 배송지가 적힌 운송장 한 장을 건넨다고 생각해 보세요. 배송 순서는 정해져 있지만 모든 배송이 반드시 하나의 쪼갤 수 없는 여정으로 끝난다는 뜻은 아니에요. 디앱이 필요한 보장을 요청하고 지갑이 그 보장을 지원해야 합니다.

wallet_sendCalls는 어떻게 작동하나요?

요청에는 버전, 체인 ID, 선택적인 발신 계정, atomicRequired 값과 순서가 있는 calls 배열이 들어가요. 각 호출에는 대상 주소(to), 호출 데이터(data), 네이티브 자산 금액(value)을 넣을 수 있습니다. 지갑은 지정된 체인에서 요청 순서대로 호출을 처리해야 해요.

{
  "version": "2.0.0",
  "from": "0xYourAccount",
  "chainId": "0x1",
  "atomicRequired": true,
  "calls": [
    { "to": "0xToken", "data": "0xApproveData" },
    { "to": "0xProtocol", "data": "0xDepositData" }
  ]
}

단순화한 예시는 토큰 승인 뒤 예치를 실행하는 흐름과 비슷해요. 실제 행동은 디앱이 붙인 설명이 아니라 16진수 호출 데이터가 결정합니다. 지갑이 디코딩(Decoding)과 시뮬레이션(Simulation)을 제공한다면 대상 컨트랙트, 금액, 승인받는 주소(Spender), 체인과 예상 잔액 변화를 전부 확인하세요.

사용자가 요청을 거절하면 지갑은 배치 안의 어떤 호출도 보내면 안 됩니다. 요청을 수락하면 wallet_sendCalls는 트랜잭션 해시가 아니라 배치 식별자(ID)를 반환해요. 하나의 배치가 하나 또는 여러 트랜잭션으로 구현될 수 있기 때문입니다.

지갑 기능은 체인별로 확인해야 해요

연결된 디앱은 배치를 요청하기 전에 승인된 주소와 체인 목록으로 wallet_getCapabilities를 호출할 수 있어요. 응답은 16진수 체인 ID별로 나뉩니다. 같은 계정도 이더리움 메인넷과 레이어 2(L2)에서 지원 기능이 다를 수 있기 때문이에요.

기본 atomic 기능에는 세 가지 상태가 있어요.

어떤 체인의 응답에 atomic 기능이 없다면, 다른 기능이 이 해석을 덮어쓰지 않는 한 EIP-5792 배치를 지원하지 않는다는 뜻이에요. 캐시된 정보와 현재 지갑 RPC 응답이 다르면 실시간 응답을 기준으로 삼아야 합니다.

기능(Capability)은 배치 요청을 확장하기도 해요. 예를 들어 ERC-7677은 호환 계정 추상화 지갑을 위한 paymasterService 기능을 정의합니다. 지갑이 지원하지 않는 기능은 디앱이 명시적으로 선택 사항(optional)으로 표시하지 않았다면 요청을 거절해야 해요. 선택 사항이라는 표시는 실패 시 대체 동작을 바꿀 뿐, 기능 자체의 안전성을 보증하지 않습니다.

원자적 배치와 비원자적 배치는 달라요

원자적 실행은 모든 호출이 함께 성공하거나 온체인에 실질적인 효과가 하나도 남지 않는다는 뜻이에요. 연속적 실행은 배치 사이에 무관한 트랜잭션이나 호출이 끼어들 수 없다는 의미입니다. atomicRequired: true이면 지갑은 두 조건을 모두 보장하거나 요청을 거절해야 해요.

atomicRequired: false이면 지갑은 원자성·연속성 보장 없이 호출을 순서대로 실행할 수 있어요. 지원한다면 원자적으로 처리해도 됩니다. 일반 EOA까지 포괄하는 유연한 설계지만, 앞 호출은 성공하고 뒤 호출은 실패할 수 있다는 중요한 위험이 생겨요.

첫 번째 트랜잭션에서 토큰을 승인하고 두 번째에서 스왑을 시도한다고 가정해 볼게요. 비원자적 실행에서 스왑이 실패하면 토큰 승인은 남을 수 있습니다. 가스비를 썼는데 원한 결과는 얻지 못하고, 승인 한도까지 활성 상태로 남는 셈이에요. 그래서 배치 상태, 각각의 영수증과 사후 토큰 승인 확인이 중요합니다.

EIP는 원자적 배치가 반드시 트랜잭션 하나로 포장된다고 가정하지 말라고도 경고해요. 원자성은 사용자가 관찰하는 실행 보장이지, 모든 체인과 계정에서 동일한 포장 형식을 뜻하지 않습니다.

제출한 배치 상태를 확인하는 법

wallet_sendCalls가 반환한 배치 ID를 wallet_getCallsStatus에 전달하면 돼요. 응답에는 숫자로 된 상태, 체인 ID, 명시적인 atomic 불리언(Boolean), 그리고 가능한 경우 해당 호출과 관련된 로그만 담긴 영수증이 포함됩니다.

원자적 실행은 호출이 체인에 포함된 방식에 따라 영수증 하나 또는 여러 개를 반환할 수 있어요. 비원자적 실행은 온체인에 포함된 트랜잭션의 영수증을 반환하며, 여기에는 되돌려진 호출도 포함될 수 있습니다. 표준은 제출 뒤 24시간 동안 지갑이 배치 상태 조회에 응답하도록 권고해요.

wallet_showCallsStatus는 목적이 달라요. 지갑 자체 화면에서 알려진 배치 정보를 보여 달라고 요청하며 성공 시 상태 객체를 반환하지 않습니다. 디앱은 프로그램 추적에는 wallet_getCallsStatus를 쓰고, 지갑 화면은 사용자가 직접 점검하는 창으로 다뤄야 해요.

보안과 개인정보 위험

배치는 승인 피로를 줄이지만 한 번의 확인창에 더 큰 권한을 모읍니다. 승인 전에 다음 위험을 확인하세요.

1. 중요한 호출 숨기기: 평범한 전송 옆에 무제한 승인이나 위임 행동이 섞일 수 있어요. 첫 줄만 보지 말고 전체 순서를 확인하세요.
2. 부분 실행: 비원자적 배치는 뒤 호출이 실패해도 앞의 승인·전송·상태 변경을 남길 수 있어요.
3. 오해를 부르는 표시: 사람이 읽는 설명은 지갑 디코딩에 의존해요. 디앱 요약만 믿지 말고 컨트랙트 주소와 시뮬레이션된 자산 변화를 확인하세요.
4. 기능 불일치: 지원 범위는 계정과 체인마다 달라요. 한 네트워크에서 본 기능을 다른 네트워크에도 있다고 가정하면 안 됩니다.
5. 상태 혼동: 배치 ID는 트랜잭션 해시가 아닐 수 있어요. 배치 상태와 생성된 모든 영수증을 추적하세요.
6. 지문 추적(Fingerprinting): 기능 질의는 지갑 소프트웨어 특징을 노출할 수 있어요. EIP는 과도한 기능 질의·공유를 피하라고 합니다.

클리어 서명 확인법과 함께 적용해 보세요. 보기 좋은 승인창도 알 수 없는 승인 대상, 과도한 한도, 악성 목적지를 안전하게 바꾸지는 못합니다.

승인 전 실전 체크리스트

EIP-5792 배치를 수락하기 전에 확인하세요.

• 활성 계정과 16진수 체인 ID가 의도와 일치하나요?
• 모든 대상 컨트랙트를 예상했고 별도로 검증했나요?
• 토큰 수량, 네이티브 자산 금액, 승인 대상과 한도가 제한되어 있나요?
• 원자적 실행이 필요한지, 지갑이 이를 지원하는지 표시되나요?
• 시뮬레이션에서 전체 잔액·승인 변화를 확인했나요?
• 페이마스터를 포함한 선택적 기능의 결과를 이해했나요?
• 배치 상태와 생성된 영수증을 확인할 방법을 알고 있나요?
• 비원자적 흐름이 실패해도 위험한 권한이 남지 않나요?

스마트 계정은 이런 흐름을 더 유연하게 만들 수 있어요. 계정 추상화 가이드는 계정 모델을 설명합니다. 이 클러스터의 ERC-4337 페이마스터 가이드에서는 누가 트랜잭션 비용을 부담할 수 있는지와 “가스리스”가 무비용·무위험을 뜻하지 않는 이유를 다뤄요.

FAQ

EIP-5792 배치는 항상 트랜잭션 하나인가요?

아니요. 인터페이스는 하나 또는 여러 트랜잭션을 표현할 수 있어요. 원자성은 atomicRequired와 지갑 기능으로 협의하는 실행 보장이지 트랜잭션 개수에 대한 약속이 아닙니다.

일반 EOA도 wallet_sendCalls를 쓸 수 있나요?

지갑이 메서드를 지원한다면 가능해요. 여러 호출을 원자적으로 처리할 계정 기능이 없고 원자적 실행도 요구하지 않았다면 지갑은 별도 트랜잭션으로 제출할 수 있습니다.

원자적 배치라면 토큰 승인도 안전한가요?

아니요. 원자성은 배치의 효과가 함께 남는지만 통제해요. 승인 대상, 금액, 컨트랙트나 디앱이 정당하다는 사실은 증명하지 않습니다.

지갑이 EIP-5792를 지원하지 않으면 어떻게 되나요?

지원하지 않는 메서드는 오류를 반환해야 해요. 디앱은 eth_sendTransaction을 여러 번 호출하는 방식으로 대체하거나 지원하지 않는 지갑이라고 안내할 수 있습니다. 대체 흐름은 원자성과 확인 방식이 달라질 수 있으니 명확하게 표시돼야 해요.

마무리

EIP-5792는 디앱과 지갑이 호출 배치, 기능 탐색과 상태 추적을 같은 언어로 다루게 해요. 핵심은 분명합니다. 배치와 원자성은 관련 있지만 같은 말이 아니에요. 전체 호출을 읽고, 체인별 실행 보장을 확인하고, 결과를 시뮬레이션한 뒤 최종 영수증까지 점검하세요.

이 글은 정보 제공 목적이며 투자 조언이 아닙니다. 온체인 행동은 되돌릴 수 없고 크립토 자산은 변동성이 큽니다. 잃어도 되는 금액만 사용하고 항상 스스로 조사하세요(DYOR).

출처

• EIP-5792: Wallet Call API
• EIP-1193: Ethereum Provider JavaScript API
• ERC-7677: Paymaster Web Service Capability
• ERC-4337: Account Abstraction Using Alt Mempool