ENF正致力于通过Wallet＋和Wave5对钱包的认可来改善用户体验

作为＃EOS 生态系统的第一个接触点，钱包是用户体验中最关键的部分之一。

ENF 正致力于通过 Wallet＋ 和 Wave 5 对钱包的认可来改善用户和开发人员的入职体验。

支持EOS钱包生态系统发展

钱包是终端用户进入区块链生态系统的第一个入口，也是EOS生态长期以来一直缺乏资金、标准化和更多关注的领域，这也是Wallet＋工作组成为EOS网络基金会赞助的四大核心支柱工作组之一。

随着第五波也是最后一波以钱包为主题的项目资助名单的公布，EOS网络基金会正在通过最具影响力的方式，为用户及开发人员带来巨大的体验变化。

Wallet＋ 和我们计划实现的目标

在上周的博客更新中，我们宣布了EOS网络基金会赞助的四个工作组，他们将作为促进EOS网络前进发展的四个核心支柱。每个工作组将在第一季度提交一份蓝皮书，涵盖EOS相关深入研究的一个方面。蓝皮书将作为基于每个工作组研究发展建议的路线图。

EOS网络基金会赞助的四个工作组包括：

Wallet＋：主要负责配合软件将EOS集成到外部应用程序中，Anchor钱包、Greymass Fuel和EOSIO签名请求（ESR）协议的核心开发团队Greymass是Wallet＋工作组的合作伙伴。

Core＋：主要负责维护EOS系统使EOS更适合运行各种类别的应用程序，EOS Amsterdam、EOS Dublin、EOS Barcelona和 Cryptolions是Core＋工作组的合作伙伴。

API＋：主要负责提供数据接口，帮助EOS生态以外的应用程序更好的集成EOS网络，Greymass、EOS Nation和EOS Rio是API＋工作组的合作伙伴。

Audit＋：主要负责为EOS应用提供安全分析工具和合约审计的整体框架，Slowmist和Sentnl是Audit＋工作组的合作伙伴。

钱包作为用户进入EOS生态系统的第一个入口，是用户体验中最关键的部分之一。大多数加密货币持有者在中心化交易所购买代币，但如果用户想自己保管资金，或者使用dApps、参与DeFi，就需要安装一个EOS钱包，并创建一个能够自主提取的EOS账户。

这听起来很简单，但在实际的操作过程中，不同项目方在EOS账户的创建和资源管理设计方面存在细微差别，而且会因为EOSIO特有的属性产生一些额外障碍。这些额外障碍和其他许多问题都将通过Greymass领导的EOS网络基金会 Wallet＋工作组解决。

Wallet＋工作组致力于解决的问题

由于不同项目方开发的钱包在解决具体问题（比如身份识别、交易签名等）时的思路和方式不同，应用开发者很难将所有的EOS钱包整合起来。

由于第1条原因，很多时候一些应用程序需要使用特定的钱包，这导致用户很难在一个产品内体验多个生态应用程序。如果用户想要使用特定的应用程序，他们就需要在钱包之间切换，这不仅困难，而且可能会有安全风险。

由于钱包或dApp对于EOS网络资源的处理方式不同，用户很难使用不同的应用程序，这些都没有标准化。

开发者很难将新用户引入他们的应用程序中，尤其是那些还没有EOS钱包的用户，这限制了大家在EOS上构建的应用程序的兴趣，并削弱了平台对开发人员的吸引力。

原生应用程序缺乏对通用硬件钱包支持，比如Ledger和Trezor等。

为了以统一的方式解决上述问题，我们认为可以从SDKs、协议和标准制定这些方面减轻用户和应用程序开发人员的负担

SDKs

对于许多 EOSIO 开发人员来说，Universal Authentication Library（通用身份验证库）在许多情况下的使用都并不理想，目前唯一的解决方法是由每个 dApp 构建自己的解决方案。

