Mô hình tài khoản Solana: Hướng dẫn kỹ thuật

Hướng dẫn kỹ thuật về Mô hình tài khoản Solana này giải thích các trường runtime và các quy tắc truy cập mà các chương trình dựa vào, bao gồm quyền sở hữu, tài khoản thực thi, tài khoản token, miễn phí thuê, Địa chỉ dẫn xuất chương trình, Tài khoản Token liên kết và Gọi chéo chương trình.

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 máy khách có thể thay đổi. Các 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.

Mọi giao dịch trên Solana đều chạm vào một tài khoản. Mọi token bạn nắm giữ, mọi chương trình bạn triển khai, mọi NFT bạn đúc: tất cả đều sống trong các tài khoản. Trước khi bạn viết một dòng mã Solana nào, việc hiểu cách thức hoạt động của các tài khoản không phải là kiến thức nền tảng tùy chọn. Đó là điều kiện tiên quyết cho mọi thứ khác.

Hãy nghĩ về Solana như một chiếc tủ hồ sơ. Mỗi ngăn kéo chứa một thư mục và mọi thư mục đều có nhãn (địa chỉ của nó), nội dung (dữ liệu của nó), con dấu số dư và tên bộ phận trên trang bìa cho biết chương trình nào có quyền chỉnh sửa những gì bên trong. Cho dù bạn là nhà phát triển đang di chuyển từ Ethereum, một nhà nghiên cứu đang đánh giá kiến trúc của Solana hay một sinh viên đang hình thành mô hình tinh thần đầu tiên về quản lý trạng thái Trên chuỗi, hướng dẫn này sẽ bao quát bức tranh toàn cảnh: giải phẫu tài khoản, các loại tài khoản, quy tắc sở hữu, cơ chế phí thuê, Địa chỉ dẫn xuất chương trình, so sánh song song với Ethereum và mã có chú thích để xây dựng trong thực tế.

Tổng quan về Hướng dẫn kỹ thuật Mô hình tài khoản Solana

Mô hình tài khoản Solana là kiến trúc quản lý trạng thái và lưu trữ dữ liệu của Blockchain Solana. Mọi phần trạng thái trên Solana, bao gồm số dư token, logic chương trình, dữ liệu người dùng và cấu hình hệ thống, đều được lưu trữ trong các tài khoản riêng biệt được xác định bởi các Public Key 256-bit duy nhất. Xem tài liệu tài khoản chính thức của Solana để biết đặc tả chuẩn tắc.

Mọi phần trạng thái trên Solana đều nằm trong một tài khoản. Các chương trình không lưu trữ dữ liệu của chính chúng; chúng đọc và ghi vào các tài khoản được chuyển vào chúng trong quá trình thực thi. Quyết định kiến trúc đơn lẻ này tách biệt thiết kế của Solana khỏi hầu hết các blockchain khác.

Phép ẩn dụ về tủ hồ sơ ánh xạ trực tiếp đến cấu trúc dữ liệu: tủ hồ sơ là Blockchain Solana, các thư mục là tài khoản, nhãn của mỗi thư mục là Public Key của nó (địa chỉ Trên chuỗi), nội dung của thư mục là trường dữ liệu, con dấu số dư là trường lamports và con dấu bộ phận trên bìa là trường chủ sở hữu ghi lại chương trình nào có quyền ghi. Chỉ bộ phận có tên trên con dấu đó mới có thể thay đổi những gì bên trong.

Nếu bạn chuyển từ Ethereum sang, sự khác biệt này rất quan trọng: các hợp đồng thông minh Ethereum lưu trữ trạng thái của chính chúng trong nội bộ, trong khi các chương trình Solana không có trạng thái (stateless). So sánh đầy đủ nằm trong phần dành riêng bên dưới.

Giải phẫu tài khoản Solana

Mọi tài khoản Solana, cho dù nó lưu trữ SOL, mã chương trình hay trạng thái ứng dụng, đều được xây dựng từ cùng năm trường.

Mỗi tài khoản trên Solana giữ chính xác năm trường, mỗi trường có một chức năng riêng biệt. Hiểu các trường này bằng các thuật ngữ đơn giản trước khi kiểm tra mã sẽ giúp các chi tiết kỹ thuật dễ tiếp thu hơn nhiều.

lamports: Số dư SOL cho tài khoản này, được thể hiện bằng Lamports (mệnh giá nhỏ nhất của Solana, được giải thích trong phần tiếp theo). Trong phép ẩn dụ về tủ hồ sơ, đây là giá trị tiền tệ được đóng dấu trên bìa thư mục.

data: một mảng byte thô (Vec<u8>) lưu trữ bất kỳ trạng thái nào mà chương trình sở hữu cần. Đối với tài khoản chương trình, trường này chứa mã bytecode BPF đã biên dịch. Đối với tài khoản dữ liệu, nó chứa trạng thái ứng dụng được tuần tự hóa. Các chương trình xác định định dạng tuần tự hóa của riêng chúng (thường là Borsh) để đọc và ghi dữ liệu có cấu trúc vào trường này. Tương đương trong tủ hồ sơ là nội dung vật lý bên trong thư mục.

