如何创建智能合约系统
如果不能将完整信息存储在区块中，那么存在哪儿呢？业界在这一块也有非常多的探索。比如IPFS项目，目标是分布式存储；比如Arwee项目，目标是存储。它们都可以与区块进行配合，在区块的账户和交易数据相关对象中存储一个外部数据blob的hash值，就能够实现数据关联，关系绑定。这种模式目前已经被大量的项目所采用。下文我们将这一类用于存储大量数据的基础设施统称为分布式存储或DistributedStorage(DS)。 这种模式仍然有很多细节问题需要面对： ●要稳定、持久。既然是用Hash方式关联，那就得保证Hash值固定不变，且始终有效。于是对这些DS项目提出了比较高的要求，要求数据有效，Hash值固定不变，且无冲突Hash ●存取效率要高。这些DS项目要能比较好的支持数据存储与访问的效率，延迟不能太高 ●存取费用不能太高。数据的存储和访问的费用不能太高，不然无法真正普及 ●接入要方便。接入容易才会让各种项目快速对接，快速建立起DS服务生态 业界很多项目在这些方面努力进行着探索，相信这是合理的方向。 这种数据的分离，会带来软件架构上的变更。区块的存储和上逻辑处理，只应负责经济事务相关业务，其它数据和业务，应该在下进行处理。理由如下： ●向DS存入数据和获取数据，都是网络操作，是一个异步请求。这种请求的返回时长具有相当程度的不确定性，相对于本地请求，Zui多可能有2，3个数量级上的差异。这种操作不适合放到上，而应该拿到下来处理 ●大量非经济事务数据的计算和处理，可能需要花费大量时间，这种处理，应该放在下执行 下处理的结果，如果与经济事务相关，则应提交给上进行后续处理。如果与经济事务无关，则应直接存取DS。 于是，现在存在两个逻辑处理引擎：一个在上，一个在下。这两个引擎如何完协作、维护、版本升级，其实是相当大的问题。我们看到，业界也开始有相应的解决方案了。比如Substrate中的Off-ChainWorker（OCW）目的就是要解决这种集成性和维护性的问题。 在整套系统中，为了提高系统执行的效率和稳定性，可能还需要负载均衡，缓存层等组件。 Web2.0App架构，以数据库为中心。运行流程如下： ●用户访问服务地址。DNS或IP到网关； ●请求通过网关后，进入服务逻辑； ●服务逻辑与数据库打交道，存入、取出或更新数据； ●服务逻辑返回处理结果给网关； ●网关返回结果给用户； ●直接基于DB的原始数据，可有另一套分支流程，即对大数据的分析，挖掘，AI训练等等 Web3.0App系统架构，以Blockchain和DistributedStorage为中心。运行流程如下： ●用户访问服务地址。分布式DNS（例如IPFS的IPNS，Arwee的DNSGateway等）到网关； ●请求通过网关后，进入服务逻辑（Off-ChainWorker及索引服务）； ●服务逻辑与DS打交道，存入、取出或更新数据。必要的时候与区块打交道，发交易、更新状态、获取结果； ●服务逻辑返回处理结果给网关； ●网关返回结果给用户； ●直接基于分布式存储的原始数据，可有另一套分支流程，即对大数据的分析，挖掘，AI训练等等。而在Web3.0场景下，这种分析，完全可由第三方大数据AI服务进行更专业的处理，做到更专业的分析。
元宇宙发布会APP功能开发公司成品开发一站式服务
