关于 Bitcoin 的钱包

在 Bitcoin 中有两种主要类型的钱包，分别为：

1. 非确定性钱包（Nodeterministic Wallet）：该钱包中的每个密钥都是从不同的随机数独立生成的，密钥彼此之间没有任何关系，这种钱包也被称为 JBOK 钱包（Just a Bunch Of Keys）；
2. 确定性钱包（Deterministic Wallet）：其中所有的密钥都是从一个主密钥派生出来的，这个主密钥就是种子（seed），在该类型的钱包中，所有的密钥之间都是相互关联的，如果有原始种子，就可以再次生成全部的密钥；在确定性钱包中，可以使用不同的密钥推导方式。目前最常用的推导方法是 树状结构，也称为 分层确定性钱包 或 HD 钱包；

我们文章的目的就是生成 HD 钱包，HD 钱包 可以允许用户在不安全的服务器上使用，或者在每笔交易中使用不同的公钥。

概述

本篇主要尝试了采用 Ethereum 生成的私钥和公钥来对数据进行加解密。在进入示例之前先简单了解一下 Ethereum 私钥和公钥的生成过程。

密钥对的生成

其实无论是 Ethereum 还是 Bitcoin，他们的私钥本质上就是一个 256 个二进制位的随机数字（2^256 ~ 10^77，目前可见宇宙中估计只含有 10^80 个原子），譬如：你可以自己选择 256 个 0 作为自己的私钥，但是这明显是不安全的，而要选择足够安全的随机数，也就是要找到足够安全的熵源，即：随机性来源，最好选择密码学安全的伪随机数生成器（CSPRNG）。下面我们看下 Ethereum(go-ethereum) 的源码中如何生成公私钥对的：

前言

随着一些交易所搞的上币排名的活动开展，也带来了空投的火爆，当然也给以太坊整个网络带来了很大的考验（极其拥堵、交易费水涨船高），本篇文章还是从技术上来看看实现空投的一种通用方案。

关于空投的实现需要提前了解一下 ERC20 标准中的下面几个函数：

• **approve(_spender, value)**：该函数表示允许 _spender 多次取回调用此函数的的账户中的 token，最高为 value 个 token，后面再次调用此函数会覆盖之前设置的余额；
• **allowance(_owner, _spender)**：返回 _spender 仍然可以从 _owner 中提取的 token 余额；
• transferFrom(_from, _to, _value): 该方法主要用于允许 contract 来自动执行转账流程，并代表所有者发送 _value 个 token；

• ERC20 标准的基础知识，可以看下这篇 Understanding ERC-20 token contracts
• 实现和部署自己的符合 ERC20 Token 标准的文章，可以参考 使用 Web3J 发个以太坊 ERC20 Token

实现流程

https://swarm-guide.readthedocs.io/en/latest/introduction.html

关于 Swarm

Swarm 是一个分布式存储平台、提供内容分发服务、作为 web3 stack 的原生基础服务，其主要目标是为 Ethereum 的公共记录（如：DApp 代码、数据、以及区块链的数据等等）提供一个去中心化的、冗余备份的存储。

从经济角度来看，Swarm允许参与者高效地共享他们的存储和带宽资源，以向所有参与者提供服务。

从用户视角来看，Swarm 除了上传不需要指定服务器之外，其他的与现有互联网的使用方式没有什么不同。Swarm 的 P2P 存储和服务可以防止 DDOS 攻击、不停机、容错性高、以及 censorship-resistant。

关于 Swarm 与 IPFS 的异同

Swarm 其实是与 IPFS & Filecoin 相似的，因为 IPFS 本身没有激励机制。

关于 Truffle

简单来说，Truffle 就是一个用于开发以太坊合约的集成框架，其支持的很多命令可以方便灵活的支持编译、测试、部署合约或者DApp。关于 Truffle 更详细的介绍，可以参考Truffle 官方文档。

下面从编写、编译和部署一个简单的合约来看一下 Truffle 框架的使用。

下面以项目 HelloToken 为例，各个步骤的操作都假设已安装了 truffle 和 geth 环境。

• truffle 安装参考

关于 ERC20 规范

ERC20 为 Ethereum 上的 Token 合约标准规范，遵守该规范的 Token 合约可以被各种以太坊钱包、以及相关的平台和项目支持，如在 etherscan 上可以查看遵守 ERC20 规范的 Token 信息和交易记录。