Bloks和Atomic Hub等大型平台上的高级开发者已经自觉做到了这一点，但我们不能指望每个开发者都能够从造车开始造汽车，因此我们需要开源的软件开发工具包（SDK），使开发者不必投入巨大的时间和精力，而是将更多心思放到继续开发他们的应用程序上面。

协议

为了改善用户体验 (UX) 并使开发人员更容易操作，每个钱包使用的协议应提供类似的兼容功能和用户流。实现这个目标的一种方法是使用相同的协议，另一种方法是统一协议的功能，以便开发人员在使用时更好地协调。

一个例子是“我如何证明这个用户拥有这个帐户”。例如，EOSIO 签名请求（ESR）协议有内置的身份请求来证明，而 Scatter 的旧协议需要两个步骤，第一步选择用户，第二步签署任意交易作为证明。统一这样的事情将改善终端用户的体验，并增加开发人员对钱包的采用。

标准制定

从备份、密钥导出等数据格式到 UI 界面（例如显示李嘉图合约和默认阻止危险操作），建立一套钱包基本操作准则和标准将改善终端用户体验。用户从钱包 A 切换到钱包 B的过程应该是既轻松又熟悉的，因为这都在同一个区块链内进行。

第5波认可资助名单：钱包类别

除了Wallet＋工作组的启动之外，EOS网络基金会很高兴地宣布第5波也是最后一波认可补助金名单。本次资助围绕钱包类别展开，入选的这些项目在EOS生态系统中发挥了至关重要的作用，很高兴能够为每个项目提供10万美元的EOS捐助，以表彰他们在EOS生态的持续贡献。

此外，作为工作组计划的一部分，Wallet＋工作组已经取得了重要的进展，我们期待根据蓝皮书确定的钱包建设方面将实施的标准和协议。

Anchor Wallet：关注安全和隐私的开源数字钱包，适用于所有基于EOSIO的网络，包含一套强大的附加功能，包括使用Greymass Fuel的无障碍资源计费系统等。

MyKey：建立在KEYID协议之上的一体化多链钱包，为EOS区块链上的用户提供管理资源、密钥恢复和身份识别等功能。

Token Pocket：去中心化多链钱包，月活跃用户超过300万，Money Services Business（货币服务业务）许可范围包括EOS在内的协议之间的跨链互换。

Starteos Wallet ：多链非托管钱包，支持多个EOSIO区块链。

EOS Argentina (MetaMask) ：钱包允许用户通过使用以太坊公钥/私钥对作为“微账户”的收费资源管理系统，在 EOS 区块链上启用 MetaMask 钱包支持。

结语

在过去的几个月里，可以明显感觉到EOS生态系统的发展势头越来越好。在过去的一个季度里，我们一扫阴霾，已经从停滞不前转变为加速创新和发展。

在认可补助、赞助工作组、Pomelo、Eden on EOS 以及 Helios 到来的一系列变化中，EOS 社区成员正经历着从未有过的激动人心的时刻。因为生态系统中想要做出贡献的每个人都可以通过各种渠道做出贡献、创造价值并得到回报，激励措施全面一致，这一切使我们能够继续推动生态系统向前发展，我们所有人都在齐心协力，朝着 EOS生态繁荣发展的统一愿景不懈努力。

向赞助的工作组提供用户/开发者反馈意见：

加入WG＋的EOS社区 Discord讨论群

加入WG＋讨论区

关注EOS网络基金会Twitter

关注EOS网络基金会中文Medium

以太坊生态：

关于如何逐步扩大可用于汇总的数据空间（从而大大降低汇总费用）的路线图，从降低 calldata gas 成本开始，并继续逐步推出分片：

使用 calldata 扩展和分片扩展汇总的分步路线图

Rollup 是短期和中期的，也可能是长期的，是以太坊唯一的去信任扩展解决方案。数月来，L1 上的交易费用一直非常高，而且迫切需要做任何必要的事情来帮助促进整个生态系统向汇总的转变。 Rollup 已经显着降低了许多以太坊用户的费用：l2fees.info 经常显示 Optimism 和 Arbitrum 提供的费用比以太坊基础层本身低约 3-8 倍，以及 ZK 汇总，它们具有更好的数据压缩并且可以避免包括签名， 费用比基础层低约 40-100 倍。

