DeFi 생태계의 급속한 발전과 함께 이 분야의 선구자 중 하나인Compound Finance V2는 혁신적인 대출 모델로 많은 사용자를 끌어 모았습니다. 그러나 복잡한 분산 애플리케이션은 잠재적인 보안 위협에 직면해 있으며, 특히 수백만 달러, 심지어 수억 달러에 달하는 자금 흐름이 관련된 경우 더욱 그렇습니다. 따라서 Complex Finance V2 및 포크된 프로젝트에 대해 포괄적이고 상세한 보안 감사를 수행하는 것이 특히 중요합니다. 이 매뉴얼은 개발자, 보안 연구원 및 DeFi 애호가에게 자세한 보안 감사 가이드를 제공하여 모든 사람이 잠재적인 위험을 보다 효과적으로 식별하고 예방할 수 있도록 돕는 것을 목표로 합니다.

1. 사업배경 개요

컴파운드 파이낸스 V2(Compound Finance V2)는 이더리움 블록체인을 기반으로 구축된 개방형 대출 플랫폼으로, 사용자는 다양한 ERC-20 기본 토큰을 예치하고 이에 대한 이자를 받을 수 있으며, 이자 지불 형태로 시장에서 토큰을 빌릴 수도 있습니다. "이자율 시장"이라는 개념을 도입하여 분산형 자본 풀 관리 및 자동화된 이자율 조정 메커니즘을 실현합니다.

2. 프로젝트 구조 분석

Compound Finance V2의 핵심 아키텍처 구성 요소는 다음과 같습니다.

2.1 컨트롤러

감사관 계약은 각 cToken 인스턴스의 동작을 조정하는 역할을 하는 복합 금융 V2의 중추 신경계입니다. 주요 책임은 다음과 같습니다.

2.2 c토큰

지원되는 각 ERC-20 토큰에는 토큰과 프로젝트 간의 모든 상호 작용을 처리하는 데 사용되는 해당 cToken 인스턴스(예: CErc20 / CEther 계약)가 있습니다. 기본 토큰 전송 기능을 구현하는 것 외에도 각 cToken은 대출, 이자 축적, 보상 분배와 같은 일부 화합물별 기능을 추가합니다. 따라서 cToken은 사용자가 컴파운드에 자산을 예치하기 위한 인증서이자 사용자가 대출 작업을 수행하기 위한 입구라고 생각할 수 있습니다.

사용자가 계약에 기초 자산 토큰을 입금하면 해당 cToken 토큰이 발행될 수 있습니다. cToken과 기초 자산 간의 교환 비율은 다음 공식에 따라 계산됩니다.

참고: 차입금은 차입 금액, 현금은 자금 풀 잔액, 준비금은 준비금을 나타냅니다. 대출이자율은 이용률에 따라 결정되며, 예금이자율은 대출이자율에 따라 결정됩니다.

사용자는 일반적으로 다양한 cToken 계약과 상호 작용하여 다양한 시장에서 토큰 대출 작업을 수행합니다.

2.3 이자율 모델

InterestRateModel 계약은 이자율 계산 방법을 정의합니다. 다양한 시장에서는 각자의 위험 성향과 유동성 요구에 맞게 다양한 유형의 이자율 모델을 사용할 수 있습니다.

컴파운드 V2 시장에서 사용되는 이자율 모델에는 크게 두 가지 유형이 있는데, 하나는 직선 모델이고 다른 하나는 변곡점 모델입니다.

정액모형의 차입이자율 계산식은 다음과 같습니다.

자금 활용률의 계산식은 다음과 같습니다.

예금이자율은 차입이자율에 따라 선형적으로 변합니다.

사용량이 점진적으로 증가한다는 것은 펀드 풀에 있는 자금이 점차 감소한다는 것을 의미하며, 특정 최고점에 도달하면 사용자가 정상적으로 입금 및 대출을 할 수 없게 될 수 있습니다. 이러한 상황을 피하기 위해 컴파운드는 두 번째 이자율 모델인 변곡점 유형을 도입했습니다.

전환점 차입이자율 계산식은 다음과 같습니다.

이용률이 특정 최고점에 도달하면 대출 금리와 예금 금리가 즉시 크게 인상되어 사용자가 예금을 늘리고 대출을 줄이도록 유도하여 이용률을 적절한 범위 내로 제어합니다. 일반적으로 활용률이 80%에 도달할 때).

2.4 가격오라클

