스테이킹 프로토콜 감사 지침

스테이킹 프로토콜 감사 지침

타임 스탬프 : 10 년 2023 월 6 일 오전 57시 XNUMX 분

읽기 시간: 6 분

이 블로그에서는 유동성 스테이킹 프로토콜의 개념과 스테이킹 프로토콜에 대한 감사 지침을 설명했습니다. 가이드라인은 출금 메커니즘, 반올림 오류, 외부 호출, 수수료 논리, 루프, 구조체, 스테이킹 기간 등과 같은 취약한 부분을 다룹니다. 이 블로그 게시물은 스테이킹 프로토콜 감사에 유용한 참고 자료가 될 것이며 잠재적인 버그를 식별하는 데 도움이 될 수 있습니다. .

유동성 스테이킹이란?

유동성 스테이킹을 통해 사용자는 유동성을 희생하지 않고도 보유하고 있는 암호화폐를 스테이킹하고 보상을 받을 수 있습니다. 고정된 기간 동안 코인을 잠그는 대신 사용자는 스테이킹한 자산을 나타내는 유동 토큰을 받을 수 있습니다. 이 토큰은 다른 암호화폐처럼 거래하거나 사용할 수 있으므로 사용자는 자산을 원하는 대로 사용하면서 스테이킹 보상을 받을 수 있습니다.

스테이킹 프로토콜 PlatoBlockchain Data Intelligence 감사 지침. 수직 검색. 일체 포함.

예를 들어, 이더리움 네트워크에 스테이킹하려는 100 ETH가 있습니다. 정해진 기간 동안 ETH를 락업하는 대신 Lido와 같은 유동성 스테이킹 서비스를 사용하여 ETH를 스테이킹하고 그 대가로 stETH라는 액체 토큰을 받을 수 있습니다. stETH를 사용하면 스테이킹 보상을 받으면서 스테이킹된 ETH를 거래하거나 사용할 수 있습니다.

스테이킹 계약 감사를 시작하겠습니다.

계약 코드로 시작하기 전에 사용 가능한 모든 감사 사양을 검사하십시오. 백서, README 파일 또는 기타 형식일 수 있습니다. 이를 통해 계약 코드에 포함되는 내용을 알 수 있습니다.

스테이킹 계약에 대한 감사 사양 문서를 볼 때 다음 사항을 찾으십시오.

  • 수수료 유형 및 계산.
  • 스테이킹된 토큰에 대한 보상 메커니즘
  • 소유자의 권한
  • 계약에 ETH가 보관됩니까?
  • 계약이 보유할 토큰은 무엇입니까?
  • 포크된 원본 계약

사양이 코드와 일치하는지 확인하십시오. 수수료 및 토크노믹스로 시작하여 소유자의 권한을 확인합니다. 모든 보상 및 수수료 값이 문서와 일치하는지 확인하십시오.

찾아야 할 취약 지점은?

1. 보상 인출 메커니즘:

스테이킹된 토큰 보상 메커니즘이 올바르게 구현되고 보상이 모든 스테이커에게 공정하고 비례적으로 분배되는지 확인하십시오. 프로젝트는 두 가지 방법으로 보상을 분배할 수 있습니다: 자동, 주기적 또는 사용자 요청 시. 철회 기능은 프로토콜의 비즈니스 로직에 따라 구현 및 사용자 정의될 수 있습니다.
다음은 몇 가지 체크포인트입니다.

  • 사용자가 보상 + 스테이킹 금액보다 더 많이 인출할 수 있는지 확인하십시오.
  • 금액계산시 오버플로우/언더플로우 확인
  • 특정 매개 변수가 계산 중에 보상에 부정적인 영향을 미칠 수 있는지 확인하십시오.
  • block.timestamp 또는 block.number가 이 함수에서 사용되는 경우. 어떤 식으로든 악용될 수 있는지 확인하십시오.

2. 수수료 논리:

입금 및 출금에 약간의 수수료가 부과되는 경우 단일 사용자가 수수료를 우회할 수 없는지 확인하십시오. 또한 잠재적인 오버플로 또는 언더플로 문제에 주의하십시오. 관리자 또는 소유자만 수수료 설정을 변경할 수 있는 권한을 부여받아야 합니다. 또한 최대 수수료에 대한 임계값이 설정되어 관리자가 과도하게 높은 금액을 설정하지 않도록 합니다.

3. LP 토큰의 주조/소각 메커니즘:

발행 및 소각 메커니즘이 올바르게 구현되었는지 확인하십시오. 소각 기능은 민트 기능에 의한 모든 상태 변경을 되돌려야 합니다. 또한 풀이 비었을 때 사용자가 첫 번째 스테이크 동안 적절한 양의 토큰을 받았는지 확인하는 것이 중요합니다.

생성 및 소각 기능의 논리를 수학적으로 검증하여 숨겨진 취약점을 발견할 수 있습니다. 또한 발행된 LP 토큰의 총 공급량은 스테이킹된 자산을 초과하지 않아야 합니다.

4. 반올림 오류:

특정 사소한 반올림 실수는 일반적으로 피할 수 없고 문제가 되지 않지만 곱할 수 있을 때 크게 커질 수 있습니다. 반복적으로 스테이킹 및 언스테이킹하여 반올림 오류로부터 이익을 얻을 수 있는 극단적인 경우를 찾으십시오.

