LOADING...
LOADING...
LOADING...
当前位置: 玩币族首页 > 区块链资讯 > saito技术进展更新

saito技术进展更新

2021-07-20 婷婷玉立 来源:区块链网络
本文授权转载自“Saito Network”公众号,Saito 是一个将 Web3 交付给用户的开放网络层。

撰文:David Lancashire,Saito 联合创始人我们的技术团队在过去的两个冲刺(sprint)中一直在努力工作。有很多东西值得与大家分享,但如果您不想涉及技术讨论,那长话短说,就是我们的进展很顺利,预期将按计划发布我们的 Rust 客户端。在这篇文章中,我会试图更深入地解释我们的运作方式、我们正在处理的问题以及我们如何解决这些问题,而不是仅仅给出事情进展顺利的模糊保证。

首先要提到的是,在 Clay 和 Stephen 的领导下,Saito 的技术团队经历了架构变革,使我们的开发环境实现专业化。我们已经进入测试驱动的开发和对代码库中的主要提交进行同行审核的过程。对于较大型团队来说,这是非常标准的流程:它涉及对开发方式的改变,使得我们中任何人都更难在不先向团队其他成员打招呼的情况下实施破坏或进行随意更改。在代码编纂的重点方面,Saito Rust 一直是我们的首要任务,我们在过去两个 sprint 中做了很多工作。Saito 系统中的大部分组件现在已经在 Rust 代码中落地:区块生产、从磁盘存储/检索区块、交易和区块的内存池管理、跟踪区块链中区块的最长链状态、我们将区块添加到区块链中的算法、销毁费用计算、签名验证、utxoset 管理等等。请注意,Rust 对于内存管理和「所有权」实施了限制性政策,因此这部分代码位不一定在生产中真正运行。我们倾向于写代码然后集成。我们尚未予以明显解决的主要组件是网络和节点管理、自动交易重播和质押机制。总体来说,我们的开发工作试图采用开放式开发周期,然后讨论具体什么可行、什么不可行,然后将共识方法集中实施到核心软件中。这种做事方式让我们能够发现:
(1)我们在 Rust 中实现逻辑时遇到了哪些实际问题
(2)贡献者对改进 Saito 有什么建议对改变 Saito 的工作方式持开放态度,使得我们放慢了速度,因为这意味着讨论不仅仅是关于实现 javascript 中已经存在的算法,而且还带来了一些非常明显的重大进展,Clay 和 Stephen 在其中居功至伟


将默认散列算法从 SHA256 升级到 BLAKE3,这将显著提升网络的整体数据吞吐量;这真的很重要——散列是经典 Saito 实现中的最大瓶颈。区块处理中的一个可选的「预验证」步骤,避免了许多区块甚至将数据插入关键区块链索引的需要,直到我们确定它们是竞争链的一部分;这避免了所有情况下都需要插入数据的工作(关键情况除外),以此加快了工作速度。更改单据被格式化的方式,无需精简钱包在进行交易后跟踪区块链:用户在创建零钱单据后立即将其花掉;还有后续的益处,可以更轻松地在这里进行真实波动幅度均值(ATR)交易。有效地缩小 Saito 交易规模的各种提案(保存到磁盘或通过网络发送),包括将交易单的规模减少了大约40%,使得我们能够在同等大小的区块空间中打包进更多的交易。回顾过去两个月,我认为我们花了比我预期的更多的时间探索各种不会落实的实施想法,但我们相信,未来的回报会证明这是值得的,因为就我们正在实施的改进而言,我们并未将其概念化为这项工作的一部分。总体结果是,代码库在原始功能方面可能稍落后于我的预期,但也更清晰、更简单,开发速度也比预期的要快。最困难的部分是整理出一个设计流程,人们可以在这个过程中就提议的修改进行有效的沟通。就实际开发里程碑而言,我们预计将在 1-2 周内完成 Saito 协议的经典版本(不联网)。然后依次处理节点连接、ATR 机制和质押(Staking)机制。这应该为网络上线部署之前的测试留出足够时间。那么初步可扩容的数字是多少?一个很好的切入点可能是上面的这个截图,它是由早期的非 Rust 版本 Saito 生成的,我为了生成一些展示竞争力的数字而启动了这一版本。您看到的是一个测试脚本,该脚本创建了随机数量的相当庞大的交易,并将它们放入较早的 Saito 实现中,以检查引擎处理它们所需的时间。通过查看不同类型的区块(几笔大的交易?大量小的交易?)如何导致引擎瘫痪的方式,来全面检查我们的性能。这一截平图显示了较少数量的数据密集型交易,处理时间约为 2 秒。你应该看到:


有三个关键瓶颈影响我们的非 Rust 实现:
(1)将区块保存到磁盘
(2)从磁盘加载区块
(3)验证区块(和交易)

