Solana for Ethereum Devs: A Different World of Blockchains

If you're an experienced Ethereum developer looking to explore other ecosystems, Solana is definitely worth checking out. While there are some high-level similarities - they're both Layer 1 smart contract platforms after all - when you peek under the hood, the differences become quite stark. Let's dive in and see how Solana compares to Ethereum in terms of architecture, execution, accounts, and more.

A Radically Different Architecture

First, a quick primer on how Ethereum works to set the stage. Ethereum relies on the tried-and-true proof-of-work (PoW) consensus mechanism, where miners compete to add blocks to the chain. Smart contracts are executed by the Ethereum Virtual Machine (EVM) in a sequential manner. Scaling is achieved through sharding and rollups.

Solana takes a very different approach with its proof-of-history (PoH) consensus model combined with proof-of-stake (PoS). Miners are replaced by "validators" who stake their SOL tokens as collateral. Rather than PoW mining, time is split into "slots" and validators take turns producing blocks based on a verifiable delay function (VDF) - a function that takes a fixed amount of time to compute, but the output can be quickly verified, making VDFs useful for providing randomness and timing in decentralized protocols like Solana's proof-of-history consensus mechanism.

This offers some key advantages:

• Higher throughput - Solana can theoretically process 50k+ TPS vs. Ethereum's ~15
• Lower latency - Transactions finalize in seconds rather than minutes
• Lower fees - Typical tx fees are a fraction of a cent
• Energy efficiency - No PoW mining means a much smaller environmental footprint

Of course, this new model is less battle-tested than Ethereum's approach. And some argue that PoH+PoS sacrifices decentralization compared to pure PoW. But overall, this architecture enables Solana to scale in a way that is not currently possible on Ethereum L1.

Parallel vs. Sequential Execution

Beyond consensus, another key difference between Solana and Ethereum is how they handle smart contract execution.

On Ethereum, transactions are executed sequentially by all nodes. The EVM processes one transaction at a time in the order they appear in the block. This keeps things simple and prevents conflicts, but limits scalability.

Solana, in contrast, uses "Sealevel", a parallel runtime that can process thousands of contracts simultaneously. The key insight behind Sealevel is that most transactions submitted by users are not actually dependent on each other. They involve interactions with totally separate programs and accounts. Two people swapping tokens on a DEX, for instance, can execute in parallel without issue because the transactions don't overlap or modify the same state. By processing non-overlapping transactions in parallel, Solana can achieve a huge boost in throughput without sacrificing consistency.

Transactions specify upfront which state they will "read" and "write" so the runtime can check for conflicts ahead of time. This allows Solana to optimize execution while still guaranteeing that transactions are processed correctly and deterministically. That said, developers need to be a bit more thoughtful about structuring logic to maximize the potential for parallel execution and avoid unnecessary dependencies between transactions.

Solana also uses the more standard LLVM compiler framework instead of a specialized virtual machine like the EVM. LLVM, which stands for "Low Level Virtual Machine", is a powerful open-source compiler toolchain used widely in the software industry. It can optimize code for many different hardware architectures. By compiling Solana smart contracts down to native machine code, the LLVM framework removes a layer of overhead and enables lower-level performance optimizations compared to higher-level VMs.

This ties into Solana's choice of Rust as its primary smart contract language. Rust is designed to be fast, safe, and memory-efficient - an ideal fit for resource-constrained blockchain VMs. And being LLVM-compatible, Rust plugs nicely into Solana's compiler architecture. The catch is Rust has a steeper learning curve than Solidity, so Ethereum devs will need to invest some time getting the hang of the borrow checker, generics, and other Rust paradigms. But the performance and safety gains are often worth the effort for demanding applications.

Understanding PDA Accounts

If you're used to Ethereum's account model, Solana's account system will feel a bit foreign at first. But it's arguably more flexible and efficient once you grasp the core concepts. Let's break it down:

In Ethereum, you have externally owned accounts (EOAs) controlled by private keys, and contract accounts with associated code and storage. Two types total. Easy enough.

Solana has three types of accounts:

1. Data accounts - Store data but have no owner
2. Program accounts - Store executable code (like a smart contract)
3. Executable accounts - Controlled by a private key, like an EOA

Program Derived Addresses (PDAs) are a special type of account that let you do some powerful things. Rather than being controlled by a private key, PDAs are owned and controlled by a program. PDAs are a unique aspect of Solana's account model that enable some powerful features not found in Ethereum. Let's dive deeper into how PDAs work under the hood, including the cryptography that makes them secure.

To understand PDAs, we first need to look at how regular accounts work in Solana. Solana uses the Ed25519 elliptic curve for its cryptography. Every normal account has a keypair consisting of:

1. A private key that can sign transactions
2. A public key that serves as the account's address on chain

The public key is a point on the Ed25519 curve that corresponds to the private key. This forms the basis of public key cryptography - anyone can verify that a transaction was signed by the owner of the private key, without needing to know the private key itself.

PDAs turn this model on its head. They are intentionally derived to be points that are off the Ed25519 curve. Because of the math behind elliptic curves, points that are not on the defined curve have no valid corresponding private key. This means there is no private key that can sign transactions for a PDA.

So how are PDAs created and used? They are deterministically derived by programs using a combination of:

1. The program's own ID
2. A set of "seeds" (arbitrary strings/public keys chosen by the program)
3. A "bump" value (a number between 0-255)

The program ID and seeds are concatenated together and hashed to generate a point. The bump value is then added, one at a time, until the resulting point falls off the Ed25519 curve. This final, off-curve point is the PDA.

This process is deterministic - given the same program ID and seeds, it will always derive the same PDA. But since there is no private key, PDAs can't sign transactions like regular accounts.

