2025年12月 - 2026年1月

AccessAudit - 链上访问审批与审计系统

Sepolia 测试网部署与 Etherscan 验证 + Dune 事件统计 Dashboard

区块链智能合约Web3数据分析
AccessAudit - 链上访问审批与审计系统
点击查看大图

项目资源

在 GitHub 上查看开源智能合约代码,在 Etherscan 上查看已验证的合约,或浏览 Dune Analytics 数据看板。

项目背景与动机

在准备深造申请一个关于 Web3 的项目过程中,我意识到对 Web3/去中心化系统的"可信执行、可审计、开放数据接口"的兴趣,仅仅停留在概念理解层面是不够的。我需要通过实际项目来验证自己的理解深度和工程能力。

因此,我从 12 月初开始,以"从零到可核验产出"为目标,刻意选择了一个能够体现 Web3 基础能力闭环的最小题目:链上访问审批与审计(Access Approval & Audit Logs)。

之所以选这个题,是因为它同时覆盖了去中心化应用中最核心的三件事:

权限控制(Role-based Access Control)

现实系统里的访问审批、数据授权、角色管理在链上如何表达。

可审计事件日志(Event Logs)

链上数据的"可验证接口",以及如何用事件构建审计轨迹。

链上数据分析(On-chain Analytics)

把事件日志变成指标、图表、Dashboard,形成可展示的分析证据。

技术栈

本项目使用现代化的Web3开发工具链,从智能合约开发到链上部署,再到数据分析,形成完整的技术闭环。

区块链平台

Ethereum Sepolia TestnetChain ID: 11155111Solidity ^0.8.20OpenZeppelin Contracts

开发工具

Foundry (forge/cast/anvil)WSL UbuntuGit & GitHub

基础设施

Alchemy RPCMetaMaskEtherscan

数据分析

Dune AnalyticsPostgreSQL (Dune SQL)

学习路径与参考资源

为避免"只看概念、缺少工程落地"的学习方式,我采取了"工具链 + 最小项目驱动"的路径,主要参考以下公开视频与教程站点完成入门与实践:

我的策略不是"把课程看完",而是边学边做:每掌握一个关键概念(合约/交易/事件/topic/RPC/测试),就把它落实进 AccessAudit 的实现与验证步骤里,确保最后能形成外部可核验成果。

合约设计与实现

合约目标:链上访问审批与审计(最小但可扩展)

我实现的 AccessAudit 是一个最小化的"访问请求—审批决策—审计留痕"系统,核心设计为:

角色(Role)

使用 OpenZeppelin 的 AccessControl,定义 APPROVER_ROLE 作为审批者角色;部署者/管理员负责授予角色。

请求(Request)

用户通过 requestAccess(payloadHash) 提交访问请求。这里我用 payloadHash 表示"被访问资源/数据集/权限范围"的摘要(哈希),避免把敏感信息直接上链。

审批(Decision)

审批者通过 decide(id, approved) 对某次请求进行批准/拒绝。

事件(Events)

关键状态变化都通过事件写入链上日志,例如 AccessRequested 与 AccessDecided。事件是链上审计的"事实记录",同时也是后续数据分析的基础。

AccessAudit 智能合约

这个设计虽然简单,但在系统层面覆盖了典型的组织访问控制逻辑:谁能发起、谁能批准、批准结果如何可追溯,以及如何把"审计证据"标准化写入链上。

AccessAudit 智能合约

solidity

工具链与工程化(Foundry + WSL)

我在 WSL Ubuntu 环境下使用 Foundry 工具链完成完整工程流程:

forge

编译合约、运行单元测试、执行部署脚本(支持 dry-run 与 broadcast)

cast

以命令行方式与合约交互、发送交易、查询链上数据(call/logs/receipt 等)

anvil

本地链用于快速迭代验证(后续再迁移到 Sepolia)

单元测试:用"可验证的失败/成功"保证可信度

我为合约编写了至少三类单元测试,覆盖关键安全与逻辑分支:

01
请求创建正确

id 自增、请求存储正确、事件发出

02
权限控制正确

只有拥有 APPROVER_ROLE 的账户才能 decide(包含 revert 测试)

03
状态不可重放

已被决定的请求不能再次决定(包含 revert 测试)

部署到 Sepolia 与验证

为了让成果具备外部可信度,我将合约部署到以太坊 Sepolia 测试网,并完成了完整的可核验证据链:

我从"什么是钱包/地址/私钥/测试币"的零基础出发,完成测试网账户准备与最小资金管理(仅用于 gas),理解了 RPC 的角色(链上读写的"入口"),并使用 Alchemy 获得可用的 Sepolia RPC。最终完成 Etherscan 源码验证(Verified),让源码、ABI、方法签名可公开查询。

合约信息

网络以太坊 Sepolia
链 ID11155111
状态已验证 ✓
合约地址
0xaED7...c60E

Etherscan 上的已验证合约

关键交易

① 部署合约

交易哈希: 0xfc08...91ef

部署 AccessAudit 合约并将 DEFAULT_ADMIN_ROLE 授予部署者地址。

② 授予 APPROVER_ROLE

交易哈希: 0xb39f...d53d

将 APPROVER_ROLE 授予指定的审批者地址,以启用访问请求审批。

③ 请求与审批访问

请求交易: 0x582f...f622

审批交易: 0x7ec6...19b5

用户使用哈希负载请求访问,审批者批准请求,发出相应事件。

Dune 事件分析与可视化 Dashboard

在完成链上部署与交互之后,我进一步用 Dune 把链上事件转化为可读的统计结果与可视化看板。我的切入点是直接使用 Dune 的 sepolia.logs 原始日志表进行分析,而不是依赖"已经解析好的项目表",这样可以体现我对 EVM 事件结构的理解:

我通过 contract_address 过滤出本合约的日志;用 topic0(事件签名哈希)区分不同事件:AccessRequested / AccessDecided;用 topic1(索引参数)关联同一条请求的 id,从而把请求与审批决策 join 起来。

Dune Analytics 看板概览

核心 SQL 查询

每日访问请求数(Daily Requests)

通过过滤具有合约地址和事件签名(topic0)的日志,统计每天的 AccessRequested 事件数量。

每日访问请求数(Daily Requests)

sql
每日审批通过率(Daily Approval Rate)

在 request_id(topic1)上关联 AccessRequested 和 AccessDecided 事件,计算每天的审批通过率。

每日审批通过率(Daily Approval Rate)

sql

项目总结

通过这个项目,我完成了从智能合约开发、测试网部署、源码验证到链上数据分析的完整工程实践:

GitHub 仓库包含合约源码、测试、部署脚本、环境配置示例与复现说明 ✓
Sepolia 合约可在区块浏览器查看部署与交互记录,Etherscan 源码验证 ✓
Dune 看板SQL 可见、图表可见、Dashboard 可分享 ✓

核心收获:从 0 到 1 的系统理解

完整的工程闭环

理解并实践了:合约、账户、交易、gas、RPC、测试网、部署、交互、回执、事件日志

链上"可审计性"的技术载体

明白了链上"可审计性"的技术载体:事件日志(topics/data)

链上数据分析能力

能够将链上原始 logs 直接用于分析(Dune SQL),并输出可视化看板

Web3 安全与最佳实践

对"权限控制是安全基线"的认识更具体:角色模型、权限校验、状态不可重放等

如果后续继续深化,我计划扩展更像真实系统的审计指标,例如审批延迟(request_time 到 decide_time)、拒绝率、活跃请求者、以及角色变更的审计统计,并逐步从测试网迁移到更接近真实生态的链上环境。