솔리디티 이벤트에 대해 자세히 살펴보기 - 이벤트

출처: 덴체인 커뮤니티

오늘의 글에서는 보다 일반화된 이더와 EVM에서 로그로 알려진 솔리디티 이벤트에 대해 살펴보겠습니다. 이를 사용하는 방법, 정의, 이벤트 토픽 해시와 서명을 사용하여 로그를 필터링하는 방법, 그리고 언제 사용해야 하는지에 대한 몇 가지 조언을 살펴보겠습니다.

전통적으로 상태 변수의 재진입에 적용되어 온 잘 알려진 패턴인 check-event 상호작용 패턴도 다룰 것입니다. 이벤트 트리거에도 이러한 패턴을 적용해야 하는 이유와 관련된 잠재적 위험 및 보안 취약점을 살펴보겠습니다.

솔리디티에서 이벤트를 어떻게 정의하나요?

event를 사용하여 Solidity에서 이벤트를 정의할 수 있습니다. span style="font-size: 18px;">키워드를 사용하여 아래와 같이 솔리디티에서 이벤트를 정의할 수 있습니다.

인터페이스 ILight {
    event SwitchedON();
    event SwitchedOFF();
    event BulbReplaced();
}

컨트랙트 이름을 정규화하여 액세스할 수 있으며, 그 뒤에를 입력하면 됩니다. 그리고 다른 컨트랙트에서 이벤트에 액세스하려면 이벤트 이름을 다음과 같이 입력하면 됩니다:

event RegisteredSuccessfully(주소 사용자)

이벤트 서명은 다음과 같습니다:

이벤트 등록 성공(주소 사용자)

이벤트 제목 해시는 다음과 같습니다.

bytes32 topicHash = RegisteredSuccessfully.selector;

솔리디 v0.8.15부터 이벤트의 .selector회원 전용입니다.

발송된 블록체인 로그를 살펴보면 로그 제목의 색인을 찾을 수 있습니다0(첫 번째) 항목은 이벤트 토픽 해시에 해당합니다. 토픽은 로그를 통해 검색할 수 있는 콘텐츠이므로 이벤트 토픽 해시별로 필터링할 수 있습니다:

• < span style="font-size: 18px;">스마트 컨트랙트 내에서 특정 주소의 특정 이벤트를 검색합니다.

• 블록체인의 모든 컨트랙트에서 특정 이벤트를 검색합니다.

아래에서 더 자세히 살펴보겠습니다.익명익명 이벤트는 이 규칙의 예외입니다. anonymous 키워드를 사용하면 검색할 수 없으므로 "anonymous ".

이 사실을 바탕으로 위에 정의된 것과 같이 매개변수가 없는 가장 단순한 이벤트가 솔리디티에 정의되어 있음을 유추할 수도 있습니다. span>전구 교체또는스위치온, 하단에 사용 LOG1< 이벤트 자체는 검색 가능하므로 로그에서 토픽을 트리거하는 opcode를 추가합니다.

더 많은 토픽을 추가할 수 있으며, 다른 토픽이 사용됩니다LOG2 , LOG3,LOG4및및LOG5로 표시되어 있는 한 indexed< span style="font-size: 18px;">. 다음 섹션에서 인덱싱 매개변수에 대해 살펴보겠습니다.

이벤트 파라미터 및 인덱싱 파라미터

이벤트는 값 유형을 포함한 모든 유형의 매개변수를 수용할 수 있습니다(uintN,bytesN,bool,address...) struct,,열거형 및 사용자 정의 값 유형.

이 글을 작성하면서 조사한 바에 따르면, 허용되지 않는 유일한 유형은 내부 함수 유형입니다. 외부 함수 유형은 허용되지만 내부 함수 유형은 허용되지 않습니다. 예를 들어 다음 코드는 컴파일되지 않습니다.

// SPDX-License->. 식별자: UNLICENSED
pragma solidity ^0.8.0;

계약 익명 이벤트 {
    event SecretPasswordHashUpdated( bytes32 secretPasswordHash) 익명;
}

이벤트 선언이 익명인 경우, 컨트랙트 ABI에서 이벤트의 "익명" 필드는 true로 표시됩니다. .

익명 이벤트의 장점 중 하나는 컨트랙트를 더 저렴하게 배포하고 트리거할 때 가스 비용을 절감할 수 있다는 점입니다.

익명 이벤트의 좋은 사용 사례는 이벤트가 하나만 있는 컨트랙트입니다. 이벤트 로그에는 해당 이벤트 하나만 표시되므로 컨트랙트의 모든 이벤트를 수신하는 것이 좋습니다. 컨트랙트에서 하나의 이벤트만 발생하도록 정의되어 있기 때문에 이름에 대한 구독은 관련이 없습니다. 따라서 이벤트를 익명으로 정의하고 컨트랙트의 모든 이벤트 로그를 구독하여 모두 동일한 이벤트인지 확인할 수 있습니다.

DappHub의 DS-Note 컨트랙트 [7]와 같은 인기 코드베이스에서 익명 이벤트 사용의 예를 참조하세요.

위 코드 스니펫에서 이벤트 선언이 익명이므로 네 번째 " 인덱싱된" 매개변수를 정의할 수 있습니다.

익명 이벤트에는 bytes32 제목 해시가 없으므로 지원되지 않습니다..selector 멤버.

LOG 옵코드를 사용하여 어셈블리에서 이벤트 트리거

어셈블리에서 이벤트를 트리거할 수 있습니다. EVM 명령어 세트의 연산자에 해당하는 logN명령을 사용합니다.

