当前位置:首页 > 区块链新闻 > 正文

LTO Network(LTO网络):交互合约

来源: 互联网时间:2019-03-05 08:00:01

业务流程建模是任何大中型组织的常见策略 。通过工作流程过程的可视化可以对其进行分析、改进和自动化 (图 1) (figure 1)。这些模型人类与计算机都可以理解,与仅使用自然语言或编程语言编写的过程不同。

对于组织之间的合作,建模不仅是为了改善沟通。各方必须具体说明工作程序,这将作为具有约束力的协议 [8];这就是 LTO 平台所谓的 交互合约。

LTO 平台给每一个交互合约都会创建一条临时性的私有区块链。此链的目的并不是作为不可改变的账簿,而是保留各方组织都拥有最新的会签历史事件和共享状态。

1. 智能 vs 交互合约

交互合约与实施于以太坊区块链的智能合约目标相似。两者都定义和巩

固可在无信任和可验证的情况下施加的逻辑。

但是,这两种数字化合约背后的理念非常不同。以太坊将智能合约描述为包含价值的加密“盒子”,而这盒子只有在满足某些条件时才会解锁 [10]。交互合约并不直接保留价值,而是描述两方或多方应如何互动。它们的意图更接近传统(纸质)合同的意图。

1.1 李嘉图合同

交互合约符合李嘉合同的定义。最值得注意的是,人类和程序都可轻松阅读。这是从定义交互合约的方式获得的属性。既没有用于法律目的的自然语言版本,也没有用于编程执行的代码版本。

1.2 执行

链上执行不适用于很多现实生活的案例。智能合约依赖于主动执行,这意味着违反协议必须是不可行的或者得使任何一方必须退出 。

就以保密协议为例。区块链不可能阻止一方透露信息,也无法强迫一方积极参与解决泄密行为。如果希望这种协议成为自我执行的合约,它必须将全部违约金扣住作为押金。这将确保每一方都会为自己的利益参与决议。

对于大多数组织而言,将大量资金用作合同的违约金存款是不切实际的。除此之外,罚款和类似措施的有效性仅限于智能合约所持有的押金。

大多数业务流程都要求通过权威机构链下解决争议。交互合约可以促进争议的删除过程。这可能包括冲突谈判,调解,甚至仲裁(通过仲裁者或法官)。在 LTO 平台上运行流程会形成可验证的事件历史记录,从而减少不对称的信息。信息的分配会影响争议时的谈判 ,并影响第三方权威机构进行的评估。

1.3 用户界面

以太坊提供了一种内置的图灵完备脚本语言,程序员可以使用它来构造任何数学方式定义的智能合约或交易。这使它们非常抽象,因正在运行的合约所包含的状态没有内在含义。

要与此类合约进行交互的话,必须为特定的智能合约创建特定的用户界面,或者说,创建此类合约的界面 。这些界面可以标准化,如 ERC-20与ERC-721,会把用户界面与合约逻辑分开。缺点是这也限制了设计合约的可能性。

通过交互合约,合约内的信息确实具有内在意义。虽然这限制了用例,但它确实能够纯粹基于合同及其过程提供的数据生成界面。因此,任何工作流程都可以在 LTO 平台上进行数字化和执行,而无需为每个工作流程创建特定的界面。

1.4 指令与整合

交互合约包含针对特定人员或节点的指令。一个节点可以根据指令行动或通知用户某个操作即将被执行。此操作可包括通过 HTTP API 调用从互联网获取信息。

在以太坊和 Hyperledger 中实施的智能合约逻辑只能改变区块链的状态。智能合约需要通过预言机将数据从外部源提交到区块链。

这个预言机可以根据智能合约的状态行事,但是这预言机的逻辑不会是合约的一部分。不过,这种逻辑在本平台是交互合约的一部分,因此各方参与者可能会对其进行验证,并可能引起争议。

2 有限状态机

交互合约将工作流定义为 有限状态机 (FSM)[18]。这使我们可以将其显为流程图 (figure 2)。这样,人类和计算机都可以理解工作流程。

2.1 确定性有限状态机

任何区块链逻辑都需要是确定性的。计算机程序可能需要额外的努力来符合此标准,但是确定性有限状态机(DFSM)本身是确定性的。

