칸쿤 업그레이드가 곧 다가옵니다. 주의해야 할 사항과 잠재적 위험은 무엇인가요?

작성자: Salus Insights

짧게 말하자면: 칸쿤 업그레이드가 다가오고 있으며, 이번 업그레이드는 EIP-1153, EIP-4788, EIP-4844, EIP-5656, EIP-6780 및 EIP-7516의 여섯 가지 실행 계층 변경을 포함합니다. EIP-4844는 이번 업그레이드의 주인공으로, 이더리움의 확장성을 향상시키고 L2의 거래 비용을 줄이며 거래 속도를 높이는 것을 목표로 합니다. 칸쿤 업그레이드는 1월 17일, 1월 30일, 2월 7일에 각각 이더리움 고를리, 세폴리아 및 홀레스키 테스트넷에서 완료되었으며, 3월 13일 이더리움 메인넷에서 활성화될 예정입니다. 업그레이드 전에 Salus는 개발자가 스스로 점검할 수 있도록 이번 업그레이드의 중요한 보안 주의 사항을 정리했습니다.

EIP 제안 검토

EIP-1153

EIP-1153은 상태를 조작하기 위한 임시 저장 작업 코드를 도입합니다. 이 작업 코드는 저장소와 거의 동일한 방식으로 작동하지만, 각 거래가 끝난 후 임시 저장소는 폐기됩니다. 이는 임시 저장소가 저장소에서 값을 역직렬화하지 않으며, 값을 저장소에 직렬화하지 않음을 의미합니다. 따라서 디스크 접근이 필요 없기 때문에 임시 저장소의 비용이 더 낮습니다. 두 개의 새로운 작업 코드 TLOAD 및 TSTORE(여기서 "T"는 "임시"를 나타냄)를 통해 스마트 계약은 임시 저장소에 접근할 수 있습니다. 이 제안은 이더리움의 거래 실행에서 여러 중첩 실행 프레임워크 간의 통신을 위한 전용이고 효율적인 솔루션을 제공하는 것을 목표로 합니다.

EIP-4788

EIP-4788은 신호 체인 블록의 해시 트리 루트를 EVM에 노출시켜 스마트 계약 내부에서 이러한 루트에 접근할 수 있도록 합니다. 이를 통해 합의 계층 상태에 신뢰 없이 접근할 수 있으며, 스테이킹 풀, 재스테이킹 구조, 스마트 계약 브리지, MEV 완화 등 다양한 사용 사례를 지원합니다. 이 제안은 스마트 계약을 통해 이러한 루트를 저장하고, 원형 버퍼를 사용하여 저장 소비를 제한하여 각 실행 블록이 이러한 정보를 상수 공간으로 표현할 수 있도록 합니다.

EIP-4844

EIP-4844는 "샤딩 Blob 거래"라는 새로운 거래 형식을 도입하여 이더리움의 데이터 가용성을 간단하고 하위 호환 가능한 방식으로 확장하는 것을 목표로 합니다. 이 제안은 EVM이 실행할 수 없는 대량의 데이터를 포함하는 "blob-carrying transactions"를 도입하여, 이러한 데이터는 그 약속에 접근할 수 있습니다. 이 형식은 향후 전체 샤딩 사용 형식과 완전히 호환되며, 롤업 확장을 위한 임시적이지만 상당한 완화를 제공합니다.

EIP-5656

EIP-5656은 메모리 영역을 효율적으로 복사하기 위한 새로운 EVM 명령어 MCOPY를 도입합니다. 이 제안은 EVM에서 메모리 복사 작업의 오버헤드를 줄이는 것을 목표로 하며, MCOPY 명령어를 통해 메모리 간 데이터 복사를 직접 구현합니다. MCOPY는 원본 주소와 대상 주소가 겹칠 수 있도록 설계되었으며, 후방 호환성을 고려하여 데이터 구조 구축, 메모리 객체의 효율적인 접근 및 복사 등 다양한 시나리오의 실행 효율성을 향상시키는 것을 목표로 합니다.

EIP-6780

