![区块链交易所](https://175.178.95.144/qu/d/file/exchange/negocie-coins.png alt="Negocie Coins的Logo">)
区块链交易所
![区块链交易所](https://175.178.95.144/qu/d/file/exchange/ripple-china.png alt="Ripple China的Logo">)
Byteball白皮书中文版(四)
发布：中币网 时间：2017-04-22 10:49:00 加入收藏 打赏
翻译：Maxwell 胖大鼠 rfmpwxbo@qq.comByteball 白皮书中文版(一) 传送门：http://www.bitett.com/portal.php?mod=viewaid=438Byteball 白皮书中文版(二) 传送门：http://www.bitett.com/portal.php?mod=viewaid=458 ... ,中币网-比特币标志着区块链时代的到来
翻译：Maxwell 胖大鼠 rfmpwxbo@qq.comByteball 白皮书中文版(一) 传送门：http://www.bitett.com/portal.php?mod=view&aid=438Byteball 白皮书中文版(二) 传送门：http://www.bitett.com/portal.php?mod=view&aid=458Byteball 白皮书中文版(三) 传送门：http://www.bitett.com/portal.php?mod=view&aid=472
已在B网上线交易:)10. 最后的球
为了保护球（最重要的是，非序列标识）不被修改，我们要求每个新单元包含作者所知的最后一个球的哈希值（这是从最后一个稳定单元建立的球，并且它位于 MC上）。这样，最后一个球将受到作者签名的保护。之后，证人将（直接或间接）计入新单元本身。
如果不曾拥有完整byteball数据库的人想知道一个特定的单元是否是连续的，那么，他得给予我们他所信任的具有诚实行为的一系列见证人名单，然后，我们将会创建一条最近的包含之前提到的多数见证人的单元链，然后从链条的最旧单元读取最后一个球，并使用球来构建一个哈希树，哈希树的顶部包含最后一个球，并且在树下面的某处包含所请求的单元。该哈希树类似于非常高的Merkle树，其中每个节点都有额外的数据。哈希树可以使用skiplist（跳跃表）进行优化。
参考最后一个球也让用户看到其他人对MC上稳定点的看法，并将其与自己的愿景进行对比。
我们还要求最后一个球不要早于每个父母单元的最后一个球。这样确保最后一个球要么沿MC前进，要么停留在相同位置，而不会退后。为了进一步降低妨害者的自由度，我们添加了一个要求：
单元的见证名单必须与位于MC单元最后部分的每个单元和最后一个球的单元之间的证明名单相一致。此要求确保在尝试其他改变之前，证人名单的所有更改首先达到稳定点。否则，攻击者可能会将明显已被修改的证人名单注入MC上，并停止从新证人的地址发布。攻击者可能会在MC上插入大量修改的证人列表，并阻止新证人发布地址。在这种情况下，稳定点将无法超越攻击者证人所占据的范围。
当代单元的所有证人名单大多相似的要求意味着所有用户对于当前可以信任的社区作为灯塔的用户几乎有相似的看法。所有用户对当前可以充当社区灯塔的人拥有相似的观点。这类似于生物学，同一物种的生物体必须具有大致相同的基因。证人名单的小差异允许进行仍然保持系统的完整性的变化发展。
11.见证列表单元
预计许多用户希望准确地使用相同的见证列表。 在这种情况下，为了节省空间，它们不会列出12个所有见证人的地址。相反，他们会参考另一个先前的单元，这个单元会明确地列出这些证人。从参考单元的角度来说，见证列表单元必须是稳定的，即它必须包括在最后一个球的单元中。
12.单元结构
这是一个单元例子：{ version: '1.0', alt: '1',
这里：•version（版本）是协议版本号。将根据这个版本的协议解释该单元；•alt是替代货币的标识符，稍后我们将会讨论;•messages（消息）是包含实际数据的一个或多个消息的数组;o app是一种信息类型，比如说“payment”代表支付，“text”代表任意文本信息等等o payload_location说明在哪里找到消息的有效载荷。 如果有效载荷包括在消息中，则可以是“内联”，如果在互联网地址可用有效载荷，则是“uri”，如果未发布有效载荷，则是“无”，被私有地存储和/或共享，并且payload_hash 用于证明它存在于特定的时间；o payload_hash是base64编码中的有效载荷散列;o payload就是真实的荷载量（因为这是这个例子里的“内联”）。 有效载荷结构是特定的应用程序。付款描述如下：. 输入代表了一串由支付（指令）消耗的输入货币。输入货币所有者必须在单元的签名者（作者）之中;. 单元是指生产货币的哈希单元。单元必须计入在最后一个球的单元才可消费; •message_index（消息索引）是输入单元的消息数组的索引。它表明生产货币的消息;. •output_index是指进入输入单元message_index消息的输出数组的索引。它表示货币产生的输出;. 输出是一组输出，表明谁收到钱；. •address（地址）是指收件人的Byteball地址;. •金额是他收到的金额;• •作者是指创建和签署本单元的作者数组。所有输入货币必须属于作者;• o地址是作者的Byteball地址;• o认证是证明作者真实性的数据结构。最常见的是ECDSA（椭圆曲线数字签名算法）签名;•parent_units是父母单元的散列数组。它必须按照字母顺序排列;•last_ball和last_ball_unit分别是最后一个球及其单元的哈希值。•witness_list_unit是可以找到见证列表的单元的哈希值。所有哈希值都采用base64编码。
请注意，在单元结构中没有时间戳字段。在Byteball中，没有依赖于系统时间的协议规则。它根本不需要，因为只要依靠事件的顺序就足够了。当时间戳从节点转发到节点时，仍然被添加到单元。然而，这只是建议性的，并且是由轻钱包用来在钱包中显示一个单元被生成的适当时间，这可能与单元被接收的时间存在显著的差异，因为轻钱包可能会长时间离线。
13.佣金
如前所述，存储单元的成本是以字节大小为单位的。 该佣金分为两部分：标头佣金和有效载荷佣金。 有效载荷佣金等同于消息的大小; 标头佣金是其他一切的大小。两种类型的佣金是不同的分配。
标头佣金转到其中一个将付款人单元作为父母的未来单元中。 只有在付款人单元的MCI和下一个MCI变得稳定之后才选择接收者。为了确定接收者，我们选取那些MCI等于或大于付款人MCI的子单元。这些子单元的每个哈希值与位于下一个MCI上（相对于付款人）的单元的哈希值相连接，并且具有最小哈希值（十六进制）的子单元赢得标头佣金。
设计下一个MC单元的哈希是为了引入不可预测性（下一个MC单元不是预先知道的），并且没有任何尝试或提高接收佣金的机会或通过使用自己的单元哈希来实现无效。同时，将候选人限定为那些MCI不大于1的人，这好于MCI不大于1的付款人。鼓励选择最近的单元作为父母。这对于保持DAG尽可能的精确是有用的。
我们只支付标头佣金，而不是将全部佣金给那些很快选择我们单元作为父母的人，原因如下：如果我们支付了整个佣金，我们会激励滥用行为：将一个数据分成几个块，并构建一个自身单元的长链来存储每单元的一个块。在前一个单元支付的所有佣金，将立即由下一个单元的同一用户收集起来。由于我们只支付标头佣金，这样的行为是无利可图的，因为要生产链上的额外元素，必须花费额外的标头佣金-大致等于收入的一个费用。我们使用剩余（有效载荷）佣金来激励对于保持网络健康很重要的活动。
有效载荷佣金转给证人。为了激励证人频繁活动，我们将有效载荷佣金平均分配给所有的证人，在支付单元后他们迅速发布100个MC索引（发布速度越快，该单位变得越稳定）。如果在此间隔内，12名证人都发布索引，则每个人收到1 / 12的有效载荷佣金。如果只有一个证人发布，他会收到所有的有效载荷佣金。在特定情况下，没有证人在间隔内发布，他们都会收到1/12的有效载荷佣金。如果除法产生小数，则根据数学规则四舍五入。由于四舍五入，支付给证人的总佣金可能不等于从该单元的作者中收到的总有效载荷佣金，所以总货币供应量也会略有变化。显然，仅在MCI + 100变得稳定之后才分发，其中MCI是付费单元的MCI。要花费获得的标头佣金或证人佣金，使用以下输入：
这样的输入扫描了由作者从佣金支付单元中赚取的所有标头佣金或证人佣金，而佣金支付单元从主链索引from_main_chain_index和to_main_chain_index之间发出。当一个由多个作者签名的单元获得标头佣金时，到目前为止，如何在作者之间分割佣金尚未明确。 要删除模糊性，由多个作者签名的每个单元都必须包含一个描述收入分成比例的数据结构：
收到佣金的地址不需要与作者地址相同 - 佣金可以发送到任何地址。 即使该单元由单个作者签名，它也可以包括此字段，向其他地方重新发送标头佣金。
14.确认时间
确认时间是指单元进入数据库达到稳定性的时间。这取决于证人发布的频繁程度，因为为了达到稳定，在新增加的单元之后，我们需要在MC上积累足够的见证作者单元。为使确认期最小化，证人应该频繁地发布（通过佣金发放规则已经激励他们这么做了），但也不能太频繁。如果两个或两个以上的证人几乎同时发出它们的单元（比通常需要将新单元传播给其他证人更快），这可能导致由最佳父链接组成的树的不必要的分支，这将延迟稳定性。因此，当证人连接良好并快速在机器上运行，此时达到最佳确认时间，因此他们能够快速验证新单元。我们估计最佳确认时间约为30秒;这只有在新单元的流量足够大才能达到，因此证人从见证佣金中所获得的收入超过他们发布自己单元的费用。
尽管充分确认的时间是相当长的，信任其对等体以传递所有新单元而不进行过滤的节点可以合理确定，一旦一个单元被至少一个证人所包含，再加上一个典型的延迟时间已经过去(新单元从点到点的时间), 该单元很有可能达到终局，并被视为有效单元。即使之后出现双花（双重支付），在本单元之后它也有可能被排序。
15.分区风险
没有命令，Byteball节点的网络永远不能被划分为持续运营的两个部分。即使在全球网络中断的情况下，例如亚大西洋大鼠切断了连接欧洲和美洲的电缆，至少断裂的其中一方将注意到它已经失去了大多数的见证人，这意味着它不能推进稳定点，而且没有人可以花费卡在MC不稳定部分的输出。即使有人试图发送双花，直到恢复连接前它将持续不稳定（因此无法识别）。断裂的另外一方碰巧是大多数见证人，将继续正常运营。
16.审查
在设计上，在byteball上已经无法修改或删除任何过去的记录。阻止任何特定类型的数据进入数据库也是相当困难的。
首先，数据本身是可以被隐藏的，并且只有实际发布到数据库的哈希值才能证明数据的存在。只有在哈希值被存储以及该单元被其他单元包含之后，才可能揭露数据，这使得它变得不可修改。
其次，即使当数据是开放时，将数据包含或不包含在数据库中的决定委托给可能（并且实际上被激励）以新单元作为父母的许多匿名用户。试图审查不良单元的人，不仅要避免直接包含该单元（作为父母），还要间接避免通过其他单元包含该单元。（这与比特币不同，矿工或采矿池可以直接过滤个别交易，此外，比特币用户对谁成为矿工没有任何意见）。由于包含“违规”单元雪球的单元数，任何企图避免这种情况的都需要审查自己。只有大多数见证人才能有效地施加禁止内容规则 -如果用户选择这样的见证人。
17. 选择见证人
依赖见证人是Byteball植根于现实世界的原因。 同时，使得byteball高度依赖于人们的决定。 健全的系统取决于用户负责地设置他们信任的见证人名单。这个过程不能安全地自动化，例如，如果大多数用户只是为了兼容，开始自动更新他们的见证列表来匹配最新观察的单元列表，用最自己单元冲击网络的攻击者很容易利用这个，来逐渐改变主要的见证名单并到其选择的东西。
虽然最大化的建议可以是“仅手动编辑见证列表”，这对于大多数用户来说是有负担的，但是对于管理见证列表更实际的方法是追踪并以某种方式平均几个“行业领袖”的见证人列表，他们关心网络健全或在不一定与Byteball相关的活动中已获得良好声誉。 其中一些人可能自身是见证人。与见证人列表不同，行业领袖列表不必兼容，并且无法频繁更新列表他们不会有任何直接的负面影响，例如找不到兼容的父母和发布新单元。 我们期望大多数用户使用最受欢迎并数量相对较小的钱包之一，该钱包将默认设置为遵循钱包供应商的见证人列表，而钱包供应商又可以看到其他主要用户的见证人列表。
见证人也有他们的见证人列表，并建议用户选择他们信任的见证人，以保持他们见证人列表代表普通用户的信念。这是非常重要的，因为未经大多数现有证人的批准，主要的证人列表无法改变。建议见证人和未来见证人公开宣布他们的见证人名单政策（例如遵循和平均其他声誉良好的用户的证人列表），以及用户根据此政策以及其他因素评估他们对工作的适应性。 任何违反声明的政策行为都会立即显现，并可能触发更换见证人的行为。对政策的无理修改也是如此。 该政策约束证人，并使他遵守公众舆论，即使它反对见证人本人或他的朋友。
如前所述，我们的协议规则要求：1.只有在见证列表不超过1个突变的父母中选择最优父亲2.相对于最后球单元的见证人列表，应该不超过1个突变3相对于最后球单元的所有MC单元不稳定的证人名单，应该不超过1个突变4. 只有在当前稳定点之后当前见证人发布足够的单元，稳定点才能提前。
这些规则旨在防止恶意和意外的分叉。 同时，它们意味着主要见证人列表的任何变动都必须是渐进的，每一步都必须得到大多数目前证人的批准。 首先单方面的变动需要达到稳定，并且得到大多数老证人的认可，然后才能进行另一次变动。 如果社区突然决定需要立即替换两个见证人，则在一个变动进入MC之后，以上的规则3将阻止第二个变动，直到第一个变动达到稳定。
除了以上所有的建议，仍然可能的是，由于行业领导者的疏忽，被选的见证人后来形成卡特尔，并集体阻止替换他们中任何一个人的尝试，来保持他们从见证佣金中赚取的利润。如果他们这样做，该行为将是有目共睹的，因为他们的见证列表将保持不变，而大多数其他行业领导的见证列表将有一个突变（允许保持兼容的最大值）。
如果老证人不屈服于这样的压力，改变用户唯一的办法是“革命”–即在旧资产的某些方面上，开办新资产来继承所有余额，用户地址等，但是从新见证列表开始，添加了特殊的协议规则，用以分裂时处理这种不兼容的变动。为了与旧资产区分开来，他们会为'alt'字段（这是什么'alt'）分配一个新值，并在新资产下发行的所有单元中使用它。结果，用户将持有两个资产（旧的alt =“1”，新的例如alt =“2”），并且能够独立地花费。如果分裂合理，可能会抛弃旧资产，但当新资产是正常时，分裂之前积累的所有数据是可获得的。由于协议几乎是相同的（除了处理分裂和变动alt的规则），在所有用户和商业设备上的软件将更容易地更新安装。
如果有人只是想创建新资产来尝试另一个协议规则，他也可以使用'alt'字段继承来自旧资产的一切, 为用户转换为合适的币种, 并从第一天开始有大量的用户结余。
18. Skiplist(跳表)
有些球含有跳表阵列，加快轻客户端证明的建设（见下文）。 只有那些直接在MC上的球有一个跳表，其MC指数可以被10整除，跳表列出最接近之前MC的球，其索引在末端具有相同或较少数量的零点。 例如，MCI 190处的球具有参照MCI 180处的跳表。在MCI 3000处的球具有参照MCI2990,2900和2000处的跳表。
19.轻客户端
轻客户端不存储整个Byteball数据库。 相反，他们将感兴趣的一子集的数据下载下来，例如仅是在任一用户的地址上进行的支出或被资助的交易。
轻客户端连接到完整节点来下载他们感兴趣的单元。轻客户端向完整节点告知其信任的见证人列表（不一定是用于创建新单元的见证人）以及其自身地址的列表。 完整节点搜索轻客户端感兴趣的单元，并按照以下方式为每个单元构建一个证明链：1.沿着MC及时返回，直到满足大多数见证人的请求。 收集所有这些MC单元。2.从这个集合中的最后一个单元（它也是最早的时间），读取最后一个球。3.从这最后一个球开始，沿着MC及时返回，直到遇到有跳表的任何一个球。收集所有的球。4.使用跳表，跳到更早引用跳表的球。这个球也有一个跳表，再次跳跃。 在跳表数组中有几个球，它们总是跳过最大的距离，所以我们首先加速跳跃10个索引，然后是100，再是1000等等。5.如果跳表的下一次跳跃将我们抛在目标球后面，通过更小距离的跳跃减速。最后，索引离开跳表，每次仅使用父母链沿着MC走。
这条链一开始就是证人授权的单元，从轻客户端的角度来看是可信的。 通过父母单元链接（同时累积见证人）或通过引用最后的球，或通过父母球链接或通过跳表链接来连接链上的所有元素。在链的结尾，我们有一个需要证明其存在性的单元。
20.多重签名
一个单元可以由多方签署。 在这种情况下，单元中的作者数组有两个或多个元素。
这是有用的，例如。 如果两个或多个当事人想签署一份合同（一份普通固定的合同，不是灵活的合同）。 他们将签署包含文本消息（app='text'）的同一单元。 他们不必在公共数据库中存储合同的全文，支付它 - 一个哈希就足够了（payload_location ='none'），并且各方可以私下存储文本。
多重签名的另一个应用是资产交换。 假设用户A想要将资产X发送给用户B，以换取资产Y（本地货币“字节”也是资产 - 基本资产）。 然后，他们将组成一个包含两个付款消息的单元：一个付款将资产X从A发送到B，另一个付款将资产Y从B发送到A.他们都签署双重创作单元并发布它。这个交换是极其微小的 - 也就是说，两个付款同时执行或两者都失败。 如果其中一笔付款出现双花，则整个单元将被视为无效，并且其他付款也被视为无效。
这种简单的结构允许用户直接交换资产，而不需要将他们的钱交给任何中心化交易所。
21.地址
用户由其地址来确认，交易输出发送到地址，并且像在比特币里，建议用户具有多个地址，并避免重复使用它们。 然而，在某些情况下，重复使用是正常的。 例如，见证人应该从同一地址来重复发布。
一个地址表示一个定义，它是一个布尔表达式（远类似于比特币脚本）。 当用户签名一个单元时，他还提供一组认证器（通常是ECDSA签名），当应用于定义时，为了证明该用户有权签名本单元，必须将其评估为真。 我们在JSON中写定义。 例如，将需要ECDSA签名来签名的地址进行定义： ["sig"，{"pubkey":"Ald9tkgiUZQQ1djpZgv2ez7xf1ZvYAsTLhudhvn0931w"}]
此定义指示地址的所有者在定义中（在base64编码中）具有给定其公共对等体的私钥，并且他将使用该私钥来签署所有小区。 如果在相应的认证器中给出的签名有效，则上述定义评估为真，否则为假。 除了验证器之外，对小区的所有数据计算签名。
给定一个定义对象，相应的地址只是初始定义对象的一个哈希值加上一个校验和。 添加校验和以避免输入错误。 然而，与一般的校验和设计不同，该校验和位不仅仅被附加到未校验数据的末尾。相反，它们被插入到数据内的多个位置。 这种设计使得在期望地址的字段中插入长串非法数据变得困难。该地址用base32编码。上述定义对应于地址A2WWHN7755YZVMXCBLMFWRSLKSZJN3FU.
当资金存入改地址时，付款发送者知道并仅指定付款输出中的该地址（定义的校验和散列）。 该定义没有显示，除了所有者之外，它仍然是未知的，直到输出消耗完。当用户从地址中发送他的第一单元时，他必须在作者数组中揭示其定义（为了使签名验证成为可能）：
如果用户从同一地址中发送第二个单元，他必须省略定义（在Byteball上，它已经被了解）。 只有在定义变得稳定之后，他才可以发送第二个单元，即显示定义的单元必须包括在第二单元的最后一个球单元中。
用户可以更新其地址的定义，同时保留旧地址。例如，要旋转链接到地址的私钥，用户需要发布一个包含消息的单元，例如：
这里，definition_chash表示新地址定义的哈希校验和（其在以后不被公开），并且单元本身必须由旧的私密签名。 该地址的下一个单元必须：•将此address_definition_change单元包含在其最后一个球单元中，即它必须已经达到稳定;•与地址上第一条消息相同的方式，在作者数组中显示新定义;
地址更改后，不再等同于其当前定义的哈希校验和。 相反，它保持等同于其初始定义的哈希校验和。
如果用户想要改变密钥（例如当迁移到新设备时）同时保持旧地址（例如，用户名），则定义变化是有用的，例如，如果此地址已经参与其他长期定义（见下文）。
21.1. 定义语法
21.1.1.逻辑运算符
定义可以包括“and”条件，例如：["and", [ ["sig", {pubkey: "one pubkey in base64"}], ["sig", {pubkey: "another pubkey in base64"}]
为了签名交易，例如，手提电脑和智能手机需要来自两个独立设备的签名时，这是有用的。“或”条件，如：["and", [ ["or", [ ["sig", {pubkey: "laptop pubkey"}], ["sig", {pubkey: "tablet pubkey"}] ]], ["sig", {pubkey: "smartphone pubkey"}]
定义可以要求最小数量的条件成为一个真的更大的集合，如2-of-3签名["r of set", { required: 2, set: [ ["sig", {pubkey: "laptop pubkey"}], ["sig", {pubkey: "smartphone pubkey"}], ["sig", {pubkey: "tablet pubkey"}]
（“r”代表“需要”），其特征在于两个强制签名的安全性和可靠性，因此在其中一个私钥丢失的情况下，地址仍然可用，并且可以用于改变其定义和用新私钥替换丢失的第三个私钥。
此外，不同的条件可以给予不同的权重，这是最低的要求： ["weighted and", { required: 50, set: [ {weight: 40, value: ["sig", {pubkey: "CEO pubkey"}] }, {weight: 20, value: ["sig", {pubkey: "COO pubkey"}] }, {weight: 20, value: ["sig", {pubkey: "CFO pubkey"}] }, {weight: 20, value: ["sig", {pubkey: "CTO pubkey"}] }
21.1.2.委派到其他地址
地址可以包含对另一个地址的引用：["and", [ ["address", "ADDRESS 1 IN BASE32"], ["address", "ADDRESS 2 IN BASE32"]
它将签名委托给另一地址，并且对于构建共享控制地址（由若干用户控制的地址）是有用的。 这种语法使用户能够随时随意更改自己组件地址的定义，而无需打扰其他用户。
21.1.3. 签名和认证
在大多数情况下，定义将包括至少一个签名（直接或间接）：["sig", {pubkey: "pubkey inbase64"}] 代替签名，定义可能需要提供哈希的前映像：["hash",{"hash":"valueof sha256 hash in base64"}]
这可以用于交叉链交换算法[7]。 在这种情况下，进入的哈希前映像作为认证器之一。
默认签名算法是曲线secp256k1上的ECDSA（与比特币相同）。最初，它是唯一支持的算法。在将来如果添加其他算法，则算法标识符将用于定义的相应部分，例如用于量子安全的NTRU算法：["sig", {algo: "ntru",pubkey: "NTRU public key in base64"}]
当人们在与更常规的签名相结合时，多重签名定义允许对未经验证的签名方案进行安全实验。
在单元标头中的认证对象包含签名者或其他数据（例如哈希前映像）,它们在地址定义中由认证者子定义路径锁定。对于单字地址，例如["sig", {pubkey: "pubkey inbase64"}]
路径只是“r”（r代表根）。 如果另一个定义中包括认证者所要求的子定义（例如and/or），则该路径通过索引扩展到包含自定义的数组中，并且路径组件由点定界。 例如，对于地址定义：["and", [ ["sig", {pubkey: "one pubkey in base64"}], ["sig", {pubkey: "another pubkey in base64"}]
路径是“r.0”和“r.1”。 对于更深层的嵌套定义：["and", [ ["or", [ ["sig", {pubkey: "laptop pubkey"}], ["sig", {pubkey: "tablet pubkey"}] ]], ["sig", {pubkey: "smartphone pubkey"}]
路径是“r.0.0”，“r.0.1”和“r.1”。 当有可选签名（例如2的3）时，路径告诉我们实际使用了哪些私钥。
（待续）
↓这是个Byteball钱包打赏地址：CMAOL3JX4V4NLZ6O5ZTUW643YRBVAEOO您的支持是对我们最大的鼓励！
来源：中币网 https://www.zhongbi.net/news/blocknews/21329.html 声明：登载此文仅出于分享区块链知识，并不意味着赞同其观点或证实其描述。文章内容仅供参考，不构成投资建议。投资者据此操作，风险自担。 此文如侵犯到您的合法权益，请联系我们3111859717@qq.com，我们将第一时间处理。
已在B网上线交易:)10. 最后的球
为了保护球（最重要的是，非序列标识）不被修改，我们要求每个新单元包含作者所知的最后一个球的哈希值（这是从最后一个稳定单元建立的球，并且它位于 MC上）。这样，最后一个球将受到作者签名的保护。之后，证人将（直接或间接）计入新单元本身。
如果不曾拥有完整byteball数据库的人想知道一个特定的单元是否是连续的，那么，他得给予我们他所信任的具有诚实行为的一系列见证人名单，然后，我们将会创建一条最近的包含之前提到的多数见证人的单元链，然后从链条的最旧单元读取最后一个球，并使用球来构建一个哈希树，哈希树的顶部包含最后一个球，并且在树下面的某处包含所请求的单元。该哈希树类似于非常高的Merkle树，其中每个节点都有额外的数据。哈希树可以使用skiplist（跳跃表）进行优化。
参考最后一个球也让用户看到其他人对MC上稳定点的看法，并将其与自己的愿景进行对比。
我们还要求最后一个球不要早于每个父母单元的最后一个球。这样确保最后一个球要么沿MC前进，要么停留在相同位置，而不会退后。为了进一步降低妨害者的自由度，我们添加了一个要求：
单元的见证名单必须与位于MC单元最后部分的每个单元和最后一个球的单元之间的证明名单相一致。此要求确保在尝试其他改变之前，证人名单的所有更改首先达到稳定点。否则，攻击者可能会将明显已被修改的证人名单注入MC上，并停止从新证人的地址发布。攻击者可能会在MC上插入大量修改的证人列表，并阻止新证人发布地址。在这种情况下，稳定点将无法超越攻击者证人所占据的范围。
当代单元的所有证人名单大多相似的要求意味着所有用户对于当前可以信任的社区作为灯塔的用户几乎有相似的看法。所有用户对当前可以充当社区灯塔的人拥有相似的观点。这类似于生物学，同一物种的生物体必须具有大致相同的基因。证人名单的小差异允许进行仍然保持系统的完整性的变化发展。
11.见证列表单元
预计许多用户希望准确地使用相同的见证列表。 在这种情况下，为了节省空间，它们不会列出12个所有见证人的地址。相反，他们会参考另一个先前的单元，这个单元会明确地列出这些证人。从参考单元的角度来说，见证列表单元必须是稳定的，即它必须包括在最后一个球的单元中。
12.单元结构
这是一个单元例子：{ version: '1.0', alt: '1',
这里：•version（版本）是协议版本号。将根据这个版本的协议解释该单元；•alt是替代货币的标识符，稍后我们将会讨论;•messages（消息）是包含实际数据的一个或多个消息的数组;o app是一种信息类型，比如说“payment”代表支付，“text”代表任意文本信息等等o payload_location说明在哪里找到消息的有效载荷。 如果有效载荷包括在消息中，则可以是“内联”，如果在互联网地址可用有效载荷，则是“uri”，如果未发布有效载荷，则是“无”，被私有地存储和/或共享，并且payload_hash 用于证明它存在于特定的时间；o payload_hash是base64编码中的有效载荷散列;o payload就是真实的荷载量（因为这是这个例子里的“内联”）。 有效载荷结构是特定的应用程序。付款描述如下：. 输入代表了一串由支付（指令）消耗的输入货币。输入货币所有者必须在单元的签名者（作者）之中;. 单元是指生产货币的哈希单元。单元必须计入在最后一个球的单元才可消费; •message_index（消息索引）是输入单元的消息数组的索引。它表明生产货币的消息;. •output_index是指进入输入单元message_index消息的输出数组的索引。它表示货币产生的输出;. 输出是一组输出，表明谁收到钱；. •address（地址）是指收件人的Byteball地址;. •金额是他收到的金额;• •作者是指创建和签署本单元的作者数组。所有输入货币必须属于作者;• o地址是作者的Byteball地址;• o认证是证明作者真实性的数据结构。最常见的是ECDSA（椭圆曲线数字签名算法）签名;•parent_units是父母单元的散列数组。它必须按照字母顺序排列;•last_ball和last_ball_unit分别是最后一个球及其单元的哈希值。•witness_list_unit是可以找到见证列表的单元的哈希值。所有哈希值都采用base64编码。请注意，在单元结构中没有时间戳字段。在Byteball中，没有依赖于系统时间的协议规则。它根本不需要，因为只要依靠事件的顺序就足够了。当时间戳从节点转发到节点时，仍然被添加到单元。然而，这只是建议性的，并且是由轻钱包用来在钱包中显示一个单元被生成的适当时间，这可能与单元被接收的时间存在显著的差异，因为轻钱包可能会长时间离线。
13.佣金
如前所述，存储单元的成本是以字节大小为单位的。 该佣金分为两部分：标头佣金和有效载荷佣金。 有效载荷佣金等同于消息的大小; 标头佣金是其他一切的大小。两种类型的佣金是不同的分配。
标头佣金转到其中一个将付款人单元作为父母的未来单元中。 只有在付款人单元的MCI和下一个MCI变得稳定之后才选择接收者。为了确定接收者，我们选取那些MCI等于或大于付款人MCI的子单元。这些子单元的每个哈希值与位于下一个MCI上（相对于付款人）的单元的哈希值相连接，并且具有最小哈希值（十六进制）的子单元赢得标头佣金。
设计下一个MC单元的哈希是为了引入不可预测性（下一个MC单元不是预先知道的），并且没有任何尝试或提高接收佣金的机会或通过使用自己的单元哈希来实现无效。同时，将候选人限定为那些MCI不大于1的人，这好于MCI不大于1的付款人。鼓励选择最近的单元作为父母。这对于保持DAG尽可能的精确是有用的。
我们只支付标头佣金，而不是将全部佣金给那些很快选择我们单元作为父母的人，原因如下：如果我们支付了整个佣金，我们会激励滥用行为：将一个数据分成几个块，并构建一个自身单元的长链来存储每单元的一个块。在前一个单元支付的所有佣金，将立即由下一个单元的同一用户收集起来。由于我们只支付标头佣金，这样的行为是无利可图的，因为要生产链上的额外元素，必须花费额外的标头佣金-大致等于收入的一个费用。我们使用剩余（有效载荷）佣金来激励对于保持网络健康很重要的活动。
有效载荷佣金转给证人。为了激励证人频繁活动，我们将有效载荷佣金平均分配给所有的证人，在支付单元后他们迅速发布100个MC索引（发布速度越快，该单位变得越稳定）。如果在此间隔内，12名证人都发布索引，则每个人收到1 / 12的有效载荷佣金。如果只有一个证人发布，他会收到所有的有效载荷佣金。在特定情况下，没有证人在间隔内发布，他们都会收到1/12的有效载荷佣金。如果除法产生小数，则根据数学规则四舍五入。由于四舍五入，支付给证人的总佣金可能不等于从该单元的作者中收到的总有效载荷佣金，所以总货币供应量也会略有变化。显然，仅在MCI + 100变得稳定之后才分发，其中MCI是付费单元的MCI。要花费获得的标头佣金或证人佣金，使用以下输入：
这样的输入扫描了由作者从佣金支付单元中赚取的所有标头佣金或证人佣金，而佣金支付单元从主链索引from_main_chain_index和to_main_chain_index之间发出。当一个由多个作者签名的单元获得标头佣金时，到目前为止，如何在作者之间分割佣金尚未明确。 要删除模糊性，由多个作者签名的每个单元都必须包含一个描述收入分成比例的数据结构：
收到佣金的地址不需要与作者地址相同 - 佣金可以发送到任何地址。 即使该单元由单个作者签名，它也可以包括此字段，向其他地方重新发送标头佣金。
14.确认时间
确认时间是指单元进入数据库达到稳定性的时间。这取决于证人发布的频繁程度，因为为了达到稳定，在新增加的单元之后，我们需要在MC上积累足够的见证作者单元。为使确认期最小化，证人应该频繁地发布（通过佣金发放规则已经激励他们这么做了），但也不能太频繁。如果两个或两个以上的证人几乎同时发出它们的单元（比通常需要将新单元传播给其他证人更快），这可能导致由最佳父链接组成的树的不必要的分支，这将延迟稳定性。因此，当证人连接良好并快速在机器上运行，此时达到最佳确认时间，因此他们能够快速验证新单元。我们估计最佳确认时间约为30秒;这只有在新单元的流量足够大才能达到，因此证人从见证佣金中所获得的收入超过他们发布自己单元的费用。
尽管充分确认的时间是相当长的，信任其对等体以传递所有新单元而不进行过滤的节点可以合理确定，一旦一个单元被至少一个证人所包含，再加上一个典型的延迟时间已经过去(新单元从点到点的时间), 该单元很有可能达到终局，并被视为有效单元。即使之后出现双花（双重支付），在本单元之后它也有可能被排序。
15.分区风险
没有命令，Byteball节点的网络永远不能被划分为持续运营的两个部分。即使在全球网络中断的情况下，例如亚大西洋大鼠切断了连接欧洲和美洲的电缆，至少断裂的其中一方将注意到它已经失去了大多数的见证人，这意味着它不能推进稳定点，而且没有人可以花费卡在MC不稳定部分的输出。即使有人试图发送双花，直到恢复连接前它将持续不稳定（因此无法识别）。断裂的另外一方碰巧是大多数见证人，将继续正常运营。
16.审查
在设计上，在byteball上已经无法修改或删除任何过去的记录。阻止任何特定类型的数据进入数据库也是相当困难的。
首先，数据本身是可以被隐藏的，并且只有实际发布到数据库的哈希值才能证明数据的存在。只有在哈希值被存储以及该单元被其他单元包含之后，才可能揭露数据，这使得它变得不可修改。
其次，即使当数据是开放时，将数据包含或不包含在数据库中的决定委托给可能（并且实际上被激励）以新单元作为父母的许多匿名用户。试图审查不良单元的人，不仅要避免直接包含该单元（作为父母），还要间接避免通过其他单元包含该单元。（这与比特币不同，矿工或采矿池可以直接过滤个别交易，此外，比特币用户对谁成为矿工没有任何意见）。由于包含“违规”单元雪球的单元数，任何企图避免这种情况的都需要审查自己。只有大多数见证人才能有效地施加禁止内容规则 -如果用户选择这样的见证人。
17. 选择见证人
依赖见证人是Byteball植根于现实世界的原因。 同时，使得byteball高度依赖于人们的决定。 健全的系统取决于用户负责地设置他们信任的见证人名单。这个过程不能安全地自动化，例如，如果大多数用户只是为了兼容，开始自动更新他们的见证列表来匹配最新观察的单元列表，用最自己单元冲击网络的攻击者很容易利用这个，来逐渐改变主要的见证名单并到其选择的东西。
虽然最大化的建议可以是“仅手动编辑见证列表”，这对于大多数用户来说是有负担的，但是对于管理见证列表更实际的方法是追踪并以某种方式平均几个“行业领袖”的见证人列表，他们关心网络健全或在不一定与Byteball相关的活动中已获得良好声誉。 其中一些人可能自身是见证人。与见证人列表不同，行业领袖列表不必兼容，并且无法频繁更新列表他们不会有任何直接的负面影响，例如找不到兼容的父母和发布新单元。 我们期望大多数用户使用最受欢迎并数量相对较小的钱包之一，该钱包将默认设置为遵循钱包供应商的见证人列表，而钱包供应商又可以看到其他主要用户的见证人列表。
见证人也有他们的见证人列表，并建议用户选择他们信任的见证人，以保持他们见证人列表代表普通用户的信念。这是非常重要的，因为未经大多数现有证人的批准，主要的证人列表无法改变。建议见证人和未来见证人公开宣布他们的见证人名单政策（例如遵循和平均其他声誉良好的用户的证人列表），以及用户根据此政策以及其他因素评估他们对工作的适应性。 任何违反声明的政策行为都会立即显现，并可能触发更换见证人的行为。对政策的无理修改也是如此。 该政策约束证人，并使他遵守公众舆论，即使它反对见证人本人或他的朋友。
如前所述，我们的协议规则要求：1.只有在见证列表不超过1个突变的父母中选择最优父亲2.相对于最后球单元的见证人列表，应该不超过1个突变3相对于最后球单元的所有MC单元不稳定的证人名单，应该不超过1个突变4. 只有在当前稳定点之后当前见证人发布足够的单元，稳定点才能提前。
这些规则旨在防止恶意和意外的分叉。 同时，它们意味着主要见证人列表的任何变动都必须是渐进的，每一步都必须得到大多数目前证人的批准。 首先单方面的变动需要达到稳定，并且得到大多数老证人的认可，然后才能进行另一次变动。 如果社区突然决定需要立即替换两个见证人，则在一个变动进入MC之后，以上的规则3将阻止第二个变动，直到第一个变动达到稳定。
除了以上所有的建议，仍然可能的是，由于行业领导者的疏忽，被选的见证人后来形成卡特尔，并集体阻止替换他们中任何一个人的尝试，来保持他们从见证佣金中赚取的利润。如果他们这样做，该行为将是有目共睹的，因为他们的见证列表将保持不变，而大多数其他行业领导的见证列表将有一个突变（允许保持兼容的最大值）。
如果老证人不屈服于这样的压力，改变用户唯一的办法是“革命”–即在旧资产的某些方面上，开办新资产来继承所有余额，用户地址等，但是从新见证列表开始，添加了特殊的协议规则，用以分裂时处理这种不兼容的变动。为了与旧资产区分开来，他们会为'alt'字段（这是什么'alt'）分配一个新值，并在新资产下发行的所有单元中使用它。结果，用户将持有两个资产（旧的alt =“1”，新的例如alt =“2”），并且能够独立地花费。如果分裂合理，可能会抛弃旧资产，但当新资产是正常时，分裂之前积累的所有数据是可获得的。由于协议几乎是相同的（除了处理分裂和变动alt的规则），在所有用户和商业设备上的软件将更容易地更新安装。
如果有人只是想创建新资产来尝试另一个协议规则，他也可以使用'alt'字段继承来自旧资产的一切, 为用户转换为合适的币种, 并从第一天开始有大量的用户结余。
18. Skiplist(跳表)
有些球含有跳表阵列，加快轻客户端证明的建设（见下文）。 只有那些直接在MC上的球有一个跳表，其MC指数可以被10整除，跳表列出最接近之前MC的球，其索引在末端具有相同或较少数量的零点。 例如，MCI 190处的球具有参照MCI 180处的跳表。在MCI 3000处的球具有参照MCI2990,2900和2000处的跳表。
19.轻客户端
轻客户端不存储整个Byteball数据库。 相反，他们将感兴趣的一子集的数据下载下来，例如仅是在任一用户的地址上进行的支出或被资助的交易。
轻客户端连接到完整节点来下载他们感兴趣的单元。轻客户端向完整节点告知其信任的见证人列表（不一定是用于创建新单元的见证人）以及其自身地址的列表。 完整节点搜索轻客户端感兴趣的单元，并按照以下方式为每个单元构建一个证明链：1.沿着MC及时返回，直到满足大多数见证人的请求。 收集所有这些MC单元。2.从这个集合中的最后一个单元（它也是最早的时间），读取最后一个球。3.从这最后一个球开始，沿着MC及时返回，直到遇到有跳表的任何一个球。收集所有的球。4.使用跳表，跳到更早引用跳表的球。这个球也有一个跳表，再次跳跃。 在跳表数组中有几个球，它们总是跳过最大的距离，所以我们首先加速跳跃10个索引，然后是100，再是1000等等。5.如果跳表的下一次跳跃将我们抛在目标球后面，通过更小距离的跳跃减速。最后，索引离开跳表，每次仅使用父母链沿着MC走。
这条链一开始就是证人授权的单元，从轻客户端的角度来看是可信的。 通过父母单元链接（同时累积见证人）或通过引用最后的球，或通过父母球链接或通过跳表链接来连接链上的所有元素。在链的结尾，我们有一个需要证明其存在性的单元。
20.多重签名
一个单元可以由多方签署。 在这种情况下，单元中的作者数组有两个或多个元素。
这是有用的，例如。 如果两个或多个当事人想签署一份合同（一份普通固定的合同，不是灵活的合同）。 他们将签署包含文本消息（app='text'）的同一单元。 他们不必在公共数据库中存储合同的全文，支付它 - 一个哈希就足够了（payload_location ='none'），并且各方可以私下存储文本。
多重签名的另一个应用是资产交换。 假设用户A想要将资产X发送给用户B，以换取资产Y（本地货币“字节”也是资产 - 基本资产）。 然后，他们将组成一个包含两个付款消息的单元：一个付款将资产X从A发送到B，另一个付款将资产Y从B发送到A.他们都签署双重创作单元并发布它。这个交换是极其微小的 - 也就是说，两个付款同时执行或两者都失败。 如果其中一笔付款出现双花，则整个单元将被视为无效，并且其他付款也被视为无效。
这种简单的结构允许用户直接交换资产，而不需要将他们的钱交给任何中心化交易所。
21.地址
用户由其地址来确认，交易输出发送到地址，并且像在比特币里，建议用户具有多个地址，并避免重复使用它们。 然而，在某些情况下，重复使用是正常的。 例如，见证人应该从同一地址来重复发布。
一个地址表示一个定义，它是一个布尔表达式（远类似于比特币脚本）。 当用户签名一个单元时，他还提供一组认证器（通常是ECDSA签名），当应用于定义时，为了证明该用户有权签名本单元，必须将其评估为真。 我们在JSON中写定义。 例如，将需要ECDSA签名来签名的地址进行定义： ["sig"，{"pubkey":"Ald9tkgiUZQQ1djpZgv2ez7xf1ZvYAsTLhudhvn0931w"}]
此定义指示地址的所有者在定义中（在base64编码中）具有给定其公共对等体的私钥，并且他将使用该私钥来签署所有小区。 如果在相应的认证器中给出的签名有效，则上述定义评估为真，否则为假。 除了验证器之外，对小区的所有数据计算签名。
给定一个定义对象，相应的地址只是初始定义对象的一个哈希值加上一个校验和。 添加校验和以避免输入错误。 然而，与一般的校验和设计不同，该校验和位不仅仅被附加到未校验数据的末尾。相反，它们被插入到数据内的多个位置。 这种设计使得在期望地址的字段中插入长串非法数据变得困难。该地址用base32编码。上述定义对应于地址A2WWHN7755YZVMXCBLMFWRSLKSZJN3FU.
当资金存入改地址时，付款发送者知道并仅指定付款输出中的该地址（定义的校验和散列）。 该定义没有显示，除了所有者之外，它仍然是未知的，直到输出消耗完。当用户从地址中发送他的第一单元时，他必须在作者数组中揭示其定义（为了使签名验证成为可能）：
如果用户从同一地址中发送第二个单元，他必须省略定义（在Byteball上，它已经被了解）。 只有在定义变得稳定之后，他才可以发送第二个单元，即显示定义的单元必须包括在第二单元的最后一个球单元中。
用户可以更新其地址的定义，同时保留旧地址。例如，要旋转链接到地址的私钥，用户需要发布一个包含消息的单元，例如：
这里，definition_chash表示新地址定义的哈希校验和（其在以后不被公开），并且单元本身必须由旧的私密签名。 该地址的下一个单元必须：•将此address_definition_change单元包含在其最后一个球单元中，即它必须已经达到稳定;•与地址上第一条消息相同的方式，在作者数组中显示新定义;
地址更改后，不再等同于其当前定义的哈希校验和。 相反，它保持等同于其初始定义的哈希校验和。
如果用户想要改变密钥（例如当迁移到新设备时）同时保持旧地址（例如，用户名），则定义变化是有用的，例如，如果此地址已经参与其他长期定义（见下文）。
21.1. 定义语法
21.1.1.逻辑运算符
定义可以包括“and”条件，例如：["and", [ ["sig", {pubkey: "one pubkey in base64"}], ["sig", {pubkey: "another pubkey in base64"}]
为了签名交易，例如，手提电脑和智能手机需要来自两个独立设备的签名时，这是有用的。“或”条件，如：["and", [ ["or", [ ["sig", {pubkey: "laptop pubkey"}], ["sig", {pubkey: "tablet pubkey"}] ]], ["sig", {pubkey: "smartphone pubkey"}]
定义可以要求最小数量的条件成为一个真的更大的集合，如2-of-3签名["r of set", { required: 2, set: [ ["sig", {pubkey: "laptop pubkey"}], ["sig", {pubkey: "smartphone pubkey"}], ["sig", {pubkey: "tablet pubkey"}]
（“r”代表“需要”），其特征在于两个强制签名的安全性和可靠性，因此在其中一个私钥丢失的情况下，地址仍然可用，并且可以用于改变其定义和用新私钥替换丢失的第三个私钥。
此外，不同的条件可以给予不同的权重，这是最低的要求： ["weighted and", { required: 50, set: [ {weight: 40, value: ["sig", {pubkey: "CEO pubkey"}] }, {weight: 20, value: ["sig", {pubkey: "COO pubkey"}] }, {weight: 20, value: ["sig", {pubkey: "CFO pubkey"}] }, {weight: 20, value: ["sig", {pubkey: "CTO pubkey"}] }
21.1.2.委派到其他地址
地址可以包含对另一个地址的引用：["and", [ ["address", "ADDRESS 1 IN BASE32"], ["address", "ADDRESS 2 IN BASE32"]
它将签名委托给另一地址，并且对于构建共享控制地址（由若干用户控制的地址）是有用的。 这种语法使用户能够随时随意更改自己组件地址的定义，而无需打扰其他用户。
21.1.3. 签名和认证
在大多数情况下，定义将包括至少一个签名（直接或间接）：["sig", {pubkey: "pubkey inbase64"}] 代替签名，定义可能需要提供哈希的前映像：["hash",{"hash":"valueof sha256 hash in base64"}]
这可以用于交叉链交换算法[7]。 在这种情况下，进入的哈希前映像作为认证器之一。
默认签名算法是曲线secp256k1上的ECDSA（与比特币相同）。最初，它是唯一支持的算法。在将来如果添加其他算法，则算法标识符将用于定义的相应部分，例如用于量子安全的NTRU算法：["sig", {algo: "ntru",pubkey: "NTRU public key in base64"}]
当人们在与更常规的签名相结合时，多重签名定义允许对未经验证的签名方案进行安全实验。
在单元标头中的认证对象包含签名者或其他数据（例如哈希前映像）,它们在地址定义中由认证者子定义路径锁定。对于单字地址，例如["sig", {pubkey: "pubkey inbase64"}]
路径只是“r”（r代表根）。 如果另一个定义中包括认证者所要求的子定义（例如and/or），则该路径通过索引扩展到包含自定义的数组中，并且路径组件由点定界。 例如，对于地址定义：["and", [ ["sig", {pubkey: "one pubkey in base64"}], ["sig", {pubkey: "another pubkey in base64"}]
路径是“r.0”和“r.1”。 对于更深层的嵌套定义：["and", [ ["or", [ ["sig", {pubkey: "laptop pubkey"}], ["sig", {pubkey: "tablet pubkey"}] ]], ["sig", {pubkey: "smartphone pubkey"}]
路径是“r.0.0”，“r.0.1”和“r.1”。 当有可选签名（例如2的3）时，路径告诉我们实际使用了哪些私钥。
（待续）
↓这是个Byteball钱包打赏地址：CMAOL3JX4V4NLZ6O5ZTUW643YRBVAEOO您的支持是对我们最大的鼓励！
来源：
来源：中币网 https://www.zhongbi.net/news/blocknews/21329.html 声明：登载此文仅出于分享区块链知识，并不意味着赞同其观点或证实其描述。文章内容仅供参考，不构成投资建议。投资者据此操作，风险自担。 此文如侵犯到您的合法权益，请联系我们3111859717@qq.com，我们将第一时间处理。
