정수 오버플로 및 언더플로 취약성은 무엇이며 SafeMath는 이를 어떻게 방지할 수 있습니까?

스마트 계약의 정수 오버플로 및 언더플로 이해

1. 블록체인 개발, 특히 Solidity로 작성된 Ethereum 스마트 계약 내에서 산술 연산은 부호 없는 정수에 대해 직접 실행됩니다. 계산이 데이터 유형이 보유할 수 있는 최대값을 초과하면 정수 오버플로가 발생합니다. 예를 들어 uint8 변수가 255를 보유하고 1씩 증가하면 256이 되는 대신 0으로 돌아갑니다.

2. 반대로, 빼기 연산 결과가 표현 가능한 최소 값보다 낮은 값이 되면 정수 언더플로가 발생합니다. uint8 변수가 0을 포함하고 1씩 감소하면 255로 줄바꿈됩니다. 이러한 동작은 EVM(Ethereum Virtual Machine)에서 낮은 수준의 산술이 작동하는 방식에서 비롯되며 EVM은 이러한 경계 위반을 자동으로 확인하지 않습니다.

3. 이러한 취약점은 악의적으로 악용될 수 있습니다. 공격자는 토큰 잔액을 조작하거나, 소유권을 부풀리거나, 의도하지 않은 논리 흐름을 촉발할 수 있습니다. BeautyChain 토큰에서 잘 알려진 사례가 발생했습니다. 오버플로로 인해 공격자가 막대한 양의 토큰을 생성하여 경제를 불안정하게 만들었습니다.

4. 이러한 결함은 특정 입력에 의해 트리거될 때까지 코드에 휴면 상태로 있는 경우가 많습니다. 일반적인 EVM 실행에서는 런타임 오류가 발생하지 않기 때문에 기본 테스트 중에는 보이지 않는 상태로 유지됩니다. 이들의 존재는 분산 애플리케이션 내에서 금융 운영의 무결성을 훼손합니다.

5. 그 영향은 개별 계약을 넘어 확장됩니다. 오버플로 또는 언더플로를 기반으로 한 악용은 사용자 신뢰를 약화시키고 자금 손실을 초래하며 영향을 받는 프로토콜을 기반으로 구축된 전체 플랫폼의 평판을 손상시킬 수 있습니다.

위험 완화에 있어 SafeMath 라이브러리의 역할

1. 이러한 위험을 해결하기 위해 SafeMath 라이브러리가 방어 프로그래밍 도구로 도입되었습니다. 연산을 수행하기 전에 명시적인 검사를 포함하는 덧셈, 뺄셈, 곱셈, 나눗셈을 위한 래퍼 기능을 제공합니다.

2. SafeMath.add(a, b)를 사용할 때 함수는 먼저 합계가 주어진 유형의 최대값을 초과하지 않는지 확인합니다. 결과가 오버플로되면 require 문을 통해 트랜잭션이 되돌려져 실행이 방지됩니다.

3. 마찬가지로 SafeMath.sub(a, b)는 빼기 전에 a가 b보다 크거나 같은지 확인합니다. 그렇지 않은 경우 작업이 되돌아가서 잔액 추적 또는 액세스 제어 메커니즘을 손상시킬 수 있는 잠재적인 언더플로 시나리오를 중지합니다.

4. SafeMath.mul(a, b)는 큰 수를 곱할 때 발생하는 오버플로 조건을 확인합니다. 두 피연산자가 개별적으로 안전해 보이더라도 특히 승수를 기반으로 토큰 발행과 같은 확장 작업에서 해당 제품이 저장 용량 제한을 초과할 수 있습니다.

5. 되돌리기 조건을 통해 산술적 안전성을 강화함으로써 SafeMath는 전체 공격 클래스를 효과적으로 제거합니다. 여러 차례의 세간의 이목을 끄는 해킹으로 인해 금융 논리에서 입력 검증의 필요성이 강조된 후 채택이 널리 퍼졌습니다.

산술 보호 장치의 통합 및 발전

1. 개발자는 라이브러리를 가져오고 'using' 지시문을 사용하여 이를 uint 유형에 연결하여 SafeMath를 통합합니다. 적용되면 표준 연산자는 계약 범위 전체에서 자동으로 확인된 연산자로 대체됩니다.

2. SafeMath는 최소한의 가스 오버헤드를 추가하지만 보안상의 이점은 비용보다 훨씬 큽니다. 각 확인에는 추가 계산이 필요하지만 이러한 투자는 되돌릴 수 없는 자산 손실을 초래할 수 있는 치명적인 오류로부터 보호합니다.

3. 최신 버전의 Solidity(0.8.0부터 시작)에는 오버플로 및 언더플로 검사가 기본적으로 언어에 통합되어 있습니다. 이는 이제 산술 연산이 외부 라이브러리 없이도 기본적으로 되돌려져 최신 코드베이스에서 SafeMath에 대한 의존도가 줄어든다는 것을 의미합니다.

4. 기본 지원에도 불구하고 많은 레거시 시스템은 이전 버전과의 호환성 요구 사항으로 인해 여전히 SafeMath에 의존합니다. 감사자는 취약성 평가의 일환으로 이전 계약에 누락된 SafeMath 사용이 있는지 정기적으로 검사합니다.

5. 보다 안전한 기본값으로의 전환은 광범위한 업계 학습을 반영합니다. 한때 수동 개입이 필요했던 것이 이제는 컴파일러 동작에 포함되어 실제 공격이 어떻게 언어 디자인 및 개발자 도구의 개선을 주도하는지 보여줍니다.

산술 보호 장치를 적절하게 사용하면 잔액 및 여유분과 같은 중요한 값의 무단 조작을 방지하여 분산형 애플리케이션의 경제 모델을 보존할 수 있습니다.

자주 묻는 질문

SafeMath 검사가 실패하면 어떻게 됩니까? SafeMath 연산이 안전하지 않은 산술 조건을 감지하면 되돌리기가 트리거됩니다. 이렇게 하면 트랜잭션이 취소되고 실행이 시작되기 전의 상태로 복원되어 변경 사항이 영구적으로 기록되지 않습니다.

부호 있는 정수에서도 오버플로가 발생할 수 있나요? 예, 부호 있는 정수도 취약합니다. 작업에 따라 음수 범위로 오버플로되거나 양수 범위로 언더플로될 수 있습니다. 잔액 추적에서는 덜 일반적이지만 제어 논리 및 인덱싱에서는 유사한 위험을 초래합니다.

Solidity 0.8+에서도 SafeMath가 여전히 필요합니까? 대부분의 경우에는 그렇지 않습니다. Solidity 0.8 이상에는 모든 산술 연산에 대한 오버플로 및 언더플로 보호 기능이 내장되어 있습니다. 그러나 개발자는 명확한 명확성을 위해 또는 확인되지 않은 블록으로 작업할 때 여전히 SafeMath를 사용할 수 있습니다.

SafeMath와 관련된 성능 비용이 있습니까? 각 SafeMath 기능에는 원시 연산에 비해 추가 가스를 소비하는 조건부 검사가 포함되어 있습니다. 작업당 증가폭은 작지만 루프 또는 잦은 업데이트와 관련된 복잡한 계산으로 인해 누적될 수 있습니다.