Solana Inspired Networks

Quick Take

• Unique Architecture: Solana's monolithic design is optimized for high throughput and efficient resource utilization, setting it apart from Ethereum's modular approach – optimising for liquidity concentration
• Pivotal Upgrades: The ecosystem is undergoing significant changes, including the introduction of new validator clients and runtime upgrades, aimed at enhancing Solana's capabilities.
• Appchains and Forks: Discussion on Solana's potential role in the creation of application-specific chains, with case studies like Pyth Network and MakerDAO's NewChain proposal.
• Layer 2 Questions: The article explores whether SVM is a suitable candidate for Layer 2 solutions, given its inherent design for performance and scalability.
• Multipolar VM World: Solana's place in a landscape that includes other major players like Ethereum and Cosmos in a multipolar VM environment.

Motivation

Recently, the Solana network and its Virtual Machine (SVM) have seen significant adoption. Notable instances include Helium's integration of Solana [1], Visa's exploration of Solana as a payment network [2], Eclipse's extension of SVM's Layer 2 capabilities to Ethereum [3], and MakerDAO's proposal to fork Solana for its upcoming NewChain network [4]. These developments raise interesting questions about Solana and SVM's future role in the wider picture of distributed networks.

This article aims to delve into this question by examining Solana's strengths and weaknesses, both as a network and as a execution runtime environment. Specifically, we will focus on identifying gaps in middleware and supporting systems that, if filled, could broaden SVM and Solana's applicability.

While Ethereum's limitations have led to a significant focus on modular architectures, Solana offers a contrasting approach: a monolithic (or integrated) environment optimised for efficiency, from hardware resource allocation to concurrent transaction handling. Key optimizations include node bandwidth via verifiable delayed functions, multi-threaded parallel execution, and a localised fee-market introduced to mitigate transaction fee congestion.

Beyond these optimizations, Solana's architecture features unique elements like Turbine, its block propagation protocol, and Proof of History (PoH), which eliminates the need for atomic timestamp coordination among validators. These features contribute to Solana's high-throughput capabilities and raise several questions:

• Execution preference on modular or monolithic environments?
• Does L2s make sense on Solana?
• Is Solana going to be used for constructing appchains?

The questions as mentioned above amongst a few others, will be answered to the best of ability down below as we continue to further deep dive into the Solana ecosystem.

Article Sections

This article will be structured in a few basic chapters to first introduce and review certain topics related to Solana & SVM then we will further discuss the questions at hand, to later summarise and conclude findings, with further research and next steps.

Sections are as follows:

1. A primer on upgrades upcoming to the Solana network
2. A primer on blockspace & localised fee markets mechanics
3. Deep dive into case studies adopting Solana & SVM
4. Open discussion & future work
5. Summary & Conclusion

Upgrades Upcoming

Currently, the Solana ecosystem is undergoing a few pivotal upgrades that will have a significant impact on Solana. These developments include:

• Implementation of a new validator client for Solana to significantly enhance throughput capabilities and;
• Upgrade of the runtime execution environment to V2. 

Below is a brief summary of these upcoming changes to Solana and it's ecosystem.

More Validator Clients to Come