PriceOracle 계약은 외부 시장 가격 정보를 획득하고 이를 시스템에서 내부적으로 사용되는 값으로 변환하는 역할을 담당하며, 이는 사용자 포지션의 가치를 정확하게 계산하는 데 중요합니다.

2.5 거버넌스 메커니즘 및 인센티브 모델

컴파운드는 거버넌스 토큰(COMP)을 보유한 사용자가 특정 매개변수 변경이나 새로운 자산 유형 추가와 같은 중요한 결정에 대한 투표에 참여할 수 있도록 하는 고유한 거버넌스 메커니즘을 도입합니다. 컴파운드는 거버넌스 토큰(COMP)을 발행하여 사용자가 플랫폼 활동에 적극적으로 참여할 수 있도록 장려하고 기여자에게 보상을 제공합니다. 자세한 내용은 컴파운드 공식 문서와 코드 저장소를 참고하세요. (https://docs.compound.finance/v2/; https://github.com/compound-finance/compound-protocol)

3. 상호작용 과정

다음으로 간단한 예를 사용하여 Complex Finance V2에서 사용자 상호 작용의 일반적인 프로세스를 설명합니다.

3.1 입금 및 환매 과정

사용자 Alice가 1 WBTC를 컴파운드에 입금해야 하는 경우 cWBTC 계약의 민트 기능을 호출하여 입금합니다. 이 계약은 cToken 계약을 상속합니다. 먼저 mintInternal 함수를 통해 내부적으로 acquireInterest 함수를 호출하여 대출 및 예금 이자율을 업데이트한 다음 mintFresh를 호출하여 특정 캐스팅 작업을 수행합니다.

mintFresh 함수는 외부적으로 Comptroller 계약의 mintAllowed 함수를 호출하여 현재 시장에서 예금이 허용되는지 확인한 다음 doTransferIn 함수를 통해 사용자의 1 WBTC를 계약으로 전송한 다음 해당 수의 cToken 토큰을 사용자에게 발행합니다. 해당 시점의 최신 환율(현재 최신 환율이 0.1이라고 가정하면 Alice는 10 cWBTC 토큰을 받게 됩니다)

Alice가 나중에 자신의 예금을 상환하기로 결정한 경우 상환 기능을 호출하여 cWBTC를 WBTC로 다시 상환할 수 있습니다. 이는 환율이 변경되었을 수 있으며(0.15로 가정), 이는 Alice가 1.5 WBTC를 상환할 수 있음을 의미합니다. 0.5 WBTC는 이자소득입니다.

3.2 차입 및 상환 과정

Alice는 먼저 감사관 계약의 enterMarkets 기능을 호출하여 cWBTC를 담보로 사용할 수 있는 상태로 설정한 다음 돈을 빌릴 수 있어야 합니다.

Alice가 70 USDC를 대출하기로 결정했다고 가정합니다. WBTC의 담보 요소는 0.75이므로 Alice는 WBTC 가치의 최대 75%까지 대출할 수 있으므로 이는 최대 차입 금액을 초과하지 않습니다.

참고: 청산 위험을 피하기 위해 Alice는 버퍼를 유지해야 하며 대출 한도를 완전히 사용하지 않아야 합니다.

Alice는 cUSDC 계약의 차용 함수를 호출합니다. 이 함수는 먼저 차용 및 예금 이자율을 업데이트하기 위해 BorrowInternal 함수 내에서 AccumulateInterest 함수를 호출한 다음, BorrowFresh를 호출하여 특정 차용 작업을 수행합니다.

Comptroller 컨트랙트의 BorrowAllowed 기능을 통해 사용자의 포지션 가치를 확인한 후 대출 데이터를 먼저 기록한 후 doTransferOut 기능을 통해 토큰을 사용자에게 전송합니다.

Comptroller 컨트랙트의 BorrowAllowed 기능을 통해 사용자의 포지션 가치를 확인한 후 대출 데이터를 먼저 기록한 후 doTransferOut 기능을 통해 토큰을 사용자에게 전송합니다.

Alice가 상환해야 하는 경우 cUSDC 계약의 repayBorrow 함수를 호출하여 자신에게 상환하거나 다른 사람이 repayBorrowBehalf 함수를 호출하여 대신 상환하도록 할 수 있습니다.

3.3 청산 과정

WBTC 가격이 크게 하락하여 Alice의 담보 가치가 차용 금액의 75% 미만으로 떨어지면 Alice의 대출 포지션이 청산됩니다.

외부 청산인(예: Bob)은 cUSDC 계약에서 청산 기능 liquidateBorrow를 호출하여 Alice가 부채의 일부를 갚는 데 도움을 줄 수 있습니다. 먼저 liquidateBorrowInternal 함수를 통해 cUSDC의 이자율과 상환에 사용되는 담보 cToken을 동시에 업데이트한 다음 liquidateBorrowFresh를 호출하여 특정 청산 작업을 수행합니다.

Comptroller 컨트랙트의 liquidateBorrowAllowed 함수를 통해 청산 허용 여부를 확인한 후 repayBorrowFresh 함수를 먼저 호출하여 상환용 컨트랙트에 USDC를 이체하고 청산자의 대출 데이터를 업데이트합니다. 그런 다음 감사관 계약의 liquidateCalculateSeizeTokens 함수를 호출하여 Bob이 청산 가치를 기반으로 Alice의 해당 가치를 얻을 수 있는 담보 금액을 계산합니다. 마지막으로 지정된 담보 시장에서 cToken 계약(예: cWBTC)의 압류 기능이 사용됩니다. Bob과 Alice를 위해 cToken을 전송합니다.

위 이미지의 고화질 버전을 보려면 이 링크를 여세요. 원본 텍스트를 읽으려면 클릭하세요: https://www.figma.com/board/POkJlvKlWWc7jSccYMddet/Compound-V2?node-id=0-1&node -유형=캔버스.

Bob은 Alice의 대출금 일부(예: 20 USDC)를 상환하고 그에 상응하는 담보 가치(예: WBTC)를 얻습니다. 동시에 Bob은 추가 청산 인센티브(5%로 가정)도 받을 수 있습니다. 최종 결과는 Bob이 21 USDC 상당의 WBTC(20 USDC 대출 + 1 USDC 청산 인센티브)를 받은 것입니다.

4. 보안 취약점 체크리스트

4.1 빈 시장으로 인한 반올림 취약성

4. 보안 취약점 체크리스트

4.1 빈 시장으로 인한 반올림 취약성

cToken이 빈 시장(즉, 시장에 빌려주는 사용자가 없는 경우)인 경우 exchangeRateStoredInternal 함수의 exchangeRate 값은 해당 계약에 해당하는 기초 자산 토큰 수에 따라 달라지므로 대량의 기초 자산을 전송할 수 있습니다. cToken 가격을 조작하기 위해 cToken 계약에 추가합니다.

따라서 소량의 cToken을 사용하여 대량의 다른 토큰을 빌려준 다음 cToken의 RedUnderlying 함수를 호출하여 기본 자산 토큰을 출금할 수 있습니다. 상환액을 계산할 때 공제해야 하는 cToken 수는 분할 반올림으로 인해 예상보다 훨씬 적은 결과(거의 절반)가 됩니다.

이때 보유하고 있는 cToken의 수는 2개(전체 공급량이기도 함)이고, 조작 후 exchangeRate는 25,015,031,908,500,000,000,000,000,000으로 인상되고, 상환해야 하는 기초 자산 토큰의 수는 50,030,063,815개라고 가정합니다. 그러면 공제되어야 할 예상 cToken 수는 다음과 같아야 합니다.

그러나 실제 계산된 cToken 수는 다음과 같습니다.

그러나 실제 계산된 cToken 수는 다음과 같습니다.

따라서 다른 시장에서 대출받은 많은 수의 자산 토큰을 얻기 위해서는 결국 아주 적은 수의 cToken만 청산하면 됩니다.

이 취약점으로 인해 컴파운드 포크 프로젝트 Hundred Finance의 해킹된 거래를 참조할 수 있습니다: https://optimistic.etherscan.io/tx/0x6e9ebcdebbabda04fa9f2e3bc21ea8b2e4fb4bf4f4670cb8483e2f0b2604f451

감사 포인트: 감사 시 환율 계산 방식이 조작되기 쉬운지, 반올림 방식이 적절한지 주의를 기울여야 하며 동시에 프로젝트팀에 소액을 발행하도록 권장할 수 있습니다. 시장이 비어있고 조작되는 것을 방지하기 위해 새로운 시장이 생성된 직후 cToken을 사용합니다.

4.2 ERC677/ERC777 토큰으로 인한 재진입 취약점

ERC677 / ERC777은 ERC20 계약의 확장이며 ERC20 토큰의 프로토콜 표준과 호환됩니다. 이러한 토큰을 사용하면 전송 프로세스 중에 수신 주소가 계약인 경우 수신 주소의 콜백 함수(예: transferAndCall 또는 tokensReceived)가 트리거됩니다.

이전 버전의 Combined Finance V2 코드에서는 사용자가 cToken 시장에서 돈을 빌릴 때 빌린 토큰이 먼저 이체된 후 대출 데이터가 기록됩니다.

사용자가 빌려준 토큰이 콜백 기능이 있는 ERC677/ERC777 토큰인 경우, 토큰을 받는 악의적인 계약을 구성하면 콜백 함수를 통해 다시 빌리기 기능에 진입하여 다시 빌릴 수 있습니다. 마지막 대출은 아직 데이터가 처리되지 않았으므로 이때 계정 상태 확인을 성공적으로 통과하면 토큰을 다시 대출할 수 있습니다.

이 취약점으로 인해 해킹된 컴파운드 포크 프로젝트 Hundred Finance의 거래를 확인할 수 있습니다: https://blockscout.com/xdai/mainnet/tx/0x534b84f657883ddc1b66a314e8b392feb35024afdec61dfe8e7c510cfac1a098

감사 포인트: 최신 버전의 컴파운드 V2 코드에서는 차용 논리가 수정되었습니다. 대신 차용 데이터가 먼저 기록된 후 차용된 토큰이 전송됩니다. 감사 중에는 대출 기능의 관련 코드가 CEI(Checks-Effects-Interactions) 사양을 준수하는지 여부에 주의가 필요하며, 콜백 기능이 포함된 토큰의 영향도 고려해야 합니다.

4.3 부적절한 오라클 메커니즘으로 인한 가격 조작 위험

4.3 부적절한 오라클 메커니즘으로 인한 가격 조작 위험

복합 금융은 과잉 담보 대출 모델을 채택하기 때문에 사용자가 대출할 수 있는 토큰 수는 담보 가치가 충분한지 여부에 따라 달라집니다.

따라서 프로젝트에서 담보 가치를 계산할 때 사용하는 오라클의 가격 공급 메커니즘을 쉽게 조작할 수 있다면 예상보다 많은 토큰을 쉽게 대출할 수 있을 것입니다.

예를 들어, 컴파운드 포크 프로젝트 Lodestar Finance가 해킹당한 경우, 오라클이 담보 plvGLP 토큰의 가격을 얻은 방법은 먼저 plvGLP 계약의 plsGLP 토큰 수(totalAssets)를 plvGLP의 총 공급량으로 나누는 것이었습니다. ( totalSupply)는 환율을 계산한 다음 환율에 GLP 토큰 가격을 곱하여 plvGLP 토큰 가격을 계산합니다.

plvGLP에는 사용자가 plvGLP 토큰 계약에 대해 해당 plsGLP 토큰을 발행하기 위해 sGLP를 기부할 수 있는 기부 기능이 있습니다.

따라서 공격자는 먼저 플래시 대출을 사용하여 Lodestar Finance 시장에서 대량의 plvGLP 담보 포지션을 생성한 다음 플래시 대출을 사용하여 GMX에서 대량의 sGLP를 발행한 다음 기부 기능을 사용하여 plsGLP 토큰을 발행할 수 있습니다. totalAssets의 가치를 높이기 위한 plvGLP 계약. 총 자산이 증가함에 따라 plvGLP의 환율이 더 커지게 되어 plvGLP 토큰의 가격이 즉각적이고 빠르게 상승하여 다른 토큰이 기대 이상으로 시장에 대출될 수 있게 됩니다.

Lodestar Finance의 해킹된 거래를 참고할 수 있습니다: https://arbiscan.io/tx/0xc523c6307b025ebd9aef155ba792d1ba18d5d83f97c7a846f267d3d9a3004e8c

또한 Complex Finance 또는 그 포크 프로젝트는 담보 가격을 얻기 위해 ChainLink 또는 CoinBase와 같은 오프체인 오라클을 사용할 것이라는 점에도 유의해야 합니다. 심각한 시장 변동이 발생할 경우 오프체인 가격과 온체인 가격 사이에 가격 차이가 발생하여 프로젝트의 재정적 안정성이 위태로워질 수 있습니다.

예를 들어 LUNA 토큰의 가격은 시장 문제로 인해 급락했으며, Combined Finance의 포크된 프로토콜인 Venus Protocol과 Blizz Finance는 모두 Chainlink 오라클을 가격 피드 소스로 사용하여 담보 가치를 계산합니다. minAnswer)는 $0.10 값으로 하드코딩되어 있습니다.

