1.Docker概述

Docker是一种轻量级的容器化技术，可以将应用和其依赖项封装成一个可移植的容器，这使得在不同的环境中部署和运行应用程序变得更加容易。Docker容器技术的核心思想是隔离和打包装箱，每个容器是互相隔离的。

Docker诞生于2010年，最初是由一家名为dotCloud的公司开发的，该公司提供了一些pass的云计算服务。Docker最初并没有受到行业的关注，直到2013年它成为了开源项目，越来越多的人开始认识到它的优点，Docker也因此变得越来越流行。

与传统的虚拟机技术相比，Docker的优点在于轻量级、资源占用少、启动快速等方面。Docker容器化技术也是一种虚拟化技术，但与虚拟机不同的是，容器内的应用直接运行在宿主机的内核上，没有自己的内核和虚拟硬件，每个容器是互相隔离的，因此可以更快速地部署和运行应用程序。

Docker的作用在于实现DevOps，即开发和运维的快速协作，将应用程序的构建、测试、部署等过程自动化，提高效率和质量，降低成本。Docker提供了一整套的工具和服务，包括Docker引擎、Docker Hub、Docker Compose等，可以方便地管理和维护容器化应用程序。

Docker是基于Golang开发的开源项目

官网地址：https://www.docker.com/

文档地址：https://docs.docker.com/

仓库地址：https://hub.docker.com

2.Docker安装

2.1 Docker的基本组成

Docker是一种轻量级容器技术，它的核心组成部分有镜像、容器和仓库。本文将在下面介绍这三个组成部分的概念和作用。

• 镜像：镜像就像是一个模板，可以通过它来创建容器服务。例如，使用tomcat镜像可以创建一个tomcat01容器，容器中可以运行最终服务或项目。

• 容器：容器则是通过镜像来创建的，利用容器技术独立运行一个或多个应用程序。启动、停止、删除等基本命令可以操作容器。可以把容器理解为一个简易的Linux系统。

• 仓库：仓库是存放镜像的地方，分为公有仓库和私有仓库。DockerHub和阿里云都有容器服务器，可以配置镜像加速。

通过使用Docker，可以方便地创建、部署和管理应用程序，加速开发和部署流程，提高开发效率和应用程序的可移植性。

2.2 搭建Linux环境

本文，笔者使用的是Unbuntu18.04版本的虚拟机，使用XShell连接工具对虚拟机进行操作，配置完成Linux环境后确保Xshell可以正常访问Ubuntu文件。

2.3 安装Docker

1. 首先需要先卸载掉Docker的旧版本文件数据。

   sudo apt-get remove docker docker-engine docker.io containerd runc
   

2. 通过仓库的方式安装。

    sudo apt-get update
   
    sudo apt-get install \
       ca-certificates \
       curl \
       gnupg \
       lsb-release
   

3. 下面添加Docker的官方GPG key。

    curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg
   
    # 国内阿里云版
    curl -fsSL https://mirrors.aliyun.com/docker-ce/linux/ubuntu/gpg | apt-key add -
   

4. 接下来验证key的指纹

   sudo apt-key fingerprint 0EBFCD88
   

   正常的输出为：

   root@camile:/# sudo apt-key fingerprint 0EBFCD88
   pub   rsa4096 2017-02-22 [SCEA]
         9DC8 5822 9FC7 DD38 854A  E2D8 8D81 803C 0EBF CD88
   uid           [ 未知 ] Docker Release (CE deb) <docker@docker.com>
   sub   rsa4096 2017-02-22 [S]
   

5. 下面我们添加稳定版的docker仓库或者国内阿里云版本。

   # 官方版本
   sudo add-apt-repository \
      "deb [arch=amd64] https://download.docker.com/linux/ubuntu \
      $(lsb_release -cs) \
      stable"
   # 国内阿里云版
   sudo add-apt-repository \
      "deb [arch=amd64] https://mirrors.aliyun.com/docker-ce/linux/ubuntu \
      $(lsb_release -cs) \
      stable"
   

6. 安装我们最新版本的docker ce和container。

    sudo apt-get update
    sudo apt-get install docker-ce docker-ce-cli containerd.io
   

7. 查看我们安装的docker版本信息。

   docker --version
   

8. 将非root用户加入docker组，以允许免sudo执行docker.

   sudo gpasswd -a 用户名 docker
   

   重启服务并刷新docker组成员：

   sudo service docker restart
   newgrp - docker
   

   设置开机自启动并启动 Docker-ce（安装成功后默认已设置并启动，可忽略）

   sudo systemctl enable docker
   sudo systemctl start docker
   

9. 接下来我们安装docker-compose https://www.runoob.com/docker/docker-compose.html

   sudo curl -L https://github.com/docker/compose/releases/download/1.25.4/docker-compose-`uname -s`-`uname -m` -o /usr/local/bin/docker-compose
   
   sudo chmod +x /usr/local/bin/docker-compose
   
   sudo ln -s /usr/local/bin/docker-compose /usr/bin/docker-compose
   
   docker-compose --version
   

10. 测试我们的第一个镜像hello-world。

    docker run hello-world
    

1. 卸载docker命令如下所示：

    sudo apt-get purge docker-ce docker-ce-cli containerd.io
    sudo rm -rf /var/lib/docker
    sudo rm -rf /var/lib/containerd
   

2.4 配置阿里云镜像加速器

在阿里云上，提供了一些免费的容器镜像服务，我们找到控制台->左侧菜单->容器镜像服务->镜像加速器，其中Ubuntu配置镜像加速器的命令已给出:

sudo mkdir -p /etc/docker
sudo tee /etc/docker/daemon.json <<-'EOF'
{
  "registry-mirrors": ["https://alvnh3pv.mirror.aliyuncs.com"]
}
EOF
sudo systemctl daemon-reload
sudo systemctl restart docker

2.5 回顾

上面我们运行了一个docker run的命令，笔者绘制了一个流程图供大家参考

那么Docker究竟是怎么工作的呢？这里笔者简单的介绍一下，Dcoker是一个 Client-Server结构的系统，Docker的守护进程运行在主机上，通过Socker从客户端访问。而DockerServer 接收到 Docker-Client 的指令，就会执行这个命令。如下所示

3.Docker常用命令

这一节，笔者总结了一些Docker的常用命令，速览以下有助于后续的使用。对于一些命令，笔者会在虚拟机上试验并给出响应结果。

3.1 帮助命令

docker version        # 版本信息
docker info           # 显示docker的系统信息，包括容器和镜像的信息
docker [命令] --help   # 帮助文档，官网在 doc下的reference 下的 command-line reference

3.2 镜像命令

docker images：查看本机所有的镜像

root@camile:~# docker images
REPOSITORY    TAG       IMAGE ID       CREATED        SIZE
hello-world   latest    feb5d9fea6a5   5 months ago   13.3kB

# 解释
REPOSITORY：镜像的仓库源
TAG：镜像的标签
IMAGE ID：镜像的ID
CREATED：镜像的创建时间
SIZE：镜像的大小

# 可选项
Options:
  -a, --all             # 列出所有镜像 
  -f, --filter          # 过滤镜像
  -q, --quiet           # 只显示镜像的id
  -aq                   # 列出所有镜像id

**docker search：**搜索镜像

root@camile:~# docker search mysql
NAME                             DESCRIPTION                                     STARS     OFFICIAL   AUTOMATED
mysql/mysql-server               Optimized MySQL Server Docker images. Create…   907                  [OK]

# 可选项
Options:
  -f=STARS=3000 --filter=STARS=3000

docker pull：下载镜像

# 下载镜像 docker pull 镜像名[:tag]
root@camile:~# docker pull mysql
Using default tag: latest # 默认是最新版本
latest: Pulling from library/mysql
72a69066d2fe: Pull complete  # 分层下载，docker image 的核心 联合文件系统
93619dbc5b36: Pull complete 
99da31dd6142: Pull complete 
626033c43d70: Pull complete 
37d5d7efb64e: Pull complete 
ac563158d721: Pull complete 
d2ba16033dad: Pull complete 
688ba7d5c01a: Pull complete 
00e060b6d11d: Pull complete 
1c04857f594f: Pull complete 
4d7cfa90e6ea: Pull complete 
e0431212d27d: Pull complete 
Digest: sha256:e9027fe4d91c0153429607251656806cc784e914937271037f7738bd5b8e7709  #签名
Status: Downloaded newer image for mysql:latest
docker.io/library/mysql:latest # 真实地址

# 等价于以下命令
docker pull docker.io/library/mysql:latest

# 指定版本下载
root@camile:~# docker pull mysql:5.7
5.7: Pulling from library/mysql
72a69066d2fe: Already exists 
93619dbc5b36: Already exists 
99da31dd6142: Already exists 
626033c43d70: Already exists 
37d5d7efb64e: Already exists 
ac563158d721: Already exists 
d2ba16033dad: Already exists 
0ceb82207cd7: Pull complete 
37f2405cae96: Pull complete 
e2482e017e53: Pull complete 
70deed891d42: Pull complete 
Digest: sha256:f2ad209efe9c67104167fc609cca6973c8422939491c9345270175a300419f94
Status: Downloaded newer image for mysql:5.7
docker.io/library/mysql:5.7

docker rmi：删除镜像

# 按照id删除镜像
docker rmi -f 容器id # 删除指定的镜像
docker rmi -f 容器id 容器id 容器id # 删除多个镜像
docker rmi -f $(docker images -aq) # 删除全部镜像

3.3 容器命令

有了镜像，我们才可以创建容器，我们下载一个centos镜像来测试学习。

新建容器并启动

docker run [可选参数] image

# 参数说明
--name=“Name”     容器名字 tomcat01 tomcat02 用来区分容器
-d                后台方式运行
-i -t -it         使用交互方式运行，进入容器查看内容
-p                指定容器的端口 -p 8080：8080
-p ip:主机端口：容器端口
-p 主机端口：容器端口（常用）
-p 容器端口
容器端口
-p    随机指定端口

# 测试
root@camile:~# docker run -it centos /bin/bash # 启动容器并进入容器内部
[root@f2e7722031c0 /] # 进入容器内部 root@后面就是容器的id
[root@f2e7722031c0 /]# ls # 查看容器内的centos目录
bin  etc   lib      lost+found  mnt  proc  run   srv  tmp  var
dev  home  lib64  media       opt  root  sbin  sys  usr
[root@f2e7722031c0 /]# exit  # 从容器中退回主机
exit
root@camile:~# 

列出所有运行中的容器

# docker ps 命令
    # 列出当前正在运行的容器
-a    # 列出当前正在进行的容器+带出历史运行的容器
-n=？    # 显示最近几个创建的容器
-q  # 只显示容器的ID
root@camile:~# docker ps -a
CONTAINER ID   IMAGE     COMMAND       CREATED       STATUS                   PORTS     NAMES
f2e7722031c0   centos    "/bin/bash"   4 hours ago   Exited (0) 4 hours ago             amazing_rosalind

退出容器

 exit # 直接容器停止并退出
 CTRL + P + Q # 容器不停止并tui'chu

删除容器

docker rm 容器id                 # 删除指定的容器，不能删除正在运行的容器
docker rm -f $(docker ps -aq)   # 删除所有的容器
docker ps -aq | xargs docker rm # 删除所有的容器

启动和停止容器的操作

docker start 容器 id
docker restart 容器id
docker stop 容器id
docker kill 容器id

3.4 其他命令

后台启动容器

# 命令 docker run -d 镜像名;
root@camile:~# docker run -d centos
# 问题 docker ps 发现，centos 停止了

# 常见的坑， docker 容器使用后台运行，就必须有一个前台进程，docker容器发现没有应用，就会自动停止
# 容器启动后，发现自己没有提供服务，就会立刻停止，就是没有程序了

查看日志

docker logs -f -t --tail 容器，没有日志

# 自己编写一段shell脚本
docker run -d centos /bin/bash -c "while true;do echo qiaowei;sleep 1;done"

# 显示日志
root@camile:~# docker logs -tf --tail 10 397eabe2c023
2022-02-26T09:21:25.266776907Z qiaowei
2022-02-26T09:21:26.268727710Z qiaowei
2022-02-26T09:21:27.270738576Z qiaowei

-tf # 显示日志
--tail  # 显示日志条数

查看容器中的进程信息

# 命令docker top 容器id
root@camile:~# docker top 19334600a733
UID                 PID                 PPID                C                   STIME               TTY                 TIME                CMD
root                14960               14931               0                   17:27               pts/0               00:00:00            /bin/bash

查看镜像的元数据

# 命令
docker inspect 容器id

进入当前正在运行的容器

# 我们通常容器都是使用后台方式运行的，需要进入容器，修改一些配置

# 命令
docker exec -it 容器id 路径