owner: Public Key của chương trình được ủy quyền sửa đổi trường dữ liệu của tài khoản này. Không chương trình nào khác có thể ghi vào nó. Đây là con dấu bộ phận trên bìa thư mục.

executable: một cờ boolean. Khi được đặt thành true, tài khoản lưu trữ mã chương trình và có thể được thực thi. Khi là false, tài khoản là một vùng chứa dữ liệu.

rent_epoch: một trường kế thừa trước đây đã theo dõi thời gian thu phí thuê (rent). Trường này đang được loại bỏ dần và không có ý nghĩa hoạt động đối với các tài khoản miễn phí thuê, vốn là tiêu chuẩn sản xuất.

Mỗi tài khoản Solana được xác định bởi một Public Key 256-bit duy nhất bắt nguồn từ một cặp khóa ed25519, đóng vai trò là địa chỉ và mã định danh Trên chuỗi của nó. Kích thước trường dữ liệu tối đa cho một tài khoản duy nhất là 10 MB theo các bản nâng cấp giao thức gần đây; hãy xác minh các giới hạn hiện tại với tài liệu tài khoản của Solana, vì giá trị này đã thay đổi trong lịch sử của Solana.

Lamports: Đơn vị nhỏ nhất của Solana

Một Lamport là mệnh giá nhỏ nhất của SOL: 1 SOL bằng 1.000.000.000 Lamports (10⁹). Đơn vị này được đặt theo tên của Leslie Lamport, một nhà khoa học máy tính có công trình về các hệ thống phân tán và khả năng chịu lỗi là nền tảng của phần lớn lý thuyết tính toán phân tán hiện đại. Lamports tồn tại vì tất cả các phép toán Trên chuỗi, bao gồm tính toán phí thuê, phí giao dịch và Số dư tài khoản, phải sử dụng số học số nguyên để tránh các lỗi chính xác của dấu phẩy động. Việc biểu thị các giá trị bằng Lamports làm cho mọi tính toán trở nên chính xác.

Tài khoản Solana có giống với Ví không?

Một tài khoản Solana và một ví không phải là một. Những gì bạn nghĩ là ví của mình, ứng dụng Phantom hoặc Solflare trên điện thoại của bạn, là phần mềm Ngoài chuỗi quản lý Private Key. Thực thể Trên chuỗi là một tài khoản hệ thống giữ Số dư SOL của bạn. Ví của bạn kiểm soát một tài khoản hệ thống; bản thân nó không phải là một tài khoản. Tài khoản token, tài khoản chương trình và tài khoản dữ liệu không có ví tương đương: chúng thuần túy là các vùng chứa dữ liệu Trên chuỗi mà không ứng dụng ví tiêu dùng nào trực tiếp đại diện.

Các loại tài khoản Solana

Tài khoản Solana được chia thành bốn loại, mỗi loại được xác định bởi chương trình sở hữu và cờ thực thi của nó.

1. Tài khoản hệ thống (System Accounts): do Chương trình hệ thống sở hữu; được sử dụng để lưu trữ SOL và ví người dùng
2. Tài khoản chương trình (Program Accounts): các tài khoản có thể thực thi lưu trữ mã bytecode BPF đã biên dịch
3. Tài khoản dữ liệu/trạng thái (Data/State Accounts): do các chương trình sở hữu; lưu trữ trạng thái dành riêng cho ứng dụng
4. Tài khoản Token (Token Accounts): các tài khoản dữ liệu chuyên dụng do Chương trình SPL Token sở hữu (với Tài khoản Token Liên kết là tập hợp con chuẩn tắc)

Tài khoản hệ thống

Các tài khoản hệ thống thuộc sở hữu của Chương trình hệ thống và ví người dùng là các tài khoản hệ thống. Chương trình hệ thống là chương trình gốc của Solana chịu trách nhiệm cho ba hoạt động cốt lõi: tạo tài khoản mới (cấp phát không gian dữ liệu Trên chuỗi), chỉ định quyền sở hữu tài khoản (đặt trường owner cho một chương trình được chỉ định) và chuyển SOL giữa các tài khoản. Mọi tài khoản mới trên Solana đều bắt đầu dưới dạng một tài khoản hệ thống do Chương trình hệ thống sở hữu.

Chương trình hệ thống có một địa chỉ nổi tiếng: 11111111111111111111111111111111 (32 số một trong base58). Xem tài liệu về Chương trình hệ thống để biết bộ hướng dẫn đầy đủ của nó. Khi một nhà phát triển tạo một tài khoản dữ liệu cho chương trình của họ, họ sẽ gọi lệnh Tạo tài khoản của Chương trình hệ thống, chỉ định kích thước dữ liệu, khoản Nạp Lamport miễn phí thuê và Public Key của chương trình sở hữu mới.

