이더리움 액세스 리스트(EIP-2930): 웜 스토리지와 가스 원리

이더리움 트랜잭션을 살펴보다 accessList 안에 컨트랙트 주소와 32바이트 스토리지 키가 가득한 모습을 보셨나요? 권한 목록이나 보안 장벽처럼 보이지만 실제로는 그렇지 않아요. 이더리움 액세스 리스트(Access List)는 트랜잭션이 접근할 상태를 미리 알려 주는 가스 계산 힌트입니다. 블록체인 기초에서 입력·실행·상태 접근이 어떻게 연결되는지 보여 주는 좋은 사례예요. 목록 밖 상태에도 접근할 수 있고, 잘못 만든 목록은 오히려 가스를 더 씁니다.

이 글에서는 EIP-2930 트랜잭션 액세스 리스트, 웜(Warm)·콜드(Cold) 상태 접근, 정확한 가스 트레이드오프, eth_createAccessList를 안전하게 쓰는 순서를 알아봅니다.

이더리움 액세스 리스트란?

EVM을 거대한 기록 보관소의 직원이라고 생각해 보세요. 서랍을 처음 열어 파일을 가져오는 작업은 비싼 **콜드 액세스(Cold Access)**예요. 파일을 책상 위에 올린 뒤 다시 읽는 작업은 저렴한 **웜 액세스(Warm Access)**가 됩니다. 액세스 리스트는 일을 시작하기 전에 “이 서랍과 파일을 미리 책상 위에 올려 주세요”라고 적어 둔 메모와 비슷해요.

EIP-2930 공식 명세는 액세스 튜플(Access Tuple)의 목록을 정의합니다. 튜플 하나에는 20바이트 계정 또는 컨트랙트 주소 하나와 그 주소에 속하는 32바이트 스토리지 키(Storage Key)가 0개 이상 들어가요. 실행을 시작할 때 목록의 주소와 슬롯은 EVM의 웜 집합에 들어갑니다.

가장 중요한 특징은 선택 사항이며 강제 규칙이 아니라는 점이에요. 목록에 없는 주소나 슬롯을 건드려도 그 이유만으로 되돌려지지 않습니다. 일반적인 콜드 접근 비용을 내고 실행할 수 있어요. 따라서 방화벽, 허용 목록(Allowlist), 권한 제한으로 해석하면 안 됩니다. 발신자, 목적지, 프리컴파일(Precompile) 주소 등은 프로토콜 규칙에 따라 별도로 처리돼요.

EIP-2930은 왜 만들어졌을까요?

EIP-2929는 베를린(Berlin) 업그레이드에서 일부 계정·스토리지 연산의 최초 접근 비용을 올렸습니다. 클라이언트가 수행하는 상태 조회 비용을 더 잘 반영하고, 반복 상태 접근을 악용한 서비스 거부 공격(DoS)에 대한 방어력을 높이기 위한 변화였어요. 동시에 이미 접근한 주소와 키를 콜드 상태와 구분하는 트랜잭션 단위 집합도 도입했습니다.

EIP-2930은 발신자가 예상 상태 접근을 미리 선언하고 비용을 내도록 같은 업그레이드에서 도입됐어요. 높아진 비용에 민감한 컨트랙트는 알려진 위치를 미리 웜 처리하고, 클라이언트는 일부 예상 데이터를 일찍 프리페치(Prefetch)할 수 있습니다.

이 제안은 EIP-2718의 타입 트랜잭션 봉투(Typed Transaction Envelope)를 사용해요. 전용 타입은 0x01이고 목록도 서명 대상 데이터에 포함됩니다. 이더리움 트랜잭션 타입 가이드는 이 형식을 레거시와 타입 0x02–0x04 옆에서 비교합니다. EIP-1559가 동적 수수료 타입 0x02를 도입한 뒤에도 액세스 리스트는 사라지지 않았어요. EIP-1559 명세에도 access_list 필드가 있습니다.

웜·콜드 가스는 어떻게 계산될까요?

EIP-2930은 실행 전에 선언 항목마다 고유 가스(Intrinsic Gas)를 부과합니다.

선언 항목	고유 가스 비용
주소	2,400 가스
스토리지 키	1,900 가스

EIP-2929에서 최초 콜드 계정 접근은 2,600 가스, 웜 계정 접근은 100 가스입니다. 최초 콜드 스토리지 읽기(SLOAD)는 2,100 가스, 웜 읽기는 100 가스예요. 하지만 목록에 넣기만 하면 항상 가스가 줄어든다는 뜻은 아닙니다.

