ChainOE
作者：郭宇
来源：mirror
最近两周的工作集中在关于DApp中合约部署的思考，大部分时间，我在学习zkRollup Layer2的合约开发，并研究它们的网络设计特点。其中，StarkNet设计的Cairo编程语言可以帮助我们更好地开发富应用的DApp，并减少一个数量级的Gas费用消耗。
在StarkNet中，所有地址均为合约地址，没有外部账户（EOA）的概念，它的钱包账户由用户签名部署的「账户合约」组成，该私钥的签名才能操作这个「账户合约」的转账。这是一个很有趣的想法，我们知道，在以太坊主网中，EOA与合约账户是一直以来的历史遗留问题之一，从EIP86草案到EIP-2938草案，都致力于将账户逻辑从EOA中抽象出来，并将其逻辑应用到智能合约所管理的账户中，以实现「智能合约钱包」。
StarkNet的主流钱包方案Argent X即是一种「智能合约钱包」的实现，社区也提供了对应的JS SDK，帮助开发者在本地或自己所部署的DApp中实现智能合约钱包。
如果我们把目光转向多签名合约，就会发现智能合约钱包作为服务，比作为Inject Provider的角色更受关注，被使用的次数也更多，其中，最流行的服务便是Gnosis Safe*。但反过来，作为独立钱包角色的智能合约钱包，并没有受到广泛的应用，尤其在L1/L1s方案中，无法与传统EOA钱包（例如MetaMask）相竞争。
*注：在这里，Gnosis Safe提供的钱包是一种多签名合约编程范式，并非EIP86与EIP-2938中提到的合约账户抽象。
我认为，智能合约钱包虽然有明显的技术与体验优势，但在重资产安全的L1/L1s网络中引入了合约这一额外的复杂性与安全风险，并无法改变需要牢记助记词的烦恼（由于仍然需要为智能合约钱包设定权限）导致用户感知不到其技术优势。除了以Argent Guardians为代表的创新产品允许用户使用三方确认找回智能合约钱包的权限之外，大部分用户只在多签名合约的场景下使用它，把此作为一种开放式资产或额外确认的管理模式。
在StarkNet类似的Layer2网络中，智能合约钱包不存在历史负担，因此，它也许能够为DApp走向大众带来一些技术架构上的优势。
实际上，随着以太坊的Layer2网络，尤其是zkRollup网络的上线，智能合约钱包很可能将允许我们设计出多层资产资产中继网络（Multi-layer Asset Relay Network）以帮助我们的用户使用L1的EOA账户控制所有应用层资产。
多层资产资产中继网络（以下简称MARN）是我的一个产品设想，它并不存在于目前的现实中，在本文的剩余部分，我将解释MARN是什么，以及我们为什么需要它。
1.大规模用户产品需求
回到我开发Checks Finance DApp中最初需求，我需要它能够支持如下功能：
非外部钱包SDK：用户不需要下载第三方钱包，能够直接在DApp中创建钱包。
非托管钱包模型：用户不需要将他们的私钥托管在我提供的服务或第三方外部中，但我们需要提供可行的流程让用户找回钱包的控制权。
无Gas费用：用户感知不到他们付出了Gas费用，由于新用户没有方便的渠道获得gas token，这对于他们来说尤其必要。
快速区块确认：用户不会在操作区块链交易时卡住或等待太长时间。
安全与良好的资产流动性：用户能通过广泛，安全，快速与富有交易深度的桥合约来转移他们的资产。
通过观察大部分市面上的DApp，我发现，它们能够在第4与第5点做到很好，但在前3点当中，由于面向的主要是Crypto Native用户，一般，这些团队并不会花太多成本来考虑进行优化。
毫无疑问，这几个难题在很大程度上限制了进入Web3的用户规模。如果不从根本上解决问题，我很难说服自己Web3产品能在下个周期中得到一个数量级的用户增长。
为了解决问题1-3，我开始寻找业界可能存在的方案。
首先，钱包方案是我们首先要迈过的重要门槛。目前，对于DApp开发者来说，流行的钱包方案大概有这几种：
外部钱包连接：最流行，但对新用户来说门槛最高。我们不在此文中考虑这种方案。
本地钱包SDK：整合简单，但用户一旦删除App数据，将无法找回私钥，面临很大的丢失风险。
托管钱包服务：通过将私钥绕开DApp应用逻辑直接上传到Secrets Service来进行管理的托管钱包服务，使用本地SDK进行交易签名，一些服务可以支持导出私钥。
面向大规模用户产品的方案中，第三种托管钱包方案是目前最多产品所使用的方案，Web3Auth与MagicLink是这种方案的代表产品。它非常明确，用户能使用邮箱、手机或其他社会化登录方式来管理并找回他们的私钥，通过这种方式，它能带来足够多的外部用户，但它的缺点也十分明显：它带来了潜在的安全隐患，这种隐患可能并不限于AWS的私钥储存服务，也可能涉及托管钱包平台在设计上的安全风险。
其次，零Gas费用的设计目前有几种主流的范式：
通过Gas Relayer代理用户在创建交易时的Gas：使用GSN或OpenZeppelin提供的Gas Relayer来创建元交易（Meta Transaction）
使用L2方案（例如IMX或StarkNet）代理Gas：通过智能合约钱包来创建元交易，接受消息的交易方合约能为用户代为支付Gas费用。
使用机器人EOA在服务端代理用户的请求：这种方案最简单，但会带来额外的安全风险，以及这无法表现出用户与合约双方真实的交易。
考虑到Gas Relayer额外的手续费和基准Gas费用，使用后者（L2方案）来部署我们的DApp合约显然是更有效与成本更低的方式。其中，一些L2方案甚至支持采用特定的ERC-20 token以支付Gas费用（例如zkSync2.0）这样的费用模型会成为DApp经济模型中的一部分，提升我们所发行的治理token的价值，就像DeFi Kingdoms Crystalvale所做的那样。
作为总结，在针对大规模用户产品的设计上来看，我们需要寻找到一种产品设计思路，能够同时支持以上的需求，目前，比较可行的方式看起来是使用Layer2的方案。
2.外部账户（EOA）存在的问题
使用Layer2的方案，我们可以基于智能合约钱包简单的实现元交易，以StarkNet为例，虽然它钱包的实现是智能合约钱包，但由于我们需要一个明确的控制权限，Argent X的产品设计思路仍然沿袭着EOA钱包MetaMask的理念：在钱包初始化时（对于StarkNet来说即是部署账户合约时）我们需要记住钱包的助记词。
这带来的一个易于混淆的概念：是否我们的DApp支持多少个网络，用户就需要新建多少个EOA钱包？
遗憾的是，市场上大部分DApp都遵循这一愚蠢但无奈的思路进行设计。我把这种产品设计称为「多重钱包噩梦」在用户看来，这不仅无益于理解Web3与Web2产品有何不同，甚至在很大程度上提高了用户侧使用产品的安全隐患。
我理解，这种无奈的方式一方面由于符合目前EOA钱包的设计思路，另外一方面，这样的权责设计是十分分明的，合约和钱包开发团队不需要为用户丢失私钥这一过失而买单。但我认为，我们应当能从智能合约钱包中寻找到更容易理解和更自然的方式。
一个简单的假设是，我们能否允许智能合约钱包通过特定的L1 EOA钱包来操作？或者，我们能否将指南合约钱包设计为一个多签钱包的特定权限操作者，并将受信任的L1/L2账户设为EOA操作员，允许他们在紧急的情况下更改这一合约的日常操作员的权限？
事实是，智能合约钱包带来的无限的想象力，对于EOA钱包来说，它提供的可编程性，不仅仅能够支持代理Gas费用的元交易，还能将钱包彻底从EOA单一密钥解放出来：而我认为，这是Web3能够被大规模应用的必要条件之一。
3.多层资产中继网络（MARN）的思考
在为Checks Finance面向日本市场推出的Mobile DApp编码之前，我反复地思考一个问题，如果未来的世界中我们面对着手机中的几百个DApp，他们部署在多个不同的网络中，我们应当如何管理自己的钱包？
我们会使用MetaMask链接所有的钱包吗？我们的资产在所有DApp中，无论它是DeFi，游戏，还是NFT交易市场中，同样重要吗？我们所有的资产都会暴露在网络中被任何人查阅吗？我们会允许自己丢失某个钱包吗？这些问题萦绕在我脑海中，久久无法散去。
这些问题指向着同两个需要回应的核心：
到底什么是理想的Web3产品？
我们如何管理纷繁复杂的资产？（会员卡，积分，零钱，储蓄，基金和股票）
我们处在一个多链多层的Web3世界中，毫无疑问，这种状况将会持续很长一段时间，这意味着，NFT玩家会在主网操作他们的MetaMask钱包，健身爱好者会在Solana参与StepN的日常运动，DeFi用户会穿梭在不同的网络中，同时拥有几十个EOA钱包，并管理他们复杂的资产类型，而DAO将会变成跨网络的资产合约。
但是，当Web3真正进入大众视野，用户再增长超过一个数量级时，DApp和钱包还会维持这样的地位吗？
我的看法是，随着Layer2和其他应用层的逐步发展，钱包，一定会变的更加碎片化，钱包所保管的记账资产，也会随之而变的碎片化。如果所有钱包都是EOA钱包，它一定会带来比目前更加严重数百倍的「多重钱包噩梦」。
然而，如果我们把实体经济中的所有资产都搬到Web3上，我们会发现，一些资产的重要性明显远不如另外一些资产。我们会允许钱包中的零钱丢失，但我们很可能无法容忍自己存在银行中的储蓄消失。简易、好用的钱包会占据一些市场地位，他们可能随着一些流行的DApp被嵌入其中，而不像EOA钱包，诸如MetaMask那样被广泛使用。
我认为，这些「不那么重要的」，分布于「应用层」的钱包，可以被一种权限网络所创建，在这个初步的设想中，我把它叫做多层资产资产中继网络（Multi-layer Asset Relay Network）
MARN指的是，我们可以通过L1的EOA钱包来创建，控制L2（或LN）的智能合约钱包，并且，允许这些LN的钱包成为它的资产缓存层。
这意味着，通过L1→LN的通信，我们有能力让用户使用一个钱包，管理所有的合约钱包，并且，在不依赖私钥托管的前提下，支持使用恢复操作者来支配LN钱包的某些权限。
例如，当用户登录DApp时，我们大部分的合约逻辑基于L2（比如StarkNet）我们可以自动为该用户创建一个钱包合约，并在本地记录它的操作者私钥（作为可允许丢失的本地缓存）在创建这个合约时，我们需要该用户提供L1的外部账户（使用MetaMask登录）并且提供备用邮箱或特定恢复操作员。通过这种方式，当用户本地私钥丢失时，L1 EOA账户的通信，或备用邮箱的认证，都可以帮助智能合约钱包修改一个新操作员，也就是说，本地随机创建的操作者是可恢复，可替换的。在产品设计上，这种恢复可以不被用户感知到，无论该用户是否记住了私钥，他都可以随时操作这个LN钱包。
通过这种设计，LN钱包的资产能够作为L1 EOA钱包的资产缓存，使用特定的通信，用户能随时从L1抽回LN钱包的资产（对StarkNet来说，这一行为会在<30分钟内到账）这在另一方面加强了合约钱包中资产的安全性，并且赋予了灵活的跨层权限管理。
MARN带来了明确的好处：对用户来说，不再需要记录超过一个EOA的助记词，并且对LN的服务无感知，对平台来说，帮助用户恢复了操作权限，但又不需要承担Secrets Service的成本和安全风险，可以说是一举多得。
MARN的最终设计目的，应当能帮助用户使用单一外部钱包跨越多层网络而实现无缝的权限控制与资产转移。从这个目标上来看，LN应当是应用服务首选的基础架构，因为Layer2技术能够在最大程度上保证跨链资产的安全性，而无需将这种安全风险交给编写跨链桥合约的应用开发者（就像Axie所遭遇的那样）。
目前，我对这一概念的思考还在初步的阶段，但我已在Checks Finance L2的DApp编码中实践这一想法，希望为它的用户提供无缝而安全的钱包体验。对于MARN，如果你持有类似的想法，或有建设性的建议，欢迎和我在Twitter上进行讨论。我也会逐步在Mirror更新我对这一想法的具体实践，并将最终产品和代码开源。
我有一种预感，Web3的大规模应用可能会在下一个周期内发生，让我们持续BUIDL，以见证这一全球性的深刻变化。
