askledger/receipts-sdk

# AskLedger · Receipts SDK 面向企业 AI 的开源、厂商中立加密信任底座。每一次 AI 调用都会产生一个经过签名、哈希链化且防篡改的收据，审计员、监管机构和保险公司只需使用公钥即可独立验证。无平台依赖。 **[开放规范 · PL-RFC-001…010](spec/README.md)** · **[一致性](conformance/README.md)** · **[架构](docs/ARCHITECTURE.md)** · **[策略映射](docs/POLICY_MAPPING.md)** · **[安全](SECURITY.md)** · **[贡献](CONTRIBUTING.md)** [](LICENSE) [](https://nodejs.org) [](spec/README.md) [](conformance/README.md) [](#testing) [](docs/security/HARDENING_CHECKLIST.md) ## 项目状态 **v0.6.0 · 已在 npm 上线（v0.7.0 已打标签，待发布）。** 加密核心已经过强化且可独立验证 —— 跨语言一致性测试确保了 TypeScript、Python、Go、Rust 和 Java SDK 之间生成字节级完全相同的收据，并且 CI 中运行着经机器检查的强化清单。SDK、集成、浏览器扩展、控制台、公开验证器、规范和一致性程序均已公开提供。第三方渗透测试和 SOC 2 Type II 报告计划于 2026 年第四季度至 2027 年第一季度进行，托管 SaaS 正在开发中。我们目前处于**设计合作伙伴阶段**，欢迎架构审查、试点意向以及标准组织的共同署名。 - 包：[npm install @askledger/receipts-sdk](https://www.npmjs.com/package/@askledger/receipts-sdk) - 网站：[askledger.org](https://askledger.org) - 源码：[github.com/askledger/receipts-sdk](https://github.com/askledger/receipts-sdk) - 联系方式：[hello@askledger.org](mailto:hello@askledger.org) ## 安装 ``` npm install @askledger/receipts-sdk ``` 或从源码安装： ``` git clone https://github.com/askledger/receipts-sdk cd receipts-sdk npm install npm run build ``` ## 签署你的第一份收据 ``` import { generateKeyPair, signReceipt, verifyReceipt } from "@askledger/receipts-sdk"; const keypair = generateKeyPair(); const receipt = signReceipt({ event: { schema_version: "1.0", tenant_id: "acme", event_type: "gateway.request", source_system: "my-app", event_id: "evt-001", captured_at: new Date().toISOString(), subject: { ai_vendor: "anthropic", ai_model: "claude-sonnet-4-6" }, payload: { input_classification: "internal", output_classification: "internal" }, }, keypair, }); const result = verifyReceipt(receipt, { publicKeys: { [keypair.kid]: keypair.public_key }, }); console.log(result.valid); // true ``` 就是这样。只需六行代码，你就拥有了一份可供监管机构验证的收据。 ## 封装你的 AI 供应商 ``` import OpenAI from "openai"; import { wrapOpenAI, generateKeyPair } from "@askledger/receipts-sdk"; const client = wrapOpenAI(new OpenAI({ apiKey }), { tenantId: "acme", keypair: generateKeyPair(), // production: HSM-backed onReceipt: async (r) => store.append(r), }); // Your application code is unchanged. const resp = await client.chat.completions.create({ model: "gpt-5", messages }); console.log(resp.x_ledger_receipt_id); // cryptographic evidence id ``` 目前可用的适配器：`wrapOpenAI` · `wrapAnthropic` · `withReceipts(fetch)`（覆盖 11 家供应商）· 面向 LangChain 的 `ReceiptsCallbackHandler`。 ## 免安装体验 ``` git clone https://github.com/askledger/receipts-sdk.git && cd receipts-sdk npm install && npm run build node dist/cli.js demo ``` 你会看到类似如下的输出： ``` ──────────────────────────────────────────────────────────────────────── AskLedger — Receipts SDK · Demo ──────────────────────────────────────────────────────────────────────── 1. Generating Ed25519 keypair… kid: dev-3a7c9b2e8f4a 2. Signing a sample AI event… receipt_id: 01HXYZ123ABC... receipt_hash: 9a4f8e0c2b1d3a6c... chain_height: 1 3. Verifying receipt independently (no Ledger server needed)… ✓ canonical hash matches ✓ Ed25519 signature valid ✓ RECEIPT VALID ``` 就是这样。收据存放在 `.ledger/last-receipt.json` 中。密钥对存放在 `.ledger/keys/default.json` 中。链状态存放在 `.ledger/chains/` 中。**这一切都不需要向 AskLedger 发起网络调用。** 监管机构在验证此收据时只需用到公钥。 ## 收据的样貌 ``` { "receipt": { "schema_version": "1.0", "receipt_id": "01HXYZ123ABC...", "tenant_id": "demo-tenant", "issued_at": "2026-05-13T10:30:00.123456789Z", "event": { "schema_version": "1.0", "event_type": "ide.completion", "source_system": "vs-code-plugin", "captured_at": "2026-05-13T10:30:00.000Z", "subject": { "ai_vendor": "anthropic", "ai_model": "claude-sonnet-4-6", "ai_capability": "code-completion" }, "payload": { "input_hash": "9a4f8e0c2b1d3a6c...", "input_classification": "internal", "input_token_count": 245 } }, "integrity": { "previous_receipt_hash": "0000...0000", "receipt_hash": "9a4f8e0c2b1d3a6c...", "chain_height": 1 } }, "signatures": [ { "alg": "EdDSA", "kid": "dev-3a7c9b2e8f4a", "sig": "base64-encoded-Ed25519-signature..." } ] } ``` 每个字段都是规范哈希的一部分。对任何字段的任何修改 —— 包括重新排列键的顺序 —— 都会破坏签名。 ## 编程式用法 ``` import { generateKeyPair, signReceipt, verifyReceipt, } from "@askledger/receipts-sdk"; // 1. Generate (or load) a keypair const kp = generateKeyPair(); // 2. Sign an AI event const signed = signReceipt({ event: { schema_version: "1.0", tenant_id: "tenant-001", event_type: "ide.completion", source_system: "vs-code-plugin", event_id: "evt-123", captured_at: new Date().toISOString(), subject: { ai_vendor: "anthropic", ai_model: "claude-sonnet-4-6", ai_capability: "code-completion", }, }, keypair: kp, }); // 3. Anyone can verify with just the public key const result = verifyReceipt(signed, { publicKeys: { [kp.kid]: kp.public_key }, }); console.log(result.valid); // true ``` ## CLI 参考 ``` # 生成 keypair（生产环境使用 HSM-backed，开发环境使用 JSON 文件） node dist/cli.js keygen --out .ledger/keys/default.json # 签名事件（按 tenant 自动链式连接） node dist/cli.js sign examples/event.json # 使用 public key 验证 receipt node dist/cli.js verify .ledger/last-receipt.json # 验证链的连续性至先前的 receipt node dist/cli.js verify .ledger/last-receipt.json --prev .ledger/prev.json # 完整演示周期 node dist/cli.js demo ``` ## 工作原理 · 加密设计 | 层级 | 选择 | 原因 | |---|---|---| | **规范化** | [RFC 8785 (JCS)](https://datatracker.ietf.org/doc/html/rfc8785) | 确定性的 JSON 字节表示。独立的验证者能够从相同的数据计算出相同的哈希。这是实现独立于监管机构的验证的基础要求。 | | **哈希算法** | SHA-256 | 标准、经审计且安全边际广为人知。 | | **签名** | Ed25519 ([EdDSA](https://datatracker.ietf.org/doc/html/rfc8032)) | 快速（约 70µs/签名），确定性（无随机 nonce 重用风险），被 Signal、WireGuard、Sigstore 采用。 | | **编码** | [JWS](https://datatracker.ietf.org/doc/html/rfc7515) base64 | 标准，可跨平台解析。 | | **链化** | 每租户追加式哈希链 | 每份收据的 `previous_receipt_hash` 是前一份收据规范字节的 SHA-256 哈希。篡改任何历史收据都会破坏随后的所有收据。 | | **ID 生成** | UUIDv7 | 可排序，内嵌时间戳，抗碰撞。 | | **后量子时代准备** | 计划在 v2 中采用混合签名方案（Ed25519 + Dilithium） | 实际的量子威胁尚需 8–12 年才会出现；而数据保留期为 7–10 年。迁移计划已记录在案。 | **实现库：** - [`@noble/ed25519`](https://github.com/paulmillr/noble-ed25519) — 经审计的纯 TypeScript Ed25519 - [`@noble/hashes`](https://github.com/paulmillr/noble-hashes) — 经审计的哈希算法 - [`canonicalize`](https://www.npmjs.com/package/canonicalize) — RFC 8785 实现 ## 标准与兼容性 本 SDK 旨在与软件供应链安全中已使用的标准进行组合，而非与之竞争： | 标准 | 关系 | |---|---| | [Sigstore Model Signing (OMS)](https://github.com/sigstore/model-transparency) | 用于收据内的模型身份验证 | | [in-toto Attestation Framework (ITE-6)](https://github.com/in-toto/attestation) | 来源声明的信封格式参考 | | [SLSA](https://slsa.dev/) | 构建时证明参考；收据则涵盖运行时 | | [OpenTelemetry GenAI Semantic Conventions](https://opentelemetry.io/docs/specs/semconv/gen-ai/) | 事件字段对齐 | | [OWASP AIBOM](https://owaspaibom.org/) | 从收据中提取并填充的 AI 物料清单 | | [SPIFFE/SPIRE](https://spiffe.io/) | 用于服务间调用的工作负载身份 | 我们并没有重新发明加密原语。我们只是将它们组合成一个专门针对 **AI 运行时问责制**的层面 —— 这是现有标准均未涉足的领域。 ## 路线图 ### v0.2（下一版本） - Rust 参考验证器 - Python SDK - Go SDK - RFC 3161 时间戳集成（FreeTSA + DigiCert） - Merkle 承诺 + 透明日志集成 - HSM 签名参考（PKCS#11） ### v0.3 - 另外 5 种语言的参考实现 - 收据浏览器（Web UI） - OpenTelemetry GenAI 规范桥接 - 客户管理密钥参考设计 ### v1.0（目标：第 2 年） - 稳定的传输格式 - Linux Foundation AI 托管标准 - 一致性测试套件 - 第三方验证器生态系统 ## 免安装体验 基于浏览器的体验沙盒和验证器已包含在此存储库中的 [`site/playground.html`](site/playground.html) 和 [`site/verify.html`](site/verify.html)。在浏览器中打开任一文件，即可生成密钥对、签署示例事件并验证生成的收据 —— 全程在客户端完成，无需服务器，也无需安装。 线上托管版本位于： [askledger.github.io/receipts-sdk/playground.html](https://askledger.github.io/receipts-sdk/playground.html)。 ## 文档 | 文档 | 内容简介 | |---|---| | [**Receipts Protocol Spec v0.1**](docs/RECEIPTS_PROTOCOL.md) | 形式化的信封结构、schema、哈希和验证规则 —— IETF 风格。候选由 Linux Foundation AI 托管。 | | [**架构**](docs/ARCHITECTURE.md) | 分层概述、逐文件解析、设计决策、性能指标。 | | [**示例文件夹**](examples/README.md) | 端到端集成模式。 | | [**Python SDK**](python-sdk/README.md) | 传输格式兼容的 Python 实现。 | | [**一致性向量**](test/conformance/README.md) | 共享的跨语言测试向量。任何新的 SDK 通过逐字节匹配这些向量即可通过一致性测试。 | | [**CHANGELOG**](CHANGELOG.md) | 版本历史 + 迈向 v1.0 的路线图。 | | [**贡献指南**](CONTRIBUTING.md) | 如何构建、测试和提出修改建议。 | | [**安全策略**](SECURITY.md) | 如何报告漏洞。 | ## 自动捕获适配器 — 支持任意 AI 工具 SDK 附带开箱即用的捕获适配器，使你技术栈中的每一次 AI 调用都会发出签名收据，且无需更改应用程序代码。 | 适配器 | 封装对象 | 一行代码调用 | |---|---|---| | `wrapOpenAI(client, ctx)` | 官方 `openai` SDK 及任何兼容 OpenAI 的提供商（LiteLLM, Groq, Together, Mistral OpenAI-compat, DeepSeek, Anyscale） | 封装 `chat.completions.create` + `embeddings.create` | | `wrapAnthropic(client, ctx)` | 官方 `@anthropic-ai/sdk` | 封装 `messages.create` | | `withReceipts(ctx)` | 任意全局 `fetch` | 检测对 OpenAI、Azure OpenAI、Anthropic、Google Gemini、Bedrock、Cohere、Hugging Face、Mistral、Groq、Together、Vercel AI Gateway 的调用。可通过 `extraPatterns` 支持自定义 endpoint。 | | `ReceiptsCallbackHandler` | LangChain.js | 实现 `BaseCallbackHandler` 接口；可直接插入任何 chain 或 agent | 模式： ``` import OpenAI from "openai"; import { wrapOpenAI, generateKeyPair } from "@askledger/receipts-sdk"; const client = wrapOpenAI(new OpenAI({ apiKey }), { tenantId: "acme-corp", keypair: generateKeyPair(), onReceipt: async (r) => store.append(r), // ship to durable store }); // Application code is unchanged const resp = await client.chat.completions.create({...}); console.log(resp.x_ledger_receipt_id); // cryptographic evidence id ``` 来自被封装客户端的错误总是会向上传播 —— 收据机制绝不会导致其所监控的 AI 调用中断。 ## 多语言 | SDK | 语言 | 状态 | 一致性 | |---|---|---|---| | `@askledger/receipts-sdk` | TypeScript / Node 18+ / 浏览器 | npm 上的 v0.6.0 · 304 个测试通过 | 参考实现 | | `askledger-receipts` (Python, 导入 `projectledger.receipts`) | Python 3.10+ | 源码运行（尚未在 PyPI）· 与 TS 向量交叉验证 | 交叉验证 | | `github.com/askledger/receipts-sdk/go-sdk` | Go 1.22+ | `go get`（基于 git）· 与 TS 向量交叉验证 | 交叉验证 | | `askledger-receipts` (Rust crate) | Rust 1.75+ | 源码运行（git 依赖，尚未在 crates.io）· 与 TS 向量交叉验证 | 交叉验证 | | `io.projectledger:receipts-sdk` (Java) | Java 17+ | 源码运行（尚未在 Maven Central）· 与 TS 向量交叉验证 | 交叉验证 | 传输格式的兼容性由[共享一致性向量](test/conformance/)强制保障，每个 SDK 都必须通过该测试。 ## 生产强化模块 这些是 v0.2 版本的功能面，旨在将参考 SDK 转化为可部署于生产环境的底座。 | 模块 | 提供的功能 | 适用场景 | |---|---|---| | `SoftwareSigningProvider` | 内存中的 Ed25519 密钥 | 开发、浏览器沙盒、中小企业 | | `HSMSigningProvider` | 面向 PKCS#11 / AWS CloudHSM / Azure Key Vault / GCP KMS 的接口 | 受监管的 BFSI、需要 FIPS 的部署环境 | | `TSAClient` (RFC 3161) | 真正的 RFC 3161 TimeStampReq 编码器 + 网络 client（默认：FreeTSA；通过 Basic Auth 支持商业 TSA） | 当你需要独立证明“这是何时签署的”时 | | `buildBatch` / `verifyInclusion` (Merkle) | 带有包含证明的 SHA-256 二进制 Merkle 树（采用 RFC 9162 叶子/内部节点前缀方案 —— 防范第二原像攻击） | 向透明日志进行批量承诺；证明某份收据属于已承诺集合 | | `PostgresChainStateStore` | 带有 CAS 并发控制和行级安全模式的 Postgres 链状态后端 | 超出单进程规模的 SaaS 多租户部署 | | `MemoryChainStateStore` | 进程内后端 | 测试、serverless | | `KeyRegistry` | 密钥轮换、废弃、撤销、具备历史时间窗口感知的受信任密钥集 | 长期存在的签发方（按 NIST SP 800-57 规定每 90 天轮换一次密钥） | ## 性能 通过 `npm run bench` 测得的数据（热身后的 5000 次迭代，Node 22，沙盒 Linux/arm64）： | 操作 | p50 | p95 | p99 | |---|---|---|---| | `canonicalize` (RFC 8785) | 5.4 µs | 7.7 µs | 13.2 µs | | `sha256` (规范字节) | 6.7 µs | 11.3 µs | 22.5 µs | | Ed25519 sign | 425 µs | 551 µs | 662 µs | | Ed25519 verify | 1.78 ms | 1.96 ms | 2.06 ms | | `signReceipt` 端到端 | 1.64 ms | 2.13 ms | 2.47 ms | | `verifyReceipt` 端到端 | 1.91 ms | 2.13 ms | 2.26 ms | 注：Ed25519 的数据反映的是纯 TypeScript 的 `@noble/ed25519`（零原生依赖，经过审计）。当部署针对原生的 libsodium 绑定或 HSM 时，签名耗时降至约 70 µs。`signReceipt` 的主要开销在于规范化以及用于链状态的文件 I/O —— 生产环境的部署会将文件后端替换为 Postgres + HSM，从而完全保持在企业网关的延迟预算范围内。 ## 生态系统 · 相关开源项目 AskLedger 并不是加密 AI 收据领域的唯一成果。以下项目致力于解决重叠的问题，我们在此对他们公开致谢： | 项目 | 重点领域 | |---|---| | [Sigstore Model Signing (OMS)](https://github.com/sigstore/model-transparency) | 构建时的模型产物签名 | | [in-toto](https://in-toto.io/) / [SLSA](https://slsa.dev/) | 构建流水线证明 | | [OWASP AIBOM](https://owaspaibom.org/) | AI 物料清单 | | [OpenTelemetry GenAI](https://opentelemetry.io/docs/specs/semconv/gen-ai/) | 运行时遥测规范 | | AgentMint, OrgKernel, Pipelock, ArkForge, Garl Protocol, AEGIS, Nono | 独立的收据/审计 SDK（完成度不一） | **我们的差异化优势。** 本 SDK 专注于 **运行时 AI 决策收据** —— 即将单次 AI 事件绑定到租户、策略、模型身份以及哈希链位置的加密信封。我们与构建时的证明（Sigstore, in-toto, SLSA）、OWASP AIBOM 以及 OpenTelemetry GenAI 语义规范进行组合。商业版 AskLedger 平台在此基础之上叠加了验证器模型、监管门户、证据包以及针对 BFSI-MENA 地区的特定框架映射 —— 采用开放核心模式，类似 Datadog / HashiCorp / Sentry 的模式。 ## 真实的生产就绪清单 · v0.3 | 能力 | 状态 | |---|---| | **底座** | | | RFC 8785 规范化 JSON | ✅ 已发布，在 5 种语言中完成了一致性测试 | | Ed25519 签名 | ✅ 已发布 (`@noble/ed25519`, `cryptography`, stdlib, `ed25519-dalek`, Bouncy Castle) | | SHA-256 | ✅ 已发布 | | 每租户哈希链 | ✅ 已发布，通过了篡改测试 + 模糊测试 | | 独立的第三方验证器 | ✅ 已发布 | | Receipts Protocol Spec v0.1 | ✅ 已发布，IETF 风格 | | 输入验证 + 结构化错误 | ✅ 已发布 | | **测试** | | | 120 项 TypeScript 测试 | ✅ 通过 | | 12 项 Python 测试 | ✅ 通过 | | 3 项 Go 测试 | ✅ 通过 | | Rust 测试 | ✅ 代码已发布；cargo 在 CI 中运行 | | Java 测试 | ✅ 代码已发布；mvn 在 CI 中运行 | | 跨语言一致性向量 | ✅ 已发布 —— TS ↔ Python ↔ Go 字节完全一致通过 | | 模糊测试工具（200 次随机突变） | ✅ 已发布 | | **加密强化** | | | RFC 3161 时间戳 client（FreeTSA + 商业 TSA） | ✅ 已发布 | | Merkle 批量承诺（RFC 9162 防范第二原像攻击） | ✅ 已发布，包含证明 | | 密钥轮换、废弃、撤销、历史验证 | ✅ 已发布 | | FIPS 模式加密路径（`FipsSigningProvider`, `requireFipsMode`） | ✅ 已发布 | | **HSM / KMS** | | | AWS KMS 驱动 | ✅ 已发布 (`@askledger/receipts-sdk/hsm/aws-kms`) | | Azure Key Vault 驱动 | ✅ 已发布 | | GCP KMS 驱动 | ✅ 已发布 | | PKCS#11 驱动（Thales, Entrust, CloudHSM, YubiHSM） | ✅ 已发布 | | **多语言 SDK（传输格式兼容）** | | | TypeScript | ✅ 参考实现 | | Python | ✅ 已发布 | | Go | ✅ 已发布 | | Rust | ✅ 已发布 | | Java | ✅ 已发布 | | **规模 + 存储** | | | 带有 CAS + RLS 模式的 Postgres 链后端 | ✅ 已发布 | | 内存链存储（测试 + serverless） | ✅ 已发布 | | 多租户隔离 | ✅ 已发布 | | **自动捕获** | | | OpenAI + 8 家兼容 OpenAI 的提供商 | ✅ 已发布 | | Anthropic | ✅ 已发布 | | 通用 fetch（11 家供应商） | ✅ 已发布 | | LangChain.js | ✅ 已发布 | | **零信任** | | | ZTA 参考架构文档（对齐 NIST SP 800-207） | ✅ 已发布 | | SPIFFE 工作负载身份辅助工具 | ✅ 已发布 | | OPA 决策 client（决策即收据） | ✅ 已发布 | | **工作流** | | | 收据流水线（捕获 → 策略 → 签名 → TSA → 持久化 → 通知） | ✅ 已发布 | | 审批工作流（N-of-M，过期机制） | ✅ 已发布 | | 证据包构建器（Merkle 批量 + 完整性哈希） | ✅ 已发布 | | **企业 UI** | | | 管理控制台（Next.js 14，App Router） | ✅ 已发布 | | 设计系统（WCAG 2.2 AA，RTL，暗黑模式，设计 token） | ✅ 已发布 | | 仪表盘 / 收据浏览器 / 策略 / 密钥 / 工作流 / 证据 / 租户 / 审计 / 设置 | ✅ 全部 9 个页面已发布 | | **审计就绪产物** | | | 威胁模型（STRIDE + LINDDUN） | ✅ 已发布 | | SOC 2 信任服务标准控制映射 | ✅ 已发布 | | 零信任架构文档 | ✅ 已发布 | | 设计系统规范 | ✅ 已发布 | | **供应链** | | | CycloneDX 1.5 SBOM | ✅ 已发布 | | npm 来源发布 | ✅ 已接通 | | Sigstore Cosign 镜像签名 | ✅ 已记录在文档中 | | **第三方评估关卡（需要外部机构参与）** | | | 外部加密审计（Trail of Bits / NCC Group / Cure53） | 🔴 代码 + 威胁模型已就绪；委托费用约 8–12 万美元，耗时 4 周 | | SOC 2 Type II 报告 | 🔴 控制框架 + 证据映射已就绪；需委托会计师事务所 + 收集 12 个月的证据 | | NIST CMVP FIPS 140-3 验证 | 🔴 通过 AWS/Azure/GCP/Thales 进行提供商委托；无需 SDK 端认证 | | **未来规划** | | | 抗量子混合签名（Ed25519 + Dilithium） | 🔴 v2.0 协议修订 | | 透明日志集成（Rekor） | 🟡 Merkle 已就绪；日志连接器将在 v0.4 中推出 | 标记为 🔴 的条目需要外部机构（审计公司、会计师事务所）介入。代码和审计就绪的产物均已发布 —— 剩下的只是聘请这些机构并开展评估工作。 ## 引用本工作 如果你在研究或行业文章中引用此协议或实现： ``` AskLedger. (2026). AskLedger Receipts SDK: Cryptographic AI Decision Receipts for enterprise AI. https://github.com/askledger/receipts-sdk ``` ## 许可证 [Apache-2.0](LICENSE)。 采用此开源许可证是深思熟虑的结果：收据是通过普及采用来构建护城河，而不是通过锁定。AskLedger 的商业层（验证器模型、监管门户、证据包、供应商基准数据）是专有的。**协议底座则是开放的。** ## 维护者与治理 请参阅 [`MAINTAINERS.md`](MAINTAINERS.md) 了解当前的维护者名单和技术指导委员会的治理模式。本项目正处于多利益相关方治理的筹备阶段；我们欢迎那些希望在标准制定桌上占有一席之地的个人和组织做出贡献。 **联系方式** - 常规问题 → [GitHub Discussions](https://github.com/askledger/receipts-sdk/discussions) - Bug 报告 → [GitHub Issues](https://github.com/askledger/receipts-sdk/issues) - 安全漏洞披露 → [私密的 GitHub Security Advisory](https://github.com/askledger/receipts-sdk/security/advisories/new) （见 [`SECURITY.md`](SECURITY.md)）

标签：JS文件枚举, MITM代理, 人工智能, 区块链, 可视化界面, 审计日志, 密码学, 手动系统调用, 数据可溯源, 日志审计, 用户模式Hook绕过, 自动化攻击, 逆向工具