详解去中心化代码协作平台 Radicle：项目架构、机制设计与治理模式

与 GitHub 相比，Radicle 专为集市式协作而设计，没有单一的 「主 」分支供贡献者合并，而是由众多上游远程交换补丁。

原文标题：《详解 Radicle：去中心化社区的代码协作基础设施》
撰文： DAOrayaki

Radicle 是一个建立在开放协议 Radicle 上的去中心化的代码协作网络。它使开发人员能够在不依赖可信中介机构的情况下进行代码协作。Radicle 旨在提供类似于中心化式代码协作平台或功能，同时保留 Git 的点对点性质，旨在做到强分布式版本控制。Radicle 还利用以太坊（opt-in）获得独特的全局名称、DAO 代码库和一些融资相关的协议，帮助维护者维持其开源工作。

如何运转？

该网络由一个建立在 Git 基础上的点对点复制协议驱动，称为 Radicle Link。Radicle Link 通过一个叫做 「gossip」的过程来传播数据，用点对点的发现来扩展 Git。也就是说，网络中的参与者通过在本地保留冗余副本，并与选定的同伴分享（也称为 「复制」）他们的本地数据，从而分享和传播他们 「感兴趣 」的数据。通过利用 Git 的智能传输协议，Radicle Link 保持了 Git 在数据复制方面的效率，同时通过点对点网络层提供全球去中心化的存储库。

由于网络上的所有数据都是由网络上对等的点在本地存储的，所以开发者可以分享和协作 Git 仓库，而不需要依赖托管服务器等中介机构。

与 GitHub 的区别？

在 Radicle 上的协作与在 GitHub 和 GitLab 等中心化式代码协作平台上的协作略有不同。

• Radicle 协作从上到下都是开源的。没有 「封闭 」的组件。Radicle 协作的每个组件都是可审计、可修改和可扩展的。
• Radicle 是完全建立在开放协议上的。没有 「特殊服务器」、特权用户或公司来控制你的协作。
• Radicle 是基于点对点的架构，而不是客户端-服务器模式。
• Radicle 默认不是全局性的。相反，你跟踪的同行和项目的社交图决定了你看到的、互动的和复制的内容。
• Radicle 是为集市式开发（bazaar-style development）设计的。这意味着在项目中，没有一个单一的主分支供贡献者合并使用。相反，同行维护他们自己的项目视图，其他同行可以通过补丁获取和合并。
• Radicle 用以太坊上的去中心化组织取代了中心化机构的机关功能及其等级管理模式。
• Radicle 是一个自我维持和社区拥有所有权的网络，而不是一个公司。它的管理依靠一种名为 RAD 的代币，主要在以太坊上使用。

如何使用？

使用 Radicle 最简单的方法是使用 Upstream，这是一个由 Radicle 项目创始团队开发的桌面客户端。通过 Upstream，你可以创建一个身份，托管你的代码，并与 Radicle 网络上的其他人进行协作。

创始团队

• Cory Levinson 联合创始人

Cory Levinson 是 Clovers Network 独立分析师、软件开发者、数据科学家。他是区块链与分布式点技术领域各种项目的积极贡献者，曾分别与 Oscoin、Secure Scuttlebutt 以及最近的 Clovers Network 有合作。

此前，他曾担任数据分析师，后来加入 SoundCloud 数据基础架构团队，工作约 5 年时间。2017 年，他在莫斯科的 Strelka 研究所，开始积极研究区块链领域，在那里领导了能源项目 Phi 的开发。

• Eleftherios Diakomichalis 联合创始人

Eleftherios Diakomichalis 是 Oscoin 联合创始人，由 OSS 合作与激励的去中心化网络与密码货币。另外，他是 SoundCloud 早期员工，此前担任其副总裁，领导数据科学团队。他的兴趣在于网络科学和统计学，侧重于在线社区。

• Abbey Titcomb 联合创始人

Abbey Titcomb 现任 Onward Labs 策略主管。此前，她在 UnderscoreVC 工作过，研究基于协作的加密经济模和系统设计。

详情介绍：

为何使用 Radicle?

在过去的十年中，开源已经成为软件开发的一个标准。自由和公开地分享代码，使软件的开发成本大大降低，也更容易，科技创新因此激增。

