EOS 消息设计初步说明

Posted thefist11

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了EOS 消息设计初步说明相关的知识,希望对你有一定的参考价值。

1. EOS

EOS是作为一个传递账户间已认证信息的平台。脚本语言和虚拟机的实现将独立于EOS操作系统技术,任何开发语言或虚拟机,只要有适当的、性能足够的沙箱,都可以通过API与EOS集成在一起。

2. 消息定义

消息就是账户与账户之间的沟通语言,每个账户都可以发送结构化的消息给任意其他账户,每个账户都可以定义处理消息的脚本,每个账户还有自己的私有数据库,消息处理脚本也可以给其他账户发消息,最终 消息和消息处理脚本组成了EOS的智能合约。

我来进一步解释一下,发消息很容易理解,消息处理脚本就是在一个账户收到了消息之后怎么处理消息。这个处理脚本本身还可以发消息给其他账户。

我的理解是有些消息是人手工发的,比如说a给b转账50eos,有些消息是可以由处理消息的脚本来发的,比如说b在收到50eos这个消息后有个消息处理脚本会自动向c发送25个eos。这其实就是一个非常简单的合约了。

2.1 模式定义的消息

在账户之间发送的所有消息都是由区块链共识状态的一个模式定义的,该架构允许消息在二进制和JSON格式之间的无缝转换。

2.2 模式定义的数据库

数据库状态也使用类似的模式定义,这确保所有应用程序存储的数据都以一种格式呈现,同时具备JSON的人类可读性,以及二进制格式的高效率存储和易操作性。

2.3 将身份验证与应用程序分离

为了最大化并行运算,同时将从程序日志中重新生成应用程序状态的计算任务降至最低,EOS操作系统将验证逻辑分为三个部分:

  • 确认消息在内部是一致的;
  • 确认所有的前置条件都是有效的;
  • 修改应用程序状态。

验证消息的内部一致性是只读的,不需要访问区块链状态,这意味着它可以最大化并行运算来执行。验证前置条件(例如需求平衡)也是只读的,因此也可以从并行运算中获益。只有对应用程序状态进行修改才需要写访问,并且需要按顺序对每个应用程序进行处理。

身份验证是验证消息是否可以应用的只读过程,应用程序实际上就是在做这项工作。实时的计算都需要执行,但交易一旦被包含在区块链中,就不再需要执行身份验证操作了。

以上是关于EOS 消息设计初步说明的主要内容,如果未能解决你的问题,请参考以下文章

rocketmq 消息队列 初步了解

消息队列ActiveMQ初步

25组初步界面原型设计

Dart中的Stream初步研究

kafka的安装和初步使用

RabbitMQ初识以及简单模式初步