石墨烯2.0 [搬砖+翻译]_石墨烯2.0是什么意思啊-优快云博客

石墨烯2.0区块链通过借鉴LMAX交易所的技术，实现了比现有金融平台更强大的交易处理能力，平均每秒可处理10万笔交易。它通过优化内存使用、精简业务逻辑和改进数据模型等手段，大幅提升了区块链的性能。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

鉴于国内有感石墨烯2.0区块链的有价值的介绍资料太少，今天从官网搬个砖，写个评。

---------------------------------------------------------------------

石墨烯2.0 -- 高性能与可扩展性的区块链

序言：高性能区块链技术对于加密货币和智能合约平台来说是必不可少的，可以替代现有的金融平台。BitShares从底层设计，实现了比Visa和万事达卡交易能力总和还要强大的交易处理能力的区块链。采用DPoS（代理权证证明），BitShare网络可以在平均1秒内进行交易确认。当我们进行网络支付时，石墨烯能够达到10万TPS。

综述

为了实现业界领先的性能，BitShare借鉴了每秒处理600万笔交易的LMAX交易所的经验，归纳起来有以下几点：

将所有事物都保存在内存中；
将核心业务逻辑维持在单线程；
将加密操作（散列和签名）隔离于核心业务逻辑之外；
将验证分为依赖状态和不依赖于状态的检查；
使用面向对象的数据模型。

通过遵循上述简单的规则，BitShares无需稍加优化即可实现每秒100,000个事务的处理能力。预计未来的优化将使得BitShares的性能达到与LMAX类似的水平。值得注意的是，由BitShares实现的性能高度依赖于具有兼容的交易协议。如果想要将核心业务逻辑部署在虚机上，并使之执行加密操作或对引用的所有对象进行散列操作，这样的方案无法达到相同的性能水平。区块链本质上是单线程的，CPU单核性能是所有资源中最大的瓶颈。BitShares性能的提升得益于单线程的应用。

背景

区块链是一个全局账簿，在其中每笔交易都拥有一个特定时间戳的共享全局状态。交易处理的顺序可以改变其他交易的有效性。例如，您的银行账户的支付状态必须清除后，才能从您的银行帐户提款。直到影响特定账户的之前所有交易都被处理后，才能知道当前交易是否有效。理论上讲，只要两个账户之间没有相互依赖关系，它们的交易是可以同时处理的。但在实践中，通过智能合约，如何确认明细账上哪些交易是真正相互独立的确实一件棘手的工作。要确保两笔交易真正独立，唯一的办法就是保持完全独立账本，然后定期转账。这种情形，类似于相比于统一内存访问方案，非统一内存访问（NUMA）方案上做出的性能折衷。在实际应用中，统一内存访问对开发人员来说设计更容易、成本更低。在建造超级计算机或巨型集群时，NUMA体系结构通常作为解决问题的最后述求。计算机行业已经逐渐认识到，通过并行来扩展性能远不如早期通过提升CPU时钟速度来的容易。正因如此，在尝试采用多线程方法来提高性能之前，CPU设计人员会将单线程性能应用到极限。而且，仅当多线程都无法满足应用时，集群计算才会成为更好的选择。（注：处理性能的提升路线：单核性能-->多核并发-->集群）许多加密币解决方案中其实尚未充分探究单核处理能力的提升，就已经试图通过期望使用“集群”来立竿见影的解决可扩展性问题。（注：文章的意思是，这样其实并不能取得良好的效果）

LMAX Disruptor

LMAX Disruptor提供了一个具有高度可伸缩性和高性能的体系结构的案例研究，展示了在单个执行线程中可实现的功能。LMAX是一个零售交易平台，旨在成为世界上最快的交易所。通过这个案例，他们慷慨地向公众分享了他们的经验。以下是他们架构的主要观点。业务逻辑处理器就是处理所有有序事务和顺序匹配的地方。它使用单线程处理每秒数百万的订单。这个架构很容易移植到加密币和区块链设计的领域。输入Disruptor的作用是从不同用户那里收集订单，并明确订单顺序。给订单进行排序后，这些订单被复制、记录并广播到许多冗余的业务逻辑处理器。输入Disruptor是个简单的并行任务，很容易部署在集群系统中。在业务逻辑处理器已经处理输入之后，输出Disruptor负责通知关心结果的处理环节。这个环节也是一个简略的并行任务。最终，LMAX能够通过业务逻辑处理器在普通CPU的单核上使用Java虚拟机每秒处理600万笔交易。如果（在单核基础上）LMAX都可以达到每秒600万笔交易，那么对于每秒不到10笔交易量的加密币和智能合约平台而言，根本不需要集群解决方案。

高性能区块链

为了实现高性能区块链，BitShares采用了LMAX相同技术方案，该方案满足以下几个关键要素：

尽量将所有事物放入内存处理；
避免同步原子函数（比如锁、原子操作）；
尽量减少业务逻辑处理器中不必要的计算。