2.2 扩展有限状态机

图 2 显出了需要多数操作到达某个状态而它们发生的顺序是任意时,会出现问题。这可以被建模为每个可能顺序的过渡路径,如图 2所示。但是,通过这种方案解决,状态和状态转换的数量将随着操作的数量呈指数增长。这不仅使工作流的图形不太清晰,而且还会使定义工作流更加困难和容易出错。

因此,交互合约不使用常规有限状态机,而使用的是允许条件状态转换的(EFSM) 扩展有限状态机。

图 3 用 EFSM(扩展有限状态机)视出与图 2 相同的工作流程。

2.3 交流性有限状态机

有限状态机仅限于顺序行为;而们不支持并发进程。若要表示具有并发性的工作流,每个并行指令序列需要画为独立的有限状态机。

交流性有限状态机 (CEFSMs) 允许通过组合各个事件序列来建模更复杂的过程。

事件链 可以作为两个 FSM 之间的交流通道。使用不同的事件链隔离两个进程会使整个系统不确定,因为通信通道是非确定性的。这可以通过确认事件来克服,如 13.1节所示。

2.4 作为自动机的合约

有限状态机可以作为参与者之间的协议用,通过规范义务,权限和禁止各方强加于另一方。金融协议等合同和服务合同可以完全数字化为FSM。

然而,在本文章中所提供的表示图都不足以用作工作流程的条件,因为它们没有定义流程中的通信和编排。虽然可以在图中结合这些因素,它会使有限状态机成为指数级更复杂。

实际上,FSM 最多仅能代表一份不完整的合同。然而,这不一定是一个问题,因为这些缺口可以用默认规则填充 。该系统允许重新谈判交互合约内容,无论是解决特定情况或一般情况。

另一件需要注意的事情是,在某过程中,不是每个操作都会构成一个约束因素。例如,在图 1 中,接受文件不会构成具有约束力的协议;这仅在文档签署时发生。为了促进这种区分,我们可以将行动分类为信息性或执行性 。

3. 备择建模方法

交流性有限状态机通常用于描述电信系统和其他实时系统,而不用于业务流程的描述。在对去中心化的组织之间的流程进行建模时,更常见的工作流注释会带来更多的挑战。

3.1 佩特里网 Petri

佩特里网是一个系统的图形表示,其中可见到多个独立活动同时进行。Petri 和 FMS 之间的区别在于 Petri 能够对多个并发活动进行建模。在 FSM中,始终都存在单个“当前”状态,该状态决定下一个可能发生的行动。在 Petri网中,可能存在几种状态,其中任何一种状态都可能通过改变 Petri 网的状态而发展。某些,甚至所有状态可以并行发展,导致 Petri 网的一些独立变化同时发生。

可用于描述业务流程的工作流网(WF-net),是 Petri 网的子集。WF网可以描述整个过程,而不仅仅是一个序列。

EFSM 使用综合状态来保存信息。此信息必须按顺序被隔离。若失败将数据化成不可改变可被利用。在 Petri 网是不可能用通用信息的。

反而,信息必须流经工作流程。

通过 CEFSM 的方法,每个序列会被定义为单独的过程。这使将访问控制应用于一部分过程一项微不足道的任务。不过,当设计整个工作流程时,不能以相同的方式解决这个问题。

Petri 网有一个有趣的注释。多数研究表明它们可用于表示业务工作流程。鉴于可以将 CEFSM 建模为 petri 网,使用 WF 网可能比使用单个 FSM 更合适。

由于 Petri 网和 FSM 之间的相似性,如本案文所述,切换到 WF 网并本质上不会改变我们的解决方案。

3.2 业务流程模型和标记法

业务流程模型和标记法 (BPMN) 是业务模型处理的行业标准,并且可能成为 LTO 的建模标记法候选之一。可是,BPMN 有多数尤其对于跨组织系统造成不便的限制。

通常与 BPMN 相关联的业务过程执行语言 (BPEL),是一种用于 Web 服务的非确定性图灵完备语言。这使得它不适合区块链的自动化。

建议的替代方案是将 BPMN 模型转换为 Petri 网,Petri 网又转换为智能合约。

虽然(图灵完备)智能合约转换步骤是多余的,从 BPMN 到 Petri 网(或CEFSM)的转换还收有意义的,以支持当前的行业标准。

