月亮链 月亮链
Ctrl+D收藏月亮链
首页 > DOT > 正文

BEA:Beam Sync:同步以太坊节点的新方法_Scotty Beam

作者:

时间:1900/1/1 0:00:00

编者按:本文来自:以太坊爱好者,作者:JasonCarver,翻译&校对:陈亮&阿剑,Odaily星球日报经授权转载。为什么要改善节点同步体验?每当我想起目前还有多少人仍在使用Infura与链上应用程序交互时,我就感到有点难受。Infura的服务很棒,但如果大部分用户都不自己运行节点,显然也不太对头。即使是非常有能力且积极性非常高的开发人员,也不能完全摆脱对Infura的依赖。从这点看来,我们仍未完成以太坊的“自主验证”愿景中的重要部分。我们的团队希望尽自己的力量扭转这一趋势。我们的使命是尽可能增加网络上的节点数量,特别是那些由爱好者、研究人员和开发人员运行的节点。当我们问起他们为何不运行自己节点时,答案不外乎是:“我安装了客户端软件,也尝试了同步区块链,但好像总是同步不上。于是我就停下来了,因为我还有别的事要做。”所以,如果我们想让更多的人来运行节点,就得让节点同步更快一些,并且在同步过程中能够反馈进度信息。许多团队都在这个领域耕耘。专用硬件或许是一条重要途径。但在这篇文章里,我们想讲的是“BeamSync”同步方法如何能够大幅提升同步速度。现有的同步方法

为了更好地理解BeamSync的原理,我们先来看看现有的几种同步方法。FullSync

完全同步方法是执行自创世区块以来的每一个区块。创世区块标志着一个起始创世状态。所谓“执行区块”就是,每下载到一个区块,就读取前一个状态并产生新状态,并以该新状态来验证区块头中的状态根。在以太坊主网上完全同步的速度非常慢,而且随着网络的老化,使用完全同步方法来同步到最新区块的时间也会越来越长。所以人们开发出了“快速同步”方法。FastSync

Beamswap:GLINT销毁量突破4000万枚:7月3日消息,基于Moonbeam的DeFi中心Beamswap发推称,GLINT销毁量已突破4000万枚。[2022/7/3 1:47:33]

快速同步方法就是下载过去所有的区块和区块头,并选择最近的区块作为“启动块”。启动块以前的区块都跳过执行,到了启动块再开始执行区块。这种方法假设了从创世块到启动块都正确地遵循了所有EVM规则。这个假设是合理的,因为矿工有动力遵循诚信不作恶原则,生产正常区块,拒绝可能具有攻击性的区块。在快速同步可以执行启动块之前,需要的区块状态包括:合约字节码、帐户和合约存储内容。执行交易时可能需要读取所有这些值中的任何一个。因此,快速同步方法要求从其他对等节点处获得启动块之前的状态快照。快照是用状态根哈希值来标记的;所谓状态根哈希值,就是所有状态内容的哈希默克尔树根值。节点使用该状态根哈希来验证从其他对等节点处下载的状态数据是否与矿工在该区块中声明的状态相匹配。快速同步方法下载完所需的所有状态后,等于节点已经有了执行交易所需的一切数据。那么这时候开始,节点就可以切换成完全同步模式了,从启动块开始可以逐个逐个执行区块了,就跟完成了启动块以前的完全同步过程的节点一样。简化之后的过程就像下面这张动图所显示的:

其他方法

其他的快速同步方法包括WarpSync以及一些目前尚未得到验证的同步方法。抽象一些来看,它们都属于快速同步方法的不同形式。另外,即使了解这些其它同步方法的原理,也无助于理解Beam同步策略,所以这些同步原理不是我们这篇文章的重点,我以后再讲。快速同步方法有多快?

Injective通过与Moonbeam和Axelar集成支持Polkadot原生资产:据官方博客消息,智能合约平台Injective通过与Moonbeam和Axelar集成,新增支持Polkadot原生资产。其中,互操作性网络Axelar促进后端Polkadot资产的桥接交易。[2022/6/4 4:01:46]

