EOS入门指南PART6——别忙着开发,先来看看智能合约数据是怎么存的

上一章我们学习了开发智能合约之前需要知道的必要概念:

  • 什么是webAssembly以及它在智能合约上下游中的位置;
  • 什么是ABI以及怎样使用eosiocpp工具产生ABI和wasm、wast
  • hello智能合约的简单入门:部署和调用

如果说智能合约开发是一个锁着门的图书馆,那么之前的学习就是钥匙。现在我们终于可以拿着钥匙打开大门,走进去一探究竟。

摘要

说到智能合约开发,大家首先想到的肯定是写代码、像solidity开发一样教语法。EOS的智能合约是用C++写的,基本语法大家可以去买本C++的书;这一篇主要介绍EOS智能合约的数据存储,为大家扫清智能合约开发道路上的最后一道障碍。

什么是RAM

之前我们在学习如何在主网创建账户时,曾经接触到RAM的概念。我们不能像操作以太坊那样,凭空生成一个地址作为自己的账户,而是要先有一个账户,再去创建另一个账户。其中就涉及到一个关于RAM很关键的知识点:创建账户需要消耗RAM。

当时我们只是很模糊地知道,RAM大概是内存的意思。

RAM is used to store data in an in-memory database. DApps will use this to store state information so it is quickly available to their app.

RAM是EOS主网中的内存,用于存储用户在EOS中使用频率高的数据(账户余额、合约状态等)。

BM对EOS的期望是成为区块链世界中的【操作系统】,因此可以把计算机的一些概念对标到EOS中,其中计算机中的运行内存,在EOS中就可以看做是RAM;而硬盘就可以对标EOS区块链数据库。

所以高访问量的决策类数据,例如账户余额、智能合约的当前状态等就会被存储在RAM中,并且这部分数据将长期占用RAM;而低访问的费决策性存证数据,例如交易数据,就会存储在EOS系统的硬盘中,也就是区块链中。当存储账号状态的空间不足,即RAM不足时,转账或部署合约等相关操作就无法执行。

什么是EOS数据库

之前我们曾经介绍过transaction和action,action是智能合约执行的基本单元,transaction可以认为是一个或几个action组成的原子性操作。action在被称为action上下文的环境中执行,action上下文提供了执行action所需的一些条件,其中一个就是action的工作内存,这是action保存工作状态的地方。在处理一个action之前,eosio会先为它清理一次内存,因此当变量在一个action中被赋值后,另一个action的上下文是拿不到这个值的。那么在action之间传递状态的唯一方法就是把它持久存储到EOS数据库中,如下图:

EOS入门指南PART6——别忙着开发,先来看看智能合约数据是怎么存的

这个持久化存储就是数据库存储数据。EOS允许智能合约定义自己的私有数据库表。比如上图,Apply Context的内容都是一次性的,一次action执行完成,对象就释放了,只有存储到EOSIO database的才被保存。

什么是multi_index

接着上面介绍的数据库往下说, 这个私有数据表是通过multi_index来访问和交互的。EOS的multi_index类似boost的multi_index,即多索引容器。有了多级索引,智能合约就具备了操作类似数据库模块的功能。

multi_index是一个非常方便的、可以和数据库交互的容器。

从字面意思来看,multi_index就是一个可以使用多索引的数据表。

如下图:

EOS入门指南PART6——别忙着开发,先来看看智能合约数据是怎么存的

每一个multi_index容器都可以理解成传统数据库中的一张表,但是行和列稍有不同。和传统的多列的表不同的是,multi_index只有一列。这一列中的每一行都表示一个对象,通常这个对象是struct或者是class类型的,有多个成员变量。因此虽然只有一列,但是multi_index的灵活性丝毫不亚于传统的数据表。

举个例子,比如下面的这个struct

// @abi table proposal i64
struct Proposal {
  uint64_t id;
  account_name owner = 0;
  string description;
  std::vector<account_name, uint32_t> votes;

  uint64_t primary_key() const { return id; }

  EOSLIB_SERIALIZE( Proposal, (id)(owner)(description)(votes))
};


typedef eosio::multi_index<N(Proposal), Proposal> proposals;

首先看第一行:

// @abi table proposal i64

在部署合约之前,我们都会用eosiocpp来生成ABI,EOS智能合约编译器可以读取struct结构体和public方法之前的注。在注释中我们可以传入两种类型:actiontable,ABI就会根据我们的声明,自动在生成的ABI中添加相应的方法或者表定义。

第二个proposal就是表名,而第三个i64就是表的主键的类型。在这里主键就是id

account_name

注意到第二个成员变量owner:

account_name owner = 0;

这里的account_name是EOS自己定义的类型,也就是之前我们曾经创建过的账户名。可以理解成以太坊中的address类型。

vector

std::vector<account_name, uint32_t> votes;

vector这里可以理解成以太坊中的mapping - 自定义的一个映射集合。

Primary Keys

uint64_t primary_key() const { return id; }

eosio::multi_index规定,每行必须有一个主键,类型为64位的无符号整型。表中的对象都会根据主键,升序或者降序排列。通过在struct中定义primary_key()方法来获取。在这个例子中,proposal的主键就是id,类型为uint64_t。当然主键的类型也可以是account_name等。(account_name在eos中被存储为uint64_int类型)。

数据序列化

EOSLIB_SERIALIZE( Proposal, (id)(owner)(description)(votes))

通过阅读contracts/eosiolib/serialize.hpp文件可以知道,它其实是使用了BOOST_PP_SEQ_FOR_EACH宏。它的作用基本上就是赋予了struct额外的操作,可以把数据序列化到multi_index,或者从multi_index中反序列化出来。

multi_index相关操作

虽然不想SQL语句那样丰富,但是multi_index依然提供了一些基础的操作:

  • 创建:使用.emplace
  • 查询:使用.find
  • 修改已存在的入口:使用.modify

举个查询的例子:

auto itr = proposals.find(proposal_id)

以上语句查询了特定id的proposal,它返回的是一个迭代器iterator。这就涉及到我们如何使用表中的数据,答案就是迭代器。

EOS入门指南PART6——别忙着开发,先来看看智能合约数据是怎么存的

可以把迭代器想象成一个电梯,在整个数据表中上下滑动(来定位数据),任何对数据的操作都必须通过迭代器。

结束语

这一章概念虽然有些多,但是值得大家仔细研究。这一章我们学习了:

  • RAM的概念:存储用户高频使用的数据的地方,比如当前状态;
  • EOS数据库的概念以及如何存储;
  • multi_index是什么 - 和数据库交互的容器

这一章理论性的内容偏多,理解上可能不如之前的几篇直观。下一篇我们将学习如何操作multi_index,以此带大家更加深入地理解multi_index,同时正式开启我们的智能合约开发之旅。

相关推荐