3.3 组织的设计和工程方法 DEMO

“DEMO”是“组织的设计和工程方法”的缩写。这种用于描述组织及其业务流程的方法基于“交流行为”。它使用四种模型来创建整体视图,即构造模型(CM),过程模型(PM),行动模型(AM)和事实模型(FM)。

DEMO 会给每一个执行的动作易建立一个通用的工作流程,而不是将过程中的每一步单独研究。此动作中有两个角色,就是发起者和执行者。标准序列如下进行:发起者发出请求,执行者做出承诺。执行者然后执行操作并对结果做出声明; 发起可以么接受这个,然后完成交易,或者拒绝它 。

其他流程也可以被建模,例如执行者拒绝请求,发起者想要撤销请求,执行者无法履行承诺等。当使用其他建模方法时,这些替代流程通常不会或仅部分地建模,可在实践中,它们总是存在。

流程模型(PM)将这些事务组合在一起,以模拟完整的业务流程。这个模型和工作流程模型之间的区别在于,在这个模型中,每个人都尽可能并行工作,在需要的地方指定事务之间的依赖关系。这种设计选择意味着与其他建模方法相比时,在 DEMO 模型中我们无法清楚地了解我们在流程中的位置。此外,互相排斥信息(不要编辑准备签名的文件)并非身临其境。相反,它需要具体被指定。

DEMO 可能是制作高级模型的好方法,从而产生可以进行微调的工作流程。这应该会产生更完整的合同,减少对派生的依赖。

4. 场景

工作流被定义为数据对象; 场景。它由以下元件组成:

• σx 作为某个操作,

• Σ 作为所有可能行动的集合 Σ = {σ1, ..., σn},

• δ 作为状态转移函数 δ : Q × Σ → Q,

• F 作为最终状态的的集合 F ⊂ Q | F = ∅,

• ¯I 作为所有角色定义,

• A¯ 作为所有资产定义,

• D 作为嵌入数据对象的集合。

4.1 状态

集合在 Q 中的状态通常包含以下内容:

• 标题:给某个状态设定的小标题,

• 带有交易的操作为 {(−→qx, δ), ...},

• 描述:给状态的描述,

• 给特定角色的地图或指令。

每个状态描述了在此状态下可以执行的操作,包括状态转换。这允许不同操作可在不同的状态下使用。

4.2 操作

Σ 由场景定义,即可在工作流中执行的所有可能操作。此类操作的示例包括填写表单,查看某个文档以及执行 HTTP 调用。操作类型与物件属性是使用JSON 模型定义的。

每个操作都会定义来自 ¯I 套的哪些角色可以执行它而且可选附加的执行约束。这些约束使场景成为一个 扩展 FSM。

当执行一个操作时,会触发状态转换。操作可被分类为需要执行人为干扰的手动操作,以及可以由系统自动执行的系统操作。

每个操作也可以下令,使用回复的数据去更新角色与资产。

4.3 角色

¯I 套定义可以在流程中发挥作用的所有角色。每个角色都使用 JSON 模型被定为一个物件。与进程相关的角色属性必须定义。

某个场景中的角色只是一个静态定义,可以在进程中实例化。

4.4 资产

A¯ 定义流程中可用的所有资产。资产是可变数据对象。与流程相关的属性必须定义。

请注意,场景仅定义资产的结构。资产只能在流程中实例化。

5. 数据对象

除了情景场景,还可以定义其他类型的数据对象。所有数据对象(包括场景)都使用 JSON 模型作为类型定义。常见示例包括表单,文档和模板。数据对象可以嵌入到进程中,也可以独立链接和存储。

链接对象由其 JSON 表示的 SHA256 哈希标识。为了确保 JSON 编码数据始终产生相同的结果,链接时用到了确定性的 JSON 编码方法。

5.1 不变性

数据对象是不可变的,当数据对象被修改时,它产生一个新的数据对象。如果此数据对象作为资产嵌入到流程中,则旧对象将被修改后的对象替换。

值得注意的是,如果某一个数据对象在多数进程中用到,其更改将不会自动传播到其他进程。

实现不了不变性可能导致可利用的情况。在图 1,我们展示了谈判和签署文件的过程。很明显,在签名过程文档中不应该被修改。

