칸쿤에서 업그레이드하기 전 중요한 안전 점검

짧은 이야기: 칸쿤 업그레이드가 다가오고 있습니다. 이 업그레이드에는 주로 6개의 EIP, EIP-1153, EIP-4788, EIP-4844, EIP-5656, EIP-6780 및 EIP-7516에서 제안된 임원 계층 변경이 포함됩니다. EIP-4844는 이더리움의 확장성을 향상하고 거래 비용을 줄이며 L2의 거래 속도를 높이는 것을 목표로 하는 이번 업그레이드의 주인공입니다. 칸쿤 업그레이드는 각각 1월 17일, 1월 30일, 2월 7일 이더리움 괴를리(Ethereum Goerli), 세폴리아(Sepolia), 홀스키(Holesky) 테스트넷에서 완료되었으며, 3월 13일 이더리움 메인넷에서 활성화될 예정입니다. 업그레이드하기 전에 Salus는 개발자가 스스로 확인할 수 있도록 이 업그레이드에 대한 중요한 안전 예방 조치를 정리했습니다.

EIP 제안 검토

오피스 공개 보안 고려 사항

smart 계약 관련 위험 eip eip 제안 검토

eip-1153

1. EIP-1153이 운영 코드에 대한 임시 스토리지 opcodes를 소개합니다. 작동 상태에 대해 저장과 거의 동일하게 동작하지만 임시 저장은 각 트랜잭션 후에 폐기됩니다. 즉, 임시 저장소는 저장소의 값을 역직렬화하거나 저장소로 값을 직렬화하지 않으므로 디스크 액세스가 필요하지 않으므로 임시 저장소의 비용이 저렴합니다. 스마트 계약은 두 개의 새로운 opcode인 TLOAD 및 TSTORE("T"는 "임시"를 나타냄)를 통해 임시 저장소에 액세스할 수 있습니다. 이 제안은 이더리움의 트랜잭션 실행에서 여러 중첩 실행 프레임워크 간의 통신을 위한 효율적이고 효율적인 솔루션을 제공하는 것을 목표로 합니다.

EIP-4788

2. EIP-4788은 비콘 체인 블록의 해시 트리 루트를 EVM에 노출하여 스마트 계약 내에서 이러한 루트에 액세스할 수 있도록 설계되었습니다. 이는 합의 레이어 상태에 대한 무신뢰 액세스를 제공하여 스테이킹 풀, 재스테이킹 구조, 스마트 계약 브리지, MEV 완화 등과 같은 다양한 사용 사례를 지원합니다. 제안서는 스마트 계약을 통해 이러한 루트를 저장하고 링 버퍼를 사용하여 스토리지 소비를 제한함으로써 각 실행 블록이 이 정보를 표현하는 데 일정한 공간만 필요하도록 보장합니다.

EIP-4844

3. EIP-4844는 간단하고 향후 호환 가능한 방식으로 Ethereum의 데이터 가용성을 확장하도록 설계된 "샤딩된 Blob 트랜잭션"이라는 새로운 트랜잭션 형식을 도입합니다. 이 제안은 EVM 실행으로는 액세스할 수 없지만 약속에는 액세스할 수 있는 대량의 데이터를 포함하는 "블롭 운반 트랜잭션"을 도입함으로써 작동합니다. 이 형식은 향후 전체 샤딩에서 사용되는 형식과 완벽하게 호환되므로 롤링 확장에 대해 일시적이지만 상당한 완화를 제공합니다.

EIP-5656

4. EIP-5656에는 메모리 영역의 효율적인 복사를 위한 새로운 EVM 명령어 MCOPY가 도입되었습니다. 본 제안은 EVM에서 메모리 복사 작업을 수행하는 오버헤드를 줄이고 MCOPY 명령을 통해 메모리 간 데이터를 직접 복사하는 것을 목표로 합니다. MCOPY는 소스 및 대상 주소가 겹치는 것을 허용하며 이전 버전과의 호환성을 염두에 두고 설계되었으며 데이터 구조 구성, 효율적인 액세스 및 메모리 개체 복사를 포함한 다양한 시나리오에서 실행 효율성을 향상시키는 것을 목표로 합니다.

