Solana Turbine: Giải thích về Truyền bá Khối

Truyền bá khối Solana Turbine mô tả cách dữ liệu khối được chia thành các mảnh và phân phối qua các trình xác thực. Các số liệu trong bài viết này là giá trị lịch sử hoặc mục tiêu trừ khi được ghi ngày cụ thể; thời gian slot thực tế, cấu trúc liên kết, mất gói và hành vi triển khai có thể thay đổi.

Giới thiệu: Tại sao truyền bá khối quyết định tốc độ Blockchain

Gửi một khối đầy đủ cho hàng ngàn trình xác thực cùng một lúc sẽ yêu cầu mỗi trình xác thực tải xuống toàn bộ khối từ một nguồn duy nhất, tạo ra một nút thắt cổ chai băng thông trở nên tồi tệ hơn khi mạng lưới mở rộng. Solana (SOL), một blockchain Layer-1 hiệu suất cao (một mạng lưới Sổ lệnh phân tán ghi lại và xác thực các giao dịch mà không cần cơ quan trung ương), giải quyết vấn đề này với Turbine, giao thức truyền bá khối chuyên dụng của nó.

Các tài liệu sớm của Solana trích dẫn thông lượng lý thuyết gần 65.000 TPS và thời gian slot mục tiêu gần 400 mili giây. Đó là các tham chiếu thiết kế thay vì các phép đo trực tiếp được đảm bảo, và một slot không phải lúc nào cũng tạo ra một khối. Turbine là cơ chế truyền bá dữ liệu khối được mô tả trong khung kiến trúc lịch sử của Solana.

Truyền bá khối nằm bên dưới Cơ chế đồng thuận: các trình xác thực (máy chủ nắm giữ một bản sao của sổ cái, xác minh các giao dịch và bỏ phiếu về tính hợp lệ của khối) không thể bỏ phiếu về tính hợp lệ của khối cho đến khi họ nhận được và tái cấu trúc nó từ các mảnh. Sự phụ thuộc đó có nghĩa là tốc độ của Turbine là yếu tố trực tiếp thúc đẩy hiệu suất đồng thuận của Solana. Mọi tương tác Hợp đồng Thông minh trên Solana, từ một giao dịch hoán đổi tài chính phi tập trung (DeFi) đến việc đúc NFT, đều phụ thuộc vào việc khối đó đến được các trình xác thực đủ nhanh để xác nhận trong slot tiếp theo.

Phần tiếp theo bao gồm định nghĩa của Turbine, cơ chế năm bước, các thông số kỹ thuật, đóng góp vào hiệu suất, sự đánh đổi về bảo mật và so sánh trực tiếp với Ethereum và Avalanche.

Trong bài viết này

• Solana Turbine Truyền bá Khối là gì?
• Các thuật ngữ chính: Hướng dẫn tham khảo nhanh về thuật ngữ Turbine
• Cách Turbine truyền bá các khối: Hướng dẫn từng bước
• Thông số kỹ thuật của Turbine
• Turbine và hiệu suất của Solana: Kết nối truyền bá khối với TPS
• Turbine có an toàn không? Mô hình bảo mật và các vectơ tấn công đã biết
• Solana Turbine so với Ethereum và các Blockchain Layer-1 khác
• Turbine trong kiến trúc của Solana: Tất cả 8 cải tiến
• Sự tiến hóa của Turbine: Từ năm 2017 Whitepaper đến nay
• Các câu hỏi thường gặp về Solana Turbine
• Kết luận: Tại sao Turbine lại quan trọng đối với tương lai của Solana
• Đọc thêm và các nguồn tài liệu chính

Solana Turbine Truyền bá Khối là gì?

Định nghĩa

Solana Turbine là giao thức truyền bá khối của Solana, cơ chế mà theo đó một khối mới được tạo ra sẽ bị phân mảnh thành hàng nghìn gói dữ liệu có kích thước cố định được gọi là các mảnh (shreds) và được phân phối qua mạng lưới trình xác thực thông qua một cấu trúc cây phân cấp được gọi là cây vùng lân cận (neighborhood tree). Mã hóa xóa Reed-Solomon giúp khôi phục bất kỳ gói tin nào bị mất trong quá trình vận chuyển, đảm bảo các trình xác thực có thể tái cấu trúc khối hoàn chỉnh ngay cả trong điều kiện mạng bất lợi.

Turbine tồn tại vì việc phát sóng (broadcast) ngây thơ không thể mở rộng. Nếu người dẫn đầu khối (trình xác thực được chỉ định để tạo khối cho một khe thời gian cụ thể) gửi trực tiếp toàn bộ khối cho mọi trình xác thực cùng một lúc, mỗi trình xác thực sẽ cần tải xuống toàn bộ khối một cách độc lập. Với hơn 2.000 trình xác thực đang hoạt động trên mạng lưới Solana, cách tiếp cận đó sẽ yêu cầu băng thông O(n) từ một nguồn duy nhất, nghĩa là chi phí băng thông tăng tuyến tính với mỗi trình xác thực được thêm vào mạng.

Turbine đạt được khả năng mở rộng băng thông O(log n) bằng cách mượn nguyên tắc cốt lõi từ giao thức BitTorrent. Giao thức phân phối tệp ngang hàng BitTorrent chuyển các tệp lớn một cách hiệu quả bằng cách chia chúng thành các mảnh nhỏ và truyền các mảnh đó qua nhiều nút cùng lúc thay vì phục vụ chúng từ một máy chủ. Turbine áp dụng ý tưởng tương tự cho việc truyền bá khối blockchain: thay vì người dẫn đầu khối truyền toàn bộ khối cho mọi trình xác thực, nó sẽ phân mảnh khối thành các mảnh và định tuyến chúng qua một cây trình xác thực nhiều lớp, với mỗi lớp sẽ chuyển tiếp các mảnh xuống phía dưới.