5.2 表格

表格定义使用 JSON 模型来定义填写表格时应该产生的数据结构。可以使用附加的 UI 模式来指定如何呈现和显示相应的字段。

现实已有类似的措施 。我们的目标是与这些项目合作,形成统一的标准。

5.3 文件

数字工作流程可以大量消除纸质文档的需求。但是,法律合规性,向下兼容性和公司政策等可能仍需要使用文档。通过将模板定义为交互合约的一部分,可以使用流程收集的数据生成自然语言文档。

我们建议使用支持字段和条件部分的开放文档格式来创建模板。

5.4 自定义类型

任何定义物件的 JSON 模型可以当成数据对象引用。自定义类型确实存在工作流无法正常运行的风险,因为其他方可能通过不支持该类型的节点参与。具有未知类型的数据将“按原样”存储,并且在该过程的上下文之外不可用。

6.参与方

参与者定义了交互合约中的个人,团队或组织。参与者始终包含以下信息:

• 身份标识,

• 节点统一资源标志符 URI,

• 自定义信息,

• 签署密钥,

• 加密密钥。

参与方与角色不同。角色是抽象的,例如“学生”; 但是,参与方可能是“Bruce Willis”或“Acme Corp”。

签署密钥是具有与身份相关联的一个或多个公钥的映射。“用户”密钥是属于参与方的,所以只能由他/她用于签署任何操作。“系统”密钥由参与方使用的节点拥有,用于签署自动操作,除此之外还可以在流程中定义其他密钥类型。

公钥可用于加密数据,数据只有目的参与者能够解密。

6.1 邀请参与方

若希望添加新的参与方到某个流程的话,此场景该定义添加新参与者的操作。如果公钥在流程内是众所皆知的新参与者可以直接被添加。

当公钥是未知的,新参与者需要被邀请 (figure 4)。这可以通过任何足够安全的方案来完成,包括电子邮件。邀请系统会生成一次性密钥并将其发送到受邀方。被邀请方必须通过其自己的安全“用户”和“系统”密钥替换它。

在新参与方完全参与流程之前,可能需要进行其他身份验证。这可能是通过 SMS 验证到联合身份验证甚至公证批准。

6.2 更新参与方

除了身份标识符外,所有参与者可以自由修改自己的信息。这也允许某方切换到另一个节点。如果本过程不允许用户切换节点,则由参与者的节点拒绝该更改。

移除某个参与方可以通过清除签署密钥,加密密钥和节点 URI 来完成。

只有在场景中定义了此类操作并在当前状态下允许时,才能更新其他参与方。

7. 过程

如果一个场景是工作流的无状态定义,则该过程是有状态实例化,包括以下内容:

• θx 作为回复,则 f : qx 7→ θx

• Θ 作为所有回复的有序的集合 Θ = {θ0, ...θn}

• qt 作为前的状态

• I 作为在线的角色

• A 被创建的资产的集合。

7.1 操作

执行操作总是会产生响应。此响应必须由执行者签署并作为新事件提交。节点基于当前状态和刚执行的操作独立地确定新状态。

该场景被定义为确定性 FSM。然而,这仅涉及状态转换和投影。在诸如以太坊和 Hyperledger 之类的系统上,所有逻辑必须是确定性的,因为它由所有节点执行,并且需要在所有系统上产生相同的结果。

使用 LTO,只有单个节点或单个角色执行操作,这意味着操作不需要是确定性的。对于从外部源获取数据等操作,不需要预言机。

7.2 手动操作

在 LTO 平台上构建的应用程序必须告知人类参与者他们在当前状态下可能执行的操作。参与人类在将其提交给他的节点之前将签署他自己的响应事件,该节点将其分发给所有参与方。

7.3 系统操作

系统操作不需要人为干扰,因为节点会自动执行。因此,由节点签署响应操作,而不是人类用户。

这些操作始终由单个系统执行,而不必是确定性的。该流程的其他参与方验证响应,并可在需要时拒绝。由于系统操作中不涉及人为干扰,操作由系统本身而不是参与者签署。

系统操作也可以安排稍后执行的。这可以在场景中指定。它允许状态超时或以预定的频率轮询外部资源。

