Bài viết này được tạo bởi AI. Vui lòng xác minh thông tin quan trọng một cách độc lập.

Solana Firedancer TPS: Giải thích 1 triệu Giao dịch

Crypto Wiki|Oct 8, 2026|★★★★★★4.5 (500 đánh giá)
Tóm tắt AI

Discover what Solana Firedancer's 1,000,000 TPS benchmark means, how it works, and its impact on network performance and reliability.

Solana Firedancer TPS mô tả thông lượng được nhắm mục tiêu hoặc đo lường trong các điều kiện thử nghiệm Firedancer cụ thể, không phải là tốc độ được đảm bảo cho mọi giao dịch trên mainnet.

Lưu ý trạng thái: Việc triển khai Firedancer, điều kiện đo lường hiệu năng và việc áp dụng client validator thay đổi theo thời gian. Đọc các cột mốc dưới đây cùng với ngày tháng được nêu và xác minh trạng thái triển khai trực tiếp thông qua các nguồn chính thức được trích dẫn.

Điểm chính

  • TPS đo lường hiệu năng: Trong các thử nghiệm testnet có kiểm soát, Firedancer của Jump Crypto đã thể hiện 1.000.000 giao dịch mỗi giây (TPS), một con số được đo trong điều kiện phòng thí nghiệm tối ưu, không phải hiệu suất mainnet hiện tại.
  • TPS thực tế: Solana hiện xử lý tổng cộng 2.000–4.000 TPS trên mainnet; giao dịch không bỏ phiếu (hoạt động của người dùng thực tế) trung bình 400–1.000 TPS.
  • Firedancer là gì: Một client validator độc lập cho Solana được viết bằng C/C++ bởi Jump Crypto, không phải là token, fork hay nâng cấp giao thức.
  • Trạng thái theo ngày nguồn: Bản nháp nguồn mô tả Frankendancer đang hoạt động trên mainnet và Firedancer đầy đủ đang trong giai đoạn triển khai theo từng giai đoạn trong năm 2025; xác minh trạng thái hiện tại thông qua các nguồn chính thức.
  • Hai lợi ích: Khả năng thông lượng cao hơn và sự đa dạng client đều giảm bớt sự dễ bị tổn thương của Solana trước sự gián đoạn mạng lưới.

Mục lục


Firedancer là gì? Giải thích Client Validator Thứ Hai của Solana

Firedancer là một bản triển khai lại độc lập, từ đầu của client validator Solana (phần mềm mà máy tính chạy để xử lý giao dịch và tham gia vào cơ chế đồng thuận mạng lưới), được viết bằng C và C++ bởi Jump Crypto, bộ phận tiền điện tử và blockchain của Jump Trading Group. Nó không phải là một token, một fork hay một nâng cấp giao thức. Firedancer chạy cùng giao thức Solana mà client Agave hiện có chạy, giống như cách Lighthouse và Prysm cùng chạy giao thức Ethereum mà không phải là các blockchain khác nhau.

Bản thân Solana là một blockchain Layer 1 phi tập trung, hiệu năng cao, không cần xin phép (một sổ cái phân tán, được bảo mật bằng mật mã ghi lại các giao dịch trên hàng nghìn máy tính đồng thời) được thiết kế cho các ứng dụng phi tập trung có khả năng mở rộng. Được thành lập vào năm 2017 bởi Anatoly Yakovenko, một cựu kỹ sư Qualcomm đã phát minh ra Proof of History, Solana đã ra mắt mainnet beta vào năm 2020. Tính đến năm 2024–2025, khoảng 1.900 validator hoạt động bảo mật cho mainnet của Solana, mỗi validator thực hiện staking token SOL làm tài sản thế chấp và nhận phần thưởng khối tương ứng.

Cho đến khi có Firedancer, mọi validator Solana đều chạy cùng một client: Agave. Client Agave (trước đây là client validator của Solana Labs, hiện được Anza, đội ngũ bảo trì client validator Agave duy trì) được viết bằng Rust và đã cung cấp năng lượng cho Solana kể từ khi ra mắt mainnet beta. Firedancer thay đổi phương trình đó bằng cách cung cấp cho các validator một lựa chọn thứ hai, độc lập được xây dựng với các ưu tiên kỹ thuật khác nhau và kiến trúc nội bộ cơ bản khác biệt.

Firedancer thực hiện ba việc cho Solana: nó đẩy thông lượng giao dịch hướng tới giới hạn chuẩn 1.000.000 TPS, nó giảm độ trễ xử lý và nó giới thiệu sự đa dạng client cho hệ sinh thái validator. Sự đa dạng client (có hai bản triển khai riêng biệt của cùng một giao thức) là một thuộc tính phục hồi cấu trúc mà Solana hiện đang thiếu. Firedancer giải quyết khoảng trống đó.

Ai đã xây dựng Firedancer?

Firedancer được xây dựng bởi Jump Crypto, bộ phận tiền điện tử và blockchain của Jump Trading Group, một trong những công ty giao dịch tần suất cao (HFT) và tạo lập thị trường lớn nhất thế giới. Nền tảng đó có ý nghĩa trực tiếp: công việc hiệu năng bên trong Firedancer, bao gồm mạng lưới vượt trội kernel, mục tiêu độ trễ dưới mili giây và truy cập phần cứng trực tiếp, phản ánh các ưu tiên kỹ thuật mà các công ty giao dịch định lượng áp dụng cho cơ sở hạ tầng tài chính truyền thống, nơi tốc độ xử lý được đo bằng micro giây.

Mã nguồn của Firedancer hoàn toàn là mã nguồn mở, có sẵn tại Kho lưu trữ GitHub mã nguồn mở của Firedancer.). Tài liệu kỹ thuật và kết quả đo lường hiệu năng được xuất bản trên blog kỹ thuật Firedancer của Jump Crypto.).


Firedancer Đạt Được Thông Lượng Cực Cao Như Thế Nào: Đi Sâu Vào Kiến Trúc

