GADIC-PROV-MVP-001｜全球可信创作与数据溯源原型·技术落地规范 v0 2 0 1977125a9c9f83a796bf01cc8f598577

龍芯北辰UID9622 龍芯北辰UID9622 博客等级 墨衍会员 · 1平台 · 200+阅读 墨衍智能分发 本文由作者通过墨衍一键同步至各平台 1分发平台 200+累计阅读 286平均单平台 已同步平台 优快云 微信公众号 微博 知乎 掘金 百家号 博客园 抖音 小红书 你的文章也可以这样分发 墨衍会员 ¥399起/年，写一次发全网 我也要 码龄162天
关注
原创 2026-11-14 06:15:48 286 阅读 AI 写同款· GEO 优化 ›
YOLOv8 结构化剪枝：Torch-Pruning + C2f_v2 + Ultralytics 微调全流程 本篇博客基于与，记录了一次完整的流程。由于（好像是8.1），所以记录了踩的各种坑，自己搭建了一个YOLO系列通用的剪枝模型，用于学习记录。 阅读详情

GADIC-PROV-MVP-001｜全球可信创作与数据溯源原型·技术落地规范 v0.2.0

所有者: 💎 龍芯北辰｜UID9622
标签: 设计

GADIC-PROV-MVP-001｜全球可信创作与数据溯源原型

GADIC-PROV-MVP-001 · Global Trusted Creation & Data Provenance Prototype — Technical Implementation Specification · v0.2.0

文档信息

字段内容
文档编号GADIC-PROV-MVP-001
版本v0.2.0 · DRAFT（公开知识库稿，待作者审定签发）
文档性质全球通用技术规范与 MVP 工程实施说明
适用范围数字创作登记 · 内容完整性 · 数字签名 · 可信时间戳 · 追加式透明日志 · 独立验证
架构锚点#GADIC-PROV-MVP-001-2026-11-14-v0.2.0
拟定作者ZHUGEXIN⚡️｜UID9622
拟定权利主体瑞安市熵梦科技有限公司
拟签发日期2026-11-14
公钥指纹A2D0092CEE2E5BA87035600924C3704A8CC26D5F
密钥核验未核验（密钥类型 / 用途 / 控制权 / 身份绑定，详见 §16）
原文链接GADIC-PROV-MVP-001｜全球可信创作与数据溯源原型·技术落地规范 v0.2.0

状态声明： 本页是技术规范与实施蓝图，不是运行报告。文档更新不代表原型已经编码、运行、测试、签名、取得 TSA 时间戳或完成第三方见证。未附真实运行证据的能力必须标记为 NOT_RUN、NOT_CONFIGURED 或 UNKNOWN，不得标记为 PASS。

状态标记约定

标记含义
PASS有真实运行证据，且验证通过
PARTIAL部分证据缺失，或可选能力未配置
NOT_RUN已设计，尚未执行
NOT_CONFIGURED依赖未配置（如 TSA、外部见证者）
UNKNOWN无法判定
FAIL验证失败

0. 版本说明与核心裁定

0.1 本次升级内容

v0.2.0 在 v0.1.0 基础上补全：

  1. 五模块的输入、输出、依赖和失败语义。
  2. 系统架构图、执行流程图、证据关系图、信任边界图。
  3. 可交换的 JSON 数据结构与 CLI/API 草案。
  4. Ed25519 签名范围、JSON 规范化、RFC 3161 时间戳对象及 Merkle Tree 规则。
  5. 独立验证器的信任材料、逐项验证、失败降级和退出码。
  6. 版本继承、作者声明、共同创作、衍生作品、授权和争议记录。
  7. 密钥轮换、撤销、隐私、备份、故障恢复和跨组织验证。
  8. 测试矩阵、验收门槛、实现路线与交付清单。
  9. 作者签章格式与版权声明区。

0.2 核心裁定

本原型证明的是证据包的完整性、签名有效性、时间戳有效性和日志包含关系，不是自动证明法律作者身份、创意唯一性、版权资格或侵权事实。

必须分别回答：

  • 内容完整性： 当前文件是否与登记时的字节摘要一致？
  • 签名有效性： 指定公钥是否验证通过了对应声明？
  • 时间证据： 可信 TSA 是否对指定摘要签发了有效时间戳令牌？
  • 日志证据： 该事件是否包含在指定 Merkle Tree 中？树的历史是否有一致性证明？
  • 身份与权利： 公钥与现实主体的绑定依据是什么？权利声明是否存在争议？
  • 法律判断： 由适用法律、合同、事实材料和有权机构判断，不由哈希或 AI 自动裁定。

0.3 绝对禁止的误报

  • 本机系统时间不得标成 RFC 3161 可信时间。
  • 本地追加文件不得标成独立第三方透明日志。
  • 自签名不得自动标成实名认证。
  • 文件哈希相同不得自动标成作者相同。
  • 内容相似不得自动判定抄袭。
  • 日志当前可读不得自动证明历史从未被重写。
  • 缺少 TSA、签名、日志证明时不得输出全链路 VERIFIED。
  • 示例密钥、示例摘要、占位签名、模拟 TSA 响应不得进入真实证据包。

1. 目标、非目标与适用边界

1.1 第一阶段目标

将单个数字作品及其来源声明封装为可携带、可独立复核的证据包，至少包含：

  • 原始文件 SHA-256 摘要；
  • 规范化登记清单；
  • Ed25519 数字签名；
  • RFC 3161 时间戳令牌（真实 TSA 配置后）；
  • 追加式透明日志事件；
  • Merkle 根摘要、包含证明及一致性证明；
  • 独立验证报告；
  • 必要的公钥、信任锚和验证策略引用。

1.2 第一阶段非目标

  • 不接入模型训练、微调、RAG 或自动代理。
  • 不建立区块链或发行代币。
  • 不宣称自动确权、自动判抄袭或自动裁定作者。
  • 不保存或上传创作私钥。
  • 不默认上传原始作品正文。
  • 不以单一平台、单一数据库或单一企业作为全球唯一信任根。
  • 不在未配置外部见证者时宣称多方见证。
  • 不把本地 MVP 的测试结果夸大为全球部署结果。

1.3 术语

术语定义
Asset被登记的数字文件或数字作品
Claim提交者对作品、贡献、来源或权利作出的声明
Manifest机器可解析的登记清单
Signature Envelope对规范化声明进行签名后形成的签名封装
TSATime Stamping Authority，可信时间戳服务机构
TSTRFC 3161 TimeStampToken
Transparency Log记录事件并提供 Merkle 证明的追加式日志
Witness独立保存或核验日志检查点的见证方
Evidence Bundle可携带的完整证据包
Trust Policy验证者采用的公钥、证书、TSA、日志和撤销策略

2. 总体架构

2.1 五模块逻辑架构

原始作品 Asset

M1 创作登记 Registration

SHA-256 内容摘要

规范化 Manifest

M2 Ed25519 数字签名

签名封装 Signature Envelope

M3 RFC 3161 时间戳

时间戳令牌 TST

M4 追加式透明日志

Merkle Root / Inclusion Proof

Evidence Bundle

M5 独立验证器

独立信任材料 Trust Store

原始文件副本或受控访问路径

逐项验证报告

PASS / PARTIAL / FAIL / UNKNOWN

2.2 五模块责任边界