然而，即使是这些费用对许多用户来说也太贵了。长期以来，人们一直认为解决目前形式的 rollup 长期不足的方法是数据分片，这将为链上的 rollup 增加约 1-2 MB/秒的专用数据空间。本文档描述了实现该解决方案的实用途径，该解决方案尽可能快地解锁汇总数据空间，并随着时间的推移增加额外的空间和安全性。

Step 1: tx calldata 扩展

今天现有的汇总使用事务调用数据。因此，如果我们想在不要求 rollup 团队做任何额外工作的情况下，短期提升 rollup 容量并降低成本，我们应该只降低交易 calldata 的成本。今天的平均块大小远不及会威胁网络稳定性的大小，因此可以安全地做到这一点，尽管它可能需要一些额外的逻辑来防止非常不安全的边缘情况。

请参阅：EIP 4488，或替代方案（更简单但效果更温和）EIP 4490。

EIP 4488 应将可用于汇总的数据空间增加到每个插槽约 1 MB 的理论最大值，并将汇总成本降低约 5 倍。它可以比后面的步骤更快地实施。

第 2 步：一些碎片

同时，我们可以开始开展工作以推出“适当的”分片。以完整的形式实现适当的分片需要很长时间，但我们可以做的是一点一点地实现它，并从每个部分中受益。要实现的第一个自然部分是分片规范的“业务逻辑”，但通过将分片的初始数量保持在非常低的水平（例如 4）来避免大部分与网络相关的困难。每个分片都将在其自己的子网上广播。默认情况下，验证者会信任委员会，但如果他们愿意，他们可以选择在每个子网上，并且只有在他们看到信标块确认的任何分片块的完整主体后才接受信标块。

分片规范本身并不是特别困难；这是一个与最近发布的 Altair 硬分叉类似的样板代码更改（Altair 信标更改规范文件长 728 行，分片信标更改规范文件长 888 行），因此可以合理地期望它可以实现 在与 Altair 的实施和部署相似的时间范围内。

为了使分片数据真正可用于汇总，汇总需要能够将证明放入分片数据中。有两种选择：

添加 BEACONBLOCKROOT 操作码； rollups 将添加代码来验证植根于历史信标链块根的 Merkle 证明。

添加面向未来的状态和历史访问预编译，以便在未来承诺方案发生变化时，汇总不需要更改其代码。

这会将汇总数据空间增加到每个插槽约 2 MB（每个分片 250 kB ＊ 4 个分片，加上步骤 1 中扩展的 calldata）。

第 3 步：N 个分片，受委员会保护

将活动分片的数量从 4 个增加到 64 个。分片数据现在将进入子网，因此此时 P2P 层必须已经足够坚固，可以拆分成更多的子网。数据可用性的安全性将基于诚实多数，依赖于委员会的安全性。

这会将汇总数据空间增加到每个插槽约 16 MB（每个分片 250 kB ＊ 64 个分片）；我们假设此时汇总已从 exec 链中迁移出来。

第 4 步：数据可用性抽样 (DAS)

添加数据可用性采样以确保更高级别的安全性，即使在发生不诚实的多数攻击时也能保护用户。数据可用性采样可以分阶段推出：首先，以非绑定方式允许网络对其进行测试，然后作为接受信标块的要求，甚至可能在其他客户端之前在某些客户端上进行。

一旦完全引入数据可用性采样，分片部署就完成了。

分片下的乐观和 ZK 汇总

分片世界和现状之间的一个主要区别是，在分片世界中，汇总数据实际上不可能成为将汇总块提交到智能合约的交易的一部分。相反，数据发布步骤和汇总块提交步骤必须分开：首先，数据发布步骤将数据放在链上（放入分片中），然后提交步骤提交其标头，以及指向 基础数据。

Optimism 和 Arbitrum 已经为汇总块提交使用了两步设计，因此这对两者来说都是一个小的代码更改。