系统操作会自动执行,如果使用不当可能会产生错误或失败。对于这些操作,必须定义两个状态转换。一个用于成功执行的情况,一个用于失败的情况。

7.4 子进程

基于 FSM 的进程只能同时处于一种状态。子流程允许交互合约保持多个状态,并且可以并行执行不同的过程。这些流程共享一个事件链,但每个流程的数据仍然是孤立的。

为了促进子流程,交互合约可能包含可以从主场景实例化的子场景。

7.5 投影

除 FSM 状态外,该过程还包含其他有状态数据,例如资产和参与者。每个响应的有效负载可用于更新此数据。在场景中定义了有效负载该如何更新数据的规则。更新投影是确定性的,因此,对场景应用一组给定的响应将始终产生相同的投影。

投影可用于设置操作的参数以及为各个操作定义的约束。

7.6 数据运算符

在场景中可能会使用数据运算符来指定投影如何影响过程。这些运算符乃确定性函数,没有副作用。它们可用于算术或逻辑运算。这些操作的结果可以存储在投影中,并且可以用作例如状态转换的基础。

7.7 被动测试

包含仅由系统操作组成的循环的场景可能会导致无限循环,从而导致大量交易。在验证场景时,如果某个场景有这样的构造,我们要拒绝它。

确定某个程序是否可以永久运行被称为停机问题。停机问题在图灵机上是不可判定问题;但是,停机问题在 FSM 是可以解决的。由于 FSM 具有的转换路径数量有限,它们的循环可以有效的被检测到。

由于不可行的路径的存在,EFSM 模型的被动测试变得复杂,并且是一个开放的研究问题。为了简单起见,我们忽略所有条件而可以假设通过 FSM的任何路径都可行。我们承认这可能会导致误报。

8. 自适应工作流程

场景将模拟流程最常见的案例。提前预见所有情况是不可能,并且无法对每个可能的边缘情况进行建模。采用代码即法律 (code-is-law) 方法会使系统僵化。相反,交互合约支持三种解决此类问题的方法。

• 批注

• 偏离

• 场景更新

8.1 批注

评论用于与求他参与者交流互动。例如,它们可用于解决冲突或在流程之外进行讨论。使用评论而不是链下沟通方法可确保会话记录在区块链上。它还让我们可以回溯检查在程序中何时发生某些对话。

评论不仅限于文字信息。也可以使用图像或文档来协助交流。批注不是过程的一部分,这意味着评论不会触发状态转换。因此,链上可以讨论进行关于在过程中未预定的主题。

8.2 偏离

任何一方都可以通过定义部分场景来建议偏离主流。此子流必须从现有场景的其中一个状态开始,并以该场景的某个状态结束。偏差流是一次性的,因为当流程返回到现有状态时,它们不再可用。

各方需要对偏离达成一致。请注意,偏离可能会导致只能通过手动解决方法来解决的分支。

偏离可用于解决争议。任何一方都可以建议它对先前事件的正确性提出异议,并对如何纠正这一各事件提出解决方案。

使用偏离的典型情况是进行支付安排。各组织当然都不希望在协议中显出该选项。预定义的子流程允许授予此类安排,同时保密。

8.3 场景更新

时常,正在运行的进程的场景会需要更改;例如,当协议受到更新或添加新法律时。

一方可以通过偏离流为给某过程提供新场景。此流程将状态移出过时的场景并进入新场景。

因为更新场景是事件序列的一部分,它不会破坏解决方案的确定性。

9. 事件链

为了确定 FSM 和投影的状态,我们需要按给定的顺序处理响应集。插入或删除事件,更改事件的顺序或修改有效负载可能会导致完全不同的状态。

在中心化方案中,控制方负责数据完整性。各方都依赖这一方,因为它代表了唯一的事实来源。在去中心化的系统中,权力和责任由各方共享。

为了简化此过程,事件链就像一个特殊的私链。每个响应都包含在一个事件中,可以将其视为具有单个操作的区块。这些事件形成一条哈希链,由各方共享。共识算法确保各方就事件顺序达成一致。

9.1 非许可私有链

在一个场景中,人员和组织被定义为参与者。参与者可以自由选择其想要哪个节点参与本过程。