Firedancer xây dựng dựa trên lợi thế tốc độ hiện có của Solana, đặc biệt là Proof of History (PoH). PoH là một hệ thống giữ thời gian mật mã hoạt động như một đồng hồ bấm giờ chạy liên tục, đóng dấu cho mỗi giao dịch một dấu thời gian có thể xác minh để các validator có thể đồng ý về thứ tự giao dịch mà không cần giao tiếp qua lại làm chậm các mạng khác. Kiến trúc cơ chế đồng thuận của Solana kết hợp PoH để sắp xếp thứ tự giao dịch với Tower BFT (giao thức cơ chế đồng thuận kháng lỗi Byzantine của Solana) để xác định cuối cùng và Proof of Stake (PoS) để lựa chọn validator. PoH không phải là một cơ chế đồng thuận độc lập; nó là một lớp tiền sắp xếp loại bỏ một nút thắt phối hợp chính. Firedancer không thay thế PoH. Nó cải thiện mọi lớp khác của ngăn xếp validator để mở khóa tiềm năng thông lượng đầy đủ của PoH. Các cải tiến bổ sung bao gồm giao thức Gulf Stream của Solana (chuyển tiếp giao dịch không có mempool) và giao thức truyền khối Turbine của nó (phân phối khối lấy cảm hứng từ BitTorrent) hoàn thành nền tảng mà Firedancer hoạt động trên đó. Để biết thêm về PoH, hãy xem tài liệu chính thức của Solana về Proof of History.).

Hãy coi kiến trúc của Firedancer như một dây chuyền lắp ráp nhà máy. Client Agave là một công nhân lành nghề duy nhất xử lý mọi bước sản xuất tuần tự: nhận nguyên liệu, phân loại, xác minh, xử lý và đóng gói. Firedancer biến công nhân duy nhất đó thành một dây chuyền sản xuất chuyên biệt, nơi mỗi trạm xử lý chính xác một nhiệm vụ đồng thời với tất cả các trạm khác. Firedancer gọi các trạm này là các tile.

Firedancer tổ chức công việc của validator thành một quy trình xử lý các giai đoạn xử lý riêng biệt. Mỗi tile xử lý chính xác một công việc, chạy như một tiến trình hệ điều hành riêng biệt và hoạt động đồng thời với tất cả các tile khác:

Net tile: Tiếp nhận các gói tin mạng thô từ card giao diện mạng và đưa chúng vào quy trình.

Verify tile: Thực hiện xác minh chữ ký mật mã trên các giao dịch đến, xác nhận từng giao dịch đã được ủy quyền bởi khóa riêng tư chính xác.

Pack tile: Lên lịch các giao dịch vào các khe khối, quyết định giao dịch nào sẽ được bao gồm và theo thứ tự nào.

Bank tile: Thực thi các giao dịch dựa trên trạng thái sổ cái hiện tại, áp dụng các thay đổi số dư tài khoản và logic chương trình.

PoH tile: Ghi lại bằng chứng thời gian mật mã cho mỗi lô giao dịch đã thực thi.

Gạch lát: Chia các khối đã hoàn thành thành các đơn vị truyền nhỏ hơn và phân tán chúng trên mạng lưới người xác thực.

Vì mỗi gạch hoạt động như một quy trình riêng biệt, lỗi ở một gạch sẽ không lan sang các gạch khác. Đường ống xử lý tiếp tục chạy trong khi gạch bị lỗi khởi động lại. Sealevel, hệ thống xử lý giao dịch song song của Solana, đã xử lý các giao dịch không xung đột đồng thời. Đường ống gạch của Firedancer cung cấp dữ liệu cho hệ thống đó với tốc độ mà kiến trúc của Agave không thể sánh kịp.

Mạng Lưới Bỏ Qua Kernel và DPDK

Quy trình mạng tiêu chuẩn định tuyến dữ liệu đến thông qua ngăn xếp mạng của hệ điều hành trước khi ứng dụng có thể đọc nó, làm tăng độ trễ ở mỗi bước. Firedancer bỏ qua toàn bộ đường dẫn đó bằng cách sử dụng DPDK (Data Plane Development Kit), một thư viện phần mềm cho phép trình xác thực giao tiếp trực tiếp với phần cứng mạng, bỏ qua hoàn toàn ngăn xếp mạng tiêu chuẩn của hệ điều hành.

Sự khác biệt tương tự như một làn thu phí nhanh dành riêng đi thẳng ra đường cao tốc so với đường nhập làn tiêu chuẩn phải đi qua tín hiệu giao thông. DPDK là làn thu phí nhanh: các gói tin đi từ card giao diện mạng đến gạch mạng của Firedancer, giảm độ trễ từ mili giây xuống micro giây.

Tại Sao Firedancer Được Viết Bằng C/C++ Thay Vì Rust

Firedancer được viết bằng C và C++ thay vì Rust, ngôn ngữ mà Agave sử dụng, vì C và C++ cho phép kiểm soát xác định trước đối với việc cấp phát bộ nhớ và các lệnh gọi hệ thống. Trên các đường dẫn nóng nơi độ trễ xử lý được đo bằng micro giây, hành vi bộ nhớ thời gian chạy quan trọng ở mức mà mô hình sở hữu của Rust không được thiết kế để ưu tiên. Rust có hiệu suất cao và Agave hoạt động tốt theo tiêu chuẩn thông thường. Các ưu tiên thiết kế của Firedancer đơn giản làm cho C/C++ trở thành lựa chọn phù hợp hơn.

Agave vs. Firedancer: So Sánh Từng Mục

Tính năngKhách hàng AgaveFiredancer
Ngôn ngữRustC / C++
Kiến trúcNguyên khối (một quy trình)Đường ống gạch mô-đun
Đơn vị bảo trìAnzaJump Crypto
Trạng tháiĐương nhiệm (đa số người xác thực)Triển khai trên mainnet theo giai đoạn
Mục tiêu thiết kế chínhĐộ ổn định, đồng thuận đã được chứng minhThông lượng tối đa, độ trễ tối thiểu

Cả hai khách hàng đều triển khai cùng một giao thức Solana. Chúng không phải là các blockchain cạnh tranh; chúng là những cách thay thế để chạy một trình xác thực Solana.