1. 什么是 keystore 文件

以太坊的每个外部账户都是由一对密钥（一个公钥和一个私钥）定义的。账户以地址为索引，地址由公钥衍生而来，取公钥的最后 20个字节。每对私钥 /地址都编码在一个钥匙文件里，也就是我们说的keystore文件。该文件是 JSON 文本文件，可以用任何文本编辑器打开和浏览。钥匙文件的关键部分，账户私钥，通常用你创建帐户时设置的密码进行加密。也就是说 keystore 文件，就是你独有的、用于签署交易的以太坊私钥的加密文件。如果你丢失了这个文件，你就丢失了私钥，意味着你失去了签署交易的能力，意味着你的资金被永久的锁定在了你的账户里。

2. keystore 文件的内容

我们先看一下keystore文件都包含哪些数据:

go-ethereum 中的所有区块数据都存储在 leveldb 中，并且 go-ethereum 又基于 leveldb 进行了一层简单的封装。

leveldb 是一个由 Google 开源（BSD）的 KV（Key/Value Pair）非关系型数据库，是基于 LSM(Log-Structured-Merge tree) 的典型实现。

主要有如下几个特性：

• Keys 和 Values 均为任意长度的字节数组；
• Data(KV) 默认以 Key 字典序排序存储，也可以提供自定义的排序算法来重载排序；
• 基本操作包括：Put(k,v)，Get(k)，Delete(k)；
• 支持原子级的批量(Batch)操作；
• 可以创建数据全景(transient)的 snapshot，并支持在 snapshot 中查找数据；
• 支持前向和后向迭代遍历数据；
• 数据自动采用 Snappy 压缩算法进行压缩；
• 可移植性；

源码目录如下，主要就下面 4 个源码文件：

1
2
3
4
5
6

➜  ethdb :
.
├── database.go        // leveldb 的封装代码
├── database_test.go   // 测试用例
├── interface.go       // 定义了 Database 的一些操作接口
└── memory_database.go // 供测试环境使用的基于内存的数据库

• EVM：Ethereum Virtual Machine，以太坊虚拟机，这是一个隔离的轻量级的VM，运行在其中的智能合约代码无法访问本地网络、文件系统和其他进程；

• EOA: External Owned Accounts，以太坊外部账号，通过与其关联的私钥（private key）来发送 ether 和 消息；

• Contracts Accounts：合约账户，存储可在 EVM 中执行的智能合约代码，只能被 EOA 来调用激活，当合约账户被调用时，存储其中的智能合约会在矿工处的EVM中自动执行，并消耗一定的 Gas，Gas 通过 EOA 中的以太币进行购买；

• Transaction: 以太坊中的交易是指从 EOA 发送给另一个账户的消息的签过名的数据包，一笔交易主要包括：接收方、发送方、gasLimit、gasPrice、Value(交易金额)等等；

• Message：消息是一个不能序列化的，并且只存在于以太坊运行环境中的虚拟对象，一条消息主要包括：消息的发送方、接收方、gasLimit等等；

• Smart Contract: 智能合约，是以太坊中最重要的一个概念，以太坊支持通过图灵完备的高级语言，如：Solidity、Serpent等来开发智能合约，其可以接受来自外部的交易请求和事件来触发合约代码逻辑，进一步生成新的交易和事件，甚至进一步调用其他的智能合约；Smart Contract Wiki

今天抽时间浏览了 Ethereum 的区块结构的相关源码，更加深入地了解区块的数据结构。

分析的主要是 go-ethereum 项目的源码。版本取的是 Frost(v1.8.2)。

1. 以太坊的基本结构

先大致了解了以太坊的基本结构，如下图（来自网络）:

其中除了区块链管理（Blockchain Management）和挖矿模块（Miner）之外还包含了：

• 基础的分布式数据库结构（Swarm）；
• 智能合约（Solidity、Serpent、LLL等），及执行环境 EVM；
• 共识机制（PoW-Ethash，PoS）；
• 账户管理；
• 加密算法模块（SHA-3、RLP等）；
• P2P 网络（Whisper）；
• 应用模块（DApp、浏览器钱包-Mist、桌面钱包-EtherWallet、JS框架-Web3js）；