Mô hình Tài khoản Solana Được Giải thích

Mô hình Tài khoản Solana lưu trữ Số dư, mã chương trình, khoản nắm giữ token và trạng thái ứng dụng trong các tài khoản riêng biệt với các quy tắc sở hữu tường minh. Hướng dẫn bằng ngôn ngữ đơn giản này giải thích mô hình cho độc giả phổ thông trước khi đi sâu vào các trường, loại tài khoản, miễn phí thuê và các ví dụ thực tế.

Các chi tiết triển khai như xử lý phí thuê, giới hạn kích thước tài khoản và API client có thể thay đổi. Nhà phát triển nên kiểm tra tài liệu Solana hiện tại và truy vấn các tham số mạng hiện tại trước khi triển khai.

Nếu bạn đến từ Ethereum, mô hình tài khoản của Solana lúc đầu sẽ có vẻ ngược đời. Phản ứng đó là điểm khởi đầu đúng đắn. Mô hình tư duy bạn xây dựng trên Ethereum không chuyển đổi một cách sạch sẽ, và việc cố gắng ép buộc nó sẽ gây ra sự nhầm lẫn ở mọi bước.

Mô hình tài khoản Solana là hệ thống kiến trúc mà theo đó tất cả trạng thái Trên chuỗi được lưu trữ trong các đơn vị lưu trữ riêng biệt gọi là tài khoản. Mọi Số dư ví, chương trình, khoản nắm giữ token và bản ghi trạng thái ứng dụng đều nằm trong một tài khoản riêng biệt với chủ sở hữu được xác định, Số dư lamport và các quy tắc tường minh quản lý ai có thể đọc hoặc ghi vào nó. Không có gì tồn tại trên Solana bên ngoài một tài khoản.

Hãy coi Solana như một hệ thống lưu trữ hồ sơ toàn cầu. Mọi phần dữ liệu đều nằm trong một tệp riêng biệt gọi là tài khoản. Các chương trình là các ứng dụng đọc và ghi các tệp đó, nhưng một chương trình chỉ có thể sửa đổi một tệp mà nó sở hữu. Runtime thực thi các quy tắc sở hữu đó ở cấp độ giao thức, không có ngoại lệ.

Bài viết này đề cập đến năm trường bên trong mỗi tài khoản Solana, năm loại tài khoản riêng biệt, cách hoạt động của phí thuê và miễn phí thuê, Địa chỉ có nguồn gốc từ Chương trình (PDA) là gì và tại sao chúng tồn tại, cách tài khoản được tạo và đóng, và tại sao kiến trúc này cho phép xử lý giao dịch song song của Solana. Các chương trình Solana được viết bằng Rust (hoặc C/C++), mặc dù các framework như Anchor trừu tượng hóa nhiều phần mã quản lý tài khoản soạn sẵn. Bài viết này bao quát nền tảng khái niệm mà cả hai đều yêu cầu.

Mô hình Tài khoản Solana: Giải phẫu một Tài khoản

Tài khoản Solana là một khe lưu trữ có nhãn trên mạng, chứa Số dư tính bằng lamport, một tải dữ liệu tùy ý và một bộ các trường siêu dữ liệu xác định ai sở hữu nó và nó có thể làm gì. Trên Solana, tất cả dữ liệu, từ Số dư ví đến trạng thái chương trình và khoản nắm giữ token, đều được lưu trữ trong các tài khoản.

Lamport là mệnh giá nhỏ nhất của SOL, token gốc của mạng. Lamport tương ứng với SOL như xu với đô la, ngoại trừ với độ chính xác chín chữ số thập phân: 1 SOL bằng 1.000.000.000 lamport. Mỗi tài khoản có một Số dư lamport để tài trợ cho sự tồn tại liên tục của tài khoản trên mạng và thể hiện giá trị có thể chuyển nhượng.

Mỗi tài khoản Solana chứa chính xác năm trường:

• lamports (u64): Số dư của tài khoản tính bằng lamport. Trường này tài trợ cho phí thuê và có thể được chuyển cho các tài khoản khác.
• data (mảng byte): Lưu trữ dữ liệu nhị phân thô. Trong các tài khoản có thể thực thi, trường này chứa mã bytecode BPF/SBF đã biên dịch. Trong các tài khoản dữ liệu, nó chứa trạng thái ứng dụng có cấu trúc. Kích thước tối đa của trường dữ liệu là 10 MB theo các tham số mainnet hiện tại.
• owner (Pubkey): Khóa công khai 32 byte của chương trình có quyền ghi độc quyền đối với trường dữ liệu của tài khoản này. Đây là trường khó hiểu nhất đối với các nhà phát triển Ethereum. Địa chỉ ví của bạn không thuộc sở hữu của bạn ở cấp độ giao thức; nó thuộc sở hữu của Chương trình Hệ thống. Phần giải thích đầy đủ về trường owner xuất hiện trong phần sở hữu tài khoản và quyền hạn.
• executable (bool): Một cờ boolean. Khi true, trường dữ liệu chứa mã bytecode chương trình và tài khoản hoạt động như một chương trình. Khi false, tài khoản lưu trữ trạng thái hoặc giữ Số dư.
• rent_epoch (u64): Một trường cũ theo dõi kỷ nguyên mà phí thuê được thu lần cuối. Tính đến năm 2024, việc thu phí thuê đã bị loại bỏ để ưu tiên mô hình miễn phí thuê mặc định. Trường này vẫn tồn tại trong cấu trúc tài khoản nhưng không còn được sử dụng tích cực.