EIP-6780은 SELFDESTRUCT 작업 코드의 기능을 수정합니다. 이 제안에서 SELFDESTRUCT는 계약 생성과 동일한 거래에서만 계정을 삭제하고 모든 이더를 전송합니다. 그 외에는 SELFDESTRUCT를 실행할 때 계약이 삭제되지 않고, 모든 이더가 지정된 대상으로 전송됩니다. 이 변경은 향후 Verkle 트리 사용에 적응하기 위한 것으로, EVM 구현을 단순화하고 상태 변화의 복잡성을 줄이며, SELFDESTRUCT의 일부 일반적인 시나리오를 유지하는 것을 목표로 합니다.

EIP-7516

EIP-7516은 현재 블록 실행 중 blob 기본 비용 값을 반환하는 새로운 EVM 명령어 BLOBBASEFEE를 도입합니다. 이 명령어는 EIP-3198의 BASEFEE 작업 코드와 유사하지만, EIP-4844에 정의된 blob 기본 비용을 반환한다는 점에서 다릅니다. 이 기능은 계약이 blob 데이터의 가스 가격을 프로그래밍적으로 고려할 수 있도록 하며, 예를 들어 롤업 계약이 신뢰 없이 blob 데이터 사용 비용을 계산하거나 이를 기반으로 blob 가스 선물을 구현하여 blob 데이터 비용을 부드럽게 할 수 있습니다.

공식적으로 공개된 보안 고려 사항

EIP-1153

스마트 계약 개발자는 임시 저장 변수의 수명 주기를 이해해야 합니다. 임시 저장소는 거래가 끝날 때 자동으로 지워지므로, 스마트 계약 개발자는 가스를 절약하기 위해 호출 과정에서 슬롯을 지우지 않으려 할 수 있습니다. 그러나 이는 동일한 거래에서 계약과의 추가 상호작용(예: 재진입 잠금의 경우)을 방해하거나 다른 오류를 초래할 수 있으므로, 스마트 계약 개발자는 주의하여 임시 저장 슬롯이 유지될 때만 비영(非零) 값을 보존해야 합니다. 그렇지 않으면 이러한 작업 코드의 동작은 SLOAD와 완전히 동일하므로 모든 일반적인 보안 주의 사항이 적용됩니다. 특히 재진입 위험 측면에서 그렇습니다.

스마트 계약 개발자는 또한 임시 저장소를 메모리 매핑의 대안으로 사용하려고 할 수 있습니다. 그들은 호출이 반환되거나 복구될 때 임시 저장소가 메모리처럼 폐기되지 않음을 인식해야 하며, 이러한 사용 사례에서는 메모리를 우선적으로 선택해야 합니다. 임시 저장소의 메모리 비용은 필연적으로 높기 때문에 이러한 사용 패턴을 방지해야 합니다. 메모리에서 매핑된 대부분의 사용법은 키 정렬된 항목 목록을 통해 더 잘 구현될 수 있으며, 스마트 계약에서 메모리 매핑이 필요한 경우는 드뭅니다(즉, 저자는 생산에서 알려진 사용 사례가 없음을 알고 있습니다).

EIP-4844

이 EIP는 각 신호 블록의 대역폭 요구 사항을 최대 약 0.75MB 증가시킵니다. 이는 현재 블록의 이론적 최대 크기(30M Gas / 각 calldata 바이트 16 Gas = 1.875M 바이트)보다 40% 더 크므로, 최악의 경우 대역폭을 크게 증가시키지 않습니다. 병합 후 블록 시간은 정적이며, 예측할 수 없는 포아송 분포가 아닌 보장된 시간 간격을 제공합니다.

호출 데이터가 제한적일지라도, 이 EIP의 지속적인 부하는 호출 데이터 비용을 줄일 수 있는 대안보다 훨씬 낮습니다. 이는 Blob 저장소를 실행 부하와 같은 시간 동안 유지할 필요가 없기 때문입니다. 이로 인해 이러한 blob을 구현하기 위해 최소한의 시간 동안 보존해야 하는 전략이 가능해집니다. 선택된 구체적인 값은 MINEPOCHSFORBLOBSIDECARS_REQUESTS 에포크로 약 18일이며, 이는 제안된(하지만 아직 구현되지 않은) 실행 유효 부하 기록의 1년 회전 시간에 비해 지연이 훨씬 짧습니다.