节点参与网络无需任何权限。启动任何程序甚至邀请其他参与者也无需任何权限。数据仅与进程的参与者之间共享。因此,事件链可以描述为非许可私有区块链。

9.2 加密签名

为确保没有人可以假造或伪造他人的事件,每个事件在使用非对称加密提交之前都会签名。签名事件也可作为收据,允许其他方证明该操作已由签名身份执行。

该平台使用 ED25519签名。这些椭圆曲线数字签名被 NIST与ENISA等机构广泛使用,受到充分支持和认可,并被认为是安全的。椭圆曲线加密允许更快速的单签名验证和不失安全性的签名。它而且还减少了密钥和签名数据的大小。请注意,此方法本身并不提供完全的安全性,因为各方仍然可以假造或伪造自己的事件。换句话说,加密签名无法证明某事件有没有发生。

9.3 哈希链

每个事件都可以使用 SHA-2 256bit 哈希进行唯一标识。该行业标准算法可确保快速的可计算与抵抗原像和第二原像攻击以及碰撞。这是 NIST 推荐的算法。

将先前事件的哈希嵌入下一事件的哈希中会创建哈希链,该哈希链记录事件的时间顺序。当与加密签名结合使用时,哈希链提供足够的证据证明特定事件序列导致当前状态 。

10。 分配

与其要求各方从中心服务器或彼此提取信息,每一方负责将事件推送到所有其他参与方的系统。

系统需要始终可用,以便事件不会丢失。解耦和消息队列可以减少临时不可用的问题。在典型情况下,所有各方将连接到他们信任的节点,该节点将接收和处理它们的事件。该节点也是较大系统的一部分。

组织和政府可以自己运行节点。用户可以连接到其组织的节点或他们选择的公共可用节点。

CAP 定理意味着在存在网络分区的情况下,必须在一致性和可用性之间进行选择 。通过使用解耦,我们牺牲了一致性,但是实现了更好的可用性。不在线或无法访问的节点不会中断其他参与者的进程,并且会在再次可用时同步。

10.1 私链

事件链是一个私有链,仅与参与者选择的节点之间共享。节点不会意识到他们未参与的私链。

节点同时存储和促进许多事件链。事件链是完全隔离的,与侧链不同。链不会直接相互影响。鉴于每个事件链的活动相当低,这允许水平缩放。

10.2 创始区块

任何人都可以随意创建一个新的事件链。此链的创始区块包含创建进程的用户的标识,后续块将包含场景。作为场景的一部分,其他参与者将被邀请到此私链。

11。 共识机制

LTO 是一个分布式系统,所有方都可以通过自己的节点参与。节点将所有事件分发给其对等体,然后这处理这些事件。这意味着过程中存在一个节点之间的过程状态不同的短暂时刻。最终的一致性保证最终,鉴于没有提交新事件,所有节点上的进程状态将是相同的。

但是,有时候,在达到一致性之前会有新事件提交。此时,两个或更多节点可能会将不同事件附加到事件链。在拜占庭故障期间,所有节点都认为他们的信息是正确的; 但是,整个系统处于不一致状态。在这种状态下,节点不再接受彼此的新事件; 他们需要能够达成共识,而不是停止。

分布式应用程序使用不同类型的共识算法。通常,这是拜占庭容错的情况。早期的拜占庭容错(BFT)方法不可地扩展。随着新的可扩展的共识算法的发明例如 工作量证明 (PoW) ,权益证明 (PoS) 与权威证明 (PoA),使得具有大量参与者的分布式网络可被创建;这也称为分布式账簿技术。

虽然这些共识方法比传统的 BFT 方法更好地扩展,它们还是需要相对大量的参与者(PoW 多于 1000)才安全 。传统的 BFT 方法依赖于不超过 ⌊n−13⌋参与者是不良行为者的事实 。这意味着如果有少于四个参与者,一个不良行为者可以影响系统,并且至少需要七个参与者保护他们免受两个不良行为者的影响。

事件链是一条私有链,参与者相对较少,通常少于 7 个,这意味着这些算法非常容易受到攻击。所以各个节点会认为它们的状态正确,除非另有证明,而不是信任多数投票。

11.1 冲突比率

事件链依赖于乐观性的并发控制; 大量的冲突会对共识算法造成压力,算法可能会相对较慢,因为它可能必须等待生成新的区块。

