Yêu cầu Máy chủ Xác thực Solana: Phần cứng & Chi phí

Lưu ý xem xét nguồn: Thông số kỹ thuật phần cứng, chi phí lưu trữ, tiêu chí SFDP và APY Staking thay đổi theo thời gian. Xác minh tất cả các thông số hiện tại trước khi cung cấp.

Yêu cầu Máy chủ Xác thực Solana: Tại sao chúng Quan trọng

Các yêu cầu máy chủ xác thực Solana bao gồm năng lực phần cứng, chi phí vận hành, nguồn vốn tài khoản, phần mềm và giám sát liên tục. Máy chủ xác thực Solana (SOL) là một nút mạng bỏ phiếu về tính hợp lệ của các khối giao dịch, kiếm phần thưởng từ việc phát hành SOL có tính lạm phát và phí giao dịch, đồng thời tạo thành xương sống đồng thuận phi tập trung của mainnet-beta Solana (mạng sản xuất trực tiếp của Solana, nơi ký hiệu "beta" là tên cũ và không chỉ ra sự không ổn định). Để có giới thiệu tổng quát hơn, hãy xem máy chủ xác thực Solana là gì. Các máy chủ xác thực cũng là xương sống hạ tầng của hệ sinh thái DeFi Solana: khi các máy chủ xác thực hoạt động kém, mọi ứng dụng trên mạng đều cảm nhận được hậu quả.

