长久以来，区块链上运行的智能合约无法直接的与外部系统进行交流，这一瓶颈限制了智能合约应用场景。

如今，我们可以通过引入预言机（Oracle）的功能来解决这一问题，预言机可以为智能合约提供与外部世界的连接性。但是目前的预言机都是中心化的服务，这会给使用中心化预言机服务的智能合约带来单点故障的风险，使得智能合约的去中心化特性变得毫无意义。

为了解决这个问题，Chainlink开发了首个去中心化预言机项目，来向智能合约提供外部数据。有了这个武器，智能合约的安全性和确定性，与真实世界中发生的各类事件联系了起来。Chainlink将为您的智能合约提供获取任意外部API数据的能力。本文档列出了所有与之相关的信息。

• 关键字：
  • 预言机
  • 去中心化

Chainlink 文档：https://docs.chain.link/docs/getting-started

1.1. 开发工具

1.1.1. Remix Solidity IDE

Remix 是一个网页端的集成开发环境，可以用它在浏览器里创建、运行、调试智能合约。它由以太坊基金会开发维护。通过 Solidity 开发智能合约所需的一切都在 Remix 的 WEB 界面上提供了，所以开发者无需自行搭建开发环境了。Remix 可以大大简化合约的部署方法，无需使用命令行界面即可方便的部署合约。

Remix 主要是编写 solidity 合约，编译，部署和调用。

IDE 地址：https://remix.ethereum.org/

1.1.2. MetaMask

MetaMask是一款浏览器插件钱包，不需下载安装客户端，只需添加至浏览器扩展程序即可使用。

使用 Remix Solidity IDE 的 Injected Web3 环境，配合 MetaMask 插件可方便部署智能合约到以太坊测试网或者主网。

MetaMask 主要部署合约到测试网，进行合约的调试。

1.1.2.1. 安装 MetaMask

MetaMask 下载地址：https://metamask.io/download.html

1. 安装好 MetaMask 的 Chrome 插件后，点击 MetaMask 的小狐狸图标打开扩展程序。
2. 创建一个新的账户。
3. 您将会看到由12个单词组成的助记词，拷贝这12个助记词到一个只有你自己知道的安全的地方。
4. 点击头像，进入设置，将网络从以太坊主网络（Main Ethereum Network）切换到 Kovan 测试网络（Ropsten Test Network）。

1.1.3. 测试网络

当前可用的以太坊测试网有如下：

• Rinkeby

  • 一个 POW 的区块链，非常类似于以太坊主网。
  • 获取 Rinkeby 的以太币：https://faucet.rinkeby.io/
  • 交易查看地址：https://rinkeby.etherscan.io/

• Kovan（推荐使用）

  • 一个 POA 的区块链，不能挖矿，只能申请。
  • 获取 Kovan 的以太币：https://faucet.kovan.network/
  • 加入 gitter 中的 faucet 组织：https://gitter.im/kovan-testnet/。在 gitter 的社区中，发送自己的钱包地址（@管理员 epheph ），就可以获得 4 个测试代币
  • 交易查看地址：https://kovan.etherscan.io/

1.2. 调试 Chainlink 合约

1.2.1. 获取 LINK 代币

• 打开 LINK 代币的获取地址：https://kovan.chain.link/
• 从 MetaMask 中获取帐号地址，复制输入框中，点击 Send me 100 Test LINK 按钮
• 点击 MetaMask 插件，点击添加代币，选择自定义代币，填写 LINK 代币的地址后自动填充代币信息，点击下一步，完成添加。
  • Rinkeby: 0x01BE23585060835E02B77ef475b0Cc51aA1e0709
  • Kovan : 0xa36085F69e2889c224210F603D836748e7dC0088

1.2.2. PriceConsumerV3 获取 ETH/USD 汇率价格

• 打开 Remix Solidity IDE 编辑器，在 Featured Plugins 选择 SOLIDITY
• 复制合约代码

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

pragma solidity ^0.6.7;

import "https://github.com/smartcontractkit/chainlink/evm-contracts/src/v0.6/interfaces/AggregatorV3Interface.sol";

contract PriceConsumerV3 {

    AggregatorV3Interface internal priceFeed;

    /**
     * Network: Kovan
     * Aggregator: ETH/USD
     * Address: 0x9326BFA02ADD2366b30bacB125260Af641031331
     */
    constructor() public {
        priceFeed = AggregatorV3Interface(0x9326BFA02ADD2366b30bacB125260Af641031331);
    }

    /**
     * Returns the latest price
     */
    function getLatestPrice() public view returns (int,uint80) {
        (
            uint80 roundID, 
            int price,
            uint startedAt,
            uint timeStamp,
            uint80 answeredInRound
        ) = priceFeed.latestRoundData();
        // If the round is not complete yet, timestamp is 0
        require(timeStamp > 0, "Round not complete");
        return (price,answeredInRound);
    }
}

• 部署，调用合约

  • 点击 Deploy 按钮时，会弹出 MetaMask 页面，点击确认继续
  • 点击 getLatestPrice 按钮，调用合约，即显示当前 ETH/USD 的价格
    
    

• 查看 Price Feed Contracts 合约内容：https://kovan.etherscan.io/address/0x9326BFA02ADD2366b30bacB125260Af641031331#code

1.2.3. 调用 VFR 合约获取随机数

• 打开 Remix Solidity IDE 编辑器，在 Featured Plugins 选择 SOLIDITY
• 复制合约代码

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44

pragma solidity 0.6.6;

import "https://github.com/smartcontractkit/chainlink/evm-contracts/src/v0.6/VRFConsumerBase.sol";

contract RandomNumberConsumer is VRFConsumerBase {
    
    bytes32 internal keyHash;
    uint256 internal fee;
    
    uint256 public randomResult;
    
    /**
     * Constructor inherits VRFConsumerBase
     * 
     * Network: Kovan
     * Chainlink VRF Coordinator address: 0xdD3782915140c8f3b190B5D67eAc6dc5760C46E9
     * LINK token address:                0xa36085F69e2889c224210F603D836748e7dC0088
     * Key Hash: 0x6c3699283bda56ad74f6b855546325b68d482e983852a7a82979cc4807b641f4
     */
    constructor() 
        VRFConsumerBase(
            0xdD3782915140c8f3b190B5D67eAc6dc5760C46E9, // VRF Coordinator
            0xa36085F69e2889c224210F603D836748e7dC0088  // LINK Token
        ) public
    {
        keyHash = 0x6c3699283bda56ad74f6b855546325b68d482e983852a7a82979cc4807b641f4;
        fee = 0.1 * 10 ** 18; // 0.1 LINK
    }
    
    /** 
     * Requests randomness from a user-provided seed
     */
    function getRandomNumber(uint256 userProvidedSeed) public returns (bytes32 requestId) {
        require(LINK.balanceOf(address(this)) > fee, "Not enough LINK - fill contract with faucet");
        return requestRandomness(keyHash, fee, userProvidedSeed);
    }

    /**
     * Callback function used by VRF Coordinator
     */
    function fulfillRandomness(bytes32 requestId, uint256 randomness) internal override {
        randomResult = randomness;
    }
}