像 GitHub 和 GitLab 这样的代码托管和协作平台通过将开源代入主流受众，为开源的发展做出了巨大的贡献。他们定义了标准的词汇和行为，使更多的人能够接触到 git，增强了社会编码的能力，并创造了全球性的开发者社区。一个不可否认的事实是，他们已经完全改变了人们写代码的方式。

这些平台还托管着最大的开源开发存储库，不仅包括代码，还包括问题、拉取请求、评论。 甚至社交关系—明星、点赞、关注—也存在于这些平台中。

然而，这些平台是由公司拥有的。它们受公司法的约束，有权定义其服务条款。他们可以实施用户禁令，比如目前针对伊朗、叙利亚和克里米亚的 GitHub 账户的禁令，以应对美国政府的压力。它们很容易受到审查制度以及企业和国家目的的影响，这些目的往往与自由和开源社区的目标不一致。

在一个几乎所有的软件都依赖开放源代码的世界里，维护自由和开放源代码生态系统的弹性和健康比以往任何时候都更重要。这就是为什么我们认为，依赖中心化托管的平台和公司来分发关键的开源基础设施是不可持续的。对这种中心化式服务的依赖与自由和开放源码生态系统的价值相矛盾。

Radicle 被认为是一种替代物。其目标是消除中介，建立一个健壮、功能强大和安全的 P2P 生态系统。必须有一种有意识的改变，优先采用符合自由和开源软件原则的去中心化代码协作替代方案。

替代方案

存在 GitHub 的替代品，从 SourceForge 和 GitLab 这样的平台，到更成熟的协作方式，如邮件列表。像 Gitea 或 Gogs 这样的平台为代码协作提供了自我托管的开源解决方案，具有较低的平台风险，但使开发者处于孤立的环境中，无法进入全球的开发者网络。一种可行的替代方案是联盟。诸如 ForgeFed 联合 GitLab 的提议是朝着正确方向迈出的一步，但实施起来还不够完善。此外，联盟依赖于域名，而域名可能经常被政府扣押。

其他成熟的开源项目，如 Linux 内核，采用了更多不局限于单一平台的市场化和可访问的开发环境，如邮件列表。这些都是可行的，但当它们被要求达到像 GitHub 这样的平台所建立的可用性标准时，就会出现问题。

像 Scuttlebutt 这样的点对点协议为我们提供了分享和托管信息的替代解决方案。这些协议能够在不依赖服务器的情况下离线工作，但建立在它们之上的应用程序缺乏让用户在全球范围内轻松协调的能力。这对博客或社交网络的使用案例来说不是太大问题，但当涉及到软件协作时，为了满足当今中心化式平台的可用性和可发现性标准，一个规范的全球注册表是必要的。任何人无论身在何处都能为任何开源项目做出贡献，这对于培养一个真正的自由和开放的网络是必要的。

设计的原则

当我们着手构建替代方案时，自由和开源代码协作是不可或缺的价值。 我们制定了以下指导原则列表：

• 它必须优先考虑用户自由
• 它必须是可访问和抗审查的

任何人都应该有使用该软件与他人协作的自由。任何一方都不能禁止用户访问系统，也不能禁止内容的分享。它必须是可审计和透明的。此外，用户应该有自由控制他们的互动和他们在个人基础上看到的内容。

• 它必须是用户友好的

该软件必须易于使用，并且不期望用户的行为发生巨大的变化。响应性和功能必须符合当前平台所建立的标准。

• 它必须是离线优先的

它必须不需要互联网连接、DNS 或在线门户才能来运行。必须没有单点故障，而且必须始终可用。

• 它必须在安全上不妥协

使用时必须不需要信任第三方或中介机构。该系统的每一个人工制品都必须用加密签名来证明，并进行验证。

让我们在这个框架下看看 GitHub 或 GitLab 这样的托管平台：它们的成功在于用户友好和可访问性，但由于它们是中心化控制的，所以它们是可审查的，并不优先考虑用户自由。如果我们看看 Gitea、Phabricator 或 Gogs 等自我托管的解决方案，它们是免费的、抗审查的、用户友好的，然而，由于把关（gate-keeping）和隔离的环境，它们不容易被访问：跨 Phabricator 部署的用户不能相互交流。我们所看到的所有目前可用的自我托管解决方案都是这种情况。他们还存在单点故障，并且需要互联网连接来与系统进行大部分互动。