Trong ước tính nguồn, Solana mainnet-beta có khoảng 1.500 đến 1.800 máy chủ xác thực hoạt động (Nguồn: validators.app

Hướng dẫn này bao gồm ba khía cạnh mà mọi nhà khai thác máy chủ xác thực tiềm năng cần đánh giá: thông số kỹ thuật phần cứng, kinh tế (bao gồm phí bỏ phiếu và phân tích hòa vốn), và các tiêu chí đủ điều kiện của Chương trình Ủy quyền của Quỹ Solana (SFDP) xác định xem Quỹ có cấp vốn ban đầu cho stake của bạn hay không.

Đối tượng của Hướng dẫn này. Hướng dẫn này nhắm đến các kỹ sư DevOps, nhà khai thác hạ tầng và người chạy nút có kinh nghiệm đang đánh giá việc tham gia làm máy chủ xác thực Solana. Nếu bạn đang chạy máy chủ xác thực trên Ethereum, Cosmos hoặc các mạng khác và đang đánh giá Solana, các phần về phần cứng và kinh tế sẽ cung cấp dữ liệu dành riêng cho Solana mà bạn cần. Người dùng tiền điện tử lần đầu nên làm quen với staking Solana trước khi đánh giá hoạt động của máy chủ xác thực.

Mục lục:

1. Yêu cầu Máy chủ Xác thực Solana: Tại sao chúng Quan trọng
2. Máy chủ Xác thực Solana Hoạt động Như thế nào
3. Yêu cầu Phần cứng Máy chủ Xác thực Solana
4. Phần mềm Máy chủ Xác thực: Chọn Client của bạn
5. Yêu cầu SOL: Tài khoản, Stake Staking và Phí Bỏ phiếu
6. Chi phí Chạy Máy chủ Xác thực Solana là bao nhiêu?
7. Phần thưởng Máy chủ Xác thực Solana Hoạt động Như thế nào
8. Chương trình Ủy quyền của Quỹ Solana (SFDP): Cách Đủ điều kiện
9. Máy chủ Xác thực Solana so với Máy chủ Xác thực Ethereum: So sánh Yêu cầu
10. Giám sát Máy chủ Xác thực Solana của bạn: Công cụ và Chỉ số Hiệu suất
11. Cách Trở thành Máy chủ Xác thực Solana: Tổng quan Thiết lập
12. Các Câu hỏi Thường gặp về Yêu cầu Máy chủ Xác thực Solana
13. Chạy Máy chủ Xác thực Solana có Phù hợp với bạn không? Một Khung quyết định

Máy chủ Xác thực Solana Hoạt động Như thế nào

Solana là một blockchain Proof of Stake, nghĩa là các máy chủ xác thực gửi SOL làm tài sản thế chấp kinh tế để tham gia xác thực khối và kiếm phần thưởng tương ứng với lượng stake được ủy quyền của họ. Solana mở rộng Proof of Stake (PoS) tiêu chuẩn với hai cải tiến kiến trúc là nguồn trực tiếp của các yêu cầu phần cứng cao cấp: Proof of History và Tower BFT.

Proof of History: Đồng hồ Mã hóa của Solana

Proof of History (PoH) là đồng hồ mã hóa của Solana. Nó tạo ra một chuỗi băm SHA-256 được cập nhật liên tục, đóng dấu thời gian cho mọi sự kiện trên mạng. Các máy chủ xác thực phải xử lý và xác minh chuỗi PoH này theo thời gian thực. Chúng không thể nhóm hoặc hoãn công việc này. Việc tính toán SHA-256 liên tục đó là lý do chính khiến Solana yêu cầu hiệu suất CPU đơn nhân cao và ổ NVMe (Bộ nhớ phi lưu Express) nhanh mà các máy chủ xác thực Lớp 1 khác có thể hoạt động mà không cần. PoH không phải là một cơ chế đồng thuận độc lập; nó là một hàm trì hoãn có thể xác minh cung cấp dòng thời gian chia sẻ mà Tower BFT sử dụng để bỏ phiếu.

Tower BFT và Giao dịch Bỏ phiếu

Tower BFT là thuật toán đồng thuận của Solana, cụ thể là một phiên bản sửa đổi của Practical Byzantine Fault Tolerance (PBFT) sử dụng dòng thời gian PoH làm đồng hồ chia sẻ để bỏ phiếu. Không giống như PBFT tiêu chuẩn hoặc Tendermint BFT (được sử dụng bởi Cosmos), cơ chế khóa lạc quan của Tower BFT giảm bớt chi phí nhắn tin, cho phép thông lượng máy chủ xác thực cao của Solana. Mỗi phiếu bầu mà máy chủ xác thực bỏ ra là một giao dịch được gửi trên chuỗi. Các giao dịch bỏ phiếu đó tích lũy khoảng 1 SOL mỗi ngày dưới dạng phí trên mainnet-beta. Chi phí liên tục đó là chi phí vận hành cố định bất kể bạn nắm giữ bao nhiêu lượng stake được ủy quyền.

Epoch và Thời gian Phần thưởng

Một epoch là kỳ kế toán cơ bản của Solana: khoảng 2 ngày (432.000 slot với khoảng 400ms mỗi slot). Tại mỗi điểm chuyển epoch, phần thưởng cho máy chủ xác thực sẽ được phân phối, lượng stake được ủy quyền mới sẽ có hiệu lực và lịch trình lãnh đạo cho epoch tiếp theo sẽ được công bố. Hai hệ quả thực tế sau đó: thứ nhất, hãy lên kế hoạch dòng tiền của bạn theo chu kỳ phần thưởng khoảng 2 ngày; thứ hai, lượng stake được ủy quyền mới sẽ mất một epoch đầy đủ để kích hoạt và bắt đầu tạo ra phần thưởng, do đó các máy chủ xác thực mới sẽ đối mặt với khoảng thời gian chờ đợi trước khi đạt được đủ điều kiện nhận phần thưởng đầy đủ.

Yêu cầu Phần cứng Máy chủ Xác thực Solana

Các máy chủ xác thực Solana yêu cầu phần cứng mạnh mẽ hơn đáng kể so với hầu hết các mạng Lớp 1 khác vì xử lý Proof of History đòi hỏi tính toán SHA-256 thông lượng cao liên tục, và các máy chủ xác thực phải phát lại toàn bộ sổ cái theo thời gian thực với tốc độ 400ms của Solana.

Bảng dưới đây phản ánh các thông số kỹ thuật lấy từ tài liệu thiết lập máy chủ xác thực Solana

Yêu cầu Phần cứng Máy chủ Xác thực Solana. Lưu ý xem xét nguồn: Nguồn: docs.solanalabs.com/operations/setup-a-validator. Xác minh các yêu cầu hiện tại trước khi cung cấp. Các yêu cầu tối thiểu về phần cứng Solana đã tăng theo thời gian khi trạng thái mạng phát triển.

Cảnh báo: SSD SATA không đủ điều kiện. Các ổ SSD SATA tiêu chuẩn không thể đáp ứng yêu cầu về lưu lượng I/O của sổ cái và cơ sở dữ liệu tài khoản của Solana. Chỉ các ổ NVMe PCIe Gen3 mới đáp ứng mức tối thiểu; NVMe PCIe Gen4 là tiêu chuẩn sản xuất. Một validator chạy lưu trữ SATA sẽ bị lỡ lượt bỏ phiếu và tích lũy tỷ lệ bỏ qua (skip rate) cao.

Lựa chọn CPU

Tốc độ xung nhịp đơn nhân cao thúc đẩy hiệu suất Proof of History hơn là số lượng nhân. Chuỗi băm SHA-256 làm cơ sở cho PoH là đơn luồng trong lộ trình quan trọng của nó. Một máy chủ 24 nhân chạy ở tốc độ 3,5 GHz vượt trội hơn máy chủ 48 nhân chạy ở tốc độ 2,0 GHz trong việc xử lý PoH. Các dòng AMD EPYC 7003 (Milan) và các nền tảng Intel Xeon Ice Lake hoặc Sapphire Rapids đạt được cấu hình hiệu suất bắt buộc. Nên tránh sử dụng CPU ảo của đám mây: các vCPU chia sẻ nhân dẫn đến sự biến động về xung nhịp, gây ra sự chậm trễ trong xử lý PoH và lỡ lượt bỏ phiếu.

RAM và Cơ sở dữ liệu tài khoản

RAM 128 GB là có thể duy trì được, nhưng bạn sẽ phải trả giá. Các validator chạy ở mức tối thiểu sẽ phải đẩy bộ nhớ đệm (spill cache) sang ổ NVMe chứa tài khoản trong các giai đoạn khối lượng giao dịch cao, và lượng I/O bị tràn đó sẽ biểu hiện dưới dạng tỷ lệ bỏ qua tăng lên. Với 256 GB, cơ sở dữ liệu tài khoản sẽ nằm phần lớn trong bộ nhớ. RAM ECC (Mã sửa lỗi) là bắt buộc vì các lỗi bộ nhớ trong môi trường validator đang hoạt động sẽ gây ra tình trạng hỏng trạng thái âm thầm, làm giảm khả năng tham gia đồng thuận.

Kiến trúc lưu trữ NVMe

Cấu hình được khuyến nghị sử dụng hai ổ NVMe riêng biệt: một ổ cho HĐH và dữ liệu sổ cái, một ổ dành riêng cho cơ sở dữ liệu tài khoản. Sự tách biệt này ngăn việc ghi sổ cái cạnh tranh với việc đọc cơ sở dữ liệu tài khoản trong các giai đoạn tải cao. PCIe Gen3 là mức tối thiểu; PCIe Gen4 tăng gấp đôi băng thông khả dụng và là tiêu chuẩn sản xuất. Hai ổ đĩa cũng cung cấp lộ trình cấu hình cho RAID hoặc dự phòng dựa trên bản chụp nhanh (snapshot).

Kết nối mạng

Kết nối đối xứng 1 Gbps là mức tối thiểu để hoạt động, nhưng các validator Mainnet sản xuất thường xuyên cần 10 Gbps trong các giai đoạn lưu lượng truy cập cao. Vị trí địa lý so với các validator có lượng stake cao rất quan trọng: độ trễ mạng thấp hơn đối với đa số tuyệt đối (supermajority) của cụm sẽ giúp giảm độ trễ lan truyền phiếu bầu và cải thiện tỷ lệ tham gia bỏ phiếu của bạn. Kết nối internet gia đình thiếu tính nhất quán về tốc độ tải lên mà nhịp độ phát sóng phiếu bầu của Solana yêu cầu.

Máy chủ vật lý (Bare Metal) so với Đám mây cho Solana Validator

Lưu trữ trên máy chủ vật lý là tiêu chuẩn sản xuất cho các validator Solana Mainnet. Máy chủ vật lý cung cấp IOPS NVMe nhất quán mà không bị tranh chấp bởi trình ảo hóa (hypervisor), các nhân CPU chuyên dụng không bị ảnh hưởng bởi "người hàng xóm ồn ào" đối với việc băm SHA-256 PoH, và băng thông mạng chuyên dụng không bị giới hạn do chia sẻ tài nguyên. Các phiên bản VPS đám mây chạy lưu trữ ảo hóa gây ra hiện tượng nghẽn cổ chai I/O cơ sở dữ liệu tài khoản, dẫn trực tiếp đến việc lỡ lượt bỏ phiếu và tỷ lệ bỏ qua ngày càng tệ hơn.

Nếu bạn đang thử nghiệm cấu hình trên testnet hoặc devnet, VPS đám mây là một môi trường có thể chấp nhận được và tiết kiệm chi phí. Đối với sản xuất Mainnet-beta, máy chủ chuyên dụng vật lý là lựa chọn cơ sở hạ tầng đúng đắn.

Phần mềm Validator: Chọn Client của bạn

Solana hỗ trợ ba bản thực thi client validator phù hợp cho sản xuất, và việc bạn chọn bản nào sẽ ảnh hưởng đến cả tiềm năng doanh thu và độ phức tạp vận hành của bạn ngay từ ngày đầu. Kiến trúc đa client của Solana là một quyết định có chủ đích vì sức khỏe mạng lưới: việc phân bổ phần mềm validator trên các bản thực thi độc lập giúp giảm rủi ro khi một lỗi client đơn lẻ ảnh hưởng đến toàn bộ mạng lưới.

Agave (trước đây là Solana Labs Validator Client)

Client Agave (trước đây là client validator của Solana Labs) là bản thực thi tham chiếu cho các validator Solana, được duy trì bởi Anza, một đơn vị kỹ thuật tách ra từ Solana Labs. Được viết bằng Rust, Agave là client được thử nghiệm thực tế và có tài liệu đầy đủ nhất trên mạng lưới. Các validator mới nên bắt đầu với Agave: nó có sự hỗ trợ cộng đồng rộng nhất và hành vi dễ dự đoán nhất dưới áp lực. Hướng dẫn cài đặt và các cờ cấu hình khởi động có trong kho lưu trữ GitHub của client Agave

Jito-Solana: Quyền truy cập doanh thu tiền tip MEV

Client Jito-Solana là một bản Fork của Agave tích hợp cơ sở hạ tầng validator của Jito

Firedancer: Client độc lập hiệu suất cao

Firedancer là một client validator Solana độc lập được phát triển bởi Jump Crypto (nhánh tiền điện tử của Jump Trading), được viết bằng C/C++ để đạt hiệu suất lưu lượng tối đa. Nó được thiết kế để tăng tổng công suất lưu lượng mạng của Solana và cải thiện tính đa dạng của client. Trong ước tính nguồn, Firedancer hiện có sẵn với năng lực sản xuất hạn chế. Kiểm tra trạng thái triển khai hiện tại tại kho lưu trữ GitHub của Firedancer

Yêu cầu hệ điều hành: Các validator Solana chạy trên Linux. Ubuntu 22.04 LTS là hệ điều hành được khuyến nghị. Việc tinh chỉnh nhân (kernel) bắt buộc bao gồm điều chỉnh kích thước bộ đệm mạng và cài đặt bộ điều phối CPU (CPU governor). Tài liệu chính thức quy định các thông số chính xác.

Yêu cầu kỹ năng Linux. Chạy một validator Solana yêu cầu sự thành thạo với quyền truy cập SSH, quản lý dịch vụ systemd, cấu hình tường lửa UFW hoặc iptables và giám sát nhật ký (log). Nếu bạn chưa đạt đến trình độ này, testnet là môi trường bắt đầu đúng đắn. Bạn có thể xây dựng sự làm quen vận hành ở đó mà không gặp rủi ro tài chính.

Yêu cầu SOL: Tài khoản, Stake, và Phí bỏ phiếu

Solana không áp dụng mức stake SOL tối thiểu ở cấp độ giao thức để chạy một validator, nhưng phí giao dịch bỏ phiếu và chi phí máy chủ tạo ra một mức tối thiểu kinh tế thực tế: lượng stake được ủy quyền của bạn phải tạo ra đủ thu nhập hoa hồng để chi trả cho các chi phí vận hành hàng tháng của bạn.

Bạn cần bao nhiêu SOL để chạy một Solana Validator?

Không có mức stake SOL tối thiểu do giao thức bắt buộc. Bất kỳ validator nào cũng có thể tham gia đồng thuận với một lượng tự stake nhỏ. Mức tối thiểu thực tế được xác định bởi tính toán điểm hòa vốn: lượng stake được ủy quyền của bạn phải tạo ra thu nhập hoa hồng đủ để trang trải chi phí máy chủ hàng tháng cộng với khoảng 30 SOL mỗi tháng phí giao dịch bỏ phiếu. Đối với hầu hết các nhà vận hành, điều này có nghĩa là phải thu hút từ 50.000 đến hơn 100.000 SOL stake ủy quyền trước khi đạt được lợi nhuận, hoặc đủ điều kiện tham gia Chương trình Ủy quyền của Solana Foundation (SFDP) để hỗ trợ stake trong giai đoạn đầu.

Tài khoản bỏ phiếu và Tài khoản danh tính

Mỗi validator Solana duy trì hai tài khoản Trên chuỗi riêng biệt với Số dư SOL riêng.

Tài khoản danh tính: Cặp khóa xác thực của validator, dùng để ký các phiếu bầu và định danh nút validator trên mạng lưới. Cặp khóa này nằm trên máy chủ vì nó cần thiết cho việc ký hoạt động. Yêu cầu nạp tiền là tối thiểu; nó cần đủ SOL để trả cho các giao dịch không thường xuyên.

Tài khoản bỏ phiếu: Một tài khoản đặc biệt Trên chuỗi được sử dụng để ghi lại các phiếu bầu của validator trong mỗi epoch. Tài khoản bỏ phiếu yêu cầu Số dư SOL miễn tiền thuê khoảng 0,02685 SOL để duy trì hoạt động (kiểm tra con số hiện tại tại các lệnh tạo tài khoản bỏ phiếu

Quan trọng: Nạp tiền vào Tài khoản Bỏ phiếu của bạn trước khi hoạt động. Phí bỏ phiếu tốn khoảng 1 SOL mỗi ngày trên mainnet-beta, bất kể bạn nắm giữ bao nhiêu stake. Nếu tài khoản bỏ phiếu hết SOL, trình xác thực của bạn sẽ ngừng bỏ phiếu và trở nên quá hạn (một trình xác thực đã ngừng tham gia đồng thuận, dẫn đến mất phần thưởng và giảm điểm hiệu suất). Nạp đủ phí cho 30 ngày trước khi ra mắt, sau đó theo dõi Số dư hàng ngày. Các nhà khai thác cần SOL cho khoản dự phòng này có thể sử dụng Bybit SOL/USDT Giao ngay, khi có sẵn, trước khi cẩn thận chuyển đến địa chỉ Solana chính xác.

Ủy quyền Stake và Điều kiện nhận Thưởng

Những người nắm giữ SOL tạo tài khoản stake và ủy quyền chúng cho một trình xác thực mà họ chọn. Tổng số stake ủy quyền của bạn xác định phần chia tương ứng của bạn trong phần thưởng lạm phát theo epoch và số lượng vị trí leader được chỉ định của bạn. Khi đánh giá một trình xác thực, người ủy quyền thường xem xét tỷ lệ hoa hồng, tỷ lệ bỏ qua và điểm hiệu suất SFDP cùng nhau. Hiểu cách thức hoạt động của Staking SOL và ủy quyền là nền tảng để mô hình hóa thu nhập của trình xác thực: người ủy quyền đang đánh giá xem trình xác thực của bạn có hoạt động tốt và bảo vệ phần thưởng của họ hay không, do đó mối quan hệ giữa chất lượng phần cứng của bạn và stake ủy quyền của bạn là trực tiếp. Stake được ủy quyền mới cần một epoch đầy đủ (khoảng 2 ngày) để kích hoạt và bắt đầu tạo ra phần thưởng.

Mức tối thiểu về kinh tế: Bạn thực sự cần bao nhiêu Stake?

Phép tính lợi nhuận ở phần tiếp theo cung cấp công thức chính xác. Với tỷ lệ Staking hàng năm là 7% APY và tỷ lệ hoa hồng 10%, một trình xác thực cần khoảng 50.000 đến 100.000 SOL dưới dạng stake ủy quyền để tạo ra thu nhập hoa hồng vượt quá chi phí máy chủ và phí bỏ phiếu thông thường. Dưới ngưỡng đó, các trình xác thực thường hoạt động thua lỗ. Phần SFDP đề cập đến cách Foundation thu hẹp khoảng cách đó cho các nhà khai thác đủ điều kiện.

Chạy một Trình xác thực Solana tốn bao nhiêu chi phí?

Chạy một trình xác thực Solana trên mainnet-beta bao gồm hai loại chi phí riêng biệt: chi phí máy chủ hàng tháng cố định cho phần cứng bare-metal và chi phí liên tục biến đổi dưới dạng phí giao dịch bỏ phiếu được tính bằng SOL.

Phân tích chi phí hoạt động hàng tháng

Tất cả giá ước tính trong bản gốc. Xác minh giá hiện tại trực tiếp với từng nhà cung cấp trước khi cam kết. Đối với hầu hết các nhà khai thác, Latitude.sh hoặc OVHcloud bare-metal trong phạm vi 150–500 USD/tháng là điểm khởi đầu thực tế cho một cấu hình có khả năng hoạt động trên mainnet.

Lưu ý về Chính sách của Hetzner. Trong bản ước tính gốc, Hetzner đã hạn chế khối lượng công việc của trình xác thực Solana trên một số phần cơ sở hạ tầng của họ. Xác minh chính sách hiện tại trực tiếp với Hetzner trước khi cung cấp máy chủ để sử dụng làm trình xác thực mainnet-beta.

Chạy một Trình xác thực Solana có Lợi nhuận không?

Lợi nhuận tỷ lệ thuận với stake ủy quyền. Một trình xác thực với 20.000 SOL được ủy quyền sẽ thua lỗ ở hầu hết các mức giá SOL. Một trình xác thực với 150.000 SOL được ủy quyền sẽ có lợi nhuận trong các điều kiện APY và hoa hồng điển hình. Công thức dưới đây cho thấy mối quan hệ chính xác.

Công thức tính lợi nhuận

Lợi nhuận ròng hàng tháng = (SOL được ủy quyền x Tỷ lệ Staking hàng năm APY / 12 x Tỷ lệ hoa hồng) - Chi phí máy chủ hàng tháng - (Phí bỏ phiếu mỗi ngày x 30)

Ví dụ đã làm (minh họa; xác minh tất cả các đầu vào với dữ liệu hiện tại):

• SOL được ủy quyền: 100.000 SOL
• Tỷ lệ Staking hàng năm APY: khoảng 6,5% (trong ước tính gốc, Nguồn: validators.app; xác minh tỷ lệ hiện tại)
• Tỷ lệ hoa hồng: 10%
• Chi phí máy chủ hàng tháng: 350 USD
• Phí bỏ phiếu: khoảng 1 SOL/ngày x 30 ngày = 30 SOL/tháng

Thu nhập hoa hồng hàng tháng: 100.000 x 0,065 / 12 x 0,10 = khoảng 54 SOL/tháng

Tổng chi phí hàng tháng: 350 USD máy chủ + (30 SOL x giá SOL hiện tại)

Với SOL = 150 USD: tổng chi phí hàng tháng khoảng 350 USD + 4.500 USD = 4.850 USD. Thu nhập hoa hồng hàng tháng ở mức 54 SOL x 150 USD = 8.100 USD. Lợi nhuận ròng: khoảng +3.250 USD/tháng.

Lưu ý: Các ước tính chi phí, dự báo lợi nhuận và tính toán thu nhập trên đây là các ví dụ minh họa dựa trên các đầu vào biến đổi (giá SOL, Staking APY, chi phí máy chủ) thay đổi theo thời gian. Chúng không phải là lời khuyên tài chính, khuyến nghị đầu tư hay đảm bảo về hiệu suất trong tương lai. Hãy xác minh tất cả các số liệu với dữ liệu thị trường hiện tại trước khi đưa ra quyết định tài chính.

Phân phối địa lý và Chấm điểm SFDP

Vị trí trung tâm dữ liệu ảnh hưởng đến tính đủ điều kiện SFDP. Điểm của Solana Foundation phạt các trình xác thực tập trung ở các khu vực trung tâm dữ liệu đã bão hòa, đặc biệt là Ashburn, VA, nơi có một lượng lớn trình xác thực Solana. Việc lưu trữ trên các nhà cung cấp đám mây lớn (AWS, GCP, Azure) nhận được điểm phi tập trung thấp hơn. Lưu trữ bare-metal ở các khu vực địa lý ít được đại diện có điểm số tốt hơn về sự đa dạng của trung tâm dữ liệu.

Phần thưởng của Trình xác thực Solana hoạt động như thế nào

Phần thưởng của trình xác thực Solana đến từ hai nguồn: phát hành SOL theo lạm phát được phân phối theo tỷ lệ phần trăm tổng số stake hoạt động của mỗi trình xác thực mỗi epoch, và doanh thu phí giao dịch từ các block mà trình xác thực sản xuất trong các vị trí leader được chỉ định của nó. Các trình xác thực chạy client Jito-Solana được truy cập vào luồng doanh thu thứ ba: phân phối tiền tip MEV từ công cụ block của Jito.

Phần thưởng lạm phát và Công thức Phần thưởng

Công thức phần thưởng cốt lõi:

Phần thưởng Tổng gộp của Trình xác thực mỗi Epoch = (Tổng stake ủy quyền của Trình xác thực Stake / Tổng stake hoạt động trên Mạng Stake) x Quỹ Phần thưởng Lạm phát Epoch

Lịch phát hành lạm phát của Solana bắt đầu ở mức 8% phát hành hàng năm và giảm 15% mỗi năm, với mức sàn dài hạn là 1,5%. Tỷ lệ Staking hàng năm hiện tại APY phản ánh vị trí của mạng trên lịch trình đó (xác minh APY hiện tại tại validators.app trước khi mô hình hóa).

Mỗi epoch, Solana công bố lịch trình leader: một vòng quay được xác định trước chỉ định cho mỗi trình xác thực các vị trí cụ thể trong thời gian đó, họ chịu trách nhiệm sản xuất các block. Nhiều stake ủy quyền hơn có nghĩa là nhiều vị trí leader hơn, có nghĩa là nhiều phần thưởng sản xuất block hơn bên cạnh phần thưởng lạm phát cơ bản.

Ví dụ đã làm (minh họa): Một trình xác thực giữ 1% tổng stake hoạt động với tỷ lệ hoa hồng 10%, với mức Staking hàng năm 6,5% APY, kiếm được khoảng 1% x (tổng SOL stake x 0,065 / 365 x 2 ngày mỗi epoch) x 10% hoa hồng mỗi epoch. Sử dụng các số liệu trực tiếp hiện tại từ validators.app để tính toán kịch bản cụ thể của bạn.

Tỷ lệ hoa hồng: Bạn giữ lại bao nhiêu so với bạn chuyển giao

Tỷ lệ hoa hồng của bạn là phần trăm phần thưởng staking mà bạn giữ lại từ thu nhập của những người ủy quyền cho bạn. Nó không phải là một khoản phí áp dụng cho các giao dịch. Với tỷ lệ hoa hồng 10%, bạn giữ 10% của tất cả phần thưởng epoch mà stake của những người ủy quyền cho bạn kiếm được, và 90% còn lại đi trực tiếp cho người ủy quyền. Việc đặt hoa hồng quá cao sẽ khiến người ủy quyền ngần ngại chọn trình xác thực của bạn; đặt quá thấp có thể không đủ chi phí hoạt động.

Phạm vi thị trường điển hình cho các validator cạnh tranh trên Solana mainnet-beta dao động từ 0% đến 10%. Việc đặt mức hoa hồng 100% sẽ làm mất tư cách của validator của bạn khỏi Chương trình Ủy quyền của Quỹ Solana. Phần SFDP bên dưới đề cập đến trần hoa hồng và cách nó tương tác với điểm đủ điều kiện.

Stake Thời gian trì hoãn kích hoạt và thời điểm nhận thưởng

Lượng stake mới được ủy quyền cần một epoch đầy đủ (khoảng 2 ngày) để kích hoạt sau khi ủy quyền. Phần thưởng được ghi có vào cuối mỗi epoch. Các validator mới nên dự trù ít nhất hai epoch đầy đủ sau khi ra mắt trước khi mong đợi thu nhập phần thưởng đầy đủ: một epoch để xác minh phần cứng và cấu hình trên testnet, và một epoch để kích hoạt stake trên mainnet-beta.

Chương trình Ủy quyền của Quỹ Solana (SFDP): Cách đủ điều kiện

Nếu không có lượng stake ban đầu từ bên ngoài, một validator Solana mới với ít sự ủy quyền tự nhiên sẽ hoạt động thua lỗ trong những tháng đầu trên mainnet-beta. Chương trình Ủy quyền của Quỹ Solana (SFDP) tồn tại để thu hẹp khoảng cách đó. Quỹ Solana (tổ chức phi lợi nhuận hỗ trợ sự phát triển và phi tập trung của Solana) ủy quyền SOL từ kho bạc của mình cho các validator mainnet-beta đủ điều kiện, cung cấp lượng stake ban đầu để giúp các nhà khai thác mới đạt được khả năng kinh tế trước khi thu hút được những người ủy quyền tự nhiên.

SFDP là chương trình của Quỹ Solana, thông qua đó Quỹ ủy quyền SOL từ kho bạc của mình cho các validator mainnet-beta đủ điều kiện. Chương trình cung cấp lượng stake ban đầu để giúp các validator mới đạt được khả năng kinh tế trước khi thu hút được những người ủy quyền tự nhiên. Việc đủ điều kiện yêu cầu đáp ứng các tiêu chí về hiệu suất, tỷ lệ hoa hồng và tính đa dạng trung tâm dữ liệu được Quỹ xác minh. SFDP không tự động. Các validator phải nộp đơn và duy trì tư cách đủ điều kiện liên tục để giữ lại sự ủy quyền.

SFDP lấp đầy khoảng trống kinh tế giữa thời điểm ra mắt và ngưỡng ủy quyền stake tối thiểu để có lãi. Một validator đủ điều kiện tham gia SFDP sẽ nhận được sự ủy quyền từ Quỹ, tạo ra thu nhập từ hoa hồng, giảm thời gian cần thiết để đạt được sự bền vững hoạt động.

Các tiêu chí sau đây phản ánh các yêu cầu của chương trình như được ghi lại tại solana.org/validators. Xác minh từng mục so với trang chương trình hiện tại trước khi nộp đơn. Quỹ cập nhật các tiêu chí này định kỳ.

• Validator phải hoạt động trên mainnet-beta (không phải testnet hoặc devnet)
• Tỷ lệ hoa hồng bằng hoặc thấp hơn mức trần SFDP hiện tại (xác minh ngưỡng chính xác hiện tại tại solana.org/validators; mức hoa hồng 100% chắc chắn sẽ bị loại trừ, và các mức cao hơn thông lệ cộng đồng sẽ ảnh hưởng đến việc tính điểm)
• Tỷ lệ tham gia bỏ phiếu tối thiểu duy trì trên ngưỡng chương trình (xác nhận ngưỡng hiện tại từ tài liệu chính thức)
• Tỷ lệ bỏ sót (phần trăm các slot lãnh đạo được chỉ định mà validator bỏ lỡ) thấp hơn ngưỡng chương trình
• Nhà cung cấp trung tâm dữ liệu không nằm trong danh sách tập trung quá mức (sự tập trung AWS, GCP và Azure sẽ bị phạt điểm)
• Danh tính validator hoạt động và tài khoản bỏ phiếu được cấp vốn mà không có lịch sử chậm trễ gần đây
• Điểm hiệu suất đáp ứng các ngưỡng của Quỹ dựa trên chất lượng sản xuất khối và thời gian hoạt động

Các tiêu chí đủ điều kiện và số lượng ủy quyền của Chương trình Ủy quyền của Quỹ Solana được Quỹ Solana quyết định tùy theo quyết định của mình và có thể thay đổi. Việc đáp ứng các tiêu chí trên không đảm bảo ủy quyền SFDP. Luôn xác minh các yêu cầu chương trình hiện tại trực tiếp tại solana.org/validators

SFDP Cung cấp bao nhiêu Stake?

SFDP phân bổ SOL theo các cấp dựa trên điểm hiệu suất của validator. Các validator mới không có lịch sử hiệu suất thường nhận được phân bổ ban đầu thấp hơn. Khi validator của bạn thể hiện thời gian hoạt động nhất quán, tỷ lệ bỏ sót thấp và tỷ lệ bỏ phiếu mạnh mẽ, phân bổ có thể tăng lên. Cấu trúc chương trình có thể được Quỹ sửa đổi. Kiểm tra trang SFDP chính thức để biết cấu trúc và số lượng cấp hiện tại.

1. Xác nhận validator mainnet-beta của bạn đang hoạt động và đáp ứng các ngưỡng hiệu suất (kiểm tra tỷ lệ bỏ sót và tỷ lệ tham gia bỏ phiếu của bạn qua validators.app
2. Hoàn thành biểu mẫu đăng ký trên trang web của Quỹ Solana tại Biểu mẫu đăng ký Chương trình Ủy quyền của Quỹ Solana
3. Theo dõi điểm hiệu suất của bạn qua validators.app sau khi đăng ký; Quỹ đánh giá dữ liệu hiệu suất trên chuỗi như một phần của quy trình xem xét của mình

Việc tính điểm SFDP thưởng cho tính đa dạng về địa lý và nhà cung cấp. Các validator được lưu trữ trên máy chủ bare-metal ở các khu vực kém đại diện sẽ có điểm cao hơn những validator tập trung vào cơ sở hạ tầng của các nhà cung cấp đám mây lớn. Nếu cơ sở hạ tầng trung tâm dữ liệu của bạn nghiêng về AWS us-east-1 hoặc các khu vực đám mây lớn tương đương, bạn có thể cần cung cấp tài nguyên ở các khu vực thay thế hoặc với các nhà cung cấp thay thế để đủ điều kiện hoặc tối đa hóa phân bổ SFDP. Cân nhắc này đặc biệt phù hợp với các nhà khai thác tổ chức đang đánh giá triển khai đa validator.

Việc Ủy quyền SFDP Không Vĩnh viễn. Quỹ Solana chủ động điều chỉnh phân bổ ủy quyền dựa trên hiệu suất hoạt động liên tục của validator. Các validator giảm xuống dưới ngưỡng hiệu suất do suy thoái phần cứng, cấu hình sai hoặc giám sát thiếu chú ý có thể nhanh chóng mất stake SFDP. Hãy xây dựng nền kinh tế validator dài hạn của bạn dựa trên stake được ủy quyền tự nhiên, không phải SFDP như một nguồn thu nhập vĩnh viễn.

So sánh Validator Solana và Validator Ethereum: Yêu cầu

Những người khai thác đã vận hành validator Ethereum thường đánh giá thấp yêu cầu phần cứng của Solana vì hai mạng áp đặt các gánh nặng tính toán khác biệt về mặt phân loại lên các validator của họ.

Các validator Solana phải xử lý các bằng chứng PoH liên tục, phát lại toàn bộ sổ cái trong thời gian thực với thông lượng 50.000+ TPS và bỏ phiếu cho các khối với độ trễ dưới một giây. Ngược lại, các validator Ethereum xác nhận các epoch kéo dài khoảng 6,4 phút mỗi chu kỳ và không phát lại sổ cái có thông lượng cao cục bộ trong thời gian thực. Kiến trúc của Solana đánh đổi yêu cầu phần cứng lấy thông lượng giao dịch. Kiến trúc của Ethereum ưu tiên rào cản phần cứng thấp hơn để đổi lấy thông lượng gốc thấp hơn.

Mức tối thiểu 32 ETH của Ethereum là một quy tắc cứng của giao thức: bạn không thể kích hoạt validator Ethereum mà không có chính xác 32 ETH được stake. Solana không có ràng buộc tương đương theo giao thức. Bất kỳ validator Solana nào cũng có thể bắt đầu bỏ phiếu với lượng stake tối thiểu. Rào cản là về kinh tế: dưới ngưỡng ủy quyền hòa vốn (được đề cập trong phần chi phí), chi phí máy chủ và phí bỏ phiếu hàng tháng vượt quá thu nhập hoa hồng, tạo ra khoản lỗ hàng tháng ròng. Đây là những loại rào cản gia nhập khác nhau. Rào cản của Ethereum là yêu cầu khóa vốn; rào cản của Solana là yêu cầu chi phí hoạt động liên tục.

Giám sát Validator Solana của bạn: Công cụ và Chỉ số Hiệu suất

Các chỉ số hiệu suất của validator xác định điểm đủ điều kiện SFDP của bạn, tỷ lệ bỏ lỡ (skip rate) và lượng stake được ủy quyền mà bạn giữ lại. Giám sát là một chức năng kinh tế trực tiếp, không phải là một suy nghĩ sau về hoạt động.

Các công cụ giám sát được sử dụng bởi các nhà khai thác validator Solana:

• validators.app

• Trình khám phá validator Solana Beach

• explorer.solana.com: Trình khám phá khối Solana chính thức. Sử dụng để tra cứu validator ở cấp độ khối bằng khóa công khai danh tính, xác minh giao dịch và kiểm tra tài khoản trên chuỗi.

• Grafana + Prometheus (tự host): Bộ công cụ được đề xuất để giám sát cơ sở hạ tầng theo thời gian thực. Theo dõi việc sử dụng CPU, tiêu thụ RAM, IOPS NVMe và thông lượng mạng ở cấp độ phần cứng. Solana Labs xuất bản tệp JSON bảng điều khiển Grafana tham chiếu trong tài liệu chính thức.

Các Chỉ Số Hiệu Suất Chính Cần Theo Dõi

• Tỷ lệ bỏ lỡ (Skip rate): Phần trăm các slot lãnh đạo được gán mà validator bỏ lỡ. Đặt mục tiêu thấp hơn 10%; SFDP thường yêu cầu ngưỡng thấp hơn. Tỷ lệ bỏ lỡ tăng là dấu hiệu sớm nhất của việc cung cấp phần cứng không đủ hoặc các vấn đề kết nối mạng.
• Tỷ lệ tham gia bỏ phiếu (Vote participation rate): Phần trăm các slot mà bạn gửi bỏ phiếu thành công. Đặt mục tiêu trên 95%.
• Số dư SOL của tài khoản bỏ phiếu: Không bao giờ để nó giảm xuống dưới mức phí bỏ phiếu cho 1 tuần chạy. Theo dõi hàng ngày.
• Trạng thái catchup ledger: Sau bất kỳ lần khởi động lại nào, hãy xác nhận validator của bạn đã trở lại điểm cuối chuỗi trước khi mong đợi sự tham gia bỏ phiếu.
• Sử dụng IOPS NVMe: Các điểm nghẽn lưu trữ xuất hiện dưới dạng tỷ lệ bỏ lỡ tăng dưới khối lượng giao dịch cao. Theo dõi thời gian chờ I/O trên cả hai ổ NVMe.

Thiết lập Cảnh báo. Cấu hình PagerDuty, OpsGenie hoặc các dịch vụ cảnh báo tương đương trên số dư SOL của tài khoản bỏ phiếu của bạn. Đặt ngưỡng cảnh báo ở mức phí bỏ phiếu còn lại trong 7 ngày. Tài khoản bỏ phiếu thiếu tiền sẽ bị chậm trễ mà không có cảnh báo nào trên chuỗi. Đến khi những người ủy quyền nhận thấy hiệu suất của bạn suy giảm, bạn đã mất stake.

Cách Trở Thành Validator Solana: Tổng Quan Thiết Lập

Phần này ánh xạ mười bước tuần tự từ cấp phát phần cứng đến nộp đơn SFDP. Hướng dẫn thiết lập sản xuất từng lệnh, các cờ CLI chính xác và các mẫu tệp cấu hình có trong tài liệu thiết lập validator Solana).

1. Phần cứng đã được cấp phát và xác minh. Tìm nguồn cung ứng máy chủ bare-metal đáp ứng các thông số kỹ thuật trong phần Yêu cầu Phần cứng. Xác nhận cấu hình ổ NVMe, dung lượng RAM và kết nối mạng trước khi tiếp tục.

2. Ubuntu 22.04 LTS đã được cài đặt và tinh chỉnh kernel. Cài đặt hệ điều hành. Áp dụng kích thước bộ đệm mạng và cài đặt CPU governor được chỉ định trong tài liệu Solana. Các tham số kernel này không tùy chọn; bỏ qua chúng sẽ gây suy giảm hiệu suất dưới tải liên tục.

3. Các công cụ Solana CLI đã được cài đặt và cấu hình cho testnet. Cài đặt bộ công cụ Solana CLI. Cấu hình đích cluster của bạn thành testnet (không phải mainnet-beta) cho tất cả công việc cấu hình ban đầu. Testnet sử dụng SOL không có giá trị, cho phép bạn kiểm tra mà không bị rủi ro tài chính.

4. Keypair danh tính và keypair tài khoản bỏ phiếu đã được tạo; thẩm quyền rút tiền đã được bảo mật. Tạo keypair danh tính validator và keypair tài khoản bỏ phiếu của bạn bằng Solana CLI. Gán thẩm quyền rút tiền cho một keypair lưu trữ lạnh (ví cứng hoặc máy air-gapped). Đây là các tài khoản riêng biệt (xem ghi chú bảo mật bên dưới).

5. Tài khoản bỏ phiếu đã được nạp tiền với ít nhất 30 ngày phí bỏ phiếu. Nạp vào tài khoản bỏ phiếu khoảng 0.02685 SOL cho số dư miễn phí thuê và thêm ít nhất 30 SOL làm bộ đệm phí bỏ phiếu trước khi hoạt động. Đây là bước thường bị bỏ qua nhất với hậu quả nghiêm trọng nhất.

6. Quá trình validator Agave (hoặc Jito-Solana) đã được cấu hình và khởi chạy. Cấu hình tập lệnh khởi chạy validator của bạn bằng các cờ từ tài liệu chính thức. Khởi chạy client Agave (trước đây là client validator Solana Labs) làm cơ sở được đề xuất. Jito-Solana là một tùy chọn sau khi hoạt động của bạn đã ổn định.

7. Quá trình catchup ledger được giám sát và xác nhận. Chạy lệnh catchup được tham chiếu trong tài liệu chính thức để giám sát tiến trình phát lại ledger của validator. Đừng mong đợi sự tham gia bỏ phiếu cho đến khi validator đạt đến điểm cuối chuỗi hiện tại.

8. Độ ổn định của Testnet được xác minh trong ít nhất một epoch đầy đủ. Chạy validator của bạn trên testnet trong tối thiểu một epoch đầy đủ (khoảng 2 ngày) trước khi di chuyển sang mainnet-beta. Xác nhận tỷ lệ bỏ lỡ (skip rate), tỷ lệ tham gia bỏ phiếu (vote participation rate) và các chỉ số phần cứng nằm trong phạm vi chấp nhận được.

9. Cấu hình được di chuyển sang mainnet-beta; tài khoản bỏ phiếu đã được nạp tiền. Chuyển cấu hình cluster của bạn sang mainnet-beta (mạng sản xuất trực tiếp của Solana). Nạp tiền cho tài khoản bỏ phiếu mainnet của bạn. Đăng ký validator của bạn với validators.app để hiệu suất của bạn hiển thị với những người ủy quyền.

10. Ứng dụng SFDP đã được gửi và chiến lược tỷ lệ hoa hồng đã được đặt. Xem xét các yêu cầu đủ điều kiện SFDP và nộp đơn nếu bạn đáp ứng tiêu chí. Đặt tỷ lệ hoa hồng của bạn, cân bằng các giới hạn trần SFDP với vị thế cạnh tranh với những người ủy quyền tự nhiên.

Testnet Đầu Tiên: Tại Sao Mạng Lập Thực Lại Quan Trọng

Cluster testnet của Solana phản ánh hoạt động của mainnet-beta nhưng sử dụng SOL không có giá trị tiền tệ, có sẵn từ faucet testnet. Các lỗi cấu hình trên testnet không tốn kém. Các lỗi tương tự trên mainnet-beta sẽ tốn SOL thật phí bỏ phiếu trong khi validator của bạn hoạt động kém hiệu quả và mất đi stake được ủy quyền. Solana Foundation khuyến nghị tối thiểu một epoch đầy đủ hoạt động testnet ổn định trước khi triển khai mainnet. Testnet khác với devnet: devnet là môi trường phát triển để kiểm tra ứng dụng và không phải là môi trường thực hành validator phù hợp.

Bảo Mật Tài Khoản Bỏ Phiếu và Tài Khoản Danh Tính

Keypair danh tính của bạn có thể và phải nằm trên máy chủ: nó ký vào mọi giao dịch bỏ phiếu mà validator phát sóng, vì vậy nó cần được truy cập bởi tiến trình validator đang chạy. Keypair thẩm quyền rút tiền của bạn không bao giờ được nằm trên máy chủ. Thẩm quyền rút tiền kiểm soát việc rút tiền từ tài khoản bỏ phiếu của bạn. Nếu kẻ tấn công có được nó, họ có thể rút cạn tất cả SOL trong tài khoản bỏ phiếu và các khoản tiền đã stake của bạn. Sử dụng ví cứng (Ledger, Trezor) hoặc máy air-gapped làm thẩm quyền rút tiền. Việc tách biệt khóa này là thực hành bảo mật quan trọng nhất đối với các validator Solana.

Câu Hỏi Thường Gặp Về Yêu Cầu Validator Solana

Các câu hỏi này đại diện cho các tìm kiếm có tần suất cao nhất từ các nhà khai thác validator Solana tiềm năng. Mỗi câu trả lời đứng độc lập.

Cần Bao Nhiêu SOL Để Chạy Validator Solana?

Không có mức stake SOL tối thiểu được áp dụng bởi giao thức. Mức tối thiểu thực tế được xác định bởi tính toán hòa vốn: stake được ủy quyền của bạn phải tạo ra đủ thu nhập hoa hồng để trang trải chi phí máy chủ hàng tháng cộng với khoảng 30 SOL phí bỏ phiếu. Đối với hầu hết các nhà khai thác ở mức APY và tỷ lệ hoa hồng điển hình, điều này có nghĩa là 50.000 đến 100.000+ SOL stake được ủy quyền, hoặc đủ điều kiện nhận hỗ trợ khởi động SFDP trong khi xây dựng sự ủy quyền tự nhiên. Xem phần Kinh tế để biết công thức lợi nhuận đầy đủ.

Chạy Validator Solana Tốn Bao Nhiêu Tiền?

Dự kiến từ 250 đến 500 USD mỗi tháng cho một máy chủ bare-metal đáp ứng các thông số kỹ thuật được Solana đề xuất, cộng với khoảng 30 SOL mỗi tháng phí giao dịch bỏ phiếu với mức giá mainnet-beta hiện tại. Tổng chi phí hàng tháng bằng USD phụ thuộc vào giá SOL hiện tại) tại thời điểm hoạt động. Đây là một biến số quan trọng trong mô hình hóa lợi nhuận mà bạn phải tính toán lại với dữ liệu thị trường hiện tại. Xem phần Chi phí Cơ sở hạ tầng để biết bảng so sánh nhà cung cấp lưu trữ.

Cần Phần Cứng Gì Để Chạy Validator Solana?

Yêu cầu tối thiểu: CPU có 12 nhân trở lên và tốc độ xung nhịp đơn nhân cao, 128 GB ECC DDR4 RAM, ổ cứng SSD NVMe PCIe Gen3 (tách riêng ổ đĩa chạy OS/ledger và ổ đĩa tài khoản), và kết nối mạng đối xứng 1 Gbps. Cấu hình sản xuất khuyến nghị là CPU 24 nhân trở lên (AMD EPYC dòng 7003), 256 GB ECC RAM, SSD NVMe PCIe Gen4 và kết nối mạng 10 Gbps. Các loại SSD SATA tiêu chuẩn không thể đáp ứng yêu cầu I/O của Solana. Xem phần Yêu cầu Phần cứng để biết bảng thông số kỹ thuật đầy đủ.

Chạy Validator Solana có lãi không?

Khả năng sinh lời phụ thuộc vào bốn biến số: stake được ủy quyền, giá SOL, tỷ lệ hoa hồng và chi phí vận hành hàng tháng (phí máy chủ cộng với phí bỏ phiếu). Các Validator có hơn 50.000 SOL được ủy quyền có thể đạt mức sinh lời ở tỷ lệ hoa hồng và APY điển hình. Các Validator có dưới 20.000 SOL được ủy quyền sẽ hoạt động thua lỗ cho đến khi việc ủy quyền từ SFDP hoặc sự tăng trưởng tự nhiên bù đắp được khoảng trống. Không có mức lợi nhuận validator nào được đảm bảo; tất cả các tính toán thu nhập đều là ước tính dựa trên các điều kiện mạng thay đổi. Xem bảng kịch bản lợi nhuận trong phần Chi phí.

SFDP là một chương trình mà qua đó Solana Foundation phân bổ SOL stake từ kho quỹ của mình cho các validator Mainnet-beta đủ điều kiện, hỗ trợ phi tập trung hóa mạng lưới và giúp các validator mới đạt được tính khả thi về kinh tế trước khi thu hút các bên ủy quyền tự nhiên. Điều kiện tham gia yêu cầu đáp ứng các ngưỡng hiệu suất, giới hạn tỷ lệ hoa hồng và tiêu chí đa dạng hóa trung tâm dữ liệu. Việc ủy quyền SFDP không diễn ra tự động, không mang tính vĩnh viễn và tùy thuộc vào quyết định liên tục của Foundation. Xem phần SFDP để biết danh sách kiểm tra điều kiện và quy trình đăng ký.

Solana có bao nhiêu Validator?

Solana Mainnet-beta có khoảng 1.500 đến 1.800 validator đang hoạt động theo ước tính nguồn (Nguồn: validators.app)

Tôi có thể chạy Validator Solana trên máy chủ Cloud không?

Các phiên bản Cloud VPS có thể chấp nhận được để thử nghiệm trên testnet và devnet nhưng không phù hợp để sản xuất trên Mainnet-beta. Lưu trữ ảo hóa trên cloud VPS gây ra hiện tượng rung nhiễu (jitter) IOPS, dẫn đến việc bỏ lỡ các phiếu bầu và làm giảm tỷ lệ bỏ qua (skip rate) cũng như điểm hiệu suất SFDP của bạn. Máy chủ chuyên dụng vật lý (Bare-metal) là tiêu chuẩn sản xuất. Nếu bạn đang cân nhắc dịch vụ "bare-metal cloud" (máy chủ vật lý có sẵn thông qua các nhà cung cấp cloud), hãy xác minh các đặc tính I/O khớp với bare-metal chuyên dụng trước khi triển khai cho Mainnet.

Tài khoản Bỏ phiếu (Vote Account) trong Solana là gì?

Tài khoản bỏ phiếu là tài khoản trên chuỗi mà qua đó validator của bạn gửi các phiếu bầu khối sau mỗi epoch. Nó tách biệt với tài khoản định danh của bạn (tài khoản dùng để xác định và xác thực nút validator). Tài khoản bỏ phiếu yêu cầu số dư miễn thuê khoảng 0,02685 SOL và tiêu tốn khoảng 1 SOL mỗi ngày cho phí giao dịch bỏ phiếu trên Mainnet-beta. Việc hết SOL trong tài khoản bỏ phiếu sẽ khiến validator của bạn trở nên quá hạn (delinquent): nó ngừng bỏ phiếu, ngừng nhận phần thưởng và mất các vị thế stake được ủy quyền khi điểm hiệu suất bị giảm sút.

Solana có cơ chế Slashing Validator không?

Tại thời điểm đánh giá nguồn, Solana không có cơ chế slashing validator. Hãy xác minh tình trạng giao thức hiện tại trước khi tin tưởng vào tuyên bố này. Điều này trái ngược với các validator Ethereum, vốn phải đối mặt với các hình phạt slashing do sự không nhất quán (ký các khối xung đột) và bỏ phiếu bao quanh. Để biết trạng thái nguồn theo ngày và các thay đổi giao thức được đề xuất, hãy xem Giải thích về slashing validator Solana. Việc không có slashing trên Solana có nghĩa là các validator không gặp rủi ro mất SOL đã stake do lỗi phần mềm hoặc lỗi cấu hình vốn sẽ kích hoạt các điều kiện slashing trên Ethereum. Đây là trạng thái giao thức hiện tại và có thể thay đổi với các bản nâng cấp Solana trong tương lai.

Chạy Validator Solana có phù hợp với bạn không? Một khung quyết định

Validator so với Bên ủy quyền (Delegator): So sánh thực tế

Bài viết nguồn trùng lặp đã đưa ra quyết định vận hành một cách trực tiếp. Sự khác biệt thiết yếu là liệu bạn muốn vận hành cơ sở hạ tầng hay muốn kiếm phần thưởng staking mà không cần duy trì máy chủ.

Đối với những người đọc quyết định thay vì chạy validator sẽ thực hiện ủy quyền, hãy sử dụng các tiêu chí trong cách chọn validator Solana.

Quyết định có nên chạy validator Solana hay không phụ thuộc vào bốn biến số: kỹ năng hạ tầng Linux của bạn, ngân sách phần cứng, vị thế stake SOL của bạn và khả năng chịu đựng của bạn đối với giai đoạn chuẩn bị từ 3 đến 6 tháng trước khi thu nhập hoa hồng trang trải ổn định chi phí vận hành hàng tháng.

Chạy một Validator nếu:

• Bạn có kỹ năng cung cấp và quản lý máy chủ Linux (SSH, systemd, cấu hình tường lửa, giám sát log)
• Bạn có thể cung cấp hoặc thuê phần cứng đáp ứng các thông số kỹ thuật khuyến nghị ($250 đến $500+/tháng)
• Bạn có đủ SOL để trang trải phí bỏ phiếu trong giai đoạn chuẩn bị trước khi SFDP hoặc ủy quyền tự nhiên đạt đến điểm hòa vốn
• Bạn có thể cam kết duy trì máy chủ hoạt động 24/7 và giám sát hàng ngày các chỉ số hiệu suất
• Bạn muốn tham gia tích cực vào cơ sở hạ tầng mạng Solana thay vì staking thụ động

Thay vào đó hãy Ủy quyền nếu:

• Mục tiêu của bạn là thu nhập từ staking SOL mà không cần quản lý cơ sở hạ tầng
• Kỹ năng Linux của bạn chưa đạt đến cấp độ quản trị máy chủ được yêu cầu
• Tổng số SOL nắm giữ của bạn thấp hơn ngưỡng stake được ủy quyền để hòa vốn ở mức APY hiện tại
• Bạn không thể cam kết giám sát liên tục và luôn sẵn sàng xử lý sự cố cho validator của mình

Các bước tiếp theo cho những người vận hành quyết định tiếp tục:

1. Cung cấp phần cứng theo phần Yêu cầu Phần cứng
2. Thực hành trên testnet trong ít nhất một epoch đầy đủ trước khi chạm vào Mainnet-beta
3. Xem lại danh sách kiểm tra điều kiện SFDP trước ngày ra mắt mainnet của bạn
4. Thiết lập giám sát Grafana + Prometheus và cảnh báo số dư tài khoản bỏ phiếu vào ngày đầu tiên vận hành mainnet
5. Đánh dấu tài liệu hướng dẫn thiết lập validator Solana

Với việc cung cấp phần cứng chính xác, tài khoản bỏ phiếu được nạp tiền và lộ trình từ stake đến lợi nhuận thực tế, việc vận hành validator Solana có thể là một đóng góp bền vững, dựa trên hoa hồng cho một trong những mạng lưới có thông lượng cao nhất trong ngành.