TBTCOIN硬分叉

TBTCOIN Evolution 初始设计文档 1
钛特币白皮书 1.2 版本
【技术白皮书】–【第 2 版】2019 年 7 月 15 日-鈦币团队
目录
背景
摘要
系统总览
区块链账户
帐户订阅
帐户数据
架构
应用程序架构
互通性
付款对象
状态序列
要求
集中解决方案
分散设计
参照完整性
状态序列
共识
持久性战略
国家转型
激励
过渡验证
块协议
块头
块验证
TBTCOIN Evolution 初始设计文档 2 存储 数据类型 提交数据 可扩展性 存储架构 数据分区 分散的 API 网络架构安全模型 网络拓扑结构 客户端协议仲裁 获取 Masternode 列表 法定人数 客户创建的状态转换 法定人数创造了国家转型 创建 授权触发器 评级Masternode 股票 治理 提案创建 表决超级块 系统管理员 钛特币发行机制 钛比特发行参数
TBTCOIN Evolution 初始设计文档 3
摘要
比特币（bitcoin）和后来的以太坊（ethereum）安全的公共区块链 的出现， 带
来了显著的利益和资本流入，为全球无许可创新浪潮提供了前提。 尽管有着崇
高的承诺，但创建一个分散、安全和可扩展的公共区块链 已被证明是一项艰巨
的任务。比特币提供假名交易，实现发送者和接受者之间一对一交易的关系，并
能永远记录全网发生过的交易。比特币只提供低层次的隐私保护， 这点在学术
界众所周知，尽管有此不足，许多人仍然相信区块链记录 的转账历史基于中本
聪成果，Tbtcoin（鈦比特）是以保护隐私为要旨的加密数字货币。我们在比特币
概念的基础上进行了一系列的改 进，由此诞生出一个去中心化的和具备良好匿
名性的加密数字货币， 它支持防篡改的即时交易， 又有能为 Tbtcoin 网络提供
服务奖励制的 点对点次级网络
区块链账户
区块链账户为用户在系统中访问提供了基础，使用户能够以加密方式证明他们创
建的假名身份的所有权，并在区块链上保留与该身份相关的数据。这些区块链账
户通过一组特殊的账户相关交易（例如注册，更改密钥）在区块链上进行注册和
管理。帐户注册将所选用户名与将用于将来活动的用户提供的公钥相关联。当帐
户所有者创建或更新其数据时，数据将使用其帐户私钥进行签名。每个区块链账
户都维持一个“费用余额”，可以用来支付矿工的费用，这些矿工要求区块链账
户更新费用。使用称为“刻录”的加密货币过程建立并重新填充此余额。其他与
安全相关的交易使区块链帐户所有者能够更新其链上公钥或关闭其帐户。
主节点
托管对区块链账户有用的分散式网络和存储服务需要基于它的可靠基础设施。典
型的 TBTCOIN 节点并不适合这种情况，因为它们没有激励它们保持在线，特别
是随着对资源的需求增加（例如存储，网络容量等）。为了在需求增加时为节点
提供支持网络的激励，本文档中描述的网络和存储服务在一组节点（主节点）上
TBTCOIN Evolution 初始设计文档 4
运行，这些节点以与 TBTCOIN 矿工类似的方式提供的服务得到奖励。为了确保
这些主节点投资于整个系统，他们需要保持最小的抵押品（例如 1000
TBTCOIN）。
分散的 API
分散式 API 模块（DAPI）提供了通过抽象出难以使用且易于阻止的 P2P 网络层
来使 TBTCOIN 可访问的必要手段。这种分散的 API 通过提供 HTTP 可访问的
API 充当 TBTCOIN P2P 网络和其他网络（例如，因特网）之间的中介。为了维
护用户的安全性，DAPI 无法控制帐户所有者的私钥，并且提交的数据由包含多
个 DAPI 提供程序的 masternode 仲裁验证，以降低恶意行为者的风险。
存储
尽管 DAPI 为典型的加密货币使用（例如金融交易）提供了优势，但使用区块链
存储自定义数据具有许多限制，例如成本和大小限制。在链外添加第二层存储，
可以更灵活地利用区块链提供的安全性。为了保持数据安全性，每个数据更新的
哈希都存储在区块链中。区块链的不变性提供了一种验证离链（第 2 层）数据保
持不变的机制。与区块链存储不同，第 2 层存储可以以特定应用程序的模式定义
的对象的形式存储通用数据。对象在差异事务中提交到存储，每个事务都链接到
对象的先前更新。通过遍历所有数据更改，可以解析“活动”状态以表示完整的
当前数据集。
架构
为了确保第 2 层存储的一致性和完整性，存储在其中的所有对象都由基于 JSON
的模式管理，该模式定义了如何验证它们以及它们允许的关系的规则。基本模式
TBTCOIN Evolution 初始设计文档 5
定义了系统中所有对象必须遵守的整体规范。然后，应用程序将其扩展，以实现
支持其自定义要求所必需的子模式。
法定人数
在仲裁中运行的 Masternode 为提交给 DAPI 的第 2 层相关数据提供验证。仲
裁的阈值数量（例如，10 个中的 6 个）必须就数据的有效性达成共识，以使其
被接受，链接到区块链，并通过 TBTCOIN 网络传播。仲裁通过向提供的数据添
加仲裁签名来表示其批准。由于参与仲裁活动是主节点必须提供以接收付款的服
务之一，因此 masternodes 有动力响应这些请求。
共识
关于块中添加的数据更新的有效性和顺序的共识规则类似于现有 TBTCOIN 协议
中的事务的那些。Schema 验证，masternode 仲裁接受和矿工强制执行的区块
链规则的组合形成了共识，使第 2 层数据存储保持安全。
系统总览
图。附图说明图 1 示出了系统的框图。该系统包括连接到主节点网络（4100）
的一个或多个客户端（1000），该节点网络包含多个主节点（2000），其提供
服务并充当加密货币网络（4200）的中介。添加更多细节，
TBTCOIN Evolution 初始设计文档 6
图 5 示出了 masternode（2000）的框图，其包括 API 模块（2100），存储模
块（2200）和区块链模块（2300）。
TBTCOIN Evolution 初始设计文档 7
图。图 2 示出了客户端（1000）数据被验证然后以分散方式存储所需的路径的
概述。客户端数据首先在 Masternode（2000）上进入 API 模块（2100）并且
被发送到区块链模块（2300）以从由多个 Masternode（2000）组成的 Quorum
（2400）获得关于数据有效性的共识（3300）。在获得共识后，Quorum（2400）
向请求的 Masternode 的区块链模块（2300）发送响应，一旦在区块链中表示
数据，该区块链模块就触发第 2 层存储同步（3400）。在第 2 层存储同步（3400）
期间，Masternode 网络（4200）上的 Masternodes（2000）的存储模块（2200）
彼此通信以确保数据在网络上同步。
TBTCOIN Evolution 初始设计文档 8
区块链账户
帐户是系统中用户访问的基础，使用户能够以加密方式证明他们创建的假名身份
的所有权，并在区块链上保留与该身份相关的公共和私有数据。帐户是存储在区
块链上的数据结构，代表系统所服务的各种新类型的用户，例如最终用户（例如
消费者）和应用程序（例如企业），他们向网络支付费用，以换取添加和更新其
帐户的数据，基本上作为网络的订户。
TBTCOIN Evolution 初始设计文档 9
图。图 7 示出了客户端（1000）使用如图 7 所示的架构建立新账户的框图。1. 客户端（1000）向 Masternode（2000）的 API 模块（2100）提交账户注册
（3710）。API 模块（2100）将其发送到区块链模块（2300），区块链模块（2300）
向加密货币网络（4200）广播有效的账户注册（3711）。该广播以与典型的加
密货币交易相同的方式工作，并且导致所有网络节点（1500）和主节点（2000）
接收注册数据。
帐户订阅
TBTCOIN Evolution 初始设计文档 10
用户可以通过在特殊构造的事务的元数据中直接在区块链上注册订阅数据来创
建帐户，这些事务也称为订阅事务处理通过事务输出之一中可证明不可靠的空数
据 pubkey 脚本的最小 TBTCOIN 量。帐户的订阅数据包含该类型的唯一密钥（例
如用户名）和公钥，该公钥允许用户通过签署质询来证明他们是帐户的所有者。
一个帐户维持一个“费用余额”，包括在帐户上刻录的大量 TBTCOIN，用于矿
工以包括块中帐户状态的更新。请注意，该帐户的公钥纯粹用于 身份验证，
不能用作付款地址。帐户订阅数据存储在交易元数据中，因为区块链在保持对订
阅数据的共识方面提供最大的安全性和持久性，并且可以使用现有工具在简化的
支付验证（SPV）级别上访问和验证。此外，由于每个帐户在其生命周期期间需
要在事务中存储的订阅数据量是最小的，因此将此数据添加到区块链的惩罚也是
最小的。此附加数据的数量与帐户注册的数量成线性关系。在交易输出中使用空
数据 pubkey 脚本来注册账户还有一个好处，即资金可以在可证明不可靠的同时
被烧掉，然后可以为账户提供“费用余额”（用于激励矿工包括账户）块中的状
态变化）。
注册
使用样本数据创建新帐户所需的事务元数据包括：
●用户名：字符串，在区块链中为指定的帐户类型设置的总帐户中必须是唯一的
（类似于数据库中的主键）。此帐户的后续订阅交易无法更改用户名。
●公钥：帐户的所有者公钥，通过根据指定的 PubKey 验证其签名，从而为私钥
持有者的帐户所有权证明。这不应该用于在 TBTCOIN 地址中持有资金，纯粹是
TBTCOIN Evolution 初始设计文档 11
出于身份验证的目的。
●签名：由所有者使用指定 PubKey 的私钥签名的前面字段的哈希的签名
●刻录量：这是事务输出中刻录的 TBTCOIN 量。它必须大于或等于注册指定账
户类型的最低费用（例如
用户帐户为 0.005）。超过最低费用的 TBTCOIN 金额将记入“费用余额”，并
在以后用于更新帐户。
订阅状态
可以使用用户名（“Alice”）识别 Alice 的帐户。初始注册事务的哈希也可用于
识别 Alice 的帐户。然后，节点可以通过查询具有给定用户名的所有订阅事务的
区
块链来验证帐户的订阅状态，例如，使用用户名“Alice”返回所有订阅事务，
并检查该帐户是否已注册且尚未关闭。
费用余额
在上面的注册示例中，帐户的当前余额来自帐户上的总燃烧（例如 0.01
TBTCOIN），减去注册用户的最低费用（例如，
0.05 短划线）（加上后面描述的任何账户更新费用）将账户余额计算在 0.005
TBTCOIN。节点通过将初始注册交易中记入的金额与区块链中存在的后续充值
交易相加，然后以区块链中用户扣除的费用形式从账户中扣除借方总和来计算余
额（如下所述） ）。请注意，订户公钥控制下的唯一资金是可用作帐户费余额
的资金，只能通过更新该帐户控制下的对象来支付。订户不能更改其他订户帐户
中的数据（没有他们的私钥），也不能将费用余额转移到另一个帐户。这最大限
TBTCOIN Evolution 初始设计文档 12
度地减少了破解账户的动机。如果订户的私钥被泄露，攻击者只能使用可用的费
用余额来更新该帐户的数据或停用该帐户。
充值帐户的费用余额
帐户所有者可以通过创建“Topup”订阅事务来充值费用余额，其中注册事务的
哈希会烧掉额外数量的 TBTCOIN。在计算当前帐户订阅状态时，已刻录的值记
入订户的帐户余额。它不需要由帐户所有者签名，因此任何人都可以充值帐户的
费用余额。
更改公钥
可以通过提交指定新公钥的“ResetKey”订阅事务来更改帐户注册的公钥。此
交易必须使用此帐户的区块链中的最新公钥进行签名，以提供所有权证明。未以
此方式签署的“重置密钥”交易将被视为无效。
关闭账户
如果订户的私钥被泄露且攻击者更改了公钥，则订户可以创建“CloseAccount”
订阅事务并使用其中一个进行签名。他们以前的公钥。这有效地停用了帐户，并
防止将来对帐户数据进行任何更新。为了验证停用，节点可以检查一段时间（例
如 6 个月）并允许在该时间段内对任何公钥进行停用。这样，帐户所有者就可以
防止对帐户进行未经授权的访问，因为帐户无法重新打开。虽然这也意味着拥有
私钥的攻击者可以停用该帐户。这只会阻止合法所有者使用该帐户更新对象。由
于公钥不持有资金，因此没有价值存在风险，用户可以复制其数据并注册新帐户。
帐户数据
TBTCOIN Evolution 初始设计文档 13
帐户数据存储为名为“对象”的数据结构集合，帐户所有者可以创建和更新这些
对象。对象由 Header 和 Data 部分组成，可以包含名为 Properties 的数据字
段。Header 包含一个包含 Data section 属性哈希的 Property，因此单个 Data
section 可以与一个头匹配（例如，当存储在不同的位置时），并且 Header 本
身可以进行散列以提供所有 Properties 的单个哈希在对象中。帐户所有者通过
使用其私钥对标头属性进行签名来证明对象的所有权。然后，节点可以使用区块
链独立验证。
国家转型
状态转换或转换是由帐户数据从旧状态到新状态的状态更改定义的。每个新的转
换都参考了网络共识所商定的最后一次转换。因为状态转换存储在块中，所以客
户端可以通过在本地散列对象并检查 merkle 树中对象分支的 Merkle 证明来证
明对象是提交给块的 State 的一部分。某些状态转换（称为代表状态转换）可以
存在于使用网络共识修改状态的情况下，例如以足够的共识多数禁止帐户。帐户
纯粹作为一系列状态转换存在，每个转换提供转换序列的加密证明，每个转换数
据的有效性通过其哈希，并证明每个转换中的数据是由帐户所有者创建的。每个
状态转换仅包含在转换中添加或更改的差异数据对象集。
架构
可以存储的对象类型，关于如何验证它们的规则以及具有不同所有者的对象之间
的允许关系，在称为模式的协议中定义。该协议使系统组件和构建在它们上的应
用程序能够通过建立共识规则和从中派生所有对象的原语来有效地进行通信。协
TBTCOIN Evolution 初始设计文档 14
议中的系统范围共识规则包括诸如序列化对象的方法，散列算法和模式规范等细
节（例如 JSON-架构）。Schema 在单个引用 JSON 规范中定义，节点和客户
端
可 以 通 过 连 续 版 本 以 编 程 方 式 或 手 动 方 式 解 释 ， JSON 是 使 用 跨 所 有
masternodes（2000）和客户端的对象进行互操作的本机格式。系统中的每个
对象都可以表示和验证为 JSON 模式中定义的 JSON 对象。每当需要验证，存
储或操作对象时，模式中定义的关系和约束将用作参考。可编程解释的 Schema
规范用于使系统能够将 Object 实现与 Object 验证，中继和存储分离。例如，
区块链模块（2300）代码可以基于模式规则验证对象，同时保持与处理更高层
中的对象类型（例如 API 模块（2100）或客户端应用程序）所需的特定功能无
关。这使得系统可以在将来修改 Schema 并添加新的 Object 类型，而无需重新
设计大量代码，或者让单独的开发人员使用 Schema 设计（在 JSON 中）以及
节点和客户端中的各种实现。使用“动态”设计时协议（如 Schema for Objects）
的一些额外好处包括：
●区块链模块（2300）/ API 模块（2100）是对象不可知的
●用于对象验证的端到端参考规范
●将业务层与数据访问层分离
●面向对象的本质使代码重用
●客户端中使用的多态代码（例如，处理基类属性和派生类约束的重用功能）
●为（例如 Client SDK 对象集）启用程序代码生成
Schema 可以具有实体关系（ER）模型和面向对象编程（OOP）中使用的统一
TBTCOIN Evolution 初始设计文档 15
建模语言（UML）模型的属性。这意味着系统的功能类似于面向最终用户和第
三方应用程序的分散的面向对象的关系数据库应用程序，其中表行是设计时由
Schema 的 JSON 定义定义的对象。
应用程序架构
还可以扩展 Schema 体系结构，以允许第三方应用程序实现自己的子模式，以
集成为自己的需求定制的功能。这些应用程序模式扩展了协议级别的原语，以定
义其用例所需的特定对象和验证规则。例如，应用程序可能要求对象具有最小值
或限于某些字符。应用模式可以被重用或扩展以添加功能，并且还可以通过相互
建立的协议支持与其他应用的交互。可以定义特定于应用程序的共识规则，其基
于事件（例如，对象的值的改变）来执行指定的逻辑。
图。图 6 示出了使用如图 6 所示的体系结构注册新模式的客户端（1000）的框
图。
TBTCOIN Evolution 初始设计文档 16