随着极大并行化的设计，内存变得日益便宜。在商用（高端）服务器中只需安装售价不足15000美元的1TB内存，足以跟踪记录每个人在互联网上的帐户余额和权限。在30亿人可广泛采用该系统之前，这种硬件配置首先将成为PC机的标配。但真正的瓶颈不在内存而是带宽要求。以每秒100万次事务和每事务256个字节，网络将需要每秒256兆字节（1Gbps）。这种带宽对于普通台式机来说并不常见，但这个水平仅仅是Internet 2机构提供给超过210 家美国教育机构、70家公司以及45家非营利和政府机构的100Gbps中的一个零头。基于上述的内存与网络条件，有理由相信，如果采用正确的设计方案，在区块链中尽可能使用内存运算，实现每秒百万事务是非常现实的。

避免使用散列算法（Hash），尽量分配ID

在单线程系统中，CPU是核心资源。传统的区块链设计使用密码哈希来生成全球唯一的统计保证不会碰撞的ID。这些散列的问题是它们需要更多的内存和更多的CPU时钟来操作。与直接数组索引相比，使用散列查找帐户记录要花费更多的CPU时间。例如，64位整数比160+位ID更容易比较和操纵。较大的哈希ID意味着占用大量的CPU的缓存、需要更多的内存。在现代操作系统上，RAM经常使用压缩方式存放不常访问的数据；而HASH标识符是不可压缩的随机数据，所以不建议存放在RAM中。幸运的是，区块链给了我们一个手段来全局分配唯一的ID，这些ID不会相互冲突，所以可以完全无需采用基于散列的标识符（比特币地址）来引用帐户、余额或权限。

从业务逻辑处理器中删除签名验证

加密货币网络上的所有交易都依赖于加密签名来验证权限。在一般情况下，所需的权限可能因其他事务而改变。这意味着权限需要按照业务逻辑处理器内不需要加密计算的方式进行定义。每个公钥都需要分配一个唯一不可变的id，每个id被分配后，输入Disruptor可以验证用户签名与指定的id是否相匹配。在事务交给业务逻辑处理器的时候，唯一剩下的步骤就是检查ID。类似的，在带有静态id的不可变对象的处理过程中，也可以取消相应的预检查操作。

为静态验证设计事务

许多事务属性可以静态检查，而不需要引用当前的全局状态。这些检查包括参数的范围检查、输入的重复数据删除、数组的排列顺序等。一般而言，如果事务包括其“假定”关于全局状态的数据，则可以执行许多检查。在执行这些检查之后，业务逻辑处理器所要做的一切就是确保“假设”仍然是真实的，通常可以归结为检查相对于交易签署时间引用的对象上的修改时间戳。

智能合约

许多区块链都采用通用脚本语言来定义所有操作。这些设计最终将“业务逻辑处理器”定义为虚拟机，所有事务都被定义为由虚拟机运行的脚本。这种方法采取了受限于真实CPU处理能力的单线程，并通过强制使用虚拟CPU来组合这些处理方法。一个虚拟的CPU，即使采用即时编译（JIT），也会比真正的CPU慢，除了计算速度之外，脚本化处理还存在其他问题。当事务被定义在较低级别时，业务逻辑处理需要插入大量的静态检查和加密操作，从而导致整体吞吐量下降。即使脚本引擎是通过本地调用完成的，脚本引擎也不应该要求执行加密签名检查。借鉴LMAX中经验，区块链虚机建议考虑单线程的性能。这意味着区块链应该从一开始就针对即时编译进行优化，最常用的智能合约应该由区块链本地支持，只留下很少使用的自定义合约在虚拟机中运行。这些自定义合约应该围绕性能进行设计，这意味着虚拟机应该将可寻址内存限制在适合CPU缓存的地方。

面向对象的数据模型

将所有内容都保存在内存中的好处之一是可以设计软件来模拟真实世界的数据关系。这意味着业务逻辑处理器可以快速地跟踪内存中指向它所需数据的指针，而不是被迫执行昂贵的数据库查询。这也意味着数据可以在不复制的情况下被访问，并且数据可以被原地修改。与使用基于数据库的方法相比，这种单一优化提供了一个数量级的性能增益。

交易规模

每秒处理100,000次交易的区块链会生成大量数据。其他区块链（如瑞波币和比特币）的平均交易大小约为250字节。BitShares上的类似事务平均只有100个字节。换句话说，竞争系统需要2.5倍带宽来传播相同数量的事务。假设千兆连接到互联网，仅仅传输包含100,000个事务的块将花费大约0.1秒。其他区块链网络需要0.25秒。在对等网络上的延迟和多跳被考虑之后，事务大小将直接影响块产生的间隔与确认的等待时间。事务大小常常是CPU在其关键路径中必须处理的数据量的指示。因此，它们可以作为一个CPU的单线程性能如何被命中的指标。如果约定所有的节点都事先知道所有的广播事务并且只需要事务标识的有序列表来广播每个块。通过这样的约定，所有相应的协议还可进行进一步优化。