Tài khoản chương trình

Tài khoản chương trình lưu trữ bytecode BPF đã biên dịch, không phải trạng thái. Cờ có thể thực thi trên các tài khoản này được đặt thành true. Các chương trình không có trạng thái: khi một chương trình chạy, nó nhận một danh sách các tài khoản để đọc hoặc ghi thông qua lệnh giao dịch. Nó không duy trì bất kỳ trạng thái nội bộ nào giữa các lần gọi. Nếu bạn đến từ Ethereum, bạn có thể biết mã có thể thực thi trên chuỗi là hợp đồng thông minh, nhưng các chương trình Solana hoạt động khác biệt về cơ bản vì chúng không mang theo trạng thái riêng. Tài khoản chương trình thuộc sở hữu của chương trình Tải BPF. Sau khi triển khai, tài khoản chương trình là bất biến trừ khi một cặp khóa xác quyền nâng cấp đã được chỉ định trong quá trình triển khai.

Tài khoản Dữ liệu và Trạng thái

Tài khoản dữ liệu chứa trạng thái ứng dụng mà các chương trình đọc và ghi trong quá trình thực thi. Cờ có thể thực thi trên các tài khoản này là false. Trường dữ liệu lưu trữ trạng thái do chương trình định nghĩa được tuần tự hóa bằng Borsh. Ví dụ bao gồm vị thế cho vay của người dùng trong một giao thức DeFi, siêu dữ liệu NFT, hoặc một bộ đếm ứng dụng. Chương trình sở hữu là thực thể duy nhất có thể ghi vào trường dữ liệu của tài khoản này, một quy tắc được đề cập chi tiết trong phần sở hữu.

Tài khoản Token và Tài khoản Token Liên kết

Tài khoản token là các tài khoản dữ liệu thuộc sở hữu của Chương trình Token SPL, mỗi tài khoản giữ một Số dư của một token cụ thể cho một ví cụ thể. Một địa chỉ ví duy nhất có thể giữ nhiều tài khoản token, mỗi tài khoản cho một loại token khác nhau mà nó nắm giữ.

Tài khoản Token Liên kết (ATA) là tài khoản token chuẩn cho một cặp [địa chỉ ví, địa chỉ mint] cụ thể. ATA được suy ra một cách tất định dưới dạng Địa chỉ được Chương trình Phái sinh (PDA) bằng cách sử dụng địa chỉ ví và địa chỉ mint token làm hạt giống. Điều này đảm bảo mỗi ví có chính xác một tài khoản "chính thức" cho mỗi loại token. ATA là tiêu chuẩn được sử dụng bởi các ví như Phantom và Solflare, bởi các sàn giao dịch và bởi các giao thức: khi bạn nhận được một token trong giao diện người dùng ví của bạn, nó sẽ được chuyển đến ATA của bạn cho token đó.

Nếu ATA không tồn tại cho một cặp [ví, mint] nhất định, nó phải được tạo trước khi có thể nhận token, và việc tạo tốn một khoản Nạp Lamport được miễn thuế. Đây là lý do tại sao một số giao dịch bao gồm "phí tạo tài khoản" nhỏ trong giao diện người dùng ví. Để biết đầy đủ thông số kỹ thuật ATA, hãy xem tài liệu Tài khoản Token Liên kết SPL. ATA là một tài khoản token, nhưng không phải mọi tài khoản token đều là ATA, và sự khác biệt này rất quan trọng khi gỡ lỗi các chương trình liên quan đến token.

Quyền sở hữu tài khoản: Solana Kiểm soát Truy cập Dữ liệu như thế nào

Quyền sở hữu tài khoản trong Solana là một cơ chế quyền ghi, không phải là khái niệm quyền sở hữu tài sản.

Quy tắc Sở hữu

Chỉ chương trình sở hữu tài khoản mới có thể sửa đổi trường dữ liệu của nó. Không có chương trình nào khác có thể ghi vào đó, bất kể người dùng cho phép gì ở cấp độ giao dịch. Trường chủ sở hữu trong AccountInfo lưu trữ khóa công khai của chương trình nắm giữ quyền này. Các chương trình không phải chủ sở hữu có thể đọc trường dữ liệu một cách tự do, nhưng việc ghi yêu cầu phải là chủ sở hữu được chỉ định.

Chương trình Hệ thống gán quyền sở hữu trong quá trình tạo tài khoản. Khi nhà phát triển tạo một tài khoản dữ liệu cho chương trình của họ, lệnh Tạo Tài khoản sẽ đặt trường chủ sở hữu thành khóa công khai của chương trình của họ. Quyền sở hữu có thể được gán lại, nhưng chỉ bởi chương trình chủ sở hữu hiện tại bằng cách sử dụng lệnh Gán. Không bên ngoài nào có thể chuyển quyền sở hữu một cách đơn phương.

