What I would love to see in a wallet
Special thanks to Liraz Siri, Yoav Weiss, and ImToken, Metamask and OKX developers for feedback and review.
特别感谢 Liraz Siri、Yoav Weiss 以及 ImToken、Metamask 和 OKX 开发人员的反馈和审核。
One critical layer of the Ethereum infrastructure stack, often underappreciated by core L1 researchers and developers, is the wallet.
以太坊基础设施堆栈的一个关键层是钱包，但经常被核心 L1 研究人员和开发人员低估。
Wallets are the window between a user and the Ethereum world, and a user only benefits from any decentralization, censorship resistance, security, privacy, or other properties that Ethereum and its applications offer to the extent that the wallet itself also has these properties.
钱包是用户和以太坊世界之间的窗口，用户只能从以太坊及其应用程序提供的任何去中心化、审查阻力、安全、隐私或其他属性中受益，前提是钱包本身也具有这些属性。
Recently, we have seen a lot of progress on improving user experience, security and functionality of Ethereum wallets.
最近，我们看到以太坊钱包在改善用户体验、安全性和功能方面取得了很大进展。
The goal of this post is to give my own views of some of the properties that an ideal Ethereum wallet would have.
这篇文章的目的是给出我自己对理想的以太坊钱包应具备的一些特性的看法。
This is not intended to be a complete list; reflecting my cypherpunk leanings, it focuses on security and privacy, and it is almost certainly incomplete on the user experience front.
这并不是一个完整的列表；它反映了我的密码朋克倾向，它专注于安全和隐私，并且几乎可以肯定它在用户体验方面是不完整的。
However, I would argue that wishlists are less effective for optimizing user experience than simply deploying and iterating based on feedback, and so I think it is most valuable to focus on the security and privacy properties.
然而，我认为愿望清单在优化用户体验方面不如简单地根据反馈进行部署和迭代有效，因此我认为关注安全和隐私属性是最有价值的。
There is now an increasingly detailed roadmap for improving cross-L2 user experience, which has a short-term part and a long-term part.
现在有一个越来越详细的改善跨L2用户体验的路线图，该路线图有短期部分和长期部分。
Here, I will talk about the short-term part: ideas which are theoretically implementable even today .
在这里，我将谈论短期部分：即使在今天理论上仍然可以实施的想法。
The core ideas are (i) built-in cross-L2 sends , and (ii) chain-specific addresses and payment requests .
核心思想是（i）内置跨L2发送，以及（ii）链特定地址和支付请求。
Your wallet should be able to give you an address that (following the style of this draft ERC ) looks like this:
您的钱包应该能够为您提供一个地址（遵循本 ERC 草案的风格），如下所示：
When someone (or some application) gives you an address of this format, you should be able to paste it into a wallet's "to" field, and click "send".
当某人（或某些应用程序）向您提供这种格式的地址时，您应该能够将其粘贴到钱包的“收件人”字段中，然后单击“发送”。
The wallet should automatically process that send in whatever way it can:
钱包应该以任何可能的方式自动处理发送的数据：
Mockup of possible wallet interface with cross-chain address support
具有跨链地址支持的可能钱包接口的模型
The above is for the "you copy-paste an address (or ENS, eg.
以上适用于“您复制粘贴地址（或 ENS，例如
vitalik.eth @ optimism.eth ) for someone to pay you" use case.
vitalik.eth @ optimism.eth ）让某人付钱给你”用例。
If a dapp is requesting a deposit (eg.
如果 dapp 请求存款（例如
see this Polymarket example ) then the ideal flow is to extend the web3 API and allow the dapp to make a chain-specific payment request.
请参阅此 Polymarket 示例），那么理想的流程是扩展 web3 API 并允许 dapp 发出特定于链的支付请求。
Your wallet would then be able to satisfy that request in whatever way it needs to.
然后，您的钱包将能够以任何需要的方式满足该请求。
Making the user experience work well would also require standardizing a getAvailableBalance request, and wallets would need to put significant thought into which chains they store users' assets on by default to maximize security and ease of transfers.
要使用户体验良好，还需要标准化 getAvailableBalance 请求，并且钱包需要认真考虑默认将用户资产存储在哪些链上，以最大限度地提高安全性和转账的便利性。
Chain-specific payment requests could also be put into QR codes, which mobile wallets could scan.
特定于链的支付请求也可以放入二维码中，移动钱包可以扫描二维码。
In an in-person (or online) consumer payments scenario, the recipient would make a QR code or web3 API call that says "I want X units of token Y on chain Z , with reference ID or callback W ", and the wallet would be free to satisfy that request in whatever way it can.
在面对面（或在线）消费者支付场景中，接收者将发出 QR 码或 web3 API 调用，表示“我想要链 Z 上的 X 单位代币 Y，带有参考 ID 或回调 W”，并且钱包将可以自由地以任何方式满足该请求。
Another option is a claim link protocol, where the user's wallet generates a QR code or URL that contains an authorization to claim a certain quantity of funds from their onchain contract, and it's the recipient's job to figure out how to then move those funds to their own wallet.
另一种选择是索赔链接协议，其中用户的钱包生成一个二维码或 URL，其中包含从其链上合约中索赔一定数量资金的授权，而接收者的工作就是弄清楚如何将这些资金转移到自己的钱包中。
Another related topic is gas payments.
另一个相关主题是天然气支付。
If you receive assets on an L2 where you do not yet have ETH, and you need to send a transaction on that L2, a wallet should be able to automatically use a protocol (eg.
如果您在尚未拥有 ETH 的 L2 上接收资产，并且需要在该 L2 上发送交易，则钱包应该能够自动使用协议（例如
RIP-7755 ) to pay the gas on a chain where you do have ETH.
RIP-7755）在您拥有 ETH 的链上支付 Gas 费。
If the wallet expects you to make more transactions on that L2 in the future, it should also just use a DEX to send over eg.
如果钱包希望你将来在 L2 上进行更多交易，它也应该使用 DEX 来发送，例如。
a few million gas worth of ETH, so that future transactions can spend gas there directly (as this is cheaper).
价值几百万 Gas 的 ETH，以便未来的交易可以直接在那里花费 Gas（因为这样更便宜）。
One way that I conceptualize the account security challenge is that a good wallet should simultaneously be good in two areas: (i) protecting the user from the wallet developer being hacked or malicious, and (ii) protecting the user from their own mistakes .
我概念化帐户安全挑战的一种方式是，一个好的钱包应该同时在两个方面发挥作用：（i）保护用户免受钱包开发人员的黑客攻击或恶意攻击，以及（ii）保护用户免受自己的错误的影响。
The typo "mistakles" on the left was unintentional.
左边的“错误”是无意的。
However, upon seeing it I realized that it's perfectly appropriate for the context, so I decided to keep it.
然而，当我看到它时，我意识到它非常适合上下文，所以我决定保留它。
My preferred solution to this, for over ten years , has been social recovery and multisig wallets, with graded access control.
十多年来，我首选的解决方案是社交恢复和多重签名钱包，以及分级访问控制。
A user's account has two layers of keys: a primary key, and N guardians (eg.
用户的帐户有两层密钥：主密钥和 N 个监护人（例如
N = 5).
N = 5）。
The primary key is able to do low-value and non-financial operations.
主键是能够进行低价值和非财务操作。
A majority of the guardians is required to do either (i) high-value operations, like sending away the entire value in the account, or (ii) change the primary key or any of the guardians.
大多数监护人需要执行 (i) 高价值操作，例如发送帐户中的全部价值，或 (ii) 更改主密钥或任何监护人。
If desired, the primary key can be allowed to do high-value operations with a timelock.
如果需要，可以允许主键通过时间锁执行高价值操作。
The above is a basic design, and can be augmented.
以上是基本设计，可以进行扩展。
Session keys, and permissions mechanisms like ERC-7715 , can help support different balances between convenience and security for different applications.
会话密钥和 ERC-7715 等权限机制可以帮助支持不同应用程序的便利性和安全性之间的不同平衡。
More complicated guardian architectures, such as having multiple timelock durations at different thresholds, can help maximize the chance of successful legitimate account recovery while minimizing the risk of theft.
更复杂的监护人架构，例如在不同阈值下具有多个时间锁定持续时间，可以帮助最大限度地提高成功恢复合法帐户的机会，同时最大限度地降低盗窃风险。
For an experienced crypto user who is inside a community of experienced crypto users, a viable option is the keys of your friends and family .
对于经验丰富的加密货币用户社区中的经验丰富的加密用户来说，一个可行的选择是您的朋友和家人的密钥。
If you ask each one to provide you with a fresh address, then no one needs to know who they are - in fact, your guardians don't even need to know who each other are.
如果您要求每个人为您提供一个新的地址，那么没有人需要知道他们是谁 - 事实上，您的监护人甚至不需要知道彼此是谁。
The chance that they will collude without one of them tipping you off is tiny.
如果他们没有向你通风报信，他们串通一气的可能性很小。
For most new users, however, this option is not available.
然而，对于大多数新用户来说，此选项不可用。
A second option is institutional guardians : firms that specialize in performing the service of only signing a transaction if they get some other confirmation that a request is coming from you: eg.
第二种选择是机构监护人：专门提供仅在收到您的请求的其他确认信息时才签署交易的服务的公司：例如。
a confirmation code, or for high-value users a video call.
确认码，或者针对高价值用户的视频通话。
People have attempted to make these for a long time, eg.
人们长期以来一直试图制造这些，例如。
I profiled CryptoCorp in 2013 .
我在 2013 年对 CryptoCorp 进行了介绍。
However, so far such firms have not been very successful.
然而，到目前为止，这些公司还不是很成功。
A third option is multiple personal devices (eg.
第三种选择是多个个人设备（例如。
phone, desktop, hardware wallet).
手机、台式机、硬件钱包）。
This can work, but also is difficult to set up and manage for inexperienced users.
这可以工作，但对于没有经验的用户来说也很难设置和管理。
There is also the risk of devices being lost or stolen at the same time, especially if they are at the same location.
还存在设备同时丢失或被盗的风险，尤其是当它们位于同一位置时。
Recently, we have started to see more wallets based on passkeys.
最近，我们开始看到更多基于密钥的钱包。
Passkeys can be backed up on your devices only, making them a type of personal-device solution, or backed up in the cloud, making their security dependent on a complicated hybrid of password security, institutional and trusted hardware assumptions.
密钥只能备份在您的设备上，使其成为一种个人设备解决方案，也可以备份在云中，使其安全性依赖于密码安全、机构和可信硬件假设的复杂混合。
Realistically, passkeys are a valuable security gain for ordinary users, but they alone are not strong enough to protect a user's life savings.
实际上，万能钥匙对于普通用户来说是一种宝贵的安全增益，但仅靠万能钥匙还不足以保护用户的毕生积蓄。
Fortunately, with ZK-SNARKs, we have a fourth option: ZK-wrapped centralized ID .
幸运的是，有了 ZK-SNARK，我们还有第四种选择：ZK 包装的中心化 ID。
This genre includes zk-email , Anon Aadhaar , Myna Wallet , and many others.
这种类型包括 zk-email 、 Anon Aadhaar 、 Myna Wallet 等等。
Basically, you can take many forms of (corporate or governmental) centralized ID, and turn it into an Ethereum address, which you can only send transactions from by generating a ZK-SNARK proving possession of the centralized ID.
基本上，您可以采用多种形式（公司或政府）中心化 ID，并将其转换为以太坊地址，您只能通过生成证明拥有中心化 ID 的 ZK-SNARK 来发送交易。
With this addition, we now have a wide array of options, and ZK-wrapped centralized ID is uniquely "noob-friendly".
有了这个补充，我们现在有了广泛的选择，并且 ZK 包装的中心化 ID 具有独特的“新手友好性”。
For this to work, it needs to be implemented with a streamlined and integrated UI: you should be able to just specify that you want "example@gmail.com" as a guardian, and it should automatically generate the corresponding zk-email Ethereum address under the hood.
为此，它需要通过简化且集成的 UI 来实现：您应该能够仅指定您想要“example@gmail.com”作为监护人，并且它应该在后台自动生成相应的 zk-email 以太坊地址。
Advanced users should be able to enter their email (along with perhaps a salt value for privacy, that would be saved in that email) into an open-source third-party application, and confirm that the address generated is correct.
高级用户应该能够将他们的电子邮件（以及可能保存在该电子邮件中的隐私盐值）输入到开源第三方应用程序中，并确认生成的地址是正确的。
The same should be true for any other supported guardian type.
对于任何其他受支持的监护人类型也应该如此。
Note that today, one practical challenge with zk-email specifically is that it depends on DKIM signatures , which use keys that are rotated once every few months, and these keys are not themselves signed by any other authority.
请注意，如今 zk-email 面临的一个实际挑战是它依赖于 DKIM 签名，该签名使用每隔几个月轮换一次的密钥，并且这些密钥本身并未由任何其他机构签名。
This means that zk-email today has some level of trust requirement beyond the provider themselves; this could be reduced if zk-email used TLSNotary inside trusted hardware to verify updated keys, but it's not ideal.
这意味着如今的 zk-email 具有超出提供商本身的某种程度的信任要求；如果 zk-email 在受信任的硬件内使用 TLSNotary 来验证更新的密钥，则可以减少这种情况，但这并不理想。
Hopefully, email providers will start signing their DKIM keys directly.
希望电子邮件提供商能够开始直接签署其 DKIM 密钥。
Today, I would recommend using zk-email for one guardian, but not for a majority of your guardians: do not store funds in a setup where zk-email breaking means that you lose access to your funds.
今天，我建议一位监护人使用 zk-email，但不建议大多数监护人使用：不要将资金存储在 zk-email 损坏意味着您无法使用资金的设置中。
New users realistically will not want to have to enter a large number of guardians in their first signup experience .
新用户实际上不希望在第一次注册时输入大量监护人。
Hence, wallets should offer them a very simple option.
因此，钱包应该为他们提供一个非常简单的选择。
One natural route is a 2-of-3 using zk-email on their email address, a key stored locally on the user's device (which could be a passkey), and a backup key held by the provider.
一种自然的途径是在其电子邮件地址上使用 zk-email、本地存储在用户设备上的密钥（可能是万能密钥）以及提供商持有的备份密钥，进行 2-of-3 的选择。
As a user becomes more experienced, or accrues more assets, at some point they should be prompted to add more guardians.
随着用户变得更有经验或积累更多资产，在某些时候应该提示他们添加更多监护人。
Wallets integrated in applications are inevitable, because applications trying to appeal to non-crypto users do not want the confusing user experience of asking their users to download two new applications (the app itself, plus an Ethereum wallet) at the same time.
钱包集成到应用程序中是不可避免的，因为试图吸引非加密用户的应用程序不希望用户同时下载两个新应用程序（应用程序本身，加上以太坊钱包）带来混乱的用户体验。
However, a user of many application wallets should be able to link all of their wallets together, so that they only have one "access control thing" to worry about.
然而，许多应用程序钱包的用户应该能够将他们的所有钱包链接在一起，这样他们就只需担心一个“访问控制问题”。
The simplest way to do this is a hierarchical scheme, where there is a fast "linking" process that allows a user to set their primary wallet to be the guardian of all of their in-app wallets.
最简单的方法是采用分层方案，其中有一个快速的“链接”过程，允许用户将其主钱包设置为所有应用内钱包的监护人。
The Farcaster client Warpcast supports this already:
Farcaster 客户端 Warpcast 已经支持这一点：
By default, your Warpcast account's recovery is controlled by the Warpcast team.
默认情况下，您的 Warpcast 帐户的恢复由 Warpcast 团队控制。
However, you can "take sovereignty over" your Farcaster account, and change the recovery to your own address.
但是，您可以“接管”您的 Farcaster 帐户，并将恢复更改为您自己的地址。
In addition to account security, wallets today do a lot to identify fake addresses, phishing, scams and other external threats, and try to protect their users from such threats.
除了帐户安全之外，当今的钱包还做了很多工作来识别虚假地址、网络钓鱼、诈骗和其他外部威胁，并尽力保护用户免受此类威胁。
At the same time, many of the countermeasures are still quite primitive: for example, requiring a clickthrough to send ETH or other tokens to any new address, regardless of whether you're sending $100 or $100,000.
与此同时，许多对策仍然相当原始：例如，要求点击才能将 ETH 或其他代币发送到任何新地址，无论您发送的是 100 美元还是 100,000 美元。
Here, there is no single magic-bullet solution; it's a series of slow ongoing fixes and improvements to different categories of threats.
在这里，不存在单一的灵丹妙药。这是针对不同类别威胁的一系列缓慢的持续修复和改进。
However, there is a lot of value in continuing to do the hard work to improve here.
然而，继续努力改进这里有很多价值。
Now is the time to start taking privacy on Ethereum much more seriously.
现在是时候开始更加认真地对待以太坊的隐私了。
ZK-SNARK technology is now very advanced, privacy technologies that mitigate regulatory risks without relying on backdoors, such as Privacy Pools , are growing more mature, and secondary infrastructure like Waku and ERC-4337 mempools is slowly becoming more stable.
ZK-SNARK技术现在已经非常先进，不依赖后门来降低监管风险的隐私技术（例如隐私池）越来越成熟，而像Waku和ERC-4337 mempools这样的二级基础设施也慢慢变得更加稳定。
However, up until now, making private transfers on Ethereum has required users to explicitly download and use a "privacy wallet", such as Railway (or Umbra for stealth addresses ).
然而，到目前为止，在以太坊上进行私人转账需要用户明确下载并使用“隐私钱包”，例如 Railway（或用于隐形地址的 Umbra）。
This adds great inconvenience and reduces the number of people who are willing to make private transfers.
这增加了极大的不便，也减少了愿意进行私人转账的人数。
The solution is that private transfers need to be integrated directly into wallets .
解决方案是私人转账需要直接集成到钱包中。
A simple implementation is as follows.
一个简单的实现如下。
A wallet could store some portion of a user's assets as a "private balance" in a privacy pool.
钱包可以将用户资产的一部分作为“私人余额”存储在隐私池中。
When a user makes a transfer, it would automatically withdraw from the privacy pool first.
用户进行转账时，会先自动退出隐私池。
If a user needs to receive funds, the wallet could automatically generate a stealth address.
如果用户需要接收资金，钱包可以自动生成一个隐形地址。
Additionally, a wallet could automatically generate a new address for each application that a user participates in (eg.
此外，钱包可以自动为用户参与的每个应用程序生成一个新地址（例如，
a defi protocol).
一个 defi 协议）。
Deposits would come from the privacy pool, and withdrawals would go straight into the privacy pool.
存款将来自隐私池，提款将直接进入隐私池。
This allows a user's activity in any one application to be unlinked from their activity in other applications.
这允许用户在任何一个应用程序中的活动与其在其他应用程序中的活动取消链接。
One advantage of this technique is that it is a natural pathway to not just privacy-preserving asset transfer , but also privacy-preserving identity .
这项技术的一个优点是，它不仅是保护隐私的资产转移的自然途径，也是保护隐私的身份的自然途径。
Identity happens onchain already: any application that uses proof-of-personhood gating (eg.
身份已经发生在链上：任何使用身份证明门控的应用程序（例如。
Gitcoin Grants), any token-gated chat, the Ethereum Follow Protocol , and much more are all onchain identity.
Gitcoin Grants）、任何代币门控聊天、以太坊遵循协议等等都是链上身份。
We want this ecosystem to also be privacy-preserving.
我们希望这个生态系统也能够保护隐私。
This means that a user's activity onchain should not be collected in one place: each item should be stored separately, and the user's wallet should be the only thing with a "global view" that sees all of your attestations at the same time.
这意味着用户的链上活动不应收集在一个地方：每个项目都应单独存储，并且用户的钱包应该是唯一具有“全局视图”的东西，可以同时看到您的所有证明。
A natively many-accounts-per-user ecosystem helps accomplish this, as do offchain attestation protocols like EAS and Zupass .
原生的每用户多账户生态系统有助于实现这一目标，EAS 和 Zupass 等链下证明协议也是如此。
This represents a pragmatic vision for Ethereum privacy in the medium-term future.
这代表了中期内以太坊隐私的务实愿景。
It can be implemented today, although there are features that can be introduced at L1 and L2 to make privacy-preserving transfers more efficient and reliable.
尽管可以在 L1 和 L2 引入一些功能以使隐私保护传输更加高效和可靠，但它现在就可以实现。
Some privacy advocates argue that the only acceptable thing is total privacy of everything: encrypting the entire EVM.
一些隐私倡导者认为，唯一可以接受的事情是所有事物的完全隐私：加密整个 EVM。
I would argue that this may be ideal as a long-term outcome, but it requires a much more fundamental rethink of programming models, and it's currently not at the level of maturity where it's ready to go and deploy across Ethereum.
我认为这可能是理想的长期结果，但它需要对编程模型进行更根本的重新思考，而且目前还没有达到准备在以太坊上部署的成熟水平。
We do need privacy-by-default to get sufficiently large anonymity sets.
我们确实需要默认隐私以获得足够大的匿名集。
However, focusing first on making (i) transfers between accounts, and (ii) identity and identity-adjacent use cases like attestations private is a pragmatic first step that is far easier to implement, and which wallets can get started on today.
然而，首先关注（i）账户之间的转账，以及（ii）身份和与身份相关的用例（例如私有证明）是务实的第一步，更容易实现，而且钱包现在就可以开始使用。
One consequence of any effective privacy solution, whether for payments or for identity or other use cases, is that it creates a need for the user to store offchain data.
任何有效的隐私解决方案的一个后果是，无论是用于支付、身份还是其他用例，它都会产生用户存储链下数据的需求。
This was obvious in Tornado Cash, which required users to save each individual "note" representing a 0.1-100 ETH deposit.
这在 Tornado Cash 中很明显，它要求用户保存每张代表 0.1-100 ETH 存款的“票据”。
More modern privacy protocols sometimes save the data encrypted onchain, and use a single private key to decrypt it.
更现代的隐私协议有时会在链上保存加密的数据，并使用单个私钥对其进行解密。
This is risky, because if the key is ever leaked, or if quantum computers ever become viable, the data all becomes public.
这是有风险的，因为如果密钥泄露，或者量子计算机变得可行，数据就会全部公开。
Offchain attestations like EAS and Zupass have an even more obvious need for offchain data storage.
EAS 和 Zupass 等链下证明对链下数据存储的需求更为明显。
Wallets need to become not just software to store onchain access permissions, but also software to store your private data .
钱包不仅需要成为存储链上访问权限的软件，还需要成为存储您的私人数据的软件。
This is something that the non-crypto world is increasingly recognizing as well, eg.
非加密世界也越来越认识到这一点，例如。
see Tim Berners-Lee's recent work in personal data stores .
请参阅 Tim Berners-Lee 最近在个人数据存储方面的工作。
All of the problems that we need to solve around robustly guaranteeing control of access permissions, we also need to solve around robustly guaranteeing accessibility and non-leakage of data.
所有我们需要围绕稳健保证访问权限控制来解决的问题，我们还需要围绕稳健保证数据的可访问性和不泄漏来解决。
Perhaps the solutions could be overlaid together: if you have N guardians, use M-of-N secret sharing between those same N guardians to store your data.
也许这些解决方案可以叠加在一起：如果您有 N 个监护人，请在这 N 个监护人之间使用 M-of-N 秘密共享来存储您的数据。
Data is inherently harder to secure, because you can't revoke someone's share of it, but we should come up with decentralized custody solutions that are as secure as we can.
数据本质上更难保护，因为你无法撤销某人的数据份额，但我们应该提出尽可能安全的去中心化托管解决方案。
Today, wallets trust their RPC providers to tell them any information about a chain.
如今，钱包相信他们的 RPC 提供商会告诉他们有关链的任何信息。
This is a vulnerability in two ways:
这是一个漏洞，有两个方面：
Ideally, we want to plug both of these holes.
理想情况下，我们希望堵住这两个漏洞。
To plug the first, we need standardized light clients for L1 and L2s, which directly verify the blockchain consensus.
为了解决第一个问题，我们需要 L1 和 L2 的标准化轻客户端，它们可以直接验证区块链共识。
Helios already does this for L1, and has been doing some preliminary work to support some specific L2s.
Helios 已经为 L1 做到了这一点，并且一直在做一些初步工作来支持一些特定的 L2。
To properly cover all L2s, what we need is a standard by which a config contract representing an L2 (also used for chain-specific addresses) can declare a function, perhaps in a manner similar to ERC-3668 , containing the logic for obtaining recent state roots, and verifying proofs of state and receipts against those state roots.
为了正确覆盖所有 L2，我们需要一个标准，代表 L2（也用于特定于链的地址）的配置合约可以通过该标准声明一个函数，可能以类似于 ERC-3668 的方式，包含获取最近状态根的逻辑，并根据这些状态根验证状态和收据证明。
This way we could have a universal light client , allowing wallets to securely verify any state or events on L1 and L2.
这样我们就可以拥有一个通用的轻客户端，允许钱包安全地验证 L1 和 L2 上的任何状态或事件。
For privacy, today the only realistic approach is to run your own full node.
为了隐私，当今唯一现实的方法是运行您自己的完整节点。
However, now that L2s are entering the picture, running a full node of everything is getting increasingly hard.
然而，现在 L2 正在进入人们的视野，运行所有内容的完整节点变得越来越困难。
The equivalent to a light client here is private information retrieval (PIR) .
这里相当于轻客户端的是私有信息检索（PIR）。
PIR involves a server holding a copy of all the data, and a client sending the server an encrypted request.
PIR 涉及保存所有数据副本的服务器和向服务器发送加密请求的客户端。
The server performs a computation over all the data, which returns the client's desired data, encrypted to the client's key, without revealing to the server which piece of data the client accessed.
服务器对所有数据执行计算，返回客户端所需的数据，并加密到客户端的密钥，而不会向服务器透露客户端访问了哪条数据。
To keep the server honest, the individual database items would themselves be Merkle branches, so the client could verify them using their light client.
为了保持服务器的诚实，各个数据库项目本身就是 Merkle 分支，因此客户端可以使用轻客户端来验证它们。
PIR is very computationally expensive.
PIR 的计算量非常大。
There are several routes around this problem:
解决这个问题有几种途径：
Figuring out the right combination of techniques to maximize privacy while maintaining practicality in the Ethereum context is an open research problem, and I welcome cryptographers trying their hand at it.
在以太坊环境中找出正确的技术组合来最大化隐私，同时保持实用性是一个开放的研究问题，我欢迎密码学家尝试这样做。
Aside from transfers and state access, one other important workflow that needs to work smoothly in a cross-L2 context is changing an account's validation configuration: whether changing its keys (eg.
除了传输和状态访问之外，需要在跨 L2 上下文中顺利工作的另一个重要工作流程是更改帐户的验证配置：是否更改其密钥（例如
recovery), or a deeper change to the account's entire logic.
恢复），或者对账户的整个逻辑进行更深层次的改变。
Here, there are three tiers of solutions, in increasing order of how difficult they are:
这里有三层解决方案，按照难度递增的顺序排列：
Solution (3) is particularly powerful because it stacks well with privacy .
解决方案（3）特别强大，因为它与隐私很好地结合在一起。
In a normal "privacy solution", a user has a secret s , a "leaf value" L is published on chain, and a user proves that L = hash(s, 1) and N = hash(s, 2) for some (never-revealed) secret that they control.
在正常的“隐私解决方案”中，用户拥有一个秘密 s ，一个“叶子值” L 发布在链上，并且用户证明 L = hash(s, 1) 和 N = hash(s, 2) 对于他们控制的某些（从未泄露的）秘密。
The nullifier N gets published, making sure that future spends of the same leaf fail, without ever revealing L .
无效符 N 被发布，确保同一叶子的未来支出失败，而不会泄露 L 。
This depends on the user keeping s safe.
这取决于用户的安全。
A recovery-friendly privacy solution would instead say: s is a location (eg.
恢复友好的隐私解决方案会说：s 是一个位置（例如
address and storage slot) onchain, and the user must prove a state query: L = hash(sload(s), 1) .
地址和存储槽）在链上，并且用户必须证明状态查询： L = hash(sload(s), 1) 。
The weakest link in a user's security is often the dapp.
用户安全中最薄弱的环节通常是 dapp。
Most of the time, a user interacts with an application by going to a website, which implicitly downloads the user interface code in real-time from a server and then executes it in-browser.
大多数时候，用户通过访问网站与应用程序交互，该网站隐式地从服务器实时下载用户界面代码，然后在浏览器中执行。
If the server is hacked, or if the DNS is hacked, the user will get a fake copy of the interface, which could trick the user into doing arbitrary things.
如果服务器被黑客攻击，或者 DNS 被黑客攻击，用户将获得界面的虚假副本，这可能会诱骗用户执行任意操作。
Wallet features like transaction simulations are very helpful in mitigating the risks, but they are far from perfect.
交易模拟等钱包功能对于降低风险非常有帮助，但它们还远非完美。
Ideally, we would move the ecosystem to on-chain content versioning: a user would access a dapp via its ENS name, which would contain the IPFS hash of the interface.
理想情况下，我们会将生态系统转移到链上内容版本控制：用户将通过其 ENS 名称访问 dapp，该名称将包含接口的 IPFS 哈希值。
An onchain transaction from a multisig or DAO would be needed to update the interface.
更新接口需要来自多重签名或 DAO 的链上交易。
Wallets would show users if they're interacting with a more-secure onchain interface, or a less-secure web2 interface.
钱包会向用户显示他们是否正在与更安全的链上界面或安全性较低的 Web2 界面进行交互。
Wallets can also show users if they're interacting with a secure chain (eg.
钱包还可以向用户显示他们是否正在与安全链交互（例如。
stage 1+, multiple security audits).
第 1+ 阶段，多次安全审核）。
For privacy-conscious users, wallets can also add a paranoid mode , which requires users to clickthrough accept HTTP requests, and not just web3 operations:
对于注重隐私的用户，钱包还可以添加偏执模式，要求用户点击接受HTTP请求，而不仅仅是web3操作：
A more advanced approach would be to move beyond HTML + Javascript, and write the business logic of dapps in a dedicated language, perhaps a relatively thin overlay over Solidity or Vyper.
更先进的方法是超越 HTML + Javascript，并用专用语言（可能是 Solidity 或 Vyper 上相对较薄的覆盖层）编写 dapp 的业务逻辑。
Browsers could then automatically generate a UI for any needed functionality.
然后，浏览器可以自动生成任何所需功能的 UI。
OKContract is doing this already.
OKContract 已经在这样做了。
Another direction is cryptoeconomic info-defense : dapp developers, security firms, chain deployers and others can put up a bond that would get paid out to affected users if a dapp was hacked or otherwise harmed users by acting in a highly misleading way, as determined by some onchain adjudication DAO.
另一个方向是加密经济信息防御：dapp 开发者、安全公司、链部署者和其他人可以建立一笔债券，如果 dapp 被黑客攻击或以高度误导性的方式伤害用户，则该债券将支付给受影响的用户（由一些链上裁决 DAO 确定）。
The wallet could show a user a score that is based on the size of the bond.
钱包可以向用户显示基于债券大小的分数。
The above was all in the context of conventional interfaces, which involve pointing and clicking on things and entering things into text fields.
以上都是在传统界面的背景下进行的，其中涉及指向和单击事物以及将事物输入到文本字段中。
However, we are also on the cusp of paradigms changing much more deeply:
然而，我们也正处于范式发生更深刻变化的风口浪尖：
These three trends together will lead to much deeper rethinking of how interfaces work.
这三种趋势共同将导致人们对界面工作方式进行更深入的重新思考。
Through natural language input, eye tracking, or eventually more direct BCI, together with knowledge of your history (perhaps including text messages, as long as all data is processed locally), a "wallet" could get a clear intuitive idea of what you want to do.
通过自然语言输入、眼球追踪或最终更直接的脑机接口，再加上您的历史记录（也许包括短信，只要所有数据都在本地处理），“钱包”可以清楚直观地了解您想要做什么。
AI could then translate that intuition into a concrete "action plan": a series of onchain and offchain interactions that accomplish what you want.
然后，人工智能可以将这种直觉转化为具体的“行动计划”：一系列链上和链下交互来完成你想要的事情。
This could greatly reduce the need for third-party user interfaces entirely.
这可以大大减少对第三方用户界面的需求。
If a user does interact with a third-party application (or another user), the AI should think adversarially on the user's behalf, and identify any threats and suggest action plans for avoiding them.
如果用户确实与第三方应用程序（或其他用户）进行交互，人工智能应该代表用户进行对抗性思考，识别任何威胁并提出避免威胁的行动计划。
Ideally, there would be an open ecosystem of these AIs, produced by different groups with different biases and incentive structures.
理想情况下，这些人工智能应该有一个开放的生态系统，由具有不同偏见和激励结构的不同群体产生。
These more radical ideas depend on technology that is extremely immature today, and so I would not put my assets today into a wallet that relies on them.
这些更激进的想法依赖于当今极其不成熟的技术，因此我今天不会将我的资产放入依赖它们的钱包中。
However, something like this seems to be pretty clearly the future, and so it's worth starting to more actively explore in that direction.
然而，类似的事情似乎很明显是未来的趋势，因此值得开始朝这个方向更积极地探索。