In January 2024, our engineers activated the Reliable External Messaging Protocol (REMP) in the Everscale mainnet. While REMP flew under the radar for the general public, it is a significant advancement for the network included in its roadmap. If you are keen to learn more about the Everscale protocol, explore REMP together with us in this article.
Types of Messages in Everscale
REMP stands for Reliable External Messaging Protocol, and “reliable” is probably the key word in this acronym. But first, let’s explain what role external messages play in Everscale and many other blockchains.
Simply put, a message is a means of delivering information and instructions from one smart contract to another, or from a user to a smart contract. Messages are kinds of orders for initiating transactions that are executed by smart contracts. Keep in mind that every on-chain entity in Everscale is a smart contract, including user accounts, so they exchange messages, too.
There are two types of messages in Everscale:
- Internal messages. Information about a transaction passed from one Everscale blockchain account to another. An internal message does not require a cryptographic signature. After receiving it, a smart contract located at the target address can execute the requested transfer.
- External messages. This type of message carries information sent or received from an external source outside of the Everscale blockchain, usually from a user’s device.
While internal messages usually work like a clock, things can get hectic when it comes to external ones.
What REMP Changed in the Messages’ Handling Process
Before the integration of REMP, when a user sent an external message, he specified an expiration time that indicated the deadline for executing it. There was no method for checking what happens to a message once it reached the blockchain, so the only option was to monitor the network activity and wait until the expiration.
Whether a message was lost, tried to get executed, or failed to do so due to an error, was unknown. If the message did not appear in the blockchain by the expiration time, it meant it was lost forever.
To mitigate users’ distress, developers have come up with various retry mechanisms, e.g. attempting to execute a message themselves to check for errors in case it did not appear on-chain.
The main improvement brought to Everscale by REMP is the ability to fetch an external message’s current and past statuses. In other words, now a message passes through certain “checkpoints” on its way to a recipient, marking them with timestamps. This ensures a message is easy to track and locate, as well as identify the cause of failure if one occurs.
Below is the visualization of the flow for processing an external message in REMP, starting from a node or an application through a queue and down to the master chain, when it gets finalized:
With REMP, developers gained the ability to track a message by receiving a receipt when a message, in particular, has been delivered to the validators, added to a block, or, finally, when the block with a message has been added to the masterchain.
This is similar to message statuses in social messaging apps: when you send a message, you can see that it is sent but has not yet reached the server, then a message’s status updates to “delivered”, and then to “read” when a recipient opens it. Thanks to REMP, similar experience is available for external messages in the Everscale blockchain.
REMP’s Technical Improvements
Besides statuses for external messages, REMP also introduced several technical solutions, which might not be noticeable to end-users but add to Everscale’s stability and reliability.
Firstly, now an Everscale validator can only execute an external message if there is a network consensus that this message has been delivered to the majority of validators. Previously, a validator could invent an external message on the fly and execute it if it was their turn to create a block. Now, only messages that the most validators contain can be used when generating a new block.
The second significant change is that the current external message does not attempt to execute multiple times. Let’s elaborate on what that means.
Before REMP was introduced, external messages spread randomly among validators. A validator that created a block also sought to execute messages completed by a previous validator. That slightly increased the amount of required computations.
Moreover, it was possible to write a smart contract that did not have replay protection, and sending an external message made it execute multiple times until the contract’s funds ran out. This happened due to different validators applying the same message in the process of creating blocks. Now, each message is unique, and there are rules that prevent it from recurrence if it has already been executed once.
Closing Thoughts
Activation of REMP is a significant milestone listed in Everscale’s 2023 roadmap, which will further enhance the process of building and maintaining decentralized applications on our blockchain. To sum up, the protocol adds several new distinctive features for message management, in particular:
- Replay protection. If an external message is added in a block after processing, it will not be collated for a while. In addition to an expiration time, this creates a replay protection.
- Loss protection. A message must be only sent once to be delivered to a recipient. It is added to a block when the possibility for that appears. The only chance of losing a message is network overload.
- Traceability. An external message passes through several “checkpoints” on its way through a queue to a recipient, e.g. when it is delivered to validators for confirmation, adding to a block, etc. This gives an accurate prediction about processing a message successfully in a given time.
Our developers published detailed documentation on REMP, so if you build on Everscale, look there for more technical details, such as methods for getting a message’s statuses throughout the flow, or for subscribing to its receipts, as well as retrieving some other data.