Chủ sở hữu và quyền hạn là hai khái niệm khác nhau trong quản lý tài khoản Solana. Chủ sở hữu là chương trình được ghi trong trường chủ sở hữu của tài khoản, nghĩa là chương trình có thể ghi vào trường dữ liệu. Quyền hạn (hoặc người ký) là cặp khóa có thể ký các giao dịch cho tài khoản.

Hãy xem xét tài khoản token làm ví dụ: khóa riêng của ví bạn ký giao dịch (bạn là người có quyền hạn), nhưng Chương trình Token SPL là chủ sở hữu tài khoản token của bạn và là thực thể duy nhất có thể sửa đổi số dư token của bạn trong trường dữ liệu. Bạn có thể ủy quyền cho một giao dịch di chuyển token, nhưng việc ghi thực tế vào trường dữ liệu được thực hiện bởi Chương trình Token, không phải bởi bạn trực tiếp. Việc nhầm lẫn hai khái niệm này gây ra hầu hết các lỗi gỡ lỗi quyền sở hữu tài khoản đối với các nhà phát triển mới làm quen với Solana.

Một chương trình DEX chỉ có thể ghi vào các tài khoản mà nó sở hữu trực tiếp. Để chuyển token từ tài khoản token của người dùng (thuộc sở hữu của Chương trình Token SPL, không phải của DEX), DEX không thể ghi trực tiếp vào tài khoản đó. Các chương trình có thể gọi các chương trình khác trong cùng một giao dịch, một mẫu được gọi là Lời gọi Liên chương trình (CPI), cho phép DEX hướng dẫn Chương trình Token di chuyển token thay mặt người dùng. DEX gửi một CPI đến Chương trình Token, cung cấp sự ủy quyền đã ký của người dùng, và Chương trình Token thực hiện ghi vào trường dữ liệu tài khoản token của người dùng. Đây là cách mô hình sở hữu chương trình mở rộng đến các tương tác liên chương trình. Để xem hướng dẫn đầy đủ, hãy xem hướng dẫn Lời gọi Liên chương trình (CPI) cho nhà phát triển Solana.

Thuế Solana là một cơ chế chi phí lưu trữ, không phải phí định kỳ.

Thuế là gì?

Thuế là cơ chế định giá lưu trữ trên chuỗi của Solana. Mọi tài khoản phải duy trì Số dư SOL tối thiểu tương ứng với kích thước dữ liệu của nó để duy trì hoạt động trên chuỗi. Sự điều chỉnh mà hầu hết nội dung cạnh tranh bỏ qua: thuế trên thực tế không phải là phí định kỳ. Tiêu chuẩn sản xuất là miễn thuế, trong đó việc Nạp đủ SOL ban đầu để chi trả cho khoảng hai năm lưu trữ sẽ làm cho tài khoản được miễn trừ vĩnh viễn khỏi bất kỳ khoản khấu trừ thuế nào. Phần lớn các tài khoản được triển khai hoạt động theo hình thức miễn thuế.

Miễn thuế: Tiêu chuẩn Thực tế

Miễn thuế là tiêu chuẩn sản xuất cho tất cả các tài khoản Solana đã triển khai. Số dư tối thiểu để miễn thuế khoảng 6.960 Lamports nhân với kích thước dữ liệu của tài khoản theo byte, cộng với một khoản cơ bản khoảng 890.880 Lamports cho tài khoản không có byte nào.

Một ví dụ đã xử lý: một tài khoản dữ liệu 100 byte yêu cầu khoảng 890.880 + (6.960 × 100) = 1.586.880 Lamports, hoặc khoảng 0,00159 SOL. Các số liệu này là xấp xỉ và có thể thay đổi. Xác minh các giá trị hiện tại bằng lệnh CLI Solana solana rent <bytes> hoặc tài liệu thuế Solana. Một đề xuất thay đổi để chuyển thuế thành mô hình phí giao dịch chưa được kích hoạt tính đến thời điểm viết bài này; tham khảo tài liệu hiện tại về trạng thái giao thức mới nhất.

Điều gì xảy ra khi tài khoản hết SOL?

Việc tạo tài khoản hiện tại thường yêu cầu nguồn vốn miễn thuế. Các nhà phát triển nên truy vấn các yêu cầu RPC hiện tại thay vì dựa vào hành vi thu thuế cũ. Đây là hành vi gây ra lo ngại về việc tài khoản bị "xóa".

Các tài khoản miễn thuế không bao giờ bị đóng tự động bởi runtime. Các tài khoản sản xuất luôn được cấp vốn đến ngưỡng miễn thuế, vì vậy việc thu gom rác không ảnh hưởng đến chúng. Việc đóng tài khoản có chủ đích là một mẫu riêng biệt, có chủ ý: các chương trình có thể đóng các tài khoản dữ liệu để thu hồi khoản Nạp Lamport. Ví dụ, trong một giao thức DeFi, việc đóng một Vị thế cho vay sẽ giải phóng SOL đã cấp vốn cho tài khoản dữ liệu của Vị thế đó và trả lại cho người dùng. Đây là một mẫu thiết kế giao thức phổ biến, không phải là xóa không tự nguyện.