Sự tương đồng này có những giới hạn đáng lưu ý. BitTorrent hoạt động như một bầy đàn ngang hàng phẳng, nơi tất cả những người tham gia được đối xử bình đẳng. Turbine sử dụng một cây phân cấp với vị trí dựa trên trọng số cổ phần, nghĩa là các trình xác thực có nhiều SOL được đặt cược hơn sẽ được đặt gần Top của cây hơn và nhận được các mảnh sớm hơn. Sự khác biệt đó rất quan trọng để hiểu cả hiệu quả của Turbine và sự đánh đổi về bảo mật của nó.

Turbine được thiết kế bởi Anatoly Yakovenko, đồng sáng lập Solana Labs, và được giới thiệu trong sách trắng Solana gốc của Anatoly Yakovenko (2017).). Giao thức này đã được đưa vào sản xuất liên tục kể từ khi ra mắt Mainnet beta của Solana vào tháng 3 năm 2020.

Các thuật ngữ chính: Hướng dẫn tham khảo nhanh về thuật ngữ Turbine

Trước khi đi sâu vào cách hoạt động của Turbine, đây là các thuật ngữ cốt lõi mà bạn sẽ gặp trong suốt bài viết này.

Cách Turbine truyền bá các khối: Hướng dẫn từng bước

Turbine truyền bá các block thông qua quy trình gồm năm bước: leader của block phân mảnh block, mã hóa Reed-Solomon tạo ra các gói dự phòng, và các mảnh phân tán kết quả chảy qua một cây cấu trúc theo trọng số stake cho đến khi mọi validator có đủ mảnh để tái tạo lại block hoàn chỉnh. Mỗi bước dưới đây sẽ trình bày chi tiết một giai đoạn của quy trình đó.

Mỗi block bắt đầu với leader của block (còn gọi là block producer), nút validator được chỉ định cho một slot nhất định và được chọn trước thông qua lịch trình leader xác định của Solana. Theo tài liệu lịch trình leader của Solana, lịch trình đó được bắt nguồn từ đồng hồ Proof of History (PoH), cơ chế theo dõi thời gian mật mã của Solana. Vì lịch trình leader công khai và xác định, bất kỳ validator nào cũng có thể xác minh ai sẽ là leader block tiếp theo trước khi slot bắt đầu.

Leader của block thu thập các giao dịch được chuyển tiếp bởi Gulf Stream (giao thức chuyển tiếp giao dịch của Solana, đẩy các giao dịch chưa xác nhận đến leader dự kiến tiếp theo trước khi block hiện tại hoàn tất) và tập hợp chúng thành một block hoàn chỉnh. Sau khi tập hợp, leader của block bắt đầu quy trình Turbine.

Leader của block chia block đã hoàn thành thành các gói dữ liệu có kích thước cố định gọi là shreds, mỗi gói có kích thước khoảng 1,5 KB, theo tài liệu kỹ thuật của Solana. Các mảnh dữ liệu block gốc này được gọi là data shreds. Một block Solana kích thước đầy đủ có thể tạo ra hàng nghìn data shreds tùy thuộc vào kích thước block.

Hãy tưởng tượng việc phân mảnh giống như chia một tệp lớn thành hàng nghìn tệp đính kèm email nhỏ và định tuyến mỗi tệp qua một đường dẫn khác nhau: tệp hoàn chỉnh sẽ được ghép lại ở đích ngay cả khi một vài tệp đính kèm đến muộn. Ưu điểm chính là truyền tải song song. Vì mỗi validator trong cây nhận và chuyển tiếp các mảnh khác nhau cùng lúc, mạng lưới không cần đợi một lần truyền tuần tự lớn trước khi bắt đầu phân phối dữ liệu.

Việc phân mảnh của Turbine không phải là sharding. Sharding chia trạng thái Blockchain hoặc xử lý giao dịch trên nhiều mạng con song song, với các tập hợp validator khác nhau xác thực các phần khác nhau của trạng thái. Turbine phân mảnh block chỉ vì hiệu quả truyền tải: toàn bộ mạng lưới validator của Solana xác thực trạng thái block hoàn chỉnh giống nhau. Việc phân mảnh là một cơ chế phân phối, không phải là một chiến lược phân chia.

Mã hóa xóa Reed-Solomon tạo ra một loại mảnh thứ hai gọi là coding shreds, là các gói dự phòng cho phép bất kỳ validator nào tái tạo lại block hoàn chỉnh ngay cả khi một phần của các data shreds ban đầu bị mất trong quá trình truyền tải. Sự khác biệt là quan trọng: data shreds mang nội dung block thực tế; coding shreds mang thông tin dự phòng được tính toán bằng toán học có thể lấp đầy các khoảng trống.

Một phép so sánh hữu ích: mã hóa xóa Reed-Solomon hoạt động giống như mã QR. Ngay cả khi một phần của mã QR bị che khuất hoặc bị hỏng, vẫn còn đủ thông tin dự phòng được mã hóa trong các phần còn lại để giải mã thông điệp hoàn chỉnh. Phép so sánh mã QR có một giới hạn đáng chú ý: mã QR là các đối tượng tĩnh, trong khi mã hóa xóa của Turbine hoạt động trên một loạt các mảnh truyền phát với ngưỡng phục hồi số cụ thể.

Theo triển khai của Solana, các validator có thể tái tạo lại block hoàn chỉnh miễn là họ nhận được khoảng hai phần ba tổng số mảnh (dữ liệu cộng với các mảnh mã hóa). Điều đó có nghĩa là giao thức có thể chịu được tổn thất gói khoảng một phần ba trước khi tái tạo thất bại. Mã hóa Reed-Solomon là một công nghệ trưởng thành với hàng thập kỷ sử dụng trong sản xuất trên đĩa CD, DVD, truyền thông vệ tinh và các ứng dụng khác, điều này hỗ trợ cho khẳng định rằng cơ chế chịu lỗi của Turbine dựa trên kỹ thuật đã được chứng minh chứ không phải thiết kế thử nghiệm. Các tham số kỹ thuật được trích dẫn từ whitepaper của Solana) và tài liệu Turbine chính thức của Solana.

Cây cấu trúc theo hàng xóm (còn gọi là cây fanout) là cấu trúc định tuyến phân cấp mà Turbine sử dụng để phân phối các mảnh, tổ chức các validator của Solana thành các lớp nơi mỗi lớp nhận mảnh từ lớp trên và truyền lại xuống dưới. Cấu trúc dưới đây cho thấy cây mở rộng trên hai lớp:

Lớp 0 (Leader Block)
        |
        +-- Layer 1: ~200 validator (mỗi validator nhận một tập hợp mảnh duy nhất)
                |
                +-- Layer 2: lên tới ~40.000 validator (200 x 200, mỗi validator Layer 1 truyền tới ~200 validator khác)

Cây cấu trúc theo hàng xóm bao phủ toàn bộ tập hợp validator hoạt động của Solana (khoảng hơn 2.000 validator theo thống kê mạng lưới của Solana Foundation) trong vòng hai đến ba lớp, với hệ số fanout xấp xỉ 200 mỗi lớp. Với hai lớp, cây về mặt toán học có thể đạt tới 40.000 validator (200 x 200), vượt xa tập hợp hoạt động hiện tại.

Hãy nghĩ về cấu trúc này giống như một mạng lưới phân loại bưu phẩm: trung tâm gửi các lô hàng đến các trung tâm phân loại khu vực, sau đó chuyển đến các bưu cục địa phương, và cuối cùng là đến từng địa chỉ cụ thể. Mỗi lớp chỉ xử lý một phần của tổng tải trọng, và không có một nút nào phải gánh toàn bộ chi phí băng thông. Tuy nhiên, không giống như một hệ thống bưu chính trung lập, cây cấu trúc theo hàng xóm của Turbine có trọng số theo stake. Các validator có lượng SOL stake lớn hơn theo mô hình Cơ chế đồng thuận dựa trên Proof of Stake của Solana (Tower BFT) được định vị gần đỉnh cây hơn, đảm bảo họ nhận mảnh sớm nhất.

Cấu trúc cây cũng được ngẫu nhiên hóa mỗi slot bằng cách sử dụng tính ngẫu nhiên có thể xác minh bắt nguồn từ đồng hồ PoH, một nguồn ngẫu nhiên mà bất kỳ validator nào cũng có thể độc lập xác minh mà không cần tin tưởng một bên trung tâm. Vì cây thay đổi mỗi slot, các validator đối địch không thể dự đoán được validator nào sẽ là hàng xóm của họ trong vòng tiếp theo. Sự ngẫu nhiên hóa đó là biện pháp bảo vệ chính của Turbine chống lại các cuộc tấn công eclipse, nơi kẻ tấn công cố gắng bao vây một validator mục tiêu và giữ lại các mảnh.

Kết quả là băng thông mở rộng theo tỷ lệ O(log n), có nghĩa là yêu cầu băng thông tăng chậm so với số lượng validator. Đặc tính này làm cho thiết kế của Turbine ngày càng có giá trị khi số lượng validator của Solana tăng lên.

Khi một validator nhận đủ mảnh để đáp ứng ngưỡng mã hóa xóa (khoảng hai phần ba tổng số mảnh cho block đó), nó sẽ tái tạo lại block hoàn chỉnh và gửi phiếu bầu của mình tới Tower BFT (Tower Byzantine Fault Tolerance), Cơ chế đồng thuận dựa trên Proof of Stake của Solana. Các validator không thể bỏ phiếu cho đến khi quá trình tái tạo hoàn tất, đó là lý do tại sao tốc độ truyền bá của Turbine trực tiếp quyết định thông lượng đồng thuận.

Quy trình truyền bá được thiết kế xung quanh nhịp độ slot mục tiêu của Solana, nhưng thời gian thực tế và phạm vi bao phủ validator thay đổi tùy theo điều kiện mạng và triển khai. Nếu quá trình truyền bá hoàn tất trong cửa sổ đó, đồng thuận sẽ tiến hành và slot tiếp theo bắt đầu. Nếu không, slot có thể bị bỏ qua, làm giảm tạm thời thông lượng.

Sự thật quan trọng

Khi các mảnh bị mất trong quá trình truyền tải, mã hóa xóa Reed-Solomon của Solana cho phép các validator tái tạo lại block hoàn chỉnh từ các coding shreds mà họ nhận được, miễn là tổng số gói bị mất vẫn dưới khoảng một phần ba tổng số mảnh được truyền cho block đó.

Phép so sánh mã QR cũng áp dụng ở đây: miễn là đủ các mẫu còn tồn tại, toàn bộ thông điệp sẽ được giải mã. Khi tổn thất gói vẫn nằm dưới ngưỡng phục hồi, các validator sẽ tái tạo lại block từ bất kỳ sự kết hợp nào của data shreds và coding shreds đã đến.

Khi tỷ lệ mất gói tin vượt quá ngưỡng đó, trình xác thực sẽ đưa ra yêu cầu sửa chữa tới các trình xác thực lân cận đang giữ các shred bị thiếu. Cơ chế sửa chữa đó làm tăng độ trễ nhưng không gây ra tình trạng bỏ lỡ slot ngay lập tức trừ khi việc sửa chữa không thể hoàn thành trong khung thời gian của slot.

Trong tình trạng tắc nghẽn mạng nghiêm trọng, khi việc mất gói tin xảy ra trên toàn mạng thay vì chỉ giới hạn ở một lộ trình, nhiều trình xác thực có thể không tái cấu trúc được các khối của họ trong khung thời gian của slot. Sự cộng hưởng đó góp phần gây ra tình trạng bỏ lỡ slot và trong những trường hợp cực đoan, dẫn đến tình trạng suy giảm mạng lưới mà Solana đã trải qua trong các sự kiện tắc nghẽn lớn vào năm 2021 và 2022. Kể từ đó, Solana Labs đã tinh chỉnh việc xử lý tắc nghẽn của Turbine để ứng phó với những sự kiện đó. Mối liên hệ giữa tắc nghẽn và bỏ lỡ slot được đề cập trong phần bảo mật bên dưới.

Các thông số kỹ thuật của Turbine

Bảng sau đây tóm tắt các thông số vận hành chính của Turbine, được trích xuất từ tài liệu chính thức của Solana và Whitepaper của Solana. Các thông số có thể được Solana Labs cập nhật khi giao thức phát triển; hãy kiểm tra các giá trị hiện tại tại Tài liệu Turbine chính thức của Solana.

