준비 중인 칸쿤 업그레이드와 관련하여 주의해야 할 사항과 잠재적 위험 요소는 무엇이 있을까?
글: Salus Insights
요약하면, 킨타나로 업그레이드가 임박했습니다. 이번 업그레이드는 주로 6개의 EIP에서 제안한 실행 계층 변경 사항을 포함하며, 해당 EIP들은 EIP-1153, EIP-4788, EIP-4844, EIP-5656, EIP-6780 및 EIP-7516입니다. 이 중 EIP-4844가 핵심으로, 이더리움의 확장성을 향상시켜 L2의 거래 비용을 낮추고 거래 속도를 높이는 것을 목표로 합니다. 킨타나로 업그레이는 이미 1월 17일, 1월 30일, 2월 7일에 각각 이더리움 Goerli, Sepolia, Holesky 테스트넷에서 완료되었으며, 3월 13일 메인넷에서 활성화될 예정입니다. 업그레이드 전에 Salus는 개발자들이 스스로 점검할 수 있도록 이번 업그레이드와 관련된 중요한 보안 사항들을 정리했습니다.
EIP 제안 요약
EIP-1153
EIP-1153은 일시 저장소(temporary storage)를 조작하기 위한 새로운 오퍼코드(TLOAD 및 TSTORE, 여기서 'T'는 '임시(temporary)'를 의미함)를 도입합니다. 이러한 오퍼코드는 상태를 조작하는 데 사용되며, 기존 스토리지와 유사하게 작동하지만 각 트랜잭션이 종료되면 일시 저장소의 내용은 폐기됩니다. 즉, 일시 저장소는 디스크 I/O 없이 값을 직렬화하거나 역직렬화하지 않으므로 비용이 더 저렴합니다. 이 제안은 여러 중첩된 실행 프레임워크 간의 통신을 위한 효율적이고 전용적인 해결책을 제공하고자 합니다.
EIP-4788
EIP-4788은 비콘 체인 블록의 해시 트리 루트를 EVM 내부에서 접근 가능하게 하여, 스마트 계약 내부에서 이 루트 값에 신뢰 없이(trustlessly) 접근할 수 있도록 합니다. 이를 통해 스테이킹 풀, 리스테이킹 구조, 스마트 계약 브릿지, MEV 완화 등 다양한 활용 사례가 가능해집니다. 이 제안은 루트 값을 스마트 계약 내부에 저장하고 원형 버퍼(circular buffer)를 사용하여 저장 공간 소비를 제한함으로써 각 실행 블록이 일정한 상수 공간만으로 정보를 표현할 수 있도록 합니다.
EIP-4844
EIP-4844는 "샤딩 블롭(sharding blob) 트랜잭션"이라고 불리는 새로운 트랜잭션 형식을 소개합니다. 이는 이더리움의 데이터 가용성을 단순하고 미래 호환 가능한 방식으로 확장하는 것을 목표로 합니다. 이 제안은 EVM이 직접 처리할 수는 없지만 그 커밋(commitment)에는 접근 가능한 대량의 데이터를 담는 "블롭 전달 트랜잭션(blob-carrying transactions)"을 도입합니다. 이 형식은 향후 전체 샤딩 시 사용되는 형식과 완전히 호환되며, 롤업 확장성에 대해 임시적이지만 큰 완화 효과를 제공합니다.
EIP-5656
EIP-5656은 메모리 영역을 효율적으로 복사하기 위한 새로운 EVM 명령어 MCOPY를 도입합니다. 이 명령어는 EVM에서 메모리 복사 작업의 오버헤드를 줄이며, 소스 주소와 대상 주소가 겹치는 경우에도 안전하게 동작하도록 설계되었습니다. 또한 기존 코드와의 하위 호환성을 고려하며, 데이터 구조 생성, 메모리 객체의 효율적 접근 및 복제 등 다양한 시나리오에서 실행 효율을 향상시키는 것을 목표로 합니다.
EIP-6780
EIP-6780은 SELFDESTRUCT 오퍼코드의 동작 방식을 수정합니다. 본 제안에 따르면, SELFDESTRUCT는 같은 트랜잭션 내에서 생성된 계약에 대해서만 계정을 삭제하고 모든 이더를 전송하며, 그렇지 않은 경우에는 계약을 삭제하지 않고 지정된 주소로 이더만 이전합니다. 이 변경은 향후 Verkle 트리를 도입하기 위한 준비로, EVM 구현을 단순화하고 상태 변경의 복잡성을 줄이며, 동시에 SELFDESTRUCT의 일반적인 사용 사례는 유지하려는 목적을 가지고 있습니다.
EIP-7516
EIP-7516은 현재 블록의 blob 기반 요금(blob base fee) 값을 반환하는 새로운 EVM 명령어 BLOBBASEFEE를 도입합니다. 이 명령어는 EIP-3198의 BASEFEE 오퍼코드와 유사하지만, EIP-4844에서 정의된 blob 기반 요금을 반환한다는 점에서 다릅니다. 이를 통해 롤업 스마트 계약이 blob 데이터의 가스 비용을 신뢰 없이 계산하거나, blob 가스 선물(futures)를 구현하여 비용 변동성을 완화하는 등의 프로그래밍이 가능해집니다.
공식적으로 공개된 보안 고려사항
EIP-1153
스마트 계약 개발자는 일시 저장소 변수의 수명 주기를 충분히 이해한 후 사용해야 합니다. 일시 저장소는 트랜잭션 종료 시 자동으로 초기화되기 때문에, 일부 개발자는 Gas 절약을 위해 호출 과정 중 슬롯을 초기화하지 않도록 시도할 수 있습니다. 그러나 이는 같은 트랜잭션 내에서 계약과의 추가 상호작용(예: 재진입 잠금 장치)을 방해하거나 다른 오류를 유발할 수 있으므로 주의가 필요합니다. 따라서 일시 저장소 슬롯에 비영(non-zero) 값을 저장할 때는 반드시 다음 호출에서도 사용할 필요가 있는 경우에만 보관해야 합니다. SSTORE 및 SLOAD와 마찬가지로 재진입 위험을 포함한 일반적인 보안 주의사항이 여전히 적용됩니다.
또한 일부 개발자는 일시 저장소를 메모리 매핑 대체 수단으로 사용하려 할 수 있습니다. 하지만 호출이 반환되거나 롤백될 때 일시 저장소는 메모리처럼 자동으로 폐기되지 않음을 인지해야 하며, 재진입 시 예기치 못한 동작을 초래할 수 있으므로 해당 케이스에서는 메모리를 우선적으로 사용해야 합니다. 일시 저장소를 메모리 대용으로 사용하는 것은 비용이 매우 높아 이미 자연스럽게 억제되고 있으며, 메모리 내 맵핑 사용 대부분은 키 순서에 따른 항목 리스트로 더 잘 구현할 수 있습니다. 실제로 생산 환경에서 메모리 내 맵핑이 필요한 사례는 거의 없습니다(저자가 아는 한 알려진 사례는 없습니다).
EIP-4844
본 EIP는 각 비콘 블록의 대역폭 요구량을 최대 약 0.75MB까지 증가시킵니다. 이는 현재 블록의 이론적 최대 크기(30M 가스 / 콜데이터 1바이트당 16 가스 = 1.875M 바이트)보다 약 40% 크며, 최악의 경우 대역폭 증가는 크게 증가하지 않습니다. 머지 이후 블록 시간은 불규칙한 포아송 분포가 아닌 고정되어 있으므로, 큰 블록의 전파에 대해 안정적인 시간이 보장됩니다.
콜데이터가 제한되어 있더라도, 본 EIP의 지속 부하는 콜데이터 비용을 낮추는 대안보다 훨씬 낮습니다. 이는 Blob 데이터를 실행 부하만큼 오랫동안 저장할 필요가 없기 때문입니다. 따라서 Blob을 일정 기간 이상 보관해야 하는 전략을 실현할 수 있으며, 선택된 구체적인 값인 MIN_EPOCHS_FOR_BLOB_SIDECARS_REQUESTS는 약 18일로, 제안된(하지만 아직 시행되지 않은) 1년 주기의 실행 페이로드 기록보다 훨씬 짧은 지연 시간을 갖습니다.
EIP-5656
클라이언트는 중간 버퍼(예: C 표준 라이브러리 memmove 함수)를 사용하지 않도록 구현에 주의해야 하며, 그렇지 않을 경우 잠재적인 서비스 거부(DoS) 벡터가 될 수 있습니다. 대부분의 언어에서 바이트 이동을 위한 내장 함수 또는 표준 라이브러리 함수는 적절한 성능 특성을 가지고 있습니다.
또한 서비스 거부(DoS) 및 메모리 고갈 공격에 대한 분석은 메모리 조작 오퍼코드와 동일하며, 메모리 확장은 동일한 가격 책정 규칙을 따릅니다.
EIP-6780
다음과 같은 SELFDESTRUCT 사용 사례는 더 이상 작동하지 않으며, 이러한 방식을 사용하는 애플리케이션은 안전하지 않습니다:
CREATE2를 사용하여 동일한 위치에 다시 배포하여 계약을 업그레이드하는 경우. 이 기능은 더 이상 지원되지 않으며, 대신 ERC-2535 또는 기타 유형의 프록시 계약을 사용해야 합니다.
계약이 SELFDESTRUCT를 통해 이더를 소각하면서 수혜자가 되는 방식에 의존하는 경우, 해당 계약이 동일한 트랜잭션에서 생성되지 않았다면 더 이상 유효하지 않습니다.
스마트 계약 관련 위험
EIP-1153
TLOAD 및 TSTORE 오퍼코드 사용 시나리오를 두 가지로 나눌 수 있습니다:
-
호출되는 계약이 해당 오퍼코드를 사용하는 경우
-
호출을 시작하는 계약이 해당 오퍼코드를 사용하는 경우
위험 1:
기존의 SSTORE 및 SLOAD와 비교해, 새롭게 도입된 일시 저장소는 데이터 저장 기간을 변화시켰습니다. tstore로 저장된 데이터는 tload로 읽을 수 있지만, 트랜잭션이 종료되면 데이터가 해제되며, sstore처럼 영구적으로 저장되지 않습니다. 개발자는 이 오퍼코드의 특성을 정확히 이해하고 사용해야 하며, 잘못 사용 시 데이터가 올바르게 기록되지 않아 손실이 발생할 수 있습니다. 또한 tstore의 데이터는 개인 변수로, 계약 자체만 접근 가능하며 외부에서 사용하려면 파라미터 전달이나 public storage 변수에 임시 저장하는 방법이 필요합니다.
위험 2:
잠재적 위험 중 하나는 스마트 계약 개발자가 일시 저장소 변수의 수명 주기를 제대로 관리하지 못해 데이터가 예기치 않게 삭제되거나 보존되는 경우입니다. 만약 계약이 후속 호출에서 일시 저장소에 저장된 데이터를 사용하려 했으나 수명 주기를 제대로 관리하지 못했다면, 호출 간에 데이터가 잘못 공유되거나 손실되어 논리 오류나 보안 취약점이 발생할 수 있습니다. 예를 들어 토큰 프로젝트의 balance 또는 allowance 데이터가 제대로 저장되지 않으면 계약 로직 오류로 인한 손실이 발생할 수 있으며, owner 주소 설정 시 이 오퍼코드를 사용하면 권한 주소가 올바르게 기록되지 않아 중요한 파라미터 수정 권한을 상실할 수 있습니다.
가상의 스마트 계약을 생각해봅시다. 이 계약은 일시 저장소를 사용해 암호화폐 거래 플랫폼의 거래 가격을 일시적으로 기록합니다. 각 거래 완료 시 가격을 업데이트하고, 사용자가 짧은 시간 내에 최신 가격을 조회할 수 있도록 합니다. 그러나 계약 설계 시 일시 저장소가 트랜잭션 종료 시 자동으로 초기화된다는 점을 고려하지 않았다면, 한 트랜잭션이 끝나고 다음 트랜잭션이 시작되기 전 사이에 사용자가 잘못되거나 오래된 가격을 받을 수 있습니다. 이는 사용자의 잘못된 의사결정을 유도할 수 있을 뿐 아니라 악의적으로 이용되어 플랫폼의 신뢰도와 사용자 자산 보안에 영향을 미칠 수 있습니다.
EIP-6780
이 제안은 기존의 selfdestruct 오퍼코드 동작을 변경하여, 동일한 트랜잭션 내에서 생성된 계약이 아닌 경우 계약을 파괴하지 않고 토큰만 이전합니다. 이 EIP의 영향은 상당히 큽니다.
CREATE2를 사용하여 동일한 주소에 다시 배포하여 계약을 업그레이드하는 기능은 더 이상 지원되지 않으며, 대신 ERC-2535 또는 다른 형태의 프록시 계약을 사용해야 합니다. (이는 온체인 계약에서 CREATE2를 사용해 업그레이드 가능한 계약을 구현한 경우 보안에 영향을 줄 수 있습니다.)
스마트 계약의 SELFDESTRUCT 오퍼코드는 계약을 파괴하고 잔액을 지정된 주소로 전송합니다. 그러나 이제는 동일한 트랜잭션 내에서 생성된 계약(본 계약 또는 다른 계약이 생성한 것)에 대해서만 파괴됩니다. 그렇지 않으면 계약 파괴 없이 이더만 이전됩니다. (예: 자기 파괴하면서 수혜자가 자기 자신인 경우 아무런 변화 없음). 이는 SELFDESTRUCT에 의존하는 모든 인출 또는 기타 동작의 계약에 영향을 미칩니다.
1inch CHI 토큰과 유사한 가스 토큰(Gas Token)의 동작 방식: 특정 오프셋을 유지하면서 해당 위치에서 항상 CREATE2 또는 SELFDESTRUCT를 수행합니다. 이번 업데이트 후, 만약 현재 오프셋의 계약이 제대로 자멸되지 않았다면, 이후 CREATE2로 계약을 성공적으로 배포할 수 없습니다.
이 제안의 시행은 직접적인 공격을 유도하지는 않지만, 기존에 배포된 SELFDESTRUCT 오퍼코드에 의존하는 계약의 정상적인 로직을 손상시켜 예기치 않은 동작을 유발할 수 있습니다. (단순히 자살을 통한 자금 이전에만 의존하는 계약은 영향 없음, 하지만 후속 동작에서 계약 삭제가 반드시 필요한 경우 영향 있음). 이는 계약의 기능 중단 및 자금 손실 등의 피해를 초래할 수 있습니다 (예: CREATE2로 기존 주소에 새 계약 배포 및 기존 계약 자살을 통한 업그레이드가 더 이상 실패함). 장기적으로 보면, 특정 오퍼코드의 기능을 수정하는 것은 중앙화 문제를 유발할 가능성도 있습니다.
예를 들어 다음과 같은 금고(vault) 계약 업데이트 시나리오를 생각해 봅시다:
-
CREATE2로 일시 계약을 생성하여 vault의 자금을 임시 보관
-
vault 계약을 자살하여 자금을 일시 계약으로 이전 (자금만 이전되고 계약은 삭제되지 않음)
-
기존 주소에 CREATE2로 새로운 vault 계약 배포 (실패, 기존 vault 계약이 삭제되지 않았기 때문)
-
일시 계약을 자살하여 자금을 vault로 반환 (자금 손실, vault 계약이 생성되지 않음)
추가 참고 자료
킨타나로 업그레이드는 이더리움의 경쟁력을 더욱 강화할 것입니다. 그러나 이번 업그레이드는 핵심 스마트 계약 계층에 변화를 가져옴으로써 기존 DApp들의 안전한 운영에 위험을 초래할 수 있습니다. 스마트 계약 개발 시 이러한 변경 사항과 잠재적 위험에 대해 충분히 주의를 기울여야 합니다.
TechFlow 공식 커뮤니티에 오신 것을 환영합니다
Telegram 구독 그룹:https://t.me/TechFlowDaily
트위터 공식 계정:https://x.com/TechFlowPost
트위터 영어 계정:https://x.com/BlockFlow_News
@salus_sec
