Accelerator白皮书学习
理论依据：多级队列调度 multilevel queue scheduling
加速器的方法
关键思想:
1.收集几个不相干的事务为组，这里的不相关指的是不能访问相同的key或地址来更新账本这样它们不太容易在共识阶段与账本的多版本并发控制（MVCC）冲突
2.将分组的事务在一起而不是单独达成一致，这个方法的可行性在于事务之间不会对结果进行相互影响，实现方法为将组内事务合并到一个新的事务中去，将新事务提交到区块链网络以达成共识
使用这种方法，可以在单个共识阶段处理更多的事务，从而提高相同的读写性能RPS(每秒读取)和TPS(每秒事务)
Aggregator：聚合器
Transaction Segregation：事务隔离
图一显示了上面讨论的事务加速的事例场景。有三个事务，分别名为TX1、TX2、TX3每个事务都尝试使用不同的key（A、B、C）更新账本状态。它们之间没有关联，因为它们尝试使用不同的key更新值，所以在验证期间不会发生MVCC冲突。当Accelerator在指定时间内（例如1秒）接受到这些事务时，它将创建一个包含A、B和C的新事务，然后将事务提交给peer节点进行背书，在背书节点中，将新事务中的原始事务隔离，以便进行事务模拟，并将结果返回给Accelerator
Accelerator可以在客户端应用程序或服务器（如API网关服务器）中实现，这将被用来为用户提供方便的连接区块链的方法。server中的Accelerator（或者叫做服务器端加速）有利于吞吐量增强，因为它可以对来着不同客户端的大量事务进行加速。另一方面，在区块链网络中没有代理或者网管服务器的情况下，客户端加速是有益的。否则的话客户端app中需要额外的加速特性实现
实现
在当前版本中 Aggregator作为服务器端加速的独立服务器存在。它被插入到区块链应用程序和超级账本结构网络之间，如图2所示。
加速器由三个主要组件组成，分别是分类器、聚合器和路由器，使用Go编程语言编写，并使用HyperledgeFabric Go SDK。
Accelerator的基本任务：
对接受到的事务进行分类，主要依据为channel、chaincode、和function name的结合
聚合这些分类后的事务到一个新的事务中去。并将新事务经路由发送到区块链网络以获得共识
Accelerator的组件：
分类器 Classifier
应用程序请求的所有事务都传递给分类器，并根据事务类型进行分类。事务类型是由以下元素的组合确定的
Channel name
Chaincode name
Function name in the chaincode
聚合器 Aggregator
为每个事务类型分配一个专用队列，以收集分类事务。同一批中的分类事务应位于聚合器中的同一队列中，以便可以一起处理它们。聚合器根据以下条件决定应该等待或向路由器提交批处理事务：
- Number of transactions
- Total size of transactions in bytes
- Wait time of the first transaction
- Occurrence of key duplication (出现重复的key)
当满足通常作为策略提供的条件组合时，Aggregator会立即生成一个由队列中的所有事务组成的批处理事务。例如，我们可以定义一个策略，其中10表示要收集的事务数，1 MB表示总大小，1秒表示等待时间。如果满足其中任何一个条件，例如10个事务首先到达，则会生成一个批处理事务并将其刷新到路由器。
一个值得注意的条件是检查key重复的发生情况，它仅用于将不相关的事务组成批处理事务。此功能的一个实现示例是：
1）在聚合器中保存事务key的记录；
2）每当新的转换到达聚合器时，对记录中存在的键进行确认。如果发现任何重复，将使用队列中的事务创建新的批处理事务。在这种情况下，新到达的队列不包含在原批处理中，以避免冲突，然后占用另一个队列。此条件检查之前必须满足上述三个条件。
路由器 Router
路由器通过HyperledgeFabricSDK将聚合器生成的批处理事务发送到背书节点。然后，peer为批处理事务中的每个原始事务操作一个验证过程。因此，将给定批处理事务分离为单个事务的链码应该补充安装在背书节点中。最后，路由器将结果返回给请求批处理事务中包含的单个事务的每个应用程序。
测试
测试环境
测试用例
以下用例在此配置上运行。
1。简单查询：在单个peer上测量简单账本查询的技术用例。
2。简单打开：一个技术用例，用于测试对账本的简单更新。
3。小型银行查询：对账本中的银行帐户进行更“真实”的查询。
4。小型银行业务：对账本中的银行帐户进行更“真实”的更新。
5。小型银行冲突：对银行帐户进行更现实的更新，因为不同程度的帐户冲突需要重新提交交易。
简单查询
在Simple Query中，应用程序通过加速器调用链码，该代码将一组并发请求收集到单个批处理中(称为作业)。当批处理已满时(根据Aggregator)， Accelerator将使作业调用修改后的链码。chain代码修改将作业拆分成单独的调用，然后按正常方式执行。在Simple Query中，每次调用都使用getState() API按键查询账本中的单个状态。聚合后的响应返回给Accelerator, Accelerator将其分解并将查询结果通知应用程序
简单打开
在Simple Open中，处理过程作为简单查询进行，但链码调用涉及状态更改，而不是查询。具体来说，chaincode调用通过使用putstate（）API创建新状态来更新账本。聚合的响应将返回给加速器，加速器将创建一个事务，对其进行排序，并等待收到已提交的通知。在中，通知各个应用程序其事务已提交（或失败）。
小型银行使用案例
小型银行使用案例比简单的使用案例更现实；它们尝试对正在查询或在它们之间转移资金的银行账户的账本进行建模。最重要的是，在几乎同时处理重叠事务的情况下，可能会发生事务冲突。处理过程是简单的开放式的，但链码调用会受到世界状态冲突的影响。具体来说，每个链码调用都使用getState（）和putstate（）API更新账本，但是不同的事务有机会更新相同的状态。这种冲突将导致在订购事务后检测到无效的作业事务，从而导致作业中的所有事务失败。
测试结果
结果分析：
图5中的图形对应于加速器用例的两种基本形式——简单查询和简单打开。对于这两个用例，我们都可以看到X轴上的驱动事务速率如何影响Y轴上的实现事务速率；我们改变了驱动事务速率，并且实现的事务速率是因变量。在基本情况下，如果没有加速器，我们可以看到每秒1500个事务（TPS）的线性增长。在这个速率之上，无论驱动速率增加多少，都没有实现速率的增益。此时系统有效饱和。
同时，加速器的使用效果得到了显著改善。我们可以看到，对于高达1500 tps的驱动事务速率，实现的事务速率以与基本速率相同的方式增长。但是，有了加速器，我们能够线性地驱动查询事务，达到11000个的实现率。高于这个速率，事务开始排队，就像基本情况一样。对于简单查询，使用Accelerator代表了大约600%的改进。对于简单的打开，我们可以看到实现的比率比简单的查询要低，因为这个用例有更多的工作要做——事务需要执行、排序，然后在它们出现在账本上之前进行验证。在基本情况下，我们可以看到达到450 tps的线性增长，但在这一点之后，随着系统变得饱和，实现率再次开始平稳。
同样，加速器的效果也得到了显著改善。我们可以看到，接近线性增长，达到了5000 tps的交易率，这代表了1000%的改进。这甚至比查询更好；使用加速器对更新样式事务比查询样式事务更有利。
图6.7中的图表对应于更真实的用例版本——smallbank查询和smallbank操作。对于smallbank用例，我们可以看到与简单用例非常相似的行为。对于这些更真实的用例，加速器在吞吐量上有显著的不同。改善率分别为300%和600%。我们继续看到，使用加速器对更新样式事务比查询样式事务更有利，尽管两者都得到了显著的改进。
然而，当引入冲突时，与小型银行用例的最大区别是显而易见的，下面的图表对应于包含冲突的更真实的账本更新用例版本。第一个图与smallbank操作相同，但自然会发生冲突。高达3000 tps，碰撞不会以任何显著的速率发生，因此实现的事务速率遵循与smallbank操作相同的轨迹。然而，高于这个速率，冲突开始发生并增加，从而影响吞吐量。我们看到，当驱动速度增加时，实现速度与不使用加速器时相同。
在第二个图中，使用3000 tps的固定驱动速率，碰撞速率变化。图中显示了提高碰撞率对实现的TPS和Y轴上的延迟的影响。我们可以看到，随着冲突率的增加，事务率下降，延迟增加。
总之，smallbank冲突用例和上面的两张图显示，一旦冲突率达到10%左右，加速器的好处就会消失。这强化了这样一个事实：为了让加速器发挥最佳作用，事务应该彼此独立。
适用场景推荐
物联网
物联网设备和/或传感器应用程序的简单示例表示一类应用程序，这些应用程序具有特别适合加速器的特性。也就是说，物联网应用程序
（1）由于交易量可能非常大而需要高吞吐量，
（2）同时由于交易独立性特别适合加速。
物联网应用通常从大量独立设备收集数据和事务，每个设备通常具有自己的唯一标识符，每个设备可能定期生成时间序列数据或独立传感器读数，这些数据不可能与其他设备的数据相关，由于不同数据特性。因此，通常可以将每个事务记录在一个单独的、唯一的键中，这反过来导致相关数据发生的可能性非常低（例如，试图在几乎相同的时间用相同的地址或键更新数据的事务）。在这种情况下，加速器可以聚合许多事务，而不期望事务之间发生冲突。客户端加速方案可用于物联网接入点。
金融服务
作为第二类应用程序，我们从金融服务领域中选择了一个示例应用程序场景，其中事务相关性和可能的更新冲突更为可能。这种情况下，个人银行账户持有人发送的转账交易可能具有许多相关性。因为有可能并且在某些情况下，甚至可能有许多事务与特定帐户关联，所以更可能遇到事务更新冲突，这些冲突试图同时更新同一key。这种冲突情况会使加速器的应用效率降低，正如我们将要说明的那样。但是，除非在几乎相同的时间生成具有更高相关性的事务，即在相同的块生成周期内（例如1秒），否则仍可以预期加速器的好处。服务器端加速可能是合适的。在这一类别中的大多数实际场景中，虽然冲突和并发更新是可能的，但它们通常会在较长的时间内传播，因此使用加速器仍然非常合适。
不适用的场景
加速器可能不太适用于许多同时并发事务试图用相同key更新极少数地址的情况。在这种情况下，同一key的许多相互依赖的并发更新可能会导致潜在的许多更新冲突，从而导致加速器性能大幅下降，从而使其使用变得不适用。此类场景可能包括许多用户或区块链客户希望更新极少量地址或具有相同键值的数据的应用程序。例如，该方案可能包括一些公共账户上的金融数据交换（例如，一些证券交易方案），以处理大量客户账户的许多并发请求（例如，需要记录、净额结算或结算大量证券交易）。就一小部分账户而言）。在这种情况下，一次聚合的事务数（即“非冲突的事务”）将非常小，以避免冲突。这意味着在这种情况下，加速收益将变得极小或者为零。
问题点/挑战
当前的加速器方法存在一些挑战。它们可以通过与Hyperledger结构更紧密地集成来克服，但正如目前所实施的，它们代表了采用它的局限性。这些小节将解释这些挑战，并讨论如何克服这些挑战。
Transaction “blurring”
交易“模糊” 应用程序提交给加速器的交易不是出现在账本上的交易。相反，账本包含多个已“模糊”在一起的交易。这是因为加速器将事务阻塞到作业中，而实际提交的事务是作业中所有单个事务的总和。这给可审计性带来了挑战，因为用户无法查看账本并识别他们提交的交易。这使得应用程序、管理员和审计人员很难将实际提交的交易与出现在账本上的交易联系起来。考虑到区块链作为不可变交易日志的目的和价值，这是一个重大问题。
Transaction proposal “mis - signing”
没有加速器的交易建议“错误签名”，由应用程序提交的交易由它和执行它的peer节点签名，这些签名在交易中保留，因为它记录在账本中。当使用加速器时，出现在账本上的事务是事务集合（一个作业）的结果，并且是加速器和peer节点签名的聚合事务。这意味着，出现在账本上的交易不是由提交的申请签署的，而且鉴于区块链作为商定交易的真实记录的目的和价值，这再次对当前的实施提出了重大挑战。
User Chaincode Wrapper
用户链代码包装器虽然是一个相当机械的过程，但链代码开发人员必须编写一个链代码包装器来将作业反阻塞到其单个事务中，然后分别执行这些事务以生成聚合事务响应。这是一个额外的开发任务，需要重新安装和重新实例化链代码。正如下面所讨论的，这将是一个相对简单的功能，可以嵌入到织物中。
Non - standard APIs
最后，加速器为应用程序提供的API只是基于GRPC的，与常规的SDK编程语言有很大的不同。这意味着当前使用JavaScript、Java或GangangSDK的应用程序必须改变以利用加速器。同样，这将是内置到结构中的一个相对简单的特性。
事务模糊、事务错误签名、用户链代码包装器和非标准API都可以通过使HyperledgeFabric了解作业的概念来克服。形成网络的peer节点和orderer节点可以将作业视为事务的集合，并在执行、订购和验证时相应地处理它们，确保保留事务建议和响应签名。这样，聚合的好处就可以在没有这些缺点的情况下得到。
无法克服的事务冲突；需要本文中未讨论的其他技术来缓解此问题。
总结
适用性
加速器在数据相互关联性较低的情况下（例如，来自大量物联网传感器/边缘设备的数据，因为它们主要生成零星数据）每秒事务数方面提供了改进的性能。当涉及到此类事务的整个数量时，较大的数据量将导致更好的性能，因为加速器的工作方式是聚合到足够数量的事务并批量提交它们。也就是说，根据Accelerator支持的特定业务用例或场景，其预期的性能优势将有所不同。因此，建议根据这些性能特点和实验测试结果考虑其适用性，以获得更精确的TPS。
适应性
加速器可以根据在给定时间内应该处理的交易数量来适应整个区块链网络条件。例如，如果加速器作为输入接收的事务数越来越少，则最好减小聚合器的阀值大小，即聚合的事务数，以减少由等待时间条件引起的额外事务延迟[6]。聚合器中的副本。同时，如果加速器处理事务的时间越来越长，则需要增加阀值大小以最大化TPS。为了增强这一能力，有必要考虑开发以下章节中描述的其他加速器监控和分析组件。
监控
通过对加速器状态数据的监控，可以最大限度地提高其适应性。它收集与加速器相关的系统信息，例如：
在特定时间内提交了多少事务
正确提交了多少事务
多少批处理事务失败
达成共识并获得最终结果需要多长时间
整个计算和网络资源消耗等
此信息不仅在系统操作员检查系统运行状况时有用，而且在以下段落中描述的加速器分析决定何时应增大或减小阀值大小，甚至何时应转动时也有用。打开或关闭加速器。
分析
基于加速器监控收集的信息，分析可以为加速器提供更深入的适应能力。通过分析与事务处理相关的状态，如入站和出站事务的数量以及它们在时间上的发生分布，加速器分析可以建议最佳参数，如动态阀值大小，以提高效率。Accelerator Analytics是一个组件，用户和开发人员可以在其中为特定的用例构建适当的模型，并且可以加载这些模型。与此同时，加速器将具有处理程序机制，以与加速器监控和加速器分析进行交互。从这个意义上说，一个由监视和分析两方面补充的加速器将具有动态适应能力，这可以减少事务延迟，同时提高事务吞吐量性能。
写在最后
三星SDS和IBM已经集中开发和评估了加速器，并制定了与开源社区合作的路线图。加速器由三个主要和一个辅助组件组成：分类器、聚合器、路由器和安装在认可对等中的链代码。所有组成部分的工作都是增加TPS，以将批量交易中的不相关交易捆绑在一起，并将其提交给Hyperledger Fabric网络，从而减少所需的背书程序总数。通过在Hyperledger Fabric网络前面部署加速器并连接到对等节点，我们在这个阶段成功地开发了加速器，而没有对Hyperledger Fabric进行任何修改。根据我们的评估和评估，Accelerator在IBM云测试环境中的性能可以达到10x TPS。根据其设计，加速器可以很容易地插入现有的基于超级账本结构的区块链网络，我们建议超级账本结构的当前用户在“创新”阶段（https://github.com/nexleger/accelerator）试用它
加速器的性能受数据和事务特性的影响。如果它们是强相关的，并且相关性几乎同时发生，那么TPS的吞吐量增益将不会高达10倍。例如，高频交易系统不容易期望获得最佳的性能优势。一个适应性更强的用例是事务不相关或相关但偶尔发生的用例。示例可能不仅包括物联网场景，还包括金融服务，如评估部分所示的小型银行业务。在这种用例中，加速器能够显示出最佳的性能改进。