第21章：交易发起的那一刻，发生了什么：谈谈交易的签名

可能是最靠谱不忽悠的区块链资讯平台

在EOS上发起交易之后，发生了什么？交易如何打包至区块，又上链的？

这个过程虽然短暂，却经过了多道流程。今天开始，我们来聊一聊EOS交易上链到最终成为不可逆这一过程。

限于学识所限，对这部分的理解可能存在诸多不当之处，还请多多指教。

transaction 概述

前面部分我们了解过一笔交易的结构。回顾一下：

交易分为两部分：交易头结构(transaction head)，和交易中的actions的信息。

交易之中所包含的Action:

那么，在发起交易的时候发生了什么呢？

对EOS的用户来说，主要有如下2个部分：

使用钱包服务，为构建好的交易信息签名

将签名之后的交易信息发送至EOS网络中

那么， 具体是发送到何处？

钱包服务，不论是使用cleos，还是使用的手机钱包或者Scatter，都会连接到一个运行了nodeos服务的节点。比如，以MeetOne钱包为例：

可以看到列出了多个节点。

签名后的交易，会发送至对应的节点，借助于节点，同步至EOS网络之中，进行后续的交易验证，打包入块，区块广播等流程。

今天，我们主要了解这两个部分：

交易签名(sign transaction)

发送交易(push transaction)

交易签名

交易签名的过程，是在幕后发生的，不论你使用的是cleos的命令行工具，还是使用Scatter钱包或者手机钱包，签名只是一瞬间的事情，输入密码，点击确认即可完成。

我们可能会好奇，在幕后发生了什么？

假设我们发起这样一笔交易:

会进行两个过程：

对交易内容进行摘要处理

对摘要处理后的信息签名

摘要(digest)

首先，会对交易内容进行摘要(digest)，可以理解为将交易内容进行哈希运算，所用到的算法的是SHA-256 。

在这一步，会将如下三者进行hash处理:

chain_id, 即交易所在的区块链所对应的chain id，这是考虑了之后的跨链等情况

当前的交易

可能存在的上下文无关数据(context free data)

顺便说一句，context free data是为了跨链的情形所准备的预留的数据结构，当前的数据之中都不包含这部分内容。

对应的代码，可以参见的文件中，sig_digest的方法：

进行摘要计算后的数据，用16进制表示，大致长这个样子:

签名

其次，会对这一摘要数据，调用相应权限所对应的私钥，进行签名。

EOS使用者，会用到ECDSA算法(Elliptic Curve Digital Signature Algorithm ,椭圆曲线数字签名算法)来对交易进行签名。

而ECDSA算法也分为几种，对EOS而言，常用的是secp256k1曲线的算法，这也是比特币在签名时候所用到的。

感兴趣的话，可以参考:

https://en.bitcoin.it/wiki/Secp256k1

签名的格式为:

通过EOS浏览器，你可以在任何一笔交易之中，见到该签名信息。

而后续在出块时候，出块节点会根据交易之中的这一签名信息，计算出来对应的公钥，对交易进行核验。

至此，我们拆解了签名背后的两个步骤。

下面，就是将签名之后的信息发送到EOS网络之中了。

篇幅所限，后续部分，我们明天接着聊。EOS42章经系列中间暂停了一段时间，今天开始，恢复更新，还多谢各位朋友的关注。

EOS42 开创去中心化的未来

EOS42的账号为: eos42freedom。

请为EOS42投票，支持我们继续不停开拓去中心化解决方案的未来。