本篇内容由UST DAO社区创作与长期更新维护，收藏订阅不迷路，也欢迎大家加入我们社区探讨财富密码。链接：

https://linktr.ee/ust_dao

目前公链问题很多，aptos就是为了来解决这些问题的。以可扩展性、安全性、可靠性以及可升级特性作为关键的设计原则。 经过350名以上开发工程师经过三年努力在共识、智能合约设计、系统安全以及性能跟去中心化等方面做了很多创新：

1. aptos 原生集成了更快更安全的move 语言。move prover[官方名词] 是一个正式的智能合约验证器，对合约常量和行为提供安全保障。

2. aptos 数据模型在key管理以及混合托管选项上提供了更高的灵活性，这个跟后面的事务前置透明度以及 实用轻量级客户端协议一起提供了更安全可靠的用户体验

3. 为了达到更高吞吐量以及低延迟，aptos综合了管道处理[想像下水在管道怎么流的，就是前一个结果为后一个执行作为输入]跟模块化处理在关键步骤的事务处理优点。让比如事务传播、块元数据排序、并行事务执行、批量存储以及账本验证的操作都并发操作。这样能够充分利用硬件资源，提供硬件资源利用效率

   【这点语言描述还是挺精准的，性能三要素就是吞吐量、延迟以及并发度。根据利泰定律，高吞吐跟低延迟这两个要素就能确定并发度。我们要么说一个软件性能高，这是很high level的说法，要么就要像这里说的，是高吞吐+低延迟，才能完整表述你是个高性能的东西。像国内软件行业比较喜欢说我是高并发来代表高性能，是很不准确的】

4. 跟其他并行执行引擎不同的是，aptos不需要通过知道前期数据来原子性的分割事务，它能对任意复杂事务进行原子操作，提供吞吐量，降低延迟，简化开发。【这里说的还是性能,准确定说算是对第三点的进一步解释】

5. aptos 模块化的架构设计为客户端的灵活度、频繁的优化以及快速升级提供了支持的可能。此外能为了快速部署一些新的技术创新以适应web3产品应用场景，aptos提供了内置链上变更管理协议。

   【总结，第1，2点都说得是安全性，包括move是一种合约友好的安全语言、数据模型搭配后面轻客户端协议以及一些新安全机制提供了更好的安全性。第5点属于一般性吧，略过。第3，4说的是性能，其实整个白皮书看下来这也是篇幅最多的部分。从软件工程角度来说能够这样的工程优化其实也算不错的。但是毕竟现在aptos已经被吹上天了，到处fomo这种天王级项目。这些工程领域的优化创新是不是感觉还不太够 ，毕竟你看near说是分片设计方向领头羊，solana是非分片领域第一个高性能的。aptos呢？接下来让我们看看aptos究竟有哪些技术亮点】

在web2世界里，很多中心化的公司通过各种不同的应用控制着用户数据的访问，特别是如google、亚马逊、苹果跟meta等大型公司。这些公司对不同用户场景通过特定优化的软件来提供基础设施，比如云服务即可以提供虚拟机出租，也可以直接出租裸硬件设备[就是没有安装云基础服务的硬件设备，类似你购买硬件服务器进行托管]。这样web2互联网才得以在如今轻松扩展至对上亿用户提供服务。但这需要我们普通用户完全信任这些中心化公司。 为了解决这种信任问题，web3应运而生。区块链作为底层基础设施跟web2中云服务一样提供支撑服务。 然而，尽管如今已经有很多区块链[各种公链]，但是web3发展还在初期。现在的这些公链还存在不少问题，比如不可靠[估计指竞争对手老是宕机]，高gas费用，吞吐量限制以及常见的因为各种安全漏洞导致的资产丢失，不能提供实时响应[延迟高]。对比web2 的云服务设施，web3 公链还有很长一段路要走

【公链对标的是web2里面的云服务商，大家都知道的谷歌云、亚马逊云以及阿里云等。软件行业的人可能知道云可以划分为三层IAAS，PAAS以及SAAS，分别是

硬件基础设施即服务（指你可以在阿里云可以购买虚拟机，也可以购买裸机）；

平台即服务，这里主要是讲中间基础软件层，比如消息服务、数据存储服务等；

软件即服务，可以理解为大家能直接使用到的各种软件了，当然也包含基础一点的，比如专门只提供短信接口的短信服务。

那么到web3 公链里面来，我们还没有看到这么清晰的分层，当然对标产品也还是有的。但是大家可以想像下，虽然现在也是公链百家争鸣，但是整体发展对比web2 还处在很早期，公链还可以很多事情可以做，很多故事可以讲。】

atpos的愿景是构建一条能够为解决真实世界用户问题而赋能的去中心化生态系统并能被web3 广泛使用的区块链。我们的使用就是通过提供一个灵活的模块化的区块链架构来提升和推进区块链在可靠性、安全以及性能方面的发展 随着web3的发展，底层公链应该能像web2云服务一样支持频繁的无缝的用户无感知升级，让上层开发者跟用户不再老是担心底层问题，以便更加聚焦在上层服务跟使用上。 我们的技术团队都是有过在Diem 开发经验的，并且在此基础上，我们完成了两处大的升级：共识协议跟核心框架。而且升级后从没发生过宕机事件。当然在diem基础之上还有很多创新，比如在事务处理，去中心化以及网络治理方面。

