EIP-3074 vs EIP-7702 vs ERC-4337: 개발자를 위한 완벽 가이드

2025년 5월 14일에 게시됨4분 읽기

Ethereum의 지갑 생태계는 계속 진화하고 있으며, EIP-7702를 완전한 계정 추상화(ERC-4337)를 향한 핵심 단계로 삼아 프로그래밍 가능한 미래를 향해 나아가고 있습니다. 하지만 7702가 왜 smart wallets를 통해 우리가 Ethereum과 상호작용하는 방식을 재편할 준비가 되어 있는지 이해하려면, 7702가 지금의 모습을 갖추는 데 중요한 토대를 마련한 제안인 EIP-3074를 먼저 살펴봐야 합니다.

앱을 만드는 개발자라면 Externally Owned Accounts(EOAs) - 개인키로 제어되는 Ethereum의 전통적인 지갑 - 의 한계를 겪어봤을 것입니다. EIP-3074는 EOA가 스마트 컨트랙트(invoker)에 제어를 위임할 수 있는 방법을 도입하여 가스 스폰서십과 배치 트랜잭션 같은 기능을 가능하게 했습니다. EIP-7702는 여기서 한 걸음 더 나아가, 계정 추상화로 가는 더 매끄럽고 안전한 경로를 제공합니다.

개발자에게 이 개념은 사용자를 익숙한 EOA에 머물게 하면서 앱에 고급 기능을 추가하는 과정을 단순화합니다. 사용자에게는 더 매끄러운 경험을 의미합니다. 예를 들어 제3자가 가스를 대신 지불하거나, 한 번의 클릭으로 여러 DeFi 거래를 실행하는 것을 생각해보세요.

이 가이드에서는 맥락을 위해 3074의 메커니즘을 풀어보고, 코드로 7702의 발전을 보여주며, 둘을 ERC-4337과 비교합니다. 시작해봅시다.

EIP-3074가 해결하고자 한 문제

EOA는 단순합니다: 개인키로 트랜잭션에 서명하고 이를 Ethereum 네트워크로 전송합니다. 하지만 한계가 있습니다. 코드를 실행할 수 없고, 액션을 배치 처리할 수 없으며, 네이티브하게 분실된 키를 복구할 수 없습니다. 스마트 컨트랙트 지갑(ERC-4337로 구현)은 더 많은 유연성을 제공하지만, 사용자가 새 주소를 관리해야 하고 종종 더 높은 가스 비용이 발생합니다. EIP-3074는 두 개의 EVM 옵코드인 AUTH과 AUTHCALL을 도입하여 EOA가 invoker 컨트랙트에 제어를 위임할 수 있게 함으로써 지갑 마이그레이션 없이 스마트 컨트랙트와 유사한 기능을 추가하는 해결책을 제안했습니다.

EIP-3074는 Ethereum의 계정 추상화 로드맵을 형성한 개념 증명이었습니다: EOA에서 Smart EOA(EIP-7702)를 거쳐 궁극적으로 완전한 Smart Wallets(ERC-4337)로 이어지는 로드맵입니다. 3074의 메커니즘을 살펴보며 이것이 어떻게 길을 닦았는지 이해해봅시다.

스마트 지갑으로 매끄러운 온체인 UX를 제공해 앱을 성장시키세요.

기능 살펴보기

EIP-3074의 핵심 구성 요소: 7702의 토대

EIP-3074는 세 가지 요소로 구성됩니다: AUTH 옵코드, AUTHCALL 옵코드, 그리고 invoker 컨트랙트입니다. 7702가 이들의 원리 위에 구축되었기 때문에 이해할 가치가 있습니다.

1. `auth` 옵코드

AUTH 옵코드(hex 0xf6)는 EOA로부터의 ECDSA 서명을 검증하여, 특정 invoker가 해당 EOA를 대신해 행동할 권한을 부여받았음을 증명합니다. EOA는 invoker의 주소와 커밋먼트(수행할 액션들의 해시)를 포함한 메시지에 서명합니다. 서명이 유효하면 EVM은 인증된 컨텍스트를 설정합니다.

AUTH의 서명 검증을 모방한 Solidity 스니펫입니다:

solidityCopied
*// Invoker contract: Verify EOA authorization*
function authenticate(bytes memory signature, address eoa, bytes32 commitment) public pure returns (bool) {
  *// Hash the message the EOA signed*
  bytes32 messageHash = keccak256(abi.encodePacked(eoa, commitment));
  *// Recover the signer from the signature*
  address signer = recoverSigner(messageHash, signature);
  *// Check if the signer matches the EOA*
  return signer == eoa;
}