Turbine và Hiệu suất của Solana: Kết nối việc Lan truyền Khối với TPS

Whitepaper của Solana và các bình luận sau đó đã trích dẫn thông lượng lý thuyết gần 65.000 TPS. Thông lượng thực tế quan sát được phụ thuộc vào thời điểm, khối lượng công việc, việc bao gồm phiếu bầu, lọc và phiên bản phần mềm, vì vậy không nên đưa ra phạm vi TPS thực tế (không tính phiếu bầu) mà không có phương pháp đo lường đi kèm. Turbine là một thành phần đóng góp vào kết quả, chứ không phải là một sự đảm bảo TPS độc lập.

Chuỗi nguyên nhân hoạt động như sau: Turbine lan truyền các shred đủ nhanh để các trình xác thực trên toàn mạng tái cấu trúc các khối và bỏ phiếu trong khung thời gian slot xấp xỉ 400ms. Sự đồng thuận tiếp tục diễn ra. Slot tiếp theo bắt đầu. Solana duy trì nhịp độ slot của mình. Vì mỗi slot có thể chứa hàng nghìn giao dịch, việc duy trì nhịp độ đó là yếu tố tạo ra TPS cao. Nếu làm gián đoạn nhịp độ bằng các đợt trễ lan truyền, TPS sẽ giảm; duy trì được nhịp độ thì TPS sẽ ở mức cao.

Sự khác biệt giữa TPS lý thuyết và TPS quan sát được xứng đáng được chú ý rõ ràng. Con số TPS thô của Solana (có thể đạt mức cao hơn) bao gồm cả các giao dịch bỏ phiếu của trình xác thực, vốn là các tin nhắn đồng thuận nội bộ không đại diện cho các giao dịch do người dùng gửi. TPS không tính phiếu bầu, con số có khả năng so sánh cao hơn với thông lượng trên các blockchain khác, thường chạy ở mức 2.000 đến 4.000 trong điều kiện tải thực tế tính đến năm 2024-2025, theo tài liệu hiệu suất của Solana Labs. Con số 65.000 là mức trần lý thuyết giả định các điều kiện lý tưởng; nó không phải là mô tả về hành vi mạng trung bình.

Thiết kế băng thông O(log n) của Turbine cũng ngăn chặn lớp lan truyền trở thành nút thắt cổ chai khi số lượng trình xác thực tăng lên. Với phương pháp phát sóng thông thường, việc tăng gấp đôi số lượng trình xác thực sẽ làm tăng gấp đôi băng thông yêu cầu từ mỗi nút gửi. Với cấu trúc cây của Turbine, việc tăng gấp đôi số lượng trình xác thực chỉ thêm một lớp bổ sung (xấp xỉ thêm 200 trình xác thực cho mỗi nút hiện có), nghĩa là yêu cầu băng thông tăng chậm thay vì tăng tuyến tính.

Điểm mấu chốt

Turbine không thực hiện các giao dịch; nó lan truyền dữ liệu khối. Hiệu suất lan truyền có thể ảnh hưởng đến việc bỏ phiếu và thông lượng, nhưng Turbine không đảm bảo một con số TPS cố định, nhịp độ slot hay thời gian hoàn tất giao dịch.

Turbine có an toàn không? Mô hình bảo mật và các vectơ tấn công đã biết

Turbine tích hợp ba cơ chế bảo mật cốt lõi: định tuyến ngẫu nhiên xáo trộn sau mỗi slot, định vị cây theo trọng số Staking, và tính dư thừa Reed-Solomon. Mỗi cơ chế giải quyết một bề mặt tấn công cụ thể, mặc dù mỗi cơ chế cũng đưa ra một sự đánh đổi xứng đáng được xem xét một cách trung thực.

Cách định tuyến ngẫu nhiên bảo vệ chống lại các trình xác thực đối địch

Cây lân cận được xáo trộn sau mỗi slot bằng cách sử dụng tính ngẫu nhiên có thể kiểm chứng được lấy từ đồng hồ Proof of History, nghĩa là các trình xác thực đối địch không thể dự đoán trình xác thực nào sẽ là lân cận của họ trong slot tiếp theo. Điều này quan trọng vì vectơ tấn công chính chống lại cây phân phối phân lớp là tấn công che khuất (eclipse attack): một kẻ tấn công đặt các trình xác thực xung quanh một trình xác thực mục tiêu và giữ lại các shred, ngăn trình xác thực đó tái cấu trúc khối và do đó chặn trình xác thực đó bỏ phiếu.

Vì cấu trúc cây thay đổi sau mỗi slot, kẻ tấn công không thể duy trì vòng vây đó một cách tin cậy. Trình dẫn đầu khối (block leader) được biết trước (thông qua lịch trình leader cố định), nhưng lộ trình lan truyền thì không. Sự bất đối xứng đó là một thiết kế bảo mật có chủ đích: minh bạch về việc ai tạo ra khối, kết hợp với tính mờ đục về cách các khối đó di chuyển.

Sự bảo vệ này có giới hạn. Một kẻ tấn công với lượng Staking đủ lớn có khả năng xuất hiện ở nhiều vị trí trong các lần xáo trộn liên tiếp, duy trì một sự hiện diện thống kê nhất định gần các trình xác thực mục tiêu. Định tuyến ngẫu nhiên làm tăng chi phí và độ phức tạp của các cuộc tấn công che khuất mà không làm cho chúng trở nên bất khả thi đối với một đối thủ có nguồn lực tốt.

Tỷ trọng Stake và các lo ngại về tập trung hóa

Tỷ trọng Stake đặt các trình xác thực có lượng Staking cao hơn ở gần Top của cây lân cận hơn, nghĩa là họ nhận được các shred sớm hơn các trình xác thực có lượng Staking thấp hơn, điều này tạo ra lợi thế cấu trúc cho các hoạt động Staking lớn. Các trình xác thực nhận được shred trước có thể bắt đầu tái cấu trúc và bỏ phiếu trước các đồng nghiệp có Staking thấp hơn, điều này chuyển thành một lợi thế nhỏ về thời gian trong quy trình đồng thuận.

