Trình xác nhận Firedancer ra mắt, mở đường cho việc áp dụng đại trà Solana
Bài viết này đến từ:《What is Firedancer? A Deep Dive into Solana 2.0 》
Tác giả gốc: 0xIchigo
Odaily Translator: Chồng thế nào
Như chúng ta đã biết, Solana là một trong những đại diện có hiệu suất cao trong public chain hiện nay, tốc độ xử lý on-chain nhanh hơn được nhiều bên dự án săn đón và cũng thu hút được sự ưu ái của những gã khổng lồ truyền thống như Visa. Tuy nhiên, Solana luôn tiềm ẩn nguy cơ ngừng hoạt động của mạng. Làm thế nào để giải quyết vấn đề ngừng hoạt động của mạng? Ứng dụng khách Firedancer mà Jump sẽ khởi chạy để xác minh ứng dụng khách của mình có thể đưa ra câu trả lời.
Bài viết này sẽ bắt đầu với vai trò của trình xác thực và ứng dụng khách xác thực trên blockchain, đồng thời khám phá cách ứng dụng khách trình xác thực Firedancer hỗ trợ mạng Solana.
Phần sau đây được tổng hợp bởi Odaily.
Tính đa dạng của trình xác thực và trình xác thực của khách hàng là gì?
Trình xác thực là các máy tính tham gia vào chuỗi khối bằng chứng cổ phần. Trình xác thực là xương sống của mạng Solana, chịu trách nhiệm xử lý các giao dịch và tham gia vào quá trình đồng thuận. Trình xác thực bảo mật mạng bằng cách khóa một lượng token gốc nhất định của Solana làm tài sản thế chấp. Mã thông báo đặt cược có thể được coi là một khoản tiền gửi bảo mật giúp kết nối những người xác thực với mạng một cách kinh tế. Kết nối này khuyến khích người xác thực thực hiện các nhiệm vụ một cách chính xác và hiệu quả vì họ được khen thưởng dựa trên những đóng góp của mình. Đồng thời, người xác nhận cũng sẽ bị phạt nếu có hành vi cố ý hoặc hoạt động sai chức năng. Vốn chủ sở hữu của người xác nhận sẽ bị giảm do hành vi không đúng đắn, một quá trình được gọi là giảm bớt. Do đó, những người xác nhận có mọi động cơ để thực hiện nhiệm vụ của mình một cách chính xác nhằm tăng số cổ phần của họ.
Máy khách của trình xác thực là ứng dụng được trình xác thực sử dụng để thực hiện các tác vụ. Khách hàng là cơ sở của người xác nhận, tham gia vào quá trình đồng thuận thông qua danh tính duy nhất về mặt mật mã của nó.
Có nhiều khách hàng khác nhau sẽ cải thiện khả năng chịu lỗi. Ví dụ: nếu không có khách hàng nào kiểm soát hơn 33% thị phần thì một sự cố hoặc lỗi ảnh hưởng đến hoạt động sẽ không làm mạng bị hỏng. Tương tự, nếu một máy khách gặp lỗi gây ra chuyển đổi trạng thái không hợp lệ và có ít hơn 33% cổ phần sử dụng máy khách đó thì mạng sẽ được bảo vệ khỏi lỗi bảo mật. Điều này là do phần lớn mạng sẽ vẫn ở trạng thái hợp lệ, ngăn chặn việc phân tách hoặc phân tách chuỗi khối. Do đó, sự đa dạng của các máy khách xác thực có thể cải thiện khả năng phục hồi của mạng và lỗi hoặc lỗ hổng trong một máy khách sẽ không có tác động nghiêm trọng đến toàn bộ mạng.
Sự đa dạng của khách hàng có thể được đo lường bằng tỷ lệ phần trăm cổ phần mà mỗi khách hàng nắm giữ và tổng số khách hàng hiện có. Tại thời điểm viết bài viết này,Có 1979 trình xác nhận trên mạng Solana.Hai ứng dụng khách được các trình xác thực này sử dụng trên mạng chính được cung cấp bởi Solana Labs và Jito Labs. Khi Solana ra mắt vào tháng 3 năm 2020, nó đã sử dụng ứng dụng khách xác thực do Solana Labs phát triển. Vào tháng 8 năm 2022, Jito Labs đã phát hành ứng dụng khách xác thực thứ hai. Máy khách này là một nhánh của mã Solana Labs được Jito duy trì và triển khai. Máy khách tối ưu hóa việc trích xuất giá trị có thể trích xuất tối đa (MEV) trong các khối. Máy khách của Jito tạo nhóm bộ nhớ giả vì Solana truyền phát các khối mà không có nhóm bộ nhớ. Điều đáng chú ý là mempool là một hàng đợi các giao dịch chưa được xác nhận và đang chờ xử lý. Mempool giả cho phép người xác thực tìm kiếm các giao dịch này, kết hợp chúng lại với nhau một cách tối ưu và gửi chúng đến công cụ khối của Jito.
Tính đến tháng 10 năm 2023, khách hàng của Solana Labs nắm giữ 68,55% số cổ phần đang hoạt động, trong khi Jito nắm giữ 31,45%. Số lượng người xác thực sử dụng ứng dụng khách Jito đã tăng 16% so với báo cáo sức khỏe trước đây của Solana Foundation. Sự tăng trưởng trong việc sử dụng khách hàng Jito cho thấy xu hướng ngày càng đa dạng hóa khách hàng.
Mặc dù tin tức về sự tăng trưởng này rất đáng khích lệ nhưng nó vẫn chưa hoàn hảo. Cần nhấn mạnh rằng khách hàng của Jito là một nhánh của khách hàng Solana Labs. Điều này có nghĩa là Jito chia sẻ nhiều thành phần với cơ sở mã trình xác thực ban đầu và có thể dễ gặp phải các lỗi hoặc lỗ hổng bảo mật ảnh hưởng đến máy khách Solana Labs. Trong một tương lai lý tưởng, Solana nên có ít nhất bốn khách hàng xác thực độc lập. Các nhóm khác nhau sẽ xây dựng những ứng dụng khách này bằng các ngôn ngữ lập trình khác nhau. Không một lần triển khai nào sẽ vượt quá 33% cổ phần vì mỗi khách hàng sẽ nắm giữ khoảng 25%. Thiết lập lý tưởng này sẽ loại bỏ các điểm lỗi duy nhất trong toàn bộ trình xác thực.
Việc phát triển ứng dụng khách xác thực độc lập thứ hai là rất quan trọng để đạt được tương lai này và Jump cam kết biến điều đó thành hiện thực.
Tại sao Jump xây dựng một ứng dụng khách xác thực mới?
Mạng chính của Solana đã ngừng hoạt động bốn lần trước đây, mỗi lần đều yêu cầu hàng trăm người xác nhận sửa chữa thủ công. Việc ngừng hoạt động làm nổi bật mối lo ngại về độ tin cậy của mạng Solana.Jump tin rằng bản thân giao thức này đáng tin cậy và cho rằng thời gian ngừng hoạt động là do các vấn đề với mô-đun phần mềm ảnh hưởng đến sự đồng thuận.Do đó, Jump đang phát triển một ứng dụng khách xác thực mới để giải quyết những vấn đề này. Mục tiêu chung của khách hàng này là cải thiện tính ổn định và hiệu quả của mạng Solana.
Phát triển một ứng dụng khách xác nhận độc lập là một nhiệm vụ khó khăn. Tuy nhiên, đây không phải là lần đầu tiên Jump xây dựng một mạng lưới toàn cầu đáng tin cậy. Trước đây, giao dịch chứng khoán (tức là mua bán cổ phiếu) được thực hiện thủ công bởi các chuyên gia thị trường. Với sự xuất hiện của các sàn giao dịch điện tử, giao dịch chứng khoán đã trở nên cởi mở hơn. Sự cởi mở này làm tăng sự cạnh tranh, tự động hóa và giảm thời gian và chi phí cho các nhà đầu tư giao dịch. Một cuộc cạnh tranh công nghệ bắt đầu giữa các chuyên gia thị trường.
Thương nhân buôn bán để kiếm sống. Trải nghiệm giao dịch tốt hơn đòi hỏi phải tập trung nhiều hơn vào các giải pháp phần mềm, phần cứng và mạng.Các hệ thống này phải có trí thông minh máy cao, độ trễ thời gian thực thấp, thông lượng cao, khả năng thích ứng cao, khả năng mở rộng cao, độ tin cậy cao và trách nhiệm giải trình cao.
Các giải pháp một kích thước phù hợp cho tất cả (tức là phần mềm mà các công ty có thể mua hoàn toàn) không phải là lợi thế cạnh tranh. Gửi đúng lệnh đến sàn giao dịch ở vị trí thứ hai là một cách tốn kém để mất tiền. Sự cạnh tranh khốc liệt trong không gian giao dịch tần số cao đã dẫn đến một chu kỳ phát triển không ngừng nghỉ nhằm xây dựng cơ sở hạ tầng giao dịch toàn cầu tốt nhất.
Kịch bản này nghe có vẻ quen thuộc. Các yêu cầu để có một hệ thống giao dịch thành công cũng tương tự như các yêu cầu đối với một blockchain thành công. Blockchain cần phải là một mạng có hiệu suất vượt trội, khả năng chịu lỗi cao và độ trễ thấp. Blockchain chậm là một công nghệ thất bại, không thể đáp ứng nhu cầu của các ứng dụng doanh nghiệp hiện đại và chỉ cản trở sự đổi mới, khả năng mở rộng và tính hữu ích trong thế giới thực. Với hơn hai thập kỷ kinh nghiệm phát triển mạng lưới toàn cầu và hệ thống hiệu suất cao, Jump là nhóm hoàn hảo để tạo ra các khách hàng xác thực độc lập. Giám đốc khoa học của Jump Trading Kevin Bowers giám sát quá trình xây dựng từ đầu đến cuối.
Tại sao tốc độ ánh sáng quá chậm?
Kevin Bowers giải thích thêm về vấn đề ánh sáng quá chậm. Tốc độ ánh sáng là một hằng số hữu hạn cung cấp giới hạn tự nhiên cho số lượng phép tính mà một bóng bán dẫn có thể xử lý. Hiện tại, các bit được mô hình hóa bằng các electron di chuyển qua bóng bán dẫn. Định lý dung lượng của Shannon, là lượng dữ liệu không có lỗi tối đa có thể được gửi trên một kênh, giới hạn số lượng bit có thể được truyền qua một bóng bán dẫn. Do những hạn chế trong vật lý cơ bản và lý thuyết thông tin, tốc độ tính toán bị giới hạn bởi tốc độ các electron di chuyển trong vật chất và lượng dữ liệu có thể được gửi đi. Những hạn chế này trở nên rõ ràng khi đẩy siêu máy tính đến giới hạn của chúng. Kết quả là, có sự không khớp đáng kể giữa khả năng xử lý dữ liệu của máy tính và khả năng truyền dữ liệu của nó.
Lấy CPU Intel Core i 9 13900 K làm ví dụ. Nó có 24 x 86 lõi với tốc độ xung nhịp cơ bản là 2,2 GHz và tốc độ xung nhịp turbo tối đa là 5,8 GHz. Trường hợp xấu nhất là ánh sáng cần phải truyền đi tổng quãng đường khoảng 52,0 mm trong CPU. Khoảng cách Manhattan (tức là khoảng cách giữa hai điểm được đo dọc theo trục vuông góc) đối với CPU là khoảng 73,6 mm. Ở tần số xung nhịp turbo tối đa của CPU là 5,8 GHz, ánh sáng có thể truyền đi khoảng 51,7 mm trong không khí. Điều này có nghĩa là trong một chu kỳ xung nhịp, tín hiệu có thể hoàn thành một vòng quay giữa hầu hết hai điểm bất kỳ trên CPU.
Tuy nhiên, thực tế còn tồi tệ hơn nhiều. Các phép đo này sử dụng tốc độ ánh sáng truyền qua không khí, trong khi tín hiệu thực sự được truyền qua silicon dioxide (SiO2). Ở chu kỳ xung nhịp 5,8 GHz, ánh sáng có thể truyền đi khoảng 26,2 mm trong silicon dioxide. Trong silicon (Si), ánh sáng chỉ có thể truyền đi khoảng 15,0 mm ở chu kỳ xung nhịp 5,8 GHz, hơn một nửa chiều dài của CPU một chút.
Nhóm Firedancer tin rằng những tiến bộ trong công nghệ điện toán trong những năm gần đây chủ yếu tập trung vào việc đưa nhiều lõi vào CPU hơn là làm cho chúng nhanh hơn. Khi mọi người cần hiệu suất cao hơn, họ được khuyến khích mua thêm phần cứng. Điều này hiện đang hoạt động trong các tình huống mà thông lượng là nút cổ chai. Nút thắt thực sự là tốc độ ánh sáng. Hạn chế tự nhiên này dẫn đến sự tê liệt trong việc ra quyết định. Giống như bất kỳ hình thức tối ưu hóa nào, có nhiều thành phần trong hệ thống không mang lại lợi ích ngay lập tức vì chúng không được tối ưu hóa tốt. Các bộ phận không được tối ưu hóa sẽ xấu đi theo thời gian vì chúng có ít tài nguyên máy tính hơn. Vậy phải làm gì bây giờ?
Trong điện toán hiệu năng cao, mọi thứ cuối cùng đều phải được tối ưu hóa. Kết quả là một hệ thống sản xuất hướng tới giao dịch định lượng và nghiên cứu định lượng, hoạt động ở giới hạn của lý thuyết vật lý và thông tin trên quy mô toàn cầu. Điều này bao gồm các thuật toán không khóa tạo ra công nghệ chuyển mạch mạng tùy chỉnh để đáp ứng các hạn chế vật lý này. Jump vừa là một công ty thương mại vừa là một công ty công nghệ. Giữa khoa học viễn tưởng và thực tế, có những điểm tương đồng đáng kinh ngạc giữa các vấn đề mà Jump hiện đang phải đối mặt và Solana, công ty đang phát triển Firedancer.
Firedancer là gì?
Firedancer là một ứng dụng xác thực độc lập mới được nhóm Firedancer phát triển bằng ngôn ngữ C. Firedancer được thiết kế chú trọng đến độ tin cậy, sử dụng kiến trúc mô-đun, mức độ phụ thuộc tối thiểu và quy trình thử nghiệm rộng rãi. Nó đề xuất viết lại ba thành phần chức năng của ứng dụng khách Solana Labs (mạng, thời gian chạy và sự đồng thuận). Mỗi cấp độ được tối ưu hóa để có hiệu suất tối đa, do đó khả năng chạy của máy khách chỉ bị giới hạn bởi phần cứng của trình xác thực chứ không phải do các hạn chế về hiệu suất do sự kém hiệu quả của phần mềm hiện đang gặp phải. Với Firedancer, Solana sẽ có thể mở rộng quy mô dựa trên băng thông và phần cứng.
Mục tiêu của Firedancer là:
Lập tài liệu và chuẩn hóa giao thức Solana (cuối cùng, mọi người sẽ có thể tạo trình xác thực Solana bằng cách xem tài liệu thay vì mã trình xác thực Rust);
Tăng tính đa dạng của khách hàng xác thực;
Cải thiện hiệu suất hệ sinh thái.
Firedancer hoạt động như thế nào
Kiến trúc mô-đun
Firedancer khác biệt với các máy khách xác thực Solana hiện tại thông qua kiến trúc mô-đun độc đáo. Không giống như ứng dụng khách xác thực Rust của Solana Labs, chạy dưới dạng một quy trình duy nhất, Firedancer bao gồm nhiều quy trình Linux C độc lập được gọi là gạch. Một ô là một quá trình và một số bộ nhớ. Kiến trúc gạch này là nền tảng của triết lý vận hành và cách tiếp cận của Firedancer nhằm cải thiện độ bền và hiệu quả.
Một tiến trình là một thể hiện của một chương trình đang chạy. Nó là thành phần cơ bản của hệ điều hành hiện đại và thể hiện việc thực thi một bộ hướng dẫn. Mỗi tiến trình có không gian bộ nhớ và tài nguyên riêng, đồng thời hệ điều hành phân bổ và quản lý các tài nguyên này một cách độc lập mà không bị ảnh hưởng bởi các tiến trình khác. Các quy trình giống như những công nhân độc lập trong một nhà máy lớn, sử dụng các công cụ và không gian làm việc của riêng họ để xử lý các nhiệm vụ cụ thể.
Trong Firedancer, mỗi ô là một quy trình độc lập với một vai trò cụ thể. Ví dụ: ngăn xếp QUIC chịu trách nhiệm xử lý lưu lượng QUIC đến và chuyển tiếp các giao dịch được đóng gói tới ngăn xếp xác minh. Ngăn xếp xác minh chịu trách nhiệm xác minh chữ ký và các ngăn xếp khác có nhiệm vụ tương tự. Các ô này chạy độc lập, đồng thời và cùng nhau tạo thành chức năng của toàn bộ hệ thống. Các quy trình Linux độc lập có thể hình thành các miền lỗi nhỏ, độc lập. Điều này có nghĩa là sự cố xảy ra với một ô sẽ chỉ có tác động tối thiểu đến toàn bộ hệ thống hoặc phạm vi tác động nhỏ mà không gây nguy hiểm ngay lập tức cho toàn bộ trình xác thực.
Ưu điểm chính của kiến trúc Firedancer là khả năng thay thế và nâng cấp từng ô trong vài giây mà không có thời gian ngừng hoạt động. Điều này trái ngược với yêu cầu máy khách xác thực Rust của Solana Labs cần phải tắt hoàn toàn trước khi nâng cấp. Sự khác biệt này xuất phát từ việc Rust thiếu tính ổn định ABI (Giao diện nhị phân ứng dụng), điều này ngăn cản việc nâng cấp nhanh chóng trong môi trường Rust thuần túy. Với cách tiếp cận quy trình C, bạn có thể dựa vào độ ổn định nhị phân trong mô hình thời gian chạy C để giảm đáng kể thời gian ngừng hoạt động liên quan đến nâng cấp. Điều này là do các ô riêng lẻ quản lý trạng thái trình xác thực trong các không gian làm việc khác nhau. Các đối tượng bộ nhớ dùng chung này vẫn tồn tại miễn là trình xác thực được bật và chạy. Trong quá trình khởi động lại hoặc nâng cấp, mỗi ô có thể tiếp tục liền mạch từ nơi nó đã dừng lại.
Nhìn chung, Firedancer được xây dựng trên kiến trúc dựa trên ô xếp, nhận biết NUMA. Trong kiến trúc này, mỗi ô sử dụng một lõi CPU. Nó có tính năng nhắn tin hiệu suất cao giữa các ô, tối ưu hóa vị trí bộ nhớ, bố cục tài nguyên và độ trễ thành phần.
xử lý mạng
Quá trình xử lý mạng của Firedancer được thiết kế để đáp ứng nhu cầu cao của mạng Solana khi nó nâng cấp lên tốc độ gigabit mỗi giây. Quá trình này được chia thành các hoạt động trong và ngoài nước.
Hoạt động trong nước chủ yếu liên quan đến việc nhận giao dịch từ người dùng. Hiệu suất của Firedancer rất quan trọng vì nếu trình xác thực chậm xử lý các gói, các thông báo đồng thuận có thể bị mất. Các nút Solana hiện hoạt động ở tốc độ khoảng 0,2 Gbps, trong khi các nút Jump đã ghi nhận mức băng thông tối đa đạt mức tối đa khoảng 40 Gbps. Sự tăng vọt băng thông này nêu bật nhu cầu về một giải pháp xử lý đầu vào mạnh mẽ và có thể mở rộng.
Các hoạt động gửi đi bao gồm đóng gói khối, tạo khối và gửi phân đoạn. Các bước này rất quan trọng đối với hoạt động an toàn và hiệu quả của mạng Solana. Hiệu suất của các tác vụ này không chỉ ảnh hưởng đến thông lượng mà còn ảnh hưởng đến độ tin cậy chung của mạng.
Firedancer nhằm mục đích giải quyết các vấn đề trước đây của Solana bằng giao diện điểm-điểm để xử lý các giao dịch. Một thiếu sót đáng kể của giao diện điểm-điểm Solana trước đây là thiếu khả năng kiểm soát tắc nghẽn khi xử lý các giao dịch gửi đến. Thiếu sót này dẫn đến ngừng hoạt động vào ngày 14 tháng 9 năm 2021 (17 giờ) và ngày 30 tháng 4 năm 2022 (7 giờ).
Để đáp lại, Solana đã thực hiện một số nâng cấp mạng để xử lý đúng cách lượng giao dịch cao. Firedancer làm theo, áp dụng QUIC làm kế hoạch kiểm soát giao thông của mình.QUIC là giao thức mạng truyền tải đa kênh, nền tảng của HTTP/3.Nó đóng vai trò quan trọng trong việc bảo vệ chống lại các cuộc tấn công DDoS và quản lý lưu lượng mạng. Tuy nhiên, điều quan trọng cần lưu ý là trong một số trường hợp, chi phí lớn hơn lợi ích. QUIC được sử dụng cùng với phần cứng trung tâm dữ liệu chuyên dụng để giảm thiểu các cuộc tấn công DDoS, loại bỏ động cơ cho các cuộc tấn công tràn ngập giao dịch.
Đặc tả 151 trang của QUIC gây ra sự phức tạp đáng kể trong quá trình phát triển. Không thể tìm thấy thư viện C hiện có đáp ứng nhu cầu cấp phép, hiệu suất và độ tin cậy của họ, nhóm Firedancer đã xây dựng cách triển khai của riêng họ. Triển khai QUIC của Firedancer, có biệt danh là fd_quic, giới thiệu các cấu trúc dữ liệu và thuật toán được tối ưu hóa để đảm bảo phân bổ bộ nhớ tối thiểu và ngăn ngừa cạn kiệt bộ nhớ.
Ngăn xếp mạng tùy chỉnh của Firedancer là trung tâm của sức mạnh xử lý của nó. Ngăn xếp được thiết kế từ đầu để tận dụng Tỷ lệ bên nhận (RSS). RSS là một hình thức cân bằng tải mạng được tăng tốc phần cứng nhằm phân phối lưu lượng mạng đến các lõi CPU khác nhau để tăng tính song song trong xử lý mạng. Mỗi lõi CPU xử lý một phần lưu lượng đến với ít chi phí bổ sung. Cách tiếp cận này vượt trội hơn so với cân bằng tải dựa trên phần mềm truyền thống bằng cách loại bỏ các bộ lập lịch, khóa và hoạt động nguyên tử phức tạp.
Firedancer giới thiệu một khung nhắn tin mới để soạn các ứng dụng ô hiệu suất cao. Các ngăn xếp này có thể vượt qua các hạn chế của kết nối mạng hạt nhân dựa trên ổ cắm bằng cách tận dụng AF_XDP, một họ địa chỉ được tối ưu hóa để xử lý gói hiệu suất cao. Sử dụng AF_XDP để cho phép Firedancer đọc dữ liệu trực tiếp từ bộ đệm giao diện mạng.
Hệ thống ô này triển khai nhiều khái niệm điện toán hiệu suất cao khác nhau trong ngăn xếp Firedancer, bao gồm:
Nhận biết NUMA - NUMA (Truy cập bộ nhớ không đồng nhất) là một thiết kế bộ nhớ máy tính trong đó bộ xử lý truy cập bộ nhớ của chính nó nhanh hơn truy cập bộ nhớ được liên kết với các bộ xử lý khác. Đối với Firedancer, việc nhận biết NUMA có nghĩa là máy khách có thể xử lý bộ nhớ hiệu quả trong cấu hình nhiều bộ xử lý. Điều này rất quan trọng để xử lý khối lượng giao dịch cao vì nó tối ưu hóa việc sử dụng các tài nguyên phần cứng có sẵn.
Vị trí bộ đệm - Vị trí bộ đệm đề cập đến việc sử dụng dữ liệu đã được lưu trữ trong bộ đệm gần bộ xử lý. Đây thường là một biến thể của vị trí tạm thời (tức là dữ liệu được truy cập gần đây nhất). Trong Firedancer, việc tập trung vào vị trí bộ đệm có nghĩa là nó được thiết kế để xử lý dữ liệu mạng đồng thời giảm thiểu độ trễ và tối đa hóa tốc độ.
Đồng thời không khóa - Đồng thời không khóa đề cập đến việc thiết kế các thuật toán không yêu cầu cơ chế khóa (chẳng hạn như mutex) để quản lý các hoạt động đồng thời. Đối với Firedancer, tính năng đồng thời không khóa cho phép nhiều hoạt động mạng thực hiện song song mà không bị chậm trễ do khóa. Tính năng đồng thời không khóa giúp nâng cao khả năng xử lý đồng thời số lượng lớn giao dịch của Firedancer.
Kích thước trang lớn - Sử dụng kích thước trang lớn trong quản lý bộ nhớ giúp xử lý các tập dữ liệu, giảm việc tra cứu bảng trang và khả năng phân mảnh bộ nhớ. Đối với Firedancer, điều này có nghĩa là hiệu quả xử lý bộ nhớ được cải thiện. Điều này rất có lợi cho việc xử lý lượng lớn dữ liệu mạng.
Xây dựng hệ thống
Hệ thống xây dựng của Firedancer tuân theo một bộ nguyên tắc hướng dẫn để đảm bảo độ tin cậy và tính nhất quán. Nó nhấn mạnh việc giảm thiểu sự phụ thuộc bên ngoài và coi tất cả các công cụ liên quan đến quá trình xây dựng là phần phụ thuộc. Điều này bao gồm việc ghim mọi phần phụ thuộc (bao gồm cả trình biên dịch) vào một phiên bản chính xác. Một khía cạnh quan trọng của hệ thống này là cách ly môi trường trong bước xây dựng. Cách ly môi trường nâng cao tính di động vì quá trình xây dựng không bị ảnh hưởng bởi môi trường hệ thống.
Tại sao Firedancer nhanh hơn
Song song dữ liệu nâng cao
Firedancer tận dụng tính năng song song dữ liệu nâng cao có sẵn bên trong các bộ xử lý hiện đại trong các tác vụ mã hóa như xác minh chữ ký ED 25519. Các CPU hiện đại có các lệnh Nhiều dữ liệu một lệnh (SIMD) để xử lý đồng thời nhiều thành phần dữ liệu, cũng như khả năng tối ưu hóa việc chạy nhiều lệnh trên mỗi chu kỳ CPU. Sẽ hiệu quả hơn về mặt diện tích, thời gian và công suất khi thực hiện song song một lệnh trên một mảng hoặc vectơ gồm các phần tử dữ liệu. Ở đây, những cải tiến trong xử lý dữ liệu song song có thể lấn át những cải tiến về thông lượng so với những cải tiến về tốc độ xử lý thuần túy.
Một lĩnh vực mà Firedancer sử dụng song song dữ liệu là tối ưu hóa xác minh chữ ký tính toán. Cách tiếp cận này cho phép xử lý đồng thời các phần tử dữ liệu trong một mảng hoặc vectơ để tối đa hóa thông lượng và giảm thiểu độ trễ. Cốt lõi của việc triển khai ED 25519 là vận hành trường Galois. Dạng số học này rất phù hợp với các thuật toán mã hóa và tính toán nhị phân. Trong trường Galois, các phép toán như cộng, trừ, nhân và chia được xác định dựa trên bản chất nhị phân của hệ thống máy tính. Đây là ví dụ về trường Galois được xác định bởi 2^3:
Vấn đề duy nhất là ED 25519 sử dụng trường Galois được xác định bởi 2^(255-19). Bạn có thể coi các phần tử miền là các số từ 0 đến 2^(255-19). Các hoạt động cơ bản như sau:
Phép cộng, trừ và nhân gần như là phép toán uint 256 _t (tức là các phép tính sử dụng số nguyên không dấu trong đó tối đa là 2^(256-1)). Phép tính chia rất khó khăn. CPU và GPU thông thường không hỗ trợ phép toán uint 256 _t chứ đừng nói đến gần như uint 256 _t math, chưa kể đến phép chia cực kỳ khó khăn. Việc thực hiện phép toán này và làm cho nó hoạt động hiệu quả là một vấn đề then chốt, tùy thuộc vào mức độ chúng ta có thể mô phỏng phép toán này.
Việc triển khai Firedancer phá vỡ các phép tính số học bằng cách xử lý các con số một cách linh hoạt hơn. Nếu chúng ta áp dụng các nguyên tắc chia và nhân dài thông thường, mang số từ cột này sang cột tiếp theo, chúng ta có thể xử lý các cột song song. Cách nhanh nhất để mô phỏng phép toán này là biểu diễn uint 256 _t dưới dạng sáu số 43 bit, với mang 9 bit. Điều này cho phép các hoạt động 64 bit hiện có được thực hiện trên CPU trong khi vẫn cung cấp đủ chỗ cho bit mang. Sự sắp xếp số lượng này làm giảm nhu cầu truyền tải thường xuyên và cho phép Firedancer xử lý số lượng lớn hiệu quả hơn.
Việc triển khai này khai thác tính song song của dữ liệu bằng cách sắp xếp lại các phép tính số học thành các tổng cột song song. Việc xử lý các cột song song có thể tăng tốc độ tính toán tổng thể vì nó biến các tác vụ có thể gây tắc nghẽn tuần tự thành các tác vụ có thể song song hóa. Firedancer cũng sử dụng các tập lệnh được vector hóa như AVX 512 và phần mở rộng IFMA của nó (AVX 512-IFMA). Các tập lệnh này cho phép xử lý số học trường Galois được mô tả ở trên, giúp tăng tốc độ và hiệu quả.
Firedancer thực hiện tăng tốc AVX 512 rất nhanh. Trên một lõi máy chủ Icelake 2,3 GHz, hiệu suất xung nhịp trên mỗi lõi cao hơn gấp đôi so với bản demo Breakpoint năm 2022 của nó. Việc triển khai có tính năng sử dụng kênh vectơ 100% và song song dữ liệu lớn. Đây là một minh chứng tuyệt vời khác của nhóm Firedancer rằng nhờ độ trễ tốc độ ánh sáng, việc thực hiện các tác vụ song song độc lập cùng lúc sẽ dễ dàng hơn nhiều so với làm từng việc một, ngay cả với phần cứng tùy chỉnh.
Cho phép truyền thông mạng tốc độ cao với FPGA
CPU có thể xử lý khoảng 30.000 xác minh chữ ký mỗi giây trên mỗi lõi. Mặc dù chúng là một lựa chọn tiết kiệm năng lượng nhưng chúng có những nhược điểm khi vận hành ở quy mô lớn. Hạn chế này bắt nguồn từ cách tiếp cận xử lý tuần tự của họ. GPU tăng sức mạnh xử lý này lên khoảng 1 triệu lần xác thực mỗi giây cho mỗi lõi. Tuy nhiên, chúng tiêu thụ khoảng 300 W mỗi đơn vị và có độ trễ cố hữu do xử lý hàng loạt.
FPGA trở thành sự lựa chọn tốt hơn. Chúng phù hợp với thông lượng của GPU nhưng tiêu thụ ít điện năng hơn đáng kể, khoảng 50 W mỗi FPGA. Độ trễ cũng thấp hơn độ trễ mười mili giây của GPU. FPGA cung cấp giải pháp xử lý thời gian thực nhạy hơn với độ trễ khoảng 200 micro giây. Không giống như xử lý hàng loạt của GPU, FPGA trong Firedancer xử lý từng giao dịch riêng lẻ theo kiểu truyền phát. Kết quả của việc Firedancer sử dụng FPGA là 8 FPGA có thể xử lý 8 triệu chữ ký mỗi giây trong khi tiêu thụ ít hơn 400 W điện năng.
Nhóm đã trình diễn quy trình xác minh chữ ký ED 25519 của Firedancer tại Breakpoint 2022. Quá trình này bao gồm nhiều giai đoạn, bao gồm tính toán SHA-512 trong quy trình RTL thuần túy cũng như các bước kiểm tra và tính toán khác nhau trong quy trình xử lý ECC-CPU tùy chỉnh. Về cơ bản, nhóm Firedancer đã viết một trình biên dịch và trình biên dịch mã cho bộ xử lý tùy chỉnh của họ, lấy mã Python từ RFC (Yêu cầu nhận xét), sử dụng các đối tượng được nạp chồng toán tử để tạo mã máy, sau đó đặt mã máy vào ECC -Trên đầu CPU.
Đáng chú ý, Firedancer áp dụng kiểu hệ số hình thức của bộ tăng tốc AWS để đạt được sự cân bằng giữa độ mạnh mẽ và khả năng kết nối mạng. Tùy chọn này giải quyết các thách thức liên quan đến kết nối mạng trực tiếp, một tính năng thường bị hạn chế ở các nhà cung cấp đám mây. Với lựa chọn này, Firedancer đảm bảo rằng các khả năng nâng cao của nó có thể được tích hợp liền mạch trong những hạn chế của cơ sở hạ tầng đám mây.
Chúng ta phải nhận ra rằng các hoạt động khác nhau đòi hỏi không gian vật lý thực tế, không chỉ không gian dữ liệu khái niệm. Firedancer hoạt động bằng cách sắp xếp vị trí của các thành phần vật lý một cách chiến lược để làm cho chúng nhỏ gọn và có thể tái sử dụng. Cấu hình này cho phép Firedancer tối đa hóa hiệu quả của FPGA, đạt được 8 triệu giao dịch mỗi giây bằng cách sử dụng FPGA 7 năm tuổi trên một chiếc máy 8 năm tuổi.
Một thách thức cơ bản trong truyền thông mạng là phát sóng các giao dịch mới trên toàn cầu
Bản chất điểm-điểm của Internet, các vấn đề về băng thông và độ trễ hạn chế đã hạn chế tính khả thi của các phương pháp truyền thống như phát sóng trực tiếp bằng mạng. Việc phân phối dữ liệu theo cấu trúc vòng hoặc cây giải quyết được một phần những vấn đề này nhưng các gói có thể bị mất trong quá trình truyền.
Mã hóa Reed-Solomon là giải pháp ưu tiên cho những vấn đề này. Nó giới thiệu tính năng dự phòng truyền dữ liệu (tức là thông tin chẵn lẻ) để khôi phục các gói bị mất. Khái niệm cơ bản là hai điểm có thể xác định một đường thẳng và bất kỳ hai điểm nào trên đường thẳng này có thể tái tạo lại các điểm dữ liệu ban đầu. Bằng cách xây dựng đa thức dựa trên các điểm dữ liệu và phân phối các điểm khác nhau của chức năng này trên các gói riêng biệt, dữ liệu gốc có thể được xây dựng lại miễn là người nhận nhận được ít nhất hai gói.
Chúng ta xây dựng các đa thức vì việc sử dụng công thức truyền thống cho các điểm trên đường thẳng (y = mx + b) sẽ chậm về mặt tính toán. Firedancer sử dụng đa thức Lagrange (một phương pháp chuyên biệt để xây dựng đa thức) để tăng tốc độ. Nó đơn giản hóa việc tạo các đa thức cần thiết cho mã hóa Reed-Solomon. Nó cũng biến đổi quá trình thành phép nhân vectơ-ma trận hiệu quả hơn cho các đa thức bậc cao hơn. Ma trận này có cấu trúc cao, với các mẫu lặp lại theo cách đệ quy sao cho hàng đầu tiên của mẫu xác định hoàn toàn nó. Cấu trúc này có nghĩa là có một cách nhanh hơn để thực hiện các phép tính nhân. Firedancer sử dụng phương pháp O(n log n), được mô tả trong một bài viết năm 2016 về cách sử dụng ma trận này để nhân, đây là phương pháp lý thuyết nhanh nhất về mã hóa Reed-Solomon hiện được biết đến. Kết quả là một cách hiệu quả cao để tính toán thông tin chẵn lẻ so với các phương pháp truyền thống:
Tốc độ mã hóa RS trên 120 Gbps trên mỗi lõi;
Tốc độ giải mã RS lên tới 50 Gbps trên mỗi lõi;
Các số liệu này so sánh với mã hóa RS ~ 8 Gbps/lõi hiện tại (rust-rse).
Sử dụng phương pháp mã hóa Reed-Solomon được tối ưu hóa này, Firedancer có thể tính toán thông tin chẵn lẻ nhanh hơn 14 lần so với các phương pháp truyền thống. Điều này làm cho quá trình mã hóa và giải mã dữ liệu nhanh chóng và đáng tin cậy, điều này rất quan trọng để duy trì thông lượng cao và độ trễ thấp trên toàn thế giới.
Làm thế nào để Firedancer được an toàn?
Cơ hội
Tất cả các trình xác thực hiện đang sử dụng phần mềm dựa trên ứng dụng khách xác thực ban đầu. Nếu Firedancer khác với các khách hàng của Solana Labs, thì Firedancer có thể cải thiện sự đa dạng về khách hàng và chuỗi cung ứng của Solana. Điều này bao gồm việc sử dụng các phần phụ thuộc tương tự và sử dụng Rust để phát triển ứng dụng khách của họ.
Máy khách xác thực Solana Labs và Jito chạy như một quy trình riêng biệt. Việc thêm bảo mật vào một ứng dụng nguyên khối rất khó khăn khi nó đang chạy trong sản xuất. Trình xác thực đang chạy các ứng dụng khách này sẽ phải ngừng hoạt động để nâng cấp bảo mật ngay lập tức lên Rust thuần túy. Nhóm Firedancer đã có thể phát triển ứng dụng khách mới của họ với kiến trúc bảo mật được tích hợp sẵn ngay từ đầu.
Firedancer cũng có lợi thế là học hỏi kinh nghiệm trong quá khứ. Solana Labs đã phát triển ứng dụng khách xác thực trong môi trường khởi nghiệp. Môi trường có nhịp độ nhanh này có nghĩa là Phòng thí nghiệm cần phải di chuyển nhanh chóng để nhanh chóng tiếp cận thị trường. Điều này khiến triển vọng phát triển trong tương lai của họ trở nên đáng lo ngại. Nhóm Firedancer có thể xem xét những gì Labs đã làm và những gì các nhóm trên các chuỗi khác đã làm, đồng thời hỏi xem họ sẽ làm gì khác nếu có thể phát triển ứng dụng khách xác thực từ đầu.
thử thách
Mặc dù khác với khách hàng của Solana Labs, Firedancer phải sao chép chặt chẽ hành vi của nó. Việc không thực hiện điều này có thể gây ra lỗi nhất quán và do đó trở thành rủi ro bảo mật. Vấn đề này có thể được giảm thiểu bằng cách khuyến khích một phần cổ phần chạy trên cả hai khách hàng, giữ cho tổng cổ phần của Firedancer ở dưới 33% tổng cổ phần trong thời gian dài hơn. Bất chấp điều đó, nhóm Firedancer cần triển khai bộ tính năng đầy đủ của giao thức, bất kể việc triển khai nó khó khăn hay an toàn đến mức nào. Mọi thứ phải nhất quán với Firedancer. Do đó, các nhóm không thể phát triển mã một cách riêng biệt và phải xem xét mã đó dựa trên khả năng của máy khách Labs. Điều này càng trở nên trầm trọng hơn do thiếu thông số kỹ thuật và tài liệu, điều đó có nghĩa là Firedancer phải đưa các cấu trúc kém hiệu quả vào giao thức.
Nhóm Firedancer cũng phải biết rằng họ đang phát triển ứng dụng khách mới của mình ở C. Ngôn ngữ C không cung cấp sự đảm bảo an toàn cho bộ nhớ nguyên bản như các ngôn ngữ như Rust. Mục tiêu chính của cơ sở mã Firedancer là giảm sự xuất hiện và tác động của các lỗ hổng an toàn bộ nhớ. Mục tiêu này cần được quan tâm đặc biệt vì Firedancer là một dự án có tiến độ nhanh. Firedancer phải tìm cách duy trì tốc độ phát triển mà không gây ra những lỗi như vậy. Hộp cát hệ điều hành là phương pháp cô lập các ô thông tin khỏi hệ điều hành. Ngói chỉ được phép truy cập vào tài nguyên và thực hiện các lệnh gọi hệ thống cần thiết cho công việc của nó. Vì Ngói có mục đích được xác định rõ ràng và nhóm Firedancer chủ yếu phát triển mã phía máy khách nên các quyền của Ngói sẽ bị tước bỏ dựa trên nguyên tắc đặc quyền tối thiểu.
Triển khai thiết kế phòng thủ chuyên sâu
Tất cả các phần mềm đều có lỗ hổng bảo mật ở một số điểm. Bắt đầu từ tiền đề rằng phần mềm sẽ có lỗi, Firedancer chọn cách hạn chế tác động tiềm ẩn của bất kỳ lỗ hổng nào. Cách tiếp cận này được gọi là phòng thủ theo chiều sâu. Phòng thủ theo chiều sâu là chiến lược sử dụng nhiều biện pháp an ninh khác nhau để bảo vệ tài sản. Nếu kẻ tấn công xâm phạm một phần của hệ thống, các biện pháp bổ sung sẽ tồn tại để ngăn chặn mối đe dọa ảnh hưởng đến toàn bộ hệ thống.
Firedancer được thiết kế để giảm thiểu rủi ro giữa các lỗ hổng và giai đoạn khai thác. Ví dụ: lỗ hổng an toàn bộ nhớ rất khó để kẻ tấn công khai thác. Điều này là do việc ngăn chặn kiểu tấn công này là một vấn đề đã được nghiên cứu kỹ lưỡng. Trong C, nghiên cứu chuyên sâu về an toàn bộ nhớ đã dẫn đến một loạt kỹ thuật tăng cường và tính năng biên dịch mà nhóm đã sử dụng trong Firedancer. Ngay cả khi kẻ tấn công có thể vượt qua các phương pháp hay nhất trong ngành thì sẽ khó có thể xâm phạm hệ thống bằng cách khai thác lỗ hổng. Điều này là do tính năng cách ly Ngói và sự hiện diện của hộp cát của hệ điều hành.
Cách ly ô là kết quả của kiến trúc song song của Firedancer. Vì mỗi Ngói chạy trong quy trình Linux riêng nên chúng có một mục đích duy nhất và rõ ràng. Ví dụ: Ô QUIC chịu trách nhiệm xử lý lưu lượng QUIC đến và chuyển tiếp các giao dịch được đóng gói tới ô xác thực. Khi đó, ô xác minh sẽ chịu trách nhiệm xác minh chữ ký. Giao tiếp giữa Ô QUIC và Ô xác minh được thực hiện thông qua giao diện bộ nhớ dùng chung (tức là các quy trình Linux có thể truyền dữ liệu lẫn nhau). Giao diện bộ nhớ dùng chung giữa hai ô đóng vai trò là ranh giới cách ly. Nếu Ô QUIC chứa lỗi cho phép kẻ tấn công thực thi mã tùy ý khi xử lý các gói QUIC độc hại thì lỗi đó sẽ không ảnh hưởng đến các Ô khác. Trong một quy trình duy nhất, điều này sẽ dẫn đến sự thỏa hiệp ngay lập tức. Nếu kẻ tấn công khai thác lỗ hổng này để nhắm mục tiêu vào nhiều trình xác thực, chúng có thể gây hại cho toàn bộ mạng. Kẻ tấn công có thể làm giảm hiệu suất của QUIC Tile, nhưng thiết kế của Firedancer giới hạn điều này ở QUIC Tiles.
Hộp cát hệ điều hành là phương pháp cô lập các ô thông tin khỏi hệ điều hành. Ngói chỉ được phép truy cập vào tài nguyên và thực hiện các lệnh gọi hệ thống cần thiết cho công việc của nó. Vì Ngói có mục đích được xác định rõ ràng và gần như toàn bộ mã của nó được phát triển bởi nhóm Firedancer nên các quyền của Ngói bị tước bỏ ở mức tối thiểu dựa trên nguyên tắc đặc quyền tối thiểu. Ngói được đặt trong không gian tên Linux của riêng nó, cung cấp một cái nhìn hạn chế về hệ thống. Chế độ xem hẹp này ngăn Ngói truy cập vào hầu hết hệ thống tệp, mạng và bất kỳ quy trình nào khác đang chạy trên cùng một hệ thống. Không gian tên cung cấp ranh giới ưu tiên bảo mật. Tuy nhiên, sự cô lập này vẫn có thể bị bỏ qua nếu kẻ tấn công có lỗ hổng kernel nâng cao đặc quyền. Giao diện cuộc gọi hệ thống là vectơ tấn công cuối cùng trong kernel có thể truy cập được từ Tile. Để ngăn chặn điều này, Firedancer sử dụng seccomp-BPF để lọc các cuộc gọi hệ thống trước khi chúng được kernel xử lý. Khách hàng có thể giới hạn Thẻ thông tin ở một nhóm lệnh gọi hệ thống đã chọn. Trong một số trường hợp, có thể lọc các tham số của cuộc gọi hệ thống. Điều này rất quan trọng vì Firedancer đảm bảo rằng các lệnh gọi hệ thống đọc và ghi chỉ hoạt động trên các bộ mô tả tệp cụ thể.
Áp dụng kế hoạch bảo mật nhúng
Trong quá trình phát triển Firedancer, người ta chú ý đến việc đưa các quy trình an toàn toàn diện vào mọi giai đoạn. Chương trình bảo mật của khách hàng là kết quả của sự hợp tác liên tục giữa nhóm phát triển và bảo mật, thiết lập tiêu chuẩn mới cho công nghệ chuỗi khối an toàn.
Quá trình bắt đầu với cơ sở hạ tầng kiểm tra lông tơ tự phục vụ. Kiểm thử Fuzz là một kỹ thuật tự động phát hiện các sự cố hoặc tình trạng lỗi cho thấy lỗ hổng. Kiểm tra fuzz được thực hiện bằng cách kiểm tra căng thẳng mọi thành phần chấp nhận đầu vào không đáng tin cậy của người dùng, bao gồm giao diện P2P (trình phân tích cú pháp) và máy ảo SBPF. OSS-Fuzz duy trì vùng phủ sóng mờ liên tục trong quá trình thay đổi mã. Nhóm bảo mật cũng thiết lập một phiên bản ClusterFuzzer chuyên dụng để liên tục thử nghiệm fuzz theo hướng dẫn về phạm vi bảo hiểm. Các nhà phát triển và kỹ sư bảo mật cũng cung cấp các công cụ để kiểm tra fuzz (nghĩa là kiểm tra đơn vị dựa trên các phiên bản đặc biệt của các thành phần quan trọng về bảo mật). Các nhà phát triển cũng có thể đóng góp các bài kiểm tra lông tơ mới, được nhận và kiểm tra tự động. Mục tiêu là kiểm tra toàn bộ các phần trước khi chuyển sang giai đoạn tiếp theo.
Đánh giá mã nội bộ giúp phát hiện các lỗ hổng mà các công cụ có thể bỏ sót. Ở giai đoạn này, trọng tâm là các thành phần có rủi ro cao, tác động lớn. Giai đoạn này là cơ chế phản hồi cung cấp phản hồi cho các phần khác của chương trình bảo mật. Nhóm áp dụng tất cả các bài học rút ra từ các bài đánh giá này để cải thiện phạm vi kiểm tra fuzz, giới thiệu các biện pháp kiểm tra phân tích tĩnh mới cho các lớp lỗ hổng cụ thể và thậm chí triển khai tái cấu trúc mã quy mô lớn để loại trừ các vectơ tấn công phức tạp. Các đánh giá bảo mật bên ngoài sẽ được bổ sung bởi các chuyên gia đầu ngành và chương trình thưởng lỗi đang hoạt động, cả trước và sau khi ra mắt.
Firedancer cũng đã trải qua quá trình thử nghiệm căng thẳng trên nhiều mạng thử nghiệm khác nhau. Các mạng thử nghiệm này sẽ phải đối mặt với nhiều cuộc tấn công và lỗi khác nhau như sao chép nút, lỗi liên kết mạng, tràn gói và vi phạm đồng thuận. Tải mà các mạng này chịu đựng vượt xa mọi thứ thực tế trên mạng chính.
Vì vậy, điều này đặt ra câu hỏi: Tình trạng hiện tại của Firedancer như thế nào?
Tình trạng hiện tại của Firedancer là gì và Frankendancer là gì?
Nhóm Firedancer đang dần phát triển Firedancer để mô-đun hóa ứng dụng khách xác thực. Điều này phù hợp với mục tiêu của họ về tài liệu và tiêu chuẩn hóa. Cách tiếp cận này đảm bảo rằng Firedancer luôn cập nhật những phát triển mới nhất ở Solana. Điều này dẫn đến việc tạo ra Frankendancer. Frankendancer là một mô hình máy khách kết hợp trong đó nhóm Firedancer tích hợp các thành phần đã phát triển của mình vào cơ sở hạ tầng máy khách xác thực hiện có. Quá trình phát triển này cho phép cải tiến dần dần và thử nghiệm các tính năng mới.
Frankendancer giống như việc đặt một chiếc xe thể thao giữa dòng xe cộ. Hiệu suất sẽ tiếp tục được cải thiện khi có nhiều thành phần hơn được phát triển và các điểm nghẽn được loại bỏ. Quá trình phát triển mô-đun này tạo điều kiện cho môi trường xác thực linh hoạt và có thể tùy chỉnh. Tại đây, các nhà phát triển có thể sửa đổi hoặc thay thế các thành phần cụ thể trong ứng dụng xác thực theo nhu cầu của họ.
Những gì thực sự chạy
Frankendancer triển khai tất cả chức năng kết nối mạng của trình xác thực Solana:
Trong nước: QUIC, TPU, Sigverify, Dedup
Gửi đi: Đóng gói khối, tạo/ký/gửi Shreds (Turbine)
Frankendancer sử dụng mã mạng C hiệu suất cao của Firedancer dựa trên mã đồng thuận và thời gian chạy Rust của Solana Labs.
Thiết kế kiến trúc của Frankendancer tập trung vào việc tối ưu hóa phần cứng cao cấp. Mặc dù hỗ trợ các máy chủ đám mây cấp thấp chạy hệ điều hành Linux tiêu chuẩn, nhóm Firedancer đang tối ưu hóa Frankendancer cho các máy chủ có số lượng lõi cao. Mục tiêu dài hạn là tận dụng các tài nguyên phần cứng hiện có trên đám mây để cải thiện hiệu quả và hiệu suất. Máy khách hỗ trợ nhiều kết nối đồng thời, tăng tốc phần cứng, điều khiển lưu lượng ngẫu nhiên để phân phối tải (đảm bảo phân phối đồng đều lưu lượng mạng) và nhiều ranh giới quy trình để cung cấp bảo mật bổ sung giữa các thành phần.
Hiệu quả kỹ thuật là nền tảng của Frankendancer. Hệ thống tránh phân bổ bộ nhớ và hoạt động nguyên tử trên đường dẫn quan trọng và tất cả phân bổ đều được tối ưu hóa NUMA khi khởi tạo. Thiết kế này đảm bảo hiệu quả và hiệu suất tối đa. Ngoài ra, khả năng kiểm tra các thành phần hệ thống một cách không đồng bộ và từ xa, cũng như quản lý các ô thông tin linh hoạt (khởi động, dừng và khởi động lại không đồng bộ), bổ sung thêm một lớp độ bền và khả năng thích ứng cho hệ thống.
Frankendancer giá vé như thế nào?
Mỗi Ngói của Frankendancer có thể xử lý 1.000.000 giao dịch mỗi giây (TPS) ở phía bên trong của mạng. Vì mỗi Ngói sử dụng một lõi CPU nên hiệu năng sẽ tăng tỷ lệ tuyến tính với số lượng lõi được sử dụng. Frankendancer đạt được kỳ tích này bằng cách chỉ sử dụng bốn lõi và sử dụng đầy đủ các thẻ giao diện mạng (NIC) 25 Gbps trên mỗi lõi.
Khi nói đến hoạt động ra bên ngoài mạng, Frankendancer đã đạt được những cải tiến đáng kể với khả năng tối ưu hóa Turbine của mình. Phần cứng nút tiêu chuẩn hiện tại đạt tốc độ 6 Gbps trên mỗi ô. Điều này bao gồm những cải tiến lớn về tốc độ trong phân mảnh (tức là cách các khối dữ liệu được phân chia và gửi đến mạng xác thực). So với các nút Solana tiêu chuẩn hiện tại, Frankendancer cho thấy tốc độ phân chia khoảng 22% khi không có cây Merkle và gần như gấp đôi khi sử dụng cây Merkle. Đây là một cải tiến lớn so với hiệu suất truyền khối xác thực và tiếp nhận giao dịch hiện tại.
Hiệu suất mạng của Firedancer cho thấy nó đạt đến giới hạn của phần cứng, đạt hiệu suất tối đa so với phần cứng trình xác thực tiêu chuẩn ngày nay. Điều này đánh dấu một cột mốc quan trọng về công nghệ, thể hiện khả năng của khách hàng trong việc xử lý khối lượng công việc cực lớn một cách hiệu quả và hiệu quả.
Frankendancer đã được ra mắt trên testnet
Frankendancer hiện đang đặt cược, bỏ phiếu và sản xuất các khối trên mạng thử nghiệm. Nó tương thích với Solana Labs và Jito và khoảng 2900 trình xác nhận khác. Việc triển khai trong thế giới thực này thể hiện sức mạnh của Firedancer trên phần cứng thông thường. Nó hiện được triển khai trên máy chủ Equinix Metal m 3.large.x 86 với CPU AMD EPYC 7513. Nhiều trình xác nhận khác cũng sử dụng cùng loại máy chủ. Nó cung cấp một giải pháp giá cả phải chăng, với mức giá theo yêu cầu dao động từ 3,10 USD đến 4,65 USD mỗi giờ, thay đổi tùy theo địa điểm.
Quá trình khởi chạy mạng chính của Firedancer mở ra một số khả năng cho phần cứng nút:
Phần cứng xác thực hiện tại cho phép hiệu suất trên mỗi nút cao hơn;
Hiệu quả của Firedancer cho phép người xác thực sử dụng phần cứng có thông số kỹ thuật thấp hơn, giá cả phải chăng hơn trong khi vẫn duy trì mức hiệu suất tương tự;
Firedancer được thiết kế để tận dụng những tiến bộ về phần cứng và băng thông.
Những bước phát triển này, cùng với các sáng kiến khác như Wiredancer (thử nghiệm tăng tốc phần cứng của nhóm Firedancer) và thời gian chạy mô-đun/SVM dựa trên Rust, khiến Firedancer trở thành một giải pháp tiên tiến.
Tiến trình của Firedancer cũng đã làm dấy lên cuộc thảo luận về việc liệu có nên để người xác nhận chạy ứng dụng khách Solana Labs cùng với Firedancer hay không, được gọi là chạy song song. Cách tiếp cận này tối đa hóa hoạt động mạng bằng cách tận dụng điểm mạnh của cả hai máy khách và giảm thiểu tác động tiềm ẩn của một trong hai máy khách trên mạng tổng thể. Ngoài ra, điều này đã dẫn đến suy đoán về việc liệu các dự án như Jito có cân nhắc việc phân nhánh Firedancer hay không. Điều này có thể tối ưu hóa hơn nữa hiệu quả khai thác MEV và xử lý giao dịch. Chỉ có thời gian mới trả lời được.
Tóm lại là
Các nhà phát triển thường nghĩ các hoạt động chiếm không gian dữ liệu hơn là không gian vật lý. Với tốc độ ánh sáng là giới hạn tự nhiên, giả định này dẫn đến hệ thống chậm hơn và không thể tối ưu hóa phần cứng của nó một cách hợp lý. Trong một môi trường có tính đối đầu và cạnh tranh cao, chúng ta không thể đơn giản ném thêm phần cứng vào Solana và mong đợi nó hoạt động tốt hơn. Chúng ta cần tối ưu hóa. Firedancer cách mạng hóa cấu trúc và hoạt động của các máy khách xác nhận. Bằng cách xây dựng một ứng dụng khách xác thực đáng tin cậy, có tính mô-đun cao và hiệu suất cao, nhóm Firedancer đang chuẩn bị cho việc áp dụng rộng rãi Solana.
Cho dù bạn là nhà phát triển cấp dưới hay người dùng Solana thông thường, điều quan trọng là phải hiểu Firedancer và ý nghĩa của nó. Thành tựu công nghệ này làm cho blockchain nhanh nhất, hiệu suất cao nhất trên thị trường thậm chí còn tốt hơn. Solana được thiết kế để trở thành một cỗ máy trạng thái toàn cầu có thông lượng cao, độ trễ thấp. Firedancer là một bước tiến lớn hướng tới việc hoàn thiện những mục tiêu này.
