Turbine: Truyền bá block trên Solana

Bài viết này nói về điều gì?

Tính khả dụng của dữ liệu đóng vai trò thiết yếu đối với blockchain. Nó bảo đảm mọi thông tin cần thiết luôn sẵn có để các node xác thực, qua đó duy trì tính toàn vẹn và bảo mật của mạng. Tuy nhiên, bảo đảm tính khả dụng của dữ liệu trong khi vẫn duy trì hiệu năng cao là một thách thức lớn, đặc biệt khi mạng mở rộng quy mô.

Solana giải quyết thách thức này bằng một thiết kế kiến trúc độc đáo, hỗ trợ việc liên tục tạo và truyền bá block. Điều này trở thành hiện thực nhờ một số cải tiến quan trọng như lựa chọn leader, Gulf Stream (loại bỏ nhu cầu về mempool) và Turbine (cơ chế truyền bá block).

Đặc tính hoạt động liên tục của Solana đòi hỏi một hệ thống hiệu quả để bảo đảm mọi trình xác thực nhanh chóng nhận được trạng thái mới nhất. Theo cách tiếp cận đơn giản, leader sẽ truyền trực tiếp mọi block đến tất cả trình xác thực khác. Tuy nhiên, do Solana có thông lượng cao, phương pháp này sẽ làm tăng đáng kể yêu cầu về băng thông và các tài nguyên khác, đồng thời làm suy yếu tính phi tập trung.

Băng thông là một tài nguyên khan hiếm và Turbine là giải pháp sáng tạo của Solana để tối ưu hóa việc truyền bá thông tin từ leader của một block nhất định đến phần còn lại của mạng. Turbine được thiết kế riêng để giảm tải cho lưu lượng đi ra (gửi dữ liệu ra ngoài) từ leader đến mạng.

Trong bài viết này, chúng ta sẽ tìm hiểu sâu về cách Turbine hoạt động cũng như vai trò then chốt của nó trong bức tranh tổng thể về việc đưa transaction vào Solana. Chúng ta cũng sẽ so sánh Turbine với các giải pháp về tính khả dụng của dữ liệu khác và thảo luận những hướng nghiên cứu còn bỏ ngỏ trong lĩnh vực này.

Turbine là gì?

Turbine là cơ chế truyền bá block đa tầng được một cụm Solana sử dụng để phát các mục trong sổ cái đến mọi node. Những ý tưởng cốt lõi đằng sau Turbine đã được giới học thuật quan tâm từ nhiều năm, thể hiện qua bài báo xuất bản vào năm 2004 cũng như các công trình gần đây hơn.

Khác với các blockchain truyền thống, nơi một block được gửi tuần tự đến tất cả node hoặc phát tràn lan, Turbine áp dụng cách tiếp cận có cấu trúc hơn để giảm thiểu chi phí giao tiếp và giảm tải cho từng node. Ở cấp độ tổng quan, Turbine chia một block thành các phần nhỏ hơn rồi phân phối chúng thông qua hệ thống phân cấp các node. Theo đó, một node riêng lẻ không cần kết nối với mọi node khác mà chỉ phải giao tiếp với một số node được chọn. Điều này càng trở nên quan trọng khi quy mô mạng tăng lên, vì các phương pháp truyền bá truyền thống sẽ không còn khả thi do khối lượng giao tiếp cần thiết quá lớn. Nhờ vậy, Turbine bảo đảm dữ liệu được phân phối nhanh chóng và hiệu quả trên Solana. Tốc độ truyền bá và xác minh block đóng vai trò thiết yếu trong việc duy trì thông lượng cao và bảo mật mạng của Solana.

Ngoài ra, Turbine giải quyết vấn đề về tính khả dụng của dữ liệu, bảo đảm mọi node có thể truy cập dữ liệu cần thiết để xác thực transaction một cách hiệu quả. Quá trình này không đòi hỏi lượng băng thông khổng lồ, vốn là một điểm nghẽn phổ biến ở các mạng blockchain khác.

Bằng cách giảm điểm nghẽn băng thông và bảo đảm truyền bá block nhanh chóng, Turbine góp phần đáng kể vào khả năng xử lý khối lượng transaction lớn của Solana, đồng thời duy trì cấu trúc mạng tinh gọn và hiệu quả. Giao thức đổi mới này là một trong những nền tảng giúp Solana hiện thực hóa cam kết trở thành một mạng nhanh, an toàn và có khả năng mở rộng.

Bây giờ, hãy cùng tìm hiểu sâu hơn về cơ chế của Turbine và cách nó truyền bá block trên mạng Solana.