我们定义分布式事件链如下:

• 由 N 作为对事件链有贡献的实体。{n1, n2, n3, . . . }。

• 由 Cn 作为事件链,由属于 n 实体的事件组成的序列 (e1, e2, e3, . . .),还由 C 作为事件链的所有副本的集合 {Cn|n ∈ N}。

• 由冲突或分支定义为 ∃ i, j ∈ N : i ̸= j, Ci0 = Cj0, Ci ̸⊂ Cj , Cj ̸⊂ Ci.

意外冲突只有在两方各自,在从其它链受到更新之前,在自己的链上添加一个区块的情况下才会发生。

若称某人将更新传播到链的比率为 P(x)。此比率取决于在给定的时间范围内被添加到链中的区块数量,将该块传播到网络的其余部分所花费的时间,以及在该时间范围内对链做出贡献的实体的数量。假设每个人都对网络做出同等贡献的话,可以推导出以下函数 (1):

以:

f = 交易总数量 / 时间范围

n = 活跃参与者总数

t = 将块传播到网络的其余部分所需的时间

这比率可以用来计算发生冲突的概率。通过从 1 减去不存在冲突的机会来导出该概率。若没有冲突的话,意味着当时没有人为链条做出贡献,其机会是使用以下函数计算的 (2),

LTO 每条链上的活跃参与者极少;这减少了冲突的可能性。如果有五个以上活跃参与者,则该数字就此不重要。超过 10 名参与者,基于网络延迟和交易次数,冲突的可能基本上变得线性。

如果使用具有解耦消息队列的单独共享事件链,则交易频率将非常低。这使冲突的可能性边缘化。

11.2 分支验证

一个节点只能在某条链的最后一个事件以及之前的时间证明另一方知道其链的存在。任何方都可以在最后一次提交后进行分支。如果一方试图从最后一个事件之前的一个点开始分支链,那么所有(其他)方都会自动丢弃该分支,并记录该事件。

在接受来自冲突分支的新事件之前,它们将像任何收到的事件一样进行验证。该事件必须由其中一个参与者正确签名,并且必须正确锚定。如果事件的时间戳与锚点的时间戳相差超过 300 秒,则可以拒绝该事件。

11.3 锚定顺序

节点必须在 global 区块链上锚定事件。区块的顺序是通过挖掘设置的,挖掘区块内的事务顺序也是固定的。

这让我们可以使用 global 区块链上的锚点顺序来确定事件的顺序。如果发生冲突,必须接受首先锚定的块。私链的共识是通过公链的共识达成的。在公链上,共识是通过大量参与者之间的匿名协作使用 PoS 的变体的达成。

11.4 优先

某些情况下可能需要给出一个操作或角色优先权,所以即使它最后被锚定,它也是先排序的。参与者可以在场景中自由设置此类优先级。

某些事件类型(例如评论)自然具有较低的优先级。

使用优先级会启用抢先交易攻击,某人可以创建新的分支来回应一个事件,然后废止此事件。优先级当只有在没有问题的情况下才应使用。

11.5 未锚定事件

当收到尚未锚定的区块时,我们可决定无论如何都接受该块。当然,是在接受它就不会产生冲突的情况下。若某区块的锚固仅是被延迟,接受该块可避免给正在运行的过程带来多余的延误。另一方面,如果永远不锚定该块,则不会出现实际问题。如果所有人都接受该块,则该过程可以正常继续,并且该块可以稍后锚定。

11.6 合并分支

当出现分叉时,大多数区块链应用会选择一条链继续并忽略其他分支上发生的一切。使用像比特币这样的区块链,所有交易最终都会包含在每个分支的挖掘区块中。

在事件链上,事件本身构建了哈希链。挑选其中一个分叉会导致丢失有关已执行操作的信息。相反,当一个节点意识到另一个分叉优先于其自己的分叉时,它必须将它本地拥有的事件基于另一条链。这类似于使用 git 时的复位基底(rebase)操作。

11.7 分叉