Lời phê bình trung thực: các trình xác thực có sự tập trung Staking đủ lớn về mặt lý thuyết có thể sử dụng quyền truy cập sớm đó để thực hiện các chiến lược giữ khối, trì hoãn phiếu bầu của họ để giành lợi thế về thông tin. Các quy tắc hoàn tất đồng thuận của Tower BFT được thiết kế để hạn chế khả năng thực thi của các chiến lược như vậy, và sự tập trung Staking được phân bổ trên khoảng hơn 2.000 trình xác thực đang hoạt động (theo số liệu thống kê mạng lưới của Solana Foundation), điều này hạn chế sự tập trung cực đoan. Solana Foundation cũng vận hành các chương trình ủy quyền Staking được thiết kế để phân bổ Staking rộng rãi hơn cho các trình xác thực nhỏ hơn. Tuy nhiên, lợi thế cấu trúc cho các trình xác thực lớn là có thật và đáng để đưa vào bất kỳ đánh giá nào về hồ sơ phi tập trung của Solana.

Turbine, Tắc nghẽn mạng và các lần ngừng hoạt động trong lịch sử

Hầu hết các đợt ngừng hoạt động mạng chính của Solana từ năm 2021 đến 2022 là do tắc nghẽn đường ống xử lý giao dịch thay vì các lỗi cụ thể của Turbine, mặc dù tình trạng tắc nghẽn cực độ có thể gây áp lực lên lớp lan truyền khối. Khi khối lượng giao dịch làm quá tải đường ống xử lý của Solana trong những giai đoạn đó, khối lượng các khối được tạo ra và chia nhỏ thành các shred cũng tăng lên, và lớp lan truyền phải đối mặt với nhiều đợt shred đồng thời hơn mức băng thông của mạng có thể hấp thụ một cách trơn tru.

Kết quả là tình trạng mất gói tin trên diện rộng vượt quá ngưỡng khôi phục của mã hóa xóa (erasure coding) trên nhiều trình xác thực cùng lúc, góp phần tạo ra các chuỗi bỏ lỡ slot liên tiếp thay vì các lỗi cá nhân riêng lẻ. Solana Labs kể từ đó đã thực hiện các cải tiến kỹ thuật trong việc xử lý tắc nghẽn, bao gồm những thay đổi trong cách mạng quản lý việc tiếp nhận giao dịch và cách Turbine xử lý việc truyền tải dưới tải trọng cao. Để biết trạng thái kỹ thuật hiện tại, hãy xem blog kỹ thuật của Solana Labs. Lịch sử sự cố ngừng hoạt động là một thực tế trong hồ sơ sản xuất của Turbine, không phải là rủi ro lý thuyết, và nó là bối cảnh liên quan cho bất kỳ ai đánh giá khả năng phục hồi kỹ thuật của Solana.

Solana Turbine so với Ethereum và các Blockchain lớp 1 khác

Solana truyền tải các khối nhanh hơn Ethereum chủ yếu vì Turbine sử dụng cây vùng lân cận phân cấp để phân phối các shred (mảnh dữ liệu) song song, trong khi Ethereum sử dụng giao thức tin đồn (gossip protocol), nơi các trình xác thực phát các khối tới một tập hợp con ngẫu nhiên gồm các đồng đẳng, những người này sau đó phát lại cho các đồng đẳng của họ, một cấu trúc mạng về cơ bản là chậm hơn khi mở rộng quy mô. Bảng dưới đây so sánh Solana, Ethereum và Avalanche qua các khía cạnh quan trọng nhất đối với việc truyền tải khối.

Một sự khác biệt đáng được làm rõ: Bản thân Solana sử dụng giao thức gossip để chia sẻ thông tin cụm và siêu dữ liệu giao thức, nhưng Turbine thay thế gossip cho nhiệm vụ cụ thể là truyền tải khối. Chính cấu trúc cây phân cấp của Turbine đã vượt trội hơn cấu trúc mạng phẳng của gossip trong việc phân phối khối ở quy mô lớn.

Giao thức gossip của Ethereum (nơi các trình xác thực phát các khối tới một tập hợp con ngẫu nhiên các đồng đẳng, những người này sau đó phát lại cho các đồng đẳng của họ, truyền tải khối qua mạng trong nhiều vòng) đơn giản hơn để triển khai và tạo ra sự lựa chọn đồng đẳng đồng nhất hơn, không ưu tiên bất kỳ trình xác thực nào dựa trên stake. Thiết kế đó phản ánh sự ưu tiên của Ethereum cho tính phi tập trung rộng rãi và sự tham gia không cần cấp phép. Sự đánh đổi là tốc độ truyền tải: nhiều vòng gossip trên một tập hợp trình xác thực lớn tạo ra thời gian khối được tính bằng giây thay vì mili giây.

Turbine khác với giao thức BitTorrent theo hai cách mà bảng trên không thể hiện hết. BitTorrent sử dụng một nhóm ngang hàng phẳng, nơi tất cả những người tham gia đều bình đẳng; Turbine sử dụng một cây phân cấp với các vị trí trung tâm có trọng số stake. BitTorrent không có giới hạn thời gian cho việc lắp ráp tệp; Turbine phải phân phối trong cửa sổ slot 400ms nếu không sẽ lỡ nhịp đồng thuận. Những sự khác biệt đó là các phản hồi thiết kế đối với các yêu cầu đặc thù của blockchain mà mô hình BitTorrent không phải đối mặt.

Truyền tải Snowflake/Snowball DAG của Avalanche thực hiện một cách tiếp cận khác: thăm dò ngẫu nhiên lặp lại các tập hợp con trình xác thực nhỏ để đạt được sự đồng thuận theo xác suất mà không cần mô hình dẫn đầu khối duy nhất. Thiết kế đó cung cấp khả năng mở rộng băng thông dưới tuyến tính thông qua việc lấy mẫu thay vì thông qua một cây, và nó tạo ra tính hữu hạn nhanh hơn Ethereum trong khi vẫn khác biệt cơ bản với cách tiếp cận dựa trên shred của Turbine. Mỗi thiết kế thực hiện các sự đánh đổi khác nhau giữa một bên là tốc độ và tính phi tập trung, và bên kia là khả năng chịu lỗi và tính phức tạp. Bảng này trình bày những sự đánh đổi đó; việc tuyên bố một kiến trúc là ưu việt hơn sẽ trình bày sai không gian thiết kế.