Turbine truyền bá block như thế nào?

Trước khi một block được truyền bá (tức là truyền đến các trình xác thực khác trong mạng), leader sẽ xây dựng và sắp xếp block dựa trên luồng transaction đến. Sau khi được xây dựng, block sẵn sàng được gửi qua Turbine đến phần còn lại của mạng. Quá trình này được gọi là truyền bá block. Sau đó, các thông điệp bỏ phiếu được truyền giữa những trình xác thực và được đóng gói trong dữ liệu block để đáp ứng trạng thái cam kết “confirmed” hoặc “finalized”. Một block đã được xác nhận là block đã nhận được phiếu bầu từ đại đa số sổ cái, còn block đã hoàn tất là block đã được xác nhận và có hơn 31 block đã xác nhận được xây dựng bên trên block mục tiêu. Sự khác biệt giữa các trạng thái cam kết được giải thích chi tiết hơn tại đây. Phần này của cơ chế đồng thuận sẽ được trình bày trong một bài viết sau.

Trong khi leader xây dựng và đề xuất toàn bộ block, dữ liệu thực tế được gửi dưới dạng shred (các phần của block) đến những trình xác thực khác trong mạng. Shred là đơn vị nguyên tử được gửi giữa các trình xác thực.

Ở cấp độ tổng quan, Turbine nhận các shred và gửi chúng đến một tập hợp trình xác thực được xác định trước. Sau đó, những trình xác thực này chuyển tiếp các shred đó đến một tập hợp trình xác thực mới. Sơ đồ sau mô tả quá trình truyền bá shred liên tục:

Trong ví dụ này, Trình xác thực 1 là leader được chỉ định cho slot. Trong slot của mình (các trình xác thực được chỉ định làm leader trong 4 slot liên tiếp), Trình xác thực 1 xây dựng và đề xuất một block. Trình xác thực 1 trước tiên chia block thành các block con gọi là shred thông qua quy trình gọi là shredding. Shredding chia dữ liệu block thành các shred dữ liệu có kích thước bằng Đơn vị Truyền Tối đa (MTU) (lượng dữ liệu tối đa có thể được gửi từ node này sang node tiếp theo mà không cần phân mảnh thành các đơn vị nhỏ hơn), đồng thời tạo các shred khôi phục tương ứng bằng phương pháp mã xóa Reed-Solomon. Phương pháp này hỗ trợ khôi phục dữ liệu và bảo đảm tính toàn vẹn của dữ liệu trong quá trình truyền, yếu tố thiết yếu để duy trì tính bảo mật và độ tin cậy của mạng.

Quá trình shredding và truyền bá này bảo đảm dữ liệu block được phân phối nhanh chóng và hiệu quả trên Solana, qua đó duy trì thông lượng cao và bảo mật mạng.

Mã xóa

Trước khi các shred được truyền bá qua Cây Turbine, chúng được mã hóa bằng mã xóa Reed-Solomon, một phương pháp phát hiện và sửa lỗi dựa trên đa thức. Mã xóa được sử dụng như một phương pháp bảo vệ dữ liệu để có thể khôi phục dữ liệu gốc ngay cả khi một số phần bị mất hoặc hỏng trong quá trình truyền. Mã xóa Reed-Solomon là một loại thuật toán Sửa lỗi Chuyển tiếp (FEC) cụ thể.

Do Turbine về cơ bản phụ thuộc vào một chuỗi lần truyền lại gói tin bởi các trình xác thực ở hạ nguồn, những trình xác thực đó có thể hành động ác ý (các node Byzantine đối nghịch) bằng cách phát lại dữ liệu không chính xác hoặc nhận dữ liệu không đầy đủ (mất gói tin mạng). Do cấu trúc cây truyền lại của Turbine, mọi tình trạng mất gói tin trên toàn mạng đều bị khuếch đại và xác suất gói tin không đến được đích tăng lên sau mỗi chặng.

Ở cấp độ tổng quan, nếu leader truyền 33% số gói tin của block dưới dạng mã xóa, mạng có thể làm mất 33% số gói tin bất kỳ mà không làm mất block. Leader có thể linh hoạt điều chỉnh con số này (tỷ lệ FEC) dựa trên điều kiện mạng bằng cách tính đến các biến như tỷ lệ mất gói tin quan sát được gần đây trên toàn mạng và độ sâu của cây.

Để đơn giản, hãy xem xét một nhóm shred có tỷ lệ FEC là 4:4.

