Zhuang's Diary

人工智能生成的图像每天都变得越来越流行。 但我们如何才能更好地识别它们，尤其是当它们看起来如此逼真时？

1. SynthID

产品介绍 - https://www.deepmind.com/synthid
产品博客 - https://www.deepmind.com/blog/identifying-ai-generated-images-with-synthid
SynthID 正在使用 Imagen 向 Vertex AI 客户发布，Imagen 是GCP最新的文本到图像模型之一，使用输入文本创建逼真的图像。
通过这个工具，用户可以将难以察觉的数字水印嵌入到人工智能生成的图像中，并识别 Imagen 是否用于生成图像，甚至是图像的一部分。
SynthID 由 Google DeepMind 开发，并与 Google Research 合作完善。SynthID 并不能万无一失地抵御极端图像处理，但它确实提供了一种有前途的技术方法，使人们和组织能够负责任地使用人工智能生成的内容。该工具还可以与音频、视频和文本等图像之外的其他人工智能模型和模式一起发展。
传统水印不足以识别人工智能生成的图像，因为它们通常像图像上的图章一样应用，并且很容易被编辑掉。例如，可以使用基本编辑技术剪掉图像角落中发现的离散水印。
在图像处理的不可察觉性和鲁棒性之间找到适当的平衡是很困难的。高度可见的水印通常作为带有名称或徽标的图层添加在图像顶部，也给创意或商业目的带来了审美挑战。同样，一些以前开发的难以察觉的水印可能会通过简单的编辑技术（例如调整大小）丢失。
SynthID 不会影响图像质量，并且即使在添加滤镜、更改颜色以及使用各种有损压缩方案（最常用于 JPEG）进行保存等修改之后，水印仍可被检测到。
SynthID 使用两种深度学习模型（用于水印和识别），这两种模型已在不同的图像集上一起进行训练。 组合模型针对一系列目标进行了优化，包括正确识别带水印的内容以及通过在视觉上将水印与原始内容对齐来提高不可察觉性。
SynthID 允许 Vertex AI 客户负责任地创建 AI 生成的图像并自信地识别它们。 虽然这项技术并不完美，但我们的内部测试表明它对于许多常见的图像处理来说是准确的。

• SynthID的组合方法：
  水印：SynthID 可以为 Imagen 生成的合成图像添加难以察觉的水印。‍
  识别：通过扫描图像中的数字水印，SynthID 可以评估 Imagen 创建图像的可能性。
  但是该软件没有开源，也没有具体实现原理的介绍。其原理可能与 Stable Signature 一致，请继续阅读下文。

2. Stable Signature

开源代码 - https://github.com/facebookresearch/stable_signature
项目论文 - https://arxiv.org/abs/2303.15435
Official implementation of the paper “The Stable Signature Rooting Watermarks in Latent Diffusion Models”。在本论文中，作者提出了一种稳定签名的策略，该策略结合了图像水印和潜在扩散模型，以确保生成图像建模的负责任部署。该方法可以快速微调图像生成器的潜在解码器，以在所有生成的图像中隐藏一个不可见的水印，以供未来检测和识别。
实现的能力和 SynthID 项目的描述是一样一样的。
具体实现方法大体有下面3个步骤（取于论文）：

思考问题：

• 如果 hacker 通过拷贝屏幕的方式复制图片，如何能够防止，杜绝，或者得到惩罚呢？
• 经过加密的图片，质量会发生些微的损失。如 Stable Signature 论文所讲，根据经验，在不影响图像质量的情况下，显着降低位精度是很困难的：在纯化过程中开始出现伪影。如何保护图片质量，也是进一步的问题。chatPDF回答：在本论文中，作者提出了一种权衡图像质量和水印鲁棒性的方法，可以通过调整感知损失的权重来实现。较高的感知损失权重会导致更接近原始图像的图像，但提取的水印的位准确性会降低。因此，可以根据具体需求来选择权衡图像质量和水印鲁棒性的方法。
• 实验和方法的成本很高，尽管比其他计算机视觉领域要低几个数量级。 我们粗略估计用于运行所有实验的总 GPU 天数为 2000，即 ≈ 50000 GPU 小时。 这相当于 10 吨二氧化碳当量的总排放量。
• 如此方法，引申至3D模型，动画，视频，是否可以重用，目前看还需要思考。

由于供应商系统的幂等性服务有bug，经过一番争执，终于说服了对方。现将经由记录如下。

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

