Pillar III · N-09 · System Spec

PoB 管道

Proof-of-Build · 贡献证明的核心流水线——证明每个节点「做了什么、贡献几何」。这是 WCN「证明账本」的贡献侧支柱,与财务侧储备证明(C-01)并立。本页把已在《第一阶段节点经济协议》Part 5 成形的归因函数、凭证格式与争议机制,落成可施工的系统规范。

系统 N-09 PoB Pipeline真源 wcn-network-tokens.v1.json守护体 AG-03 节点网络体状态 70% · 全机构最成熟来源 节点经济协议 v0.1 Part 5
00

现状

PoB 管道是 WCN 最成熟的系统(70%):其核心机制已在《第一阶段节点经济协议 v0.1》第五部分「归因与 PoB」与《节点系统完整方案 v2.0》中成形——归因函数(α/β/γ)、凭证格式(链下签名 + 多方背书)、争议窗口均已定义,且已是国家合伙人 KPI 的计量单位(「12 个月本国 PoB 凭证 ≥ 10 份」)。

缺的是把这套机制落成正式系统规范(本页)、工具化签发与上链。本页将既有设计固化为可施工的流水线 + 凭证 schema,未决参数(α/β/γ 权重值、上链时点、验证者去中心化)显式标注待白皮书/紫皮书与 GC 审定,不编造。

成熟度
70%
设计来源
协议 Part 5
凭证阶段
Phase 1 链下
异议窗口
14 天
01

定位 · 证明账本的贡献侧

WCN 自命「主权级证明账本机构」,其「证明」有两条独立支柱:

证明系统证明什么
Proof-of-Build 贡献证明N-09(本页)谁、做了什么贡献、权重几何——网络侧
Proof-of-Reserves 储备证明C-01储备 ≥ 已发行义务——财务侧
核心价值主张

「贡献无法证明,WCN 的核心价值主张落空」——PoB 是 WCN 区别于普通基金/社群的根本。它让每一份 carry、每一级声誉、每一枚会员 NFT 都可追溯到一份可验证的贡献凭证,而非人情或职位。

02

归因函数 · α / β / γ

据协议 5.1,第一阶段归因采用三维加权——把一笔成果拆给参与各方:

维度含义典型角色
α 角色谁引入、谁主导(身份与位置贡献)引入方 Introducer · Lead
β 工作实际投入的工作量与交付Service Providers · 执行节点
γ 结果最终达成的结果与影响Backers · 跟投与背书方

α/β/γ 的具体权重系数由白皮书/紫皮书的归因函数定稿,GC 入职后审定;本页只固化三维结构,不预设数值。

03

PoB 凭证 Schema

据协议 5.2,第一阶段凭证以「链下签名 + 多方背书」形式,每份至少包含:

字段内容来源/规则
deal_idDeal 唯一标识协议 5.2
parties[]引入方 · Lead · Backers · Service Providers 列表,各带归因权重α/β/γ 加权
evidence交割证据:合同 · 汇款凭证 · 或链上 tx hash;服务范围/交付物/付款方式须事前书面约定并留存协议 5.2 · 4.x
signatures[]各责任方电子签名,门槛 ≥ Stephen + Lead + 50% 以上跟投节点协议 5.2
issued_at / effective_at生成时间 · 生效时间协议 5.2
dispute_window争议窗口,默认 14 天协议 5.3
history_hashPoB History Hash——凭证链的完整性锚方案 v2.0
on_chain第一阶段 false(不上链);Phase 2 起锚定上链协议 5.2 · 本页路线
04

签发流水线

一份 PoB 凭证从贡献发生到生效入账的可执行路径:

贡献发生Deal 引入/交付/跟投 凭证草案填 deal_id + parties + α/β/γ 证据校验合同/汇款/tx hash 多方签名≥ Stephen + Lead + 50% 跟投 14 天异议窗口有异议 → 走争议处理 争议处理(§05)复核 → 改判/驳回 生效 + History Hash 记录入账 → 下游消费

无异议则窗口期满自动生效;凭证一经生效即写入 PoB History Hash 链,作为声誉、carry、NFT 的权威依据。

05

异议与争议处理

据协议 5.3:任何被列入凭证的责任方,在 14 天异议窗口内可提出异议。

步骤处理
提出异议窗口内由责任方就归因权重/参与事实提出,凭证暂缓生效
复核由 Lead + 守护体 AG-03 复核证据;必要时上 Council
裁定改判权重 / 维持 / 驳回该凭证;裁定记入 History Hash

争议裁定阈值与上诉路径(是否上 Council / 理事会)为待治理(N-06/N-07)就位后审定项。

06

下游消费 · 一份凭证喂四个系统

PoB 凭证生效后,是多个系统的权威输入——这是 N-09 作为「网络基石」的杠杆:

下游消费什么接口
N-04 声誉系统累计贡献分 → 节点声誉评分与等级贡献分聚合
C-03 Carry 引擎α/β/γ 归因权重 → carry/收益瀑布分配权重 → 分配比例
N-01 NFT 合约贡献与等级 → 会员/等级 NFT 凭证链上凭证
C-01 资金库经 C-03 形成的 carry/奖励义务 → 资金库须储备的负债义务 → 储备证明
与财务侧的闭环:PoB 证明贡献 → C-03 据归因权重算出 carry/奖励义务 → 这些义务进入 C-01 的储备证明(Proof-of-Reserves)分母。贡献侧(N-09)与财务侧(C-01)由 C-03 串成一条「贡献→权益→储备」的可对账闭环——两份证明合起来才是完整的「证明账本」。
07

上链路线

阶段形态状态
Phase 1链下签名 + 多方背书,PoB History Hash 留痕,不上链已定义
Phase 2History Hash 锚定上链,凭证可公开验证待白皮书/工具
Phase 3归因函数与签发工具化、验证者逐步去中心化待定

上链时点、链选型、验证者集合为待决项;第一阶段刻意保持链下以求灵活与低摩擦,符合协议设计。

DoD · 完成判定

已交付 vs 待执行

设计层 · 本页已交付

  • 定位:证明账本贡献侧,与 C-01 储备证明并立
  • 归因函数 α/β/γ 三维结构
  • PoB 凭证 Schema(8 字段 + 签名门槛)
  • 签发流水线(贡献→草案→校验→签名→异议→生效)
  • 14 天争议处理流程
  • 下游消费(N-04 / C-03 / N-01 / C-01)与财务闭环
  • Phase 1→3 上链路线

现实层 · 待执行

  • α/β/γ 权重系数由白皮书/紫皮书定稿(待 GC)
  • 签发工具化(表单 → 多签 → 凭证库)
  • Phase 2 上链:History Hash 锚定与公开验证
  • 争议上诉路径待 N-06/N-07 治理就位
  • 与 C-03 Carry、N-04 声誉的接口落地