To boost community strength, the Solana Foundation hosted a community call with developer teams from across the network to discuss thoughts and concerns about the Solana blockchain and how they could best improve their workflows. 

What resulted was an interesting thought-discussion about different processes with engineers expressing their opinions on how to handle upcoming changes, methods of improving SIMDs, and other future developments to be made. 

Opening Statement by Solana Foundation

The call began with a formal introduction from the Solana Foundation who described what the call would be about. They went over what to expect in the future with subsequent calls which would normally revolve around engineering topics. 

Dan Paul, executive director of the Solana Foundation, then went on to explain that many people within the community want more visibility on the details of project roadmaps. He explained that the issue with this is that engineering roadmaps are difficult to predict and plan accurately. 

He went on to explain that more people were requesting written access to the codebases which meant that a better system for formal processing would be necessary to handle the request. 

Increasing validator clients

Kevin Bowers, from Firedance, explained that the network required new specs to handle additional validator clients. He said that having one validator client handling too many team projects would lead to a lot of conflicts due to differing work philosophies and team cultures. 

However, this implementation would go against the protocol, so the team at Firedance is building a proof of concept first to help reinforce how the network would handle these new styles of operating. 

The Firedance team then referenced the same issue on the Ethereum network and how that blockchain solves changes, claiming that it would be beneficial to try something similar because Ethereum’s process has scaled well.

Standardizing SIMDs

Dan Paul then went over Solana IMprovements Documents (SIMDs) and how the bar for merging SIMDs needs to be higher to ensure better quality across the network. He suggested using GitHub more openly as a place for forum discussion.

That was argued by @jump_ripatel who believed that it would be better to have a more standardized method of creating SIMDs as it would create a formal discussion as opposed to casual forums.

Both points eventually became moot though as one community member explained that SIMDs could quickly become outdated if ignored by the community. They explained that it would be necessary to attach a time restriction of 6 months to enforce that proposals would be accepted or rejected at a meaningful pace. 

Faster bug patches

Another topic for discussion was how to handle critical security vulnerabilities. Many agreed that the biggest validators should begin building everything from the source code so that any issues or errors could be quickly solved by the Solana Foundation and patched relatively quickly. 

It was explained that smaller patches wouldn’t require as much immediacy and could be patched without halting the network. However, more immediate bugs would need to be worked on through optimistic confirmations in order to prevent a ⅔ network shutdown, making the problems worse. 

What’s next for Solana developers?

Following the call, the Solana Foundation suggested topics concerning making vote credit proposals more timely, ZK verification, and new standards for feature activation coordination. 

With the price of Solana in a near free-fall during the last couple of months and accelerated by the FTX collapse, it is relieving to see the developer community on Solana coming together to suggest how to improve the efficiency of the overall network during a time when many have begun looking elsewhere for their web3 investments.