_// Helper function to recover signer_
function recoverSigner(bytes32 messageHash, bytes memory signature) internal pure returns (address) {
bytes32 r; bytes32 s; uint8 v;
assembly {
r := mload(add(signature, 32))
s := mload(add(signature, 64))
v := byte(0, mload(add(signature, 96)))
}
return ecrecover(messageHash, v, r, s);
}

이 코드는 제어를 위임하려는 EOA의 의도를 검증합니다. 인증이 완료되면 invoker는 EOA로서 행동할 수 있습니다.

2. `authcall` 옵코드

AUTHCALL(hex 0xf7)은 invoker가 EOA의 주소를 호출자로 사용하면서 트랜잭션을 EOA로서 실행할 수 있게 하며, 이때 invoker가 가스를 지불할 수 있습니다. 이것이 3074에서 가스 스폰서십과 배치 처리를 가능하게 했습니다.

어셈블리에서 AUTHCALL을 사용하는 방법은 다음과 같습니다:

solidityCopied
// Invoker contract: Execute a call as the EOA
function executeAsEOA(address target, bytes memory data) public {
  // Assumes prior AUTH verification
  assembly {
      // AUTHCALL: gas, target, value, argsOffset, argsSize, retOffset, retSize
      let success := authcall(gas(), target, 0, add(data, 32), mload(data), 0, 0)
      if iszero(success) {
          revert(0, 0)
      }
  }
}

이 스니펫은 대상 컨트랙트(예: DeFi 프로토콜)를 EOA로서 호출합니다. gas\(\) 함수는 남은 가스를 할당하고, AUTHCALL는 해당 액션이 EOA의 신원을 반영하도록 보장합니다.

3. Invoker 컨트랙트

Invoker는 EOA가 위임하는 스마트 컨트랙트입니다. EIP-3074의 invoker는 영구적이었으며, 이는 7702가 다루는 보안 우려를 야기했습니다. 다음은 가스 스폰서십과 배치 처리를 위한 3074 스타일 invoker입니다:

⚠️ 보안 참고사항: Invoker는 반드시 감사를 거치고 신중하게 구성되어야 합니다. 결함이 있는 invoker는 서명을 오용하거나 액션을 재실행할 수 있습니다.

jsxCopied
// EIP-3074 invoker for gas sponsorship and batching
contract LegacyInvoker {
  address public authorizedEOA;

  // Set authorized EOA
  function setAuthorizedEOA(address eoa, bytes memory signature, bytes32 commitment) external {
      require(authenticate(signature, eoa, commitment), "Invalid signature");
      authorizedEOA = eoa;
  }

  // Execute batch transactions, optionally sponsored
  function executeBatch(
      address[] memory targets,
      bytes[] memory datas,
      uint256[] memory values,
      bool sponsored
  ) external payable {
      require(msg.sender == authorizedEOA || sponsored, "Not authorized");
      if (sponsored) {
          require(msg.value >= estimateGas(targets, datas), "Insufficient gas funds");
      }
      for (uint i = 0; i < targets.length; i++) {
          assembly {
              let success := authcall(
                  gas(),
                  mload(add(targets, add(32, mul(i, 32)))),
                  mload(add(values, add(32, mul(i, 32)))),
                  add(mload(add(datas, add(32, mul(i, 32)))), 32),
                  mload(mload(add(datas, add(32, mul(i, 32))))),
                  0,
                  0
              )
              if iszero(success) { revert(0, 0) }
          }
      }
  }

  // Estimate gas for sponsored transactions
  function estimateGas(address[] memory targets, bytes[] memory datas) internal view returns (uint256) {
      uint256 totalGas = 21000; // Base transaction gas
      for (uint i = 0; i < targets.length; i++) {
          totalGas += 10000; // Approximate per call
      }
      return totalGas;
  }

}

💡 구현 팁: EIP-3074 invoker는 서명 재사용을 방지하기 위해 감사가 필요했습니다. EIP-7702는 영구적인 invoker를 피함으로써 위험을 줄입니다.

EIP-3074 vs. EIP-7702: 7702가 우위인 이유

EIP-3074는 대담한 실험이었지만, EIP-7702와 ERC-4337이 미래입니다. 간단히 비교해보겠습니다:

EIP-3074 vs. ERC-4337