TPS Solana Firedancer: Phân Tích Tuyên Bố 1.000.000 TPS

Trong các bài kiểm tra benchmark có kiểm soát, trình xác thực Firedancer của Jump Crypto đã chứng minh 1.000.000 giao dịch mỗi giây (TPS), nhưng con số đó có ý nghĩa cụ thể. Hiểu nó đòi hỏi phải tách biệt ba phép đo TPS riêng biệt mà hầu hết các bài viết gộp chung.

TPS đo lường số lượng giao dịch riêng lẻ mà một mạng có thể xử lý và xác nhận trong một giây. Hãy coi nó như các làn trên đường cao tốc: nhiều làn hơn có nghĩa là nhiều xe (hoặc giao dịch) có thể di chuyển đồng thời mà không bị tắc nghẽn. Kiến trúc hiện có của Solana đã mang lại cho nó nhiều làn hơn Bitcoin hoặc Ethereum. Firedancer mở rộng con đường đó theo cấp số nhân. Nhưng số làn mà một con đường có thể xử lý về mặt lý thuyết, số lượng mà nó xử lý dưới bài kiểm tra sức chịu tải, và số lượng mà nó xử lý trong giờ cao điểm sáng thứ Ba điển hình là ba con số khác nhau.

Phân biệt ba loại TPS

Loại TPSCon sốĐiều kiệnNguồn
Benchmark TPS1.000.000 TPSKiểm tra testnet nội bộ của Jump Crypto, 2023; phần cứng và loại giao dịch có kiểm soát; không phải đo lường trên mainnet trực tiếpBlog kỹ thuật Firedancer của Jump Crypto)
TPS Tối đa Lý thuyết~65.000 TPSGiới hạn kiến trúc L1 Solana hiện tại trong điều kiện mạng lý tưởng; hiếm khi duy trì trong sản xuấtTài liệu chính thức của Solana
TPS Thực tếTổng cộng 2.000–4.000 TPS; 400–1.000 TPS không bỏ phiếuMức trung bình trên mainnet trực tiếp (dữ liệu 2024–2025); giao dịch không bỏ phiếu đại diện cho hoạt động của người dùng thực tếDữ liệu TPS Solana thời gian thực trên Solscan

Bản nháp nguồn không trích dẫn xác minh độc lập của bên thứ ba cho benchmark 1M TPS. Con số này đại diện cho giới hạn kiến trúc trong điều kiện tối ưu, không phải là sự đảm bảo về hiệu suất mainnet được duy trì.

Lưu ý về giao dịch bỏ phiếu: Người xác thực Solana truyền tin nhắn bỏ phiếu đồng thuận trên chuỗi dưới dạng giao dịch thực tế, được tính vào tổng số TPS. Đây không phải là giao dịch người dùng. TPS không bỏ phiếu (400–1.000 TPS) là benchmark có ý nghĩa hơn để đánh giá thông lượng ứng dụng của Solana. Khoảng cách giữa benchmark và TPS thực tế phản ánh các ràng buộc về sự lan truyền mạng, sự khác biệt về phần cứng trên bộ người xác thực, động lực thị trường phí giao dịch và thực tế là Firedancer hoàn chỉnh chưa được triển khai trên tất cả người xác thực.

Khi việc áp dụng Firedancer tăng lên trên mainnet, khoảng cách giữa các con số benchmark và thực tế dự kiến sẽ thu hẹp, nhưng dòng thời gian triển khai đầy đủ vẫn đang phát triển.


TPS Solana Firedancer So Với Ethereum, Bitcoin, Visa và SWIFT

TPS thực tế hiện tại của Solana là 2.000–4.000 đã vượt trội hơn thông lượng của Ethereum Layer 1 khoảng 100 lần và Bitcoin khoảng 400 lần. Con số benchmark của Firedancer mở rộng khoảng cách đó lên một quy mô khác, mặc dù việc so sánh liên quan đến các loại con số khác nhau trong các điều kiện khác nhau.

So sánh TPS trực tiếp giữa các mạng blockchain và các bộ xử lý thanh toán truyền thống đóng vai trò là minh họa quy mô, không phải là sự tương đương về kiến trúc. Visa vận hành một cơ sở dữ liệu tập trung mà không yêu cầu đồng thuận phi tập trung. Solana xử lý giao dịch trên hơn 1.900 trình xác thực độc lập, những người phải đạt được thỏa thuận trước khi hoàn tất bất kỳ giao dịch nào. Tam giác tỷ lệ của blockchain nắm bắt lý do tại sao điều này khó khăn: một blockchain có thể đạt được tối đa hai trong ba thuộc tính cùng một lúc (khả năng mở rộng, bảo mật và phân quyền). Firedancer giải quyết khả năng mở rộng đồng thời cải thiện bảo mật thông qua sự đa dạng của các khách hàng.

So Sánh TPS: Solana Firedancer vs. Các Blockchain và Mạng Thanh Toán Chính (2025)

Mạng / Hệ thốngTPS Thực tế Điển hìnhTPS Lý thuyết / Đỉnh điểmGhi chú
Solana (hiện tại, trước Firedancer đầy đủ)Tổng cộng 2.000–4.000; 400–1.000 không bỏ phiếu~65.000Tính đến năm 2024–2025; không bỏ phiếu = giao dịch người dùng thực tế
Solana + Firedancer (benchmark)Chưa đo lường ở quy mô trên mainnet1.000.000Benchmark testnet của Jump Crypto, 2023; điều kiện có kiểm soát
Ethereum L1~15–30~30Theo thiết kế; dựa vào các Rollups Layer 2 để mở rộng khả năng
Ethereum L2 (Arbitrum / Optimism / Base)~2.000–4.000 (tổng hợp)Thay đổi theo L2Gộp ngoài chuỗi được đăng lại lên Ethereum L1
Bitcoin~7~7Lớp cơ sở theo thiết kế; ưu tiên bảo mật hơn thông lượng; mạng Lightning không bao gồm
Ripple (XRP)~1.500~1.500Tập trung vào thanh toán; tập hợp người xác thực tập trung
Avalanche~4.500~4.500Kiến trúc Subnet; các con số thay đổi theo subnet
Visa~24.000~65.000+ (tuyên bố đỉnh)Bộ xử lý thanh toán tập trung; không phải mạng phi tập trung
Mastercard~5.000~5.000Bộ xử lý thanh toán tập trung
SWIFT~50 (tương đương tin nhắn/giây)Không áp dụngLớp nhắn tin ngân hàng, không phải chuỗi quyết toán; ~42 triệu tin nhắn mỗi ngày

