区块链钱包技术要点

[TOC]

私钥随机性（根种子），助记词的生成，keystore的生成

助记词的生成

使用BIP-39中定义的标准化过程，钱包自动生成助记词。钱包从一个熵源开始，添加一个校验和，然后将熵映射到一个单词列表:

创建128到256位的随机序列（熵）。
通过获取SHA256哈希的第一（熵长度/32）位来创建随机序列的校验和。
将校验和添加到随机序列的末尾。
将序列分成11 bits的12个部分。
将每个11 bits值映射到来自2048个单词的预定义字典中的单词。
助记词是单词序列。

种子Seed的生成

助记词代表长度为128到256位的熵。然后熵通过使用密钥扩展函数PBKDF2来导出更长（512位）的种子。然后，所产生的种子用于构建确定性钱包并获得其密钥。

过程如下：

PBKDF2密钥扩展功能的第一个参数是从步骤6产生的助记词。
PBKDF2密钥扩展功能的第二个参数是salt。salt由字符串常量“mnemonic”和可选的用户提供的密码短语字符串组成。
PBKDF2使用2048轮HMAC-SHA512哈希算法来扩展助记词和salt参数，产生512位值作为其最终输出。那个512-bit的值就是种子。

keystore的生成

keystore是JSON编码的，其中包含一个（随机生成的）私钥，由密码加密以提高安全性。keystore格式使用密钥派生函数（KDF），也称为密码扩展算法，可防止针对密码加密的暴力、字典或彩虹表攻击。

有许多代码库可以读写keystore格式，例如JavaScript库keythereum：https://github.com/ethereumjs/keythereum

keystore内容如下所示：

{
    "address": "001d3f1ef827552ae1114027bd3ecf1f086ba0f9",
    "crypto": {
        "cipher": "aes-128-ctr",
        "ciphertext": "233a9f4d236ed0c13394b504b6da5df02587c8bf1ad8946f6f2b58f055507ece",
        "cipherparams": {
            "iv": "d10c6ec5bae81b6cb9144de81037fa15"
        },
        "kdf": "scrypt",
        "kdfparams": {
            "dklen": 32,
            "n": 262144,
            "p": 1,
            "r": 8,
            "salt": "99d37a47c7c9429c66976f643f386a61b78b97f3246adca89abe4245d2788407"
        },
        "mac": "594c8df1c8ee0ded8255a50caf07e8c12061fd859f4b7c76ab704b17c957e842"
    },
    "id": "4fcb2ba4-ccdb-424f-89d5-26cce304bf9c",
    "version": 3
}

私钥对公钥，公钥哈希，地址等的转换

熟悉了它们之间的关系与原理，可以通过官方的核心库进行转换，比如使用bitcoinj或web3j等。

BTC地址生成

首先介绍BTC的，关系转换如下所示：

ETH地址生成

ETH的前面部分至生成私钥步骤都是一样的，下面介绍其不同点：

Base58check编码

钱包账户体系，多币种钱包账户管理

BIP-44标准

多币种多账户钱包需要遵循BIP-44标准，BIP-44指定了由5个预定义树级别组成的结构:

m / purpose' / coin_type' / account' / change / address_index

第一级“purpose”总是设置为44'。第二级“coin_type”指定加密货币的类型。在标准文件中定义了若干币种，名为slip0044：https://github.com/satoshilabs/slips/blob/master/slip-0044.md

举几个例子: 以太坊是m/44'/60'，以太坊经典是m/44'/61'，比特币是m/44'/0'，所有加密货币测试用m/44'/1'。

树的第三级是“account”，它允许用户将钱包细分为独立的逻辑子帐户，第四层是“change”，有两个子树，一个用于创建接收地址，一个用于创建付款地址。

第五层“address_index”作为第四级的子级派生，例如，在主要账户中，以太坊付款的第三个接收地址是M/44'/60'/0/2。

钱包的导入与备份

