When things go awry, it is imperative to identify exactly what went wrong in order to prevent the same thing happening again in the future. This is all the more true in financial technology, where any hiccups can lead to pronounced consequences.
Everscale developers work continuously to improve every aspect of the Everscale blockchain. Today, we want to share a couple of updates to the network’s transaction executor implemented to make the handling of bounce messages easier and more transparent. Such messages normally show up when transactions do not make it to the finalized state.
To that effect, Global Capabilities mechanisms have been switched on in the network, thus upgrading the bounce messages received after a transaction failure.
But first, let’s cover some essentials
This is the Transaction executor message processing scheme that you can find in the docs:
Stages of transaction processing
Credit — Message coins are put on the Storage balance agent;
Storage — The storage fee is deducted from the Computer balance agent;
Computer — The contract bytecode gets executed inside TVM with proper parameters. The contract generates Actions;
Action — Generated actions get executed by the action handler, producing outbound messages;
Bounce — The bounce phase is triggered if failure happens during the compute or action phase. This most often results in the reply getting sent back with coins;
Out messages — The queue gets delegated to other validators.
As we can see from the scheme description above, a bounce message is sent from the smart contract that received the message back to the message sender if the Compute stage fails.
Getting the full body of a bounce message
Earlier, Everscale nodes had only one Global Capabilities mechanism related to bounce messages, CapBounceMsgBody, which made the Transaction executor include the first 256 bits (32 bytes) of the original message into the bounce message body. But there was a trick — 4 bytes of the bounce message size were allocated to include the ID of the function that was called by the message. Therefore, developers had to get by with only 28 bytes of the original message which could hinder the handling of the bounce message.
Presently, we have another mechanism called CapFullBodyBounced. The mechanism, now active in the network, ensures the receiving smart contract to include the full body of the in-message into the bounce message sent as a result of failed transaction processing.
This update is going to simplify the development of smart-contract interactions.
Let it bounce after Action
Another issue that has been successfully addressed is that sometimes when a failure occurs during the Action stage after successful computing, a bounce message is not triggered.
A situation in which a sending smart contract (with active bounce flag) doesn’t receive a bounce message after a transaction failure will never happen in the future. Why? Well, we have introduced a mechanism that has already been activated and now ranks among other Global Capabilities — CapBounceAfterFailedAction.
As its name suggests, the capability ensures that a bounce message is sent every time there is a failure in the Action stage and the sender is willing to receive a bounce message back.