模块输入输出不负责的事项
M1 Registration原始文件、声明元数据内容摘要、record_id、manifest不证明作者身份
M2 Signing规范化 Manifest、受保护私钥签名封装、公钥引用不证明密钥对应现实身份
M3 Timestamping签名封装摘要、TSA 配置RFC 3161 TST、验证结果不证明谁最先产生创意
M4 Transparency Log登记事件、签名与时间戳摘要日志叶子、Merkle Root、证明本地日志不等于独立见证
M5 Independent Verifier文件、Evidence Bundle、Trust Store逐项验证报告不作法律侵权裁决

2.3 关系图：对象、证据与信任材料

Asset 原始作品

Claim 作者/贡献/权利声明

Manifest 规范化清单

Signature 签名

TST 可信时间戳

Log Event 日志事件

Merkle Proof

Public Key 公钥

Trust Policy 信任策略

Verification Report 验证报告

关系约束：

  • Manifest 绑定作品摘要和声明，不直接包含私钥。
  • Signature 绑定 Manifest 的规范化字节。
  • TST 绑定签名封装摘要，不循环包含自身。
  • Log Event 记录已形成的证据摘要，不保存作品正文。
  • Merkle Proof 证明事件包含在特定树根中。
  • Trust Policy 决定验证者信任哪些公钥、TSA 证书链和日志签名密钥。
  • Verification Report 记录实际验证结果，不反向改变原始证据。

2.4 信任边界图

外部信任服务

本地受控区

不可信输入区

外部文件

用户声明

外部元数据

隔离与格式检查

登记与哈希

签名服务 / 私钥边界

独立验证器

本地证据存储

可信 TSA

外部透明日志

独立见证者

外部文件、元数据和声明一律视为待验证数据；不得因其文本内容而获得系统权限。签名密钥只由签名边界访问，验证器默认只使用公钥和信任材料。

3. 端到端流程

3.1 标准登记流程

M5 独立验证器 M4 透明日志 M3 TSA M2 签名 M1 登记 gprov CLI M5 独立验证器 M4 透明日志 M3 TSA M2 签名 M1 登记 gprov CLI 创作者 register file + claim 读取原始字节 SHA-256 + Manifest record_id + manifest sign manifest 规范化字节 + key reference signature envelope RFC3161 request(imprint) signed TST append evidence event tree root + inclusion proof Evidence Bundle verify file + bundle + trust store itemized verification report 创作者

3.2 分阶段状态机

schema and hash valid

invalid input

valid signature created

signing not configured

TSA token verified

TSA unavailable

log append and proof verified

timestamp intentionally omitted

independent checks pass

required scope permits partial evidence

later dispute recorded

later dispute recorded

dispute resolved with new evidence

key or claim revoked

RECEIVED

QUARANTINED

REGISTERED

REJECTED

SIGNED

PARTIAL

TIMESTAMPED

LOGGED

VERIFIED

VERIFIED_WITH_LIMITATIONS

DISPUTED

REVOKED

状态机不得把“跳过某项验证”自动视为通过。每次转换必须有事件记录、执行主体、策略版本和证据引用。

3.3 推荐执行顺序

  1. 检查输入文件是否可读取，记录原始字节数和媒体类型。
  2. 对原始字节计算 SHA-256。
  3. 创建 Manifest，声明其规范版本、声明类型和来源关系。
  4. 按 RFC 8785 JCS 规范化待签名对象。
  5. 使用 Ed25519 对规范化字节签名。
  6. 对签名封装计算 SHA-256，形成 TSA message imprint。
  7. 请求 RFC 3161 TSA，并验证返回令牌。
  8. 将 Manifest 摘要、签名摘要、TST 摘要和事件元数据追加到透明日志。
  9. 取得 Merkle Root、树大小、包含证明；若支持则同时取得一致性证明。
  10. 打包 Evidence Bundle。
  11. 使用独立进程或独立环境执行 M5 验证。
  12. 保存原始命令、退出码、验证器版本和报告摘要。

3.4 TSA 绑定对象的固定规则

为避免循环签名和歧义，MVP 固定以下顺序：

  • manifest_core：不包含签名、时间戳和日志字段。
  • manifest_canonical_bytes：对 manifest_core 按 RFC 8785 规范化后的字节。
  • signature_envelope：包含 Manifest 摘要、签名算法、key_id、签名值和规范版本。
  • timestamp_imprint：SHA-256(JCS(signature_envelope))。
  • timestamp_token：TSA 对 timestamp_imprint 签发的 RFC 3161 令牌。
  • log_event：引用 Manifest、Signature Envelope 和 Timestamp Token 的摘要。

TSA 令牌不得包含在被它自身时间戳的签名封装内；否则会形成循环依赖。

4. 模块实施规范

M1｜创作登记 Registration

输入： 单个文件、声明类型、提交者引用、可选父版本和贡献者列表。
输出： record_id、asset_hash、manifest.json、登记事件。

要求：

  • 对原始文件字节计算 SHA-256，不对未经声明的文本转换结果计算。
  • 生成不可预测的 UUID/ULID 作为 record_id；ID 不作为安全凭证。
  • 明确记录字节数、媒体类型、文件名（可选）、登记器版本和 Schema 版本。
  • 不把文件系统 mtime 当作可信创作时间。
  • 用户声明时间只能记作 claimed_created_at，并标注 SELF_ASSERTED。
  • 重复哈希只能提示字节相同，不得自动判定作者相同或谁先创作。
  • 原始文件默认留在创作者本地或其选择的受控存储中。

M2｜数字签名 Signing

算法： Ed25519（RFC 8032）。
规范化： JSON Canonicalization Scheme（RFC 8785）。
签名对象： manifest_core 的规范化字节。

要求：

  • 固定签名覆盖字段，不得在实现间自行增减。
  • 拒绝重复 JSON 键、非规范数据和不支持的 Schema 版本。
  • 公钥必须随证据包或通过可信公钥目录可获取。
  • 私钥不得写入 Manifest、日志、Notion、代码仓库、普通配置文件或验证报告。
  • 私钥推荐由 OS Keychain、硬件安全密钥、受控密钥代理或安全密码库管理。
  • 记录 key_id、算法、密钥用途、创建/轮换/撤销事件。
  • 密钥轮换时建立新旧 key 关系，并由旧密钥签署轮换声明（旧密钥可用时）；否则进入人工身份复核流程。
  • 自签名只能证明某个私钥签署了某份数据，不自动证明现实身份。

M3｜可信时间戳 Timestamping

协议： RFC 3161，必要时同时遵循其更新文件 RFC 5816。
请求对象： SHA-256(JCS(signature_envelope))。

验证器必须核验：

  • token 的 messageImprint 与本地重新计算值一致；
  • TSA 签名有效；
  • TSA 证书链通向配置的信任锚；
  • TSA 证书用途、有效期及策略 OID 符合配置；
  • token 的 nonce（如请求使用）与响应一致；
  • genTime、精度和策略信息可解析；
  • 撤销状态与验证策略符合要求。

状态规则：

  • 未配置 TSA：NOT_CONFIGURED。
  • 请求尚未完成：PENDING。
  • 网络超时或 TSA 拒绝：FAIL 或明确的可重试错误。
  • token 验签成功：PASS。
  • token 存在但缺少信任锚：UNKNOWN，不得标为可信时间戳通过。