Đây là những gì một tài khoản ví trông giống như một cấu trúc dữ liệu:

{
  "lamports": 1000000000,
  "data": [],
  "owner": "11111111111111111111111111111111",
  "executable": false,
  "rent_epoch": 0
}

Trường owner là một khái niệm ở cấp độ giao thức: chương trình kiểm soát quyền ghi đối với trường dữ liệu. Quyền hạn là một quy ước riêng biệt được lưu trữ bên trong dữ liệu do chương trình quản lý, chẳng hạn như trường quyền hạn chuyển khoản bên trong tài khoản token. Chúng không giống nhau; phần sở hữu làm rõ sự khác biệt này.

Năm Loại Tài khoản Solana

Solana có năm loại tài khoản riêng biệt, mỗi loại phục vụ một vai trò kiến trúc cụ thể được xác định bởi trường owner và cờ executable của nó. Loại này không được lưu trữ dưới dạng một trường riêng biệt; nó được suy ra từ chủ sở hữu của tài khoản và liệu nó có chứa mã có thể thực thi hay không.

Tài khoản thuộc sở hữu Hệ thống (Tài khoản Ví)

Một tài khoản thuộc sở hữu hệ thống giữ Số dư SOL của người dùng và không có gì khác. Chủ sở hữu luôn là Chương trình Hệ thống (11111111111111111111111111111111), cờ executable là false và trường dữ liệu trống. Khi bạn chia sẻ địa chỉ ví của mình với Phantom hoặc Solflare, bạn đang chia sẻ địa chỉ của một tài khoản thuộc sở hữu hệ thống. Bạn kiểm soát nó bằng cách ký các giao dịch bằng Private Key của mình, nhưng Chương trình Hệ thống là chủ sở hữu ở cấp độ giao thức.

Tài khoản Chương trình (Tài khoản có thể thực thi)

Một tài khoản chương trình là một tài khoản có thể thực thi chứa mã bytecode BPF/SBF đã biên dịch. Cờ executable là true và chủ sở hữu là BPF Loader. Tài khoản chương trình được thiết kế để không trạng thái; chúng chỉ chứa mã, không bao giờ chứa trạng thái. Trên Ethereum, một Hợp đồng Thông minh lưu trữ cả mã và trạng thái của nó tại một địa chỉ hợp đồng duy nhất. Trên Solana, mã nằm trong một tài khoản chương trình và trạng thái nằm trong các tài khoản dữ liệu riêng biệt, luôn được lưu trữ tách biệt.

Các tài khoản chương trình có thể lưu trữ mã có thể thực thi, với executable = true và mã bytecode BPF/SBF trong trường dữ liệu. Các tài khoản dữ liệu không thể thực thi có executable = false và thay vào đó lưu trữ trạng thái.

Tài khoản Dữ liệu (Tài khoản thuộc sở hữu Chương trình)

Một tài khoản dữ liệu là một tài khoản không thể thực thi thuộc sở hữu của một chương trình cụ thể, lưu trữ trạng thái của chương trình trong trường dữ liệu của nó. Cờ executable là false. Chủ sở hữu là bất kỳ chương trình nào đã tạo và quản lý tài khoản. Số dư token USDC của bạn, một Vị thế cho vay DeFi, một bản ghi siêu dữ liệu NFT: mỗi thứ nằm trong tài khoản dữ liệu chuyên dụng của riêng nó thuộc sở hữu của chương trình liên quan.

Tài khoản Chương trình Gốc

Các tài khoản chương trình gốc là các chương trình tích hợp được triển khai tại các địa chỉ cố định trong quá trình genesis của mạng. Chúng bao gồm Chương trình Hệ thống, BPF Loader, Chương trình Bỏ phiếu và Chương trình Stake. Đây là các chương trình hạ tầng cốt lõi mà người dùng không thể thay thế hoặc nâng cấp. Cờ executable của chúng là true.

Tài khoản Sysvar

Các tài khoản Sysvar là các tài khoản chỉ đọc được tiền điền sẵn bởi runtime Solana, cho phép các chương trình truy cập trạng thái mạng hiện tại. Hãy coi các tài khoản sysvar như một bảng thông báo của chính phủ tại tòa án: có thể đọc công khai, được duy trì bởi một nguồn có thẩm quyền, nhưng không bên tư nhân nào có thể sửa đổi chúng. Sysvar Đồng hồ tại SysvarC1ock11111111111111111111111111111111 cung cấp dấu thời gian khối hiện tại và số lượng slot. Sysvar Phí thuê cung cấp các tham số phí thuê hiện tại.

