Everscale Node February 2024 Updates
We keep on informing you about the development of the Everscale node, one of the crucial protocol components, in our monthly digest. In February 2024, our developers released lots of updates making the node client even more secure, efficient, and up-to-date. Without further ado, let’s dive into the details!
Queue Clearing
One big change implemented in the Everscale Node client is the ability to finish the process of clearing an outgoing messages queue after the completion of the shard-splitting procedure. Before this update, it had to be done within splitting, creating a possibility for exploit.
To illustrate the significance of this change, let’s break down how workchains in Everscale manage their queues of outgoing messages. When a smart contract from workchain A wants to call another contract from workchain B, it creates an outgoing message. The workchain A stores this message. Then, workchain B gets the state of workchain A, locates that outgoing message, and executes it. The workchain A realizes the message is delivered and removes it from the queue.
Now, let’s consider that workchain A sent the message to many other workchains, increasing the queue, and decided to split itself into two new workchains (shards), namely A1 and A2. This process takes time. A Collator (a validator node assigned to produce, or collate blocks) of the new workchain A1 must only keep the messages belonging to contracts from the A1, removing all the messages for the workchain A2.
This system operation does not cost gas for users, meaning it can be exploited by creating a queue so big that a new shard might not finish the splitting of messages within the collation time.
To prevent this exploit, we improved the Collator and validator in a way so they would finish the clearing operation after the collation.
Other updates
Aside from the queue clearing, we dealt with other advancements to the Everscale node in February 2024:
- The Everscale node can now utilize the old persistent state. This update is intended to fix the bug in one of the testnets: a node could not synchronize with the network because it did not find fresh persistent states. Although such a situation is hardly possible in the mainnet maintained by plenty of “good” nodes that generate and share new persistent states, we decided to optimize the synchronization process, letting a node use the older persistent state in case it can not find the latest one.
- Capability CapTvmV19. Now, the Everscale mainnet works on the 1.9.x version of the virtual machine. Upon a transfer to the new version, we activated several improvements related to calculating the gas for some operations, and security patches for a few working instructions.
- Solidity compiler received the new version (0.73.0), which generates ABI v 2.4. The actual list of changes is quite long, you can read the full changelog in our GitHub.
Here are the other minor changes:
- added more debug output upon sending an ADNL query;
- fixed compiler warnings and updating the default configuration with REMP;
- reverted the use of all peers for requesting key block IDs;
- updated the recommended version of the Rust compiler to 1.76;
Two new issues were published in the Evernode repository: about making the virtual machine support BLS12-381 (this can bring some new features to the Everscale protocol, in particular, zero-knowledge proofs), and about not deleting frozen accounts.