钱包的备份上面已经描述了，主要分为私钥的导出、助记词的备份、keystore导出备份。

钱包的导入主要就是针对已经备份的私钥、助记词、keystore恢复钱包，也就是前面描述的钱包地址生成的流程。

JSON-RPC接口的调用

熟悉官方的JSON-RPC接口，部署钱包节点，然后进行接口调用即可。

交易验证、交易构建、交易签名、广播交易

交易首先需要了解交易结构。BTC的交易都是基于UTXO的，我们需要了解的是BTC交易输入和输出的关系：

ETH我们需要搞清楚gas的含义；而EOS我们需要理清楚密钥对、账户、权限的关系。

交易构建弄清楚交易结构就很好弄了，而广播交易只需要调用JSON-RPC接口即可。

交易验证主要验证交易签名以及交易的合法性。

交易签名

以BTC为例：

遍历交易的所有vin
把该vin对应的utxo的地址的公钥放入scriptSig
把包含些公钥的交易（包含vin&vout数据）整体做Hash->得到待签名的交易的Hash值
用该utxo对应私钥，对该Hash进行签名，比如SignatureHash函数->得到该私钥对该笔交易的签名数据
把签名数据组装到scriptSig
完成一个vin的签名
重复已上动作至vin遍历完

签名流程：

首先我們先暫時的在 raw transaction 後面掛上 4 bytes 的 hash type code，一般的 transaction 來說都用 SIGHASH_ALL (0x00000001)，要記得因為也是用 little endian 表示所以是 01000000
然後我們把整串 raw transaction 複製一份之後拿去做兩次 SHA256
接著把兩次 SHA256 的結果連同我自己的 private key 一起送去 ECDSA 簽名，會得到一個 signature
再來把 signature 後面再掛上 1 byte 的 hash code type，在這邊一樣是 01 的 SIGHASH_ALL
最後把上一步的 signature 連同我自己的 public key 去取代這個 raw transaction 原本的 input unlocking script，記得也要符合 script language，所以 signature 和 public key 前面都需要加他們的長度

而ETH和EOS也都是使用ECDSA进行签名，签名对象其实都是交易hash，只是说中间的步骤以及数据结构不一样。

智能合约的编写与调用

ETH的智能合约编写现在主要使用solidity编写，使用Truffle工具进行智能合约开发，然后进行合约测试以及发布。使用JSON-RPC或者web3框架进行合约调用。

EOS的智能合约使用C++进行编写，然后使用eosjs框架进行调用。

数据结构的序列化与反序列化

Merkle树

BTC的数据结构为Merkle树，理解了Merkle树的原理就可以获取相对应的数据。

如果在树中（树的根除外）形成一行时，具有奇数个元素，则最后的双重哈希将被复制以确保该行具有偶数个哈希。
首先形成树的底部行，其中区块中的交易的字节流具有有序的双SHA-256散列。
然后它上面的那行包含一半的哈希数。每个条目都是树中它下面相应两个哈希的64字节串联的双SHA-256散列。
该过程以递归方式重复，直到我们到达由单个双重哈希组成的行。这就是树的Merkle根。

假设一个包含三个交易a,b和c的区块。Merkle树是：

d1 = dhash (a)
d2 = dhash (b)
d3 = dhash (c) 
d4 = dhash (c)   // a,b,c总数为3，这是一个奇数，所以将c取两次

d5 = dhash (d1 concat d2)
d6 = dhash (d3 concat d4)

d7 = dhash (d5 concat d6)

其中

dhash (a)= sha256(sha256 (a))

d7是该区块中3笔交易的Merkle根。

RLP编码

RLP旨在成为高度简化的序列化格式，它唯一的目的是存储嵌套的字节数组。

RLP编码功能只处理两类数据：字符串（字节数组）和列表（list）。

了解即可，使用web3j可以实现对应的序列化以及反序列化，而bitcionj也封装了交易数据的序列化与反序列化。