Add files via upload
This commit is contained in:
@@ -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 的优点,通常将部分功能(如订单撮合)放在链下以提高效率,而将资产结算和托管放在链上以确保安全和去中心化。这种模式目前仍在发展中,但尚未成为主流
|
||||||
@@ -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` 指令时,它通常意味着一个参数正在被复制到内存中
|
||||||
@@ -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` 中的所有以太币被耗尽
|
||||||
@@ -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 项目的经济模型漏洞,远比单纯的代码审计复杂。它需要对**区块链机制、智能合约、博弈论和金融市场**有深刻的理解
|
||||||
@@ -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 等。这些曲线是实现高效零知识证明的基础
|
||||||
|
- **哈希函数**:用于数据完整性检查
|
||||||
@@ -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` 命令运行你的测试用例
|
||||||
@@ -0,0 +1,42 @@
|
|||||||
|
### 智能合约的鉴权、公私密钥
|
||||||
|
|
||||||
|
**什么是鉴权?**
|
||||||
|
|
||||||
|
在传统中心化系统中,鉴权通常是指验证用户身份的过程,比如通过用户名和密码登录。但在区块链和智能合约中,鉴权的方式完全不同,它依赖于密码学而非用户名
|
||||||
|
|
||||||
|
在智能合约中,**鉴权就是验证发起交易的账户是否拥有执行某个特定操作的权限**。这个验证过程通常通过**数字签名**(Digital Signature)来实现
|
||||||
|
|
||||||
|
当你从一个地址向智能合约发送一笔交易时,这笔交易中包含了你想要执行的函数和参数。为了证明这笔交易确实是你发起的,你需要用你的**私钥**对交易数据进行签名
|
||||||
|
|
||||||
|
智能合约或区块链网络会使用与你私钥对应的**公钥**来验证这个签名。如果签名验证成功,系统就会确认这笔交易的合法性,并执行相应的操作
|
||||||
|
|
||||||
|
**公私密钥:鉴权的基石**
|
||||||
|
|
||||||
|
公私密钥对是区块链鉴权的核心。它基于非对称加密算法(如椭圆曲线加密算法)。
|
||||||
|
|
||||||
|
**1. 私钥(Private Key)**
|
||||||
|
|
||||||
|
- **定义**:一个随机生成的、非常长的数字。它就像你银行账户的密码,是你的**身份唯一凭证**
|
||||||
|
- **功能**:用于**对交易进行数字签名**。只有私钥持有者才能生成有效的签名
|
||||||
|
- **安全性**:私钥必须绝对保密。一旦泄露,你的所有资产都可能被盗
|
||||||
|
- **形象比喻**:你的**银行卡密码**
|
||||||
|
|
||||||
|
**2. 公钥(Public Key)**
|
||||||
|
|
||||||
|
- **定义**:从私钥通过加密算法推导出来的一串数字
|
||||||
|
- **功能**:用于**验证私钥生成的数字签名**。任何人都可以拥有你的公钥,就像任何人都可以拥有你的银行账户号码。公钥可以公开,因为无法通过公钥反向推导出私钥
|
||||||
|
- **形象比喻**:你的**银行账户号码**
|
||||||
|
|
||||||
|
**3. 地址(Address)**
|
||||||
|
|
||||||
|
- **定义**:由公钥通过哈希函数派生出来的一串字符
|
||||||
|
- **功能**:用于接收和发送资产,是你在区块链上的**公开身份**
|
||||||
|
|
||||||
|
**工作流程总结:**
|
||||||
|
|
||||||
|
1. 你想要调用智能合约中的一个函数(比如提款)
|
||||||
|
2. 你用**私钥**对交易数据(包括函数名、参数和目标合约地址)进行**签名**
|
||||||
|
3. 你将签了名的交易广播到区块链网络
|
||||||
|
4. 网络中的节点接收到交易后,会使用你的**公钥**来**验证签名**
|
||||||
|
5. 如果签名有效,交易被确认,并被打包进一个区块
|
||||||
|
6. 智能合约执行你请求的操作
|
||||||
@@ -0,0 +1,34 @@
|
|||||||
|
### 数字钱包的身份认证
|
||||||
|
|
||||||
|
**数字钱包的身份认证:一个去中心化的过程**
|
||||||
|
|
||||||
|
在区块链和加密货币的世界里,数字钱包的**身份认证**(Authentication)与我们习惯的传统银行或互联网服务的身份认证截然不同。它不是通过用户名和密码,而是通过一种基于**密码学**的、去中心化的方式来完成
|
||||||
|
|
||||||
|
这个过程的核心是**公私密钥对**。你可以把它们想象成一套独特的钥匙,这套钥匙代表了你在区块链上的身份和资产所有权
|
||||||
|
|
||||||
|
**1. 核心机制:公私密钥对**
|
||||||
|
|
||||||
|
每个数字钱包都包含一个独一无二的**私钥**(Private Key)。这个私钥是一个非常长的随机数字,它就像你银行保险箱的唯一密码
|
||||||
|
|
||||||
|
- **私钥**是你的**所有权证明**:只有拥有私钥,你才能控制钱包里的资产
|
||||||
|
- **私钥**用于**签名**(Signing):当你想要进行一笔交易(比如转账或与智能合约交互)时,你需要用你的私钥对这笔交易数据进行数字签名
|
||||||
|
|
||||||
|
与私钥配对的是一个**公钥**(Public Key)。公钥是从私钥通过加密算法生成的,它就像你的银行账户号码
|
||||||
|
|
||||||
|
- **公钥**用于**验证**:任何人都可以使用你的公钥来验证你用私钥生成的签名是否有效
|
||||||
|
- **公钥**是公开的:即使公开了公钥,攻击者也无法反向推导出私钥
|
||||||
|
|
||||||
|
最终,你的**钱包地址**(Wallet Address)是根据公钥生成的。它是你接收资金的公开身份,你可以放心地分享给任何人
|
||||||
|
|
||||||
|
**2. 身份认证的工作流程**
|
||||||
|
|
||||||
|
那么,钱包是如何使用这个机制来验证你的身份的呢?整个过程是自动化的,对用户来说是透明的,但背后的原理可以分解为几个步骤:
|
||||||
|
|
||||||
|
1. **用户发起交易**:你在钱包应用中点击“发送”或“批准”一个交易,并输入相关信息(比如接收地址和金额)
|
||||||
|
2. **钱包生成交易数据**:钱包会创建一个原始交易数据包,其中包含所有交易细节
|
||||||
|
3. **私钥签名**:你的钱包会使用你独有的私钥对这个数据包进行加密签名,生成一个**数字签名**
|
||||||
|
4. **广播交易**:带有数字签名的完整交易数据包被广播到区块链网络
|
||||||
|
5. **网络节点验证**:网络中的每个节点收到这笔交易后,都会使用你钱包的公钥来验证签名
|
||||||
|
6. **身份认证成功**:如果签名验证成功,意味着这笔交易确实是由拥有该私钥的人发起的。这笔交易随后会被打包到区块中,并最终完成
|
||||||
|
|
||||||
|
这个过程有效地证明了“你就是你”,而无需向任何中心化机构透露你的身份信息
|
||||||
Reference in New Issue
Block a user