Các chương trình không có trạng thái trên Solana. Tất cả trạng thái nằm trong các tài khoản dữ liệu mà chúng sở hữu và kiểm soát. Sự tách biệt logic khỏi trạng thái này là quyết định thiết kế làm cho mọi thứ khác trong bài viết này có thể thực hiện được.

Chương trình vs. Tài khoản Dữ liệu: Sự Tách Biệt giữa Logic và Trạng thái

Các chương trình Solana không có trạng thái. Chúng không giữ dữ liệu riêng và mọi phần dữ liệu mà chúng xử lý đều nằm trong các tài khoản dữ liệu riêng biệt được truyền cho chương trình khi chạy.

Hãy coi chương trình Solana như phần mềm xử lý giao dịch của ngân hàng, và các tài khoản dữ liệu là hồ sơ tài khoản của từng khách hàng. Phần mềm biết cách xử lý các khoản nạp và rút tiền, nhưng số dư thực tế nằm trong tệp của khách hàng, không phải bên trong chính phần mềm. Trên Ethereum, tương đương là một ngân hàng nơi phần mềm và hồ sơ của mọi khách hàng chia sẻ cùng một phòng khóa, với chương trình và trạng thái của nó không thể tách rời tại một địa chỉ duy nhất.

Bốn thuộc tính xác định cách các chương trình Solana tương tác với tài khoản:

• Các chương trình xử lý các chỉ lệnh và đọc/ghi từ các tài khoản được truyền cho chúng tại thời điểm gọi. Chúng không giữ trạng thái riêng.
• Các chương trình là không thể thay đổi sau khi triển khai, trừ khi nhà phát triển chọn trình tải có thể nâng cấp tại thời điểm triển khai.
• Chỉ chương trình sở hữu một tài khoản dữ liệu mới có thể sửa đổi trường dữ liệu của tài khoản đó. Bất kỳ người dùng nào cũng có thể gọi một chương trình, nhưng quyền ghi vào bất kỳ tài khoản nào đều được giới hạn bởi quyền sở hữu.
• Cờ executable thực thi sự phân biệt này ở cấp độ giao thức và không thể thay đổi sau khi triển khai.

Các chương trình Solana không có trạng thái, nhưng hệ thống Solana nói chung là có trạng thái. Trạng thái tồn tại lâu dài; nó nằm trong các tài khoản dữ liệu. Sự khác biệt là trạng thái luôn ở bên ngoài chương trình, không bao giờ được đóng gói bên trong nó.

Sự tách biệt này có ảnh hưởng đến hiệu suất. Bởi vì mọi giao dịch phải khai báo tài khoản nào sẽ đọc hoặc ghi trước khi thực thi bắt đầu, môi trường chạy Sealevel có thể xác định các giao dịch không chồng chéo và chạy chúng đồng thời. Giải thích đầy đủ về cách mô hình tài khoản cho phép thực thi song song theo sau.

Quyền sở hữu Tài khoản và Thẩm quyền: Ai Kiểm soát Cái gì trên Solana

Trường owner trong một tài khoản Solana xác định chương trình có quyền độc quyền sửa đổi dữ liệu của tài khoản đó. Chỉ chương trình đó, ở cấp độ giao thức, mới có thể ghi vào trường dữ liệu.

Trường owner lưu trữ một khóa công khai (Public Key) 32 byte. Đối với tài khoản ví, chủ sở hữu là Chương trình Hệ thống. Đối với tài khoản token, chủ sở hữu là Chương trình Token SPL. Đối với các tài khoản dữ liệu tùy chỉnh, chủ sở hữu là chương trình đã tạo ra chúng. Quyền sở hữu được đặt tại thời điểm tạo tài khoản và được thực thi bởi môi trường chạy Solana trên mọi giao dịch.

Hãy xem xét một hộp an toàn tại ngân hàng. Ngân hàng sở hữu hộp và là thực thể duy nhất có thể vật lý mở và sửa đổi nội dung của nó. Bạn giữ một chiếc chìa khóa cho phép bạn chỉ dẫn ngân hàng phải làm gì với hộp của mình, nhưng chỉ ngân hàng mới chạm vào nội dung. Trên Solana, chương trình là ngân hàng, và bạn là chủ tài khoản có chìa khóa.

Sự khác biệt giữa chủ sở hữu (owner) và thẩm quyền (authority) làm nhiều nhà phát triển Ethereum bối rối:

• Chủ sở hữu (trường giao thức): ID chương trình có thể sửa đổi trường data của tài khoản. Được đặt tại thời điểm tạo tài khoản. Được thực thi bởi môi trường chạy Solana, không phải bởi logic của bất kỳ chương trình nào.
• Thẩm quyền (quy ước dữ liệu): Một khóa công khai (Public Key) được lưu trữ bên trong trường data của tài khoản bởi chương trình sở hữu. Nó cho phép các hoạt động cụ thể trong logic của chương trình đó. Được thực thi bởi chính chương trình, không phải môi trường chạy.