Giải thích Địa chỉ Phái sinh từ Chương trình (PDA)

Địa chỉ Phái sinh từ Chương trình giải quyết một vấn đề cụ thể: làm thế nào một chương trình có thể kiểm soát một tài khoản mà không có ai nắm giữ khóa riêng tương ứng.

Địa chỉ Phái sinh từ Chương trình là gì?

Địa chỉ Phái sinh từ Chương trình (PDA) là một địa chỉ tài khoản được tạo một cách tất định từ ID chương trình và một hoặc nhiều giá trị hạt giống bằng cách sử dụng băm SHA-256. PDA cố tình được đặt ngoài đường cong ed25519, nghĩa là chúng không có khóa riêng tương ứng. Chỉ chương trình sở hữu mới có thể ký các giao dịch cho các tài khoản tại địa chỉ PDA. Xem tài liệu PDA của Solana để biết thông số kỹ thuật đầy đủ.

Tất cả các địa chỉ tài khoản Solana thông thường đều nằm trên đường cong elliptic ed25519. PDA được cố tình đặt ngoài đường cong đó. Đặc tính ngoài đường cong không phải là lỗi; đó là cơ chế thiết kế khiến Private Key không thể tồn tại về mặt toán học. Không người nào, ví cứng hay hệ thống quản lý khóa nào có thể tạo ra Private Key cho PDA vì không có khóa nào tồn tại trên đường cong đó.

Tại sao PDA Quan trọng: Quyền giám sát do chương trình kiểm soát

Hậu quả của việc không có Private Key là chỉ chương trình sở hữu mới có thể ủy quyền giao dịch cho PDA. Điều này cho phép quyền giám sát do chương trình kiểm soát mà không cần tin tưởng: chương trình nắm quyền kiểm soát tài khoản mà không cần dựa vào bất kỳ con người nào để bảo vệ Private Key.

Ba Trường hợp Sử dụng PDA Thực tế

So sánh điều này với các tài khoản cặp khóa thông thường, nơi bất kỳ ai nắm giữ Private Key đều kiểm soát tài khoản. Nếu khóa bị mất, quyền truy cập sẽ biến mất. Nếu khóa bị đánh cắp, tài khoản sẽ bị xâm phạm. PDA loại bỏ hoàn toàn sự phụ thuộc này. Logic của chương trình là người giám sát, là mã có thể kiểm toán chứ không phải là con người.

Ba Trường hợp Sử dụng PDA Thực tế

PDA xuất hiện trong ba mẫu lặp lại trên các chương trình Solana.

DEX tài khoản ký quỹ: một chương trình sàn giao dịch phi tập trung nắm giữ token trong một PDA cho đến khi cả hai bên của một giao dịch hoán đổi đáp ứng các điều kiện cần thiết. Không có trung gian đáng tin cậy nào nắm giữ Private Key của tài khoản ký quỹ. Logic của chương trình kiểm soát việc giải phóng, và không người tham gia nào có thể rút tiền ngoài các quy tắc của giao thức.

Không cá nhân nào có thể "rút vốn" thẩm quyền phát hành của một bộ sưu tập NFT. Thẩm quyền phát hành NFT hoạt động bằng cách có các chương trình Metaplex kiểm soát việc phát hành thông qua PDA có nguồn gốc từ địa chỉ phát hành. Vì không có Private Key cho PDA này, các quy tắc phát hành của bộ sưu tập được thực thi bởi mã chương trình một mình sau khi triển khai.

Làm thế nào một chương trình lưu trữ dữ liệu cho từng người dùng mà không duy trì một chỉ mục tập trung? Lưu trữ trạng thái cho từng người dùng sử dụng một PDA duy nhất có nguồn gốc từ [program_id, user_pubkey]. Điều này tạo ra một địa chỉ tài khoản xác định, dành riêng cho người dùng để lưu trữ điểm số trò chơi, vị thế cho vay hoặc hồ sơ Staking của người dùng đó. Chương trình luôn biết tìm dữ liệu của mỗi người dùng ở đâu.

Các hàm findProgramAddress() và createProgramAddressSync() định vị các địa chỉ ngoài đường cong hợp lệ bằng cách kiểm tra các địa chỉ ứng viên với một bộ seed tăng dần cho đến khi một địa chỉ nằm ngoài đường cong.

Khi nào nên Sử dụng PDA?

Sử dụng PDA bất cứ khi nào chương trình của bạn cần kiểm soát một tài khoản mà không cần dựa vào Private Key của con người. Nếu thẩm quyền tài khoản nên là logic chương trình thay vì một người, hãy sử dụng PDA. Quy tắc này bao gồm các tài khoản ký quỹ, kho tiền của giao thức, thẩm quyền phát hành và bất kỳ trạng thái nào mà chính chương trình phải sở hữu và quản lý trên nhiều người dùng.

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