Currently, there are four different client implementations for Solana, where three of these validators are from independent codebases (Jito as mentioned later in this article is an adaptation of Solana Lab's validator). On a high-level there are two more upcoming Solana validator clients soon coming out:

• Firedancer by Jump Crypto (development started aug, 2022)
• Sig by Syndica (announced in July 2023)

Firedancer

First, there is Jump Crypto is in the process of developing Firedancer, a new validator client for Solana, coded in C/C++. This client is designed to serve as an alternative to Solana Labs' existing Rust-based validator client. The introduction of Firedancer aims to fortify the network's resilience by providing a secondary client, thereby reducing the risk of failures due to being overly dependant on only one client. Preliminary tests indicate that Firedancer could process up to 1.2 million raw transactions per second (TPS) and 600,000 TPS after deduplication [5]. This development aligns with Jump Crypto's belief that Solana's throughput is currently constrained more by software inefficiencies than by hardware limitations [6].

Sig

Second, there is Sig, a Solana validator client written in the Zig programming language. Sig aims to optimize Reads-Per-Second (RPS), a metric often overlooked in favour of Transactions-Per-Second (TPS). The focus on RPS is to improve the end-user experience by making blockchain interactions faster and more reliable. Sig is designed to tackle the issue of Solana nodes falling behind in performance, especially when handling heavy read calls.

Runtime v2 Upgrades

Further, SVM – the runtime execution environment, is undergoing an upgrade to Runtime V2. This new version aims to introduce a number of new features designed to enhance the runtime's capabilities. Some of the key upgrades include:

• Move Programming Language Support: Originating from the Diem team, Move will be integrated as a frontend language for developing and deploying dApps. This language will be compiled and verified at the time of deployment, enhancing the security and auditability of the code.
• Typed Interfaces: The new runtime will feature typed interfaces and accounts, making deployment and execution safer and more efficient. This eliminates the need for serialisation and deserialization, streamlining the execution process.
• Limit & Costs: The V2 runtime will remove several existing limitations, such as those on reallocation and Cross-Program Invocation (CPI) depth. This is expected to make smart contracts easier to develop and more composable.
• Consistency and Transition: While Rust will continue to be the primary programming language, the old runtime will be gradually phased out. However, V2 will maintain backward compatibility to ensure a smooth transition.

To summarise, the forthcoming upgrades to the Solana ecosystem—namely, the introduction of the Firedancer validator client and the transition to Sealevel Runtime V2—represent pivotal shifts that extend beyond mere incremental improvements.

Blockspace & Localised Fee Markets Mechanics

Now, with every distributed network, blockspace is usually a shared and in-demand resource for it's users to include and process their transactions. Usually the fee market is a reflection on the aggregated state value on chain and fluctuates accordingly. For most readers, the reason why we need such fee markets is clear, however beyond any reason of doubt, it should be made clear that fees are used for Incentivisation (payment) to relevant network contributors such as validators/nodes (please see the diagram below).

Blockspace Fee Mechanics

Unlike most blockchains that rely on a mempool and priority gas auction system, Solana has charted a unique path. It has set aside the mempool in favour of a different method referred to as Gulf Stream. This protocol is responsible for dispatching pending transactions directly to current and upcoming block leaders. This design choice has several ramifications, affecting not only the speed of transaction confirmations but also the associated fee structure.

Mechanics of Gulf Stream:

• Forward-Thinking: Gulf Stream leverages the validators' knowledge of upcoming block leaders. This enables validators to forward transactions directly to these leaders, thereby reducing latency and accelerating transaction processing times.
• Transaction Validity: Each transaction is associated with a specific block-hash and has a limited validity window, approximately 24 seconds. This mechanism ensures that transactions are either confirmed quickly or invalidated, thereby reducing the likelihood of network congestion.
• Efficiency: Gulf Stream eliminates the need for a traditional mempool, thereby reducing memory pressure and enhancing the overall efficiency of the transaction confirmation process.

Implications on Fees:

• Reduced Congestion: The proactive forwarding of transactions ensures that there's less congestion, which can lead to reduced fees, especially during times of high network demand.
• Priority Fees: While Gulf Stream optimises transaction processing, Solana still employs a priority fee system. Transactions are primarily processed on a first-come, first-served basis, but clients can opt for prioritisation fees to enhance the likelihood of their transaction's inclusion.
• Base Fees: Solana maintains a minimal base fee (0.000005 SOL) per signature, which is divided equally between the validator and a burn mechanism. This ensures a balanced incentive structure for network participants.

The synergy of Gulf Stream's mechanics and Solana's fee structure results in a streamlined transaction processing system. This ensures rapid confirmations and a cost-effective environment, even during periods of heightened network demand.

Quality of Service & Spam

Further enhancing the network's efficiency is Solana's Quality of Service (QoS) model, which is stake-weighted. This allows nodes to earn transmission rights in proportion to their stake, thereby ensuring equitable network participation and preventing any group of nodes from overpowering or silencing others. The stake-weighted QoS model is further optimised by Solana's adoption of the QUIC protocol, a Google-developed protocol that enhances asynchronous communication and data processing.

However, a significant portion of computational power is directed towards failed transactions, indicating potential inefficiencies and spam. Solutions could involve dynamic fee adjustments, enhanced stake-weighted systems, and strategic partnerships to improve computational efficiency. Solana also incorporates local fee markets based on per-block and per-account compute unit (CU) limits. This stands in contrast to global fee markets, where a single event can congest the entire network. Solana's local fee markets are adaptive and resilient, ensuring that only transactions related to specific high-demand activities face rising fees.

MEV & Blockspace Auction on Solana

It is worth mentioning that Miner Extractable Value (MEV) is also present in Solana as in Ethereum, just with different actors.

Jito, as previously mentioned before, operates outside the Solana protocol but has a significant impact on gas prices and MEV within the network. Functioning similarly to Flashbots in the Ethereum ecosystem, Jito conducts off-chain block space auctions. Their primary objective is to optimize the positive aspects and mitigate the negative externalities associated with MEV.

Jito's infrastructure allows searchers to send bundled transactions, which are then relayed to validators running a specialized Jito-Solana client. Despite its functionality, Jito's adoption within the Solana network is considerably lower (~25%) compared to Flashbots' penetration in the Ethereum network (~90%+) [7]. The presence of Jito and its potential for wider adoption raises questions about the evolving dynamics of MEV and gas prices within the Solana ecosystem. Further reading on MEV can be found here.

Solana Forks

In the sections above, we've provided an overview of Solana's imminent upgrades and recent changes, including the introduction of localised fee markets. As we proceed, we will delve into the rationale behind forking Solana's codebase to construct application specific networks with better decentralised & performance capabilities compared to other application specific networks built on Cosmos.

There are a few notable projects adopting or thinking of adopting the integrated technology developed by the Solana Foundation, mainly for forking the Solana codebase to establish application specific chains, such as Pyth Network.

The main reason Pyth chose Solana is its low latency and high throughput. Pyth needs to do thousands of transactions per second, and Solana is the only well-tested blockchain technology with that capability. While there are newer projects that aim to reach the same goal (Aptos/Sui/Sei/Monad), none of them have the same track record that Solana does.

– Jayant Krishnamurthy, CTO of Douro Labs, Core-Contributor of Pyth

Due to the upcoming modifications (as described earlier in this article) and the network factors we describe below, we have formed one thesis that Solana and the SVM will continue to see further adoption to make application specific networks due to obvious performance characteristics both in terms of execution and decentralisation capabilities.

Maker's Forking Proposal

When deciding to adopt a new protocol technology, there are a myriad of factors that all play a role in the decision making process. MakerDAO co-founder Rune Christensen published a proposal to fork Solana’s codebase as a foundation for the upcoming Maker’s NewChain (new name will come later as put forward in The 5 phases of Endgame). Rune wrote the following on why NewChain is such an important and pivotal part of Maker’s journey: 

The most important reason for why NewChain is needed, is that it will allow the ecosystem to use hard forks to gracefully recover from the most severe form of governance attacks or technical failures. NewChain also allows the system to deal with the 8 years of technical debt in the protocol, and means all components of the protocol can be purposefully rebuilt for their exact role in the final, permanent Endgame technical design 

– Rune Christensen, Founder of MarkerDAO

The question still remains, why fork Solana? Several points were described in the rather brief proposal. Solana has been proven to be a resilient ecosystem, there is plenty of talent with diverse backgrounds, an ecosystem culture that is prevalent and sufficient bridging infrastructure between Solana, Ethereum and the upcoming NewChain. However, it is to be noted that there is more to the analysis than what was pointed out in his proposal. 

These factors could largely be divided into two main categories, ecosystem and network (SVM) related factors, such as: 

Ecosystem: 

• Client Diversity: Solana currently has multiple client implementations (as previously mentioned with Firedancer currently being in development), with more in development, enhancing network resilience.
• Community and Expertise: A wide range of infrastructure providers, validators, and developers are available to assist with specific deployments.
• Tools & Libraries: Solana's active developer community and frameworks like Anchor make it easy to find support and deploy code.

Network & SVM: 

• Fee Isolation: Solana's SVM allows for localised fee markets, ensuring that high fees in one activity don't impact others. 
• Cost-Efficiency: Solana is designed for minimal hardware costs, with options to run a validator for as low as $350/month.
• Decentralisation: Solana's Turbine protocol supports a high degree of decentralisation, with over 2000 full nodes and scalability goals of up to 10,000 nodes.
• Scalability: Solana's SVM offers parallel execution, enabling massive scalability for various applications.
• Language Support: Beyond Rust, Solana supports multiple programming languages including Solidity, C, and Python, with more on the way.
• Innovation Pipeline: Solana is continuously innovating at the protocol level, with features like Turbine, PoH, TowerBFT, and more in the pipeline.

One particular point Rune used in his proposal was the comparison of Solana versus Cosmos – highlighting key differences between implementation philosophy, technical architecture and organisational development of the core stack in itself.

The biggest difference between Cosmos and Solana is that Cosmos is not built around efficiency at its core in the same way Solana is which means it would cost more to maintain and keep performant. Cosmos also doesn’t have a strong central foundation organization like Solana has, which could be either a good or bad thing.

– Rune Christensen, Founder of MarkerDAO

Recently, there has been attention on comparing the design similarities of Cosmos and Ethereum, such as scaling through implicit sharding, SDKs for developing their own execution environments (Cosmos SDK, OP Stack), utilising Cosmos stack (Celestia) for scaling Ethereum and shared sequencing (Suave, IBC & Skip Protocol). Further information can be found on the presentation by Guy Wuollet on Where Cosmos & Ethereum Collide.

As previously discussed, Solana has been implemented as a high performance stack whilst being able to support a high Nakamoto Coefficient from day one, with further improvements upcoming.

Need for a Solana SDK?

Developing an L2 for efficient scaling and faster execution for Solana mainnet currently does not make much sense as it would drastically over-estimate the demand for Blockspace. However, adopting the Solana codebase to establish independent networks (such as Pyth or NewChain) certainly makes more sense due to the factors we have discussed above in this article.

If we imagen a scenario where we have multiple independent Solana inspired network, there are a few questions that come to mind:

1. How will the network be secured, by it's own validators that the network has to incentivise themself or should the network rely on security derived from another third-party network such as Solana or Ethereum via liquid re-staking?
2. Bridging to multiple networks in a multichain world presents a few unique challenges, such as bridging security, developer experience and user experience – how will this be solved?

Developer's who think an app-chain would serve their purpose better than an integrated application on a rollup or L1 – usually now goes to the beloved and battletested Cosmos SDK. If we are to see a scenario materialise of multiple Solana inspired networks, there could be a need for a Solana SDK (or shall we name it SolForge SDK)?

1) Borrowing Security from Elsewhere?

