问题标签 [consensus]

我正在尝试实现一个协作画布，许多人可以在其中自由绘制或使用特定的形状工具。服务器是在 Node.js 中开发的，客户端是使用 Angular1-js 开发的（我对它们都很陌生）。我必须使用共识算法来向所有用户显示始终相同的内容。

由于找不到合适的使用教程，因此我遇到了严重的麻烦。我一直在寻找和研究 Paxos 的实现，但似乎 Raft 非常实用。

有什么建议么？我真的很感激。

FLP86关于不可能在异步分布式系统中解决共识（即使只有一次故障）的著名证明假设，在第三个引理的证明中，存在一个事件e'，这样邻居配置C0和C1可以关联为C1 = e'(C0).

我不明白这是怎么可能的，因为在我看来，这就像e'执行从 0 价配置到 1 价配置的状态转换。此外，引理 3 的案例 1 的证明清楚地表明，任何 0 价配置的任何后继都必须是 0 价配置。我在这里想念什么？

这个问题的答案不回答上面的问题。另一个问题与存在的证明有关C0，C1而不是的存在e'。

场景 1：假设有一个 5 节点集群，其中 3 个节点已经失效。服务A(leader), B, C中有3个节点

A 向 B、C 复制了一个日志条目，收到成功的响应，提交它，应用它，响应客户端，然后死亡。现在，只有两个节点 B、C 有一些未应用的日志条目。现在，如果 D 出现，并且 B 成为新的领导者，那么未应用的条目会发生什么？它们也会被提交/应用吗？

场景二： 5个节点集群，3个刚下线，A仍然是leader，B在线

A 向 B 复制了一个条目，但无法提交，然后 A 被杀死，C、D 出现（所以 B、C、D 都出现了）。复制到 B 的条目会怎样？他们会被承诺/应用吗？

我很难理解领导者何时真正确认客户。这是 DistributedLog文档的一部分：

每个附加到日志段的批处理条目将由日志段编写器分配一个单调递增的条目 ID。所有条目都异步写入管道中。因此，日志段写入器会更新内存中的指针，称为 LAP (LastAddPushed)，它是写入器推送到日志段存储的最后一个批处理条目的条目 id。条目可以乱序写入，但只能按条目 ID 顺序进行确认。除了成功确认之外，日志段编写器还更新内存中的指针，称为 LAC (LastAddConfirmed)。LAC 是作者已经确认的最后一个条目的条目 ID。在 LAC 和 LAP 之间写入的所有条目都是未确认的数据，它们对读者不可见。

读取器可以读取高达 LAC 的条目，因为已知这些条目是持久复制的 - 因此可以安全地读取，而不会违反读取顺序的风险。writer 在发送给 BookKeeper 的每个条目中都包含当前 LAC。因此，每个后续条目都会使前一个条目中的记录对读者可见。LAC 更新可以搭载在编写器写入的下一个条目上。由于读者是严格的追随者，他们可以利用 LAC 从任何副本中读取持久数据，而无需与作者进行任何沟通或协调。

DL 引入了一种系统记录，称为控制记录——它作为两阶段提交算法中的提交请求。如果在指定的 SLA 内没有应用程序记录到达，编写器将生成控制记录。随着控制记录的写入，它将推进日志流的LAC。在收到写入用户记录的确认后立即添加控制记录，如果没有添加应用程序记录，则定期添加控制记录。它被配置为写入器刷新策略的一部分。虽然控制日志记录存在于物理日志流中，但它们不会由日志读取器传递给应用程序。

现在考虑以下场景：

1. Leader 向 Bookkeeper 发布消息
2. 追随者获取消息，附加到日志并向领导者发送ACK
3. 领导者从追随者那里得到确认，增加 LAC 并回复客户端消息已提交。
4. 现在：领导者在它可以搭载 LAC 已增加的追随者之前失败。
5. 问题是：由于潜在的领导者不知道 LAC 已增加的事实，它成为新的领导者并将日志截断为旧的 LAC，这意味着我们丢失了日志中已由前任领导者确认的条目。

结果客户端已经确认消息已经写入成功，但是已经丢失了。

例如，如何向节点证明公证人没有与交易对手勾结以双花输出？

Corda 系统内的信任和共识是如何实现的？

编辑：

在监管机构是公证服务运营商的场景中，监管机构可以向 Corda 节点透露哪些数据或信息，以提供对机构完整性的高度信任？（即可以提供公证人分类账真实性的证据或准确证据的数据）

换句话说，哪些数据或信息可以揭示监管机构的可信度的证据或证据？

这个问题更多是针对私有区块链框架，例如 Corda、Hyperledger 等。在所有这些平台上都可以编写一些名为链码、智能合约等的程序，让我们能够实现业务逻辑。所有这些都部署在区块链网络的每个对等点中，但是如何避免和检测在某些对等点中部署了不同版本的代码？

我说的是智能合约的最终结果是相同的，所以没有提交共识，但是是的，一些同行可以出于任何原因修改它运行的代码。

我们如何在私有区块链中管理这种情况？

在 raft 中，当一个节点重新启动时，它会尝试重做所有日志条目以赶上状态。但是如果节点在恢复阶段再次宕机，节点会执行两次操作。如果操作不是幂等的，这两次重做操作将违反状态机。

根据上面的描述，我的问题是，在实践中使用 raft 的系统中是否需要使 ops 幂等？

我在从我的数据集中确定最佳集群数量时遇到了两难境地。我已经获得了 ConsensusClusterPlus 热图，但不确定决定最佳集群数量。

有人可以帮忙吗？我附上了热图和绘图的图片，以决定最佳集群数量。似乎 k=3 是一个最佳数字点击这里查看图片 pic 6 , pic 4 , pic 2 , pic 3 , pic 7 , pic 8 , pic 9 , pic 10

场景很简单：许多公司需要共享一些参考数据（例如，产品列表及其属性）。

问题是目前每个实体都在内部收集/清理数据，然后与其他公司共享数据，这导致了交换文件（电子表格）的冗长过程。

解决这个问题的现代方法有哪些？当然，这种情况在现代企业生活中很常见，所以我正在寻找一些关于标准流程/技术的指导来研究。

谢谢！

在工作量证明中，如果我们篡改一个区块，从该区块重新挖掘整个区块链需要巨大的计算能力。但在权益证明中，nouce 并不难找到。那么是否有可能篡改一个区块并重建后续区块链？或者权益证明有其他方法可以防止这种情况发生？