Pre-PIP: 3
Author: Zaryab Afser
Discussions: Not Applicable
Created: 30th July 2024
Simple Summary
Pre-PIP 3 is a proposal to implement the Cross Chain Requests feature in Push Protocol smart contracts (i.e., PushCore and PushComm). Once enabled this feature shall allow users to interact with Push Core smart contract on the Ethereum chain, from any EVM or Non-EVM chain of their choice ( without leaving their favorite chain).
Abstract
Cross Chain Requests ( CCR) feature shall be one of the most significant features of Push Smart Contracts as it will enable users to perform important actions like channel creation, creation of Incentivized Chat requests, or any arbitrary request from the chain of their choice.
In other words, users would no longer need to switch their network to Ethereum to interact with the Push Core contract. Instead, they can remain on their favorite chains and still be able to interact with the Core contract seamlessly and perform the required actions.
Motivation
Push Smart Contracts are currently designed in the following way:
- Push Core Contract:
- Deployed only on Ethereum.
- The main contract handles all the imperative features like channel creation, incentivization mechanisms like staking, channel state changes, incentivized chat request functionalities, etc.
- Apart from features, the Push Core contract also includes the Protocol Fee Pool which stores the fees earned by the core smart contract via different actions. These fees are then used to incentivize token holders.
- Push Communicator(Comm) Contract:
- Deployed on multiple EVM chains, this is a lightweight contract that primarily handles sendNotification features as well as channel alias-related functionalities.
It’s noteworthy how all imperative functionalities that a user or other web3 protocol might require to interact with Push Smart Contracts are included in the Push Core contract which is only deployed on the Ethereum chain.
- Deployed on multiple EVM chains, this is a lightweight contract that primarily handles sendNotification features as well as channel alias-related functionalities.
The problem here is quite clear as the user must switch to the Ethereum network for any interaction they would want to do with the Push Core contract.
This leads to a bad user experience for existing or new users who want to interact with the Push Core contract. This strict requirement to only use one specific network is cumbersome, particularly for users who primarily operate on other EVM-compatible chains or even Non-EVM users.
Additionally, this acts as a barrier to Push Protocol as well.
The reliance on Ethereum exclusively limits the Push Protocol’s ability to tap into other chains and help solve the communication/notification issues of those chains adequately. This constraint hinders the protocol from reaching a broader audience and solving communication issues across diverse blockchain environments.
Therefore, by enabling a cross-chain request feature, Push Protocol can primarily significantly enhance the UX for average users as well as channel creators/managers from not just Ethereum but multiple other EVM/Non-EVM chains as well. It also allows the protocol to expand its market reach, attract users from different chains, and foster a more interconnected blockchain ecosystem.
Specification
Overview
The core idea of Cross Chain request feature is to make Push smart contracts capable of handling requests that can originate from any chain and are securely relayed to Push Core contracts on Ethereum for necessary validations & state changes.
As previously mentioned, the Push Comm smart contract was designed to be a lightweight and stand-alone smart contract that can be deployed on multiple chains quite easily.
This is an added advantage that we already have which reduces the complexity of implementing Cross Chain Request features being proposed in this Pre-PIP. Since Push Comm is already deployed on multiple EVM-compatible chains ( and soon non-EVM chains), it already resolves the first concern of expanding the smart contracts to multiple chains.
The next step would be the implementation of the Cross Chain Request feature in already existing Push Comm contracts.
This means the following changes in the existing smart contracts:
Push Communicator contract can be upgraded to implement cross-chain features that allow it to perform the following actions:
- Receive a msg payload from users on any chain.
- Securely relay this message to Push Core Contract on Ethereum
Push Core would require some modifications as well. These modifications would specifically allow Push Core contract to perform the following actions:
- Receive relayed messages or tokens from Push Comm
- Validate the incoming message payloads
- Update states in Core Contract.
How exactly can we bridge tokens and messages?
To achieve this feature, we currently propose using Wormhole’s NTT architecture and Relayers, this might change in the future as new features of Push get realized.
This will allow us to securely bridge arbitrary message payloads as well as tokens from one chain to another allowing us to relay any important requests like channel creations from any chain to Push Core on Ethereum.
In the next sections, it should be clear why these design choices are being proposed for the CCR feature.
Before that, let’s visualize how this entire flow would work with the help of a quick example of BOB creating a channel on Push Core via the CCR feature:
Complete flow of CCR:
- Bob is a native Polygon user and has a Polygon-PUSH token in his wallet. He wants to create a channel and start sending notifications.
- Instead of bridging $PUSH tokens from Polygon to Ethereum and changing the network, the points BOB to the already existing Push Communicator contract on Polygon.
- With the Cross Chain Request feature enabled, the Push Comm contract has a function called createChannel()
- BOB calls this function and provides the details of his channel, i.e., channel’s name, description, type, etc.
- Channel creation also requires 50 PUSH, so BOB also approves 50 PUSH tokens to be used by Push Comm.
- Along with this 50 PUSH, the on-chain transaction also uses some native tokens ( i.e., MATIC, , in this case,) for the transaction to be submitted. It should be noted that any unused MATIC shall be refunded to BOB.
- Once the transaction is submitted, the _createChannel() function on Push Comm shall perform the following actions:
- Validates the provided input and token value by BOB is valid.
- Create a payload of the provided input. ( this payload will be bridged to Core )
- Then, use Wormhole Relayers to relay the arbitrary data( payload containing details about the channel being created) to Push Core on Ethereum.
- Then, use Wormhole’s NTT framework to bridge the 50 PUSH tokens from Push Comm ( polygon ) to Push Core ( eth ).
- The completion of this step shall indicate that BOB’s request to create a channel has been successfully accepted and relayed to the Push Core contract.
- The last step required is for the Push Core contract to be able to handle this incoming cross-chain request.
- Once Wormhole relayers bridge the tokens and message payload to the Push Core on Ethereum, the Core contract performs the following actions:
- Decodes the incoming payload.
- Checks and validates the type of request contained by the payload, i.e., channel creation request in this case.
- Then use the payload data to call the actual _createChannel() function on Push Core, updates the state of the Core contract and thus, successfully completes the request from BOB.
As this transaction gets executed, BOB ends up having a channel successfully created on Push Core on Ethereum without ever having to leave the Polygon chain.
Here is a simple diagram to visualize how cross-chain features would look like:
Rationale
To understand the rationale behind the proposed implementation above, we must acknowledge that Push Smart Contracts are already live on Ethereum as well as many other L2s. Therefore this feature must be implemented keeping two crucial points in mind:
- it should be implemented with minimal changes in the existing architecture,
- It should be implemented with a security-first approach and keeping best practices in mind.
A simple solution to solving this would have been to deploy the Push Core contract on multiple chains so that users could easily interact with the Core contract without changing their network to Ethereum.
Let’s understand each one individually.
-
Why not deploy Push Core on multiple chains?
A simple solution to resolve this would have been to deploy the Push Core contract on multiple chains so that users could easily interact with the Core contract without changing their network to Ethereum.
While it does sound simple it isn’t really.
Multiple deployments of Push Core contracts indicate multiple fee pools on various chains which keeps increasing as Push starts to support more chains.
This leads to an extremely difficult scenario of handling and syncing up multiple fee pools between all different chains. This will eventually affect the incentivization framework for token holders as well since it’s tied to the fee pool of the Push Core contract.
In a nutshell, deploying multiple Push Core on different chains to achieve this feature is not ideal as it leads to significant modifications in the existing architecture, thereby making this implementation quite complex, less secure, and time-consuming.
-
Why modify the Push Communicator contract?
Now that we understand why Push Core on multiple chains is a bad idea, it’s easier to understand why Push Communicator is the right way to go.
As previously mentioned, the Push Communicator contract has the added advantage of being already available on multiple chains due to its design. This makes it quite easy to implement and expand this feature to multiple chains.
Secondly, this allows us to not make significant changes in the existing architecture of Push smart contracts, hence more secure, reliable, and faster.
-
Why use Wormhole NTT framework & Relayers for Cross Chain Feature?
After a thorough research on all existing arbitrary messages & token bridging protocols, we realized Wormhole fits best for our requirements.
Mentioned below are some of the important reasons:
- Wormhole’s NTT Framework for Token Bridging:
- Wormhole’s NTT framework is best suited for us as it allows us to use our existing Push Token with its framework seamlessly.
- Most importantly, with NTT we will be able to retain ownership, upgrade authority, and customizability over our token as the NTT framework can integrate with any token contract or standard and any protocol governance processes.
- Support for EVM & Non-EVM Chains:
- The Push Communicator contract is essentially designed to be deployed on all chains.
- Wormhole’s wide range of support for EVM/Non-EVM chains aligns very well with the eventual vision of Push Communicator contracts.
- Secure and Battle-Test bridging network:
- Since security is of utmost importance to us, we believe Wormhole is a battle-tested network for relaying tokens or arbitrary messages between chains.
- Wormhole’s NTT Framework for Token Bridging:
Implementation
To support this Cross Chain Request feature, we foresee the following crucial developments in our existing architecture:
- Enabling Push Token for Multi-Chain Support,
- Building Cross-Chain Support in Push Communicator, and
- Building Cross-Chain Support in Push Core Contract.
Note: The only external libraries needed for this feature would be Wormhole’s Relayer Interface and NTT framework support
Let’s understand the implementation at each level.
-
Enabling Cross Chain support for Push Token
As mentioned above, this feature would require Wormhole’s Native Token Transfer (NTT) framework which means the $PUSH Token must be able to support the NTT-related features.
To achieve this the following steps are required:
- Develop a $PUSH Token for NTT Support:
- This will ensure that the $PUSH token on different chains is capable of supporting Wormhole’s NTT framework.
- Deployment of NTT-supported $PUSH Token:
- Once the NTT Wrapped $PUSH Token is developed, it shall be deployed and activated on other chains.
- This ensures that PUSH Comm will be able to handle cross-chain token transfers using this $PUSH token on any chain, once deployed.
Note: It must be noted that since Wormhole’s NTT framework will be used for token transfers, $PUSH token shall be completely owned and governed on any specific chain natively by Push Community, as it is currently done for the Ethereum chain.
- Develop a $PUSH Token for NTT Support:
-
Building Cross-Chain Support in Push Communicator:
The second step would be to build the necessary functionalities in the Push Communicator smart contract.
Push Communicator contract will be able to support functionalities that allow users to perform imperative actions like channel creations, channel modification, creation of chat requests, or creation of any arbitrary request on Push Core contract on Ethereum.
These functions will mainly perform the following actions:
- Collection of Payload ( message payload and/or token value ):
- The first step allows users to pass the payload which could be token value or messages ( or both together ) that must be bridged to the Push Core contract to trigger a specific action.
- For instance: passing 50 push and channel details as payload to create a channel on Push Core on the Ethereum chain
- Validation of Payload:
- This includes validating the payload on the contract level to ensure the data being passed is accurate.
- Relaying of Payload:
- Once validated, the final step is to bridge this payload to the Push Core contract securely.
- It must be noted that these functions will be able to bridge/relay both token value as well as arbitrary message data, based on the requirement of the function being called.
- For Token Bridging: The Push Comm shall rely on Wormhole’s NTT framework for any token value transfer.
- For Arbitrary Message Bridging: The Push Comm shall rely on Wormhole’s Relayer interface and use its
sendPayloadToEvm()function for the same.
- Collection of Payload ( message payload and/or token value ):
-
Building Cross-Chain Support in Push Core Contract
While most of the development shall be required in Push Communicator contract, Push Core also needs to be capable of handling the incoming requests from different chains.
Therefore the main implementation required in Push Core contract would be:
- Inclusion of
receiveWormholeMessages():- This is a required function for the Core contract to be able to receive, decode as well as process the incoming payloads.
- Processing the incoming payloads indicates that this function shall route the payload according to the request type. For instance, if a payload is sent to create a new channel, the function must correctly identify this payload type and then trigger the _createChannel() function in the contract with the accurate data from the payload.
- Adjustments in existing functionalities:
- Additionally, the core contract also needs to include modifications in the existing functions to ensure they are compatible for handling cross-chain requests.
- This means ensuring that the functions are updated to handle not just the simple calls from the Ethereum chain but also from multiple other chains. This could involve updating arguments, validation logic, etc.
- Inclusion of
-
Final Stages of CCR Feature
Once the core architecture for CCR is complete, we shall proceed with the following final actions:
- Test cases that cover all CCR-related feature
- Security Audits for modified smart contracts
- Deployment and Upgrade of testnet and mainnet contracts.
Here are the requests for all the community members:
- Share your thoughts and ask as many questions as you wish to on this PRE-PIP
- Use the poll below to express your thoughts on Pre-PIP 3:
- For
- Against
Great to see Pre-PIP 
I know Push was founded as EPNS, and we all love and adore Ethereum, but it is truly a monumental step to see the growth beyond Ethereum.
Technical Viability: Wormhole appears to be a solid option for cross-chain management, providing a proven infrastructure for message and token transfers.