快速同步方法在目前的主网运行环境下面临一些挑战,因为同步需要下载很多数据,甚至超过100GB的数据,所以,可能在上图所示的第二步“GetAllState”就要卡住很长时间。更糟糕的是,对等节点不会逐块给你提供状态数据,只会提供启动块前一段时间内的状态,比如启动块前100个区块的状态数据。Geth客户端的默认设置是前120个区块。如果你不能在30分钟内下载完所有的状态数据,你就需要做切换,就是换一个新的启动块,重新开始同步,虽然不是从0开始,但是也增加了下载和验证区块的时间。Geth客户端在提高同步速度上取得了非凡的成绩,快速同步和完全同步模式都有巨大进步,而且Geth客户端的每一次更新都会有所推进,但即使你有非常完美的电脑硬件,同步过程依然需要持续至少4小时。对于第一次同步来说,这样的过程确实略显艰难。那么,我们团队正在开发一个用Python语言编写的客户端,叫“Trinity”。Python在速度性能上不会比Go语言更快。如果以性能为中心的Geth代码不能像我们希望的那样快速同步,Trinity客户端又有什么机会呢?完全有理由预计Trinity客户端执行一次快速同步需要几个星期。但是如果客户端不能同步主网,那么它就没意义,同样,花费几周时间去同步也没有意义。出于这种需要,我们构思了一种新的同步策略,我们现在称之为:Beam同步方法。Beam同步方法

稳定币协议Beanstalk将于6月6日启动筹款活动以挽回黑客攻击损失:金色财经报道,基于信用的去中心化稳定币协议Beanstalk周四正式宣布推出筹款活动“TheBarnRaise”,以恢复因治理漏洞而损失的7700万美元流动性。“TheBarnRaise”将于6月6日美国东部时间下午12点开始,将持续到所有“Fertilizer”代币(将作为参与证明的BarnRaise代币)售完为止。作为筹款活动的一部分,Beanstalk还将推出10,000个非同质代币(NFT),即TheBarnRaiseNFTCollection,该系列将提供给在协议重新启动之前至少贡献1,000USDC的第一批参与者。此前报道,Beanstalk在4月份遭到1.82亿美元的闪电贷攻击。[2022/6/3 3:59:43]

概述

Beam同步方法是直接改进快速同步方法的结果,这两种同步方法的区别是Beam同步方法是一开始就直接执行启动块,并且只请求本地数据库中缺少的状态数据,并把输入状态和输出状态保存在本地。执行完一个块后就同步到下一个块并重复该过程,按需请求缺少的数据。

随着时间的推移,缺少的数据会越来越少。注意,如果某个状态从未被访问过,那么客户端将永远不会请求它,因此我们在后台运行另一个进程来填补这些空白。通过该回填过程,Beam同步最终会取得所有状态数据并保存在本地,然后节点就可以切换到完全同步状态。我们将执行每个块所需的数据集称为“区块见证数据”。得益于默克尔树的结构,我们不用完整地下载某个状态,就可以证明见证数据真的是从这个状态中取出来的。区块见证数据大小

Velo实验室副董事Beam:解读Velo收购Interstellar背后布局:金色财经报道,3月17日下午16:00,金色财经与欧易OKEx联合举办“金色财经对话Beam:解读Velo收购Interstellar背后布局“,邀请Velo 实验室副董事长 Tridbodi Arunanondchai(Beam)作为嘉宾讲述背后故事。

在直播中,Beam表示,Velo的目标是建立一个赋能传统银行商业并将其与最新的中心化和去中心化商业相链接的桥梁。

在谈及本次收购的原因时,Beam解释道,Velo与Stellar有着共同的目标和愿景,并且双方在能力上互相补充互相赋能。Interstellar团队在提供更快、更低廉以及更稳定的给予Stellar网络的跨境支付方案中有着极深厚的经验。因此彼此的融合是一个非常自然的选择。这次合并将使其成为行业里更强、更有影响力的团队。[2021/3/18 18:56:33]

为了简单起见,我们用“区块见证数据大小”来指称执行区块所需的数据元素数量。这类数据元素可能是在主要账户状态树上的一个节点,或者是合约存储树上的一个节点,或者是某个合约的完整字节码。分析区块见证数据大小是理解Beam同步方法性能的关键。快速同步方法必须在执行第一个区块之前下载全部状态数据,而Beam同步仅需要下载一个区块的见证数据,如果所下载的区块见证数据包含完整状态的三分之一,那么Beam同步的运行效率将大约是快速同步的三倍。所以,显然,下一个步骤是看主网的见证数据实际是多大。可能直接下结论还为时尚早,但是早期试验结果表明3000个状态树节点的数据量是一个合理的估计。而主网的全部状态信息有超过3亿个树节点。Beam同步的速度提升

