vtavakkoli/EdgeChainDB

# EdgeChainDB EdgeChainDB 是一个 **防篡改 IoT 数据库** 的 Python 原型。它避开了工作量证明，转而结合了以下机制： 1. **设备微链** — 每个设备对每个事件进行签名，并将其链接到其前一个事件。 2. **网关宏链** — 验证通过的事件被打包进 Merkle 块中。 3. **权威节点仲裁** — 一个区块只有在配置数量的权威节点对其进行签名后才成为最终状态。 4. **可查询的 SQLite 存储** — 遥测数据保持易于查询，同时通过加密验证来检测变更。 5. **选择性证明** — 可以证明单个事件属于某个区块，而无需披露整个区块。 6. **策略承诺** — 每个区块都会对当前生效的验证和打包策略进行承诺。 这种组合适用于工厂、智能建筑、能源系统、车队和市政 IoT。它是一个研究质量的原型，并不意味着该架构具有全新的专利性，也尚未成为一款生产级的安全产品。 ## 为什么这种设计适合 IoT 公共的工作量证明区块链通常不适合小型设备：它会增加延迟、能耗和操作复杂性。EdgeChainDB 保持了设备端轻量级的签名操作，并将打包、存储、仲裁最终性和审计转移到了网关或基础设施节点上。 设备链可以检测到： - 重放的消息； - 重复的序列号； - 乱序的消息； - 连续性缺失； - 伪造的遥测数据。 网关链可以检测到： - 删除或篡改的数据库行； - 更改的区块顺序； - 篡改的事件成员关系； - 权威节点审批不足。 ## 架构 ``` IoT device └─ signed event #1 → signed event #2 → signed event #3 device micro-chain │ ▼ validating edge gateway │ verified pending event pool │ ▼ Merkle block N-1 ← Merkle block N ← Merkle block N+1 │ 2-of-3 authority quorum │ ▼ finalized queryable ledger ``` ## 安全选择 - 用于设备和权威节点的 Ed25519 签名。 - 域分离的 SHA-256 Merkle 树。 - 用于所有签名和哈希结构的确定性 CBOR。 - 使用整数传感器单位而不是浮点数值，例如 `temperature_milli_celsius: 23650`。 - 原子 SQLite 事务和 WAL 模式。 - 每个区块内不可变的权威节点快照。 - 精确的每设备序列号和前一事件哈希验证。 ## 安装 ``` python -m venv .venv source .venv/bin/activate # Windows: .venv\Scripts\activate pip install -e ".[dev]" ``` ## 运行演示 ``` edgechain-demo --database demo.db --events 12 ``` 该演示会创建三个权威节点，要求 3 选 2 的仲裁，注册两个设备，生成已签名的事件，完成区块的最终化，验证完整的数据库，并验证 Merkle 包含证明。 ## 运行 API ``` edgechain-api --database edgechain.db --host 127.0.0.1 --port 8000 ``` 在 `/docs` 打开生成的 API 文档。 API 节点会在 `edgechain-node.key` 中创建一个持久的 Ed25519 权威密钥。其默认的开发仲裁数为一。多节点部署应该注册独立的权威公钥，并使用大于一的阈值。 ## 最小化 Python 用法 ``` from edgechaindb.crypto import KeyPair from edgechaindb.device import DeviceClient from edgechaindb.ledger import EdgeChainLedger from edgechaindb.store import Database db = Database("factory.db") ledger = EdgeChainLedger(db, quorum_threshold=1) authority = KeyPair.generate() ledger.register_authority("factory-gateway-a", authority.public_bytes) device_key = KeyPair.generate() ledger.register_device("temperature-01", device_key.public_bytes) device = DeviceClient("temperature-01", device_key) event = device.create_event( event_type="temperature", payload={"temperature_milli_celsius": 23650}, ) ledger.accept_event(event) block = ledger.propose_block("factory-gateway-a", authority.private_key) print(block["status"]) print(ledger.verify_all()) ``` ## REST 事件格式 ``` { "device_id": "temperature-01", "sequence": 1, "device_time_ms": 1784548800000, "event_type": "temperature", "payload": { "temperature_milli_celsius": 23650 }, "previous_event_hash": "0000000000000000000000000000000000000000000000000000000000000000", "signature": "hex-encoded-ed25519-signature" } ``` ## MQTT 集成 MQTT 应该被用作传输层，而不是作为事实来源。生产环境的适配器可以订阅类似以下主题： ``` edgechain/v1/events/{device_id} ``` MQTT payload 应该是事件的确定性 CBOR 表示。 网关在确认或持久化事件之前，必须验证签名和连续性。MQTT QoS 并不能替代重放保护；系统允许重复投递，并通过事件哈希和序列约束来处理这种情况。 ## 建议的研究贡献 一个合理的论文贡献可以按以下主题进行评估： **适用于间歇性连接 IoT 的连续性感知仲裁账本** 可测试的假设是：与工作量证明或基于单一事件的分布式共识相比，这种微/宏双链能以更低的设备能耗和更低的最终化延迟，检测出丢失、重放和被网关篡改的遥测数据。 测量指标： - 每个事件的签名能耗； - 每个事件的大小； - 网关摄入吞吐量； - 区块最终化延迟； - 存储开销； - 重放和删除检测率； - 在离线缓冲和重新连接下的行为表现； - 不同仲裁规模下的拜占庭容错能力。 在完成系统的文献和专利检索之前，请勿声称该系统具有科学上的新颖性。 ## 仍需完成的生产化工作 - 双向 TLS 和经过身份验证的管理员注册。 - 硬件支持的设备密钥或安全元件。 - 作为账本管理事件进行的密钥轮换和撤销。 - 具有经过身份验证的对等传输的真实网络仲裁协议。 - 针对过期提议区块的崩溃恢复。 - 限流、配额、可观测性和备份程序。 - 隐私保留策略和敏感 payload 的加密。 - 外部检查点锚定。 - 独立的安全审查和模糊测试。 ## Docker Compose：20 个独立的 IoT 节点 0.3 版本提供了一个完整的分布式测试平台： - 一个带有持久化 SQLite WAL 存储的网关容器； - 20 个持续运行、独立控制的设备容器； - 一个私有的 `edgechain-iot-net` 桥接网络； - 为每个设备提供持久化的密钥和链检查点； - 一个实时的网关仪表板，用于显示状态、事件和节点控制； - 自动化的攻击、恢复、规模扩展、Merkle 证明和审计场景； - 在 `result/` 目录下生成安全的 JSON 和 HTML 报告。 确切的 `run` 和 `test` 命令已在下文记录。辅助脚本 `./scripts/run_docker_tests.sh` 和 `./scripts/run_docker_tests.ps1` 会执行相同的工作流基准测试，并等待其完成。 ### 运行等效的本地集成套件 这对于没有 Docker 的机器非常有用。它会启动真实的 FastAPI 网关，创建 20 个并发的设备客户端，执行相同的协议和攻击场景，执行进程重启，并生成 HTML 报告。 ``` edgechain-system-test --mode local --expected-devices 20 \ --events-per-device 8 --result-dir result ``` ### 涵盖的场景 生成的报告包括结构化的 Compose 验证、20 节点并发摄入、身份冲突预防、伪造签名、签名 payload 篡改、防重放重试、乱序消息、断链、检查点恢复、自动和手动区块封装、仲裁最终性、有效和篡改的 Merkle 证明、完整的账本审计以及持久化重启恢复。 ## Docker 工作流和实时集群仪表板 Compose 拓扑现在公开了两个明确的工作流。 ### 1. 启动完整的运行集群 ``` docker compose up -d run ``` 等效的旧版拼写命令是： ``` docker-compose up -d run ``` 这会启动： - 持久化的网关； - 20 个持续运行的 IoT 设备容器； - 保持拓扑活跃状态的 `run` 协调器。 在以下地址打开实时的网关仪表板： ``` http://localhost:8000/dashboard ``` 仪表板显示容器状态、账本状态、近期事件、序列检查点、健康状态和退出代码。它可以启动、停止、重启、暂停或恢复单个或所有设备。API 文档依然可以通过 `http://localhost:8000/docs` 访问。 ### 2. 运行完整的 Docker 基准测试 ``` docker compose up -d test ``` `test` 服务会等待直到所有 20 个设备都生成了遥测数据，停止它们以创建一个稳定的基准测试窗口，运行单元/集成/安全/规模场景，重启网关，验证持久化恢复，生成报告，然后恢复设备运行。 通过以下命令查看进度： ``` docker compose logs -f test ``` 生成的文件： ``` result/report.html result/result.json result/pytest.txt result/docker-compose.log result/benchmark-status.json ``` 最新完成的报告也会从仪表板中链接，并通过 `http://localhost:8000/benchmark/report` 提供访问。 ### 为什么之前的 PowerShell 脚本会失败 在旧的测试工作流中，设备容器都是一次性的。一个成功的容器可能会在该命令运行之前就已完成执行： ``` docker compose ps -q device-02 ``` 默认情况下，`docker compose ps -q` 仅返回正在运行的容器。因此，`device-02` 存在并且已成功退出，但脚本将空查询结果解释为“未找到容器”。修正后的脚本使用 `--all` 参数查询一次性的 `test` 容器，并且基准测试不再执行脆弱的针对单个设备的容器查询。 ### 开发安全提示 本地仪表板通过挂载的 Docker socket 控制容器。因此，对外发布的端口被限制为 `127.0.0.1`。请仅将其视为本地的研发控制平面。不要将其暴露给网络或 Internet，并在投入生产环境之前，将 Docker socket 访问权限替换为经过身份验证的编排器。

标签：Python, 区块链, 完整性保护, 密码学, 手动系统调用, 数据库, 无后门, 版权保护, 物联网, 网络测绘, 逆向工具