┌─────────┐      ┌────────────┐     ┌────────────┐
│  客户端  │  ┌──►│  幂等性服务 │  ┌──►│  数据存储   │
└─────────┘  │   └────────────┘  │  └────────────┘
             │                   │
             │                   │
             │   ┌───────────┐   │
             ├──►│ 请求处理   │───┤
             │   └───────────┘   │
             │                   │
             │                   │
             │   ┌───────────┐   │
             ├──►│  检查状态  │───┤
             │   └───────────┘   │
             │                   │
             │                   │
             │   ┌───────────┐   │
             ├──►│ 执行操作   │───┤
             │   └───────────┘   │
             │                   │
             │                   │
             │   ┌───────────┐   │
             ├──►│ 更新状态   │───┤
             │   └───────────┘   │
             │                   │
             └───────────────────┘

1. 客户端： 这是发起请求的外部实体，可能是用户、其他服务或应用程序。
2. 幂等性服务： 这是幂等性服务的核心组件，负责接收和处理来自客户端的请求。
3. 数据存储： 数据存储组件用于存储已处理请求的唯一标识符，以及可能需要的其他相关数据。这可以是数据库、缓存或文件系统等。
4. 请求处理： 请求处理模块负责解析和验证请求，包括提取唯一标识符和其他请求参数。
5. 检查状态： 在处理请求之前，服务会检查请求的状态，以确保请求之前未被处理过。这一步骤通常涉及检查唯一标识符是否在数据存储中存在。
6. 执行操作： 执行操作模块负责实际执行请求所需的操作。这可能包括创建订单、更新资源、执行业务逻辑等。
7. 更新状态： 更新状态模块负责在请求处理成功后，将请求的唯一标识符添加到数据存储中，以标记该请求已被处理。

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
45
46
47
48
49
50
51
52
53
54
55

package main

import (
    "fmt"
    "net/http"
    "sync"
)

// 数据存储：使用映射来存储已处理请求的唯一标识符
var processedRequests = make(map[string]bool)
var mutex = &sync.Mutex{}

// 处理HTTP请求的处理程序函数
func handleRequest(w http.ResponseWriter, r *http.Request) {
    // 从请求中获取唯一标识符
    requestID := r.Header.Get("Request-ID")
    // 使用互斥锁保护共享数据
    mutex.Lock()
    defer mutex.Unlock()
    // 检查请求是否已经处理过
    if processedRequests[requestID] {
        // 如果已处理过，返回已处理的响应
        w.WriteHeader(http.StatusOK)
        fmt.Fprintf(w, "Request already processed\n")
    } else {
        // 如果未处理过，执行请求操作
        // 注意：在实际应用中，要确保请求操作是幂等的
        result := performRequestOperation(r)
        // 更新已处理请求的映射
        processedRequests[requestID] = true
        // 返回操作结果
        if result {
            w.WriteHeader(http.StatusOK)
            fmt.Fprintf(w, "Request processed successfully\n")
        } else {
            w.WriteHeader(http.StatusInternalServerError)
            fmt.Fprintf(w, "Request processing failed\n")
        }
    }
}

// 执行请求操作的函数
func performRequestOperation(r *http.Request) bool {
    // 在这里执行实际的请求操作，确保操作是幂等的
    // 例如，创建订单、更新资源、执行业务逻辑等
    // 如果操作成功，返回true；否则返回false
    return true
}

func main() {
    // 创建HTTP服务器
    http.HandleFunc("/process", handleRequest)
    http.ListenAndServe(":8080", nil)
}

Bug针对上述代码中的 result ，如果是 false 的情况下，该 Token 的请求处理结果应该记录为 false， 即 processedRequests[requestID] = false。
本例子中，供应商的错误在哪里呢？供应商系统的幂等服务，在24小时内，如果出现错误，服务不会重新执行，而是认为已经处理完成，继续抛出同样的 error message。实在不能够接受。

1. 背景

BloombergGPT是布隆伯格2023年3月30日公开在arXiv的一篇文章——BloombergGPT: A Large Language Model for Finance中涉及到的语言模型，也是金融领域第一个公开发表文章的大语言模型（以下简称“LLM”）。

2. 要点

