Ξ

    Search by

    以太七日谈 • 2021/6/8

    Uniswap V3 部署在 Arbitrum；zksycn 2.0测试网上线

    E

    ECN       2021-06-08

    8

    Eth2

    Lighthouse可以在Windows上跑了

    Lighthouse客户端将于六月中旬上线的 v .1.4.0 版本加入了对 Windows系统的支持，目前仅支持Windows 10，Windows 8 和 7 还未测试。

    教程指路：https://www.reddit.com/r/ethstaker/comments/nre9tz/how_to_compile_and_run_lighthouse_on_windows/


    Eth1

    Geth的快照同步功能已成默认设置

    Geth 客户端在 v.1.10.4 版本里把同步的默认设置从快速变为快照同步，同步时间从大约11小时缩短到2小时。团队负责人Péter Szilágyi表示实现这点花了3.5年的时间。

    geth

    来源：https://twitter.com/peter_szilagyi/status/1399266019407970305?s=20


    伦敦升级新测试网 Calaveras

    伦敦升级的新测试网 Calaveras 已上线，这意味着上周的核心开发者会议提出的，关于MaxFee和maxPriorityFee没有形成一个明确的上限，这一问题已解决。

    来源：https://github.com/ethereum/eth1.0-specs/blob/master/network-upgrades/client-integration-testnets/calaveras.md


    EIP-1559 GAS API会议

    Tim Beiko对上周进行的 EIP-1559 GAS API 会议进行了总结，列出了1559 API愿望清单，内容包括：

    priority fee历史数据

    • 返回过去N个区块中被接受的最低 priority fee 的列表，
      • 矩形图？
      • 前十分位的数而不是最低值？
      • 客户端应该把满的区块过滤了，因为在这种情况里，矿工可能会漏掉那些本可以被放进待处理交易池里，也就是说我们可能实际上不会在被打包的交易里看到给矿工的最低小费
      • 考虑点：我们可以把矿工自己的交易过滤掉吗？起码我们应该过滤掉任何小费是0的交易

    消耗的gas的历史数据

    • 返回过去N个区块消耗的gas (%满)
      • 矩形图？
      • 每个区块消耗的gas数列

    基本费历史数据

    • 有的话不错
    • 矩形图？

    上一个区块的基本费+消耗的gas

    • 当你想要 gas 价格计算的所必须的数据时，如果能有一个终端返回eth_getBlockBy*里的子集数据会很不错
    • 长期的解决方案可能会是像 GraphQL这样的方案

    下一个区块的 baseFeePerGas

    • 返回下一个区块的预期 baseFeePerGas
      • 注意：可以在Geth客户用eth_getBlockByNumber("pending")实现

    会议中的有趣争论的编译：

    API存在这样的问题：在区块大小是稳定没有高峰，以及在过去20个区块里出现过峰值，但当前峰值已过去这两种情况下，API提供的数据没有问题。但如果正值峰期，API会失效。

    争论点：priority fee是否应该对峰期作出反应？

    开发者：总的来说，我反对任何priority fee 预估，因为这等于强化了让用户进入竞拍和竞价战的情况，在大多数情况下，这是没有必要的。现有的做法对用户的好处和弊端参半。我希望在小费的设定上，是我们知道矿工会接受1、2 gwei 的小费，然后我们就不改了，就把小费设成固定的1、2 gwei。

    实现者：这就是为什么我说有时根据历史数据，这是可行的最低值，但你是说使用一个固定值，但ETH 的价格在不断变化，还有矿工的偏好，还有技术等多个变量，如果矿工的设置真的变了，且我们不根据现实的交易提供数据，用户要如何发现？

    开发者：我同意这需要是一个动态系统，但这应该是在一个长时间的范围里。这里我希望要严谨一点，有可能矿工获得基于MEV的动态小费就已足够激励他们去工作了。这很复杂也很难，但这是可能的且理论上有道理的。但我不认为矿工很快能做到这一点，因为他们有很多大型工作，而这只是小工程。因此我们可以长远地看，像 geth这样的客户端矿工都在用，它有一个命令行选项用于设置最低priority fee，我们相信矿工都会把它设在某个值。根据过去数以上万的区块，95%的矿工把它设为低于2，即以低于2 gwei挖一个区块。我想说的是API 是保持动态，但同时不需要变化太快，因为大多数时候这些变化都是基于短期的拥堵峰期，不会持续很久。

    实现者：我认为这些数据应该是动态的，但以过去的数据作为指标可能反应过慢，当交易处于峰值时你还在推荐最低的priority fee，当峰值过去了，你推荐高的priority fee。因此这样可能作用不大。我们其实有1559本身提供的免费客观数据来源——我们不需要看用户做什么，我们可以看区块有多满，可能是最近的2、3个区块，如果它们都是满的，我们就知道峰期来了，所以直接看区块的gas消耗就足够了解情况，这可能与现有的模式不同，且有更多的实现难度，但这是我对API的看法。

    所以还是主张对峰值作出反应，但我认为让用户至少有指标来了解现时情况还是很有价值的。因此根据过去几个区块消耗的gas而不是用户的主观竞价。因此我认为需要返回一些指示，告诉用户目前的紧急程度，然后由用户来决定是否要他们的交易被优先打包，给用户一个选择我认为是好的。

    开发者：关于是否要对拥堵情况作出反应，我们肯定是要知道前面的满块程度以确认拥堵，同样地，当我们尝试确定95%矿工的最低小费值是多少时，也需要在满块情况才能知道95%的矿工设置的最低小费值，我们要首先过滤了满的区块，这样才能看到最低值而不是拥堵时的值。这个讨论的一个重点是，如果大家都对拥堵作出反应，就会走向最后大家都支付更多。反应性对竞赛是有利的，在比赛中，有反应的会赢得比赛。如果你想构造一个生态系统是用户间达到大致平等，那么你为比赛中每个人使用同样的策略来造工具时，你最终会给矿工支付不必要的费用。如果我们在核心层，比如geth客户端引入这个策略，我们要确保引入后大多数的人不会使用它。这听上去很奇怪，但如果引入后大家都用了，那其实作用就不大了。像这种“高速、一般、缓慢”模式，高速表示会作出反应，缓慢表示不会，这种模式的一个坏处在于我担心如果基本费是100，三个速度分别是1、2、3 gwei，这样每个人都选高速，其实没人在里面获益。因此，我们需要大家用不同的策略，大家用同一个策略，那么这个策略就没用。这在博弈论里非常常见。

    来源：https://hackmd.io/@timbeiko/1559-api-wishlist

    会议视频：https://www.youtube.com/watch?v=SpU6WACP2cM


    Layer2

    Uniswap V3 已在 Arbitrum One 上部署

    此前，社区投票通过了在 Arbitrum 上部署 Uniswap V3。随后，为了响应社区的需求，Uniswap Labs 于 6 月 5日发推表示，V3 版本已经部署在 Arbitrum 主网上。app.uniswap.org 已更新支持部署。Arbitrum 目前只对白名单进行开放，已经申请为白名单的开发者们现在可以使用该版本了。一旦 Arbitrum 向所有用户开放，Uniswap V3 将不需要额外的工作，用户就可以体验其部署在 Arbitrum 上的版本。

    来源：https://twitter.com/Uniswap/status/1400847744596598792


    The Graph 的数据索引和查询服务上线 Arbitrum One

    区块链数据索引项目 The Graph 为 Arbitrum One 提供的数据索引和查询服务已上线。Arbitrum 上的开发者可以构建和发布开放的 APIs，调用 subgraphs，应用程序可以使用 GraphQL 进行查询。也就是说，开发者现在可以使用 subgraphs 来搜集和访问 Arbitrum One 的数据，就像在以太坊主网一样。

    the_graph

    来源：https://offchain.medium.com/the-graph-indexing-and-querying-services-are-live-on-arbitrum-one-c539a122da14


    开发者平台 Alchemy 已开放对 Arbitrum 的支持

    6 月 1 日，区块链开发者平台 Alchemy 对 Layer2 扩容解决方案 Arbitrum 主网的支持正式开放。Arbitrum 提供的 Layer2 技术让开发者的 gas 费可以节省最多 270 倍，而 Alchemy 开发者平台为此提供支持。这意味着开发者可以利用 Alchemy 的 Supernode 以及其开发者工具来访问 Arbitrum。

    所有 Alchemy 用户都可以访问 Arbitrum，并使用与以太坊相同的 API 方法。此外，Arbitrum 几乎与所有目前的以太坊智能合约兼容，所以将来不需要有任何的代码变化。

    这是 Alchemy 帮助其用户解决扩容问题以及 UI 问题的第一步，在接下来几个月，Alchemy 将进一步加深对 Arbitrum 和其他 Layer2 解决方案的支持。

    Arbitrum API 文档：https://docs.alchemy.com/alchemy/documentation/apis/arbitrum

    来源：https://blog.alchemy.com/blog/arbitrum-is-live


    zkSync 2.0：zkEVM 测试网的 Alpha 版本上线

    zkSync 推出 2.0 版本的 Alpha 测试网，添加了 zkEVM 和 zkPorter 两项技术。该测试网版在以下三个方面达成的成就有：

    • 在密码学方面，zkEVM 已经准备就绪，整个指令集已经确定下来，并且两种实现都已经完成：在电路中和在执行环境中。
    • 在编译器方面，用 Solidity 和 Zinc 编写的智能合约现在可以编译到 zkEVM 字节码中。
    • 在核心基础设施方面，全节点集成已完成，并且能够成功地部署和执行已编译的智能合约。

    当编译器 100% 准备好时，zkSync 将向开发人员开放测试网。届时将会公布上线第一批项目的流程。

    zkSync 2.0 测试网浏览器：https://zksync2-alpha.zkscan.io/

    来源：https://medium.com/matter-labs/zksync-2-0-hello-ethereum-ca48588de179


    生态

    Gitcoin Grants Round 10 即将开始

    开源软件资助平台 Gitcoin 将于 6 月 16 日 —— 7 月 1 日进行第 10 轮捐赠活动 Grants Round 10，并于 6 月 16 日 —— 7 月 7 日进行 Gitcoin Grants Round 10 黑客松。

    本轮活动资助者有 BadgerDAO、CenterPrime、Teller、Perpetual Protocol、Polygon、Mask Network、IOSG Ventures、Algorand 、Aave、The Graph Protocol 、Uniswap 等等。

    此外，ENS 团队于今宣布向 Gitcoin Grants Round 10 捐赠 70 万美元。

    gitcoin10

    cr：Gitcoin

    来源：https://gitcoin.co/grants/explorer/

    https://gitcoin.co/hackathon/gr10/onboard


    Lex Fridman 对话 Vitalik Buterin

    6 月 4 日，以太坊联合创始人 Vitalik Buterin 参加了由 Lex Fridman 主持的访谈节目，该访谈持续了 3 小时，谈及 SHIB 代币的故事、加密货币监管、PoS vs PoW、MEV、扩容、比特币区块大小战争、分片、Rollups、合并、狗狗币 vs 以太坊、NFT、Polygon 以及其他 Layer2 侧链解决方案等等话题。

    完整视频：https://www.youtube.com/watch?v=XW0QZmtbjvs


    5 月份，ETH 在多个指标上超过 BTC

    The Block 研究员 @lars0x 发布了几组图表，其中一个图表，显示了 ETH 在 5 月份链上流通量总值增长了 35.4%，超过了 BTC 的链上流通量总值。

    flipping

    来源：https://twitter.com/lars0x/status/1399734913218355201


    本期最佳meme

    meme

    cr：@hasufl



    ECN的翻译工作旨在为中国以太坊社区传递优质资讯和学习资源，文章版权归原作者所有，转载须注明原文出处以及ethereum.cn，若需长期转载，请联系eth@ecn.co进行授权。
    Ethereum Community Network
    以太坊社区网络
    Ethereum Community Network
    以太坊社区网络