Simperby：基于 Git 的区块链

Simperby: 基于 Git 的区块链

Simperby 最独特的特性之一是它对 Git 的使用。

前提条件

你应该对以下内容有基本的了解：

1. 区块链
2. Simperby 治理和共识
3. Git

总结

1. Simperby 链中所有已完成的和待完成的数据都存储在 Git 仓库中。
2. 所有已完成的数据，包括交易、议程、议程证明、聊天记录和区块，都以线性方式提交到 finalized 分支。
3. 所有待完成的数据，包括待处理的议程（等待批准）和区块（等待最终确认）都以从 finalized 分支增长出来的多个分支的形式呈现。
4. 每个 Simperby 节点管理自己的 Git 仓库，并为对等节点和节点Operator提供只读的 Git 服务器。
5. 节点Operator可以 git fetch Simperby 节点管理的本地服务器到他们自己的本地克隆，遍历历史记录，并使用任何 Git 客户端检查快照和差异。
6. 对等节点也可以从彼此获取区块链数据，验证提交，并同步区块链状态或待处理的提案。
7. Simperby 作为一个通用的分布式 Git 仓库运行，可以包含任何对组织有用的数据。这很容易实现，因为 Simperby 将 Git 提交作为区块链交易。 任何在仓库的规范分支（finalized）上进行的提交都将以拜占庭容错和分布式的方式永久存储。

对应关系

以下是对应的关系：

1. 交易和区块头：提交
2. 区块链的规范历史：finalized 分支
3. 区块提案被最终确认：rebase 到 finalized 分支
4. 状态快照：仓库的工作树
5. 启动一个新节点：克隆仓库
6. 对等网络：从彼此获取仓库

为什么选择 Git？

Git 是一个分布式版本控制系统，在软件开发社区中被广泛使用。它是一项成熟的技术，已经使用了几十年。我们使用 Git 作为 Simperby 底层存储的主要原因有四个。

版本控制系统

首先，Git 是一个版本控制系统。它提供了很棒的功能，如分支、合并、变基和差异比较。你可以检出到任何提交，并浏览该时间点的文件系统。它以线性或 DAG 结构管理仓库的整个历史记录。

这与 Simperby 非常吻合，因为…… TODO

文件系统

Git 管理一个文件系统，用户可以通过主机操作系统直接浏览。由于 Simperby 是一个为组织服务的区块链，而不是一个合约平台，区块链状态的作用是作为通用数据存储。以下是为组织使用分布式文件系统的一些例子：

1. 替换像 谷歌云盘 这样的共享文件系统
2. 存储组织拥有的网站的静态文件服务器
3. 组织的代码库——也是 Git 本身最常见的用例
4. 差异敏感的数据，如组织的法律或章程（组织章程大纲、细则等）

如果你想探索区块链状态的快照（包括过去的状态），你可以简单地检出到修订版本并浏览文件系统。

分布式

Git 本质上以分布式方式工作。一个 Git 仓库可以有多个“远程仓库”，可以自由添加、删除和从中获取。仓库没有“中央服务器”。基于这个原则，在 Simperby 中，每个节点都会添加他们发现的对等节点，并可能获取相关的远程分支，验证它们并更新他们的本地仓库。它可以通过验证传入的区块头来推进区块高度，从而移动本地的 finalized 分支。它还可以跟踪作为对等节点的远程分支提供的新观察到的议程或区块提案，反映在本地仓库上，并用自己的分支标记。

强大的第三方工具和服务

Git 是目前使用最广泛的版本控制系统。它拥有庞大的第三方工具和服务生态系统。

1. 像 GitHub 或 GitLab 这样的托管服务可以轻松地镜像组织的仓库。这对于想要向公众提供数据的组织非常有用。这将节省开发自己的区块浏览器和索引服务的成本！也可以添加一个 CI 插件来验证传入的提交，就像 Simperby 节点所做的那样。
2. 像 GitKraken、SourceTree、GitHub Desktop 这样的客户端或你在文本编辑器上的各种扩展将使仓库的探索和编辑（对于提案者）都更加容易和高效。

规范

这里我们介绍 Simperby Git 仓库的规范。

提交

提交的定义如下：

1. block：用于提议或最终确认的区块的空提交
2. tx：对状态进行任意更新的交易（除了保留目录）。请注意，tx 提交是提交标题不是以其类型 tx 开头的唯一例外。 它可以是空的。
3. tx-delegate，tx-undelegate：一个非空的额外议程交易，用于更新委托状态，该状态位于仓库的保留目录中。
4. tx-report：一个非空的提交，用于报告验证者的不当行为，并附带加密证明。这必须包括由罚没引起的状态变化。
5. chat：用于高度的聊天记录的空提交。
6. agenda-proof：用于议程的治理批准证明的空提交。

提交格式

TODO

分支

以下是 Simperby 节点专门处理的分支名称。

1. finalized：始终指向最后一个最终确认的区块。它受到强力保护；用户不能推送到此分支。
2. p：此节点的区块提案。节点Operator可以推送到此分支或强制推送到此分支。推送时，Git 服务器将检查分支的有效性。共识引擎将识别此分支并提议达成共识。它代表“区块提案”。
3. a-<hash>：从其他节点传播过来的有效议程（但尚未批准）。如果治理部门已经批准了议程，它将指向位于议程提交之上的 agenda-proof 提交。<hash> 必须是提交的哈希值，截断为前 8 位数字。
4. b-<hash>：从其他节点传播过来的有效区块（但尚未最终确认）。<hash> 必须是提交的哈希值，截断为前 8 位数字。
5. fp：一个非常特殊的分支，始终保存最后一个区块的最终确认证明。这是必需的，因为区块头不包含其自身的最终确认证明。因此，为了使仓库具有自验证性，必须以某种方式在某个地方保存该证明。此分支只有一个空提交，直接位于相应的区块提交之上，标题为 fp: <height>。提交消息正文包含实际的证明。请注意，由于签名者的不同观察结果，fp 分支的提交可能在节点之间有所不同，但证明本身必须有效。

标签

标签不能由用户推送。它们始终由节点管理。

1. vote-<number>：仅适用于议程提交；表示用户已投票支持该议程。<number> 由节点任意分配。
2. veto-<number>：仅适用于区块提交；表示用户已否决该区块。<number> 由节点任意分配。
3. genesis：创世区块。

结构

// 历史记录从底部到顶部增长。
// 每行代表一个 Git 提交。

block H+1 (branch: finalized)
chat H+1
[extra-agenda transactions]
...
agenda proof H+1
agenda H+1
[ordinary transactions]
...
block H

如果节点收到多个议程，它将呈现多个分支，这些分支由 ordinary transactions 和从 block 增长的单个 agenda 组成。

起源

在 Simperby 中，区块链起源被定义为在现有 Git 仓库上创建第一个 block 提交。仓库可以处于任何状态，所有历史记录都将作为“起源前”时代保存。起源前时代中最后一个提交（创世区块的父级）的 Git 提交哈希（不是 Simperby 哈希）将贡献给创世区块头的 previous_hash 字段。

示例

TODO

• 原文链接： github.com/postech-dao/s...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～