即使有担保达成共识的方式,参与方也可能决定忽略其他链并保持分叉。对于大多数区块链应用来说,例如以太坊,没有理由去干扰分叉,因为价值仅来自参与主链。交互合约是一种用于数字化和部分自动化现有流程的工具。即使区块链允许分叉的存在,这些过程通常不会。在分叉的情况下,各方可以启动一个辅助过程以尝试手动解决冲突。

12. 隐私

LTO 专为多方之间的运行流程而构建。除了这些参与方之外,没有人需要了解这个过程甚至是合作。

公有区块链容纳匿名帐户; 但是,这些帐户充当假名作用。任何交易都可能揭示帐户的身份,从而暴露完整的交易历史记录。智能合约要求数据是公开的,因为它需要可用于每个节点。在联盟链上,参与者彼此了解。

临时的私有链允许随机分类的参与者进行协作,而无需批准或公开信息。完成该过程后,可以完全清除这些链。

12.1 链结资料

每一方通过自己的节点或其信任的节点进行连接。每个节点都有一个私有存储服务,用户可以在其中存储数据。用户可以完全控制存储在此的数据,类似于存储在 DropBox 等服务上的数据。他们可以随时删除自己的个人数据。在未经有效协议和用户明确批准的情况下,数据不会被共享或处理。

当某个操作导致链结资料时,该数据不会直接与其他方共享; 只有一个哈希值会被添加到链中。LTO 通过将哈希与时间戳和一些随机数据一起放入信封中来防止哈希被用于验证接收数据之外的任何其他内容。为了形成信封而创建的哈希将永远不会在区块链上出现多次。

当某组织表明它想要执行需要链结资料的操作时,该组织的节点将自动发出请求。数据所有者的节点检查指定的操作是否有效,并且可能由当前状态的角色执行。

12.2 GDPR 通用数据保护条例

随着新的 GDPR 在欧洲的到来(通用数据保护条例) ,许多关于区块链应用程序不符合 GDPR 的事实已经引发了争论 [63]。造成这种情况的两个主要原因如下:

• 区块链的不变性与修改和删除数据的权利相冲突,

• 没有专用数据控制方的事实,因为区块链是一个分布式环境。

链结资料意味着参与方选择的节点将充当该用户的数据控制器。所有其他方始终充当数据处理器。数据请求自动格式化以创建适当的数据处理协议,其中包括处理数据所需的目的和时间。

临时区块链可以在需要时清除整个链。

简而言之,LegalThings 的隐私功能使得解决方案无需额外的努力符合 GDPR政策。

12.3 零知识证明

某个场景可能要求一方向另一方证明其知道某个特定值。零知识证明(zkproof)是一种方法,除了证明一方知道该值之外,不传达任何其他信息。

LTO 通过交互式证明系统支持 zk 证明。证明方与验证方两方交互目的为,证明方对验证方证实其诚实度(完整性)还有让验证方揭露证明方不诚实的证据(健全性)。

交互合约的 zk 证明始终是两方之间的操作。合约中不需要非交互式的 zk证明,例如 zkSNARKS,它仍然被认为是实验性的。

13 常用模式

13.1 链互动

某些流程可能必须与其他流程交互才能继续运行;例如,某各进程需要来自另一个进程的允许才能继续运行检索冲突解决过程的结果。从另一个进程请求数据是通过遵循 5中所示的模式完成的。

13.2 显式同步

在某些情况下,如果事件传播得太晚,则会特别麻烦。当这种情况发生时,我们可以在场景中构建显式同步。这需要所有各方在继续该过程之前确认当前状态。这是 FSM 中的一种模式,旨在防止各方在此事件之前分叉事件链。如果发生争议或冲突,可以使用此类确认方式来决定应该用于继续该过程的分支。

这种显式同步仅在所有方都确认当前状态时才有效。如果某方缺乏继续的动力或有分叉流程的动力,则需要另一种解决方案。在这种情况下,想要继续该过程的一方向所有其他方宣布其意图。如果收到此公告的任何一方注意到所宣布的操作在自己的链上无效,他们可以传播此信息。这意味着链已经分叉并且必须应用常规冲突解决方案。为了防止此公告影响网络延迟会在假定没有人拒绝宣布的事件之前,等待一定时间。

免责声明:

1.本文内容综合整理自互联网,观点仅代表作者本人,不代表本站立场。

2.资讯内容不构成投资建议,投资者应独立决策并自行承担风险。