EVM에서는 "이벤트"라는 것을 코드에 짜두는데, 이게 원하는 동작이 처리되었음을 확인하기 위한 로그라고 보면 됨.
제일 많이 사용되는 이벤트는 erc20과 erc721에서 사용되는 approve, transfer, swap 정도이고 이걸 기반으로 dune이나 flipside cryto는 토큰 이동에 대해서나 dex 데이터는 꽤 잘 인덱싱해두었지만, 그렇다고 이것만 있으면 스마트컨트랙트의 동작을 정확히 알 수 없음.
그 이유는 예를 들어 p2p로 토큰을 보내는 것도 전송이고, 소각도 결국에는 전송에 일부라 소각을 정확히 알기 위해서는 burn 이벤트를 찾거나, transfer 이벤트인데 0x0000~으로 가는 걸 찾아야 함.
근데 이게 0x000으로 간다고 꼭 소각이 아닐 수 있음. 그게 브릿지일수도 있는 것. 그렇기에 이런 이벤트 로그를 뜯어보는 것 + 로직을 알아야 온체인 분석이 시작됨.
그리고 이제 이걸 알면 실제 이벤트 로그에 담겨 있는 값을 알아야 하는데, 이 이벤트 로그는 EVM의 stack 구조를 알아야 함. 간단하게 32byte 스택 구조를 쓰는데, 이게 결국 32byte (256bit) 단위로 데이터를 끊어서 읽어야 제대로 읽힘.
그런데 보통 token amount는 event log에서도 마지막에 기록함. 그래서 각 변수 개수와 메모리 구조보고 대충 X번째 byte 부터 32byte 읽어서 이를 (u)int256으로 바꾸는 과정이 필요함. 그리고 evm address는 기본적으로 160bit, 즉 20자리 hex로 구성되어서 꼭 앞에 비트 12개 떼고 읽어야 하는데 이것도 반복작업이지만 매우 빡치는 부분 중 하나. 예전에는 이것도 직접적으로 되는 게 아니라 string으로 처리하고 hex로 변환해서 다시 정수형으로 변환해야 해서 번거로웠는데 이제는 varbinary처리가 잘되어 있어서 그나마 나아짐.
근데 이것도 이벤트가 코드로 어떻게 짰는지 알아야지 이렇게 쪼갤 수 있음. 이 함수는 스마트 컨트랙트가 익스플로러 위에 누가 등록을 해야하는 건데 마이너EVM체인이나 신규 컨트랙트는 등록을 안해서 그것 조차 안적혀 있는 경우가 있음. 이럴 때는 그냥 컨트랙트 직접 써서 내가 예상한 동작과 하나하나 매칭 시켜야함.
한 1년 전만 해도 Dune에서도 나포함 5명 내외로만 이정도로 로그 파싱해서 데이터 제공하고 대시보드 만들었는데 요새는 팀에 데이터 분석가 경력자가 있거나 이런 걸 잘하는 외주들도 있어서 점점 디테일한 파싱능력자들이 생기는 중.
참고로 aptos나 solana 로그 보면 자연어로 되어 있거나 상당히 직관적이어서 좋은데, 대신 여기는 로그 관련 표준 대장이 마땅히 없어서 컨트랙트 다 뜯어봐야 로그 파싱할 수 있음.
좋게 말하면 이정도만 알면 누구든 EVM 온체인 데이터 분석 할 수 있음. 😁