假设一个联合的 GitLab 可以满足所有的要求，但是，联合的服务不能是离线优先的，也不能提供对用户身份的主权。用户被捆绑在特定的实例上，因此也存在与中心化式服务相同的缺点。

像 Linux 内核邮件列表这样的集市式解决方案几乎在所有概述的原则方面都很成功，但在用户友好性方面却很有限。很难将电子邮件线程的可用性与 GitHub 和 GitLab 等平台上可能出现的复杂工作流程进行比较。

Radicle：一个用于代码协作的点对点堆栈

Radicle 采用了 Scuttlebutt 社会覆盖范式，在分布式版本控制系统之上建立了一个点对点复制层，首先是 git。用户账户和登录被公钥加密技术所取代，托管问题跟踪器被本地对等复制所取代，单一规范上游的想法被基于补丁的点对点或 「集市 」模所取代。

为了补充复制层，我们引入了一个建立在以太坊上的选择注册表，它持有规范的项目元数据。这使得项目能够锚定重要的信息-如项目状态和存储库负责人-并保证其全球可用性和不可更改性。

需要强调的三个主要主题是：专注于点对点的代码协作模式，建立在底层的分布式版本控制系统上进行复制，以及采用协议优先的方法。

重新审视 「集市」

「大教堂和集市 」描述了两种自由软件的开发方式。大教堂模式，以 Emacs 等项目为例，公开发布版本，但让所谓的 「个人巫师 」独家开发。另一方面，集市模式由 Linus Torvalds 推广，并由 Linux 的巨大成功所验证，要求完全开放的开发，频繁和早期发布，在整个社区内授权，并尽可能多的 「眼球 」关注代码。只要有足够的眼睛，所有的错误都是浅显的。

点对点网络使开发者和维护者更容易开发出不仅是共享的，而且是以实际源代码和安全的对等身份为基础的项目。通过对等复制，补丁变得更加全面，因为它们与开发过程中的本地问题、评论和审查联系在一起。有了更全面的补丁，集市式开发可以保持其灵活性，同时支持更复杂的工作流程。这就是为什么 Radicle 用 90 年代和 21 世纪初开源黑客们所熟悉的点对点模式取代了单一的模式的想法。它使集市式的开发更容易、更好。

这种潜力导致 Radicle 选择了基于 gossip 的「社交覆盖」，该系统建立在分布式版本控制系统上，该系统免费且始终可用，无需自托管或信任拥有用户数据的公司。

Git gossips 优点

下一个设计决定来自于我们对去中心化存储的实验结果。在 IPFS 上建立第一个版本的 Radicle 后，我们遇到了性能和功能问题。主要的认识是，在存储层上点对点地复制 git repos，使我们别无选择，只能失去 packfile 协议，这是 git 能够快速的原因之一。这种方法会使源代码成为二等公民–这使得存储历史大数据变得不切实际。

在思考上述问题时，一个几乎显而易见的想法出现了：为什么不使用 git 本身来分发数据？在 git 中存储合作成果（问题、拉动请求、评论 ……）以前已经做过了，而且 git 中的数据结构可以满足我们所有的需求。与 gossip 层搭配，git 就成为了存储、复制和分发代码和协作工件的必要条件。

通过在 git 之上建立一个点对点的覆盖层，我们不仅找到了一个高性能的解决方案，而且是一个更适合代码协作的解决方案。问题、评论和评论成为本地工件，被加密签名并进行离线交互。

协议，不是平台

大代码托管平台的故事与互联网从开放协议到私有平台的普遍转变相吻合。今天，大多数社会编码平台实际上利用了开放协议（git、mERCurial、ssh），但已经建立了封闭的花园。

Radicle 的方法旨在通过专注于协议优先的理念，并拒绝中介机构的数据收集和孤立。 这反映在构建和扩展 git 的决策中。 将其作为复制的纽带建立在其优势和去中心化性质之上。 在本地提供问题、拉取请求、评论为开发人员提供了管理和设计工作流程的工具，而无需将他们锁定在新的「体验」中。 尽管将构建任何前端接口，Radicle 最重要的是作为一个开放协议存在—而不是一个平台。

Radicle 设计

Radicle Link 是一个带有通用分布式版本控制后端的点对点 gossip 协议。它的目标是足够通用，可以用在 pijul 或 mERCurial 等系统之上，尽管它最初的实现主要是支持 Git。