MVP 不硬编码某家 TSA 地址。由维护者通过环境配置或受保护配置文件提供 TSA URL、信任锚和策略。测试可使用本地测试 TSA，但报告必须标明 TEST_TSA，不能冒充公共可信 TSA。

M4｜追加式透明日志 Transparency Log

MVP 采用 RFC 6962 风格的 Merkle Tree 哈希构造作为技术参考，不宣称实现了完整 Certificate Transparency 服务或符合其全部协议要求。

固定哈希构造：

  • Leaf Hash：SHA-256(0x00 || leaf_data)
  • Node Hash：SHA-256(0x01 || left_hash || right_hash)

要求：

  • 明确 leaf_data 的字节编码与版本。
  • 每个事件有 event_id、tree_size、event_type、record_id、manifest_digest、signature_digest、timestamp_digest（可空）、event_time_observed 和 schema_version。
  • 每次追加生成新的 tree_size 和 root_hash。
  • 提供 inclusion proof。
  • 提供 consistency proof，证明较大树是较小树的追加扩展，而非另起一棵冲突树。
  • 根摘要必须由日志签名密钥签署。
  • 验证者需通过可信渠道获得日志公钥或固定检查点。
  • 发现同一 tree_size 对应不同 root_hash 时，标记 LOG_FORK_DETECTED。
  • 本地日志只具备本地篡改检测能力；只有外部独立见证者保存并比对签名检查点，才可报告多方见证。

M5｜独立验证 Independent Verification

输入：

  • 原始文件或其受控读取路径；
  • Evidence Bundle；
  • signer public key；
  • TSA trust anchors；
  • transparency log public key；
  • trust policy；
  • 可选撤销列表和见证者检查点。

验证器必须：

  • 不导入登记器内部数据库状态；
  • 不依赖登记器进程内存；
  • 不相信证据包内自带的公钥就是可信公钥；
  • 对所有摘要重新计算；
  • 对所有签名独立验签；
  • 对 TSA token 独立验证；
  • 对 Merkle inclusion proof 和 consistency proof 独立验证；
  • 输出逐项状态、失败原因、验证器版本、策略版本和输入证据摘要；
  • 支持离线验证；若必须联网查询撤销状态，应在报告中标记网络依赖与查询时间。

5. 标准化数据结构

5.1 Manifest 示例

以下是字段结构示例，所有示例值均为占位符，不得作为真实登记证据。

{
  "schema_version": "gadic.asset-manifest/1.0",
  "record_id": "urn:uuid:00000000-0000-4000-8000-000000000000",
  "asset": {
    "representation": "original-bytes",
    "media_type": "text/plain",
    "size_bytes": 0,
    "hash": {
      "algorithm": "sha-256",
      "value": "REPLACE_WITH_REAL_DIGEST"
    }
  },
  "claim": {
    "claim_type": "creation_record",
    "claimant_ref": "REPLACE_WITH_SUBJECT_REFERENCE",
    "claim_status": "SELF_ASSERTED",
    "claimed_created_at": null,
    "rights_holder_claim": null,
    "license_ref": null
  },
  "contributors": [],
  "relationships": {
    "parent_assets": [],
    "source_assets": [],
    "derived_from": [],
    "replaces_record": null
  },
  "canonicalization": {
    "algorithm": "RFC8785-JCS",
    "version": "1"
  },
  "created_by": {
    "software": "gadic-prov-mvp",
    "version": "0.2.0"
  }
}

5.2 Signature Envelope 示例

{
  "schema_version": "gadic.signature-envelope/1.0",
  "record_id": "urn:uuid:00000000-0000-4000-8000-000000000000",
  "manifest_digest": {
    "algorithm": "sha-256",
    "value": "REPLACE_WITH_REAL_DIGEST"
  },
  "signature": {
    "algorithm": "Ed25519",
    "key_id": "REPLACE_WITH_KEY_ID",
    "value_base64url": "REPLACE_WITH_REAL_SIGNATURE"
  },
  "signed_at_claimed": null,
  "canonicalization": "RFC8785-JCS"
}

5.3 Timestamp Evidence 示例

{
  "protocol": "RFC3161",
  "imprint_algorithm": "sha-256",
  "imprint_value": "REPLACE_WITH_REAL_IMPRINT",
  "token_file": "timestamp/token.tsr",
  "tsa_policy_oid": "REPLACE_WITH_TSA_POLICY",
  "gen_time": null,
  "verification_status": "NOT_RUN",
  "trust_anchor_ref": "REPLACE_WITH_CONFIGURED_TRUST_ANCHOR"
}

5.4 Transparency Event 示例

{
  "schema_version": "gadic.log-event/1.0",
  "event_id": "urn:uuid:00000000-0000-4000-8000-000000000000",
  "event_type": "ASSET_REGISTERED",
  "record_id": "urn:uuid:00000000-0000-4000-8000-000000000000",
  "manifest_digest": "sha256:REPLACE_WITH_REAL_DIGEST",
  "signature_digest": "sha256:REPLACE_WITH_REAL_DIGEST",
  "timestamp_token_digest": null,
  "tree_size": 1,
  "previous_checkpoint": null
}

5.5 Verification Report 示例

{
  "schema_version": "gadic.verification-report/1.0",
  "record_id": "urn:uuid:00000000-0000-4000-8000-000000000000",
  "verifier": {
    "name": "gprov-verify",
    "version": "0.2.0"
  },
  "checks": {
    "content_hash": "NOT_RUN",
    "manifest_schema": "NOT_RUN",
    "manifest_signature": "NOT_RUN",
    "timestamp_token": "NOT_CONFIGURED",
    "log_inclusion": "NOT_RUN",
    "log_consistency": "NOT_RUN",
    "revocation": "UNKNOWN"
  },
  "overall_status": "PARTIAL",
  "limitations": [
    "Example only; no real evidence was verified"
  ]
}

5.6 字段规则

  • JSON 字段名使用稳定英文标识。
  • 时间使用 RFC 3339 格式，必须携带 UTC 标记或明确时区偏移。
  • 哈希算法必须显式记录，不能只保存裸摘要字符串。
  • 大整数、二进制和字节长度必须定义序列化方式。
  • Schema 版本必须可识别；未知字段应按兼容策略处理，不得静默丢弃安全关键字段。
  • 对签名对象使用 RFC 8785 JCS；禁止依赖不同语言默认 JSON 序列化结果。
  • 原始字节摘要与文本规范化摘要是不同对象，必须分别命名和记录。
  • 任何可选字段被省略时，必须定义其语义；不得混淆 null、空字符串和字段缺失。

6. 证据包与目录规范

6.1 建议目录

gadic-prov-mvp/
├── README.md
├── LICENSE
├── pyproject.toml
├── schemas/
│   ├── asset-manifest.schema.json
│   ├── signature-envelope.schema.json
│   ├── log-event.schema.json
│   └── verification-report.schema.json
├── src/
│   └── gprov/
│       ├── registration/
│       ├── signing/
│       ├── timestamping/
│       ├── transparency/
│       ├── verification/
│       ├── canonicalization/
│       └── cli/
├── tests/
│   ├── unit/
│   ├── integration/
│   ├── security/
│   └── fixtures/
├── docs/
│   ├── architecture.md
│   ├── threat-model.md
│   ├── key-management.md
│   ├── timestamp-policy.md
│   └── interoperability.md
├── examples/
│   └── synthetic-evidence/
└── reports/
    ├── test-report.template.md
    └── verification-report.template.json