• 部署合约，获取部署的合约地址

  • 点击 Deploy 按钮时，会弹出 MetaMask 页面，点击确认继续

• 重要：转入 LINK 代币到合约

  • 获取部署后合约的地址
  • 在 MetaMask 向合约地址转入 LINK 代币

• 调用合约，获取随机数
  • 先发送获取随机数请求
  • 发送请求获取生成的随机数
    

提示：

• 如果没有向部署的合约转入 LINK 代币，会提示错误：Gas estimation errored with the following message (see below). The transaction execution will likely fail. Do you want to force sending?
• The execution failed due to an exception. Reverted。

2018 年 11 月 6 日，中国人民银行发布的《区块链能做什么？不能做什么？》报告中，是这样对预言机定义的：

区块链外信息写入区块链内的机制，一般被称为预言机 (oracle mechanism) 。

从定义来看，预言机的功能就是将外界信息写入到区块链内，完成区块链与现实世界的数据互通。它允许确定的智能合约对不确定的外部世界作出反应，是智能合约与外部进行数据交互的唯一途径，也是区块链与现实世界进行数据交互的接口。预言机作为区块链和现实世界之间的纽带，扮演这数据互通的角色。

2. 为什么需要预言机？

在说明为什么需要预言机之前，我们需要知道区块链最重要的特点：

1. 具有确定状态的状态机

   • 区块链的本质就是一个状态机。
   • 系统中所有的节点从同一个创世状态开始，依次运行达成共识的区块内的交易，驱动各个节点的状态按照相同操作序列（增加，删除，修改）不断变化，实现所有节点在执行完相同编号区块内的交易后，状态完全一致，我们把这个状态称之为世界状态。

2. 没有边界

   • 没有固定数量的节点，一旦达成共识，每个节点的状态必须保持一致。

如果说区块链就是一个状态机，那么改变这个状态的就是 EVM（以太坊虚拟机）。它能够在分散的网络中的任何节点上执行程序，并更新受共识规则约束的区块链状态。为了保持共识，EVM 的执行过程必须完全确定。这就产生了两个比较重要的结果：

• EVM 和智能合约没有内在的随机性来源；

  • 节点 A 将执行命令并代表智能合约存储 3 在其存储中，而节点 B 执行相同的智能合约，将存储 7。这样会导致节点 A 和 B 的结果有两种情况，虽然执行的是相同的代码，这样就会导致节点之间无法达成共识。

• 外部数据只能通过交易数据传入；

  • 区块链是确定性的环境，不允许不确定的事情或因素，智能合约不管何时何地运行都必须是一致的结果。所以虚拟机（VM）不能让智能合约有 network call（网络调用），从外部是获取数据，不然就会导致结果不的不确定性，从而也无法达成共识。

区块链是一个封闭的环境，链上是无法主动发起 Network call（网络调用）主动获取链外真实世界的数据，只能被交易触发，被动的通过交易接收数据。其次，智能合约最终的执行需要合约参与方的私钥签署，智能合约本身没有办法自动执行。

所以，预言机就是为了解决智能合约无法主动去获取链外的数据，只能被动接受数据的问题，能够让智能合约主动从外部获取数据。

2.1. 预言机的实现

上图就是理想中预言机的工作流程，即用户的智能合约把请求给链上 Oracle 合约，通过链下的 API 接口获得外部数据，更确切的说是外部把数据给链上的 Oracle 合约，然后 Oracle 合约再把数据给用户的智能合约。

3. 预言机的应用场景和示例

在理想的情况下，预言机提供了一种无信任（或者至少近乎无信任）的方式来获取外在的（即“真实世界”或“链外”）信息，例如足球比赛的结果，黄金的价格或真正的随机数字，用于以太坊平台上的智能合约。

1. 可以将预言机视为弥合链外世界与智能合约之间差距的机制；
2. 允许智能合约基于真实世界的事件和数据来强制执行合约关系（基于智能合约实行的航空延误险）；

但是，这样的模式也会给以太坊的安全模型带来外部风险。

假如有一个“智能遗嘱”的合约–当一个人去世时分配资产。如果这样的合约控制的继承金额足够高，那么在所有者死亡之前攻击预言机（发出假的死讯）并触发资产分配的动机是非常强烈的。

3.1. 数据来源的真实性

某些预言机可以提供某些私有数据源的数据，例如学术证书和政府 ID。这些数据的来源，如大学或者政府部门，是完全可信的。

数据的真实性是主观的（真相只能通过来源的权威来确定）

3.2. 适用场景

预言机作为区块链与现实世界进行数据交互的桥梁，应用场景非常多，可以说一切需要与链下进行数据交互的 DApp 都需要预言机。

• 来自物理来源的随机数/熵（例如量子/热现象）：公平地选择彩票智能合约中的赢家，博彩游戏
• 与自然灾害相关的参数触发器：触发巨灾债券智能合约（对于飓风债券来说的风速）
• 汇率数据：将稳定币与法定货币准确挂钩
• 资本市场数据：代币化资产/证券的定价篮子
• 基准参考数据：将利率纳入智能金融衍生品
• 损害赔偿：保险合约
• 航班延误：保险合约

3.2.1. DeFi

目前最主要的场景就是 DeFi（Decentralized Finance，去中心化金融）

DeFi 领域的项目为什么需要预言机。类似 DAI 这样的稳定币系统，需要获取 ETH 的实时价格，来判断所抵押的加密货币是否达到了平仓价格进而触发平仓。假设有 1000 个节点，那就需要向交易所（比如币安）或 CoinMarketCap 的 ETH / USDT 交易对进行 1000 次的 API 数据请求 ，但是，由于 ETH 的价格是实时变动的，加上网络延迟、计算速度等原因，每个节点获取到的价格可能都不相同，这部分数据被输入到智能合约后，节点间无法达成共识，那么整个系统就会崩溃。

3.2.2. 博彩游戏

博彩游戏的核心是不可预测、可验证的随机数，从而决定赌注的最终结果，但是在链上是无法生成随机数的或者说在链上的随机数是可以被预测和破解的，这时候就需要预言机从外部给智能合约安全的、不可预测的随机数。