该协议通过基于 gossip 的复制来传播 Git 存储库，使存储库的托管和共享不依赖于中央服务器。Radicle 网络上的存储库被称为 「项目」，由 「同伴 」进行 gossip。

在 Radicle 中。

• 同行跟踪其他同行
• 同伴跟踪他们感兴趣的项目
• 点对点对项目进行闲谈。这意味着复制来自他们所追踪的同伴和他们感兴趣的项目的更新。
• 这些互动创造了一个 「可信的 」同伴和项目的社交图，成为 Radicle 内部合作的基础。

Radicle Link 支持集市式的合作模式，其中没有单一的 「主 」分支供贡献者合并，而是由众多的上游通过远程交换补丁。

身份概述

Radicle Link 区分了两种类的身份：个人和项目。前者描述了系统中的行为者（同行），而后者描述了一个或多个行为者协作的软件项目（仓库）。

Radicle Link 中的 「身份 」概念仅仅意味着在 Git 存储库中的常规位置存在一个身份文件，该文件要遵守某些验证规则。初始文件的哈希值被认为是其稳定的标识符，并被编码为统一资源名称（URN），其形式为 rad:git:$HASH （针对 Git 仓库）。该 URN 应该可以在网络上解析为同名的顶级 Git 仓库（$HASH.git），如果该仓库包含所述身份文件，并且该文件通过了验证规则，则该仓库是有效的。

数据模

我们维护资源库数据一致性的模，是基于更新框架（TUF），它被设想为安全分发软件包的一种手段。我们的方法是建立一个所有权证明，与一个对等体的网络身份，或一组对等体的网络身份相联系，这样，项目的观点可以根据对等体之间的信任关系进行复制（「跟踪」）。

Revision 是一个文件内容的加密哈希值，这样，这个文件在存储系统内可以通过这个哈希值进行内容寻址。

replaces 指的是文件的前一个修订版，如果是第一个修订版，则指的是没有。

payload 是一个可扩展的、向前和向后兼容的数据类，包含应用程序定义的关于存储库的元数据。协议解释了其中的一些属性，如 Doc Payload 中所述。

delegation 包含被授权发布和批准文件新修订的密钥所有者的公钥。授权格式取决于正在建立的身份类。

Git 实现概述

Radicle 基本上把 Git 当作一个数据库。这意味着一切都存储在一个单一的 Git monorepo 中，并通过 Upstream 客户端进行读取和写入。我们的 Git 实现是为了激励播种者提供所有必要的数据来解决和验证一个仓库，同时通过尽可能地消除 gossip 查询和 git 获取来减少延迟。

对等发现和复制概述

Radicle Link 通过一个叫做 gossip 的过程，通过点对点网络发现来扩展 Git。 这意味着网络中的对等点通过在本地保留（复制）冗余副本并与点对点共享增量来共享和传播他们「感兴趣」的数据。使用 Radicle，我们根据节点和项目的「社交图」在连接的存储库中复制数据，从而根据用途和价值传播源代码和变更集：对某个项目感兴趣的节点越多，该项目就越可用 项目制作到网络。

复制模

存储库是 Radicle 中复制的基本单元。要将存储库发布到网络，必须首先将其初始化为项目。项目将源代码、问题和提议的更改组合在一个保护伞下，并带有唯一的、可共享的点对点标识符。整个项目数据和元数据，包括评论等社会人工制品，都存储在存储库中。要创建项目，存储库的所有者定义项目身份。在后台，按照惯例 rad/id，在存储库的预定不相交分支中创建项目身份文档。该文件包含重要的元数据，例如项目名称、维护者列表以及任何相关链接。

复制单元是一个存储库，由项目文档上下文中的 PeerID 标识（请参阅数据模）。相应 DeviceKey 的持有者称为存储库的维护者。属于同一项目的存储库在本地表示为单个存储库，由 Radicle URN （或上游客户端中的 Radicle ID）标识。在项目的上下文中，存储库的维护者可以选择跟踪其他对等点的存储库（这在 git 术语中称为远程：对远程存储库的命名引用）。如果发现远程存储库跟踪其他远程存储库，则跟踪存储库还将传递跟踪这些远程存储库，最多 n 度。

因此，Radicle 上的项目保留了其远程节点的传递信息（即通过哪个跟踪的 PeerID 跟踪另一个 PeerID）。

追踪