真实作品和私钥不得放进公开源码仓库。测试夹具只能使用合成数据或获得明确许可的样本。

6.2 Evidence Bundle

evidence-bundle/
├── manifest.json
├── signature-envelope.json
├── signer-public-key.pem
├── timestamp/
│   ├── request.tsq
│   ├── token.tsr
│   └── tsa-chain.pem
├── transparency/
│   ├── event.json
│   ├── checkpoint.json
│   ├── inclusion-proof.json
│   ├── consistency-proof.json
│   └── log-public-key.pem
├── trust/
│   ├── trust-policy.json
│   └── revocation-snapshot.json
└── reports/
    └── verification-report.json

原始作品可作为独立文件交给验证器，不强制复制进证据包。证据包中的公钥、证书和策略仍需通过可信渠道确认，不能因为它们与证据放在同一个 ZIP 中就自动信任。

7. 通用 CLI 与 API 契约

7.1 CLI 命令草案

# 1. 登记文件：生成 manifest 和内容摘要
gprov register ./作品文件.pdf --out ./evidence/record-001

# 2. 查看待签名清单摘要
gprov inspect ./evidence/record-001/manifest.json

# 3. 使用本地密钥引用签名；不得把私钥内容作为命令行参数
gprov sign ./evidence/record-001/manifest.json --key-ref local:keychain/gadic-author

# 4. 对签名封装请求真实 TSA 时间戳
gprov timestamp ./evidence/record-001 --tsa-config ./config/tsa.json

# 5. 追加透明日志并生成 Merkle 证明
gprov log append ./evidence/record-001

# 6. 使用独立验证器重新验证
gprov verify ./作品文件.pdf ./evidence/record-001   --trust-policy ./config/trust-policy.json

# 7. 输出机器可读状态
gprov verify ./作品文件.pdf ./evidence/record-001 --format json

以上命令是接口契约草案，不代表当前已有可执行程序。实际参数必须以代码实现、CLI help 和集成测试为准。

7.2 API 路由建议

MethodEndpoint功能
POST/v1/records创建登记记录
GET/v1/records/{record_id}读取登记清单
POST/v1/records/{record_id}/sign生成签名封装
POST/v1/records/{record_id}/timestamp请求 RFC 3161 时间戳
POST/v1/log/events追加透明日志事件
GET/v1/log/checkpoints/latest获取最新签名检查点
GET/v1/log/proofs/{event_id}获取包含证明
POST/v1/verify独立验证证据包
POST/v1/keys/revocations登记密钥撤销事件

API 必须具备身份认证、速率限制、输入 Schema 校验、请求幂等性、审计事件和明确错误码。MVP 本地 CLI 可先实现核心能力，HTTP API 不应成为第一阶段的强制依赖。

7.3 通用错误码

错误码含义建议处理
E_INPUT_INVALID输入文件或字段无效拒绝登记
E_SCHEMA_UNSUPPORTEDSchema 版本不支持隔离并提示升级
E_HASH_MISMATCH文件摘要不一致验证失败
E_SIGNATURE_INVALID数字签名无效验证失败
E_KEY_UNTRUSTED公钥未被信任策略认可UNKNOWN / 需核验
E_TSA_NOT_CONFIGURED未配置 TSAPARTIAL
E_TSA_UNAVAILABLETSA 不可用PENDING 或 FAIL
E_TSA_TOKEN_INVALIDTSA token 验证失败FAIL
E_LOG_PROOF_INVALIDMerkle 证明无效FAIL
E_LOG_FORK同一树大小出现冲突根安全事件
E_KEY_REVOKED密钥已撤销按撤销策略判断
E_EVIDENCE_INCOMPLETE证据包不完整PARTIAL
E_POLICY_UNAVAILABLE信任策略不可用UNKNOWN

8. 独立验证规则

8.1 验证顺序

  1. 解析证据包，拒绝路径穿越、恶意压缩包和超限文件。
  2. 验证 Manifest Schema。
  3. 重新读取原始文件并计算 SHA-256。
  4. 按声明的规范版本重建 JCS 字节。
  5. 从可信来源解析 signer public key。
  6. 验证 Ed25519 签名。
  7. 对签名封装重新计算 timestamp imprint。
  8. 验证 RFC 3161 token、TSA 证书链和信任策略。
  9. 重新计算 Log Event leaf hash。
  10. 验证 Merkle inclusion proof。
  11. 验证日志检查点签名及 consistency proof。
  12. 查询或验证密钥撤销事件。
  13. 输出逐项报告和整体摘要。

8.2 整体状态规则

条件整体状态
所有必需项均通过，且信任材料有效VERIFIED
部分可选能力未配置，必需项通过VERIFIED_WITH_LIMITATIONS
缺少必要证据或信任材料PARTIAL / UNKNOWN
任一必需密码学验证失败FAIL
发现日志分叉或签名伪造FAIL + SECURITY_EVENT
权利归属存在争议DISPUTED（不等于密码学验证失败）

密码学验证状态和权利争议状态是两个维度。例如，一份签名完全有效的作品仍可能存在作者归属争议；一份作品没有 TSA 也不等于作品是伪造的。

8.3 退出码建议

Exit Code含义
0所有配置为必需的验证项通过
1验证失败
2证据不完整或结果未知
3配置错误或依赖不可用
4检测到日志分叉或高风险安全事件

CLI 输出必须同时提供人类可读文本与机器可解析 JSON。

9. 作者、贡献、版本与权利关系

9.1 不采用单一作者字段解决所有权利问题

作品可以有：

  • 单一作者；
  • 多名共同创作者；
  • 编辑者；
  • 翻译者；
  • 受委托制作方；
  • 权利受让方；
  • 许可使用方；
  • 来源素材提供者；
  • AI 工具参与记录。

Manifest 应区分 creator、contributor、claimant、rights_holder_claim、license_ref 和 source_asset。这些角色不应默认相等。

9.2 版本关系图

revision_of

revision_of

source_asset_of

contributor_to

licensed_to

作品 A / Version 1

作品 A / Version 2

作品 A / Published Version

第三方素材 B

衍生作品 C

共同创作者声明

被许可使用记录

每个新版本产生新的内容摘要和登记事件。旧版本不得被覆盖。衍生关系、素材来源和许可条件必须由提交者声明并保留证据引用。

9.3 归属争议处理

争议记录采用追加事件：

  • CLAIM_SUBMITTED
  • COAUTHOR_ADDED
  • SOURCE_ASSET_DECLARED
  • LICENSE_GRANTED
  • CLAIM_DISPUTED
  • EVIDENCE_ADDED
  • CLAIM_CORRECTED
  • KEY_ROTATED
  • KEY_REVOKED
  • DISPUTE_RESOLVED

不得删除原声明来掩盖争议。纠错应追加新声明并关联被纠正事件。验证器显示当前状态时，必须能追溯历史状态和证据。

10. 密钥管理、撤销与恢复

10.1 密钥生命周期

secure backup and registration

scheduled rotation

new key verified

suspected leak

revocation event signed or independently attested

owner revokes

GENERATED

ACTIVE

ROTATION_PENDING

ACTIVE_NEW

COMPROMISED

REVOKED

