以太坊:以太坊2.0 Staking老司机指南:避免罚没的三大技巧

*重要免责声明*PrysmaticLabs对用户的资金损失不承担任何责任,无论原因是什么,包括客户端漏洞或文档错误,这种责任的免除延伸到了罚没过程。尽管每个以太坊2.0客户端都尽最大努力确保代码库是安全的,但与其他任何开发项目一样,总是会存在出错的可能性。参与以太坊2.0是一项有风险的活动,重要的是参与者需要研究并理解他们要承担的风险及责任。

什么是罚没?

当一个验证者表现出与以太坊网络相争对的行为时,就会发生罚没。罚没不一定是因为有恶意意图,它也有可能是因为错误的配置。验证者的行为可能会使得系统变混乱,或破坏其完整性,因此,这些对网络造成危害的验证者,其质押的ETH就会遭到惩罚,而这是不可逆转的。不要将罚没和不活动处罚混淆,罚没的目标是抑制那些试图伤害以太坊2.0网络的人,并反过来奖励那些按计划维护、管理和运营以太坊2.0网络的人。罚没的的主要目的是减轻在以太坊2.0网络上执行的攻击,例如在不同的历史检查点视图上创建相互冲突的验证者分支。正确遵循协议的验证器在正常操作中永远不会发出可遭到罚没的投票,验证器不会因为离线而遭到罚没。罚没的工作方式

罚没的行为会破坏掉那些伤害以太坊网络的验证者的质押资金,强迫他们离开网络,并通过促进好的参与者来加强区块链的安全性。尽管罚没是一种惩罚方式,但即便是一个正常用户,如果其验证器配置不正确,仍有可能遭到罚没。因此,了解如何正确设置和管理验证器客户端和操作系统是至关重要的,用户还应避免在不了解其全部功能的情况下尝试使用高级指令。在以下情况下,验证者会遭到罚没:验证器在同一个slot中使用不同的root提出两个冲突的区块。如果这类操作没有遭到惩罚,那么验证者就很容易创建不必要的分叉,或造成混乱。注:简单地提出相同的区块两次,并不会遭到罚没;验证器在同一个slot中证明两个冲突的区块。这被称为双重投票,也意味着验证者可能试图创建冲突的链分叉。注:简单地为相同区块投票两次,并不会遭到罚没;验证器投出的投票“包围”或被之前的投票“包围”,这意味着验证者试图投票反对历史,这种情况下就会遭到罚没;

以太坊网络当前已销毁243.18万枚ETH:金色财经报道,据Ultrasound数据显示,以太坊网络当前已销毁2,431,858.27ETH。其中,OpenSea销毁230,048.63枚ETH,ETHtransfers销毁225,263.05枚ETH,UniswapV2销毁133,542.10枚ETH。注:自以太坊伦敦升级引入EIP-1559后,以太坊网络会根据交易需求和区块大小动态调整每笔交易的BaseFee,而这部分的费用将直接燃烧销毁。[2022/6/11 4:18:15]

以太坊2.0surround投票,来自https://github.com/protolambda/eth2-surround遭到罚没后,会发生什么?

