这项工作旨在确定所分析的对象是否为DLT系统。 所获得的结果非常适合用于各种项目的比较分析，从管理结构到交易引用链接的定义。
分布式分类帐技术是一种信息存储技术，其主要功能是根据共识算法进行数字数据的共享和同步，在全球不同点的等效副本的地理分布以及没有中央管理员的情况。
技术分析
协议层
创世记协议级别，是指在网络启动之前需要开发和运行的过程。
对其他网络的依赖。对其他协议的依赖取决于所分析项目的边界。 这确定系统是可以作为独立系统运行（自给自足）还是依赖于另一个网络。
表1.对其他系统的依赖
程式码该代码可以基于现有框架，也可以从头开始编写。 最受欢迎的框架是来自开源系统（比特币/以太坊）的代码库。 还有由数字资产/ Clearmatics和SETL等项目提供的封闭平台的封闭源数据库。
表2.程序代码
定义规则规则的引入是指DLT系统应在其上运行的一组规则的定义。 该过程可以由不同的参与者执行，并且对于特定的DLT系统是独立的。
协议更新
协议更新适用于允许您修改系统规则的现有过程。 更新协议可能包括消除技术错误（错误），提高系统的安全性和功能性，以及扩展或限制现有协议规则。
协议管理协议管理是指一组决策过程，使您可以有序和合法地更改协议。 这是更广泛的项目管理的子集，它涵盖了描述和定义协调与动作的完整过程和规范集，但不能正式集成到DLT系统中。
提议对协议进行任何更改的一个重要因素是采用和批准协议的方式，或者换句话说，如何在网络参与者的建议下提供合法性。 由于在这种情况下合法性是一个社会概念，因此识别DLT系统中可能存在的某些“社会政治”关系似乎是合理的。
表3.协议管理
协议管理有多种形式，通常不清楚。 最初，DLT系统的特点是无政府主义力量（免费），没有公司或一群人负责决策。 最重要的是，它们类似于开源流量管理过程。 协议更改讨论的一个示例可以是在聊天/ GitHub /会议中开发人员的交流。 在独裁条件下，讨论更改的过程可能完全相同，但是最终决定权将由一个人做出。 在某些情况下，协议管理表格可以由不止一种类型的板定义。 例如，EOS区块链充当由拥有EOS资产的用户选择的区块制造商的联合。 投票权重由地址上持有的代币数量决定。 这种类型的政府将协议分为两方：“精英”用户和“普通”用户，并具有等级制的特征：联邦，民主和富裕。
链上管理意味着在数据级别包含管理功能。 目标是使治理正规化，从而增加合法性并避免由于争端或协议更新不一致而导致网络碎片化。 已经为DLT系统开发了多种多样的链上投票计划，范围从社区情绪晴雨表到全民公决。 但是，通常，链上管理功能只是其他形式的管理的补充。
协议变更更新协议的实际过程意味着：
- 如果是开源项目，则在GitHub上更新代码；
- 客户端更新（如果它是封闭源协议）；
- 使用旧程序代码的客户可能被认为无关紧要且被列入黑名单；
- 在旧程序代码上运行的客户端形成一个分支，这导致了该协议的替代版本的创建。
表4.协议修改表
不同的DLT系统使用不同的方法来更新网络。 例如，以太坊接受捐赠以资助发展，并使用由赠款资助的开发商的软件来更新网络。
网络层
DLT协议网络是协议规则实施的直接结果。 该网络由参与者的协调工作和遵循技术标准（协议）的流程组成，并积极参与特定通信渠道上的数据和信息交换。
沟通过程
在DLT系统中的参与者之间传输数据的过程。
网络访问接入网络意味着连接协议的可能性，它可以是受限制的或不受限制的。
- 无限访问 -任何用户都可以随时自由连接/断开连接；
- 受限访问 -只有某些用户可以连接到网络，通常这是由指定实体控制的。
通常，具有无限访问权限的系统对参与者的数量没有限制，而封闭的网络可以设置有限数量的参与者。
通常，参与者可以通过启动完整的节点来直接访问网络：他们被认为是具有大量权限的“精英”，因为他们可以发送/验证和传输记录数据。 网络参与者还可以通过运行“轻客户端”来间接访问网络，该“轻客户端”通过特殊服务（API）连接来向完整节点请求数据。
表5.网络访问表
通常，系统越开放，就越容易受到攻击。 特别是，当攻击者创建许多伪造的身份来增加对网络的影响时，这些系统容易受到Sibyl攻击。
当攻击者获得访问权限或隐藏协议中的更改并创建许多错误身份时，Sibyl攻击是一种攻击。
由于身份识别是外来的（即“真实”）属性，因此DLT系统无法阻止这些攻击，因此它必须依赖外部参与者（认证系统）或降低攻击可能性的机制（PoW / PoS）。
传送资料数据传输是将数据分发到连接的节点的过程。 数据可以是原始的/未格式化的，也可以标准化为特定格式（例如，以事务或记录的形式）。 数据可以传输到每个节点（通用扩散），或仅传输到节点的特定子集（多通道扩散）。 在后一种情况下，数据的分发通常仅限于交易的参与者。 这使您可以创建用于数据传输的“通道”，通常这意味着分片/闪电网络。
早期的DLT系统（例如比特币，莱特币）使用通用数据分发模型，该模型仍然是最受欢迎的数据分发方法。
为了保持公司的匿名性和隐私性，后来的系统具有多渠道扩散模型（例如Hyperledger Fabric，Corda）。 其他系统（例如Cosmos）被设计为充当集线器，以便独立的DLT系统可以通过分片互连。
表6.数据提交表
多渠道数据扩散的一个示例是，并非所有网络参与者都必须参与有关渠道状态的共识：只有渠道参与者必须对存储在该渠道中的数据达成一致（“本地”共识）。 这与具有全局数据分发功能的系统明显不同，因为每个单独的节点都必须就系统的全局状态达成共识（“全局”共识）。 无法达成某些节点的共识可能会导致其断开连接或创建分叉。
交易创建交易创建过程包含一组指令，这些指令将在交易添加到网络后执行。 创建交易可以是无限的（即所有人都可以访问）或限于某些参与者。 交易是由用户使用其私钥对消息签名而创建的。 用户可以使用各种接口来创建交易并将交易发送到网络（例如，PC和移动钱包）。
交易处理事务处理描述了将未确认事务添加到已确认事务列表所需的一组操作。 在将事务列表添加（“确认”）后，该事务被视为（初步）有效，这将导致执行嵌入在事务中的指令。 但是，仅凭确认单还不足以使该交易成为后续操作的基础。 在系统可以使用交易输出之前。
图1. DLT系统中的事务处理
记录服从DLT系统中使用的特定共识算法。 这包括确定提议的记录是否有效以及拒绝无效条目（例如，有缺陷或不兼容的条目）并在不同但同样有效的条目之间进行选择的过程。
记录候选人区块的创建者发送将来可以移至已确认交易列表的记录，该创建者从未确认交易列表中选择它们，并将它们组合在一起以形成候选项，以写入已确认记录列表。 有两个属性可以确定发送记录的权利以及将其将来包含在已确认记录列表中的权限。
表7.记录表格
由于记录需要达成共识，因此它们必须遵守协议规则。 首先，它们必须正确格式化，并且不包含无效或无效的事务。 此外，每个条目都应包括指向前一个条目的链接/指针，并在必要时使用PoW或任何其他难以进行Sibyl攻击的方法。
共识算法可以根据其复杂程度（电力/金钱成本）进行分类。 在达成共识所需的资源中测量了具有无限复杂性的算法。 例如，在计算PoW比特币的情况下，随着散列数据的复杂性，找到正确解决方案的难度会增加。 恰恰相反，其他算法工作（例如，拜占庭将军/ BFT任务）不需要大量的计算成本，并且复杂度有限。
在开放系统中，应提供减少Sybil攻击机会的算法。 专用（封闭）系统会在允许每个参与者访问网络连接之前对其进行检查，以防止遭受攻击的可能性。 在封闭的系统中，一组节点倾向于选择一个将创建块的节点。
解决冲突造成冲突的原因有几个：
- 参与者不同意该协议的哪个版本；
- 参与者不同意已验证的交易。
如果出现比特币网络中第一点的情况，则网络会选择最长的区块链为有效链，而忽略较短的区块链。 在Tezos中，块的有效性是由不同的“块权重”确定的，这里的权重是它从放样机随机收到的验证者的“批准”数。
任何共识算法都会带来很多折衷
表7.交易处理动机的形式
验证方式验证是指确保主体独立地就批准的记录集得出相同结论的必要过程集。 这包括：检查已发送的交易/检查记录的数据/检查网络的一般状态。 这是与非DLT系统的重要区别，因为它为参与者提供了对系统进行独立审核的机会。
交易验证验证交易是为了确保单个记录符合协议规则，然后再将其转移到其他实体。 这包括：交易格式的正确性，适当签名的存在以及交易与其他交易不冲突的条件的满足。 某些系统可能会运行禁止交易直到特定时间点或其他原因的系统。 通常，这些条件通过智能合约来满足。
当一个参与者或几个参与者结合其计算能力（语音）并比协议其余部分更快地处理网络上的事务时，攻击率为51％。 此类攻击使您可以进行无效交易并将其记录为有效。 使用PoW的系统尤其容易受到攻击
检查记录通过检查正在发送的记录，可以确保记录符合协议规则。 如果建议的条目被识别为有效，则将其添加到已确认条目的列表中，并中继到网络中所有连接的节点。 尽管此过程在每个系统中都不同，但是通常，按照一般原则，它在所有地方都相似，例如，检查是否已对事务执行PoW工作。 发送的交易的验证和验证器随后的记录的结合提供了对整个系统的独立审核。
交易记录确认的交易/记录不一定是不可逆的。 写不可逆性可能是概率性的（例如，在基于PoW的系统中，重新计算所有记录的事务是不切实际的），或者是包含必须分配给每个事务的“检查点”的系统。 已确认的记录可能被称为不可变的，但已被“预先确认”的记录可能会被取消。 在克服了从“预确认”到“已确认”的过渡状态后，预确认记录将保持不变。
图2. DLT系统中的事务处理
图2描述了在事务处理过程中发生的过程的示意图。 首先，用户创建一个事务并将其发送到网络。 每个节点都会检查事务是否符合协议规则。 如果认为正确，则该节点将事务添加到其列表（内存池），该列表存储所有未确认的事务，等待添加到已确认事务的列表。
在交易处理阶段，节点从其内存池中随机选择未确认的交易，然后将它们组合在一起，成为“预批准”交易的列表。 接下来，将根据共识算法检查交易，以将这些交易提供给所有其他网络参与者。 节点将查看收到的交易及其内容；如果交易通过验证，则交易将添加到节点列表中。 每个节点的交易清单最终会发送到一个最重要的已确认交易清单，并将被视为已完成。
但是，已确认的交易由于有其他交易而可能被“取消”，这意味着在结算阶段可以取消交易-在这种情况下，它们作为未确认的交易返回到节点，等待创建新的交易清单。 “结算”阶段的交易处理时间取决于单个系统的设置。 一些系统实现了对交易及其不可撤销性的即时记录，但是，某些协议在理论上可以取消交易的意义上具有“概率”完成。 然而，实际上，由于与PoW关联的节点的成本可能会很高，因此随着每个新事务的添加，此操作的可能性会降低。 尽管交易处于“结算”阶段，但不能将其视为“已完成”。 , , , .
« », «long-range». , ( ), , «», . « » — , . , «» . , .
8.
, . . , , .
, .
. , , , (, , ) -.
, - . , , , , (. ). , « – state channel» , .
9.
-. - . -. , , , , . DLT-, (). , Bitcoin Script, , - . – Stateless. Ethereum (Solidity), Tezos (Michelson) EOS (WebAssembly) – -, Bitcoin Monero, , .
10. -
, , . , – on-chain off-chain ( ). On-chain . , , (EVM – Ethereum), . - on-chain , « ».
Off-chain , , . , , on-chain, , . , (Hybrid) , , Plasma Ethereum. , , Cosmos, «», .
11. -
参考文献, DLT-, . , – . , DLT-, . , , , , . , DLT-, -, , . , – .
: , , .
() , , , «» . , Bitcoin, , . , . () , , , . , , . , , : – . , - – , . - , - (« »).
12.
结论
, DLT-. , , , , .