10.2 要求

  • 私钥优先使用 OS Keychain、硬件安全模块或受控密钥代理。
  • 私钥备份必须加密并由所有者控制。
  • 不允许把私钥写入环境变量、命令历史、日志、Notion 或代码仓库。
  • 公钥指纹必须说明算法、编码方式和计算对象。
  • 发生泄露时立即停止使用旧密钥，登记撤销事件并生成新密钥。
  • 历史签名是否仍可接受，应结合可信时间戳、密钥有效期、泄露时间证据和验证策略判断。
  • 无法确定泄露时间时，不得擅自声称泄露前签名必然安全。
  • 证据包应携带或引用密钥状态快照，验证器应报告快照时间和新鲜度。

11. 隐私、跨境与多方见证

11.1 数据最小化

透明日志默认只记录摘要、最小事件元数据和证明引用，不记录作品全文、私钥、身份证件或不必要的个人信息。

11.2 跨机构互操作

不同机构可分别运营：

  • TSA 服务；
  • 透明日志；
  • 见证节点；
  • 公钥目录；
  • 证据镜像；
  • 独立验证器。

参与者通过开放 Schema、签名算法标识、时间戳协议和 Merkle 证明互相验证，而不是依赖单一厂商账户。

11.3 多方见证

真正的多方见证至少要求：

  1. 独立运营主体；
  2. 不同管理权限；
  3. 独立保存签名检查点；
  4. 定期交换并验证 tree head；
  5. 能发现同一 tree_size 的冲突 root；
  6. 保存见证时间和签名证据。

同一台服务器上的两个进程、同一企业控制的两个数据库，不应被宣传为两个独立见证方。

11.4 删除与更正

不可篡改日志不意味着可以无限保留个人数据。敏感内容应留在受控存储；日志只保存法律允许保留的最小证明信息。删除原始作品时，日志应追加删除/限制访问事件，而不是声称可以从哈希恢复原文。

12. 安全威胁与缓解措施

威胁控制措施残余风险
文件被替换原始字节哈希复核无法仅凭哈希证明作者
Manifest 被修改JCS + Ed25519私钥泄露仍可伪造新签名
时间戳伪造TSA token 与证书链验证TSA 本身可能失陷或停运
日志被重写Merkle proof、签名检查点、一致性证明无外部见证时仍可能被整体重建
日志分叉多方见证与 tree-head 比对见证者串通或全部离线
公钥替换独立信任策略、指纹核验身份绑定仍需额外证明
证据包恶意文件沙箱解析、路径与大小限制解析器漏洞
元数据伪造声明与验证结果分离现实事实需外部证据
密钥遗失加密备份、轮换与恢复流程无备份时历史证明受限
隐私泄露数据最小化、访问控制摘要和元数据仍可能泄露关联信息

13. 测试矩阵与真实验收

所有测试在实际执行前均为 NOT_RUN。

ID测试场景预期结果
T-001同一文件重复计算 SHA-256摘要一致
T-002修改文件一个字节内容哈希验证失败
T-003正确公钥验证签名PASS
T-004错误公钥验证签名FAIL
T-005签名后修改 ManifestFAIL
T-006JSON 字段顺序不同但语义相同JCS 字节一致
T-007JSON 重复键拒绝或明确 FAIL
T-008未配置 TSANOT_CONFIGURED，不生成假令牌
T-009有效 RFC 3161 tokenmessageImprint、签名和链验证通过
T-010篡改 TSA tokenFAIL
T-011TSA 证书链不受信任UNKNOWN / FAIL，按策略明确区分
T-012透明日志正常追加tree_size 增长、root 可复算
T-013修改日志叶子数据inclusion proof 失败
T-014错误 Merkle pathFAIL
T-015consistency proof 有效证明旧树为新树前缀
T-016同一 tree_size 出现不同 rootLOG_FORK_DETECTED
T-017删除本地日志尾部与外部检查点比对后发现截断
T-018证据包缺少时间戳PARTIAL，不得全链路 VERIFIED
T-019独立验证器在干净环境运行不依赖登记器数据库
T-020私钥扫描证据包和仓库中无私钥材料
T-021撤销密钥后验证历史签名按撤销时间和策略输出明确结论
T-022恶意压缩包/路径穿越安全拒绝，不写出隔离目录
T-023网络断开离线可验证项继续验证，在线依赖标 UNKNOWN
T-024TSA 超时有界重试，明确失败，不伪造成功
T-025日志检查点签名错误FAIL

13.1 测试报告模板

Project: GADIC-PROV-MVP-001
Build/Commit:
Verifier Version:
OS / Runtime:
Dependency Lock Hash:
Test Date (RFC3339):
Test Command:
Total:
Passed:
Failed:
Skipped:
Not Run:
External Services:
Raw Output Path:
Evidence Bundle Hash:
Known Limitations:
Reviewer:
Review Status:

13.2 验收门槛

进入受控试用前必须：

  • M1 至 M5 均有可运行实现；
  • 签名覆盖范围与 JCS 规则冻结；
  • Ed25519 有正确/错误密钥测试；
  • RFC 3161 使用真实 TSA 时完成 token 与证书链验证；未配置时如实降级；
  • Merkle inclusion 与 consistency proof 有测试向量；
  • 日志检查点由日志密钥签名；
  • 独立验证器能在干净环境重验；
  • 密钥管理、撤销、备份与恢复流程经过演练；
  • 安全测试和隐私扫描有真实报告；
  • 每项测试保留命令、原始输出和版本信息。

14. 实施路线与交付清单

Phase 0｜规范冻结

  • 确认 Manifest Schema。
  • 固定 RFC 8785 规范化范围。
  • 固定签名覆盖字段。
  • 固定 TSA imprint 对象。
  • 固定 Merkle 叶子与节点编码。
  • 固定状态枚举和退出码。
  • 形成公开测试向量。

Phase 1｜本地最小证据链

  • M1：SHA-256 登记。
  • M2：Ed25519 签名和验签。
  • M5：独立验证 Manifest 与签名。
  • CLI 和 JSON 报告。
  • 合成样本端到端测试。

Phase 2｜真实可信时间戳

  • TSA 配置与信任锚管理。
  • RFC 3161 请求生成。
  • token、messageImprint、证书链验证。
  • 未配置、超时、错误响应测试。
  • 真实 TSA 运行证据归档。

Phase 3｜透明日志

  • 追加式事件存储。
  • Merkle Root。
  • Inclusion Proof。
  • Consistency Proof。
  • 签名检查点。
  • 日志篡改、截断和分叉测试。

Phase 4｜独立验证与发布准备

  • 干净环境验证。
  • 证据包导出与导入。
  • 公钥信任策略。
  • 撤销与密钥轮换。
  • 故障恢复。
  • 安全审查。
  • 生成可复现运行报告。

Phase 5｜跨机构见证（MVP 之后）

  • 第二个独立日志运营者。
  • 外部见证者检查点签名。
  • 多方 tree-head 比对。
  • 公共验证端点。
  • 跨平台互操作测试。

AI 数据投毒防护不纳入本次五模块 MVP。 只有本阶段的证据链完成并通过独立验证后，才进入第二阶段的数据隔离、训练数据准入、RAG 来源绑定和提示注入防护。

15. 公开标准与技术参考