尽管存在多个防止罚没的机制,但每个验证器密钥对仅被一个验证器使用是至关重要的。这听起来很容易,但是当配置了多个验证器时,很容易错误地还原验证器并复制已经运行的验证器。进行更改时,请始终确认正在使用/恢复/设置正确的验证器密钥。你可以在这里找到一些其他资源。如果验证器遭到罚没,则会发生很多事情:遭到罚没的验证器被迫在36天内退出信标链;遭到罚没的验证器会面临三种惩罚类型;当被提议的举报人在一个区块中包含举报信息时,将受到最低处罚;在每个epoch周期开始进行惩罚,直到验证器离开退出队列;在举报信息被包括在一个区块内,以及遭罚没的验证器退出之间的中间时间,将实施特别处罚,这一特殊处罚与在此期间有多少其他验证器遭到罚没成比例。所适用的最大值,可达到相关罚没对象的所有有效余额。这意味着,如果验证器遭到罚没,它会立即受到惩罚,并将持续受到约36天的处罚,直到其可以退出为止,并且在18-36天的时间内,还会受到一次性罚款,而罚没的金额还受到同一epoch时期遭罚没的验证器数量的影响。有关更详细的说明,请访问此处。最后,值得注意的是,遭到罚没的验证器无法重新进入验证器集。如果验证者要继续验证,就需要进行新的质押以及生成新的密钥,而罚没是不可逆的!总的来说,遭到罚没会导致你质押的ETH不断变少,并在中途遭受重大损失。在36天后,你可以退出信标链,也可以撤回所有剩余的ETH,而在这36天的时间段内,你会损失很大一部分的ETH。会导致罚没的常见用户错误

以太坊Layer 2开发商StarkWare融资5000万美元,估值已达20亿美元:金色财经报道,使用ZK-rollups技术的以太坊第2层开发商StarkWare在C轮融资中筹集了5000万美元,其估值已达20亿美元。该轮融资由红杉资本领投,现有投资者参投,包括Paradigm、三箭资本、Alameda Research和Founders Fund。StarkWare联合创始人兼首席执行官Uri Kolodny表示,这是一次“机会主义”筹款,这意味着该公司已经盈利,但获得了新资金以尽快发展其团队和生态系统。Kolodny称,StarkWare将在本月晚些时候推出StarkNet。通过使用StarkNet,任何开发人员都可以无需许可地编写和部署他们的智能合约。[2021/11/17 21:56:02]

尽管上面提到的罚没场景对普通用户而言似乎是不可能发生的,但不正确的配置,很可能会导致诚实的验证者也会遭到罚没!以下是一些可能发生这种情况的场景:1、相同的验证密钥同时运行在两个服务器上,其中一个可能用作故障转移,以防第一个服务器出现故障。说明:这是最容易让你遭到罚没的方式,如果你的故障转移系统误报第一个节点已关闭,你可能会发现自己处在遭遇罚没的境地。请不要同时在两个地方运行验证密钥!2、你把密钥迁移至另一台计算机或另一个以太坊2.0客户端,而没有迁移你的罚没保护历史记录;说明:你的另一个节点可能有一个不正确同步的时钟,这可能会导致你遭遇罚没,如果你迁移了罚没保护历史记录,就可以轻松避开这种情况。3、你在验证器客户端中删除或丢失了罚没保护历史记录;说明:失去罚没保护历史记录,可能会导致一些问题,比如你的时钟被弄乱,从而产生会遭到罚没的区块或投票。4、使用没有持久卷的容器化环境进行验证说明:如果你使用Docker运行,或者可能在云环境中运行,则需要为验证器设置持久卷,这样,如果pod或容器重新启动,则不会清除罚没保护历史。5、可能导致罚没错误的协议漏洞说明:测试网上发生的大规模罚没事件的催化剂,通常是由于客户端实现中的漏洞。但是,具有罚没保护数据库和正确配置的验证器并没有受到影响。这些示例包括时间服务器故障以及区块ID处理不当的错误。当Medalla测试网中发生服务器故障时,大多数验证器都遭到罚没了,因为它们没有一个持久化的罚没历史数据库。选择验证器时,了解如何设置、配置,升级和排除任何已安装软件的故障是至关重要的。在这里可以找到一个很好的资源来更好地理解参与以太坊2.0Staking的风险,这里还有另一个解释如何检测罚没条件的资源。谁在实行罚没?

Reality Cards将迁移至以太坊扩容解决方案Polygon:官方消息,基于NFT的预测市场Reality Cards将从xDai迁移至以太坊扩容解决方案Polygon。[2021/7/29 1:22:38]