Đối với một tài khoản token USDC, Chương trình Token là chủ sở hữu và có thể sửa đổi Số dư được lưu trữ trong trường dữ liệu. Ví của bạn là thẩm quyền chuyển khoản, một khóa công khai (Public Key) được ghi lại bên trong trường dữ liệu mà Chương trình Token kiểm tra trước khi thực hiện chuyển khoản. Đây là các khóa khác nhau thực hiện các chức năng khác nhau. Nhầm lẫn chúng là một trong những lỗi phổ biến nhất trong phát triển Solana mới.

Tiền thuê tài khoản Solana và Giải thích về Miễn tiền thuê

Tiền thuê trên Solana là một khoản phí lưu trữ, được tính bằng lamport, được thu từ các tài khoản để bù đắp cho những người xác thực vì đã duy trì trạng thái trên chuỗi (On-Chain). Các tài khoản giữ một Số dư lamport tối thiểu, ngưỡng miễn tiền thuê, sẽ vĩnh viễn được miễn phí thuê và sẽ không bao giờ bị môi trường chạy xóa bỏ.

Tiền thuê trên Solana là gì?

Những người xác thực phải lưu trữ tất cả trạng thái tài khoản đang hoạt động trong bộ nhớ. Một số lượng không giới hạn các tài khoản có Số dư bằng không sẽ là một vector từ chối dịch vụ chống lại mạng lưới, vì vậy Solana yêu cầu các tài khoản giữ một Số dư lamport tối thiểu như một cam kết thanh toán chi phí lưu trữ. Mô hình tiền thuê ban đầu tính phí theo từng epoch tương ứng với kích thước dữ liệu, với các tài khoản dưới mức tối thiểu có nguy cơ bị thu gom rác. Mô hình đó đã lỗi thời.

Theo các tham số Mainnet hiện tại của Solana (chính thức hóa trong SIMD-0084), tất cả các tài khoản mới phải được miễn tiền thuê khi tạo. Trường rent_epoch trong cấu trúc tài khoản hiện là một trường cũ.

Cách thức hoạt động của Miễn tiền thuê

Để làm cho tài khoản của bạn được miễn tiền thuê, hãy cấp vốn cho nó với ít nhất Số dư lamport tối thiểu cho kích thước dữ liệu của nó khi gửi giao dịch tạo. Theo các tham số mạng hiện tại:

• Tài khoản 0 byte (ví): khoảng 890.880 lamport (~0,00089 SOL)
• Tài khoản 165 byte (tài khoản token tiêu chuẩn): khoảng 2.039.280 lamport (~0,00204 SOL)
• Tài khoản dữ liệu 1.024 byte: khoảng 7.180.800 lamport (~0,00718 SOL)

Các giá trị này là gần đúng và có thể thay đổi theo tham số môi trường chạy. Tính toán mức tối thiểu hiện tại chính xác bằng Solana CLI hoặc phương thức RPC getMinimumBalanceForRentExemption:

solana rent 0       # miễn tiền thuê cho tài khoản 0 byte
solana rent 165     # miễn tiền thuê cho tài khoản token tiêu chuẩn

Miễn tiền thuê hoạt động giống như một khoản tiền đặt cọc an ninh cho một đơn vị lưu trữ. Bạn khóa một Số dư lamport tối thiểu để đảm bảo sự tồn tại của tài khoản trên mạng lưới. Không giống như một khoản phí, khoản đặt cọc này có thể thu hồi toàn bộ. Khi bạn đóng tài khoản, các lamport đó sẽ được trả lại cho bạn.

Đơn vị lamport được sử dụng trong các tính toán tiền thuê được định nghĩa trong phần giải phẫu tài khoản. Để làm cho tài khoản dữ liệu được miễn tiền thuê khi chương trình của bạn tạo ra nó, hãy gọi getMinimumBalanceForRentExemption(dataSize) ở phía client trước khi xây dựng giao dịch tạo, sau đó bao gồm số lượng lamport đó trong chỉ lệnh.

Solana vs. Ethereum vs. Bitcoin: So sánh các Mô hình Tài khoản

Sự khác biệt giữa Tài khoản Solana và Tài khoản Ethereum là gì?

Trên Ethereum, các Hợp đồng Thông minh gộp mã và trạng thái của chúng lại với nhau tại một địa chỉ. Một tài khoản hợp đồng giữ cả logic và dữ liệu mà nó hoạt động. Trên Solana, mã và trạng thái luôn ở các tài khoản riêng biệt: các chương trình (logic) nằm trong các tài khoản có thể thực thi, và tất cả trạng thái nằm trong các tài khoản dữ liệu riêng biệt do các chương trình đó sở hữu. Sự tách biệt này là nền tảng kiến trúc cho mọi thứ Solana làm khác biệt.