【总结，aptos就是要跟web2中云服务商一样提供各种基础设施，除了说不宕机问题显然针对竞争对手外，倒没有过多强调跟目前竟对有啥不同。愿景宏观伟大】

aptos 区块链是由一系列 验证节点组成，这些验证节点使用拜占庭容错算法，pos共识机制处理用户事务。每个节点的共识投票权重是由它质押数量决定的 任何提交事务或者查询状态跟历史数据的都可以算是客户端。客户端可以选择下载跟验证验证节点验证过的数据。 全节点算是一种从验证节点或者其他全节点复制事务以及区块状态的客户端。 轻客户端只维护当前的验证节点，能够安全地从全节点查询部分区块状态数据。钱包就是这样一种轻客户端。

为了满足对安全，快速可靠以及可升级的web3 基础设施的广泛应用，aptos区块链构建在以如下的设计原则基础上：

1） 快速安全的执行以及简单的可审计性和可分析性智能合约编程Move语言

2） 通过批、管道化以及并行执行事务以达到极致的高吞吐跟低延迟[高性能]

3） Block-STM技术，能理论有效提升事务并行执行性能

4） 通过快速、质押权重验证节点集流转以及声誉追踪优化性能跟去中心化

5） 可升级性和可配置型作为最重要设计原则

6） 模块化设计

7） 在保留去中心化的同时具备吞吐量水平扩展能力，以及分片作为最重要的概念

【跟摘要里面说的差不多，无非就是强调下自己的一些特性。其中block-STM技术算是跟其他公链有显著不同以及在理论层面看来是性能提升至关重要的点。STM全称软件事务内存，是为了解决以锁机制并发编程里面缺点而诞生的机制概念。早在1987年即被提出，软件行业人可能了解的高性能akka语言就是基于此机制。Aptos在stm基础上结合区块链事务执行特点提出了在stm上改进版本block-stm，可以参考：https://medium.com/aptoslabs/block-stm-how-we-execute-over-160k-transactions-per-second-on-the-aptos-blockchain-3b003657e4ba】

Move是一种在安全性以及灵活性上有加强的合约编程语言。Aptos使用move的对象模型作为它的账本状态，使用move代码（模块）来编写规则。 Move语言生态包括编译器、虚拟机以及很多其他开发工具。[显然不是evm兼容的] Move在rust基础上加强了对资源的控制。Move 模块定义了每种资源的完整生命周期、存储以及访问模式，这种模式保证不会有双花或者代币消失的情况 而aptos团队又在原move基础上针对web3应用场景进行了增强。比如上面提到的细粒度资源控制。这样不仅有利于对事务并行化处理，而且也可以做到在访问跟变更数据时比较恒定的时间消耗。此外，aptos在存储上还支持了表的概念，使得同一个账户可以存储大量数据（比如很多NFT）

账本状态包括了链上所有账户。使用64位无符号整型记录系统已执行事务数量来表示账本状态的版本。所以任何人发起一笔交易，都会修改这个账本状态。

1. 事务 签名事务包含如下信息：  事务授权者  发送者地址  数据载体。就是发送内容  Gas价格  最大gas数量  顺序编号  过期时间  链id。

2. 事件 事件是在事务执行过程中产生的。比如转账交易中，分别产生发送事件跟接收事件。每个事件都有唯一的key用来查询。多个事件拥有同一个key就是事件流。 对于move开发者来说，通常需要把底层资源变更前的数据以及事务执行后的数据都放到事件中。

3. 账户 账号使用唯一的256位标识[实际过程中应该是使用16进制来表示。标识跟表示两码事]。新账户可以通过两种方式：create_account以及transfer 创建。 账户地址是通过对公钥以及一个签名标识符进行加密hash得到的 addr=H（vk,ssid）

4. Move 模块 Move 模块包括字节码以及过程。跟面向对象里面的类的概念类似。 是由账户地址唯一确定的，总是跟一个模块名称一起定于。 每个账户最多可以定义一个模块。

5. 资源 跟模块类似，在账户地址里面跟数据关联。通俗的可以里面资源就是数据类型。不过这里明确不是所有数据类型都是资源，需要具备key跟store 两种属性

6. 账本状态 从move 虚拟机脚本看，每个账户就是由一些列值跟KV 数据结构组成。这些数据结构被称为表实体，以BCS形式存储。[很底层的概念，这是数据在物理存储介质上的最终存储形式]。这种数据层级结构使得开发者能够有效的在一大堆账户上操作少部分的数据副本或者在小部分账号上存储一大堆数据。

   【没太理解到底是怎么样一种数据存储形式。看上去就是读快，因为kv存储。而且在连续（小部分账户）空间写数据也快】

   现在初期，aptos仅使用一个账本状态。但是随着后面用户增加跟技术发展，会采用分片形式进行扩展。

1. 事务可行性保护 签名一个事务意味着签名者认可了事务将被提交和执行。但有时候，用户也可能无意识或者没有考虑清楚风险就签名了。为了减少这种风险，aptos提供如下三种保护措施： 1） 同一发送者账号同一事务编号只能提交一次。 2） 区块时间以高精度跟频率推进。 3） 每个事务在每个链上都有唯一编号，防止测试网的事务在主网上重放。