EIP-3074: EVM에 AUTH과 AUTHCALL를 추가했고, EOA와 함께 작동했지만 invoker가 필요했습니다.
ERC-4337: 프로토콜 변경이 없으며, 스마트 컨트랙트 지갑을 위해 별도의 mempool과 bundler를 사용합니다.
요약: 3074는 EOA에는 더 단순했지만, 4337의 유연성이 완전한 추상화에 더 이상적입니다.

EIP-3074 vs. EIP-7702

EIP-3074: 영구적인 invoker가 보안 위험을 야기했고 미래 호환성이 부족했습니다.
EIP-7702: 트랜잭션별 스마트 컨트랙트 기능을 가능하게 하여 4337과 정렬됩니다.
요약: 7702는 3074의 아이디어를 다듬어 더 안전하고 확장 가능한 경로를 제공하며 Ethereum AA 로드맵에 더 밀접하게 정렬됩니다.

EIP-3074는 7702가 완성한 아이디어를 도입했으며, 이는 완전한 계정 추상화를 위한 Ethereum 로드맵에 부합하는 생태계로 이어집니다.

가스 스폰서십: 앱이 사용자를 위해 가스를 지불하여 온보딩 장벽을 낮춥니다.
배치 트랜잭션: 사용자가 여러 액션(예: 토큰 스왑과 스테이킹)을 하나의 트랜잭션으로 결합합니다.
복구 메커니즘: 사용자가 신뢰할 수 있는 delegate를 통해 분실된 EOA를 복구합니다.

Smart wallets로 빌드를 시작하세요

EIP-3074가 걸었기에 EIP-7702가 뛸 수 있었습니다. 3074가 EOA 위임에 대한 획기적인 아이디어를 도입했다면, 7702는 이를 다듬어 더 안전하고 확장 가능한 솔루션으로 만들어, ERC-4337과 함께 Ethereum의 계정 추상화 최종 목표에 우리를 더 가깝게 데려갑니다. EIP-7702는 Ethereum의 Pectra 업그레이드에 포함되어 있으며, 2025년 4월 기준 테스트넷이 활성화되어 있습니다. 메인넷 활성화는 2025년 5월 7일부로 라이브되었으며, 클라이언트 채택(Geth, Nethermind 등)이 진행 중입니다. 한편, ERC-4337은 이미 라이브 상태로, 스마트 컨트랙트 지갑을 위한 완전한 계정 추상화를 제공하고 있습니다.

dApp UX를 최적화하든, 매끄러운 사용자 경험을 만들든, 지금이 7702와 4337에 뛰어들 때입니다. 문서를 살펴보고 빌드를 시작하세요!

질문이 있으시면 언제든 문의해 주세요. 통합 전략, 기술 구현 관련 질문, 트레이드오프에 대해 이야기하고, 여러분의 앱에 가장 적합한 솔루션을 찾도록 도와드리겠습니다. 즐거운 빌드 되세요!

자주 묻는 질문

EIP-3074란 무엇인가요?

EIP-3074는 두 개의 EVM 옵코드(AUTH와 AUTHCALL)를 도입한 제안으로, EOA가 invoker라고 불리는 스마트 컨트랙트에 제어를 위임할 수 있게 하여, 사용자가 새 지갑으로 마이그레이션할 필요 없이 가스 스폰서십과 배치 트랜잭션 같은 기능을 가능하게 했습니다.

EIP-7702는 EIP-3074를 어떻게 개선했나요?

EIP-7702는 영구적인 invoker 대신 트랜잭션별 스마트 컨트랙트 기능을 가능하게 함으로써 EIP-3074의 개념을 다듬었으며, 3074의 영구적 위임 모델과 관련된 보안 위험을 해결하는 더 안전하고 확장 가능한 경로를 제공합니다.

EIP-7702와 ERC-4337의 차이는 무엇인가요?

EIP-7702는 EOA가 트랜잭션 동안 일시적으로 스마트 컨트랙트 코드에 제어를 위임할 수 있게 하는 반면, ERC-4337은 프로토콜 변경 없이 오프체인 mempool과 bundler를 사용하여 스마트 컨트랙트 지갑을 위한 완전한 계정 추상화를 제공합니다.

EIP-3074와 ERC-4337은 함께 작동할 수 있나요?

네, 서로 보완적입니다: EIP-3074는 EOA가 실행을 위해 ERC-4337 스마트 계정과 상호작용할 수 있게 하여, 스마트 컨트랙트 지갑으로 완전히 마이그레이션하지 않고도 가스 스폰서십과 향상된 사용자 경험 같은 이점을 제공할 수 있습니다.