So sánh có liên quan thương mại nhất là con số benchmark của Solana so với Ethereum L1: benchmark 1M TPS của Firedancer đại diện cho khoảng 33.000 lần thông lượng của Ethereum Layer 1. Ethereum theo đuổi khả năng mở rộng thông qua các giải pháp Layer 2 (L2) như Arbitrum, Optimism, và Base, xử lý các giao dịch ngoài chuỗi chính của Ethereum và định kỳ đăng bằng chứng trở lại L1. Cách tiếp cận đó đạt được quy mô nhưng mang lại sự phức tạp thông qua cầu nối, phân mảnh thanh khoản và các giả định tin cậy bổ sung. Solana theo đuổi khả năng mở rộng trực tiếp tại Layer 1, bảo tồn khả năng kết hợp của một mạng thống nhất duy nhất.

Để có bảng phân tích chi tiết về sự khác biệt giữa cách tiếp cận của Solana và Ethereum, hãy xem bản so sánh hiệu suất Solana và Ethereum của chúng tôi. Để biết thêm bối cảnh về sự khác biệt hiệu suất giữa Ethereum và Bitcoin, bản so sánh hiệu suất Ethereum và Bitcoin sẽ bao gồm các điểm khác biệt chính.


Từ Frankendancer đến Firedancer: Lộ trình triển khai và Trạng thái Mainnet theo nguồn dữ liệu

Frankendancer là một validator client lai tạm thời kết hợp lớp mạng hiệu suất cao của Firedancer với logic thực thi và đồng thuận đã được thiết lập của Agave. Đây là một điểm trung gian có tính toán, được thiết kế để cho phép các validator áp dụng các cải tiến về tốc độ của Firedancer mà không cần từ bỏ ngay lập tức các hành vi đồng thuận đã được thử nghiệm qua thực tế của Agave. Firedancer không có một ngày ra mắt duy nhất. Quá trình triển khai của nó đang diễn ra theo từng giai đoạn, mỗi giai đoạn đại diện cho một bước tiến đã được thử nghiệm và xác minh hướng tới việc thay thế hoàn toàn client.

Frankendancer là gì?

Frankendancer có cái tên không chính thức được kết hợp từ Frankenstein và Firedancer, phản ánh bản chất lai của nó: ngăn xếp mạng front-end tốc độ cao của Firedancer được ghép vào back-end thực thi và đồng thuận đã được chứng minh của Agave. Tên gọi này mang tính thông tục và được sử dụng rộng rãi trong cộng đồng nhà phát triển Solana.

Frankendancer không phải là một Blockchain riêng biệt, một token riêng biệt hay một giải pháp vĩnh viễn. Nó là một cấu hình chuyển đổi cung cấp cho các validator quyền truy cập vào các ô (tiles) xử lý gói tin và mạng của Firedancer trong khi vẫn giữ lại logic đồng thuận của Agave. Cách tiếp cận theo từng giai đoạn này cho phép mạng lưới tích lũy kinh nghiệm thực tế với các thành phần của Firedancer trước khi cam kết thay thế hoàn toàn. Frankendancer đã mang lại những cải thiện có thể đo lường được về TPS và độ trễ so với việc chỉ dùng Agave, mặc dù chưa đạt đến ngưỡng hiệu suất tối đa của Firedancer.

Các cột mốc triển khai Firedancer

Việc triển khai mainnet của Firedancer đang diễn ra theo từng giai đoạn, không có một ngày ra mắt công khai duy nhất.

Cột mốcTrạng thái / NgàyNguồn
Firedancer được công bố bởi Jump Crypto2022Blog Jump Crypto
Kho lưu trữ GitHub của Firedancer được công khai2022–2023Kho lưu trữ GitHub mã nguồn mở của Firedancer
Trình diễn benchmark 1 triệu TPS (testnet)2023Thử nghiệm nội bộ Jump Crypto
Bắt đầu triển khai Frankendancer trên mainnet2024Jump Crypto / Solana Foundation
Triển khai Firedancer toàn phần theo giai đoạn trên mainnet2024–2025 (đang diễn ra)Phân phối validator client hiện tại trên solana.com

Các chỉ số triển khai được cập nhật liên tục. Để biết các số liệu về việc áp dụng validator client hiện tại, hãy xem phân phối validator client hiện tại trên solana.com.. Tỷ lệ Stake của mạng chạy Frankendancer hoặc Firedancer toàn phần ảnh hưởng trực tiếp đến việc cải thiện TPS thực tế tổng thể.

Dành cho các Đơn vị vận hành Validator: Firedancer yêu cầu thẻ giao tiếp mạng (NIC) hỗ trợ driver DPDK cho ngăn xếp mạng bỏ qua kernel (kernel-bypass). Các yêu cầu phần cứng cụ thể có thể thay đổi khi phần mềm hoàn thiện hơn. Các validator đang đánh giá việc di chuyển nên tham khảo kho lưu trữ GitHub mã nguồn mở của Firedancer để biết các thông số phần cứng hiện tại và tài liệu hướng dẫn di chuyển.


Cách Firedancer cải thiện độ tin cậy của mạng Solana và giảm rủi ro gián đoạn

Tính đa dạng của client có nghĩa là nhiều bản thực thi phần mềm độc lập của cùng một giao thức Blockchain chạy đồng thời trên các validator khác nhau, và đây là một trong hai cải tiến chính về độ tin cậy mà Firedancer mang lại cho Solana bên cạnh việc tăng thông lượng thô. Nếu mọi validator Solana đều chạy cùng một phần mềm, một lỗi nghiêm trọng duy nhất trong phần mềm đó có thể làm sập hoặc dừng toàn bộ mạng lưới cùng lúc, vì tất cả các validator đều thất bại cùng nhau. Với hai client độc lập chạy song song, một lỗi làm sập các validator Agave sẽ vẫn để các validator Firedancer hoạt động bình thường.

