Sẵn sàng cho môi trường production

Xây dựng cục bộ và thử nghiệm trên devnet là những cách tuyệt vời để bắt đầu với thanh toán Solana. Tuy nhiên, khi bạn sẵn sàng triển khai lên Mainnet, bạn cần nhận thức được những điểm đặc thù của mainnet. Devnet tha thứ cho sai lầm. Mainnet thì không. Hướng dẫn này đề cập đến những khác biệt quan trọng để đảm bảo người dùng của bạn có trải nghiệm mượt mà.

Hạ tầng RPC

Endpoint công khai (api.mainnet-beta.solana.com) bị giới hạn tốc độ và không có SLA. Chúng phù hợp cho phát triển nhưng sẽ làm thất bại các luồng thanh toán production—giống như cố gắng chạy một bộ xử lý thanh toán thông qua API dùng chung mà không có đảm bảo uptime.

Khi chọn nhà cung cấp RPC, hãy tìm:

• Độ tin cậy: SLA với đảm bảo uptime (99.9%+)
• Độ trễ: Gần về mặt địa lý với người dùng của bạn
• Tính năng: Tính năng landing giao dịch, indexing, API phí ưu tiên

Để xem danh sách đầy đủ các nhà cung cấp RPC, hãy xem hướng dẫn Nhà cung cấp hạ tầng RPC.

Cấu hình RPC dự phòng

Giống như bất kỳ nhà cung cấp dịch vụ mạng nào, các nhà cung cấp RPC có thể gặp downtime hoặc giai đoạn hiệu suất giảm sút. Để đảm bảo ứng dụng của bạn có khả năng phục hồi, bạn nên cấu hình ứng dụng của mình để sử dụng nhiều nhà cung cấp RPC.

Solana Kit cung cấp thư viện để tùy chỉnh các phương thức truyền tải RPC, cho phép bạn xây dựng client RPC dự phòng của riêng mình. Dưới đây là ví dụ về cách bạn có thể sử dụng nó để xây dựng một client RPC dự phòng:

import { RpcTransport } from "@solana/rpc-spec";
import { RpcResponse } from "@solana/rpc-spec-types";
import { createHttpTransport } from "@solana/rpc-transport-http";

// Create a transport for each RPC server
const transports = [
  createHttpTransport({ url: "https://mainnet-beta.my-server-1.com" }),
  createHttpTransport({ url: "https://mainnet-beta.my-server-2.com" }),
  createHttpTransport({ url: "https://mainnet-beta.my-server-3.com" })
];

// Create a wrapper transport that distributes requests to them
let nextTransport = 0;
async function roundRobinTransport<TResponse>(
  ...args: Parameters<RpcTransport>
): Promise<RpcResponse<TResponse>> {
  const transport = transports[nextTransport];
  nextTransport = (nextTransport + 1) % transports.length;
  return await transport(...args);
}

Nếu bạn không muốn tự xây dựng công cụ định tuyến, bạn có thể tận dụng dịch vụ bên thứ ba như Iron Forge để xử lý việc định tuyến cho bạn.

Xác nhận giao dịch

Trên Devnet, các giao dịch được xác nhận khá dễ dàng. Trên Mainnet, bạn đang cạnh tranh cho không gian block. Để tăng khả năng giao dịch của bạn được đưa vào một block, bạn nên đảm bảo rằng bạn đã lắp ráp giao dịch đúng cách. Điều này có nghĩa là:

• bao gồm blockhash mới trước khi gửi giao dịch
• bao gồm chỉ thị phí ưu tiên trong giao dịch với mức phí ưu tiên cạnh tranh
• bao gồm chỉ thị giới hạn đơn vị tính toán trong giao dịch với giới hạn đơn vị tính toán dựa trên ước tính đơn vị tính toán cần thiết cho giao dịch

Ngoài ra, bạn nên xem xét các công cụ khác như Jito Bundles để tăng khả năng giao dịch của bạn được đưa vào một block. Hãy cùng khám phá các công cụ này chi tiết hơn.