In the proposal posted by Rune on MakerDAO, he makes the following argument:

"The most important reason for why NewChain is needed, is that it will allow the ecosystem to use hard forks to gracefully recover from the most severe form of governance attacks or technical failures."

Where, in this case – one of the primary motivations to own the network state is due to attack vectors as mentioned in his argument.

Governance attacks and technical failures can manifest in various forms:

Governance Attacks

• Large Majority Attack: If an entity gains control of more than 50% of the governance tokens, they could potentially make unilateral decisions that are detrimental to the network, such as draining the treasury or altering key parameters.
• Sybil Attacks: An attacker creates multiple identities to gain a disproportionate influence in governance decisions. This could be used to skew voting in favour of proposals that benefit the attacker at the expense of the network.
• Voter Apathy and Low Participation: While not an attack per se, low voter turnout can make it easier for a small group to control governance decisions.

Technical Failures

• Smart Contract Vulnerabilities: Flaws in the smart contract code could be exploited to drain funds or manipulate key protocol parameters. For example, a re-entrancy attack could be used to drain assets from the protocol.
• Social Consensus Chain Reorg: A successful chain reorg could potentially invalidate previously confirmed transactions, leading to double-spending or other forms of asset manipulation.
• Data Availability Issues: If data is not readily available for validators, it could lead to a halt in the protocol's operation or even to forks.