追踪是协作的基础，因为它推动了项目及其工件的交换。 在 Radicle 中，peer 跟踪他们感兴趣的其他 peer 和项目。当一个 peer 克隆另一个 peer 的项目或通过 Upstream 将它们作为远程添加到他们的项目来直接跟踪一个 peer 时，就会发生这种情况。

由于对等点代表网络中的独立设备，因此他们每个人都有自己的网络视图。 每个对等点都在其自己的 monorepo 中跟踪来自连接对等点的项目、身份和数据的视图。

当一个节点在一个项目的上下文中跟踪另一个节点时——比如说，如果它克隆了另一个节点的项目——它设置了获取和 gossip 另一个节点对该项目的看法的意图。 这意味着包括项目元数据、所有工作分支和提交，并且变更集将被复制并存储在跟踪 peer 的 monorepo 中，以便可以获取和协作。

直接追踪

一个点可以跟踪另一点的方法是，明确告诉其 Monorepo 跟踪特定的 PEER_ID。使用带有感兴趣的 PEER_ID 的 track 函数，monorepo 在 git 配置中创建一个新条目。来自被跟踪 peer 的任何更新都可以类似地获取并应用到跟踪 peer 的 monorepo。

Upstream 中的 Manage Remotes 功能使用 track 功能将作为远程的对等点直接添加到项目中。

社交图（The Social Graph）

在多个 peer 复制的情况下，任何跟踪项目的 peer 也会隐式跟踪它的维护者。这意味着当网络上的任何 peer 克隆一个项目时，所有该项目的维护者都将最终出现在该 peer 的远程列表中。由于项目的维护者是在项目的规范视图上进行工作的，因此这种自动跟踪功能可以确保在整个网络中散布项目时，其运行状况和一致性。

这也意味着对于单个 PEER_ID，我们有一个包含更多 PEER_ID 的子图——无论他们是项目的维护者还是其他被跟踪的同行。任何时候复制一个对等点，他们的子图的一部分也会被复制，最多 2 度。

这意味着每次跟踪对等点时，您不仅将它们添加为遥控器，而且还添加了它们的遥控器，以及它们遥控器的遥控器。这确保了项目在整个网络中始终可用，而无需完全依赖项目的维护者或原始跟踪 peer 。

验证

为了确保数据的完整性和真实性，当创建一个项目的工作副本时，根据远程对等体的证明历史在所有其他版本库内容之前被获取，并对其运行验证程序。如果这没有产生一个验证的状态，克隆就会被中止。由此产生的仓库状态必须包括根据远程对等人对身份文件的看法，至少有四分之一的代表的证明历史。在 Git 中，在获取仓库内容之前，可以通过检查公布的远程参考文献来确定是否会出现这种情况的说法。如果这些前提条件没有得到满足，克隆就会被中止，已经获取的数据也会被剪除

播种（seeding）

为了提高数据可用性，网络中的参与者可以选择充当种子。这在概念上类似于 Secure Scuttlebutt 中的酒吧。种子节点是在公共 IP 地址上运行的「永远在线」节点，为任何连接的对等点提供数据。通过加入种子节点，它会自动跟踪您并在其他连接用户的网络中共享您的数据。这提高了您的数据在整个网络中的可用性，同时也更容易找到其他人的数据。

种子可能会跟踪给定项目的大量存储库，因此从种子进行克隆将大大增加跟踪图的连通性。另请注意，通过跟踪种子，上游维护者可以增加返回它们的路径数量，这样即使贡献来自不在维护者的跟踪存储库中心化的参与者，也可以回流。

上游预先配置了官方 Radicle 种子节点，以引导您的连接。如果您删除了默认种子节点，您可以随时按照添加种子节点中的步骤重新添加它。

协作模式

我们从 git commit 构建的 Identity 允许多个 id 来描述文档的相同修订版（因此同样有效）。这意味着各个代表的历史记录可能会在其提交历史记录中有所不同，但仍会就已证明的文档修订的有效性达成一致。

这意味着上游中没有单一的规范分支（或主），因为同行都在维护自己的同一个项目的上游。但是，由于 Radicle 身份的数据模，与维护者相关联的项目始终存在「规范」视图。维护者可以遵循基于领导者的工作流程，在该工作流程中，他们将贡献节点的历史融合到他们的主要分支中。由于他们的视图是可验证的，并且在同行关注项目时隐式跟踪，因此，同行可以确保他们正在复制项目的规范和更新视图。