Việc chạy hai validator client độc lập trên mạng của Solana hoạt động giống như việc có hai nhà sản xuất động cơ riêng biệt cung cấp cho một đội máy bay. Nếu động cơ của một nhà sản xuất gặp lỗi nghiêm trọng, các hãng hàng không sử dụng động cơ của nhà sản xuất kia vẫn tiếp tục bay. Một đội bay chỉ có một nhà cung cấp duy nhất sẽ khiến mọi chiếc máy bay phải nằm đất đồng thời. Kiến trúc trước Firedancer của Solana chính là đội bay chỉ có một nhà cung cấp đó.

Solana đã trải qua nhiều đợt gián đoạn mạng từ năm 2021 đến 2023, nguyên nhân do các cuộc tấn công spam giao dịch làm quá tải bộ nhớ validator, các lỗi đồng thuận trong client Agave và các nút validator bị cấu hình sai. Tắc nghẽn mạng (tình trạng nhu cầu giao dịch vượt quá khả năng xử lý của mạng, khiến các giao dịch thất bại, xếp hàng vô thời hạn hoặc yêu cầu phí cao hơn) là một cơ chế lặp đi lặp lại trong các sự kiện đó.

Firedancer giảm đáng kể khả năng bị tổn thương của Solana trước hai loại gián đoạn mạng. Ngưỡng thông lượng cao hơn của nó tạo ra nhiều không gian hơn trước khi tình trạng tắc nghẽn xảy ra. Và cơ sở mã độc lập của nó có nghĩa là một lỗi phần mềm ảnh hưởng đến Agave sẽ không lan sang các validator Firedancer. Cả hai client đều thực hiện cùng một giao thức nhưng không chia sẻ mã nguồn, vì vậy một lỗi logic ở client này không tạo ra lỗi tương quan trên toàn bộ mạng lưới.

Mạng của Ethereum đã trở nên kiên cường hơn rõ rệt khi đạt được sự đa dạng client có ý nghĩa giữa Lighthouse, Prysm và Teku. Không có client đơn lẻ nào kiểm soát đại đa số bộ validator của Ethereum, điều đó có nghĩa là bất kỳ lỗi client riêng lẻ nào cũng chỉ ảnh hưởng đến một nhóm nhỏ các validator. Solana đang theo đuổi khả năng phục hồi kiến trúc tương tự thông qua Firedancer.

Firedancer không phải là sự đảm bảo chống lại tất cả các lần ngừng hoạt động trong tương lai. Độ tin cậy của mạng cũng phụ thuộc vào chất lượng phần cứng của validator, sự phân bổ địa lý và các cải tiến ở cấp độ giao thức. Những gì Firedancer cung cấp là sự giảm thiểu về mặt cấu trúc đối với xác suất của hai chế độ lỗi phổ biến nhất trong lịch sử: chậm trễ do tắc nghẽn và các lỗi tương quan của một client duy nhất.


Các trường hợp sử dụng thực tế mà TPS của Firedancer mở khóa trên Solana

Thông lượng cao hơn tại Layer 1 loại bỏ rào cản hiện đang hạn chế một số loại ứng dụng nhất định trên Solana, đặc biệt là những ứng dụng yêu cầu Quyết toán gần như thời gian thực, Thanh khoản Sổ lệnh sâu hoặc các dòng vi thanh toán liên tục. Các hợp đồng thông minh (được gọi là các chương trình trong tài liệu chính thức của Solana) cung cấp sức mạnh cho DeFi, Gaming và các ứng dụng thanh toán trên mạng lưới. Mỗi trường hợp sử dụng sau đây mang theo các yêu cầu về thông lượng cụ thể mà kiến trúc của Firedancer nhắm trực tiếp đến.

DeFi và Sổ lệnh Trên chuỗi

Các ứng dụng Tài chính phi tập trung (DeFi), bao gồm giao dịch, cho vay, Phái sinh và yield farming chạy qua các hợp đồng thông minh mà không có trung gian tập trung, về cơ bản bị giới hạn bởi TPS và tốc độ hoàn tất của Blockchain. Các Sổ lệnh Trên chuỗi mô phỏng hoàn toàn chức năng của một lệnh Giới hạn trung tâm (CLOB) truyền thống Trên chuỗi. Mỗi lệnh mua, mỗi lệnh bán, mỗi khớp lệnh, mỗi lệnh hủy là một giao dịch riêng lẻ. Với TPS thực tế hiện tại của Solana, các Nền tảng như OpenBook (Sổ lệnh Trên chuỗi của Solana) và Drift Protocol (một Nền tảng giao dịch hợp đồng vĩnh cửu) có thể hoạt động, nhưng độ sâu Sổ lệnh và tốc độ thực thi vẫn bị hạn chế so với các Sàn giao dịch tập trung. Với ngưỡng thông lượng cao hơn của Firedancer, các Sổ lệnh Trên chuỗi có thể tiếp cận độ sâu thực thi và tốc độ của hạ tầng Sàn giao dịch tập trung, làm cho giao dịch phi tập trung thực sự cạnh tranh với các địa điểm lưu ký. Cả Sàn giao dịch tập trung và phi tập trung đều được hưởng lợi từ việc Quyết toán nhanh hơn và chi phí giao dịch thấp hơn.

Thanh toán toàn cầu và Vi thanh toán

