频密展开交易以前进以太坊虚拟机是不必要的便宜和较慢。今天大多数用于以太坊的应用程序都通过改版链上合约的存储变量来工作,用户为此缴纳交易费用并花长时间等候区块证实。为了用于应用程序,我们强制用户手动将数据库改版递交给世界上最安全性,集中和无信任的环境。
通过将一些功能移往到客户端代码上,而不是分开依赖以太坊为我们做到所有事情,我们可以撰写几乎安全性的应用程序。一般来说我们将这些称作“layer2”技术。大多数“以太坊应用于都不能前端!”的描述并不是因为底层的区块链不适合。
更加精确地说道,这是因为开发人员很难用于状态地下通道等Layer2层技术。我们必须在以太坊之上享有更佳的开发人员工具,这将使以高效方式撰写应用程序显得更为更容易。Counterfactual是一个开源项目,于是以致力于解决问题这个问题。
我们的目标是使开发人员更容易用于以太坊上的状态地下通道来建构应用程序。为什么现在很难用于状态地下通道?今天,如果开发人员期望用于以太坊撰写分布式应用程序,他们有可能要构建以下每一项:1. 公共API-合约上的public或extenal函数2. 许可逻辑(Authorization logic)-一般来说通过检查msg.sender3. 解决问题逻辑(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种有效地的切换类型。
本文来源:RAYBET雷竞技入口-www.fdjs.net
Copyright © 2008-2024 www.fdjs.net. RAYBET雷竞技入口科技 版权所有备案号:ICP备65156409号-4网站地图