Cấu hình gửi giao dịch

Khi gửi giao dịch trên Mainnet, hãy cấu hình các tham số này để đạt tỷ lệ xác nhận tối ưu:

Quản lý blockhash:

• Lấy với cam kết confirmed
• Lưu trữ lastValidBlockHeight được trả về bởi getLatestBlockhash—điều này cho bạn biết khi nào giao dịch của bạn hết hạn
• Blockhash hết hạn sau ~150 block (~60-90 giây)

Tùy chọn gửi:

• maxRetries: 0 — Vô hiệu hóa thử lại RPC tự động. Tự xử lý việc thử lại để bạn có thể làm mới blockhash khi cần thiết.
• skipPreflight: true — Bỏ qua mô phỏng trước khi gửi. Sử dụng tùy chọn này khi bạn đã xác thực giao dịch và muốn độ trễ thấp nhất. Giữ nó ở false trong quá trình phát triển để phát hiện lỗi sớm.

import { createSolanaRpc } from "@solana/kit";

const rpc = createSolanaRpc(process.env.RPC_URL!);

// 1. Get blockhash with confirmed commitment
const { value: latestBlockhash } = await rpc
  .getLatestBlockhash({ commitment: "confirmed" })
  .send();

// 2. Build and sign your transaction with the blockhash
// ... (transaction building code)

// 3. Send with production settings
const signature = await rpc
  .sendTransaction(encodedTransaction, {
    encoding: "base64",
    maxRetries: 0n, // Handle retries yourself
    skipPreflight: true, // Skip simulation for speed (use false during dev)
    preflightCommitment: "confirmed"
  })
  .send();

// 4. Track expiration using lastValidBlockHeight
const { lastValidBlockHeight } = latestBlockhash;
// Stop retrying when current block height exceeds lastValidBlockHeight

Sử dụng phí ưu tiên

Mọi giao dịch Solana đều yêu cầu phí giao dịch, được thanh toán bằng SOL. Phí giao dịch được chia thành hai phần: phí cơ bản và phí ưu tiên. Phí cơ bản bù đắp cho các validator khi xử lý giao dịch. Phí ưu tiên là khoản phí tùy chọn, nhằm tăng khả năng leader hiện tại sẽ xử lý giao dịch của bạn. Hãy nghĩ về nó như dịch vụ giao hàng nhanh: bạn trả nhiều hơn để được giao hàng nhanh hơn và đáng tin cậy hơn.

Cách thức hoạt động của phí:

Total fee = Base fee (5,000 lamports per signature) + Priority fee
Priority fee = Compute units x Price per unit (micro-lamports per compute unit)

Chi phí thực tế:

• Chuyển USDC đơn giản: ~$0.001-0.005 trong điều kiện bình thường
• Trong thời gian tắc nghẽn: ~$0.01-0.05
• Tắc nghẽn cao điểm: Có thể tăng cao hơn

Ví dụ triển khai:

Gói @solana-program/compute-budget cung cấp hàm trợ giúp để dễ dàng cập nhật hoặc thêm chỉ thị giá đơn vị tính toán (tính bằng micro-lamport) vào giao dịch.

import { updateOrAppendSetComputeUnitPriceInstruction } from "@solana-program/compute-budget";

const tx = pipe(
  createTransactionMessage({ version: 0 }),
  (m) => setTransactionMessageFeePayerSigner(payer, m),
  (m) => setTransactionMessageLifetimeUsingBlockhash(latestBlockhash, m),
  (m) => appendTransactionMessageInstructions([myInstructions], m),
  (m) => updateOrAppendSetComputeUnitPriceInstruction(1000n as MicroLamports, m)
);

Lấy ước tính phí: Hầu hết các nhà cung cấp RPC đều cung cấp API phí ưu tiên:

• Helius Priority Fee API
• QuickNode Priority Fee Add-on
• Triton Priority Fees API

Để biết đầy đủ cơ chế phí, xem Phí giao dịch và hướng dẫn của chúng tôi: Cách thêm phí ưu tiên vào giao dịch.