While some of the aforementioned attack vectors may appear improbable, their consideration remains crucial for network security. This leads to a nuanced question: Which is more valuable—settlement or execution? This question becomes even more important when contemplating a future with multiple specialized environments for different functions such as NewChain or Pyth. Should a protocol like Maker opt for ownership of its network state and should it lease fully or partially it's security from elsewhere?

It is without doubt that securing a valuable state typically entail an economic cost that the network must absorb – and with that comes options:

There is several potential sources of borrowing security, they are as following:

• Leveraging interchain security from a producer chain, such as Cosmos Hub.
• Utilizing a common settlement layer, exemplified by Ethereum.
• Adopting a checkpointing mechanism from a producer chain, like Babylon, which offers protection against both long-range and weakest-link attacks.
• Relying on a common Data Availability (DA) layer, such as Celestia or EigenDA, which can furnish censorship-resistant data essential for trust-minimized bridging and fraud proofs.
• Source security from a pooled security services, such as EigenLayer, which imposes extra penalty conditions contingent on specific validation tasks

In their seminal whitepaper, EigenLayer proposed an alternative security mechanism that leverages the robustness of established networks like Ethereum or Solana. The core argument centres on the notion that actively validated services (AVSs)—be they specialized chains like NewChain or decentralized components like oracles and bridges—constitute potential weak links in the broader landscape of interoperable systems, as the system overall is only as secure as it's weakest component.