Các shred dữ liệu là những phần của block gốc do leader xây dựng, còn các shred khôi phục là các block mã xóa được tạo bằng Reed-Solomon.

Các block trên Solana thường sử dụng FEC 32:32 (có thể mất 32 trong số 64 gói tin mà không cần truyền lại). Theo mô tả trong tài liệu Solana, các giả định thận trọng về mạng bao gồm:

• Tỷ lệ mất gói tin là 15%
• 50 nghìn TPS tạo ra 6.400 shred mỗi giây

Tỷ lệ FEC 32:32 mang lại tỷ lệ thành công của block là ~99%. Ngoài ra, leader có thể tăng tỷ lệ FEC nếu muốn nâng cao xác suất block thành công.

Turbine hiện sử dụng UDP để truyền bá block, mang lại lợi ích rất lớn về độ trễ. Theo một đơn vị vận hành trình xác thực, việc truyền 6 MB dữ liệu cùng dữ liệu mã xóa từ us-east-1 đến eu-north-1 bằng UDP mất 100ms, trong khi TCP mất 900ms.

Cây Turbine

Cây Turbine là một cấu trúc liên kết mạng có tổ chức được Solana sử dụng để hỗ trợ truyền bá hiệu quả các shred (dữ liệu block đã mã hóa) giữa những trình xác thực. Sau khi các shred được mã hóa đúng cách thành những nhóm shred tương ứng, chúng sẵn sàng được phân phối qua Cây Turbine để thông báo trạng thái mới nhất cho các trình xác thực khác trong mạng.

Mỗi nhóm shred được gửi qua một gói tin mạng đến một node gốc đặc biệt. Node này quản lý những trình xác thực thuộc tầng đầu tiên (cách 1 chặng). Sau đó, các bước sau được thực hiện:

1. Tạo danh sách: Node gốc tổng hợp tất cả trình xác thực đang hoạt động vào một danh sách, sau đó sắp xếp dựa trên lượng stake mà mỗi trình xác thực nắm giữ trong mạng. Các trình xác thực có trọng số stake cao hơn được ưu tiên nhận shred sớm hơn, cho phép họ phản hồi nhanh hơn bằng thông điệp bỏ phiếu của chính mình để phục vụ cơ chế đồng thuận.
2. Xáo trộn danh sách: Danh sách này sau đó được xáo trộn theo cách tất định. Quá trình này tạo ra một “Cây Turbine” từ tập hợp các node trình xác thực cho mỗi shred, sử dụng seed được lấy từ ID của leader slot, slot, chỉ mục shred và loại shred. Một cây mới được tạo trong thời gian chạy cho mỗi nhóm shred nhằm giảm thiểu rủi ro bảo mật tiềm ẩn liên quan đến cấu trúc cây tĩnh.
3. Hình thành tầng: Các node sau đó được chia thành nhiều tầng, bắt đầu từ đầu danh sách. Việc phân chia dựa trên giá trị DATA_PLANE_FANOUT, yếu tố quyết định chiều rộng và chiều sâu của Cây Turbine. Giá trị này ảnh hưởng đến tốc độ truyền bá shred qua mạng. DATA_PLANE_FANOUT hiện là 200, vì vậy hầu hết trình xác thực chỉ cách 2–3 chặng (leader -> root -> L1 -> L2).

Vì mọi bên đều biết Cây Turbine, mỗi trình xác thực biết chính xác vị trí mà mình chịu trách nhiệm chuyển tiếp shred đó. Cây Turbine thường là cây có 2 hoặc 3 chặng (tùy thuộc vào số lượng trình xác thực đang hoạt động), với giá trị DATA_PLANE_FANOUT hiện tại là 200.

Ngoài ra, các node có thể chuyển sang gossip và repair nếu không nhận đủ shred hoặc nếu tỷ lệ mất vượt quá tỷ lệ FEC. Trong cách triển khai hiện tại, một node không có đủ shred để tái tạo block sẽ gửi yêu cầu đến leader để truyền lại. Với Turbine tất định, bất kỳ node nào đã nhận toàn bộ block đều có thể gửi các shred sửa chữa mà node yêu cầu cần, qua đó đẩy việc truyền dữ liệu xuống sâu hơn đến những khu vực đang yêu cầu dữ liệu trong cây.

So sánh cơ chế truyền bá block giữa Solana và Ethereum

Cơ chế truyền bá block trên Solana khác với Ethereum. Dưới đây là một số khác biệt tổng quan:

• Yêu cầu băng thông lý tưởng của Solana (>1 Gbps) cao hơn đáng kể so với Ethereum (geth khuyến nghị >25 Mbps). Yêu cầu băng thông cao hơn này xuất phát từ kích thước block lớn hơn và thời gian tạo block nhanh hơn của Solana. Thiết kế của Solana cho phép sử dụng hiệu quả toàn bộ băng thông để tăng tốc truyền dữ liệu, qua đó giảm độ trễ. Mặc dù băng thông có thể tăng vọt đến 1 Gbps, hệ thống không liên tục sử dụng 1 Gbps. Kiến trúc của Solana được thiết kế riêng để đáp ứng các đợt tăng vọt về nhu cầu băng thông.
• Solana sử dụng Turbine để truyền bá dữ liệu block, trong khi Ethereum sử dụng giao thức gossip tiêu chuẩn. Trên Ethereum, việc truyền bá dữ liệu block được thực hiện theo cách đơn giản: mỗi node giao tiếp với mọi full node khác trong mạng. Khi có block mới, các client sẽ xác minh block đó bằng cách gửi đến các peer và phê duyệt những transaction có trong block. Cơ chế này phù hợp với Ethereum vì kích thước block nhỏ hơn và thời gian tạo block dài hơn so với Solana. Đối với dữ liệu rollup L2 của Ethereum (không bao gồm validium), quá trình truyền bá cũng tuân theo giao thức gossip, với dữ liệu block được lưu trong trường “calldata” của các block Ethereum L1.
• Ethereum sử dụng TCP (thông qua giao thức DevP2P) để truyền bá block, trong khi Solana sử dụng UDP (với một số sự ủng hộ từ cộng đồng dành cho việc chuyển sang QUIC). Có một số đánh đổi cần cân nhắc giữa UDP và QUIC:
• Đặc tính một chiều của UDP mang lại độ trễ thấp hơn so với QUIC, vốn cần các stream QUIC. Các cuộc thảo luận về việc triển khai stream một chiều trong QUIC vẫn đang diễn ra.
• Những người ủng hộ QUIC cho rằng mặc dù có thể xây dựng luồng điều khiển tùy chỉnh trên UDP, việc này đòi hỏi công sức kỹ thuật đáng kể, trong khi QUIC giảm bớt gánh nặng đó nhờ hỗ trợ sẵn các tính năng này. Mục tiêu cuối cùng là như nhau, nhưng giới hạn trên về hiệu năng của QUIC (độ trễ, thông lượng, v.v.) hiện chỉ tương đương trạng thái hiện tại của UDP thuần túy.

Những khác biệt này làm nổi bật các quyết định kiến trúc riêng của Solana và Ethereum, góp phần tạo nên hiệu năng, khả năng mở rộng và độ bền vững mạng của từng nền tảng. Để xem phân tích chuyên sâu hơn về TCP, UDP và QUIC, hãy đọc bài viết của chúng tôi về Solana và QUIC.

Các câu hỏi nghiên cứu trong tương lai

Truyền bá block và tính khả dụng của dữ liệu vẫn là những lĩnh vực nghiên cứu mở, với nhiều nhóm đang xây dựng các cách tiếp cận riêng. Mặc dù các chỉ số có thể thay đổi, chúng tôi muốn cung cấp cái nhìn tổng quan về các cách tiếp cận khác nhau và những đánh đổi liên quan:

• Một số cuộc thảo luận đã đề cập đến vị thế của Turbine như một cơ chế “tính khả dụng của dữ liệu” (DA). Turbine đóng vai trò là cơ chế bảo đảm tính khả dụng của dữ liệu theo nghĩa toàn bộ dữ liệu block được công bố và tải xuống bởi tất cả trình xác thực khác trên Solana. Tuy nhiên, Turbine không hỗ trợ lấy mẫu tính khả dụng của dữ liệu (DAS), một tính năng giúp các node nhẹ xác minh trạng thái với yêu cầu phần cứng thấp hơn. Đây là trọng tâm phát triển tích cực của các nhóm như Celestia. Giống Turbine, DAS cũng sử dụng mã xóa, nhưng với mục đích rõ ràng là phát hiện và ngăn chặn các cuộc tấn công giữ lại dữ liệu.
• Đối với các L2 Solana Virtual Machine (SVM) như Eclipse, Turbine không còn nhiều ý nghĩa vì không có tập hợp trình xác thực để truyền dữ liệu qua lại. Trong trường hợp của Eclipse, dữ liệu block được công bố lên Celestia để bảo đảm tính khả dụng của dữ liệu – điều này cho phép các bên quan sát bên ngoài chạy bằng chứng gian lận để bảo đảm việc thực thi và chuyển đổi trạng thái là chính xác. Eclipse sẽ là một trong những cách triển khai SVM đầu tiên bên ngoài chính mạng Solana. Pyth cũng đã fork SVM cho mạng oracle riêng có tên “Pythnet” và trên thực tế vận hành như một sidechain riêng.
• Trên Solana, các full node quản lý việc truyền bá block, đồng thời tham gia vào những phần khác của ngăn xếp blockchain tích hợp như sắp xếp transaction và đồng thuận. Các chỉ số định lượng của Turbine sẽ như thế nào nếu nó được vận hành như một thành phần mô-đun trên phần cứng chuyên dụng?
• Turbine ưu tiên các node có trọng số stake cao hơn để nhận dữ liệu block trước. Liệu điều này có dẫn đến việc MEV ngày càng tập trung theo thời gian không?
• Khi triển khai thực tế, các cách tiếp cận khác nhau đối với tính khả dụng của dữ liệu như EigenDA (bộ chuyển tiếp unicast đơn có khả năng mở rộng theo chiều ngang) và Celestia (lấy mẫu tính khả dụng của dữ liệu) sẽ so sánh với Turbine như thế nào về thông lượng thô và giảm thiểu yêu cầu đặt niềm tin?
• Firedancer hướng đến việc tiếp tục tăng khả năng truyền bá dữ liệu và được tối ưu hóa cho kết nối băng thông ổn định 10 Gbps. Các tối ưu hóa cấp hệ thống mà họ đã thực hiện quanh Turbine sẽ hoạt động như thế nào trong môi trường production trên cả phần cứng phổ thông lẫn phần cứng chuyên nghiệp?
• Hiện tại, mọi node trên Solana đều là full node (các cách triển khai client nhẹ vẫn đang được phát triển). Gần đây, Sreeram Kannan (EigenLayer) đã mô tả một cách triển khai DAS-S trên Turbine. Liệu Turbine có hỗ trợ một phiên bản DAS không? Có thể triển khai client nhẹ với DAS để duy trì thông lượng dữ liệu cao, đồng thời cho phép client nhẹ (với yêu cầu tài nguyên thấp hơn nhiều) đáp ứng mục tiêu giảm thiểu yêu cầu đặt niềm tin không?

Kết luận

Chúc mừng bạn! Trong bài viết này, chúng ta đã tìm hiểu Turbine và cách nó hoạt động trong bức tranh tổng thể về việc đưa transaction vào Solana. Chúng ta đã so sánh Turbine với các giải pháp về tính khả dụng của dữ liệu khác và thảo luận những hướng nghiên cứu còn bỏ ngỏ trong lĩnh vực này. Giao thức Turbine của Solana thể hiện cam kết của mạng trong việc đạt thông lượng cao và độ trễ thấp bằng cách tận dụng cấu trúc liên kết mạng có tổ chức để phân phối hiệu quả dữ liệu block giữa các trình xác thực.

Nỗ lực tìm kiếm những cách cải thiện tính khả dụng của dữ liệu và nâng cao hiệu quả truyền bá block đang thúc đẩy đổi mới trong cộng đồng blockchain nói chung. Phân tích so sánh các cơ chế truyền bá block của Solana và Ethereum làm rõ thế mạnh và những đánh đổi riêng của từng nền tảng, đồng thời khơi mở cuộc thảo luận sâu hơn về cách các giải pháp blockchain mới nổi như EigenDA, Celestia và Firedancer có thể định hình hệ sinh thái này trong tương lai.

Giải pháp cho việc truyền bá dữ liệu hiệu quả và bảo đảm tính khả dụng của dữ liệu vẫn còn lâu mới hoàn thiện. Tuy nhiên, cách tiếp cận của Solana cùng cam kết vững chắc trong việc tối ưu hóa hiệu năng mạng mà không đánh đổi tính bảo mật và mục tiêu giảm thiểu yêu cầu đặt niềm tin là điều rất đáng hoan nghênh.

Cảm ơn @dubbel06 và @jon_charb đã đánh giá và đóng góp ý kiến.

Tài nguyên bổ sung / Đọc thêm

• Cơ chế truyền bá block của Turbine
• Tìm hiểu về mã xóa
• Các block Ethereum
• Bản nâng cấp mạng Pyth Perseus
• Giới thiệu EigenDA: Tính khả dụng của dữ liệu siêu quy mô cho rollup
• Firedancer