1. 客户端（1000）向 Masternode（2000）的 API 模块（2100）提交模式注
   册
2. （3610）。API 模块（2100）首先验证应用程序模式（3611）以检查对系
   统模式的遵从性。然后，API 模块（2100）将应用模式写入存储模块（2200）
   中的存储（3612），同时还将其发送到区块链模块（2300），区块链模块（2300）
   将模式注册（3613）广播到加密货币网络（4200）。该广播以与典型的加密货
   币交易相同的方式工作，并且导致所有网络节点（1500）和主节点（2000）接
   收注册数据。
   互通性
   TBTCOIN Evolution 初始设计文档 17
   JSON 是 Schema 中对象的本机格式和 Schema 定义本身。这使得对象可以在
   整个 TBTCOIN 网络和生态系统中从完整节点到客户端进行普遍的互操作，例如：
   ●区块链模块（2300）可以使用 P2P 消息与其他全节点中继对象
   ●区块链模块（2300）可以使用本地存储来存储和检索对象
   ●API 模块（2100）可以使用 RPC 和 ZMQ 从区块链模块（2300）读取和写入
   对象
   ●API 模块（2100）可以处理包含本机 JSON 对象的 HTTP XHR 请求和响应
   ●客户端钱包可以从 API 模块（2100）请求和接收对象，并可以以本机 JSON
   格式备份用户的对象集
   ●客户端应用程序可以以本机 JSON 格式请求和接收对象
   付款对象
   模式还可用于提供对区块链数据的基于对象的表示的访问。这些付款对象来自已
   确认的区块链事务，并可作为系统对象使用。这使应用程序可以在需要时轻松访
   问这些结构，并使对象在内部引用它们。
   付款对象可能包括：
   ●块，Tx 和地址 - 当前 TBTCOIN 协议的当前支付级别中使用的主要对象类型
   ●订阅事务 - 具有订阅元数据的特殊事务，指示帐户的所有权，状态和费用余额
   ●抵押品 - 具有系统中使用的特定元数据的 UTXO（例如，masternodes）
   ●超级块（SB） - 阻止支付获胜的提案对象，这些对象由系统中的矿工确定性
   地创建，在 SB 的 coinbase 交易中将支付作为输出添加。
   TBTCOIN Evolution 初始设计文档 18
   状态序列
   模型中的一些示例类型的对象可以说明如何实现对象功能以及多方交互使用用
   户私人 C2C（消费者对消费者）支付的基本测试用例来观察的状态序列。
   要求作为一个简单的测试用例，用户应该能够注册一个帐户，并请求将另一个用
   户“添加”为联系人，此时另一个用户可以接受或拒绝该请求。如果接受，则两
   个用户都可以在其联系人列表中看到其他用户。如果请求是拒绝，请求用户没有
   再次请求的选项，并且请求的用户不再看到请求。对于此测试用例，可以使用“帐
   户对象”存储数据。在整个“朋友”流程中，每个州的两个用户的帐户对象中存
   储的数据和状态顺序都是必需的。因此，在该测试案例中，可以假设所有对象可
   以使用到目前为止定义的规则读取和写入网络，并且可以假设为无信任的虚拟分
   散数据库，其中所有数据都通过区块链共识来保护。
   集中解决方案
   在用户通过服务器连接的集中式可信关系数据库中，需求可以包括
   1.存储所有注册用户的用户表，以及
   2.UserContact 表，存储由 RequesterKey，RequestedKey 和 Response 组成
   的联系人数据用户（例如 Alice 和 Bob）都可以通过服务器注册 UserKey，这会
   在 User 表中创建两行。如果用户 Alice 想要请求与 Bob 的联系，她指示服务器
   在 UserContact 表中创建一个新行，其中她的密钥在 RequesterKey 列中，Bob
   的密钥在 RequestedKey 列中，并且 Response 列的值设置为 0 ，表示没有回
   应。然后可以通过在没有响应的情况下扫描 UserContact 表以获得对他自己的
   任何请求来警告 Bob，然后将响应设置为 1 表示“否”或 2 表示“是”。如果
   TBTCOIN Evolution 初始设计文档 19
   为“否”，则服务器可以在下次 Bob 访问时过滤掉请求，并且可以阻止 Alice
   向 Bob 重新发送请求。如果“是”，则服务器可以将用户详细信息作为已批准
   的联系人返回给对方。验证由数据库负责，确保只能输入有效的数据类型，通过
   在两个表的主键上使用外键约束来防止重复用户或联系请求。
   分散设计
   为了使用上面详述的 Account，Object 和 Schema 概念以完全分散和无信任的
   方式实现用例，使用了类似于集中/可信数据库模型的方法，但有一些限制：
   ●没有可信任的服务器具有更新数据的权限或访问权限;Alice 和 Bob 都可以通过
   签署其帐户的公钥证明所有权后更新自己帐户中的数据。
   ●数据不存储在单个表中，它存储在用户帐户中的对象中。因此，两个用户都需
   要能够查询引用它们的所有用户的对象。对此的解决方案在于使帐户所有者（他
   们只能更改自己的数据）在他们自己的对象数据中引用数据对象（例如状态转换）
   到外国帐户（例如预期或连接的联系人），然后外国帐户可以检测并响应与原始
   用户相关的自己的对象集中的数据。
   参照完整性
   可以说明，对象之间的引用关系对于维护正确的全局对象集是不可或缺的，并且
   没有会破坏客户端应用程序的重复或无效数据。这提供的好处包括：
   ●启用对象关系验证以确保共识对象集的完整性
   ●防止重复对象实例或滥用架构，例如插入自定义数据
   ●启用对象集的提取到关系数据库以进行集成，分析或仓储方案
   ●通过优化索引策略实现检索优化
   TBTCOIN Evolution 初始设计文档 20
   ●通过索引对象关系来启用存储占用空间的优化
   外键关系是隐含的。这意味着它们无法使用网络共识进行验证，因为密钥位于加
   密 blob 中，只有用户才能解密。在这种情况下，关系完整性依赖于正确的客户
   端实现。客户端应用程序可以使用加密 blob 作为自定义属性的存储单元，并在
   对象和关系中实现自己的自定义功能以进行状态序列互操作。
   状态序列
   通过定义对象和关系，可以解释系统如何为最终用户实现类似数据库的功能，但
   是以分散和无信任的方式，我们称之为状态序列。
   状态序列允许希望交互的帐户组通过仅更改其自己的对象数据来传递信息，其中
   状态以在集中式数据库应用程序中找到的序列类型进行转换，但用户可以更改自
   己的数据。设计模式类似于信号量，其中用户更改自己的状态，引用正在观察与
   其帐户相关的帐户对象的任何更改的外国帐户。
   共识
   Evolution 为 TBTCOIN 协议管理添加了共识规则，通常：
   ●根据账户订购交易的顺序和资金，就账户的存在，状态和所有权达成共识
   ●关于国家过渡的顺序和有效性的共识
   ●关于每个国家过渡期内对象状态的共识
   ●关于 Schema 中定义的对象定义和验证规则的共识
   持久性战略
   在详细说明共识规则之前，基于上述设计确定了 2 个新的持久性要求，每个要求
   具有非常不同的特征：
   TBTCOIN Evolution 初始设计文档 21
   1.无论更改的数据量如何，状态转换（帐户状态之间的转换）都可能需要在更改
   数据时存储少量固定数量的数据（例如~200 字节）。可以将多个对象更新批处
   理到单个状态转换中，并且完整节点必须保留一整套历史转换以验证新状态是否
   满足一致性规则。这些差异的 Object 数据集（称为每个状态转换）可以包含数
   据的散列和数据本身。使用共识规则进行历史验证可能不需要对象哈希值和数
   据，并且可以对其进行修剪（在触发器需要某些数据的最短时间之后，例如 1
   个月）。数据可以是可变大小，有时大（例如大约 10Kb），这取决于构成状态
   转换数据的对象的数量。
   2.活动数据集是表示当前（或“活动”）数据集的对象的数据集。它可以通过遍
   历先前的差异状态转换来导出和提供，并在发生更改数据的新状态转换时更新。
   2 种不同类型的持久性要求具有以下特征。状态转换要求所有节点的完全持久
   性，这些节点大致线性地扩展到事务数量（假设转换被用作促进事务的本质元数
   据）。活动数据集仅保留用户数据的当前状态，因此线性扩展到用户数（通常来
   说）。由于这些原因，可以使用类似于事务的过程将状态转换直接存储在块中。
   存储在块中是理想的，因为需要完全耐用。对块大小的影响相对较小，因为状态
   转换小于正常事务并且创建频率较低。
   对于活动数据集，由于其不可变性，块可能不适合。因此，使用更有效的存储机
   制，其基本上存储基于新块中的状态转换的可变对象集。该机制称为存储模块
   （2200），并在下面进一步讨论。
   国家转型
   状态转换表示状态和元数据的更改顺序，由矿工添加到块中，并包括帐户的先前
   TBTCOIN Evolution 初始设计文档 22
   转换的哈希。
   州过渡期的财产包括：
   ●注册相关帐户的事务的哈希
   ●相关帐户的先前订阅事务哈希，即源状态
   ●提交的数据的哈希值，即目标状态
   ●帐户最新公钥的数据签名
   ●由 masternode 法定人数签署的国家过渡（2400）
   激励
   Masternodes（2000）形成 Quorums（2400），接受和传播状态转换以及存
   储数据的动机是因为 Masternode 奖励依赖于他们对这些转换的处理。这需要
   基于固定时间内的总 Masternode 活动来实现块中的最小状态转换配额。
   矿工增加州过渡到区块的动机是因为他们在每次加入的过渡中获得费用，这些费
   用从账户的统计余额中扣除，并在额外的硬币基础输出中发给矿工，支付区块中
   包含的状态转换的所有费用的总和。
   过渡验证
   每个节点验证转换如下：
   ●检查状态转换是否格式正确并使用正确的语法
   ●根据从引用的注册 tx 哈希开始的关联订阅事务，检查关联的帐户是否有效和打
   开状态
   ●检查账户费用余额是否能承担承诺费用（余额 - 费用> 0）
   ●将费用添加到 coinbase（通过检查区块链从帐户的刻录中扣除）
   TBTCOIN Evolution 初始设计文档 23
   ●验证随转换提供的对象格式正确并使用正确的语法
   ●使用关联模式定义中的规则验证对象属性
   ●验证 Object 头中的关系是否映射到 Active Set 中的有效对象
   ●验证所有者签名是为与帐户的活动订阅状态中的 pubkey 关联的公钥签名的转
   换哈希（即最新的“register”或“resetkey”订阅事务）
   ●检查上一个转换哈希是此帐户的最后一次转换
   ●确定帐户的正确仲裁（2400）
   ●根据仲裁的公钥验证仲裁签名
   块协议
   关于块中添加的状态转换的有效性和顺序的共识规则类似于现有 TBTCOIN 协议
   中的事务的规则。矿工将新的过渡收集到一个块中，在这个块中，它们被划分为
   Merkle 树，只有根包含在块的标题中，使客户能够使用简化的验证过程验证块
   中是否存在特定的状态，并为已关闭的帐户启用状态转换被修剪。在块期间，块
   中所有 Transition 的根哈希值被散列为块头的一部分工作证明，以便就自上一
   个块以来已转换的所有对象的新状态达成共识。该解决方案是可扩展的，因为每
   个帐户每个块只能有一个状态转换，无论更改的数据量如何。这最大限度地减少
   了对块增长的影响，每个帐户的状态已更改为每个块大约 200 个字节。如果每
   天有 100 万个唯一帐户更新对象一次，那么每个块大约会增加 347Kb，而在 2
   分钟的目标间隔内，TBTCOIN 平均每天有 720 个块。
   块头
   块头的格式保持不变，因为 State Transitions 只是一种特定类型的事务，所有
   TBTCOIN Evolution 初始设计文档 24
   事务都经过哈希处理以创建块的 merkle 根。基于此，状态转换的 SPV 验证与
   正常金融交易的验证方式相同。
   块验证
   块验证的其他共识规则包括：
   ●验证每次转换
   ●检查 coinbase 交易费用输出金额是所有费用的总和（交易费用加上通过账户
   费用余额支付的任何费用）
   更改块验证的共识规则：
   ●由于州过渡费是从账户的费用余额中支付的，因此州过渡交易不需要包括任何
   输入或输出
   存储
   存储模块（2200）是对象的存储机制，对象是存储在块中的状态之间的转换中
   公证的数据。
   数据类型
   对于在新块中添加的每个状态转换，存储模块（2200）存储：
   ●针对过渡中所有物体的 merkle 树哈希
   ●对象数据，包含帐户和相关帐户的公共和私有属性
   提交数据
   对象被提交到存储模块（2200），其在差异状态转换内被包括在新块中。通过
   遍历帐户注册后的所有应用程序状态转换，可以解析“活动”状态以表示帐户的
   应用程序数据的完整当前集。只要新块包含转换，就会更新活动状态。
   TBTCOIN Evolution 初始设计文档 25
   对未决状态转换的访问可以允许查看未提交的更改。
   图。图 4 示出了第 2 层存储同步（3400）。当通过 Masternodes（2000）的
   区块链模块（2300）接收到块（3410）时，存储模块（2200）解析该块以进行
   状态转换并识别其没有相关数据的任何块。然后，Masternode（2000）的存储
   模块（2200）通过 Masternode 网络（4100）与其他 Masternode（2000）
   连接来同步 Masternode 存储（3411）以检索它所需的任何数据。
   可扩展性
   TBTCOIN Evolution 初始设计文档 26
   存储模块（2200）提供可扩展的解决方案，因为节点仅需要保持帐户的应用程
   序数据（活动数据集）的当前状态并在新的状态转换上更新它。这意味着可以修
   剪用于许多差异状态的数据，例如，用户更新其配置文件 100 次导致仅在配置
   文件对象的 1 个副本存储在节点上。
   例外情况是，根据模式中 Object 类型的剪枝深度定义，可能需要在一段有限的
   时间内保留一些差异状态以进行块验证。此设计针对日常用户访问模式。例如，
   典型用户可能不关心查看他们的个人资料信息的所有过去修订，他们只关心其他
   用户将看到的活动集。如果用户需要来自非活动集的数据修订并且它们是从网络
   中删除的，则只需要修订单个副本来恢复状态，因为可以针对块中的关联状态转
   换验证数据的哈希值并根据用户的订阅交易验证签名。这意味着想要保留修订版
   的用户可以从诸如本地备份（客户端可以配置为保留）的位置或列出历史数据的
   网站恢复数据，并验证对象在区块链上的真实性和存在性。或者，希望保留每个
   修订版的用户可以运行自己的完整节点，并在其帐户上禁用修剪。实际上，数据
   以块为单位进行公证，公证数据存储在并行存储中，并将其修剪为与最终用户数
   量相关的集合大小，而不是它们添加到链中的事务数量。使用扩展每个块的辅助
   存储的关键原因是块最适合保留状态之间转换的完整数据，而存储模块（2200）
   的主要用例是维持当前的“活动”状态。帐户的应用程序数据，在某个深度修剪
   已弃用的状态，例如在 1 个月后（取决于模式中的对象定义）。
   存储架构
   如何在存储模块（2200）中存储状态转换的要求，即存储与块中包括的帐户状
   态的转换相关联的对象的差异集，类似于在数据库表中存储行，但是在保持过去
   TBTCOIN Evolution 初始设计文档 27
   版本的数据库中新转换到达时的行在这种情况下，添加的最后一行被视为活动
   行。使用该原理，可以注意到存储模块（2200）中的所有对象都由帐户拥有。
   通常，对象也与应用程序标识相关联。它们在组织存储策略方面共同构成了对象
   的顶级分区或维度。在某些情况下，对象可能仅与帐户关联，并且与特定应用程
   序标识无关。
   存储模块（2200）中的第二个维度来自于数据与新块一起添加的事实，其中对
   象通过与该转换相关的所有对象的根哈希与块中的状态转换相关联。当帐户与应
   用程序架构交互时，在存储模块（2200）中为与该应用程序关联的帐户数据创
   建新分区。作为帐户所有者创建状态转换，帐户中相应的新对象或更新对象作为
   新行提交给存储模块（2200），第一行表示帐户的所有过去数据转换的已解决
   活动状态。二维状态转换存储结构可以被建模为数据立方体，其中注册账户的总
   集合形成 X 轴，并且 Z 轴表示导致当前活动状态的对象的历史添加和更新。通
   过按模式类型对对象进行分组，可以在 Y 轴上的数据立方体中创建第三个维度。
   这可以基于类型的不同使用和验证要求实现优化，例如构建和验证对象评级的状
   态转换将需要矿工准备新块以快速搜索评级触发对象以最小化验证成本。
   数据分区
   存储模块（2200）数据也可以在节点上基于每个帐户进行修剪，而无法随机或
   基于已关闭或长时间没有活动的帐户存储完整的对象数据集（例如， 12 个月，
   18 个月，2 年或 5 年）。在这种情况下，只需要一个带有数据副本的节点来恢
   复它，或者可以从备份或归档源恢复数据。以这种方式划分数据的一个限制是可
   TBTCOIN Evolution 初始设计文档 28
   能需要包含外键关系的 Object 头来历史地执行关系验证。例如，为了验证从
   Alice 到 Bob 的联系请求，共识规则规定 Bob 必须存在以维持存储模块中的整
   个对象集的关系完整性（2200）。将来，可以根据对象类型修剪 Transitions。
   例如，可以根据 Object 的 Schema 定义中指定的参数来修剪对象转换。
   使用非正式的临时方法进行分区而不是正式的分片策略的一个原因是正式分片
   会削弱数据的持久性，因为攻击者可以利用存储该数据的节点子集的知识来定位
   特定数据。正式分片的开销还需要在节点周转时组织和重建分片，而不是节点，
   例如，当它们在磁盘空间不足时随机修剪旧帐户。
   分散的 API
   API 模块（2100）是分散式应用程序编程接口（DAPI），它使系统最终用户和
   应用程序能够直接连接到 TBTCOIN P2P 网络，以使用支持 HTTP 的客户端（如
   浏览器）读取/更新帐户数据和读取/创建事务和移动应用程序。
   网络架构
   API 模块（2100）是 TBTCOIN 网络设计的重新架构的一部分，以引入客户端安
   全和直接访问 P2P 网络的方式。在当前的 TBTCOIN 设计（继承自 BITCOIN）
   中，没有像大多数服务模型（例如 Client-Server）中典型的客户端的协议级别
   定义。在比特币中，每个用户都希望通过 P2P 节点访问并直接作为对等方进行
   交互。这在 BITCOIN 的早期版本中是可以理解的假设，其中每个节点都开采，
   审核并维护区块链的完整本地副本。扩展到浏览器/移动应用程序以及尝试与更
   多主流系统集成，使得 P2P 协议成为增长的障碍。用户可以在现有体系结构下
   TBTCOIN Evolution 初始设计文档 29
   操作 P2P 节点的不同模式，最接近客户端的是用户操作节点而没有区块链的副
   本并且使用 SPV 验证而不是 P2P 消息传递。这实际上是一个自私的节点，并且
   当通过集中式代理调解时被称为“精简客户端”（例如电子）。
   由于这些原因，API 模块（2100）是与现有 P2P 网络协议相邻的新客户端协议
   的端点，其中客户端是运行软件的任何设备，其使用正确的互操作通过 HTTP
   连接到 API 模块（2100）。协议。
   安全模型
   API 模块（2100）及其客户端的安全模型基于这种非 P2P 自私的 SPV 节点模型，
   客户端可以连接到节点并将数据添加到区块链（事务和转换），而无需作为对等
   体参与和使用最受支持和审查的协议，HTTP。客户端还可以访问网络中的任何
   节点，以使用 SPV over HTTP 验证事务和转换数据。
   API 模块的安全模型基于客户端用户对私钥的完全所有权，私钥永远不会进入
   API 模块（2100）。这可以防止 API 模块（2100）访问用户资金。API 模块节
   点可能不提供代码或内容（例如，JavaScript 或 HTML）到浏览器。API 模块
   （2100）纯粹是基于 HTTP 的 XHR API，由确定性构建的开源客户端访问。API
   模块（2100）节点利用 Masternode Quorums（2400）（例如，10 个中的 6
   个）来确认客户端请求的验证和客户端响应的内容。Quorums（2400）为未提
   交的客户端会话数据提供冗余，并减少恶意节点浪费客户端时间的可能性以及客
   户端随后使用 SPV 无效的响应（客户端 SPV 进程外部应用于客户端的仲裁
   （2400），即网络范围） 。
   网络拓扑结构
   TBTCOIN Evolution 初始设计文档 30
   然后，TBTCOIN 的连接拓扑在网络中分成 2 个环。当前的 P2P 网络拓扑（技术
   上是部分连接的网格）成为由 P2P 节点组成的内环，该 P2P 节点验证，持久并
   向其他 P2P 节点提供区块链。外环由单独的客户端组成，这些客户端直接连接
   到服务于 HTTP 请求的抵押 P2P 节点集群（客户端/多节点服务器），而不是连
   接后端 P2P 的中间代理服务，我们称之为客户端到对等（ C2P）网络，技术上
   是客户端到抵押的 Peer-quorum 网络，在 TBTCOIN 中也称为 Tier-3。这种结
   构的一个问题是缺乏对完整节点支持非常大量的自私节点的激励。在一些加密货
   币中，激励模型是纯粹基于 P2P 的，即总体上 P2P 网络在网络中存在足够的节
   点播种（作为接收入站连接的中继完整节点）以处理来自相对少量的 leechers
   （主要是桌面的）的额外流量。最终用户和应用程序连接的钱包，集中代理，如
   SPV 代理，网络钱包和支付处理器。通过代理（即大多数不希望直接参与或支
   持 P2P 网络的终端用户）消除了需要通过代理连接的 leechers，从而导致自私
   节点大量增加（现在可以直接访问网络的客户端）通过集中式 SPV 或 Web 钱包
   代理），运行完整节点的成本增加，并且 P2P 网络的激励模型被打破。在 TBTCOIN
   中，节点被激励以提供非挖掘服务，但不是专门用于处理这种新拓扑，即，当前
   节点仍然可以得到奖励，而不会诚实地为这些最终用户提供服务。为了解决这个
   问题，可以将抵押节点（Masternodes）奖励改为临时关于他们添加到区块链
   的客户数据量（技术上，账户状态转换的数量），这为选择运营节点的用户提供
   激励。提供 HTTP 客户端和确定性方法，以确保只有提供足够（和诚实）客户端
   服务级别的节点才会得到奖励。
   客户端协议仲裁
   TBTCOIN Evolution 初始设计文档 31
   客户端可以使用两种连接模式：
   -被动会话 - 匿名，只读访问帐户 API（查询帐户数据），以及对支付 API 的匿
   名读/写访问（查询区块链和创建交易）
   -交互式会话 - 被动会话的所有功能以及假名更新用户持有私钥的帐户数据的
   功能。
   当帐户所有者想要从客户端使用 API 模块（2100）启动会话（即更新其帐
   户状态）时，需要执行几个步骤。请注意，在 TBTCOIN 中读取任何 Account
   上的数据时不需要这样做，因为客户端可以匿名查询任何 API 模块节点的数据。
   此外，如果用户希望使用区块链和相关数据的完整副本完全验证所有交互，则这
   可能不会妨碍用户从本地完整节点访问 API 模块（2100）。第一步是获取有效
   Masternode 列表（2000），第二步是确定客户端必须连接哪些 Masternodes
   （2000）以更新其帐户状态。
   获取 Masternode 列表
   客户端可以连接到TBTCOIN网络中的任意数量的节点以获取Masternode列表
   并使用 SPV 验证其内容，使用与 SPV / Electrum 客户端基本相同的安全模型，
   但具有更高程度的分散，即客户端可以访问任何节点 TBTCOIN 网络中的节点，
   而不必通过一小组集中式第 2 层服务器进行代理，并且由于该访问是基于 HTTP
   的，因此可以从任何启用 HTTP 的客户端（例如 Web 浏览器）获取客户端可以
   使用社区设置的 HTTP DNS 种子来构建 Masternodes（2000）的初始列表，
   以与今天的核心钱包相同的方式进行连接。一旦连接到一些初始 API 模块节点，
   客户端就可以检索所有 Masternode（2000）及其 IP 的列表，并使用链上确定
   TBTCOIN Evolution 初始设计文档 32
   性 Masternode 列表上的 SPV 验证活动状态，以避免来自 DNSseed 的欺骗节
   点。
   法定人数
   一组确定性选择的 masternodes（2000）形成了一个法定人数（2400），可
   以就诸如状态转换之类的交易的有效性达成共识。法定人数
   通过使用法定人数的链式公钥可验证的方式集体签署，表明接受州过渡。
   Masternode Quorums（2400）由区块链模块（2300）构建和操作。不同大
   小（例如 10,50,200）和批准阈值（例如 6 个）的法定人数（2400）
   可以存在 10,30 的 50,125 中的 200）以支持不同的要求。基于访问仲裁（2400）
   的账户的注册交易哈希来选择客户的仲裁（2400）。一旦客户端构建了有效的
   活动 Masternode 列表，他们就可以确定它们的仲裁（2400）并连接到它。
   图。图 3 示出了获得关于数据更新的 Masternode Quorum（2400）一致性的
   框图（3310）。当 Masternode（2000）的 API 模块（2100）接收到数据更
   新（3310）时，在根据相关模式验证结构之后，它将其发送到区块链模块（2300）。
   区块链模块（2300）从 Quorum（2400）中的 Masternodes（2000）组请求
   法定人数批准（3311）。一旦最小数量的 Masternode（2000）批准该改变，
   则 Quorum（2400）的成员发送消息，指示 Quorum（2400）批准该改变（3312）。
   当请求批准的 Masternode（2000）接收到法定人数批准（3313）时，它继续
   处理数据更新。通常，这需要广播与数据变化相关的事务以包括在区块链中。
   客户创建的状态转换
   客户端（1000）将组装的状态转换和相关对象提交给 API 模块（2100）以请求
   TBTCOIN Evolution 初始设计文档 33
   包含在块中。API 模块（2100）将状态转换发送到
   客户的法定人数（2400）获得多数共识，并在收到法定人数签名后将其传播到
   TBTCOIN 网络。
   法定人数创造了国家转型
   创建
   将来，可以在交互式客户端 - 仲裁会话期间创建来自用户的状态转换，在此期
   间，指定的仲裁（2400）以设置的间隔（例如，大约 1 分钟，2.5 分钟，5）缓
   存对帐户的数据对象的任何更新。分钟或 10 分钟）将这些表示为表示状态转换
   数据结构中节点的新状态的批处理。如果经过验证，状态转换将其数据包含在矿
   工的一个区块中，并从账户的统计费用余额中扣除费用。这些数据（由块中包含
   的转换公证）将包含在 Masternodes（2000）的 Object Storage 中，它必须
   促进最小状态转换配额以接收它们的块奖励部分。间隔（例如，由法定人数
   （2400）进行的 2.5 分钟状态转换传播）称为“心跳”，最小化转换到区块链
   上的账户的频率，同时仍然经常发生足以提供可用性的频率。客户端可以随时控
   制此频率或提升状态转换，以便在下一个块中“保存”其数据。
   授权
   一旦 Quorum（2400）组装了状态转换，它就会使用 Web 套接字回调或作为
   轮询响应的一部分将其发送到帐户的连接客户端进行授权。然后，每个客户端将
   其本地对象集的 merkle 树的根哈希值与状态转换中的根哈希值进行比较，如果
   有效，则使用其帐户私钥对状态转换哈希值进行签名，然后将其发送回仲裁
   （2400） ）谁将其传播到 P2P 网络。
   TBTCOIN Evolution 初始设计文档 34
   触发器
   触发器是在节点中具有硬连线功能的对象类型，例如评级帐户，预算周期和主节
   点支付。基本上，共识规则取决于 Schema 中少数类型的数据。实际的派生对
   象类型可能没有连线，但只是在 Schema 中表示某些对象是导致触发器的类型。
   例如，如果用户在其 UserApp 对象的标头中对应用程序进行评级，则该对象在
   模式中具有一种类型，表示它具有提高评级的标头。节点可以保持与特定架构无
   关，但是当对象具有触发器类型时，请将这些对象数据用于预定义的触发器功能。
   请注意，触发器对象通常具有更高的剪枝深度。例如，所有预算对象需要保留至
   少 1 个预算周期（大约 1 个月，2 个月，3 个月，6 个月或 1 年），以便节点能
   够使用共识规则验证超级块。
   评级
   评级是系统固有的。它们为用户提供了一种民主和分散的方式，可以将分数应用
   于他们使用的其他帐户（例如用户和应用程序），并报告违反 TBTCOIN 服务条
   款的用户。如果达到最低共识，那么可以通过 Masternode 投票关闭这些账户。
   请注意，关闭帐户永远不会导致帐户所有者丢失资金或阻止帐户转移资金。帐户
   被禁止创建任何状态转换，因此无法创建或更新数据对象。作为通过委托状态转
   换的缺席者帐户评级的示例，该过程是：
   ●Alice 和 Bob 都为他们的 Charlie 应用程序的 UserApp 对象设置了评级，该应
   用程序正在销售小部件。
   ●矿工收集 Alice 和 Bob 更新到块中的状态转换，并检测 Object 数据集中是否
   存在 Rating 值
   TBTCOIN Evolution 初始设计文档 35
   ●矿工必须统计评级（基于迄今为止查理应用程序的总评级，平均评级，以及此
   区块中的任何新评级）。
   ●因为查理没有在这个区块中更新他的账户，所以矿工必须在他缺席的情况下创
   建一个代表状态转换，这会更新元数据但是将数据转换保留为空（或者只是查理
   的最后状态转换的哈希值）
   验证节点重复此过程以验证矿工是否已为包含Charlie帐户评级的矿工包含的任
   何州过渡包括代表州过渡
   这激励矿工创建代表状态转换数据，即使他们没有直接索取费用。这是因为他们
   不能在没有代表状态转换的情况下包括 Alice 和 Bob 的帐户的状态转换来处理
   Charlie 评级元状态的变化。
   Masternode 股票
   Masternode 共享可以使帐户持有者组合在一起，以抵押 Masternode 帐户运
   营商，该运营商链接到物理 Masternode 实例。在此架构设计中，共享所有者
   确定地收到它们的奖励份额，但只有 Masternode（MN）帐户持有者可以代表
   该节点投票。
   希望获得 MN 份额的用户（例如，Alice 和 Bob）向他们拥有的地址发送一个金
   额（例如每个 500 TBTCOIN），并使用特定元数据将其表示为抵押交易。该交
   易使用 CheckTimeLockVerify 来防止资金移动 30 天。这是为了最初降低 MN
   股东的周转率。如果他们与特定的 MN 运营商待在一起超过 30 天，他们可以立
   即转移资金。然后，Masternode 帐户所有者（例如 Charlie）通过将交易哈希
   值添加到其数据集中的新 Collat eralStatus 对象（或更新现有的 Collat
   TBTCOIN Evolution 初始设计文档 36
   eralStatus 对象（如果存在））来“声明”Alice＆Bob 的抵押交易。抵押品交
   易只能由一个 Masternode 账户申领。为了验证 Masternode 帐户是否完全抵
   押，节点检查帐户的 Collat eralStatus 对象数据，如下所示：
   ●对象中列出的抵押交易未使用，并且未被任何其他 Masternode 帐户声明。
   ●抵押品交易至少达到最低 MN 要求或最低抵押要求（例如 5000 TBTCOIN）
   每个 Masternode 的最大份额可能有限（例如 20），但个人份额可以是超过 5
   TBTCOIN 的任何数量。Masternode 帐户所有者必须自己提供至少 10％的总需
   求，以增加设置恶意 masternode 的成本。请注意，共享所有者不会因为不共
   享私钥而面临资金风险。
   治理
   有 两 个 触 发 器 对 象 用 于 治 理 预 算 周 期 ： AppBudgetProposal 和
   MasternodeBudgetVotes 对象，处理预算建议创建和 Masternodes 投票。然
   后，跨全局对象集的这些对象的状态确定节点的超级块创建和验证，其每月向获
   胜的提议支付 1％的块奖励（使用现有的用于 SB 验证的共识规则）。
   提案创建
   应用可以通过创建新的 AppBudgetProposal 并设置 Name，Description，
   URL，PayDate，NumPayments，PayAmount，PaymentAddr 的属性来创建
   新的预算建议。
   表决
   要对提案进行投票，Masternode 帐户所有者使用对 AppBudgetProposal 的
   引用更新其 MasternodeBudgetVotes 对象，并通过 Vote 属性添加其 yes / no
   TBTCOIN Evolution 初始设计文档 37
   / abstain。请注意，MasternodeAccount 必须支付州过渡投票的费用（除非
   可以找到解决方案）。
   超级块
   超级块可以由系统中的矿工确定性地创建，由矿工查询以及自上一个预算周期期
   间包括在块中的状态转换内的所有 MasternodeBudgetVotes 对象并计算投
   票。然后，矿工可以在 coinbase 交易中添加适当的相关支付（使用当前系统的
   预算确定规则），并重复该过程以验证节点。请注意，节点必须将所有治理对象
   的完整对象数据维护到一定深度（例如，直到 1 个月才能修剪）。
   系统管理员
   管理系统（即，停用订户对象）将是实现一定百分比的 Masternode 投票的简
   单功能（例如 5％，10％，15％，20％，25％，30％，35％，40％，
   禁止账户的 45％，50％，51％，或 66％和 2/3％）。
   要禁止帐户，用户可以使用类似的系统“报告”帐户以评级。然后，Masternode
   管理员可以使用他们的 AdminVotes 对象对这些禁令进行投票，矿工必须为被
   投票的账户创建一个委托状态转换，并在下一个区块中使用禁止评级和总计。当
   投票达到禁令级别时，下一个区块的矿工必须为报告的账户设置一个代表状态转
   换，并将状态设置为“已关闭”，以便通过共识规则接受该块。
   TBTCOIN 发行机
   TBTCOIN 采用了 POW(工作证明）1%+SPOS(主节点服务证明）99%， 发行
   机制，其创新的治理系统。1%算力工作证明，即 99%主节点权益 1%社区执行
   维护。 9%算力权益 TBTCOIN 采用了 X11 算法为利用了 11 个科学散列算法序
   TBTCOIN Evolution 初始设计文档 38
   列用于工作量证明，90%主节点权益的实现方式是通过持有一定数量 下限的
   TBTCOIN 的主节点实现的。这种有投票权的节点被称为主节 点，主节点本身并
   不参与挖矿，主节点除社区投票外，本身会提供证/闪电交易/加密隐私交易等服
   务 1%社区执行维护 TBTCOIN 网络允许任何人提出议案支付 5TBTCOIN 的代
   价（避免充斥垃圾提案），议案在主节点投票通过后即可动用 1 的社区执行基金。
   也就是说做推广并不需要动用自己的资金。 如果出现某个主机节点还是纯算力
   节点故意作恶的情况，它会被从网 络内除名，同时也损失收益。这在大多数情
   况下能直接从经济博弈上 迫使节点善意合作，这一治理模式可以有效减少挟算
   力拒绝升级的情 况。因为通过了投票的议案，算力拒绝的话，该算力会被网络
   开除。
   TBTCOIN 发行量数据
   区块产生时间：2 分钟
   区块奖励数量：20 枚
   主节点奖励：99 %
   主节点数量：5000 枚
   TBT POW 奖励：1 %
   超级块奖励：1 %
   减产区块高度：500000
   创世区块奖励：5000000 枚（3000000 枚用于公开发售，2000000 枚用于社区
   建设奖励）
   总发行量：25000000 枚
   TBTCOIN Evolution 初始设计文档 39
   总结
   主节点：加密数字货币的未来 TBTCOIN 的主节点网络是加密数字货币领域的一
   项重大创新。它不仅 优化了现有的 TBTCOIN 网络，并且为其未来发展提供了
   经济激励。 TBTCOIN 的主节点网络其奖励机制对网络运转的重要性。主节点网
   络 的相关设计意味着它将引领加密数字货币的未来。