# 测试
root@camile:~# docker exec -it 19334600a733 /bin/bash
[root@19334600a733 /]# ls
bin  etc   lib      lost+found  mnt  proc  run   srv  tmp  var
dev  home  lib64  media       opt  root  sbin  sys  usr
[root@19334600a733 /]# ps -ef
UID         PID   PPID  C STIME TTY          TIME CMD
root          1      0  0 09:27 pts/0    00:00:00 /bin/bash
root         15      0  0 09:46 pts/1    00:00:00 /bin/bash
root         31     15  0 09:46 pts/1    00:00:00 ps -ef

# 方式二
docker attach 容器id
root@camile:~# docker attach 19334600a733          
[root@19334600a733 /]# ls
bin  etc   lib      lost+found  mnt  proc  run   srv  tmp  var
dev  home  lib64  media       opt  root  sbin  sys  usr

# docker exec     # 进入容器后开启一个新的终端，可以在里面操作（常用）
# docker attach   # 进入容器正在执行的终端，不会启动新的进程

从容器内拷贝文件到主机上

docker cp 容器id：容器内路径 目前的主机路径

# 测试
[root@19334600a733 /]# cd /home
[root@19334600a733 home]# ls
[root@19334600a733 home]# touch test.java
[root@19334600a733 home]# exit
exit
root@camile:~# docker ps 
CONTAINER ID   IMAGE     COMMAND   CREATED   STATUS    PORTS     NAMES
root@camile:~# docker ps -a
CONTAINER ID   IMAGE     COMMAND                  CREATED          STATUS                        PORTS     NAMES
19334600a733   centos    "/bin/bash"              32 minutes ago   Exited (0) 12 seconds ago               admiring_bohr
397eabe2c023   centos    "/bin/bash -c 'while…"   39 minutes ago   Exited (137) 37 minutes ago             focused_ellis
cd940d7abbb2   centos    "/bin/bash -C 'while…"   40 minutes ago   Exited (127) 40 minutes ago             ecstatic_galileo
23db6f7950f8   centos    "/bin/bash -C 'while…"   40 minutes ago   Exited (127) 40 minutes ago             keen_sanderson
8f9ce6c66f30   centos    "/bin/bash"              43 minutes ago   Exited (0) 40 minutes ago               flamboyant_moser
root@camile:~# docker cp 19334600a733:/home/test.java /home
root@camile:~# cd home
-bash: cd: home: No such file or directory
root@camile:~# cd /home
root@camile:/home# ls
camile  test.java

# 拷贝是一个手动过程，未来我们使用 -v 卷的技术，可以实现

4.Docker部署简单环境

接下来，笔者将带领大家安装Nginx和Tomcat这两个常见的镜像。

4.1 安装Nginx

# 1.搜索镜像 search 建议大家去docker搜索，可以看到帮助文档

# 2.下载nginx镜像
docker pull nginx

# 3.运行测试
root@camile:/# docker images
REPOSITORY   TAG       IMAGE ID       CREATED        SIZE
nginx        latest    605c77e624dd   8 weeks ago    141MB
centos       latest    5d0da3dc9764   5 months ago   231MB

# -d 后台运行
# --name 给容器命名
# -p 宿主机端口：容器内端口
root@camile:/# docker run -d --name nginx01 -p 3344:80 nginx
586cda0f86a49f103522efcf0300a8592639ae2da23c8317745a487d8373a555
root@camile:/# docker ps
CONTAINER ID   IMAGE     COMMAND                  CREATED         STATUS         PORTS                                   NAMES
586cda0f86a4   nginx     "/docker-entrypoint.…"   4 seconds ago   Up 4 seconds   0.0.0.0:3344->80/tcp, :::3344->80/tcp   nginx01
root@camile:/# curl localhost:3344
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
html { color-scheme: light dark; }
body { width: 35em; margin: 0 auto;
font-family: Tahoma, Verdana, Arial, sans-serif; }
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>

<p>For online documentation and support please refer to
<a href="http://nginx.org/">nginx.org</a>.<br/>
Commercial support is available at
<a href="http://nginx.com/">nginx.com</a>.</p>

<p><em>Thank you for using nginx.</em></p>
</body>
</html>

4.2 部署Tomcat

# 官方的使用
docker run -it --rm tomcat:9.0

# 我们之前的启动都是后台，停止了容器之后，容器还是可以查到，官方的方法一般是用完及删

# 我们的逻辑是先下载再启动
docker pull tomcat:9.0

# 启动运行
root@camile:/# docker run -d -p 3355:8080 --name tomcat01 tomcat

# 发现问腿：1.Linux命令少了 2.没有webapps，阿里云镜像的原因，默认是最小的镜像，所有不必要的都删除吊
# 保证最小的运行环境

4.3 部署ES+kibana

# es 暴露的端口很多！
# es 十分的耗内存
# es 的数据一般需要放置在安全目录！挂载
# --net somenetwork ? 网络配置

# 启动 elasticsearch
docker run -d --name elasticsearch --net somenetwork -p 9200:9200  -e "discovery.type=single-node" elasticsearch:7.6.2

# 启动了 linux就卡住了 docker stats 查看 cpu状态

# es 是十分耗内存的  1核2G

# 查看 docker stats

# 测试以下 es 是否成功了

# 赶紧关闭，增加内存的限制 -e环境配置修改
docker run -d --name elasticsearch --net somenetwork -p 9200:9200 -p 9300:9300 -e "discovery.type=single-node" elasticsearch:tag
docker run -d --name elasticsearch --net somenetwork -p 9200:9200  -e ES_JAVA_OPTS="-Xms64m -Xmx12m" elasticsearch:7.6.2

4.4 Docker可视化工具

这里我们可以使用一个portainer，它是一个Docker的图形化界面管理工具，提供一个后台面板供我们操作，登陆进入可以管理我们的容器。

docker run -d -p 8088:9000 --restart=always -v /var/run/docker.sock:/var/run/docker.sock --privileged=true   portainer/portaioner

在虚拟机中可以使用：localhost:8080来访问界面

5.Docker镜像理解

5.1 镜像是什么

镜像是一种轻量级、可执行的独立软件包，用来打包软件运行环境和基于运行环境开发的软件，它包含运行某个软件所需的所有内容，包括代码、运行时、库、环境变量和配置文件。

如何获得镜像：

• 从远程仓库下载

• 朋友拷贝

• 自己制作一个镜像DockerFile

5.2 镜像加载原理

UnionFS(联合文件系统)

我们下载的时候看到的一层一层的数据就是这个。

UnionFS（联合文件系统）：Union文件系统是一种分层、轻量级并且高性能的文件系统，它支持对文件系统的修改作为一次提交来一层层地叠加，同时可以将不同目录挂载到同一个虚拟文件系统下。Union文件系统是Docker镜像的基础。镜像可以通过分层来进行继承，基于基础镜像（没有父镜像），可以制作各种具体的应用镜像。

特性：一次同时加载多个文件系统，但从外表看起来，只能看到一个文件系统，联合加载会把各层文件系统叠加起来，这样最终的文件系统会包含所有的底层的文件和目录。

Docker镜像加载原理

docker的镜像实际上由一层一层的文件系统组成，这种层级的文件系统UnionFS。

bootfs(boot file system)主要包含bootloader和kernel, bootloader主要是引导加载kernel,Linux刚启动时会加载bootfs文件系统，在Docker镜像的最底层是bootfs。这一层与我们典型的Linux/Unix系统是一样的，包含boot加载器和内核。当boot加载完成之后整个内核就都在内存中了，此时内存的使用权已由bootfs转交给内核，此时系统也会卸载bootfs。

rootfs (root file system)，在bootfs之上。包含的就是典型Linux系统中的/dev,/proc, /bin, /etc等标准目录和文件。各种不同的操作系统发行版，比如Ubuntu , Centos等等

平时我们安装虚拟机的CentOS都是好几个G，为什么Docker这里才200M？

对于一个精简的OS，rootfs可以很小，只需要包含最基本的命令、工具和程序库就可以了，因为底层直接用Host的kernel，自己只需要提供rootfs就可以了。因此可见对于不同的linux发行版，bootfs基本是一致的，rootfs会有差别，因此不同的发行版可以公用bootfs。

5.3 分层理解

分层的镜像

我们可以去下载一个镜像，注意观察下载的日志输出，可以看到是一层一层地在下载。

思考：为什么Docker镜像要采用这种分层结构？

最大的好处，我觉得莫过于是资源共享了!比如有多个镜像都从相同的Base镜像构建而来，那么宿主机只需在磁盘上保留一份base镜像，同时内存中也只需要加载一份base镜像，这样就可以为所有的容器服务了，而且镜像的每一层都可以被共享。

查看镜像分层的方式可以通过docker image inspect命令!

[root@iZwz99sm8v95sckz8bd2c4Z ~]# docker image inspect nginx:latest
[
    {
        "Id": "sha256:ae2feff98a0cc5095d97c6c283dcd33090770c76d63877caa99aefbbe4343bdd",
        "RepoTags": [
            "nginx:latest"
        ],
        "RepoDigests": [
            "nginx@sha256:4cf620a5c81390ee209398ecc18e5fb9dd0f5155cd82adcbae532fec94006fb9"
        ],
        "Parent": "",
        "Comment": "",
        "Created": "2020-12-15T20:21:00.007674532Z",
        "Container": "4cc5da85f27ca0d200407f0593422676a3bab482227daee044d797d1798c96c9",
        "ContainerConfig": {
            "Hostname": "4cc5da85f27c",
            "Domainname": "",
            "User": "",
            "AttachStdin": false,
            "AttachStdout": false,
            "AttachStderr": false,
            "ExposedPorts": {
                "80/tcp": {}
            },
            "Tty": false,
            "OpenStdin": false,
            "StdinOnce": false,
            "Env": [
                "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin",
                "NGINX_VERSION=1.19.6",
                "NJS_VERSION=0.5.0",
                "PKG_RELEASE=1~buster"
            ],
            "Cmd": [
                "/bin/sh",
                "-c",
                "#(nop) ",
                "CMD [\"nginx\" \"-g\" \"daemon off;\"]"
            ],
            "Image": "sha256:13bffe371b56f4aeed88218ec17d0c6f653a83b49bd3e211fc8cfa2ca5d7a3d3",
            "Volumes": null,
            "WorkingDir": "",
            "Entrypoint": [
                "/docker-entrypoint.sh"
            ],
            "OnBuild": null,
            "Labels": {
                "maintainer": "NGINX Docker Maintainers <docker-maint@nginx.com>"
            },
            "StopSignal": "SIGQUIT"
        },
        "DockerVersion": "19.03.12",
        "Author": "",
        "Config": {
            "Hostname": "",
            "Domainname": "",
            "User": "",
            "AttachStdin": false,
            "AttachStdout": false,
            "AttachStderr": false,
            "ExposedPorts": {
                "80/tcp": {}
            },
            "Tty": false,
            "OpenStdin": false,
            "StdinOnce": false,
            "Env": [
                "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin",
                "NGINX_VERSION=1.19.6",
                "NJS_VERSION=0.5.0",
                "PKG_RELEASE=1~buster"
            ],
            "Cmd": [
                "nginx",
                "-g",
                "daemon off;"
            ],
            "Image": "sha256:13bffe371b56f4aeed88218ec17d0c6f653a83b49bd3e211fc8cfa2ca5d7a3d3",
            "Volumes": null,
            "WorkingDir": "",
            "Entrypoint": [
                "/docker-entrypoint.sh"
            ],
            "OnBuild": null,
            "Labels": {
                "maintainer": "NGINX Docker Maintainers <docker-maint@nginx.com>"
            },
            "StopSignal": "SIGQUIT"
        },
        "Architecture": "amd64",
        "Os": "linux",
        "Size": 132935043,
        "VirtualSize": 132935043,
        "GraphDriver": {
            "Data": {
                "LowerDir": "/var/lib/docker/overlay2/cb791e78a08db7091bf2ce1d78603f1758f52199e57f1805156fe30e39067aae/diff:/var/lib/docker/overlay2/1e73a72b25af68ee9abf4eb443f778d31226e12e9af428fcc14c7b044c83b258/diff:/var/lib/docker/overlay2/88c9c01762f2af8327db65d0b0d4a64785e87c9c2ab76c62e7d03619db03a985/diff:/var/lib/docker/overlay2/7304ab112ac4a9cb91fc6f74730be28fecbe19f042e92d321aa9181424cc4b2e/diff",
                "MergedDir": "/var/lib/docker/overlay2/48b288740bbb2b07b41ed43a4d17a005c46b08d3357d2960b5ef7db4b2de6618/merged",
                "UpperDir": "/var/lib/docker/overlay2/48b288740bbb2b07b41ed43a4d17a005c46b08d3357d2960b5ef7db4b2de6618/diff",
                "WorkDir": "/var/lib/docker/overlay2/48b288740bbb2b07b41ed43a4d17a005c46b08d3357d2960b5ef7db4b2de6618/work"
            },
            "Name": "overlay2"
        },
        "RootFS": {
            "Type": "layers",
            "Layers": [
                "sha256:87c8a1d8f54f3aa4e05569e8919397b65056aa71cdf48b7f061432c98475eee9",
                "sha256:5c4e5adc71a82a96f02632433de31c998c5a9e2fccdcbaee780ae83158fac4fa",
                "sha256:7d2b207c26790f693ab1942bbe26af8e2b6a14248969e542416155a912fec30d",
                "sha256:2c7498eef94aef8c40d106f3e42f7da62b3eee8fd36012bf7379becc4cd639a2",
                "sha256:4eaf0ea085df254fd5d2beba4e2c11db70a620dfa411a8ad44149e26428caee4"
            ]
        },
        "Metadata": {
            "LastTagTime": "0001-01-01T00:00:00Z"
        }
    }
]

