Solana (SOL): Cách thức hoạt động của giao dịch và trình xác thực

Trạng thái nằm trong các tài khoản

Mọi phần trạng thái bền vững của Solana được giữ trong một tài khoản được xác định bởi địa chỉ 32 byte. Một tài khoản ghi lại lamports, dữ liệu, chương trình sở hữu và các trường liên quan đến thực thi. Chủ sở hữu là chương trình được phép thay đổi dữ liệu tài khoản đó; nó không nhất thiết là người kiểm soát khóa ví.

Các chương trình Solana là các tài khoản thực thi chứa mã bytecode sBPF. Một chương trình thường được coi là không trạng thái vì trạng thái ứng dụng có thể thay đổi nằm trong các tài khoản riêng biệt được cung cấp cho mỗi lệnh. Điều này cho phép runtime thấy các tài khoản mà một giao dịch sẽ đọc hoặc ghi trước khi thực thi và lên lịch công việc không tranh chấp cùng một trạng thái ghi được.

Ví, tài khoản token và PDA

Một địa chỉ ví có thể sở hữu SOL và ủy quyền giao dịch, nhưng số dư token SPL thường nằm trong một tài khoản token liên kết với một mint và chủ sở hữu. Một địa chỉ dẫn xuất chương trình được dẫn xuất một cách xác định từ ID chương trình và hạt giống; chương trình có thể ủy quyền cho nó thông qua các quy tắc runtime mặc dù không có khóa riêng tư cho địa chỉ đó.

Trước khi gửi token, hãy xác nhận mint, tài khoản token đích và chương trình được gọi. Một mã ticker hoặc nhãn ví quen thuộc không phải là bằng chứng rằng mint là chính thống. Đóng, tạo hoặc phân bổ lại tài khoản cũng có thể di chuyển lamports, vì vậy tóm tắt giao dịch nên được xem xét ngoài số lượng token chính.

Thông điệp, chữ ký và lệnh

Thông điệp liệt kê các địa chỉ tài khoản, một blockhash gần đây và các lệnh được biên dịch. Mỗi lệnh đặt tên một chương trình và xác định các tài khoản mà nó có thể sử dụng. Những người ký bắt buộc ủy quyền cho thông điệp, và các giao dịch có phiên bản có thể sử dụng bảng tra cứu địa chỉ để tham chiếu nhiều tài khoản hơn mà không cần đặt mọi địa chỉ trực tiếp trong gói.

Tính mới và xác nhận

Một blockhash gần đây ngăn một giao dịch thông thường vẫn hợp lệ vô thời hạn. Nếu nó hết hạn trước khi xử lý, giao dịch phải được xây dựng lại và ký lại; phát lại chữ ký cũ không tạo ra một giao dịch mới. Các quy trình nonce bền vững tồn tại cho việc ký ngoại tuyến hoặc ký trễ chuyên biệt và yêu cầu xử lý riêng.

Các máy khách RPC hiển thị các mức cam kết processed, confirmed và finalized. Một giao diện nhanh có thể hiển thị kết quả processed trước khi đạt được sự đồng thuận mạnh hơn của cụm. Các khoản gửi, cầu nối và hành động ứng dụng phụ thuộc nên chờ mức mà dịch vụ đó yêu cầu và nên xác minh chữ ký thông qua một RPC hoặc explorer hiện tại.

Thành phần cơ bản và ưu tiên

Mỗi giao dịch trả một khoản phí cơ bản bằng SOL cho các chữ ký bắt buộc. Giao thức biểu thị SOL bằng lamports, và do đó số tiền cơ bản phụ thuộc vào số lượng chữ ký chứ không phải giá trị của một khoản thanh toán hoặc hoán đổi token. Một giao dịch thất bại có thể tiêu tốn phí cơ bản vì việc xác minh chữ ký và thực thi đã được thử.

Một khoản phí ưu tiên tùy chọn dựa trên giới hạn đơn vị tính toán được yêu cầu và giá đơn vị tính toán đã chọn. Giới hạn là một ngân sách, không phải dự đoán về mức sử dụng thực tế, vì vậy đặt nó cao hơn nhiều so với cần thiết có thể trả quá mức cho thành phần ưu tiên. Ước tính của ví nên sử dụng các điều kiện gần đây và mô phỏng giao dịch thay vì sao chép một khoản phí cố định từ ứng dụng khác.

Kiểm tra vận hành

Giữ đủ SOL cho phí ngay cả khi tài sản được chuyển là token SPL. Xem lại mọi chỉ dẫn ngân sách tính toán, vì chúng có thể thay đổi giới hạn được yêu cầu và giá ưu tiên. Cũng phân biệt phí giao dịch với việc cấp vốn tài khoản, số dư liên quan đến tiền thuê, tác động giá hoán đổi và phí ứng dụng; chúng là các chi phí riêng biệt ngay cả khi một ví tóm tắt chúng cùng nhau.