EIP-2930 접근 목록은 거래가 사용할 것으로 예상하는 계정 주소와 그 계정의 storage key를 거래에 미리 포함하는 형식입니다. 목록 항목은 실행 시작부터 warm access로 취급돼 해당 접근 비용이 낮아지지만 주소당 2,400 gas, storage key당 1,900 gas를 선불로 냅니다. 목록 밖 상태에도 접근할 수 있으므로 허용 목록이나 보안 경계가 아니며 정확한 목록이 항상 총 gas를 줄이는 것도 아닙니다.
접근 목록은 예상 상태를 거래에 함께 싣는다
EVM 거래는 계약 실행 중 여러 계정의 코드·잔액과 storage slot을 읽거나 쓸 수 있습니다. EIP-2930은 address와 그 주소 아래 storage key 배열을 accessList로 넣는 type 1 거래를 정의했습니다. 실행 시작 때 이 항목들을 accessed set에 추가합니다.
목록의 목적은 상태 접근을 금지하는 것이 아니라 미리 알려 warm access 비용을 적용하는 것입니다. 계약이 동적으로 다른 주소를 계산하더라도 목록에 없다는 이유로 실행이 막히지 않습니다. 예상하지 못한 접근은 더 비싼 cold 비용을 냅니다.
| 항목 | 선불 비용 | 실행 중 효과 |
|---|---|---|
| 계정 주소 1개 | 2,400 gas | 해당 계정 warm |
| storage key 1개 | 1,900 gas | 해당 (주소,slot) warm |
| 목록 밖 주소 | 선불 없음 | 첫 접근 cold 비용 |
| 중복 항목 | 중복 과금 | 추가 실행 효과 없음 |
type 1 거래는 목록 자체에도 서명한다
EIP-2930 payload에는 chainId, nonce, gasPrice, gasLimit, to, value, data, accessList와 서명 값이 들어갑니다. 서명 해시는 type byte 0x01과 이 필드들을 결합하므로 서명 뒤 목록을 바꾸면 유효하지 않습니다. 다른 거래 유형으로 재해석되는 것도 type byte가 막습니다.
EIP-1559 type 2 거래도 access list 필드를 포함할 수 있지만 수수료 필드가 maxPriorityFeePerGas와 maxFeePerGas로 달라집니다. 접근 목록과 수수료 시장은 별도 개념입니다. 지갑이 type 2를 보낸다고 접근 목록을 자동으로 최적 생성했다는 뜻은 아닙니다.
접근 목록은 실행 경로의 힌트이며 호출 가능한 상태의 경계선이 아니다.
JOBCOIN 해설
항목별 선불 비용과 절약분을 비교한다
목록 주소는 2,400 gas, storage key는 1,900 gas가 거래 시작 때 부과됩니다. 대신 EIP-2929의 첫 cold account 또는 storage 접근보다 낮은 warm 비용을 적용받습니다. 항목이 실제로 사용되지 않으면 선불 비용만 내므로 총 gas가 늘어납니다.
예를 들어 특정 storage slot을 한 번 읽을 예정이라도 그 주소가 이미 거래 수신자나 precompile처럼 warm한 조건인지 봐야 합니다. 동일 slot을 여러 번 읽으면 첫 접근 이후 자동으로 warm해지므로 목록의 절약은 주로 첫 접근 차이에 달려 있습니다. eth_createAccessList 결과와 estimateGas를 목록 유무 두 경우로 비교합니다.
- 시뮬레이션 블록의 상태와 실제 포함 시점 차이를 고려한다.
- 사용하지 않는 주소·slot과 중복 항목을 제거한다.
- access list 포함·미포함 estimateGas를 비교한다.
- 서명 전에 chainId·to·data·목록 전체를 확인한다.
storage key는 변수 이름이 아니라 32바이트 slot이다
Solidity의 단순 상태 변수는 배치 규칙에 따라 slot을 갖고 mapping은 key와 기준 slot을 해시해 실제 storage key를 만듭니다. 사용자가 allowance라는 이름을 안다고 slot 문자열을 바로 적을 수 있는 것이 아닙니다. 프록시와 delegatecall은 호출 대상 코드와 실제 storage가 있는 주소가 다를 수 있습니다.
go-ethereum의 access list 구현도 address 존재와 (address, slot) 존재를 별도로 관리합니다. 잘못된 주소에 올바른 듯한 slot을 넣으면 원하는 접근을 warm하게 만들지 못합니다. trace나 클라이언트의 access list 생성 RPC로 실제 경로를 얻고 계약 업그레이드 뒤 다시 생성합니다.
동적 실행에서는 사전 목록이 빗나갈 수 있다
AMM 경로, 사용자 잔액, oracle 결과에 따라 호출 주소와 slot이 달라질 수 있습니다. 생성 시뮬레이션과 채굴 사이 상태가 변하면 실제 경로가 목록과 달라질 수 있습니다. 목록 밖 접근이 허용되므로 보통 거래는 계속되지만 예상 gas 절약이 사라지고 gas limit이 빠듯하면 실패할 수 있습니다.
하드웨어 지갑은 긴 access list를 모두 사람이 확인하기 어렵습니다. 목록이 서명 대상이므로 신뢰한 거래 생성기와 시뮬레이션 결과를 사용하고, to·value·data를 우선 검증합니다. 접근 목록에 악성 주소가 있다고 그 주소로 자산 전송이 자동 발생하는 것은 아니지만 calldata 실행과 함께 해석해야 합니다.
성능 힌트와 보안 정책을 혼동하지 않는다
접근 목록은 어떤 주소만 호출할 수 있다는 allowlist가 아니며 목록 밖 storage 쓰기를 차단하지도 않습니다. 계약 권한 검사는 msg.sender, 역할, 서명, 상태 조건으로 구현해야 합니다. 감사 보고서에서 access list를 보안 통제로 표현한다면 실제 코드 경계를 다시 확인합니다.
거래 뒤 receipt의 gasUsed를 기준으로 목록 효과를 측정합니다. 동일 호출을 다른 상태에서 비교하면 storage 값과 경로 변화가 섞일 수 있습니다. 테스트넷과 포크 환경에서 동일 블록 상태로 목록 유무를 비교하고, 최적화 이익이 복잡성보다 작은 단순 전송에는 빈 목록을 유지할 수 있습니다.
자주 묻는 질문
목록에 없는 계약은 호출할 수 없나요?
호출할 수 있습니다. 첫 접근이 cold로 과금될 뿐 접근 목록은 허용 목록이 아닙니다.
접근 목록을 넣으면 gas가 항상 줄어드나요?
아닙니다. 항목별 선불 비용이 있어 사용하지 않거나 중복된 항목은 오히려 총 gas를 늘릴 수 있습니다.
EIP-1559 거래에는 접근 목록이 없나요?
type 2 거래도 access list를 포함할 수 있습니다. 다만 base fee 관련 수수료 필드와 접근 목록의 목적은 별도입니다.