这里指示了分层信息:

"RootFS": {
    "Type": "layers",
    "Layers": [
        "sha256:87c8a1d8f54f3aa4e05569e8919397b65056aa71cdf48b7f061432c98475eee9",
        "sha256:5c4e5adc71a82a96f02632433de31c998c5a9e2fccdcbaee780ae83158fac4fa",
        "sha256:7d2b207c26790f693ab1942bbe26af8e2b6a14248969e542416155a912fec30d",
        "sha256:2c7498eef94aef8c40d106f3e42f7da62b3eee8fd36012bf7379becc4cd639a2",
        "sha256:4eaf0ea085df254fd5d2beba4e2c11db70a620dfa411a8ad44149e26428caee4"
    ]
},

所有的Docker镜像都起始于一个基础镜像层，当进行修改或增加新的内容时，就会在当前镜像层之上，创建新的镜像层。

举一个简单的例子，假如基于Ubuntu Linux 16.04创建一个新的镜像，这就是新镜像的第一层;如果在该镜像中添加Python包，就会在基础镜像层之上创建第二个镜像层;如果继续添加一个安全补丁，就会创建第三个镜像层。

该镜像当前已经包含3个镜像层，如下图所示(这只是一个用于演示的很简单的例子)。

在添加额外的镜像层的同时，镜像始终保持是当前所有镜像的组合，理解这一点非常重要。下图中举了一个简单的例子，每个层包含3个文件，而镜像包含了来自两个镜像层的6个文件。

这种情况下，上层镜像层中的文件覆盖了底层镜像层中的文件。这样就使得文件的更新版本作为一个新镜像层添加到镜像当中。Docker通过存储引擎（新版本采用快照机制)的方式来实现镜像层堆栈，并保证多镜像层对外展示为统一的文件系统。

Linux上可用的存储引擎有AUFS、Overlay2、Device Mapper、Btrfs以及ZFS。顾名思义，每种存储引擎都基于Linux中对应的文件系统或者块设备技术，并且每种存储引擎都有其独有的性能特点。

Docker在Windows 上仅支持windowsfilter一种存储引擎，该引擎基于NTFS文件系统之上实现了分层和CoW[1].下图展示了与系统显示相同的三层镜像。所有镜像层堆叠并合并，对外提供统一的视图。

特点

Docker镜像都是只读地，当容器启动时，一个新的可写层被加载到镜像的顶部！

这一层就是我们通常说的容器层，容器之下的都是镜像层！

5.4 commit镜像

当我们想要保存当前容器的状态，就可以通过commit来提交，获得一个镜像：

docker commit 提交容器成为一个新的副本

docker commit -m="提交的描述信息" -a="作者" 容器id 目标镜像名：[tag]

实战测试

# 启动一个默认的tomcat

# 发现这个默认的 tomcat 没有webapps应用，镜像的原因，官方的镜像默认 webapps 下是没有文件的

# 自己拷贝进去基本的文件

# 将我们操作过的容器通过commit提交为一个镜像！我们以后就可以使用我们修改过的镜像即可，这也就是我们自己的一个修改镜像。

6.Docker容器数据卷

6.1 什么是容器数据卷

容器数据卷是Docker中一种用于持久化数据的技术，它可以让容器中的数据在容器删除后不会丢失。Docker的理念是将应用和环境打包成一个镜像，但如果数据都在容器中，那么容器删除后数据也会消失。因此，需要使用数据卷技术实现数据持久化和同步操作。

例如，在使用MySQL时，如果容器删除，则数据库中的数据也会丢失，因此需要将MySQL数据存储在本地并使用卷技术实现容器和本地数据的同步。卷技术通过目录挂载实现，将容器内的目录挂载到Linux系统上。因此，容器间也可以共享数据，实现数据共享。容器数据卷是Docker中非常重要的一部分，可以实现容器的持久化和同步操作，为容器应用提供了强大的数据管理功能。

6.2 使用数据卷

方式一：直接使用命令来挂载 -v

 docker run -it -v 主机目录:容器目录

 # 测试
 docker run -it -v /home/ceshi:/home centos /bin/bash

 # 容器起来时候我们可以通过 docker inspect 容器id 来查看挂载状态

在容器内简历一个test.java测试文件。测试文件的同步，是一个双向绑定的过程。

6.3 实战：安装MySQL

# 获取镜像
camile@camile:/$ docker pull mysql:5.7

# 运行容器，需要做数据卷挂载 # 安装启动mysql -e表示配置环境
# 官方测试：docker run --name some-mysql -e MYSQL_ROOT_PASSWORD=my-secret-pw -d mysql:tag

# 启动我们的mysql
-d 后台运行
-p 端口映射
-v 卷挂载
-n 容器名字
camile@camile:~$ docker run -d -p 3310:3306 -v /home/mysql/conf:/etc/mysql/conf.d -v /home/mysql/data:/var/lib/mysql -e MYSQL_ROOT_PASSWORD=zuiweizhiming666 --name mysql01 mysql:5.7

# 启动成功之后，我们在本地使用 navicat 来测试以下
# navicat 连接到服务器的3310 -3310和容器内的3306映射，这个时候我们就可以连接上了

# 在本地测试创建一个数据库，查看一下我们创建的路径是否ok

6.4 具名和匿名挂载

Docker中的匿名挂载和具名挂载是两种不同的数据卷挂载方式。

匿名挂载是指在启动容器时，只指定容器内的路径，而不指定宿主机的目录。这样会生成一个随机的宿主机挂载目录，可以通过 docker volume ls 命令查看。

具名挂载是指在启动容器时，既指定容器内的路径，又指定一个卷名作为宿主机的目录。 这样可以方便地找到和管理数据卷，也可以通过 docker volume inspect 卷名 命令查看详细信息。

匿名挂载和具名挂载的语法如下：

• -v 容器内路径 # 匿名挂载

• -v 卷名:容器内路径 # 具名挂载

下面是具名挂载和匿名挂载的相关命令代码块：

# 启动一个nginx容器，使用匿名挂载，将容器内的/etc/nginx目录挂载到宿主机上
docker run -d -P --name nginx01 -v /etc/nginx nginx

# 查看所有的数据卷
docker volume ls

# 启动一个nginx容器，使用具名挂载，将容器内的/etc/nginx目录挂载到宿主机上，并命名为juming-nginx
docker run -d -P --name nginx02 -v juming-nginx:/etc/nginx nginx

# 查看具体的数据卷信息
docker volume inspect juming-nginx

6.5 DockerFile

DockerFile 就是用来构建Docker镜像的构建文件、命令脚本，下面先体验一下！

通过这个脚本可以生成镜像，镜像是一层一层的，脚本是一个个的命令。

# 创建一个DockerFile文件，名字可以随机 ，建议 Dockerfile

# 文件中的内容
FROM centos

VOLUME ["volume01","volume02"]

CMD echo "---end---"
CMD /bin/bash

# 这里的每个命令，就是镜像的一层

# 启动自己写的容器

这个目录就是我们生成镜像的时候自动挂载的数据卷目录。这个卷和外部一定有一个同步的目录。

查看一下卷挂载的路径。

测试一下刚才的文件是否同步了。

这种方式我们未来使用的十分多，因为我们通常会构建自己的镜像！假设构建镜像的时候没有挂载卷，要手动镜像挂载 -v 卷名:容器内路径。

7.DockerFile

7.1 DockerFile

dockerFile 是用来docker镜像的文件，是命令参数脚本。

构建步骤：编写一个dockerfile文件

1. docker build 构建成一个镜像

2. docker run 运行镜像

3. docker push 发布镜像

7.2 dockerFile构建过程

基础知识：

1. 每个保留关键字都是大写字母

2. 执行从上到下执行

3. #表示注释

4. 每一个指令都会创建提交一个新的镜像层，并提交！

dockerfile是面向开发的，我们以后要发布项目，做镜像，就需要编写dockerfile文件，这个文件十分简单。

Docker镜像逐渐成为企业交付的标准，必须要掌握。

步骤：

DockerFile：构建文件，定义了一切的步骤，源代码

DockerImages：DockerFile构建生成的镜像，最终发布和运行的产品，原来是 jar war。

Docker容器：容器就是镜像运行起来提供服务的。

7.3 DockerFile指令

知晓了DockerFile命令，我们就可以自己制作镜像：

FROM          # 基础镜像，一切从这里开始构建
MANITAINER    # 镜像是谁写的 姓名+邮箱
RUN           # 镜像构建的时候需要运行的命令
ADD           # 步骤，tomcat镜像，这个tomcat压缩包！添加内容
WORKDIR       # 镜像的工作目录
VOLUME        # 挂载的目录
EXPOSE        # 指定暴露端口
CMD           # 指定这个容器启动的时候要运行的命令，只有最后一个会生效，可被替代
ENTRYPOINT    # 指定这个容器启动的时候要运行的命令，可以追加命令
ONBUILD       # 当个构建一个被继承dockerfile 的时候，会运行这个指令，触发指令
COPY          # 类似ADD，将我们文件拷贝到镜像中
ENV           # 构建的时候设置环境变量

7.4 实战测试

Docker Hub 中绝大多数镜像都是从这个基础镜像过来的 FROM scratch，然后配置需要的软件和配置来进行的构建。

创建一个自己的Centos

# 1.编写DockerFile的文件
FROM centos:7

MAINTAINER qiaowei<454921269@qq.com>

ENV MYPATH /usr/local

WORKDIR $MYPATH

RUN yum -y install vim
RUN yum -y install net-tools

EXPOSE 80

CMD echo $MYPATH
CMD echo "---end---"
CMD /bin/bash

# 2.通过这个文件构建镜像
# 命令 docker build -f dockerfile文件路径 -t 镜像名:[tag]
Successfully built 11a9535c2896
Successfully tagged mycentos:0.1