2. 基于move语言的私钥管理 Aptos账户支持密钥轮换，从而避免私钥泄露、远程攻击以及未来可能的加密算法破解。此外用户也可以把轮换权限下放给其可信任的人，同时可以针对私钥应用场景进行策略配置。

3. 预签名事务透明 如今钱包在进行签名时提供的信息不多，导致用户资产被盗。Aptos为了解决这个问题，提出了事务预执行：就是在事务真正执行前，预先执行一遍把执行结果告诉用户。

   【比如签名approve for all，现在在签名之前，就告诉你你做完这个动作后，人家能进行转账操作，这样就可以避免小白不清楚approveforall的风险了。】

4. 实用轻客户端协议 依赖于TLS/SSL证书进行通信在区块链客户端跟服务器之间通信并不可靠。[区块链节点是开发式加入，不涉及共识层面写数据还是有作弊可能] Aptos通过提供状态证明跟轻客户端验证协议用于钱包和客户端来验证非可信第三方提供的数据的有效性。【这里的技术细节后面章节还会提到】

为了提高吞吐，增加并发以及降低工程复杂度，aptos 把事务处理分解为多个阶段。这种方式不仅极大提升了性能，而且使得aptos提供了在客户端跟验证节点之间的交互提供了一种新的模式。  当特定事务中包含一批持久化事务时会通知客户端。有效且持久化事务有可能被立即提交  当批量持久化事务完成排序时会通知客户端。这样为了降低确定事务输出的延迟，客户端可以选择在本地执行而不是等验证节点完成执行  客户端可以选择等待验证节点执行认证事务，然后执行状态同步

Aptos模块化设计主要解决开发跟发布效率问题，同时也有利于验证节点的水平扩展。

1.批处理

批处理是aptos每一个环节中最重要的性能优化。事务传播过程中验证节点把多个事务合并到一个批次，然后共识阶段又把这些批次合并到一个块中。 在执行、存储以及账本认证阶段也都是批处理模式。 批处理虽然产生了一定延迟，但是可以根据情况来分别配置。在一个去中心化网络中也可以做到根据市场需求来进行自动调节，同时还能避免无意识的DoS攻击。

2.持续事务传播

事务传播在aptos中跟共识过程解耦了。验证节点持续的流式化处理批量事务，充分利用网络带宽资源。 无限的持久化批量事务会触发DoS向量攻击导致验证节点的存储很快被用光从而宕机。为了防止这种情况，aptos给每个批次的事务分配了时间戳，这样每个验证节点就行有效进行垃圾回收。另外按验证节点为单位进行配额的机制也能保护在极端情况可能造成的存储空间耗尽问题，比如潜在的拜占庭攻击。在存储前也会对事务批次大小进行验证。最后，还有一些其他优化机制来去重跟缓存事务来减少存储消耗保证并行执行引擎的性能

【按照时间来进行垃圾回收在区块链中确实可行，但是如果存入的速率要大于垃圾回收的速率会怎么办？这里配额机制就起这个作用吗 ？达到一定预先配置的存储空间就不再接受新事务存储请求？】

3.块元数据排序

普遍认为共识层是区块链吞吐量跟延迟的主要瓶颈，所以aptos的关键创新之一就是把非协议相关的任务从共识阶段解耦出来。 Aptos使用了DiemBFT v4 版本，这是一种乐观拜占庭容错协议。大部分情况下共识只需要通过两次交互。同时也有一个leader机制，它会在一个窗口时间内对没有参与的验证节点降级，这样能把异常的验证节点对网络影响降到最低。

【白皮书里面剩余内容并没说明如何分配这个物理时间戳，仅描述了其使用场景。是否跟solana机制类似，由leader产生物理时间戳?】

4.并行事务执行

并行执行是区块链的一个重要目标。Aptos从数据模型和执行引擎两方面做了尝试

 并行数据模型 引入了一个新概念 delta writes 。它描述了对账户状态的修改，而不是修改后的状态。所以只要更新顺序对，事务就可以并行处理。

【web2中delta update比较多，这里的delta writes 其实我觉得也可以理解是一个delta update，只不过区块链数据是没有update这一说而已。比如第一个事务针对a (3) +1,第二个对a+2，那么delta write 就可以理解为，第一个事务3+1=4，第二个事务不再是在3基础上+2，而是在3+1基础上+2.】

 并行执行引擎 Block-STM 已经集成到aptos中。针对低争用和高争用两个用例进行了测试。低争用情况下，在32线程时实现了16倍性能加速。在高争用情况下，也有超过8倍加速。 元数据有可能在并行执行过程中重新排序，一个事务可能跨多个区块。这种可能的重新排序的随机性可以阻止MEV套利者。

5.批量存储

并行执行阶段会把结果都结果都放到一个写集合中。这个写集合并不持久化到磁盘上而是都放到内存中，用作下一个区块的缓存。这样后面产生的重复的写数据不会一次又一次的直接写到磁盘，在内存里面就合并了，最终本来多次写就变成了一次。如果在这个过程中，由于某种原因这些放在内存中数据丢失了，只需要从元数据排序阶段重新执行并行阶段即可。 多少内存作为这些写集合数据的缓存是可以手动配置的，且提供背压机制【背压机制的意思就是即使你内存大，但是你缓存配置小，也不会由于写数据太多导致内存溢出。上游会根据写入延迟等数据来决定是否继续往你这里写，而不仅仅是看机器内存大小。】