罚没者罚没器是指一个单独的软件,其主要目的是检测可罚没的事件。你可以把罚没器想象成以太坊2.0网络的“警察”,由于检测恶意消息所需的额外数据和进程,通常这些罚没器是独立于信标节点运行的。为了检测可罚没的消息,罚没器记录网络上每个验证器的证明和提议历史记录,并将该历史记录与广播的内容交叉引用,以找到可罚没的消息,例如双重区块或surrounding投票。网络所需要的是一个诚实的罚没器客户端来监视网络,因为发现的任何罚没都会传播到整个网络,以便尽快将其放入一个区块中。举报人奖励为了激励罚没检测,验证器将获得一种“举报人奖励”,这是在信标链上对提交具有任何有效罚没的区块的奖励。这些奖励是给予那些参与罚没的验证者的,通常每个验证者大约有0.1ETH奖励。虽然激励检测是有价值的,但如果你在Prysm中发现了罚没,仅运行一个罚没器客户端是不会获得举报人奖励的。默认情况下,发现的任何罚没都会广播到网络以尽快包含在区块中,因此,通常在检测到罚没后,奖励会立即发给提议者,而不是发给运行罚没器的验证者。运营一个罚没器并不意味着有利可图。罚没本就是罕见的,举报人奖励也被设置地很低。本质上,运营罚没器相当于一种利他行为,再次强调,网络中只需激活一个诚实的、功能正常的罚没器,即可捕获到违规行为。幸运的是,这是低门槛的,我们设想会有相当多的用户和实体将运行罚没器来确保网络安全。罚没预防针

动态 | 以太坊开发者大会ETHDenver进行加密货币支付的餐车实验:以太坊开发者大会ETHDenver进行使用加密货币DAI支付的餐车实验。实验结果显示,ETHDenver大会参会者使用DAI进行支付购买餐车食物的交易有60%成功,但还有40%的交易并未成功。据悉,ETHDenver内部许多讨论都涉及通过分散金融(DeFi)创收,但加密货币最基本的用途(作为一种支付手段)仍在开发中。[2020/2/17]

我们有好消息要告诉大家,罚没是可以预防的!有很多最佳实践可确保我们不会遭到罚没,但重要的是要了解它们。1、本地罚没保护数据库

一种由多个客户端实现的罚没保护方法是本地签名历史数据库。该功能在Prysm的验证者客户端中是默认启用的。该数据库确保验证器根据其自身的历史记录不对被视为可罚没消息的消息进行签名。更简单地说,验证器在决定是否应对消息进行签名时,会将数据库视为其唯一的真实来源。这种方法确保单个验证器不会执行重复的操作。需要注意的是,本地罚没保护无法防止使用相同的验证器密钥运行多个验证器实例。该数据库仅跟踪该本地实例中验证器的签名事件。这也意味着,如果用户将其验证器更改为其他客户端,或转移到新的硬件设置,那么还必须迁移签名历史数据库。这将确保在任何新客户端上保留过去操作的历史记录。2、远程罚没保护

防止罚没的另一种替代实现方式是使用罚没器。罚没器记录它收到的所有证明和区块,验证器在同意签署消息之前会引用它。与本地签名历史数据库相比,这种方法是一种更强的罚没保护方式,但与数据库一样,此方法无法防止运行同一验证器的多个实例。防止罚没的另一种实现,是将罚没器本身用作信标节点和验证器客户端之间的中间件。在验证器客户端提交区块或证明之前,它首先询问罚没器这是否是可罚没的。如果检查通过,数据将通过信标节点。这是最先进的罚没保护形式,因为理想情况下,罚没器了解网络中发生的所有事件,并记录了每个验证器的区块和证明历史。但有一点需要注意的是,在Prysm中,远程罚没保护还没有优化,因为我们的罚没器仍然是资源消耗大户。鉴于我们的罚没器资源消耗很高,这可能会导致你的验证器错过证明或区块。远程罚没保护旨在作为本地罚没保护之上的附加层运行。出于安全原因,用户无法在Prysm中禁用本地罚没保护。3、迁移你的罚没保护历史