# 3.测试运行
root@camile:/home/dockerfile# docker run -it 11a9535c2896
[root@f9c5dbcee829 local]# pwd
/usr/local
[root@f9c5dbcee829 local]# ifconfig
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 172.17.0.6  netmask 255.255.0.0  broadcast 172.17.255.255
        ether 02:42:ac:11:00:06  txqueuelen 0  (Ethernet)
        RX packets 23  bytes 2804 (2.7 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

[root@f9c5dbcee829 local]# vim test

自己写的centos 添加了vim 和 net-tools ，测试成功！

我们可以列出本地镜像的变更历史

root@camile:/home/dockerfile# docker history 11a9535c2896
IMAGE          CREATED         CREATED BY                                      SIZE      COMMENT
11a9535c2896   4 minutes ago   /bin/sh -c #(nop)  CMD ["/bin/sh" "-c" "/bin…   0B        
5005cf751c81   4 minutes ago   /bin/sh -c #(nop)  CMD ["/bin/sh" "-c" "echo…   0B        
21407997234d   4 minutes ago   /bin/sh -c #(nop)  CMD ["/bin/sh" "-c" "echo…   0B        
a567cd94200e   4 minutes ago   /bin/sh -c #(nop)  EXPOSE 80                    0B        
48ad5b128e9a   4 minutes ago   /bin/sh -c yum -y install net-tools             161MB     
da7d8a18d88e   4 minutes ago   /bin/sh -c yum -y install vim                   216MB     
b1524097a173   4 minutes ago   /bin/sh -c #(nop) WORKDIR /usr/local            0B        
01282534605d   4 minutes ago   /bin/sh -c #(nop)  ENV MYPATH=/usr/local        0B        
9bb0de5c2898   4 minutes ago   /bin/sh -c #(nop)  MAINTAINER qiaowei<454921…   0B        
eeb6ee3f44bd   5 months ago    /bin/sh -c #(nop)  CMD ["/bin/bash"]            0B        
<missing>      5 months ago    /bin/sh -c #(nop)  LABEL org.label-schema.sc…   0B

7.5 tomcat镜像

1. 准备镜像文件 tomcat 压缩包，jdk的压缩包。

1. 编写dockerfile文件，官方命名“Dockerfile”，build会自动寻找这个文件，就不需要 -f 指定了。

   root@camile:/home/qiaowei/build/tomcat# touch readme.txt
   root@camile:/home/qiaowei/build/tomcat# vim Dockerfile
   

   # 自己制作Dockerfile
   FROM centos:7
   MAINTAINER qiaowei<454921269@qq.com>
   
   COPY readme.txt /usr/local/readme.txt
   
   ADD jdk-17_linux-x64_bin.tar.gz /usr/local/
   ADD apache-tomcat-9.0.59.tar.gz /usr/local/
   
   RUN yum -y install vim
   
   ENV MYPATH /usr/local
   WORKDIR $MYPATH
   
   ENV JAVA_HOME /usr/local/jdk-17.0.2
   ENV CLASSPATH $JAVA_HOME/lib/dt.jar:$JAVA_HOME/lib/tools.jar
   ENV CATALINA_HOME /usr/local/apache-tomcat-9.0.59
   ENV CATALINA_BASH /usr/local/apache-tomcat-9.0.59
   ENV PATH $PATH:$JAVA_HOME/bin:$CATALINA_HOME/lib:$CATALINA_HOME/bin
   
   EXPOSE 8080
   
   CMD /usr/local/apache-tomcat-9.0.59/bin/startup.sh && tail -F /usr/local/apache-tomcat-9.0.59/bin.logs/catalina.out
   

2. 构建镜像

   # docker build -t diytomcat .
   

1.

2. 运行容器：

   docker run -d -p 9090:8080 --name qiaoweitomcat -v /home/qiaowei/build/tomcat/test:/usr/local/apache-tomcat-9.0.59/webapps/test -v /home/qiaowei/build/tomcat/tomcatlogs/:/usr/local/apache-tomcat-9.0.59/logs diytomcat
   

3. 访问测试

1. 发布项目（由于做了卷挂载，我们直接在本地编写项目就可以）

   <?xml version="1.0" encoding="UTF-8"?>
   <web-app xmlns="http://java.sun.com/xml/ns/javaee"
              xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
              xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
             http://java.sun.com/xml/ns/javaee/web-app_4_0.xsd"
              version="4.0">
   </web-app>
   

2. 随便写一个html文件，测试访问

   <!DOCTYPE html>
   <html>
       <head>
            <meta charset="UTF-8"/>
           <title>这是个标题</title>
       </head>
       <body>
           <h1>这是一个一个简单的HTML</h1>
           <p>Hello World！</p>
       </body>
   </html>
   

7.6 发布自己的镜像

Dockerhub

1. 地址：https://hub.docker.com/，注册自己的账号

2. 确定这个账号可以登录

3. 在我们服务器上提交自己的镜像

   Usage:  docker login [OPTIONS] [SERVER]
   
   Log in to a Docker registry.
   If no server is specified, the default is defined by the daemon.
   
   Options:
     -p, --password string   Password
         --password-stdin    Take the password from stdin
     -u, --username string   Username
   

4. 登录完毕后可以提交镜像了

   # 先给镜像打一个标签
   docker tag 1ba62e6aa598 wulegekong/tomcat:1.0
   
   # 提交镜像
   docker push wulegekong/tomcat:1.0
   
   # 注意：镜像名前一定是自己dockerhub的用户名，否则会拒绝push请求
   

7.7 发布镜像到阿里云容器服务

• 登录阿里云

• 找到容器镜像服务

• 创建命名空间

• 根据官方提供的操作指南操作即可。

8.Docker网络

我们使用 ip addr 命令查看本机的所有网络信息：

这里出现了docker0地址，下面简单理解一下docker网络的原理：

1. 我们每安装一个docker容器，docker就会给docker容器分配一个ip，只要电脑安装了docker，就会有一个网卡docker0桥接模式，使用的是evth-pair技术。

2. 再次测试ip addr

3. 再启动一个容器测试，发现又多了一对网卡

# 我们发现这个容器带来网卡，都是一对一对的 
# evth-pair 就是一对的虚拟设备接口，它们是成对出现的，一端连着协议，一段彼此相连。 
# 正因为有这个特性，evth-pair充当一个桥梁，连接各种虚拟网络设备 
# openstac,Docker容器之间的连接 ovs的连接都是使用evth-pair技术

1. 我们来测试tomcat01和tomcat02这两个之前创建的容器是否可以相互ping通，能够ping通！

结论：tomcat01和tomcat02是公用的一个路由器，docker0.

所有的容器不指定网络的情况下，都是docker0路由的，docker会给我们的容器分配一个默认的可用IP。

小结

Docker使用的是Linux的桥接，宿主机中是一个Docker容器的网桥 docker0。

Docker中的所有的网络接口都是虚拟的，虚拟的转发效率高，只要容器删除，对应网桥一对就没了。

9.总结

笔者仅仅简单地学习和应用了Docker的一些基本内容，勉强算是入门，后续会学习Docker-Compose等进阶内容，敬请期待。

作者：Samehada

时间：2023/03/18

文章: 《IPFS - Content Addressed, Versioned, P2P File System》

版权声明：文章采用 BY-NC-SA 许可协议，转载请注明出处！

前言

今天，我们要阅读的是一篇白皮书。这是一个非常有名的去中心化项目—IPFS 星际文件系统，该白皮书于2014年7月发布，此时IPFS项目还没有上线，其中许多内容都尚且是技术构想阶段。虽然目前最新的IPFS技术规范有一些更新，但总体设计和白皮书的内容是基本一致的。

这里简单介绍一下白皮书作者Juan Bennet，他毕业于斯坦福大学的计算机科学专业。低调的胡安并不像中本聪，V神那样被世人所熟知，但他所创建的IPFS在这几年确实风头很劲，很多人知道IPFS，但是对胡安一无所知，这也很正常，主要因为IPFS或者说IPFS所成就的分布式存储可能成为区块链未来发展的重要支撑。

2014年5月胡安就自己成立了公司，起名协议实验室，并且在当年夏天得到了YC的资助，这个YC就是全球著名的创业孵化器，投资了非常非常多优秀的早期创业项目。现在在中国YC掌舵的正是百度前COO陆奇。在胡安拿到投资之后，开始对IPFS、LIBP2P以及其他项目的进行开发。

0️⃣摘要

首先，Juan对IPFS进行了定义——一个点对点的分布式文件系统，旨在用同一个文件系统连接所有的计算设备。

随后，Juan称，在某些方面，IPFS对标于WEB互联网，但更像是单一的BitTorrent集群，使用Git作文件存储和数据交换。换句话说，IPFS使用基于内容寻址的超链接，提供了一个高吞吐量的、基于内容寻址的块存储模型。这种模型构成了一个广义的Merkle DAG（Directed Acyclic Graph，有向无环图）数据结构，可用来构建版本控制文件系统、区块链甚至永恒的互联网体系。IPFS整合了三大技术，分布式哈希表、带有奖励机制的块交换协议和自认证的命名系统。IPFS还解决了单点故障问题，可在节点无需相互信任的情况下正常运行。

1️⃣概述

第一段，Juan说已经有很多人尝试构建全球化的分布式文件系统，并列举了学术界和商业界的一些案例。在学术届，AFS获得了比较广泛的成功并至今仍在使用，而能获得如此成功的其他产品则寥寥无几。在商业界，分布式文件系统主要应用于点对点文件共享，尤其是音视频的共享。并列举了Napster、KaZaA和BitTorrent这些分布式文件应用

这些分布式文件应用承载了上亿的用户规模，至今，BitTorrent仍保持着上千万的活跃节点。     但是Juan认为这些商业系统虽然用户量很大，但是都在应用层。这些软件没有专注于底层协议框架以便于基于基础设施进行开发，没能实现全球开发者共享这些商业系统的分布式和低延迟的优势。

HTTP协议，作为互联网传输文件的公认标准，在大多数场景下已经足够成功。和浏览器伴生，HTTP协议已经积攒了很强的技术和社会声望。但是HTTP协议实在是太老了，并没能利用好近十几年出现的优秀的新文件分发技术。这些新技术与HTTP协议难以兼容，并且许多相关方都在现有的HTTP模型上有很多投资，所以WEB网络的发展陷入了停滞。但是从另一个角度，HTTP协议之后许多优秀的新协议出现并得到了广泛使用，这是令人兴奋的。目前所需要升级的是：在不降低用户体验的情况下引入新的文件分发技术，从而加强如今的HTTP的网络。

第二段，Juan谈到HTTP的成功在于处理小文件的表现很好，但是目前新网络时代的数据分发有以下5点挑战：

1. 托管和分发数据量达到PB（1PB = 1024TB）级别

2. 跨组织大数据运算

3. 分发海量的高清晰度媒体流

4. 海量数据的连接与版本控制

5. 防止重要文件丢失

Juan总结说，新时代的数据量激增，“海量数据，无处不在”，这时候Juan团队不再对HTTP协议抱有幻想了，转而努力开发新的数据分发协议。

Many of these can be boiled down to “lots of data, accessible everywhere.”

第三段，Juan说分布式系统要解决的两大问题就是数据同步和版本控制，而Git则是一套非常实用的源码版本控制系统。现在完全可以讲Git技术作为启发，尤其是将它基于内容寻址的Merkle DAG数据模型应用到分布式文件系统中。当然，还需解决高吞吐量和升级WEB网络的问题。

白皮书提出了IPFS：一种点对点的、基于版本控制的文件系统可以解决前面的问题。IPFS的核心原则就是将所有数据作为同一Merkle DAG的一部分来建模。

The central IPFS principle is modeling all data as part of the same Merkle DAG.

2️⃣背景

这一章，Juan回顾了IPFS系统所整合的一系列技术，这些技术对构建一个优秀的点对点系统非常重要。

2.1 分布式哈希表DHT（Distributed Hash Tables）

分布式哈希表，即为分散存储在不同位置的哈希表，而哈希表就是存储文件哈希值和文件地址的表结构，一般是结构。DHT在点对点系统中广泛用于存储和同步元数据。下面，Juan介绍了三种DHT应用，分别是 Kademlia，Coral DSHT 和 S/Kademlia。 KAD Kademlia是非常流行的一种DHT算法（简称KAD），在eMule，BitTorrent，Guntella这些软件中都有使用。KAD算法的优点是查询高效(log(n))，同步开销低，抗攻击性强，应用广泛。 Coral DSHT，是对KAD的改进。在KAD协议中，使用XOR距离，信息永远存储在XOR距离最近的节点中，但是这些节点可能并不需要这些数据，这样会浪费存储和带宽资源。所以Coral将地址存储在可以提供数据的节点上，放宽了get_value(key)函数，改成了get_any_values(key)，将DSHT根据位置和大小分成不同的cluster，优先查询低延时的节点。 S/KAD算法扩展了KAD来防止恶意的攻击。首先，它通过一些机制生成NodeId防止女巫攻击。第二，S/KAD算法的节点在不相交的路径上查找值，即使网络中存在一般不诚实节点也能达到85%的成功率。 2.2 块交换技术 BigTorrent是一个广泛应用的P2P文件共享系统，它的一些特性给IPFS带来了3点启发： BitTorrent的数据交换协议使用了一种针锋相对的激励策略，奖励多做贡献的节点，惩罚只会索取资源的节点。 BitTorrent追踪文件片段的有效性，优先传输稀有资源。 对于一些消耗带宽的共享策略，BitTorrent的tit-for-tat策略表现脆弱，而PropShare表现非常好。 2.3 版本控制系统-Git Git是当前最流行的文件版本控制系统，它可以对文件内容的更新进行建模和分发。Git提供了一种强大的Merkle DAG对象模型，可以将文件版本更新记录在文件树中，同时对分布式环境也非常友好。Juan列举了Git的6种特性： 模型中有3种对象：文件、目录和commit更新 基于对象内容的哈希来寻址 对象之间的链接是嵌入式的，形成有向无环图 DAG 大部分版本化的元数据基于指针引用，创建和更新资源更高效 版本变化只需要更新引用或者增加对象 分布式的版本更新只需要传输文件和更新远程引用。 2.4 自认证文件系统 这里提到了SFS实现了分布式信任链和平等共享的全局命名空间。此外，Juan还提到了一种SFS远程文件寻址机制： # Addressing remote filesystems using the following scheme: /sfs/<Location>:<HostID> # where Location is the server network address, and: HostID = hash(public_key || Location) 3️⃣IPFS模型设计 Juan在第三章提到IPFS融合了DHT，BitTorrent，Git以及SFS等系统的思想。IPFS的贡献就是将这些技术简化、优化和整合，并凝聚成一套更完整优秀的系统。IPFS也具备平台能力供开发者在平台上部署各类应用。IPFS所有的节点都是平等的，没有特殊的节点。这些节点需要在本地存储IPFS对象，并且互相通信和传递数据。 接着，Juan将IPFS协议按照功能划分为7个子协议栈： Identities（身份标识），负责节点的身份生成和身份验证。 Network（网络），负责管理节点之间的通信。 Routing（路由），负责维护数据寻址的结构。 Exchange（交换），建立一种新的数据交换协议（BitSwap）来管理数据块的分发。 Objects（对象），采用Merkle DAG连接内容寻址的对象。 Files（文件），借鉴了Git的文件版本控制模型。 Naming（命名），建立了一种自认证的、可变更的命名系统。 这些子协议最终融合一体，构建整个IPFS模型，下面Juan分别介绍了这7个协议。 3.1 Identities（身份标识） IPFS使用NodeId标识节点，它是由生成的公钥进行hash后的结果。用户可以在每次启动前，实例化一个新的节点标识。但是系统不鼓励节点经常更新NodeId，因为这样会消耗网络资源。 type NodeId Multihash type Multihash []byte // self-describing cryptographic hash digest type PublicKey []byte type PrivateKey []byte // self-describing keys type Node struct { NodeId NodeID PubKey PublicKey PriKey PrivateKey } 上面是节点身份标识的数据结构，下面是节点身份生成的生成算法。 // S/Kademlia based IPFS identity generation difficulty = <integer parameter> n = Node{} do { n.PubKey, n.PrivKey = PKI.genKeyPair() n.NodeId = hash(n.PubKey) p = count_preceding_zero_bits(hash(n.NodeId)) } while (p < difficulty) 假设首次连接新节点other时，要判断它的公钥哈希hash(other.PubKey)和NodeId(other.NodeId)是否相等。如果不相等则节点无效，断开连接。 3.2 Network（网络） IPFS的节点要连接上百个来自整个互联网的其他节点，Juan给出了IPFS网络的5种特性： Transport（数据传输层），IPFS会使用多种传输层写有，这里Juan推荐WebRTC DataChannels和uTP协议。 Reliability（可靠性），即便底层网络不可靠，IPFS也可以使用uTP或SCTP来提升可靠性。 Connectivity（连接性）：IPFS使用ICE NAT穿透技术。 Integrity（完整性）：IPFS可以通过hash checksum，来校验消息完整性。 Authenticity（权限可验证性）：通过用发送者的私钥对消息进行数字签名，来验证消息的权限。 在最后，Juan补充了关于节点地址结构的说明。由于IPFS支持多种协议，所以可以应用在多种网络层。这种情况下，IPFS用一种多层地址multiaddr的结构来存储地址数据。 # an SCTP/IPv4 connection /ip4/10.20.30.40/sctp/1234/ # an SCTP/IPv4 connection proxied over TCP/IPv4 /ip4/5.6.7.8/tcp/5678/ip4/1.2.3.4/sctp/1234/ 3.3 Routing(路由) IPFS需要一个路由系统来查找目标节点，这里用到了基于S/Kademlia和Coral的DSHT技术。IPFS的DHT，就是分布式哈希表，是基于value值的大小区别存储的。如果value比较小，小于1kb，那么直接存在DHT上，如果value比较大，那么DHT上只存储引用，就是能够提供对象内容节点的NodeId。下面是Juan给出的IPFS的DSHT接口设计代码： type IPFSRouting interface { FindPeer(node NodeId) // gets a particular peer’s network address SetValue(key []bytes, value []bytes) // stores a small metadata value in DHT GetValue(key []bytes) // retrieves small metadata value from DHT ProvideValue(key Multihash) // announces this node can serve a large value FindValuePeers(key Multihash, min int) // gets a number of peers serving a large value } 3.4 Block Exchange - BitSwap Protocal（块交换） IPFS使用的BitSwap协议收到了BitTorrent的启发，通过节点间交换数据完成数据的分发。像BitTorrent一样，每个节点向其他节点下载需要的数据want_list，同时提供已有的数据have_list，用这种方式实现数据交换。与BitTorrent不同的是，BitSwap不局限于一个torrent种子文件中所记录的数据块，它更像一个永久的交易市场，节点可以获取任意想要的数据块，这些数据碎片可能来自不相关的文件。所有节点都要在这个市场交易数据。交易市场的概念往往需要一个流通的虚拟货币支撑，这就需要一个全局账本来记录交易。 BitSwap 常规情况下，BitSwap节点之间直接能各取所需是最好的。但是，很多情况下，一方拥有对方需要的数据，而另一方没有。那可以，以较低的优先级去获取其他节点需要的数据。这就激励每个节点，能缓存和传播一些冷门的数据，即便并不是该节点所需要的。 下面，Juan介绍了BitSwap信用、策略、账本和规范四部分内容。 3.4.1 BitSwap信用 BitSwap鼓励节点多存储和传播数据，即便自己不需要但是其他节点可能需要。节点乐观地相信，预先付出以后会得到回报，可以后面催其他节点还债。这就可以防止只免费索取不愿分享的节点，可以建立信用系统（credit-like system）来解决这些问题： 追踪节点之间相互可用的信用额度。 节点给另一个债务节点发送数据的可能性与债务大小成反比。 换句话说，对方欠我数据越多，我想它发送数据的可能性越小，并且设计一个函数来计算这个概率。但如果一个节点不打算理睬另一个节点，可以给出一个ignore_cooldown超时，表达断交的通知。 3.4.2 BitSwap策略 IPFS每个节点可以采用不同的BitSwap策略，不同的策略对块交换的性能会产生很大影响。BitTorrent指定tit-for-tat作为标准默认策略，但也有许多第三方非标准策略，如BitTyrant、BitThief和ProShare。BitSwap节点也应支持多种协议，不论是善意的还是恶意的。Juan给BitSwap的协议提出4点目标： 最大化节点和网络的交易性能 防止吃白食的负载节点消耗和破坏交易 谨慎对待或拒绝使用未知策略的节点 宽仁地对待信任的节点 Juan提到实践中，sigmoid函数是一个被证实有效的选择。这个函数可以根据负债率(r)来调节。 负债率 发送给负债节点的概率公式如下所示： 概率 概率曲线如下所示： 曲线 这种策略对长期交易的节点宽松，对未知节点严格，这样有几点好处： 抵制攻击者创建大量新节点发起女巫攻击 对长期合作的节点，即便偶尔不稳定也能维持友好关系 不跟表现恶劣的节点合作，知道对方有所改变 3.4.3 BitSwap账本 BitSwap节点保存一个记录与其他节点交易的账本，这样可以追踪历史记录、避免篡改。每建立一次连接，节点之间就要交换账本信息。如果双方的帐对不上，就要创建一个空账本初始化数据，同步给对方。所有不同步的借贷数据就会丢失。当然恶意节点有可能会故意制造这种债务丢失，不过这种数据不匹配的情况，很快就会发现，不会让恶意节点占太多便宜。如果发生次数较多，其他节点就不会再信任它了。 type Ledger struct { owner NodeId partner NodeId bytes_sent int bytes_recv int timestamp Timestamp } 节点可以自由处理自己的账本数据，一般只有新的数据是有用的，无用的数据可以进行垃圾回收。 3.4.4 BitSwap协议规范 下面是BitSwap协议的数据结构，以及节点Peer的数据结构和4个接口： // Additional state kept type BitSwap struct { ledgers map[NodeId]Ledger // Ledgers known to this node, inc inactive active map[NodeId]Peer // currently open connections to other nodes need_list []Multihash // checksums of blocks this node needs have_list []Multihash // checksums of blocks this node has } type Peer struct { nodeid NodeId ledger Ledger // Ledger between the node and this peer last_seen Timestamp // timestamp of last received message want_list []Multihash // checksums of all blocks wanted by peer // includes blocks wanted by peer’s peers } // Protocol interface: interface Peer { open (nodeid :NodeId, ledger :Ledger); send_want_list (want_list :WantList); send_block (block :Block) -> (complete :Bool); close (final :Bool); } BitSwap结构的字段包括：当前节点的账本ledger、当前有效连接active，需要的block的校验码need_list，拥有的block的校验码have_list。 Peer结构的字段包括：NodeId，节点与当前peer之间的账本ledger，上一条消息时间last_seen，当前peer节点需要的block数据块校验码want_list，其中包括当前peer的peer所需要的数据块。 Peer协议接口包括：open，send_want_list，send_block，close四个接口。 Peer节点连接有4种声明状态： Open：对方节点请求建立连接并且发送账本 Sending：节点间交换需求块列表和数据块 Close：节点之间关闭连接 Ignored：策略认为该节点可以忽略，返回超时 后面，Juan详细介绍了Peer接口4个函数的流程，这里不再多做赘述。 3.5 Object（对象） Merkle DAG 前面提到的分布式哈希表DHT和块交换协议BitSwap，能够使IPFS构建点对点系统，高效稳定地存储和分发数据，但是这些数据是如何存储的呢？在这一章，Juan介绍IPFS会构建有向无环图Merkle DAG将对象进行连接。 Merkle DAG对IPFS来说，有3种重要特性： 内容寻址，所有内容都是由多重哈希校验来唯一标识 无法篡改，所有内容都用checksum来验证，数据被篡改，IPFS会检测到 有效去重，所有拥有一致内容的对象被IPFS看作同一个对象并只存储一次 IPFS数据格式如下： type IPFSLink struct { Name string // name or alias of this link Hash Multihash // cryptographic hash of target Size int // total size of target } type IPFSObject struct { links []IPFSLink // array of links data []byte // opaque content data } IPFS Merkle DAG 可以很灵活地处理数据，他只需要满足内容索引，以及上面的对象格式。IPFS不会干涉每个应用如何管理自己的数据，或是使用什么数据格式。Juan列举了一些IPFS对象连接表地操作指令： 列出一个对象的引用对象。 <object multihash> <object size> <link name> 解决了路径查找问题，如foo/bar/baz这样的路径，可以很容易通过link表来遍历。 递归遍历所有对象的引用，这就是遍历对象的指令。 > ipfs refs --recursive \ /XLZ1625Jjn7SubMDgEyeaynFuR84ginqvzb XLLxhdgJcXzLbtsLRL1twCHA2NrURp4H38s XLYkgq61DYaQ8NhkcqyU7rLcnSa7dSHQ16x XLHBNmRQ5sJJrdMPuu48pzeyTtRo39tNDR5 XLWVQDqxo9Km9zLyquoC9gAP8CL1gWnHZ7z ... 3.5.1 Paths IPFS对象可以通过路径来查找，格式与UNIX文件系统或者WEB路径差不多。Merkle DAG link结构让这种查找非常简单：下面是路径的例子： # format /ipfs/<hash-of-object>/<name-path-to-object> # example /ipfs/XLYkgq61DYaQ8NhkcqyU7rLcnSa7dSHQ16x/foo.txt 假设一个对象路径是：/bar/baz，则以下三种方式都可以访问baz： /ipfs//bar/baz /ipfs//baz /ipfs/ 3.5.2 本地化存储 IPFS客户端需要一定的本地存储空间，一般存储于磁盘上或者内存种，用来存储一部分对象和原始数据。 3.5.3 对象锁定 IPFS节点可以将对象进行锁定，这样对象就可以一直保存在本地，也可以通过递归，将对象的所有关联对象全部锁定在本地。 3.5.4 发布对象 IPFS是全球化的分布式网络，需要满足海量文件同步工作。通过DHT技术，可以更安全、公平、分布式地分发对象。每个人都有权分发对象，只需要把对象的key，添加到DHT表中，把自己添加成为peer节点，也就是value中，再将路径分享给其他用户，就完成了发布。对象是永远不可变的，如果数据更新版本了，hash也会随之更新。 3.5.5 对象级密码学 IPFS支持对象级的密码学操作，加密或者签名的对象，可以用下面的数据结构： type EncryptedObject struct { Object []bytes // raw object data encrypted Tag []bytes // optional tag for encryption groups } type SignedObject struct { Object []bytes // raw object data signed Signature []bytes // hmac signature PublicKey []multihash // multihash identifying key } 对象加密以后，hash发生变化成为了一个新的对象。所谓对象级加密，就是一个父节点对象，可以用一个密钥加密，另一个子对象可以用其他对象加密或者不加密，这即是对象级别的保护。 3.6 Files（文件） 3.5中的对象是相对抽象的数据结构，这一章，Juan在Merkle DAG上定义了四种对象类型。建立了一种可版本化的文件系统： block：大小可变的数据块 list：block的集合或者list的集合 tree：block、list或者tree的集合 commit：tree的版本历史快照 相比于Git模型，IPFS做了一些改进，如增加了总字节数字段（方便快速查询 ），增加了list对象（方便去重大文件）。下图是论文中的Object Merkle DAG样例图： DAG样例 样例图中有4中不同颜色的节点，代表4种不同的对象类型，接下来论文重点介绍这4种类型： 🕛blob对象 blob对象是可寻址的文件数据单元，用来存储文件数据. { "data": "some data here", // blobs have no links } 这里是blob对象bbb222的数据样例: > ipfs file-cat <bbb222-hash> --json { "data": "blob222 data", "links": [] } blob对象没有link字段，它是树的叶节点。IPFS的文件既可以用blob也可以用list。 🕛list对象 list对象一般代表由多个blob组成的大文件，list可以包含blob和list。 🕛tree对象 tree对象和Git一样，代表目录，是一组名称和哈希的映射，下面是tree对象的数据结构： { "data": ["blob", "list", "blob"], // trees have an array of object types as data "links": [ { "hash": "XLYkgq61DYaQ8NhkcqyU7rLcnSa7dSHQ16x", "name": "less", "size": 189458 }, { "hash": "XLHBNmRQ5sJJrdMPuu48pzeyTtRo39tNDR5", "name": "script", "size": 19441 }, { "hash": "XLWVQDqxo9Km9zLyquoC9gAP8CL1gWnHZ7z", "name": "template", "size": 5286 } // trees do have names ] } 这里的哈希指向连接的blob，list和其它的tree或者commit，下面是ttt111对象的数据结构： > ipfs file-cat <ttt111-hash> --json { "data": ["tree", "tree", "blob"], "links": [ { "hash": "<ttt222-hash>", "name": "ttt222-name", "size": 1234 }, { "hash": "<ttt333-hash>", "name": "ttt333-name", "size": 3456 }, { "hash": "<bbb222-hash>", "name": "bbb222-name", "size": 22 } ] } ttt111对象link了两个tree和一个blob对象。 🕛commit对象 commit对象表示对象的历史版本快照，它可以指向任何类型的对象。下面是commit对象ccc111的数据结构： { "data": { "type": "tree", "date": "2014-09-20 12:44:06Z", "message": "This is a commit message." }, "links": [ { "hash": "<ccc000-hash>", "name": "parent", "size": 25309 }, { "hash": "<ttt111-hash>", "name": "object", "size": 5198 }, { "hash": "<aaa111-hash>", "name": "author", "size": 109 } ] } 这一章最后，Juan讲了IPFS文件的一些特性。IPFS和Git的对象模型略有差别，但基本兼容。很多Git上的文件管理工具稍加修改也可以用在IPFS上。IPFS文件系统路径的格式和UNIX也是兼容的，tree代表unix目录，commit既可以表示目录也可以隐藏。对于一些大文件的管理和分发，主要的挑战是如何将它们分割成一些独立的数据块，这里Juan刚给了三种大致思路。紧接着Juan谈到了路径查询的新性能问题。通过一个路径去查询数据，要在DHT中找到key，再连接映射的peer节点拉取数据。如果路径比较深，效率可能比较低。Juan提出了两个方案：tree cacheing（树缓存）、flattened trees（扁平树）。 3.7 IPNS: Naming and Mutable State（命名系统） 目前，IPFS系统已经构建了点对点的块交换协议以及基于内容寻址的对象DAG。但目前的系统，发布的对象都是不可变的，这样会有什么问题呢？基于内容寻址很大的问题是，内容一变，之前的地址就失效了。文件都是通过hash来寻址的，但是有一些文件是经常变化的，每变化一次它的连接地址也会发生变化。而且哈希地址这种字符串，对人类识别很不友好，所以希望建立一种当文件变化时，路径可以保持不变的机制，这就是IPNS。 IPFS借鉴了自认命名系统SFS的命名机制： 计算node id 给每个用户分配一个可变的空间 用户可以在路径空间下添加对象，用其私钥签名 其他用户找到这个对象后，通过该用户公钥验证是否是其本人发布 IPNS虽然能够帮助重新命名，但长串的hash对用户很不友好，Juan列举了4种技术提升体验： 节点链接，Peer Links，通过这种方法可以将其他用户的对象连接到我的对象，当然也要通过权限验证，这就建立了一个可信网络。 # Alice links to bob Bob ipfs link /<alice-pk-hash>/friends/bob /<bob-pk-hash> # Eve links to Alice ipfs link /<eve-pk-hash/friends/alice /<alice-pk-hash> # Eve also has access to Bob /<eve-pk-hash/friends/alice/friends/bob # access Verisign certified domains /<verisign-pk-hash>/foo.com DNS TXT记录，对于一个有效的域名，IPFS要在DNS TXT记录查找，找到对应映射的IPNS路径 # this DNS TXT record ipfs.benet.ai. TXT "ipfs=XLF2ipQ4jD3U ..." # behaves as symlink ln -s /ipns/XLF2ipQ4jD3U /ipns/fs.benet.ai 转换成可读的标识符，就是把一些无规则的加密字符串，变成一组可识别的单词 # this proquint phrase /ipns/dahih-dolij-sozuk-vosah-luvar-fuluh # will resolve to corresponding /ipns/KhAwNprxYVxKqpDZ 短域名服务 # User can get a link from /ipns/shorten.er/foobar # To her own namespace /ipns/XLF2ipQ4jD3UdeX5xp1KBgeHRhemUtaA8Vm 3.8 Using IPFS（应用） 最后的一小节，Juan列举了12种期望的应用场景，还有3个需要实现的目标 ： 建立IPFS库，可以导入到开发者的应用程序 通过命令行工具直接操作对象 实现可挂载的文件系统 4️⃣展望 Juan认为，IPFS沿着前人的成功足迹，结合了许多优秀的分布式系统的思想精华。除了BitSwap是一个新的协议，其他的都是各种现有技术的整合。IPFS有一个伟大的构想，构建分布式的互联网基础设施，并且支持各种应用程序。

作者：Samehada

时间：2023/01/07

文章: 《Bitcoin: A Peer-to-Peer Electronic Cash System》

版权声明：文章采用 BY-NC-SA 许可协议，转载请注明出处！

1.前言

2008年11月1日，比特币白皮书—《比特币:一种点对点的电子现金系统》横空出世。该文章向世人介绍了全新的货币系统-比特币。15年过去了，如今白皮书有了些被神话的味道，它成了许多人心中圣经般的存在，仿佛天不生比特币，加密货币领域万古如长夜。如此认知对于我们了解比特币是不利的，比特币白皮书更像是一种科学文献或是产品的说明文档，仅此而已，只是未曾料到它的出现影响了世界的走向。

在中本聪之前，对于点对点通信的信任问题，人们在密码学、时间戳、哈希现金等技术层面不断推陈出新，彼时科研人员也发表了一些带有相应技术特点的电子货币。2008年，中本聪站到了前人的肩膀上，提取了前人的智慧，做出了关键性的突破，打造出了自己心目中理想的电子现金系统。其发布时间恰逢美国政府滥发钞票造成了全国通胀。比特币生不逢时，却也来得刚刚好。

2.摘要

在摘要中，中本聪开门见山，道出设计比特币系统的目的：

A purely peer-to-peer version of electronic cash would allow online payments to be sent directly from one party to another without going through a financial institution.

比特币的目标是通过构建点对点的技术，实现一种电子现金系统，达到无需金融中介，也无需双方信任的情况下实现在线电子化支付。

紧接着中本聪提出了比特币系统要解决的核心问题—双重支付，此处由于篇幅问题不予展开：

Digital signatures provide part of the solution, but the main benefits are lost if a trusted third party is still required to prevent double-spending.

这里文章说数字签名技术为双花交易提供了部分解决方案，而比特币系统是也采用数字签名这一方法，但是如此还是需要第三方机构介入，那系统的设计就有些无趣了。事实上，日常的数字资产常依赖于第三方信任机构进行，如银行、支付宝、微信，这些机构通过中心化管理，并通过实时修改账户余额的方法来防止双重支付的出现。

现实世界中，人们需要为交易中的第三方验证支付巨额的费用，全球总共超过75亿人，每天的交易量更高达万亿级别，中心化机构管理的费用在交易中被提取出来。这也是文章中说的 the main benefits are lost。

We propose a solution to the double-spending problem using a peer-to-peer network.

所以比特币系统要做的就是去中心化和解决双重支付，在不需要第三方信任机构的情况下，点对点转移数字资产，中本聪提出了基于点对点的网络解决方案。

The network timestamps transactions by hashing them into an ongoing chain of hash-based proof-of-work, forming a record that cannot be changed without redoing the proof-of-work.

中本聪设计的点对点网络为交易打上了时间戳，通过取这些交易的哈希值，将它们编入一条持续增长的工作量证明链，这样的一条链除非重做已经做的大量工作否则将无法改变，这里的主要工作量是计算一个符合条件的哈希值。

The longest chain not only serves as proof of the sequence of events witnessed, but proof that it came from the largest pool of CPU power.

由于设计的工作量证明机制，比特币系统最长的链不仅仅是交易执行的事件序列，而且也代表着这条链占有者最大的CPU计算资源。

As long as a majority of CPU power is controllerd by nodes that are not cooperating to attack the network, they'll generate the longest chain and outpace attackers.

因为系统最长链是最大CPU计算资源工作形成的，所以只要大部分的CPU算力不被恶意节点所控制，那么这些诚实的节点就能一直生成最长的合法链并且延长链的速度会超过恶意节点所工作的另一条链，从而使得攻击失效，这里即是后面大名鼎鼎51%攻击的雏形，但是引起笔者反思“多数人即正义”在有些突发事件下真的合理吗？

The network itself requires minimal structure. Messages are broadcast on a best effort basis, and nodes can leave and rejoin the network at will, accepting the longest proof-of-work chain as proof of what happened while they were gone.

比特币网络结构很简单，因为没有中心化服务器，所以它的结构非常小巧。每个节点只管尽可能广泛的打包并向最长合法链传播交易信息即可。每个节点也可以随时离开系统，因为有其他节点同时也在打包这些交易并试图传播到链上，而且可以随时回到系统，只需要继续接受最长链继续工作即可。

总结：中本聪通过数字签名，随机散列，哈希算法，工作量证明，动态链式存储等技术，设计了一系列的机制，使比特币能够不依附于第三方信任机构，解决了电子支付中的双花、记录篡改等问题，并证明该系统安全有效、稳定可行。

3.概述

文章第一章概述，中本聪在文章中描述了传统线上交易模式的弊病，并正式提出本文的比特币系统。

Commerce on the Internet has come to rely almost exclusively on financial institutions serving as trusted third parties to process electronic payments. While the system works well enough for most transactions, it still suffers from the inherent weaknesses of the trust based model.

中本聪指出当前的线上交易往往非常依赖于金融机构充当可信任的第三方。但这种交易模式有着先天性的缺点，那就是下面要说的交易成本高和交易可逆性。

Completely non-reversible transactions are not really possible, since financial institutions cannot avoid mediating disputes.

文章这里谈到，由于金融机构不可避免地需要调节买卖双方的争端，所以现有的模式下实现完全不可逆的交易是不可能的。这里如何理解呢，交易双方往往由于没有充足的信任，交易完成后如果一方不满意，此时金融机构就要承担仲裁的角色，来平息买卖双方的争议，买家退货商家退款，这样的线上交易时可逆的。但是有些服务业和餐饮业的交易是需要一种不可逆性的，享用了服务再退款难免会出现扯皮的现象。

With the possibility of reversal, the need for trust spreads. Merchants must be wary of their customers, hassling them for more information than they would otherwise need. A certain percentage of fraud is accepted as unavoidable.

由于买卖双方不够信任，恶意退货这种行为使得交易存在被撤销的可能性。因此，商家有着很强的不安感，所以他们向客户索要大量的信息来建立脆弱的信任，降低交易撤回的可能性。这里说明了传统线上交易的第一个弊病——交易可逆性。

These costs and payment uncertainties can be avoided in person by using physical currency, but no mechanism exists to make payments over a communications channel without a trusted party.

文章紧接着说，这些协调争端的成本和支付的不确定性提高了整体交易的成本，而且目前不存在不引入第三方信任机构就能进行支付的机制，除非当面一手交钱一手交货，这就是传统交易的第二个弊病——交易成本高。

What is needed is an electronic payment system based on cryptographic proof instead of trust, allowing any two willing parties to transact directly with each other without the need for a trusted third party.

传统线上交易的两个弊病根源都在于互不信任，因此需要的一个电子支付系统，基于密码学来建立一种共识，这种具有公信力的共识可以允许双方互不信任并直接交易，而不需要第三方。

Transactions that are computationally impractical to reverse would protect sellers from fraud, and routine escrow mechanisms could easily be implemented to protect buyers.

从计算上的不可逆转性可以保护卖家的利益，而常规的托管机制也很容易实现来保护买家的利益。

In this paper, we propose a solution to the double-spending problem using a peer-to-peer distributed timestamp server to generate computational proof of the chronological order of transactions.

下面文章又将矛头转向了多次提及的双重支付问题，中本聪提出的是一种点对点的分布式时间戳服务器，生成按交易顺序先后顺序排列的可计算的证明。

The system is secure as long as honest nodes collectively control more CPU power than any cooperating group of attacker nodes.

只要节点和算力足够分散，诚实节点算力大于恶意节点算力，系统总是安全的。

总结：目前的电子交易机制存在两点弊端：

1. 基于第三方机构的交易提高了交易成本。

2. 由于不存在不可逆的交易，交易对信用要求高，买方会收集过多的信息。

所以，文章提出的电子交易系统，建立在密码学共识而非新人之上，这让交易在不需要第三方机构的前提下可以完成。

4.交易

文章第二章，中本聪提出了比特币系统中非常重要的概念，交易和记账。对任何一个电子货币系统来说，如何完成收付款以及存储交易记录，是头等大事。

We define an electronic coin as a chain of digital signatures. Each owner transfers the coin to the next by digitally signing a hash of the previous transaction and the public key of the next owner and adding these to the end of the coin. A payee can verify the signatures to verify the chain of ownership.

中本聪说，我们定义电子货币是一条数字签名链，每个拥有者通过将上一次交易和下一个拥有者的公钥的哈希值的数字签名添加到货币末尾的方式，将货币转移给下一个拥有者。这样收款人就可以通过验证数字签名来证实该链的拥有者。

在上一笔交易的Hash值上进行数字签名，表明拥有者确实收到过这些货币，这些收到的货币是可溯源的。在下一位拥有者的公钥Hash上进行数字签名，表示是当前所有者转给下一位拥有者的。

下面将注意力放到中间的这笔交易上，这是Owner 1向Owner 2转账的一笔交易。从上向下看，首先这笔交易包含了上一笔交易的Hash，同时包含了Owner 2公钥的Hash，实际上就是Owner 2 的收款地址，最后在使用Owner 1的私钥对这笔转账进行签名。而Owner 2可以使用Owner 1的公钥来验证Owner 1的签名是否是其本人。

The problem of course is the payee can't verify that one of the owners did not double-spend the coin. A common solution is to introduce a trusted central authority, or mint, that checks every transaction for double spending. After each transaction, the coin must be returned to the mint to issue a new coin, and only coins issued directly from the mint are trusted not to be double-spent. The problem with this solution is that the fate of the entire money system depends on the company running the mint, with every transaction having to go through them, just like a bank.

通过数字签名技术，收款方已经能够验证付款方身份的真实性，但是它还不能验证付款方是否进行了双重支付，也就是付款方是否是否给其他人支付了这些电子货币。通常情况会引入可靠的第三方机构，比如央行或铸币厂，由他们负责发行、结算和审核交易。

We need a way for the payee to know that the previous owners did not sign any earlier transactions. For our purposes, the earliest transaction is the one that counts, so we don't care about later attempts to double-spend. The only way to confirm the absence of a transaction is to be aware of all transactions.

这样可以解决双花问题，但是比特币的使命就是不再依赖第三方金融中介，所以另一种方案就是不如让收款人洞悉到付款人在此次交易之前的其他交易。这样可以判断在这笔交易之前，付款人有没有会造成双重支付的其他可疑交易。

To accomplish this without a trusted party, transactions must be publicly announced , and we need a system for participants to agree on a single history of the order in which they were received.

如果系统不依赖任何第三方来审核账本，那么就需要公开所有的交易数据。所有的节点都来监督和维护一个共同的账本，并达成一种对交易收到顺序的单一历史性共识，最终只有一个有效的、带时间顺序的记账数据并公之于众，这就是比特币的分布式记账系统。

总结：数字签名技术可以验证付款人身份，但无法验证双花问题。对于双重支付，去中心化的解决方案时靠公开数据并全网广播，所有人维护同一个有效账本。

5.时间戳服务器

第三章，时间戳服务器，这一章只有短短一段话和一幅图。

The solution we propose begins with a timestamp server. A timestamp server works by taking a hash of a block of items to be timestamped and widely publishing the hash, such as in a newspaper or Usenet post. The timestamp proves that the data must have existed at the time, obviously, in order to get into the hash.

文章说时间戳服务器对包含交易数据的区块的哈希值打上时间戳，将时间信息纳入区块信息中，然后将这些哈希值广播到网络中。

Each timestamp includes the previous timestamp in its hash, forming a chain, with each additional timestamp reinforcing the ones before it.

同时文章提到，而每一个打上时间戳的区块Hash中包含着前一个打赏时间戳的区块的信息，即每打上一个时间戳就会加强前一个时间戳的真实存在性。

总结：时间见证一切，所有的区块像编年史一样，按照时序紧密连接，并且同步到全部的节点。因此，历史区块信息几乎无法篡改。因为。如果要修改区块数据，就需要修改其后所有已生成区块的哈希数据，还要让大多数节点形成共识 。

6.工作量证明

第四章，来到了Proof-of-Work工作量证明。前面提到账本是由全体分布式节点共同维护的，接下来就面临谁拥有记账权的问题。

To implement a distributed timestamp server on a peer-to-peer basis, we will need to use a proof-of-work system similar to Adam Back's Hashcash , rather than newspaper or Usenet posts.

POW的理念早在1997年Adam Back发明的哈希现金(hashcash)中就提到过，原型本来是用于解决互联网的垃圾信息问题。

The proof-of-work involves scanning for a value that when hashed, such as with SHA-256, the hash begins with a number of zero bits. The average work required is exponential in the number of zero bits required and can be verified by executing a single hash.

在进行哈希运算时，工作量证明机制将扫描寻找一个符合条件的值。例如通过SHA-256，遍历这些SHA-256的哈希值将从一些0开始。寻找这个值所需的工作量随着0的增长将呈指数级增长，而验证这个值是否是正确的仅需一次哈希运算。

For our timestamp network, we implement the proof-of-work by incrementing a nonce in the block until a value is found that gives the block's hash the required zero bits.

为了保证每次工作量证明都是重新计算的，中本聪在区块中添加了一个Nonce随机数。这个随机数要使得区块的哈希值出现所需的那么多个0。通过反复运算来找到这个随机数，找这个随机数的过程就是在做工作，同时将难度动态调整，大约每10分钟出一个块。

Once the CPU effort has been expended to make it satisfy the proof-of-work, the block cannot be changed without redoing the work. As later blocks are chained after it, the work to change the block would include redoing all the blocks after it.

一旦节点使用CPU工作满足了POW机制获得了记账权，区块发布后信息就不能再更改，除非重做一遍这些工作。而一旦有新的区块内链接到了一个区块后面，要修改这个区块的信息，就需要将这个区块已经做的所有工作全部重做一遍。

文章给出的插图中可以看出，一个区块包含着上一个区块的哈希值。一旦修改某个区块的内容，其哈希值必然改变，则下一个区块就要重新寻找Nonce值，以此类推，一直追赶后面在不断延伸的链条。所以，如果没有足够强的算力，几乎不可能修改区块上的信息。

The proof-of-work also solves the problem of determining representation in majority decision making. 

中本聪还提到了，POW机制解决了在多数决定中决定代表的问题。

If the majority were based on one-IP-address-one-vote, it could be subverted by anyone able to allocate many IPs. Proof-of-work is essentially one-CPU-one-vote. The majority decision is represented by the longest chain, which has the greatest proof-of-work effort invested in it.

如果是基于一个IP一票的方式，那些恶意控制众多IP的人将会代表大多数，而POW机制本质是按CPU算力投票，最长链代表了最多数的投票结果，因为这条链上有最多的算力投票。

If a majority of CPU power is controlled by honest nodes, the honest chain will grow the fastest and outpace any competing chains.

如果多数的CPU算力被诚实的节点所控制，那么诚实的链增长得会最快，并超过其他的竞争链。

To modify a past block, an attacker would have to redo the proof-of-work of the block and all blocks after it and then catch up with and surpass the work of the honest nodes.

前面已经提到，如果要修改某一个区块内容，那么其后已产生的区块信息都要修改，需要重做这些工作。攻击者需要重新一遍这个区块的工作量以及这个区块后所有区块的工作量，才能弯道超车赶上诚实节点的工作量，这个成本极高。

We will show later that the probability of a slower attacker catching up diminishes exponentially as subsequent blocks are added.

这种攻击者赶上诚实节点的概率会随着后续区块的增长而大大减小，成本也会大大增加。

To compensate for increasing hardware speed and varying interest in running nodes over time, the proof-of-work difficulty is determined by a moving average targeting an average number of blocks per hour. If they're generated too fast, the difficulty increases.

为了抵消硬件速度提升和平衡节点利益，工作量证明将使用移动平均数法来确定每小时生成区块的平均个数。如果出块过快，系统将会让出块的难度增加，最终保持在10分钟的水平。

总结：中本聪在前人基础上提出了工作量证明机制，并介绍了每个节点工作量的体现方式。同时提出工作量证明机制本质上是基于算力的投票，拥有最大工作量的最长链代表着大多数节点认可的链。

7.网络

第五章，中本聪设计了有效的机制，来部署整个分布式网络。

运行整个网络分为六个步骤：

1. 每一笔新交易都要向所有节点广播。

2. 每个节点将新交易打包收集到一个区块中。

3. 每个节点要为这个区块进行一定难度的工作量证明。

4. 当一个节点找到了工作量证明，向其他节点广播这个区块。

5. 节点需要验证区块内所有交易有效且没有双重支付的区块下接受这个区块。

6. 节点使用这个区块的哈希值作为previous hash，记录在新区块中，表示节点已经认可这个区块。

Nodes always consider the longest chain to be the correct one and will keep working on extending it.

节点总是认为最长的链是正确的，并共同维护和延长它。

If two nodes broadcast different versions of the next block simultaneously, some nodes may receive one or the other first.

有这样一种情况，两个节点同时 广播了不同的区块，有些节点可能先收到其中一个，其他节点先收到另一个。

In that case, they work on the first one they received, but save the other branch in case it becomes longer. The tie will be broken when the next proof-of-work is found and one branch becomes longer; the nodes that were working on the other branch will then switch to the longer one.

这种情况下，节点基于他们先收到的区块继续工作，但也保存另一个分支，以防其变成更长的链。当下一个工作量证明被找到后，僵局就会被打破，从而其中一个分支变得更长，在另一个分支上工作的节点，将要转到更长链上工作。

New transaction broadcasts do not necessarily need to reach all nodes. As long as they reach many nodes, they will get into a block before long.

新交易的广播不必到达所有的节点，只要它们到达足够多的节点，它们很快就会被打包进入一个新区块。

Block broadcasts are also tolerant of dropped messages. If a node does not receive a block, it will request it when it receives the next block and realizes it missed one.

区块广播是容忍消息丢失的。如果一个节点没有接收到一个区块，他会请求下载这个缺失的区块信息。

总结：中本聪给出了比特币网络是如何运行的，并对网络中区块和交易的广播进行了解释。

8.激励

想要完成复杂的工作量证明，显然需要大量诚实的网络节点支持，并将一个个新区块数据写入网络中。这样的过程需要很大的成本，显然各个节点不会情愿一直为爱发电。

第六章，中本聪介绍了比特币网络的激励政策。

By convention, the first transaction in a block is a special transaction that starts a new coin owned by the creator of the block.

比特币系统做了约定，每一个区块里的第一笔交易是特殊交易，是系统专门奖励给区块创造者的奖励。

This adds an incentive for nodes to support the network, and provides a way to initially distribute coins into circulation, since there is no central authority to issue them.

这样不仅增加了对网络节点的激励，也提供了一种分发新货币到流通领域的方法。

The incentive can also be funded with transaction fees. If the output value of a transaction is less than its input value, the difference is a transaction fee that is added to the incentive value of the block containing the transaction.

还有一部分激励是交易的手续费。如果一笔交易输出值小于输入值，那么差额就作为交易费，被打包到包含此交易的区块激励中。

Once a predetermined number of coins have entered circulation, the incentive can transition entirely to transaction fees and be completely inflation free.

一旦预先量的货币都进入了流通域，激励将只剩交易费，如此防止通货膨胀。

The incentive may help encourage nodes to stay honest. If a greedy attacker is able to assemble more CPU power than all the honest nodes, he would have to choose between using it to defraud people by stealing back his payments, or using it to generate new coins. 

同时，激励有助于鼓励节点保持诚实。比如一个贪婪的攻击者，如果他有能力聚集比所有诚实节点更多的CPU算力，而他的目的仅仅是为了完成一次双花攻击或欺骗交易，比起诚实地做矿工拿激励，这是不值得的。

He ought to find it more profitable to play by the rules, such rules that favour him with more new coins than everyone else combined, than to undermine the system and the validity of his own wealth.

使用这些CPU算力做矿工获取稳定收益，这样做比他攻击链条、修改区块信息、盗取货币的利益更大。

总结：比特币的激励 = 挖矿奖励 + 交易手续费。

9.回收磁盘空间

第七章，回收磁盘空间，中本聪讲了区块链交易数据的存储结构。

Once the latest transaction in a coin is buried under enough blocks, the spent transactions before it can be discarded to save disk space.

如果某个币的最新交易信息被纳入了足够多的区块，那么可以丢弃掉这笔交易之前的交易，一词节省磁盘空间。

To facilitate this without breaking the block's hash, transactions are hashed in a Merkle Tree, with only the root included in the block's hash.

区块中交易的存储结构是默克尔树，它有一个根节点、一组中间节点和一组叶节点组成。

叶节点包含存储数据或是它的哈希值，中间节点是包含两个子节点内容的哈希值，根节点也是由下面两个子节点的哈希值构成。

Old blocks can then be compacted by stubbing off branches of the tree. The interior hashes do not need to be stored.

当一笔交易被足够多区块覆盖，即形成共识的时候。那么在区块中，它过去拥有者的交易数据就可以丢弃，只保留最新的数据以及之前数据根节点的哈希值，同时哈希值不会被破坏，依然可以来验证数据有效性。

如此验证，也就是零知识证明。也就是说，验证一个时间正确与否，并不需要验证者重现整个事件。默克尔树里的哈希值，即不占空间，又能提升索引效率，还能用于零知识证明。

A block header with no transactions would be about 80 bytes.

中本聪还通过距离做了一笔估算，他说每个不包含交易的区块头大概是80个字节。

If we suppose blocks are generated every 10 minutes, 80 bytes * 6 * 24 * 365 = 4.2MB per year. With computer systems typically selling with 2GB of RAM as of 2008, and Moore's Law predicting current growth of 1.2GB per year, storage should not be a problem even if the block headers must be kept in memory.

假设10分钟挖出一个区块，那么每年会生成4.2MB的数据。在2008年的计算机有2G的内存，根据摩尔定律预测，每年的内存会增长1.2GB。所以，就算区块头全部保存到内存中，存储也不是问题。

总结：使用默克尔树这种数据结构可以压缩数据，节约交易数据的存储成本。默克尔树里的哈希值，即不占空间，又能提升索引效率，还能用于零知识证明。

10.简化的支付验证

第八章，Simplified Payment Verification，简称SPV。

It is possible to verify payments without running a full network node.

SPV指的是不运行一个完整的网络节点，也可以进行支付验证的方式。我们经常看到的比特币钱包SPV Wallet或者轻钱包，往往运行的是SPV节点。

一个用户运行全节点需要几百G的磁盘空间，成本太高。因此，中本聪介绍了简化支付验证的可能性。

A user only needs to keep a copy of the block headers of the longest proof-of-work chain, which he can get by querying network nodes until he's convinced he has the longest chain, and obtain the Merkle branch linking the transaction to the block it's timestamped in.

实际上用户只需保存最长共识链的区块头数据就足够了，他可以通过向其他网络节点查询来确保获取到了最长链的数据，然后将需要验证的交易链接到对应的默克尔分支。

He can't check the transaction for himself, but by linking it to a place in the chain, he can see that a network node has accepted it, and blocks added after it further confirm the network has accepted it.

SPV节点原本不能自行验证交易，但是通过将交易连接到链上的某个位置，它可以看到网络节点认可了这笔交易，而在此之后增加的区块进一步确认了该交易被整个网络接受。

实际上，这种简化认证的钱包客户端抗攻击能力较差。

As such, the verification is reliable as long as honest nodes control the network, but is more vulnerable if the network is overpowered by an attacker. While network nodes can verify transactions for themselves, the simplified method can be fooled by an attacker's fabricated transactions for as long as the attacker can continue to overpower the network.

如果面临攻击，这种简化验证就会有较高的风险。这种简化的节点，也需要设计一定的机制保证安全性。

One strategy to protect against this would be to accept alerts from network nodes when they detect an invalid block, prompting the user's software to download the full block and alerted transactions to confirm the inconsistency.

一种对策是接受其他网络节点发现一个无效区块时发出的警告，提醒用户软件下载整个区块和被警告的交易来检查一致性。

Businesses that receive frequent payments will probably still want to run their own nodes for more independent security and quicker verification.

对于高频首付款的公司或者企业级服务商，中本聪还是建议维护一个自己的全节点。

总结：SPV节点可以方便地验证交易，但容易被攻击者控制。

11.合并和分割交易额

第九章，合并和分割交易额。

Although it would be possible to handle coins individually, it would be unwieldy to make a separate transaction for every cent in a transfer. To allow value to be split and combined, transactions contain multiple inputs and outputs.

实际上每笔比特币交易可以有多个输入方和多个输出方，即多个付款方和多个收款方。同时，收款方还可以包括付款方自己，这就是找零的过程。

Normally there will be either a single input from a larger previous transaction or multiple inputs combining smaller amounts, and at most two outputs: one for the payment, and one returning the change, if any, back to the sender.

同时，收款方还可以包括付款方自己，这就是找零的过程。

12.隐私

第十章，论文提到了隐私问题。

The traditional banking model achieves a level of privacy by limiting access to information to the parties involved and the trusted third party.

传统的银行模式，是通过限制参与各方和第三方机构对信息的访问来达到一定的隐私保护。

也就是说，用户交易信息只有用户本人和银行可以获取和提供。

The necessity to announce all transactions publicly precludes this method, but privacy can still be maintained by breaking the flow of information in another place: by keeping public keys anonymous.

而如果需要广播全部交易就排除了这种方式，但比特币系统仍可以通过保持公钥的匿名性这种阻断信息流的方式保护用户隐私。用户无需注册和实名审核，在匿名的状态下就可以获得比特币账户，这样就打破了交易信息和真实身份之间的关联。

The public can see that someone is sending an amount to someone else, but without information linking the transaction to anyone. This is similar to the level of information released by stock exchanges, where the time and size of individual trades, the "tape", is made public, but without telling who the parties were.

公众能看到有人正在发送一定量货币给别人，但是他不能将交易关联到某个人。就像股票交易，每笔交易的时间和交易量，也就是行情是公开的，但是看不到交易双方是谁。

13.计算

第十一章计算，中本聪通过公式和代码论证：在实践中，比特币网络被攻击成功的概率非常低。

We consider the scenario of an attacker trying to generate an alternate chain faster than the honest chain.

假设攻击者试图生成一条比诚实链更快的替代链，如果目的达到会怎样呢？

Even if this is accomplished, it does not throw the system open to arbitrary changes, such as creating value out of thin air or taking money that never belonged to the attacker.

即使这种情况可以实现，攻击者也不能凭空创造比特币或者拿走其他人的钱。因为，这需要破解别人的私钥，这是一个难度极高的数学问题。如果没有私钥，这就是一笔无效交易。

Nodes are not going to accept an invalid transaction as payment, and honest nodes will never accept a block containing them.

诚实的节点不会接受无效的交易作为支付，而且永远不会接受包含无效交易的区块。

An attacker can only try to change one of his own transactions to take back money he recently spent.

所以，攻击者只能试图改变他自己的某笔交易来拿回不久前已经支出的钱。

The race between the honest chain and an attacker chain can be characterized as a Binomial Random Walk.

中本聪说，诚实链于攻击者链之间的竞争，可以描述为二项随机游走模型。

The success event is the honest chain being extended by one block, increasing its lead by +1, and the failure event is the attacker's chain being extended by one block, reducing the gap by -1.

这里约定成功事件是诚实节点的链延长一个区块，也就是两条链的差距加1.失败事件是攻击者的链延长一个区块，两条链的差距减1。

The probability of an attacker catching up from a given deficit is analogous to a Gambler's Ruin problem.Suppose a gambler with unlimited credit starts at a deficit and plays potentially an infinite number of trials to try to reach breakeven.

那么攻击者从某一落后位置赶上诚实链的概率类似于赌徒破产理论。假设一个赌徒拥有无限的信任额度，从一定的亏损开始，玩潜在无限次的测试来试图弥补亏空。

We can calculate the probability he ever reaches breakeven, or that an attacker ever catches up with the honest chain, as follows :

我们要计算的是赌徒达到盈亏平衡的概率，也就是攻击者赶上诚实链的概率。

首先做出一些假设：

• p = 诚实节点找到下一个区块概率

• q = 攻击者找到下一个区块的概率

• $q_z$ = 攻击者从落后 z 个区块赶上诚实链的概率

当 p < q，$q_z$ = 1，因为攻击者总是能够更快找到下一个区块

当 p > q，$q_z = (q/p)^Z$，因为有z个独立事件。

Given our assumption that p > q, the probability drops exponentially as the number of blocks the attacker has to catch up with increases.

假设 p > q，概率$q_z$将会随着攻击者需要赶上的区块呈指数级下降。

With the odds against him, if he doesn't make a lucky lunge forward early on, his chances become vanishingly small as he falls further behind.

因为这种形式对他非常不利，如果攻击者没有在早期快速地赶上，那么他落后越远，赶上的机会就越渺茫。

We now consider how long the recipient of a new transaction needs to wait before being sufficiently certain the sender can't change the transaction.

接下来，中本聪考虑一个新交易的收款人要等多久，才能确信付款人不能再修改交易了。

We assume the sender is an attacker who wants to make the recipient believe he paid him for a while, then switch it to pay back to himself after some time has passed. The receiver will be alerted when that happens, but the sender hopes it will be too late.

假设付款人是攻击者，他想让收款人相信他已经付完款好一阵了，然后他又向自己打回这笔钱。当这个事件发生后，收款人将收到竞购，但是付款人希望付款人收到警告时为时已晚。

The receiver generates a new key pair and gives the public key to the sender shortly before signing.

其实，收款人可以临时生成一对新密钥，并将公钥给付款人。这样付款人就不会提前指导收款人的常用收款地址，也就无法提前对交易进行签名。

This prevents the sender from preparing a chain of blocks ahead of time by working on it continuously until he is lucky enough to get far enough ahead, then executing the transaction at that moment.

这样能防止付款人预先准备好一条区块链，然后执行交易。

Once the transaction is sent, the dishonest sender starts working in secret on a parallel chain containing an alternate version of his transaction.

但不管怎么样，一旦交易发出，不诚实的付款人就开始秘密地在一条包含他替换版交易的链上搞动作了。

The recipient waits until the transaction has been added to a block and z blocks have been linked after it. He doesn't know the exact amount of progress the attacker has made, but assuming the honest blocks took the average expected time per block, the attacker's potential progress will be a Poisson distribution with expected value:

假设收款人等到了交易被加到区块中，而且后面追加了 z 个诚实区块。他虽然不知道攻击者的确切进度，但假设诚实的区块按平均时间生成，攻击者可能的进度将会是一个泊松分布。

期望值 λ 就是攻击者在这个平均时间内取得进展的区块数量的期望值。

To get the probability the attacker could still catch up now, we multiply the Poisson density for each amount of progress he could have made by the probability he could catch up from that point:

为了计算攻击者当前仍然能赶上的概率，就是攻击者能到达 k 个区块进度的概率，下面列出了攻击者当前达到 k 个区块时，最终还能赶上 z 个诚实区块的概率。

然后对所有事件概率积分得到总的概率值，再通过变换来避免无限尾部求和，最终得到下面公式：

后面中本聪还给出了一段C语言代码和运行结果：

#include <math.h>
double AttackerSuccessProbability(double q, int z)
{
    double p = 1.0 - q;
    double lambda = z * (q / p);
    double sum = 1.0;
    int i, k;
    for (k = 0; k <= z; k++)
    {
        double poisson = exp(-lambda);
        for (i = 1; i <= k; i++)
            poisson *= lambda / i;
        sum -= poisson * (1 - pow(q / p, z - k));
    }
    return sum;
}

结论就是当收款人被攻击的交易后面增加了z个区块后，攻击者的虚假链仍然能赶上诚实链的概率随着 z 的增长呈指数级下降。

14.总结

论文最后一章，总结。

We have proposed a system for electronic transactions without relying on trust.

中本聪说我们提出了一种不依赖信任的电子交易系统。

We started with the usual framework of coins made from digital signatures, which provides strong control of ownership, but is incomplete without a way to prevent double-spending.

参考了通用的数字签名货币体系，这种体系虽然提供了强有力的所有权控制，但是由于缺乏防止双重支付的方法而不够完善。

To solve this, we proposed a peer-to-peer network using proof-of-work to record a public history of transactions that quickly becomes computationally impractical for an attacker to change if honest nodes control a majority of CPU power.

为了解决这个问题，中本聪提出了工作量证明机制，并在点对点网络中记录公开的交易数据。只要诚实的节点掌控大多数CPU算力，对于攻击者来说，交易历史在计算上几乎变得不可更改。

Nodes work all at once with little coordination. They do not need to be identified, since messages are not routed to any particular place and only need to be delivered on a best effort basis. Nodes can leave and rejoin the network at will, accepting the proof-of-work chain as proof of what happened while they were gone.

中本聪认为这是一个结构简介而健壮的网络。节点只需要很少的协同就能同时工作。它们不需要被认证，因为信息不会发送到某个中心位置，只需要广泛传播。节点可以随时离开和重新加入网络。

They vote with their CPU power, expressing their acceptance of valid blocks by working on extending them and rejecting invalid blocks by refusing to work on them. Any needed rules and incentives can be enforced with this consensus mechanism

节点使用CPU算力来投票，通过努力延长有效区块来表达接受，通过拒绝在无效区块上工作来表达抵制。任何必要的规则和激励，都可以通过这个共识机制来加强。