当前位置:   article > 正文

Clickhouse 以太坊分析:交易日志分析_clickhouse there is no session or session context

clickhouse there is no session or session context has expired

概述

读者可前往我的博客获得更好的阅读体验。

上一篇中,我们介绍了如何使用 Clickhouse 进行基础的信息提取,这些信息往往依赖于以太坊底层机制,我们只能获得如 ETH 转账、 gas 等信息,这些信息并没有涵盖以太坊中最重要的智能合约的相关数据。这使我们无法获得 ERC-20 代币转账或 NFT 转移等数据。

对于很多数据分析师而言,了解智能合约相关数据更加重要。本文主要介绍如何获得关于智能合约的相关数据,以进一步完善数据分析。本篇仍主要聚焦于数据清洗,但仍会给出部分数据分析案例以帮助读者理解。

前置知识

如果需要获取合约内的数据,我们必须了解对于智能合约非常重要的 Event 数据类型。该数据类型的一般定义如下:

event Transfer(address indexed _from, address indexed _to, uint256 _value)
  • 1

上述定义来自 ERC-20 的 EIP 文档。在智能合约中,我们可以通过 emit Transfer(...) 来将 event 释放到区块空间中,这使我们可以从外部读取智能合约运行的结果。我们可以将此释放行为认为是日志记录,在 etherscan 中,该部分记录在 Logs 中,如下图:

ERC20 Event

我们需要关注 Topics 栏中的内容,该部分内容与上述定义是对应的:

  1. Topics 0Transfer(address,address,uint256)Keccak-256 哈希结果
  2. Topics 1 对应为 address indexed _from 表示代币转移的发起方
  3. Topics 2 对应为 address indexed _to 表示代币转移的接受发
  4. Data 对应为 _value 表示代币转移的数量

总结来说,Topics 0 是对事件整体名称的 Keccak-256 哈希结果,通过此 Topics ,我们可以获得区分不同的事件。读者可以通过 Signature Database 反查具体的事件名称,如下图:

Event Sigs Db

标有 indexed 的变量为根据顺序逐一显示在 Topics 中,通过这些 Topics 我们可以获得合约运行过程中的大量信息。事实上,这也是获得链上智能合约运行信息最常见和最有效的方法,包括钱包在内的大量区块链基础设施都依赖于Event 释放获得的日志信息。由于 Event 如此重要,所以常见的 Event 基本都是由 EIP 规定,以实现兼容性。

假如你构造的 ERC-20 代币进行代币转移时不释放 Transfer 事件,这会导致钱包内对此 ERC20 代币余额信息不更新,对持币人造成巨大困扰。

最后,所有没有标识 indexed 的变量会被放在 Data 内,这部分数据往往重要性不高。

关于 emit 事件释放的底层逻辑,我们在 NFT合约分析:ERC721A 内已经进行过讨论。

在我们的数据源 0xfast 中,这部分数据结构如下:

"logs": [
    {
   
        "address": "0xdac17f958d2ee523a2206206994597c13d831ec7",
        "topics": [
            "0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef",
            "0x0000000000000000000000004ad8d9cf9424b477e77a0d7c339c4de792b92fc6",
            "0x000000000000000000000000a144a5c6aaa3a11dfb63a9b7b836ec35ff7a9bf3"
        ],
        "data": "0x00000000000000000000000000000000000000000000000000000000886f5e40",
        "blockNumber": "0xfcd79e",
        "transactionIndex": "0x1",
        "logIndex": "0x4",
        "@type": "Log"
    }
]
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16

我们需要使用 SQL 语言提取出这一部分并进行保存。

数据清洗

数据导入

此部分与上一篇 一致,如果您当前数据库内仍存在 jsonTemp 表格,可不进行此部分。为方便读者,我们列出 SQL 代码:

CREATE TABLE jsonTemp
(
	field String
)
ENGINE = Memory

INSERT INTO jsonTemp 
SELECT * FROM url('https://eth-uswest.0xfast.com/stream/free?range=16448580-16448680', 'JSONAsString', 'field String');
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8

此处,我们不再详细分析 SQL 代码,读者如感兴趣,请自行参考 上一篇

数据提取

我个人习惯于在进行表格建立前使用 SELECT 进行数据提取,以方便后期的表格建立和插入。

在此处,我决定提取交易的以下数据:

  1. hash 交易的 hash 值
  2. blockNumber 交易所处区块位置
  3. value 交易转移的 ETH 价值
  4. logs 获取智能合约数据,也是本篇文章的核心数据,具体来看,我们需要以下数据:
    1. topics Event 的具体内容
    2. address 释放 Event 的合约地址

读者可根据自身需求选择需要提取的数据。

声明:本文内容由网友自发贡献,不代表【wpsshop博客】立场,版权归原作者所有,本站不承担相应法律责任。如您发现有侵权的内容,请联系我们。转载请注明出处:https://www.wpsshop.cn/w/你好赵伟/article/detail/587545
推荐阅读
相关标签
  

闽ICP备14008679号