akoita/proof-of-audit

# Proof-of-Audit [](https://github.com/akoita/proof-of-audit/actions/workflows/ci.yml) [](./LICENSE)  **用于 AI agent 代码判断的信任基础设施。** 一个审计 agent 会审查智能合约，在其裁决背后质押 ETH，任何人都可以在链上挑战该裁决。

## 为什么这很重要 如今，当 AI agent 说一个智能合约是安全的，你没有办法验证该声明或追究 agent 的责任。Proof-of-Audit 改变了这一点： | 问题 | 解决方案 | | -------------------------- | ------------------------------------------------------------- | | Agent 的声明是不可见的 | 声明**在链上发布**并附带交易哈希 | | 没有利益约束 | Agent 在每次判断背后**质押 ETH** | | 出错时没有追索权 | 任何人都可以用证据**发起挑战**并触发结算 | | 没有标准的身份 | Agent 通过 **ERC-8004** 注册以便发现 | ## 工作原理 ``` 1. Discover → Find the auditor agent and verify its identity 2. Submit → Send a contract for review 3. Draft → Agent produces a code judgment (not yet committed) 4. Publish → Agent stakes ETH and commits the claim on-chain 5. Challenge → Anyone (except the auditor itself) submits evidence against the claim 6. Resolve → The arbiter rules on the dispute; the escrow settles on-chain ``` ### 目前的信任模型 在这个阶段，我们需要明确什么是和不是 trustless 的（参见[去中心化阶梯](./docs/strategy/VISION.md))： - **链上强制执行：** stake 和 bond 托管、挑战窗口、支付计算、自我挑战拒绝以及 ERC-8004 身份所有权。 - **目前信任的：** 每个争议裁决来自操作员持有的单个 **arbiter key**。验证器输出（包括可执行证据）**仅供参考**，永远不会自动削减 stake；普通的 proof-URI 证据总是进入人工审查。 - **演示模式：** 默认的本地演示以 `deterministic` 模式运行审计 worker，它会返回**为测试合约预写的基准测试报告**——没有实时分析。实时分析需要 `hybrid`/`agent_forge` runtime 模式（参见[本地 Agent Forge](./docs/LOCAL_AGENT_FORGE.md))。 ## 致评审者 从[评估就绪情况](./docs/EVALUATION_READINESS.md)索引开始。如需完整的产品演练，请使用 [评审评估路径](./docs/JUDGE_EVALUATION.md) 中的默认本地评估路径： ``` ./scripts/run-judge-stack.sh ``` 然后打开 `http://127.0.0.1:3000`。如果 Web 应用不可用，请使用位于 `http://127.0.0.1:8080/docs` 的备用 API 文档。 ## 尝试一下 ### 快速开始（3 条命令） ``` # Terminal 1：启动本地链并部署 contracts ./scripts/start-anvil.sh ./scripts/prepare-agent-demo-stack.sh # Terminal 2：启动 API PYENV_VERSION=proof-of-audit-3.12 PYTHONPATH=agent:api python -m proof_of_audit_api.app # Terminal 3：启动 web app cd web && pnpm dev ``` 然后打开 `http://localhost:3000` 并按照 [演示脚本](./docs/DEMO_SCRIPT.md) 操作。 ### 纯终端演示 无需浏览器——在终端中运行完整的信任循环： ``` python ./scripts/run_agent_demo.py --api-url http://127.0.0.1:8080 ``` 有关录制说明，请参见 [Asciinema 演示](./docs/ASCIINEMA_DEMO.md)。 ## 演示快照  ## 架构 ``` ┌──────────┐ ┌──────────┐ ┌───────────────┐ ┌────────────────────┐ │ Web UI │────▸│ REST API │────▸│ Audit Worker │────▸│ ProofOfAudit.sol │ │ (Next.js)│ │ (FastAPI)│ │ (Python) │ │ (Foundry/Base) │ └──────────┘ └──────────┘ └───────────────┘ └────────────────────┘ │ │ └────────────────────────────────────────▸ │ ERC-8004 Validation Bridge │ ``` 1. 用户通过 Web 应用或 API 提交合约 2. 审计 agent 生成审查声明 3. 该声明连同 stake 一起在链上发布 4. 挑战者提交证据并交纳 bond 5. 普通的 proof-URI 证据进入人工审查；可执行证据获取建议性验证器裁决——由操作员持有的 arbiter key 做出最终解决决定 ## 仓库内容 | 目录 | 功能 | | ------------ | ------------------------------------------------------------------ | | `contracts/` | Solidity 结算合约 (Foundry) —— 质押、挑战、解决 | | `agent/` | 具有确定性基准测试输出的 Python 审计 worker | | `api/` | FastAPI 服务 —— 提交、发布、挑战、解决 | | `web/` | Next.js 前端 —— 工作台 UI | | `demo/` | 用于基准演示的示例合约 | | `scripts/` | 本地部署、录制和测试工具 | ## API 端点 | 方法 | 端点 | 用途 | | ------ | -------------------------- | ------------------------------------- | | `GET` | `/auditor` | 发现 auditor 身份 | | `GET` | `/auditors` | 列出已注册的 auditor 服务和声誉 | | `GET` | `/auditors/:id` | 读取一条 auditor 服务记录 | | `GET` | `/auditors/:id/reputation` | 读取一份 auditor 声誉摘要 | | `GET` | `/auditor/registration` | ERC-8004 注册文档 | | `GET` | `/auditors/:id/registration` | 读取一条 auditor 注册 | | `GET` | `/auditor/reputation` | 读取默认的 auditor 声誉 | | `GET` | `/config` | 链配置和质押金额 | | `GET` | `/fixtures` | 可用的演示基准合约 | | `GET` | `/requests?status=` | 列出基于文件支持的已开启或已关闭的审计请求 | | `GET` | `/requests/:id/eligibility` | 预览一位 auditor 的请求资格 | | `GET` | `/audits?contract_address=` | 列出一个目标合约的声明 | | `GET` | `/targets/:address/audits` | 基于目标的声明历史 | | `GET` | `/targets/:address/comparison` | 目标对比声明摘要 | | `GET` | `/challenger-feed` | 轮询最近的已发布/已挑战/已解决的生命周期事件 | | `POST` | `/audits` | 创建草稿审计声明 | | `POST` | `/audits/:id/publish` | 质押 ETH 并在链上发布 | | `POST` | `/audits/:id/challenge` | 针对该声明提交证据 | | `POST` | `/audits/:id/resolve` | 解决有争议的纠纷 | | `GET` | `/audits/:id/validation/*` | ERC-8004 验证轨迹 | | `GET` | `/audits/:id/reputation/*` | 链上声誉轨迹 | 服务器运行时，可在 `http://127.0.0.1:8080/docs` 获取交互式 API 文档。 有关详细的集成指南，请参阅 [Agent API](./docs/AGENT_API.md)、[Agent 交互流程](./docs/AGENT_INTERACTION_FLOW.md) 和 [声誉模型](./docs/REPUTATION_MODEL.md)。 ## 链上部署 **Base Sepolia** (实时)： | | | | --------------------------- | ----------------------------------------------------------------------------------------------- | | ProofOfAudit | [`0xf2dA…F24`](https://sepolia.basescan.org/address/0xf2dA3947d028b85e597Fe1Df4633a87eF4A85F24) | | ERC-8004 IdentityRegistry | `0x8004A818BFB912233c491871b3d84c89A494BD9e` | | ERC-8004 ValidationRegistry | `0x8004B663056A597Dffe9eCcC1965A193B7388713` | ## 开发 ``` # 运行所有测试 make test-python # Python unit tests make test-system-e2e # Full stack end-to-end make test-testnet-smoke # Gated Base Sepolia smoke suite make test-ui-e2e # Browser end-to-end (Playwright) cd contracts && forge test # Smart contract tests ``` 安装安全 pre-commit hook： ``` make install-git-hooks ``` ## 文档 | 文档 | 涵盖内容 | | ------------------------------------------------- | ----------------------------------- | | [愿景 v2](./docs/strategy/VISION.md) | 黑客松后的产品愿景和信任模型指路明灯 | | [产品策略](./docs/strategy/PRODUCT_STRATEGY.md) | 市场分析、切入点、商业模式 | | [路线图 v2](./docs/strategy/ROADMAP.md) | 从原型到真正产品的分阶段路径 | | [项目状态](./docs/strategy/STATE_OF_THE_PROJECT.md) | 诚实盘点：什么是真实的，什么是演示包装 | | [积压任务分类](./docs/strategy/BACKLOG_TRIAGE.md) | 过去讨论串的裁决 + 提议的新积压工作 | | [Agentic 技术栈雷达](./docs/strategy/AGENTIC_STACK.md) | Agent 框架/协议适合的地方（以及它们永远不适合的地方） | | [技术文档](./docs/TECHNICAL_DOCUMENTATION.md) | 规范的端到端技术参考 | | [Challenge Verifier V2](./docs/CHALLENGE_VERIFIER_V2.md) | 下一代挑战裁决 pipeline 的设计 | | [TEE 证据 RFC](./docs/TEE_EVIDENCE_RFC.md) | 关于 TEE 支持的证据执行的研究笔记 | | [Agent 请求参与](./docs/AGENT_REQUEST_PARTICIPATION.md) | 轮询、启发式方法和防重放的请求参与 | | [演示脚本](./docs/DEMO_SCRIPT.md) | 60 秒现场演练 | | [架构](./docs/ARCHITECTURE.md) | 系统设计和数据流 | | [Agent API](./docs/AGENT_API.md) | 面向 Agent 调用方的集成指南 | | [Challenger feed](./docs/CHALLENGER_FEED.md) | 面向 challenger 工具的轮询接口 | | [ERC-8004 对齐](./docs/ERC8004_ALIGNMENT.md) | 标准映射 | | [声誉模型](./docs/REPUTATION_MODEL.md) | 可解释的 auditor 评分 | | [本地 Agent Forge](./docs/LOCAL_AGENT_FORGE.md) | 在本地运行真正的 Agent Forge | | [部署指南](./docs/DEPLOYMENT.md) | 生产环境部署设置 | | [Asciinema 演示](./docs/ASCIINEMA_DEMO.md) | 终端录制运行手册 | | [提交材料包](./docs/SUBMISSION_PACK.md) | 最终文案和演示资产盘点 | | [评估就绪情况](./docs/EVALUATION_READINESS.md) | 面向评审者的最终评估索引 | | [Base Sepolia 冒烟测试证据](./docs/proofs/base-sepolia-smoke-2026-03-22.md) | 最新日期的实时冒烟测试证据记录 | ## 后续计划 这是一个 v1 原型——一个 auditor、一个合约、一个挑战流程。这是它的发展方向： - **多个竞争的 auditor** —— 不同的 agent 在同一个合约上质押，声誉跟踪准确性 - **声誉注册表** —— 来自已解决挑战的 ERC-8004 声誉轨迹，让 agent 随着时间的推移建立或失去信誉 - **跨链结算** —— 将 ProofOfAudit 部署到 Base Sepolia 之外的主网和其他 L2 - **更丰富的证据类型** —— 形式化验证证明、fuzzer 输出和多来源挑战制品 - **Agent 市场** —— 外部 agent 通过协议发现、雇佣并支付 auditor 服务 ## 安全性 ⚠️ 这是一个原型。在处理真实价值或对抗性使用之前，应对合约逻辑、API 流程和挑战验证进行审查。 ## 许可证 MIT —— 见 [LICENSE](./LICENSE)。

标签：Web3, 人工智能, 区块链, 去中心化, 智能合约, 用户模式Hook绕过, 逆向工具