• BloombergGPT是Bloomberg训练出来的金融大语言模型（LLM for Finance）
• 模型参数量为500亿，使用了包含3630亿token的金融领域数据集以及3450亿token的通用数据集
• 隐藏层维度为7680，多头的头数为40
• 模型采用Unigram tokenizer，AdamW优化器
• 模型在64个AWS的p4d.24xlarge实例上训练了53天，其中每个p4d.24xlarge实例包含了8块40GB的A100GPU
• 对BloombergGPT的评估包含了两部分：金融领域评估与通用领域评估
• 评估对比的其他大语言模型有GPT-NeoX、OPT、BLOOM、GPT-3
• 在金融领域任务上，BloombergGPT综合表现最好；在通用任务上，BloombergGPT的综合得分同样优于相同参数量级的其他模型，并且在某些任务上的得分要高于参数量更大的模型
• BloombergGPT模型在金融领域取得好效果的同时，并没有以牺牲模型通用能力为代价
• 对模型定性评估的结果表明，BloombergGPT可以提高工作效率
• 出于安全性的考虑，BloogbergGPT模型不会被公开，但是模型训练和评估的相关经验和思考会被分享出来
• 作者认为，对模型效果提升促进最大的三个因素（按影响从高到低排序）分别为精心清洗的数据集、合理的tokenizer、流行的模型结构

文章的主要贡献在以下几点：

• 混合数据集训练方法不仅可以在特定任务上表现出色，也可以在一般NLP基准测试上表现良好
• 不同于常见的网络爬取数据，本文的数据包含了巨量的可信来源的精心清洗的数据
• 不仅包含了模型在基准测试集上的评估结果，也包含了在Bloomberg内部任务上的评估结果
• 在超过7000亿个token的语料库中的5690亿个token上训练出一个500亿参数的LLM
• 使用Unigram模型而非常用的基于贪心合并的子词标记器进行tokenize，方便在推理时进行更智能的标记化
• 借鉴BLOOM的训练大模型方法，同时也将自己自己在训练BloombergGPT中的经验分享

3.数据集

BloombergGPT是一个有500亿参数、基于BLOOM模型的LLM，过程中采用了一种兼具通用能力和特定领域的方法。
作者首先构建了FinPile——一个包含了新闻、档案、网络爬取的新闻稿件、英文财经文档等英文金融文档的金融领域数据集，同时也采用了通用的数据集。

金融领域数据集

金融领域数据集共包含了3630亿个token，占总数据集token量的54.2%，具体由以下几个部分构成：

• 金融领域相关网页，2980亿token，占比42.01%
• 金融领域知名新闻源，380亿token，占比5.31%
• 公司财报，140亿token，占比2.04%
• 金融相关公司的出版物，90亿token，占比1.21%
• bloomberg，50亿token，占比0.7%

因为包含一部分收费和私有数据，所以这份数据集不会被公开，但是文章中公开了模型训练方法。

通用数据集

**通用数据集共包含了3450亿个token，占总数据集token量的48.73%**，具体分为如下几个部分：

• The Pile数据集，1840亿token，占比25.9%
• C4数据集，1380亿token，占比19.48%
• Wikipedia数据集，240亿token，占比3.35%

数据集使用Unigram tokenizer对原始文本进行tokenize。具体处理时，作者这了两点改进（具体内容可参考原论文《2.3Tokenization》）：

• 在pretokenization这一步，将数字视为单个token，并且允许词组的存在，以提高信息密度减少句子长度
• 使用分治的思想优化Unigram tokenizer在大数据集上的实现，并对最终词表大小控制在13万这个数量级上

4.模型

模型结构

模型基于BLOOM模型的自回归结构，具体包含了70层transformer decoder。
另外一些细节如下（详见《3.1 Architecture》）：

• 前馈层（FFN）中的非线性函数采用GELU
• 位置编码采用ALiBi编码
• 模型在第一层多了一个layer normalization

模型尺度

这一部分，作者先有了算力预算（40G内存A100共130万GPU小时），并且给中间checkpoint存储留出了约25%的时间预算。
根据Chinchilla scaling laws，计算出模型的参数和需要的数据量大小——模型参数为500亿，token数据量为11000+亿。
考虑到金融领域token数量要占总token数量的50%以上，而且目前的数据暂时无法再进行扩充，最终模型参数量选择为500亿，token数据量为7000+亿。
另一方面，隐藏层维度D也可以根据decoder的层数计算出来，这里经过计算隐藏层维度为7680，多头的头数为40。

训练配置

