Handshake 中文白皮书
摘要
互联网安全的基础依赖于可信任的证书颁发机构（CA），这些证书颁发机构证明用户正在连接到正确的服务器或节点。这产生了对少数可信赖参与者的依赖，其中许多是营利性公司或其他可能没有长期动机来管理互联网的参与者。净效应是“ 1-of-m multisig”，由此，如果任何一个受信任的CA失败，则整个互联网的安全都会失败。此类失败已经在这种受信任的CA设计中发生过并将继续存在，而随着越来越多的基础设施联网，将带来灾难性的风险。
已经有许多替代方案被提了出来以恰当的保护互联网，但并没有成功。从根本上讲，需要一个信任锚来提供域名与声称是这些域名正确端点的服务器之间的安全关联。联盟节点（CA）与控制网络的单个受信任实体（DNSSEC）之间已经进行了权衡。Handshake是一个正在进行的项目，旨在建立一个去中心化的网络，通过建立加密经济激励机制的方式，来协调对域名和证书之间关联的共识。
本文档描述了一项提案、操作功能以及打算用去中心化的证书颁发机构和由去中心化的区块链及加密经济学机制支撑的加密证明组成的全局独特的命名空间来替代中心化受信任的互联网基础结构的意图。这种构造使命名空间可以直接指向代表信任锚的紧凑证书，该信任锚不像现有的联合证书颁发机构模型中那样依赖于单个受信任的机构来创建证明。Handshake建立在紧凑可验证证明上，以确保与嵌入式和移动设备的兼容性，并且对提交的默克尔式状态证明大小和性能有显著改进。
此外，我们还提出了一种方法，该方法受到了自由开源软件美学的启发，想要实现去中心化，大规模的社区协作。自由开源社区为互联网的发展做出了最关键的贡献，并创造了全人类赖以生存的软件。 这种协作是通过建立一个由区块链支持的去中心化基础架构来实现的，并由最有能力集成和使用Handshake区块链的人使用他们对代币的直接所有权来表示对这些证书和协作的一致赞同，从而从长期激励的角度对自由开源社区进行了优化。Handshake项目和社区是一项功能试验，旨在以自利的赠予经济取代中心化公司的社会功能，同时实现协作的目标。
项目概述
许多人将Web浏览器上的绿色小锁图标理解为他们与网站的服务器之间的连接是安全且加密的。但是，这种安全性总是被托付给少数几个中心化的证书颁发机构（CA）身上。这些机构是互联网的守护者，但已经有许多的失败案例[fakecert-fr] [fakecert-ir]。随着互联网连接越来越多的设备，经济基础设施逐渐联网，任何一个故障的影响都会大大增加。
历史上存在一个被称为Zooko三角形[zooko]的三难困境。这个困境是说，任何人必须从三种可能的特性中选择两种，这些特性包括：对人类有意义、去中心化和安全。该三难困境反映了围绕以下观念的感知约束，即需要对于短域名（例如网站地址）的共识建立单点信任，否则域名所有者缺乏全局共识消除了名称的意义和安全性。
通过在由许多验证网络的参与者代表的单一去中心化区块链中，围绕域名和证书之间的关联建立单点共识，最近一些区块链方面的创新可能已经绕过了这个难题。要实现此安全属性，不仅需要重新设计证书颁发机构中的信任锚，还需要在域名基础设施中进行深度集成。
我们设计了一个区块链，该区块链可以优化之前的缺陷，确认利益相关者（比如现有的顶级域名持有者（TLD））相，针对去中心化进行了优化（同时仍然允许n-of-m认证）。用户使用原生代币注册与特定证书绑定的TLD作为身份标识。提交的包含所有顶级域名的默克尔证明允许使用紧凑的、可共享的包含和排除证明。该区块链的存在是为了试图解决对全局唯一命名空间的需求，而这必须对唯一域名和证书建立关联。虽然可以创建单一的中心化的全局统一的关联（DNSSEC），但也可以通过创建具有自己的加密经济激励（硬币）的区块链来创造一个去中心的系统，激励包括拍卖唯一命名空间和创建区块。需要女巫攻击保护的稀有资源通常由中心化的信任权威机构（CA，ICANN）管理，但是也可以通过使用基于区块链的机制来实现全局共识和资源分配。
由于需要使用区块链来实现对命名空间的全球共识，因此需要选择如何为此系统分配资源。Handshake背后的意图是将资源的有代表性部分分配给利益相关者，这可能对开发和使用产生潜在的贡献，因此绝大多数资源都被分配给了免费开源社区。该项目可能会刺激其他项目以无义务分配的形式将绝大多数经济资源分配给免费开源社区。本文档介绍了一种新兴的机制和博弈，在这种机制和博弈中，去中心化的区块链项目开发者和投资者在面对其他项目的竞争时，可能由于重大的利己动机，将绝大多数代币/硬币所有权分配给免费开源社区，最终将分配给全人类。
为了实现新的分配博弈和依赖于给合同工的真实礼物的新经济，必须通过一种在博弈论上合理的、自我督促且自利的机制。该项目的主要目的之一是激发一种机制，使个人能出于自利的动机，来建立去中心化项目并大范围地分配礼物。因此，其目标是通过创始人发起、开发和全球扩展项目来实现自利的迫切回报。但是，为了扩大规模，项目之间存在这一种博弈，这就是将链本身的所有权分配给尽可能多的参与者。Handshake计划将15％的代币分配给负责创建代币的个人和公司（开发者/机构/顾问，以及早期投资者平分，两方各得到7.5％）。这样可以确保自利的博弈可以在未来的项目中永存，而没有大量前期开发成本的未来项目甚至可以更低。
Handshake项目计划将约70％的代币供应分配给开源开发者、项目和非营利组织，而对免费和开源开发人员的没有任何协议上的工作期望。
从根本上讲，自利机制要求所有开发人员和用户都收到代币作为奖励。该机制如下所述：假设在未来发布了三个假想项目，它们想实现相同的目标，比方说一个去中心化的网状网络区块链。三个项目中的两个将其价值的90％给了项目的创建者。第三个将85%的价值给了FOSS开发人员和那些建立节点的人。有理由认为，第三个项目成功的几率会更大。Handshake机制在设计层面想要创建一个竞争性的资产所有权博弈，将其更多分配给FOSS开发人员，甚至可能分配给全人类。
就像资本主义在参与者之间创造了一种竞争博弈，这种竞争博弈中自身利益的竞争降低了非垄断商品环境中的商品价格，Handshake机制是一个探索类似的并发博弈、以最大化自由开源软件开发者和公众的所有权的项目。没有任何一个生产者在资本主义市场上因为利他主义降低自己商品的价格，这是通过自利的竞争激励手段实现的，“当我降低价格时，我就会赚更多的钱”。同样，Handshake机制正在试验这样一种机制：“当我为FOSS开发人员和全人类发放更多奖励的时候，我就能赚更多钱”。
去中心化证书颁发机构与区块链
解决三难问题（Zooko三角）的关键在于：域名与所有者的密码学身份之间的关系上。通过将域名所有者设为加密密钥，我们可以通过创建由该所有者的密钥签名（托管链）来创建一个直至公钥的所有者的证书链。在当前传统系统下，这是不可能的，因为域名的所有者不是由加密密钥控制，而是由托管人持有的受信任记录拥有，记录内容是域名所有者的非加密记录，例如， TLD“ .com”由Verisign持有。
但是，SSL / HTTPS证书链的加密证明不足以创建去中心化的证书颁发机构。如果对于密钥和域名之间关系的去中心化记录没有真实的规范，则该记录可能会引起争议。爱丽丝可以声称拥有TLD“ .example”，而鲍勃可以认为自己是正确的所有者。于是就不能确定“ .example”的真正所有者是谁。
区块链按顺序记录，可以知道一条记录比另一记录存在得早，创造了规范所有权记录的能力（从而让一个人知道Alice在Bob可能会注册一个域名之前就已经注册了一个域名，因此只有Alice的域名是正确的）。没有这种规范化，我们就不可能有信心确定自己在与一个正确的域名所有者对话，因此这对于规范域名解析至关重要。
这种规范化引入了一个有趣的难题，即对网络进行女巫攻击的能力。即使使用规范顺序，命名空间分配问题仍然存在。一方可以向网络进行欺诈，注册存在的所有可能的短域名，从而垄断网络。当一个或少数几个参与方垄断资源时，将严重降低其实用性。为了缓解此问题，需要使用区块链固有的代币来作为创建域名的成本函数。当拍卖并售出一个域名时，代币会从系统中永久销毁。当网络欺诈没有成本时，单独的一方就会拥有一切。原生代币是必需的，因为与美元挂钩的币将取决于外部环境，并需要有受信任的第三方充当系统的守护人，而本地代币将不依赖于任何单个受信任的第三方。
结果，这就变成了一个分配资源，以作为防止女巫攻击的一种方法的问题。在代币诞生之初，应该把大多数给最初的开发者/投资者、大多数给矿工，还是给FOSS开发者？Handshake是一种实验，我们认为让FOSS社区拥有大多数所有权，对某些项目类型而言，相对于传统的公司成长和发展模型而言，是一种合理的，具有博弈论上优势的策略；一个去中心化的区块链是理想的。
共识
Pow
随着比特币的出现，工作量证明(Proof of Work) [pow]第一次被用于加密货币。比特币的PoW是在名为Hashcash的PoW上进一步迭代的。PoW的使用产生了专门用于优化性能的芯片，即矿机。矿机可以确保PoW网络受到保护，但它也会出现算力的垄断。
然而，我们认为使用SPV的PoW同样带来了好处，所以这种垄断是一个可接受的风险。没有SPV证明，我们的协议在实践中是不可用的。 目前还没有一种已知的、足够去中心化的 PoS 系统能够有效地对抗欺诈的SPV证明。
PoW 函数
Hashcash使用SHA3和blake2b作为工作量证明函数。 SHA3是目前在工作量证明中不够典型。 我们发现Hashcash的简单质限制了无法预料的优化空间，并且
当前在工作量证明中缺少SHA3与blake2b的结合使用，这种结合将为硬件制造商创造了一个更公平的竞争环境。
Cuckoo Cycle算法一开始被考虑使用，我们认为它有望在协议初始迭代中扮演重要角色。 在开发协议的整个过程中，Tromp和其他贡献者对Cuckoo Cycle 挖矿算法不断优化。考虑到这些优化和基础算法本身的复杂性，我们开始考虑挖矿过程中不可预见的优化的空间。
我们担心，如果发现这些不可预见的优化却保密，可能会导致矿机生产市场出现更严峻的垄断。此外，我们发现Cuckoo Cycle的验证和挖矿算法缺乏严肃的学术分析。如果优化Cuckoo Cycle有一些经济激励，我们期望图论研究者和其他专家将参与优化挖矿算法和矿机。
我们认为这些是不可调和的问题，因为它们阻碍了选择合适的Cuckoo cycle参数。Cuckoo cycle的参数本身很难在共识层上进行调整，并且可能无法动态调整。
由Tromp 提出的Cuckoo Cycle 是一种内存要求高的PoW。在这种PoW中，内存延迟而不是CPU使用成为了性能瓶颈。
难度调整
考虑到timewarp Attacks [timewarp]等情况的存在，以及比特币难度调整算法上算力突然变化期间停滞的情况，我们寻求了替代方法。
我们检查了DigiByte的DigiShield [digishield-1] [digishield-2]，MegaCoin的Kimoto Gravity Well [kimoto-1] [kimoto-2]和DarkCoin的Dark Gravity Wave [dgw]，作为我们协议的潜在难度调整算法。
由于不确定上线时将有多少算力力进入网络，以及在初始阶段新的PoW算法带来的不确定性，我们希望有一种对每个区块重新确定目标的方法。在算力突然进入或退出网络的情况下，DigiShield的性能似乎特别好。
鉴于各自协议中PoW函数的相似性，_Zcash_难度调整算法[zcash-1] [zcash-2] [zcash-3]的表述也具有特殊意义。 Zcash在DigiShield的变体上取得了成功，因此，我们协议的重定位或多或少是对Zcash算法的忠实实现。
UTXOs
由比特币开始的、基于UTXO的区块链，使用一系列_transaction output_将资金从一方转移到另一方。交易输出固有地在_block_内强制执行_order_交易。为了使我们的协议具有最大的安全性，交易的强制执行是必须的。
我们的域名系统需要类似链上智能合约的行为。它处理需要更新全局状态的输出。这是UTXO系统的非典型例子。但是，因此，我们要求这些操作以可预测的顺序发生。
这种顺序保留机制对于以可预测的方式维护转账_mempool_状态尤其必要。此模型可确保块的组装是快速而简单的过程。
历史命名
域名的历史非常有效，具有探索性，并且拥有许多技术高超的团队和项目。从一开始，DNS系统和SSL / CA一直都很优雅，并且从1990年代中期到现在，证书颁发机构系统的存在在成千上万的个人和组织的辛勤工作下证明了它的弹性。从那时起，进行了许多其他尝试来替换，升级或发布该系统。
域名加密货币的先驱包括Namecoin [namecoin-1]，ENS [ens-1] [ens-2]和Blockstack [blockstack-1]。
Namecoin的模型要求用户运行一个完全的验证节点，以便安全地解析域名。尽管Namecoin是第一个尝试为加密货币命名协议实现DNS网桥[namecoin-2]的加密货币项目，但该协议本身缺乏SPV。
Ethereum命名服务 [ens-3] [ens-4] [ens-5]自身有一些中心化的控制，因为ENS根[ens-6] [ens-7]由一组选定的签署者集中维护。与Namecoin一样，在ENS上没有简单的压缩证明方法。
在我们的三个前辈中，Blockstack最接近为域名提供易于验证的紧凑证明。
Blockstack _SNV_协议中的SPV域名验证首先涉及从_trusted node_检索状态根（也称为consensus hash），并从不可信节点安全地请求域名记录。不幸的是，无法验证所提供的名称记录是否为最新修订版[blockstack-2]。此外，从可信任节点请求状态根导致了与Namecoin类似的构造，其中必须运行一个完全验证的节点才能安全地检索名称数据。
所有之前的域名项目都以某种形式受到了全节点要求的阻碍，这可能是域名加密货币推广的主要障碍之一。为了在没有受信任的全节点的情况下允许SPV域名解析，域名的可证明性必须是协议的固有功能。
之前在替代根区方面也有相关的研究。备用根区域的最重要例子是OpenNIC [opennic]。它提出了一种通过未使用域名替代ICANN的备用命名空间的方案。这将单一的事实来源转换成了一种联邦模型，在该模型中，命名空间由不同实体控制，但是并不能消除对这些组织的信任。它不会创建附加安全性，因为会根据TLD将信任关系划分到单个根区域。
Moxie Marlinspike最初提出的Convergence Project [convergence]创建了一个证书固定和证明系统。公证人将证明端点的证书。该系统创建了一个加性联合信任模型。这对现有的单个CA信任模型进行了重大改进。但是，它没有没有规范的信任锚，这意味着两个人在互相反对或有缺陷的公证人中对正确证书的看法可能不同。
证书透明性[ct]提供了一种确保提交域名记录证明的方法，并显着提高了系统的安全性。它创建了一种故障追究和快速检测的方法。这主要是在CA失败的情况下的一种检测机制。
可证明的数据集
为了摆脱全节点要求，我们的协议要求使用一个认证数据结构（authenticated data structure）。特别是，我们需要一种可以有效地将键映射到值的数据结构。为了使我们的协议能够替代DNS根域，速度和大小是我们的首要考虑。
在对各种数据结构的基准测试中，我们发现尽管其中许多确实表现出色，但它们的证明大小过大，超过1-3 KB。这导致我们进行了进一步的研究。
我们的严格要求包括最小的存储空间，在固态硬盘上的出色性能，较小的证明体积和插入顺序不影响树的最终状态的“历史独立性”。后一种要求是每个再平衡数据结构天生缺乏的。
这些要求严重减少了我们的选择。我们特别检查了以太坊[ethereum]中使用的Merkelized Base-16 Trie [ept-1] [ept-2]，以及Google证书透明度[smt-2]中使用的稀疏默克尔树(Sparse Merkle Tree[smt-1](。
我们发现，虽然以太坊的base-16 trie性能出色，但证明的大小不适合我们的协议。存储需求也过多。
我们进一步发现Google的Sparse Merkle Tree在性能上不合适，因为每次插入都需要大量的数据库查找而没有大量的缓存，并且插入的每个项目都要经过几轮哈希处理。在我们的基准测试中，典型地插入5,000个叶子需要至少进行120万轮哈希，并且需要进行大量的数据库重新插入。
这项研究的结果是，我们认为在现有数据存储之上已实施或打算实施的经过身份验证的数据结构在可扩展性方面存在固有的缺陷。
FFMT (平面文件默克尔树)
我们设计了一个经过身份验证的数据结构，该结构与以太坊trie或稀疏默克尔树不同，旨在存储在平面文件中。通过使数据结构成为其自己的数据库实现，这完全消除了数据库查找的开销。
通过将默克尔化的数据结构存储在一系列仅允许附加的文件中，我们可以提供传统的数据库功能，例如快照，原子性和崩溃一致性。考虑到我们的要求，trie是作为备用数据结构的明显选择。
我们的FFMT的最初实现是一个简单的base-2 merkelized trie，其结构与Bram Cohen [merkleset]的早期工作有很多相似之处。
我们数据结构的后续迭代开始在内部节点上存储冲突的前缀位，从而得到了一个base-2 merkelized radix tree，类似于Amaury Séchet提出的Merklix Tree [merklix-1] [merklix-2]。
作为FFMT的骨干，我们建议使用上述两个数据结构之一。
我们最初的FFMT实现是以太坊的Base-16 Trie速度的50倍，是Google的稀疏Merkle Tree速度的500倍。我们还发现，证明大小与压缩的稀疏默克尔树证明相当，并且比base-16 trie证明小大约四倍。
FFMT的存储要求虽然比Sparse Merkle Tree的存储要求更陡峭，但仍然比以太坊的base-16 trie小得多。我们对插入做了基准测试，以每批次500向FFMT中插入5000万个300字节叶节点，并定期向树提供44,000个值。我们的基准测试是在高端但仍属消费级的笔记本电脑上运行的，其中包含Intel Core i7-7500U 2.70GHz和NVMe PCIe SSD。在接近峰值容量的情况下，具有500个值的插入本身平均大约需要100-150毫秒，而对于44,000个叶节点而言，平均的调试时间为400-600毫秒。注意，树的提交涉及对fsync（2）的调用。
这些插入和调试时间能够容纳在5分钟每个的区块中。我们添加了额外的故障保护功能，可将任何树更新限制为每个块最多600个，从而为我们提供了可预测的最坏情况插入复杂性。
描述
与任何类似trie的结构一样，FFMT沿着每个键向下的路径查找目标叶节点。
插入
我们从简单插入值“ a”和键“ 0000”开始。它成为树的根。
fig. 1
Map:
0000 = a
Tree:
a我们使用键“ 1100”插入值“ b”。树向下生长，现在深度为1。请注意，尽管密钥中有3个额外的位，但我们仅遍历过右边一次。
fig. 2
Map:
0000 = a
1100 = b
Tree:
R
/ \
/ \
a b下面是我们简化的FFMT如何处理键冲突的步骤，这部分很重要。我们在键“ 1101”处插入值“ c”。它与叶节点“ b”有三位是冲突的，叶节点“ b”的键为“ 1100”。为了在树中维护适当的密钥路径，我们将子树向下扩展，并添加null（或dead-end）节点（由x表示）作为内部节点的子节点。死节点由所有位都是零的标记哈希更具体地表示。
这我们类似Merklix版本的树不同，后者在单个父内部节点内存储位冲突。
fig. 3
Map:
0000 = a
1100 = b
1101 = c
Tree:
R
/ \
/ \
a /\
/ \
x /\
/ \
/\ x
/ \
b c我们在键“ 1000”处添加值“ d”。使用一个空节点不会产生开销。
fig. 4
Map:
0000 = a
1100 = b
1101 = c
1000 = d
Tree:
R
/ \
/ \
a /\
/ \
d /\
/ \
/\ x
/ \
b c在键“ 1001”处添加值“ e”会导致进一步增长。
fig. 5
Map:
0000 = a
1100 = b
1101 = c
1000 = d
1001 = e
Tree:
R
/ \
/ \
a /\
/ \
/ \
/ \
/ \
/\ /\
/ \ / \
/\ x /\ x
/ \ / \
d e b c移除
当子树中有dead-end节点时，删除似乎不简洁明了。所有先前执行的子树的生长必须被取消。
fig. 6
Map:
0000 = a
1100 = b
1101 = c
1000 = d
Tree:
R
/ \
/ \
a /\
/ \
d /\
/ \
/\ x
/ \
b c如果要从上面的树中删除叶节点d，则必须将其替换为dead-end节点。
删除叶节点d（我们必须用dead-end节点代替）：
fig. 7
Map:
0000 = a
1100 = b
1101 = c
Tree:
R
/ \
/ \
a /\
/ \
x /\
/ \
/\ x
/ \
b c移除叶节点c（缩小子树）
fig. 8
Map:
0000 = a
1100 = b
Tree:
R
/ \
/ \
a b移除叶节点b（a变成根节点）
fig. 9
Map:
0000 = a
Tree:
a随着最后的移除，我们回到了初始状态。
证明
我们的FFMT证明类似于标准的Merkle树证明，但有一些额外的警告。叶哈希的计算公式为：
HASH(0x00 || 256-bit-key || HASH(value))||表示并列
将完整密钥作为原像的一部分很重要。如果需要不存在的证明，则必须发送完整的原像，以证明该节点是包含具有冲突路径的其他密钥叶节点。如果密钥路径在dead-end节点之一处停止，则无需预映像。子树上的任何dead-end节点都可以压缩，因为它们是冗余的零散列。
如果要求我们用原始树来证明键“ 1110”的存在或不存在：
fig. 10
Map:
0000 = a
1100 = b
1101 = c
1000 = d
Tree:
R
/ \
/ \
a /\
/ \
d /\
/ \
/\ x
/ \
b c在这种情况下，键“ 1110”不存在，因此我们必须提供节点“ a”，“ d”，“ b”和“ c”的父哈希以及最后一个死节点“ x”的哈希。最后一个叶子节点是一个dead-end节点这一情况被证明是不存在的。
fig. 11
Proving non-existence for: 1110
Map:
0000 = a
1100 = b
1101 = c
1000 = d
Tree:
R
/ \
/ \
(a) /\
/ \
(d) /\
/ \
(/\) [x]
/ \
b c证明密钥’0100’不存在更加困难。节点“ a”的密钥为“ 0000”。在这种情况下，我们必须提供“ d”及其右同级的父节点的哈希值，以及“ a”及其原始键“ 0000”的哈希值。这使不存在的证明更大，因为我们必须提供完整的原像，从而证明节点“ a”确实是叶节点，但它具有与所请求的密钥不同的密钥。由于我们在计算叶哈希之前对值进行哈希处理，因此完整的原映像是64字节的恒定大小，而不是除完整值大小之外的键大小。
fig. 12
Proving non-existence for: 0100
Map:
0000 = a
1100 = b
1101 = c
1000 = d
Tree:
R
/ \
/ \
[a] (/\)
/ \
d /\
/ \
/\ x
/ \
b c我们只需要发送“ a”的原像（“ a”本身的值哈希及其键“ 0000”）。发送其散列将是冗余的32个字节。
存在证明相当简单。证明叶节点c（1101），我们将发送a和d的叶哈希值，带有一个dead-end节点，最后是c的同级对象：b。不会传输“ c”的叶哈希，仅传输其值（“ c”）。完整的原像在另一侧是已知的，这使我们能够计算HASH（0x00 || 1101 || HASH（“ c”））`来重新创建叶哈希。
fig. 13
Proving existence for: 1101 (c)
Map:
0000 = a
1100 = b
1101 = c
1000 = d
Tree:
R
/ \
/ \
(a) /\
/ \
(d) /\
/ \
/\ (x) <-- compressed
/ \
(b) [c]我们的目标是至少在最初的几年中，将证明大小保持在1 KB以下。
在树中有5000万个叶节点的情况下，树中任何给定键路径的平均深度应约为27或28（由于不可避免的键前缀冲突）。这导致证明大小略超过800字节，从而在我们前面提到的硬件上缩短了1-2ms的证明创建时间。
硬盘优化
由于节点数量众多，因此需要flat-file存储。对于诸如_LevelDB_之类的数据存储，数据库查找的数量将不堪重负。我们的FFMT比以太坊Base-16 Trie简单得多，因为我们只需要存储两个节点：内部节点和叶节点。
内部节点的存储如下：
fig. 14
struct internal_node_s {
uint8_t left_hash[32];
uint16_t left_file;
uint32_t left_position;
uint8_t right_hash[32];
uint16_t right_file;
uint32_t right_position;
} internal_node;Leaf nodes are stored as:
fig. 15
struct leaf_node_s {
uint8_t key[32];
uint16_t value_file;
uint32_t value_position;
uint16_t value_size;
} leaf_node;叶节点数据本身存储在“ value_file”中的“ value_position”中。
我们将树存储在一系列仅能添加的文件中，并有一个特别大的写入缓冲区，用于以最少的写操作批处理所有插入。
可以通过在每次委托后调用fsync（2）并将最佳的根哈希和文件位置插入数据库来实现父数据库的原子性。
因为我们的数据库是仅可添加的，所以传统的崩溃一致性也可以通过在每次提交时写入元数据根来实现。该元数据根包含一个指向最新根的指针，一个指向前一个元数据根的指针以及一个20字节的校验和。在启动时，数据库可以以相反的顺序解析文件，以找到最后一个完整状态。
压缩
FFMT数据库可以通过用户干预定期进行压缩，尽管这是一项相当昂贵的操作。在我们的基准测试中，每个数据库有14,000笔提交，每笔提交44,000个300字节叶节点（总共50,000,000个叶节点），数据库容量为49GB。可以压缩为大约20GB的存储空间。
碰撞攻击
毋庸置疑，攻击者最有可能制造密钥以产生位冲突。当前，比特币网络在区块哈希上产生72-80位的冲突。在最坏的情况下，这将在我们的树中深入挖掘72-80层，但是随着存储量的增加，散列的轮次远少于稀疏默克尔树。
稍作修改，我们最初的FFMT实现就可以转换为base-2 merkelized radix tree。我们发现，尽管Merklix树提供了更好的DoS保护，但实际上，与上述简化的base-2 trie相比，它似乎没有明显的性能或存储优势。
我们认为这些潜在的修改是空间效率和简单性之间的权衡。对树的基数树修改导致就树的实现和证明验证而言，复杂度略有增加。这些修改最不幸的方面是当存储在磁盘上时需要可变大小的节点。与简化的trie不同，基数树必须在每个内部节点上存储可变数量的前缀位。
我们希望观察这些树中的每一个在Handshake测试网的未来迭代中的行为，以便更好地确定适合我们协议的数据结构。
域名市场
与ENS类似，我们的命名协议旨在在允许注册之前确定名称的真实市场价值。特别是，我们的系统需要一个域名拍卖系统。为了防止price sniping，我们实施盲次拍卖，也称为Vickrey Auction。
在Vickrey拍卖中，参与者仅知道自己的出价。当有获胜者时，竞标会在拍卖结束时显示。胜者将支付第二高的出价，而不是他或她自己的出价。
William Vickrey [vickrey]首先描述了这种拍卖结构。Vickrey认为，简单的非盲拍卖的结果实际上与第二价盲拍相同。在公开竞标的拍卖中，竞标者将宣布其竞标价格，直到达到第二高价。此时，仅剩下一个愿意支付的竞标者，他或她最终支付了第二高的价格。我们同意Vickrey的分析，得出的结论是，如果我们要进行盲拍，使其成为第二价拍卖是合乎逻辑的。
但是，Vickrey Auction系统要求我们能够在UTXO集之上执行相当复杂的共识层智能合约行为。这种功能在基于UTXO的世界中很少存在。我们的初始实现试图在交易级别添加动态功能。这种方法难以管理。无论添加什么动态行为，都必须在输出级别上发生。
公约
_Bitcoin Covenants_最早由Maxwell [maxwell-1] [maxwell-2]探索，后来由Möser等人[covenants]正式描述，是一种智能合约形式，存在于基于UTXO的区块链（如比特币）上。 “公约”一词本身是指具有法律约束力的和约，其中一方同意将来避免或参与某些行动。从最基本的角度看，公约限制了货币在输出间转移的路径。金钱一旦进入公约，就被锁定在一条特定的道路上，在任何情况下都不得偏离该道路。有能力创建和签署交易的参与者必须根据公约的状态进行创建。
为了使比特币上的约定限制货币的流通，目前正在考虑几种截然不同的机制。 Bitcoin-NG [bitcoin-ng]以新的比特币脚本操作码OP_CHECKOUTPUTVERIFY的形式提出共识级别的约定。共识公约的广泛讨论的对应对象是密码公约，它是通过密码欺骗手段执行的。这种诡计形式多样，从ECDSA密钥恢复的新颖用法和特殊的交易签名哈希到SNARK的用法。
尽管由于可替代性和AML / KYC监管问题而从未在比特币上启用，但我们认为契约的核心思想是与UTXO集结合实施复杂智能合约的适当框架。
为我们的协议选择的方法与比特币-NG提出的共识级别公约最为相似。
我们构建的是一个深度共识级别的公约，与之前的提议不同，后者要求对Layer2区块链进行监视以实现动态行为，例如资产所有权。区块链本身可以维护这些资产的状态，而不是由Layer2节点确定这些细节。在我们的案例中，相关资产为域名。
输出结构
在基于UTXO的区块链中，典型的交易输出由_locking script_或_predicate_以及输出值组成。
典型的比特币输出结构：
fig. 16
struct output_s {
int64_t value;
uint8_t script[];
} output;“脚本”是锁定脚本；谓语是锁定赎回的资金。我们添加了一个名为covenant的新字段：
fig. 17
struct output_s {
int64_t value;
uint8_t script[];
struct covenant_s {
uint8_t action;
uint8_t arguments[][];
} covenant;
} output;资金仍然可以被谓词以同样方式锁定。但是，当资金汇入公约时，它限制了可以兑现的产出。
由于仅在共识级别规定了公约行为，因此与其他公约提议相比，此构造应可抵抗可替代性攻击。
拍卖系统
使用我们的通用共识级别公约系统，我们能够在区块链层上实施几乎所有类型的智能合约。
在普通的UTXO系统中，输入和输出的顺序几乎没有意义。使用公约时，我们会强制执行输入和输出的位置要求。
在区块链本身的实现中，我们的契约行为由共识代码规定。我们的系统足够通用，以后可以将新的契约类型“软分叉”到协议中。
我们规定了一个称为“ BID”的契约类型，该契约将一个竞标输入到系统中，并与一个域名及其相应的输出关联。投标本身带有一些参数：参与者正在投标的域名和盲值。盲值是参与者的出价与256位随机数关联的摘要。
与输出本身相关的值必须大于或等于出价值（尽管区块链无法初步验证此值）。一旦输入“ BID”公约，该值可能无法再被赎回为正常输出。与此输出关联的值称为锁定值（lockup value）。
进入公开竞标的第一个参与者启动“竞标阶段”，之后其他参与者可以自由加入竞标。
fig. 18
TX #1 (txid=f3ce)
Input #0 | Output #0
... | covenant_type=BID
| covenant_items={name, blind}
| address=0d1a
| value=15投标期结束后，区块链会自动启动一个“揭示期”。现在，在投标期内输入投标的任何参与者都有有限的时间来公开其投标。这是通过在“揭示”公约中揭示他们盲拍价格的完整原像来实现的。
fig. 19
TX #2 (txid=c1d3)
Input #0 | Output #0
prev_txid=f3ce | covenant_type=REVEAL
prev_index=0 | covenant_items={name, nonce}
| address=0d1a
| value=5
|
| Output #1
| covenant_type=NONE
| covenant_items={}
| address=c0a8
| value=10
|完整的原像包括参与者的256位随机数（直到这个时间点一直保密），以及他们的出价。此时，“ 揭示”输出的值必须等于参与者的出价值。锁定值的剩余部分可以视为找零。在图19中，出价的值为5个代币，而15个代币的锁定值成功隐藏了出价的真实价值。该参与者能够立即兑换10个代币作为找零。
揭露期结束后，将选择获胜者。获胜者可以将其“ 揭示”输出兑换为“ 注册”公约。 “ 注册”输出的值必须等于第二高的出价，或者在只有一个出价的情况下，是参与者自己的出价值。我们将此值称为name value。与REVEAL公约类似，其剩余的投标价值可以视为找零。
fig. 20
TX #3 (txid=a7be)
Input #0 | Output #0
prev_txid=c1d3 | covenant_type=REGISTER
prev_index=0 | covenant_items={name, name_data}
| address=0d1a
| value=3
|
| Output #1
| covenant_type=NONE
| covenant_items={}
| address=b1c9
| value=2
|一旦输入“ REGISTER”公约，名称值就无法正常地赎回，并且不能用于价值转移或常规付款。它由于无法离开公约的路径而被系统有效地烧掉了。
但是，如果参与者输了，他们的资金可以通过“赎回”输出退出公约路径。
fig. 21
TX #3 (txid=c0c1)
Input #0 | Output #0
prev_txid=c1d3 | covenant_type=REDEEM
prev_index=0 | covenant_items={name}
| address=0d1a
| value=5REGISTER输出允许第二个参数，称为name data。按照共识标准，name data是512字节的Blob，没有一定的格式。根据政策标准，其格式应类似于DNS信息格式[rfc1035]。
fig. 22
TX #4 (txid=cc1e)
Input #0 | Output #0
prev_txid=a7be | covenant_type=UPDATE
prev_index=0 | covenant_items={name, [name_data], block_hash}
| address=0d1a
| value=3注册域名后，将启动一年期的计时，然后需要续订域名。域名数据的更新是通过“ UPDATE”公约动作实现的。
UPDATE公约类似于REGISTER公约，但是它接受第三个参数区块哈希_(block hash)。为了刷新续订计数器，域名的所有者必须提供最近的区块哈希（过去6个月内在主链上发生的一次哈希）。我们要求这样做是为了防止所有者预先签署价值数千年的续订。续约应证明拥有者仍拥有他或她的私钥。
在整个过程中，地址必须与原始出价输出中提供的地址相同。如果需要更改所有权，则必须将输出赎回为“转让”盟约。 “ TRANSFER”约定的参数要求所有者在48小时的延迟后承诺将其打算将所有权更改为的地址。经过48个小时的封锁后，所有者可以将“ TRANSFER”输出转换为“ FINALIZE”输出。
fig. 23
TX #5 (txid=0b17)
Input #0 | Output #0
prev_txid=cc1e | covenant_type=TRANSFER
prev_index=0 | covenant_items={name, address=fe13}
| address=0d1a
| value=3fig. 24
TX #6 (txid=11a3)
Input #0 | Output #0
prev_txid=0b17 | covenant_type=FINALIZE
prev_index=0 | covenant_items={name, name_data}
| address=fe13
| value=3前面提到的48小时延迟是必要的，这样可以防止域名盗窃。在延迟期间，所有者可以将TRANSFER输出转换为REVOKE输出。 REVOKE输出使该域名的输出永远无法使用，并将该域名备份以进行投标。
fig. 25
TX #6 (txid=d1da)
Input #0 | Output #0
prev_txid=0b17 | covenant_type=REVOKE
prev_index=0 | covenant_items={name}
| address=0d1a
| value=3为了在整个过程中提高安全性，我们定义了一个新的脚本操作码：OP_PUSHTYPETOSTACK。这个特定的操作码利用_transaction introspection_来将_next_输出的约定类型推入脚本执行堆栈。这允许名称所有者分配_hot key_和cold key。前者用于更新域名数据，而后者仅用于传输和撤销。
利用此功能的示例脚本可能看起来类似于图26。
fig. 26
OP_7 OP_PUSHTYPETOSTACK OP_GREATERTHANOREQUAL OP_IF [cold-key] OP_ELSE [hot-key] OP_ENDIF OP_CHECKSIG
例如，还可以通过要求转账和撤销以要求来自多方的签名来使用更高级的脚本代码。
参与者可以将此脚本分配给支付给脚本的哈希地址，并在输入初始出价时使用它，或者稍后将其域名传递给它。
我们打算让脚本成为增强名称所有权安全性的主要机制。与之相对地，我们打算将REVOKE输出作为域名所有者的最后手段。它的存在主要是为了使以盈利为目的的域名盗窃几乎不可能。
委托
域名数据会定期提交给我们的身份验证树。由于我们的树是由一系列仅可添加文件实现的，因此需要一个委托间隔来防止历史记录膨胀，否则可能需要软件的用户定期压缩其历史记录。
域名和域名数据每天平均六次间隔（由blockheight定义）每天四次批量插入树中。这意味着在实践中，区块链上任何资源的“生存时间”至少为六个小时。
上下文优化
在加密货币实现中，存在_contextual_和_non-contextual_验证的概念。非上下文验证功能在执行任何资源密集型代码（例如数据库查找或椭圆曲线操作）之前，对交易数据执行基本的完整性检查。这样做是为了逻辑分离以及为防止拒绝服务而采取的措施。
相反，仅在大多数网络状态（例如UTXO）易于使用时才执行上下文验证。
在我们协议的实施中，我们发现将区块链验证分为三个逻辑类别更容易：非上下文，上下文和超上下文。
我们将_super-contextual_验证定义为仅在_global state_可用时才执行的验证函数。我们的全局状态是拍卖和域名的状态。尽管UTXO已本地化为特定交易，但任何交易都可以全局访问拍卖和域名状态。
我们对公约类型的规定是专门为使超级上下文验证更容易、更高效而设计的。
我们的系统需要处理许多交易锁定，这些交易锁定是由交易中的公约强制执行的。我们遇到的困难的一个特殊示例是在事务内存池的实现中发现的一些极端情况。由于区块链重组会导致主链高度变化，因此重组有可能使我们的内存池中的数百甚至数千笔交易无效。比特币在处理交易锁定时间和从coinbase支出时也存在这些问题（必须具有100个区块的成熟时间）。这些边缘情况在我们的系统中更为严重，并且每当发生重组时，最初都需要对整个内存池进行完全重新验证。
通常，加密货币内存池实现在内存中不保存任何UTXO，仅针对组装区块所需的状态进行优化。通过对我们指定的公约类型设计一些冗余数据，并通过将超级上下文验证与上下文验证分离，我们可以优化此过程。
为了验证与公约有关的锁定时间，我们的实现不需要访问上下文信息（例如UTXO）。它仅需要访问全局状态和非上下文数据，例如事务本身的输出。
强化的逻辑分离被精心设计过，除其他外，使我们避免了必须存储专门用于内存池的内存中UTXO缓存。
我们认为，在公约参数向量中包含少量冗余数据以及一些冗余公约类型，也有助于实现钱包，尤其是SPV钱包。
域名架构
互联网的域名系统是DNS [rfc1035]。 DNS当前以多层模型运行。操作系统通常公开stub解析器。stub解析器没有递归功能，只能将简单的DNS消息查询发送到远程域名服务器。它们旨在指向递归服务器。递归服务器代表stub解析器执行完整的DNS迭代，方法是遍历每个_zone_的名称服务器，直到收到_answer_为止。区域的名称服务器称为“ 授权服务器”。授权服务器既可以提供自己的记录，又可以将_referrals_发送到child zone。
递归服务器通常是公共的，并由网络服务提供商或其他组织（例如Google，Cloudflare或OpenDNS）维护。
当前，递归DNS解析器（例如Google的Public DNS [google]）命中了由各个实体维护的许多根服务器[root]。这些根服务器服务于root zone。根区域是顶级域（TLD）的集合。解析这些TLD所需的信息存储在ICANN分支机构IANA [iana]分发和维护的根区域文件中。ICANN目前充当根区域文件中允许输入哪些域的守门人。
区域文件在其最通用的定义中，可以认为是一个数据库，其中包含在给定的_zone_中提供域名记录所需的所有信息。在根区域的情况下，域名是诸如“ com”，“ net”和“ org”之类的TLD，并且区域文件本身实际上是RFC 1035 [rfc1035]表达形式中的纯文本文件[internic]。
可证明
用于证明DNS的当前方法称为DNSSEC [dnssec]。 DNSSEC在每个DNS消息中都包含DNS资源记录的加密签名。这样可以防止攻击者在过程中更改任何DNS记录。
为了避免将每个域名的公共密钥分发给每个DNS解析器，从根区域开始将信任链_验证为信任锚。这意味着IANA的公钥必须由该网络的所有参与者存储，并且还必须对root密钥签名keys [anchors]绝不受到损害[签名]的观念加以限制。此外，为了使域被认为是安全的，IANA仅为非拍卖名称注册充当了安全性的守护者，对密钥进行签名以将其添加到信任链中。
Handshake 架构
Handshake域名协议与其之前的协议的不同之处在于，它在共识层没有_namespacing_或子域的概念。当前，其目的不是替换所有DNS，而是替换根区域文件和根服务器。
我们的目标是以去中心化的方式维护自己的根区域文件，从而使根区域不可审查，无需许可，并且没有诸如ICANN和证书颁发机构之类的中心化的守护者。在我们的协议中，网络上的每个_full node_对等方都充当根服务器，为根区域文件提供_provable_的版本。我们的区块链本质上是一个更大但分布式的区域文件，无需许可，任何参与者都有权在其中添加条目。
PoW作为信任锚
工作量证明是一个有趣的机制，因为它是为数不多的完全无法被中间人攻击的机制之一。因此，工作量证明的区块链能够充当我们可能需要证明的任何事物的去中心化信任锚。在我们的案例中，我们可以将其用作一种“许可”机制来“注销”子DNS密钥。
DNS当前具有将子区域的DNS密钥的指纹存储在其父区域中的功能。由于协议中的根区域是区块链，因此协议本身可以充当这些密钥的信任锚，从而使任何人不仅可以在区块链上证明其域名，还可以证明他们可能拥有的任何子域。这涉及将一个人的主要指纹简单地提交到区块链上进行记录。
甚至在通过常规DNS在每个区域对信任链进行了验证之后，该系统的用户最终仍会获得与区块链类似的安全性。这是因为信任锚实际上是一个区块链。
兼容性
与其他域名项目相反，我们的目标是使用DNS，而不是反对DNS。我们打算透明地在去中心化系统上与IANA和ICANN使用的协议兼容，同时要求大多数用户零干预。这些协议可以随时间更新，并且Handshake区块链可以与新的DNS协议向前兼容。
DNS是非常成熟的互联网体系结构。我们已经构建了一些所需的工具。例如，已经可以将SSH指纹存储在DNS [sshfp]中。 OpenSSH [openssh]当前支持此功能。这样一来，您就可以以去中心化的方式验证SSH指纹，而无需在Handshake守护程序之外安装任何其他软件。
DNS还具有通过将SubjectPublicKeyInfo的哈希存储在DNS资源记录中来验证SSL / TLS证书的功能。使用此功能，人们可以在本地运行递归DNS解析器，其根提示指向区块链。如果是这种情况，只要存在有效的DNSSEC链，就没有理由不信任自签名证书。
我们相信，将这些技术一起使用可以消除对证书颁发机构的需求。
实施
我们的共识协议可用作ICANN根域服务器的合适替代品。当然，替代ICANN根域的方法不是一个新主意。以前，Open Root Server网络或ORSN [orsn]曾探索过这种途径。
为了透明地替换根区域，递归解析器必须指向一个权威的域名服务器，该服务器提供提交给区块链的记录，而不是ICANN的根区域文件。这是一个很难解决的问题，因为当前几乎没有任何消费类设备附带在本地运行的递归解析器。
更糟糕的是，DNS是一个很难使用的协议。当前仅存在少数完整的DNS实现。鉴于DNS参考实现（ISC的BIND [bind]）已有34年的代码维护历史，因此也很难使用。这使我们找到了替代的DNS实现，最著名的是LDNS [ldns]和Unbound [unbound]，它们都是由NLnetLabs [nlnetlabs]创作的。由于缺少可用的选项，我们在整个研究过程中还创建了自己的完整DNS实施[bns]。
网络引导
为了引导网络，根据共识规则，ICANN现有区域文件中的所有条目都被预留了。 Alexa排名前100,000 [alexa]域名列表中的名称也被保留，以进一步包含现有的利益相关者（具有重复数据删除功能，并且常用单词的名称减少到80,000个以上）。通过选择第一个域名标签，将后者转换为顶级域名。
这些保留域名的所有者可以绕过拍卖过程直接在区块链上声明它们。我们旨在以无许可的方式将现有的域名持有人迁移到Handshake区块链。为此，我们提出DNSSEC所有权证明。
尽管DNSSEC本身旨在缓解中间人攻击，但我们发现，通过一些修改，DNSSEC证明可以用作域名所有权的安全证明。
较小的域名可能不可靠，因为尚不清楚它们是否是名称的合法所有者。我们的项目有一个抢注阶段，所有者可以在其中声明自己的域名。
DNSSEC所有权证明
我们建议将DNSSEC所有权证明作为DNSSEC证明的更为严格的子集，因为它们不允许使用CNAME glue或通配符。此外，每个标签都必须使用典型的DS-to-DNSKEY设置进行推荐，并通过区域切割来分隔。检索并组合所有区域引用，以生成最终证明。
这些证明必须源于ICANN的key-signing keys（KSK）直到目标区域中的最终ZSK。最终的zone-signing key（ZSK）必须对TXT记录进行签名，该记录将提交给该域名在区块链上的所需地址。该证明将广播到对等网络，并由矿工包含在一个区块的coinbase交易中。共识规则规定，矿工必须为关联的证明创建输出，从而将域名授予承诺的地址。
根据共识规则，将根据ICANN现有的信任锚（KSK-2010和KSK-2017）对证据进行验证。尽管当前未使用KSK-2017，但ICANN确实在去年（2017年）发布了密钥。从一开始，这便使我们能够将其包含在区块链的共识规则中。
仅依靠信任锚进行验证会生成大量证据（通常介于3到10 KB之间），但是，此方法允许缺少现有DNSSEC设置的名称持有人将来升级并声明其域名。
我们将DNSSEC声明系统设计为在区块链上总共可运行4年。
安全考虑
一段时间以来，由于ICANN对用于所有权证明的根信任锚的控制，因此它将间接成为该系统的有限仲裁者。这引起了潜在的担忧。
在分析根区域文件的过程中，我们发现大量域将SHA1用于RSA签名和密钥指纹。不幸的是，SHA1的防碰撞安全性最近遭到破坏[破碎]。即使对于现有的DNSSEC设置，我们的共识规则必须禁止使用不安全的算法（例如SHA1）。
结果，为了使RSA-SHA1名称持有者在Handshake区块链上声明其域名，他们必须在创建所有权证明之前将其密名密钥至少升级到RSA-SHA256。不幸的是，要做到这一点，域名持有人必须联系其父区并要求他们签署新秘钥。
考虑到这一点，我们必须考虑ICANN可能不合作并拒绝为现有域名持有人签署更高安全性密钥的可能性。如果发生这种情况，则RSA-SHA1根区域名称在区块链上将不可兑换。为了缓解这种攻击，我们的DNSSEC所有权验证算法将RSA-SHA1密钥隐式升级为RSA-SHA256，从而允许保留的名称持有者使用不同的算法字段（RSA-SHA256或RSA-SHA512）在其自己的区域中发布相同的RSA密钥。这样，在创建必要的所有权证明时，域名持有人就可以绕过ICANN的根区域文件更新过程。
除了SHA1漏洞外，我们还发现一些主要的根域名持有人在其RSA区域签名密钥中使用1024位模。我们相信，这是使用dnssec-keygen生成密钥时BIND默认行为的结果。长期以来，人们一直认为RSA-1024是不安全的，尽管从未执行过1024位模数的实际分解，但我们认为这是一个弱点，特别是对于经济激励型系统。
如果我们通过共识规则考虑要求2048位模数或更高的模数，那么我们发现自己处于SHA1漏洞的类似情况：名称持有者可能会受到不合作的父级区域维护者的摆布。
作为对对不合作实体攻击的最终故障保护，我们允许使用RSA-1024并提供一个由版本位激活的软分叉。该软分叉负责通过要求所有权证明至少具有2048位模来加强共识性RSA实现。如果1024位RSA被破坏，我们将寻求矿工的共识来解决该问题。这允许区块链支持RSA-1024，直到证明对其有实际攻击为止。
作为激活此fork的必要效果，所有最初用RSA-1024赎回的名称都将被立即撤消，直到使用更强的密钥再次赎回为止。这种构造要求我们为使用RSA-1024赎回的名称在交易时间上设置6个月的锁定时间。
我们考虑的最后风险（也许是最主要的风险）是ICANN的关键撤销流程。 ICANN声明的KSK-2017过渡计划涉及在KSK-2010上设置REVOKE位。不幸的是，发布已撤销的密钥并不能真正使旧状态无效。聪明的攻击者可以保留吊销密钥记录和签名，仅服务于较早的状态。因此，DNSSEC的撤销机制对我们的区块链几乎毫无用处。
我们主要担心的是，ICANN可能会在某个时候决定通过发布其相应的私钥来撤销KSK-2010。为解决此问题，可以在发布单独的证明以证明KSK-2017现在处于活动状态后，将最终共识规则添加到disable KSK-2010。该证明将包括ICANN的DNSKEY RRset的KSK-2017签名。我们坚信，在过渡到KSK-2017之前，ICANN将无法从道德上证明发布KSK-2010的合理性。因此，我们发现这种缓解措施可为此类攻击提供足够的安全性。
此外，在极端情况下，社区可以建立硬分叉，以充分协商一致地手动分配版权所有者的姓名。
SNSSEC实施的经济激励
DNSSEC的支持相当少，只有极少数的顶级域名和第二级域名完全支持它[nameandshame]。那些确实实现DNSSEC的应用通常不安全（通过SHA1或RSA-1024）。
我们发现这是采用基于验证递归解析器的安全性的系统的主要障碍。为了激励安全DNSSEC的正确实施，只能通过正确的DNSSEC设置在区块链上兑换保留名称。我们希望这可以为现有的根区域和Alexa前100,000名用户中的绝大部分增加安全性。
为了进一步增加奖励，区块链将代币奖励附加到任何保留域名的兑换上。域名中附加的价值将根据区域中存在多少个子区域进行加权。
SPV域名解析
我们的SPV实现的体系结构包含以下4个组件：
1.一个用于同步区块头和验证域名树证明的p2p层。
2.一个权威的域名服务器，可将链上资源转换为DNS响应，具体取决于请求。该域名服务器的行为就像是根服务器，服务区域.。
3.一个递归服务器，将其根提示和信任锚设置为其自身的权威根服务器，而不是ICANN的根服务器。
4.第二个非递归解析器，位于权威层并充当ICANN系统的后备。这适用于以下情况：保留的尚未被声明的顶级域名。只有从别的节点收到合适的域名缺少证明时才会通过ICANN的系统进行解析。
fig. 27
+-------------+ +------------------+ +----------------------+
| OS Resolver | --> | Recursive Server | --> | Authoritative Server | --+
+-------------+ +------------------+ +----------------------+ |
|
+----------------------------------------------------------------------+
|
| +--------------------+ +---------------+ +-------------+
+--> | Peer-to-peer Layer | --> | Proof Request | --> | Remote Peer |
+--------------------+ +---------------+ +-------------+fig. 28
+-------------+ +----------------+ +--------------------+
| Remote Peer | --> | Proof Response | --> | Peer-to-peer Layer | --+
+-------------+ +----------------+ +--------------------+ |
|
+------------------------------------------------------------------+
|
| +----------------------+ +------------------+ +-------------+
+--> | Authoritative Server | --> | Recursive Server | --> | OS Resolver |
+----------------------+ +------------------+ +-------------+默认情况下，我们的p2p层是使用噪声协议[noise]握手（类似于闪电网络 [lightning]使用的握手）进行端到端加密的。为了进一步提高这一层的隐私性，只允许代表他人解析名称的对等方查看顶级域（或更确切地说，域名的哈希）。
由于点对点加密，此体系结构的唯一纯文本方面位于遍历子区域的递归解析器中。为了在这里提高隐私性，递归解析器可以使用QNAME最小化 [qname]。令人惊讶的是，QNAME的最小化是不遍历的，因为并非每个域名标签都来自区域切割，这使得如何“欺骗”权威服务器以发送适当的名称服务器引用变得不明显。幸运的是，像Unbound这样的现代验证解析器可以很好地实现此功能。
尽管子区域未加密，但仍可以通过DNSSEC对其进行验证。由于ICANN根区域已被区块链取代，因此递归解析器还必须更改其信任锚。当前，递归解析器将其信任锚设置到IANA的两个DNSKEY（KSK），这两个DNSKEY签名根区域的区域签名密钥_（ZSK）。为了与现有解析程序兼容，我们建议SPV节点的权威域名服务器使用其私有密钥为所有人所知的静态信任锚。
当然，由于工作量证明充当安全机制，而不是数字签名，因此不再需要在根区域签名。但是，必须在根目录中包括DNSSEC签名，以使现有的DNS实现能够考虑完整的信任链。使用公共可知的私钥，符合标准的SPV节点可以在提供响应时实时创建适当的RRSIG记录。可以缓存这些响应，以避免重复昂贵的签名操作。
虽然可以创建虚拟RRSIG来欺骗现有的递归解析器来验证完整的信任链，但是NX证明提出了另一项挑战。当前DNS中最现代的不存在证明验证是NSEC3 [nsec3]。 NX证明通过维护子区域的排序链接列表来运行。生成NX证明时，权威服务器以签名的DNS记录进行响应，该记录显示请求的子区域应该在列表中的位置，从而证明其不存在。不幸的是，NSEC3通过使用不安全的SHA1散列标签来混淆子区域。如果NSEC3使用更现代的哈希函数，则在整个根节点上遍历我们的名称FFMT可以在根区域生成DNS NX证明。不幸的是，SPV解析器由于缺乏随意搜索树的能力而仍然难以生成此虚拟证明。
要解决此难题，我们生成使用空区域的dummy NSEC3证明。
根区回退
由于并非所有保留的根域名都会立即被域名所有者声明，因此，我们提出了两种最终透明过渡到新系统的解决方案：_Hardcoded Fallback_和Dynamic Fallback。
硬编码回退涉及将现有ICANN区域文件硬编码到SPV软件中。当权威服务器收到预先存在的TLD的缺席证明时，将检查硬编码后备的记录，并作为DNS响应返回。
动态回退类似，但是涉及到查询ICANN的根服务器并根据其信任锚验证响应。这样可以提供更好的活动性，但可以赋予中央权力机构更大的权力。
在这两种构造中，一旦适当的所有者声明了预先保留的名称，该软件将透明地开始遵循区块链，而不是遵循硬编码记录或ICANN的记录。
库集成
我们提供了库集成，以替代SPV解析器或完整节点。这消除了普通用户安装额外软件的需要，而将责任交给了软件开发人员。
我们认为这是我们协议的“最低安全模式”。但是，尽管它比本地递归解析器模型更中心化，但是它比DNS的当前状态更加安全且没有权限。
————
包括Mac OSX在内的基于Unix的操作系统将其操作系统存根解析器配置为使用/ etc / resolv.conf中列出的域名服务器。
resolv.conf格式指向操作系统的存根解析器要使用的递归服务器列表。在调用gethostbyname（3）和getaddrinfo（3）期间会调用存根解析器。
我们提出了一个新的标准操作系统配置文件hns.conf，位于Unix上的/etc/hns.conf中，而在Windows上则位于％SystemRoot \ Drivers \ etc \ hns.conf中。此配置文件让人想起标准的resolv.conf，但是，其唯一目的是列出域名服务器，而其他选项只是从常规resolv.conf解析中继承而来。
为了使用协议的解析器，我们需要为每个域名服务器列表使用33字节压缩的ECDSA公钥。该密钥将用于对签名的DNS消息进行SIG（0） [sig0]验证。 DNSSEC当前不足以实现此目的，因为它仅签名DNS响应的个人记录。由于TSIG [tsig]需要对称密钥，因此也不足够。我们的SIG（0）用法将常规SIG记录作为伪节添加到DNS消息的其他节中。该记录在ECDSA secp256k1曲线上对所有数据进行签名。
运行本地SPV解析器的用户可以将其hns.conf指向127.0.0.1（无需SIG（0）验证）。如果不存在，则hns.conf解析器应回退到各自的社区成员运行的硬编码递归服务器的列表。这些条目将与已知的ECDSA公钥配对。
理想情况下，应通过Anycast [anycast]网络路由对公共递归服务器的请求，以提供与Google或Cloudflare的公共DNS相当的速度。
必须执行此设置，以允许所有用户使用新的根区域。如果某些用户不愿意运行SPV节点，我们的系统将退回到更中心化的模型。请注意，该中心化模型仍在当前ICANN根域上进行了许多改进。根区域仍然是未经许可的，并且数据仍在进行身份验证（现在的存根解析器中不存在这种情况）。
最终的集成库由一个简单的存根解析器组成，它可以了解我们的新hns.conf格式，并能够验证SIG（0）记录。
集成
我们深信，为了广泛采用，SPV守护程序和集成库必须是无运行时的，并且必须使用可移植的C语言编写。如果要在嵌入式和IoT设备上使用此协议，则集成库尤其必要。
未来方向
DNS迭代证明
为了消除对SPV的本地递归解析器的要求，假设DNS遍历证明是有用的。这种证明将涉及汇总每个区域的粘合记录、DNSSEC签名和密钥，从而产生最终的半紧凑证明。这将允许客户端将递归安全地卸载到不受信任的服务器。此构造类似于我们的DNSSEC所有权证明，它也是DNS引用的汇总证明。
与本地递归解析器相比，由于签名聚合，这将节省CPU时间和带宽。通过避免对消息高速缓存的需要，它将进一步减少存储器的使用。这将大大降低SPV解析程序的复杂性，因为它们也不再需要维护递归或权威的根服务器。
区域复制与DNS曲线
丹尼尔·伯恩斯坦（Daniel Bernstein）的DNSCurve [dnscurve]是DNS的扩展，它执行ECDH并在交换消息之前与权威的名称服务器建立流密码。它与DNS向后兼容，因为身份密钥在常规NS记录中被编码为base32标签。
不幸的是，DNSCurve的采用率很小。如前所述，我们名称解析协议的唯一未加密部分是在通过权威服务器进行常规DNS迭代期间发生的。
如果我们设想对等网络，其中对等方可以充当区域的“代理”，则他们将能够在现有区域的名称服务器之上将DNSCurve支持分层为公共服务。然后，他们可以将自己宣传为对等层上特定区域的启用DNSCurve的代理。
这引发了许多安全性和激励性问题，但是我们认为这是将来值得追求的想法。
子区域
将来，并非所有子区域都可能是标准DNS服务器。在该系统中，名称的链上资源可以使用标准NS记录作为指向plasma子链的指针来引用解析程序。像DNS一样，这构造了一个多层系统，名称的所有者可以实例化他或她自己的子区块链。
该子区块链充当DNS区域。通过经济激励措施作为该子区域的固有属性，域名所有者可以出售其顶级域名内的子域名。
随着在以太坊上研究和开发Plasma，也有可能构建与以太坊链兼容的子区域。Plasma可以验证并提交给第三方链，并具有紧凑的头。另外，使用类似btcrelay- [btcrelay]的构造，并使用验证程序强制创建新块，可以对其他链中的Handshake状态进行外部验证。
重组安全性与域名过期
强烈建议客户端实施程序验证链是否进行了深度重组。这可以通过让第三方证明来实现，到目前的块高是无可争议的。这与现有的CA基础架构在本质上是不同的，因为安全性是附加的，每个人都在证明相同的信息。任何一方都可以提供此信息和证明（甚至可以在链上发布/证明）。
将来，通过社区共识变可能变成具有类似于Ethereum中提出的Casper Finality Gadget [casper-finality-gadget]的混合权益证明结构，区块通过绑定代币进行提交。
强烈建议证书锁定[certpinning]用于客户端和用户代理关联身份。这可以通过将名称所有者的脚本哈希固定到名称本身来实现，因此，当所有权记录更改时，用户必须批准此更改。
利益所有者
Handshake机制背后的主要功能是最大程度地向最相关的利益相关者分配令牌、代币或不可替代资产的所有权。为了做出有效的改变，必须承认所有相关的现有和未来利益相关者。通过最大化正确的利益相关者分配，可以最大化变更的有效性。就Handshake而言，它是从中心化的证书颁发机构和命名向去中心化的基础结构转变。
激励所有利益相关者以自身利益的方式促进项目的发展和增长。为了做到这一点，许多人需要代币的某些所有权或价值，以便建立足够的动力。
这些分配是本文提议的分配，Handshake社区将最终确定主网中的最终分配。
创世区块共铸造了 1,360,000,000 枚代币，分发给利益相关者：
主网启动前的开发 – 7.5%
这部分用于资助参与此项目创建的各个利益相关者之间的开发。这些代币用于在主网启动之前的工作费用，并且是开发资金的唯一来源。存在一个迭代的针锋相对的博弈，在许多模拟此模型的项目和开发团队中，会出于自利的目的给出价值（“我付出的越多，我获得的价值就越多”）。
财务贡献者和定价 – 7.5%
总共向购买者分配了$ 10,200,00 ，以对代币的初始价值进行定价，占代币总供应量的7.5％，初始代币供应的总价值为136,000,000美元。
所筹集的资金100％用于非营利组织和FOSS项目，以及FOSS社区（如黑客空间）。实际上，这是对美元定价的单向无损“燃烧证明”。
代币购买者的角色对于项目的发展至关重要，它是最初的利益相关者。通过将资金分配给专门从事加密货币和去中心化互联网生态系统的风险投资家和代币基金，已经安排了购买者以最大程度地发挥有效的变化。这些购买者中的许多人已经有效地突破整个行业，并参与了互联网服务的大规模增长（有些甚至跨代发展）。
这些参与者的存在对令牌定价是必要和基础的，因为分配需要确定真实价值（在令牌定价中销售总初始供应量的1％是不可信的）。此外，销售已尽可能接近发布/声明时间。
仿照此机制的其他项目可能需要更多的资金来资助开发或要求更多的发行前的开发资金。这可能导致没有单向的“燃烧证明”，而是使用资本来为项目的开发提供资金。
为了分发代币，为代币定价是必须的，因为代币在分发过程中需要确认价值。尽管表面上看，在没有这种机制的情况下启动项目和部署区块链是理想的选择，但可能缺乏足够的协调和对价值的事先期望。高信誉的风险投资的作用是提供一种增味剂功能，为潜在的具有经济和社会价值的项目提供信号和Schelling点。这些实体在当前生态系统中是重要的利益相关者，项目选择和管理的持续游戏可能会最终持续下去（“把钱放在嘴里”）。
自由开源软件开发者 – 68%
自由开源社区是项目启动时的主要代币持有者。分发这些代币无需任何工作。由于免费和开放源代码软件是在没有任何直接财务回报的情况下发布代码，类似的，Handshake是在没有任何代码回报期望的情况下放弃财务价值的。
如果社区感兴趣，并且Handshake在将来变得可行，则个人有可能（但没有任何义务，无论是合同义务还是隐含的）有动机将功能集成到自己的软件中。
域名所有者 – 10%
Handshake区块链将在区块链上提交足够安全的DNSSEC证明后，将所有TLD分配给合法持有者。此外，使用了Alexa前100,000个域并将其过滤（重复，通用词典名称）为80,000多个非通用名称，可以通过DNSSEC证明作为TLD。这样，只要及时声明所有权，所有当前现有的域都可以使用Handshake，因为TLD的所有者可以在Handshake中声明所有TLD。
除了与现有域名系统的向后兼容性之外，还提供了代币，以鼓励域名持有者采用。这为在Handshake上注册域名提供了动力。索赔期后无人认领的代币将被焚毁。
在域名的TLD DNSSEC记录提供安全的DNSSEC记录（不是SHA1密钥哈希）之前，某些域名可能无法主张所有权，并且在代币成熟并可以使用之前可能会有一个延迟期。
2.5％ 平均分配给TLD。
2.5% 分配给Alexa前100名域名
2.5% 分配给Handshake保留域名（超过80,000个域名）。这些域名能够在Handshake中声明为顶级域名。
CA/域名公司和其他区块链项目 – 5%
以下公司和项目正在被提供Handshake代币。在撰写本文时，他们尚未确认或接受代币。如果代币未被领取或接受，这些代币不会再分配，并会被燃烧掉。如果在Handshake主网启动之前遭到拒绝，则这些分配可能会在启动之前更改。这些分配中的某些分配仅可通过将其域的DNSSEC证明提交给区块链以索取代币来赎回。这些实体中的任何一个都没有合同以任何方式帮助Handshake项目，并且明确地是无义务的分发，没有附带条件。
ICANN一直是互联网的根域名空间。Handshake社区向ICANN（CA，US）分配24,480,000初始代币。
Cloudflare，Inc.（DE，US）是一家从事基础研究的域名公司，缓存和证书颁发机构。分配了6,800,000 初始代币。
Namecoin也是一个去中心化域名区块链。初始供应量的10,200,000 被分配给当前和以前的Namecoin开发者。
Verisign，Inc.（VA，US）是 .com 和 .net 的注册商，分配了初始供应量中的6,800,000枚。Handshak上的.com和.net TLD将向Verisign提供DNSSEC证明。
Keybase在域名和证书颁发机构领域进行了创新。Keybase，Inc.（DE，US）分配了代币总供应量的0.25％。
公共因特网注册表（VA，US）维护.org命名空间。他们被分配了代币总供应量的3,400,000。Handshake上的.org TLD将通过DNSSEC证明提供给PIR。
Afilias plc（IE）一直是.org域名空间的服务提供者。他们分配了总供应量的3,400,000。请注意，对于PIR和Afilias，此分配是在提案之前进行的 .org域名空间的出售
Brave是一种具有加密经济激励的浏览器。Handshake分配给Brave Software，Inc.（CA，US）3,400,000。这是向实体所有者本身分发的提议，并不意味着向BAT持有者的分发；由实体决定如何分配或是否要求分配。
Namecheap是一个大型域名注册商，一直支持加密货币。他们被分配了最初供应的2,720,000。
Godaddy（AZ, US）是一家大型域名注册商，其证书颁发机构很好。他们被分配了最初供应的2,720,000。
Blockstack是一家开发域名区块链和去中心化互联网堆栈的公司。Handshake将为Blockstack Token LLC（美国新泽西州）分配408,000的代币。这是向实体所有者本身进行分发的提议，并不意味着向Blockstack代币持有者进行分发；由实体决定如何分配或是否要求分配。
ENS使用去中心化的以太坊智能合约开发了备用命名根（.eth）。Handshake项目将向根密钥持有者分配Handshake代币供应量的136,000（并且可能最终根据他们对主要ENS开发人员的需求进行分配）。
GnuNet提供PKI基础结构并通过DHT提供身份。向gnunet.org分配了136,000的初始代币供应（可能需要DNSSEC更新 .org 域名空间）
非营利和FOSS项目 – 2%
不要与为非营利组织和FOSS项目提供的10,200,000美元相混淆，除了这些美元之外，还将向这些实体提供代币（HNS）。
矿工
从历史上看，许多区块链将总代币供应的100％分配给了工作量证明矿工，或者将绝大多数分配给了投资者（没有代币直接提供给免费开源开发者）。这些矿工通过竞争性地发现低价电来降低运营成本成本或使用更好的硬件优化计算来获取价值。
矿工因正确验证链而获得整体奖励。对于未来对矿工的奖励，没有任何承诺、暗示或明确的保证，并且可能会随着未来的技术进步而改变。此外，无法保证硬件继续运行的支出。
未来分配
进一步的激励性分配以来自以下方面的激励为前提，梅特卡夫定律理论上可以通过硬分叉来实现，但超出了本文档的内容范围，因为对未来的行为进行规范是错误的，尤其是在未来未知的情况下，能否实现协调这种活动和获取钥匙的编程能力。
协作
该项目的目的除了开发去中心化的域名系统外，还旨在执行和演示一种在没有中心化权力结构最终状态的情况下进行大规模协调的方法，其机制和激励措施可以在无权限或无合同的情况下在数百万人之间进行协调义务。
区块链允许进行低成本的验证，但它本身并不能促使人们改变基础架构。在一个层次结构中建立一个数以百万计的自上而下的组织来取代根深蒂固的代价是非常昂贵的，因此，提出了一种使用赠予经济的自下而上的结构，这只有在没有中央机构的情况下能够计算价值的新兴技术才有可能（区块链），以及用于数以百万计的大规模协作的工具（互联网免费和开源通信软件）。Handshake是全世界各方的公开展示，旨在参与并交付新的域名系统，作为对更广泛社会的礼物。
公司理论[thenatureofthefirm]假定组织的存在是由于交易成本造成的：在组织内部进行交易通常比在组织之间进行交易便宜，因为组织内部的目标是一致的，而非组织间的目标不是，因为外部各方尽职调查成本很高。公司从根本上因信任而变大，并确保每个人都出于同一原因。力量集中在这些公司的成员中，我们相信我们可以利用技术做得更好。
统一的公司模型在外部成本（“对社会有益吗”）和领导者-员工问题（“此人是否代表我正确行事”）上有重大问题。这就要求负责人时刻注意员工的活动，以确保负责人的目标得到实现。活动要求的信任复杂性越高，它在公司范围内的可能性就越大。股东监督董事会，监督高管，监督员工，并采用硬编码的合同结构来组织和确保采取正确的行动。
智能合约[smartcontracts]的目的是它允许领导者也可以充当执行员工，因为计算可以使人一次读取代码并确保遵循代码，从而大大降低了潜在的信息成本。但是，智能合约并不能从根本上解决社会协调问题，对于那些已经同意进行协调的人来说，它们只是更便宜。
通过构建无义务的资本结构（奖励经济），提出了一种方法，该方法可以创建具有适当社会激励作用的极有价值的社会结构，以通过这种礼物经济的参与者来重构当前社会内部的权力组织中心。
无法验证的行为
不可能直接将价值分配给代码。尽管将来的项目有可能使用p2p预言机根据操作来进行奖励，但代码过于主观。相反，该项目建议删除正在进行的代码奖励验证。尽管此设计的未来迭代可能会通过乐观的针锋相对的机制持续进行验证/奖励，但可以相信，构建系统时无需固有的劳动交换。
由于将其构建为区块链，因此没有单个实体可以控制该系统。该系统之所以存在，是因为人们普遍认为该系统很有价值，计量单位具有价值，并且有足够的愿望来改进/维护该系统。包括自由和开源软件在内的许多基于Commons的对等生产形式[wealthofnetworks]都是集市[bazaar]，但到目前为止，我们一直都将奖励机制设为大教堂。在基于奖励机制的交换机制中，已有一些工作可以交换，以交换基于普通货币的加密货币[primaveradefilippi]，并且在了解没有单一所有者的区块链的含义方面已经进行了很多探索（因此与普通货币的概念相似），但是为免费和开放源代码付款主要是在为提议的可接受的工作付款以换取加密货币的情况下进行的。相反，该项目旨在确保自由和开放源代码开发人员是系统的主要所有者，而没有任何直接的合同期望回报或工作。
以前，FOSS开发人员在大型公司（例如Red Hat Software）工作而获得回报，这些公司能够依据最终的财务收益目标评估付款。这种构造在FOSS软件的价值和公司的利润最大化的价值之间造成了直接的利益冲突。此外，随着公司为FOSS软件提供资金，领导者员工问题仍然存在，因为它们是向公司的最终目标持续付出，而不是为开源项目的最终目标付出。
通过构建一种向FOSS开发人员分配代币而又不希望有回报的机制，这将创建一个免费的系统，从而使构建FOSS软件的个人能够为公地构建软件，同时拥有在此期间共同创建该系统的多数所有权和经济利益。在开发阶段，仅仅是为了鼓励拥有代币的开发人员参与并创建有价值的系统而进行的激励。结果，FOSS开发人员可以做他们认为最符合系统利益的事情，而无需权力层级来确定什么是资源的最佳使用方法，作为回报，人们了解到，付款对于贡献者来说是不精确的（就像那些使用代码获得了好处的人，对公众的不精确付款一样）。
与传统资本公司模型对比
双向市场是替换现有系统时的基本问题。克服双向市场的典型例子是Uber取代了出租车，这有乘客和驾驶员的两个方面-如果驾驶员不足（长等待时间）就很难说服乘客参加，并且如果没有足够的乘客（低回报）就很难说服驾驶员。贝宝（PayPal）致力于解决互联网服务的这种双向市场问题，最早的努力之一就是通过直接给贝宝（PayPal）的新用户发钱来解决市场的一面。
克服双向市场传统上需要大量资金，并且涉及占领未来市场的期望。结果，这些公司从风险投资中筹集了大量资金，从而创造了条件，打破现有的商业模式，创造更有效率的系统，并由中心化提供者进行大规模的协作。这些风险投资公司创造了巨大的价值，并且在替换现有系统以及推动社会的技术，组织和更广泛的社会协调方面拥有专业知识。这在为社会制度创造有效变革方面提供了巨大的社会效益，而如果没有有效的变革，生态系统内的参与者就无法充分协调以创造为广泛的社会效益所必需的充分变革。
已经出现了这种为筹集大量资金以解决双边市场问题而进行的协调的复制[fatprotocols] [fredblog] [navalblog]，并在加密货币领域进行了尝试，这个新兴现象在历史上被称为“ ICO”或“初始代币发行”。这利用资本筹集大量的价值，以建立开发平台所需的资本，并筹集资本以建立基金，以解决双向市场问题。这些公司中的许多公司已经成功地利用了大量筹集的资金来建立开发者社区、用户市场，并通过补贴市场一侧来鼓励各种服务提供商。
然而，尽管风险投资模式已推广并创造了令人难以置信的巨大的收益，但是在传统风险投资中，这种模式仍然存在一些局限性。另外，基于ICO模型的仿真模型已经筹集了大量资金，但是没有足够的实验来展示成功的模型。最大的限制之一是，网络责任不会归因于负责开发此系统并确保其成功的用户。此外，受益于网络效应的经济利益相关者与负责建立那些网络效应的利益相关者之间缺乏关联。此外，通过将大量资金筹集到一个基金会中，存在巨大的中心化压力。
于此不同的是，Handshake机制不依赖利他行为者，它完全依赖于自私的个人和利益相关者。通过向FOSS开发人员和更广泛的人类赠送价值，可以最大限度地提高回报，并且可能是对其他开发模式的探索。
免责声明
Handshake社区开发人员均不保证在过去和未来对项目的持续开发和领导。该文件是一份说明，事实上的社区标准是主要来源。所有本文档的内容可能会根据社区共识而更改。
对于域名和拍卖系统（包括续订、费用、区块可用性）的功能不提供任何保证。此外，不对代币供应、代币价值、域名价值提供任何保证。在全球范围来讲，这一切取决于更广泛的社区对项目的推进。
那些单方面倡导区块链应该走到哪里的人 成为链的早期开发者以及任何与言辞有关的暗示 值得怀疑。由社区来建议更改和分叉都是在社区共识和批准下启动的。
如果进行深度重组，社区应停止处理和确认新的状态更新。强烈建议服务提供商 具有较长的充值确认时间以及自己的内部控制和软件验证。
这里并没有关于挖矿、经济模型等的承诺，硬分叉是可能发生的。
商标持有人对自己的续约、注册负责，项目开发人员不能在锁定期后单方面更改系统。记录的任何变更都需要硬分叉并且需要社区中的全节点和矿工的批准。任何在锁定期后的更改都需要提交给社区硬分叉，或者由客户端解析器变更（无共识）。
不保证一年以上的交易格式。预签名的交易不保证永久可用。私钥应当保持在交易格式改变的时候。