2025年...Push上的频道创建已今非昔比

现在是 2025 年......

美国大选结束了，特朗普重返办公室...... 加密货币正处于牛市中......屏幕闪耀着绿光......最优秀的人才正在创造令人惊叹的 web3 产品......web3 正在开启它吸引下一个十亿用户的旅程。

你也刚刚推出了你的新产品、服务或新闻通讯。好样的，伙计。

你意识到你需要一种 web3 专用的方式与你的用户沟通。很自然地，你决定在 Push Protocol 上创建一个频道，开始直接向他们的钱包地址发送通知。

你认为既然 Push Protocol 频道是在以太坊上的，那么你需要将你的原生 L2 代币转换为 ETH。

但是，有些东西引起了你的注意。👀

你注意到 Push dApp 允许你使用钱包中的任何代币，从你选择的任何链上创建频道。

你将能够无缝地从任何链向 Push 智能合约（在以太坊上）创建任何跨链请求。

无需桥接，无需等待，无需浪费你宝贵的代币。

昨天我为 Push Protocol 社区撰写了一份 2500 字的长篇提案，这是迄今为止针对 Push Smart Contracts 的最重要的提案之一。

系好安全带！Decipherers，今天我将带你踏上 Push Protocol 未来之旅。🚀

首先...

在理解为什么这项研究和提案很重要之前，让我们快速了解 Push 目前的状况以及它的历史。

对于那些不知道的人来说，Push 正在构建 Web3 的通信层，任何 dApp、智能合约或后端都可以使用它来发送直接与用户钱包地址（又名 Web3 用户名）绑定的任何实时通知。

要使用 Push Protocol 向你的用户发送通知，必须创建一个频道。在 Push 上创建频道意味着将自己确立为一项服务，你的用户可以选择加入并接收来自你的通知/更新。基本上，类似于 YouTube 频道和订阅的工作方式。

Push Protocol 在以太坊和多个 EVM 链（如 Polygon、Arbitrum、BSC、Optimism 等）上部署了智能合约。这些智能合约在 Push Protocol 的架构中发挥着重要作用。这些合约允许创建频道、发送链上通知、激励机制等等。

简而言之，对于任何强制性操作，如创建频道、维护频道详细信息等，都必须与这些智能合约进行交互。

Push 智能合约现在是如何工作的？

Push 智能合约目前以以下方式设计：

1. Push Core 合约：
2. 仅部署在以太坊上。
3. 这是处理所有强制性功能的主要合约，例如频道创建、激励机制（如 staking）、频道状态更改、激励聊天请求功能等。
4. 除了功能外，Push Core 合约还包括协议费用池，用于存储核心智能合约通过不同操作赚取的费用。然后，这些费用用于 激励代币持有者。
5. Push Communicator(Comm) 合约：
6. 部署在 多个 EVM 链 上，这是一个轻量级合约，主要处理 sendNotification 功能以及 频道别名相关的功能。
7. Push Comm 合约位于多个链上，这使得 Push Protocol 能够支持任何其他链上的通知。

现在你已经了解了 Push 的当前状态，让我们进入下一个阶段。

那么，有什么问题？

应该注意的是，对于 Push Protocol 中所有与频道相关的关键功能，都必须与仅部署在以太坊链上的 Push Core 合约进行交互。

这意味着用户必须始终切换到以太坊网络才能进行任何与其频道相关的重要操作。

对于想要与 Push Core 合约交互的现有或新用户来说，这会导致糟糕的用户体验。这种仅使用一个特定网络的严格要求非常麻烦，特别是对于主要在其他 EVM 兼容链甚至非 EVM 用户上操作的用户。

此外，这也成为了 Push Protocol 的一个障碍。

对以太坊的严格依赖限制了 Push Protocol 利用其他链并充分解决这些链的通信/通知问题的能力。这种约束阻碍了协议接触更广泛的受众并解决各种区块链环境中的通信问题。

为什么不在多个 EVM 链上部署 Push Core？

解决此问题的一个显而易见的解决方案是，“嘿，为什么不在多个链上部署 Push Core？”

虽然这听起来像是一个简单的解决方案，但事实并非如此。

Push Core 合约包括一个关键组件，称为费用池。每当 Push Core 合约中发生任何重要操作时，例如创建频道、更新现有频道、重新激活/停用频道或创建激励聊天请求，合约都会向用户收取费用（少量 10 个 PUSH 代币）。

