diff --git a/.gitignore b/.gitignore index b3144ed..84727e4 100644 --- a/.gitignore +++ b/.gitignore @@ -17,6 +17,15 @@ pids *.seed *.pid.lock +# OS generated files +.DS_Store +.DS_Store? +._* +.Spotlight-V100 +.Trashes +ehthumbs.db +Thumbs.db + # Directory for instrumented libs generated by jscoverage/JSCover lib-cov diff --git a/articles/How to Migrate an Ethereum Protocol to Solana Contracts (Part 1)/README.md b/articles/How to Migrate an Ethereum Protocol to Solana Contracts (Part 1)/README.md new file mode 100644 index 0000000..440d0d5 --- /dev/null +++ b/articles/How to Migrate an Ethereum Protocol to Solana Contracts (Part 1)/README.md @@ -0,0 +1,596 @@ +--- +published: true +title: "How to Migrate an Ethereum Protocol to Solana — Contracts (Part 1)" +author: ["Jimmy Zhao / Fullstack Engineer", "Bin Li / Tech Lead"] +createTime: 2026-01-26 +categories: ["engineering"] +tags: ["Solana", "Ethereum", "Smart Contract", "Solidity", "Anchor"] +landingPages: ["Blockchain-Onchain infra"] +thumb: "./thumb.png" +thumb_h: "./thumb_h.png" +intro: "A deep dive into the core mindset shift and best practices when moving contracts from Ethereum to Solana." +--- + +## Article Overview + +As the Solana ecosystem matures, more Ethereum (EVM) protocol teams are exploring migration to Solana to achieve higher throughput, lower transaction costs, and improved user experience. Through leading and executing multiple real-world Ethereum-to-Solana migrations, we've accumulated hands-on experience across smart contract architecture, data models, transaction design, and full-stack coordination. + +This article is part of a broader series on migrating Ethereum protocols to Solana, where we break the process down into three core layers: smart contracts, backend services, and frontend interactions. If you're new to the series, we recommend starting with "[How to Migrate an Ethereum Protocol to Solana — Preamble](https://57blocks.com/blog/how-to-migrate-an-ethereum-protocol-to-solana-preamble?tab=engineering)," which introduces the fundamental architectural differences between the two ecosystems. + +In this article, we focus specifically on the smart contract layer. Rather than treating migration as a simple language switch from Solidity to Rust, we examine the deeper mindset shifts required when moving from Ethereum's contract-centric model to Solana's account-centric design. Using concrete examples and real production patterns, we'll walk through the most important conceptual changes, common pitfalls, and best practices that Ethereum developers need to understand to build secure and efficient Solana programs. + +#### Article Navigation + +- [How to Migrate an Ethereum Protocol to Solana — Preamble](https://57blocks.com/blog/how-to-migrate-an-ethereum-protocol-to-solana-preamble?tab=engineering): A systematic introduction to the fundamental differences between Ethereum and Solana in account models, execution mechanisms, and fee systems. +- [How to Migrate an Ethereum Protocol to Solana — Contracts (Part 1)](https://57blocks.com/blog/how-to-migrate-an-ethereum-protocol-to-solana-contracts-part-1?tab=engineering): A focus on the core mindset shift and best practices for contract development from Ethereum to Solana. + +--- + +Solana rose in popularity and matured quickly because its high performance and low costs attracted a surge of developer and user attention. Meanwhile, Ethereum (EVM) and EVM-compatible chains had massive ecosystems but faced challenges like limited scalability and high transaction fees. As a result, more Web3 developers have been turning to Solana for its improved developer and user experiences, making the migration from Ethereum to Solana a prominent trend. So, how do we effectively port the smart contracts we've mastered on Ethereum to the Solana platform? Many developers initially thought that they would only need to reprogram apps using Rust rather than Solidity, but they soon discovered that the real migration challenge rested in the fundamental differences of Solana's underlying architecture. This article aims to help experienced Ethereum developers complete a critical mental model shift so they can efficiently and securely reimplement existing contract logic the Solana way. + +## The Core Mindset Shift + +When migrating from Ethereum to Solana, your first task is to shift your mindset from a contract-centric model to an account-centric one. You may want to read "[How to Migrate an Ethereum Protocol to Solana — Preamble](https://57blocks.com/blog/how-to-migrate-an-ethereum-protocol-to-solana-preamble?tab=engineering)," for additional background. + +In this article, we will address the core mental model for Solana smart contract development. Three key conceptual shifts to help you move an app from EVM to Solana contract development include gaining a new understanding of the relationship between accounts and programs, moving from Token accounts and Cross-Program Invocations (CPI), and using explicitly declared dependencies in calls. + +To make these concepts concrete, we included code examples that reference a complete, open-source Staking migration project. We'll dissect the project in the final section, but before that, we'll frequently use its code snippets to support each concept we discuss. + +### The Account Model + +On Ethereum and EVM-compatible chains, smart contracts follow a monolithic design where a contract is both the carrier of code and the container of state, tightly coupling execution logic and storage. For example, a standard ERC20 token contract not only contains functions like `transfer` and `approve`, but also a `mapping` to store balances for all users. This design is similar to object-oriented programming's class instances (Object), where methods and data are encapsulated in a single entity, forming a complete, self-contained functional unit. Here's a concrete Solidity example: + +```solidity +// evm-staking/src/Staking.sol +contract Staking { + // Staking and reward tokens are state variables + IERC20 public stakingToken; + IERC20 public rewardToken; + + // User stake information is stored in a mapping + mapping(address => StakeInfo) public stakes; + uint256 public totalStaked; + + struct StakeInfo { + uint256 amount; + int256 rewardDebt; + uint256 claimed; + } + + // ... business logic like stake() and unstake() +} +``` + +In this example, the `stakingToken` and `rewardToken` addresses, and all users' Staking data `stakes`, are stored directly in the internal state of the `Staking` contract. + +Solana takes a completely different approach to its account model, by fully separating code and data. On Solana, **programs** contain only logic, are stateless, and do not store business data, while **accounts** only store data. When executing a transaction, you must explicitly tell the **program** which **accounts** to operate. As a simpler explanation, think of a **program** as an executable and **accounts** as the data files it reads and writes, stores and manages separately. + +Here’s the corresponding Solana (Anchor) implementation: + +```rust +use anchor_lang::prelude::*; + +// The program itself is stateless. +#[program] +pub mod staking { + pub fn stake(ctx: Context, amount: u64) -> Result<()> { + // Business logic operates on accounts passed via the context. + // The context `ctx` contains all necessary accounts, + // such as `GlobalState` and `UserStakeInfo`, defined in the `Stake` struct below. + let state = &mut ctx.accounts.state; + let user_info = &mut ctx.accounts.user_stake_info; + state.total_staked += amount; + user_info.amount += amount; + // ... + Ok(()) + } + // ... other instructions like unstake() +} + +// The `Stake` context struct, defining all accounts for the `stake` instruction. +#[derive(Accounts)] +pub struct Stake<'info> { + #[account(mut)] + pub state: Account<'info, GlobalState>, + #[account(mut)] + pub user_stake_info: Account<'info, UserStakeInfo>, + // ... other necessary accounts +} + +// State is defined in separate account structs. +#[account] +pub struct GlobalState { + pub total_staked: u64, + // ... other global state +} + +#[account] +pub struct UserStakeInfo { + pub amount: u64, + // ... other user state +} +``` + +Here, the `staking` program is stateless and holds no data. All data—both global `GlobalState` and per-user `UserStakeInfo`—are defined in separate `#[account]` structs. The program receives these accounts through the `Context` object (typed by the `Stake` struct), and then operates on them. + +This design's fundamental purpose is to enable large-scale [parallel processing](https://medium.com/solana-labs/sealevel-parallel-processing-thousands-of-smart-contracts-d814b378192). Because code and data are separated, Solana transactions will declare all accounts they will access ahead of execution and specify whether each account is read-only or writable. This allows the runtime to build a dependency graph and schedule transactions efficiently. If two transactions touch completely unrelated accounts—or both only read the same account—they can safely run in parallel. Only when one transaction needs to write to an account, other transactions that access that account (read or write) will be temporarily blocked and executed sequentially. With this fine-grained scheduling, Solana maximizes multi-core utilization to process many non-interfering transactions concurrently. This is a key element to its high throughput and low latency. + +### Token Standards + +Differences in the account model appear most directly in token standards. Using our Staking contract example, let's compare it across the two platforms. In the ERC20 standard on Ethereum, token state is managed by a centralized token contract, and application contracts indirectly manipulate user balances by calling that token contract's functions. + +```solidity +// evm-staking/src/Staking.sol +contract Staking { + IERC20 public stakingToken; + // ... + + function stake(uint256 amount) external { + // The Staking contract calls the token contract's transferFrom + // to move funds from the user to itself. + stakingToken.transferFrom(msg.sender, address(this), amount); + // ... + } +} +``` + +In this model, a user’s token balance is just an entry in a `mapping` inside the `stakingToken` contract, and `transfer` means mutating two values in that mapping. + +Solana's SPL Token standard works differently. There is a shared, official `Token Program` for all tokens. Users’ tokens are not stored in a centralized contract but in user-owned, independent token accounts. To operate on tokens, our staking program must receive these token accounts as inputs. + +```rust +// solana-staking/programs/solana-staking/src/instructions/stake.rs +// The context for the stake instruction requires specific token accounts. +#[derive(Accounts)] +pub struct Stake<'info> { + #[account(mut)] + pub user_token_account: Account<'info, TokenAccount>, + #[account(mut)] + pub staking_vault: Account<'info, TokenAccount>, + pub token_program: Program<'info, Token>, + // ... +} + +// The instruction itself commands the Token Program to perform the transfer. +pub fn stake(ctx: Context, amount: u64) -> Result<()> { + token::transfer( + CpiContext::new( + ctx.accounts.token_program.to_account_info(), + Transfer { + from: ctx.accounts.user_token_account.to_account_info(), + to: ctx.accounts.staking_vault.to_account_info(), + authority: ctx.accounts.user.to_account_info(), + } + ), + amount + )?; + // ... + Ok(()) +} +``` + +Here, Staking uses a Cross-Program Invocation (CPI) to call the official token program's transfer instruction to move funds between the user's token account and the program's vault token account—clearly illustrating the separation between data (token accounts) and logic (Token Program). + +This fundamental difference also explains the common confusion new Solana users often see: the wallet prompting a user or programmer to create an account before receiving a new token. Before receiving USDC, your Solana wallet must first create a token account to hold USDC, almost like setting up a dedicated mini-vault. Whereas on Ethereum, your wallet address can "receive" any ERC20 token because "receiving" simply means another entry is recorded inside the token contract's internal ledger; no preparation is needed on your end. + +### Contract Calls + +Differences in account models lead to huge differences in how you interact with contracts (programs). In Solidity, when calling a function, the EVM prepares contextual information behind the scenes—most notably `msg.sender`. Developers don't need to specify the caller in parameters; the EVM handles it implicitly, making function calls look clean. + +Here is an Ethereum Call Example (Foundry Test) that illustrates how this works. + +```solidity +// evm-staking/test/Staking.t.sol +function testStake() public { + uint256 stakeAmount = 1000 * 10 ** 18; + + // The user's address is implicitly passed as msg.sender + vm.startPrank(user1); + myToken.approve(address(staking), stakeAmount); + staking.stake(stakeAmount); + vm.stopPrank(); + + (uint256 stakedAmount, ,) = staking.getStakeInfo(user1); + assertEq(stakedAmount, stakeAmount); + assertEq(staking.totalStaked(), stakeAmount); +} +``` + +In Foundry Test above, `vm.startPrank(user1)` sets `msg.sender` for subsequent calls to `user1`. When calling `staking.stake(stakeAmount)`, we only pass the business parameter `amount`. + +On Solana, the program has no implicit context about the caller or surrounding state. The program needs every piece of information—including identifying who the caller is and which accounts it must read or write to—explicitly provided in the transaction instruction. These accounts are packed into a `Context` object and passed as parameters. This design aligns with parallel processing: the runtime can only determine safe parallel execution if each transaction lists all accounts it will access. + +Below is the Solana Call Example (TypeScript Test) for reference: + +```typescript +// solana-staking/tests/solana-staking.test.ts +// Helper function to simplify the call +async function stakeTokens( + user: Keypair, + userSigner: any, + stakingToken: PublicKey, + rewardToken: PublicKey, + amount: bigint +) { + const userStakePda = getUserStakePda(statePda, user.publicKey); + + // All required accounts must be explicitly passed. + const stakeInstruction = programClient.getStakeInstruction({ + user: userSigner, + state: address(statePda.toBase58()), + userStakeInfo: address(userStakePda.toBase58()), + userTokenAccount: address(stakingToken.toBase58()), + stakingVault: address(stakingVaultPda.toBase58()), + // ... and other accounts + amount: amount, + }); + + return await sendTransaction(provider, stakeInstruction, user); +} +``` + +In this TypeScript Test, calling the `stake` instruction requires a large account object: `user` (signer), `state` (global state account), `userStakeInfo` (user staking data account), `userTokenAccount` (the user's token account), `stakingVault` (the program's vault), etc. While this makes the client call more verbose, it brings transparency and safety. Before the transaction is sent, the client code explicitly defines all accounts included in the transaction. There are no hidden contextual dependencies in a Solana transaction. + +Additionally, on Ethereum, upgrading a contract often requires changing client code to point to a new contract address. On Solana, you simply deploy new program code to the same program ID, achieving seamless upgrades. All business data remains untouched in their accounts because data and logic are decoupled. Since the program address doesn’t change, client code remains compatible. + +If you want deeper architectural context for the code patterns in this article, revisit "[How to Migrate an Ethereum Protocol to Solana — Preamble](https://57blocks.com/blog/how-to-migrate-an-ethereum-protocol-to-solana-preamble?tab=engineering)," which provides a more systematic conceptual background. + +## Tooling Comparison + +To put these ideas into practice, you may want to get comfortable with a different, ecosystem-specific toolchain. From language to standard libraries, Solana's ecosystem differs significantly from Ethereum's ecosystem. The table below summarizes key differences to help you build a new understanding of the differences quickly. + +| **Domain** | **Ethereum Ecosystem** | **Solana Ecosystem** | **Key Notes** | +| :------------------------ | :------------------------------------ | :---------------------------------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| **Frameworks** | Hardhat / Foundry (Solidity) | Anchor (Rust) | In the Ethereum ecosystem, Hardhat and Foundry are widely used smart contract development tools. Anchor is the de facto standard for Solana development; it uses powerful macros to greatly simplify the complexity of Solana program development. | +| **Interface Standard** | ABI (Application Binary Interface) | IDL (Interface Definition Language) | Anchor automatically generates an IDL from your program code, similar to the ABI concept on Ethereum—ABI is Ethereum’s contract interaction standard, and the Solidity compiler automatically generates ABI files describing function/parameter/return binary encodings. Clients can use these IDL or ABI files to interact with your program without needing to understand the underlying implementation. | +| **Standard Library** | OpenZeppelin | SPL (Solana Program Library) | OpenZeppelin is an import-and-inherit code library, whereas SPL is a set of reusable standard programs already deployed on-chain. You interact with them via Cross-Program Invocation (CPI) instead of copying code into your project. | +| **Contract Verification** | Upload and verify source on Etherscan | Submit source for Verified Build | Solana supports “Verified Builds,” conceptually similar to Ethereum. Developers submit source code, which is compiled in a deterministic environment; the build artifact’s hash is compared against on-chain bytecode. This ensures the source matches the on-chain program—not just validating the IDL interface. | +| **Network RPC** | Infura, Alchemy, QuickNode | Helius, Alchemy, QuickNode | Both ecosystems have top-tier RPC providers; only a few (like QuickNode) are multi-chain. Solana's high throughput has also led to specialized providers like Helius to offer enhanced Solana-first APIs. | +| **Explorers** | Etherscan, Blockscout | Solscan, Solana Explorer, X-Ray | The Ethereum ecosystem has powerful tools like Tenderly for deep transaction simulation and debugging. In the Solana ecosystem, tools like Helius (product X-Ray) provide similar functionality. Due to Solana’s parallel transaction model, these tools focus more on visualizing value flows between accounts and CPI call chains to help developers understand complex instruction interactions. | + +From this comparison, a clear pattern emerges: Ethereum development supports ideas like inheritance and extension (e.g., inheriting OpenZeppelin contracts), while Solana development supports composition and interaction (via CPI with on-chain SPL programs). + +We recommend that newcomers to Solana use the Anchor framework whenever possible. Unlike Ethereum's Hardhat/Foundry, which focuses on the external development flow (tests, deployment, scripting), Anchor affects how program code is written and runs. Its Macros and constraints dramatically simplify the process of writing Solana programs by handling a lot of tedious and error-prone low-level safety checks and data serialization. If you master Anchor, you'll master efficient, safe business logic on Solana. + +## Solana Development Best Practices + +Once you understand Solana's tooling differences, you still need to apply them with Solana's design philosophy in mind. Simply swapping Solidity for Rust isn't enough—true efficiency and account security come from following best practices distilled by the ecosystem as outlined in the following sections. + +### Embrace the Anchor Framework + +There are two main approaches to Solana program development: Native and Anchor-based. + +Native development requires direct interaction with Solana's low-level libraries, meaning you must manually serialize and deserialize account data and write a lot of code to verify account ownership, signer permissions, mutability, and similar functions. While this offers maximum flexibility, it's complex, verbose, and prone to security pitfalls. + +Solana's official recommendation, meant specifically for developers migrating from Ethereum, is to choose Anchor. Anchor leverages Rust macros to simplify development, enhance safety, and ultimately automate the complex parts of native development. + +Here's a simple `initialize` instruction for creating a new global state account using Anchor. Once you declare accounts and constraints, the framework handles validation and initialization for you. + +```rust +// solana-staking/programs/solana-staking/src/instructions/initialize.rs +#[program] +pub mod staking { + pub fn initialize_handler(ctx: Context, reward_per_second: u64) -> Result<()> { + // Business logic is clean and focused. + let state = &mut ctx.accounts.state; + state.reward_per_second = reward_per_second; + state.admin = ctx.accounts.admin.key(); + // ... + Ok(()) + } +} + +// Define accounts and constraints declaratively. +#[derive(Accounts)] +pub struct Initialize<'info> { + #[account(mut)] + pub admin: Signer<'info>, + // Anchor handles the creation and rent payment for this account. + #[account(init, payer = admin, space = 8 + GlobalState::INIT_SPACE)] + pub state: Account<'info, GlobalState>, + pub system_program: Program<'info, System>, +} + +#[account] +pub struct GlobalState { + pub admin: Pubkey, + pub reward_per_second: u64, + // ... +} +``` + +To better understand what Anchor abstracts, let's examine a functionally equivalent implementation using the Native approach. + +A functionally equivalent implementation using the Native approach requires you to handle all the details manually: + +```rust +// A functionally equivalent implementation in native Rust. +use solana_program::{ + account_info::{next_account_info, AccountInfo}, + entrypoint, + entrypoint::ProgramResult, + pubkey::Pubkey, +}; +use borsh::{BorshDeserialize, BorshSerialize}; + +// The single entrypoint for the program. +entrypoint!(process_instruction); + +pub fn process_instruction( + program_id: &Pubkey, + accounts: &[AccountInfo], + instruction_data: &[u8], +) -> ProgramResult { + // 1. Manually parse and validate accounts from the raw slice. + let accounts_iter = &mut accounts.iter(); + let state_account = next_account_info(accounts_iter)?; + let authority = next_account_info(accounts_iter)?; + // ... must manually check that authority is a signer, state is writable, etc. + + // 2. Manually create the state account via a Cross-Program Invocation (CPI). + // This requires calculating space, rent, and building the instruction. + // (This is a complex, multi-line operation in real code). + + // 3. Manually deserialize instruction data to get the `reward_rate`. + let reward_rate = u64::try_from_slice(&instruction_data)?; + + // 4. Manually serialize the new state and write to the account's data buffer. + let state = State { authority: *authority.key, reward_rate }; + state.serialize(&mut &mut state_account.data.borrow_mut()[..])?; + + Ok(()) +} +``` + +Anchor abstracts a lot of native boilerplate code (account checks, CPI calls, data serialization) into concise, safer macros. This allows developers to focus on determining and defining business logic, significantly improving productivity and readability. In the examples above, Anchor removes the need for manual account parsing, signer and mutability checks, explicit account creation via CPI, and byte-level (de)serialization, allowing the instruction handler to focus almost entirely on business logic. + +Of course, convenience isn't free. Anchor's abstraction layer, including its auto-inserted safety checks, tends to consume more Compute Units (CU) than highly optimized native code, and Anchor-generated bytecode is usually larger than equivalent native programs. Although Solana program accounts can be up to 10 MB in size, which appears fairly small, the complexity of the protocols and program will impact performance. To truly excel on Solana and solve complex issues or do deep optimizations, you should still understand the native APIs behind Anchor's macros and how the abstractions and underlying mechanisms work. + +For most projects, Anchor's gains in development speed and safety far outweigh its performance overhead. But to master Solana, you'll want deeper knowledge of its lower-level mechanisms. + +### Account Lifecycle and Rent + +On Ethereum, you pay for contract storage once at deployment, and it persists forever. Solana, however, uses a Rent mechanism to manage on-chain storage. + +On Solana, all accounts (data or program accounts) must pay rent to occupy on-chain storage. This rent mechanism prevents unbounded state growth and compensates validators for storing data. In practice, to avoid accounts being reclaimed when their balance is exhausted, the standard approach is to deposit enough SOL (in lamports) upon creation to cover about two years of rent. This action makes the account **rent-exempt** and, effectively, permanently allocated. When an account is closed, this pre-deposited lamports balance is fully refunded. + +This introduces an **account lifecycle** concept, where developers proactively manage creation, use, and destruction. Many major Solana projects follow this pattern. To explain this in greater depth, we'll use [Mango Markets v4](https://github.com/blockworks-foundation/mango-v4) as an example. Mango Markets is a Solana-based decentralized trading, lending, and leverage platform, whose program design exemplifies account lifecycle management. + +**Creation & Initialization** + +When a user first opens an account in Mango v4, the program creates a new `MangoAccount`. This process is defined in the `AccountCreate` context, where the `#[account(init, ...)]` constraint is key to creation and rent payment. + +```rust +#[derive(Accounts)] +pub struct AccountCreate<'info> { + // ... other accounts + #[account( + init, + seeds = [b"MangoAccount".as_ref(), group.key().as_ref(), owner.key().as_ref(), &account_num.to_le_bytes()], + bump, + payer = payer, + space = MangoAccount::space(token_count, serum3_count, perp_count, perp_oo_count, 0), + )] + pub account: AccountLoader<'info, MangoAccountFixed>, + pub owner: Signer<'info>, + + #[account(mut)] + pub payer: Signer<'info>, + pub system_program: Program<'info, System>, +} +``` + +- `init`: tells Anchor to create the `account`. +- `seeds = [...]` and `bump`: indicate `MangoAccount` is a PDA, derived from the protocol’s `group`, `owner`, and `account_num`. +- `payer = payer`: specifies the payer (often the owner) to fund rent-exemption on creation. +- `space = ...`: defines the allocated storage size, computed dynamically by a function. + +For more details, see [Mango Markets v4 source](https://github.com/blockworks-foundation/mango-v4/blob/dev/programs/mango-v4/src/accounts_ix/account_create.rs). + +**Closing & Destruction** + +When an account is no longer needed (e.g., a user clears and closes their Mango trading account), it can be closed to recover the pre-deposited rent. In Mango v4, the `AccountClose` context uses the `close` constraint: + +```rust +#[derive(Accounts)] +pub struct AccountClose<'info> { + // ... other accounts + #[account( + mut, + has_one = group, + has_one = owner, + constraint = account.load()?.is_operational() @ MangoError::AccountIsFrozen, + close = sol_destination + )] + pub account: AccountLoader<'info, MangoAccountFixed>, + pub owner: Signer<'info>, + + #[account(mut)] + pub sol_destination: UncheckedAccount<'info>, +} +``` + +- `close = sol_destination`: this is crucial to tell Anchor to automatically close `account` after successful execution and refund all its lamports (rent deposit) to `sol_destination`. This explicit create–destroy model is central to resource management in Solana programs. + +For more details, see [Mango Markets v4 source](https://github.com/blockworks-foundation/mango-v4/blob/dev/programs/mango-v4/src/accounts_ix/account_close.rs). + +Our `solana-staking` example also follows this lifecycle model. The `initialize` instruction creates global state and vault accounts; the `stake` instruction uses `init` to create a user info account on first stake; and in `unstake`, if the user’s balance returns to zero, the program uses `close` to destroy their user info account and refund rent. See the repository here: [solana-staking](https://github.com/57blocks/evm-to-solana/tree/main/contract/solana-staking). + +### Program Derived Addresses (PDA) + +When managing account lifecycles, Program Derived Addresses (PDA) are central to Solana's security model. A PDA is deterministically derived from a program ID and a set of seeds, has no private key, and only the deriving program can "sign" for it. PDAs let programs own/control other accounts, making them ideal as secure data stores, token vaults (Vault), or authority hubs. In an instruction, Anchor recomputes and verifies a PDA's address using the provided seeds and a `bump` (a nonce ensuring the address lies off the elliptic curve), preventing clients from passing forged accounts, which is critical for security. By setting a PDA as another account's `authority`, you can build complex, program-controlled permission systems, which is a common pattern in Solana program design. + +Here's how a PDA is defined and used. In our staking program, the `UserStakeInfo` account is a PDA that stores each user's personal staking information. + +```rust +// solana-staking/programs/solana-staking/src/instructions/stake.rs +// The Stake context defines how the user_stake_info PDA is derived. +#[derive(Accounts)] +pub struct Stake<'info> { + #[account(mut)] + pub user: Signer<'info>, + + // The 'seeds' and 'bump' constraints define this as a PDA. + #[account( + init_if_needed, + payer = user, + space = 8 + UserStakeInfo::INIT_SPACE, + seeds = [STAKE_SEED, state.key().as_ref(), user.key().as_ref()], + bump + )] + pub user_stake_info: Box>, + // ... other accounts +} + +// The data structure for the PDA account. +#[account] +#[derive(InitSpace)] +pub struct UserStakeInfo { + pub owner: Pubkey, + pub amount: u64, + pub reward_debt: i128, + pub claimed: u64, + pub bump: u8, +} +``` + +- `seeds = [STAKE_SEED, state.key().as_ref(), user.key().as_ref()]`: the core PDA definition. It derives `user_stake_info` from a constant `STAKE_SEED`, the global state account `state.key()`, and the user public key `user.key()`. This ensures a unique, predictable `UserStakeInfo` address per user per staking pool. +- `bump`: Anchor finds a `bump` and stores it in the PDA’s data. Future instructions use the stored `bump` to re-derive and verify the address, ensuring `user_stake_info` is legitimate, not forged. +- `init_if_needed`: a convenience constraint that auto-creates this PDA on a user’s first stake. It’s feature-gated in Anchor because it can introduce reinitialization risks, so avoid it when possible. + +This gives each user a unique, program-controlled data account, showcasing the power of PDAs. + +### Program Architecture: Prefer a Single Program + +In Ethereum, developers often build composable mini-contracts, each handling a distinct function. On Solana, a different architectural pattern is generally recommended to use where you consolidate tightly related business logic into a relatively complete single program. + +There are two reasons to do this. First, the complexity of CPI (Cross-Program Invocation) makes fine-grained contract decomposition less practical. Second, Ethereum historically enforces a contract bytecode size limit (about 24,576 bytes / 24 KB), pushing developers to split logic. On Ethereum, calling another contract is straightforward, with context like `msg.sender` implicitly passed. On Solana, each CPI requires the caller to manually construct and pass a complete account list required by the callee's instruction. This is verbose, error-prone (e.g., missing or misordered accounts), and increases transaction size and complexity. Here's a real CPI example in our staking program calling the official Token Program to transfer tokens. + +```rust +// solana-staking/programs/solana-staking/src/instructions/stake.rs +// Transfer staking tokens from user to vault +let cpi_accounts = Transfer { + from: ctx.accounts.user_token_account.to_account_info(), + to: ctx.accounts.staking_vault.to_account_info(), + authority: ctx.accounts.user.to_account_info(), +}; +let cpi_program = ctx.accounts.token_program.to_account_info(); +let cpi_ctx = CpiContext::new(cpi_program, cpi_accounts); +token::transfer(cpi_ctx, amount)?; +``` + +To complete this transfer, we construct a `Transfer` struct with `from` (user token account), `to` (program vault), and `authority` (signer) accounts, then bundle it with the `token_program` into a `CpiContext` before calling `token::transfer`. + +Now imagine splitting staking logic across multiple programs—one for user stake data and another to update `total_staked`. A simple `stake` could require multiple CPIs, each with its own verbose account context, greatly increasing complexity, CU usage, and the chance of mistakes. + +So, to improve developer efficiency and maintainability, best practice is to implement an app or protocol's core features (e.g., a DeFi protocol's staking, lending, reward calculation) inside a single program. Use CPI only to interact with standardized external programs like the SPL Token Program. This monolithic pattern reduces CPI count, simplifies clients, and keeps logic cohesive, which is easier to audit and manage. + +### Fee Model + +Solana's fee model shares some conceptual similarities with Ethereum but differs in implementation. Ethereum uses Gas, with transactions declaring a Gas Limit and paying based on Gas Used × price. Since EIP-1559, fees comprise Base Fee (auto-adjusts with congestion) and Priority Fee, so total cost is `Gas Used × (Base Fee + Priority Fee)`. + +On Solana, execution cost is measured in Compute Units (CU). Each transaction has a CU budget; exceeding it fails the transaction, somewhat similar to Ethereum's Gas Limit. But Solana's base transaction fee doesn't depend on CU consumption; it's tied to transaction byte size and signature count. The larger the transaction, the higher the base fee, which is loosely decoupled from computational complexity. Competition for compute is expressed via Priority Fees: developers can use `ComputeBudgetProgram` to set how many microLamports to pay per million CU, incentivizing validators to prioritize their transactions, which is similar to Ethereum's Gas Price/Priority Fee. + +In other words, Solana transaction costs consist of three parts: a base fee tied to transaction size, storage costs expressed through rent, and compute pricing expressed through priority fees. The base fee is your **entry ticket**, while compute competition appears mostly in priority fees. + +```js +import { ComputeBudgetProgram, Transaction } from "@solana/web3.js"; + +const transaction = new Transaction(); + +// Request a specific compute unit limit +transaction.add( + ComputeBudgetProgram.setComputeUnitLimit({ + units: 400_000, + }) +); + +// Set a priority fee +transaction.add( + ComputeBudgetProgram.setComputeUnitPrice({ + microLamports: 100_000, + }) +); + +// ... add your main instruction here +// transaction.add(myInstruction); +``` + +### Contract Upgrades + +Upgrades are crucial to a project’s evolution, and Ethereum and Solana offer very different yet effective solutions. + +In early Ethereum, upgrading smart contracts was complex and risky. Because code and data are tightly coupled at one address, upgrading often meant deploying a new contract and migrating data, which can be complex and error-prone. The community developed mature Proxy patterns where data resides in a stable proxy contract and upgradeable logic contracts are referenced via pointers. Upgrades switch the logic implementation without changing the proxy address—now the de facto standard. + +Solana's design is simpler and more elegant: program code and state storage are naturally separated. You can redeploy new BPF bytecode to the same program ID to upgrade the program, while state accounts (outside the program) remain intact. There is no data migration needed, significantly reducing complexity and risk. However, there's a new challenge–once an account's structure and size are set, you can’t expand it in-place. If you later add new fields to a state account that was allocated with a smaller size, you’ll get data misalignment or read errors. The recommended approach is to pre-allocate unused space (`padding`) in v1 so you can safely add fields later without changing account size: + +```rust +#[account(zero_copy)] +#[repr(C)] +pub struct MyState { + pub data_field_a: u64, + pub data_field_b: bool, + // Reserve 128 bytes for future upgrade + pub _reserved: [u8; 128], +} +``` + +This way, when you need new fields, you can repurpose part of `_reserved` without changing the account size, keeping old accounts compatible with the new program. + +Also, when deploying a Solana program, you must set an upgrade authority (`upgrade authority`), which is often the deployer wallet or a multisig. This authority is the only entity that can update program bytecode. If it's compromised or removed improperly, the program could be maliciously upgraded or become immutable, so handle it with care. + +### Authorization Models: `transferFrom` vs `transfer` + +In Ethereum's ERC20 standard, transferring on behalf of a user usually takes two steps: the user calls `approve` to grant an allowance, and the authorized party (often a contract) then calls `transferFrom`. This exists because the account model distinguishes between the token holder and the executor, and the executor must submit a transaction separately. + +In Solana’s SPL Token model, this is greatly simplified. Each token account records its _authority_ explicitly. As long as the transaction includes that authority’s signature, the program can directly call `token::transfer` to move tokens—no separate `transferFrom` needed. In other words, Solana’s runtime natively supports a **who-signs-who-authorizes** model instead of relying on contracts to check a second-layer approval. + +Furthermore, Solana’s execution environment supports signature propagation across CPI: + +- If the outer transaction includes a user signature, callee programs can recognize it. +- If the caller is a PDA, `invoke_signed` lets the runtime synthesize and verify a derived signature for authorization. + +Because the runtime understands and propagates authorization at the system level, once a program has a valid signature (or PDA-derived signature), it can safely transfer on the user’s behalf. No proxy-style instruction required. + +Our staking flow uses direct user signatures without proxy or PDA authority. When the user calls `stake`, they directly authorize the program to operate their token account; the program then uses CPI `token::transfer` to move tokens into the vault—no `approve + transferFrom` needed. The example below illustrates how this works. + +```rust +pub fn stake_handler(ctx: Context, amount: u64) -> Result<()> { + let cpi_accounts = Transfer { + from: ctx.accounts.user_token_account.to_account_info(), + to: ctx.accounts.staking_vault.to_account_info(), + authority: ctx.accounts.user.to_account_info(), + }; + let cpi_program = ctx.accounts.token_program.to_account_info(); + let cpi_ctx = CpiContext::new(cpi_program, cpi_accounts); + token::transfer(cpi_ctx, amount)?; + + Ok(()) +} +``` + +Solana doesn’t need `transferFrom` because its runtime fuses _authorization_ and _execution_: if a valid signature is present in the transaction, the user has authorized the transfer without extra steps. + +### Numerical Computation + +Numeric handling on Solana also requires a shift of thinking. First, regarding precision: SPL Tokens are often 6 or 9 decimal places long, not the 18 decimal places common in ERC20. Thus, token amounts usually fit in `u64`, simplifying math and saving 8 bytes per account compared to `u128`, reducing rent costs at scale. + +When mixing multiplication and division, beware of precision loss in intermediate results. In many languages, writing `r = a / b * c` as a single expression may benefit from extended precision registers; on x86, the FPU uses 80-bit extended precision internally, only truncating to 64-bit at the end. Note that compilers may also reorder or combine operations. But if you split this into steps like `t = a / b; r = t * c;`, the intermediate result is written to memory (64-bit), then read back, causing extra precision loss. + +For integer token amounts, choose `u64/u128` to avoid floating-point issues. However, for ratios, rates, and prices, floats may be necessary, and if that is the case, be careful with intermediate precision. For example, on x86, a single expression like `r = a / b * c` might compute in 80-bit precision, only truncating at the end. Note that splitting the computation into steps as described earlier (first computing t = a / b, then computing r = t \* c) forces 64-bit truncation in between, introducing additional errors. + +## Conclusion + +This article provides experienced Ethereum developers with a detailed migration guide to Solana, helping bridge the gap between the two ecosystems. We first emphasized the core mindset shift required, then examined fundamental differences in account models, token standards, and call mechanisms. Next, we compared key tooling across the ecosystems and proposed a set of Solana best practices. By understanding and adopting these concepts and practices, developers can build high-performance decentralized applications on Solana more efficiently and safely. + +In the next article, “From Ethereum to Solana — Contracts (Part 2),” we’ll continue exploring some limitations and shortcomings in Solana development. Finally, we’ll walk through a complete staking contract example, step by step, showing how to migrate an entire Ethereum contract to Solana. Stay tuned. + +## References + +- [Moving from Ethereum Development to Solana](https://solana.com/news/evm-to-svm) +- [EVM vs. SVM: Smart Contracts](https://solana.com/developers/evm-to-svm/smart-contracts) +- [How to Migrate From Ethereum to Solana: A Guide for Devs](https://www.helius.dev/blog/how-to-migrate-from-ethereum-to-solana) +- [Basic Knowledge Needed for Migrating from EVM to Solana](https://medium.com/@easypass.inc/basic-knowledge-needed-for-migrating-from-evm-to-solana-7814b29c8bd5) +- [A Complete Guide to Solana Development for Ethereum Developers](https://solana.com/developers/evm-to-svm/complete-guide) +- [Solana Development for EVM Developers](https://www.quicknode.com/guides/solana-development/getting-started/solana-development-for-evm-developers#key-architectural-differences-between-ethereum-and-solana) +- [Verifying Programs](https://solana.com/docs/programs/verified-builds) diff --git a/articles/How to Migrate an Ethereum Protocol to Solana Contracts (Part 1)/thumb.png b/articles/How to Migrate an Ethereum Protocol to Solana Contracts (Part 1)/thumb.png new file mode 100644 index 0000000..cee4a45 Binary files /dev/null and b/articles/How to Migrate an Ethereum Protocol to Solana Contracts (Part 1)/thumb.png differ diff --git a/articles/How to Migrate an Ethereum Protocol to Solana Contracts (Part 1)/thumb_h.png b/articles/How to Migrate an Ethereum Protocol to Solana Contracts (Part 1)/thumb_h.png new file mode 100644 index 0000000..99beff9 Binary files /dev/null and b/articles/How to Migrate an Ethereum Protocol to Solana Contracts (Part 1)/thumb_h.png differ diff --git a/articles/How to Migrate an Ethereum Protocol to Solana-Preamble/README.md b/articles/How to Migrate an Ethereum Protocol to Solana-Preamble/README.md new file mode 100644 index 0000000..52637e4 --- /dev/null +++ b/articles/How to Migrate an Ethereum Protocol to Solana-Preamble/README.md @@ -0,0 +1,332 @@ +--- +published: true +title: "How to Migrate an Ethereum Protocol to Solana — Preamble" +author: + [ + "Bonnie Chen/ Full Stack Engineer", + "Bin Li/Tech Lead", + "Jimmy Zhao/ Full Stack Engineer", + "Shan Yang/Tech Lead", + "Jia Xin Liang/Backend Engineer", + "Wei Wang/Tech Lead", + ] +createTime: 2026-01-23 +categories: ["engineering"] +subCategories: ["Blockchain & Web3"] +tags: ["Solana", "Ethereum", "Smart Contract", "Solidity", "Anchor"] +landingPages: ["Blockchain-Onchain infra"] +heroColor: "#5E86E2" +thumb: "thumb.png" +thumb_h: "thumb-h.png" +intro: "A systematic introduction to the fundamental differences between Ethereum and Solana in account models, execution mechanisms, and fee systems." +--- + +## Overview + +As the Solana ecosystem matures, more and more product owners are considering migrating their Ethereum (EVM) projects to Solana to gain higher performance, lower transaction costs, and a better user experience. Our company has extensive hands-on experience in this area, having led the migration and refactoring of multiple Ethereum protocols to Solana across various industries. We understand the complexity of migration across contract architecture, data models, transaction logic, and front-backend coordination, and we've developed a systematic methodology and set of best practices to address these areas. + +To help developers systematically master the methods and practices for migrating from Ethereum to Solana, we're launching a series of articles focused on three core layers—the smart contract layer, backend services, and frontend interactions. In this series, we'll share lessons we learned from real projects, including key caveats, best practices, and typical issues encountered during migration. Additionally, we'll share case studies that demonstrate an end-to-end migration approach and implementation path along with sample code to help you get started. + +Through this series, we hope to help developers not only complete the migration, but also fully tap into Solana's high-performance potential and unique mechanisms to redesign protocols natively for Solana. + +### Article Navigation + +- [**How to Migrate an Ethereum Protocol to Solana — Preamble**](https://57blocks.com/blog/how-to-migrate-an-ethereum-protocol-to-solana-preamble?tab=engineering): A systematic introduction to the fundamental differences between Ethereum and Solana in account models, execution mechanisms, and fee systems. +- [**How to Migrate an Ethereum Protocol to Solana — Contracts ( Part 1 )**](https://57blocks.com/blog/how-to-migrate-an-ethereum-protocol-to-solana-contracts-part-1?tab=engineering): A focus on the core mindset shift and best practices for contract development from Ethereum to Solana. + +This article approaches the topic from a **system design** perspective, summarizing the core differences between EVM and Solana across four dimensions: account model, execution model, transaction structure, and fee model. Understanding these differences provides a foundational shift in how developers reason about smart contract platforms at the architectural level. + +## 1. Account Model: How Logic and Data Are Bound + +### 1.1 EVM: Logic and State as a Single Unit + +In EVM, there are two types of accounts: + +- **EOA (Externally Owned Account)**: + Controlled by a private key. It can send transactions and hold ETH, but does not contain any code. + +- **Contract Account**: + Contains executable logic and persistent storage. When a user is interacting with the contract, they simply specify its address. + +EVM follows a "logic + state bundled together" model. Each contract not only defines function logic but also carries its own internal storage. Any changes to the contract's state must be performed through its own code. This design makes contract interaction straightforward; however, because logic and state are tightly coupled, it limits modularity and composability. + +### 1.2 Solana: Decoupling Logic and Data + +Solana completely separates execution logic from data storage: + +- **Program Account** stores executable logic. It is immutable and does not hold business state. +- **Data Account** works as an independent data storage unit, explicitly defined and accessed by the program. +- **System Account/Sysvar Account** is used by the Solana runtime layer to store SOL balances and maintain chain state. + +In this model, the program only defines how data should be operated on, while the actual data (account) must be passed explicitly during execution. + +The same account may be shared across multiple programs. Different programs can jointly operate on the same piece of data. + +This results in an account model that is highly composable—logic remains lightweight, data is flexible, and parallel execution becomes possible. However, it also requires developers to explicitly specify all data dependencies when constructing instructions. + +For more details on account structure and access rules, refer to Solana's documentation: [Solana Docs: Accounts](https://solana.com/docs/core/accounts). + +## 2. Execution Model: Serial vs Parallel + +### 2.1 EVM: Single-Threaded Execution + +EVM executes transactions in a serial manner. Each transaction is processed one after another, and the global state is updated before the next transaction can run. + +Although contracts can call each other (via `call`, `delegatecall`, etc.), the overall execution still forms a linear execution chain. + +This serial model ensures state consistency, but it naturally limits throughput. + +### 2.2 Solana: Explicit Dependencies + Parallel Execution + +In Solana, a transaction consists of multiple instructions. Each instruction invokes a program and explicitly declares the accounts it needs to read or write. + +At runtime, Solana schedules execution based on account dependency rules: + +- If two instructions access different accounts, then they can be executed in parallel. +- If two instructions read the same account, then they can still run in parallel. +- If two instructions access the same account and at least one writes, then they must be executed sequentially to maintain state consistency. + +Thus, Solana's parallelism is not automatic but explicitly driven by account access patterns. This is the core reason Solana can achieve high throughput on a single chain. + +## 3. Transaction Structure: Functional vs Compositional + +### 3.1 EVM: Single-Target Invocation + +In EVM, a transaction typically targets one contract and one function. The call relationship forms a tree structure where the outer transaction triggers internal contract calls, which then execute sequentially to completion. + +### 3.2 Solana: Multi-Instruction Composition + +A Solana transaction is more like a container of instructions. + +Developers can bundle multiple Instructions in a single transaction, such as: + +- Creating an account +- Initializing stored data +- Executing business logic operations + +Each Instruction explicitly specifies the program it calls and the accounts it depends on.This structure provides much greater flexibility and enables composability across programs. + +However, it also introduces more complexity in that developers must clearly understand account layouts and access patterns when constructing transactions. + +For more details on composing transactions, see Solana's documentation: [Solana Docs: Transactions](https://solana.com/docs/core/transactions). + +## 4. Fee Model: Gas vs Compute Units + +### 4.1 EVM: Gas, Base Fee, and Priority Fee + +In EVM, transaction fees are composed of the following components: + +- **Base Fee**: Automatically adjusted by the protocol. This is the minimum required fee per unit of gas in the current block and is burned. +- **Priority Fee (Tip)**: Set by the user to incentivize validators to prioritize their transaction. This fee goes directly to the validator. +- **Max Fee**: The maximum gas price a user is willing to pay. Any unused portion is refunded. +- **Gas Limit**: The maximum amount of gas the transaction is allowed to consume. + +**Fee Calculation Formula**: + +``` +Transaction Fee = Gas Used × (Base Fee + Priority Fee) +``` + +### 4.2 Solana: Compute Units, Priority Fee, and Rent + +Solana's transaction cost structure consists of three main parts: + +#### (1) Base Fee + +- Each signature in a transaction costs 5,000 lamports (where lamports are the smallest unit of SOL, similar to wei in Ethereum). +- **Fee Allocation**: + - 50% is burned + - 50% is paid to the validator who processes the transaction +- Importantly, this fee is unrelated to transaction complexity. + +#### (2) Prioritization Fee (Optional) + +- This fee applies only when a Compute Unit Price is explicitly set. + + **Formula**: + + ``` + Prioritization Fee = Compute Units Consumed × Compute Unit Price + ``` + +- **Compute Units (CU)** are Solana's core resource measurement unit, similar to gas in EVM. + + - Default limit per transaction: 200,000 CU + - Compute Units themselves do not incur cost — fees arise only when `ComputeUnitPrice` is set. + - **Purpose**: During network congestion, users can increase priority by paying more CUs. + +- Developers can use the `ComputeBudgetProgram` to: + + - `setComputeUnitLimit`: Increase the CU (Compute Unit) limit, suitable for complex contract calls. + - `setComputeUnitPrice`: Set the prioritization fee, similar to the Gas Price in EVM. + +#### (3) Rent (Storage Cost) + +On Solana, on-chain accounts occupy storage space and storage resources are limited. To prevent users from creating excessive unused accounts that waste blockchain state, Solana implements a Rent mechanism. + +- If an account holds a sufficient SOL deposit, it avoids periodic rent deductions; this state is called **Rent-exempt**. + +- The minimum balance for rent exemption is calculated as: + + ``` + rent_exempt_minimum = lamports_per_byte_year × data_len × exemption_threshold + ``` + + where: + + - `lamports_per_byte_year` = rent per byte per year + - `exemption_threshold` = number of years exempt from rent (default: 2 years) + +- If an account balance exceeds the rent-exempt threshold, the account will not be reclaimed. +- If the balance falls below the threshold, rent must be paid, reducing the balance. If the balance is depleted, the account is deleted. +- The required minimum balance is determined programmatically using `getMinimumBalanceForRentExemption`. +- When an account is closed, the system automatically refunds the rent deposit (the previously frozen SOL), freeing the occupied storage space. + +For more details on Rent calculations, see Solana's documentation: [Solana Docs: Rent](https://docs.anza.xyz/implemented-proposals/rent). + +## 5. Core Conceptual Foundations of Solana + +Most of this article compares EVM-compatible chains, which share similar account models, execution models, transaction structure, and fee models. Solana, however, operates differently. Understanding its architecture makes the comparison more meaningful. This section introduces the key concepts that define Solana. + +### 5.1 Program + +A Program in Solana plays a role similar to a smart contract in the EVM, but it is significantly more lightweight: + +- It contains only execution logic, without its own persistent storage. +- All states must be explicitly passed in through external Data Accounts during instruction execution. +- The most commonly used development framework is Anchor, which automates serialization, account validation, and other boilerplate tasks. + +### 5.2 Account + +In Solana, all persistent states are stored in Accounts. Any data that needs to be retained across transactions must be stored in an Account. + +Every Account contains the following fields: + +| Field | Type / Unit | Description | +| ------------ | ------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------- | +| `lamports` | Integer (1 SOL = 10⁹ lamports) | Balance held by the account, used to pay transaction fees or maintain rent-exempt status. | +| `owner` | Public Key (Program ID) | The program that "owns" the account. Only this program can modify the account's data or withdraw lamports. | +| `executable` | Boolean | Indicates whether the account is a Program (true) or a Data Account (false). | +| `data` | Byte Array | The raw stored data. Its layout and interpretation are defined by the owning program. | +| `rent_epoch` | Integer | The next epoch at which rent is due. Accounts with insufficient balance may be reclaimed. If closed, the stored rent deposit is refunded. | + +In simple terms: + +**Account in Solana ≈ Storage in an EVM contract** + +### 5.3 PDA (Program Derived Address) + +A PDA (Program Derived Address) is one of the core concepts in Solana understood as a deterministic, program-controlled address. Unlike regular wallet addresses, a PDA is not derived from a private key and therefore has no signing capability on its own. Instead, it can act as a signer through a specific Program's logic, enabling secure ownership and management of data accounts. + +A PDA Account serves a role similar to a storage slot in EVM, used to persist contract state. + +#### Address Derivation + +The generation of a PDA is deterministic and depends on three factors: + +1. **Seeds (optional)** + + - Developer-defined inputs (e.g., strings, numbers, wallet addresses, or other account addresses). + - Different seed combinations produce different PDAs. + +2. **Bump Seed** + + - A one-byte value appended to the seeds. + - Ensures the generated address lies off the Ed25519 curve (i.e., cannot correspond to a private key). + - The runtime searches bump from 255 downward until a valid PDA is found. + +3. **Program ID** + - The address of the program that owns the PDA. + - The Program ID implicitly acts as the signing authority for the PDA. + +Given the same seeds + bump + Program ID, the resulting PDA is always identical, meaning both on-chain programs and front-end clients can compute it without needing to store it anywhere. + +#### Key Properties of PDA (Program Derived Address) + +Program Derived Addresses (PDAs) are a cornerstone of Solana's account model. Unlike Ethereum's smart contracts, which are inherently associated with an externally owned account, Solana separates program logic from account ownership. PDAs allow programs to securely manage accounts, enforce deterministic access control, and authorize actions without relying on user private keys. Understanding their properties is essential for building secure, composable, and predictable on-chain programs. + +- **Non-public-key nature** + + Although SDKs like `web3.js` represent PDAs using the `PublicKey` type, a PDA is not a traditional public key and has no corresponding private key. + + - PDAs exist off the Ed25519 curve, so they cannot be directly controlled by any private key. + +- **Uniqueness** + + - A PDA is bound to a specific Program, ensuring no address conflicts. + + - PDAs generated by different Programs do not interfere with each other. + +- **Can act as a signer** + + - In certain cases, a Program can use runtime APIs to allow a PDA to act as a "virtual signer" for a transaction. This enables secure authorization of data modifications without exposing any private key. + +PDAs are central to Solana's implementation of deterministic storage, keyless signing, and secure data access. They enable developers to organize on-chain data structures in a predictable, composable, and pre-deployment-free manner, distinguishing Solana from EVM. + +Furthermore, PDAs represent Solana's native account abstraction (AA): the essence of AA is that "accounts are controlled by code", which Solana implements via predictable PDA addresses and programmatic signing. + +For the complete rules on PDA generation, refer to Solana's documentation: [Solana Docs: PDA](https://solana.com/docs/core/pda). + +### 5.4 SPL (Solana Program Library) + +The Solana Program Library (SPL) is a collection of standard, audited on-chain programs maintained by the Solana Foundation. Commonly used modules include: + +- **Token Program**, which manages the creation, minting, transfer, and burning of fungible tokens and NFTs. +- **Associated Token Program**, which generates and manages Associated Token Accounts (ATA), ensuring deterministic and standard token account ownership. +- **Memo Program**, which allows adding human-readable text notes in transactions for logging or on-chain metadata. + +SPL is a standardized collection of smart contracts officially provided by Solana, analogous to the ERC standards (ERC-20, ERC-721) and the OpenZeppelin library in the EVM ecosystem. + +Source code and documentation are available on the [official SPL repository](https://github.com/solana-labs/solana-program-library). + +### 5.5 ATA (Associated Token Account) + +In Solana, a single wallet could have multiple token accounts for the same token, which can lead to difficulties in tracking, leading to fragmented funds, and potential misuse. The Associated Token Account (ATA) solves this by deterministically deriving a unique, predictable default token account from the combination of the owner's address + Mint via the Associated Token Program. Essentially, this is a token account managed by the SPL Token Program with a PDA address, which anyone can compute locally. On the front-end, before transferring or minting, the ATA is derived and created independently using `getAssociatedTokenAddressSync`. If the ATA doesn't exist, it is created (with a small SOL rent); if the ATA exists, it is used directly. This eliminates the need to search or select accounts, ensures funds consolidate into a single address, and makes interactions simpler, safer, and compliant with ecosystem standards. + +In Solana, ATA functions similarly to how ERC-20 or ERC-721 contracts track balances internally in EVM. In the EVM model, each token contract maintains a centralized ledger using a `mapping(address => uint256)` to record all addresses and balances. Solana, however, uses a distributed account-based model: each user has an independent on-chain account that stores the token balance and related information. + +### 5.6 IDL (Interface Description Language) + +The Interface Description Language (IDL) serves as the "interface specification" for a Solana program, functioning similarly to the ABI in EVM. It describes: + +- Program instructions +- Parameter types +- Return values/errors +- Events +- The structure and constraints of relevant accounts + +Using Anchor, developers can generate an IDL file that reflects the program's structure, simplifying client-side interaction with Solana programs. By combining the IDL with Anchor's TypeScript library [@coral-xyz/anchor](https://github.com/solana-foundation/anchor/tree/0e5285aecdf410fa0779b7cd09a47f235882c156/ts/packages/anchor), constructing instructions and transactions becomes much easier. + +Ideally, you can also use TypeScript types generated from the IDL, which makes program interaction more convenient. After building a program, these types can be found in the `/target/types` folder. The example we provide below uses this approach. + +#### How to obtain an IDL: + +- **Solana Explorer**: If you know the programId (e.g., `time2Z2SCnn3qYg3ULKVtdkh8YmZ5jFdKicnA1W2YnJ`), you can directly access the Explorer [here](https://explorer.solana.com/address/time2Z2SCnn3qYg3ULKVtdkh8YmZ5jFdKicnA1W2YnJ/idl) to find and copy the corresponding IDL. +- **Anchor Local Build**: If you have the program source code, run `anchor build`. This will generate a JSON-format IDL file in `/target/idl` and corresponding TypeScript types in `/target/types`. + +These mechanisms together form Solana's account-centric architecture, where logic and data are predictable, composable, and parallelizable—a fundamental difference from EVM's contract-centric architecture. + +More about IDL: [Program IDL File](https://www.anchor-lang.com/docs/basics/idl) + +## 6. Summary: Comparing the Two Paradigms + +| Comparison Dimension | EVM | Solana | +| --------------------- | ------------------------------------------ | -------------------------------- | +| Logic & Data Relation | Contract cohesion (logic + storage) | Program and accounts separated | +| Execution Model | Serial | Explicit dependencies + parallel | +| State Management | Implicit (via internal contract variables) | Explicit (passed-in accounts) | +| Call Structure | Single-target, functional | Multi-instruction, composable | +| Fee Model | Gas-based | Compute Units + Rent | +| Architectural Style | Integrated, encapsulated | Composable, modular | + +EVM resembles a state machine running around each contract. Solana, in contrast, is more like a distributed operating system, executing logic in parallel based on account dependencies. The former emphasizes encapsulation, the latter emphasizes composition. Understanding these differences is key to grasping the underlying operation of Web3 platforms. + +This article is the first in a series. Subsequent articles will delve deeper into migrating from Ethereum to Solana. If you are interested in cross-chain development or migrating from the EVM ecosystem to Solana, stay tuned for the updates! + +## References + +- [Solana Account](https://solana.com/docs/core/accounts) +- [Solana Transaction](https://solana.com/docs/core/transactions) +- [Solana PDA](https://solana.com/docs/core/pda) +- [Moving from Ethereum Development to Solana](https://solana.com/developers/evm-to-svm) +- [Anchor](https://www.anchor-lang.com/) diff --git a/articles/How to Migrate an Ethereum Protocol to Solana-Preamble/thumb-h.png b/articles/How to Migrate an Ethereum Protocol to Solana-Preamble/thumb-h.png new file mode 100644 index 0000000..f06d4f5 Binary files /dev/null and b/articles/How to Migrate an Ethereum Protocol to Solana-Preamble/thumb-h.png differ diff --git a/articles/How to Migrate an Ethereum Protocol to Solana-Preamble/thumb.png b/articles/How to Migrate an Ethereum Protocol to Solana-Preamble/thumb.png new file mode 100644 index 0000000..bcbd367 Binary files /dev/null and b/articles/How to Migrate an Ethereum Protocol to Solana-Preamble/thumb.png differ diff --git a/generated/dir.json b/generated/dir.json index 6dab84a..c89a4b8 100644 --- a/generated/dir.json +++ b/generated/dir.json @@ -42,6 +42,68 @@ "path": "articles/Image%20Search%20with%20AI%20Models/README.md", "slug": "image-search-with-ai-models" }, + { + "published": true, + "title": "How to Migrate an Ethereum Protocol to Solana — Contracts (Part 1)", + "author": [ + "Jimmy Zhao / Fullstack Engineer", + "Bin Li / Tech Lead" + ], + "createTime": "2026-01-26T00:00:00.000Z", + "categories": [ + "engineering" + ], + "tags": [ + "Solana", + "Ethereum", + "Smart Contract", + "Solidity", + "Anchor" + ], + "landingPages": [ + "Blockchain-Onchain infra" + ], + "thumb": "./thumb.png", + "thumb_h": "./thumb_h.png", + "intro": "A deep dive into the core mindset shift and best practices when moving contracts from Ethereum to Solana.", + "path": "articles/How%20to%20Migrate%20an%20Ethereum%20Protocol%20to%20Solana%20Contracts%20(Part%201)/README.md", + "slug": "how-to-migrate-an-ethereum-protocol-to-solana-contracts-part-1" + }, + { + "published": true, + "title": "How to Migrate an Ethereum Protocol to Solana — Preamble", + "author": [ + "Bonnie Chen/ Full Stack Engineer", + "Bin Li/Tech Lead", + "Jimmy Zhao/ Full Stack Engineer", + "Shan Yang/Tech Lead", + "Jia Xin Liang/Backend Engineer", + "Wei Wang/Tech Lead" + ], + "createTime": "2026-01-23T00:00:00.000Z", + "categories": [ + "engineering" + ], + "subCategories": [ + "Blockchain & Web3" + ], + "tags": [ + "Solana", + "Ethereum", + "Smart Contract", + "Solidity", + "Anchor" + ], + "landingPages": [ + "Blockchain-Onchain infra" + ], + "heroColor": "#5E86E2", + "thumb": "thumb.png", + "thumb_h": "thumb-h.png", + "intro": "A systematic introduction to the fundamental differences between Ethereum and Solana in account models, execution mechanisms, and fee systems.", + "path": "articles/How%20to%20Migrate%20an%20Ethereum%20Protocol%20to%20Solana-Preamble/README.md", + "slug": "how-to-migrate-an-ethereum-protocol-to-solana-preamble" + }, { "published": true, "title": "Improve Performance on Three.js Scenes Using Custom Meshes and BufferGeometry", diff --git a/generated/dir.min.json b/generated/dir.min.json index 3ae681e..3616c3f 100644 --- a/generated/dir.min.json +++ b/generated/dir.min.json @@ -1 +1 @@ -{"articles":[{"published":true,"title":"Image Search with AI Models","subTitle":"How to Leverage Image Models, Large Language Models, and Multimodal Models to Provide Users with the Right Results","author":["Alpha Xiang / Machine Learning Engineer","Yanqi Liu / Back-End Engineer","Anjing Wang / AI Lead"],"createTime":"2024-05-21T00:00:00.000Z","categories":["engineering"],"subCategories":["AI & Vector DBs"],"tags":["Image Search","Image Retrieval","LLM","Image Encoder","Image Embedding","OCR","Text Embedding","CLIP","Multimodal"],"landingPages":["AI-AI/ML Model Dev","Blockchai-AI agent"],"heroColor":"#7B61BB","thumb":"thumb.png","thumb_h":"thumb_h.png","intro":"Using just an image on a mobile device, the search application is designed to return matches from the database that are either identical or resemble the original uploaded image. In this blog, we describe the technology behind this powerful functionality.","top":true,"previousSlugs":["image-search-leveraging-ai-models"],"path":"articles/Image%20Search%20with%20AI%20Models/README.md","slug":"image-search-with-ai-models"},{"published":true,"title":"Improve Performance on Three.js Scenes Using Custom Meshes and BufferGeometry","author":["Andrés Díaz / Front-End Engineer"],"createTime":"2025-12-4","categories":["engineering"],"subCategories":["Developer Tools & Performance"],"tags":["Three.JS"],"thumb":"./thumb.png","thumb_h":"./thumb_h.png","intro":"We’ll explore a real-world case where it was necessary to dive into some of Three.js’s more advanced concepts to improve performance and create a smooth experience. ","path":"articles/Improve%20Performance%20on%20Three.js%20Scenes%20Using%20Custom%20Meshes%20and%20BufferGeometry/README.md","slug":"improve-performance-on-threejs-scenes-using-custom-meshes-and-buffergeometry"},{"published":true,"title":"The Rising Strategic Value of Creative in Digital Advertising","author":["Christian Karren / Research Analyst"],"createTime":"2025-12-4","categories":["engineering"],"subCategories":["AI & Vector DBs"],"tags":["Digital Advertising","Performance Marketing","Ad Creative","Generative AI"],"landingPages":["AI-AI/ML Model Dev"],"heroColor":"#8761B1","thumb":"./thumb.png","thumb_h":"./thumb_h.png","intro":"Creative has emerged as a key driver influencing success in performance marketing, and digital advertising companies are increasingly asked to facilitate the creation of advertisements. How did we get here, and what comes next?","path":"articles/The%20Rising%20Strategic%20Value%20of%20Creative%20in%20Digital%20Advertising/README.md","slug":"the-rising-strategic-value-of-creative-in-digital-advertising"},{"published":true,"title":"Web3 Intents Based Systems and How LI.FI is Pushing Cross-Chain Swaps Evolution","author":["Kamil Krupa / GTM Lead"],"createTime":"2025-10-09T00:00:00.000Z","categories":["engineering"],"subCategories":["Blockchain & Web3"],"tags":["Cross-chain transactions","Intent based swaps","Chain interoperability"],"landingPages":["Blockchain-Onchain infra"],"heroColor":"#5E86E2","thumb":"./thumb.png","thumb_h":"./thumb_h.png","intro":"How intent-based swaps revolutionize cross-chain transactions making crypto UX simple and secure.","previousSlugs":["ai-driven-workflows"],"path":"articles/Web3%20Intents%20Based%20Systems%20and%20How%20LIFI%20is%20Pushing%20Cross-Chain%20Swaps%20Evolution/README.md","slug":"web3-intents-based-systems-and-how-lifi-is-pushing-cross-chain-swaps-evolution"},{"published":true,"title":"Reactive Programming in Tokenpad (Part 2)","subTitle":"Advanced Stream Operations and Real-Time Data Management","author":["Juan E Quintero R / Tech Lead"],"createTime":"2025-09-22T00:00:00.000Z","categories":["engineering"],"subCategories":["Developer Tools & Performance"],"tags":["Reactive","Flutter","Crypto","Streams","Dart"],"landingPages":["AI-Agentic Applications"],"heroColor":"#735BB9","thumb":"./thumb.png","thumb_h":"./thumb_h.png","intro":"In Part 2, we go beyond the Observer Pattern to make Tokenpad's data truly reactive—building reusable, composable Streams, combining sources with `rxdart`, and tackling real-world pitfalls so the UI stays accurate in real time.","previousSlugs":["reactive-programming-in-tokenpad-p2"],"path":"articles/Reactive%20Programming%20in%20Tokenpad%20Part%202/README.md","slug":"reactive-programming-in-tokenpad-part-2"},{"published":true,"title":"Soroban Integration Testing Best Practices (JS)","author":["Leo Meng / Account Manager"],"createTime":"2025-09-16T00:00:00.000Z","categories":["engineering"],"subCategories":["Blockchain & Web3"],"tags":["Soroban","Stellar","Resource Usage","Smart Contract","Integration Testing"],"landingPages":["Blockchain-Onchain infra"],"heroColor":"#886FD0","thumb":"./thumb.png","thumb_h":"./thumb_h.png","intro":"This article explores our experiences and practices for writing integration tests for smart contracts on Soroban, with the aim of providing practical assistance to developers currently working on Stellar contract development.","path":"articles/Soroban%20integration%20testing%20best%20practices/README.md","slug":"soroban-integration-testing-best-practices"},{"published":true,"title":"What It Takes to Build a Payments Integration: Key Components and Considerations","author":["GuangPeng Liu / Fullstack Engineer","Ida Zhou / Backend Engineer","Hum Tan / Fullstack Engineer"],"createTime":"2025-09-05T00:00:00.000Z","heroColor":"#6480D7","thumb":"thumb.png","thumb_h":"thumb_h.png","categories":["engineering"],"subCategories":["FinTech & Payments"],"tags":["Payment","Components"],"landingPages":["AI-AI Infra and Framework"],"intro":"In today's digital economy, payment integration represents far more than just a technical implementation—it's a critical business capability that can determine the success or failure of modern digital platforms. Whether you're building an e-commerce platform, a subscription service, or a marketplace, the ability to process payments reliably, securely, and efficiently is fundamental to business operations.","path":"articles/What%20It%20Takes%20to%20Build%20a%20Payments%20Integration%3A%20Key%20Components%20and%20Considerations/README.md","slug":"what-it-takes-to-build-a-payments-integration-key-components-and-considerations"},{"published":false,"title":"AI-Driven Workflows: The Key to Operational Efficiency at Scale","author":["Traci Flitcraft"],"createTime":"2025-07-17T00:00:00.000Z","categories":["business"],"subCategories":[],"tags":["AI"],"landingPages":[],"heroColor":"#4B91E3","thumb":"./thumb.png","thumb_h":"./thumb_h.png","intro":"In the early days of any company, scrappy manual processes are almost a badge of honor. Founders take pride in knowing every detail, every customer quirk, every spreadsheet formula. But as your business grows, what once felt like “high touch” quickly turns into high friction. At 57Blocks, we've seen this transformation firsthand, both within our evolution and in the startup and enterprise clients we support. The lesson is simple: companies don't just scale by adding more people. They scale by refining their processes, embedding AI-driven workflows at the core to unlock true operational efficiency automation.","previousSlugs":["ai-driven-workflows"],"path":"articles/AI-Driven%20Workflows%20The%20Key%20to%20Operational%20Efficiency%20at%20Scale/README.md","slug":"ai-driven-workflows-the-key-to-operational-efficiency-at-scale"},{"published":true,"title":"Mastering Layer 1 Blockchain Testing: A Comprehensive Guide","author":["Jia Chen / QA Engineer","Jacqueline Zhang / QA Engineer","Tina Tang / QA Engineer","Jesse Zheng / QA Engineer"],"createTime":"2025-07-07T00:00:00.000Z","categories":["engineering"],"subCategories":["Blockchain & Web3"],"tags":["Layer 1 blockchain","Ethereum Virtual Machine (EVM)","Cosmos","Blockchain testing","GitHub Actions"],"heroColor":"#2D9FB8","thumb":"./thumb.png","thumb_h":"./thumb-h.png","intro":"As blockchain technology continues to transform industries with its promise of decentralization and transparency, the foundational layer of this technology, known as Layer 1 (L1) blockchains, plays a critical role. L1 blockchains provide the necessary infrastructure to build and operate decentralized applications, hosting the protocol and consensus layer fundamental to the entire network. Here, we describe for developers and QA testers how we approach testing L1 blockchains built with EVM and Cosmos to reduce immutability, financial exposure, systemic risks, boundary complexity, cryptoeconomic attacks, and adversarial environments.","path":"articles/Mastering%20Layer%201%20Blockchain%20Testing%3A%20A%20Comprehensive%20Guide/README.md","slug":"mastering-layer-1-blockchain-testing-a-comprehensive-guide"},{"published":true,"title":"Code to Cash: The Evolving Landscape of Payments","author":["GuangPeng Liu / Fullstack Engineer","Ida Zhou / Backend Engineer","Hum Tan / Fullstack Engineer"],"createTime":"2025-06-23T00:00:00.000Z","categories":["engineering"],"subCategories":["FinTech & Payments"],"tags":["Web2","FinTech"],"heroColor":"#5E76D5","thumb":"thumb.png","thumb_h":"thumb_h.png","intro":"This comprehensive guide explores the rapidly evolving payments landscape, offering developers strategic insights on implementing payment processors, navigating modern trends, and seamlessly integrating platforms like Stripe and PayPal into web applications.","path":"articles/Code%20to%20Cash%3A%20Expert%20Insights%20on%20Implementing%20Payment%20Processors%20in%20Your%20Web%20App/README.md","slug":"code-to-cash-expert-insights-on-implementing-payment-processors-in-your-web-app"},{"published":true,"title":"Drive iOS App Downloads with Clip","author":["Eric Qi / iOS Engineer"],"createTime":"2025-03-25T00:00:00.000Z","categories":["engineering"],"subCategories":["App Growth & Delivery"],"tags":["App Clip","iOS","App","App Downloads"],"heroColor":"#48AC9A","thumb":"ArticleImage.png","thumb_h":"ArticleImage_h.png","landingPages":["AI-Agentic Applications"],"intro":"Excited to use App Clips to help promote your app? In this article, a case study illustrates how App Clips can be used as a promotional tool to drive app downloads and engagement.","path":"articles/Drive%20iOS%20App%20Downloads%20with%20Clip/README.md","slug":"drive-ios-app-downloads-with-clip"},{"published":true,"title":"Deep Dive into Resource Limitations in Solana Development — CU Edition","author":["Jimmy Zhao / Fullstack Engineer"],"createTime":"2025-02-20T00:00:00.000Z","categories":["engineering"],"subCategories":["Blockchain & Web3"],"tags":["Web3","Blockchain","Solana","Resource Limitation","Compute Unit"],"landingPages":["Blockchain-Onchain infra"],"heroColor":"#7F6DCD","thumb":"thumb.jpg","thumb_h":"thumb_h.jpg","intro":"Explore how resource limitations, specifically Compute Unit (CU) restrictions, affect Solana program development.","path":"articles/Deep%20Dive%20into%20Resource%20Limitations%20in%20Solana%20Development%20CU%20Edition/README.md","slug":"deep-dive-into-resource-limitations-in-solana-development-cu-edition"},{"published":true,"title":"Exploring Account Abstraction in Ethereum: Building and Optimizing Smart Wallets with Dynamic and Alchemy","author":["Zewei Zhang / Front-End Engineer"],"createTime":"2025-01-13T00:00:00.000Z","categories":["engineering"],"subCategories":["Blockchain & Web3"],"tags":["Web3","Account Abstraction","Wallet","Dynamic","Alchemy"],"landingPages":["Blockchain-Defi Protocols"],"heroColor":"#656ACE","thumb":"thumb.png","thumb_h":"thumb_h.png","intro":"Discover how Account Abstraction (AA) using Dynamic and Alchemy can be used to build and optimize smart wallets. This article discusses AA's origins, workflow, advantages, and disadvantages. The demo and front-end code examples provide practical, tangible guidance for developers to implement AA in their projects or products immediately.","path":"articles/Exploration%20of%20The%20Web3%20Account%20Abstraction/README.md","slug":"exploration-of-the-web3-account-abstraction"},{"published":true,"title":"Blockchain Encryption Technology: A Critical Defense for Protecting Digital Assets","author":["Bonnie Chen/ Front-End Engineer"],"createTime":"2025-01-10T00:00:00.000Z","categories":["engineering"],"subCategories":["Blockchain & Web3"],"tags":["Blockchain","Encryption"],"landingPages":["Blockchain-Defi Protocols"],"heroColor":"#429C9A","thumb":"thumb.png","thumb_h":"thumb-h.png","intro":"The rise of blockchain technology has sparked widespread concern for the security of digital assets. Here, you will find the information you need to navigate this space to understand and assess the core encryption technologies used in blockchain, identify potential security risks, and apply these encryption methods to enhance system security and ensure the safety of data and transactions.","path":"articles/Blockchain%20Encryption%20Technology/README.md","slug":"blockchain-encryption-technology"},{"published":true,"title":"Frontend Performance Optimization","author":["Bonnie Chen/ Front-End Engineer"],"createTime":"2024-09-18T00:00:00.000Z","categories":["engineering"],"subCategories":["Developer Tools & Performance"],"tags":["Frontend","Performance"],"landingPages":["Blockchain-dApps"],"heroColor":"#0894BB","thumb":"thumb.png","thumb_h":"thumb_h.png","intro":"If your site is loading slowly, what can you do to troubleshoot and fix what's causing those long page load times? Here, we provide a way to approach frontend troubleshooting and strategies to improve page load results. To help visualize how page loading works, we explain the page load journey including associated metrics for each step. Read on to discover how to improve your frontend site experience using seven Web Vitals (some of which are Core Metrics) and ten optimization strategies.","path":"articles/Frontend%20Performance%20Optimization/README.md","slug":"frontend-performance-optimization"},{"published":true,"title":"Get a Print Quote in Seconds - Not Weeks","subTitle":"When Thousands of Data Points Converge to a Decision Point in Less Than Three Seconds","author":["Yanqi Liu / Back-End Engineer","Teki Yang / Tech Lead"],"createTime":"2024-07-26T00:00:00.000Z","categories":["engineering"],"subCategories":["Developer Tools & Performance"],"tags":["B2B","Multi-tenancy","Parallel Computing","Microservices Architecture"],"landingPages":["AI-Agentic Applications"],"heroColor":"#45A587","thumb":"./thumb.png","thumb_h":"./thumb_h.png","intro":"How do you approach creating a system that finds the right supplier and provides a price in less than three seconds using hundreds of data points? By approaching this system as an ERP system in the cloud, we were able to make the process fast and low cost. Here we share how we did it. ","path":"articles/Get%20a%20Print%20Quote%20in%20Seconds%20-%20Not%20Weeks/README.md","slug":"get-a-print-quote-in-seconds-not-weeks"},{"published":true,"title":"What Makes a Good Vector Database? Comparing Pinecone and LanceDB","author":["Alex Hu / Machine Learning Engineer","Steven Zhang / Back-End Engineer","Anjing Wang / AI Lead"],"createTime":"2024-05-22T00:00:00.000Z","categories":["engineering"],"subCategories":["AI & Vector DBs"],"tags":["Vector Database","Pinecone","LanceDB"],"landingPages":["AI-Data Engineering"],"heroColor":"#3D9AB6","thumb":"./thumb.png","thumb_h":"./thumb_h.png","intro":"Which vector database to use? It depends. Based on our experiences, there is no one-size-fits-all \"best\" database. Instead, a superior vector database is well-matched with its use case, meeting the unique requirements of that scenario. Our comparative analysis offers a promising path to discovering the ideal database for your specific needs.","previousSlugs":["what-makes-a-good-vector-database"],"path":"articles/What%20Makes%20a%20Good%20Vector%20Database%3F%20Comparing%20Pinecone%20and%20LanceDB/README.md","slug":"what-makes-a-good-vector-database-comparing-pinecone-and-lancedb"},{"published":true,"title":"How to Use LLMs to Extract Document Information","author":["Carvin Li / Machine Learning Engineer","Anjing Wang / AI Lead"],"createTime":"2024-05-21T00:00:00.000Z","categories":["engineering"],"subCategories":["AI & Vector DBs"],"tags":["Information Extraction","LLM"],"landingPages":["AI-Data Engineering"],"heroColor":"#4A9C98","thumb":"thumb.png","thumb_h":"thumb_h.png","intro":"Today, we are pioneering a new approach to information extraction (IE) from volumes of academic papers. Traditional IE methods, with their reliance on labor-intensive handcrafted rules and patterns, often struggle to generalize across diverse domains and languages. In contrast, we are harnessing the power of Large Language Models (LLMs) from GPT to Claude to complete IE from these documents and compare their performance. We're excited to share our innovative approach in the field of information extraction.","previousSlugs":["document-information-extraction-with-large-language-models"],"path":"articles/How%20to%20Use%20LLMs%20to%20Extract%20Document%20Information/README.md","slug":"how-to-use-llms-to-extract-document-information"},{"published":true,"title":"How to Use Gradle to Optimize Android Development","author":["Rafael Ruiz / Android Engineer"],"createTime":"2024-05-09T00:00:00.000Z","categories":["engineering"],"subCategories":["Developer Tools & Performance"],"tags":["Mobile","Android"],"landingPages":["AI-AI Infra and Framework"],"heroColor":"#3DA497","thumb":"./thumb.png","thumb_h":"./thumb_h.png","intro":"Dependency conflicts, version compatibility, and maintaining a clean dependency tree can pose challenges in Android development. However, by harnessing the power of Gradle and Dependency Injection (DI), you can navigate these hurdles with confidence. These tools ensure a smooth process and maintain a modular architecture that follows the principles of Clean Architecture. Read how we have successfully achieved this on our projects, and how you can too.","previousSlugs":["overcoming-challenges-in-android-gradle-dependency-management"],"path":"articles/How%20to%20Use%20Gradle%20to%20Optimize%20Android%20Development/README.md","slug":"how-to-use-gradle-to-optimize-android-development"},{"published":true,"title":"Make Releases Manageable with \"Shipping As Small As Possible\"","author":["Yongzhi Yang / Back-End Engineer, Team Lead"],"createTime":"2024-05-09T00:00:00.000Z","categories":["engineering"],"subCategories":["Developer Tools & Performance"],"tags":["CI/CD","Workflow"],"landingPages":["AI-AI Infra and Framework"],"heroColor":"#5B6FBE","thumb":"./thumb.png","thumb_h":"./thumb_h.png","intro":"If you're finding it challenging to release complex features while adhering to the principles of Continuous Integration and Continuous Deployment (CI/CD), we're excited to share our proven approach. By breaking down large features into manageable components, we can relieve the burden of managing these large features, ensuring smoother data management and migration, and minimizing disruptions to dependent clients. This approach also supports an agile and iterative deployment process, enhancing stability and the user experience.","previousSlugs":["shipping-as-small-as-possible","make-release-manageable-with-shipping-as-small-as-possible"],"path":"articles/Make%20Releases%20Manageable%20with%20%22Shipping%20As%20Small%20As%20Possible%22/README.md","slug":"make-releases-manageable-with-shipping-as-small-as-possible"},{"published":true,"title":"Inside Story: How We Approach QA","author":["Jia Chen / QA Engineer","Martha Luo / QA Engineer"],"createTime":"2024-05-07T00:00:00.000Z","categories":["engineering"],"subCategories":["QA & Testing"],"tags":["QA strategy","CI","Automation Framework"],"landingPages":["Blockchain-Onchain infra"],"heroColor":"#329ECC","thumb":"./thumb.png","thumb_h":"./thumb_h.png","intro":"Our Quality Assurance (QA) team plays a pivotal role in ensuring the quality and excellence of our software. We are dedicated to enhancing software quality, team performance, and overall project delivery. This article shares the QA strategies we employ for our projects. We'll also demonstrate how embracing these methods can mitigate difficulties and improve results and provide you with the assurance that our software is of the highest quality.","previousSlugs":["57blocks-testing-best-practices"],"path":"articles/Inside%20Story%3A%20How%20We%20Approach%20QA/README.md","slug":"inside-story-how-we-approach-qa"},{"published":true,"title":"Our Guide to Modern Front-End Build Pipelines","author":["Andy Lai / Fullstack Engineer"],"createTime":"2024-04-23T00:00:00.000Z","categories":["engineering"],"subCategories":["Developer Tools & Performance"],"tags":["JavaScript Framework","React","Webpack"],"landingPages":["QA & Testing"],"heroColor":"#4996F1","thumb":"https://s3.amazonaws.com/assets.57blocks.io/cms_uploads/illustration_cup_an_laptop_e12de970e5.png","thumb_h":"./thumb_h.png","intro":"Feeling overwhelmed by the number of tools available for your oprganization's front-end build pipeline? Don't worry. We're sharing all we've learned about these tools while working on our projects and summarized it here. This comprehensive guide is designed to provide you with the knowledge and confidence to navigate the complexities of modern front-end development, mitigating difficulties and improving results.","previousSlugs":["modernizing-front-end-build-pipelines"],"path":"articles/Our%20Guide%20to%20Modern%20Front-End%20Build%20Pipelines/README.md","slug":"our-guide-to-modern-front-end-build-pipelines"},{"published":true,"title":"Getting Started with Reactive Programming","subTitle":"Tokenpad: A Case Study in Displaying Real-Time Data","author":["Juan E Quintero R / Tech Lead"],"createTime":"2024-04-22T00:00:00.000Z","categories":["engineering"],"subCategories":["Developer Tools & Performance"],"tags":["Reactive","Flutter","Crypto"],"landingPages":["AI-Agentic Applications"],"heroColor":"#735BB9","thumb":"https://s3.amazonaws.com/assets.57blocks.io/cms_uploads/illustration_tokenpad_65aea3b800.png","thumb_h":"./thumb_h.png","intro":"Users expect to see real-time data while using apps and don't want to refresh the screen. This is achieved by using Reactive Programming. In this article, you'll explore why Reactive Programming exists and how it enables apps to update with new data in real time.","previousSlugs":["reactive-programming-in-tokenpad"],"path":"articles/Getting%20Started%20with%20Reactive%20Programming/README.md","slug":"getting-started-with-reactive-programming"},{"published":true,"title":"Boost Traffic and Leads with Programmatic SEO","author":["Shi Chen / Product Manager"],"createTime":"2024-04-21T00:00:00.000Z","categories":["engineering"],"subCategories":["App Growth & Delivery"],"tags":["SEO","Growth","Alternative Investment"],"heroColor":"#39A0A0","thumb":"https://s3.amazonaws.com/assets.57blocks.io/cms_uploads/illustration_seo_db9bc06b49.png","thumb_h":"./thumb_h.png","intro":"You may have heard that programmatic SEO could boost site traffic from search engines and increase leads. However, considering the complexities of implementation can be intimidating. In this blog, we describe our design and client collaboration process, along with our findings and we outline the numerous client benefits after launch.","previousSlugs":["maximizing-online-visibility-the-power-of-programmatic-seo-for-boosting-search-traffic-and-leads"],"path":"articles/Boost%20Traffic%20and%20Leads%20with%20Programmatic%20SEO/README.md","slug":"boost-traffic-and-leads-with-programmatic-seo"},{"published":true,"title":"Image Quality Assessment Using Machine Learning","author":["Damon Wang / Android Engineer","Roy Xie / Tech Lead"],"createTime":"2024-04-20T00:00:00.000Z","categories":["engineering"],"subCategories":["AI & Vector DBs"],"tags":["Image Quality","CNN","OpenCV"],"landingPages":["AI-AI/ML Model Dev","Blockchai-AI agent"],"heroColor":"#4996F1","thumb":"https://s3.amazonaws.com/assets.57blocks.io/cms_uploads/illustration_blue_squares_c1bbaab97b.png","thumb_h":"./thumb_h.png","intro":"Image Quality Assessment (IQA), specifically Objective Blind or no-reference IQA, is a crucial function in determining image fidelity or the quality of image accuracy. Further, IQA helps maintain the integrity of visual data, ensuring its accurate representation. In this article, we share an analysis of the best machine learning models that support IQA, including BRISQUE, DIQA, NIMA and OpenCV. We will delve deeper into their operations, the challenges and advantages, and their significance in the ever-evolving field of image quality assessment.","previousSlugs":["image-quality-assessment"],"path":"articles/Image%20Quality%20Assessment%20Using%20Machine%20Learning/README.md","slug":"image-quality-assessment-using-machine-learning"},{"published":true,"title":"How to QA Smart Contracts on Blockchain","author":["Lily Hu / Smart Contract Engineer"],"createTime":"2024-04-19T00:00:00.000Z","categories":["engineering"],"subCategories":["QA & Testing"],"tags":["Smart Contract","Web3","QA"],"landingPages":["Blockchain-Onchain infra"],"heroColor":"#795ECA","thumb":"./thumb.png","thumb_h":"./thumb_h.png","intro":"Deploying a smart contract on the public blockchain is a significant milestone but also fraught with risk. Blockchain technology's immutability means that any flaws in the contract's code can have irreversible consequences. In this guide, we will walk you through a systematic and detailed approach to ensuring that your smart contract functions as intended, remains secure against malicious attacks, and is optimized for performance and cost-effectiveness.","previousSlugs":["smart-contract-development-a-step-by-step-quality-assurance-guide"],"path":"articles/How%20to%20QA%20Smart%20Contracts%20on%20Blockchain/README.md","slug":"how-to-qa-smart-contracts-on-blockchain"},{"published":true,"title":"Guide to Web3 and dApp Infrastructure","author":["Wei Wang / Tech Lead"],"createTime":"2024-04-18T00:00:00.000Z","categories":["engineering"],"subCategories":["Blockchain & Web3"],"tags":["Smart Contract","Web3","Architecture","Dapp"],"landingPages":["Blockchain-dApps"],"heroColor":"#2CA9CA","thumb":"./thumb.png","thumb_h":"./thumb_h.png","intro":"We created this guide to help people new to Web3 and the dApp infrastructures use this technology in their organizations. The design of Web3 apps is much more decentralized than that of Web2. New services are constantly appearing to make building and running these projects easier and safer. Engineers must know how each part works to create effective Web3 apps. We describe this here.","previousSlugs":["the-building-blocks-of-web3-a-deep-dive-into-dapp-infrastructure"],"path":"articles/Guide%20to%20Web3%20and%20dApp%20Infrastructure/README.md","slug":"guide-to-web3-and-dapp-infrastructure"}]} \ No newline at end of file +{"articles":[{"published":true,"title":"Image Search with AI Models","subTitle":"How to Leverage Image Models, Large Language Models, and Multimodal Models to Provide Users with the Right Results","author":["Alpha Xiang / Machine Learning Engineer","Yanqi Liu / Back-End Engineer","Anjing Wang / AI Lead"],"createTime":"2024-05-21T00:00:00.000Z","categories":["engineering"],"subCategories":["AI & Vector DBs"],"tags":["Image Search","Image Retrieval","LLM","Image Encoder","Image Embedding","OCR","Text Embedding","CLIP","Multimodal"],"landingPages":["AI-AI/ML Model Dev","Blockchai-AI agent"],"heroColor":"#7B61BB","thumb":"thumb.png","thumb_h":"thumb_h.png","intro":"Using just an image on a mobile device, the search application is designed to return matches from the database that are either identical or resemble the original uploaded image. In this blog, we describe the technology behind this powerful functionality.","top":true,"previousSlugs":["image-search-leveraging-ai-models"],"path":"articles/Image%20Search%20with%20AI%20Models/README.md","slug":"image-search-with-ai-models"},{"published":true,"title":"How to Migrate an Ethereum Protocol to Solana — Contracts (Part 1)","author":["Jimmy Zhao / Fullstack Engineer","Bin Li / Tech Lead"],"createTime":"2026-01-26T00:00:00.000Z","categories":["engineering"],"tags":["Solana","Ethereum","Smart Contract","Solidity","Anchor"],"landingPages":["Blockchain-Onchain infra"],"thumb":"./thumb.png","thumb_h":"./thumb_h.png","intro":"A deep dive into the core mindset shift and best practices when moving contracts from Ethereum to Solana.","path":"articles/How%20to%20Migrate%20an%20Ethereum%20Protocol%20to%20Solana%20Contracts%20(Part%201)/README.md","slug":"how-to-migrate-an-ethereum-protocol-to-solana-contracts-part-1"},{"published":true,"title":"How to Migrate an Ethereum Protocol to Solana — Preamble","author":["Bonnie Chen/ Full Stack Engineer","Bin Li/Tech Lead","Jimmy Zhao/ Full Stack Engineer","Shan Yang/Tech Lead","Jia Xin Liang/Backend Engineer","Wei Wang/Tech Lead"],"createTime":"2026-01-23T00:00:00.000Z","categories":["engineering"],"subCategories":["Blockchain & Web3"],"tags":["Solana","Ethereum","Smart Contract","Solidity","Anchor"],"landingPages":["Blockchain-Onchain infra"],"heroColor":"#5E86E2","thumb":"thumb.png","thumb_h":"thumb-h.png","intro":"A systematic introduction to the fundamental differences between Ethereum and Solana in account models, execution mechanisms, and fee systems.","path":"articles/How%20to%20Migrate%20an%20Ethereum%20Protocol%20to%20Solana-Preamble/README.md","slug":"how-to-migrate-an-ethereum-protocol-to-solana-preamble"},{"published":true,"title":"Improve Performance on Three.js Scenes Using Custom Meshes and BufferGeometry","author":["Andrés Díaz / Front-End Engineer"],"createTime":"2025-12-4","categories":["engineering"],"subCategories":["Developer Tools & Performance"],"tags":["Three.JS"],"thumb":"./thumb.png","thumb_h":"./thumb_h.png","intro":"We’ll explore a real-world case where it was necessary to dive into some of Three.js’s more advanced concepts to improve performance and create a smooth experience. ","path":"articles/Improve%20Performance%20on%20Three.js%20Scenes%20Using%20Custom%20Meshes%20and%20BufferGeometry/README.md","slug":"improve-performance-on-threejs-scenes-using-custom-meshes-and-buffergeometry"},{"published":true,"title":"The Rising Strategic Value of Creative in Digital Advertising","author":["Christian Karren / Research Analyst"],"createTime":"2025-12-4","categories":["engineering"],"subCategories":["AI & Vector DBs"],"tags":["Digital Advertising","Performance Marketing","Ad Creative","Generative AI"],"landingPages":["AI-AI/ML Model Dev"],"heroColor":"#8761B1","thumb":"./thumb.png","thumb_h":"./thumb_h.png","intro":"Creative has emerged as a key driver influencing success in performance marketing, and digital advertising companies are increasingly asked to facilitate the creation of advertisements. How did we get here, and what comes next?","path":"articles/The%20Rising%20Strategic%20Value%20of%20Creative%20in%20Digital%20Advertising/README.md","slug":"the-rising-strategic-value-of-creative-in-digital-advertising"},{"published":true,"title":"Web3 Intents Based Systems and How LI.FI is Pushing Cross-Chain Swaps Evolution","author":["Kamil Krupa / GTM Lead"],"createTime":"2025-10-09T00:00:00.000Z","categories":["engineering"],"subCategories":["Blockchain & Web3"],"tags":["Cross-chain transactions","Intent based swaps","Chain interoperability"],"landingPages":["Blockchain-Onchain infra"],"heroColor":"#5E86E2","thumb":"./thumb.png","thumb_h":"./thumb_h.png","intro":"How intent-based swaps revolutionize cross-chain transactions making crypto UX simple and secure.","previousSlugs":["ai-driven-workflows"],"path":"articles/Web3%20Intents%20Based%20Systems%20and%20How%20LIFI%20is%20Pushing%20Cross-Chain%20Swaps%20Evolution/README.md","slug":"web3-intents-based-systems-and-how-lifi-is-pushing-cross-chain-swaps-evolution"},{"published":true,"title":"Reactive Programming in Tokenpad (Part 2)","subTitle":"Advanced Stream Operations and Real-Time Data Management","author":["Juan E Quintero R / Tech Lead"],"createTime":"2025-09-22T00:00:00.000Z","categories":["engineering"],"subCategories":["Developer Tools & Performance"],"tags":["Reactive","Flutter","Crypto","Streams","Dart"],"landingPages":["AI-Agentic Applications"],"heroColor":"#735BB9","thumb":"./thumb.png","thumb_h":"./thumb_h.png","intro":"In Part 2, we go beyond the Observer Pattern to make Tokenpad's data truly reactive—building reusable, composable Streams, combining sources with `rxdart`, and tackling real-world pitfalls so the UI stays accurate in real time.","previousSlugs":["reactive-programming-in-tokenpad-p2"],"path":"articles/Reactive%20Programming%20in%20Tokenpad%20Part%202/README.md","slug":"reactive-programming-in-tokenpad-part-2"},{"published":true,"title":"Soroban Integration Testing Best Practices (JS)","author":["Leo Meng / Account Manager"],"createTime":"2025-09-16T00:00:00.000Z","categories":["engineering"],"subCategories":["Blockchain & Web3"],"tags":["Soroban","Stellar","Resource Usage","Smart Contract","Integration Testing"],"landingPages":["Blockchain-Onchain infra"],"heroColor":"#886FD0","thumb":"./thumb.png","thumb_h":"./thumb_h.png","intro":"This article explores our experiences and practices for writing integration tests for smart contracts on Soroban, with the aim of providing practical assistance to developers currently working on Stellar contract development.","path":"articles/Soroban%20integration%20testing%20best%20practices/README.md","slug":"soroban-integration-testing-best-practices"},{"published":true,"title":"What It Takes to Build a Payments Integration: Key Components and Considerations","author":["GuangPeng Liu / Fullstack Engineer","Ida Zhou / Backend Engineer","Hum Tan / Fullstack Engineer"],"createTime":"2025-09-05T00:00:00.000Z","heroColor":"#6480D7","thumb":"thumb.png","thumb_h":"thumb_h.png","categories":["engineering"],"subCategories":["FinTech & Payments"],"tags":["Payment","Components"],"landingPages":["AI-AI Infra and Framework"],"intro":"In today's digital economy, payment integration represents far more than just a technical implementation—it's a critical business capability that can determine the success or failure of modern digital platforms. Whether you're building an e-commerce platform, a subscription service, or a marketplace, the ability to process payments reliably, securely, and efficiently is fundamental to business operations.","path":"articles/What%20It%20Takes%20to%20Build%20a%20Payments%20Integration%3A%20Key%20Components%20and%20Considerations/README.md","slug":"what-it-takes-to-build-a-payments-integration-key-components-and-considerations"},{"published":false,"title":"AI-Driven Workflows: The Key to Operational Efficiency at Scale","author":["Traci Flitcraft"],"createTime":"2025-07-17T00:00:00.000Z","categories":["business"],"subCategories":[],"tags":["AI"],"landingPages":[],"heroColor":"#4B91E3","thumb":"./thumb.png","thumb_h":"./thumb_h.png","intro":"In the early days of any company, scrappy manual processes are almost a badge of honor. Founders take pride in knowing every detail, every customer quirk, every spreadsheet formula. But as your business grows, what once felt like “high touch” quickly turns into high friction. At 57Blocks, we've seen this transformation firsthand, both within our evolution and in the startup and enterprise clients we support. The lesson is simple: companies don't just scale by adding more people. They scale by refining their processes, embedding AI-driven workflows at the core to unlock true operational efficiency automation.","previousSlugs":["ai-driven-workflows"],"path":"articles/AI-Driven%20Workflows%20The%20Key%20to%20Operational%20Efficiency%20at%20Scale/README.md","slug":"ai-driven-workflows-the-key-to-operational-efficiency-at-scale"},{"published":true,"title":"Mastering Layer 1 Blockchain Testing: A Comprehensive Guide","author":["Jia Chen / QA Engineer","Jacqueline Zhang / QA Engineer","Tina Tang / QA Engineer","Jesse Zheng / QA Engineer"],"createTime":"2025-07-07T00:00:00.000Z","categories":["engineering"],"subCategories":["Blockchain & Web3"],"tags":["Layer 1 blockchain","Ethereum Virtual Machine (EVM)","Cosmos","Blockchain testing","GitHub Actions"],"heroColor":"#2D9FB8","thumb":"./thumb.png","thumb_h":"./thumb-h.png","intro":"As blockchain technology continues to transform industries with its promise of decentralization and transparency, the foundational layer of this technology, known as Layer 1 (L1) blockchains, plays a critical role. L1 blockchains provide the necessary infrastructure to build and operate decentralized applications, hosting the protocol and consensus layer fundamental to the entire network. Here, we describe for developers and QA testers how we approach testing L1 blockchains built with EVM and Cosmos to reduce immutability, financial exposure, systemic risks, boundary complexity, cryptoeconomic attacks, and adversarial environments.","path":"articles/Mastering%20Layer%201%20Blockchain%20Testing%3A%20A%20Comprehensive%20Guide/README.md","slug":"mastering-layer-1-blockchain-testing-a-comprehensive-guide"},{"published":true,"title":"Code to Cash: The Evolving Landscape of Payments","author":["GuangPeng Liu / Fullstack Engineer","Ida Zhou / Backend Engineer","Hum Tan / Fullstack Engineer"],"createTime":"2025-06-23T00:00:00.000Z","categories":["engineering"],"subCategories":["FinTech & Payments"],"tags":["Web2","FinTech"],"heroColor":"#5E76D5","thumb":"thumb.png","thumb_h":"thumb_h.png","intro":"This comprehensive guide explores the rapidly evolving payments landscape, offering developers strategic insights on implementing payment processors, navigating modern trends, and seamlessly integrating platforms like Stripe and PayPal into web applications.","path":"articles/Code%20to%20Cash%3A%20Expert%20Insights%20on%20Implementing%20Payment%20Processors%20in%20Your%20Web%20App/README.md","slug":"code-to-cash-expert-insights-on-implementing-payment-processors-in-your-web-app"},{"published":true,"title":"Drive iOS App Downloads with Clip","author":["Eric Qi / iOS Engineer"],"createTime":"2025-03-25T00:00:00.000Z","categories":["engineering"],"subCategories":["App Growth & Delivery"],"tags":["App Clip","iOS","App","App Downloads"],"heroColor":"#48AC9A","thumb":"ArticleImage.png","thumb_h":"ArticleImage_h.png","landingPages":["AI-Agentic Applications"],"intro":"Excited to use App Clips to help promote your app? In this article, a case study illustrates how App Clips can be used as a promotional tool to drive app downloads and engagement.","path":"articles/Drive%20iOS%20App%20Downloads%20with%20Clip/README.md","slug":"drive-ios-app-downloads-with-clip"},{"published":true,"title":"Deep Dive into Resource Limitations in Solana Development — CU Edition","author":["Jimmy Zhao / Fullstack Engineer"],"createTime":"2025-02-20T00:00:00.000Z","categories":["engineering"],"subCategories":["Blockchain & Web3"],"tags":["Web3","Blockchain","Solana","Resource Limitation","Compute Unit"],"landingPages":["Blockchain-Onchain infra"],"heroColor":"#7F6DCD","thumb":"thumb.jpg","thumb_h":"thumb_h.jpg","intro":"Explore how resource limitations, specifically Compute Unit (CU) restrictions, affect Solana program development.","path":"articles/Deep%20Dive%20into%20Resource%20Limitations%20in%20Solana%20Development%20CU%20Edition/README.md","slug":"deep-dive-into-resource-limitations-in-solana-development-cu-edition"},{"published":true,"title":"Exploring Account Abstraction in Ethereum: Building and Optimizing Smart Wallets with Dynamic and Alchemy","author":["Zewei Zhang / Front-End Engineer"],"createTime":"2025-01-13T00:00:00.000Z","categories":["engineering"],"subCategories":["Blockchain & Web3"],"tags":["Web3","Account Abstraction","Wallet","Dynamic","Alchemy"],"landingPages":["Blockchain-Defi Protocols"],"heroColor":"#656ACE","thumb":"thumb.png","thumb_h":"thumb_h.png","intro":"Discover how Account Abstraction (AA) using Dynamic and Alchemy can be used to build and optimize smart wallets. This article discusses AA's origins, workflow, advantages, and disadvantages. The demo and front-end code examples provide practical, tangible guidance for developers to implement AA in their projects or products immediately.","path":"articles/Exploration%20of%20The%20Web3%20Account%20Abstraction/README.md","slug":"exploration-of-the-web3-account-abstraction"},{"published":true,"title":"Blockchain Encryption Technology: A Critical Defense for Protecting Digital Assets","author":["Bonnie Chen/ Front-End Engineer"],"createTime":"2025-01-10T00:00:00.000Z","categories":["engineering"],"subCategories":["Blockchain & Web3"],"tags":["Blockchain","Encryption"],"landingPages":["Blockchain-Defi Protocols"],"heroColor":"#429C9A","thumb":"thumb.png","thumb_h":"thumb-h.png","intro":"The rise of blockchain technology has sparked widespread concern for the security of digital assets. Here, you will find the information you need to navigate this space to understand and assess the core encryption technologies used in blockchain, identify potential security risks, and apply these encryption methods to enhance system security and ensure the safety of data and transactions.","path":"articles/Blockchain%20Encryption%20Technology/README.md","slug":"blockchain-encryption-technology"},{"published":true,"title":"Frontend Performance Optimization","author":["Bonnie Chen/ Front-End Engineer"],"createTime":"2024-09-18T00:00:00.000Z","categories":["engineering"],"subCategories":["Developer Tools & Performance"],"tags":["Frontend","Performance"],"landingPages":["Blockchain-dApps"],"heroColor":"#0894BB","thumb":"thumb.png","thumb_h":"thumb_h.png","intro":"If your site is loading slowly, what can you do to troubleshoot and fix what's causing those long page load times? Here, we provide a way to approach frontend troubleshooting and strategies to improve page load results. To help visualize how page loading works, we explain the page load journey including associated metrics for each step. Read on to discover how to improve your frontend site experience using seven Web Vitals (some of which are Core Metrics) and ten optimization strategies.","path":"articles/Frontend%20Performance%20Optimization/README.md","slug":"frontend-performance-optimization"},{"published":true,"title":"Get a Print Quote in Seconds - Not Weeks","subTitle":"When Thousands of Data Points Converge to a Decision Point in Less Than Three Seconds","author":["Yanqi Liu / Back-End Engineer","Teki Yang / Tech Lead"],"createTime":"2024-07-26T00:00:00.000Z","categories":["engineering"],"subCategories":["Developer Tools & Performance"],"tags":["B2B","Multi-tenancy","Parallel Computing","Microservices Architecture"],"landingPages":["AI-Agentic Applications"],"heroColor":"#45A587","thumb":"./thumb.png","thumb_h":"./thumb_h.png","intro":"How do you approach creating a system that finds the right supplier and provides a price in less than three seconds using hundreds of data points? By approaching this system as an ERP system in the cloud, we were able to make the process fast and low cost. Here we share how we did it. ","path":"articles/Get%20a%20Print%20Quote%20in%20Seconds%20-%20Not%20Weeks/README.md","slug":"get-a-print-quote-in-seconds-not-weeks"},{"published":true,"title":"What Makes a Good Vector Database? Comparing Pinecone and LanceDB","author":["Alex Hu / Machine Learning Engineer","Steven Zhang / Back-End Engineer","Anjing Wang / AI Lead"],"createTime":"2024-05-22T00:00:00.000Z","categories":["engineering"],"subCategories":["AI & Vector DBs"],"tags":["Vector Database","Pinecone","LanceDB"],"landingPages":["AI-Data Engineering"],"heroColor":"#3D9AB6","thumb":"./thumb.png","thumb_h":"./thumb_h.png","intro":"Which vector database to use? It depends. Based on our experiences, there is no one-size-fits-all \"best\" database. Instead, a superior vector database is well-matched with its use case, meeting the unique requirements of that scenario. Our comparative analysis offers a promising path to discovering the ideal database for your specific needs.","previousSlugs":["what-makes-a-good-vector-database"],"path":"articles/What%20Makes%20a%20Good%20Vector%20Database%3F%20Comparing%20Pinecone%20and%20LanceDB/README.md","slug":"what-makes-a-good-vector-database-comparing-pinecone-and-lancedb"},{"published":true,"title":"How to Use LLMs to Extract Document Information","author":["Carvin Li / Machine Learning Engineer","Anjing Wang / AI Lead"],"createTime":"2024-05-21T00:00:00.000Z","categories":["engineering"],"subCategories":["AI & Vector DBs"],"tags":["Information Extraction","LLM"],"landingPages":["AI-Data Engineering"],"heroColor":"#4A9C98","thumb":"thumb.png","thumb_h":"thumb_h.png","intro":"Today, we are pioneering a new approach to information extraction (IE) from volumes of academic papers. Traditional IE methods, with their reliance on labor-intensive handcrafted rules and patterns, often struggle to generalize across diverse domains and languages. In contrast, we are harnessing the power of Large Language Models (LLMs) from GPT to Claude to complete IE from these documents and compare their performance. We're excited to share our innovative approach in the field of information extraction.","previousSlugs":["document-information-extraction-with-large-language-models"],"path":"articles/How%20to%20Use%20LLMs%20to%20Extract%20Document%20Information/README.md","slug":"how-to-use-llms-to-extract-document-information"},{"published":true,"title":"How to Use Gradle to Optimize Android Development","author":["Rafael Ruiz / Android Engineer"],"createTime":"2024-05-09T00:00:00.000Z","categories":["engineering"],"subCategories":["Developer Tools & Performance"],"tags":["Mobile","Android"],"landingPages":["AI-AI Infra and Framework"],"heroColor":"#3DA497","thumb":"./thumb.png","thumb_h":"./thumb_h.png","intro":"Dependency conflicts, version compatibility, and maintaining a clean dependency tree can pose challenges in Android development. However, by harnessing the power of Gradle and Dependency Injection (DI), you can navigate these hurdles with confidence. These tools ensure a smooth process and maintain a modular architecture that follows the principles of Clean Architecture. Read how we have successfully achieved this on our projects, and how you can too.","previousSlugs":["overcoming-challenges-in-android-gradle-dependency-management"],"path":"articles/How%20to%20Use%20Gradle%20to%20Optimize%20Android%20Development/README.md","slug":"how-to-use-gradle-to-optimize-android-development"},{"published":true,"title":"Make Releases Manageable with \"Shipping As Small As Possible\"","author":["Yongzhi Yang / Back-End Engineer, Team Lead"],"createTime":"2024-05-09T00:00:00.000Z","categories":["engineering"],"subCategories":["Developer Tools & Performance"],"tags":["CI/CD","Workflow"],"landingPages":["AI-AI Infra and Framework"],"heroColor":"#5B6FBE","thumb":"./thumb.png","thumb_h":"./thumb_h.png","intro":"If you're finding it challenging to release complex features while adhering to the principles of Continuous Integration and Continuous Deployment (CI/CD), we're excited to share our proven approach. By breaking down large features into manageable components, we can relieve the burden of managing these large features, ensuring smoother data management and migration, and minimizing disruptions to dependent clients. This approach also supports an agile and iterative deployment process, enhancing stability and the user experience.","previousSlugs":["shipping-as-small-as-possible","make-release-manageable-with-shipping-as-small-as-possible"],"path":"articles/Make%20Releases%20Manageable%20with%20%22Shipping%20As%20Small%20As%20Possible%22/README.md","slug":"make-releases-manageable-with-shipping-as-small-as-possible"},{"published":true,"title":"Inside Story: How We Approach QA","author":["Jia Chen / QA Engineer","Martha Luo / QA Engineer"],"createTime":"2024-05-07T00:00:00.000Z","categories":["engineering"],"subCategories":["QA & Testing"],"tags":["QA strategy","CI","Automation Framework"],"landingPages":["Blockchain-Onchain infra"],"heroColor":"#329ECC","thumb":"./thumb.png","thumb_h":"./thumb_h.png","intro":"Our Quality Assurance (QA) team plays a pivotal role in ensuring the quality and excellence of our software. We are dedicated to enhancing software quality, team performance, and overall project delivery. This article shares the QA strategies we employ for our projects. We'll also demonstrate how embracing these methods can mitigate difficulties and improve results and provide you with the assurance that our software is of the highest quality.","previousSlugs":["57blocks-testing-best-practices"],"path":"articles/Inside%20Story%3A%20How%20We%20Approach%20QA/README.md","slug":"inside-story-how-we-approach-qa"},{"published":true,"title":"Our Guide to Modern Front-End Build Pipelines","author":["Andy Lai / Fullstack Engineer"],"createTime":"2024-04-23T00:00:00.000Z","categories":["engineering"],"subCategories":["Developer Tools & Performance"],"tags":["JavaScript Framework","React","Webpack"],"landingPages":["QA & Testing"],"heroColor":"#4996F1","thumb":"https://s3.amazonaws.com/assets.57blocks.io/cms_uploads/illustration_cup_an_laptop_e12de970e5.png","thumb_h":"./thumb_h.png","intro":"Feeling overwhelmed by the number of tools available for your oprganization's front-end build pipeline? Don't worry. We're sharing all we've learned about these tools while working on our projects and summarized it here. This comprehensive guide is designed to provide you with the knowledge and confidence to navigate the complexities of modern front-end development, mitigating difficulties and improving results.","previousSlugs":["modernizing-front-end-build-pipelines"],"path":"articles/Our%20Guide%20to%20Modern%20Front-End%20Build%20Pipelines/README.md","slug":"our-guide-to-modern-front-end-build-pipelines"},{"published":true,"title":"Getting Started with Reactive Programming","subTitle":"Tokenpad: A Case Study in Displaying Real-Time Data","author":["Juan E Quintero R / Tech Lead"],"createTime":"2024-04-22T00:00:00.000Z","categories":["engineering"],"subCategories":["Developer Tools & Performance"],"tags":["Reactive","Flutter","Crypto"],"landingPages":["AI-Agentic Applications"],"heroColor":"#735BB9","thumb":"https://s3.amazonaws.com/assets.57blocks.io/cms_uploads/illustration_tokenpad_65aea3b800.png","thumb_h":"./thumb_h.png","intro":"Users expect to see real-time data while using apps and don't want to refresh the screen. This is achieved by using Reactive Programming. In this article, you'll explore why Reactive Programming exists and how it enables apps to update with new data in real time.","previousSlugs":["reactive-programming-in-tokenpad"],"path":"articles/Getting%20Started%20with%20Reactive%20Programming/README.md","slug":"getting-started-with-reactive-programming"},{"published":true,"title":"Boost Traffic and Leads with Programmatic SEO","author":["Shi Chen / Product Manager"],"createTime":"2024-04-21T00:00:00.000Z","categories":["engineering"],"subCategories":["App Growth & Delivery"],"tags":["SEO","Growth","Alternative Investment"],"heroColor":"#39A0A0","thumb":"https://s3.amazonaws.com/assets.57blocks.io/cms_uploads/illustration_seo_db9bc06b49.png","thumb_h":"./thumb_h.png","intro":"You may have heard that programmatic SEO could boost site traffic from search engines and increase leads. However, considering the complexities of implementation can be intimidating. In this blog, we describe our design and client collaboration process, along with our findings and we outline the numerous client benefits after launch.","previousSlugs":["maximizing-online-visibility-the-power-of-programmatic-seo-for-boosting-search-traffic-and-leads"],"path":"articles/Boost%20Traffic%20and%20Leads%20with%20Programmatic%20SEO/README.md","slug":"boost-traffic-and-leads-with-programmatic-seo"},{"published":true,"title":"Image Quality Assessment Using Machine Learning","author":["Damon Wang / Android Engineer","Roy Xie / Tech Lead"],"createTime":"2024-04-20T00:00:00.000Z","categories":["engineering"],"subCategories":["AI & Vector DBs"],"tags":["Image Quality","CNN","OpenCV"],"landingPages":["AI-AI/ML Model Dev","Blockchai-AI agent"],"heroColor":"#4996F1","thumb":"https://s3.amazonaws.com/assets.57blocks.io/cms_uploads/illustration_blue_squares_c1bbaab97b.png","thumb_h":"./thumb_h.png","intro":"Image Quality Assessment (IQA), specifically Objective Blind or no-reference IQA, is a crucial function in determining image fidelity or the quality of image accuracy. Further, IQA helps maintain the integrity of visual data, ensuring its accurate representation. In this article, we share an analysis of the best machine learning models that support IQA, including BRISQUE, DIQA, NIMA and OpenCV. We will delve deeper into their operations, the challenges and advantages, and their significance in the ever-evolving field of image quality assessment.","previousSlugs":["image-quality-assessment"],"path":"articles/Image%20Quality%20Assessment%20Using%20Machine%20Learning/README.md","slug":"image-quality-assessment-using-machine-learning"},{"published":true,"title":"How to QA Smart Contracts on Blockchain","author":["Lily Hu / Smart Contract Engineer"],"createTime":"2024-04-19T00:00:00.000Z","categories":["engineering"],"subCategories":["QA & Testing"],"tags":["Smart Contract","Web3","QA"],"landingPages":["Blockchain-Onchain infra"],"heroColor":"#795ECA","thumb":"./thumb.png","thumb_h":"./thumb_h.png","intro":"Deploying a smart contract on the public blockchain is a significant milestone but also fraught with risk. Blockchain technology's immutability means that any flaws in the contract's code can have irreversible consequences. In this guide, we will walk you through a systematic and detailed approach to ensuring that your smart contract functions as intended, remains secure against malicious attacks, and is optimized for performance and cost-effectiveness.","previousSlugs":["smart-contract-development-a-step-by-step-quality-assurance-guide"],"path":"articles/How%20to%20QA%20Smart%20Contracts%20on%20Blockchain/README.md","slug":"how-to-qa-smart-contracts-on-blockchain"},{"published":true,"title":"Guide to Web3 and dApp Infrastructure","author":["Wei Wang / Tech Lead"],"createTime":"2024-04-18T00:00:00.000Z","categories":["engineering"],"subCategories":["Blockchain & Web3"],"tags":["Smart Contract","Web3","Architecture","Dapp"],"landingPages":["Blockchain-dApps"],"heroColor":"#2CA9CA","thumb":"./thumb.png","thumb_h":"./thumb_h.png","intro":"We created this guide to help people new to Web3 and the dApp infrastructures use this technology in their organizations. The design of Web3 apps is much more decentralized than that of Web2. New services are constantly appearing to make building and running these projects easier and safer. Engineers must know how each part works to create effective Web3 apps. We describe this here.","previousSlugs":["the-building-blocks-of-web3-a-deep-dive-into-dapp-infrastructure"],"path":"articles/Guide%20to%20Web3%20and%20dApp%20Infrastructure/README.md","slug":"guide-to-web3-and-dapp-infrastructure"}]} \ No newline at end of file