【这样的写入机制在web2中有不少应用。比如spark，也是管道并行化处理，中间结果不持久化可以放内存，失败就从前再来一遍。毕竟数据也不是老会丢失，这样大部分情况下性能会更好】

6.账本认证

aptos为账本历史实现的账本认证跟账本状态差不多，不同的点在于账本认证并不需要在事务执行的关键路径上执行，而是可以按需运行。

 账本历史认证 验证节点通常把事务执行输出放到一个全局认证的账本数据结构。 每个验证节点为最新版本结果数据库给短认证器签名。并且验证节点之间会相互放分享他们最近签名的短认证器，集体来收集合法签名过的短认证器。客户端使用这个签名就能完全信任这个数据库版本是完整、有效且符合拜占庭协议的账本历史数据。客户端可以查询任何验证节点读取数据，并使用认证器来验证这些数据。

 定期状态认证 因为全局状态是随机访问，如果要实时更新，维护成本会很高。但是如果大批量数据更新的话，可以并行计算更新，而且还可以把重复部分合并。所以最终aptos针对账本历史认证进行定期更新。 定期更新引入了检查点概念。相当于对某个时刻的全局状态进行了一次快照，并且持久化下来。虽然还是有丢失风险，但是可以通过重新执行事务来弥补。 两个状态检查点之间差距越大，每笔交易更新经过状态验证的摊销成本也就越低。

7.状态同步

主要利用上面6点说到的账本历史认证以及经过验证的状态证明来提供灵活、可配置的同步协议。

Aptos属于 pos模型，原生aptos 代币用来作为gas。

1. Aptos的gas因为架构上进行管道化处理有关，它可以在任何一个环节对gas低的事务进行丢弃处理。这样随时时间推移，aptos给矿工们的gas费用就会更加符合他们在硬件方面的投入。

2. 网络治理 每个重要功能变更以及改进都会通过如下流程：提议、实现、测试以及部署 每次部署也会分两个阶段：

   1）更新先部署到节点

   2）通过开关开启 跟其他公链在这方面不同的是：aptos把所有配置都放到链上了。节点可以通过流程来调整是否同步最新配置以及启用。

3. Pos共识 节点运营商有足够的质押代币就就可以加入链。当然赚取的奖励也是分两份，节点运营商跟质押者。质押者可以在多个节点质押代币。 质押代币数量的多少会在事务传播、投票以及元数据排序等重要环节产生不同影响。自然质押数量多，在这些环节影响就大，后面获得奖励自然就多。这就是pos

上面提到了aptos通过并行，批处理优化，模块化事务的管道处理以及后面的共识协议升级、delta写，事务hints以及关键路径缓存来提升优化性能。 今天，区块链吞吐量主要按照TPS来度量。但是这种方式不精准，事务延迟也有很大差异。另外一些系统没有使用接近真实情况的复杂事务来度量系统性能。 【应该是吐槽竞争对手发布的性能数据问题】

1. 同构状态分片 最开始，aptos是单个账本状态。随着时间推移，aptos将使用一种独特的方式在保留去中心化的同时实现水平扩展能力。

   【就是可以加节点同时提升整体性能。水平扩展能力差的系统，加了节点也提升不了整体性能，比如以太网】

   这通过账本状态分片来实现，每一个分片提供同构API。Aptos 代币在所有分片上都可以用作gas，质押以及治理 数据可以在不同分片之间通过同构桥来连接。开发者跟用户可以按照自己的需求选择在哪种分片。不同的分片会有不同的特性，比如有些分片是基于ssd进行了计算密集型优化[性能高]；有的分片转为大存储以及低密度计算做了优化[相对来说性能低，适合存储冷数据] 总的来说，同构状态分片提供了吞吐量水平扩展能力，在使用上无论是开发者还是用户都跟使用一个分片是一样的。

   【此种分片方案跟near分片是不同的，near那种算是真数据分片存储，而这种方案有点类似于多集群或者联邦概念。所以aptos虽然有这个分片概念在里面，但不属于目前我们对公链技术方案区分的分片技术领域。】

   【说回aptos分片。它这里按照不同workload特征匹配合适的分片去做计算跟存储，想法是挺好的，但我觉得后期效果不一定好。为啥？

   这里要说目前区块链架构在性能上的一个大问题：没有很好的把计算跟存储分离。这也恰巧是我进入web3之前花了很多时间的工作方向。虽然L2方案也是把计算挪到上面存储在L1上，看上去算是存算分离。但是毕竟没有首先就以良好水平扩展能力作为优先设计原则，也就是L2 的计算即便能很好的水平扩展，下面的存储层L1的能力始终是固定的，没法扩展。所以综合来说L2方案肯定不具有存算分离的良好水平扩展能力。 所以再回到aptos，还是没有做存算分离，怎么可能做好水平扩展呢？你是能水平扩展，但同时区块链特性就是开放式网络，你没法去量化和管理每台加入链上的节点的硬件资源最大化满足当前的workload特征。所以即便按照不同负载workload运行在不同分片上，也会有不少的资源浪费。自然最终效果也就不会好】