EIP-5656

클라이언트는 구현이 중간 버퍼를 사용하지 않도록 주의해야 합니다(예: C stdlibmemmove 함수는 중간 버퍼를 사용하지 않음). 이는 잠재적인 서비스 거부(DoS) 벡터입니다. 바이트 이동을 위한 대부분의 언어 내장 함수/표준 라이브러리 함수는 여기에서 올바른 성능 특성을 가지고 있습니다.

그 외에도 서비스 거부(DoS) 및 메모리 고갈 공격에 대한 분석은 다른 메모리에 접근하는 작업 코드와 동일합니다. 메모리 확장은 동일한 가격 책정 규칙을 따르기 때문입니다.

EIP-6780

다음 애플리케이션에서 SELFDESTRUCT가 파괴되며, 이러한 방식으로 사용하는 애플리케이션은 더 이상 안전하지 않습니다:

WhereCREATE2는 동일한 위치에서 계약을 재배포하여 계약을 업그레이드하는 데 사용됩니다. 이 기능은 더 이상 지원되지 않으며, ERC-2535 또는 다른 유형의 프록시 계약으로 대체해야 합니다.

계약이 SELFDESTRUCT 계약을 통해 이더를 소각하는 데 의존하는 경우, 계약은 동일한 거래에서 생성되지 않습니다.

스마트 계약 관련 위험

EIP-1153

작업 코드 TLOAD 및 TSTORE를 사용하는 두 가지 시나리오를 상상해 보십시오:

1. 호출된 계약이 해당 작업 코드를 사용합니다.
2. 호출을 시작한 계약이 해당 작업 코드를 사용합니다.

위험 1:

전통적인 SSTORE 및 SLOAD와 비교할 때, 새로 추가된 임시 저장소는 데이터의 저장 기간을 주로 변경합니다. tstore에 저장된 데이터는 tload를 통해 읽혀지며, 한 거래 실행이 끝난 후 해당 데이터는 해제됩니다. 이는 sstore와 달리 계약에 영구적으로 기록되지 않습니다. 개발자는 이 작업 코드를 사용할 때 해당 작업 코드의 특성을 인식해야 하며, 잘못된 사용으로 인해 데이터가 계약에 올바르게 기록되지 않아 손실이 발생하지 않도록 해야 합니다. 또한 tstore의 데이터는 개인 변수에 속하며, 계약 본인만 접근할 수 있습니다. 외부에서 해당 데이터를 사용하려면 매개변수 형태로 전달하거나 public storage 변수에 임시로 저장해야 합니다.

위험 2:

또 다른 잠재적 위험은 스마트 계약 개발자가 임시 저장 변수의 수명 주기를 올바르게 관리하지 않으면 데이터가 불필요한 시점에 삭제되거나 잘못 보존될 수 있다는 것입니다. 계약이 후속 호출에서 임시 저장소에 저장된 데이터를 사용하기를 기대하지만, 이러한 데이터의 수명 주기를 적절히 관리하지 않으면 서로 다른 호출 간에 데이터가 잘못 공유되거나 손실되어 논리적 오류나 보안 취약점이 발생할 수 있습니다. Token 프로젝트의 balance 또는 allowance 데이터가 올바르게 저장되지 않으면 계약 논리에 오류가 발생하여 손실이 발생할 수 있습니다. 또는 owner 주소를 설정할 때 이 작업 코드를 사용하면 특권 주소가 올바르게 기록되지 않아 계약의 중요한 매개변수 수정이 손실될 수 있습니다.

