最近两周的工作集中在关于 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 是什么，以及我们为什么需要它。

回到我开发 Checks Finance DApp 中最初需求，我需要它能够支持如下功能：

1. 非外部钱包 SDK：用户不需要下载第三方钱包，能够直接在 DApp 中创建钱包。

2. 非托管钱包模型：用户不需要将他们的私钥托管在我提供的服务或第三方外部中，但我们需要提供可行的流程让用户找回钱包的控制权。

3. 无 Gas 费用：用户感知不到他们付出了 Gas 费用，由于新用户没有方便的渠道获得 gas token，这对于他们来说尤其必要。

4. 快速区块确认：用户不会在操作区块链交易时卡住或等待太长时间。

5. 安全与良好的资产流动性：用户能通过广泛，安全，快速与富有交易深度的桥合约来转移他们的资产。

通过观察大部分市面上的 DApp，我发现，它们能够在第 4 与第 5 点做到很好，但在前 3 点当中，由于面向的主要是 Crypto Native 用户，一般，这些团队并不会花太多成本来考虑进行优化。

毫无疑问，这几个难题在很大程度上限制了进入 Web3 的用户规模。如果不从根本上解决问题，我很难说服自己 Web3 产品能在下个周期中得到一个数量级的用户增长。

为了解决问题 1-3，我开始寻找业界可能存在的方案。

首先，钱包方案是我们首先要迈过的重要门槛。目前，对于 DApp 开发者来说，流行的钱包方案大概有这几种：

1. 外部钱包连接：最流行，但对新用户来说门槛最高。我们不在此文中考虑这种方案。

2. 本地钱包 SDK：整合简单，但用户一旦删除 App 数据，将无法找回私钥，面临很大的丢失风险。

3. 托管钱包服务：通过将私钥绕开 DApp 应用逻辑直接上传到 Secrets Service 来进行管理的托管钱包服务，使用本地 SDK 进行交易签名，一些服务可以支持导出私钥。

面向大规模用户产品的方案中，第三种托管钱包方案是目前最多产品所使用的方案，Web3Auth 与 MagicLink 是这种方案的代表产品。它非常明确，用户能使用邮箱、手机或其他社会化登录方式来管理并找回他们的私钥，通过这种方式，它能带来足够多的外部用户，但它的缺点也十分明显：它带来了潜在的安全隐患，这种隐患可能并不限于 AWS 的私钥储存服务，也可能涉及托管钱包平台在设计上的安全风险。

其次，零 Gas 费用的设计目前有几种主流的范式：

1. 通过 Gas Relayer 代理用户在创建交易时的 Gas：使用 GSN 或 OpenZeppelin 提供的 Gas Relayer 来创建元交易（Meta Transaction）

2. 使用 L2 方案（例如 IMX 或 StarkNet）代理 Gas：通过智能合约钱包来创建元交易，接受消息的交易方合约能为用户代为支付 Gas 费用。

3. 使用机器人 EOA 在服务端代理用户的请求：这种方案最简单，但会带来额外的安全风险，以及这无法表现出用户与合约双方真实的交易。

考虑到 Gas Relayer 额外的手续费和基准 Gas 费用，使用后者（L2 方案）来部署我们的 DApp 合约显然是更有效与成本更低的方式。其中，一些 L2 方案甚至支持采用特定的 ERC-20 token 以支付 Gas 费用（例如 zkSync2.0）这样的费用模型会成为 DApp 经济模型中的一部分，提升我们所发行的治理 token 的价值，就像 DeFi Kingdoms Crystalvale 所做的那样。

作为总结，在针对大规模用户产品的设计上来看，我们需要寻找到一种产品设计思路，能够同时支持以上的需求，目前，比较可行的方式看起来是使用 Layer2 的方案。

使用 Layer2 的方案，我们可以基于智能合约钱包简单的实现元交易，以 StarkNet 为例，虽然它钱包的实现是智能合约钱包，但由于我们需要一个明确的控制权限，Argent X 的产品设计思路仍然沿袭着 EOA 钱包 MetaMask 的理念：在钱包初始化时（对于 StarkNet 来说即是部署账户合约时）我们需要记住钱包的助记词。

这带来的一个易于混淆的概念：是否我们的 DApp 支持多少个网络，用户就需要新建多少个 EOA 钱包？

