AccessAudit - 链上访问审批与审计系统
Sepolia 测试网部署与 Etherscan 验证 + Dune 事件统计 Dashboard

项目资源
在 GitHub 上查看开源智能合约代码,在 Etherscan 上查看已验证的合约,或浏览 Dune Analytics 数据看板。
项目背景与动机
在准备深造申请一个关于 Web3 的项目过程中,我意识到对 Web3/去中心化系统的"可信执行、可审计、开放数据接口"的兴趣,仅仅停留在概念理解层面是不够的。我需要通过实际项目来验证自己的理解深度和工程能力。
因此,我从 12 月初开始,以"从零到可核验产出"为目标,刻意选择了一个能够体现 Web3 基础能力闭环的最小题目:链上访问审批与审计(Access Approval & Audit Logs)。
之所以选这个题,是因为它同时覆盖了去中心化应用中最核心的三件事:
权限控制(Role-based Access Control)
现实系统里的访问审批、数据授权、角色管理在链上如何表达。
可审计事件日志(Event Logs)
链上数据的"可验证接口",以及如何用事件构建审计轨迹。
链上数据分析(On-chain Analytics)
把事件日志变成指标、图表、Dashboard,形成可展示的分析证据。
技术栈
本项目使用现代化的Web3开发工具链,从智能合约开发到链上部署,再到数据分析,形成完整的技术闭环。
区块链平台
开发工具
基础设施
数据分析
学习路径与参考资源
为避免"只看概念、缺少工程落地"的学习方式,我采取了"工具链 + 最小项目驱动"的路径,主要参考以下公开视频与教程站点完成入门与实践:
我的策略不是"把课程看完",而是边学边做:每掌握一个关键概念(合约/交易/事件/topic/RPC/测试),就把它落实进 AccessAudit 的实现与验证步骤里,确保最后能形成外部可核验成果。
合约设计与实现
合约目标:链上访问审批与审计(最小但可扩展)
我实现的 AccessAudit 是一个最小化的"访问请求—审批决策—审计留痕"系统,核心设计为:
角色(Role)
使用 OpenZeppelin 的 AccessControl,定义 APPROVER_ROLE 作为审批者角色;部署者/管理员负责授予角色。
请求(Request)
用户通过 requestAccess(payloadHash) 提交访问请求。这里我用 payloadHash 表示"被访问资源/数据集/权限范围"的摘要(哈希),避免把敏感信息直接上链。
审批(Decision)
审批者通过 decide(id, approved) 对某次请求进行批准/拒绝。
事件(Events)
关键状态变化都通过事件写入链上日志,例如 AccessRequested 与 AccessDecided。事件是链上审计的"事实记录",同时也是后续数据分析的基础。
AccessAudit 智能合约
这个设计虽然简单,但在系统层面覆盖了典型的组织访问控制逻辑:谁能发起、谁能批准、批准结果如何可追溯,以及如何把"审计证据"标准化写入链上。
AccessAudit 智能合约
工具链与工程化(Foundry + WSL)
我在 WSL Ubuntu 环境下使用 Foundry 工具链完成完整工程流程:
forge
编译合约、运行单元测试、执行部署脚本(支持 dry-run 与 broadcast)
cast
以命令行方式与合约交互、发送交易、查询链上数据(call/logs/receipt 等)
anvil
本地链用于快速迭代验证(后续再迁移到 Sepolia)
单元测试:用"可验证的失败/成功"保证可信度
我为合约编写了至少三类单元测试,覆盖关键安全与逻辑分支:
请求创建正确
id 自增、请求存储正确、事件发出
权限控制正确
只有拥有 APPROVER_ROLE 的账户才能 decide(包含 revert 测试)
状态不可重放
已被决定的请求不能再次决定(包含 revert 测试)
部署到 Sepolia 与验证
为了让成果具备外部可信度,我将合约部署到以太坊 Sepolia 测试网,并完成了完整的可核验证据链:
我从"什么是钱包/地址/私钥/测试币"的零基础出发,完成测试网账户准备与最小资金管理(仅用于 gas),理解了 RPC 的角色(链上读写的"入口"),并使用 Alchemy 获得可用的 Sepolia RPC。最终完成 Etherscan 源码验证(Verified),让源码、ABI、方法签名可公开查询。
合约信息
Etherscan 上的已验证合约
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 看板概览
Dune Analytics 看板概览核心 SQL 查询
每日访问请求数(Daily Requests)
通过过滤具有合约地址和事件签名(topic0)的日志,统计每天的 AccessRequested 事件数量。
每日访问请求数(Daily Requests)
每日请求量图表每日审批通过率(Daily Approval Rate)
在 request_id(topic1)上关联 AccessRequested 和 AccessDecided 事件,计算每天的审批通过率。
每日审批通过率(Daily Approval Rate)
每日审批通过率图表项目总结
通过这个项目,我完成了从智能合约开发、测试网部署、源码验证到链上数据分析的完整工程实践:
核心收获:从 0 到 1 的系统理解
完整的工程闭环
理解并实践了:合约、账户、交易、gas、RPC、测试网、部署、交互、回执、事件日志
链上"可审计性"的技术载体
明白了链上"可审计性"的技术载体:事件日志(topics/data)
链上数据分析能力
能够将链上原始 logs 直接用于分析(Dune SQL),并输出可视化看板
Web3 安全与最佳实践
对"权限控制是安全基线"的认识更具体:角色模型、权限校验、状态不可重放等
如果后续继续深化,我计划扩展更像真实系统的审计指标,例如审批延迟(request_time 到 decide_time)、拒绝率、活跃请求者、以及角色变更的审计统计,并逐步从测试网迁移到更接近真实生态的链上环境。