本篇内容由UST DAO社区创作与长期更新维护，收藏订阅不迷路，也欢迎大家加入我们社区探讨财富密码。链接：

https://linktr.ee/ust_dao

目前公链问题很多，aptos就是为了来解决这些问题的。以可扩展性、安全性、可靠性以及可升级特性作为关键的设计原则。 经过350名以上开发工程师经过三年努力在共识、智能合约设计、系统安全以及性能跟去中心化等方面做了很多创新：

1. aptos 原生集成了更快更安全的move 语言。move prover[官方名词] 是一个正式的智能合约验证器，对合约常量和行为提供安全保障。

2. aptos 数据模型在key管理以及混合托管选项上提供了更高的灵活性，这个跟后面的事务前置透明度以及 实用轻量级客户端协议一起提供了更安全可靠的用户体验

3. 为了达到更高吞吐量以及低延迟，aptos综合了管道处理[想像下水在管道怎么流的，就是前一个结果为后一个执行作为输入]跟模块化处理在关键步骤的事务处理优点。让比如事务传播、块元数据排序、并行事务执行、批量存储以及账本验证的操作都并发操作。这样能够充分利用硬件资源，提供硬件资源利用效率

   【这点语言描述还是挺精准的，性能三要素就是吞吐量、延迟以及并发度。根据利泰定律，高吞吐跟低延迟这两个要素就能确定并发度。我们要么说一个软件性能高，这是很high level的说法，要么就要像这里说的，是高吞吐+低延迟，才能完整表述你是个高性能的东西。像国内软件行业比较喜欢说我是高并发来代表高性能，是很不准确的】

4. 跟其他并行执行引擎不同的是，aptos不需要通过知道前期数据来原子性的分割事务，它能对任意复杂事务进行原子操作，提供吞吐量，降低延迟，简化开发。【这里说的还是性能,准确定说算是对第三点的进一步解释】

5. aptos 模块化的架构设计为客户端的灵活度、频繁的优化以及快速升级提供了支持的可能。此外能为了快速部署一些新的技术创新以适应web3产品应用场景，aptos提供了内置链上变更管理协议。

   【总结，第1，2点都说得是安全性，包括move是一种合约友好的安全语言、数据模型搭配后面轻客户端协议以及一些新安全机制提供了更好的安全性。第5点属于一般性吧，略过。第3，4说的是性能，其实整个白皮书看下来这也是篇幅最多的部分。从软件工程角度来说能够这样的工程优化其实也算不错的。但是毕竟现在aptos已经被吹上天了，到处fomo这种天王级项目。这些工程领域的优化创新是不是感觉还不太够 ，毕竟你看near说是分片设计方向领头羊，solana是非分片领域第一个高性能的。aptos呢？接下来让我们看看aptos究竟有哪些技术亮点】

在web2世界里，很多中心化的公司通过各种不同的应用控制着用户数据的访问，特别是如google、亚马逊、苹果跟meta等大型公司。这些公司对不同用户场景通过特定优化的软件来提供基础设施，比如云服务即可以提供虚拟机出租，也可以直接出租裸硬件设备[就是没有安装云基础服务的硬件设备，类似你购买硬件服务器进行托管]。这样web2互联网才得以在如今轻松扩展至对上亿用户提供服务。但这需要我们普通用户完全信任这些中心化公司。 为了解决这种信任问题，web3应运而生。区块链作为底层基础设施跟web2中云服务一样提供支撑服务。 然而，尽管如今已经有很多区块链[各种公链]，但是web3发展还在初期。现在的这些公链还存在不少问题，比如不可靠[估计指竞争对手老是宕机]，高gas费用，吞吐量限制以及常见的因为各种安全漏洞导致的资产丢失，不能提供实时响应[延迟高]。对比web2 的云服务设施，web3 公链还有很长一段路要走

【公链对标的是web2里面的云服务商，大家都知道的谷歌云、亚马逊云以及阿里云等。软件行业的人可能知道云可以划分为三层IAAS，PAAS以及SAAS，分别是

硬件基础设施即服务（指你可以在阿里云可以购买虚拟机，也可以购买裸机）；

平台即服务，这里主要是讲中间基础软件层，比如消息服务、数据存储服务等；

软件即服务，可以理解为大家能直接使用到的各种软件了，当然也包含基础一点的，比如专门只提供短信接口的短信服务。

那么到web3 公链里面来，我们还没有看到这么清晰的分层，当然对标产品也还是有的。但是大家可以想像下，虽然现在也是公链百家争鸣，但是整体发展对比web2 还处在很早期，公链还可以很多事情可以做，很多故事可以讲。】

atpos的愿景是构建一条能够为解决真实世界用户问题而赋能的去中心化生态系统并能被web3 广泛使用的区块链。我们的使用就是通过提供一个灵活的模块化的区块链架构来提升和推进区块链在可靠性、安全以及性能方面的发展 随着web3的发展，底层公链应该能像web2云服务一样支持频繁的无缝的用户无感知升级，让上层开发者跟用户不再老是担心底层问题，以便更加聚焦在上层服务跟使用上。 我们的技术团队都是有过在Diem 开发经验的，并且在此基础上，我们完成了两处大的升级：共识协议跟核心框架。而且升级后从没发生过宕机事件。当然在diem基础之上还有很多创新，比如在事务处理，去中心化以及网络治理方面。

