The Chain Security company carried out a security review process for Tron (TRX), the network created by Justin Sun. It discovered “several vulnerabilities” that have already been resolved, as detailed by the security company on September 30.
Chain Security, intended for smart contract audits and security solutions for networks and decentralized applications (dApps), reported that their study focused on the network consensus mechanism, in the execution of transactions and in the Tron Virtual Machine (TVM).
The company, in a thread on affected performance of the network or caused interruptions.” In this way, Chain Security explained the following solved problems.
Certain nodes were able to block legitimate transactions
Chain Security’s solution shored up Tron’s new code so that filter out invalid producer blocks before processing. This ensures that only valid blocks are considered, maintaining network consistency and avoiding censorship of legitimate blocks.
Tron uses a consensus mechanism based on Delegated Proof of Stake (DPoSDelegated Proof of Stake) and Practical Byzantine Fault Tolerance (PBFTPractical Byzantine Fault Tolerance).
In the first of them, users vote for a set of delegates (super representatives) who are responsible for validating transactions and generating new blocks.
While the second works to ensure that two-thirds of the nodes in the network reach an agreement even if there are nodes that are faulty or acting maliciously (it does this to keep the network running).
The resolved error was linked to this last consensus mechanism. This is the “unallowed censorship of fork blocks (fork blocks)”. This expression refers to the action of an attacker who try to block or remove legitimate blocks in a blockchain.
Chain Security identified that a node could block or delete those legitimate blocks by creating a fork chain with fake blocks. If the network detected this fork, it could discard the entire chain, including valid blocks, resulting in inconsistencies in the network.
The Tron network consumed resources that slowed down transactions
Chain Security took care of solving an excess of “resource consumption by blocks not signed by witnesses.”
On the Tron network, Witnesses are nodes that validate and sign the blocks to ensure its legitimacy. A non-witnessed block is a block that has not gone through this validation process.
Each block processed consumes memory, requires computing power, and although non-validated blocks are eventually discarded, they initially take up storage space.
So if the network is busy processing unvalidated blocks, it uses a significant amount of resources that could have been allocated to valid blocks and legitimate transactions.
So, processing those non-validated blocks, could slow down the network and its overall performance. This can lead to longer transaction times and lower efficiency in executing smart contracts.
Tron resolved a vulnerability in its Virtual Machine
On the other hand, the security company detected an error in the communication system of the PBFT (Practical Byzantine Fault Tolerance) consensus mechanism that is directly related to the MVT (Tron virtual machine).
In the context of Tron, PBFT messages are crucial for the functioning of the consensus mechanism that ensures the secure and efficient execution of smart contracts on the MVT.
That bug in the PBFT messages could have led to unlimited memory expansion, potentially leading to a Denial of Service (DoS) attack. This means that without the update, the network could have been vulnerable to attacks that overloaded system memory, affecting its performance and availability.
The system was updated to ensure that PBFT messages are only processed when PBFT is enabled. This avoid excessive memory consumption and protects the network against possible DoS attacks.
Ultimately, Chain Security communicated that there were other failures or vulnerabilities resolved, however their report focused on what is provided here.