这一部分原始论文写的比较详细，具体见《3.3 Training Configuration》，这里简单摘要如下：

• 作者在每篇文档的最后添加了特殊标记<|endoftext|>，模型训练时选取的句子长度为2048token
• 训练时采用的优化方法是AdamW，beta1、beta2、weight decay取值分别为0.9、0.95、0.1，初始学习率为6e-5，采用cosine衰减、线性warmup方式
• 模型参数随机初始化为均值0、标准差0.006588的正态分布，并对MLP的第二层和注意力层输出进行缩放
• 关于训练的不稳定性，文章中没有描述训练BloombergGPT时采用的方法，只是介绍了相关进展
• 关于计算使用到的硬件，使用了64个AWS的p4d.24xlarge实例，每个p4d.24xlarge实例包含了8块40GB的A100GPU

大规模优化采用的方法

这一部分中，作者描述了具体优化时采用的方法：ZeRO优化、MiCS、Activation Checkpointing、混合精度训练（Mixed Precision Training）、内核融合（fused kernels）。
具体见《3.4 Large-scale Optimization》
经过上述优化，上述硬件的平均算力水平达到了102TFLOPs，训练一步需要32.5秒。

训练过程

文章中记录模型共训练了139,200步，进行了约0.8个epoch，训练了53天。
一个epoch都没有训练完的原因是这时验证集上的损失函数已经不再继续下降了。
具体训练过程如下：

• 初始训练的batch size大小为1024，warm-up过程持续了7200步，随后作者将batch size修改为2048。
• 115,500步之后，验证集上的损失不再下降，然后作者将学习率缩小为原始的2/3；
• 129,900步之后，学习率缩小为之前的1/2，同时增加dropout
• 137,100步之后，学习率再次缩小为之前的1/2
• 最终，训练在146,000步结束。作者选取139,200这一步的模型最为最终使用的模型

这里推荐阅读原始文章3.3节与3.4节中关于训练方法的描述，对于大模型训练有一定的参考意义。

5.评估

文章中对BloombergGPT的评估分成了两部分：金融领域任务与通用任务。这样做的目的也比较直观，就是验证在特定领域预训练后的模型能够在特定领域表现好，同时在通用领域的表现也不会差太多这一观点。
同时，文章对比了BloombergGPT、GPT-NeoX、OPT、BLOOM、GPT-3在不同任务上的表现。注意，这里因为GPT-3模型无法获取，故仅在部分通用任务上进行了评测。
作者对每一个模型均独立进行了评测，并且在每一个任务中使用相同的标准prompt、相同的样例、不使用任务描述和任何CoT prompt，以保证评测结果的公平性。
对于有多个答案的任务，文章中采用了**基于似然的分类方法（likelihood-based classification）进行评估；对于其他任务，文章采用贪心解码（greedy decoding）的方式进行评估。

holdout loss

作者首先在FinPile数据集预留的部分样本上对各个模型进行了bits per byte的评估。
bits per byte指标是评估语言模型的一种常见指标，类似于perplexity，取值越小，模型越好。具体计算方法可见How to compute bits per character (BPC)?
BloombergGPT在金融语料上的bits per byte均好于其他模型，并且在财报（Filings）这个类别上表现尤其突出。这个结果也符合预期。否则可能就没有后面任务对比的必要了。
文章又将金融领域任务分成了外部任务和Bloomberg内部任务。在每个任务上，作者除了评估模型在任务上的表现，还评估了同一任务下不同模型生成结果之间两两比较的胜率（WR）。

外部任务

外部任务主要如下：

• ConvFinQA，标普500收益报告问答推理
• FiQA SA，金融新闻和微博客标题基于方面的情感三分类（正负中）
• FPB，金融新闻句子级别情感三分类（正负中）
• Headline，新闻标题在预定义标签下的二分类
• NER，信用风险评估数据的命名实体识别

BloombergGPT在上述5个任务中的4个都取得了最好效果，在另外一个取得了第二名；并且在模型两两结果对比的胜率最高，同时在ConvFinQA这个任务上遥遥领先。

Bloomberg内部任务之情感分析

这个任务中的情感分析均为基于方面的情感三分类（aspect-specific sentiment），数据集的内容通过任务名称就可以略知一二。
BloombergGPT在上述4个数据集上的表现均大幅领先于其他模型。

探索性任务：NER

