This post has been inspired by the eth core dev updates and current ethereumMost of the information here is sourced from the solana main repo pull requests and issues And the Solana community calls + Notes so feel free to dig in. The main goal is to bring more eyes to upcoming proposals so that folks could contribute and get more active in shaping the Solana roadmap.This will be a series of Posts covering Simds and core solana tech so stay tuned!

• What are SIMDs?

• SIMD-0022 ( first community-accepted core SIMD)

• SIMD-0016: Application Fee

• SIMD-0019: Sidecar for Data Availability

What truly makes a decentralized protocol is its functioning and maintenance/upgrades run by the community with its effort. For changes to the core implementation, all the decentralized protocols like Ethereum, ENS, Solana, and Mozilla have community proposals that are discussed and then voted on by the community before they are implemented in the core. SIMD aka Solana Improvement Documents/proposals are the community proposals to make changes to the solana core validator, there has been convo around which updates should require a proposal and general consensus is that an simd should be targeting a substantial new feature. One of the hardest parts of introducing new features and making changes to core client code is that as new client implementations get built like Firedancer, tinydancer they would also have to make changes and make sure that the bugs are battle-tested cause small bugs can cause big problems. One of the last outages was caused by a bug in the consensus on the newly released versions which has brought a lot of attention to new approaches to test new updates + features. A proposal goes through a lot of phases from ideation to forums to poc(proof of concept) to testing before its implemented in the core even then to maintain the stability of the network is closely monitored for bug fixes. Most of the hyped new features like dank sharding, Account Abstraction were first introduced as new EIPs to the community which was heavily worked on.

Note: Only 1 simd has been accepted so the process is still flexible to the community’s needs and nothing is hard coded.

Multi-stake proposal is the first SIMD to be accepted + implemented making changes to the stake features of the Solana protocol. In POS systems where validators stake their tokens to qualify to be block producers, anyone can delegate their tokens to validators so that they could reap the benefits of mining without putting the effort into setting up a new node. As everything on solana is an account even a program, whenever some amount of data is stored a new account with paying rent in lamports is created. As more and more folks delegate to diff parties this process could become cumbersome but with small stakes + liquid staking the validators have to maintain liquidity so delegators could exit as they wish or there's no exit liquidity at all. whenever a delegator wants to re-delegate their stake with some other validator it has to be deactivated which unlocks after the epoch and re-activated with the new validator which adds the cost of opening multiple accountsSolution -> Make a new type of account that has 2 Delegation instances that can be called and updated without making/closing additional accounts using less storage and in turn fee. A stake account can be created by

solana create-stake-account --from <KEYPAIR> stake-account.json <AMOUNT> \--stake-authority <KEYPAIR> --withdraw-authority <KEYPAIR> \
--fee-payer <KEYPAIR>
// to create a stake account

solana stake-account <STAKE_ACCOUNT_ADDRESS>
//to check amount of sol in stake_account

Links PRs SIMD

For any interaction with the protocol, the states that are touched by the interaction have to be predefined which allows Solana to parallelize the transactions and assign threads for the computation of specific programs. This makes local fee markets where the different amount of gas fee is paid for interaction with different programs allowing for the normal functioning of the protocol during high activity due to specific events. But this also creates the concept of Dapp Blockspace where only a certain amount of the block is filled by specific program interactions, when rogue/greedy agents spam the same program it becomes unusable for normal users.
Solution-> this Simd tries to introduce something called an application fee which everyone has to pay in order to interact with the program and directly goes to the developer of the program(who has access to the dapp account). The fee can be rebated depending on the developer and the fee has to be paid even if the transaction fails which penalizes the bad behavior and makes dapps more user-centric. On a high level, it would require a new native program with instruction of App_fee to be set by the developer.
Links SIMD https://github.com/solana-labs/solana/issues/21883MY blogpost

The main focus of rollups is to verify a bunch of transactions with the help of off-chain computation and post the least amount of data to cryptographically secure the transaction on the chain. Zero-knowledge rollups just put the zk proof of the transactions executed on the chain to show its computational integrity. But a big part of it is that the transaction data itself is not saved on the mainnet but on off-chain services which makes it less likely to be there for a long time but it still maintains the hash of txn. As the proofs are smaller than the data of all the txns combined they are still bigger than a single txn which makes Solana's single transaction data limit ~ 1.3 kb to be a hurdle. Ethereum will be facing the same issue post-sharding so they introduced a new EIP named Proto-Danksharding which would use Data availability sampling for the data blobs.

SIMD-0019 enables blob transactions which are chunks of data posted on the mainnet bigger than the current limit. As the posted proofs themselves don't require computational effort they are only needed to be stored for a certain amount of time and with the help of DA sampling it could be further optimized. This would allow a more rollup-friendly approach where dapps could launch rollups to add more functionality to it and still maintain solana as their root base where they post the proof and inherit its security.Links SIMD

The Solana forum is up which will be one of the centers of discussion for new updates and features so make sure to check it out

PS: thanks for Making it to the end! Gonna be making more tech dives on solana in the future. Also there were way too many resources and fragmented readings that went into this post so if I forget to link a resource feel free to reach out to me!