【总结，aptos就是要跟web2中云服务商一样提供各种基础设施，除了说不宕机问题显然针对竞争对手外，倒没有过多强调跟目前竟对有啥不同。愿景宏观伟大】

aptos 区块链是由一系列 验证节点组成，这些验证节点使用拜占庭容错算法，pos共识机制处理用户事务。每个节点的共识投票权重是由它质押数量决定的 任何提交事务或者查询状态跟历史数据的都可以算是客户端。客户端可以选择下载跟验证验证节点验证过的数据。 全节点算是一种从验证节点或者其他全节点复制事务以及区块状态的客户端。 轻客户端只维护当前的验证节点，能够安全地从全节点查询部分区块状态数据。钱包就是这样一种轻客户端。

为了满足对安全，快速可靠以及可升级的web3 基础设施的广泛应用，aptos区块链构建在以如下的设计原则基础上：

1） 快速安全的执行以及简单的可审计性和可分析性智能合约编程Move语言

2） 通过批、管道化以及并行执行事务以达到极致的高吞吐跟低延迟[高性能]

3） Block-STM技术，能理论有效提升事务并行执行性能

4） 通过快速、质押权重验证节点集流转以及声誉追踪优化性能跟去中心化

5） 可升级性和可配置型作为最重要设计原则

6） 模块化设计

7） 在保留去中心化的同时具备吞吐量水平扩展能力，以及分片作为最重要的概念

【跟摘要里面说的差不多，无非就是强调下自己的一些特性。其中block-STM技术算是跟其他公链有显著不同以及在理论层面看来是性能提升至关重要的点。STM全称软件事务内存，是为了解决以锁机制并发编程里面缺点而诞生的机制概念。早在1987年即被提出，软件行业人可能了解的高性能akka语言就是基于此机制。Aptos在stm基础上结合区块链事务执行特点提出了在stm上改进版本block-stm，可以参考：https://medium.com/aptoslabs/block-stm-how-we-execute-over-160k-transactions-per-second-on-the-aptos-blockchain-3b003657e4ba】

Move是一种在安全性以及灵活性上有加强的合约编程语言。Aptos使用move的对象模型作为它的账本状态，使用move代码（模块）来编写规则。 Move语言生态包括编译器、虚拟机以及很多其他开发工具。[显然不是evm兼容的] Move在rust基础上加强了对资源的控制。Move 模块定义了每种资源的完整生命周期、存储以及访问模式，这种模式保证不会有双花或者代币消失的情况 而aptos团队又在原move基础上针对web3应用场景进行了增强。比如上面提到的细粒度资源控制。这样不仅有利于对事务并行化处理，而且也可以做到在访问跟变更数据时比较恒定的时间消耗。此外，aptos在存储上还支持了表的概念，使得同一个账户可以存储大量数据（比如很多NFT）

账本状态包括了链上所有账户。使用64位无符号整型记录系统已执行事务数量来表示账本状态的版本。所以任何人发起一笔交易，都会修改这个账本状态。

1. 事务 签名事务包含如下信息：  事务授权者  发送者地址  数据载体。就是发送内容  Gas价格  最大gas数量  顺序编号  过期时间  链id。

2. 事件 事件是在事务执行过程中产生的。比如转账交易中，分别产生发送事件跟接收事件。每个事件都有唯一的key用来查询。多个事件拥有同一个key就是事件流。 对于move开发者来说，通常需要把底层资源变更前的数据以及事务执行后的数据都放到事件中。

3. 账户 账号使用唯一的256位标识[实际过程中应该是使用16进制来表示。标识跟表示两码事]。新账户可以通过两种方式：create_account以及transfer 创建。 账户地址是通过对公钥以及一个签名标识符进行加密hash得到的 addr=H（vk,ssid）

4. Move 模块 Move 模块包括字节码以及过程。跟面向对象里面的类的概念类似。 是由账户地址唯一确定的，总是跟一个模块名称一起定于。 每个账户最多可以定义一个模块。

5. 资源 跟模块类似，在账户地址里面跟数据关联。通俗的可以里面资源就是数据类型。不过这里明确不是所有数据类型都是资源，需要具备key跟store 两种属性

6. 账本状态 从move 虚拟机脚本看，每个账户就是由一些列值跟KV 数据结构组成。这些数据结构被称为表实体，以BCS形式存储。[很底层的概念，这是数据在物理存储介质上的最终存储形式]。这种数据层级结构使得开发者能够有效的在一大堆账户上操作少部分的数据副本或者在小部分账号上存储一大堆数据。

   【没太理解到底是怎么样一种数据存储形式。看上去就是读快，因为kv存储。而且在连续（小部分账户）空间写数据也快】

   现在初期，aptos仅使用一个账本状态。但是随着后面用户增加跟技术发展，会采用分片形式进行扩展。

1. 事务可行性保护 签名一个事务意味着签名者认可了事务将被提交和执行。但有时候，用户也可能无意识或者没有考虑清楚风险就签名了。为了减少这种风险，aptos提供如下三种保护措施： 1） 同一发送者账号同一事务编号只能提交一次。 2） 区块时间以高精度跟频率推进。 3） 每个事务在每个链上都有唯一编号，防止测试网的事务在主网上重放。

