README更新

Author: 建平

README.md

@@ -178,9 +178,72 @@ Merkle 树 (MerkleTree)
 
 1. 提供了调试和可视化功能
 
+### Block
 
+Block中增加了merkleRoot_字段，其通过初始化时构造MerkleTree然后提取根节点的HASH值获得。
 
-#### `buildProofPaths` 的逻辑。
+merkleRoot_可用于在后续验证交易是否被篡改。
+
+### MerkleTree
+
+#### MerkleNode
+
+假设我们有4个交易（A、B、C、D），构建的默克尔树如下：
+
+```
+        Root
+       /    \
+      /      \
+    AB        CD
+   /  \      /  \
+  A    B    C    D
+```
+
+相邻节点一起构造了一个父节点，其Hash值为2个子节点拼接后再次hash出的值。如果叶节点为奇数，则最后一个叶节点重复一次。
+
+```
+MerkleTree::printTree
+  ABCC  Level 2: 779cc102d995f0cb01c420eddc2d9a2154a992cc4d93a113e18ab34e001850a2
+    AB  Level 1: e5d5262bd00f3ab8dc254c5ed2d4a8b9a3793d3fce38e8e8a693ad451218033f
+      A  Level 0: 43caa04a00f424b1911f5fff8ee452c32e2bc945ae8a88a05183021d27a69446
+      B  Level 0: 7cb17ad411d33feb075223d142e3cb631afd52370cfd1961c34dc4d300978a3a
+    CC  Level 1: 37f004022cc1769ebc8214ed4a5e17b387935f308bb6b81451b2fe0f0b6193d1
+      C  Level 0: 97fd3316a49190b85a5b9305b28854d30ac937e551f759d45b56319d82b777e3
+      C  Level 0: 97fd3316a49190b85a5b9305b28854d30ac937e551f759d45b56319d82b777e3
+```
+
+### 
+
+#### ProofPaths
+
+proofPaths 表为每个叶节点构造一个最快构建出根节点的相邻节点hash列表。即顺着列表逐个拼接HASH值并hash出父节点HASH值。
+
+```
+MerkleTree::MerkleTree
+  MerkleNode::MerkleNode A 
+  MerkleNode::MerkleNode B 
+  MerkleNode::MerkleNode C 
+  MerkleTree::buildTree
+  MerkleNode::MerkleNode AB 
+  MerkleNode::MerkleNode CC 
+  MerkleTree::buildTree
+  MerkleNode::MerkleNode ABCC 
+  
+  buildProofPaths leftPath CC true
+    buildProofPaths leftPath B true
+      buildProofPaths leaf A 
+    buildProofPaths rightPath A false
+      buildProofPaths leaf B 
+  buildProofPaths rightPath AB false
+    buildProofPaths leftPath C true
+      buildProofPaths leaf C 
+    buildProofPaths rightPath C false
+      buildProofPaths leaf C 
+```
+
+
+
+##### `buildProofPaths` 的逻辑。
 
 默克尔树的证明路径（Merkle Proof）的目的是：证明某个交易确实存在于区块链中。为了做到这一点，我们需要提供从该交易到根节点的路径上所有兄弟节点的哈希值。
 
@@ -262,7 +325,7 @@ for (const auto& [siblingHash, isLeft] : path) {
 
 这就是为什么在构建路径时，我们要记录兄弟节点的哈希值而不是当前节点的哈希值。因为验证时需要的是兄弟节点的哈希值来重建父节点的哈希值。
 
-#### verifyPath逻辑
+##### verifyPath逻辑
 
 在 `verifyPath` 函数中，我们应该倒序访问路径，因为我们需要从叶子节点开始，一步步向上构建到根节点。让我修改这部分代码
 
@@ -313,3 +376,56 @@ for (auto it = path.rbegin(); it != path.rend(); ++it) {
   2. 再用 AB 和 CD 的哈希值计算 Root
 - 所以需要倒序访问路径，先处理 CD 的哈希值，再处理 B 的哈希值
 
+##
+
+
+
+## 钱包系统 / 数字签名(v0.0.4)
+
+添加钱包系统，包括密钥生成、签名和验证功能。使用 OpenSSL 的椭圆曲线加密（ECDSA）来实现。
+
+这个实现添加了以下功能：
+
+1. **钱包系统**：
+   - 使用 OpenSSL 的椭圆曲线加密（ECDSA）
+   - 支持密钥对生成
+   - 支持交易签名和验证
+   - 使用 secp256k1 曲线（与比特币相同）
+
+2. **交易签名**：
+   - 每个交易都可以被签名
+   - 签名使用发送方的私钥
+   - 任何人都可以使用发送方的公钥验证签名
+
+3. **安全性**：
+   - 私钥永远不会离开钱包
+   - 所有敏感操作都有适当的错误处理
+   - 使用 OpenSSL 的安全随机数生成
+
+4. **主程序：**
+   1. 创建三个钱包（Alice、Bob 和 Charlie）
+   2. 为每个钱包生成密钥对
+   3. 创建并签名交易
+   4. 验证交易签名
+   5. 创建区块链并添加区块
+   6. 验证区块链的有效性
+   7. 打印详细的区块链信息，包括：
+      - 区块基本信息（索引、时间戳、哈希等）
+      - 交易详情
+      - Merkle 树结构
+      - 交易验证结果
+
+### 钱包
+
+- 钱包其实是相对于用户，而每笔交易对应着2个钱包之间。
+- 钱包生成时核心数拥有自己的私钥和公钥，私钥永不对外暴露，而公钥则暴露给交易
+- 钱包可对自己作为发起方的交易签名，签名时使用私钥加密
+
+### 交易
+
+- 交易保存交易双方的公钥（替代交易双方的HASH值）
+- 交易由发起方的钱包对交易的HASH值签名，并将签名保存在交易内
+- 交易可通过发起方的公钥对签名解码，解码后是否和交易HASH值一致判断交易是否签名合法
+
+
+