초록: 2025년 11월 3일, 탈중앙화 거래소 Balancer V2는 역사상 가장 심각한 보안 사고를 겪었으며, 1억 1,660만 달러에서 1억 2,860만 달러에 달하는 자산이 도난당했습니다. 공격자는 Balancer V2의 스왑/불균형 메커니즘과 관련된 스마트 계약의 취약점을 악용하여 이더 메인넷, Arbitrum, Base, Optimism을 포함한 온체인 유동성 풀에서 자금을 성공적으로 클레임. 이 공격은 Balancer V2 아키텍처의 오랜 보안 취약점을 노출했을 뿐만 아니라 크로스 체인 프로토콜 배포의 시스템 리스크 드러냈습니다. 이 공격의 핵심 취약점은 Balancer V2의 스마트 계약 검사 메커니즘의 결함, 특히 스왑 작업 및 풀 잔액 상태 처리 시 검증 부족과 관련이 있었습니다. 반면, Balancer V3는 일시적 저장(EIP-1153), 개선된 Vault 아키텍처, 그리고 더욱 엄격한 보안 메커니즘을 도입하여 이 공격의 영향을 성공적으로 회피했습니다. 공격자는 주로 Balancer V2가 서로 다른 블록체인 온체인 동일한 스마트 계약 코드를 배포했기 때문에 온체인 동시에 공격을 시작할 수 있었고, 이로 인해 모든 배포 환경에서 동일한 취약점이 악용될 수 있었습니다.I. 소개 1.1 배경 개요 Balancer는 DeFi 생태계에서 중요한 자동 마켓메이커(AMM)(AMM) 프로토콜로, 2020년 출시 이후 탈중앙화 금융을 위한 중요한 유동성 인프라를 제공합니다.프로그래밍 가능한 유동성 프로토콜인 Balancer를 사용하면 사용자가 최대 8개의 서로 다른 토큰을 포함하는 사용자 지정 풀을 만들 수 있으며 유연한 가중치를 지원합니다.공격 전에 Balancer는 총 잠금 가치(TVL)에서 7억 5천만 달러 이상을 관리했으며, 이 중 3억 5천만 달러 이상이 이더 메인넷에 보관되었습니다.그러나 2025년 11월 3일 이른 아침, 블록체인 보안 회사 PeckShield가 비정상적인 자금 유출을 처음 감지했고, 이후 Nansen을 포함한 여러 보안 기관이 Balancer V2가 대규모 공격을 받고 있음을 확인했습니다. 초기 보고서에는 7,090만 달러의 손실이 표시되었지만 공격이 계속되면서 최종 추정 손실은 1억 1,660만 달러에서 1억 2,860만 달러 사이로 증가하여 2025년 DeFi 공간에서 가장 심각한 보안 사고 중 하나가 되었습니다. 도난당한 자산에는 주로 6,851 osETH(약 2,686만 달러), 6,590 WETH(약 2,450만 달러), 4,260 wstETH(약 1,930만 달러)가 포함되었습니다. 1.2 분석 목표 이 보고서는 Balancer V2 공격에 대한 포괄적인 기술적 분석을 제공하고 스마트 계약 취약성의 근본 원인, 공격 메커니즘, 크로스체인 전파 경로 및 다른 DeFi 취약성과의 상관 관계를 탐구하는 것을 목표로 합니다. Balancer V2와 V3의 아키텍처적 차이점에 대한 체계적인 분석을 통해 V3가 이 공격을 피할 수 있었던 이유를 밝히고 DeFi 프로토콜의 향후 보안 설계에 대한 귀중한 참고 자료를 제공합니다. 또한 이 보고서는 취약성 수정의 기술적 복잡성을 평가하고 실행 가능한 솔루션과 예방 조치를 제안합니다.1.3 연구 방법론 이 연구는 블록체인 보안 회사의 실시간 모니터링 데이터, 공식적인 사고 후 보고서, 학술 연구 결과 및 과거 취약성 사례를 통합하는 다중 소스 정보 종합 분석 방법을 사용합니다.Balancer의 다양한 버전의 스마트 계약 코드를 비교 및 분석하고, 온체인 거래 기록을 검토하고, AMM 프로토콜과 유사한 보안 이벤트를 연구하여 포괄적인 기술 분석 프레임 구축했습니다.이 연구에서는 PeckShield, SlowMist 및 BlockSec과 같은 권위 있는 보안 기관의 분석 보고서와 Balancer의 공식 문서 및 기술 백서 참조했습니다.II. Balancer V2 스마트 계약 취약성의 기술적 세부 사항 2.1 Balancer V2 핵심 아키텍처 개요 Balancer V2가 2021년에 출시되었을 때 혁신적인 아키텍처 디자인을 도입했습니다.핵심 혁신은 토큰 관리를 풀 로직에서 완전히 분리한 데 있습니다. 이 설계는 모든 Balancer 풀의 중앙 허브 역할을 하는 단일 Vault 컨트랙트를 통해 구현되며, 모든 토큰 보유, 회계 및 이체 작업을 관리합니다. 이러한 "관심사 분리" 아키텍처는 민감한 토큰 작업이 엄격하게 감사 컨트랙트에 중앙 집중화되므로 이론적으로 더 높은 보안과 효율성을 제공합니다. Balancer V2의 3계층 아키텍처에서 Router 컨트랙트는 프로토콜의 진입점 역할을 하며, 사용자 거래 요청을 수신하여 Vault로 라우팅합니다. Vault 컨트랙트는 모든 풀의 토큰 잔액 원장을 관리하고, delegatecall을 사용하여 특정 풀 컨트랙트를 호출하여 스왑 계산을 수행합니다. 풀 컨트랙트 자체는 토큰을 보유하지 않으며, 특정 가격 곡선 로직(예: 가중 풀의 상수 곱 공식 또는 안정 풀의 StableSwap 불변식) 구현만 담당합니다. 이 설계를 통해 Balancer는 가중 풀, 안정 풀, 선형 풀, 구성 가능한 안정 풀 등 다양한 풀 유형을 지원할 수 있습니다. 2.2 스왑 메커니즘 및 불균형 문제 Balancer V2의 스왑 메커니즘은 전체 프로토콜의 핵심 기능으로, 사용자가 풀 내에서 두 토큰을 교환할 수 있도록 합니다. 일반적인 작동에서 스왑 기능은 풀의 불변 공식에 따라 주고받을 토큰 수를 계산한 다음 Vault의 내부 원장을 업데이트합니다. 그러나 이처럼 간단해 보이는 프로세스는 실제로 복잡한 상태 관리 문제를 숨기고 있으며, 특히 멀티홉 트랜잭션 및 일괄 스왑을 처리할 때 더욱 그렇습니다. 이 공격은 2023년 Balancer가 발견한 반올림 오류 취약점과 유사한 스왑 작업의 유효성 검사 결함을 악용했을 가능성이 높습니다. 2023년 공격에서 공격자는 선형 풀이 매우 적은 양의 토큰 스왑을 처리할 때 일부 출력 값이 반올림으로 인해 0으로 처리되지만 해당 입력 토큰은 여전히 풀의 가상 잔액 에 추가된다는 사실을 발견했습니다. 이러한 비대칭성을 통해 공격자는 풀에 일방적으로 가치를 추가하여 환율을 조작할 수 있었습니다. 2023년 취약점은 당시 패치되었지만, 2025년 공격은 Balancer V2의 핵심 스왑 메커니즘에 유사하거나 관련된 결함이 존재할 가능성을 시사했습니다. 불균형 메커니즘은 원래 스왑 작업 후에도 풀이 불변 상태를 유지하도록 설계되었지만, 실제로는 경계 조건을 부적절하게 처리하는 데 문제가 있을 수 있습니다. 특수 유형의 토큰(이자 발생 토큰, 리베이스드 토큰 또는 디플레이션 토큰 등)을 처리할 때 풀의 내부 원장이 실제 토큰 잔액 과 다를 수 있습니다. 공격자는 이러한 편차를 악용하여 신중하게 제작된 거래 시퀀스를 통해 풀의 상태를 조작하여 궁극적으로 실제 기여도 이상의 가치를 클레임 할 수 있습니다. 2.3 결함 있는 스마트 계약 확인 기능 예비 보고서에 따르면 이 공격의 근본 원인은 "잘못된 스마트 계약 확인"이었습니다. 이 설명은 Balancer V2의 스왑 작업 적법성 검증에 결함이 있음을 나타냅니다. 견고한 AMM 구현에서는 풀의 핵심 속성이 유지되도록 각 상태 변경 후 엄격한 불변성 검사를 수행해야 합니다. 그러나 Balancer V2 구현은 특정 중요 지점에서 이러한 검사를 생략하거나 약화시켰을 수 있습니다. 특히 다음과 같은 영역에서 문제가 발생할 수 있습니다. 첫째, Vault는 batchSwap 작업을 처리할 때 여러 풀 간의 순 토큰 흐름을 추적해야 합니다. 이 복잡한 결제 프로세스에서 검증 단계가 실패하면 공격자는 겉보기에 합법적인 거래 시퀀스를 구성하여 실제로는 풀 불변성을 위반할 수 있습니다. 둘째, 선형 풀과 구성 가능한 안정 풀 간의 상호 작용에는 복잡한 환율 계산 및 가상 공급량 관리가 수반됩니다. 이러한 계산에서 정밀도 문제나 경계 조건의 잘못된 처리가 악용될 수 있습니다. 셋째, Vault의 토큰 잔액 캐싱 메커니즘은 경우에 따라 오래된 데이터를 반환하여 후속 작업이 잘못된 상태를 기반으로 수행되도록 할 수 있습니다. 과거 취약성 분석 결과, 2020년 Balancer가 겪었던 디플레이션 토큰 공격은 근본적인 문제를 드러냈습니다. 프로토콜은 모든 ERC20 토큰 transferFrom 작업이 지정된 정확한 금액을 이체한다고 가정하지만, 실제로는 일부 토큰에 이체 수수료가 부과됩니다. 이 특정 문제는 해결되었지만, 유사한 "가설 기반" 패턴이 다른 곳에서 다시 나타날 수 있습니다. 2025년 공격은 특정 예외 사례에 대한 잘못된 가정을 포함하고 있었으며, 공격자가 신중하게 조작된 입력값으로 보안 검사를 우회할 수 있도록 했습니다. 2.4 공격 흐름 재구성 온체인 거래 데이터와 보안 기관의 분석을 기반으로 공격의 전반적인 흐름을 재구성할 수 있습니다. 공격자는 먼저 dYdX와 같은 플랫폼에서 거액의 플래시 론(Flash loan) 받아 실제 자산을 소유하지 않고도 단일 거래에서 막대한 금액을 조작할 수 있습니다. 다음으로, 공격자는 Vault의 batchSwap 기능을 사용하여 겉보기에 정상으로 보이는 일련의 스왑 작업을 신중하게 구성하여 실제로 유효성 검사 결함을 악용합니다. 공격의 핵심은 풀의 내부 상태를 조작하여 실제 토큰 잔액 과 불일치를 만드는 것입니다. 이는 다음과 같은 방법으로 달성할 수 있습니다. 첫째, 특정 토큰 조합과 스왑 경로를 사용하여 Vault의 경계 조건을 트리거하여 특정 유효성 검사를 우회하거나 잘못된 결과를 반환합니다. 둘째, 선형 또는 구성 가능한 안정 풀의 환율 계산 결함을 악용하여 매우 작거나 큰 스왑 볼륨을 통해 반올림 오류를 발생시켰습니다. 셋째, 여러 풀 간에 순환 스왑 경로를 구축하여 서로 다른 풀 간의 환율 차이와 시간 지연을 악용하여 수익을 증폭시켰습니다. 공격자는 풀 상태를 성공적으로 조작한 후, 실제 예치금보다 더 많은 금액을 클레임 하여 인출했습니다. 이러한 명백히 불균형한 거래는 Vault의 최종 정산 확인 결함으로 인해 검증을 통과했습니다. 마지막으로, 공격자는 플래시 론(Flash loan) 상환하고 도난당한 자산을 새로 생성된 지갑 주소로 이체했습니다. 특히, 이 지갑에는 공격 전에 가스 요금 지불에 사용된 ETH 잔액 없었는데, 이는 공격자가 일반적인 가스 요금 지불 요건을 우회하기 위해 대량 작업이나 메타 트랜잭션을 사용했음을 시사합니다. 2.5 과거 취약점의 관련성 Balancer의 보안 이력은 이 공격을 이해하는 데 중요한 맥락을 제공합니다. 2020년 6월 발생한 디플레이션 토큰 공격은 Balancer의 첫 번째 주요 보안 사고였으며, 약 50만 달러의 손실을 초래했습니다. 공격자는 Balancer의 ERC20 토큰 전송 동작에서 잘못된 가정을 악용했습니다. 프로토콜은 transferFrom(amount)이 항상 정확한 양의 토큰을 전송하지만 디플레이션 토큰(예: STA)은 각 전송에서 1%의 수수료를 공제한다고 가정합니다. 공격자는 WETH와 STA를 반복적으로 교환하여 풀의 STA 잔액 점차 고갈시키는 동시에 내부 원장과 실제 잔액 의 불일치를 악용하여 환율을 조작했습니다. 2023년 8월의 반올림 오류 취약점은 더 정교한 공격 벡터를 나타냅니다. 이 취약점은 Balancer V2의 Boosted Pools에 영향을 미쳤는데, 공격자는 선형 풀에서 매우 작은 스왑을 수행할 때 반올림으로 인해 출력 금액이 0이 될 수 있지만 입력 토큰은 여전히 가상 잔액 증가시킬 수 있음을 발견했습니다. 이를 악용하여 공격자는 BPT(Balancer 풀 토큰)의 환율을 조작하여 시장 가격보다 낮은 가격으로 풀의 자산을 획득할 수 있었습니다. 이 공격으로 약 210만 달러의 손실이 발생했으며, Balancer 자체도 100만 달러, 포크 프로토콜인 Beethoven X도 110만 달러의 손실을 입었습니다. 2025년 11월에 발생한 공격은 이러한 기존 취약점의 진화 또는 조합으로 추정됩니다. 공격자는 유사한 원장 불일치 또는 환율 조작을 유발하는 새로운 방법을 발견했거나, 이전에 발견되지 않은 경계 조건을 발견했을 수 있습니다. 중요한 것은 Balancer 팀이 각 공격 후 수정 사항을 적용했지만, 기본 아키텍처의 일부 근본적인 결함이 완전히 해결되지 않은 것으로 보인다는 점입니다. 이는 문제가 단순히 특정 코드 버그가 아니라 V2 아키텍처 설계의 시스템적 취약점과 관련이 있을 수 있음을 시사합니다. III. Balancer V2와 V3의 보안 차이점 비교 3.1 Balancer V3 아키텍처 혁신 Balancer V3는 프로토콜 설계 철학의 근본적인 변화를 나타냅니다. 2024년 말에 출시된 Balancer V3는 V2에 누적된 기술 채무 와 보안 취약점을 해결하는 것을 목표로 합니다. V3의 핵심 개선 사항은 더욱 표준화된 Vault 아키텍처, 임시 저장에 대한 기본 지원, 그리고 더욱 강력한 보안 메커니즘을 중심으로 합니다. 이러한 개선 사항은 프로토콜의 성능과 유연성을 향상시킬 뿐만 아니라, 더 중요한 것은 보안을 근본적으로 강화합니다. V3의 가장 중요한 혁신은 EIP-1153에서 도입된 임시 저장 기능을 완전히 도입한 것입니다. 이 새로운 저장 메커니즘은 TLOAD 및 TSTORE 명령어를 사용하여 단일 트랜잭션의 수명 주기 내에 데이터를 유지하고 트랜잭션 종료 후 자동으로 삭제할 수 있도록 합니다. 기존의 영구 저장 방식과 비교했을 때, 임시 저장은 가스 비용을 크게 절감하고, 더 중요한 것은 특정 유형의 재진입 공격을 자연스럽게 방지한다는 것입니다. V3에서는 모든 중간 트랜잭션 상태가 임시 저장을 통해 추적되므로 외부 계약이 트랜잭션 실행 중에 불일치 상태를 읽는 것을 불가능하게 하여 특정 공격 벡터를 근본적으로 차단합니다. 또한 V3는 단일 트랜잭션 내에서 일련의 작업에 걸쳐 순 잔액 변화를 추적하고 트랜잭션 종료 시에만 최종 정산을 수행하는 "til" 모드 회계 시스템을 도입했습니다. 이 접근 방식은 가스 효율성을 향상시킬 뿐만 아니라 모든 중간 상태 변경의 원자성을 보장하여 보안을 강화합니다. 트랜잭션의 어느 단계든 실패하면 전체 작업 시퀀스가 롤백되어 일관성 없는 상태가 남지 않습니다. 이는 V2의 특정 상황에서 발생할 수 있는 부분 실행 문제와 극명한 대조를 이룹니다. 3.2 핵심 보안 메커니즘 비교 토큰 잔액 관리 측면에서 V2와 V3는 근본적으로 다른 접근 방식을 사용합니다. V2의 Vault는 각 풀의 토큰 잔액 독립적인 매핑으로 저장하고 정교한 캐싱 메커니즘을 사용하여 가스 소비를 최적화합니다. 그러나 이 캐싱 메커니즘은 특정 경계 사례, 특히 이자 발생 토큰이나 리베이스드 토큰을 처리할 때 만료된 데이터를 반환할 수 있습니다. V3는 Vault 자체를 다중 토큰 ERC20 계약으로 구현하여 모든 Balancer 풀 토큰(BPT)을 기본적으로 관리함으로써 기반 풀 토큰 잔액 및 BPT 공급에 대한 업데이트의 원자성을 보장합니다. 이러한 설계는 V2에서 발생할 수 있는 동기화되지 않은 잔액 및 공급의 창을 제거합니다. 재진입 보호 측면에서 V3의 접근 방식은 더욱 포괄적이고 현대적입니다. V2는 재진입 공격을 방지하기 위해 기존의 nonReentrant 수정자를 사용하지만, 이 접근 방식에는 미묘한 취약점이 있습니다. 바로 "읽기 전용 재진입"입니다. 외부 프로토콜이 Vault가 "잠금 해제"된 상태에서 공개 쿼리 함수를 호출하여 일관되지 않은 중간 상태를 읽고 잘못된 가격 정보를 기반으로 결정을 내릴 수 있습니다. V3는 일시적인 저장 플래그와 더욱 엄격한 상태 검사를 통해 이러한 공격 경로를 완벽하게 차단합니다. 트랜잭션 실행 중 Vault 상태를 쿼리하려는 모든 작업은 명시적으로 쿼리 패턴을 사용하지 않는 한 거부됩니다. 환율과 정밀도 처리 또한 V3의 또 다른 핵심 차별화 요소입니다. V2는 소수점 이하 자릿수가 다른 토큰을 정규화하기 위해 스케일링 계수를 사용하지만, 이러한 변환으로 인해 극단적인 경우 정밀도 손실이나 오버플로가 발생할 수 있습니다. V3의 Vault는 계산을 위해 모든 토큰 잔액 소수점 이하 18자리까지 자동으로 스케일링하며, 환율 제공자와 긴밀하게 통합되어 유동성 스테이킹 토큰(LST)과 같은 이자 발생 자산을 기본적으로 지원합니다. 더 중요한 것은 V3가 모든 수학 연산에서 "프로토콜 우선" 반올림 전략을 구현한다는 것입니다. 출력 금액은 내림(과다 지불 방지)하고 입력 금액은 올림(과소 지불 방지)합니다. 이 간단하지만 중요한 원칙은 전체 코드베이스에 적용되어 2023년과 같은 반올림 오류 취약점의 재발을 효과적으로 방지합니다. 3.3 V3가 이 공격을 어떻게 방어했는가? V3가 이 공격에서 살아남을 수 있었던 것은 주로 다층적인 보안 강화 덕분입니다. 첫째, 일시적인 회계 시스템은 _supplyCredit(), _takeDebt(), _accountDelta() 함수를 통해 모든 거래의 모든 토큰 흐름을 엄격하게 추적합니다. 이러한 함수들은 거래 종료 시 모든 토큰의 순 변동이 0이 되도록 보장합니다. 불균형이 발생하면 거래가 롤백됩니다. V2에 존재할 수 있는 검증 결함은 V3에서 이 필수 최종 검사를 통해 제거됩니다. 둘째, V3의 Vault는 각 풀 작업의 주요 지점에서, 특히 Hooks를 실행한 후에 풀 잔액 과 환율을 다시 계산합니다. 이를 통해 악의적이거나 결함이 있는 Hooks가 재진입이나 상태 조작을 통해 메인 풀 로직을 공격하는 것을 방지합니다. 이와 관련하여 V2의 방어는 약하여, 특수하게 조작된 특정 상호작용 시퀀스가 검증을 우회할 수 있습니다. 셋째, V3는 최소 거래 금액 한도(_MINIMUM_TRADE_AMOUNT 및 _MINIMUM_WRAP_AMOUNT)를 도입하여 매우 작은 거래를 통해 반올림 오류나 경계 조건을 유발하는 공격을 방지합니다. 이 간단하면서도 효과적인 방어는 V2가 역사상 반복적으로 마주쳤던 미세 조작 공격을 직접 해결합니다. 마지막으로, V3 코드베이스는 보다 체계적인 보안 감사 와 공식 검증을 거쳤습니다. 프로토콜 팀은 V3 출시 전에 커뮤니티 검토를 위해 코드베이스를 공개했으며, 여러 최고 보안 회사와 경쟁 감사 위해 협력했습니다. 이러한 "보안 우선" 개발 문화와 V2의 과거 취약점에서 얻은 교훈 덕분에 V3는 설계 단계에서 잠재적인 보안 위험을 피할 수 있었습니다. 3.4 업그레이드 경로 및 호환성 문제 V3는 상당한 보안 이점을 제공하지만, V2에서 V3로의 마이그레이션은 단순한 컨트랙트 업그레이드가 아니라 완전한 프로토콜 재배포 및 유동성 마이그레이션을 요구합니다. 이 과정에는 여러 가지 과제가 있습니다. 첫째, V2와 V3는 API 및 데이터 구조 측면에서 호환되지 않으며, Balancer를 통합하는 DeFi 애플리케이션은 V3를 지원하기 위해 대량 코드 수정이 필요합니다. 둘째, 유동성 공급자는 V2 풀에서 자금을 인출하여 V3 풀에 다시 입금해야 하는데, 이 과정에서 거래 비용과 일시적인 유동성 파편화가 발생합니다. 더 심각한 문제는 V2 풀의 일시 중지 불가 특성입니다. Balancer V2는 "일시 중지 창" 메커니즘을 구현하여 긴급 취약점이 발견되면 풀 작업을 일시 중지하고 사용자가 자금을 인출할 수 있도록 합니다. 그러나 이 창은 일정 기간이 지나면 만료되며, 그 이후에는 풀을 일시 중지할 수 없습니다. 더욱이, 이전 풀 유형(일부 선형 풀 등)은 일시 정지 기능을 전혀 지원하지 않습니다. 즉, 취약점이 발견되면 프로토콜 팀은 모든 사용자 자금에 대한 보호를 시행할 수 없으며, 사용자가 자금을 신속하게 인출하기만 기대할 수 있습니다. 2025년 공격은 이러한 오래되고 일시 정지가 불가능한 풀을 악용했을 가능성이 높습니다. 기술적 관점에서 가장 철저한 해결책은 V2를 완전히 폐기하고 모든 유동성을 V3로 강제 이전하는 것입니다. 그러나 프로토콜 팀이 사용자 행동을 강제할 수 없기 때문에 탈중앙화 환경에서는 이러한 목표를 달성하기 어렵습니다. 더 현실적인 해결책은 V2에 긴급 패치를 구현하는 것입니다. 이는 아키텍처상의 취약점을 완전히 제거할 수는 없지만, 적어도 알려진 공격 벡터를 차단할 수 있습니다. 한편, 토큰 보상이나 더 높은 거래 수수료 공유와 같은 인센티브는 유동성 공급자가 자발적으로 V3로 이전하도록 유도합니다. IV. 크로스체인 공격 메커니즘 분석 4.1 Balancer의 크로스체인 배포 아키텍처 Balancer는 멀티체인 프로토콜로서 이더 메인넷, Arbitrum, Optimism, Base, Polygon, Avalanche를 포함한 여러 블록체인 네트워크에 V2 버전을 배포합니다. 이 멀티체인 전략은 다양한 네트워크의 장점을 활용하는 것을 목표로 합니다. 이더 최고의 보안성과 유동성을 제공하고, Arbitrum 및 Optimism과 같은 레이어 2 네트워크는 낮은 거래 비용을 제공하며, Polygon 및 Avalanche와 같은 다른 체인은 특정 사용자 커뮤니티와 애플리케이션 생태계를 유치합니다. 기술적으로 Balancer는 각 온체인 에 독립적이지만 거의 동일한 스마트 계약 인스턴스를 배포합니다. 이러한 "복사 및 붙여넣기" 배포 모델은 개발 및 유지 관리를 간소화하기 때문에 DeFi 분야에서 매우 일반적입니다. 동일한 감사 코드를 여러 네트워크에서 재사용할 수 있어 이론적으로 일관된 보안을 보장합니다. Vault 계약, Pool 계약 및 Router 계약의 바이트코드는 여러 온체인 에서 거의 동일하며, 배포 매개변수(예: 초기 유동성 또는 거버넌스 주소)에는 약간의 차이가 있습니다. 이 아키텍처의 핵심 특징은 체인 간의 독립성입니다. 온체인 각 Balancer 인스턴스는 자체적인 독립적인 유동성 풀과 토큰 잔액 가지며, 서로 직접 통신하지 않습니다. 이더 의 Balancer 풀에 있는 사용자의 유동성 점유율 크로스 체인 브리지를 통해 전송되지 않는 한 Arbitrum에서 직접 사용할 수 없습니다. 이러한 격리는 일반적인 상황에서는 리스크 확산을 제한하는 데 도움이 되지만, 스마트 계약 수준의 취약점 대면 하면 이러한 독립성은 시스템적인 취약점으로 작용합니다. 4.2 동일 소스 코드의 시스템 리스크 이 공격의 가장 심각한 특징은 여러 블록체인에 동시에 영향을 미칠 수 있다는 것입니다. 공격자는 각 체인마다 다른 익스플로잇을 개발할 필요가 없습니다. 대신, Balancer V2가 배포된 모든 네트워크에서 거의 동일한 공격 스크립트를 사용하여 반복적으로 실행할 수 있습니다. 이 "한 번 빌드하면 모든 곳에서 공격 가능" 모델은 크로스 체인 배포에서 동일한 코드를 사용하는 관행에서 비롯됩니다. 핵심 코드 로직에 스마트 계약 취약점이 존재하는 경우, 해당 취약점은 동일한 코드를 사용하는 모든 배포 인스턴스에 복제됩니다. Balancer V2의 경우, 이더 볼트 컨트랙트와 아비트럼 볼트 컨트랙트 모두 동일한 스왑 검증 취약점을 포함하고 있습니다. 공격자가 이더 메인넷을 표적으로 하는 익스플로잇을 발견하고 검증하면, 대상 컨트랙트 주소를 수정하고 가스 매개변수를 조정하는 것만으로 온체인 동일한 공격을 반복할 수 있습니다. 이러한 시스템 리스크 기존 소프트웨어 보안에서 "단일 장애 지점"으로 알려져 있지만, 블록체인 환경에서는 그 영향이 훨씬 더 큽니다. 스마트 컨트랙트의 불변성으로 인해 온체인 취약점이 발견되고 해결책이 개발되더라도 모든 온체인 에 신속하게 적용할 수 없습니다. 각 체인은 새로운 버전의 컨트랙트를 독립적으로 배포하고 유동성을 이전해야 하는데, 이 과정에는 며칠 또는 몇 주가 걸릴 수 있습니다. 이 기간 동안 공격자는 패치 온체인 계속해서 익스플로잇을 시도할 충분한 시간을 확보할 수 있습니다. 더 심각한 것은, 크로스 체인 공격이 동시에 발생하면 재정적 손실이 증폭된다는 것입니다. 취약점이 단일 블록체인에만 영향을 미치는 경우, 공격자는 온체인 가용 유동성과 가스 비용에 의해 제한을 받습니다. 그러나 공격이 온체인 동시에 실행될 수 있는 경우 총 손실은 단일 체인의 손실보다 몇 배에 달할 수 있습니다. Balancer 공격에서 이더 메인넷이 가장 큰 손실(약 9,100만 달러)을 입었지만 Arbitrum, Base 및 Optimism에서 발생한 추가 손실로 총액이 1억 달러를 넘어섰습니다. 4.3 공격자의 크로스 체인 조정 전략 온체인 데이터 분석에 따르면 공격자는 높은 수준의 기술력과 꼼꼼한 계획을 보여주었습니다. 공격은 온체인 거의 동시에 시작되었으며, 이는 공격자가 자동화된 스크립트나 봇 네트워크를 사용하여 작업을 조정했음을 나타냅니다. 이러한 조정은 프로토콜 팀이 온체인 공격이 감지되면 온체인 방어 조치(예: 풀 중단 또는 사용자 경고)를 구현할 수 있으므로 수익을 극대화하는 데 중요합니다. 공격자는 공격 논리의 정확성과 신뢰성을 보장하기 위해 온체인 먼저 익스플로잇을 검증했을 가능성이 높습니다. 이후, 그들은 실시간 모니터링 시스템의 탐지 리스크 줄이기 위해 유동성이 상대적으로 낮은 시기에 공격을 시작했습니다. 공격 트랜잭션의 구성은 공격자들이 Balancer V2의 내부 메커니즘을 깊이 이해하고 있었으며, 이를 통해 취약점을 유발하는 데 필요한 토큰 수와 거래 순서를 정확하게 계산할 수 있었음을 시사합니다. 특히 주목할 점은 공격자들이 가스 최적화에 집중했다는 점입니다. 가스 비용이 높은 이더 메인넷과 같은 환경에서 공격자들은 일괄 처리, 플래시 론(Flash loan) 의 효율적인 사용, 간소화된 계약 호출 체인 등 다양한 기법을 사용하여 거래 비용을 절감했습니다. 레이어 2 네트워크에서는 가스 비용이 더 낮지만, 공격자들은 각 공격의 이익율 극대화하기 위해 거래 구조를 최적화했습니다. 이러한 전문성은 공격이 단일 해커가 아닌 숙련된 팀에 의해 조직되었을 가능성을 시사합니다. 공격 후 자금 이체 전략 또한 크로스체인 사고방식을 보여줍니다. 도난당한 자산은 새로 생성된 여러 지갑 주소로 빠르게 분산된 후 다양한 경로를 통해 세탁되었습니다. 일부 자금은 기존 온체인 에 남아 탈중앙화 거래소 통해 교환되었고, 다른 자금은 크로스 체인 브리지를 통해 다른 네트워크로 이체되었습니다. 이러한 분산 전략은 자금 추적 및 동결 어렵게 만들고 공격자에게 여러 수익화 채널을 제공합니다. 4.4 크로스 체인 프로토콜의 보안 거버넌스 과제 이 공격은 보안 거버넌스 측면에서 크로스 체인 프로토콜이 직면한 고유한 과제를 보여줍니다. 단일 체인 환경에서는 프로토콜 팀이 하나의 네트워크 상태를 모니터링하고 이상 징후에 신속하게 대응할 수 있습니다. 그러나 멀티체인 환경에서는 모니터링 리소스가 분산되고 공격 표면이 기하급수적으로 확장됩니다. Balancer 팀은 각각 고유한 블록 시간, 거래 패턴 및 사용자 행동 특성을 가진 12개 이상의 블록체인 네트워크를 동시에 모니터링해야 합니다. 크로스 체인 환경에서는 사고 대응 메커니즘도 더욱 복잡합니다. 온체인 공격이 탐지되면 팀은 모든 체인이 위협받고 있는지 신속하게 평가하고 멀티체인 방어 조치를 조율해야 합니다. 그러나 앞서 언급했듯이 일부 레거시 풀에는 일시 중지 기능이 없어 프로토콜 수준의 글로벌 방어가 불가능합니다. 팀은 소셜 미디어와 프런트엔드 알림을 통해서만 사용자에게 알릴 수 있지만, 사용자 주도성에 대한 이러한 의존성은 빠르게 진화하는 공격 시나리오에서 효과가 제한적입니다. 크로스 체인 환경에서 코드 업그레이드와 패치 배포는 마찬가지로 어렵습니다. 취약점을 수정하기 위해 새로운 버전의 계약이 개발되더라도 온체인 배포하려면 대량 작업과 조정이 필요합니다. 각 체인은 배포 요구 사항, 가스 가격 변동 및 네트워크 혼잡이 다를 수 있습니다. 더 중요한 것은 업그레이드를 위해 모든 온체인 에 대한 거버넌스 투표가 필요하며(프로토콜이 탈중앙화 거버넌스를 사용하는 경우), 거버넌스 참여 및 투표 속도는 온체인 크게 다를 수 있다는 것입니다. 장기적으로 DeFi 업계는 크로스 체인 배포의 과제를 해결하기 위해 새로운 보안 패러다임을 개발해야 합니다. 몇 가지 가능한 방향은 다음과 같습니다. 온체인 이상 동작을 감지하고 다른 온체인 에서 자동으로 방어 조치를 트리거할 수 있는 크로스 체인 모니터링 및 경고 시스템 구현, 배포 전에 스마트 계약을 수학적으로 증명하는 공식 검증 도구 개발, 모든 온체인 에서 핵심 보안 속성이 충족되는지 확인; 다양한 프로토콜이 위협 정보와 방어 전략을 공유할 수 있도록 크로스체인 보안 동맹을 구축하고, 업그레이드 가능한 프록시 계약을 통해 모든 온체인 에 보안 패치를 신속하게 적용할 수 있는 모듈 식 아키텍처를 모색합니다. V. 유사 DeFi 프로토콜의 취약점 사례 연구 5.1 AMM 프로토콜의 일반적인 보안 문제 AMM (자동 마켓메이커(AMM)) 프로토콜은 DeFi 생태계에서 핵심적인 역할을 하지만, 복잡한 수학적 논리와 상태 관리로 인해 공격자의 주요 표적이 됩니다. Balancer, Uniswap, Curve와 같은 주요 AMM 프로토콜의 과거 취약점을 분석함으로써, AMM 모델 자체의 고유한 복잡성에 기인하는 여러 가지 반복적인 보안 문제를 파악할 수 있습니다. 재진입 공격은 AMM 프로토콜에 대한 가장 지속적인 위협 중 하나입니다. 재진입 공격이라는 개념은 DAO 공격 이후 널리 알려져 있지만, AMM의 특수성으로 인해 방어가 더욱 복잡해집니다. 2023년, Balancer는 "읽기 전용 재진입"이라는 특정 형태의 재진입 공격을 받았습니다. 이 공격에서 악성 계약은 상태를 수정하는 함수를 다시 입력하는 대신, Vault가 일관되지 않은 상태에 있을 때 읽기 전용 쿼리 함수(예: getPoolTokens)를 호출합니다. Balancer 풀을 가격 오라클 로 사용하는 외부 프로토콜은 잘못된 가격 데이터를 읽어 자체 프로토콜의 잘못된 결정을 초래할 수 있습니다. Curve Finance가 2023년에 발견한 Vyper 컴파일러 취약점은 본질적으로 재진입 문제였습니다. 컴파일러 버그로 인해 여러 함수의 @nonreentrant 데코레이터가 독립적인 잠금을 사용하여 함수 간 재진입이 가능해졌습니다. 정밀도 손실과 반올림 오류는 또 다른 심각한 위협입니다. AMM 프로토콜은 대량 나눗셈 및 곱셈 연산을 포함하므로 소수점 이하 자릿수가 다른 토큰을 처리할 때 단위 변환이 필요합니다. 2023년 Balancer의 Boosted Pools 공격에서 공격자는 극소량을 처리할 때 선형 풀의 반올림 동작을 악용하여 BPT 환율을 체계적으로 조작했습니다. 마찬가지로, 벨로드롬 프로토콜(Velodrome Protocol)은 불변량 계산 시 반올림 오류로 인해 공격을 받았습니다. x*y가 1e18보다 작을 때, 중간 변수가 0으로 초기화되어 곱 상수 검증이 실패하고 공격자가 풀을 비울 수 있게 되었습니다. 이러한 사례들은 사소해 보이는 정밀도 처리 문제조차도 잘 설계된 공격 시퀀스에서 심각한 취약점으로 확대될 수 있음을 보여줍니다. 가격 조작은 AMM 프로토콜이 대면 구조적 문제입니다. 풀의 가격은 전적으로 내부 토큰의 비율에 의해 결정되기 때문에, 이 비율을 크게 변경할 수 있는 모든 조작은 가격 변동을 유발할 수 있습니다. 이러한 편차는 일반적으로 차익거래자에 의해 신속하게 수정되지만, 공격자는 특정 상황에서 이 짧은 시간을 악용할 수 있습니다. 플래시 론(Flash loan) 공격자가 풀의 상태에 일시적으로 영향을 미치는 데 대량 자본이 필요하지 않기 때문에 가격 조작 공격에 대한 방어력을 크게 낮춥니다. 2023년 PancakeSwap BH 토큰 사건에서 공격자는 플래시 론(Flash loan) 사용하여 매우 낮은 가격으로 BH를 교환한 다음 특정 풀에서 부풀려진 가격으로 유동성을 클레임 127만 달러의 이익을 얻었습니다.5.2 Curve Finance Vyper 컴파일러 취약점 심도 비교 2023년 7월 Curve Finance에 대한 공격은 컴파일러 수준 취약점의 영향을 이해하는 데 중요한 사례 연구를 제공합니다.이 공격의 근본 원인은 Curve 프로토콜의 코드 로직 자체가 아니라 Vyper 컴파일러(버전 v0.2.15, v0.2.16 및 v0.3.0)의 심각한 버그에 있습니다.이 버그로 인해 개발자가 지정한 키에 따라 잠금을 공유하는 대신 `@nonreentrant` 데코레이터를 사용하는 모든 함수에 독립적인 스토리지 슬롯이 할당됩니다.즉, 두 함수가 동일한 재진입 잠금을 사용한다고 선언하더라도 컴파일러가 실제로는 이에 대해 독립적인 잠금을 만들어 함수 간 재진입이 가능해집니다. 공격자는 이 취약점을 악용하여 여러 Curve 유동성 풀, 특히 pETH/ETH 풀을 공격했습니다. 공격 흐름은 먼저 풀의 `remove_liquidity` 함수를 호출하여 사용자에게 ETH를 전송합니다(외부 호출 트리거). 이 외부 호출의 콜백에서 공격자는 `add_liquidity` 함수를 다시 호출하여 호출합니다. 두 함수 모두 `@nonreentrant("lock")` 데코레이터를 사용하지만, 컴파일러 버그로 인해 실제로는 서로 다른 잠금을 사용하므로 두 번째 호출은 차단되지 않습니다. `remove_liquidity`를 사용하여 상태를 업데이트하기 전에 `add_liquidity` 함수를 다시 호출함으로써 공격자는 오래된 상태를 기반으로 풀을 조작하여 궁극적으로 pETH/ETH 풀에서 약 1,100만 달러를 훔칠 수 있었습니다. 이 사례는 Balancer 상황과 몇 가지 중요한 유사점과 함의를 공유합니다. 첫째, 두 공격 모두 겉보기에 강력한 보안 메커니즘(Curve의 재진입 잠금 및 Balancer의 검증 검사)을 사용하지만, 실제 구현에는 결함이 있습니다. 둘째, 두 취약점 모두 경계 조건이나 기반 툴체인 관련 문제가 있기 때문에 정기적인 감사 로는 쉽게 탐지되지 않습니다. 셋째, 두 공격 모두 공격자가 플래시 론(Flash loan) 과 정교한 거래 시퀀스를 활용하여 현대 DeFi 환경에서 취약점의 영향을 증폭시키는 방법을 보여줍니다. 그러나 Curve 사례는 중요한 차이점도 드러냅니다. 취약점이 애플리케이션 코드가 아닌 컴파일러에서 발생하는 경우, 수정 과정이 훨씬 더 복잡해집니다. Curve 팀은 Vyper 커뮤니티에서 수정 사항이 공개될 때까지 기다린 후, 영향을 받는 모든 컨트랙트를 다시 컴파일하고 배포해야 했습니다. 반면, Balancer V2 취약점이 기반 툴이 아닌 컨트랙트 로직에서 발생하는 경우, 이론적으로 패치를 훨씬 더 빠르게 개발하고 배포할 수 있습니다. 그러나 수정 섹션에서 논의하겠지만, Balancer V2는 업그레이드가 불가능하고 일시 중지 기간이 만료되었기 때문에 문제가 발견되더라도 신속하게 수정하기 어렵습니다. 5.3 크로스 체인 브리지 공격의 교훈 Balancer 자체는 크로스 체인 브리지가 아니지만, 크로스 체인 브리지에 대한 공격은 크로스 체인 배포의 보안 리스크 이해하는 데 귀중한 교훈을 제공합니다. 2022년 3월 로닌 브리지 공격은 암호화폐 역사상 가장 큰 해킹 사건 중 하나로, 6억 2천만 달러의 손실을 초래했습니다. 공격자는 소셜 엔지니어링 및 피싱 공격을 통해 9개의 검증자 개인 키 중 5개를 획득하여 브리지의 다중 서명 메커니즘을 제어했습니다. 가장 충격적인 것은 공격이 발생한 지 6일 만에 발견되었다는 점입니다. 이는 공격자가 자금을 이체하고 세탁할 충분한 시간을 제공했습니다. 2022년 2월 웜홀 브리지에 대한 3억 2천만 달러 규모의 공격은 스마트 계약 검증 로직의 결함에서 비롯되었습니다. 공격자는 브리지의 서명 검증 기능을 우회하여 솔라나에서 무담보 wETH 토큰을 민트 할 수 있다는 것을 발견했습니다. 이 취약점의 근본 원인은 솔라나의 고유한 프로그래밍 모델에 대한 부적절한 가정에 있으며, 이는 크로스 체인 배포 시 발생하는 주요 리스크 을 부각시킵니다. 서로 다른 블록체인 간의 실행 환경 및 보안 모델 차이로 인해 한 온체인 에서 안전한 코드가 다른 체인 온체인 취약해질 수 있습니다. 2022년 8월 노마드 브리지 공격은 "혼란스러운 강도"를 보여주었습니다. 계약 업그레이드의 초기화 오류로 인해 누구든 브리지에서 자금을 클레임 할 수 있었습니다. 첫 번째 공격자가 취약점을 발견하고 악용한 후, 그들의 거래는 블록체인 온체인 공개적으로 노출되었고, 수백 명의 모방범(MEV 봇과 일반 사용자 포함)이 이를 모방하여 결국 몇 시간 만에 약 2억 달러의 손실을 초래했습니다. 이 사례는 블록체인의 투명한 환경에서 취약점이 공개적으로 악용되면 그 영향이 빠르게 확산될 수 있음을 보여줍니다. 이러한 크로스 체인 브리지 사례는 밸런서 공격을 이해하는 데 몇 가지 통찰력을 제공합니다. 첫째, 개인 키 관리가 밸런서 문제의 근본 원인은 아니지만, 중앙 집중식 제어 지점의 리스크 부각합니다. Balancer의 일부 관리 기능(예: 일시 중지 풀)에는 특권 액세스가 필요하며, 이러한 권한이 남용되거나 유출되면 심각한 결과를 초래할 수 있습니다.둘째, 스마트 계약 검증 로직의 중요성은 두 가지 유형의 프로토콜 모두에서 매우 중요합니다.브리지의 서명 검증이든 AMM의 스왑 검증이든 모든 결함이 악용될 수 있습니다.셋째, 사전 예방적 모니터링과 신속한 대응의 가치는 과장될 수 없습니다.Ronin Bridge에 더 나은 모니터링 시스템이 있었다면 손실을 크게 줄일 수 있었을 것입니다.5.4 디플레이션 토큰과 비표준 ERC20의 지속적인 과제 Balancer가 2020년에 겪은 디플레이션 토큰 공격은 프로토콜의 첫 번째 주요 보안 사고일 뿐만 아니라 전체 DeFi 공간이 대면 지속적인 과제, 즉 비표준 ERC20 토큰을 안전하게 처리하는 방법이기도 했습니다. 이론적으로 ERC20 표준은 토큰 계약의 작동 방식을 정의하지만, 실제로 많은 토큰은 DeFi 프로토콜의 가정과 호환되지 않을 수 있는 다양한 비표준 특성을 구현합니다. 디플레이션 토큰 외에도 DeFi 프로토콜은 다양한 비표준 토큰 유형을 처리해야 합니다. 리베이스 토큰(예: Ampleforth)은 모든 보유자의 잔액 주기적으로 조정하는데, 이로 인해 AMM 풀의 내부 원장과 실제 잔액 간의 불일치가 발생할 수 있습니다. 거래 수수료가 있는 토큰(예: 일부 거버넌스 토큰)은 디플레이션 토큰과 유사하지만 메커니즘이 다른 각 거래에서 일정 비율을 차감합니다. 이중 주소 토큰(예: TUSD)은 동일한 자산을 가리키는 여러 계약 주소를 가질 수 있으며, 이로 인해 프로토콜이 이를 다른 토큰으로 잘못 처리할 수 있습니다. 일부 토큰의 transfer 또는 transferFrom 함수는 부울 값을 반환하지 않거나 항상 true를 반환합니다(작업 성공 여부와 관계없이). 이는 ERC20 표준을 위반하지만 여전히 널리 사용되고 있습니다. Uniswap V3는 문서에서 특정 유형의 비표준 토큰, 특히 이체 수수료가 있는 토큰을 지원하지 않는다고 명시적으로 명시하고 있습니다. 프로토콜의 라우터 계약은 transferFrom이 지정된 금액을 정확히 이체한다고 가정합니다. 실제 이체가 예상보다 적으면 이후 스왑 계산이 부정확해집니다. 마찬가지로, Uniswap V3 풀에서 리베이스된 토큰을 사용할 수 있지만, 풀이 잔액 변화를 자동으로 반영하지 않기 때문에 유동성 공급자는 돌이킬 수 없는 손실을 입을 수 있습니다. 이러한 사례는 근본적인 보안 원칙을 강조합니다. 즉, 외부 종속성에 대해 검증되지 않은 가정을 하지 않아야 한다는 것입니다. 스마트 컨트랙트 환경에서는 "신뢰하되 검증하라"는 것만으로는 충분하지 않습니다. 프로토콜은 "신뢰하지 않고 검증을 강제해야 한다"는 것입니다. 토큰 상호 작용의 경우, 요청된 금액과 같다고 가정하는 대신 각 transferFrom 이후에 실제 이체 금액을 확인해야 합니다. 잔액 조회의 경우, 리베이스 또는 기타 잔액 변경 메커니즘의 가능성을 고려해야 합니다. 외부 호출의 경우, 잠재적으로 재진입이 가능하다고 가정하고 이에 따른 방어 수단을 구현해야 합니다. Balancer V3는 이러한 측면에서 상당한 개선을 이루었습니다. V3는 OpenZeppelin의 SafeERC20 라이브러리를 사용하여 모든 토큰 상호작용에 대해 추가적인 보안 검사를 수행합니다. 또한 이 프로토콜은 토큰 허용 목록 및 리스크 평가 시스템을 도입하여 거버넌스가 지원되는 토큰 유형을 제어할 수 있도록 합니다. 더 중요한 것은 V3의 아키텍처가 ERC4626 래퍼를 통해 수익 토큰과 리베이스 토큰을 기본적으로 지원하여 비표준 동작을 올바르게 처리하고 프로토콜이 안전하게 처리할 수 있는 표준 인터페이스로 변환한다는 것입니다. 5.5 정밀 엔지니어링: 과소평가된 공격 벡터 DeFi 분야에서 정밀 손실 및 반올림 오류 공격이 만연하는 것은 우려스러운데, 이는 이러한 공격이 종종 "진짜" 보안 취약점으로 간주되지 않기 때문입니다. 개발자는 극히 적은 금액으로 인해 약간의 wei를 잃는 것은 용인될 수 있다고 생각할 수 있지만, 공격자는 수천 또는 수백만 개의 작은 손실을 통해 상당한 이익을 축적할 수 있습니다. Balancer 2023 공격은 이러한 사고방식에 대한 전형적인 반례로, 공격자가 반올림 오류를 체계적으로 악용하여 200만 달러 이상의 손실을 초래했습니다. 정밀도 문제의 근본 원인은 종종 Solidity 언어 자체의 한계에 있습니다. Solidity는 부동 소수점 연산을 지원하지 않습니다. 모든 소수는 정수(10의 거듭제곱)로 표현해야 합니다. 나눗셈을 수행할 때 결과는 반올림 대신 잘라내어 기본 반내림 동작이 발생합니다. 이는 단순한 단일 단계 계산에서는 중요하지 않을 수 있지만, 복잡한 다단계 알고리즘(예: AMM의 가격 책정 공식)에서는 오류가 누적되거나 증폭될 수 있습니다. Balancer V2의 특정 리스크 지원되는 뛰어난 유연성에서 비롯됩니다. 이 프로토콜은 최대 8개의 토큰을 포함하는 풀을 생성할 수 있으며, 각 토큰은 잠재적으로 서로 다른 소수 자릿수(0에서 18 이상)를 가집니다. 계산에 여러 토큰의 스왑이 포함되는 경우, 프로토콜은 여러 번의 단위 변환을 요구하며, 각 단위 변환은 정밀도 손실 지점이 될 수 있습니다. 공격자는 특정 토큰 조합과 스왑 경로를 통해 이러한 손실을 극대화하여 풀에서 체계적으로 가치를 클레임 할 수 있습니다. 정밀도 공격을 방어하려면 다층적인 접근 방식이 필요합니다. 첫째, 수학 공식을 설계할 때 정밀도의 영향을 고려하여 중간 계산 단계를 최소화하는 알고리즘을 선택해야 합니다. 둘째, 일관된 반올림 전략을 구현하여 반올림 방향이 사용자(또는 공격자)가 아닌 프로토콜에 항상 유리하도록 해야 합니다. Balancer V3의 "프로토콜 우선 반올림" 원칙이 이러한 접근 방식을 구현합니다. 셋째, 매우 적은 양으로 인해 경계 조건이 발생하는 것을 방지하기 위해 최소 연산량 임계값을 설정합니다. 넷째, 더 높은 정밀도의 중간 계산(예: 최종 결과가 128비트만 필요하더라도 계산에 256비트 정수 사용)을 사용하고 마지막 단계에서만 반올림합니다. 정형 검증은 정확도 문제를 감지하는 데 특히 중요합니다. 수학적 증명을 통해 극단적인 경계 조건을 포함하여 모든 가능한 입력에서 프로토콜의 특정 불변량이 유지되는지 확인할 수 있습니다. 예를 들어, 특정 벤치마크를 기준으로 측정된 풀의 총 가치는 예상 비용을 제외하고 어떤 스왑 시퀀스 이후에도 감소하지 않음을 증명할 수 있습니다. 이 불변량이 매우 적은 양이라도 위반되면 정형 검증 도구가 이를 감지하고 보고합니다. 2025년 11월 3일 - 작성자 X @OutageVictfzev 이 글을 만드는 건 쉽지 않았습니다. 좋아요를 눌러 주시고 공유해 주세요.