오랜 기간 동안 반올림 오류가 상당한 양으로 발생할 수 있는지 여부를 결정하기 위해 가능한 반올림 오류의 범위를 수학적으로 계산할 수 있습니다.

5. 스테이킹 기간:

계약의 스테이킹 기간 계산이 지정된 비즈니스 로직과 일치하는지 확인하십시오. 기간 확인을 우회하여 스테이킹 기간이 종료되기 전에 사용자가 보상을 사용할 수 없는지 확인합니다. 또한 공격자가 더 많은 보상을 얻기 위해 스테이킹 기간을 악용할 수 있는지 확인하십시오.

6. 외부 호출 및 토큰 처리:

대부분의 외부 호출은 토큰 계약에 대한 것입니다. 따라서 스테이킹 계약이 처리할 토큰 유형을 결정해야 합니다. 오류 및 재진입 공격에 대한 외부 호출을 확인하는 것이 필수적입니다. Safemoon과 같은 이체 수수료가 있는 디플레이션 토큰이나 토큰은 논리가 올바르게 구현되지 않으면 문제가 발생할 수 있습니다.

7. 가격 조작 검사:

플래시 론을 통한 가격 조작은 DeFi 프로젝트에서 가장 자주 발생하는 해킹 중 하나입니다. 악의적인 행위자가 대량의 토큰을 스테이킹하거나 스테이킹 해제하는 동안 플래시 론을 사용하여 가격을 조작할 수 있는 상황이 있을 수 있습니다. 스테이킹 및 스테이킹 해제 기능을 신중하게 검토하여 플래시 론 기반 가격 조작 공격 및 다른 사용자의 자금 손실을 초래할 수 있는 극단적인 시나리오를 피하십시오.

8. 몇 가지 추가 확인 사항:

  • 루프 : 계약 로직이 배열에 대한 루프를 포함하는 경우 블록 가스 한도를 초과하지 않도록 하는 것이 중요합니다. 이는 배열 크기가 매우 클 때 발생할 수 있으므로 배열 크기를 증가시킬 수 있는 기능과 이를 악용하여 DoS 공격을 일으킬 수 있는 사용자가 있는지 조사해야 합니다. 이것을 확인하십시오 신고.
  • 구조체: 스테이킹 계약은 구조체 유형을 사용하여 사용자 또는 풀 데이터를 저장합니다. 함수 내에서 구조체를 선언하거나 액세스할 때 "메모리" 또는 "저장소"를 사용할지 여부를 지정하는 것이 중요합니다. 가스를 절약하는 데 도움이 될 수 있습니다. 자세한 내용은 다음을 참조하십시오. 이 기사에.
  • 프론트 러닝: 악의적인 행위자가 자신에게 유리한 거래를 앞장서서 실행할 수 있는 모든 시나리오를 찾습니다.
  • 기능 가시성/액세스 제어 확인: 외부 또는 공용으로 선언된 함수는 누구나 액세스할 수 있습니다. 따라서 공공 기능이 민감한 작업을 수행할 수 없도록 하는 것이 중요합니다. 스테이킹 프로토콜이 스테이킹된 코인과 시스템 인프라에 대한 무단 액세스를 방지하기 위해 적절한 제어를 구현했는지 확인하는 것이 중요합니다.
  • 중앙화 위험: 소유자에게 과도한 권한을 부여하지 않는 것이 중요합니다. 관리자 주소가 손상되면 프로토콜에 심각한 손상을 줄 수 있습니다. 소유자 또는 관리자 권한이 적절한지 확인하고 관리자의 개인 키가 유출되는 상황을 처리하기 위한 계획이 프로토콜에 있는지 확인하십시오.
  • ETH / WETH 취급: 계약에는 종종 ETH를 처리하기 위한 특정 논리가 포함됩니다. 예를 들어, msg.value > 0일 때 계약은 WETH를 직접 수신하는 동시에 ETH를 WETH로 변환할 수 있습니다. 사용자가 통화로 WETH를 지정했지만 호출과 함께 ETH를 전송하면 특정 불변성이 깨지고 잘못된 동작이 발생할 수 있습니다.

지금까지 우리는 유동성 스테이킹 프로토콜과 그러한 프로토콜에 대한 감사 지침에 대해 논의했습니다. 간단히 말해서 유동성 스테이킹을 통해 사용자는 유동성을 희생하지 않고도 스테이킹 보상을 얻을 수 있습니다. 인출 메커니즘, 수수료 논리, LP 토큰 발행/소각 메커니즘, 반올림 오류, 스테이킹 기간, 외부 호출 및 가격 조작 확인과 같이 감사자가 주의해야 하는 스테이킹 계약의 취약 지점을 설명했습니다. 

감사인은 감사 사양 문서를 검토하고, 사양을 코드와 일치시키고, 수수료 및 토크노믹스 검증을 확인하도록 권장합니다. 또한 배열 반복, 구조 유형 데이터에 대한 메모리 또는 저장소 지정, 선행 실행 시나리오와 같은 추가 검사를 권장합니다. 이 지침은 스테이킹 프로토콜을 감사하고 잠재적인 버그를 식별하는 데 유용합니다.

11 조회수

타임 스탬프 :

더보기 퀼해시