提供了编程的基础技术教程

zl程序教程

您现在的位置是：首页 >  其他

当前栏目

eos源码赏析（二十一）：EOS智能合约之区块签名的天龙八“步”

源码 消息 智能
2023-03-15 22:08:17 时间

在上篇文章中我们提到了，由用户操作会产生各种事务，事务的链上执行是由push_transaction来完成的，我们简单的划分了下，具体可参考eos源码赏析（二十）：EOS智能合约之push_transaction的天龙八“步” 。我们知道，在区块生产或者打包事务信息的时候免不了对数据进行签名，同时对于非本节点的区块信息也要进行验签。当然，针对每一个事务也都有签名及验签的过程，我们今天以区块的签名过程为例，来谈谈eosio中的签名是如何实现的。由于本人在该领域接触较少，行文中难免出现纰漏和差错，还望各位读者能及时批评指正。

本文主要分为以下内容：

  • SHA256简介eos区块签名的天龙八“步”

1、SHA256简介

我们在eos的源码阅读过程中，不管有没有在意，或多或少的都会遇到SHA256，或者在合约的开发过程中遇到checksum256。我们来看：

SHA全拼：Secure Hash Algorithm，又称为安全散列算法，是一种能计算出一个数字消息所对应到的，长度固定的字符串（又称消息摘要）的算法。且若输入的消息不同，它们对应到不同字符串的概率很高；而SHA是FIPS所认证的五种安全散列算法。这些算法之所以称作“安全”是基于以下两点（根据官方标准的描述）：由消息摘要反推原输入消息，从计算理论上来说是很困难的。想要找到两组不同的消息对应到相同的消息摘要，从计算理论上来说也是很困难的。任何对输入消息的变动，都有很高的概率导致其产生的消息摘要迥异。

对于任意长度的消息，SHA256都会产生一个256bit长的哈希值，称作消息摘要。这个摘要相当于是个长度为32个字节的数组，通常用一个长度为64的十六进制字符串来表示，这就是我们看到在eosio中，一些数据经过hash之后变成了64位的字符串的原因。

在eosio中基于安全裤openssl实现了SHA的部分功能，关于如何实现以及SHA实现的原理不作为本文的主要内容，包括中秋节期间被媒体大做文章的黎曼猜想，感兴趣的朋友也可以在群内一起讨论，我们接下来看区块生产之后是如何进行签名的。

2、eos区块签名的天龙八“步”

在上篇文章中，我们将push_transaction简单的分为八步，有利于我们进行代码的阅读，在本文中同样将区块签名的过程分为八步，通过每一步日志打印的结果来查看eos中区块签名进行了哪些动作：

  • 第一步：producer_plugin区块生产之后启动签名
void producer_plugin_impl::produce_block() {
   //获取chain及block_header相关内容
   auto signature_provider_itr = _signature_providers.find( pbs->block_signing_key );
   ....
   //等等操作，这里根据当前节点的sign_key进行签名
   ....
   //启动签名
   chain.sign_block( [&]( const digest_type& d ) {
      auto debug_logger = maybe_make_debug_time_logger();
      return signature_provider_itr->second(d);
   } );
}
  • 第二步：controller中开始进行区块签名，这里我们加了日志方便接下来的对比
   void sign_block( const std::function<signature_type( const digest_type& )>& signer_callback  ) {
       std::string strState = "";
      auto p = pending->_pending_block_state;
       strState = fc::json::to_string(*p);
      dlog("contorller sign_block begin:${state}", ("state", strPending));
      p->sign( signer_callback );
       strState = fc::json::to_string(*p);
       dlog("contorller sign_block end:${state}", ("state", strPending));

      static_cast<signed_block_header&>(*p->block) = p->header;
   } /// sign_block
  • 第三步：调用block_header_state中sign
 void block_header_state::sign( const std::function<signature_type(const digest_type&)>& signer ) {
     auto d = sig_digest();
     dlog(block_header_state::sign":${state}", ("state", d));
     header.producer_signature = signer( d );
     EOS_ASSERT( block_signing_key == fc::crypto::public_key( header.producer_signature, d ), wrong_signing_key, "block is signed with unexpected key" );
  }
  • 第四步：调用block_header_state中的sign_digest获取摘要信息