Sự khác biệt cốt lõi giữa các mô hình tài khoản của Solana và Ethereum là nơi trạng thái tồn tại.

Trong Ethereum, các hợp đồng thông minh có trạng thái: chúng lưu trữ trạng thái của riêng mình bên trong cùng với mã của chúng. Một hợp đồng Solidity giữ các ánh xạ và biến trạng thái của riêng nó trong bộ lưu trữ hợp đồng, được quản lý bởi máy ảo Ethereum (EVM). Trong Solana, các chương trình không có trạng thái; tất cả trạng thái tồn tại trong các tài khoản bên ngoài mà các chương trình đọc và ghi trong quá trình thực thi. Nơi Ethereum chạy các chương trình trong EVM, Solana sử dụng một runtime dựa trên BPF thực thi các chương trình chống lại các tài khoản được khai báo trước trong giao dịch.

Các đánh đổi diễn ra theo cả hai hướng. Mô hình có trạng thái của Ethereum mang lại lợi thế trải nghiệm nhà phát triển thực sự: mô hình tư duy đơn giản hơn, không cần quản lý tài khoản rõ ràng, chi phí nhận thức thấp hơn cho nhiều trường hợp sử dụng. Nhà phát triển có thể viết và triển khai hợp đồng ERC-20 mà không cần nghĩ về kích thước tài khoản dữ liệu, tiền gửi miễn phí thuê hoặc suy luận PDA.

Mô hình không có trạng thái của Solana đánh đổi sự đơn giản đó để lấy song song hóa thực thi và phân tách mối quan tâm. Các khai báo tài khoản được yêu cầu bởi mọi giao dịch là đầu vào cho thuật toán lập lịch của Sealevel, thuật toán này thực thi đồng thời các giao dịch không chồng chéo. Các blockchain Lớp 1 khác như Aptos và Sui áp dụng các biến thể của riêng họ về phân tách trạng thái dựa trên tài nguyên, mỗi loại có hồ sơ đánh đổi khác nhau. Cách tiếp cận của Ethereum hoặc Solana không có cách nào vượt trội hơn một cách rõ ràng; chúng phản ánh các ưu tiên thiết kế khác nhau cho các khối lượng công việc khác nhau.

Tại sao Kiến trúc này Quan trọng: Sealevel và Thực thi Song song

Các chương trình không có trạng thái không phải là một ràng buộc thiết kế; chúng là cơ chế làm cho thực thi song song trở nên khả thi.

Chuỗi nhân quả từ thiết kế mô hình tài khoản đến hiệu suất hoạt động như sau. Đầu tiên, các chương trình Solana không có trạng thái. Thứ hai, vì các chương trình không mang theo bất kỳ trạng thái nào, mọi giao dịch phải khai báo tất cả các tài khoản mà nó sẽ truy cập, cả đọc và ghi, trước khi thực thi bắt đầu. Thứ ba, công cụ thực thi song song của Solana, Sealevel, phân tích các danh sách truy cập tài khoản này trước khi lập lịch. Thứ tư, các giao dịch truy cập các tập hợp tài khoản không chồng chéo lên nhau không có sự phụ thuộc dữ liệu vào nhau và có thể thực thi đồng thời trên nhiều lõi xử lý. Thứ năm, kết quả là một mạng lưới có khả năng xử lý hàng chục nghìn giao dịch mỗi giây.

Anatoly Yakovenko đã thiết kế kiến trúc của Solana với mục tiêu rõ ràng là xử lý giao dịch song song, và việc tách logic chương trình khỏi trạng thái tài khoản là những gì làm cho điều đó trở nên khả thi. Mô hình tài khoản hoạt động cùng với các đổi mới kiến trúc khác của Solana, bao gồm cả Proof of History (PoH), cơ chế đồng hồ mật mã của Solana. Để hiểu PoH đóng góp như thế nào vào thông lượng này, hãy xem phần giải thích về cách Proof of History hoạt động trong kiến trúc của Solana.

Mọi tài khoản mà chương trình Solana làm việc phải được tạo, cấp vốn và gán cho một chủ sở hữu trước khi chương trình có thể đọc hoặc ghi vào nó.

Tạo Tài khoản với Chương trình Hệ thống

Các chương trình Solana được viết bằng Rust, một ngôn ngữ lập trình hệ thống, và được biên dịch thành bytecode BPF trước khi triển khai. Việc tạo một tài khoản trên Solana tuân theo các bước sau, mỗi bước tương ứng với một tham số trong chỉ thị Tạo Tài khoản của Chương trình Hệ thống:

1. from_pubkey: xác định tài khoản cấp vốn cho việc tạo (người thanh toán)
2. new_account_pubkey: chỉ định địa chỉ của tài khoản mới
3. lamports: tính toán số dư miễn phí thuê dựa trên kích thước dữ liệu
4. space: đặt kích thước dữ liệu theo byte để phân bổ cho tài khoản
5. owner: chỉ định khóa công khai của chương trình sẽ sở hữu và ghi vào tài khoản này