Turbine trong Kiến trúc của Solana: Tất cả 8 Cải tiến

Turbine là một trong tám cải tiến kiến trúc mà Anatoly Yakovenko đã giới thiệu trong sách trắng Solana năm 2017, mỗi cải tiến được thiết kế để giải quyết một điểm nghẽn hiệu suất khác nhau trong cơ sở hạ tầng blockchain. Danh sách đầy đủ:

• Proof of History (PoH): Cơ chế chấm công mật mã của Solana, một hàm trì hoãn có thể xác minh tạo ra bản ghi lịch sử về thứ tự sự kiện mà không yêu cầu các trình xác thực phải liên lạc để thống nhất về thời gian. PoH không phải là một cơ chế đồng thuận; nó là một chiếc đồng hồ. Nó xác định cấu trúc slot mà Turbine hoạt động trong đó.
• Tower BFT: Cơ chế đồng thuận dựa trên Proof of Stake của Solana, một biến thể của Khả năng chịu lỗi Byzantine Thực tế (PBFT) sử dụng đồng hồ PoH để giảm chi phí thông điệp trong việc đạt được tính hữu hạn.
• Turbine: Truyền tải khối, chủ đề của bài viết này. Turbine phân phối các khối mới được tạo ra cho tất cả các trình xác thực thông qua các shred và cây vùng lân cận.
• Gulf Stream: Giao thức chuyển tiếp giao dịch của Solana. Gulf Stream đẩy các giao dịch chưa được xác nhận tới trình dẫn đầu khối dự kiến tiếp theo trước khi khối hiện tại được hoàn thành, giảm thời gian trình dẫn đầu cần để lắp ráp một khối.
• Sealevel: Công cụ thực thi Hợp đồng Thông minh song song của Solana, xử lý hàng nghìn Hợp đồng Thông minh không chồng chéo cùng lúc thay vì tuần tự.
• Pipelining: Một đường ống xử lý giao dịch chỉ định các giai đoạn xác thực giao dịch khác nhau cho phần cứng chuyên dụng, cho phép nhiều khối được xác thực đồng thời ở các giai đoạn xử lý khác nhau.
• Cloudbreak: Cơ sở dữ liệu tài khoản được mở rộng theo chiều ngang của Solana, được tối ưu hóa cho các hoạt động đọc và ghi đồng thời trên phần cứng lưu trữ của trình xác thực.
• Archivers: Các nút lưu trữ Sổ lệnh phân tán giúp chuyển dữ liệu lịch sử blockchain từ các trình xác thực sang một lớp lưu trữ riêng biệt, giảm yêu cầu phần cứng của trình xác thực.

Gulf Stream và Turbine hoạt động theo trình tự trong suốt chu kỳ sống của giao dịch. Gulf Stream định tuyến các giao dịch chưa xác nhận tới trình dẫn đầu khối dự kiến trước khi quá trình sản xuất khối bắt đầu; sau đó Turbine phân phối khối kết quả ra bên ngoài tới tất cả các trình xác thực sau khi quá trình sản xuất hoàn tất. Cùng với nhau, hai giao thức này xử lý toàn bộ chu kỳ sống của giao dịch từ khi gửi đến khi phân phối trên toàn mạng.

Tám cải tiến này đã được giới thiệu bởi Anatoly Yakovenko, đồng sáng lập Solana Labs, trong sách trắng Solana gốc được xuất bản năm 2017.

Góc nhìn của Trình xác thực

Vị trí cây vùng lân cận của Turbine ảnh hưởng đến yêu cầu phần cứng của trình xác thực. Các trình xác thực được đặt ở Layer 1 (gần trình dẫn đầu khối hơn) nhận các shred trước và phải chuyển tiếp chúng cho khoảng 200 trình xác thực Layer 2, yêu cầu băng thông tải lên cao hơn các trình xác thực Layer 2 chỉ chuyển tiếp đến vùng lân cận phụ được chỉ định của họ. Mức độ Stake xác định vị trí trong cây: các trình xác thực có stake cao hơn chiếm các vị trí Layer 1 và nên chuẩn bị tương ứng. Các nhà vận hành nên tham khảo các khuyến nghị phần cứng hiện tại từ Solana Labs, vì các thông số kỹ thuật tối thiểu đã phát triển kể từ khi ra mắt Mainnet.

Sự phát triển của Turbine: Từ Whitepaper năm 2017 đến nay

Turbine lần đầu tiên được quy định trong sách trắng Solana gốc do Anatoly Yakovenko của Solana Labs viết vào năm 2017, khiến nó trở thành một trong những quyết định kiến trúc nền tảng của giao thức chứ không phải là một tính năng được thêm vào sau đó. Đặc tả năm 2017 đã thiết lập thiết kế cốt lõi: phân mảnh khối dựa trên shred, cấu trúc cây fanout để phân phối, và mã hóa xóa Reed-Solomon cho khả năng chịu lỗi.

Phiên bản Mainnet beta của Solana đã ra mắt vào tháng 3 năm 2020, đưa Turbine vào vận hành thực tế lần đầu tiên. Việc triển khai ban đầu đã xác nhận các đặc tính cốt lõi của thiết kế nhưng cũng bộc lộ những điều kiện thực tế mà đặc tả lý thuyết chưa dự đoán đầy đủ, đặc biệt là sự tương tác giữa tắc nghẽn giao dịch và tải truyền bá.

Sau các sự kiện căng thẳng mạng vào năm 2021 và 2022, Solana Labs đã thực hiện các cải tiến kỹ thuật đối với việc xử lý tắc nghẽn của Turbine, bao gồm các điều chỉnh về cách xếp hàng và truyền các lô shred (mảnh dữ liệu) dưới tải mạng cao. Những cải tiến này không thay đổi kiến trúc cơ bản của giao thức nhưng đã cải thiện hành vi của nó ở các giới hạn cực đoan của khung vận hành.