除此之外，Radicle Link 的工作方式对最终用户的协作体验有一定的影响：

您的社交图决定了您看到、互动和复制的内容类。

假设您已经在 Radicle 网络中发现了一个感兴趣的项目（稍后将详细介绍可发现性），那么为了与其交互，您必须做的第一件事就是跟踪它。跟踪项目表示兴趣，并且设计意味着跟踪项目的维护者，因此在他们的社交图中复制数据。

在项目的上下文中，存储库的维护者可以选择跟踪其他所有者的视图（这在 Git 术语中称为远程：对远程存储库的命名引用）。如果发现远程存储库跟踪其他远程存储库，则跟踪存储库还应传递跟踪这些远程存储库，最多可配置 N 度（目前正在开发中）。

垃圾邮件和内容审核自然由 peer 的社交图处理

虽然这起初可能看起来令人困惑，但实际上它更自然（它实际上模仿了现实生活中的交流），并且通过设计解决了垃圾邮件和内容审核等问题，这些问题自然由同行的社交图处理。

垃圾邮件发送者的补丁或问题永远不会被实际维护者跟踪，因此网络的其余部分不会看到它们（除非明确跟踪）。同样，如果您对同行的观点或对项目的贡献不感兴趣，您可以简单地取消关注他们，停止复制、查看他们的数据并与之交互。

在同一个项目中，两个同行可能有不同的看法。

上述设计也意味着，即使在同一个项目中，同行也有主观（并且经常有分歧）的观点。

至少，您对项目的看法将成为您所关注人员的看法加上项目维护者的看法的总和。此外，您可以通过配置复制设置来扩展您的视角，以便还可以从您关注的 peer （即，peer 的 peer/ 远程方的远程方）传递跟踪 N 度以外的其他远程方。

这种设计也解决了完全依赖分布式账本技术的去中心化系统的一个重要问题，即 「区块链中毒 」的问题。这是指有人故意将非法内容添加到仅有的 append source 中，希望使复制项目的唯一行为产生法律上的问题，正如 Linux 基金会的 Konstantin Ryabitsev 正确指出的关于依赖 IPFS 的 Radicle 的前一个版本。

代币

Radicle 项目的建立有两个主要目标。

• 开发有弹性的合作基础设施，尊重用户的自由，不依赖可信的守门人，也不依赖企业或国家。
• 利用新开发的主权金融基础设施（比特币、以太坊、DeFi），以便为开发者创造新的价值流并发展数字公域。

为了实现这两个目标，一直有一个先决条件：让 Radicle 能够自我维持。

Radicle 项目已经在网络上发布了 1000 多个项目，并且在其公开测试版中每周平均增长 8%，Radicle 项目已经准备好在其社区中去中心化网络，并开始寻求自我可持续发展。

为什么选择代币？

虽然主权和审查抵制的论点继续加强，但去中心化的理由超越了技术。在当前的闭源网络时代，用户已经放弃了对其隐私和软件自由的控制权，以自由方便地进入开放互联网。现在，他们正在寻找替代方案，因为我们的全球社交平台由于社会压力、缺乏创新以及满足利益相关者所需的无情挖矿而恶化。

在这种现实中，在传统范式中构建 Radicle，例如 SaaS 或开放核心公司，将迫使用户保持客户 / 公司关系，使他们容易受到最终提取（extraction）的影响。此外，如果 Radicle 要成为真正尊重用户自由的弹性协作基础架构，则需要在考虑信任最小化的情况下进行开发，让世界上任何人都可以访问它，同时在资金雄厚的大市场中保持适应性和竞争力- 公司。摆脱这种模式的唯一方法是构建自给自足和社区所有的免费和开源网络。

在这些限制条件下，Radicle 将基于代币的可持续性模视为最有希望的前进道路。更具体地说，正是加密网络中治理原语的出现，为工程社区拥有的开源协议和网络提供了一个新的设计空间。这些原语为真正「开放」的开源世界提供了基础，而不受任意墙的束缚。

出于这些原因，Radicle 项目将作为一个开源、社区主导和自我维持的软件协作网络向前发展。 Radicle 的 ETHereum 集成将实现这一愿景，这是一套补充 Radicle 对等网络的开放协议。它的智能合约系统支持独特的全球名称、去中心化的组织和经验，帮助维护者维持他们的开源工作。集成的智能合约系统将使用 Radicle 代币去中心化——这是一种治理代币，可实现 Radicle 网络的集体治理和长期可持续性。