임시 저장소를 사용하여 암호화폐 거래 플랫폼에서 거래 가격을 임시로 기록하는 스마트 계약을 고려해 보십시오. 이 계약은 각 거래가 완료될 때 가격을 업데이트하고 사용자가 짧은 시간 내에 최신 가격을 조회할 수 있도록 합니다. 그러나 계약 설계가 거래가 끝날 때 임시 저장소가 자동으로 지워지는 특성을 고려하지 않으면, 한 거래가 끝난 후 다음 거래가 시작되기 전의 이 시간 동안 사용자는 잘못되거나 오래된 가격을 받을 수 있습니다. 이는 사용자가 잘못된 정보를 기반으로 결정을 내리게 할 수 있으며, 악의적으로 이용되어 플랫폼의 신뢰성과 사용자의 자산 안전에 영향을 미칠 수 있습니다.

EIP-6780

이 제안은 이전 SELFDESTRUCT 작업 코드의 동작을 변경하여 계약을 파괴하지 않고, 토큰만 전송하며, 오직 자폭과 동일한 거래에서 생성된 계약만 삭제됩니다. 이 EIP의 영향은 상대적으로 큽니다.

create2를 사용하여 동일한 주소에서 계약을 재배포하여 계약을 업그레이드합니다. 이 기능은 더 이상 지원되지 않으며, ERC-2535 또는 다른 유형의 프록시 계약으로 대체해야 합니다. (이는 create2를 사용하여 업그레이드 가능한 계약을 구현하는 온체인 계약의 안전성에 영향을 미칠 수 있습니다.)

스마트 계약의 SELFDESTRUCT 작업은 계약을 파괴하고 계약 잔액을 지정된 목표 주소로 전송할 수 있습니다. 이 경우 계약은 SELFDESTRUCT를 사용하여 이더를 파괴하고, 파괴된 이더를 계약으로 전송합니다. 그러나 이 계약은 동일한 거래에서 생성된 계약(동일한 거래에서 본 계약 또는 다른 계약에 의해 생성된 계약)에서만 가능합니다. 그렇지 않으면 이더만 전송되고 계약은 파괴되지 않습니다(예: 자폭하고 수혜자가 자폭 계약인 경우, 이는 아무런 변화를 초래하지 않습니다). 이는 selfdestruct에 의존하여 인출하거나 다른 작업을 수행하는 계약에 영향을 미칠 것입니다.

1inch CHI Token과 유사한 가스 토큰의 작동 원리: 오프셋을 유지하고 항상 이 오프셋에서 CREATE2 또는 SELFDESTRUCT를 실행합니다. 이 업데이트 이후, 현재 오프셋의 계약이 올바르게 자폭되지 않았다면 이후의 CREATE2는 계약을 성공적으로 배포할 수 없습니다.

이 제안의 구현은 계약에 대한 직접적인 공격을 초래하지 않지만, selfdestruct 작업에 의존하는 기존 배포된 계약의 정상적인 논리를 손상시킬 수 있습니다(자폭에 의존하여 자금을 이동하는 계약은 영향을 받지 않지만, 후속 작업에서 자폭 계약이 삭제되어야 하는 경우에는 영향을 받습니다). 이는 계약이 예상치 못한 방식으로 작동하게 하여, 계약 및 사용자에게는 계약의 중단, 자금 손실 등의 위험을 초래할 수 있습니다(예: 원래 create2를 사용하여 원래 주소에 새 계약을 배포하고, 원래 계약을 자폭하여 업그레이드하는 계약이 더 이상 성공적으로 배포할 수 없음). 장기적으로는 특정 작업 코드의 기능을 수정하는 것이 중앙 집중화 문제를 초래할 수 있습니다.

예를 들어, 기존의 금고 계약 vault를 업데이트하는 경우:

• create2 임시 저장 계약을 사용하여 vault의 자금을 임시로 저장합니다.
• vault 계약을 자폭하고, 자금을 임시 계약으로 전송합니다(자금만 전송되고 계약은 파괴되지 않음).
• 원래 주소에서 create2로 새로운 vault 계약을 생성합니다(실패, 원래 vault 계약이 파괴되지 않음).
• 임시 계약을 자폭하여 자금을 vault로 반환합니다(자금 손실, vault 계약이 생성되지 않음).