Adithyaa

10 months back i dropped out of college when i was just 19 to build and contribute on @solana as a developer. 6 months later i won a grant from @SuperteamIN. two months later @epochdotm took a bet on me as CMO. shipped content, grew fast and made the noise. two months after that i co-founded @dawghq_. shipped hype videos across Solana and earned my way into working with some of the most passionate startups in the ecosystem. and i’m not done yet. my goal is to be one of the best motion designers and ship great content forward with all my creativity for the best products out there. and i wanna document my learnings, works, Ws and Ls from now. everything you see next will be a part of my journey. appreciate all the support in advance <3

don’t settle.

@solana @toly @rajgokal

@solana @toly

solana validator client 101 1/ streamer basically when someone submits a transaction it travels over the internet as a UDP packet to the current validator leader. at the validator the streamer is the one which is receiving all these UDP packets. not only the transactions also the votes from other validators, shreds (block data), gossip messages (more on this later) - all of these come as UDP packets too & land at the streamer. * 1 packet is upto 1232 bytes of raw data + metadata (sender, size, flags). when these packets arrive at the streamer it doesn't know yet what the packets actually are whether a tx, vote or scrap. at first they are basically put into a pre allocated buffer, get grouped into a PacketBatch of 64 & are down streamed to sigverify channel. * PacketBatch is a vec of 64 packets grouped together, why 64 packets? - recvmmsg syscall reads up to 64 packets in one kernel call. if the channel is temporarily overwhelmed and it fills up, the packets are dropped & the pipeline keeps moving without getting stalled. the sender can retry. 2/ sigverify sigverify uses these to verify signatures across all 64 packets in a PacketBatch in parallel using a thread pool. this is how GPU/CPU parallelism gets applied to packet processing. if packets are invalid it marks them as discard = true. but they are not removed. * since its fixed batch of 64 slots removing the packet at 7th index is much costlier at 70K+ TPS. basically sigverify does 3 steps: 1. dedup (deduplication): a bloom filter (probabilistic data structure). hash the packet bytes, check if that hash exists in the filter within a 2 sec window. if yes marks it discard with a false positive rate of 0.001 * sigverify is too expensive so removing dups makes sense cause we don't wanna waste CPU verifying the same tx 100 times from spam bots! 2. priority floor: when the scheduler is saturated (too many txs queued), it publishes a "floor" priority. any incoming tx with fee below that floor gets discarded immediately, before sigverify. * if the scheduler queue is full of high-fee txns, there's no point in verifying low-fee ones. they'll just sit in queue and expire. kill them early & save CPU! 3. ed25519_verify_serial(&mut batch, reject_non_vote, ...): opens the bytes, deserializes the transaction, checks the ed25519 signature. if invalid sig adds discard flag. * the vote channel rejects non-vote transactions here. the verified batch (with discard flags set) gets wrapped in a BankingPacketBatch and pushed to the banking stage channel. 3/ banking - how valid transactions get scheduled & executed. upcoming thread! cc: @toly @solana @solana_devs