[开源设想]去中心化的内网穿透项目(fknat)

这个项目最开始，其实只是想做一个类似 IPFS 的去中心化存储系统。

但真正开始做之后，我发现一个很现实的问题：

在国内，去中心化存储最难解决的，可能并不是“存储”，而是“网络”。

运营商 QoS、上下行限速、复杂的 NAT 环境，以及大量没有公网 IP 的设备，使得很多设计上非常漂亮的 P2P / 去中心化项目，真正落地时都会遇到一个问题：

节点之间，到底怎么稳定地连起来？

如果最后还是需要项目方自己准备大量高带宽服务器负责打洞、发现和中继，那么对于一个非商业项目而言，长期承担这些服务器和带宽成本其实并不现实。

所以项目最开始的目标很简单：

先做一个能够服务于去中心化存储的网络层。

但做到后面，我逐渐发现——

既然存储需要它，其他 P2P 应用同样需要它，那为什么一定要把它限制在“存储”这个场景里？

于是项目的方向慢慢发生了变化。

我现在更希望把它做成一个开放的、由参与者共同提供网络资源的 P2P 基础网络：需要 NAT 穿透、节点发现、中继传输能力的开发者，可以直接使用这个网络；拥有服务器、带宽等闲置资源的人，也可以作为节点加入进来，为整个网络提供能力。

最终我希望形成这样一个循环：

有人使用网络 → 有人为网络提供资源 → 提供资源的人获得对应的流量额度 → 额度继续在网络中流转 → 网络因此能够长期维持可用。

这也是目前这个项目真正的初衷。

目前项目已经到了一个我觉得可以拿出来让大家折腾一下的阶段。

所以想找一些感兴趣的人帮忙体验、测试、提建议，包括整个架构有没有明显问题、哪些设计不合理，以及下一阶段应该优先开发什么。

当然，如果你愿意直接参与开发，那就更欢迎了。

作为一点小小的感谢，我可以提供我自用gpt分发站点的 1× 倍率 50 额度。

先介绍一下目前整个网络的核心架构。

三类节点

整个网络目前存在三种角色：

使用节点、中转节点、计费节点。

下面是目前网络运行起来之后的大致结构：

其中为了方便描述，我暂时把两个使用节点分别叫做 natServer 和 natClient。

一次连接建立的大致流程是：

两个使用节点分别连接距离自己较近的中转节点 → natClient 发起连接请求，并携带目标 natServer 的 addr 信息 → 中转节点在网络中查找 natServer 所连接的中转节点 → 两侧中转节点建立通信 → 通知 natServer 有新的连接请求 → 双方进入正常的 TLS 连接建立流程。

所以简单来说，中转节点目前主要承担的就是：

节点接入、目标发现，以及必要情况下的数据中继。

那“计费节点”是干什么的？

前面的连接流程里，我一直没有提到计费节点。

这是故意的。

因为从整个项目的设计目标来说，计费节点应该尽可能少地参与实际的数据通信。

它更像是整个网络当前阶段的一套结算与准入机制。

理论上，如果目标是一个真正开放的去中心化网络，那么这里不应该长期依赖一个由项目方控制的中心化服务。

但目前项目毕竟还处在非常早期的阶段。

为了控制滥用、验证激励机制，同时避免网络在完全开放之后出现大量暂时无法处理的问题，我目前仍然保留了一个中心化的计费节点。

所以严格来说：

当前版本还不能称为“完全去中心化”。

更准确地说，它目前是一个数据传输和中继逐渐去中心化，但身份、准入和结算暂时中心化的 P2P 网络。

而我后续比较重要的一个目标，就是把这一部分也逐渐拆掉。

流量是怎么结算的？

真正建立连接并开始传输数据之后，中转节点会针对每一条逻辑连接统计流量。

目前 natClient 和 natServer 两侧都会产生对应的流量费用，计费单位为 Byte。

但中转节点不会每传输几个字节就去请求一次计费节点。

它会按照一定的时间窗口统计连接的流量，并根据窗口内的流量数据计算出对应的流量特征值 / 结算凭证。

随后：

中转节点生成结算数据 → 交由对应支付方签名确认 → 收集窗口内的签名凭证 → 提交给计费节点 → 计费节点完成最终的流量额度划转。

这样做的一个核心目的，是让计费节点尽可能只负责：

“确认这笔流量确实发生过，然后记账。”

而不是让它参与每一条连接的数据转发。

不过当前版本还有一个比较明显的中心化设计：

所有参与网络的节点，目前都必须在计费节点拥有对应的身份以及扣费密钥，否则无法接入网络。

这是目前为了防止恶意节点、无限白嫖流量以及其他滥用行为所做的妥协。

也是我后续最想逐渐去掉的一部分。

接下来准备做什么？

目前我考虑的几个主要方向是：

1. 逐步去中心化计费节点

   中转节点满足一定条件，例如在线时长、累计完成传输量、稳定性等指标后，可以进一步成为计费节点。

   计费节点自行生成身份密钥，并通过广播、公钥证明或者其他共识机制建立自己的网络身份。

   至于多个计费节点之间如何同步账本、如何防止双花/伪造流量、如何处理恶意计费节点，目前还在设计中，这部分也是整个项目接下来比较核心的问题。

2. 加入流量额度划转

   不同身份之间可以自由划转自己的流量额度。

   比如我运行中转节点获得了额度，但自己并不需要使用，就可以把这些额度转给其他节点。

3. 提供标准 SDK

   我最终并不希望这个项目只能服务于我自己的应用。

   后续会把节点发现、连接建立、NAT 穿透、中继、流量结算等能力封装成标准 SDK。

   这样开发者不需要关心底层网络是怎么建立的，只需要：

   “我要连接这个节点。”

   剩下的事情交给网络本身完成。

有一件事目前明确不会做

不会提供法币购买流量的充值入口。

这里的“流量”更接近整个网络内部使用的资源额度 / 结算单位，而不是准备拿来交易的 Token。

流量额度由计费系统发行，并通过中转、传输等网络贡献行为进行分配。

如果不同社区希望使用自己的积分体系，可以自行建立积分与流量额度之间的兑换关系。

我更希望它最终形成的是：

资源 → 流量额度 → 使用网络 → 资源提供者获得额度 → 再次流转

而不是：

充值 → 买流量 → 项目方卖带宽。

因为一旦走到后者，这个项目本质上就变成了一个传统的商业化网络服务，而不是我最开始想做的东西。

目前整个项目仍然非常早期，很多设计也远远谈不上成熟。

特别是计费节点去中心化、恶意节点防护、流量证明、节点身份、Sybil Attack、账本一致性这些问题，后面其实还有非常大的坑要填。

所以这次把它发出来，并不是想说：

“我已经做出了一个完整的去中心化网络。”

恰恰相反。

我是想在它还没有彻底定型的时候，让更多人进来折腾一下。

如果是你，你会拿这样的网络做什么？

或者从架构上看，你觉得现在这套设计里，最容易被攻击 / 薅爆 / 玩坏的地方在哪里？

目前去中心化的中转节点、用户节点已开源:

https://github.com/wangshiben/natp2p (中转节点/核心框架)
https://github.com/wangshiben/fknat (用户节点、已编译为应用)
https://github.com/wangshiben/natP2pSDK (用户节点的核心包)

下面是目前计费节点的用户界面