LUNA 토큰의 가격이 $0.1(예: $0.001) 아래로 떨어지면 누구나 시장 가격으로 대량의 LUNA를 구매하고 이를 담보($0.10 상당)로 사용하여 플랫폼의 다른 자산을 빌려줄 수 있습니다.

감사 포인트: 감사 중에는 담보 가치를 계산할 때 사용되는 오라클 가격 공급 메커니즘이 외부에서 쉽게 조작되는지 여부에 주의해야 합니다. 프로젝트 당사자는 다양한 가격 소스를 활용하여 종합적인 평가를 수행하는 것이 좋습니다. 단일 가격 소스로 인한 위험을 방지합니다.

4.4 다중 진입점 토큰으로 인한 환율 조작 위험

컴파운드 코드에는 SweepToken이라는 함수가 있는데, 실수로 컨트랙트에 토큰을 전송한 사용자가 해당 토큰을 출금할 수 있도록 하는 데 사용됩니다. 이전 버전의 코드는 다음과 같습니다. 이 함수에는 중요한 보안 검사가 있습니다. 전달된 토큰 매개변수는 계약의 기본 자산 토큰이 될 수 없습니다.

그러나 특정 cToken 시장의 기초 자산 토큰에 대한 진입점 계약이 여러 개 있는 경우(동일한 기본 잔액은 여러 계약 주소를 통해 접근할 수 있고 외부 상호 작용이 모든 진입점의 잔액에 영향을 미치므로 이는 초기 에이전시와 같습니다. 모델) 공격자는 기본 자산 토큰과 다른 진입점 계약을 전달하여 계약의 기본 자산 토큰을 전송하기 위해weepToken 함수를 호출할 수 있습니다.