Ở mức thông lượng chuẩn, Solana được kích hoạt bởi Firedancer về lý thuyết có thể xử lý khối lượng giao dịch kết hợp của Visa (~24.000 TPS trung bình) và Mastercard (~5.000 TPS) đồng thời với dung lượng còn lại. Quy mô đó định vị Solana như một cơ sở hạ tầng đáng tin cậy cho việc quyết toán thanh toán toàn cầu ngoài các giao dịch chuyển tiền điện tử sang tiền điện tử. Solana Pay, một giao thức thanh toán hiện có được xây dựng trên Solana, đã cho phép thanh toán tại điểm bán hàng với tính cuối cùng dưới một giây (thời điểm giao dịch trở nên không thể đảo ngược trên sổ cái). Thông lượng cao hơn của Firedancer cũng thay đổi kinh tế học của các khoản thanh toán siêu nhỏ: các giao dịch chỉ một phần nhỏ của xu trở nên khả thi ở quy mô lớn khi chi phí mạng trải rộng trên khối lượng giao dịch lớn hơn nhiều.

Các ứng dụng Gaming yêu cầu xử lý giao dịch theo thời gian thực. Việc chuyển tài sản trong game, giao dịch trên thị trường và cập nhật trạng thái phải hoàn thành trong mili giây để người chơi cảm thấy phản hồi nhanh. Thời gian khối hiện tại của Solana khoảng 400 mili giây đã cạnh tranh với các nền tảng game blockchain khác, nhưng logic game yêu cầu nhiều giao dịch nối tiếp mỗi giây cho mỗi người chơi sẽ nhanh chóng đạt đến giới hạn thông lượng hiện tại. TPS cao hơn và độ trễ thấp hơn của Firedancer làm cho Solana trở thành cơ sở hạ tầng khả thi cho game thời gian thực, nơi tốc độ blockchain hiện tại tạo ra độ trễ đáng chú ý. Các thiết kế game trước đây yêu cầu quản lý trạng thái ngoài chuỗi để duy trì phản hồi có thể chuyển nhiều logic lên trên chuỗi với hồ sơ hiệu suất của Firedancer.


Firedancer có ý nghĩa gì đối với các nhà đầu tư Solana (SOL) và hệ sinh thái

Firedancer củng cố nền tảng kỹ thuật của Solana trên ba phương diện quan trọng đối với việc áp dụng hệ sinh thái: năng lực thông lượng thô, độ tin cậy của mạng và sự khác biệt cạnh tranh so với phương pháp mở rộng quy mô phụ thuộc vào Layer 2 của Ethereum.

Tuyên bố miễn trừ trách nhiệm: Phần này thảo luận về các tác động tiềm tàng của các phát triển kỹ thuật đối với hệ sinh thái Solana. Phần này không cấu thành lời khuyên tài chính hoặc đầu tư. Các khoản đầu tư tiền điện tử mang rủi ro đáng kể, bao gồm cả rủi ro mất toàn bộ vốn. Thực hiện nghiên cứu của riêng bạn và tham khảo ý kiến của cố vấn tài chính đủ năng lực trước khi đưa ra quyết định đầu tư.

Lợi thế kỹ thuật. Trong số các blockchain Layer 1 chính, con số TPS chuẩn của Firedancer đứng một mình mà không có đối thủ được công bố. Nếu triển khai đầy đủ diễn ra theo đúng quỹ đạo hiện tại, TPS thực tế của Solana có thể mở rộng đáng kể vượt xa mức hiện tại khi việc áp dụng trình xác thực tăng lên. Lãnh đạo về thông lượng đó có thể thu hút các loại ứng dụng hiện không có không gian trên chuỗi khả thi trên bất kỳ mạng lưới cạnh tranh nào, bao gồm cả giao dịch tần suất cao, quyết toán theo thời gian thực và cơ sở hạ tầng thanh toán toàn cầu.

Độ tin cậy và sự tự tin của nhà phát triển. Các sự cố ngừng hoạt động mà Solana gặp phải từ năm 2021 đến 2023 đã gây tổn hại danh tiếng với các nhà phát triển và người dùng tổ chức những người yêu cầu cơ sở hạ tầng đáng tin cậy. Sự đa dạng về trình khách của Firedancer giải quyết gốc rễ cấu trúc của những thất bại đó. Khi Frankendancer được áp dụng rộng rãi hơn và Firedancer đầy đủ được triển khai, kỷ lục thời gian hoạt động được chứng minh của mạng có thể hỗ trợ sự tự tin ngày càng tăng của nhà phát triển, mặc dù điều này phụ thuộc vào tiến trình triển khai liên tục và sự vắng mặt của các chế độ lỗi mới.

Nhu cầu hệ sinh thái. Thông lượng cao hơn hỗ trợ nhiều hoạt động DeFi hơn, tạo ra nhiều phí giao dịch hơn, có thể hỗ trợ bảo mật mạng và kinh tế học của trình xác thực. Cơ sở hạ tầng có khả năng hơn thu hút nhiều nhà phát triển hơn, những người xây dựng nhiều ứng dụng hơn, những người thu hút nhiều người dùng hơn. Việc liệu bất kỳ chuỗi nào trong số đó có chuyển thành sự tăng giá của token SOL hay không phụ thuộc vào các yếu tố vượt xa hiệu suất kỹ thuật: môi trường pháp lý, chu kỳ thị trường rộng lớn hơn và tốc độ triển khai của Firedancer.

Để biết dữ liệu thị trường SOL hiện tại, hãy tham khảo dữ liệu thị trường trực tiếp từ một nguồn thị trường hiện tại. Bài viết này không cung cấp dự đoán giá.


Câu hỏi thường gặp về TPS Firedancer của Solana

TPS hiện tại của Solana là bao nhiêu?

Tính đến năm 2024–2025, Solana xử lý khoảng 2.000–4.000 TPS tổng cộng trên mainnet (mạng sản xuất trực tiếp), bao gồm cả các giao dịch bỏ phiếu của trình xác thực. Các giao dịch không bỏ phiếu, đại diện cho hoạt động người dùng thực tế, trung bình là 400–1.000 TPS. Số liệu thời gian thực có sẵn tại dữ liệu TPS Solana thời gian thực trên Solscan. Các số liệu này sẽ phát triển khi việc áp dụng Firedancer tăng lên trên bộ trình xác thực.