EIP-6780

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

EIP-7516

6. EIP-7516에는 현재 블록 실행에서 Blob 기본 수수료 값을 반환하는 데 사용되는 새로운 EVM 명령어 BLOBBASEFEE가 도입되었습니다. 이 명령어는 EIP-4844에 정의된 대로 Blob 기본 수수료를 반환한다는 점을 제외하면 EIP-3198의 BASEFEE opcode와 유사합니다. 이 기능을 사용하면 계약이 Blob 데이터의 가스 가격을 프로그래밍 방식으로 고려할 수 있습니다. 예를 들어 롤업 계약이 Blob 데이터 사용 비용을 신뢰할 수 없게 계산하거나 이를 기반으로 Blob 가스 선물을 구현하여 Blob 데이터 비용을 원활하게 할 수 있습니다.

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

   EIP-1153

   스마트 계약 개발자는 사용하기 전에 임시 저장 변수의 수명 주기를 이해해야 합니다. 임시 저장소는 거래가 끝나면 자동으로 지워지기 때문에 스마트 계약 개발자는 가스를 절약하기 위해 호출 중에 슬롯을 지우는 것을 피하려고 노력할 수 있습니다. 그러나 이로 인해 동일한 트랜잭션 내에서 계약과의 추가 상호 작용이 방해되거나(예: 재진입 잠금의 경우) 다른 오류가 발생할 수 있으므로 스마트 계약 개발자는 예약할 때 비임시 저장소 슬롯만 예약하도록 주의해야 합니다. 값이 0입니다. 동일한 트랜잭션 내에서 향후 호출에 사용하기 위한 것입니다. SSTORE 그렇지 않으면 이러한 opcode는 SLOAD 및 SLOAD 와 똑같이 동작하므로 특히 재진입 위험과 관련하여 모든 일반적인 보안 고려 사항이 적용됩니다.

   스마트 계약 개발자는 메모리 매핑 대신 임시 저장소를 사용하려고 시도할 수도 있습니다. 호출이 반환되거나 재개될 때 임시 저장소는 메모리처럼 폐기되지 않는다는 점을 알아야 하며, 동일한 트랜잭션 내에서 재진입 시 예기치 않은 동작을 방지하려면 이러한 사용 사례에서 메모리를 선호해야 합니다. 메모리에 대한 일시적인 저장 비용은 필연적으로 높기 때문에 이러한 사용 패턴을 억제해야 합니다. 대부분의 인메모리 매핑 사용은 키순으로 정렬된 항목 목록으로 더 잘 구현되며, 스마트 계약에서는 인메모리 매핑이 거의 필요하지 않습니다(즉, 작성자는 프로덕션에서 알려진 사용 사례를 알지 못합니다).

   EIP-4844

   이 EIP는 대역폭 요구 사항을 비콘 블록당 최대 약 0.75MB까지 늘립니다. 이는 오늘날의 블록의 이론적 최대 크기(30M 가스/호출 데이터 바이트당 16가스 = 1.875M 바이트)보다 40% 더 크므로 최악의 경우 대역폭을 크게 늘리지는 않습니다. 병합 후 블록 시간은 예측할 수 없는 포아송 분포가 아닌 정적이므로 대규모 블록 전파를 위한 보장된 시간을 제공합니다.

   제한된 통화 데이터가 있더라도 이 EIP의 지속적인 부하는 로드가 실행되는 한 블롭을 저장할 필요가 없기 때문에 통화 데이터 비용을 줄이는 대안보다 훨씬 낮습니다. 이를 통해 이러한 Blob을 적어도 일정 기간 동안 유지해야 하는 정책을 구현할 수 있습니다. 선택된 특정 값은 MIN_EPOCHS_FOR_BLOB_SIDECARS_REQUESTS 에포크이며, 이는 약 18일입니다. 이는 페이로드 기록 실행을 위한 권장(아직 구현되지 않음) 1년 순환에 비해 훨씬 짧은 지연입니다.

   EIP-5656

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

   그렇지 않으면 메모리 확장이 동일한 가격 책정 규칙을 따르기 때문에 DoS(서비스 거부) 및 메모리 고갈 공격 분석은 메모리를 다루는 다른 opcode와 동일합니다.

   EIP-6780

   다음 애플리케이션 SELFDESTRUCT는 손상될 것이며 이 방식으로 이를 사용하는 애플리케이션은 더 이상 안전하지 않습니다.

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

   SELFDESTRUCT 계약을 수혜자로 지정하여 Ether 소각에 의존하는 계약의 경우 동일한 거래에서 계약이 생성되지 않습니다.

   스마트 계약과 관련된 위험

   EIP1153

   opcode TLOAD 및 TSTORE를 사용하는 두 가지 시나리오를 고려하십시오.

   1. 호출된 계약이 이 opcode를 사용합니다.
   2. 호출 계약이 이 opcode를 사용합니다

   위험 1:

   기존 계약과 비교 SSTORE와 SLOAD는 주로 데이터의 저장 기간을 변경합니다. tstore에 저장된 데이터는 sstore에 작성된 계약이 아닌 트랜잭션 실행 후에 해제됩니다. 영구적으로 기록됩니다. 개발자는 데이터가 계약에 잘못 기록되어 손실을 초래할 수 있는 잘못된 사용을 방지하기 위해 이 opcode를 사용할 때 이 opcode의 특성을 인식해야 합니다. 또한 tstore의 데이터는 개인 변수이며 계약 자체에서만 액세스할 수 있습니다. 데이터를 외부에서 사용하려면 매개변수 형식으로 전달하거나 공용 스토리지 변수에 임시 저장해야만 합니다.

   위험 2:

   또 다른 잠재적 위험은 스마트 계약 개발자가 임시 저장 변수의 수명 주기를 적절하게 관리하지 않으면 데이터가 삭제되거나 잘못 유지될 수 있다는 것입니다. 계약이 트랜잭션에 대한 후속 호출에서 임시 저장소에 저장된 데이터를 사용할 것으로 예상하지만 이 데이터의 수명 주기를 적절하게 관리하지 못하는 경우 호출 간에 데이터가 잘못 공유되거나 손실되어 논리 오류 또는 보안 취약점이 발생할 수 있습니다. 토큰 프로젝트와 유사한 잔액 또는 수당 데이터를 올바르게 저장할 수 없다는 점을 고려하면 계약 논리 오류가 발생하고 손실이 발생합니다. 또는 소유자 주소를 설정할 때 이 opcode를 사용하면 권한 있는 주소가 올바르게 기록되지 않아 계약의 중요한 매개변수 수정 사항이 손실됩니다.

   임시 저장소를 사용하여 암호화폐 거래소에 거래 가격을 일시적으로 기록하는 스마트 계약을 생각해 보세요. 계약은 각 거래가 완료될 때 가격을 업데이트하고 사용자가 짧은 기간 동안 최신 가격을 쿼리할 수 있도록 합니다. 그러나 계약 설계가 트랜잭션이 끝날 때 임시 저장소가 자동으로 지워지는 기능을 고려하지 않으면 사용자는 한 트랜잭션이 끝날 때부터 다음 트랜잭션이 시작될 때까지 기간 동안 부정확하거나 오래된 트랜잭션을 받을 수 있습니다. 거래 가격. 이는 사용자가 잘못된 정보에 기초하여 결정을 내릴 수 있을 뿐만 아니라 악의적으로 사용될 수도 있어 플랫폼의 신뢰성과 사용자 자산의 보안에 영향을 미칠 수 있습니다.

   EIP-6780

   이 제안은 이전 selfdestruct opcode의 동작을 변경합니다. 계약은 파기되지 않고 토큰만 전송되며 self destruct와 동일한 트랜잭션에서 생성된 계약만 파기됩니다. 이 EIP의 영향은 상대적으로 큽니다.

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

   스마트 계약의 SELFDESTRUCT 작업을 사용하면 계약을 파기하고 계약 잔액을 지정된 대상 주소로 보낼 수 있습니다. 이 경우 컨트랙트는 SELFDESTRUCT를 사용하여 이더를 파기하고 파기된 이더를 컨트랙트에 보냅니다. 단, 계약은 동일한 거래에서 생성된 계약(본 계약 또는 동일한 거래에서 다른 계약에 의해 생성된 계약)만 가능합니다. 그렇지 않으면 계약을 파기하지 않고 이더만 전송됩니다(예를 들어 이더가 자멸하고 수혜자가 자파 계약인 경우 아무런 변경 사항도 발생하지 않습니다). 이는 출금이나 기타 작업을 위해 자체 소멸을 사용하는 모든 계약에 영향을 미칩니다.

   1인치 CHI 토큰과 유사한 가스 토큰은 오프셋을 유지하고 항상 이 오프셋에서 CREATE2 또는 SELFDESTRUCT를 실행하여 작동합니다. 이번 업데이트 이후 현재 오프셋의 계약이 올바르게 자체 소멸되지 않으면 후속 CREATE2가 계약을 성공적으로 배포할 수 없습니다.

   이 제안의 구현은 계약에 대한 직접적인 공격으로 이어지지는 않지만, 자체 파괴 작업에 의존하는 원래 배포된 계약의 정상적인 논리를 손상시킬 것입니다(자금 이체를 위해 자체 파괴에만 의존하는 계약은 영향을 받지 않습니다. 후속 작업에서 자체 파괴가 필요한 경우 파괴된 계약이 삭제되면 영향을 받게 되며 계약과 사용자에게만 계약이 예기치 않게 작동하게 되어 계약이 파업되고 자금 손실 및 기타 위험이 발생할 수 있습니다. 예를 들어 원래 create2를 사용하여 원래 주소에 새 계약을 배포하면 원래 계약이 자동으로 파괴됩니다. 업그레이드된 계약은 더 이상 성공적으로 배포될 수 없습니다. 장기적으로 opcode의 기능을 수정하면 중앙 집중화 문제가 발생할 수 있습니다.

   예를 들어, 기존 재무 계약 금고가 업데이트됩니다.

   • create2 임시 저장 계약을 사용하여 금고에 자금을 임시로 확보합니다.

   • 금고 계약을 자멸하고 자금이 임시 계약으로 이체됩니다. (계약을 파기하지 않고 자금만 이체) )

   • 원래 주소에 새로운 Vault 계약 2개 생성 (원래 Vault 계약이 파기되지 않아 실패)

   • 임시 계약을 자폭하고 자금을 반환 볼트(자금이 손실되고 볼트 계약이 생성되지 않음)

   확장 읽기

   칸쿤 업그레이드는 이더리움의 경쟁 우위를 더욱 강화할 것입니다. 그러나 이번 업그레이드는 핵심 스마트 계약 계층의 변경에 위험을 가져오며, 이는 기존 DApp의 안전한 운영에 영향을 미칠 것입니다. 스마트 계약을 개발하는 동안 이러한 변화와 이로 인해 발생할 수 있는 위험에도 큰 주의가 필요합니다. 위험 검토 또는 감사 지원을 위해 Salus에 문의하거나 자세한 내용을 읽어 변경 사항에 대해 알아볼 수 있습니다.

위 내용은 칸쿤에서 업그레이드하기 전 중요한 안전 점검의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!