아래 예를 들어 TUSD를 사용하면 두 개의 진입점 계약이 있습니다. 보조 진입점 계약 0x8dd5fbce는 모든 통화(예: 전송 또는 BalanceOf)를 기본 계약으로 전달하므로 계약 중 하나와의 상호 작용이 두 계약 모두에 영향을 미칩니다. 의 잔액 데이터(즉, 두 개의 서로 다른 계약이 동일한 잔액 데이터를 공유함).

이때, 시장에 설정된 기본 토큰 주소가 TUSD의 주요 계약 주소라고 가정하면, SweepToken 함수를 호출할 때 보조 진입점 계약 주소 0x8dd5fbce를 수신 토큰 매개변수로 사용할 수 있으며, 주소(토큰) = 기본이 성공적으로 확인되면 계약은 모든 기본 자산 토큰 TUSD를 관리자 주소로 이전합니다.

TUSD/cTUSD의 환율은 cTUSD 계약의 기초자산 토큰인 TUSD의 수량에 따라 영향을 받습니다. 모든 TUSD가 관리자의 주소로 전송되면 TUSD/cTUSD의 환율은 즉시 급락합니다. 이때 공격자는 매우 낮은 환율로 다른 사용자를 청산하거나, 빌린 후 예상 수량보다 적은 양의 토큰을 상환하여 이익을 얻을 수 있습니다.