Bitcoin có một cách tiếp cận hoàn toàn khác, sử dụng mô hình UTXO (Unspent Transaction Output). UTXO giống như các séc chưa chi trong một cuốn séc: mỗi giao dịch tiêu thụ các đầu ra hiện có và tạo ra các đầu ra mới. Không có tài khoản cố định nào giữ Số dư theo thời gian. Số dư của bạn là tổng các đầu ra chưa chi được liên kết với các khóa của bạn. Mô hình của Bitcoin có trước khái niệm trạng thái có thể lập trình, đó là lý do tại sao khả năng Hợp đồng Thông minh của nó bị giới hạn ở Bitcoin Script.

Các mạng tương thích với EVM, bao gồm Ethereum, Polygon, BNB Chain và Avalanche C-Chain, đều chia sẻ cùng một mô hình tài khoản mà Solana đã loại bỏ. Một so sánh duy nhất có thể bao quát tất cả các mạng này.

Trên Ethereum, ví người dùng được gọi là Tài khoản Sở hữu Bên ngoài (EOA). Trên Solana, ví tương đương là một tài khoản do hệ thống sở hữu được kiểm soát bởi một cặp khóa (keypair); cơ chế này tương tự, nhưng trường chủ sở hữu được đặt rõ ràng là Chương trình Hệ thống thay vì ở dạng ngầm định.

Những điều nhà phát triển Ethereum phải thay đổi tư duy

Cần có ba sự thay đổi trong mô hình tư duy trước khi viết một chương trình Solana hoạt động được:

1. Các chương trình không nắm giữ trạng thái riêng. Các tài khoản dữ liệu mới làm điều đó. Ngừng tìm kiếm trạng thái tại địa chỉ chương trình.
2. Chủ sở hữu ví của bạn không phải là bạn ở cấp độ giao thức. Bạn kiểm soát tài khoản bằng cách ký; Chương trình Hệ thống sở hữu trường dữ liệu.
3. Lưu trữ không miễn phí. Mọi tài khoản dữ liệu đều yêu cầu một khoản nạp lamport để được miễn phí thuê. Hãy lập ngân sách cho chi phí này khi thiết kế các chương trình tạo tài khoản.

Sự tách biệt nghiêm ngặt giữa mã và trạng thái của Solana là điều kiện tiên quyết cho việc thực thi song song, một mối liên hệ được khám phá đầy đủ trong phần Sealevel và thực thi song song.

Cách Mô hình Tài khoản thúc đẩy Tốc độ của Solana: Sealevel và Thực thi song song

Mô hình tài khoản của Solana cho phép xử lý song song vì mọi giao dịch phải khai báo rõ ràng danh sách đầy đủ các tài khoản mà nó sẽ đọc hoặc ghi trước khi bắt đầu thực thi. Sealevel, thời gian chạy Hợp đồng Thông minh song song của Solana, sử dụng các khai báo trước đó để xác định các giao dịch chạm vào các tài khoản khác nhau và thực thi chúng đồng thời.

Dưới đây là chuỗi nhân quả, từng bước một:

1. Một giao dịch Solana bao gồm một danh sách đầy đủ tất cả các tài khoản mà nó sẽ truy cập, mỗi tài khoản được đánh dấu là chỉ đọc (read-only) hoặc đọc-ghi (read-write), trước khi bất kỳ hoạt động thực thi nào diễn ra.
2. Sealevel kiểm tra tất cả các giao dịch đang chờ xử lý trong slot hiện tại.
3. Các giao dịch chia sẻ ít nhất một tài khoản đọc-ghi sẽ được sắp xếp theo thứ tự. Các giao dịch truy cập vào các tài khoản hoàn toàn khác nhau được xác định là không xung đột.
4. Các giao dịch không xung đột được thực thi đồng thời trên nhiều lõi CPU.

EVM của Ethereum thực thi các giao dịch tuần tự dựa trên một trạng thái toàn cầu được chia sẻ. Vì trạng thái hợp đồng nằm cùng với mã hợp đồng, việc xác định các xung đột đọc/ghi sẽ yêu cầu thực thi giao dịch trước, khiến việc lập lịch tĩnh trước khi thực thi là không thể.

Hãy nghĩ về Sealevel giống như một siêu thị có nhiều làn thanh toán. Mỗi giao dịch là một người mua hàng với danh sách các mặt hàng đã khai báo. Miễn là hai người mua hàng không với lấy cùng một mặt hàng, họ sẽ thanh toán đồng thời. Solana biết trước chính xác mỗi giao dịch cần gì, bởi vì mô hình tài khoản buộc phải khai báo điều đó ngay từ đầu.

Proof of History (PoH), được phát minh bởi đồng sáng lập Solana Anatoly Yakovenko, cung cấp một đồng hồ mật mã cho phép các trình xác thực đồng ý về thứ tự giao dịch mà không cần phối hợp theo thời gian thực. Solana sử dụng Proof of Stake (PoS) để đồng thuận, nơi các trình xác thực Stake SOL để tham gia sản xuất khối, và PoH như một lớp định thời. Kết hợp với các khai báo tài khoản trước của mô hình tài khoản, kiến trúc này cho phép Sealevel xử lý các giao dịch không xung đột theo cách song song mà không cần chờ xác nhận trên toàn mạng lưới ở mỗi bước.