At the time of writing, Maker's combined market capitalization, encompassing both its governance token and DAI, stands at approximately $6.5 billion. This substantial economic weight poses challenges for securing a network like NewChain (or Maker). If one opts to rely on a based security model with the help of middleware services such as EL, questions inevitably arise concerning dispute resolution within the AVS network state. Moreover, middleware services like EL face their own set of challenges, particularly when it comes to scaling the security of the AVSs they oversee. As these networks grow in size and complexity, the leased security model offered by services like EL will undoubtedly encounter implementation hurdles.

Further, the a based security model, either hybrid or not could also be adopted from Solana mainnet – however here, one significant issue at the moment of writing is that only 3-4% of native SOL tokens are staked with liquid staking providers and therefore there isn't a sufficient market present. However, the opportunity space presents itself for interested builders both in liquid staking and pooled security middleware either native or interchain.

Enshrined Interoperability

With multiple sovereign Solana inspired networks – just like with Cosmos, there will be a need for cross-communication between the different networks. In Rune's MakerDAO proposal, he mentioned the "two-Stage gravity bridge from NewChain to Solana alongside the bridge from NewChain to Ethereum." An brief interpretation of this statement would be the use of Gravity Bridge as we know it today (utilising IBC), with further modifications there should be possibility to extend this to Solana and other Solana inspired networks (or SolForged networks).

There is other alternatives, as we know – one of the original bridges Wormhole would offer cross-chain communication however it is primarily based on application level.

Bo Du from Polymer labs makes the case for kernel space interoperability between different chains utilising their cross-chain IBC protocol – This is instead of having application space bridges that exposes internal chain data structures and imposing an additional security assumption burden to the end-user.

Enshrined interoperability would provide a complete implementation of the full interoperability model regarding the transport, state and application layer.

Further, it would avoid exposing internal chain information to other external networks, proof verification schemes and relayers infrastructure would be reused and with this comes a reduced integration overhead. Atomic transactions, some ideas Anoma has discussed recently – can also be realised by a runtime chain that spins up between chainA and chainB to complete the atomic transaction. One would also be able to introduce interchain fee/gas tokens as well – as we have seen with either paymasters or recently EIP-6551 in Ethereum (account abstraction).

An enshrined IBC implementation would include its own separate mempool and p2p layer by default. Optionally, it could pull from the general mempool and benefit from turbine propagation.

– Bo Du, Co-founder of Polymer

It goes without saying, IBC in Solana? That's new — and it is. The idea here would be to bring a different form of message passing between Solana inspired networks. One of the design concerns here, would be utilising Polymer's system above, a shared mempool would be present cross-chain, question here is how would this work with Turbine?

SVM Execution other Ecosystems

So far, we have mainly looked at networks like Pyth or the potential upcoming NewChain project adopting the Solana codebase for a sovereign network. However, there are other projects as well bringing the overall power of SVM to other ecosystems either in terms of Rollups on Ethereum with Eclipse or as an L1 execution engine with Nitro on Cosmos.

Eclipse & SVM L2s on Ethereum

As mentioned above, a key adoption of Solana's SVM comes from Eclipse, a project that has chosen to adopt this execution environment (EE or EEs) bringing the SVM as an EVM L2 . A key point to note here, is that Eclipse is built with a modular approach in mind – where they use SVM for execution, Celestia for data availability and Ethereum for settlement (please see diagram below). Eclipse's decision to adopt SVM is not arbitrary as it aligns with several unique attributes that SVM offer.

Bringing another execution environment to Ethereum instead of the EVM and expecting other developers to adopt it – would require substantial improvement in performance, the following factors were mentioned by Eclipse:

• Parallel execution capabilities
• Isolated fee markets
• Multiple language support (including Solidity with Solang)
• EVM compatible with Neon EVM

Eclipse's modular approach, presents a unique set of strengths and weaknesses overall in a system we have not observed much before due to its use of frontier modular components that are relatively new:

On the one hand, the integration of SVM, particularly with the prospective inclusion of the Firedancer client, offers a compelling case for enhanced computational throughput. This not only facilitates higher transaction per second (TPS) rates but also alleviates network congestion, a persistent issue in blockchain ecosystems. Moreover, the utilization of Celestia for data availability is a strategic move to reduce transaction costs, a critical factor in overall enterprise adoption. The dual support for SVM and EVM broadens the developmental landscape, and the inherent design of SVM offers a more secure environment against re-entrancy attacks, a known vulnerability in EVM.