Tối ưu hóa đơn vị tính toán

Tính toán trên Solana thực chất là thước đo lượng công việc mà chương trình đang thực hiện. Có giới hạn về lượng tính toán có thể được sử dụng trong một giao dịch (hiện tại là 1,4 triệu đơn vị tính toán), và giới hạn về lượng tính toán có thể được sử dụng cho mỗi tài khoản trên mỗi block (hiện tại là 100 triệu đơn vị tính toán).

Khi bạn gửi giao dịch, bạn cần ước tính lượng tính toán sẽ được sử dụng và đặt giới hạn đơn vị tính toán cho phù hợp - đây thực chất là yêu cầu về lượng công suất tổng thể cần được dành riêng cho giao dịch của bạn. Trên thực tế, điều này có nghĩa là việc ước tính chính xác các đơn vị tính toán cần thiết cho giao dịch của bạn là rất quan trọng để giao dịch được đưa vào block (và quan trọng cho việc quản lý phí ưu tiên của bạn).

Solana JSON RPC API có phương thức simulatetransaction có thể được sử dụng để ước tính số đơn vị tính toán cần thiết cho một giao dịch, bao gồm cả ước tính số đơn vị tính toán sẽ được sử dụng. @solana/kit cung cấp các hàm trợ giúp để ước tính giới hạn tài nguyên của giao dịch và đặt chúng vào thông điệp trong một bước (sử dụng phương thức simulatetransaction bên dưới). Đối với các giao dịch phiên bản 1, các hàm trợ giúp này cũng ước tính giới hạn kích thước dữ liệu tài khoản đã tải.

import {
  estimateResourceLimitsFactory,
  estimateAndSetResourceLimitsFactory
} from "@solana/kit";

const estimateResourceLimits = estimateResourceLimitsFactory({ rpc });
const estimateAndSetResourceLimits = estimateAndSetResourceLimitsFactory(
  estimateResourceLimits
);
const txWithResourceLimits = await estimateAndSetResourceLimits(tx);

Trong môi trường sản xuất, nếu bạn lặp lại cùng một loại giao dịch nhiều lần, bạn nên cân nhắc lưu vào bộ nhớ cache kết quả ước tính tính toán cho loại giao dịch đó để tránh phải ước tính lại đơn vị tính toán mỗi lần.

Jito Bundles

Jito bundles là một công cụ để quản lý việc thực thi nguyên tử của nhiều giao dịch. Điều này được thực hiện bằng cách gửi nhiều giao dịch đến mạng Jito kèm theo một khoản tiền thưởng. Tiền thưởng có thể được sử dụng để khuyến khích mạng Jito đưa các giao dịch của bạn vào một khối.

Tài nguyên:

• Tài liệu Jito
• 🎥 Video: Jito Bundles
• Hướng dẫn QuickNode về Jito bundles

Chiến Lược Thử Lại

Giao dịch có thể thất bại vì nhiều lý do. Không giống như các API thanh toán truyền thống trả về kết quả thành công/thất bại ngay lập tức, các giao dịch blockchain yêu cầu theo dõi xác nhận.

Các khái niệm chính:

• Hết hạn blockhash: Giao dịch có hiệu lực trong ~150 khối (~60-90 giây)
• Tính bất biến: Cùng một giao dịch đã ký luôn tạo ra cùng một chữ ký — việc gửi lại là an toàn
• Backoff theo cấp số nhân: Tránh làm quá tải mạng bằng các lần thử lại nhanh chóng

import {
  createSolanaRpc,
  createSolanaRpcSubscriptions,
  sendAndConfirmTransactionFactory,
  isSolanaError,
  SOLANA_ERROR__BLOCK_HEIGHT_EXCEEDED
} from "@solana/kit";

const rpc = createSolanaRpc(process.env.RPC_URL!);
const rpcSubscriptions = createSolanaRpcSubscriptions(process.env.RPC_WSS_URL!);

const sendAndConfirmTransaction = sendAndConfirmTransactionFactory({
  rpc,
  rpcSubscriptions
});

