The percentage of active nodes fell below the “66%”, affecting block processing.
The causes were delays in the inclusion of blocks and overload in the nodes.
The implementation of the next Ethereum update, known as Fusaka, began with “some turbulence,” according to the developers who participated in the 166th meeting of “Ethereum’s main developer consensus layer” (ACDC) on October 2.
Fusaka began to be tested on October 1 in Holesky, the test network (Testnet) of Ethereum. According to the report, although “the activation of the fork in Holesky was good in general,” there were inconveniences.
According to what was described, Fusaka entered a state of «Non-finality for approximately two daysthen he recovered and resumed the end ».
The expression “non-infinality” means that Transactions and blocks do not reach an irreversible state For a prolonged period, which can compromise the temporal security of the network.
That is, during the first hours of Fusaka in the test network, transactions and blocks They did not get a definitive state that allows them not to be reversed.
Then, the report From developers he adds that “initially participation fell due to updates of unpant clients” until falling to a percentage “below 66% and then recovered.”
Participation refers to the percentage of validated nodes that are active in the network. Having fallen that participation to minor figures from “66%” Block completion was affected.
Despite the “turbulence” explained, these types of conflicts are usually seen in early tests.
In fact, as Cryptonoticia reported in the debut of pein (the previous update of Ethereum) in Holesky, similar episodes had already been registeredreflecting the experimental and adjustment character of these stages.
What were the causes of the problems in Fusaka in Ethereum?
Among the possible causes of the problems detected, the developers indicated three factors: delays in blocking blocks, processing overload in the nodes and an unusual volume of data that could have saturated the test network.
These combined elements They can reduce the network capacity to validate and confirm transactions stable.
The report also mentions that in Holesky many validators manage about 10,000 signature or validation keys each. This high server load can influence performance and increase the probability of temporary failures.
Ethereum collaborators also estimated that Holesky’s next update is scheduled For October 7.
After that, the test calendar will continue in the Sepolia networks (October 14) and Hoodi (October 28), other ecosystem tesnets, while Fusaka activation in the Ethereum main network It would not arrive before December.
On the other hand, developers discussed the development of «Glamsterdam«, Name of the update that will follow Fusaka.
With regard to Glamsterdam, they pointed out that the deadline for the “EIP not mainly set a week after the Fusaka Mainnet date confirmed.”
What will Fusaka bring to Ethereum?
As Cryptonotics reported, Fusaka will incorporate 13 proposals for improvement of Ethereum (EIP).
The most prominent is EIP-7594, which introduces “peerdas”, a system for the availability of pairs data. That system would allow the nodes to “specialize” in Store and verify different types of dataincreasing the storage and efficiency capacity of the network.
Through “peerdas”, in Ethereum Transaction costs would be reduced in second layers (L2) as a base, arbitrum and others; climb to 128 BLOBS (data packages outside the chain) per block over time; and host lighter nodes that only store a fraction of the data.