Firedancer là một trình khách trình xác thực độc lập cho Solana, được viết bằng C/C++ bởi Jump Crypto, đã chứng minh 1.000.000 TPS trong các bài kiểm tra chuẩn có kiểm soát vào năm 2023. Nó quan trọng vì hai lý do: nó đẩy trần thông lượng của Solana vượt xa những gì trình khách Agave đạt được, và nó giới thiệu sự đa dạng về trình khách (một cơ sở mã độc lập thứ hai) làm giảm rủi ro các lỗi trên toàn mạng từ một lỗi phần mềm duy nhất.

Vâng, trong các bài kiểm tra chuẩn có kiểm soát được thực hiện bởi Jump Crypto vào năm 2023. Con số đó đại diện cho một trần kiến trúc trong điều kiện testnet tối ưu, không phải hiệu suất mainnet hiện tại. Bản nháp nguồn báo cáo phạm vi mainnet là 2.000–4.000 TPS tổng cộng cho ảnh chụp nhanh đã lỗi thời của nó. Con số 1 triệu cho thấy những gì kiến trúc của Firedancer có thể duy trì về mặt lý thuyết; TPS mainnet thực tế có thể thay đổi khi việc áp dụng trình xác thực phát triển. TPS chuẩn, TPS lý thuyết và TPS thực tế là ba phép đo riêng biệt không nên bị nhầm lẫn.

TPS thực tế của Solana là 2.000–4.000 vượt quá Ethereum L1 (~15–30 TPS) khoảng 100 lần và Bitcoin (~7 TPS) khoảng 400 lần. Với chuẩn 1M TPS của Firedancer, khoảng cách mở rộng lên khoảng 33.000 lần so với Ethereum L1. TPS thấp của Bitcoin là có chủ đích: thiết kế của nó ưu tiên bảo mật và phân quyền hơn thông lượng. Ethereum giải quyết vấn đề mở rộng quy mô thông qua các giải pháp Layer 2 thay vì thay đổi kiến trúc L1.

Firedancer giải quyết tình trạng tắc nghẽn thông qua hai cơ chế: bằng cách nâng cao trần thông lượng để các đợt tăng nhu cầu ít có khả năng làm quá tải công suất xử lý, và bằng cách giới thiệu sự đa dạng về trình khách để một lỗi gây tắc nghẽn làm sập các trình xác thực Agave không đồng thời dừng các trình xác thực Firedancer. Hãy coi đó là việc vừa mở rộng đường cao tốc vừa đảm bảo một sự cố ở một làn đường không chặn tất cả giao thông.

Trình khách Agave, được duy trì bởi Anza, là phần mềm trình xác thực ban đầu của Solana được viết bằng Rust với kiến trúc nguyên khối, nơi tất cả các tác vụ xử lý chạy trong một quy trình hợp nhất duy nhất. Firedancer, được duy trì bởi Jump Crypto, là một triển khai độc lập mới được viết bằng C/C++ với kiến trúc đường ống dựa trên các ô mô-đun, nơi mỗi tác vụ xử lý chạy như một quy trình biệt lập. Cả hai trình khách đều triển khai cùng một giao thức Solana. Chúng là những cách thay thế để chạy một trình xác thực Solana, không phải là các blockchain cạnh tranh.

Frankendancer là một trình khách trình xác thực lai kết hợp lớp mạng hiệu suất cao của Firedancer với logic đồng thuận và thực thi đã được thiết lập của Agave. Tên không chính thức đến từ Frankenstein kết hợp với Firedancer, phản ánh bản chất lai của nó. Đây là giai đoạn chuyển tiếp giữa việc chạy Agave đơn lẻ và chạy Firedancer đầy đủ, và nó bắt đầu triển khai mainnet vào năm 2024. Frankendancer không phải là một blockchain, token hay giao thức riêng biệt.

Firedancer không có một ngày ra mắt duy nhất. Việc triển khai đang diễn ra theo từng giai đoạn. Bản nháp nguồn mô tả Frankendancer hoạt động trên mainnet và Firedancer đầy đủ đang trong giai đoạn triển khai theo từng giai đoạn trong năm 2024–2025. Chưa có ngày công khai nào cho việc hoàn thành triển khai đầy đủ được xác nhận. Để biết dữ liệu áp dụng trình khách trình xác thực trực tiếp, hãy kiểm tra phân phối trình khách trình xác thực hiện tại trên solana.com.

Có. Firedancer cải thiện độ tin cậy thông qua hai cơ chế: khả năng thông lượng cao hơn giúp giảm xác suất lỗi do tắc nghẽn và tính đa dạng của client đảm bảo rằng một lỗi phần mềm ảnh hưởng đến một client validator sẽ không làm dừng toàn bộ mạng lưới. Kinh nghiệm của Ethereum với nhiều client đồng thuận (Lighthouse, Prysm, Teku) đã chứng minh cách tiếp cận này: khả năng phục hồi của mạng lưới được cải thiện rõ rệt khi Ethereum đạt được sự phân bổ client có ý nghĩa. Firedancer không phải là sự đảm bảo chống lại tất cả các sự cố ngừng hoạt động trong tương lai, nhưng nó giải quyết hai chế độ lỗi phổ biến nhất trong lịch sử.

Kiến trúc của Firedancer khác với các trình xác thực blockchain khác như thế nào?

Hầu hết các trình xác thực blockchain sử dụng kiến trúc nguyên khối, nơi tất cả các tác vụ xử lý chạy trong một quy trình thống nhất duy nhất. Firedancer sử dụng một quy trình dựa trên các tile (mô-đun), trong đó mỗi tác vụ (tiếp nhận mạng, xác minh chữ ký, thực thi giao dịch, ghi chép khối) chạy như một quy trình độc lập đồng thời với các quy trình khác. Lỗi ở một tile sẽ không gây ảnh hưởng dây chuyền đến toàn bộ quy trình. Đây vừa là một tính năng hiệu suất (thực thi song song) vừa là một tính năng tin cậy (cô lập lỗi giữa các giai đoạn xử lý).

Tốc độ của Solana so với các hệ thống thanh toán truyền thống như Visa như thế nào?