어셈블리에서 이벤트를 트리거하려면 이벤트에서 방출할 모든 데이터를 메모리에 저장해야 합니다. 18px;">memory에 특정 위치에 저장해야 합니다.

이벤트에서 전송할 데이터를 메모리에 저장한 후에는 다음 매개변수를 logN 지시어에 할당할 수 있습니다.

• p = 데이터 가져오기를 시작할 메모리 위치입니다. 이것은 기본적으로 메모리 포인터 또는 "오프셋" 또는 "메모리 인덱스"라고 부르는 것에 따라 다릅니다.

• s = 이벤트에서 전송할 바이트 수(p로 시작)입니다.

• 다른 모든 매개변수 t1,t2, t3 및 . t4는 모두 색인화할 수 있는 이벤트 매개변수입니다. 여기에는 두 가지 중요한 사항이 있습니다. 1) 이벤트 정의에서 동일한 순서로 정의된 동일한 매개변수여야 하고, 2) 데이터를 가져오기 위해 메모리에 배치되어야 한다는 점입니다.

다음 코드 스니펫은 어셈블리에서 이 작업을 수행하는 방법을 보여줍니다.

<span ) 10px 10px / 40px no-repeat ;height: 30px;width: 100%;margin -하단: -7px;테두리-반경: 5px;'>event ExampleEventAsm(bytes32 tokenId);

 function _emitEventAssembly(bytes32 tokenId) internal{
     bytes32 topicHash = ExampleEventAsm.selector;

    ; assembly {
        let freeMemoryPointer := mload(0x40)
        mstore(freeMemoryPointer, topicHash)
       mstore(add(freeMemoryPointer, 32), tokenId)

       // ``이벤트 발생. ExampleEventAsm` 이벤트와 2개의 토픽
         log2( 
       freeMemoryPointer, // `p` =.........................................................................`를 발생시킵니다. 메모리 내 시작 오프셋
       64, // `s` = 이벤트 데이터에 포함할 `p`의 메모리 내 바이트 수
               64, // `p` = 메모리 내 바이트 수 topicHash, // 이벤트 자체를 필터링하기 위한 주제
             tokenId // 첫번째 인덱싱된 매개변수
      )
    }
}

이벤트 가스 비용

모든 레코드 옵코드(LOG0,LOG1,,< span style="font-size: 18px;">LOG2,LOG3< ,LOG4) 모두 가스를 소비합니다. 매개변수(토픽)가 많을수록 더 많은 가스를 소비합니다.

또 인덱싱이나 데이터 크기 같은 다른 요인으로 인해 이벤트에 예상보다 많은 시간이 소요될 수 있습니다.

체크-이벤트-인터랙션 패턴

체크-적용-인터랙션 패턴[9]도 이벤트에 적용됩니다. 이벤트에도 적용됩니다.

이러한 패턴을 탐지하는 한 가지 방법은 Remix 정적 분석 도구를 사용하는 것입니다.

이 패턴은 Slither에서도 감지할 수 있습니다. 외부 호출 후 이벤트를 트리거하는 컨트랙트에서 Slither를 실행하면 "재진입 이벤트"를 제안하는 검색을 얻을 수 있습니다.

따라서 디앱의 경우 어떤 이벤트가 처음, 다음, 마지막으로 발생했는지 정확하게 확인할 수 있도록 순서가 중요합니다. 이는 재귀 호출이나 재진입 호출의 경우 특히 중요합니다. 외부 호출 후에 이벤트가 트리거되고 해당 외부 호출이 재진입 호출을 하는 경우:

1. 첫 번째 이벤트는 두 번째 재진입 호출이 완료된 후 발생하는 이벤트입니다.

2. 두 번째로 방출되는 이벤트는 초기 트랜잭션 이후에 방출되는 이벤트입니다.

이를 이해하면 컨트랙트 호출을 모니터링하기 위해 체인 아래로 명확한 감사 추적을 제공할 수 있습니다. 트랜잭션이 실행되는 동안 어떤 함수가 처음과 마지막으로 호출되는지, 각 루틴이 실행되는 순서를 확인할 수 있습니다.

슬라이더 감지기에 대한 문서[10] - 솔리디티 및 바이퍼용 정적 분석기.

이 잠재적 취약점은 트레일 오브 비트의 Liquity[11] 스마트 계약 감사에서도 발견되어 보고되었습니다.

< 그림캡션>이미지

이벤트는 언제 트리거되어야 하나요?

계약에서 이벤트 트리거가 중요하고 유용할 수 있는 몇 가지 상황이 있을 수 있습니다.

• 제한된 사용자 및 주소가 특정 작업을 수행할 때(예: 소유자 또는 컨트랙트 관리자). 예를 들어, 소유자만 호출할 수 있는 인기 있는 소유권 이전(주소)기능이 여기에 포함됩니다. 소유자만 호출할 수 있는 함수입니다.

• 계약의 핵심 로직을 담당하는 일부 주요 변수 또는 산술 매개변수를 변경합니다. 이는 탈중앙 금융 프로토콜의 맥락에서 특히 중요합니다.

<그림 style="text-align: 가운데;">

슬라이더 탐지기 문서 ^{[12]에는 다음과 같이 설명되어 있습니다. sup>에서 이러한 사례에 대해 자세히 설명합니다.}

이 내용은 LooksRare에 대한 Trail의 감사 보고서에도 설명되어 있습니다.

0x프로토콜에 대한 자세한 내용 보기^{[13]. sup>에서 이벤트와 관련된 보안 관련 문제에 대한 자세한 내용을 확인하세요.}

참고

1. 익명 이벤트 사용 목적에 대한 문서 누락(사용 목적 알기)^[14]
   

2. [익명 이벤트의 장점]