2. 基于move语言的私钥管理 Aptos账户支持密钥轮换，从而避免私钥泄露、远程攻击以及未来可能的加密算法破解。此外用户也可以把轮换权限下放给其可信任的人，同时可以针对私钥应用场景进行策略配置。

3. 预签名事务透明 如今钱包在进行签名时提供的信息不多，导致用户资产被盗。Aptos为了解决这个问题，提出了事务预执行：就是在事务真正执行前，预先执行一遍把执行结果告诉用户。

   【比如签名approve for all，现在在签名之前，就告诉你你做完这个动作后，人家能进行转账操作，这样就可以避免小白不清楚approveforall的风险了。】

4. 实用轻客户端协议 依赖于TLS/SSL证书进行通信在区块链客户端跟服务器之间通信并不可靠。[区块链节点是开发式加入，不涉及共识层面写数据还是有作弊可能] Aptos通过提供状态证明跟轻客户端验证协议用于钱包和客户端来验证非可信第三方提供的数据的有效性。【这里的技术细节后面章节还会提到】

为了提高吞吐，增加并发以及降低工程复杂度，aptos 把事务处理分解为多个阶段。这种方式不仅极大提升了性能，而且使得aptos提供了在客户端跟验证节点之间的交互提供了一种新的模式。  当特定事务中包含一批持久化事务时会通知客户端。有效且持久化事务有可能被立即提交  当批量持久化事务完成排序时会通知客户端。这样为了降低确定事务输出的延迟，客户端可以选择在本地执行而不是等验证节点完成执行  客户端可以选择等待验证节点执行认证事务，然后执行状态同步

Aptos模块化设计主要解决开发跟发布效率问题，同时也有利于验证节点的水平扩展。

1.批处理

批处理是aptos每一个环节中最重要的性能优化。事务传播过程中验证节点把多个事务合并到一个批次，然后共识阶段又把这些批次合并到一个块中。 在执行、存储以及账本认证阶段也都是批处理模式。 批处理虽然产生了一定延迟，但是可以根据情况来分别配置。在一个去中心化网络中也可以做到根据市场需求来进行自动调节，同时还能避免无意识的DoS攻击。

2.持续事务传播

事务传播在aptos中跟共识过程解耦了。验证节点持续的流式化处理批量事务，充分利用网络带宽资源。 无限的持久化批量事务会触发DoS向量攻击导致验证节点的存储很快被用光从而宕机。为了防止这种情况，aptos给每个批次的事务分配了时间戳，这样每个验证节点就行有效进行垃圾回收。另外按验证节点为单位进行配额的机制也能保护在极端情况可能造成的存储空间耗尽问题，比如潜在的拜占庭攻击。在存储前也会对事务批次大小进行验证。最后，还有一些其他优化机制来去重跟缓存事务来减少存储消耗保证并行执行引擎的性能

【按照时间来进行垃圾回收在区块链中确实可行，但是如果存入的速率要大于垃圾回收的速率会怎么办？这里配额机制就起这个作用吗 ？达到一定预先配置的存储空间就不再接受新事务存储请求？】

3.块元数据排序

普遍认为共识层是区块链吞吐量跟延迟的主要瓶颈，所以aptos的关键创新之一就是把非协议相关的任务从共识阶段解耦出来。 Aptos使用了DiemBFT v4 版本，这是一种乐观拜占庭容错协议。大部分情况下共识只需要通过两次交互。同时也有一个leader机制，它会在一个窗口时间内对没有参与的验证节点降级，这样能把异常的验证节点对网络影响降到最低。

【白皮书里面剩余内容并没说明如何分配这个物理时间戳，仅描述了其使用场景。是否跟solana机制类似，由leader产生物理时间戳?】

4.并行事务执行

并行执行是区块链的一个重要目标。Aptos从数据模型和执行引擎两方面做了尝试

 并行数据模型 引入了一个新概念 delta writes 。它描述了对账户状态的修改，而不是修改后的状态。所以只要更新顺序对，事务就可以并行处理。

【web2中delta update比较多，这里的delta writes 其实我觉得也可以理解是一个delta update，只不过区块链数据是没有update这一说而已。比如第一个事务针对a (3) +1,第二个对a+2，那么delta write 就可以理解为，第一个事务3+1=4，第二个事务不再是在3基础上+2，而是在3+1基础上+2.】

 并行执行引擎 Block-STM 已经集成到aptos中。针对低争用和高争用两个用例进行了测试。低争用情况下，在32线程时实现了16倍性能加速。在高争用情况下，也有超过8倍加速。 元数据有可能在并行执行过程中重新排序，一个事务可能跨多个区块。这种可能的重新排序的随机性可以阻止MEV套利者。

5.批量存储

并行执行阶段会把结果都结果都放到一个写集合中。这个写集合并不持久化到磁盘上而是都放到内存中，用作下一个区块的缓存。这样后面产生的重复的写数据不会一次又一次的直接写到磁盘，在内存里面就合并了，最终本来多次写就变成了一次。如果在这个过程中，由于某种原因这些放在内存中数据丢失了，只需要从元数据排序阶段重新执行并行阶段即可。 多少内存作为这些写集合数据的缓存是可以手动配置的，且提供背压机制【背压机制的意思就是即使你内存大，但是你缓存配置小，也不会由于写数据太多导致内存溢出。上游会根据写入延迟等数据来决定是否继续往你这里写，而不仅仅是看机器内存大小。】

