主页 > 华为手机怎么安装imtoken > 一个解决区块大小的提议——弹性区块大小

一个解决区块大小的提议——弹性区块大小

华为手机怎么安装imtoken 2023-01-26 05:14:12

具有滚动惩罚的弹性区块上限最近有很多关于是否应该放宽区块链大小 1MB 限制的讨论。 已经提出了很多观点,但最常见的经典权衡如下:

具有滚动惩罚的弹性区块上限最近有很多关于是否应该放宽区块链大小 1MB 限制的讨论。 已经提出了很多观点,但最常见的经典权衡如下:

更大的块 -> 更难运行节点 -> 更少的节点 -> 更中心化

更小的区块 -> 较少的直接支付 -> 更依赖第三方支付处理解决方案 -> 更中心化

大部分人认为这个权衡应该有一个最优值,也会讨论这个最优值是什么,如何确定这个最优值,如何围绕这个最优值做出更好的决策等等。 绝大多数人认为,如果区块太小,我们可以增加交易费用来维持比特币网络的运行。

然而,迈克说这不是比特币网络的运作方式(我倾向于同意他的看法)。 相反,如果区块限制对于交易需求来说太小,比特币网络就会崩溃。 在我看来,他的论点的要点是,市场力量应该在交易供应与需求相匹配的情况下找到费用平衡。 然而,市场力量对波动的反应不够迅速,造成软件无法处理的技术积压。

Mike 还认为,既然我们不知道什么时候会达到上限,但一旦达到,我们就会措手不及,所以我们必须迅速提高上限以确保安全。 在这方面我有一个问题——如果比特币在交易量增加的情况下不能适当贬值,那么无论当前的区块大小上限如何,我们都会遇到很多问题。 我们应该集中精力解决这个问题。

在这里,我将介绍一种可能的解决方案——协议修改。 我会分析它是如何工作的。 有了它,我们就没有大幅下跌的风险,只会增加费用。

然后,让我们谈谈基于上述权衡的关于块大小应该是多少的争论。

递延费用池

该提案要求使用滚动费用池作为先决条件。

最初的想法是,交易费用将支付给一个矿池,而不是支付给区块的矿工,然后逐渐支付给该矿池中未来的矿工。 例如,在任何一个区块,矿工有权获得当前池中资金的 1%(不包括任何其他区块奖励)。

根据目前的提议,我们将使用这样一个池,其中随着时间的推移进行支付——但不是用户将钱投入池中。 交易费用通常会支付给构建区块的矿工。

ps:为了清楚起见,我再说一遍---在目前的提议下,交易费将立即全额支付给当前区块的矿工。 矿工通过接受带外交易费用一无所获。 如下所述,是矿工自己将钱放入递延费用池。弹性区块上限

该提案的核心是惩罚而不是禁止大区块。 拥有大区块的矿工必须根据区块的大小支付清算费用。 罚款将从他在区块创世交易中收到的资金中扣除,并将支付到递延费用池中,由未来的矿工分配。 如果惩罚超过矿工的交易手续费收入+铸币+他在当前递延手续费池中的收入,则该区块无效。

这需要选择一个函数 f 来返回给定块大小的惩罚。 这提供了很大的灵活性,如果我们选择了“错误”的功能,仍然很少会出错。 主要要求是它是凸的,在我们认为的块大小中具有明显的曲率。 我的建议是:选择一个目标块大小 T。然后对于任何给定的块大小 x,设置 f(x)=Max(xT,0)^2 / (T*(Tx))。 (图表)

这意味着当区块大小达到 T 时不会有任何惩罚。随着区块大小的增加,任何额外的交易都会产生惩罚——一开始可以忽略不计比特币区块上限大小,但最终会大幅增长。 禁止出现大于 2T 的块。

分析

我认为我们真的需要区块链的稀缺性——这可以防止无用的交易使区块链膨胀,并使运行节点变得更加困难,并激励用户为比特币基础设施提供资金。 块大小限制会造成稀缺性,但前提是确实存在达到限制这样的事情。 但就目前情况而言,达到极限会导致技术故障。

迈克称这个问题为“跌得太厉害”,但对我来说更像是撞墙。 达成协议的需要被推向了极限,没有什么可以减缓它,直到它痛苦地撞到墙上。 本来区块里还有多余的空间,没理由收手续费,突然间就没有空间了,就出问题了。

如果进入网络的交易数量多于可以添加到区块中的数量,那么队列会变大并需要数小时才能清除,这意味着交易将需要数小时才能确认。 矿工可以通过手续费引导市场,适度新增交易,但市场反应太慢。 首先比特币区块上限大小,因为软件没有针对接收此信号进行优化,其次,因为短期内交易需求缺乏弹性。 如果在一段持续的时间后,交易费用很高,我将停止寻找用比特币支付的地方,并注册支付便利服务。 但在短期内,如果我有一笔交易设置为立即发送(例如餐厅标签),如有必要,我愿意为此支付很高的费用。 所以手续费不能有效控制交易的泛滥。

输入弹性帽。 当交易需求超过目标块值时,积压不会累积——矿工只需将额外的值包含在块中。 他们会开始要求一点额外的费用来补偿罚款,但仍然可以按照交易完成的速度清算。 如果传入交易的速度继续增加,矿工需要为任何一笔交易支付的边际罚款将会增加,因此费用会更高——但由于这个过程是渐进的,客户将有时间欣赏快速确认需要什么费用要支付。 这个过程就像爬山而不是撞墙。 当我们接近区块上限时,弹性会变得更强,直到我们达到平衡。

随着时间的推移,市场将了解典型的费用并做出决定。 它可以分析一天或一周中费用较低的时段,并使用这些时段进行对时段不敏感的交易。

有了硬上限,交易团队只能以一定的速度清除。 低于这个利率没有费用紧张,高于它就有不稳定。 对于弹性上限,更长的队列会导致更高的交易费用,从而鼓励矿工在区块中接受更多交易,从而提高队列被清除的速度。 这是一种稳定的平衡,可以防止交易队伍无休止地增长,同时持续保持一定的费用紧张。

顺便说一句,当前系统是该提案的特例,f(x) = if (x

前进的道路

我认为此解决方案几乎没有缺点。 即使超调没有 Mike 认为的那么糟糕,它仍然有用。 该原型还可以用于其他可能的协议改进。 我相信这是一个本质上简单而充满活力的想法。 所以我希望它能在没有太多争议的情况下被接受。

然而,这是一个重大变化,可能需要一些重要的编码。 在和Gavin讨论这个想法时,他说如果他能写出测试代码,他就能更好地评估它。 尽管写代码不是我的强项。 如果有人有兴趣尝试一下,我很乐意提供帮助。

原文: 作者:Meni Rosenfeld 译者:yyy 译者比特地址:1AZ8NqLgxnhxZSH44V1RhxuUp6Z6a4nhF6 责任编辑:printemps 稿件来源(译):巴比特信息