Git 防止散列链中的无限循环？

好的，我想实现一个简单的网络算法，每个参与者选择自己的对等点，轮流查看他们最新的散列，生成自己的散列链，如下所示：

H[n+1] = hash( H[n] + P[n][k] )

其中，

p[n][k]

是所选对等方的最新哈希。让我们称之为“时间戳”

这一点是通过生成从

a

到

B

的散列链，生成一个网络，证明事件

a

发生在事件

B

之前，反之亦然。网络是以一种无许可的方式完成这项工作的——这意味着如果任何参与者在你的活动

a

上加上时间戳，那么最终他们都会这样做

我面临的问题是，如果参与者

X2

时间戳

X1

，

X3

时间戳

X2

等等，如果

X[n]

确实是对等的

X1

，那么这可能会自我加倍，并且他们会在周期中不断地给自己加时间戳，即使没有真正提交新事件

当我将fork

B

中的更改合并回

A

，生成一个新的哈希，然后将

A

的头（尖端）合并到

B

中时，git或mercurial也会出现同样的问题。换句话说，工作副本中没有任何更改，但每次新合并都会生成一个新的哈希，从而导致虚假更改

Mercurial通过检查上一次“真正改变”的情况来防止它。也就是说，如果自上次提交分支以来没有更改任何文件，它基本上会说“与直系祖先合并没有效果”

我同样可以通过遍历整个散列链来防止循环，直到找到一个循环为止。但这可能是一个非常漫长的过程。如果我在10次散列时切断它，那么11个或更多参与者的循环仍然会导致散列循环，即使没有真正的“改变”。或者我可能有一些“真正改变”的概念

---

有什么方法可以解决这个问题，或者谷歌的一些术语吗？

你可能需要更多的元数据，而不仅仅是散列来确定它是否已经来自某个节点。可以想象，该元数据是散列数据的一部分（除了“时间戳”）。这样就可以确认元数据的真实性。以git为例，散列不仅仅是父提交的散列，还包括提交消息、作者/提交者信息、日期和树散列

---

至于要搜索的术语：通常，这类系统（git、Mercurial、比特币、各种文件系统等）用于实现事务验证和完整性检查。

Mercurial和git总是添加新的哈希：它们从不在新提交时重复使用现有哈希。如果您的新哈希确实是新的，那么它就不能是循环的一部分。然而，这个特定的测试需要知道所有现有的哈希（Git和Hg都知道）。你的情况听起来有点不同。你是说如果你的散列真的是新的，它就不能成为循环的一部分吗？我的观点不是散列重复，而是参与者不断地进行新的散列，即使没有新的东西真正改变。Git和Mercurial通过它的ID标识提交。如果提交是新的，而它的两个父节点不是新的，那么我们向图中添加了一个新节点，并且由于新节点的两个边仅出站，该节点不是周期的一部分（要成为周期的一部分，必须有一些入站边缘）。假设初始图没有循环，所有节点在创建后都是只读的，这是添加节点的唯一方法：然后通过归纳，更新后的图继续没有循环。显然，根据定义，DAG没有循环。我使用这个词的意思不同：你可以无休止地将a合并到B中，将B合并到a中，即使文件没有任何新的更改。对：但这里的要点是，在Git和Mercurial中，你不只是为了好玩而添加新的提交。在您的情况下，您将不得不进行搜索，因为在您的系统中，您确实可以添加一个新节点，因为您可以。但在我的系统中，关键是如果一个参与者给你的东西加上时间戳，那么他们都会这样做。您可以包含邻居发布的哈希，也可以不包含。如果你不这样做，那么他们就不会包括你的，你现在实际上已经和邻居分开了。如果是，则哈希有助于确认邻居时间戳上的所有事件在之前发生。那么，我该如何强制这些人同时获取元数据呢？它们可能通过包含一个散列来为1000000个事件（在DAG的前面）加时间戳。所有这些不同事物的元数据将是巨大的。怎么办？好吧，你说“在DAG早期”，但你的问题源于事实，它实际上不是DAG，也就是说，它不是非循环的。核心问题，也就是您在Mercurial示例中提到的，是检测何时“没有工作要做”的问题。为此，您需要某种数据。也许你可以把散列分成两种类型？一种类型是“验证事务的哈希”，而另一种类型是“验证对等哈希的哈希”。然后，当您得到的所有哈希都是对等验证哈希时，您可以确定不需要做任何工作？