合约累积的这些费用存储在 FEE_POOL 中。这是一个关键组件，因为这些累积的费用用作激励机制，并在 Push 代币持有者之间分配。

简而言之，这些奖励与协议的增长直接相关。随着协议随着更多频道的增长而增长，费用也会增加，从而增加对 Push 代币持有者的激励。

现在，这是在多个链上部署 Push Core 的问题所在。

Push Core 合约的多次部署意味着各个链上有多个费用池，并且随着 Push 开始支持更多链，这些费用池会不断增加。

这导致在所有不同链之间处理和同步多个费用池的困难情况。这最终会影响代币持有者的激励框架，因为它与 Push Core 合约的费用池相关联。

简而言之，在不同链上部署多个 Push Core 并不理想，因为它会导致现有架构的重大修改，从而使该实现非常复杂、安全性降低且耗时。

问题陈述

考虑到以上所有详细信息，以下是最终的问题陈述：

1. 增强现有和新 Push Protocol 用户在与 Push Core 智能合约交互时的用户体验 (UX)。
2. 减少 Push Smart Contracts 对以太坊链的严格依赖。
3. 该解决方案应优先考虑安全性，并最大限度地减少对现有架构的极端破坏。
4. 并且，Push Core 不能部署在多个链上。

那么，我们该如何解决它？

进入，跨链请求功能 ( CCR )

现在，我们进入激动人心的部分，CCR 功能。

跨链请求 ( CCR) 功能将使用户能够从他们选择的链执行重要操作，例如频道创建、创建激励聊天请求或任何任意请求。

换句话说，用户将不再需要将其网络切换到以太坊才能与 Push Core 合约交互。相反，他们可以留在自己喜欢的链上，并且仍然能够无缝地与 Core 合约交互并执行所需的操作。

CCR 功能的核心思想是使 Push 智能合约能够处理可以源自任何链的请求，并安全地中继到以太坊上的 Push Core 合约以进行必要的验证和状态更改。

CCR 的实施建议

以下是我们为 Push Smart Contracts 提出的 CCR 功能实施方案。

很明显，在多个链上部署 Push Core 不是一个解决方案。因此，最佳前进方向似乎是：

1. 利用 Wormhole 的 NTT 框架和 Relayers
2. 利用 Push Communicator 的多链存在

让我们快速探索每一个：

1. Wormhole 的 NTT 框架和 Relayers

CCR 的想法是能够将消息（或代币）从任何链上的 Push Comm 合约中继到以太坊。这意味着我们需要一个跨链网络，使我们能够安全地将我们的消息和代币从 Comm 中继到 Core。

为了实现此功能，我们目前建议使用 Wormhole 的 NTT 架构 和 Relayers。但是，随着 Push 新功能的实现，这将来可能会发生变化。

以下是选择 Wormhole 用于此功能的一些重要原因：

• 用于代币桥接的 Wormhole NTT 框架：
  1. Wormhole 的 NTT 框架最适合我们，因为它使我们能够使用现有的 Push 代币及其框架无缝地使用。
  2. 最重要的是，通过 NTT，我们将能够保留对代币的所有权、升级权限和可定制性，因为 NTT 框架可以与任何代币合约或标准以及任何协议管理流程集成。
• 支持 EVM 和非 EVM 链：
  • Push Communicator 合约本质上设计为可以部署在所有链上。
  • Wormhole 对 EVM/non-EVM 链的广泛支持与 Push Communicator 合约的最终愿景非常吻合
• 安全且经过实战测试的桥接网络：
  • 由于安全性对我们来说至关重要，我们认为 Wormhole 是一个经过实战测试的网络，用于在中继链之间中继代币或任意消息。

2. Push Communicator 的多链存在

现在，让我们来看看我们如何利用 Push Communicator 合约。

如前所述，Push Comm 智能合约被设计为一个轻量级且独立的智能合约，可以轻松地部署在多个链上。

这是我们已经拥有的一个额外优势，它降低了实施 CCR 功能的复杂性。由于 Push Comm 已部署在多个 EVM 兼容链上（并且很快将部署在非 EVM 链上），因此它已经解决了将智能合约扩展到多个链的第一个问题。

下一步将是 在已存在的 Push Comm 合约中实施跨链请求功能。