如何运转？

Radicle 代币 (RAD) 被设计为一种治理代币，它支持许多基于以太坊的功能以及 Radicle 网络的公共所有权、集体治理和长期可持续性。

简而言之，Radicle 代币的经济模会在用户与某些基于以太坊的协议交互时向用户收取费用，除非他们是成员（代币持有者）。通过购买（或获得奖励）并持有一定数量的代币，用户可以避免（或打折）费用并参与网络治理。成员保持对所有基于以太坊的智能合约的管理控制权，最重要的是，拥有超过 50% 的代币总供应量的 Radicle 金库。

任何人都可以通过购买和持有一定数量的 Radicle 代币成为会员，以换取以下好处：

• 与 Radicle 基于以太坊的协议交互时可享受折扣或不收费。
• 参与 Radicle 智能合约系统治理（通过投票和提案）的权利。

通过为 Radicle 用户提供持有代币的功能性理由，他们可以体验治理带来的好处，并开始为数字开源基础设施的公共所有权建立新的范式。如果出于任何原因，他们对网络不满意，他们可以通过参与治理来「表达」担忧，或者可以通过向市场出售代币来「退出」。

治理

Radicle 治理模块是一个复合分叉，赋予所有者参与 Radicle 智能合约系统治理的权利。明确地说，这意味着会员可以控制和参数化其会员体验-无论是通过更改费用，升级合同还是引入新的体验。

选择 Compound 治理模块是因为它经过了实战测试、审计，并通过其流动授权方案平衡了执行权与社区参与。

与 Compound 类似，每个 RAD 代币等于一票，并且通过将投票权委托给代币持有者选择的地址（或多个地址）来启用投票：

• 业主自己的钱包，如果他们想自己投票。
• 另一个用户的钱包，如果他们希望另一个用户代表他们投票。
• 没有钱包，如果他们不想投票。

任何将 1% 的 RAD 委托给其地址的人都可以提出治理动作。建议是可执行代码，而不是团队或基金会实施的建议。所有提案都有 3 天的投票期，任何有投票权的地址都可以对提案投赞成票或反对票。

金库

与其他去中心化协议类似，选择加入 Radicle 的一些 ETHereum 功能会产生网络费用。这些费用累积在 Radicle 财库中，这是一个智能合约，占整个代币供应量的 50%。

财政部完全由 Radicle 代币持有人通过 Radicle DAO 控制。成员将通过社区计划和倡议协调库房的供应分配，从而支持网络的长期可持续性。这些社区项目（例如，开发者挖矿，贡献者奖励，赠款等……）将通过 Radicle 社区有机地出现，因为 Radicle 成员使用国库来不断支持网络的增长和恢复力。

网络的代码和资产库是公开管理的，允许任何开发者为项目做出贡献并影响项目的发展方向，使 Radicle 成为集体治理的实验。

代币分配和发布时间表

1 亿个 Radicle 代币（固定）已在创世时铸造，并将在 4 年内授予。

• 50% 社区资金（归属超过 4 年）
• 19% 团队（从加入之日起 4 年归属，从创世起 1 年锁定）
• 20% 早期支持者（1 年锁定期）
• 5% 基金会（1 年锁定期）
• 2% 种子计划（1 年锁定期）
• ~4% 流动性引导池

问答

在 Radicle 上进行协作与在 GitHub 上协作有何不同？

与中心化式代码协作平台相比，Radicle 专为集市式协作而设计。 在 Radicle 网络上，内容通过称为 gossip 的过程进行点对点分发。 这意味着同级可以控制他们的社交互动，因为他们自托管自己的内容以及他们感兴趣的任何同级的内容。这也意味着在项目中，没有贡献者合并到一个单一的主分支。 每个 peer 都使用其变更集和分支维护项目的视图。 这些观点会被其他对这些变化感兴趣的同行 gossip。

Radicle 如何比中心化平台更安全？

Radicle 网络是点对点的，建立在公钥密码学基础上。 首先，这意味着无需依赖第三方来访问或使用 Radicle 网络。 由于没有失败的中心点，并且可以抵抗公司和国家的捕获和审查，因此更难取缔。 此外，Radicle 网络上的所有数据都经过加密签名和验证，因为它在 peer 之间进行 gossip。 虽然中心化平台依赖用户界面组件和关键预言机来表示用户与用户之间的信任，但 Radicle 已将信任设计为协议的核心。