// Create a new data account using the System Program
let create_account_ix = system_instruction::create_account(
    &payer.pubkey(),         // from_pubkey: who funds this account
    &new_account.pubkey(),   // new_account_pubkey: the account's address
    rent_exempt_balance,     // lamports: enough to be rent-exempt
    data_size as u64,        // space: bytes allocated for account data
    &program_id,             // owner: the program that controls this account
);

Chỉ thị này thiết lập quyền sở hữu tài khoản. Sau khi nó thực thi, chỉ chương trình tại program_id mới có thể ghi vào trường dữ liệu của tài khoản này.

Sử dụng Anchor Framework

Nhiều chương trình Solana được xây dựng với Anchor framework, cung cấp các macro có cấu trúc để định nghĩa các ràng buộc tài khoản và chỉ thị chương trình. Xem tài liệu Anchor) để biết tài liệu tham khảo đầy đủ về framework.

// Anchor: xác định các ràng buộc tài khoản bằng cách sử dụng macro #[derive(Accounts)]
#[derive(Accounts)]
pub struct Initialize<'info> {
    #[account(
        init,                        // tạo tài khoản này nếu nó chưa tồn tại
        payer = user,                // người dùng trả khoản nạp được miễn tiền thuê
        space = 8 + MyData::LEN,    // 8-byte discriminator + kích thước dữ liệu
    )]
    pub my_account: Account<'info, MyData>,     // tài khoản dữ liệu mới
    #[account(mut)]
    pub user: Signer<'info>,                    // người ký giao dịch và người thanh toán
    pub system_program: Program<'info, System>, // bắt buộc để tạo tài khoản
}

Anchor tự động xử lý các khuôn mẫu xác thực tài khoản, xác minh quyền sở hữu và trạng thái người ký trước khi logic lệnh của bạn chạy. Việc hiểu mô hình tài khoản cơ bản vẫn cần thiết khi gỡ lỗi các lỗi sở hữu hoặc thiết kế cấu trúc PDA, bởi vì các macro của Anchor là sự trừu tượng hóa trên cùng các cơ chế được mô tả xuyên suốt bài viết này.

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

Các nhà phát triển đang tìm kiếm lộ trình triển khai ngắn hơn có thể sử dụng hướng dẫn mô hình tài khoản tập trung vào nhà phát triển; các quy ước chương trình token được đề cập trong phần tổng quan về Thư viện chương trình Solana. Trang giá SOL và thị trường Giao ngay SOL/USDT liên quan đến việc tiếp cận thị trường, không phải quyền sở hữu tài khoản hay thẩm quyền chương trình.

Câu hỏi thường gặp: Mô hình tài khoản Solana: Hướng dẫn kỹ thuật

Tài khoản trong Solana là gì?

Tài khoản Solana là một vùng chứa dữ liệu Trên chuỗi được xác định bằng một Public Key 256-bit duy nhất. Mỗi tài khoản lưu trữ một Số dư SOL tính bằng Lamports, một trường dữ liệu (một mảng byte chứa trạng thái chương trình hoặc mã bytecode), một trường chủ sở hữu (Public Key của chương trình được ủy quyền sửa đổi dữ liệu) và một cờ thực thi cho biết tài khoản đó có lưu trữ mã chương trình hay không.

Trong Ethereum, các hợp đồng thông minh lưu trữ trạng thái của chính chúng nội bộ bên cạnh mã của chúng. Trong Solana, các chương trình là phi trạng thái (stateless); tất cả trạng thái nằm trong các tài khoản bên ngoài mà các chương trình đọc và ghi trong quá trình thực thi. Sự tách biệt này cho phép thời gian chạy Sealevel của Solana phát hiện các mẫu truy cập tài khoản không trùng lặp và thực hiện nhiều giao dịch cùng một lúc, cho phép xử lý song song ở quy mô lớn.

Tất cả các tài khoản Solana đang hoạt động đều được nạp tiền đến ngưỡng miễn tiền thuê, giúp chúng được miễn các khoản phí lưu trữ vĩnh viễn. Thuê (Rent) là cơ chế cơ bản: các tài khoản phải duy trì một Số dư SOL tối thiểu tỷ lệ thuận với kích thước dữ liệu của chúng để duy trì hoạt động Trên chuỗi. Các tài khoản miễn tiền thuê, những tài khoản được nạp tiền trên ngưỡng, không bao giờ bị đóng tự động bởi thời gian chạy (runtime).