以下标准应在实现时按正式文本核对版本、适用范围和更新状态：

  1. RFC 3161 — Internet X.509 Public Key Infrastructure Time-Stamp Protocol
    https://www.rfc-editor.org/rfc/rfc3161.html
  2. RFC 5816 — ESSCertIDv2 Update for RFC 3161
    https://www.rfc-editor.org/rfc/rfc5816.html
  3. RFC 8032 — Edwards-Curve Digital Signature Algorithm (EdDSA)
    https://www.rfc-editor.org/rfc/rfc8032.html
  4. RFC 8785 — JSON Canonicalization Scheme (JCS)
    https://www.rfc-editor.org/rfc/rfc8785.html
  5. RFC 6962 — Certificate Transparency（Merkle Tree 构造与证明设计参考；本项目不宣称完整 CT 合规）
    https://www.rfc-editor.org/rfc/rfc6962.html
  6. W3C PROV-O — The PROV Ontology
    https://www.w3.org/TR/prov-o/
  7. C2PA Technical Specifications — Content Credentials 与媒体来源声明互操作参考
    https://spec.c2pa.org/
  8. Sigstore Rekor — Transparency Log 参考实现
    https://docs.sigstore.dev/logging/overview/

标准引用不等于本项目已经符合相应标准。正式发布前应记录具体采用版本、兼容范围和测试依据。

16. 签章与版权声明

文档编号： GADIC-PROV-MVP-001
版本： v0.2.0（DRAFT）
架构锚点： #GADIC-PROV-MVP-001-2026-11-14-v0.2.0
拟定作者： ZHUGEXIN⚡️｜UID9622
拟定权利主体： 瑞安市熵梦科技有限公司
拟签发日期： 2026-11-14
公钥指纹： A2D0092CEE2E5BA87035600924C3704A8CC26D5F

版权声明： 本文为拟由作者及拟定权利主体发布的原创技术文档。建议采用 Creative Commons Attribution-ShareAlike 4.0 International（CC BY-SA 4.0）许可；正式生效前须由权利主体确认其有权授权，并确认文中第三方标准、引用材料和代码示例的许可边界。转载或改编时应保留作者署名、原文出处、许可链接及修改说明。

许可文本：https://creativecommons.org/licenses/by-sa/4.0/

原文链接： 以上 Notion 页面为本文件当前版本的知识库原文地址。若未来在 优快云 或其他平台发布，应在发布后将该平台的实际文章 URL 追加到本区，不得预先编造链接。

作者提供的既有参考文章：
https://blog.youkuaiyun.com/UID9622/article/details/170744240

数字签章状态

项目内容
签署主体待作者签署
签名算法拟 Ed25519（以实际密钥为准）
签署对象冻结后的 v0.2.0 Markdown 文件及其 SHA-256
文档 SHA-25652ef329aa7c146b9f5e5b73afd55b3f453ab252d61bd2439d03a4c5d9b2aa78b
摘要对象本地冻结文件（UTF-8 · 41,194 字节 · 1,058 行 · 按原始字节计算）
计算时间2026-11-14T04:43+08:00（本机系统时间 · SELF_ASSERTED）
交叉校验SHA-1 37add6719480542078fd962c35cda1ae2a9d9977 · MD5 3def5ddb973c74d9559aa15a95524c49
数字签名NOT_GENERATED
RFC 3161 时间戳NOT_ATTACHED
透明日志登记NOT_REGISTERED
独立验签NOT_VERIFIED
签发状态DRAFT_UNSIGNED

回填说明： 上述摘要对应「回填前」的本地冻结文件。本页回填后若再次导出 Markdown，字节必然变化，须另算新摘要并记为 v0.2.0-hashfix，不得沿用本值。

签章安全说明： 公钥指纹文本本身不是签名，也不能证明现实身份。正式签发时，作者必须使用本人控制的私钥，对最终冻结版本的规范化签署清单进行签名；随后由独立验证器验签，并按需取得可信时间戳和透明日志证明。任何私钥、助记词或私密凭证均不得粘贴到 Notion、聊天或公开仓库。

17. 当前实施状态与后续记录

项目当前状态说明
技术规范 v0.2.0DRAFT本次完成文档设计，不代表代码实现
M1 创作登记NOT_RUN待原型实现与测试
M2 数字签名NOT_RUN待密钥边界和签名实现
M3 RFC 3161NOT_CONFIGURED尚未提供真实 TSA 配置与信任锚
M4 透明日志NOT_RUN待 Merkle Tree 与证明实现
M5 独立验证NOT_RUN待独立验证器实现
外部多方见证NOT_CONFIGURED尚无独立见证者
作者数字签章NOT_GENERATED待作者实际签署
AI 数据投毒防护OUT_OF_SCOPE第二阶段单独设计

结论： 本项目的最小可交付物不是一个漂亮的登记网页，而是一个可携带、可复核、可独立验证的数字证据包。只有真实代码、真实密钥、真实 TSA 令牌、真实日志证明和独立验证报告全部形成后，才能将相应能力从设计状态更新为运行通过。

文档维护规则： 每次版本升级必须保留旧版本、变更摘要、差异说明、测试结果和新的文档摘要；已签发版本不得原位覆盖，修订应形成新版本并通过新证据链关联旧版本。

[divider]

18. 本地实现与哈希登记（2026-11-14 回填 · v0.2.0-impl）

性质声明： 本节是运行记录回填，不改变 §0~§17 的任何规范裁定。所有 PASS 限于「本地合成样本 · 本地测试环境」，不构成真实 TSA / 独立见证 / 法律作者身份证明（§0.2、§0.3 继续全量适用）。

18.1 本地工程落地（Phase 1）

项目状态说明
本地工程根目录已建~/LONGHUN_SYSTEM/GADIC-PROV-MVP/
M1 创作登记PASS（本地）原始字节 SHA-256 + JCS 规范化 manifest 落盘
M2 Ed25519 签名PASS（本地）RFC 8032 + RFC 8785 JCS；签名对象=manifest 规范字节
M3 RFC 3161NOT_CONFIGURED未配置真实 TSA；未配置时如实降级，零假令牌（T-008）
M4 透明日志PASS（本地篡改检测）RFC 6962 构造；inclusion+consistency 证明；日志密钥签署检查点；分叉/截断检测
M5 独立验证器PASS（干净重放）纯磁盘材料+带外信任策略；证据包自带公钥不自动可信
测试矩阵19/19 PASST-001008、012020、022、025；T-009/010/011/021/024 = NOT_RUN（依赖真实 TSA/撤销流程）
端到端运行VERIFIED_WITH_LIMITATIONSexit 0；timestamp=NOT_CONFIGURED 如实降级，未输出全链路 VERIFIED
运行环境已记录Python 3.12.15 · cryptography 50.0.0 · pytest 9.1.1 · 全离线

18.2 本地冻结文件哈希登记（权威对象）