Turbine hiện đã vận hành liên tục trong hơn bốn năm trên một mạng lưới xử lý hàng triệu giao dịch mỗi ngày. Hồ sơ vận hành đó hỗ trợ một câu trả lời rõ ràng cho câu hỏi liệu Turbine là một phương pháp đã được chứng minh hay mang tính thử nghiệm: đó là một giao thức vận hành đã được thử thách qua thực tế ở quy mô lớn, với nguồn gốc kỹ thuật có thể truy xuất từ bản đặc tả năm 2017. Để biết các tham số giao thức hiện tại và những thay đổi kỹ thuật gần đây, hãy xem blog kỹ thuật của Solana Labs.

Các câu hỏi thường gặp về truyền bá khối Solana Turbine

Các câu hỏi sau đây giải đáp những thắc mắc phổ biến nhất về thiết kế và hiệu suất của Solana Turbine.

Solana Turbine là gì?

Turbine là giao thức mà Solana sử dụng để đưa các khối mới được tạo đến mọi trình xác thực (validator) trong mạng lưới trong khung thời gian khe (slot window) 400 mili giây. Nó hoạt động bằng cách chia nhỏ các khối thành các shred và định tuyến chúng qua một cây lân cận phân cấp, với mã hóa xóa Reed-Solomon xử lý bất kỳ gói tin nào bị mất trong quá trình truyền. Kết quả là sự phân phối khối nhanh chóng, hiệu quả về băng thông và có khả năng mở rộng khi số lượng trình xác thực tăng lên.

Shred trong Solana là gì?

Shred là gói dữ liệu cơ bản được Turbine sử dụng để truyền khối, có kích thước khoảng 1,5 KB. Có hai loại: data shred (shred dữ liệu), mang nội dung khối gốc và coding shred (shred mã hóa), là các gói dư thừa được tạo bởi mã hóa xóa Reed-Solomon cho phép tái tạo khối ngay cả khi một số data shred bị mất trong quá trình truyền.

Turbine phân phối dữ liệu khối như thế nào?

Trình dẫn đầu khối (block leader) chia khối thành các data shred và tạo các coding shred thông qua mã hóa Reed-Solomon. Những shred đó chảy qua cây lân cận: trình dẫn đầu khối gửi đến khoảng 200 trình xác thực Layer 1, mỗi trình xác thực này lại chuyển tiếp đến khoảng 200 trình xác thực Layer 2, bao phủ toàn bộ tập hợp trình xác thực đang hoạt động trong vòng hai đến ba lớp và hoàn tất trong khung thời gian khe khoảng 400 mili giây.

Tại sao Solana nhanh hơn Ethereum trong việc truyền bá khối?

Solana sử dụng cây lân cận phân cấp của Turbine, giúp phân phối các shred song song qua nhiều trình xác thực cùng một lúc, đạt được khả năng mở rộng băng thông O(log n). Ethereum sử dụng giao thức gossip (tin đồn) yêu cầu nhiều vòng truyền phát lại ngẫu nhiên tuần tự giữa các thực thể ngang hàng để đạt được độ phủ toàn mạng, tạo ra thời gian tạo khối khoảng 12 giây so với thời gian khe khoảng 400 mili giây của Solana. Cả hai thiết kế đều phản ánh các ưu tiên kiến trúc có tính toán.

Turbine có an toàn không?

Turbine bao gồm định tuyến ngẫu nhiên (cây lân cận xáo trộn lại mỗi khe bằng cách sử dụng tính ngẫu nhiên có thể kiểm chứng), tính dư thừa Reed-Solomon (chịu được tỷ lệ mất gói tin khoảng một phần ba) và định vị theo trọng số staking. Định tuyến ngẫu nhiên giúp các cuộc tấn công nhật thực (eclipse attacks) khó thực hiện hơn đáng kể. Việc tính trọng số staking dẫn đến một sự đánh đổi nhẹ về tính tập trung: các trình xác thực có mức stake cao hơn sẽ nhận được shred sớm hơn, tạo ra một lợi thế cấu trúc mà các quy tắc đồng thuận của Tower BFT bù đắp một phần.

Điều gì xảy ra nếu các shred bị mất?

Khi tỷ lệ mất gói tin vẫn dưới mức khoảng một phần ba tổng số shred, mã hóa xóa Reed-Solomon cho phép các trình xác thực tái tạo khối hoàn chỉnh từ các data shred và coding shred còn sót lại. Vượt quá ngưỡng đó, trình xác thực sẽ gửi yêu cầu sửa chữa đến các trình xác thực lân cận đang giữ các shred bị thiếu. Nếu việc sửa chữa không thể hoàn tất trong khung thời gian khe, khe đó có thể bị bỏ qua.

Turbine có tạo ra rủi ro tập trung hóa không?

Việc tính trọng số staking của Turbine tạo ra lợi thế cấu trúc cho các trình xác thực có mức stake cao, những người nhận được shred sớm hơn và giữ vị trí cao hơn trong cây lân cận. Đây là một sự đánh đổi thực sự. Các yếu tố giảm thiểu bao gồm sự phân bổ của Solana trên hơn 2.000 trình xác thực đang hoạt động, các quy tắc đồng thuận của Tower BFT giới hạn giá trị của việc tiếp cận shred sớm và các chương trình ủy quyền stake của Solana Foundation nhằm mở rộng sự phân bổ stake.

Ai đã tạo ra Solana Turbine?

Turbine được thiết kế bởi Anatoly Yakovenko, người đồng sáng lập Solana Labs, và được đặc tả lần đầu trong Whitepaper của Solana xuất bản năm 2017. Solana Labs (tổ chức kỹ thuật, khác với Solana Foundation vốn xử lý quản trị hệ sinh thái) duy trì và tiếp tục phát triển giao thức.

Turbine có liên quan gì đến Gulf Stream?

