最后更新:
Radicle 是一个用于托管和协作 Git 代码库的点对点协议,无需依赖中心化代码托管平台。它利用加密身份、分布式网络和本地优先存储来支持代码协作、代码库验证以及抗审查性。 [1]
Radicle Protocol 是一个用于代码发布和协作的去中心化点对点网络,基于 Git 构建。参与者无需依赖中心化托管服务,而是在自己的设备上运行 nodes 来存储和同步代码库,包括议题(issues)和补丁(patches)等相关的协作数据。该网络使用流言协议(gossip protocol)来发现对等节点和代码库,同时利用 Git 的复制机制支持 nodes 之间的数据交换。只要至少有一个在线对等节点托管着正在访问的代码库,其架构就与现有的 Git 工具和工作流保持兼容。
Radicle 采用本地优先(local-first)架构,允许用户在没有互联网连接的情况下访问其代码库。每个代码库都有一个唯一标识符,提交代码、评论议题和提交补丁等操作均经过加密签名,以便其他参与者验证其真实性和来源。这种设计实现了协作和数据共享,而无需依赖中心化机构来托管代码库或管理项目活动。尽管其主要侧重点是代码发布和协作,但该协议也可以支持其他分布式应用,包括知识共享、项目协调和数据集协作。 [4]
Radicle nodes(节点)是其点对点网络的参与者,既可以作为客户端也可以作为服务器,托管 Git 存储库并与其他 nodes 同步更改。每个节点由一个唯一的节点 ID 标识,该 ID 派生自 Ed25519 公钥,而每个存储库都有自己的存储库 ID。用户通过定义存储库选择、数据保留和同步的播种策略(seeding policies)来控制其节点存储和共享哪些存储库。个人用户可以在个人电脑上运行节点以支持自己的项目,而专用的种子 nodes 可以为更广泛的网络或特定社区提供对存储库的持续访问。
节点身份使用公钥密码学在本地生成,不需要中心化的身份提供者、电子邮件地址或个人信息。公钥作为节点的标识符,而私钥用于验证签名消息,必须妥善保管。用户还可以分配一个可更改的别名,使他们的 nodes 更易于识别。为了参与网络,用户需要安装 Radicle 的开源客户端软件,其中包括网络客户端和命令行界面,以及可选的 Web 前端。参考实现是用 Rust 编写的,各实现方案均遵循通过 Radicle Improvement Proposals (RIPs) 维护的协议规范。 [4]
Radicle 采用本地优先的点对点 (P2P) 架构,允许 nodes 相互发现、交换存储库更新并同步代码,而无需依赖中心化托管服务。其网络层使用 Gossip 协议来分发有关可用对等点、托管存储库和存储库更改的信息。经过签名的公告包含节点标识符和时间戳,允许参与者验证消息的真实性,并避免重复转发已收到的消息。节点可以临时保留并重播公告,以帮助新连接或重新连接的对等点发现网络活动。
存储库元数据通过 Gossip 协议交换,而 Git 则使用 Git 的复制协议传输实际的代码和对象。节点可以从托管或播种相关存储库的对等点获取存储库数据,并支持通过共享网络连接进行多次传输。新的 nodes 使用引导节点(bootstrap nodes)来发现初始对等点并在参与常规网络发现之前建立地址簿。与服务器运营商可以影响用户身份和共享服务访问权限的联邦系统不同,Radicle 让用户保留自己的存储库和协作数据,而种子 nodes 则提供可互换的托管和复制服务。 [4]
Radicle 存储库是在其点对点网络中共享的 Git 存储库,具有用于建立所有权、权限和真实性的附加标识符和元数据。它们可以包含源代码、文档或其他数据集,每个存储库在初始化时都带有一个身份文档,定义了其名称、描述、默认分支和指定的委托人(delegates)。委托人是由去中心化标识符 (DIDs) 识别的个人、团体或自动化代理,负责合并补丁、解决问题和管理存储库权限等任务。存储库以其创建者作为初始委托人,并可以将权限分配给多个委托人,由指定的签名阈值管理对默认分支的更改。
每个存储库都会获得一个全局唯一的存储库 ID (RID),该 ID 派生自其身份文档的初始版本,身份文档可以在不更改标识符的情况下进行更新。身份文档以标准化的 JSON 格式存储在 Git 存储库中,支持一致的加密验证。Radicle 还通过将复制限制在明确授权的对等节点集来支持私有存储库,同时存储库代表(delegates)保留访问权限。私有存储库数据在静态存储时未加密,因此访问控制依赖于限制哪些节点可以复制和访问存储库,而不是依赖存储加密。 [4]
Radicle 使用基于标准 Git 存储库构建的本地优先存储架构,允许用户直接从其设备存储、管理和同步存储库数据。每个存储库在本地存储为一个裸 Git 存储库,并使用 Git 命名空间(namespaces)隔离与各个对等节点相关的引用。每个命名空间由其对应的节点控制,允许用户维护自己的分支和更改,而无需修改其他对等节点的版本。这些命名空间共享底层的 Git 对象数据库,当多个对等节点拥有相同的提交或文件时,可以减少重复存储。用户可以同时使用本地工作副本和存储副本,通过标准的 Git 命令(如 push 和 fetch)同步更改。
用户可以进行离线更改,并在节点重新连接到网络时将其传播给其他对等节点。Radicle 使用专用的 rad:// URL 方案和 Git 远程助手(remote helper),将 fetch 和 push 操作引导至相应的存储库和对等节点命名空间。当未指定对等节点时,Git 操作可以针对存储库的规范引用(canonical references),这些引用代表了其代表们达成一致的版本。这种设计在保持与现有 Git 工作流兼容性的同时,允许在不依赖中心化托管服务器的情况下维护和同步存储库数据。 [4]
Radicle 使用自我认证模型来验证存储库的真实性,而不依赖于中心化托管服务。每个存储库的身份通过其存储库 ID (RID) 和身份文档建立,身份文档定义了其代表、默认分支以及授权更改所需的签名阈值。默认分支的规范状态取决于所需数量的代表是否对同一个提交进行了签署。例如,如果一个存储库需要三名代表中的两名批准,那么当两名代表向各自的分支发布匹配的更新时,该提交就变成了规范提交。存储库的更改通过加密签名进行身份验证,包括对跟踪分支和协作数据的 Git 引用的更新。Radicle 会在节点的引用发生变化时自动对其进行签名,并将签名信息存储在专用的 Git 引用下。这使得网络参与者能够利用身份信息和加密记录来验证存储库更新并确定存储库的权威状态,而无需受信任的第三方。 [4]
Radicle 使用协作对象 (COBs) 来支持 Git 原生不提供的协作功能,包括议题跟踪(issue tracking)、代码审查和讨论。这些对象直接存储在存储库中,并在点对点网络中进行复制,从而保持协作数据的本地优先、用户受控和加密签名。Radicle 提供了三种预定义的 COB 类型:用于跟踪错误和功能请求的 Issues(议题)、用于提议和审查代码更改的 Patches(补丁),以及用于管理存储库身份文档的 Identities(身份)。每个对象都由唯一的类型名称和对象标识符标识,用户还可以为其他协作需求定义额外的类型。
COB 使用 Git 提交历史将变更记录为有向无环图,允许跨多个用户独立进行更新,而无需通过中央服务器进行协调。当节点同步时,它们会合并各自的历史记录,并通过以确定的、因果一致的顺序处理变更来重建对象状态。这种方法利用了 Git 现有的数据完整性和同步机制,同时帮助节点在每个对象的一致视图上达成共识,即使更新是以无序方式到达的。该系统还支持存储在代码库 refs/cobs 层级结构中的自定义 COB 类型,允许开发人员和组织在不更改核心协议的情况下添加协作功能。 [4]
Radicle Garden 是一项托管服务,为 Radicle 点对点网络提供常驻节点,在用户个人设备离线时保持 Git 代码库可用。该服务通过复制选定的代码库来提高可用性,而无需用户运行自己的服务器。用户保留其本地 Radicle 节点用于签名和管理工作,而 Garden 节点则提供持续的代码库播种(seeding)。该服务还可以播种由其他用户维护的代码库,帮助确保项目在整个网络中保持可访问性。Radicle Garden 由 Better Internet Foundation 运营,这是一家负责监督 Radicle 协议开发的瑞士非营利组织。该服务为自我管理的种子节点提供了一个可选的托管替代方案,同时其源代码保持开源,用户可以继续运行自己的基础设施。托管节点位于欧洲,订阅收入用于支持该基金会继续开发 Radicle 协议的工作。 [3] [4]
RAD 是 Radicle 生态系统的原生治理代币,Radicle 是一个去中心化的代码协作网络。它用于参与协议治理,并为持有者在使用某些基于 Ethereum 的 Radicle 协议时提供费用相关的福利。RAD 持有者可以对协议变更以及有关 Radicle Treasury(持有大部分代币供应量)的决策进行投票。治理通过 Radicle DAO 进行管理,该 DAO 使用源自 Compound 协议的治理系统,并遵循“一币一票”模式。持有 RAD 还可以为某些协议交互提供折扣或费用豁免,而没有代币的用户仍可以通过支付适用费用来访问协议。[2]
RAD 的总供应量为 1 亿枚代币,分配如下:[2]