Radicle 如何与 Git 交互？

Radicle Link-为 Radicle 网络提供动力的协议建立在 Git 上。 所有 Radicle 数据都存储在您机器上的单个 Git monorepo 中，通过上游客户端读取和写入。

Radicle 如何获得许可？

Radicle 是完全免费和开源的。 它在 GNU 通用公共许可证 (GPLv3) 的第 3 版下使用 Radicle Linking Exception 获得许可。

问题和 PR 将如何运作？

社交协作功能（即错误报告、补丁、讨论等）都在 Radicle 路线图上。 它们的工作方式与我们现在的体验非常相似，但将是本地优先和加密签名的。 这意味着问题、PR 和讨论将更加安全，可离线使用，并作为 git 对象存储在您的机器上-而不是在中央服务器上！

我可以在 Radicle 上备份 GitHub 项目吗？

是的！将代码库发布到 Radicle 是创建存储库点对点备份的好方法。在 Radicle 上维护一个项目的镜像就像推送到另一个遥控器一样简单。阅读有关创建项目的更多信息。

我可以用 Radicle 替换 GitHub 吗？

如果你想！虽然我们的 Beta 版本将只有基本的协作功能（即代码托管、共享、签出和推送 / 拉取），但我们计划引入可以支持与 GitHub 类似的日常代码协作体验的功能。它们将包括错误报告，补丁，代码审查和讨论。

话虽如此，虽然我们认为减少对中央托管平台的依赖通常是一个好主意，但我们也相信代码协作解决方案为不同的人服务于不同的目的。 Radicle Upstream 将支持社交协作，但其首要任务是提供安全的，本地优先的，对等代码协作-而不是确切的 GitHub 副本。

我的数据存储在哪里？

在 Radicle 网络上，内容通过称为 gossip 的过程进行点对点分发。 这意味着对等点在他们的机器上本地的 Git monorepo 中自行托管他们自己的内容——以及他们感兴趣的任何对等点的内容。 这也意味着无论何时您的数据发布到网络，它都可以被复制并存储在另一台对等机器上。

我可以在 Radicle 上创建私有存储库吗？

不，还没有-但是将来！ 具有端到端加密的私人项目在我们的路线图上。 同时，请务必注意，放置在 Radicle 上的所有内容都可以公开获得。

什么是 remote？

远程是指你的项目由另一个人维护的项目版本。要在 Radicle 上与其他人合作，你必须添加并关注其他人的 remote 才能从他们那里获取更改。 你可以在项目页面上管理 remote。

什么是 Radicle ID？

Radicle ID 是在 Radicle 网络中识别项目的独特方式。 您可以在项目页面或种子节点仪表板上找到它。

什么是设备 ID？

设备 ID 是绑定到特定设备的 peer 公钥的编码。 未来人们将能够管理多个设备 ID，但目前每个身份只能有一个设备 ID。

我可以在多个设备上使用 Radicle 吗？

可以，但是目前没有。 尽管还没有多设备支持，但是您仍然可以在不同的设备上创建帐户，但是它们不会被链接到一个上游用户帐户下。

我如何确保没有其他人知道我的显示名称？

你还不能…… 我们将很快引入独特的名称。

我可以删除项目吗？

目前，此功能不受支持，但已在路线图中，并将包含在即将发布的版本中。在此之前，您只能从本地机器上删除您的项目，从而限制了可以找到和复制您的项目的对等点数量。您不能从其他 peer 的本地机器上删除项目，因为他们保留对其本地数据的控制权。

为什么我只连接到一个对等点？

默认情况下，上游客户端连接到 Radicle 操作的种子节点。虽然我们支持流行病广播来寻找并连接到其他对等点，但我们目前不支持打孔，这将阻止两台计算机之间的稳定连接。

合约

Radicle Token: 0x31c8eacbffdd875c74b94b077895bd78cf1e64a3

Governance: 0x690e775361AD66D1c4A25d89da9fCd639F5198eD

Timelock: 0x8dA8f82d2BbDd896822de723F55D6EdF416130ba

Genesis: 0x6838f63899728816f602B3e9bF73952e2bD6dc35

Registrar: 0x37723287Ae6F34866d82EE623401f92Ec9013154