对象值
冻结规范文件specs/GADIC-PROV-MVP-001-v0.2.0-frozen.md（UTF-8 · 41,057 字节）
文档 SHA-256ae61f37630a05bd79cf056f96fcc98509b5cce3cdfcdf95182fd146c4f858a17
交叉校验SHA-1 92daf2e0fe1e1ec9eb755d4f20a24639a2fc54dc · MD5 b96e5a8035db47a68a01262d87018843
端到端 record_idurn:uuid:4c2a7566-7839-4094-8909-a7bebd4285a3（合成样本）
合成作品 SHA-256ea836c8bb14e51f0abae1036509922748e7feb3950b640a9cf22f2bda1f74668
signature-envelope SHA-256（= TSA imprint 对象）2d2d7c44a50806f16790b26baf70f8165c07114ea197e62c834ac9301599a12d
verification-report SHA-25665b10ad6723660f0158ca5f42bdf74f2763890321307f71154cd0083643b8d4d
log events.jsonl SHA-25685eea5c15216cd43568165e1c52148bff8e2ab06f05de1176c0e90a8621a28a4
log checkpoints.jsonl SHA-25688bafb6155021256b95b832e3a56f50d3cb64667a15ea4b1b17a87e1540ec065
与 §16 数字签章状态的关系： §16 记载的 52ef32…aa78b（41,194 字节）为 Notion 回填前稿摘要。本地冻结文件与其字节不同（编辑差异），按 §16 回填说明规则：本地冻结文件为权威摘要对象；本页回填后若再导出 Markdown，须另算新摘要并记为 v0.2.0-hashfix。

18.3 距 §13.2 验收门槛的差距（如实）

  • 真实 TSA 配置与信任锚（M3 仍是 NOT_CONFIGURED）；
  • 依赖锁定（pip freeze 未归档）与官方 Merkle 测试向量归档；
  • 密钥撤销/轮换演练（T-021）；
  • 外部独立见证者（Phase 5）；
  • 演示密钥为合成密钥，不得用于真实签发。

18.4 本次运行证据链

  • 测试命令：python3 -m pytest tests/ -q（19 passed）· python3 scripts/demo_e2e.py
  • 运行报告：reports/run-report-2026-11-14.md
  • 哈希账本：reports/hashes-2026-11-14.json
  • 执行：鲁班（工程实现）→ 上帝之眼（测试矩阵）→ 包青天（状态裁定，本节 §0.3 误报禁令全项复查通过）
  • 记录时间：2026-11-14T05:15+08:00（本机系统时间 · SELF_ASSERTED，非可信时间戳）

[divider]

18.5 第二轮记录：干支纪时合并 + DNA 盖章落库（2026-11-14）

项目内容
干支纪时桥新增 gprov/time_ganzhi.py，复用真身 lh_time_engine.py（不复制不造轮）；log-event 增可选字段 ganzhi_stamp（加性变更，符合 §5.6）
实测干支戳丙午年·己亥月·壬辰日·卯时
诚实边界干支戳=本机时钟推出 → SELF_ASSERTED 文化纪时辅助字段，非可信时间，不参与密码学绑定；引擎缺席=None 不编造
测试矩阵19→22 全绿（新增：2026=丙午年基准互证 / 字段存在性 / 缺席回退）
DNA 盖章26 个代码/文档文件逐文件独立 DNA（#龍芯⚡️标记）+ SHA256SUMS.sha256 全量清单（sha256sum -c 可验）
冻结规范 hashfix盖章后字节变化 → 按 §16 规则记 v0.2.0-hashfix：c153b21900930c1af998b5297ca8e57994cdef0c480b0989f44bf6c283ffbdee（41,147 字节；旧值 ae61f376… 留档于 §18.2）
永恒审计边界证据工件（manifest/envelope/events.jsonl/pem/tsr）不加 DNA 注释——它们字节被密码学钉死；改由 Merkle 检查点签名+SHA256SUMS 锚定。本地钩子配置修正沿 lh-ingestor 先例，理由全文见仓内 docs/永恒审计边界说明.md
git 落库本地 commit c357f8b（42 文件）；对外 push 未执行（外发面协议闸：待定目标仓）
页面查重结论本页全量扫描 410 块：顶层 §0~§18 无重复标题，394 个正文块零重复
本节性质：运行记录回填，不改变 §0~§17 任何规范裁定。
收录于
开源

当前文章被收录于：

开源
2 篇文章 0 人学习
订阅专栏 查看详情
标签
#java #开发语言 #人工智能 #chrome #中文编程
#CNSH #开源
署名-相同方式共享 4.0 国际 (CC BY-SA 4.0)附加条款：保留DNA追溯码，禁止商业AI训练抓取归属：龍魂系统 · UID9622 · 诸葛鑫协议版本：v2.0 人民标准版
CC2640R2F BLE5.0 BLE吞吐量测试 BLE吞吐量测试 介绍 本章分别测试了TI CC2640R2F LuanchPad和LECONIOT CC2640R2F Evaluation Board开发板吞吐量。我们提供了两个例程供大家参考测试，分别是ble5_throughput_peripheral和ble5_throughput_central。本文最后提供了测试程序下载链接。 该工程中进行了一些修改以方便进行吞吐量 阅读详情

相关推荐

C学习 - Kasumi F8/F9算法实现