遗憾的是，市场上大部分 DApp 都遵循这一愚蠢但无奈的思路进行设计。我把这种产品设计称为「多重钱包噩梦」在用户看来，这不仅无益于理解 Web3 与 Web2 产品有何不同，甚至在很大程度上提高了用户侧使用产品的安全隐患。

我理解，这种无奈的方式一方面由于符合目前 EOA 钱包的设计思路，另外一方面，这样的权责设计是十分分明的，合约和钱包开发团队不需要为用户丢失私钥这一过失而买单。但我认为，我们应当能从智能合约钱包中寻找到更容易理解和更自然的方式。

一个简单的假设是，我们能否允许智能合约钱包通过特定的 L1 EOA 钱包来操作？或者，我们能否将指南合约钱包设计为一个多签钱包的特定权限操作者，并将受信任的 L1/L2 账户设为 EOA 操作员，允许他们在紧急的情况下更改这一合约的日常操作员的权限？

事实是，智能合约钱包带来的无限的想象力，对于 EOA 钱包来说，它提供的可编程性，不仅仅能够支持代理 Gas 费用的元交易，还能将钱包彻底从 EOA 单一密钥解放出来：而我认为，这是 Web3 能够被大规模应用的必要条件之一。

在为 Checks Finance 面向日本市场推出的 Mobile DApp 编码之前，我反复地思考一个问题，如果未来的世界中我们面对着手机中的几百个 DApp，他们部署在多个不同的网络中，我们应当如何管理自己的钱包？

我们会使用 MetaMask 链接所有的钱包吗？我们的资产在所有 DApp 中，无论它是 DeFi，游戏，还是 NFT 交易市场中，同样重要吗？我们所有的资产都会暴露在网络中被任何人查阅吗？我们会允许自己丢失某个钱包吗？这些问题萦绕在我脑海中，久久无法散去。

这些问题指向着同两个需要回应的核心：

1. 到底什么是理想的 Web3 产品？

2. 我们如何管理纷繁复杂的资产？（会员卡，积分，零钱，储蓄，基金和股票）

我们处在一个多链多层的 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，以见证这一全球性的深刻变化。

最近两周的工作集中在关于 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 是什么，以及我们为什么需要它。

回到我开发 Checks Finance DApp 中最初需求，我需要它能够支持如下功能：

1. 非外部钱包 SDK：用户不需要下载第三方钱包，能够直接在 DApp 中创建钱包。

2. 非托管钱包模型：用户不需要将他们的私钥托管在我提供的服务或第三方外部中，但我们需要提供可行的流程让用户找回钱包的控制权。

3. 无 Gas 费用：用户感知不到他们付出了 Gas 费用，由于新用户没有方便的渠道获得 gas token，这对于他们来说尤其必要。

4. 快速区块确认：用户不会在操作区块链交易时卡住或等待太长时间。

5. 安全与良好的资产流动性：用户能通过广泛，安全，快速与富有交易深度的桥合约来转移他们的资产。

通过观察大部分市面上的 DApp，我发现，它们能够在第 4 与第 5 点做到很好，但在前 3 点当中，由于面向的主要是 Crypto Native 用户，一般，这些团队并不会花太多成本来考虑进行优化。

毫无疑问，这几个难题在很大程度上限制了进入 Web3 的用户规模。如果不从根本上解决问题，我很难说服自己 Web3 产品能在下个周期中得到一个数量级的用户增长。

为了解决问题 1-3，我开始寻找业界可能存在的方案。

首先，钱包方案是我们首先要迈过的重要门槛。目前，对于 DApp 开发者来说，流行的钱包方案大概有这几种：

1. 外部钱包连接：最流行，但对新用户来说门槛最高。我们不在此文中考虑这种方案。

2. 本地钱包 SDK：整合简单，但用户一旦删除 App 数据，将无法找回私钥，面临很大的丢失风险。

3. 托管钱包服务：通过将私钥绕开 DApp 应用逻辑直接上传到 Secrets Service 来进行管理的托管钱包服务，使用本地 SDK 进行交易签名，一些服务可以支持导出私钥。

