之前的文章中介绍了，STEEM/HIVE中的签名是对消息Hash的签名，STEEM/HIVE中的消息就是transaction，但是由于transaction中的条目位置不是固定的，所以仅仅是把消息转化成字符串并签名是行不通的。
(图源 ：pixabay)
解决这个问题的办法就是对消息当中的内容进行序列化(serialized)，无论transtion中内容位置如何变化，并不影响最终生成的二进制串的结果。
然而序列化(serialized)是一个很麻烦的事情，玩STEEM已经三四年了，我还没有把这块搞清楚。不过学习EOS和BTS相关内容的时候，知道两者都可以通过RPC API获取transtion序列化的结果。
get_transaction_hex
好在，STEEM/HIVE当中也有类似的API，那就是：
condenser_api.get_transaction_hex
Returns a hexdump of the serialized binary form of a transaction.
或者使用database_api.get_transaction_hex两者本质是一样的，只是暴露在不同的API接口中。
这个API的使用方法和其它的并无什么本质区别，所以按着我们以往使用方法使用即可。
同样以之前我们示例中的以transaction为例：
在获取这个tx，我们得到类似如下的数据：
因为block_num、transaction_id、transaction_num以及signatures内容本身并不参与序列化，所以我们可以把他们去掉（其实不去掉也无所谓，服务器端会帮我清理）：
然后我们得出如下json数据：
{"jsonrpc": "2.0", "method": "condenser_api.get_transaction_hex", "params": [{"ref_block_num": 21449, "ref_block_prefix": 4231435724, "expiration": "2020-04-08T09:44:27", "operations": [["vote", {"voter": "oflyhigh", "author": "deanliu", "permlink": "9fdbg", "weight": 10000}]], "extensions": [], "signatures": []}], "id": 1}
向RPC节点POST上述数据：
curl -s --data '{"jsonrpc": "2.0", "method": "condenser_api.get_transaction_hex", "params": [{"ref_block_num": 21449, "ref_block_prefix": 4231435724, "expiration": "2020-04-08T09:44:27", "operations": [["vote", {"voter": "oflyhigh", "author": "deanliu", "permlink": "9fdbg", "weight": 10000}]], "extensions": [], "signatures": []}], "id": 1}' https://api.hive.blog
格式化后的返回结果为：
其中c953cc9536fcfb9c8d5e0100086f666c7968696768076465616e6c697505396664626710270000就是我们要的序列化结果啦。
如何验证这个序列化结果是争取的呢？下篇文章我们再做分析。
结论
使用这个RPC API会大幅减轻我们客户端程序的编码工作量。
不过这个东西有两个弊端，一个是效率问题，多增加一次网络访问；另外一个就是安全问题，恶意的API节点可以替换内容，发起攻击。