Back
메타 트랜잭션
메타 트랜잭션

메타 트랜잭션

Date
Nov 18, 2025
Published
Published
1. 메타 트랜잭션의 기본 개념 및 구조1-1. 메타 트랜잭션(Meta Transaction)1-2. Relayer1-3. 유의점2. 관련 표준 분석2-0. 요약2-1. EIP-17762-2. EIP-26122-3. EIP-27712-4. EIP-30092-5. EIP-43373. 완전한 가스비 대납 구현3-1. EIP-27713-2. EIP-4337

1. 메타 트랜잭션의 기본 개념 및 구조

1-1. 메타 트랜잭션(Meta Transaction)

사용자가 가스비를 직접 지불하지 않고도 블록체인 상에서 트랜잭션을 실행할 수 있도록 하는 개념이다.
  • 작동 방식
      1. 사용자의 서명을 제 3자에게 전달
      1. 제 3자는 자신의 가스비를 사용하여 블록체인에 트랜잭션을 실행
 

1-2. Relayer

제 3자로써 가스비를 대납하고 실제 트랜잭션을 블록체인에 전송하는 주체이다.
  • 필수적
    • 온체인에서의 모든 트랜잭션은 가스비를 지불해야 하며, 이 가스비는 트랜잭션을 실행하는 주체로부터 지불된다. 따라서 사용자의 가스비 지불을 없애기 위해서는 Relayer가 사용자의 서명을 오프체인으로 받아서 온체인에 대신 제출해야하므로 메타트랜잭션의 구현을 위해 Relayer는 필수적이다.
  • 구조
    • EOA → Relayer → dApp
 

1-3. 유의점

  • msg.sender와 실사용자의 불일치
    • dApp 컨트랙트에서 msg.sender를 호출하게되면 실사용자가 아닌 Relayer의 주소가 반환된다.
    • 핵심 기능들에서 사용자의 주소를 알기 위한 로직 추가가 불가피하다.
  • Relayer의 신뢰성
    • 서명을 위변조하지 않을 신뢰할 수 있는 Relayer가 필요하다.
 
 

2. 관련 표준 분석

2-0. 요약

EIP
목적
주요 특징
가스비 대납 범위
단점
EIP-1776
Native Meta Transaction
1. Forwarder 컨트랙트 사용 2. 범용 메타 트랜잭션 구현
완전한 가스비 대납 가능
1. dApp 컨트랙트 수정 필요 (_msgSender 사용) 2. Relayer 운영 및 비용 관리 필요
EIP-2612
approve를 오프체인 서명으로 대체
1. permit 함수 표준 2. wrapper 함수 별도 구현 필요 3. ecrecover로 검증
부분적 Gasless (approve 단계만)
1. dApp 컨트랙트에 wrapper 함수 추가 개발 필요 2. approve만 대체 가능
EIP-2771
Meta Transaction 구조의 실사용자 주소 확인 표준
1. msg.data 맨 뒤 20byte에 실사용자 주소 2. OpenZeppelin 채택 3. EIP-1776 인프라 활용
완전한 가스비 대납 가능
1776과 동일
EIP-3009
transfer를 오프체인 서명으로 대체
1. transferWithAuthorization 구현 2. allowance 불필요 3. 토큰 전송에 한정
부분적 Gasless (transfer만)
1. 토큰 전송에만 한정
EIP-4337
Account Abstraction 표준
1. UserOperation, WalletContract, Bundler, Paymaster 2. 다양한 서명방식 지원 가능, Web2 유저 친화적 3. 기존 dApp 호환
완전한 가스비 대납 가능
1. 인프라 구축 필요 (Bundler, Paymaster) 2. 사용자 온보딩 필요 (WalletContract 생성) 3. 외부 서비스 의존 가능성