面向大规模用户产品的方案中，第三种托管钱包方案是目前最多产品所使用的方案，Web3Auth 与 MagicLink 是这种方案的代表产品。它非常明确，用户能使用邮箱、手机或其他社会化登录方式来管理并找回他们的私钥，通过这种方式，它能带来足够多的外部用户，但它的缺点也十分明显：它带来了潜在的安全隐患，这种隐患可能并不限于 AWS 的私钥储存服务，也可能涉及托管钱包平台在设计上的安全风险。

其次，零 Gas 费用的设计目前有几种主流的范式：

1. 通过 Gas Relayer 代理用户在创建交易时的 Gas：使用 GSN 或 OpenZeppelin 提供的 Gas Relayer 来创建元交易（Meta Transaction）

2. 使用 L2 方案（例如 IMX 或 StarkNet）代理 Gas：通过智能合约钱包来创建元交易，接受消息的交易方合约能为用户代为支付 Gas 费用。

3. 使用机器人 EOA 在服务端代理用户的请求：这种方案最简单，但会带来额外的安全风险，以及这无法表现出用户与合约双方真实的交易。

考虑到 Gas Relayer 额外的手续费和基准 Gas 费用，使用后者（L2 方案）来部署我们的 DApp 合约显然是更有效与成本更低的方式。其中，一些 L2 方案甚至支持采用特定的 ERC-20 token 以支付 Gas 费用（例如 zkSync2.0）这样的费用模型会成为 DApp 经济模型中的一部分，提升我们所发行的治理 token 的价值，就像 DeFi Kingdoms Crystalvale 所做的那样。

作为总结，在针对大规模用户产品的设计上来看，我们需要寻找到一种产品设计思路，能够同时支持以上的需求，目前，比较可行的方式看起来是使用 Layer2 的方案。

使用 Layer2 的方案，我们可以基于智能合约钱包简单的实现元交易，以 StarkNet 为例，虽然它钱包的实现是智能合约钱包，但由于我们需要一个明确的控制权限，Argent X 的产品设计思路仍然沿袭着 EOA 钱包 MetaMask 的理念：在钱包初始化时（对于 StarkNet 来说即是部署账户合约时）我们需要记住钱包的助记词。

这带来的一个易于混淆的概念：是否我们的 DApp 支持多少个网络，用户就需要新建多少个 EOA 钱包？

遗憾的是，市场上大部分 DApp 都遵循这一愚蠢但无奈的思路进行设计。我把这种产品设计称为「多重钱包噩梦」在用户看来，这不仅无益于理解 Web3 与 Web2 产品有何不同，甚至在很大程度上提高了用户侧使用产品的安全隐患。

我理解，这种无奈的方式一方面由于符合目前 EOA 钱包的设计思路，另外一方面，这样的权责设计是十分分明的，合约和钱包开发团队不需要为用户丢失私钥这一过失而买单。但我认为，我们应当能从智能合约钱包中寻找到更容易理解和更自然的方式。

一个简单的假设是，我们能否允许智能合约钱包通过特定的 L1 EOA 钱包来操作？或者，我们能否将指南合约钱包设计为一个多签钱包的特定权限操作者，并将受信任的 L1/L2 账户设为 EOA 操作员，允许他们在紧急的情况下更改这一合约的日常操作员的权限？

事实是，智能合约钱包带来的无限的想象力，对于 EOA 钱包来说，它提供的可编程性，不仅仅能够支持代理 Gas 费用的元交易，还能将钱包彻底从 EOA 单一密钥解放出来：而我认为，这是 Web3 能够被大规模应用的必要条件之一。

在为 Checks Finance 面向日本市场推出的 Mobile DApp 编码之前，我反复地思考一个问题，如果未来的世界中我们面对着手机中的几百个 DApp，他们部署在多个不同的网络中，我们应当如何管理自己的钱包？

我们会使用 MetaMask 链接所有的钱包吗？我们的资产在所有 DApp 中，无论它是 DeFi，游戏，还是 NFT 交易市场中，同样重要吗？我们所有的资产都会暴露在网络中被任何人查阅吗？我们会允许自己丢失某个钱包吗？这些问题萦绕在我脑海中，久久无法散去。

这些问题指向着同两个需要回应的核心：

1. 到底什么是理想的 Web3 产品？

2. 我们如何管理纷繁复杂的资产？（会员卡，积分，零钱，储蓄，基金和股票）

我们处在一个多链多层的 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，以见证这一全球性的深刻变化。