Linux上的可运行代码，废话不说，直接上C源码1. f8.c/*------------------------------------------------------------------- * F8 - Confidentiality Algorithm *------------------------------------------------------------...

jianhui_wang的专栏 2925

YOLOv8之C2f模块——与YOLOv5的C3模块对比

YOLOv8的C2f模块与YOLOv5的C3模块对比

python_plus的博客 4万+

CC2640R2F BLE5.0 CC2640R2F Evaluation Board功耗测量

CC2640R2F Evaluation Board功耗测量 简介 蓝牙低耗能标准在开发过程中就考虑到了长电池寿命， 可支持器件依靠单节纽扣电池运行数年。我们假定读者对基本的电气功能概念有所了解， 并了解如何使用示波器和外用表等实验室测试设备。 本文使用SimpleBLEPeripheral示例程序进行功耗测量并使用TI的 CC2640R2F LuanchPad开发板和我公司的CC264

leconiot的博客 3466

YOLOv8改进——使用C2f-Faster替换C2f

【代码】YOLOv8改进——使用C2f-Faster替换C2f.(使用FasterNet中的FasterBlock替换C2f中的Bottleneck)

pope888的博客 1万+

CC2640R2F BLE5.0 开发向导

入门 磨刀不误砍柴工，这个章节我们先详细讲解TI SimpleLink低功耗蓝牙无线MCU CC2640R2F的学习路线图。无论你是经验丰富还是才入门的的开发人员，TI都提供了各种资源，以简化CC2640R2F平台的开发。学会利用这些资源对学习、产品开发都至关重要。往往这部分也是我们最容易忽略的部分，迫不及待的吸收新知识，反而忽略了学习的方法。 尽管我们我们写了大量中文教程尝试带你入门，但

leconiot的博客 5444

CC2640R2F BLE5.0 CC2640R2F软件架构

软件架构 开发模型 下图展示CC2640R2F支持的两种开发模型，本文讲解都集中在图一，也就是整个ble协议栈和应用都工作在一个CC2640R2F的单SOC解决方案。 单一设备：Controller、Host、Profile、应用程序都在CC2640R2F上实现，作为真正意义的单芯片解决方案。这种模型是使用CC2640R2F时最简单和最常见的。TI的大部分示例项目都使

leconiot的博客 4702

AMSR/ADEOS-II L2A 全球带状空间重采样亮度温度 V001

AMSR Level-2A 产品 (AA_L2A) 包含 6.9 GHz、10.65 GHz、18.7 GHz、23.8 GHz、36.5 GHz、89.0 GHz、50.3 GHz 和 52.8 GHz 的亮度温度。除 50.3 GHz 和 52.8 GHz 数据外，其他数据均经过重采样以保持空间一致性，因此可提供多种分辨率，分别对应观测覆盖区大小，例如 56 千米、38 千米、24 千米、21 千米、12 千米和 5.4 千米。

此星光明博客 855

CC2640R2F BLE5.0 CC2640R2F增加一个具有通知属性的characteristic

CC2640增加一个具有通知属性的characteristic 介绍 本章使用simple_peripheral作为实验平台。创建一个自定义属性的characteristic。simple_peripheral的IAR工程可以在目录C:\ti\simplelink_cc2640r2_sdk_1_35_00_33\examples\rtos\CC2640R2_LAUNCHXL\ble5sta

leconiot的博客 1759

CC2640R2F BLE5.0 BTool的使用

BTool的使用 BTool是一个用于蓝牙设备调试的PC软件工具，它可以让用户在两个BLE设备之间形成连接。BTool利用HCI供应商特定的命令与作为网络处理器的CC2640R2F LaunchPad进行通信。而CC2640R2F上必须烧写运行主机测试示例应用程序（cc2640r2lp_host_test.hex）。 有关网络处理器配置的更多信息，你可以在蓝牙低功耗软件开发人员指南中查

leconiot的博客 9940

GBase 8a MPP Cluster V9安装部署

VMware下载：https://support.broadcom.com/group/ecx/productdownloads?VirtualBox下载：https://www.virtualbox.org/wiki/DownloadsOS 建议下载 CentOS 7.9 安装包。推荐网址：https://mirrors.aliyun.com/centos/7.9.2009/isos/x86_64/?

鱼爻 1781

YOLOv5/v7 引入 YOLOv8 的 C2f 模块

基于快速、准确和易于使用的设计理念，使其成为

Coding... 1万+

yolov5的C3，yolov8的C2f，yolov11的C3k2，yolov12的A2C2f模块的设计核心理念

用 “分支并行 + 灵活卷积核”，解决了这些痛点：

2303_80218362的博客 2294

YOLOv9改进策略 ： C2f改进 | 引入YOLOv8 C2f结构

C2f层是一种特殊的卷积层，用于将不同尺度的特征图融合在一起，以提高目标检测的准确性

①答疑群聊服务；②YOLO大模型知识问答系统；③计算机视觉论文生成智能体； 1951

YOLOv8改进——使用C2f-Faster-EMA替换C2f

【代码】YOLOv8改进——使用C2f-Faster-EMA替换C2f.(C2f-Faster-EMA推荐可以放在主干上,Neck和head部分可以选择C2f-Faster)

pope888的博客 8630

yolov5+C2F:将yolov8中高效C2F结构与v5结合，实现模型改进

并且，提供了一种设计范式， Slim-Neck ，以实现检测器更高的计算成本效益。在实验中，与原始网络相比，本文方法获得了最先进的结果（例如， SODA10M 在 Tesla T4 上以 ~100FPS 的速度获得了 70.9% mAP0.5）。类脑研究的直观理解是，神经元越多的模型获得的非线性表达能力越强。两阶段检测器在检测小物体方面表现更好，通过稀疏检测的原理可以获得更高的平均精度（mAP），但这些检测器都是以速度为代价的。真的快要卷秃噜皮了！在本人的数据集上有效涨点，但不是很多，大约1个点左右！

qianxun 6134

Transformer凭什么取代RNN？深入拆解自注意力机制与梯度消失问题的终极对决

本文深入探讨了Transformer如何通过自注意力机制解决RNN的梯度消失问题，成为自然语言处理领域的新标准。通过对比RNN和Transformer的架构差异，揭示了自注意力机制在并行计算、长期依赖处理等方面的技术优势，并提供了实际任务中的性能对比数据。

f6g7h8i9j的博客 191

【YOLOv5/v7改进系列】引入YOLOv8的C2f模块

【YOLOv5/v7改进系列】引入YOLOv8的C2f模块

2401_84870184的博客 3212

# 解决 win11 连接共享打印机，报错 0x00000709 问题

# 解决 win11 连接共享打印机，报错 0x00000709 问题

段子手168的博客 9万+

【CC2640R2F】香瓜CC2640R2F之主机端获取notify数据

本文以simple_central，介绍如何打开从机的char4的通知开关，然后接收来自char4的数据

feilusia的博客 1316

SpringCloud Alibaba - Seata 实现高可用和异地容灾

这里不仅仅要实现高可用，还需要实现异地容灾. 异地容灾就是说，如果你整了好几个节点部署起来，全部放到一个机房里面，那么如果这个机房出了故障，就意味着整个集群就完了，所以对于一个大型的集群来讲，都会把这些服务异地部署.问题2：如果我们要实现异地容灾，也就说某一个机房挂了，需要快速的切换到另一个可用的机房，但是这个配置在配置文件中写死了，如果要改配置文件，还需要重启服务器，这是我们不希望看到的，怎么办？进入 seata/bin 目录，运行 seata-server.bat 文件，默认端口为 8091。

CYK_byte的博客 977

灰质-白质组织对比（Gray-white matter tissue contrast，GWC）计算以及可视化

GWC是深层灰质与浅表白质（superficial white matter，SWM）之间T1加权信号强度的比值，已知髓鞘中的胆固醇是T1加权信号强度的主要影响因素，因此GWC大致反映了大脑皮层和浅表白质之间的髓鞘化差异。GWC代表灰白质交界处的模糊程度，较低的GWC表明灰质和白质交界处更相似和更模糊；较高的GWC表明灰白质分界更加清楚。据之前的研究报道，局灶性皮质发育不良、颞叶癫痫、帕金森病、强迫症、精神分裂症和自闭症谱系障碍中存在灰白质交界区GWC异常增高或降低。 灰质信号强度和白质信号强度采集的示意图

xxx 736

llama.cpp数据格式：BF16/F16/Q8_0量化对比

在大语言模型（Large Language Model，LLM）部署过程中，模型大小和推理速度是两个关键瓶颈。一个70B参数的模型在FP32精度下需要约280GB存储空间，这远远超出了大多数消费级硬件的承载能力。量化技术通过降低数值精度来压缩模型大小，同时保持可接受的性能损失，成为解决这一问题的关键技术。 llama.cpp作为领先的C/C++ LLM推理框架，支持多种量化格式，其中BF16（B...

gitblog_00128的博客 2087

双端之Nginx+Php结合PostgreSQL搭建Wordpress

制作的 PG4WP 分支版本，它与所有版本的 WordPress 兼容，解决了原版的一些问题。参数，确保 PostgreSQL 正在监听默认端口（通常是 5432），或者你自定义的端口。：PG4WP 插件存在缺陷和不完整的功能，可能与最新版本的 WordPress 不兼容。的插件，它允许 WordPress 使用 PostgreSQL 数据库。，如果看到 Nginx 的默认欢迎页面，说明 Nginx 已正确安装。，如果看到 Nginx 的默认欢迎页面，说明 Nginx 已正确安装。

宇宙第一小趴菜的博客 1894
上一篇： 智能是使用者的镜像：当 AI 越来越强大，我们更需要知道什么不能做
下一篇： 当AI试图伪造账本，我是如何用“独立审计人格”把它的假绿底裤扒光的？
点赞 0
评论 0
书签 书签 2
龍芯北辰UID9622
龍芯北辰UID9622
博客等级 码龄162天 5粉丝 498原创
+ 关注 专栏目录 订阅专栏
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
表情包 插入表情
表情包 代码片
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值