我们在这里看不到保存区块的延迟,因为这是异步和幕后发生的。但是我们可以看到:散列交易附加数据并检查这些交易签名需要大量的处理时间。还有一些不太明显的经验教训——有趣的是,我们的 Google Dense Hashmap 在处理 UTXO 更新方面甚至不费吹灰之力,但我们的钱包已经开始不堪重负,表明核心路由节点甚至不应该默认执行这一工作。区块链领域的肮脏秘密之一是网络速度是扩容最关键的瓶颈。这就是世界需要 Saito 的原因之一,因为「路由工作」实现快速的网络连接,而这最终是实现扩容的唯一途径。但是我们可以从其他工作中省出的时间越多,我们就能有越多的时间可以浪费在网络延迟上,因此我们在核心区块链性能方面的重点一直放在这三个关键瓶颈上:
(1)将区块保存到磁盘
(2) 从磁盘加载区块
(3) 验证区块(及其交易)在没有解决上述任何问题的情况下,非 Rust 实现的整体数字告诉我们,任何 javascript 客户端的处理上限都是每分钟 400 MB 左右,如果它们开始被恶意节点发送垃圾邮件,可能会更快。了解这一点很有用,因为 TB 级数据需要每分钟大约 1.5GB 的速度,所以 Rust 需要带来巨大的提升。拥有原始数字也很有用,因为虽然有些人认为 javascript 不是一种高性能语言,但事实并非如此——你在这里看到的是 「优化过的」代码,它在性能关键领域执行诸如交换预编译的 C 二进制文件之类,例如处理 UTXO 集。那么 Rust 现在表现如何?

在 javascript 中,我们使用 JSON 并以「人类可读的字符串」等格式存储大量数据,这些格式在磁盘上读写速度较慢。在 Rust 中,我们正在消除这些,并专注于纯字节流以提高性能。最重要的是,我们将「验证」交易的工作在计算机具有\可用的 CPU 内核数量中进行分配。由于一些复杂的原因,Rust 几乎独一无二地更适合并行化处理数据。Rust 交出的成绩单要好得多。

就基线数据而言,我们看到有证据表明,写入磁盘和从磁盘加载的速度提高了 2 倍。这里的节省不是来自与硬盘驱动器交互的速度,而是来自生成的字节流和软件可以处理的内存对象之间的转换。保存到磁盘并不是一个真正的关键瓶颈,但从磁盘(或网络)加载才是瓶颈,因此这里的性能提升对于能够快速验证和转发区块非常关键。特别是 Clay 在推动我们实现更好更快的数据序列化和反序列化方面做了很多繁重的工作。很难分享实打实的硬数据,因为序列化工作仍在进行中。我们认为区块加载速度提高 50% 是可能的。交易验证呢?

在测试系统性能时,我们的测试区块处理速度主要在 10 MB 到 1 GB 范围内,总共有 1000 到 100,000 笔交易(约 30 万个数据单)。我们真的不清楚用户将有多少数据与交易相关联,因此这里的差异不是体现在近似现实,而是体现在找出不同交易规模的区块验证需要多长时间(因为需要处理海量交易)。这样做有助于我们了解:例如,对于大多数实际交易规模,散列花费的时间比验证结果交易签名要多得多。UTXO 验证?仍然是小菜一碟。可能是因为我们使用的是同类最佳的工具,而不是 POS 网络倾向于使用的那种数据库,因此我们在很长一段时间内不需要优化更新 UTXO 哈希图的速度。好消息是,Rust 实现了 100% 数据平行化处理。

虽然我们可以使用各种技术将「平行处理」添加到其他语言中的交易验证中,但很多语言需要为单独的 CPU 线程创建多个区块「实例」以进行单独处理。Rust 的优势在于它避免了这个问题,意味着一旦我们的区块进入内存中,我们就可以根据需要在交易验证中投入尽可能多的 CPU。出于所有务实的目的,这使得交易验证不再是难题。与我们正在做的所有其他事情相比,这个过程仍然需要相当长的时间,但这里的性能天花板在于可用的 CPU 线程数,并且在商业硬件上可以扩展到今天的 ** 核。我们很高兴达到基准测试变得现实和有用的程度。

我们真的不想在一切事情上广泛分享数据,因为我们还没有完成序列化,ATR 和路由工作显然会对性能产生影响,但是如果您真的很好奇,可以随时下载并运行代码并亲自查看。对我们来说最重要的是,在提交补丁和提出设计更改方面为我们自己的团队打下了坚实的基础,并且决策是根据实际数字做出的。这会让事情进展变得更快吧?所以我们认为我们的进展非常扎实可靠。

我们接下来 2 周的最大目标是完成我们认为的 Saito 经典实现。这涉及最终确定「基本」版本中默认包含哪些算法版本,特别是挖矿组件如何与区块生产交互。之后,我们开始主攻更高级的功能(自动交易重播、抵押)。前路依然任重道远,但我们也确实取得了很多进步。与往常一样,如果您有兴趣亲自了解正在发生的事情或加入我们并解决一些开发问题,欢迎在 Github 上跟踪或克隆我们的Saito Rust代码库。我们在 Saito Discord 有一个开发频道,也非常欢迎来提问和讨论。希望见到您。

—-

编译者/作者:婷婷玉立

玩币族申明:玩币族作为开放的资讯翻译/分享平台,所提供的所有资讯仅代表作者个人观点,与玩币族平台立场无关,且不构成任何投资理财建议。文章版权归原作者所有。

LOADING...
LOADING...