谷歌reCAPTCHA竞争对手Human Protocol将扩展至波卡平行链Moonbeam:金色财经报道,Human Protocol周四宣布将扩展到以太坊之外,扩展到尚未推出的Polkadot平行链Moonbeam。据悉,其反机器人系统hCaptcha是谷歌验证码(reCAPTCHA)的竞争对手。此举还为在英特尔的开源计算机视觉注释工具(CVAT)上增加新的分布式工作市场做好了准备,以更好地服务于机器学习的数据标签。hCaptcha目前在15%的互联网上运行,而谷歌reCAPTCHA占据了大部分互联网。[2020/12/4 23:03:28]

让我们新定义一个标准:“从启动到执行”的时间。这是从用空数据库启动节点到完成最近一个区块的完全导入所需的时间。如果Beam仅需要下载3000个状态树节点,而快速同步需要下载3亿个树节点,那么我们就可以确定BeamSync方法的速度上限:在同步主网时,可在“从启动到执行”时间上获得最多10万倍的提升!但是,BeamSync方法往往无法真正做到10万倍提升。理由包括但不限于:状态数据的下载并不是建立全节点的所有工作,例如,我们还要下载区块头来验证我们所同步的区块链是最长链区块见证数据是按需确定的,这就意味着我们无法提前预知需要哪些状态数据。所以我们向对等节点请求数据时,一次只能请求一个状态数据。相反,快速同步一次最多可请求384个树节点,这使得Beam同步对对等节点的网络延迟更敏感。寻找高质量,低延迟的同步节点需要花些时间。说实在的,会遇上什么样的对等节点,那是真·随机事件。与快速同步方法不同,Beam同步方法会持续下载启动块之后的区块状态,这样也会拖慢区块导入时间。如果你对这一点有一些直观认识,那么你可能会注意到,如果收集区块见证的平均时间比区块生产的平均时间还要长,那问题会更加严重。Beam同步滞后性

获得第一份区块见证数据所需的时间必定长于网络产生一个区块的时间。同样,我们也可以预见,见证数据要几个区块的时间才能送达,我们把这种情况称为“滞后”,大约是最新一个导入区块和链顶端区块之间的时间间隔。区块见证数据的收集延迟问题可能会逐渐加重,然后你会发现你的Beam同步节点延迟了5分钟。这就是说,你本地拥有的最新区块其实是整个网络5分钟之前产生的区块,这意味着当RPC调用你现在节点账户余额的时候,你的节点会反馈五分钟之前的余额。在坊间的测试中,很常见的一个现象是滞后时间变化很大,从1分钟到20分钟不等。幸运的是,我们有一些技巧可以使得区块同步从滞后的情况中恢复,事实上,一般来说,落后越多反而恢复得越好,这就导致了滞后时间的极大波动:先是不断落后,然后是迅速追赶,循环往复。我们可以在区块落后的情况下更快地赶上的一个原因是,我们可以提前、同时为多个区块生成见证数据。毕竟,只有落后时,你才能利用这些未来的区块。当然,如果收集所需区块数据的时间总是超过区块产生时间,那么毫无疑问你将会越来越落后于区块链的增长,我们希望这种情况永远不会发生,但我们需要为此做好计划。BeamSyncPivot

就像快速同步一样,如果你落后太多,对等节点可能就不愿意为你提供你需要的数据了。切换机制是解决这个问题的关键。Beam同步里的pivoting机制就像快速同步里的一样,你的节点选择一系列要跳过的块,并在链顶端附近选择一个新的区块块区块头,然后,Beam同步再一次开始,节点并没有完全从头开始同步,它仍然拥有来自上一次同步的所有数据。无论你是采用Beam同步或者快速同步,只要使用切换机制你就需要付出相应的成本,切换机制意味着需要下载更多数据,这些数据中还会有一些你的节点并没有亲自验证过其执行的区块。好消息是:如果你不是落后超过30分钟,Beam同步方法就不需要激活切换机制,相反,使用快速同步方法时,你非得切换几次不可。好了,让我们看看真实的情况是什么样。Trinity客户端上的Beam同步

原型公布

