복구할 수 있는 방법이 없으며 YAM 투표 구조 작업은 처음부터 실패할 운명입니다.

36시간 이내에 건물이 올라가는 것을 보았고 몇 분 안에 건물이 무너졌습니다.

베이징 시간 8월 13일 03:00, 유명한 DeFi 프로젝트 YAM Finance가 유동성 채굴을 발표했습니다.단 하루 만에 잠긴 자산의 가치가 6억 달러를 넘어섰고, 잠긴 자산의 증가율과 성장률은 거의 미친 상태에 도달한 자산. 그리고 이런 전개에 따르면 초기에 풀에 유동성을 투입한 일부 양모 당사자들의 연이율은 200배까지 육박할 정도로 광기의 정도를 보여준다.

그런데 모두가 광산 축제에 빠져들고 있던 찰나 사고가 발생했다.

보조 제목

YAM 작은 고구마를 저장하는 방법?

취약점을 발견한 후 YAM 팀은 거버넌스 제안을 제출하기 위해 160,000명의 위임 투표가 필요하다고 말하면서 "구조 작업"을 시작했습니다. 그래서 그들은 투표를 위해 커뮤니티에 전화를 걸었습니다. 곧 이 활발한 커뮤니티 투표 작업이 완료될 것입니다.

그러나 모든 사람들이 단지 잘못된 경보라고 생각했을 때, 베이징 시간으로 8월 13일 오후 16시 1분에 YAM 설립자 Brock Elmore는 트윗했습니다. 허?

PeckShield 보안 담당자가 분석에 개입한 후 신속하게 문제의 본질을 찾았습니다. 탄력적 공급 메커니즘(리베이스)에 코드 공식 오류가 있어 시스템이 두 번째 리베이스할 때 자동으로 10^18개의 새 토큰을 발행했습니다. 높은 수준으로 유지되면 이후의 리베이스마다 기하급수적으로 증가하여 Little Sweet Potato YAM의 수가 끔찍한 천문학적 숫자로 바뀝니다. 이는 커뮤니티가 후기 단계에서 아무리 투표를 위임해도 시스템을 제어할 수 있는 충분한 표를 얻지 못하고 전체 시스템이 통제력을 상실하고 주인이 없는 상태에 빠지게 된다는 것을 의미합니다.

원래 YAM 관계자는 모든 YAM 보유자에게 이 기존 허점을 수정하기 위해 대리 투표를 통해 투표 "구조 작업"을 완료할 것을 촉구했습니다. 그러나 PeckShield 보안 요원의 추가 분석에 따르면 YAM 관계자가 호소하기 시작했을 때 구조 작업은 실제로 실패할 운명이었습니다.

두 가지 이유가 있습니다.

1）시간이 너무 늦었습니다: YAM 관계자가 한 가지를 간과했을 수 있습니다. , 두 번째 rebase가 이미 완료되었습니다.

2）새로 배포된 거버넌스 컨트랙트가 효과적으로 실행되지 않음: 2차 리베이스 트리거로 인해 실행 시간 이후에 새 거버넌스 컨트랙트가 실행될 것으로 예상했지만, 총 투표 수는 총 투표 수의 4%에 미치지 못함 계약서에 합의된 사항이므로 효과적으로 이행할 수 없습니다.

보조 제목

먼저 YAM 스마트 계약의 유연한 공급 메커니즘(리베이스)을 소개합니다.

1) 시스템은 시장 가격 변동에 따라 동적으로 토큰 공급을 조정하며, 시장 가격이 상승하면 비례적으로 추가 토큰을 발행하여 단위 토큰의 가치가 $1로 떨어질 때까지 줄입니다.

2) Rebase는 하루 2회 진행되며, 각 Rebase는 토큰의 공급량을 변경하며, 현재 시세에 따라 일정량의 토큰이 발행 또는 소각됩니다.

제안 실행의 핵심 요소에 대해 이야기하겠습니다. 보유자가 투표를 위임하고 투표 수가 전체의 1%를 초과하면 제안이 실행 및 배열될 수 있으며 계약에 따른 실행 시간은 12.5시간을 기다린 후 제안이 실행되면 Voting이 전체의 4%를 초과해야 합니다. 그래야만 새로운 거버넌스 계약이 구현되고 효력을 발휘할 수 있으며 프로젝트가 계속 정상적으로 운영될 수 있습니다.

위의 기술적 포인트를 예표하여 YAM의 공식 후속 일정을 살펴보고 이 구조 작업이 실패할 수밖에 없는 이유를 알아보겠습니다.

아래 타임라인에 표시된 대로:

② 최초 리베이스가 발생하는 시점으로 컨트랙트의 버그로 인해 totalsupply의 자산이 비정상적으로 폭등했고, 관계자는 버그가 존재함을 발견하고 이를 공개했다.

그러나 상황은 역효과를 낳았고, 관리들이 허점을 발견하고 투표 요청을 공개하기에는 너무 늦어서 성공할 수 있는 유일한 황금 비상 기간을 놓쳤습니다. 설상가상으로 공식 시간 리듬에 따라 새로운 거버넌스 계약이 ⑦의 실행 시간에 도달하면 득표수가 총액의 4%를 넘어야 하며 이때 총액은 10^18*10으로 확대된다. ^18 , 이전에 누적된 투표 수는 이미 양동이의 한 방울이며 전혀 도움이 되지 않습니다.

따라서 이 구조 작업은 처음부터 실패할 운명이었습니다.

아래에서 우리는 이 사건에 대한 자세한 분석을 할 것입니다: (프로젝트 당사자 github 주소https://github.com/yam-finance/yam-protocol）

이미지 설명

그림 1. 첫 번째 rebase에 대한 자산 변경 사항

위의 체인에 대한 정보로 (https://oko.palkeo.com/)는 첫 번째 리베이스 후 totalSupply가 3,500,000* 10^18에서 최대값으로 급증함을 보여줍니다.

코드를 더 분석하여 코드에서 무슨 일이 일어났는지 살펴보겠습니다. 먼저 체인의 정보에서 rebase 작업이 YAMRebaser 계약의 YAMRebaser::rebase() 함수를 호출한다는 것을 알 수 있습니다(먼저 이 함수를 건너뛰고 나중에 이야기하겠습니다.) 결국 YAM 계약(0xa923af6d05993495257a872ec69dbbf01501eb0e)의 rebase() 함수를 호출하여 totalSupply를 다시 계산한다는 것을 발견했습니다(코드 논리는 아래 그림 2에 나와 있습니다.) 340행의 totalSupply 할당 작업에서 다음을 수행할 수 있습니다. 이 코드 행에는 명백한 오류가 있습니다. BASE를 나누지 않아 totalSupply의 값이 10^18배 증가했습니다.

이미지 설명

그림 2. YAMToken::rebase()가 비정상적으로 큰 totalSupply 값을 가져옴

그리고 12시간 후 YAM은 두 번째 리베이스(https://oko.palkeo.com/이미지 설명

그림 3. 두 번째 리베이스 자산 변경

이미지 설명

그림 4. YAMRebaser::rebase()는 잘못된 totalSupply로 initSupply를 계산합니다.

보조 제목

프로젝트 당사자가 준비 작업을 너무 늦게 완료한 이유는 무엇입니까?

이미지 설명

그림 5. GovernorAlpha::queue() 함수는 eta(유효 시간)를 설정합니다.

그리고 취해진 구조 조치가 전혀 소용이 없다고 말하는 이유는 무엇입니까?

이미지 설명

그림 6. GovernorAlpha::execute()는 제안 상태를 확인합니다.

이미지 설명

그림 7. GovernorAlpha::state() 실행에서 Defeated 오류 반환

이미지 설명

그림 8. 잘못된 이상값을 반환하는 GovernorAlpha::quorumVotes()

이미지 설명

이미지 설명

요약하다

이번 YAM 취약점 사건으로 인해 결국 거버넌스 계약의 750,000 yCRV가 영구적으로 잠기게 되었고, 급격한 급락과 단기간에 회복이 불가능한 상황, 높은 가격대에 얼마나 많은 사람들이 매몰됐는지, 그리고 광기의 정도는 이것이 오늘날 DeFi 유동성 채굴의 진정한 묘사입니다. 잔인하고 마법 같지 않습니까? 프로젝트 당사자가 계약을 배포하기 전에 rebase 프로세스를 한 번 테스트했다면 허점의 존재를 확실히 잡을 수 있을 것입니다. DeFi 프로젝트에 대한 보안 감사의 중요성을 보는 것으로 충분합니다.

요약하면 PeckShield는 이를 사용하여 귀하에게 조언하고자 합니다.블록체인 세계에서는 계약 코드의 모든 라인을 경외하는 것이 중요합니다. 약간의 누락이 돌이킬 수 없는 상황을 초래할 수 있기 때문입니다.. 결국 코드는 사람이 작성하고 허점을 완전히 피하기 어렵기 때문에 계약이 온라인으로 배포되기 전에 프로젝트 당사자가 충분한 테스트 및 제3자 보안 감사 작업을 수행해야 도움이 됩니다. 잠재적인 계약 코드를 조기에 발견하고 문제를 해결합니다. 위반이 발생한 후 보안 위반을 수정하기에는 너무 늦었습니다.