注意，这里的NER只涉及到ORG、PER、LOC这三类实体。
同时探索性任务NER+NED是指识别出实体后再将实体链接到上市公司的股票简称。比如“AAPL announced that they will stop using Intel chips in future products.” 这句话NER的结果是“AAPL, Intel”，NER+NED的结果是 “AAPL, INTC”。
这两类任务涉及到的数据集包括了7个数据集，分别为BN（Bloomberg BN wire上内容）、BFW（Bloomberg First Word上的内容）、Filings（财报内容）、Headlines（Bloomberg news内容）、Premium（Bloogberg收录 的第三方新闻内容）、Transcripts（公司新闻发布会的文字记录）、Social Media。
最终，NER任务下，BloombergGPT仅在Headlines这一个数据集上得分最高；但在NER+NED任务下，BloombergGPT在除了Social Media任务的其他任务上均得分第一。

通用任务

文章在通用任务上做了相当多的对比，这里仅对任务类型和结果做简要描述，详细内容见文章中的5.4~5.7节。
作者在BIG-bench Hard（BIG-bench的一个子集，仅包含目前模型表现无法超过人类的任务）、常识测试（不提供任何背景知识，仅可以训练时使用的数据）、阅读理解、语言学（消歧、语法识别、蕴含判别等）等任务上进行了测试。
在BIG-bench Hard任务上，BloombergGPT得分低于参数量更大的PaLM和BLOOM，但是与参数规模类似的GPT-NeoX或OPT66B相比，BloombergGPT的性能更接近BLOOM，这说明开发金融专用的大语言模型并没有明显牺牲其通用能力。
在常识测试任务中，BloombergGPT在1个任务上取得了第一名，在其余3个任务上取得了第二名（这里未考虑GPT-3）。
在阅读理解任务上，GPT-3在所有任务上排名第一，BloombergGPT在5/6个任务上排名第二，且得分远高于BLOOM模型。
在语言学任务上，GPT-3在综合排名第一，BloombergGPT综合排名第二，且综合得分高于BLOOM模型。

评测总结

在金融领域任务上，BloombergGPT综合表现最好；
在通用任务上，BloombergGPT的综合得分优于相同参数量级的其他模型，并且在某些任务上的得分要高于参数量更大的模型。
这都说明，开发金融专用的大语言模型在金融领域取得好效果的同时，并没有以牺牲模型通用能力为代价。
这一结论也可以给我们一个启示，在其他特定领域，我们也可以开发专用的大语言模型。

定性评估

作者在文章的第6章还展示了对BloombergGPT定性评估的例子，以展示模型在专业领域带来的促进作用。
这些列子包括：

• BQL（Bloomberg查询语言）生成，即使用自然语言完成Bloomberg数据库查询，类似NL2SQL
• 新闻标题提示，辅助记者生成新闻短标题
• 金融问答

6.道德伦理、限制与研究意义

这一章没有太多值得写的，主要就是强调了目前大语言模型可能会生成有害的、有偏见的内容，并且可能存在prompt注入导致信息泄露的风险，Bloomberg在使用大语言模型前后都会做好风控，保证生成内容的准确性。
同时，BloogbergGPT模型不会被公开，但是模型训练和评估的相关经验和思考会被分享出来。

7.总结与展望

文章提出了BloombergGPT——一个金融领域顶级的LLM，并且在训练特定领域大语言模型做出了如下贡献：

• 使用领域数据和通用数据的训练方式可以让模型在这两个方面得到平衡的结果
• 模型参数量参考了Chinchilla scaling laws
• 公布了相关训练细节

下一步，作者们会在以下方向继续研究：

• 金融领域的fine-tuning
• 使用更无害和更无偏见的语言
• 研究tokenization方法对模型结果的影响

最后，作者把模型取得目前效果归结于以下三个因素（按影响从高到低排序）：

• 精心清洗的内部数据集
• tokenizer的选择
• 流行的模型结构

1. 改变神经网络的复杂程度: 从最简单的单层神经网络模型 AutoRec ( 自编码器推荐)，到经典的深度神经网络结构 Deep Crossing(深度特征交叉)，其主 要的进化方式在于 增加了深度神经网络的层数和结构复杂度。

2. 改变特征交叉方式: 这类模型的主要改变在于丰富了深度学习网络中特征交叉的方式。例如，改变了用户向量和物品向量互操作方式的 NeUralCF( Neural Collaborative Filtering,神经网络协同过滤)，定义了多种特征向量交叉操作的 PNN ( Product-based Neural Network, 基于积操作的神经网络 )模型。

