[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也封装了交易数据的序列化与反序列化。