However, programs are allowed to sign for PDAs that they own. More precisely, a program can issue transactions "signed" by a PDA if:

1. The program ID was used to derive the PDA
2. The program can provide the exact seeds and bump used to derive the PDA

This gives programs a secure way to assign ownership and control over accounts without needing to custody private keys. The program can derive PDAs on the fly from arbitrary seeds, and then use them to create and manipulate accounts that only the program has authority over.

Solana's SPL Token Standard

To set the stage, let's briefly review how tokens typically work on Ethereum. The two most common standards are:

1. ERC20 for fungible tokens
2. ERC721 for non-fungible tokens (NFTs)

ERC20 defines a standard interface for tokens that are interchangeable and divisible, like a stablecoin or governance token. The standard includes functions like transfer, balanceOf, approve and so on.

ERC721, in contrast, is used for unique assets like collectibles, art, or game items. Each token has a unique ID and isn't divisible. The interface includes things like ownerOf, safeTransferFrom, etc.

In both cases, the token logic lives in a central contract. The balances are mapped to user addresses in the contract's storage. And notably, tokens don't have their own addresses on chain - they exist solely within the contract's storage.

Solana takes a fundamentally different approach with its SPL (Solana Program Library) token standard. Rather than living in a single contract, each token mint and token account is its own distinct account on chain.

The token program itself defines the rules for how these accounts behave, but each token is its own standalone thing. This has some important implications:

1. Tokens have their own addresses on chain
2. Each token account has its own storage, independent of the main token contract
3. The token contract is really more of a "token program" that any account can interact with
4. The same token program can be used for any number of distinct tokens

This model is powerful because it allows tokens to be treated as first-class citizens on the Solana chain. Rather than being tucked away in a contract's storage, they are real accounts that can interact with any other account or program.

Associated Token Accounts

Another key concept in Solana are associated token accounts. In Ethereum, your token balances live in the token contract itself, mapped to your main address. But in Solana, users need to create a separate "associated token account" (ATA) for each token they want to hold.

An ATA is deterministically derived from a user's main address and the token mint address. So for a given wallet and token, there is exactly one ATA address that will always belong to that user.

The process looks like this:

1. A user's wallet sends a transaction to the token program
2. The transaction includes the user's main address and the token they want to create an account for
3. The token program derives the ATA address using the createAssociatedTokenAccount function
4. The program creates an account at that address, owned by the user

Once created, that ATA is a distinct account on chain with its own storage and logic. The user's wallet can instruct the ATA to transfer or receive tokens, check its balance, and so on.

While this may seem like more work than the Ethereum model, it has some big benefits:

1. Token accounts have their own storage, so they can actually hold more than just a balance (more on this later)
2. Since each token is its own account, it's easier to reason about and inspect on chain
3. There's less brittleness and centralization risk since everything isn't crammed into one contract
4. You can transfer tokens to an account before it even exists (the ATA will be created on transfer)

Bringing It All Together: A More Expressive Token Standard

The SPL token interface itself takes inspiration from both ERC20 and ERC721. Like ERC20, it supports fungible tokens that are divisible and interchangeable. But it also includes some features from ERC721, like the ability to attach metadata to a token account!

Since each token account has its own storage, you can actually extend it with additional data beyond just the balance. This could include things like:

• A URI pointing to off-chain metadata (name, description, etc.)
• On-chain attributes or properties
• Vesting or lockup schedules
• Whitelists or transfer restrictions
• Anything else you can dream up!

This flexibility opens up a lot of doors. You can create tokens that blur the line between fungible and non-fungible, similarly to ERC-1155, or that have sophisticated on-chain behavior. Some clever examples I've seen:

• "Programmable" tokens that interact with other programs
• Governance tokens with on-chain voting power
• Stablecoins with built-in yield
• NFTs with dynamic, upgradeable metadata
• Tokens that "transform" based on certain conditions
• Gated access tokens for games or exclusive communities

Because Solana's accounts are so flexible, and because the token program is a primitive that anyone can build on, developers have a ton of latitude to experiment with novel designs that aren't really feasible on Ethereum today.

Other Quirks and Differences

A few other random differences worth knowing about:

• Solana is single-threaded in each shard, while Ethereum supports multi-threading
• Solana has a 8 byte unsigned integer for internal value, while Ethereum uses a 32 byte signed integer
• Solana has a different curve (Ed25519) for generating key pairs, so Ethereum's secp256k1-based keys won't work
• Solana uses Rust as the primary smart contract language rather than Solidity
• Solana contracts can be upgradable, while Ethereum contracts are immutable by default
• Solana has a different VM, file format (.so), and ABI method

Takeaways

Overall, Solana presents a very powerful alternative to Ethereum, especially for use cases that demand high throughput and low fees. That said, it's a very different paradigm that will require some mental rewiring if you're used to the EVM world.

The account model in particular introduces a lot of new concepts that can be tricky to grasp at first. PDAs, Associated Token Accounts, ownership rules - it's a lot to wrap your head around. But once it "clicks", you'll find that Solana's design allows for some really creative applications that aren't feasible on contemporary Ethereum.

The other big consideration is maturity and adoption. Ethereum is still the 800-pound gorilla in terms of developer mindshare, tooling, infrastructure, and network effects. While Solana is growing fast, it's still a smaller ecosystem with some kinks being worked out.

As an Ethereum developer, it's absolutely worth learning how Solana works and playing around with it. The concepts you'll learn - parallel execution, PoH, PDAs, etc. - will expand your mental model and make you a more well-rounded blockchain developer. And you may find that Solana is a better fit for some projects. Just go in with eyes wide open about the differences and tradeoffs.

I hope this overview helps kickstart your journey into the world of Solana! Let me know if you have any other questions.