这里我们也加了相应的日志方便对比：

  digest_type   block_header_state::sig_digest()const {
      std::string strHeaderDig = "";
      strHeaderDig = fc::json::to_string(header.digest());
      dlog("block_header_state::sig_digest begin,header digest:${state}", ("state", strHeaderDig));
      std::string strBmRoot = "";
      strBmRoot = fc::json::to_string(blockroot_merkle.get_root());
      dlog("block_header_state::sig_digest begin,bm root:${state}", ("state", strBmRoot));
     auto header_bmroot = digest_type::hash( std::make_pair( header.digest(), blockroot_merkle.get_root() ) );
      dlog("header_bmroot:${state}", ("state", header_bmroot));
      dlog("pending_schedule_hash:${state}", ("state", pending_schedule_hash));
     return digest_type::hash( std::make_pair(header_bmroot, pending_schedule_hash) );
  }

在这一步中，我们看到首先对区块的头信息header进行了hash获取了其摘要信息，而后将摘要信息和默克尔树的最后一个元素pair之后再次进行hash，最后将本次hash的结果和本节点轮流出块的hash（每个生产节点是固定的）pair之后再次进行hash，也就是进行了三次hash的过程。关于默克尔树在区块链或者说在eos中的应用，我们在后续的文章中也会做一些简单的介绍，然后我们来看取区块头本身的hash是如何实现的。

  • 第五步：获取区块头信息的摘要信息及默克尔树的最后一个元素
   digest_type block_header::digest()const
   {
      return digest_type::hash(*this);
   }
   //按递增顺序获取当前节点的默克尔树
   DigestType get_root() const {
   if (_node_count > 0) {
      return _active_nodes.back();
    } else {
        return DigestType();
     }
  }

可以看到，获取区块头信心的摘要信息也是经过一次hash散列完成。

  • 第六步：基于openssl的sha256 hash的实现
    static sha256 hash( const T& t ) 
    { 
      sha256::encoder e; 
      fc::raw::pack(e,t);//将需要散列的信息t打包至加密信息e里面
      return e.result(); //返回打包的结果
    }

   //sha256的结果
    sha256 sha256::encoder::result() {
      sha256 h;
      SHA256_Final((uint8_t*)h.data(), &my->ctx );
      return h;
    }

在hash的实现过程中，我们可以看到使用了fc库中的pack将需要散列的信息打包到加密变量e里面，而在查看pack的过程中可以发现其依据变量类型对pack进行了多次重载，最终使用openssl库中的SHA256_Final将hash结果返回。

  • 第七步：将签名结果放到区块头信息中
header.producer_signature = signer( d );
  • 第八步：签名前几签名后信息对比

我们在签名的各个步骤中分别加了日志，由于区块信息较长，这里我们贴出区块头信息在签名前和签名后的对比。

//区块头信息签名之前
    "header": {
        "timestamp": "2018-09-26T10:58:49.000",
        "producer": "eosio",
        "confirmed": 0,
        "previous": "0001336d4c819c9656e3d8f9619afb65b4d94eb368cb7cbf1b8a0b3175dcfdff",
        "transaction_mroot": "0000000000000000000000000000000000000000000000000000000000000000",
        "action_mroot": "c2fd5cfedbf61c357b14a05dcdb3ab186aabb394c385f2f2a4daf79fb35cf454",
        "schedule_version": 0,
        "header_extensions": [],
        "producer_signature": "SIG_K1_111111111111111111111111111111111111111111111111111111111111111116uk5ne"
    },
//区块头信息签名之后
    "header": {
        "timestamp": "2018-09-26T10:58:49.000",
        "producer": "eosio",
        "confirmed": 0,
        "previous": "0001336d4c819c9656e3d8f9619afb65b4d94eb368cb7cbf1b8a0b3175dcfdff",
        "transaction_mroot": "0000000000000000000000000000000000000000000000000000000000000000",
        "action_mroot": "c2fd5cfedbf61c357b14a05dcdb3ab186aabb394c385f2f2a4daf79fb35cf454",
        "schedule_version": 0,
        "header_extensions": [],
        "producer_signature": "SIG_K1_KdhkFF5W2YVtNdwmCVYmdw3WMoKCcCgestut6wHsWtRuekjaHv7BZkWU4UXJqboozf6JonXru9hVfQVcptWCN23s6YpFjX"
    }

通过对比可以发现，在基本信息保持一致的情况下，经过上面的八步操作，producer_signatrue发生了变化，至此也完成了区块签名的整个流程。

本文从区块生产过程出发，一步步介绍区块在生产过程中是如何实现SHA256签名的。eos中关于hash的内容很多，从钱包到账户，从action到transaction皆是如此，感兴趣的同学可以自己摸索下。

在后续的文章中，我们会针对验签及默克尔树进行讨论。

相关文章