【这样的写入机制在web2中有不少应用。比如spark，也是管道并行化处理，中间结果不持久化可以放内存，失败就从前再来一遍。毕竟数据也不是老会丢失，这样大部分情况下性能会更好】

6.账本认证

aptos为账本历史实现的账本认证跟账本状态差不多，不同的点在于账本认证并不需要在事务执行的关键路径上执行，而是可以按需运行。

 账本历史认证 验证节点通常把事务执行输出放到一个全局认证的账本数据结构。 每个验证节点为最新版本结果数据库给短认证器签名。并且验证节点之间会相互放分享他们最近签名的短认证器，集体来收集合法签名过的短认证器。客户端使用这个签名就能完全信任这个数据库版本是完整、有效且符合拜占庭协议的账本历史数据。客户端可以查询任何验证节点读取数据，并使用认证器来验证这些数据。

 定期状态认证 因为全局状态是随机访问，如果要实时更新，维护成本会很高。但是如果大批量数据更新的话，可以并行计算更新，而且还可以把重复部分合并。所以最终aptos针对账本历史认证进行定期更新。 定期更新引入了检查点概念。相当于对某个时刻的全局状态进行了一次快照，并且持久化下来。虽然还是有丢失风险，但是可以通过重新执行事务来弥补。 两个状态检查点之间差距越大，每笔交易更新经过状态验证的摊销成本也就越低。

7.状态同步

主要利用上面6点说到的账本历史认证以及经过验证的状态证明来提供灵活、可配置的同步协议。

Aptos属于 pos模型，原生aptos 代币用来作为gas。

1. Aptos的gas因为架构上进行管道化处理有关，它可以在任何一个环节对gas低的事务进行丢弃处理。这样随时时间推移，aptos给矿工们的gas费用就会更加符合他们在硬件方面的投入。

2. 网络治理 每个重要功能变更以及改进都会通过如下流程：提议、实现、测试以及部署 每次部署也会分两个阶段：

   1）更新先部署到节点

   2）通过开关开启 跟其他公链在这方面不同的是：aptos把所有配置都放到链上了。节点可以通过流程来调整是否同步最新配置以及启用。

3. Pos共识 节点运营商有足够的质押代币就就可以加入链。当然赚取的奖励也是分两份，节点运营商跟质押者。质押者可以在多个节点质押代币。 质押代币数量的多少会在事务传播、投票以及元数据排序等重要环节产生不同影响。自然质押数量多，在这些环节影响就大，后面获得奖励自然就多。这就是pos

上面提到了aptos通过并行，批处理优化，模块化事务的管道处理以及后面的共识协议升级、delta写，事务hints以及关键路径缓存来提升优化性能。 今天，区块链吞吐量主要按照TPS来度量。但是这种方式不精准，事务延迟也有很大差异。另外一些系统没有使用接近真实情况的复杂事务来度量系统性能。 【应该是吐槽竞争对手发布的性能数据问题】

1. 同构状态分片 最开始，aptos是单个账本状态。随着时间推移，aptos将使用一种独特的方式在保留去中心化的同时实现水平扩展能力。

   【就是可以加节点同时提升整体性能。水平扩展能力差的系统，加了节点也提升不了整体性能，比如以太网】

   这通过账本状态分片来实现，每一个分片提供同构API。Aptos 代币在所有分片上都可以用作gas，质押以及治理 数据可以在不同分片之间通过同构桥来连接。开发者跟用户可以按照自己的需求选择在哪种分片。不同的分片会有不同的特性，比如有些分片是基于ssd进行了计算密集型优化[性能高]；有的分片转为大存储以及低密度计算做了优化[相对来说性能低，适合存储冷数据] 总的来说，同构状态分片提供了吞吐量水平扩展能力，在使用上无论是开发者还是用户都跟使用一个分片是一样的。

   【此种分片方案跟near分片是不同的，near那种算是真数据分片存储，而这种方案有点类似于多集群或者联邦概念。所以aptos虽然有这个分片概念在里面，但不属于目前我们对公链技术方案区分的分片技术领域。】

   【说回aptos分片。它这里按照不同workload特征匹配合适的分片去做计算跟存储，想法是挺好的，但我觉得后期效果不一定好。为啥？

   这里要说目前区块链架构在性能上的一个大问题：没有很好的把计算跟存储分离。这也恰巧是我进入web3之前花了很多时间的工作方向。虽然L2方案也是把计算挪到上面存储在L1上，看上去算是存算分离。但是毕竟没有首先就以良好水平扩展能力作为优先设计原则，也就是L2 的计算即便能很好的水平扩展，下面的存储层L1的能力始终是固定的，没法扩展。所以综合来说L2方案肯定不具有存算分离的良好水平扩展能力。 所以再回到aptos，还是没有做存算分离，怎么可能做好水平扩展呢？你是能水平扩展，但同时区块链特性就是开放式网络，你没法去量化和管理每台加入链上的节点的硬件资源最大化满足当前的workload特征。所以即便按照不同负载workload运行在不同分片上，也会有不少的资源浪费。自然最终效果也就不会好】