Mô hình tài khoản không chỉ là một kế hoạch lưu trữ riêng lẻ. Nó là điều kiện tiên quyết cho tính song song và là gốc rễ kỹ thuật cho lợi thế về thông lượng và khả năng mở rộng của Solana.

Ví dụ thực tế: Tài khoản Token, NFT và DeFi trên Solana

Mọi tài sản trên Solana, một Số dư token, một NFT, một Vị thế DeFi, đều là một tài khoản Solana với bố cục dữ liệu cụ thể. Kiến trúc trừu tượng được mô tả ở trên biểu hiện trong ba mô hình mà mọi người dùng Solana đều gặp phải.

Tài khoản Token SPL

Token SPL, tương đương với token ERC-20 của Ethereum trên Solana, được quản lý bởi Chương trình Token SPL, chương trình này sở hữu tất cả các tài khoản token trên mạng lưới. Địa chỉ ví của bạn chỉ giữ SOL (lamports). Mỗi token bạn nắm giữ, cho dù là USDC, JTO, BONK hay bất kỳ token nào khác, đều nằm trong tài khoản token chuyên dụng của riêng nó do Chương trình Token SPL sở hữu.

Trường dữ liệu của tài khoản token lưu trữ ba thông tin: địa chỉ mint token (tài khoản này giữ token nào), Public Key có thẩm quyền sở hữu (địa chỉ ví của bạn, nơi ủy quyền chuyển tiền) và Số dư token hiện tại. Trên Ethereum, tất cả số dư ERC-20 cho một token nhất định nằm bên trong ánh xạ nội bộ của hợp đồng token. Trên Solana, mỗi cặp (người dùng, token) yêu cầu tài khoản chuyên dụng của riêng nó.

Đây là lý do tại sao các ví Solana nhắc bạn tạo một tài khoản token khi nhận một token mới lần đầu tiên. Việc tạo đó yêu cầu một khoản nạp lamport miễn phí thuê khoảng 0,00204 SOL cho tài khoản 165 byte tiêu chuẩn theo các tham số mạng hiện tại.

Tài khoản Token Liên kết (ATAs)

Tài khoản Token Liên kết (ATA) là một tài khoản token có địa chỉ là một PDA được dẫn xuất xác định từ địa chỉ ví của bạn và địa chỉ mint của token. Vì địa chỉ là xác định, bất kỳ giao thức nào cũng có thể tính toán vị trí tài khoản USDC của bạn mà không cần lưu trữ bảng tra cứu. ATA là loại tài khoản token tiêu chuẩn được sử dụng bởi hầu như tất cả các ví và giao thức Solana.

ATA là một ứng dụng của dẫn xuất PDA. Bạn có thể có nhiều tài khoản token cho cùng một lần mint, nhưng ATA của bạn là tài khoản chính tắc mà các giao thức mặc định sử dụng.

NFT trên Solana

Một NFT trên Solana bao gồm ít nhất hai tài khoản: Tài khoản Mint do Chương trình Token sở hữu xác định nguồn cung của token chính xác là 1, và Tài khoản Siêu dữ liệu (Metadata Account) do Chương trình Siêu dữ liệu Token Metaplex sở hữu lưu trữ tên, ký hiệu, URI hình ảnh của NFT và cấu hình phí tác quyền. Hình ảnh NFT không được lưu trữ Trên chuỗi; chỉ có URI trỏ đến nó nằm trong tài khoản siêu dữ liệu. Số dư token (1 NFT) được lưu trữ trong một tài khoản token, giống hệt như bất kỳ token SPL nào khác.

Các giao thức DeFi trên Solana, bao gồm các sàn giao dịch phi tập trung, nền tảng cho vay và các nhóm Thanh khoản, lưu trữ mọi Vị thế người dùng, trạng thái nhóm và cấu hình giao thức trong các tài khoản dữ liệu chuyên dụng, với các PDA do chương trình sở hữu kiểm soát các quỹ chung một cách tự trị.

Tại sao Mô hình Tài khoản Solana lại quan trọng đối với SOL

Lưu ý: Phần này giải thích cách mô hình tài khoản Solana ảnh hưởng đến tiện ích kỹ thuật của SOL. Không có nội dung nào trong bài viết này cấu thành lời khuyên tài chính hoặc khuyến nghị đầu tư.

Mô hình tài khoản không chỉ là mối quan tâm của nhà phát triển. SOL, có sẵn trên các sàn giao dịch Tiền điện tử lớn, đóng vai trò là token tiện ích gốc của mạng lưới. Mô hình tài khoản là cơ chế chính thông qua đó SOL được yêu cầu và sử dụng ở lớp mạng.

SOL được sử dụng trong mô hình tài khoản thông qua ba cơ chế riêng biệt:

Tiền nạp miễn phí thuê: Mọi tài khoản trên Solana phải giữ một số dư lamport để tồn tại trên mạng lưới. Với hàng triệu tài khoản token, tài khoản dữ liệu chương trình, hồ sơ NFT và tài khoản trạng thái DeFi đang hoạt động tại bất kỳ thời điểm nào, điều này tạo ra nhu cầu cơ bản liên tục cho SOL. Những lamport này được khóa trong các tài khoản và bị loại bỏ khỏi lưu thông Thanh khoản miễn là các tài khoản đó vẫn mở.

Phí giao dịch: Mọi giao dịch tạo hoặc sửa đổi tài khoản đều phải trả một Phí cơ sở bằng lamport. Một phần của mỗi khoản phí sẽ bị đốt theo cấu trúc phí hiện tại, làm giảm Nguồn cung Lưu thông với mỗi giao dịch.

Staking của Người xác thực: Người xác thực Staking SOL để tham gia vào cơ chế đồng thuận Proof of Stake của Solana, kiếm phần thưởng cho việc xác thực các chuyển đổi trạng thái tài khoản trên mạng.

Khi hoạt động trên chuỗi tăng trưởng, có nhiều giao thức DeFi hơn, nhiều bộ sưu tập NFT hơn, nhiều đợt ra mắt token hơn, số lượng tài khoản tăng lên tương ứng. Nhiều tài khoản hơn yêu cầu nhiều SOL bị khóa trong các khoản tiền đặt cọc miễn trừ phí thuê hơn.

Các lamport bị khóa trong các tài khoản được miễn trừ phí thuê hoạt động như các khoản tiền đặt cọc bảo mật do mạng nắm giữ: không được chi tiêu, nhưng được cam kết miễn là các tài khoản đó còn mở. Khi tài khoản đóng, các lamport đó sẽ được trả lại cho chủ sở hữu.

Tài nguyên Kiến trúc Solana liên quan

Các tài khoản token dễ hiểu hơn khi xem xét cùng với Solana Program Library, trong khi tính đồng thời được giải thích trong hướng dẫn về Sealevel xử lý song song. Người đọc có thể xem trang giá SOL;) người dùng đánh giá các sản phẩm liên quan đến staking có thể xem riêng SOL Earn,) bao gồm các điều khoản và rủi ro hiện tại của nó.

FAQ: Mô hình Tài khoản Solana

Sự khác biệt giữa tài khoản Solana và tài khoản Ethereum là gì?

Trên Ethereum, một Hợp đồng Thông minh lưu trữ cả mã và trạng thái của nó tại một địa chỉ. Trên Solana, mã và trạng thái luôn ở các tài khoản riêng biệt: chương trình là các tài khoản thực thi không có trạng thái, và tất cả trạng thái nằm trong các tài khoản dữ liệu riêng biệt thuộc sở hữu của các chương trình đó. Sự tách biệt này cho phép Sealevel thực thi đồng thời các giao dịch không xung đột, điều không thể thực hiện được với mô hình trạng thái đặt chung của Ethereum.

Phí thuê (rent) trên Solana là gì và nó hoạt động như thế nào?

Phí thuê trên Solana là chi phí lưu trữ dữ liệu trên mạng, được tính bằng lamport. Thay vì trả phí liên tục, tài khoản phải Nạp một Số dư lamport tối thiểu trước, ngưỡng miễn trừ phí thuê, để tránh bị runtime xóa bỏ. Khoản Nạp có thể thu hồi: khi tài khoản bị đóng, các lamport sẽ được trả lại cho chủ sở hữu. Đối với một tài khoản token tiêu chuẩn 165 byte, khoản Nạp xấp xỉ 0,00204 SOL theo các thông số mạng hiện tại.

Địa chỉ Phái sinh từ Chương trình (PDA) trên Solana là gì?

PDA là một địa chỉ tài khoản Solana được suy ra một cách xác định từ ID chương trình và một tập hợp các giá trị hạt giống (seed). Nó không có Private Key tương ứng, do đó chỉ chương trình đã suy ra nó mới có thể ủy quyền các giao dịch thay mặt nó thông qua Cross-Program Invocation. PDA cung cấp cho các chương trình quyền kiểm soát tài khoản một cách tự động, không cần tin cậy, một yêu cầu đối với các giao thức DeFi, các thỏa thuận ký gửi NFT và các Tài khoản Token Liên kết.

Mô hình tài khoản của Solana cho phép xử lý song song như thế nào?

Mọi giao dịch Solana phải khai báo toàn bộ danh sách các tài khoản mà nó sẽ đọc hoặc ghi trước khi thực thi. Sealevel, runtime Hợp đồng Thông minh song song của Solana, sử dụng các khai báo đó để xác định các giao dịch không xung đột và thực thi chúng đồng thời trên nhiều lõi CPU. Lập lịch tĩnh này chỉ khả thi vì mã và trạng thái nằm trong các tài khoản riêng biệt, thuộc sở hữu rõ ràng, giúp phát hiện xung đột đọc/ghi trước khi thực thi bắt đầu.

Trường 'owner' trong tài khoản Solana là gì?

