Host:
Welcome everyone to the AMA session with key developers from Everscale. Today, our guests, Aleksandr Alekseev and Vyacheslav Belenko, will share the development results for the first quarter and answer community questions. Aleksandr, the floor is yours.
Aleksandr:
Hello, everyone. Let's start with discussing the Roadmap for the first quarter. We had several key initiatives planned: this week, we successfully launched Shadow SMFT, which is now operating in Mainnet, and we launched REMP at the beginning of January with a focus on improving the finality of transaction chains.
In the second quarter, our main goal is to launch MESH in the testnet. We are also actively working on resolving issues related to Currency Collection and integrating zk primitives into the Everscale network.
Now let's discuss what has been done with our node from January to March this year. Vyacheslav, over to you.
Vyacheslav:
Alongside our primary Roadmap tasks, we've tackled some extra challenges as well. We've been having some issues with data caching in our nodes, which caused network instabilities. To fix this, we've optimized the caching process and upgraded our methods for storing and reading data cells in the database, rolled out bug fixes in our virtual machine, and introduced a new capability feature to better integrate these fixes. During our testing phase, we encountered synchronization issues in unstable networks due to incomplete data exchanges between nodes. So we've refined our algorithm for synchronizing key blocks to handle inaccuracies in network data. We restored archive-based synchronization, significantly boosting our performance under unstable network conditions. Analyzing network failures during high load scenarios, like managing large queues of external messages, revealed some miscalculations in our fee and block size estimations. These were partly due to the initial incomplete description of Merkle proofs in the original TON network whitepapers. We've had to practically rework these aspects on the fly. These adjustments, along with the successful deployment of Shadow SMFT, have been a major focus of our recent efforts.
Aleksandr:
We've been busy enhancing our development process, including changes to how we create and publish code. Previously, we'd make one large Pull Request to the Master Chain about once a month from a private repository, which made testing harder and reduced transparency for users and observers of the public repository. We've completely revamped this process: over the last three months, we've made around 25 Pull Requests directly to the master branch, greatly increasing the openness and accessibility of our developments. Most of our work is now done publicly in open branches, which is a significant achievement for our network. We invite everyone to check out the changes and join the project.
We're currently renaming most repositories, completing the transition from FreeTon to Everscale. There's been a lot of work done, but there are still many artifacts that need to be refined. The development team decided to merge some libraries, turning two into one, which has simplified library management and eased testing.
We've ramped up the process of publishing issues and created a public chat in the Everscale Community to facilitate communication and gather feedback from the community. Additionally, we've started publishing monthly articles detailing the work done each month, with articles already out for January, February, and March. We also now host quarterly AMA sessions like this one to maintain transparency and openness in our processes. Vyacheslav, can you share what we're currently working on and what our plans are moving forward?
Vyacheslav:
Let’s talk about some of the tasks from our roadmap. We're actively developing MESH algorithms for networks to facilitate integration between networks launched at different times into a single system. This will allow independently launched networks to exchange data and contract logic. The code is written, and we are currently debugging it. We're also addressing issues submitted by the community; three tasks are in development, some are already implemented and ready for testing.
A key issue we're tackling is preventing the accidental deletion of frozen contracts. We've devised a scheme that prevents contracts from being frozen by accident, which is crucial because we don’t want to lose them.
In response to community suggestions, we've added a new set of commands for zero-knowledge proofs at the smart contract level in the virtual machine. This update will be released soon. These are the situations that have been addressed, and now we're doing a fix that allows us to deal more deterministically with contracts in edge cases where the contract had debt or could have debt, but in the scenario of dealing with that contract, we don't expect that. Our main focus right now is on SMFT and REMP, their integration, and network stability tasks.
Aleksandr:
Yes, thank you, Vyacheslav. I’ll go into more detail about SMFT, and Vyacheslav will cover REMP. This week, we launched SMFT in Shadow mode, which is a significant technological change in our protocol, greatly enhancing security and eventually leading us to one of the solutions for Fast-Finality.
We have a server that acts as a validation node. It creates a block, while other functioning validation nodes check that the block is correctly created, ensuring, for instance, that the Collator hasn’t decided to assign some amount of money to itself or disrupt the virtual machine's operation. We currently use a BFT consensus, where after a block is created by a Collator, it is checked by validators and, upon receiving the necessary number of signatures, is sent to the Master Chain. The Master Chain also has its validators and Collators who accept blocks from the Workchain, verify the signatures, and incorporate the block into the blockchain.
We've already implemented SMFT in Shadow mode. What is SMFT? It’s a security enhancement. Currently, the number of validators that check a block is limited. Yes, the number of validators and the validators themselves can change. We have a Collator, and we have a validator. SMFT adds a new role - the verifier. A verifier is a node that must additionally check the blocks; it is chosen randomly based on a certain algorithm. This technology is operational right now. Verifiers that receive blocks created by a Collator additionally verify them and report back to the network whether the block is valid or not. Master chain validators, after receiving a signed block from the Collator, not only incorporate it into the network but also check whether they have received information from verifiers about an additional check of the block.
SMFT introduces several key improvements: it ensures block propagation guarantees using BLS signatures, which are often used in SNARKs. The Collator issuing the block also confirms that the block has been delivered to at least half of the servers in the network. This information is additionally transmitted to the Master Chain to confirm that the block has been distributed across half of the entire network and that it is not the result of any attack. I remind you, the role of the verifier is hidden; it is unknown until the moment of verification. This is SMFT.
Why is it called Shadow? Because the protocol, although active, MasterChain validators are currently only receiving information from the verifiers and collecting logs. During development, we tested the operation of SMFT on a limited number of machines. This could be 30 or 40 servers, whereas in Everscale, there are over 180 validators. This significantly increases the block propagation time requirements. Validators are located all over the world, leading to significant network delays. SMFT is already activated, and we are analyzing its performance, measuring the speed of block propagation through the network and observing how verifiers report their checks. This is the "shadow mode," where everything is operational, but for now, MasterChain validators are only collecting and analyzing logs, which does not yet affect the block issuance process by MasterChain validators.
The second very complex part involves fully implementing SMFT, which requires significant changes, including modifying the elector and possibly DePools, leading to a whole series of additional changes that may still be in development. Now over to Vyacheslav—can you tell us about REMP?
Vyacheslav:
At the end of last year, we successfully integrated the REMP technology into the core code and deployed it to the Everscale mainnet. REMP has been stable in operation, but we encountered issues with handling large-sized messages. Due to increased network traffic and additional load on the REMP consensus, we made some changes to the code. In testing various scenarios, including handling rare messages with high periodicity, we expect them to be accepted. Some problems were identified during testing, and we are actively working on resolving them. A further REMP release is scheduled for next week to address these issues.
REMP, or Responsible Extensible Message Protocol, is based on the GetChain technology and uses a similar method to achieve consensus in blocks. This technology is also used to coordinate the state of the external message queue. REMP allows for consensus on the state of the external message stream being sent to validators. This process is similar to block consensus in the network but specifically adapted for external messages.
That wraps up what we’ve been working on this quarter. Shall we move on to questions from the community?
Host:
Our speakers have thoroughly discussed the development progress of the node. Now, let’s turn to questions from the community that were asked before the stream. The first set of questions is about mesh networks.
Question: How do you plan to address potential spam issues from external blockchains through the MESH protocol?
Aleksandr:
In the MESH protocol, each network has the capability to independently disconnect another if it notices inappropriate behavior, such as attempted attacks. This mechanism protects the network from spam. Furthermore, spam isn't considered a major issue because all messages between networks are paid for. If one network wants to export messages from another, it relies on a pool to cover the gas fees charged by validators. If there aren’t enough funds to cover these costs, the messages aren't exported, and the connection between the networks is terminated. Thus, spam does not pose a significant concern.
Question: Is it possible to run decentralized applications on Venom or TON through MESH?
Aleksandr:
Let me split this question into two parts. Can you launch DApps through the MESH protocol? Yes, it's possible if two networks are connected through it. For end-users, it will function as a single network, allowing transactions and the deployment of contracts between networks. The speed of message delivery might be slower than within a single network, but from a user experience perspective, it should feel like a unified space. Regarding the question about Venom and TON, the decision to support the protocol must be made by the networks themselves.
Question: What is the future of workchains? Will the concept continue to be used, or will they be phased out as happened with GOSH?
Aleksandr:
I can't comment on the situation with Gosh as I don’t know all the details. However, regarding the concept of workchains, which are partially used in MESH, especially in aspects of network queue synchronization: MESH does not completely replace workchains. Currently, there isn't a significant business use case for deploying a workchain using the same virtual machine and token as it may seem pointless. It does not offer visible benefits and only requires time spent on development.
Nonetheless, if workchain technology becomes popular with businesses and users, it would be unwise to discard it as it offers interesting guarantees, different from MESH. Working with your own contracts from your workchain is usually faster, while using contracts from another workchain or a MESH network can be slower and depends on the specifics of the business tasks.
Host:
Alright. Let's move on to the questions about REMP.
Question: The documentation indicates that REMP enables blockchain to defend against DDoS attacks. Can you explain the essence of this functionality in simple terms? And what level of attacks is the blockchain capable of withstanding?Vyacheslav:
In the context of defending against DDoS attacks on the blockchain through external messages, there are two main measures. The first is the REMP mechanism, which filters out duplicate messages based on their hash, preventing the same message from being processed multiple times. The second measure relates to the protocol usage of REMP: we have validators who receive REMP messages, and REMP clients who send them. REMP clients can regulate the flow of messages to the validators, although the exact number of messages a client can send currently remains an open question. This allows us to limit the incoming message flow and track duplicate messages, reducing unnecessary load.
Question: Is the issue of the order of inclusion of external messages resolved in REMP?
Vyacheslav:
At this moment, the issue is not resolved. We have primarily focused on other, more critical requests. I think it's possible, but currently, there's no solution in place.
Question: One of the tasks to address lost messages is REMP. It's very interesting to compare how these problems are solved in TON or other TVM or EVM blockchains.
Vyacheslav:
I can't comment on the situation with TON as we don't have information on how the problem is resolved there. In EVM, like in Ethereum, the principle of handling external messages differs: the responsibility for each external message lies with its sender, as indicated in the message. As for other TVM networks, honestly, I can't say as I do not have that information. Aleksandr:
I already mentioned SMFT at the beginning. In brief, the block creator not only distributes it across the network but also gathers confirmations of its distribution. Master chain validators receive not just the block itself but also evidence that the block has reached at least half of the network. Additionally, they may receive information that the block is invalid if a verifier detects and reports this.
Question: At the beginning of 2024, the Near team reported that they finally achieved full sharding in their blockchain. How well does sharding work currently in Everscale and Venom?
Aleksandr:
I will primarily discuss Everscale, as today's AMA session is dedicated to Everscale. As far as Near is concerned, from what I recall, they report achieving data sharding. Our sharding is implemented mainly by splitting computation resources: as the load increases, the number of shards grows, and the load is distributed among more validators. All nodes in the workchain maintain the same storage state, which is synchronized through the master chain. This computation-sharding technology works wonderfully.
Question: What are the differences in the Venom and Everscale nodes, and why is Venom faster than Everscale?
Aleksandr:
I don’t want to delve into the details of other networks. However, I recommend looking at the number of validators in the Venom network compared to Everscale. Venom may have some specific network-level settings that differ from other networks, creating significant differences for the network. For example, Venom is configured by default to have 8 shards, which is more than the standard settings of other networks, leading to an increased number of processed blocks.
Question: Is it interesting to compare what's happening on the technical side in other TVM blockchains, and can you create a comparative table of the main parameters?
Aleksandr:
Each network is unique, and to understand which aspects are important for comparison, specific comparison goals need to be defined. While creating comparative tables is possible, it is often more beneficial to focus on developing and improving one's own network than spending time preparing such tables.
Question: What future technical solutions could radically increase interest in the network?
Aleksandr:
Since the end of last year, we have focused on two main tasks. The first is achieving faster transaction finality in a sharded environment, which, while increasing network throughput, can also extend the time it takes for users to receive final confirmation of transactions due to long operational chains. For example, in EVM networks, typical operations like taking liquidity, placing collateral, and going to a DEX could take longer with a large number of shards. Our goal is to optimize these processes to ensure they are executed quickly regardless of the load.
The second task involves using MESH technology to integrate various blockchain networks into a single user space, simplifying network interactions. This allows users to freely move assets, like NFTs, between networks via MESH, opening up new possibilities for interaction without worrying about which network the operations are occurring in.
Question: Is Everscale an experimental network for Venom?
Aleksandr:
From my perspective, no. If you compare the number of validators and how the networks operate, Everscale cannot be considered an experimental network.
Question: Is the implementation of slashing for validator nodes planned?
Aleksandr:
In short, yes, slashing is planned. However, given the current changes in the protocol related to finality and MESH, I won’t go into details about dates and figures right now. The priority is currently on developing MESH and improving finality.
Question: Will there be a direct bridge between Everscale and Venom?
Aleksandr:
I hope that instead of a bridge, MESH will be used, but that’s up to the networks themselves. It’s not a technical question. Our task is to develop MESH technology, and I hope it will be used for these purposes as it is significantly more powerful than a traditional bridge.
Question: Will EverCloud continue to be developed?
Vyacheslav:
Yes, we plan to continue its development, but there are more urgent tasks at the moment. Currently, we are dealing with various changes, including renaming repositories and modifying interfaces, so we are more focused on its support. However, we intend to continue its development in the future.
Question:What is the difference between email messages in Qamon and traditional web2 services like Gmail, particularly in terms of full anonymity?
Aleksandr:
This question deviates from the discussion of nodes and development as it concerns a product built on the network. Therefore, I prefer not to answer it, as it's better addressed by the team working on the product.
Question: Will it be possible in the future to transfer an NFT from the Everscale network to the Venom network? Is there a technical possibility, or will it be implemented?
Aleksandr:
I've already mentioned that the main advantage of MESH technology is that it doesn't limit the interaction of contracts between different networks. This allows for the creation of a unified space for the user, where one can have an NFT in one network and put it up for sale or transfer it to another network. The technology is so flexible that the possibilities are only limited by the imagination of smart contract developers.