// Send with automatic confirmation tracking and block height monitoring
try {
  await sendAndConfirmTransaction(signedTransaction, {
    commitment: "confirmed",
    // Optional: abort after 75 seconds
    abortSignal: AbortSignal.timeout(75_000)
  });
} catch (e) {
  if (isSolanaError(e, SOLANA_ERROR__BLOCK_HEIGHT_EXCEEDED)) {
    // Blockhash expired—rebuild transaction with fresh blockhash and retry
    rebuildAndRetryTransaction(); // implement your own logic for rebuilding and retrying the transaction
  }
  throw e;
}

sendAndConfirmTransactionFactory từ @solana/kit xử lý việc polling xác nhận và theo dõi chiều cao khối tự động. Nó ném ra SOLANA_ERROR__BLOCK_HEIGHT_EXCEEDED khi blockhash của giao dịch hết hạn, báo hiệu rằng bạn cần xây dựng lại giao dịch với một blockhash mới.

Tài Nguyên Bổ Sung

• Hướng dẫn: Xác Nhận & Hết Hạn Giao Dịch
• Helius: Cách Thực Hiện Giao Dịch Trên Solana
• QuickNode: Chiến Lược Tối Ưu Hóa Giao Dịch Solana

Hiểu Về Các Mức Xác Nhận

Solana cung cấp ba mức xác nhận. Theo thuật ngữ tài chính truyền thống:

Khi nào sử dụng từng loại:

• Cập nhật UI: Hiển thị processed để phản hồi ngay lập tức ("Thanh toán đã được gửi")
• Ghi có tài khoản người dùng: Chờ confirmed (an toàn cho hầu hết các giao dịch)
• Giao hàng vật lý: Chờ finalized
• Rút tiền lớn: Chờ finalized
• Tuân thủ/kiểm toán: Luôn ghi lại trạng thái finalized

Để biết thêm về cách kiểm tra trạng thái giao dịch, xem Tương Tác Với Solana.

Xử Lý Lỗi

Solana Kit cung cấp các lỗi có kiểu thông qua isSolanaError(). Sử dụng mã lỗi cụ thể thay vì so khớp chuỗi:

import {
  isSolanaError,
  SOLANA_ERROR__BLOCK_HEIGHT_EXCEEDED,
  SOLANA_ERROR__TRANSACTION_ERROR__INSUFFICIENT_FUNDS_FOR_FEE,
  SOLANA_ERROR__TRANSACTION_ERROR__BLOCKHASH_NOT_FOUND,
  SOLANA_ERROR__INSTRUCTION_ERROR__INSUFFICIENT_FUNDS
} from "@solana/kit";

function handlePaymentError(error: unknown): {
  message: string;
  retryable: boolean;
} {
  // Blockhash expired—rebuild and retry
  if (
    isSolanaError(error, SOLANA_ERROR__BLOCK_HEIGHT_EXCEEDED) ||
    isSolanaError(error, SOLANA_ERROR__TRANSACTION_ERROR__BLOCKHASH_NOT_FOUND)
  ) {
    return { message: "Transaction expired—rebuilding", retryable: true };
  }

  // Insufficient SOL for fees
  if (
    isSolanaError(
      error,
      SOLANA_ERROR__TRANSACTION_ERROR__INSUFFICIENT_FUNDS_FOR_FEE
    )
  ) {
    return { message: "Not enough SOL for fees", retryable: false };
  }

  // Insufficient token balance
  if (
    isSolanaError(error, SOLANA_ERROR__INSTRUCTION_ERROR__INSUFFICIENT_FUNDS)
  ) {
    return { message: "Insufficient balance", retryable: false };
  }

  // Unknown error
  console.error("Payment error:", error);
  return { message: "Payment failed—please retry", retryable: true };
}

Mã Lỗi Thường Gặp:

Giao Dịch Không Phí Gas