Gulf Stream và Turbine là các giao thức tuần tự trong vòng đời giao dịch của Solana. Gulf Stream định tuyến các giao dịch chưa xác nhận đến trình dẫn đầu khối dự kiến trước khi quá trình sản xuất khối bắt đầu, để trình dẫn đầu có thể bắt đầu lắp ráp khối mà không cần chờ giao dịch đến. Sau đó, Turbine sẽ phân phối khối đã hoàn thành ra bên ngoài cho tất cả các trình xác thực sau khi quá trình sản xuất kết thúc.

Solana có thể xử lý bao nhiêu TPS?

Tối đa lý thuyết của Solana là khoảng 65.000 TPS, theo Whitepaper của Solana, trong điều kiện lý tưởng. Trong điều kiện thực tế, TPS không bao gồm phiếu bầu (non-vote) quan sát được thường dao động từ 2.000 đến 4.000 giao dịch mỗi giây tính đến giai đoạn 2024-2025, theo tài liệu hiệu suất của Solana Labs. Con số TPS thô đôi khi được trích dẫn ở mức cao hơn bao gồm cả các giao dịch bỏ phiếu của trình xác thực, vốn là các thông điệp đồng thuận nội bộ chứ không phải là giao dịch của người dùng.

Các hướng dẫn liên quan về Solana

• Các nút RPC của Solana
• Các khe và thời gian khối của Solana

Khám phá SOL trên Bybit

Người đọc có thể xem lại thông tin thị trường SOL hiện tại hoặc thị trường Giao ngay SOL/USDT.. Các liên kết này cung cấp thông tin thị trường và quyền truy cập; chúng không xác nhận một tuyên bố kỹ thuật nào hoặc ngụ ý rằng SOL phù hợp với mọi người đọc.

Kết luận: Tại sao Turbine quan trọng đối với tương lai của Solana

Turbine là cơ chế kỹ thuật giúp Solana đạt được thời gian khe khoảng 400 mili giây: nếu không có sự truyền bá khối nhanh chóng và hiệu quả về băng thông, các trình xác thực của Solana sẽ không thể nhận và bỏ phiếu cho các khối đủ nhanh để duy trì nhịp độ khe mà thông lượng cao yêu cầu. Thiết kế này giải quyết một hạn chế thực sự về khả năng mở rộng, vấn đề băng thông O(n) của việc phát sóng thô sơ, thông qua sự kết hợp giữa phân mảnh dựa trên shred, phân phối cây phân cấp và khả năng chịu lỗi Reed-Solomon.

Thiết kế này mang theo những sự đánh đổi đáng để tìm hiểu. Việc định vị cây theo trọng số Stake mang lại lợi thế cấu trúc cho các trình xác thực lớn. Định tuyến ngẫu nhiên giảm thiểu các cuộc tấn công nhật thực nhưng không loại bỏ được chúng trước các đối thủ có nguồn lực tốt. Lớp truyền bá có thể bị căng thẳng khi mạng lưới tắc nghẽn cực độ, như đã được chứng minh qua hồ sơ sự cố năm 2021-2022 của Solana. Không có điều nào trong số này là yếu tố bác bỏ; tất cả đều là những đánh đổi về kiến trúc được thực hiện để đổi lấy tốc độ và hiệu quả băng thông mà giao thức cung cấp.

Turbine đã hoạt động trong môi trường sản xuất từ năm 2020 và đã được cải tiến để đáp ứng các điều kiện thực tế. Khi số lượng trình xác thực của Solana tăng lên, thuộc tính tỷ lệ mở rộng O(log n) trở nên ngày càng quan trọng: mỗi lần tăng gấp đôi bộ trình xác thực chỉ thêm một lớp cây thay vì nhân đôi chi phí băng thông. Thuộc tính đó là thứ làm cho thiết kế bền vững ở quy mô lớn. Tốc độ và độ tin cậy của việc truyền khối của Turbine cũng là thứ làm cho Solana trở thành một lớp hạ tầng khả thi cho các ứng dụng tài chính phi tập trung (DeFi) tần suất cao, nơi độ trễ truyền ảnh hưởng trực tiếp đến kết quả xác nhận giao dịch.

Điểm chính cần ghi nhớ

Turbine là nền tảng kỹ thuật làm cho các tuyên bố về tốc độ của Solana trở nên đáng tin cậy. Hiểu cách nó phân mảnh các khối thành các mảnh nhỏ, định tuyến chúng qua một cây lân cận được trọng số theo stake và khôi phục các gói bị mất thông qua mã hóa xóa Reed-Solomon là cách rõ ràng nhất để đánh giá liệu các tuyên bố về hiệu suất đó có dựa trên kiến trúc vững chắc hay không. Thiết kế có những điểm mạnh thực sự và những đánh đổi thực sự; cả hai đều xứng đáng được xem xét trong bất kỳ đánh giá kỹ thuật trung thực nào về cơ sở hạ tầng của Solana.

Đọc thêm và các nguồn chính

Các nguồn chính sau đây cung cấp nền tảng kỹ thuật cho các tuyên bố được đưa ra trong bài viết này.

• Turbine Block Propagation (Tài liệu Solana): Tài liệu kỹ thuật chính thức về Turbine, được duy trì bởi các kỹ sư Solana Labs.
• Whitepaper Solana gốc của Anatoly Yakovenko (2017): Đặc tả nền tảng cho Turbine và tất cả tám cải tiến kiến trúc của Solana.
• Blog kỹ thuật Solana Labs: Các cập nhật kỹ thuật mới nhất, cải tiến giao thức và phân tích sau sự cố từ Solana Labs.
• Solana GitHub: mã nguồn turbine: Mã nguồn dành cho các nhà phát triển muốn xem xét trực tiếp cách triển khai của Turbine.
• Thống kê mạng lưới Solana Foundation: Số lượng trình xác thực hiện tại, dữ liệu phân phối stake và các chỉ số sức khỏe mạng lưới.

Bài viết này chỉ dành cho mục đích giáo dục và không cấu thành lời khuyên tài chính hoặc đầu tư. Đầu tư Tiền điện tử tiềm ẩn rủi ro đáng kể. Luôn tự nghiên cứu trước khi đưa ra bất kỳ quyết định đầu tư nào.