分析 | 以太坊波动率创下三个月以来最低点 指标表明它正进入“危险区域”:据Skew Markets数据,与比特币相比,以太坊的市场波动率已创下三个月以来的最低点,许多其他指标也都表明以太坊正在进入一个“危险区域”。 和比特币今年大涨不同,以太坊今年仅比去年同期增长31.77%,而同一时期的比特币价格增幅已经超过 160%,这意味着可能会触发市场短期抛售,投资者可能也会遭遇持续的价格跌势。 由于比特币和黄金吸引了人们的注意力,这两个资产最近也被人们称为是在全球经济不稳定时期的“避风港”。相比之下,以太坊在很大程度上被忽视了。以太坊链上交易数量已经跌至2017年12月牛市之前的水平。另一方面,以太坊挖矿算力也受到了很大打击,从今年二月开始算力增长也在放缓。 Blockstream首席战略官Samson Mow认为,以太坊已经进入到了一个死胡同。(Bitcoinist)[2019/9/3]

在验证过程中的某个特定时刻,质押者可能需执行的一个重要活动,是将其验证密钥迁移到另一台机器或不同的以太坊2.0客户端。有时,你可能希望切换Staking机器,或者你可能希望迁移到适合你的不同的以太坊2.0客户端。无论如何,你都应始终携带好你的罚没保护记录。

罚没保护标准:EIP-3076目前有一个官方标准用于迁移以太坊2.0客户端之间的罚没保护历史记录,它被称为EIP-3076。该标准建议在JSON文件中表示验证器的罚没保护历史记录。该文件包含了:有关验证历史记录的链的初始状态信息;有关用户正在运行的验证器公钥的所有签名区块以及签名证明信息;通过导出此文件,并在迁移到另一台计算机或以太坊2.0客户端时导入它,你将获得大量好处,并能够免受未存储此本地历史记录的情况下的简单罚没条件。将现有的验证密钥导入Prysm截至发稿时,在Prysm的v1.0.1版本中,Prysm不允许用户将EIP-3076罚没保护JSON文件导入验证器客户端。这是Prysm团队的首要任务,可能会在以太坊2.0主网上线后的下一个版本中实现这个功能。从Prysm导出你的罚没保护历史截至发稿时,在Prysm的v1.0.1版本中,Prysm不允许用户将罚没保护历史记录导出到EIP-3076罚没保护JSON文件中,同样的,Prysm团队正在抓紧实现这一目标。如果你确定希望迁移机器,我们建议你等到Prysm支持导出罚没保护历史记录之后。如果实在等不及,请记住以下一些重要事项:关闭你的信标节点以及机器1上的验证器,确保它没有作为系统进程运行。你可以使用操作系统的进程监视器工具或命令行工具进行检查,并检查是否包含名称“prysm”,“validator”或“beacon”。请注意你的钱包目录位置。如果你在启动Prysm时使用默认值,则可以在“验证者帐户列表”输出的顶部查看其路径,该路径因操作系统而异。获取整个目录并将其迁移至你的下一台计算机。如果你修改了验证器的datadir,也请将该目录迁移到下一台计算机。至少等待几个epoch时间段,在第二台机器上同步信标节点,然后在第二台机器上启动验证器客户端。确保不在机器1或其他任何地方运行相同的密钥。

郑重声明: 本文版权归原作者所有, 转载文章仅为传播更多信息之目的, 如作者信息标记有误, 请第一时间联系我们修改或删除, 多谢。

地球链

POL币最新价格比特币:比特币是最大的“大空头”?

大空头——派拉蒙电影公司当目标金融工具价格下跌时,卖空者就会赚钱,但他们并不总是受到企业或政府领导人的欢迎。那些对股票或货币进行反面押注的人,往往被描绘成破坏人们努力建设、发展和创造价值的鲨鱼.

[0:15ms0-0:873ms