On the other hand, the architecture introduces a complex web of security and trust assumptions. The reliance on Celestia's validators for data attestations, especially given the network's nascent stage, could pose a risk to the economic security of transactions. This is further complicated by the sequential finality process involving both Celestia and Ethereum, which inherently extends the time required for transaction settlement. Additionally, the isolation between SVM and EVM environments introduces operational friction, necessitating different wallets and potentially fragmenting the user experience. This could also introduce additional trust assumptions, particularly if one has to rely on less mature or less secure components for specific functionalities.

Bringing parallel execution capabilities to the Ethereum ecosystem in form of an L2 via the SVM surely brings benefits to certain applications, where settlement finality latency is not crucial. Further utilising Eclipse's platform allows for shared liquidity

Summary & Conclusion

As we've explored throughout this article, Solana's unique architectural choices and upcoming upgrades position it as a compelling alternative in the blockchain space. Its monolithic (or integrated) design, optimized for high throughput and efficient resource allocation, offers a contrasting approach to Ethereum's modular architecture. This has implications not just for Layer 1 solutions but also raises intriguing questions about its suitability for creation of app-specific chains (SolForged networkes) and Layer 2 implementations.

Key Takeaways:

• Performance Optimization: Solana's focus on high throughput and efficient resource utilization makes it a strong candidate for applications requiring rapid transaction processing.
• Upcoming Upgrades: The introduction of new validator clients and runtime enhancements are pivotal developments that promise to further elevate Solana's capabilities.
• Layer 2 and Appchains: While Solana's architecture may not lend itself naturally to Layer 2 solutions, its performance characteristics make it an attractive option for application-specific chains, as evidenced by projects like Pyth Network and MakerDAO's NewChain.
• Multipolar Environment: Solana's rise doesn't necessarily mean the fall of other blockchain ecosystems like Ethereum or Cosmos. Instead, we may be moving towards a multipolar blockchain world where different chains serve different needs but can co-exist and interoperate.
• Technical Complexity: The technical intricacies of Solana's architecture, while offering numerous advantages, also present challenges and trade-offs that developers and network participants must navigate.

Future Research and Next Steps:

As Solana continues to evolve, several areas warrant further research:

1. Security Models: How will Solana-inspired networks secure themselves? Will they borrow security from established chains or create their own mechanisms?
2. Interoperability: With the rise of multiple Solana-inspired networks, the question of how these networks will interact with each other and with existing ecosystems becomes increasingly important.
3. Middleware and Supporting Systems: As Solana grows, there will be a need for robust middleware solutions to fill gaps in the ecosystem, whether it's in the form of developer toolkits or bridging solutions.

In conclusion, Solana's architecture and the questions it raises represent a fascinating area of study for anyone interested alternatives to the EVM and CosmWasm. Its unique approach to solving some of the most pressing issues in the space—scalability, throughput, and efficiency—makes it a subject of interest for developers, investors, and academics alike. As the ecosystem matures, it will be intriguing to see how Solana navigates the challenges and opportunities that lie ahead.

Current or Aspiring Founder?

If you're a current or aspiring founder focused on ground-breaking innovations in the crypto sector, don't hesitate to connect. I offer tailored mentorship to projects that align with my own areas of interest within the field. Additionally, at Elixir Capital, we invest in pre-seed, seed, and Series A start-ups that are pioneering new frontiers in the crypto space

While I strive to review all submissions and provide feedback, please note that due to the high volume of inquiries, I can't guarantee a response to everyone. Rest assured, I will do my best to evaluate your project and offer constructive feedback.

Notes

Please find some alternative resources below that was used for this article, either for inspiration on narrative or fact searching certain topics within this topic.

• Crypto Podcast by a16z, Episode 29, Debating Blockchain Architectures (with Solana)
• Modular vs. Integrated: Theory and Practice (Keynote) by Kyle Samani, Managing Partner at Multicoin Capital

Resources

[1] Case Study: Helium brings real-world 5G networks on Solana

[2] A deep dive on Solana, a high performance blockchain network

[3] Introducing Eclipse Mainnet: The Ethereum SVM L2

[4] Explore a fork of the Solana codebase for NewChain

[5] Breakpoint 2022 : Deep Dive Into Performance Optimization With Kevin Bowers From Jump

[6] Jump Crypto Plans New Solana Validator Client to Boost Performance, Decentralization

[7] Pricing Blockspace on Solana