최신 버전의 Combined V2 코드에서는 관리자 역할만 계약을 호출할 수 있도록 하기 위해weepToken 기능에 권한 확인을 추가했으며 여러 진입점 토큰이 있는 모든 시장을 제거했다는 점을 언급할 가치가 있습니다.

감사 포인트: 감사 중에 계약 내 토큰 전송 기능과 관련하여 다중 진입점 토큰 시나리오가 프로젝트에 미치는 영향을 고려해야 합니다. 프로젝트 당사자는 다중 진입점을 사용하지 않는 것이 좋습니다. 토큰 또는 토큰 전송 전후를 확인하십시오. 계약의 기본 자산 토큰 수가 변경되는지 여부와 관련 기능의 권한을 확인하십시오.

4.5 계약 코드의 이전 버전과 새 버전 간의 호환성 문제

복합 금융 V2 포크 프로젝트에서 핵심 계약의 코드가 새 버전의 복합 금융 V2 코드로 분기되지만 이와 상호작용하는 일부 다른 계약이 이전 코드 버전을 사용하는 경우 호환성 문제가 발생할 수 있습니다.

예를 들어 이전 버전의 cToken에서 사용했던 InterestRateModel 컨트랙트에서 차입 금리를 구하는 getBorrowRate 함수의 반환 값은 2개의 uint 유형 값이었지만, 새로운 버전의 InterestRateModel 함수에서는 getBorrowRate 함수가 1개의 uint만 반환합니다. 유형 값.