Người dùng muốn thanh toán bằng stablecoin, không phải mua SOL để trả phí mạng. Giao dịch không phí gas giải quyết vấn đề này—tương tự như cách người dùng Venmo không cần quan tâm đến phí ACH. Xem Trừu Tượng Hóa Phí để biết cách triển khai đầy đủ.

Bảo Mật

Quản Lý Khóa

• Không bao giờ để lộ khóa riêng tư trong mã frontend. Sử dụng ký phía backend, ví phần cứng, ví đa chữ ký, hoặc dịch vụ quản lý khóa.
• Tách biệt ví nóng và ví lạnh. Ví nóng dùng cho vận hành, ví lạnh dùng cho ngân quỹ.
• Sao lưu tất cả khóa sản xuất. Lưu trữ bản sao lưu đã mã hóa ở nhiều vị trí bảo mật khác nhau. Mất khóa đồng nghĩa với mất quyền truy cập vĩnh viễn.
• Sử dụng các khóa khác nhau cho devnet và mainnet. Khóa devnet của bạn không nên là khóa mainnet. Sử dụng cấu hình dựa trên môi trường để đảm bảo tải đúng khóa cho từng mạng.

Cơ Sở Hạ Tầng Ký

Để ký phía backend trong môi trường sản xuất, hãy sử dụng Keychain—một thư viện ký thống nhất, trừu tượng hóa nhiều backend quản lý khóa thông qua một giao diện duy nhất: Memory, Vault, Privy, Turnkey, AWS KMS, Fireblocks, GCP KMS, CDP, Para, Dfns, Crossmint, Openfort và Utila. Điều này cho phép bạn phát triển cục bộ với khóa lưu trong bộ nhớ, sau đó chuyển sang backend cấp sản xuất mà không cần thay đổi mã ứng dụng.

Chưa biết backend nào phù hợp? Xem Chọn backend. Keychain có sẵn cho cả Rust và TypeScript.

Bảo mật RPC

Hãy xem các endpoint RPC như khóa API—đừng để lộ chúng trong mã frontend nơi chúng có thể bị trích xuất và lạm dụng. Hãy sử dụng proxy backend hoặc biến môi trường không được đóng gói vào mã client.

• QuickNode: Các phương pháp bảo mật endpoint tốt nhất
• Helius: Bảo vệ khóa API Solana của bạn: Các phương pháp bảo mật tốt nhất

Giám sát

Theo dõi các chỉ số này trong môi trường production:

Thiết lập cảnh báo cho:

• Chuyển khoản vượt ngưỡng từ kho bạc
• Tăng đột biến tỷ lệ giao dịch thất bại
• Các mẫu người nhận bất thường
• Tăng tỷ lệ lỗi RPC

Để giám sát giao dịch theo thời gian thực ở quy mô lớn, hãy xem Hướng dẫn lập chỉ mục của chúng tôi.

Xác minh địa chỉ

Mỗi token và chương trình có đúng một địa chỉ chính xác trên mainnet. Các token giả mạo bắt chước USDC hoặc các stablecoin khác là phổ biến—chúng sẽ có cùng tên và ký hiệu nhưng lại có mint khác. Ứng dụng của bạn nên hardcode hoặc đưa vào danh sách cho phép các địa chỉ mint (dựa trên yêu cầu của bạn), không bao giờ chấp nhận chúng một cách động từ các nguồn không đáng tin cậy.

Cấu hình theo môi trường: Devnet và Mainnet thường sử dụng các token mint hoàn toàn khác nhau. Thiết lập cấu hình ứng dụng của bạn để tải đúng địa chỉ cho từng môi trường—đừng hardcode địa chỉ mainnet và quên đổi chúng trong quá trình kiểm thử, hoặc tệ hơn là triển khai địa chỉ devnet lên production.

Một số token mint stablecoin phổ biến:

Địa chỉ chương trình cũng rất quan trọng. Gửi lệnh đến sai chương trình sẽ thất bại—hoặc tệ hơn, dẫn đến mất vốn không thể hoàn tác. Các địa chỉ Token Program là:

Việc đưa vào danh sách cho phép các địa chỉ đúng giúp bảo vệ chống lại các token giả mạo, nhưng không bảo vệ chống lại việc gửi đến sai loại tài khoản. Địa chỉ người nhận có thể là ví, token account, mint hoặc chương trình, và mỗi loại yêu cầu cách xử lý khác nhau. SOL gốc được gửi đến bất kỳ thứ gì ngoài ví sẽ thoát khỏi tầm kiểm soát của người gửi — mất hoàn toàn nếu gửi đến mint hoặc chương trình, chỉ có thể thu hồi bởi chủ tài khoản nếu gửi đến token account — mà không có giao dịch thất bại nào để cảnh báo người dùng.

Danh Sách Kiểm Tra Trước Khi Ra Mắt

• Đã mua SOL trên Mainnet cho phí giao dịch và rent
• Đã cấu hình RPC cho môi trường Production (không dùng endpoint công khai)
• Đã cấu hình endpoint RPC dự phòng
• Đã triển khai phí ưu tiên với định giá động
• Logic thử lại xử lý được việc blockhash hết hạn
• Mức xác nhận phù hợp với trường hợp sử dụng
• Tất cả các lỗi phổ biến được xử lý một cách hợp lý
• Đã cấu hình Gasless (nếu áp dụng)
• Đã xác minh địa chỉ token trên Mainnet (không phải devnet mints)
• Xác thực địa chỉ người nhận trước khi gửi (ví vs token account vs mint vs chương trình)
• Tất cả các khóa đã được sao lưu an toàn
• Đã xem xét quản lý khóa (không lưu khóa ở frontend)
• Đã kích hoạt giám sát và cảnh báo giao dịch
• Đã kiểm tra tải ở mức khối lượng dự kiến

Triển Khai Chương Trình

Nếu bạn đang triển khai một chương trình Solana tùy chỉnh như một phần trong cơ sở hạ tầng thanh toán của mình, có một số lưu ý bổ sung cần xem xét.

Trước khi triển khai

• Phiên bản Solana CLI: Đảm bảo bạn đang sử dụng phiên bản mới nhất của Solana CLI.
• Program keypair: Chương trình của bạn sẽ có địa chỉ khác trên mainnet so với devnet (trừ khi bạn tái sử dụng cùng một keypair). Cập nhật tất cả các tham chiếu trong cấu hình ứng dụng của bạn. Lưu trữ program keypair của bạn ở nơi an toàn (lưu ý rằng việc chạy cargo clean có thể sẽ xóa program keypair của bạn).
• Khởi tạo tài khoản: Nếu chương trình của bạn yêu cầu tài khoản admin, PDA, hoặc các tài khoản trạng thái khác, hãy đảm bảo những tài khoản này được tạo trên mainnet trước khi người dùng tương tác với ứng dụng của bạn. Tương tự đối với bất kỳ Associated Token Accounts (ATAs) nào mà chương trình của bạn cần.

Quy trình triển khai

• Tài khoản buffer: Các chương trình lớn được triển khai thông qua tài khoản buffer. Lệnh solana program deploy xử lý điều này tự động, nhưng cần lưu ý rằng quá trình triển khai không phải là nguyên tử — nếu bị gián đoạn, bạn có thể cần khôi phục hoặc đóng các tài khoản buffer. Xem Deploying Programs.
• Quyền nâng cấp: Quyết định xem chương trình của bạn có nên được nâng cấp sau khi ra mắt hay không. Để đảm bảo tính bất biến, hãy thu hồi quyền nâng cấp sau khi triển khai. Để linh hoạt, hãy bảo mật khóa quyền nâng cấp một cách phù hợp.
• Rent: Đảm bảo ví triển khai của bạn có đủ SOL để trang trải mức tối thiểu miễn rent cho tất cả các program account.
• Xác minh: Xác minh chương trình của bạn để đảm bảo rằng chương trình thực thi bạn triển khai lên mạng Solana khớp với mã nguồn trong kho lưu trữ của bạn

Để được hướng dẫn đầy đủ về triển khai chương trình, hãy xem Deploying Programs.