浅研Push Protocol（获得创始人和官方认可）

注：这是我之前发在twitter关于对研究的内容，今天看到被它们创始人和官方认可互动了，所以觉得比较有价值，故整理成文章发给粉丝们，另外也请大家关注我的twitter @jason_chen998，及时获取最新信息

    之前提到了假的protocol @HookedProtocol，今天浅研了一下真的protocol @pushprotocol，看看正经的协议到底是什么样。

    push protocol之前叫EPNS，在9月份才改为现在这个名字，从这两个名字都可以看出来它是做消息推送协议的，我先从它改名字的过程中了解一下前世今生，然后再分析具体实现和项目价值

    首先之前的名字EPNS的含义是以太坊消息推送服务，做过ios开发的朋友应该熟悉APNS（Apple Push Notification Service），所以明白为什么它叫EPNS了吧，把apple换成了Ethereum。

    那为什么又改名了呢？因为它现在开始支持polygon等多链，所以继续叫EPNS会把自己和以太坊在品牌上绑定，于是直接叫自己 push protocol。

    它也完成了一千万美金融资，是web3通信的头部项目，我们接下来详述它具体做的事情。

    消息推送是web2不可或缺的一环，从IM聊天、到新闻、再到各种营销信息、通知提示等，整体不管是场景还是技术都非常成熟，但是在web3中，请你立刻3秒钟回想用过什么可以消息推送的dapp？3、2、1，很难想到是吗？

    主要原因有两个:

    第一，目前web3应用大多数都以网站形式呈现，移动端发展极其缓慢，因为消息推送是即时性的，web2也是在移动互联网出现后消息推送才大范围应用，后面有机会再和大家分析web3移动端的问题

    第二，web3的基建层消息推送目前确实是一块发展洼地，能看到的成熟解决方案不多

    即使如此web3依然有大量需要消息推送的场景，比如defi价格变动、ENS域名过期、借贷清算预警、gas异常预警等，这些场景也是EPNS可以解决的。

    以及很多时候你要检查交易是否完成只能自己去链上查看，智能合约最多只能抛出一个event由第三方去处理，整套过程不论对用户还是项目方都很不友好

    下图为ios的app对消息推送的原理，APNS作为中转服务，分为3个阶段:

    阶段1:上游项目方把要发送的消息和接收的iPhone标识打包，发给APNS。

    阶段2:APNS在注册Push服务的iPhone列表中，查找有相应标识的iPhone，并把消息发到iPhone。

    阶段3:iPhone把发来的消息传递给应用程序，并且按照设定弹出Push通知。

    下图为EPNS的原理，其实会发现结构上和web2的APNS是一致的，上游的DAPP、服务、合约等输入层会把要推送的信息和接收地址给到EPNS，由它进行分发中转出去，第三方产品可以使用EPNS的消息捕获接口获取并显示出来对应的消息。

     简单来说，可以理解成合约、后端服务等上游可以在需要消息推送的地方埋一段EPNS的代码，并传入对应消息内容，EPNS就会帮你把这个消息广播给对应地址，当然你必须还要在下游有个前端负责接收消息，并把它展示出来，而不是像很多人以为它会神奇的直接出现在你的小狐狸钱包里（当然也许后面小狐狸会支持）

    所以EPNS做了一个自己的消息盒子插件的前端用来接收消息，当然其他任何第三方产品都可以使用EPNS的接口去展示用户所收到的消息，包括小狐狸，这也就是为什么我叫他真的protocol原因，这是正儿八经的中间件协议层，万物可接，万物可用。

    在EPNS中主要有3个概念：用户、频道和订阅者，用户是指所有在EPNS中的实体包括合约、钱包、人员等，

    如下图所示当我打开它的操作台后，并点击channels栏目右侧会出现很多频道，这些频道就是用户所创建的，我可以点击选择加入和退出，点击加入需要签名，然后就相当于订阅了该频道的消息

    当频道中进行消息推送时，就会发送给所有订阅了的钱包地址，这里和web2的APNS有区别，APNS是项目方决定我要将消息推送给谁，而EPNS则是采用订阅制，只有你订阅了我的消息才会进行推送，所以用户掌握绝对的消息获取权，可以随时取消订阅。

    EPNS也是少有已经发币的早期协议，如下图所示，币价不予评价。

    EPNS中涉及到钱的主要是频道创建需要质押50DAI，如图创建频道需要填写以下内容，并且发送消息时需要消耗DAI或ETH，所以项目方出于成本考虑也不会乱发消息。

    暂未在产品内看到有原生token的消耗场景，具体原因尚不得知，也许是我还没发现

    EPNS可以支持多种消息发送源，我们以智能合约为例看一下具体实现方式，首先导入EPNS的合约接口，然后设置你的频道地址，每个用户创建的频道都会分配一个频道地址，然后设置接收地址，你可以指定某些订阅地址，也可以直接设置为广播模式即所有订阅者都会接收。最后按照EPNS的标注数据格式传入内容数据

    这样当你的合约代码执行到对应位置时就可以完成一次消息内容的触发，由EPNS的节点进行内容的中转。

    消息发出去后，下游的需要对消息进行接收然后展示，接收的方式EPNS给出了三种。

    可以通过API直接接收，也可以通过webhook来监听，最后还可以直接读取EPNS节点来接收，这种方式就很web3 native了。

    EPNS的内容还有非常多，包括他们和the graph、ethsign等深度合作，以及它们基于其协议自研的应用层聊天软件Push Chat等等，EPNS我给予比较高度的评价，它是真正的干了协议该干的事情，大量的第三方接入和原子化能力，值得期待该项目更多的新动向。

    欢迎阅读转发本文，如果有收获欢迎打赏，也请关注我的twitter：@jason_chen998，有需要也可添加微信 cj350306878，请备注姓名、公司和目的，谢谢。

往期文章：