×
  • 澳门新莆京娱乐网站
  • 问卷调查
  • 问卷调查系统
  • 区块链
  • 大数据
  • 数据中心
  • 创建问卷
问卷调查系统工具软件推荐
区块链

以太坊上状态通道的应用案例

频繁进行交易以推进以太坊虚拟机是不必要的昂贵和缓慢。今天大多数使用以太坊的应用程序都通过更新链上合约的存储变量来工作,用户为此支付交易费用并花长时间等待区块确认。

为了使用应用程序,我们强迫用户手动将数据库更新提交给世界上最安全,分散和无信任的环境。

通过将一些功能转移到客户端代码上,而不是单独依靠以太坊为我们做所有事情,我们可以编写完全安全的应用程序。通常我们将这些称为“layer2”技术。

大多数“以太坊应用都不可伸缩!”的叙述并不是因为底层的区块链不合适。更准确地说,这是因为开发人员很难使用状态通道等Layer2层技术。我们需要在以太坊之上拥有更好的开发人员工具,这将使以高效方式编写应用程序变得更加容易。

Counterfactual是一个开源项目,正致力于解决这个问题。我们的目标是使开发人员易于使用以太坊上的状态通道来构建应用程序。

为什么现在很难使用状态通道?

今天,如果开发人员希望使用以太坊编写分布式应用程序,他们可能要实现以下每一项:

1. 公共API-合约上的public或extenal函数
2. 授权逻辑(Authorization logic)-通常通过检查msg.sender
3. 解决逻辑(Resolution logic)-决定如何分配资金

在大多数情况下,这是开发人员在设计分布式应用程序时要考虑的一个很好的抽象层次。 去年,我们已经看到成千上万的开发人员使用这种模式使用以太坊构建应用程序,所以最好不要彻底改变它。

从这种角度考虑状态通道会给应用程序开发人员产生更多共鸣。在大多数情况下,尝试设计状态通道应用程序时,您会遇到各种障碍,例如:

1. 不清楚应该如何编写公共API,因为您不再签署Ethereum事务,而是签署通用状态对象
2. 授权逻辑(Authorization logic)要求状态通道的每个用户为每个更新签署一个对象,并使用ecrecover验证这些签名。
3. 由于每次提交新状态时都有一个内置的“挑战”或“争议”阶段,因此现在的解决逻辑(Resolution logic)更加复杂。

最糟糕的是,对于整个状态通道协议,没有任何既定的标准,这使得框架或公共库很难出现。

我们可以做些什么来简化它?

使状态通道应用程序更易于推理的最重要的第一步是标准化通用状态通道功能,使状态通道解析逻辑与应用程序逻辑完全分离以与状态通道兼容的格式编写应用程序应该尽可能简单,理想情况下,应该感觉像是在编写常规的智能合约代码。

实现此目的的一种方法是将应用程序建模为状态机。强制移动游戏框架就是其中的一个示例,通常EVM已基于状态机的基本思想构建,状态机基于事务执行来更新每个区块的状态。

那么,普通智能合约和兼容状态通道的智能合约有什么区别?本质上可以归结为以下事实:无论公共API的实现如何,我们都需要一种标准方法来与应用程序的状态转换进行交互。简而言之,我们需要一个入口点函数来计算状态转换。

一个例子-井字游戏

假设我们要编写一个井字游戏应用程序。我们可能会编写一个智能合约,该合约具有带有placeX和placeO函数的公共API,并检查msg.sender以验证是否有正确的参与者在行动。

contract TicTacToe {

  address player1;
  address player2;
  uint8[3][3] board;
  uint8 nextTurn;

  function placeX(uint8 x, uint8 y) public {
    if (msg.sender == player1) { … }
  }

  function placeO(uint8 x, uint8 y) public {
    if (msg.sender == player2) { … }
  }

}

用Solidity编写的井字游戏智能合约示例。

将这个游戏建模为一个状态机,我们可以看到在它们之间有5种状态和2种有效的转换类型。

郑重声明:本文版权归原作者所有,转载文章仅为传播更多信息之目的,如作者信息标记有误,请第一时间联系我们修改或删除,多谢。

人已赞赏
区块链

区块链共识机制的历史

2019-11-27 20:10:46

区块链

区块链在物联网中应用的挑战

2019-11-28 12:14:20

问卷调查系统工具软件推荐
0 条回复 A文章作者 M管理员
    暂无讨论,说说你的看法吧
个人中心
购物车
优惠劵
今日签到
有新私信 私信列表
有新消息 消息中心
搜索
XML 地图 | Sitemap 地图