2-1. EIP-1776

  • 모든 트랜잭션을 대신 실행하는 중계 컨트랙트(Forwarder) 인프라에 대한 표준
  • 구조
    • EOA → Relayer → Forwarder → dApp
  • 동작 방식
      1. "dApp 컨트랙트의 swap을 호출하겠다"에 대한 payload와 vrs 생성, Relayer에게 전달
      1. Relayer는 해당 데이터를 가지고 Forwarder의 excute를 실행
      1. Forwarder는 ecrecover로 vrs를 검증하여 서명자가 payload와 일치하는지 확인
      1. payload에서 실행할 함수(swap)를 확인하고 DApp의 swap을 호출
  • 특징
    • 구조 내 Forwarder라는 개념이 추가되어 Relayer 신뢰성 문제를 해결했다.
      • Forwarder가 서명을 검증함으로써 Relayer가 임의의 트랜잭션을 대신 실행하는 것을 막는다.
    • EIP-4337의 근간이 되는 구조이다.
 

2-2. EIP-2612

  • ERC-20의 approve 를 오프체인 서명으로 대체하는 permit 함수에 대한 표준
  • 동작 방식
      1. vrs 생성(EIP-712)
      1. dApp 컨트랙트에 있는 transferWithPermit (permit을 위한 wrapper함수) 호출
        1. 토큰 컨트랙트의 permit 호출
          1. ecrecover로 vrs 검증
          2. 검증 실패 시 revert
        2. 토큰 컨트랙트의 transferFrom 실행
  • 특징
    • dApp 컨트랙트의 추가 개발
      • permit이 동작할 수 있는 wrapper함수의 별도 구현이 필요하다.
    • 부분적인 Gasless
      • approve 단계를 오프체인 서명으로 대체하여, 사용자는 가스비가 발생하는 approve 트랜잭션을 생략할 수 있다.
      • Relayer가 이 서명을 제출하며 가스비를 대납할 수도 있다.
 

2-3. EIP-2771

  • EIP-1776 인프라를 채택한 dApp이 msg.sender를 Forwarder가 아닌 실사용자로 확인하기 위한 방법에 대한 표준
    • Relayer가 Forwarder에게 트랜잭션을 전달할 때 msg.data의 맨 뒤 20byte는 실사용자의 주소를 붙이기로 약속한다.
  • 동작 방식
      • notion image
    • EIP-1776과 동일 흐름 유지
    • dApp 컨트랙트 (ERC2771Context 상속받아 _msgSender 사용)
        1. msg.sender == Forwarder 확인
        1. 해당 경우 msg.sender가 아니라 msg.data의 맨 뒤 20자리를 확인해서 실사용자를 인식
  • 특징
    • OZ에서 채택
      • OpenZeppelin에서 채택하여 널리 사용되고 안정적인 범용 메타 트랜잭션 표준이다.
      • EIP-1776 인프라를 사용하면서도 dApp 컨트랙트가 msg.data 확인을 통해 실사용자 주소를 간편하게 복구한다.

2-4. EIP-3009

  • ERC-20 토큰의 transfer 기능을 오프체인 서명으로 대체하는 표준
  • 동작 방식
      1. 토큰 컨트랙트 내에 transferWithAuthorization을 구현
      1. 토큰 컨트랙트는 vrs로 사용자를 검증하고 _transfer로 전송
          • _transfer는 msg.sender를 사용하지 않기 떄문에 allowance가 필요없다.
  • 특징
    • 토큰 전송에 한정하여 별도의 approve  없이 서명 하나로 바로 전송할 수 있다.
      • transferWithAuthorization 트랜잭션에 대한 가스비만 Relayer가 부담한다.