现在的大多数博彩游戏都是在链上生成随机数，所以很容易被预测和破解，导致资产被盗，大家有兴趣的可以去看一下DApp被盗的相关研究报告，很多因为随机数问题被盗的。比如 BetDice、Dice2Win。

关于智能合约中的随机数，可以参考 DOS Network 创始人@nrek jonny 关于《智能合约中的随机数》的分享。其实，早在 Fomo3D 这个游戏出来之后，以太坊的 Team Leader 就在推特上说过链上是无法生成随机数的。

Dear devs… you can`t generate random numbers on chain！

4. 预言机的设计模式

4.1. 预言机的基本功能

1. 从链外的数据源收集数据。
2. 使用签名消息在链上传输数据。
3. 将数据放入智能合约的存储空间，使数据可用。

一旦数据在智能合约的存储中可用，其他智能合约就可以通过调用预言机智能合约的“检索”功能来访问。

4.2. 预言机的设计模式

预言机有三种设计模式：

1. 立即读取
2. 发布与订阅
3. 请求与相应

4.2.1. 立即读取

• 在需要时即时获取
• 比如，这个人是否满 18 岁；
• 数据存储在合约中，其他智能合约使用对语言及合约的请求调用来查找（跟请求和响应的区别是，不涉及外部交互）

4.2.2. 发布与订阅

• 链上智能合约轮询
• 链外守护进程监视和更新
• 比如，价格查询，天气信息，交通数据
• 轮询可能消耗大量的 gas

4.2.3. 请求与相应

• 最复杂的情况
• 数据空间太大，无法存储在智能合约中，并且每次用户值需要整个数据集的一小部分
• 数据提供商的业务模型

主要步骤：

• 接受来自 DApp 的查询
• 解析查询
• 检查是否符合付款和数据权限/权利义务
• 从链外数据源检索相关数据（并在必要时加密）
• 使用包含的数据对事物进行签名
• 将事务广播到网络
• 安排任何进一步必要的交易，例如通知等

类似的，可以从外部所有帐户（EOA）请求数据并直接返回数据，从而无需使用oracle 智能合约。也可以向支持物联网的硬件传感器发出请求和响应。因此，oracle 可以是人，软件或硬件。

5. 数据认证

在“请求/响应”模式下，可能会存在多个实体的操作，如何防止数据在传输中被篡改？所以，必须要让链外方可以证明返回数据的完整性。

两种方式：

• 真实性证明（authenticity proof）
• 可信执行环境（Trusted Execution Environment, TEE）

5.1. 真实性证明

真实性证明是用密码学证据证明数据没有被篡改过，比如使用数字签名。

将信任从数据提供者转移到证明者（证明方法的提供者），通过在链上验证真实性，智能合约能够在对其进行操作之前验证数据的完整性。

5.1.1. Oraclize

Oraclize：为以太坊提供中心化预言机服务

Oraclize 依托亚马逊 AWS 服务和 TLSNotary 技术，是一个可证明的诚实的预言机服务，不过它是中心化的，目前只能在以太坊网络使用，而且 gas 费较高。但是不妨碍它是目前很受欢迎的预言机服务，也可能是因为还没有更好的选择吧。这里有 Oraclize 详细的使用说明：Oraclize Documentation

特点：

• 中心化
• 基于亚马逊 AWS 服务和 TLSNotary 技术
• 智能在以太坊网络适用
• gas 费用较高

基础：亚马逊不会篡改虚拟机实例。

5.2. 可信执行环境

基于硬件的安全区（security enclave）来验证数据的完整性。

5.2.1. TownCrier

TownCrier 基于英特尔的 SGX（Software Guard eXtensions）提供：

• HTTPS 查询的响应可靠性验证

• 完整性保证

  • 确保在安全区内运行的应用程序受到CPU的保护，防止任何其他进程被篡改

• 机密性保证

  • 应用程序在安全区中运行时，其状态对其它进程来说是不可知的

基础：假设信任（Intel/SGX）。

6. 计算型的预言机

以太坊上的计算成本太高，出现了提供密集计算功能的预言机。

Oraclize 提供的服务允许去中心化应用请求输出在沙盒 AWS 虚拟机中执行的计算。

作为可验证预言机事实上的标准，“Cryptlet” 的概念已经被规范化为微软更广泛的 ESC 框架的一部分。

TrueBit 是一个可扩展和可验证的链外计算的解决方案。它引入了一个解决这和验证者系统，分别执行计算和验证。

7. 去中心化的预言机

大多的预言机都是中心化的预言机系统，需要依赖可信的权威：

• Oraclize 需要假设亚马逊不会篡改虚拟机实例
• Town Crier 需要假设 Intel/SGX 不会篡改返回的数据

所有中心化的预言机都存在单点故障。

7.1. ChainLink

Chainlink：以太坊上第一个去中心化预言机解决方案

ChainLink 提出了一种去中心化预言机网络，包括三个关键的智能合约：

• 声誉合约

  • 跟踪数据提供商的绩效

• 订单匹配合约

  • 从声誉合约的语言集中选择竞标者，并最终确定服务层级要约（Service Level Agreement, SLA），其中包含了查询参数和要求的预言机数量

• 数据汇总合约

  • 使用“commit-reveal” 提交模式从多个预言机处收集相应，计算查询的最终总结果，然后将结果反馈回声誉合约。

7.2. 欧链 OracleChain

欧链 OracleChain：EOS 上的第一个去中心化预言机解决方案

欧链采用自主的 PoRD 机制（Proof-of-Reputation&Deposit），本质上是一种抵押代币奖惩机制的声誉系统，奖励数据节点惩罚作恶节点，可以实现 Augur、Gnosis 等预测市场应用的功能，还能支撑对链外数据有更高频率访问需求的智能合约业务。预测市场的结果本身有时也可以作为 Oracle 的输入数据源，欧链更像是预测市场，而且不足是单纯的声誉系统容易集中化。目前欧链只在 EOS 上开发，而且专注于提供随机数服务。

7.3. DOS Network

DOS Network：支持多条主流公链的去中心化预言机服务网络

DOS Network 是一个 Layer-2 的预言机解决方案，它通过在链上部署一个轻量级智能合约，链下是一个 p2p 网络，服务节点的选取和数据验证采用 VRF+阈值签名等技术，保证了去中心化和数据安全，并达到快速反应。可以适配所有主流公链，比如以太坊、EOS、Tron、ThunderCore、Ultrain 等。

7.4. 去中心化预言机的挑战

去中心化方案的一个重大挑战：构建数据汇总函数。

• ChainLink

  • 通过在链上的智能合约和链下的数据节点，通过奖惩机制和聚合模型的方式，进行数据的请求和馈送。不过也有一些不足，比如链式聚合成本较高，拓展性差，基于声誉系统容易集中化。他们更关注支付场景的应用，比如帮助银行与企业之间建立智能合约。

• SchellingCoin 协议

  • 将中位数作为“正确”答案。记录者必须先质押保证金，这些保证金会根据他与中位数的接近程度重新分配，由此激励人们记录与其他人提供的值相近的值。这些共同的数值，就是所谓的“谢林点”。

• Jason Teutsch 方案

  • 利用一条专用的工作量证明区块链，该区块链能够正确地报告在给定时期内的注册数据是否可用。矿工尝试下载，存储和传播所有当前注册的数据，因此保证数据在本地可用。虽然这样的系统在每个挖掘节点存储和传播所有注册数据的意义上是昂贵的，但是系统允许通过在注册周期结束之后释放数据来重用存储。

8. 中心化和去中心化的选择

在 DeFi 领域稳定币、去中心化杠杆交易、金融衍生品交易等都需要预言机，只是短期内大多数项目选择使用自己搭建的预言机服务，但实际上这会有很多问题，比如单点故障、易受攻击等，比如知名的衍生品交易平台 Synthetix 在 19 年 6 月份遭遇了 oracle 攻击，损失超过 3700 万枚 sETH，「Synthetix平台遭Oracle攻击，攻击者篡改汇率，低价大量换购sETH - 巴比特」。

这个事件的具体原因可以在这篇文章中查看「中心化预言机有多“脆弱”？从 Synthetix 被攻击事件得到反思」，

所以，在长久的来看，去中心化预言机应该是更好的方式。

9. 总结

正如上面所了解的，预言机为智能合约提供了至关重要的服务：将外部的事实带入合约执行。当然，预言机也会带来很大的风险：如果他们是受信任的来源并且可能受到损害，可能导致他们提供的智能合约执行受损。

一般来说，在考虑使用预言机时要非常的小心信任模型。一旦认为预言机可以信任，那么合约的安全性就可能因为来自预言机的错误输入受到破坏。所以，需要特别注意预言机的信任机制。

去中心化的语言既可以解决一些问题，并为以太坊智能合约提供无信任的外部数据。谨慎选择，你就可以开始探索以太坊与语言及提供的“真实世界”之前的桥梁。

交易是由外部系统账户对区块链系统发起的经过签名的消息。

**外部账户：**拥有私钥的账户，控制合约的访问（比如发起交易）；私钥用于对交易进行签名
**合约账户：**智能合约部署后的地址；没有私钥

2.

3. 交易的作用

• 触发区块链状态改变（管理资产，价值转移）
• 触发 EVM 上的合约执行；

交易的生命周期：

构建交易私钥签名网络传输到多个节点通过共识机制打包到区块执行交易（节点执行交易相关智能合约代码，修改区块链状态，存储新区块状态）交易确认生成交易回执（receipt），和交易一起保存在区块中（结果码，日志，消耗的 gas 量）

”只读”交易用于读取链上数据，节点收到请求后会根据请求的参数访问状态信息并返回，并不会将请求加入共识流程，也不会导致修改链上的数据。

4. 交易的结构

交易的本质是一串打包在一起的二进制数据。

下表是某公链的交易结构：

备注：

EOA 表示外部账户；
交易消息的结构使用递归长度前缀（RLP）编码方案；
交易结构并不包含 EOA 的地址的 “from” 字段，EOA 的公钥通过 ECDSA 签名的 v,r,s 计算得出；
不同的联盟链对数据结构有相应的扩充；比如：FISCO-BCOS 交易的数据结构和编码协议；

4.1. RLP 编码方案

RLP（Recursive Length Prefix），递归长度前缀编码：

• 主要用于数据的网络传输和持久化存储；
• 不包含任何字段的标识符或者标签；
• 使用长度偏移量来表示每个字段的长度；

参考文档：

• RLP编码

5. 交易的随机数（nonce）

nonce 是一个数值，等于这个地址发出的交易数量，当这个地址与合约关联时，是这个地址所创建的合约数量。

特点：

• 发起方地址的一个属性，只在发送地址的上下文中才有意义；
• 没有作为账户状态的一部分，显示的保存在区块链上，而是通过计算发送方地址已经确认的交易数量而动态计算；

作用：

• 创建顺序交易，去中心化系统中，保证节点按照一定的顺序（nonce 的值大小）先后处理交易；
• 交易重复保护，防止原始交易被”复制“后重复发起；

5.1. nonce 间隔

区块链网络是根据 nonce 数值的顺序处理交易，如果发出了一个 nonce = 0 的交易，接下来发起一个 nonce = 2 的交易（缺少了 nonce = 1 的交易），那么第二个交易不会被确认，会一直存在待确认交易内存池中，区块链网络会一直等待 nonce = 1 的交易出现。所有节点都认为 nonce = 1 的交易因为网络延迟问题还没有传输过来，而 nonce = 2 的交易先到。

5.2. nonce 确认

由于区块链网络处理交易是根据 nonce 的数值顺序来处理，所以，一旦中间某个交易没有被“确认”（成功处理），那么之后所有的交易都会被“卡”住，会一直等待没有被确认的交易。

交易可以在 nonce 序列中产生无意的“间隙”，比如因为它无效或 gas 不足。为了让交易能够被继续处理，你必须使用缺失的 nonce 值创建一笔有效的交易。一旦这笔确实的交易被确认后，后续的交易都会被广播，逐渐变得有效；而且无法“撤回”任何交易。

5.3. nonce 重复

如果发出两个相同的 nonce 的交易，但是接受地址，或者交易金额不同，那么只有其中的一笔交易会被确认，另一个会被拒绝。最先到达区块链网络中确认节点的那个交易会被确认（随机）

6. 交易 gas（了解 BSN 最终的计费方案？）

gas 是区块链网络中的计量单位，表示在区块链上执行具体的操作所消耗的计算量和存储资源。

特点：

• 独立的虚拟货币；

目的：

• 控制交易对资源的使用，防止虚拟机内恶意代码死循环；
• 避免拒绝服务攻击；
• 防止交易的过度消耗；
• 使用 gas 来表示对资源的消耗，不牵扯到具体的虚拟币，可以让物理资源不受虚拟币价格的波动而受到影响。

gasPrice：

• gasPrice 从字面上来看，表示 gas 的价格，表示在发起交易时，发起方愿意为每单位 gas 支付多少的 代币数量。因此，gas 的单位为：wei/gas；
• gasPrice 最低可接受的值是 0；
• gasPrice 越高，交易被确认的速度越快；

gasLimit：

• gasLimit 表示发起方为了完成交易所愿意支付的最大 gas 数量；

gasUsed：

• gasUsed 是交易中消耗的总共的 gas；
• 交易的总费用 = gasUsed * gasPrice <= gasLimit；

7. 交易的接收方（to）

to 是一个 20 字节的区块链账户地址，有两种：

• 外部账户地址：资产转移；
• 合约地址：调用合约方法；

提示：

• 区块链不会验证接收方的地址正确性。

8. 交易中的 value 和 data

交易数据包的核心是两个字段：value 和 data。

交易中 value 和 data 的情况：

• 同时包括 value 和 data：
• 只有 value：支付操作；
• 只有 data：合约调用；
• 既没有 value 也没有 data：没有意义，浪费 gas；

9. 特殊交易-合约创建

合约创建交易的目的地址是一个特殊地址–零地址（0x0），data 字段中包含经过编译的合约字节码，目的是把合约注册到区块链网络上。同事，如果 value 字段中包括了代币，表示为合约设置起始余额。

10. 交易签名

交易签名的流程：

• 创建一个包含九个字段的交易数据结构：nonce，gasPrice，startGas，to，value，data，v，r，s；
• 生成交易的RLP编码的序列化消息；
• 计算此序列化消息的Keccak256哈希；
• 计算ECDSA签名，用发起EOA的私钥签名散列；
• 在交易中插入ECDSA签名计算出的 r 和 s 值；

提示：

• v 表示链标识符 chainId。
• “简单重放攻击保护”的 EIP-155 标准。通过在交易结构中加入一个 v 变量（chainId，不同的网络 chainId 有不同的值，比如 区块链网络 A 是 1， 区块链网络 B 是 61 等等）来实现。确保在一个区块链网络（如区块链网络 A）上创建的交易在其它的区块链（如区块链网络 B 或者 区块链 测试网）上是不合法的。所以，在一个网络广播的交易，不能被重放到另一个网络，这就是所谓的重放攻击保护。

11. 离线签名

离线签名是指将交易的签名和交易的广播分开处理，将交易的签名放在一个不连外网的环境中。等交易签名后，再将签名后的交易放入到联网的网络中进行广播。

目的：

• 保护私钥的安全；

12. 总结

区块链的本质就是一个不可篡改的分布式账本，而账本是由一个个区块组成，每个区块通过引入前一个区块的 hash 值，形成一个链状结构的数据。每一个区块，包含了区块头和区块体，区块体由一笔笔交易和相关的回执信息组成。所以，交易作为区块链数据存储的最基本的单位，在区块链中扮演重重要的角色。

同时，交易也是区块链网络系统进行每项活动的起点，是区块链网络中的“输入”窗口，可以触发虚拟机执行合约，价值转换等操作，用于修改区块链的状态。

1.1. 快速创建表格（仅支持 Mac）

Markdown 的表格在创建的时候，总是需要敲很多的 |，-，耗时耗力，所以搜寻了一个 Mac Alfred 插件，可以快捷创建多行多列的表格。快捷呼出 Alfred，输入 tb 3 5，就直接在文档中插入 3 列，5 行的表格代码

参考文档：

• https://github.com/crispgm/alfred-markdown-table

1.2. 快速粘贴表格（仅支持 Mac）

如果需要把 HTML 页面，Excel 中的表格，甚至一行行 csv 格式的数据导入到 Markdown 的表格中，如果一行行手动敲表格，然后再粘贴数据就太慢了。

可以直接拷贝 HTML 和 Excel 中的表格到剪贴板，此时是 csv 的数据格式，可以快捷呼出 Alfred，输入 tbl，然后选择一个格式，即可在文档中插入表格代码。

参考文档：

• https://github.com/danielecook/markdown-table-alfred
• https://github.com/deanishe/alfred-fixum

1.3. table 合并单元格

Markdown 默认的表格语法是不支持单元格合并的，如果要实现单元格合并的功能，比如下面的表格：

要实现这个功能，需要使用 HTML 中的 <table> 语法，将表格的 HTML 插入到一对 <escape></escape>中即可。

推荐一个表格工具：在线编辑表格，支持导出，支持 HTML，Markdow

首先，查一下新华字典：

共识：指一个社会不同阶层、不同利益的人所寻求的共同认识、价值、理想。

简单理解就是指所有的参与者（关联方）都达成一致的意思。

公司的年会活动聚餐，不同的人有不同的喜好和口味，有的人喜欢吃火锅，有的人喜欢烧烤，有的人不吃辣，有的人不吃海鲜。。。

此时，共识就是指大家最终达成了一致的协定，最终选择了一个年会聚餐的地方。

2. 为什么需要共识

对于一个有多个参与者的系统或者组织，如果大家都按照各自的意愿做事，那么，这个系统和组织也就没有意义。

设想，如果在一个分布式数据库系统中，查询一个用户的余额，不同的节点，对相同的用户返回了不同的余额，那么这个系统也就毫无可靠信而言。

3. 如何达成共识

• 中心化系统

  • 在一个中心化的系统中，只需要所有的参与者都服从“中心”的安排即可。比如，数据库的主从备份，公司的组织架构管理等等。

• 去中心化系统

  • 在去中心化系统中，每个参与者都是对等的关系，没有任何的参与者是处于权力领导地位。此时，就需要使用某些特定的共识机制，来达成去中心化系统的共识，而这个共识机制，就是所谓的共识算法。

4. 区块链中的共识

区块链系统，是一个典型的去中心化的系统，包含未知数量的节点，每个节点之间都是对等关系。

在区块链系统中，每个节点（即参与者）不仅自己维护一份数据（也就是常说的区块链账本），同时，还保持跟其他节点（其它参与者）维护的数据相一致，这就是区块链中的共识。

5. 共识机制（共识算法）

在区块链共识中，协同松散耦合、互不信任的节点之间达成信任关系，并保障一致性，持续性协作的过程，通常抽象为“共识”过程，而这个过程中，所牵涉的算法和策略统称为共识机制。所以，共识机制，往往也称作为共识算法。

区块链系统是有多个节点组成，任意安装了相应区块链系统所需软硬件，加入到区块链网络里的计算机，就可以称为一个“节点”。如果节点间通信十分顺畅，各个节点都能瞬间响应，那么只需要简单广播投票和应答就可以解决一致性问题。然后现实并不是这样。节点往往会遇到网络中断、节点故障、恶意节点（被入侵后篡改，或者原本就是恶意节点）。节点遇到的问题可以进行如下的分类：

• 节点出现故障但不会伪造信息的情况称为“非拜占庭错误”；
• 节点会伪造信息恶意响应的情况称为“拜占庭错误”，伪造信息的节点称为拜占庭节点（恶意节点）。

相对应的，共识算法也可以分为 CFT 和 BFT 两类：

• CFT（Crash Fault Tolerance）：

  • 只容忍节点故障，不容忍“恶意”作恶；
  • 常见的比如：Paxos，Raft 等等；

• BFT（Byzantine Fault Tolerance）：

  • 可以容忍节点故障与“恶意”节点；
  • 常见的比如：POW，POS（DPoS），POA，PBFT（dBFT，RPBFT）等等；

恶意节点是指在一个节点发送错误或者被篡改过的数据。可能是由于被外部入侵后修改，也可能原本就是某些攻击者估计接入的篡改了区块链系统软件的节点。

5.1. CFT 算法

Paxos 算法和 Raft 算法是常见于分布式服务器集群中的共识算法，主要目的是解决分布式系统中存在故障（fault），但不存在恶意（corrupt）节点场景（即可能消息丢失或重复，但无错误消息）下的共识达成（Consensus）问题。

Paxos 算法出现的比较早，在后来一系列的 Paxos 算法变种形成了丰富的 Paxos 算法族。Raft 算法与 Paxos 算法有很大的关联，可以认为 Raft 就是在 Paxos 算法基础上改进而来。

5.2. Paxos && Raft

• Paxos

  • 1990 年由 Leslie Lamport 提出的 Paxos 共识算法，在工程角度实现了一种最大化保障分布式系统一致性（存在极小的概率无法实现一致）的机制。Paxos 被广泛应用在 Chubby、ZooKeeper 系统中。
  • 早期的 Basic Paxos 的协议复杂，且相对效率较低，所以在后来提示了很多对几点 Paxos 改进的版本，比如：Fast Paxos，Multi-Paxos 以及 Byzanetine Paxos 等等。

• Raft

  • Raft（Replication and Fault Tolerant）算法是 Paxos 算法的一种简化实现。它保证了在一个由 N 个节点构成的系统中有 (N+1)/2（向上取整）个节点正常工作的情况下的系统的一致性。比如在一个 5 个节点的系统中允许 2 个节点出现非拜占庭错误，如节点宕机、网络分区、消息延时。

  • Raft相比于Paxos更容易理解，且被证明可以提供与 Paxos 相同的容错性以及性能，其详细介绍可见官网及动态演示。

• Paxos 和 Raft 比较

  • Paxos 相对 Raft，理解和实现都更难；
  • Raft 的流程和描述更清晰，更容易理解和实现；
  • Raft 能容忍 不大于 (N-1)/2 个故障节点；
  • Paxos 根据不同的实现，最大容忍错误不一致，Fast-Paxos 为 （N-1)/3, Basic-Paxos 和 Multi-Paxos 为 (N-1)/2；
  • Paxos 和 Raft 算法不能解决拜占庭问题；
  • Raft 的建议性更适合作为区块链共识算法（仅仅作用域联盟链等可信网络的区块链系统）

参考文档：

• Raft 算法
• Paxos 算法
• 分布式一致性算法对比 - Raft VS Paxos

5.3. BFT 算法

BFT 类算法，最主要的特点是，可以解决拜占庭问题，可以容忍在去中心化的分布式系统中存在部分恶意节点。

5.4. POW

POW（Proof Of Work）：即工作量证明，简单说就是干的越多，收的越多。

依赖机器进行数学运算（通过 HASH 运算来寻找一个特征值）来获取记账权，资源消耗相比其他共识机制高、可监管性弱。同时每次达成共识需要全网共同参与运算，性能效率比较低，容错性方面允许全网 50% 节点出错。

• 优点：

  • 算法简单，容易实现；
  • 节点间无需交换额外的信息即可达成共识；
  • 破坏系统需要投入极大的成本；

• 缺点：

  • 浪费能源；
  • 区块的确认时间难以缩短；
  • 新的区块链必须找到一种不同的散列算法，否则就会面临比特币的算力攻击；
  • 容易产生分叉，需要等待多个确认；
  • 永远没有最终性，需要检查点机制来弥补最终性；

• **使用者：**Bitcoin、Ethereum、Litecoin、Dogecoin 等。

5.5. POS

POS（Proof of Stake）：即权益证明，也作股权证明，简单点说就是持有越多，获得越多。

POS 是 POW 的一种升级共识机制，根据每个节点所占代币的比例和时间，获得股份比例，拥有代币股份越多的人越容易获取记账权，等比例的降低挖矿难度，从而加快找随机数的速度。

• 优点：

  • 节能，不需要无用计算；
  • 在一定程度上缩短了共识达成的时间；

• 缺点：

  • 安全性还需要更进一步的检验；
  • 币如何产生和分配机制设计难度较高；

• 使用者：

  • Ethereum（即将推出）、Peercoin、Nxt。

5.6. DPoS

DPoS（Delegated Proof of Stake）：即股份授权证明机制或者受托人机制。DPOS与POS原理相同，只是选了一些“人大代表”。

从某种角度来看，DPoS 有点像民主大会，持币人选出几个代表节点来运营网络，用专业运行的网络服务器来保证区块链网络的安全和性能。DPOS机制中，不需要算力解决数学难题，而是由持币者选出谁说生产者，如果生产者不称职，就有随时有可能被投票出局，这也就解决了POS的性能问题。

为了方便理解，可以再举个例子。想象有这样一家公司：公司员工总数有 1000 人，每个人都持有数额不等的公司股份。每隔一段时间，员工可以把手里的票投向自己最认可的 10 个人来领导公司，其中每个员工的票权和他手里持有的股份数成正比。等所有人投完票以后，得票率最高的10 个人成为公司的领导。

如果有领导能力不胜任或做了不利于公司的事，那员工可以撤销对改领导的投票，让他的得票率无法进入前10名，从而退出管理层。这就是对 DPoS(Delegated Proof of Stake)共识机制的一个形象描述。

• 优点：

  • 能耗低；
  • 大幅缩小参与验证和记账节点的数量，可以达到秒级的共识验证（EOS 的块时间是 0.5 秒）；

• 缺点：

  • 拥有高权益的参与者可投票使自己成为一名验证者（这是近期已在 EOS 中出现的问题）；
  • 投票需要消耗时间，精力，导致投票的积极性并不高。绝大多数持股人（90％+）从未参与投票；
  • 节点代理是人为选出的，公平性相比 PoS 较低；
  • 同时整个共识机制还是依赖于代币的增发来维持代理节点的稳定性，很多商业应用是不需要代币存在的；

• 使用者：

  • BitShares、Steemit、EOS、Lisk、Ark。

5.7. PoA（Proof of Authority，权威证明）

POA（Proof of Authority）：即权威证明。

PoA 机制不挖矿也不需要 Token。在基于此 PoA 的区块链网络中，所有的交易和区块均由验证人（Validator）处理。PoA 平台的维护成本低，但在 PoA 中，交易和验证区块的验证人，必须是能通过可靠性审查的人。所以，PoA 的验证人必然非常关注自身声誉。声誉在 PoA 里就是非常重要的资产。一般情况下，验证人会公开自己的实际身份。目前，这种共识机制形成的区块链技术主要是应用在行业特征明显的联盟链、私有链上。

• 优点：

  • 节能，维护成本相对较低；
  • 出块效率高；
  • 不需要代币；

• 缺点：

  • 略为中心化；
  • 虽然可用于公有区块链，但是更多用于私有区块链，许可区块链，联盟链等；

• 使用者：

  • POA.Network、Ethereum Kovan testnet、VeChain，GE航空（GE Aviation）和沃尔玛（Walmart）的物流链、Giveth、Tomochain、Go-Chain。

5.8. PBFT

PBFT（Practical Byzantine Fault Tolerance）：即实用拜占庭容错。

PBFT 算法中，有一个节点会被当做主节点，而其他节点都是备份节点。系统内的所有节点都会相互通信，最终目标是大家能以少数服从多数的原则达成数据的共识。

每一个共识过程分下面这四步：

1. 客户端发一个请求给主节点去执行某个操作。
2. 主节点广播这个请求到各个备份节点。
3. 所有节点执行操作并把结果返回给客户端。
4. 当客户端收到 f + 1 个来自不同节点的相同的结果后，过程结束。f 代表可能撒谎的节点的最大值。

从第 4 步也可以看出，只要客户端能保证多数人认可了一个相同的结果，这个结果就是最终的共识了。同时，为了保证主节点失效后，系统的活性，会触发视图切换。或者，如果主节点出现明显的撒谎迹象，其他的节点也可以联合起来更换主节点，触发视图切换。

• 优点：

  • 不需要代币；
  • 共识的时延大约在 2~5 秒钟，基本达到商用实时处理的要求；
  • 共识效率高，可满足高频交易量的需求；

• 缺点：

  • 仅仅适用于联盟链，私有链；
  • 网络复杂度过高，可拓展性比较低，一般的系统在达到 100 左右的节点个数时，性能下降非常快；
  • PBFT在网络不稳定的情况下延迟很高；
  • 当有超过 (N-1)/3 个无效或者恶意节点时，系统无法提供服务；

• 使用者：

  • Hyperledger Fabric、Stellar、Ripple、Dispatch、FISCO-BCOS

5.9. PBFT 衍生（dBFT，RPBFT）

dPBFT（Delegated Byzantine Fault Tolerance）：授权拜占庭容错算法。
RPBFT（Rotation Practical Byzantine Fault Tolerance）：轮流拜占庭容错算法。

dPBFT 和 RPBFT 原理跟 PBFT 类似，只是不是所有的节点都参与共识，而是将节点分为两种，共识节点和和验证节点：

• 共识节点
  • 执行 PBFT 共识流程的节点，有轮流出块权限；
• 验证节点
  • 不执行共识流程，验证共识节点是否合法、区块验证，经过若干轮共识后，会切换为共识节点；

共识节点之间通过 PBFT 算法达成共识，转发给验证节点进行验证。dPBFT 和 RPBFT 之间的区别仅仅是选择共识节点的算法不一样：

• dPBFT：根据权益投票选举；

• RPBFT：轮流将共识节点替换为验证节点）

• 优点：

  • 不需要代币；
  • 且由于算法复杂度与节点数无关，所以，性能衰减远小于 PBFT；
  • 网络复杂度与节点规模无关，可扩展性强于 PBFT 共识算法；
  • 共识效率更高，可秒级确认；

• 缺点：

  • 仅仅适用于联盟链，私有链；
  • 当有超过 (N-1)/3 个无效或者恶意节点时，系统无法提供服务；

• 使用者：

  • FISCO-BCOS（RPBFT），Neo（dBFT）

6. 区块链类型x

现在的区块链，主要分为：公有链，私有链，联盟链、许可链。

• 公有链

  • 公有链是开源的，全世界的人都可以参与，完全去中心化；
  • 公有链是匿名的，通过节点之间的共识机制达到信任完成交易，公有链一般会通过代币机制来鼓励参与者竞争记账，来确保数据的安全性；
  • 读写权限是对所有人开放的，任何人都可以接入；
  • 常见的 BTC，ETH，EOS；

• 私有链

  • 仅限在一个企业、组织以及机构内的用户访问和交易，参与节点的资格会被严格限制；
  • 参与节点是有限和可控的，极快的交易速度、更好的隐私保护、更低的交易成本、不容易被恶意攻击；
  • 常见可用于一些金融、审计机构，用以存放账本及数据（不能被篡改）的存放；

• 联盟链

  • 若干个（大于一个）企业、组织以及机构共同参与管理的区块链；
  • 常用语组织机构间的交易和结算，比如银行的对账等等；

• 许可链

  • 参与到区块链系统中的每个节点都是经过许可的，未经许可的节点是不可接入系统中；
  • 私有链和联盟链都属于许可链；
  • 有些许可链没有代币机制，因为不需要代币来鼓励节点竞争记账；

7. 总结

这个世界上，没有任何事物是完美无缺的，对于共识机制而言也是。不同的共识机制都有自己的优缺点，甚至，有些共识机制就是是为解决一些特定的问题而生。

往往在评价一个共识机制时，不能单纯的用好或者坏来定义，要根据业务属性来判断，主要从场景、去中心化程度、记账节点、响应时间、存储效率、吞吐量和容错性等维度进行比较。

• 共识机制的多维度对比：

鱼和熊掌不可兼得，区块链中的安全，性能以及去中心化三个方面，同样不可兼得。

2 月 12 号提出离职，3 月 6 号办的手续。从 2 月中旬就开始面试，找工作。这次找工作，对比 16 年找工作的时候，真的是太失败了，这几年的时间过得。不过有好有坏吧，在欣哥和大佬的帮助下，办了一件大事，这个也算是这几年唯一能让我欣慰的事情了。

自己的不足太明显了，对于大型网站的架构设计，RPC，MQ，数据库 这些技术在针对大流量，高并发上面，实践的太少了。三年，从开始的 Java 麻将服务器到 C++ 的游戏，再到 Go 的代理，PHP 的视频网站。做得事情，是不少，但是真的都是一些小的项目。号称自己是 DEV_OPS，结果对于运维也就是一点皮毛而已。

想想自己，深入的东西几乎太少了，也讲不清楚东西。年初的时候，面试阿里的时候，一个 P8 的面试官提醒我，如果你想达到 P7 的水平。首先要做到的就是总结，用精简的话，能描述出自己做的项目，特点，解决了什么问题，而且这个能力很重要；对于前沿的技术也需要去了解，对技术的了解也要深入；大数据分析，AI，物联网，边缘计算这些都需要自己平时去多了解和跟进。

去年把 V2Ray 编译 IOS framework 的事情搞定了过后，也还没来得及优化，又来了 PHP。忙到年初找工作，博客就这样又拉下了。其实这次还是有想写一些文章:

1. 客户端透明代理的实现原理
2. 比特币入门
3. 区块链开发入门
4. Dockerfile 优化
5. 运维总结
6. 面试总结

一篇篇想写的文章，有的写了一部分，有得还只是杂乱的草稿。这下又要面临试用期，现在先顺顺利利的过试用期。毕竟自己这次是换了一个行业，区块链的行业，菜知道，区块链并不是比特币而已。

写这篇文章也就是刚刚看到一个同事，受了我的刺激，也开始搭起博客来了，想起自己的博客已经很久没有更新了。不过现在看来，微众的节奏还是能接受的，做着开源的项目，限制也没那么多，又摆脱了大小周，至少周末的时间能得到保证。后面还是得好好的把自己的博客撸起来，多写点能深入的东西。

最后，希望疫情早点过去吧。。也用心感恩那些无名的英雄，因为你们，我们才有安全感，感恩！！！

1
2
3
4
5

1 xxxxx
1.1 xxxx
1.1.1 xxxx

2. xxxxx

但是写 MD 的时候，经常改来改去，所以，一旦想在前面插入一个标题什么的，后面都要手动改，太麻烦了。所以就在想，有没有什么简单的办法，能自动的跟据 MD 的标题去生成序号呢？

1. MWeb

CSS 就可以干这个事情:

1
2
3
4
5
6
7
8

body {counter-reset:section}
body h1{counter-reset:sub-section}
body h2{counter-reset:composite}
body h3{counter-reset:detail}
body h1:before{content:counter(section) " ";counter-increment:section}
body h2:before{content:counter(section) "." counter(sub-section) " ";counter-increment:sub-section}
body h3:before{content:counter(section) "." counter(sub-section) "." counter(composite) " ";counter-increment:composite}
body h4:before{content:counter(section) "." counter(sub-section) "." counter(composite) "." counter(detail) " ";counter-increment:detail}

在 MWeb 中的属性，主题中，找到下面的 把这段 css 贴到 Hexo 的 themes/next/source/css/_custom 目录中的 找到 Preview CSS ，找到编辑，copy 一份当前的 css 样式到自定义目录，然后把这段 css 贴到 copy 后台的 css 文件中，然后选择 reload 即可。

2. Hexo

在 Hexo 中，使用了一个 hexo 的插件， Hexo 根目录执行下面的命令

1

npm install hexo-heading-index --save

然后在 Hexo 根目录的 _config.yml 最后加上下面的配置:

1
2
3
4
5
6

5 heading_index:
4   enable: true
3   index_styles: "{1} {1} {1} {1} {1} {1}"
2   connector: "."
1   global_prefix: ""
95    global_suffix: ". "

重新生成即可。

参考:https://www.npmjs.com/package/hexo-heading-index

本文主要对 V2Ray 中 DNS 的解析流程做一个说明。

V2Ray 的 DNS 解析分两种:

1. DNS Outbound 解析
2. Socks5 Proxy 代理解析

1. DNS Outbound 解析

DNS Outbound 解析是指通过 TUN 设备做透明代理，把 DNS 的 UDP 流量全部导入到 V2Ray 中，同时配置一个 rule 去拦截到这个 UDP 的流量。

1
2
3
4
5
6
7
8
9
10
11

  "rules": [{
      "type": "field",
      "outboundTag": "dns-out",
      "inboundTag": [
        "tun2socks"
      ],
      "network": "udp",
      "port": 53
    },
    .........
]

这个时候，V2Ray 第一会调用内置的 DNS 模块去解析 UDP 流量中的域名地址。

通过 dns servers 中的 DNS server IP 同样要经过 rules 的规则路由。比如，如果 DNS server 的 IP 地址是 8.8.8.8，就需要配置相应的 rule，走代理去解析。（V2Ray/VMess 目前是 UDP over TCP）

2. Socks5 Proxy 代理解析

需要开启域名嗅探功能, sniffing 的配置:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

{
  "port": 1086,
  "listen": "0.0.0.0",
  "protocol": "socks",
  "settings": {
    "auth": "noauth",
    "timeout": 0,
    "udp": true
  },
  "sniffing": {
    "enabled": true,
    "destOverride": [
      "http",
      "tls"
    ]
  }
}

包含 两种 ：
1. inbound 接收到 socks5 代理请求
2. TUN 设备通过 tun2Socks 转发到 v2ray-core 的请求

当 inbound 获取到代理请求时，会使用 rules 进行匹配，匹配时有三种情况，对应rules 中的 domainStrategy 的三个配置：

1. AsIs（默认）: 使用core 接收到的地址（可能是域名，也可能是 IP）匹配
2. IPOnDemand : 只要rules里面有匹配 IP 的规则，都先解析一次
3. IPIfNonMatch : 如果根据域名没有匹配到规则，则调用内置 DNS 执行一次解析后，再根据 IP 匹配

如果以上都没有匹配到规则，那么默认使用 outbound 的第一个规则(通常第一个是 Vmess Proxy，有时候也会配置成 freedom )。

2.1. 根据匹配到的 outbound 来判断是否进一步解析

1. 如果根据 域名 匹配到的是 freedom 的 direct outbound，那么会看是否有配置 UseIP(v4,v6),有配置，调用内置的 dns server 去解析（dns server IP 同样要通过 rules 匹配走哪个规则），然后直接连接获取到的 IP 地址。

2. 如果匹配到的是 proxy 的代理规则，则不解析域名，直接将域名发到远程代理服务器，远端执行的 DNS 解析。