스토리지 키 하나를 선언하면 1,900 가스를 먼저 내고 실제 최초 웜 읽기에 100 가스를 써요. 실제로 읽는다면 합계 2,000 가스로 콜드 읽기보다 100 가스 적습니다. 실행하지 않는 분기의 슬롯을 넣으면 비용만 추가돼요. 이미 규칙상 웜인 주소도 있을 수 있습니다.

중복 항목도 형식상 유효하지만 등장할 때마다 비용을 내요. 웜 상태는 집합처럼 작동하므로 같은 항목을 두 번 넣어도 효과는 늘지 않습니다. 정보 없이 고유 가스만 늘어나는 셈이에요.

트랜잭션에는 어떤 형태로 들어갈까요?

JSON-RPC에서는 다음처럼 읽을 수 있어요.

{
  "accessList": [{
    "address": "0x1111111111111111111111111111111111111111",
    "storageKeys": [
      "0x0000000000000000000000000000000000000000000000000000000000000007"
    ]
  }]
}

스토리지 키는 사람이 읽는 변수명이 아니라 EVM의 원시 슬롯입니다. 솔리디티(Solidity)의 매핑과 동적 배열은 해싱 규칙으로 슬롯을 계산해요. 프록시 컨트랙트는 구현 코드를 실행하면서 프록시의 스토리지를 사용할 수 있습니다. 소스 코드의 변수 순서만 보고 슬롯을 추측하면 틀릴 수 있어요.

액세스 리스트는 이더리움 콜데이터를 대신하지 않습니다. 콜데이터는 요청한 함수와 인자를 표현하고, 액세스 리스트는 가스 계산을 위해 미리 웜 처리할 상태 위치를 표현해요. 둘 다 서명되는 데이터지만 답하는 질문이 달라요.

eth_createAccessList로 목록 생성하기

현재 이더리움 Execution API는 eth_createAccessList 메서드를 명시합니다. 트랜잭션 호출 객체와 블록 기준 상태를 받아 accessList, 예상 gasUsed, 경우에 따라 error를 반환해요.

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "eth_createAccessList",
  "params": [{
    "from": "0x2222222222222222222222222222222222222222",
    "to": "0x1111111111111111111111111111111111111111",
    "data": "0x12345678"
  }, "pending"]
}

안전한 작업 순서는 다음과 같습니다.

체인, 발신자, 목적지, 전송 가치(Value), 콜데이터가 정확한 호출 객체를 만드세요.
pending, latest, 지원되는 블록 번호 중 명시적인 상태 기준을 고르세요.
신뢰하는 실행 클라이언트나 RPC에서 메서드를 호출하세요.
모든 주소와 스토리지 키를 확인하고 중복을 제거하세요.
같은 상태에서 목록을 넣은 버전과 빼 놓은 버전을 모두 추정하세요.
상태에 따라 경로가 달라진다면 제출 직전에 다시 실행하세요.
최종 목적지, 콜데이터, 수수료, 목록을 확인한 뒤 서명하세요.

Geth RPC 문서는 생성 결과가 추정치이고, 목록을 추가한다고 반드시 가스 사용량이 줄지는 않는다고 설명합니다. 절감 보장 도구가 아니라 시뮬레이션 도구로 다뤄야 해요.

언제 도움이 되고 언제 손해일까요?

실행이 알려진 컨트랙트와 슬롯을 따라 예측 가능한 경로를 반복한다면 검토할 만해요. 콜드 상태 접근의 가스 동작을 세밀하게 관리하는 인프라 팀에도 의미가 있습니다.

반대로 다음 상황에서는 쓸모가 없거나 더 비쌀 수 있어요.

실행이 실제로 건드리지 않는 주소나 키를 넣었을 때
이미 프로토콜 규칙상 웜인 주소를 불필요하게 넣었을 때
중복 항목이 비용만 더할 때
변하는 상태에 따라 다른 분기를 실행할 때
생성과 블록 포함 사이에 상태가 달라졌을 때
생성 도구의 넓은 목록 비용이 할인보다 커졌을 때

특정 연산의 할인만 보지 말고 총 가스를 비교하세요. gasUsed와 ETH로 표시되는 최종 수수료도 달라요. 가스 단위를 적게 써도 포함 시점의 유효 가스 가격이 높으면 ETH 비용은 커질 수 있습니다. 실행 뒤 실제 사용량은 이더리움 트랜잭션 영수증 가이드에서 확인할 수 있어요.