Blockchain

This is Part 5 of the Solana Program Lifecycle series. In Part 4 we walked through the deploy and upgrade flows: the Buffer account, the chunked writes, and the activation step that copies bytecode into the ProgramData account. Every upgrade instruction checks one thing before it proceeds: who is allowed to do this. That one thing is the upgrade_authority_address field: 33 bytes in the ProgramData account that control who can replace the program’s bytecode. This post traces the full lifecycle of that field, from the keypair that deployed the program to the irreversible --final flag that writes None and freezes the program forever. ...

This is Part 4 of the Solana Program Lifecycle series. In Part 3 we saw that a program is two accounts: a 36-byte Program Account that points to a ProgramData Account holding the actual bytecode. Now we look at how those two accounts get created and replaced. The short version: there is a third account involved. A temporary one. It exists only during the deploy or upgrade, and if anything goes wrong, it can sit on chain holding your SOL until you reclaim it. ...

This is Part 3 of the Solana Program Lifecycle series. In Part 1 we covered the account model. In Part 2 we covered compute units. Now let’s look at something most developers never think about until something breaks: how programs actually live onchain. Because here’s the thing: a Solana program isn’t one account. It’s two. And the relationship between them is what makes upgrades possible without breaking everything that depends on the program. ...

This is Part 2 of the Solana Program Lifecycle series. In Part 1 we covered how accounts work. Now comes the thing that will break our code if we ignore it: compute units. Solana transactions don’t warn you when you’re close to the compute limit. They just fail. Users lose the fees. No refund. The first time many developers discover this is when mainnet starts rejecting transactions that worked fine on devnet. ...

This is Part 1 of the Solana Program Lifecycle series. If you’re new to Solana development, start here. These concepts come up in everything you’ll build. 1. The Account Model Everything on Solana is an account. Programs, user data, tokens, even the ledger state, all stored in accounts. There’s no database engine, no relational tables. Just accounts in a flat key-value map where each key is a 32-byte address and each value is an account. ...

1. Introduction Sui is a Layer-1 blockchain that uses an object-centric model to process transactions in parallel, enabling high throughput and instant finality while providing native primitives for building decentralized applications. Developers choose Sui for several compelling reasons: Parallel execution - Transactions don’t wait in a single-file line, resulting in faster confirmation times Consumer-ready features - zkLogin (sign in with Google/Apple) and zkSend (share crypto via link) lower barriers to entry Move programming language - A secure, resource-oriented language designed specifically for blockchain development Built for scale - Optimized for data-heavy applications like gaming, NFTs, DeFi, and social apps This guide walks you through setting up the complete Sui development environment on your local machine. By the end, you’ll have the Sui CLI installed, a local network running, and the essential developer tools configured to start building Move smart contracts and decentralized applications on Sui. ...