After network-wide technical issues left users worried, Everscale is releasing a comprehensive plan to improve the operation of the network and make it more secure for end users.
The Everscale network experienced several tech issues starting on April 25. In response to the disruptions, devs immediately prohibited the activity of the smart contract that tried to exploit a vulnerability in the node.
The overall plan to remedy the issue is three-phased: immediate response, upcoming improvements, and later integrations.
NB To accelerate the implementation of the plan, an alliance comprising Broxus and EverX devs was formed.
1. Immediate response
Enhanced monitoring system
Improvement of the monitoring system will supply devs with more actual (processed) information about the activity on the network. To make this happen, three core conditions have to be met. First, information about specific nodes that collate and validate blocks in a problematic shard needs to be made available. Second, since one of the problems is getting logs from the collating machine, a mechanism enabling logs to be delivered to the node command is needed. Third, in order to be able to look more accurately into the logs, a mechanism for prod network forks (to replace validator sets) is required.
Let’s look at the steps we need to take to achieve this:
1) Setting up additional monitoring tools for speedier reactions from the moment an attack is launched to its detection. This will help commence incident resolution more rapidly.
2) From the moment an attack is detected, a working group will be formed for the immediate collection of logs.
3) A wide-scale investigation in order to have a clear picture of what exactly is going wrong.
4) The formation of a global fix of the identified issue after there is a complete understanding of what happened and a guarantee that the actions taken would not make the situation worse. The process will unfold according to the following points:
a) Examining how much time the repair process would take.
b) All actions taken involving the human factor will be re-checked by several people.
5) Community announcements
a) News about incidents will be provided within an hour after they are detected. No room for speculation will be allowed – only confirmed facts will be communicated.
b) Close cooperation with validators so that they are ready to be updated.
2. Upcoming improvements
Keeping compiler team and smart contract devs in sync
The devs on the compiler team have created a roadmap with the changes required for a new version of the compiler. It is important to mention that a crucial element in the current and subsequent upgrades will be the sync between smart contract and compiler dev teams. The need to resort to such a measure was dictated by the identification of some miscommunications between the two. In order to eliminate this issue, smart contract devs will be involved in all stages of compiler beta-version testing. As a result, a form of checks and balances will be achieved, ensuring the compiler is tailored towards the needs of smart contract devs and runs well before it is released in the prod version.
3. Later integrations
To advance network-wide security, two new protocols are coming to the fore: REMP and SMFT.
REMP
REMP is a set of protocols designed to add additional guarantees to external message processing. When a message is sent to the network, it gets accepted by current validators and included in the message queue catchain (MQC) with a timestamp. The validators, in turn, send a confirmation to the user about the message receipt. There are three main (traceable) checkpoints on the message processing path: the message has been received by validators, the message has been added to a block, and block finalization. Also, the protocol provides highly efficient replay protection. Namely, if a message is processed and added to an accepted block, then the same message (the message with the same hash) will not be collated for some time.
SMFT
Soft Majority Fault Tolerance is an original Everscale consensus protocol designed to increase blockchain security to the level where any attempted malicious attacks become meaningless. At the same time, it ensures that the blockchain operates at a high speed while retaining sufficient decentralization. Currently, the mechanism is in the works and includes the random rechecking of candidate blocks by any of the workchain validators. Such validators are called verifiers. The need for verification is calculated on the basis of the signature from the hash of the candidate block with the private key of the validator using a BLS deterministic signature. If block validation issues should arise, the verifier notifies all Masterchain validators of the fact that the corresponding shard block contains an error and must be rechecked before being included in the Masterchain.