EIP-3074의 보안 우려사항은 무엇인가요?

EIP-3074의 영구적인 invoker는 EOA에 대해 invoker에게 상당한 제어권을 부여함으로써 보안 위험을 야기했으며, 서명 재사용과 위임된 권한의 오용 등 신중한 감사가 필요한 잠재적 취약점이 있었습니다.

EIP-3074 대신 EIP-7702가 선택된 이유는 무엇인가요?

EIP-7702는 영구적인 invoker와 관련된 EIP-3074의 보안 우려를 해결하고, ERC-4337과의 미래 호환성을 더 잘 제공하며, Ethereum의 계정 추상화 로드맵에 더 밀접하게 부합하기 때문에 선호되었습니다.

이 제안들은 개발자에게 어떤 기능을 제공하나요?

이 제안들은 가스 스폰서십(앱이 사용자를 위해 가스를 지불), 배치 트랜잭션(하나의 트랜잭션에서 여러 액션을 결합), 그리고 신뢰할 수 있는 delegate를 통한 분실된 EOA 복구 메커니즘을 가능하게 합니다.

EIP-7702는 Ethereum 메인넷에서 라이브 상태인가요?

네, EIP-7702는 Ethereum의 Pectra 업그레이드의 일환으로 2025년 5월 7일부로 메인넷에서 라이브되었으며, Geth와 Nethermind 같은 구현체 전반에 걸친 완전한 클라이언트 채택이 진행 중입니다.

블록체인 매직을 만드세요

Alchemy는 가장 강력한 Web3 개발자 제품 및 도구를 리소스, 커뮤니티, 그리고 전설적인 지원과 결합합니다.

API 키 받기

EIP-3074 vs EIP-7702 vs ERC-4337: 개발자를 위한 완벽 가이드

EIP-3074가 해결하고자 한 문제

EIP-3074의 핵심 구성 요소: 7702의 토대

1. `auth` 옵코드

2. `authcall` 옵코드

3. Invoker 컨트랙트

EIP-3074 vs. EIP-7702: 7702가 우위인 이유

Smart wallets로 빌드를 시작하세요

자주 묻는 질문

EIP-3074란 무엇인가요?

EIP-7702는 EIP-3074를 어떻게 개선했나요?

EIP-7702와 ERC-4337의 차이는 무엇인가요?

EIP-3074와 ERC-4337은 함께 작동할 수 있나요?

EIP-3074의 보안 우려사항은 무엇인가요?

EIP-3074 대신 EIP-7702가 선택된 이유는 무엇인가요?

이 제안들은 개발자에게 어떤 기능을 제공하나요?

EIP-7702는 Ethereum 메인넷에서 라이브 상태인가요?

관련 개요

Agent Wallets: AI 에이전트를 위한 세션 및 권한 모델

Cursor에 프라이빗 키를 붙여넣지 마세요: 코딩 에이전트에게 지갑을 부여하는 방법

크립토 번들러(bundler)란?

블록체인 매직을 만드세요

EIP-3074 vs EIP-7702 vs ERC-4337: 개발자를 위한 완벽 가이드

EIP-3074가 해결하고자 한 문제

EIP-3074의 핵심 구성 요소: 7702의 토대

1. auth 옵코드

2. authcall 옵코드

3. Invoker 컨트랙트

EIP-3074 vs. EIP-7702: 7702가 우위인 이유

Smart wallets로 빌드를 시작하세요

자주 묻는 질문

EIP-3074란 무엇인가요?

EIP-7702는 EIP-3074를 어떻게 개선했나요?

EIP-7702와 ERC-4337의 차이는 무엇인가요?

EIP-3074와 ERC-4337은 함께 작동할 수 있나요?

EIP-3074의 보안 우려사항은 무엇인가요?

EIP-3074 대신 EIP-7702가 선택된 이유는 무엇인가요?

이 제안들은 개발자에게 어떤 기능을 제공하나요?

EIP-7702는 Ethereum 메인넷에서 라이브 상태인가요?

관련 개요

Agent Wallets: AI 에이전트를 위한 세션 및 권한 모델

Cursor에 프라이빗 키를 붙여넣지 마세요: 코딩 에이전트에게 지갑을 부여하는 방법

크립토 번들러(bundler)란?

블록체인 매직을 만드세요

1. `auth` 옵코드

2. `authcall` 옵코드