TPS thực tế hiện tại của Solana từ 2.000–4.000 đã bao phủ một phần đáng kể tải mạng trung bình của Visa (trung bình ~24.000 TPS). Con số chuẩn 1.000.000 TPS của Firedancer gấp khoảng 40 lần thông lượng xử lý trung bình của Visa. Việc so sánh trực tiếp đòi hỏi phải thừa nhận rằng Visa vận hành một cơ sở dữ liệu tập trung trong khi Solana vận hành một mạng lưới phi tập trung gồm hơn 1.900 trình xác thực, khiến thông lượng tương đương của Solana khó đạt được hơn về mặt kiến trúc.

Firedancer được viết bằng ngôn ngữ lập trình nào và tại sao nó lại quan trọng?

Firedancer được viết bằng C và C++, các ngôn ngữ cấp thấp hơn so với Rust mà Agave sử dụng. C và C++ cho phép kiểm soát xác định đối với việc phân bổ bộ nhớ và truy cập trực tiếp vào các nguyên hàm phần cứng, những đặc tính quan trọng khi các mục tiêu độ trễ xử lý được đo bằng micro giây. Lựa chọn này cho phép mạng lưới bỏ qua kernel (kernel-bypass) của Firedancer thông qua DPDK, nơi các gói tin đi trực tiếp từ card giao tiếp mạng đến ứng dụng mà không cần đi qua ngăn xếp mạng của hệ điều hành.

Solana có nhanh hơn Ripple (XRP) không?

Có. TPS thực tế của Solana từ 2.000–4.000 đã vượt quá thông lượng mạng của Ripple là khoảng 1.500 TPS. Với con số chuẩn 1.000.000 TPS của Firedancer, khoảng cách này nới rộng đáng kể, mặc dù con số chuẩn đó đến từ các điều kiện testnet được kiểm soát, không phải hiệu suất Mainnet duy trì. Ripple nhắm mục tiêu Quyết toán thanh toán với một nhóm trình xác thực tập trung; Solana nhắm mục tiêu thực thi Hợp đồng Thông minh đa mục đích với một mạng lưới trình xác thực phi tập trung.

Những ứng dụng nào sẽ được Firedancer hỗ trợ trên Solana?

Khả năng thông lượng cao hơn của Firedancer mở rộng tính khả thi của các sổ lệnh Trên chuỗi (chẳng hạn như OpenBook), các nền tảng phái sinh vĩnh cửu (chẳng hạn như Drift Protocol), Quyết toán thanh toán theo thời gian thực và các ứng dụng Gaming blockchain yêu cầu tính hoàn tất giao dịch dưới một giây. Bất kỳ danh mục ứng dụng nào mà TPS hiện tại của Solana tạo ra trần thông lượng, bao gồm các chiến lược DeFi tần suất cao, nền kinh tế Gaming nhiều người chơi theo thời gian thực và cơ sở hạ tầng thanh toán vi mô toàn cầu, đều trở nên khả thi hơn khi việc triển khai Firedancer tiến triển.

Firedancer ảnh hưởng như thế nào đến Giá token SOL?

Firedancer củng cố nền tảng kỹ thuật của Solana, điều này có thể hỗ trợ việc áp dụng hệ sinh thái và hoạt động mạng lưới, nhưng các nâng cấp hiệu suất blockchain không tự động chuyển hóa thành việc tăng Giá token. Các điều kiện thị trường, môi trường pháp lý, tỷ lệ chấp nhận của nhà phát triển và các chu kỳ thị trường Tiền điện tử rộng lớn hơn đều ảnh hưởng đến giá trị của SOL độc lập với các cải tiến kỹ thuật. Đây không phải là lời khuyên tài chính. Thị trường Tiền điện tử luôn biến động và hiệu suất trong quá khứ không đảm bảo cho kết quả trong tương lai. Hãy sử dụng nguồn thị trường trực tiếp để biết dữ liệu thị trường SOL hiện tại.


Kết luận: Vai trò của Firedancer trong tương lai hiệu suất cao của Solana

Firedancer đại diện cho một bước tiến kiến trúc đã được ghi nhận cho Solana: mức chuẩn đã được xác minh là 1.000.000 TPS trong thử nghiệm có kiểm soát, triển khai phân đoạn tích cực thông qua Frankendancer trên Mainnet và cải thiện độ tin cậy về cấu trúc thông qua tính đa dạng của client giúp giải quyết lỗ hổng từng góp phần vào các gián đoạn mạng lịch sử của Solana.

Con số 1.000.000 TPS đại diện cho tiềm năng chuẩn của Firedancer, không phải thực tế Mainnet hiện tại. Bản thảo nguồn báo cáo tổng cộng 2.000–4.000 TPS và 400–1.000 TPS không phải bỏ phiếu cho ảnh chụp nhanh đã cũ của nó. Nền tảng kiến trúc để tiếp cận thông lượng duy trì cao hơn nhiều đã được chứng minh là sẵn sàng và quá trình tiến triển từ Frankendancer đến Firedancer đầy đủ là con đường mà các con số thực tế có thể thay đổi khi việc áp dụng trình xác thực phát triển.

Đối với các nhà phát triển đang đánh giá Solana cho các ứng dụng nhạy cảm với độ trễ, đối với các nhà đầu tư đang đánh giá sự khác biệt kỹ thuật của Solana và đối với các trình xác thực đang cân nhắc quyết định di chuyển, tầm quan trọng của Firedancer nằm ở những gì nó mang lại khả thi trong DeFi, thanh toán, Gaming và tài chính tổ chức, chứ không chỉ là con số chuẩn Headline.

Để tìm hiểu trực tiếp các thông số kỹ thuật của Firedancer, kho lưu trữ GitHub mã nguồn mở của Firedancer và blog kỹ thuật Firedancer của Jump Crypto là những nguồn sơ cấp có thẩm quyền.

Bài đọc liên quan:

  • Ethereum vs. Bitcoin: Bên nào có tiềm năng tăng giá nhiều hơn
  • Near Intents: Giao dịch Blockchain dựa trên ý định

Hướng dẫn kỹ thuật Solana liên quan

Người đọc so sánh sự phát triển mạng lưới với hoạt động thị trường có thể sử dụng trang giá SOL và thị trường Giao ngay SOL/USDT làm các tham chiếu thị trường riêng biệt.