3. 组合模型: 这类模型主要是指 Wide&Deep 模型及其后续变种 Deep&Cross,DeepFM等，其思路是通过组合两种不同特点、优势互补的深度学 习网络，提升模型的综合能力。

4. FM 模型的深度学习演化版本: 传统推荐模型 FM 在深度学习时代有了 诸多后续版本，其中包括 NFM ( Neural Factorization Machine, 神经网络因子分解机 )、FNN ( Factorization-machine supported Neural Network, 基于因子分解机支持的神经网络)、AFM(Attention neural Factorization Machine, 注意力因子分解机)等，它们对 FM 的改进方向各不相同。例如，NFM 主要使用神经网络提升 FM 二阶部分的特征交叉能力，AFM 是引入了注意力机制的 FM 模型，FNN 利用 FM 的结果进行网络初始化。

5. 注意力机制与推荐模型的结合: 这类模型主要是将“注意力机制”应用于深度学习推荐模型中，主要包括结合了 FM 与注意力机制的 AFM 和引入了注 意力机制的 CTR 预估模型 DIN ( Deep Interest Network, 深度兴趣网络)。

6. 序列模型与推荐模型的结合: 这类模型的特点是使用序列模型模拟用户行为或用户兴趣的演化趋势，代表模型是 DIEN( Deep Interest Evolution Network, 深度兴趣进化网络 )。

7. 强化学习与推荐模型的结合: 这类模型将强化学习应用于推荐领域，强调模型的在线学习和实时更新，其代表模型是 DRN( Deep Reinforcement Learning Network, 深度强化学习网络 )。

— 摘录于《深度学习推荐模型》

1. PBFT https://github.com/yeasy/blockchain_guide/blob/master/evaluation/hyperledger.md

Hyperledger Fabric v0.6 - PBFT 性能评测

环境配置

每个集群启动后等待 10s 以上，待状态稳定。

仅测试单客户端、单服务端的连接性能情况。

评测指标

一般评测系统性能指标包括吞吐量（throughput）和延迟（latency）。对于区块链平台系统来说，实际交易延迟包括客户端到系统延迟（往往经过互联网），再加上系统处理反馈延迟（跟不同 consensus 算法关系很大，跟集群之间互联系统关系也很大）。

本次测试仅给出大家最为关注的交易吞吐量（tps）。

query 交易

pbft:classic

pbft:batch

invoke 交易

pbft:classic

pbft:batch

PBFT结论

PBFT单客户端连接情况下，TPS 基本在 190 ~ 300 范围内。

============================================

2.tendermint https://www.inf.usi.ch/faculty/pedone/Paper/2021/srds2021a.pdf

我们使用 Tendermint 版本 0.33.8 和 Go 版本 1.15，使用默认配置。 内存池最多可存储5000笔交易，最大字节大小为1GB，块大小为20MB。 这些默认限制足以应付未完成交易的最大数量。两个都连接的最大发送和接收速率为 5000 KB/s，控制gossip通信的时间间隔是 100 毫秒。
我们在地理分布式环境中进行了实验，验证器节点均匀分布在各大洲的 16 个 AWS 区域中。另一个 AWS 实例托管 1 个以种子模式运行的非验证器节点和所有客户端。
我们将所有客户端托管在单个 AWS 服务器中，以将所有测量集中在一个位置。客户端在闭环中均匀地向验证器提交 1KB 交易。

图中比较了 Tendermint 在 16、32、64 和 128 个验证者规模下的性能。 我们并不期望通过增加验证器的数量来提高性能，因为消息复杂性和共识成本随着进程数量的增加而增加。 本次比较中使用了 128 个验证器的参考工作负载，在实验中的验证器之间均匀分配 1536 个客户端。 采用了第 VII-B 节中考虑的相同实验设置。图中，在相同的工作负载下，当我们将验证器数量增加一倍时，吞吐量会适度下降。

Tendermint结论

Tendermint 的 TPS 基本在 400 ~ 600 范围内。交易延时在2～4秒。

根据以上性能数据，可以在设计区块链系统时，预先分析得出系统综合来看，性能瓶颈到底在哪里。如，某些外部的SaaS服务，性能可能会低于上述区块链指标，从而拖累系统的整体性能。