2-5. EIP-4337

  • evm의 계정 모델 자체를 변경(AccountAbstraction)하고 AA 사용 전반에 관한 표준
  • 구조
    • UserOpertaion: 사용자의 의도가 담긴 객체
      • sender, callData, signature, paymasterAndData 등
          • notion image
    • WalletContract: 사용자 지갑역할을 하는 컨트랙트. 기존의 EOA를 대체
      • validateUserOP, excute
    • Bundler: UserOperation를 멤풀에서 확인하고 EntryPoint로 트랜잭션 실행
      • Relayer의 역할
      • 가스비를 선불로 대납
    • EntryPoint: Bundler가 실행한 트랜잭션을 WC와 paymaster에게 확인하고 Bundler에게 가스비를 정산
        • notion image
      • 공용컨트랙트
    • Paymaster: dApp에서 부담할 대납용 가스비를 지불하는 역할
      • 대납 정책에 따른 선택사항
  • 동작 방식
    • dApp 프론트에서 UserOpertaion을 생성 후 사용자가 서명
    • 멤풀로 전달
    • Bundler가 OP확인 후 자신의 네이티브 토큰으로 EntryPoint의 handleOps 트랜잭션 실행
      • EntryPoint의 handleOps는
          1. WC.validateOP를 호출하고 서명 검증
          1. Paymaster.validatePaymasterUserOp를 호출하고 대납여부 검증
          1. 전달받은 UserOpertaion을 포함시켜 WC.excute 호출
      • WC.excute는
          1. OP의 callData 확인해서 실행할 함수와 기타정보 확인
          1. DApp.함수 호출
              • 이 때 DApp에서는 msg.sender를 그대로 확인할 수 있어 기존의 DApp들도 인프라 내에서 동작 가능
      • success / revert에 상관없이 사용된 가스비를 Paymaster의 자금에서 Bundler에게 정산
  • 특징
    • EIP-2771의 _msgSender를 사용하지 않으므로 dApp에 추가로 구현할게 없다.
    • EIP-2612, 3009처럼 토큰 컨트랙트 내에서 적용되어야하는 함수들이 없다.
    • WC.validateUserOP를 커스텀하여 EIP-712, multisig, Passkey 등 다양한 서명방식을 사용할 수 있다.
      • 이는 web2 유저들의 진입에 굉장히 큰 도움이 될 것이라 생각한다.

3. 완전한 가스비 대납 구현

모든 트랜잭션에 대하여 완전한 가스비 대납을 위해서는 토큰 컨트랙트 레벨이 아닌 인프라 레벨에서의 서포트가 필요하다.

3-1. EIP-2771

기존 EOA 모델을 유지하면서 모든 트랜잭션에 가스비 대납을 적용할 수 있다.
  • Relayer 운영 및 관리가 필요하다.
    • 인프라 구축
      • 사용자의 서명을 받아 온체인에 제출할 Relayer 서버를 구축하고 무중단으로 운영해야 한다.
    • 비용 관리
      • Relayer의 지갑에 가스비로 사용될 네이티브 토큰을 충전하며 관리해야 한다.
    • 보안
      • Relayer가 해킹당하지 않도록 보안에 유의해야 한다.
  • dApp 개발에 추가 리소스가 발생한다.
    • 컨트랙트 수정
      • 가스비 대납을 제공할 dApp 컨트랙트는 msg.sender 대신 _msgSender()를 사용하여 실사용자의 주소를 확인하도록 개발해야 한다.

3-2. EIP-4337

계정 추상화를 통해 가스비 대납뿐만 아니라 UX 최적화 등 다양한 이점을 적용할 수 있다.
  • dApp 혹은 컨트랙트 개발에 유리하다.
    • WalletContract가 UserOperation을 실행하며, dApp은 msg.sender를 실사용자로 인식할 수 있으므로 기존의 dApp에서도 사용할 수 있다.
    • KGLD 토큰 컨트랙트 자체에도 별도의 함수(transferWithAuthorization 등)를 추가할 필요가 없다.
  • AA적용과 인프라가 필요하다.
    • Bundler 및 Paymaster를 구축하거나, 외부 서비스(Alchemy 등)에 의존해야 한다.
    • AA 적용을 위해 사용자들에게 WalletContract를 생성하고 사용하도록 온보딩해야 한다.