Địa chỉ dẫn xuất từ chương trình (Program Derived Address - PDA) là một địa chỉ tài khoản được tạo theo phương pháp xác định, có nguồn gốc từ một ID chương trình và các giá trị seed bằng cách sử dụng băm SHA-256. Các PDA nằm ngoài đường cong elliptic ed25519, vì vậy chúng không có Private Key tương ứng. Chỉ chương trình sở hữu mới có thể ký các giao dịch cho các tài khoản tại địa chỉ PDA, cho phép quyền lưu ký do chương trình kiểm soát mà không cần tin cậy cho các tài khoản ký quỹ, thẩm quyền đúc tiền và lưu trữ trạng thái cho mỗi người dùng.

Việc tạo tài khoản hiện tại thường yêu cầu nạp tiền để được miễn tiền thuê. Các nhà phát triển nên truy vấn các yêu cầu RPC hiện tại thay vì dựa vào hành vi thu tiền thuê cũ. Các tài khoản sản xuất được triển khai đúng cách luôn được nạp tiền đến ngưỡng miễn tiền thuê và không bao giờ bị xóa tự động. Các chương trình cũng có thể chủ động đóng tài khoản để thu hồi khoản Số dư SOL đã nạp, một mô hình phổ biến trong các giao thức DeFi.

Lamports là mệnh giá nhỏ nhất của SOL trên Blockchain Solana: 1 SOL tương đương với 1.000.000.000 Lamports (10⁹). Được đặt theo tên của Leslie Lamport, một người tiên phong trong lĩnh vực tính toán phân tán, Lamports được sử dụng cho tất cả các Số dư SOL, phí giao dịch và tính toán tiền thuê Trên chuỗi. Việc định giá số tiền bằng Lamports giúp tránh các lỗi độ chính xác của dấu phẩy động phát sinh từ việc sử dụng các giá trị SOL phân số trong số học Trên chuỗi.

Chương trình Hệ thống (System Program) là chương trình gốc của Solana chịu trách nhiệm cho ba hoạt động cốt lõi: tạo tài khoản mới (cấp phát không gian dữ liệu Trên chuỗi), chỉ định quyền sở hữu tài khoản (thiết lập trường chủ sở hữu cho một chương trình cụ thể) và chuyển SOL giữa các tài khoản hệ thống. Mỗi tài khoản Solana mới đều bắt đầu như một tài khoản hệ thống. Các nhà phát triển gọi lệnh Create Account của Chương trình Hệ thống để cung cấp các tài khoản dữ liệu cho chương trình của họ.

Có ba loại tài khoản chính trong Solana: (1) Tài khoản hệ thống (System Accounts), do Chương trình Hệ thống sở hữu và được sử dụng cho Số dư SOL và ví người dùng; (2) Tài khoản chương trình (Program Accounts), tài khoản thực thi lưu trữ mã bytecode BPF đã biên dịch; (3) Tài khoản dữ liệu/trạng thái (Data/State Accounts), do các chương trình sở hữu và lưu trữ trạng thái cụ thể của ứng dụng. Tài khoản Token là một tập hợp con chuyên biệt của tài khoản dữ liệu do SPL Token Program sở hữu.

Mô hình tài khoản của Solana đòi hỏi nhiều tư duy ban đầu hơn so với mô hình có trạng thái của Ethereum, nhưng sự đầu tư trí tuệ đó chính là điều giúp việc thực thi song song trở nên khả thi.

• Mọi phần trạng thái trên Solana đều nằm trong một tài khoản; các chương trình đọc và ghi vào các tài khoản được truyền trong quá trình thực thi, không phải bộ nhớ lưu trữ nội bộ
• Mỗi tài khoản có năm trường: lamports, dữ liệu, chủ sở hữu, có thể thực thi và rent_epoch (cũ)
• Chỉ chương trình chủ sở hữu mới có thể sửa đổi trường dữ liệu của tài khoản; đây là cơ chế kiểm soát truy cập chính của Solana
• Các tài khoản sản xuất được nạp tiền đến ngưỡng miễn tiền thuê và không bao giờ bị thời gian chạy tự động thu hồi dữ liệu rác
• Các địa chỉ dẫn xuất từ chương trình (PDA) cho phép quyền lưu ký do chương trình kiểm soát mà không cần tin cậy bằng cách sử dụng các địa chỉ ngoài đường cong không có Private Key
• Thời gian chạy Sealevel của Solana song song hóa việc thực thi giao dịch bằng cách phân tích danh sách truy cập tài khoản được khai báo qua các giao dịch không xung đột

Bạn đã sẵn sàng xây dựng trên nền tảng này chưa? Tiếp tục với:

• Cách các chương trình Solana hoạt động: hướng dẫn dành cho nhà phát triển về thực thi phi trạng thái
• Hướng dẫn khung Anchor để xây dựng các chương trình Solana
• Giải thích về Gọi chéo chương trình (CPI): cách các chương trình Solana gọi lẫn nhau
• Cách hoạt động của Proof of History trong kiến trúc của Solana

Để biết các thông số kỹ thuật giao thức mới nhất về kích thước tài khoản, tính toán tiền thuê và hành vi thời gian chạy, hãy tham khảo trực tiếp tài liệu tài khoản chính thức của Solana.