一个新的阿尔法版本的Trinity客户端上周公布,这个版本包括一个可在高端硬件上运行的Beam同步方法原型。我们一直在测试针对主网的同步过程。通常可在第一个小时内执行第一个区块,多数时候都能在5分钟之内搞定!这里不包括下载区块头的时间和偶尔因为缺少好的对等节点所耽误的时间。注释:把区块GasLimit从8M提升到10M似乎会增加平均滞后时间,伊斯坦布尔升级后可能会减少滞后时间,因为提高了在区块链上写入状态数据所需的gas耗费量。目前Trinity还是阿尔法版本,最新的版本依然有很多问题,比如同步可能会在一两天后突然中止,即使没有中止,也会落后很多导致激活切换机制。安装Trinity客户端需要额外的工作,命令行输出更是一团糟。所以,Trinity目前只准备好了给那些既好奇、又不介意实际操作一下的开发者和研究人员使用。悬而未决的问题基本上都会在日常开发中暴露出来,所以这些问题都是“后台日志上的bug”。在这一点上,可以说,没有人担心BeamSync会不会是一个难以企及的梦想。这种对Beam同步的信心是崭新的。但我们也认为未来有可能有突发的未知问题亟待解决,就像一个月前一样!剩下的工作

除了基础的调试和实现工作,我们依然还有许多其它工作要做。Trinity还没有实现状态的回填机制。目前激活切换机制的唯一方法是重新启动Trinity,而且尚不清楚Beam同步方法所需的最低硬件配置。以上所有问题都处于积极的研发攻克之中,并且这只是Trinity上许多工作之一,感谢以太坊基金会对这些工作的赞助和支持。BeamSync的创新之处在哪里?

Beam同步方法,和其他的理论一样,都是建立在之前的研究工作之上的。通过下载最新状态、跳过旧区块执行来加速同步的方法,并不是我们发明的。依靠见证数据而不是完整状态来执行区块,从而加速执行的方法,也不是我们发明的,详细情况可以看无状态客户端。真正的进展是我们综合了这两者:首先使用引导式快速同步来模拟无状态客户端,然后逐渐过渡到完全同步模式。我们丢掉了无状态客户端的一个优点,即低硬盘开销,但是我们保留了快速执行最近一个块的优点。通过在本地保存状态输入和状态输出数据,我们减轻了关于无状态客户端的一个重要隐忧,即被大量见证数据DOS攻击的风险,Beam同步方法执行的时间越长,被DOS攻击的风险越小。在我们运行以太坊本地客户端的时候,Beam同步模式可以提供更好的反馈和更快的执行结果,我们觉得这对于用户愉快地运行本地节点来说是重要的一步。感谢PiperMerriam、BrianCloutier、AlexStokes、VoithMascarenhas和NoelMaersk。

标签:BEABEAMTRITrinityBearn Defi ProtocolScotty BeamSTRI币Vrtrinity

DOT热门资讯
比特币:星球日报康康:美联储降息50基点对行情的影响_Planet Sandbox

《OK江湖录》由全球顶级交易所最专业最安全的数字资产交易平台OKEx主办的行业深度访谈栏目。主要内容是行情分析,市场政策,行情分析,技术指标,投资技巧,个人经验等.

1900/1/1 0:00:00
比特币:比特币秘史(二十四):中本聪如何在互联网内隐藏自己的身份?_比特币是什么时候有的

大家都知道,「中本聪到底是谁」是区块链领域最大的迷案;那么问题来了,他又是如何在网络发达的现如今成功隐身的呢?实际上,自这位比特币灵魂人物失踪之后.

1900/1/1 0:00:00
APP:加密货币钱包全景概览:生态系统、用户界面及最新进展_blockchainresearchandapplication

钱包是密码学货币世界里重要的基础设施。所有跟密码学货币相关的操作,包括买卖密码学货币、持有密码学货币、转账,乃至质押获利,多多少少都跟钱包相关.

1900/1/1 0:00:00
比特币:维基解密已获得4050个比特币捐赠,中本聪的担忧将重现?_INT

编者按:本文来自巴比特资讯,编译:kyle,星球日报经授权发布。维基解密在其旧地址上接受了超过4,043个比特币的捐款,价值高达3,900万美元.

1900/1/1 0:00:00
COM:继MakerDAO之后,还有哪些DeFi项目值得关注?_DAI

编者按:本文来自头等仓区块链研究院,Odaily星球日报经授权转载。目前,DeFi协议中最为瞩目的无疑是MakerDAO,它不仅是去中心化金融的主要参与者,还负责创建和管理DAI去中心化算法稳定.

1900/1/1 0:00:00
区块链:区块链开发者社区面面观_wpc币区块链

2月27号20:00,BlockManiaAMA直播第52期继续进行,本期为硬核技术系列,BlockMania致力于将区块链行业最深度的认知和思考带给行业与公众,欢迎其他社区跟我们合作.

1900/1/1 0:00:00