Trường 'owner' là một Public Key 32 byte xác định chương trình có thẩm quyền sửa đổi trường dữ liệu của tài khoản. Đối với tài khoản ví, owner là Hệ thống Chương trình (System Program). Đối với tài khoản token, owner là Chương trình Token SPL (SPL Token Program). Trường owner là một khái niệm cấp độ giao thức được thực thi bởi runtime Solana. Nó khác biệt với trường 'authority' có trong các tài khoản dữ liệu được quản lý bởi chương trình nhất định như tài khoản token.

SOL được sử dụng như thế nào trong mô hình tài khoản?

SOL được sử dụng trong mô hình tài khoản thông qua ba cơ chế: mỗi tài khoản phải giữ một Số dư lamport (SOL) để tồn tại trên mạng; việc tạo tài khoản yêu cầu SOL để cấp vốn cho khoản Nạp miễn trừ phí thuê; và những người xác thực xử lý và lưu trữ trạng thái tài khoản phải Staking SOL để tham gia vào cơ chế đồng thuận. Khi mạng lưới phát triển, nhu cầu cấu trúc đối với SOL cũng tăng theo.

Sealevel là gì và nó liên quan đến tài khoản như thế nào?

Sealevel là runtime Hợp đồng Thông minh song song của Solana. Nó có thể thực thi nhiều giao dịch đồng thời vì mô hình tài khoản của Solana yêu cầu mỗi giao dịch phải khai báo trước những tài khoản mà nó sẽ đọc hoặc ghi. Sealevel sử dụng các khai báo đó để xác định các giao dịch không xung đột và lên lịch để chúng chạy song song. Nếu không có khai báo trước của mô hình tài khoản, việc lập lịch tĩnh này sẽ không thể thực hiện được.

Sự khác biệt giữa tài khoản ví và tài khoản chương trình trên Solana là gì?

Tài khoản ví là một tài khoản thuộc sở hữu của hệ thống với trường dữ liệu trống, chỉ giữ Số dư SOL, được kiểm soát bởi một cặp khóa (keypair). Tài khoản chương trình là một tài khoản thực thi với executable = true chứa mã bytecode BPF/SBF đã biên dịch; nó thuộc sở hữu của BPF Loader và không giữ trạng thái riêng. Bảng loại tài khoản trong Phần Năm Loại Tài khoản Solana hiển thị cả năm biến thể cạnh nhau.

Một giao dịch Solana có thể tham chiếu bao nhiêu tài khoản?

Một giao dịch Solana duy nhất có thể tham chiếu tới tối đa 64 tài khoản theo thông số Mainnet hiện tại, tăng từ 32 ban đầu thông qua Bảng Tra cứu Địa chỉ (Address Lookup Tables). Mỗi tài khoản phải được khai báo chỉ đọc hoặc đọc/ghi trước khi thực thi. Khai báo trước này là điều cho phép Sealevel lên lịch thực thi song song mà không cần chạy giao dịch trước để phát hiện xung đột.

Một tài khoản Solana có thể giữ nhiều token không?

Không. Mỗi loại token SPL yêu cầu một tài khoản token riêng biệt. Một địa chỉ ví chỉ giữ SOL; mỗi token bổ sung yêu cầu một tài khoản token riêng biệt được liên kết với ví thông qua trường ủy quyền của nó. Đây là lý do tại sao ví Solana yêu cầu bạn tạo một tài khoản token mới khi nhận một token mà bạn chưa từng giữ trước đây, và tại sao việc tạo đó tốn một khoản Nạp miễn trừ phí thuê lamport nhỏ.

• Mọi phần trạng thái trên chuỗi trên Solana đều nằm trong một tài khoản với năm trường: lamports, data, owner, executable, rent_epoch.
• Chương trình thì không có trạng thái. Tất cả trạng thái đều nằm trong các tài khoản dữ liệu riêng biệt mà chương trình sở hữu và kiểm soát.
• Tài khoản yêu cầu một khoản tiền đặt cọc lamport (miễn trừ phí thuê) để tồn tại trên mạng. Khoản tiền đặt cọc có thể thu hồi khi tài khoản bị đóng.
• PDA là các địa chỉ không có Private Key, được suy ra một cách xác định từ ID chương trình và các hạt giống (seeds), chỉ có thể ký bởi chương trình đã tạo ra chúng thông qua CPI.
• Mọi giao dịch đều khai báo danh sách truy cập tài khoản của mình trước. Sealevel sử dụng các khai báo đó để thực thi đồng thời các giao dịch không xung đột.

Bước tiếp theo

• Để biết chi tiết về cách triển khai, hãy xem tài liệu tài khoản Solana) trên docs.solana.com.
• Các nhà phát triển xây dựng chương trình Solana đầu tiên có thể bắt đầu với khung Anchor,) giúp trừu tượng hóa nhiều phần mã quản lý tài khoản lặp đi lặp lại (chương trình được viết bằng Rust hoặc C/C++).
• Đối với các công thức mã thực tế và ví dụ hoạt động bằng JavaScript/TypeScript, Solana Cookbook) cung cấp tài liệu tham khảo thực tế.