澳洲幸运5
热门标签

皇冠信用网:以太坊单双博彩(www.326681.com)_若何实现区块构建者角色的去中央化?

时间:3周前   阅读:1

新加坡telegram群组www.tg888.vip)是一个Telegram群组分享平台,飞机群组内容包括telegram群组索引、Telegram群组导航、新加坡telegram群组、telegram中文群组、telegram群组(其他)、Telegram 美国 群组、telegram群组爬虫、电报群 科学上网、小飞机 怎么 加 群、tg群等内容,为广大电报用户提供各种电报群组/电报频道/电报机器人导航服务。

本文主要围绕 Vitalik 最近的 SBC MEV 钻研会演讲而构建,并提供进一步的剖析。

原文题目:《若何实现区块构建者角色的去中央化?这里有两种方式》(Decentralizing the Builder Role

撰文:Jon Charbonneau

弁言

快速回首——本讲述的一个要害主题是 Vitalik Buterin 在《终局游戏》一文中的想法,即所有前进蹊径似乎都通向:

生产者 - 构建者星散(PBS)试图将中央化与构建者隔离(远离验证者),然后以太坊添加盔甲(例如 crList)以减轻构建者的审查权力。构建者自然会很老练,以是悬而未决的问题主要是他们的中央化水平。我们是在说 1 个构建者?照样 10 个?

一其中央化构建者仍然不理想,那么我们能做得更好吗?解决这个问题有两种方式:

    • 去中央化构建者角色自己 —— 使获胜的构建者自己成为去中央化的协议。一组去中央化的介入者都有助于构建一个给定的区块。

    本讲述主要围绕 Vitalik 最近的 SBC MEV 钻研会演讲而构建。我将把它剖析并提供进一步的剖析。

    去中央化的构建者能胜出吗?

    这里现实上有两个潜在的问题:

    • 手艺可行性——我将先容一些可行的路径(存在其他可能性,而且正在起劲探索中)

    • 竞争力——用户真的想使用它吗?或者一其中央化构建者总是会在功效和效率上胜已往中央化构建者?

    去中央化什么?

    中央化构建者很容易。下面思量了一些可以去中央化的漫衍式构建者,需要在许多搜索者和用户之间聚合捆绑和生意:

    • 算法 - 构建者运行算法来聚合搜索者的捆绑包和其他生意,然后自己填写区块的其余部门。该算法及其输入可以涣散。(请注重,这里假设漫衍式构建者仅运行一种算法的简朴情形。现实上,漫衍式构建者中的差异介入者可能在运行差异算法时孝顺区块的差异部门。)

    资料泉源:基于 Vitalik Buterin 的图片

    • 资源 - 资源需求将显着增添,尤其是使用 Danksharding。区块将携带更多数据而且构建起来加倍庞大→构建它们的带宽和硬件要求更高。不需要一个节点来构建和分发整个区块,而是可以在多个节点之间拆分事情。

    • 分外的构建者服务——构建者可以施展创意并提供新的服务,例如生意预确认。为了使漫衍式构建者取得乐成,他们需要提供与中央化构建者相比具有竞争力的服务。

    • 接见订单流(orderflow)——将订单流发送给单个构建者异常简朴,而且可以为用户带来利益。也许他们答应不抢跑你的生意,他们可以在你后面给你一些回扣。在潜在的许多介入者之间涣散对订单流的接见是对照棘手的。

    • 隐私——同样,信托您的订单将私下执行的构建者是最容易的,因此您可以将其发送给他们。漫衍式构建者需要一种方式来提供生意隐私,同时在此历程中还包罗许多去中央化方。

    • 跨链执行——漫衍式构建者需要一种与外部介入者协调以捕捉跨链 MEV 的方式(例如,若是链 Y 上的交流将以原子方式完成,则仅在链 X 上完成交流)。

    挑战

    若是我们想在整个区块生产供应链中避开受信托的第三方,有几个障碍需要战胜。我将在这里解决的一些挑战包罗:

    若何珍爱搜索者免受 MEV 窃取?

    若是建设者看到搜索者提交给他们的捆绑包,他们可以复制生意,然后用他们自己的地址替换搜索者的地址。构建者在不奖励搜索者的情形下捕捉了 MEV。

    神圣(enshrined)PBS 和 MEV-Boost(加上中央可信中继)中使用的提交披露方案从提议者 ←→ 构建者关系中消除了同样的 MEV 窃取威胁,但对于搜索者 ←→ 构建者来说,这是一个未解决的问题。搜索者现在只信托构建者,但信托不是可扩展的解决方案。

    若何允许聚合器机制组合搜索者输入?

    珍爱搜索者免受 MEV 窃取意味着他们的捆绑包不能以明文形式发送。然则,若是它们不在明处,那么构建者若何聚合它们呢?

    若何保证聚合器机制能够真正宣布这个区块?

    捆绑内容最终必须明确。从密文→明文的历程是什么,我们若何在没有信托假设的情形下实现这一目的?

    若何珍爱搜索者免受聚合者 + 提议者勾通?

    请注重,这并不是构建漫衍式构建者所面临的挑战的详尽列表。另有其他悬而未决的问题(例如,您若何防止漫衍式构建者受到他们被迫模拟的大量不良捆绑包的 DDOS 攻击?)和未知的未知数。

    想法 1 - 可信硬件

    一种方式行使可信硬件 - TPM(可信平台模块)。排序如下所示:

    在解密区块之前,TPM 必须确信两件事:

    • 提议者署名 - 这种对区块头的答应(没有看到区块体)防止提议者窃取 MEV。若是提议者在构建者区块体被公然后(通过提议替换区块)试图为自己窃取 MEV,任何人都可以提出他们最初的答应。这证实提议者在相同的区块高度签署了两个区块→他们被削减了。

    • 提议者署名的可用性证实 - 防止聚合者 + 提议者勾通。提议者的答应存在是不够的——它必须是可用的。若是只有聚合器收到答应,他们可以简朴地永远隐藏它,允许提议者提出替换的 MEV 窃取区块。TPM 必须确信最初的提议者署名现实上是公然的。

    有几种方式可以证实提议者署名的可用性:

    • 证实者 - 验证者可以证实看到提议者署名,然后 TPM 可以检查提议者和这些证实者署名。这需要更改以太坊协议。

    • 低平安性实时数据可用性预言机——像 Chainlink 这样的器械可以证实署名存在并将被重新广播的事实。

    • 聚合器内的 M of N 假设 - 聚合器自己可以是漫衍式 M of N 协议。聚合器协议中可能存在阈值投票,您对此有一个忠实的假设。

    想法 2 - 合并不相交的捆绑包温顺序拍卖

    合并不相交的捆绑包

    这种方式需要 M of N 聚合器,但我们可以脱节 TPM。该历程如下所示:

    • 搜索者发送加密到一个阈值密钥的捆绑包。捆绑包包罗接见列表(他们接见的帐户和存储槽的列表)和准确性 SNARK(注重快速天生此内容的手艺庞大性)。

    • 聚合器合并不相交的捆绑包,使总出价(bid)最大化。(我们在这里只讨论聚合不相交的出价,但有可能进一步改善这一点。)

    • 聚合器必须盘算状态根

    最后一步很棘手。盘算状态根需要清晰地看到生意,或者至少看到它们的状态更新。然而,纵然看到状态更新也可能足以举行 MEV 窃取。对于何时盘算状态,我们有几个选项:

    • 让一个聚合器节点解密然后盘算状态。然则,他们可以与提议者勾通。

    • 只有在提议者答应支持吸收到的任何区块和状态根之后,才盘算状态根。这种设置将行使 EigenLayer - 提议者让自己受到分外的削减条件才气介入。提议者发送一条链下新闻,答应他们将依次天生的唯一区块是包罗这组捆绑包(无论它们是什么)的区块。只有在提议者做出答应之后,捆绑包才会被解密,并盘算状态根。若是提议者违反了这一答应,那么他们将被削减。

    请注重,对于此 EigenLayer 组织,也可以阻止前面提到的 SNARK 要求。这里的提议者可以预先提交一个替换区块或替换区块组合,若是提交给他们的区块或替换区块组合被证实是无效的。然后可以使用一个诓骗证实来检查第一个区块组合的无效性。

    顺序拍卖

    EigenLayer 手艺可以直接用于不相交的捆绑合并,或者它可以依赖于每个插槽内的多轮顺序拍卖。(请注重,若是需要,也可以在此顺序组织中阻止 SNARK 要求。)

    例如,以下可能发生在一个区块中:

    第 1 轮

    1. 提议者签署一个 EigenLayer 新闻,预先赞成一些生意(包罗捆绑 1),从而在这一轮中最大化他们的出价以启动区块

    2. 构建者宣布该区块的这一部门

    3. 提议者宣布状态差异

    第 2 轮

    4. 提议者签署一条 EigenLayer 新闻,预先赞成分外的生意(包罗捆绑 2),从而在本轮中最大化他们的出价以继续这个区块

    5. 构建者宣布该区块的这一部门

    6. 提议者宣布状态差异

    第 3 轮…

    一个瑕玷是这种合并可能不是最理想的。例如,提议者可能已经预先赞成捆绑包 1,然后他们收到了与捆绑包 1 冲突的更有利可图的捆绑包 2。他们将不得不拒绝此捆绑包 2。

    具有相同订单流的中央化构建者可以看到所有生意,当他们在插槽末尾构建区块时可以包罗捆绑包 2(由于他们没有预先赞成捆绑包 1)。

    另一个潜在的瑕玷 - 顺序拍卖可能会使非原子 MEV 变得异常难题,由于若是天下状态发生转变,搜索者将无法作废或更新他们的出价(一旦答应)。若是您需要在生意被包罗之前 10 秒以上提交生意,那么若是您保留更新出价的能力,您将无法肩负尽可能多的风险。

    然则,该示例假定相同的订单流。现实上,由于它提供的保证,这种漫衍式构建者可能能够在吸收更多订单流方面胜过中央化构建者。更好的保证 → 更多的订单流 → 构建最有利可图的区块(纵然有其他瑕玷)。然后,由于漫衍式构建者始终提供最高价值的区块,因此提议者选择这种结构(切断自己接受其他构建器的区块)将具有经济意义。

    ,

    以太坊开奖网

    ,

    皇冠信用网www.hg108.vip)是一个开放皇冠信用网即时比分、皇冠信用网开户的平台。皇冠信用网平台(www.hg108.vip)提供最新皇冠信用网登录,皇冠信用网APP下载包含新皇冠体育代理、会员APP,提供皇冠信用网代理开户、皇冠信用网会员开户业务。

    ,

    www.326681.com采用以太坊区块链高度哈希值作为统计数据,联博以太坊统计数据开源、公平、无任何作弊可能性。联博统计免费提供API接口,支持多语言接入。

    ,

    为了取得乐成,漫衍式构建者提供的价值可能需要跨越它带来的瑕玷(包罗效率较低的合并和非原子 MEV 的挑战)。

    区块构建 post-Danksharding

    Danksharding 使验证者的节点要求较低。单个节点只认真下载区块的一部门。

    然而,最初提出的设计将有意义地增添构建以太坊区块的硬件和带宽要求(只管验证者总是可以以漫衍式方式重修)。那么问题是我们是否甚至可以以漫衍式方式举行初始构建。这将消除对单个高资源实体构建完整区块、盘算所有 KZG 答应、毗邻到许多子网以宣布它,等等。

    (注重:这个架构是否会使用子网或类似 DHT 的开放研究问题,但我会在这里假设子网)。

    现实上很有可能以漫衍式方式构建。漫衍式纠删码甚至没有那么难。

    首先,包罗每个数据生意的人认真对其举行编码并将 blob 区块流传到子网和数据可用性网络。

    当聚合器选择包罗哪些数据生意时,他们可以使用实时 DA 预言机。聚合器不能只自己举行数据可用性采样 (DAS),由于当只有一方举行 DAS 时,这并不平安。以是一些漫衍式预言机需要下载整个器械。

    然后网络可以从这里填写列。请记着,数据在此 2 D 方案中获得扩展。例如,每个 blob 是 512 个 chunks,但它被擦除编码为 1024 个 chunks。然后扩展也垂直运行。例如,您在此处说图像中有 32 个 blob,然后垂直扩展为 64 个 blob。多项式答应在每行水平和每列垂直运行。

    资料泉源:Vitalik Buterin

    KZG 答应

    由于 KZG 答应的线性,你可以填写这些列,这将用于以太坊的分片设计。

    KZG 的答应 (com) 具有线性关系。例如,您可以说 com (A) + com (B) = com (A+B)。

    你在证实中也有线性。例如,若是:

    • Qᴀ 证实 A = 在某个坐标 z 处的某个值,而且

    • Qʙ 证实 B = 在统一坐标 z 处的某个值,则

    • 您可以对 Qᴀ 和 Qʙ 举行线性组合,这自己就是证实 A 和 B 的相同线性组合在相同坐标 z 处具有准确值

    更正式地说:

    • 让 Qᴀ 证实 A (z) 和 Qʙ 证实 B (z)

    • 然后,cQᴀ + dQʙ 证实 (cA + dB)(z)

    这种线性属性允许网络填入所有内容。例如,若是您有第 0 列中第 0-31 行的证实,那么您可以使用它来天生第 0 列中第 32-63 行的证实。

    只有 KZG 具有这种答应线性和证实线性(IPA 和 Merkle 树,包罗 SNARK 的 Merkle 树不能同时知足这两个)。

    要更深入地领会以太坊的 2 D KZG 方案,您可以查看我的以太坊讲述或 Dankrad 最近的 KZG 演讲。Vitalik 的这篇研究文章‌还谈到了将 KZG 与 IPA 用于 DAS 的思量因素。

    这里的 TLDR 是 KZG 有一些异常好的属性,允许漫衍式区块构建和重修。您不需要任何一方来处置所有数据、扩展所有数据、盘算所有 KZG 答应并流传它们。它们可以为每一行和每一列单独完成。若是这样做了,我们就没有剩余的超级节点要求:

    资料泉源:Dankrad Feist 和 Vitalik Buterin

    非 KZG 替换选择

    若是我们无法实现所有 KZG 邪术,那么这是下一个最佳选择。

    行答应的前半部门只是 blob,以是没有问题。然后,构建者必须提供其余部门和一些列答应。

    然后这些答应必须匹配。以是 jᵗʰ 坐标处的 iᵗʰ 行答应 = iᵗʰ 坐标处的 jᵗʰ 列答应。

    更正式地说:

    • 构建者必须提供行答应 R₁…Rₕ 和列答应 C₁…C?,其中 Rᵢ(xⱼ) = Cⱼ(xᵢ)

    • 以及答应等价的证实

    • 这可以像讨论的那样以漫衍式方式完成,但请注重,这样做更难:

    • 前面形貌的 KZG 方式 - 可以在一轮中完成。构建者只检查所有 blob 然后宣布。网络在不涉及构建者的完全自力的历程中填充行。

    • 此处的漫衍式方式 - 至少需要两轮协议。构建者需要介入。

    分外的构建者服务 - 预先确认

    以太坊区块时间很慢,用户喜欢快速的区块时间。以太坊做出这一牺牲主要是希望支持一个大型去中央化验证者集——Vitalik 在这里写过的权衡空间。然则我们能做到一箭双鵰吗?

    以太坊 rollup 用户已经领会并喜欢这些预先确认。构建者创新也许能够在基础层提供类似的服务。

    例如,构建者可以赞成:

    • 若是用户发送优先级用度 ≥ 5 的生意,构建者会立刻发送一个可执行的署名新闻,赞成将其包罗在内。

    • 若是用户发送优先级用度≥ 8 的生意,构建者甚至提供后状态根。因此,较高的优先级用度迫使生意以某种顺序被包罗在内,从而使用户可以立刻知道该生意的效果是什么。

    若是构建者不推行他们的答应,他们可能会被削减。

    在具有并行化 EVM 的未来,您还可以通过预先确认获得更高级的信息。例如,只要用户体贴的状态没有改变,纵然在给出预先确认之后,构建者也可以重新排序一个区块中的一些生意。

    漫衍式构建者可以提供预先确认吗?

    是的。漫衍式构建者可以运行一些内部共识算法,例如具有快速出块时间的 Tendermint。构建者可能会因以下缘故原由受四处罚:

    • Tendermint 机制内的双重确定性

    • 签署与 Tendermint 机制认同的内容不兼容的区块

    请注重,为了在此处获得最佳平安性,需要对最终构建者署名举行某种帐户抽象。阈值 BLS 是不能归因的——这意味着若是建设者只是 BLS 签署区块,若是泛起问题,我们将不知道该削减谁。抽象署名将解决这个问题。

    对于任何构建者预确认服务(漫衍式或中央化的),请注重,预确认仅与他们现实构建获胜区块的能力一样好。具有更高包罗率的更占主导职位的构建者可以提供更好的预确认。

    然则,您现实上可以通过漫衍式构建者获得更强的预先确认,例如 EigenLayer 组织。若是当条件议者选择了 EigenLayer 而且您获得了预先确认,那么您的生意必须包罗在内。您不再押注于中央化构建者的概率赔率,给您一个预先确认然后最终是否赢得区块。

    漫衍式构建者的优瑕玷

    假设所有的手艺都乐成了,漫衍式构建者有成千上万的介入者。你甚至可以让大部门以太坊验证者选择加入提供亚秒级预确认的 EigenLayer 组织。与中央化构建者相比,这种漫衍式构建者具有一些不错的竞争优势:

    • 经济平安——支持预确认服务的巨额平安存款

    • 信托——搜索者可以信托这个漫衍式构建者,而不是单其中央化实体

    • 抗审查——与决议恶意的单其中央化运营商相比,损坏和控制任何平安的漫衍式系统都加倍难题

    中央化构建者可能具有其他优势,一些是固有的,一些基于漫衍式构建者的组织:

    • 更快地顺应新功效——顺应市场需求的天真性是有价值的,而这可能是上述漫衍式构建者组织所缺乏的。理想情形下,您可以未来自多方的怪异功效聚合到一个区块中。

    • 更低的延迟——这总是相关的,但对于跨链 MEV 尤其云云,当天下状态跨域转变时,搜索者更有可能想要更新他们的出价。(如前所述,他们还希望首先在整个区块历程中天真地修改出价。)

    结论性想法

    以太坊在很洪水平上是凭证最坏情形假设设计的——纵然只有一个构建者存在,我们若何才气最好地减轻他们的权力(例如,审查能力)?

    然而,我们可以(而且应该)同时起劲阻止这种最坏情形的假设。这意味着设计一个并不总是导致根深蒂固的中央化构建者的系统。这里形貌的两个想法提供了一些更有趣的可能性。然而,它们远不是一个详尽的清单——其他想法正在起劲探索中,而且应该继续探索。

    此外,这不应被视为「专有订单流的问题神奇地消逝了,因此我们不再需要围绕它举行构建。」dApps 必须继续围绕 MEV 举行机制设计创新,包罗削减对专有订单流的需求。MEV 不会去任何地方。

    稀奇谢谢 Vitalik Buterin、Sreeram Kannan、Robert Miller 和 Stephane Gosselin 的审阅和意见。没有他们的事情,这份讲述是不能能完成的。

    查看更多

    上一篇:三公最明智的打法(www.eth108.vip):Tránh con gà, một học sinh tử vong do va chạm với xe ôtô

    下一篇:chơi tài xỉu(www.84vng.com):名建筑师为城市化靓妆 施家殷最爱挑战旧变新

    网友评论