A major security flaw was promptly addressed through collaboration between Solana developers and network validators, though the swift resolution has drawn scrutiny regarding the platform’s centralized nature.
It was confirmed by the Solana Foundation that a zero-day flaw, which had the potential to let an attacker mint specific tokens and withdraw them from user accounts, has been successfully patched.
In a post-mortem released on May 3, it was stated by the Solana Foundation that a security vulnerability, initially identified on April 16, might have been exploited by an attacker to generate a falsified proof impacting Solana’s privacy-focused “Token-22 confidential tokens.”
No exploitation of the vulnerability has been detected, and the updated patched version has been implemented by Solana validators, according to the foundation.
Zero-Day Security Flaw Impacted Solana’s Token-22 Confidential Tokens
It was stated by the Solana Foundation that the security flaw was related to two specific programs: Token-2022 and ZK ElGamal Proof.
The primary application logic for token mints and accounts is managed by Token-2022, while the accuracy of zero-knowledge proofs used to verify account balances is ensured by ZK ElGamal Proof.
It was reported by the foundation that specific algebraic elements had been excluded from the hash during the transcript generation of the Fiat-Shamir Transformation, which defines the method by which provers generate public randomness through a cryptographic hash function.
The vulnerability could have been leveraged by an attacker to manipulate the unhashed elements, allowing a fraudulent proof to pass verification and enabling the unauthorized minting and theft of Token-22 confidential tokens.
Token-22 confidential tokens, also known as “Extension Tokens,” are designed to support advanced token features and are built using zero-knowledge proofs to ensure privacy during transfers.
The vulnerability was initially detected on April 16, and two fixes were implemented to address the problem. Within approximately two days, the patches had been adopted by a supermajority of Solana validators.
The security patch was primarily developed by Solana development teams Anza, Firedancer, and Jito, with additional support provided by Asymmetric Research, Neodyme, and OtterSec.
It was confirmed by the foundation that all assets have remained secure.
Although the issue was resolved, concerns about centralization were expressed by some in the crypto community due to the Solana Foundation’s confidential coordination with validators.
Among those expressing concern was a Curve Finance contributor, who questioned the foundation’s close coordination with Solana validators.
Questions were raised by the contributor, who asked why a complete list of validators and their contact information was available, expressing concerns that such communication channels could be used to collude, censor transactions, or even reverse the blockchain.
The claims were not directly refuted by Solana Labs CEO Anatoly Yakovenko, who instead noted that members of the Ethereum community could similarly collaborate to address a comparable security vulnerability.
It was pointed out by Yakovenko that over 70% of validators on the Ethereum network are also managed by cryptocurrency exchanges or staking platforms like Lido, in support of his argument.
It’s the same people to get to 70% on ethereum. All the lido validators (chorus one, p2p, etc..) binance, coinbase, and kraken. If geth needs to push a patch, I’ll be happy to coordinate for them.
In August, another major vulnerability was discreetly addressed by the Solana Foundation along with network validators. At that time, it was stated by the foundation’s executive director, Dan Albert, that the capacity to organize a patch does not indicate Solana’s centralization.
Ethereum Unlikely to Face Similar Vulnerability, Claims Community Member
Claims that Ethereum faces the same centralization challenges as Solana were criticized by Ethereum community member Ryan Berckmans, who emphasized that Ethereum benefits from adequate client diversity.
It was stated by Berckmans that the most widely used Ethereum client, Geth, holds no more than a 41% share of the network, while also highlighting that Solana relies on a single production-ready client, Agave.
This means zero day bugs in the single Sol client are de facto protocol bugs. Change the single client program, change the protocol itself. The client is the protocol.
At the same time, a new client named Firedancer is expected to be launched by Solana in the coming months, with the goal of enhancing the network’s stability and operational continuity.
It was noted by Berckmans that a minimum of three clients would be required for Solana to achieve adequate decentralization at the client level.