这意味着我们必须在现有智能合约中包含以下更改：

1. Push Communicator 合约所需的修改
   • 接受来自用户的消息有效负载：
     • 第一步允许用户传递有效负载，该有效负载可以是代币值或消息（或两者一起），必须将其桥接到 Push Core 合约以触发特定操作。
     • 例如：传递 50 个 push 和频道详细信息作为有效负载，以在以太坊链上的 Push Core 上创建频道。
   • 验证消息有效负载：
     • Push Comm 还必须验证用户发送的消息有效负载是否足够。
   • 中继消息有效负载：
     • 验证后，最后一步是将此有效负载安全地桥接到 Push Core 合约。
2. Push Core 合约所需的修改：
   • 包含 receiveWormholeMessages():
     • 这是 Core 合约能够接收、解码和处理传入有效负载的必需函数。
   • 调整现有功能：
     • 此外，核心合约还需要对现有功能进行修改，以确保它们兼容处理跨链请求。

那么，频道创建的未来是什么样的？

1. Bob 是一位原生 Polygon 用户，他的钱包中有 Polygon-PUSH 代币。他想创建一个频道并开始发送通知。
2. BOB 不必将 $PUSH 代币从 Polygon 桥接到以太坊并更改网络，只需转到 Polygon 上现有的 Push Communicator 合约即可。
3. 启用跨链请求功能后，Push Comm 合约将具有一个名为 createChannel() 的函数
4. BOB 调用此函数并提供其频道的详细信息，即频道的名称、描述、类型等。
5. 频道创建还需要 50 PUSH，因此 BOB 还批准 Push Comm 使用 50 个 PUSH 代币。
6. 除了这 50 个 PUSH 之外，BOB 还发送了一些原生代币（即在本例中为 MATIC）以提交交易。应该注意的是，任何未使用的 Matic 都将退还给 BOB。
7. 提交交易后，Push Comm 上的_ createChannel() 函数 应执行以下操作：
   1. 验证 BOB 提供的输入和代币值是否有效。
   2. 创建提供的输入的有效负载。（此有效负载最终将桥接到 Core）
   3. 创建后，它使用 Wormhole Relayers 将任意数据（包含有关正在创建的频道的详细信息的有效负载）中继到以太坊上的 Push Core。
   4. 然后，它使用 Wormhole 的 NTT 框架将 50 个 PUSH 代币从 Push Comm ( polygon ) 桥接到 Push Core ( eth )。
8. 此步骤的完成应表示 BOB 创建频道的请求已被成功接受并中继到 Push Core 合约。
9. 需要的最后一步是 Push Core 合约能够处理此传入的跨链请求。
10. 一旦 Wormhole 中继器将代币和消息有效负载桥接到以太坊上的 Push Core，Core 合约将执行以下操作：
    1. 解码传入的有效负载。
    2. 检查并验证有效负载包含的请求类型，即本例中的频道创建请求。
    3. 然后，它使用有效负载数据调用 Push Core 上的实际 createChannel() 函数，更新 Core 合约的状态，从而成功完成来自 BOB 的请求。
11. 只要执行此交易，BOB 最终就会在以太坊上的 Push Core 上成功创建一个频道，而无需离开 Polygon 链。

好的，解密者们，

希望你对 Push Protocol 的频道创建的未来有所了解。

我将尽快回来发布更多相关更新。

并期待更多关于跨链的文章。

下次见。

\ Solididity ABI 编码的深度心理模型：第 1 部分\ 为什么要学习 Solidity 的困难知识 [ ABI 编码系列：第 0 部分 ]\ \ Solididity 很 EASY。\ \ 它是一种简单而美丽的语言。\ \ 随着卓越的教育资源、课程、开发工具和 LLM 的兴起，学习和编写 Solidity 从未如此简单。\ \ 但这是一个残酷的事实——如果每个人都容易上手，那么\ 我在 SUI-Move 中的第一个迷你项目 - 第 2 部分\ 我对 Move 智能合约的首次体验 - 第 1 部分\ \ 我最近尝试了一种新的智能合约语言 MOVE。\ \ 该语言的灵感来自 Rust，因此 Solidity 开发人员对其并不直观。\ \ 然而，使用它进行构建非常有趣。\ \ 在本系列文章中，我旨在介绍 Move 语言及其功能。

• 原文链接： decipherclub.com/push-pr...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～