그러나 복합 금융 V2 포크 프로젝트인 Percent Finance에서 프로젝트 팀은 이전 버전의 cToken 계약 코드를 사용했지만 InterestRateModel 계약은 새 버전을 사용했습니다. 이로 인해 getBorrowRate 함수를 호출할 때 cToken의 accrueInterest 함수가 실패했습니다. AccumulateInterest 기능은 출금과 대출 모두에 사용되며, 이로 인해 궁극적으로 출금 및 대출 기능이 정상적으로 진행될 수 없게 되고 계약상의 자금이 완전히 잠기게 됩니다.

감사 포인트: 감사 중에는 업데이트된 코드의 계약 인터페이스, 상태 변수, 함수 서명 및 이벤트의 변경 사항이 기존 시스템의 정상적인 작동을 방해하는지 여부에 주의를 기울여야 하며 모든 계약 코드 버전의 일관성을 보장해야 합니다. 업데이트하거나 업데이트된 코드가 이전 버전의 코드와 호환되는지 확인하세요.

4.6 다중 체인 배포로 인한 하드 코딩 문제

Compound Finance V2의 코드에서 상수 blockPerYear는 매년 생성되는 예상 블록 수를 나타냅니다. 그 값은 이자율 모델 계약에 2102400으로 하드 코딩되어 있습니다. 이는 이더리움의 평균 블록 생성 시간이 15초이기 때문입니다.

그러나 서로 다른 체인의 블록 시간은 반드시 동일하지는 않으며, 일년 내내 생산되는 대략적인 블록 수도 반드시 동일하지는 않습니다. 컴파운드 포크 프로젝트가 다른 체인에 배포되지만 하드 코딩된 값이 다른 체인의 조건에 따라 수정되지 않는 경우 최종 이자율 계산이 예상을 초과할 수 있습니다. 이는 blockPerYear 값이 baseRatePerBlock 및 multiplierPerBlock 값에 영향을 미치고, baseRatePerBlock 및 multiplierPerBlock 값이 궁극적으로 차입 금리에 영향을 미치기 때문입니다.

예를 들어, BSC 체인의 블록 생성 시간이 3초라면, 연간 예상 블록 수(blocksPerYear)는 10,512,000개가 되어야 합니다. 배포 전에 blockPerYear 값을 수정하지 않으면 최종 계산된 차입 금리는 예상보다 5배 더 높아집니다.

감사 포인트: 감사 시 프로젝트 계약서에 하드 코딩된 상수나 변수가 서로 다른 체인의 특성상 예상치 못한 결과를 초래할 수 있는지 주의를 기울여야 합니다. 프로젝트 당사자는 해당 값을 올바르게 수정하는 것이 좋습니다. 다른 체인의 조건에 따라.

다른

위에서 언급한 주요 우려 사항 외에도, 컴파운드 V2의 포크된 프로젝트는 일반적으로 외부 타사 프로토콜과 상호 작용하기 위한 코드를 추가하는 등 프로젝트 팀의 설계를 기반으로 일부 비즈니스 로직을 수정합니다. 이는 특정 비즈니스 논리 및 설계 요구 사항을 기반으로 감사 중에 Complex Finance V2 자체의 핵심 대출 모델 및 프로젝트에 영향을 미칠지 여부를 평가해야 합니다.

마지막에 쓰세요

이 복합 금융 V2 및 해당 포크 프로젝트에 대한 보안 감사 매뉴얼은 감사 중에 이러한 복잡한 시스템의 보안을 더 잘 이해하고 평가하는 데 도움이 되기를 바랍니다. 이 매뉴얼도 반복적인 기술 업데이트를 통해 업데이트되고 개선될 것입니다.

[1] https://github.com/YAcademy-Residents/defi-fork-bugs

[1] https://github.com/YAcademy-Residents/defi-fork-bugs

[2] https://medium.com/chainsecurity/trueusd-compound-vulnerability-bc5b696d29e2

[3] https://github.com/code-423n4/2023-05-venus-findings/issues/559

[4] https://learnblockchain.cn/article/2593

[5] https://github.com/compound-finance/compound-protocol

작가 |

편집자 |