FROM : https://docs.blockstack.org/core/naming/forks.html
BNS有效地使用公共区块链来存储数据库日志。BNS对等点通过从区块链下载并重新播放数据库日志来引导自己，在这样做的过程中，它将计算与具有相同区块链视图的其他BNS对等点相同的名称数据库状态。
至关重要的是，BNS是建立在一个不知道BNS存在的公共区块链之上的。这意味着区块链对等点不验证BNS事务。相反，BNS对等方需要这样做，并且必须知道如何拒绝来自不诚实对等方(即不遵循相同一致规则的对等方)的无效事务和格式良好的事务。
BNS节点之间不直接通信——按照设计，BNS节点集是不可枚举的。BNS对等点之间唯一共享的通信媒介是区块链。
为了在没有区块链帮助的情况下识别和拒绝无效和恶意的事务，将嵌入到区块链中的名称操作日志构造为一个fork-一致的数据库日志。Fork-consistency是一个一致性模型，所有节点中的状态副本都具有以下属性:
-
每个正确的对等点维护一个格式良好、有效的状态操作历史。在本例中，每个正确的BNS节点都维护历史区块链事务的副本，这些事务编码了格式良好的有效名称操作。
-
每个诚实的对等点的历史记录包含它发送的所有操作的序列。也就是说，用户的BNS对等点的事务日志将包含用户的客户端写到区块链的所有有效事务的序列。
-
如果两个对等点接受来自同一个正确客户机的操作op和op '，那么它们的日志中这两个操作的顺序将相同。如果op '在op之前被接受，那么两个对等点的日志在op之前都是相同的。在BNS中，这意味着如果两个对等点都接受一个给定的事务，那么这意味着它们接受了相同的先前事务序列。
这意味着与区块链不同，BNS数据库日志可能有多个长期冲突的分支。但是，由于fork-一致性，一个正确的BNS对等点只处理其中一个分支，并且会忽略来自其他分支中的对等点的事务。换句话说，fork-consistency将BNS对等点集划分为不同的fork集，其中一个fork集中的所有对等点处理彼此的事务，而其他fork集中的对等点则完全忽略。
BNS节点使用一致哈希来标识它们属于哪个分支集。共识散列是节点操作历史的加密摘要。每个BNS对等点在每次处理一个新块时计算一个新的一致哈希值，并为它处理的每个块存储一致哈希值的历史。
两个诚实的BNS对等点可以通过查询彼此对给定块的一致哈希值，快速确定它们是否在同一个fork集中。如果它们匹配，那么它们在相同的fork集中(assming no hash collision)。
BNS客户端通过在区块链事务中包含来自该叉集的最近共识散列，对特定的叉集执行名称操作。与此同时，BNS协商一致规则规定，只有包含最近有效的协商一致散列的事务才能被接受。这意味着客户端所需叉集中的所有BNS节点将接受该事务，而不在叉集中的所有其他BNS节点将忽略该事务。通过阅读事务线格式文档，您可以看到协商一致散列在区块链事务中包含的位置。
Fork-set选择
区块链对事务的历史进行了线性化，这意味着一般来说，对于每一组不同的BNS一致规则，都存在一个fork集。例如，Blockstack Core 2016 hard fork和2017 hard fork都引入了新的共识规则，这意味着在撰写本文时，有三种可能的fork集:2016年前的fork集、2016-2017年的fork集和2017年后的fork集。公共BNS节点总是在具有最新共识规则的fork集中运行。
BNS客户端被鼓励与使用最多的fork集中的对等端通信，因为这个fork集中的名称数据库将编码用户最广泛接受和理解的名称/状态绑定。为了识别这个叉集，BNS客户端需要学习它最近的一致哈希表。一旦它拥有一个最近的协商一致散列，它就可以查询一个不受信任的BNS节点，以获得其名称数据库的副本，并使用协商一致散列来验证是否使用名称数据库来生成它。
BNS节点如何确定一致哈希是否对应于最广泛使用的叉集?有两种策略:
-
确定一个特征事务是否被广泛使用的fork集接受。如果客户端知道某个特定事务属于广泛使用的fork集而不是其他事务，那么他们可以使用consensus散列来有效地确定给定节点是否属于这个fork集。
-
通过检查区块链以确定一个fork集中存在多少“经济活动”。名称空间和名称注册的结构是这样的:将加密货币令牌发送到知名的burn地址，或发送到易于查询的payto - Namespace -creator地址。
这两种策略都依赖于这样一个事实:共识哈希是作为一个Merkle跳转列表计算的，该列表覆盖BNS节点接受的事务。客户机可以使用一致哈希来确定事务T是否被具有O(log n)时间和空间复杂度的节点接受。我们将协商一致散列解析为特定事务简化名称验证(SNV)的协议称为协议。有关SNV如何在引擎盖下工作的详细信息，请参阅我们关于这个主题的论文。
如果客户端有一个共识散列，并且知道广泛使用的fork集中有一个特征事务，那么它可以使用SNV来确定一个节点是否属于接受它的fork集中。
如果客户知道多个冲突的一致哈希值，他们仍然可以使用SNV来确定哪个值对应于最常用的叉集。为此，客户端将使用区块链explorer查找烧毁加密货币令牌的事务列表。这些事务中的每一个都将被视为潜在的特征事务:客户端将首先选择格式良好的BNS事务的子集，然后使用SNV来确定它们中哪些与哪些一致散列相对应。客户端选择一致的散列，该散列对应于累积烧损最高的fork集。
目前正在进行自动化这一过程的工作。
网友评论