用于通过区块链的用户运行去中心化应用的方法和设备与流程

文档序号:29624918发布日期:2022-04-13 14:11阅读:69来源:国知局
用于通过区块链的用户运行去中心化应用的方法和设备与流程

1.本发明涉及一种用于通过区块链的用户运行去中心化应用的方法。本发明此外涉及一种相对应的设备、一种相对应的计算机程序以及一种相对应的存储介质。


背景技术:

2.计算机网络中的在特定交易的顺序方面导致达成一致(共识(consensus))的每个协议被称为去中心化交易系统、交易数据库或分布式账本(distributed ledger)。这种系统的通常表现形式基于区块链(blockchain),并且构成许多所谓的加密货币的基础。
3.根据现有技术最常使用的共识方法提供工作量证明(proof of work, pow)用于产生新的有效区块。为了抵抗通过提交这种证明引起的过度能源消耗以及抵抗区块链的不必要增长,提出并且推广了所谓的交易或状态通道(state channels),所述交易或状态通道将区块链下(off chain(链下))的各个用户连接,尽管如此仍锚定在后者中。coleman, jeff; horne, liam; xuanji, li. counterfactual: generalized state channels. 2018提供了该技术的概览。
4.de102018210224a1在根据权利要求6所述的实施方式中公开了用于在两个系统之间商定合作的以下方法:第一系统发送其关于第二系统的假设和其提供给所述第二系统的保证;相反地,第二系统发送其关于第一系统的假设和提供给该第一系统的保证。交易数据库接收这些相互的假设和保证,检查它们是否相互对应,必要时起草在系统之间要签订的数字安全合约,并且最后记录所述数字安全合约,其方式是将相对应的区块添加到区块链。交易数据库随后将具有安全合约的区块发送给两个系统,一旦所述系统接收到区块,所述系统就着手合作。所述系统为此建立相互的交易通道,所述系统在接收到区块之后在所述交易通道上交换信息和签名通知。如果系统之一接收到违反安全合约的信息,该系统恳求交易数据库的调解。交易数据库将此告知给另一系统,从该另一系统请求(想像违反安全合约的)信息并且根据合约检查所述信息。
5.这种智能合约(smart contracts)体现交易数据库的每个分布式应用(distributed application, dapp)的法律逻辑。例如,de102017214902a1描述了一种用于准备和/或执行终端设备的持有者和服务提供商之间的交易的智能合约,其中智能合约包含服务提供商针对信息服务提供商的服务的条件、尤其是关于使用费、优选地道路使用费的条件,和/或针对业务服务提供商的服务的条件、尤其是关于转让费、优选地关于停车费、燃料费、终端设备的充电站的费用的条件和/或保险条件和/或关于使用费、优选地关于联合使用终端设备来提供和/或取消服务的费用的条件和/或包含由该终端设备的持有人定义的针对采用和/或终止服务的条件,其中智能合约在基于区块链的计算机网络的授权节点中被执行。


技术实现要素:

6.本发明提供根据独立权利要求所述的用于通过区块链的用户运行去中心化应用
的方法、相对应的设备、相对应的计算机程序以及相对应的存储介质。
7.在此情况下,所建议的方法基于以下认识,即在已知的状态通道结构中,在链下阶段中通常无时间概念可供使用。然而,在相对应协议的链下阶段中,时间概念也是有利的或者甚至是需要的。
8.通过在下面详尽地讨论的方案克服这种限制。概括地说,利用以下情形,即所基于的区块链经由区块数量或区块深度预先给定虽然间接的、但严格的时间概念,并且此外许多分布式交易系统甚至提供对显著有区别的时间概念的可能更少的、但仍然足够安全的访问,类似以太坊中的服务“now()”。随后介绍的概念更好利用该时间概念,并且从中导出用于通道构造的链下阶段的时间概念,所述时间概念基于用于以下定时情况的单个或甚至多个灵活可用的时间帧,所述定时情况可以单独地或彼此结合地出现:1.商定和实现在其之内一个或多个下一用户必须进行反应的时间帧,以及2.商定和实现对于对每种情况的下一反应可能需要以便防止过早实现的时间帧。
9.两种应用又适用于两种调度方案:1.严格计时(具有对间隔的强制和/或主要遵守)和2.尽可能快的应用进展。
10.通过在从属权利要求中列出的措施,对在独立权利要求中给出的基本思想的有利改进和改善是可能的。
附图说明
11.本发明的实施例在附图中示出并且在下面的描述中更详细地予以阐述。其中:图1示出根据第一实施方式的方法的流程图。
12.图2示出在严格计时情况下的交互。
13.图3示出在第一应用情况中在尽可能快的计时情况下的交互。
14.图4示出在第二应用情况中在尽可能快的计时情况下的交互。
15.图5示意性地示出根据第二实施方式的控制设备。
具体实施方式
16.图1图解说明了根据本发明的方法的基本步骤,现在应该根据图2至4详细地阐述该方法。为了使得能够在状态通道交互时实施协调的时间控制,为此引入一系列数据字段作为通道或dapp状态的一部分。
17.首先,应该考虑具有严格间隔计时的情况。
18.状态规定了持续时间的各个子步骤或协议的所有步骤的共同值。为简单起见,在这里应该讨论后种情况;概括是简单地可行的。
19.图2阐明了时序并且示例性地阐明两个通道用户a和i的动作,这绝对不排除通道处的其他用户。假设存在支持的状态,所述支持的状态已经预先给定时间点t
untilnext,i
(t
直到下一个,i
),并且应该轮到a。(在下面,考虑基于走子次序(zugfolgen)的协议、例如“forcemove”,因为更强烈地涉及这些协议;然而,概括到具有任意步骤顺序的协议是可能的。)在根据图的第一步骤(1)中,第一用户a提出状态变化ma(以下根据博弈论始终称
为“走子(zug)”),其中所述第一用户将t
untilnext
(t
直到下一个
)符合规则地在将来移位预先给定的时间差δ,这可以通过dapp的程序逻辑(无论是在链下通过其他用户或者是通过好像用作仲裁者的区块链本身)检验:公式1如果在该状态通道上通过第二用户i的确认未发生(2),则a上传走子ma(3)并且以挑战(challenge)的方式邀请i在区块链上在“挑战持续时间”、即预先给定的时间区间(6)内进行确认。如果i在那里也没有及时响应(erwidern)走子,则如在区块链上的相对应仲裁方法中常见的那样,由区块链采用状态变化,并且a可以关闭通道。
20.在本示例中,用户i要么在无dapp-程序逻辑或状态变化的进展情况下通过联署ma(4a)响应用户并且以这种方式接受针对其对策(5a)的尽可能晚的时间点t
untilnext,i+1
(t
直到下一个,i+1
),要么所述用户i满足邀请,其方式是所述用户i直接执行对策mi并且在此更新:公式2t
untilnext = max (t
now(现在)
,t
untilnext,i+1
) +δ函数max检测以下情况:在邀请的范围中给i提供的时间区间(6)超过值δ,由此在时间点t
untilnext,i+1
之后考虑响应。对于这种情况,应该相对应地使严格的间隔计时移位,以便向下一用户提供商定的时间差δ,否则将会在t
untilnext,i+2
(t
直到下一个,i+2
)时继续进行所述严格的间隔计时。为了避免与设置的时间栅的每个偏差,因此可能将会将时间区间(6)选择得等于或小于δ。
21.在步骤4b或5a之后,利用a和i的互换的角色达到初始状况(1),并且协议可以相对应地进展。
22.通常,轮到的用户i及时作出反应,并且从而防止在区块链上(on chain)的挑战和响应。
23.在基于序列的协议(例如“forcemove”)中,如果a是第一通道用户,则步骤4a和4b将会援引奇数走子编号j。但是,如果应用灵活支持的状态的概念(其中在序列中后续的选手可以为于是有效的走子编号建议状态),并且所有其他用户都签署该状态,则步骤4a和5a的所建议的组合将会是可能的。在这种情况下,i在编号j+2下执行走子mi。如果a发出其签名,则使协议继续进行。如果不是,则i在参考支持的状态的情况下将会为此邀请用户a。如果区块链在这种情况下有利于a地作出决定,而所述a在dapp中不采用所建议的状态变化mi,则i之后将会再一次走子,并且可能会再次建议该状态并且最终实现所述状态。
24.如果通道上的应用进展允许在特定或非特定的时间内被中止,则在中止之前已经轮到的用户可以在状态存储器中注明这一点。对于中断的有限持续时间,可以相对应地更新t
untilnext
。对于非特定的时间,不同的方案是可能的。因此例如可以将t
untilnext
设置到所定义的值、例如零。可替代地,可以使用附加数据字段,例如布尔变量t
suspended
(t
中止
),其反映中止的状态。
25.此外,除了规定在其之内必须进行下一走子的时间帧之外,还可以使用所描述的技术来规定用户可以充分利用而不受惩罚或者例如通过挑战被强制来执行其走子的时间帧。例如,这可以通过以下方式来实施,即在商定的时间点之前不允许挑战。也可以同时应用两种方法,即规定在同时限制最大持续时间时可以被充分利用的时间间隔。这种方案和
使用不同时间间隔δi的优点在于,要留待通道用户例如每走子、每局或根据dapp状态详细地关于区块链下的通道上的时间预设达成一致。
26.在使用诸如“perun”的不设置规定的顺序的通道协议时,可以以上面讨论的方式毫无问题地实现时间预设。概括而言,建议时间限制的可能性供每个用户使用,其方式是所述每个用户设置相对应的数据字段,并且其他用户可以同意或被迫以任意的顺序进行应答。
27.在下面,描述严格计时的扩展,以便在通道构造中能够实现尽可能快的应用进展。在此情况下仅探讨不同之处;上述基础也在这里适用。首先,应该讨论在图3中所示的路径,在所述路径上不发生通过第二用户i对状态变化的确认(2)。从中得出作为简化的序列的替代路径。
28.使用两个附加的数据字段构成该扩展的基础:在最有益的情况下要遵守的优先的时间点t
uno
和可选的时间缓冲δ。为了尽可能快的流程,轮到的用户a在步骤1中不仅如常见的那样更新t
untilnext
,而且此外基于当前时间建议优先的时间点,所述优先的时间点在乐观的假设下将会遵守:公式3t
uno = t
now + δ + δ在此,基本思想是,如果轮到的用户不能或不想完全地充分利用时间差δ,则所述轮到的用户允许建议根据节省的时间使时间盒的参考移位。可以由用户商定附加的较小时间段δ,以补偿例如由于通信困难引起的常见的延迟,使得建议的接收者在最有益的情况下在时间点t
now
+δ之前获得所述建议并且可以将时间差δ完全用于其自身的走子。在该方法的替代扩展方案中,可以忽略δ并且可以考虑δ范围内的可能通信延迟。
29.在根据图3的场景中,在状态信道上通过第二用户i对状态变化的确认未发生(2)。在这种情况下,恰好如在严格计时情况下那样,a强制走子,其方式是所述a为此通过区块链上的挑战邀请i(3)。所建议的时间点t
uno,i+1
最初被忽略。i可以按规定的期限遵照该邀请,其方式是所述i要么联署ma(4a)并且执行对策mi(5a)直至时间点t
untilnext,i+1
为止,要么直接在时间区间(6)内执行(4b)所述对策。不仅在步骤4b中而且在步骤5a中,可以建议t
uno
的值并因此建议时间盒的优先(vorziehen)。在此情况下应该注意的是,如已经结合严格计时所讨论的那样,可以考虑在挑战的范围中同意的时间间隔(6)与δ之间的比例。
30.然后以交换的角色或者(在其他通道用户情况下)在i和在走子序列中排在下游的用户之间继续进行协议。
31.图4阐明替代路径,根据所述路径接受所建议的状态。如上所阐述的,这种确认原则上可以通过步骤4a和5a的组合或通过步骤4b进行,这仍然附有以下指示地,即步骤4a或4b在时间点t
untilnext
(在图4中在左侧所示的步骤中具体为t
untilnext,i
)之前进行。继步骤4a之后的步骤5a又必须在优先的时间点t
uno
(在图4中左侧所示的步骤中具体地为t
uno,i+1
)之前进行,所述时间点在步骤4a中已经被确认并且从而代替初始预先给定的时间点t
untilnext
。而如果步骤5a未发生,则如上所述地那样发生升级(eskalation)。实际的步骤4b和5a在应用所建议的和接受的时间预移位的情况下更新t
untilnext
:公式4t
untilnext,i+2 = t
uno,i+1 + δ
如在严格的间隔计时情况下那样,两个路径即使在尽可能快的方案中也可以交替,使得用户可以在区块链的损害最小时按需求强制走子,并且然后可以再次切换回链之外的流程。应该再次强调,为了简化上述实施,使用了在所有步骤中统一的值δ。然而,在一般化的实施方式中,用户可以根据走子的方式、dapp状态等对各种各样的值δ取得一致;同样如上所示的那样,与最小时间段的组合是可设想的,用户可以充分利用所述最小时间段,而不受惩罚或被迫执行其走子。
32.该方法可以例如以软件或硬件的方式或以软件和硬件的混合形式例如在控制设备(20)中实现,如图5的示意图所阐明的那样。
当前第1页1 2 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1