This post has been inspired by the eth core dev updates and current ethereumMost of the information here is sourced from the solana main repo pull requests and issues And the Solana community calls + Notes so feel free to dig in. The main goal is to bring more eyes to upcoming proposals so that folks could contribute and get more active in shaping the Solana roadmap.This will be a series of Posts covering Simds and core solana tech so stay tuned!

• What are SIMDs?

• SIMD-0022 ( first community-accepted core SIMD)

• SIMD-0016: Application Fee

• SIMD-0019: Sidecar for Data Availability

What truly makes a decentralized protocol is its functioning and maintenance/upgrades run by the community with its effort. For changes to the core implementation, all the decentralized protocols like Ethereum, ENS, Solana, and Mozilla have community proposals that are discussed and then voted on by the community before they are implemented in the core. SIMD aka Solana Improvement Documents/proposals are the community proposals to make changes to the solana core validator, there has been convo around which updates should require a proposal and general consensus is that an simd should be targeting a substantial new feature. One of the hardest parts of introducing new features and making changes to core client code is that as new client implementations get built like Firedancer, tinydancer they would also have to make changes and make sure that the bugs are battle-tested cause small bugs can cause big problems. One of the last outages was caused by a bug in the consensus on the newly released versions which has brought a lot of attention to new approaches to test new updates + features. A proposal goes through a lot of phases from ideation to forums to poc(proof of concept) to testing before its implemented in the core even then to maintain the stability of the network is closely monitored for bug fixes. Most of the hyped new features like dank sharding, Account Abstraction were first introduced as new EIPs to the community which was heavily worked on.

Note: Only 1 simd has been accepted so the process is still flexible to the community’s needs and nothing is hard coded.

Multi-stake proposal is the first SIMD to be accepted + implemented making changes to the stake features of the Solana protocol. In POS systems where validators stake their tokens to qualify to be block producers, anyone can delegate their tokens to validators so that they could reap the benefits of mining without putting the effort into setting up a new node. As everything on solana is an account even a program, whenever some amount of data is stored a new account with paying rent in lamports is created. As more and more folks delegate to diff parties this process could become cumbersome but with small stakes + liquid staking the validators have to maintain liquidity so delegators could exit as they wish or there's no exit liquidity at all. whenever a delegator wants to re-delegate their stake with some other validator it has to be deactivated which unlocks after the epoch and re-activated with the new validator which adds the cost of opening multiple accountsSolution -> Make a new type of account that has 2 Delegation instances that can be called and updated without making/closing additional accounts using less storage and in turn fee. A stake account can be created by

solana create-stake-account --from <KEYPAIR> stake-account.json <AMOUNT> \--stake-authority <KEYPAIR> --withdraw-authority <KEYPAIR> \
--fee-payer <KEYPAIR>
// to create a stake account

solana stake-account <STAKE_ACCOUNT_ADDRESS>
//to check amount of sol in stake_account

Links PRs SIMD

For any interaction with the protocol, the states that are touched by the interaction have to be predefined which allows Solana to parallelize the transactions and assign threads for the computation of specific programs. This makes local fee markets where the different amount of gas fee is paid for interaction with different programs allowing for the normal functioning of the protocol during high activity due to specific events. But this also creates the concept of Dapp Blockspace where only a certain amount of the block is filled by specific program interactions, when rogue/greedy agents spam the same program it becomes unusable for normal users.
Solution-> this Simd tries to introduce something called an application fee which everyone has to pay in order to interact with the program and directly goes to the developer of the program(who has access to the dapp account). The fee can be rebated depending on the developer and the fee has to be paid even if the transaction fails which penalizes the bad behavior and makes dapps more user-centric. On a high level, it would require a new native program with instruction of App_fee to be set by the developer.
Links SIMD https://github.com/solana-labs/solana/issues/21883MY blogpost

The main focus of rollups is to verify a bunch of transactions with the help of off-chain computation and post the least amount of data to cryptographically secure the transaction on the chain. Zero-knowledge rollups just put the zk proof of the transactions executed on the chain to show its computational integrity. But a big part of it is that the transaction data itself is not saved on the mainnet but on off-chain services which makes it less likely to be there for a long time but it still maintains the hash of txn. As the proofs are smaller than the data of all the txns combined they are still bigger than a single txn which makes Solana's single transaction data limit ~ 1.3 kb to be a hurdle. Ethereum will be facing the same issue post-sharding so they introduced a new EIP named Proto-Danksharding which would use Data availability sampling for the data blobs.

SIMD-0019 enables blob transactions which are chunks of data posted on the mainnet bigger than the current limit. As the posted proofs themselves don't require computational effort they are only needed to be stored for a certain amount of time and with the help of DA sampling it could be further optimized. This would allow a more rollup-friendly approach where dapps could launch rollups to add more functionality to it and still maintain solana as their root base where they post the proof and inherit its security.Links SIMD

The Solana forum is up which will be one of the centers of discussion for new updates and features so make sure to check it out

PS: thanks for Making it to the end! Gonna be making more tech dives on solana in the future. Also there were way too many resources and fragmented readings that went into this post so if I forget to link a resource feel free to reach out to me!