Tiêu đề gốc: "Turbine: Block Tuyên truyền trên Solana"

Tác giả gốc: Ryan Chern

Bản tổng hợp gốc: Sharon, BlockBeats

Thông tin về tác giả: Tác giả của bài viết này, Ryan Chern, từng là thực tập sinh kỹ thuật tại Solana và là người đồng sáng lập Phòng thí nghiệm lượng tử. Hiện đang làm việc tại Blackhawk Research, một trung tâm nghiên cứu tiền điện tử.

Tính khả dụng của dữ liệu rất quan trọng đối với blockchain để đảm bảo rằng các nút có thể dễ dàng truy cập tất cả thông tin cần thiết để xác minh, từ đó duy trì tính toàn vẹn và bảo mật của mạng. Tuy nhiên, việc đảm bảo tính sẵn có của dữ liệu trong khi vẫn duy trì mức hiệu suất cao là một thách thức đáng kể, đặc biệt là khi mạng mở rộng quy mô.

Solana đáp ứng thách thức này thông qua một thiết kế kiến ​​trúc độc đáo tạo điều kiện thuận lợi cho việc tạo và nhân rộng các khối liên tục. Điều này đạt được thông qua một số cải tiến quan trọng như lựa chọn người lãnh đạo, Gulf Stream (loại bỏ nhu cầu về mempool) và Turbine (cơ chế lan truyền khối).

Tính liên tục của Solana đòi hỏi một hệ thống hiệu quả để đảm bảo rằng tất cả người xác nhận đều nhận được trạng thái mới nhất một cách kịp thời. Một cách tiếp cận đơn giản là yêu cầu người lãnh đạo truyền trực tiếp tất cả các khối đến mọi người xác thực khác. Tuy nhiên, với thông lượng cao của Solana, phương pháp này sẽ tăng đáng kể băng thông và các yêu cầu tài nguyên khác đồng thời làm suy yếu tính phân cấp.

Băng thông là một nguồn tài nguyên khan hiếm và Turbine là giải pháp khéo léo của Solana để tối ưu hóa việc truyền bá thông tin từ khối dẫn đầu của một khối nhất định đến phần còn lại của mạng. Tua bin được thiết kế đặc biệt để giảm áp lực đầu ra (gửi dữ liệu) từ dây dẫn tới mạng.

Trong bài viết này, chúng ta sẽ xem xét kỹ hơn cách Turbine hoạt động và vai trò chính của nó trong bối cảnh hòa nhập giao dịch rộng hơn của Solana. Chúng tôi cũng sẽ so sánh Turbine với các giải pháp sẵn có dữ liệu khác và thảo luận về các hướng nghiên cứu mở trong lĩnh vực này.

Tua bin là gì?

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

Không giống như các chuỗi khối truyền thống, được gửi tuần tự hoặc theo kiểu tràn ngập đến tất cả các nút, Turbine thực hiện một cách tiếp cận có cấu trúc hơn để giảm thiểu chi phí liên lạc và giảm tải cho từng nút riêng lẻ. Ở cấp độ cao, Turbine chia một đoạn thành các đoạn nhỏ hơn và truyền các đoạn này thông qua hệ thống phân cấp nút. Ở đây, một nút không cần liên lạc với tất cả các nút khác mà chỉ liên lạc với một số nút đã chọn.

Điều này ngày càng trở nên quan trọng khi các mạng phát triển về quy mô, khi các phương pháp truyền bá truyền thống trở nên không bền vững do khối lượng lưu lượng truy cập cần thiết quá lớn. Do đó, Turbine đảm bảo phổ biến dữ liệu nhanh chóng và hiệu quả trong Solana. Tốc độ truyền và xác minh khối là rất quan trọng để 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, đảm bảo rằng tất cả các nút đều có quyền truy cập vào dữ liệu cần thiết để xác minh giao dịch một cách hiệu quả. Điều này được thực hiện mà không cần nhiều băng thông, vốn là điểm nghẽn phổ biến trong các mạng blockchain khác.

Turbine cải thiện đáng kể khả năng của Solana trong việc xử lý khối lượng giao dịch cao và duy trì cấu trúc mạng tinh gọn và hiệu quả bằng cách giảm bớt tắc nghẽn băng thông và đảm bảo truyền khối nhanh. Giao thức đổi mới này là một trong những nền tảng cho lời hứa của Solana về mạng nhanh, an toàn và có thể 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 các khối trên mạng Solana.

Turbine truyền bá các khối như thế nào?

Trước khi truyền bá một khối (tức là truyền nó đến những người xác nhận khác trong mạng), người đứng đầu sẽ xây dựng và ra lệnh cho khối dựa trên luồng giao dịch đến. Khi khối được xây dựng, nó có thể được gửi đến phần còn lại của mạng thông qua Turbine. Quá trình này được gọi là lan truyền khối. 『

Sau đó, thông báo biểu quyết sẽ được chuyển giữa những người xác thực và những thông báo này được gói gọn trong dữ liệu khối để đáp ứng trạng thái cam kết là "đã xác nhận" hoặc "đã hoàn tất". Khối được xác nhận là khối đã nhận được đa số phiếu bầu trong sổ cái, trong khi khối cuối cùng là khối được xác nhận với hơn 31 khối được xác nhận được xây dựng trên đầu khối mục tiêu. Sự khác biệt về trạng thái cam kết được giải thích chi tiết tại đây. Phần đồng thuận này sẽ được thảo luận trong một bài viết trong tương lai.

Trực quan hóa vị trí của Turbine trong vòng đời giao dịch Solana

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

Ở cấp độ cao, Turbine lấy các phân đoạn và gửi chúng đến một bộ trình xác thực được xác định trước, sau đó chuyển tiếp các phân đoạn đến một bộ trình xác thực mới. Sơ đồ dưới đây tóm tắt quá trình lan truyền mảnh vụn liên tục:

Như thể hiện trong hình trên, mặc dù được gọi là "truyền khối" nhưng dữ liệu được truyền ở cấp độ phân đoạn

Trong ví dụ này, trình xác thực 1 là người dẫn đầu vị trí được chỉ định. Trong thời gian của nó (người xác nhận được chỉ định là người dẫn đầu cho 4 vị trí liên tiếp), người xác thực 1 sẽ xây dựng và đề xuất một khối. Trình xác thực 1 trước tiên chia khối thành các khối con được gọi là phân đoạn thông qua một quá trình được gọi là băm nhỏ.

Việc băm nhỏ sẽ chia dữ liệu khối thành các đoạn dữ liệu có kích thước đơn vị truyền tải tối đa (MTU) (lượng dữ liệu lớn nhất có thể được gửi từ nút này sang nút tiếp theo mà không chia thành các đơn vị nhỏ hơn) và được tạo bởi sơ đồ mã hóa đoạn khôi phục tương ứng của Reed-Solomon. . Giải pháp này tạo điều kiện phục hồi dữ liệu và đảm bảo tính toàn vẹn dữ liệu trong quá trình truyền, điều này rất quan trọng để duy trì tính bảo mật và độ tin cậy của mạng.

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

xóa mã hóa

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

Vì về cơ bản, Turbine dựa vào một loạt các lần truyền lại gói từ các trình xác thực xuôi dòng, nên các trình xác thực này có thể độc hại (bằng cách chọn phát lại dữ liệu không chính xác đối với các nút Byzantine hoặc nhận dữ liệu không đầy đủ (mất gói mạng). Do cấu trúc cây truyền lại của Turbine, bất kỳ dữ liệu nào trên toàn mạng đều Việc mất gói phức tạp hơn và xác suất gói không đến được đích sẽ tăng theo mỗi bước nhảy.

Ở mức cao, nếu người dẫn đầu truyền 33% gói của khối dưới dạng mã hóa xóa thì mạng có thể loại bỏ 33% gói bất kỳ mà không làm mất khối. Nhà lãnh đạo có thể tự động điều chỉnh con số này (tốc độ FEC) dựa trên điều kiện mạng, có tính đến các biến số như tình trạng mất gói trên toàn mạng được quan sát gần đây và độ sâu của cây.

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

Ví dụ về nhóm phân mảnh: 4 trong số 8 gói có thể bị giả mạo hoặc bị mất mà không ảnh hưởng đến dữ liệu gốc

Các phân đoạn dữ liệu là các khối một phần của khối ban đầu được tạo bởi người lãnh đạo, trong khi các phân đoạn khôi phục là các khối được mã hóa xóa do Reed-Solomon tạo ra.

Các khối trên Solana thường sử dụng FEC là 32:32 (32 trong số 64 gói có thể bị mất nếu không truyền lại). Như đã nêu trong tài liệu Solana, sau đây là các giả định mạng thận trọng:

· Tỷ lệ mất gói 15%

· 50k TPS tạo ra 6400 phân đoạn mỗi giây

Tỷ lệ FEC là 32:32 mang lại tỷ lệ thành công khối khoảng 99%. Ngoài ra, các nhà lãnh đạo có quyền tăng tỷ lệ FEC nếu họ chọn tăng xác suất thành công của một khối.

Turbine hiện sử dụng UDP để truyền khối, mang lại lợi ích về độ trễ rất lớn. Theo nhà điều hành trình xác thực, việc truyền 6 MB+ dữ liệu được mã hóa xóa từ us-east-1 sang eu-north-1 mất 100 mili giây khi sử dụng UDP so với 900 mili giây khi sử dụng TCP.

Cây tuabin

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

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

1. Tạo danh sách: Nút gốc tổng hợp tất cả các trình xác thực đang hoạt động vào một danh sách và sau đó sắp xếp chúng theo cổ phần của từng trình xác thực trong mạng. Những người xác thực có tỷ trọng cổ phần cao hơn sẽ được ưu tiên cho các phân đoạn nhanh hơn, cho phép họ phản hồi nhanh hơn với thông báo biểu quyết của mình để đạt được sự đồng thuận.

2. Xáo trộn danh sách: Danh sách sau đó được xáo trộn theo cách xác định. Điều này sẽ tạo ra một "Cây tuabin" từ tập hợp các nút xác thực của mỗi phân đoạn bằng cách sử dụng hạt giống có nguồn gốc từ ID lãnh đạo vị trí, vị trí, chỉ mục phân đoạn và loại phân đoạn. Một cây mới được tạo cho mỗi nhóm phân đoạn trong thời gian chạy để 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 lớp: Các nút sau đó được chia thành các lớp bắt đầu từ đầu danh sách. Việc phân vùng dựa trên giá trị DATA_PLane_FANOUT, giá trị này xác định chiều rộng và chiều sâu của cây tuabin. Giá trị này ảnh hưởng đến tốc độ truyền của các đoạn qua mạng. Hiện tại DATA_PLane_FANOUT là 6.

Cây Turbine nổi tiếng đảm bảo rằng mỗi người xác thực biết chính xác nơi họ chịu trách nhiệm chuyển tiếp phân đoạn đó. Giả sử giá trị DATA_PLANE_FANOUT hiện tại là 6, cây Turbine thường là cây 4 hoặc 5 bước nhảy (tùy thuộc vào số lượng trình xác thực đang hoạt động).

Ngoài ra, nếu một nút không có đủ phân mảnh hoặc nếu tỷ lệ mất mát vượt quá tỷ lệ FEC, thì nút đó có thể quay trở lại hoạt động tin đồn và sửa chữa. Theo cách triển khai hiện tại, các nút thiếu đủ phân đoạn để xây dựng lại khối sẽ gửi yêu cầu truyền lại đến nút dẫn đầu. Trong các tuabin xác định, bất kỳ nút nào nhận được khối hoàn chỉnh đều có thể gửi các đoạn sửa chữa mà nút yêu cầu yêu cầu, do đó đẩy quá trình truyền dữ liệu xuống sâu hơn trong cây đến khu vực nơi dữ liệu được yêu cầu.

So sánh việc lan truyền khối giữa Solana và Ethereum

Việc truyền bá khối trên Solana khác với trên Ethereum. Dưới đây là một số khác biệt cấp cao:

1. 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 là do kích thước khối lớn hơn và thời gian khối nhanh hơn của Solana. Solana được thiết kế để sử dụng hiệu quả toàn bộ băng thông nhằm tăng tốc độ truyền dữ liệu, từ đó giảm độ trễ. Mặc dù băng thông đạt đỉnh tới 1 Gbps nhưng 1 Gbps không được sử dụng nhất quán. Kiến trúc của Solana được thiết kế để xử lý nhu cầu băng thông ở mức cao nhất.

2. Solana sử dụng Turbine để truyền dữ liệu khối, trong khi Ethereum sử dụng giao thức tin đồn tiêu chuẩn. Trên Ethereum, việc truyền dữ liệu khối diễn ra theo cách đơn giản: mọi nút giao tiếp với mọi nút đầy đủ khác trong mạng. Khi có một khối mới, khách hàng sẽ xác minh nó bằng cách gửi nó cho các đồng nghiệp của mình và phê duyệt các giao dịch trong khối. Cơ chế này phù hợp với Ethereum vì nó có kích thước khối nhỏ hơn và thời gian tạo khối dài hơn so với Solana. Khi nói đến dữ liệu tổng hợp Ethereum L2 (không bao gồm validium), việc truyền bá cũng tuân theo giao thức tin đồn và dữ liệu khối được lưu trữ trong trường "calldata" của khối Ethereum L1.

3. Ethereum sử dụng TCP (thông qua giao thức DevP2P) để truyền khối, trong khi Solana sử dụng UDP (chuyển sang QUIC với một số hỗ trợ của cộng đồng). Có một số sự cân bằng cần cân nhắc giữa UDP và QUIC:

· Bản chất đơn hướng của UDP dẫn đến độ trễ thấp hơn so với QUIC, do đó cần có luồng QUIC. Các cuộc thảo luận về việc triển khai luồng một chiều vào QUIC đang diễn ra;

· Những người ủng hộ QUIC tuyên bố rằng mặc dù luồng điều khiển tùy chỉnh có thể được thực hiện qua UDP, nhưng nó đòi hỏi nỗ lực kỹ thuật đáng kể, điều mà QUIC giảm bớt bằng cách hỗ trợ chức năng đó ngay từ đầu. Mục tiêu cuối cùng là như nhau, nhưng giới hạn trên về hiệu suất QUIC (độ trễ, thông lượng, v.v.) là trạng thái hiện tại của UDP thuần túy.

Những khác biệt này nêu bật các quyết định kiến ​​trúc độc đáo do Solana và Ethereum đưa ra nhằm giúp cải thiện hiệu suất, khả năng mở rộng và độ mạnh mẽ của mạng tương ứng. Để phân tích sâu hơn về TCP, UDP và QUIC, hãy xem bài viết của chúng tôi về Solana và QUIC.

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

Tuyên truyền khối và tính sẵn có của dữ liệu vẫn là lĩnh vực nghiên cứu mở, với nhiều nhóm phát triển các phương pháp tiếp cận độc đáo của riêng họ. Mặc dù các số liệu có thể tiếp tục phát triển nhưng chúng tôi muốn cung cấp thông tin tổng quan về các phương pháp tiếp cận khác nhau và sự đánh đổi liên quan của chúng:

1. Một số cuộc thảo luận đã nổi lên về Turbine như một cơ chế "dữ liệu sẵn có" (DA). Turbine hoạt động như cơ chế sẵn có của dữ liệu, với toàn bộ dữ liệu khối được xuất bản và tải xuống bởi tất cả các trình xác thực khác trên Solana. Tuy nhiên, Turbine thiếu hỗ trợ Lấy mẫu sẵn có dữ liệu (DAS), một tính năng giúp các nút nhẹ xác minh trạng thái với yêu cầu phần cứng giảm. Đây là trọng tâm phát triển tích cực của các đội như Celestia. Giống như Turbine, DAS sử dụng mã hóa xóa nhưng làm như vậy 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 che giấu dữ liệu.

2. Tubrine mất đi tính liên quan đối với Máy ảo Solana (SVM) L2 (ví dụ: Eclipse) vì không có trình xác thực nào được thiết lập để truyền dữ liệu giữa chúng. Trong trường hợp của Eclipse, dữ liệu khối được xuất bản lên Celestia để cung cấp dữ liệu - điều này cho phép các nhà quan sát bên ngoài chạy bằng chứng gian lận để đảm bảo thực thi chính xác và chuyển đổi trạng thái. Eclipse sẽ là một trong những triển khai đầu tiên của SVM bên ngoài mạng Solana. Pyth cũng phân nhánh SVM cho mạng oracle "Pythnet" của riêng mình và vận hành nó một cách hiệu quả dưới dạng chuỗi bên của riêng mình.

3. Trên Solana, các nút đầy đủ quản lý việc truyền bá khối đồng thời tham gia tích hợp các phần khác của ngăn xếp chuỗi khối, chẳng hạn như thứ tự giao dịch và sự đồng thuận. Nếu Turbine được chạy dưới dạng thành phần mô-đun trên phần cứng chuyên dụng thì số liệu định lượng của nó là gì?

4. Turbine ưu tiên các nút có trọng số cao hơn để nhận dữ liệu khối trước. Liệu điều này có dẫn đến việc tập trung MEV nhiều hơn theo thời gian không?

5. Các phương pháp tiếp cận khác nhau về tính khả dụng của dữ liệu như EigenDA (rơle unicast đơn có thể mở rộng theo chiều ngang) và Celestia (lấy mẫu tính khả dụng của dữ liệu) so sánh với Turbine trong sản xuất về mặt thông lượng thô và giảm thiểu độ tin cậy như thế nào?

6. Firedancer được thiết kế để tăng cường hơn nữa khả năng lan truyền dữ liệu và được tối ưu hóa cho các kết nối băng thông 10 Gbps mạnh mẽ. Việc tối ưu hóa cấp hệ thống xung quanh Turbine sẽ hoạt động như thế nào trong quá trình sản xuất trên phần cứng cấp độ chuyên nghiệp và tiêu dùng?

7. Hiện tại, tất cả các nút trên Solana đều là các nút đầy đủ (việc triển khai ứng dụng khách nhẹ vẫn đang được phát triển). Sreeram Kannan (EigenLayer) gần đây đã mô tả việc triển khai DAS-S trên Turbine. Sẽ có hỗ trợ cho phiên bản DAS cho Turbine không? Có thể triển khai các máy khách hạng nhẹ với DAS để duy trì thông lượng dữ liệu ở mức cao, trong khi các máy khách hạng nhẹ (với yêu cầu tài nguyên thấp hơn nhiều) đáp ứng việc giảm thiểu độ tin cậy không?

Tóm lại là

Chúc mừng! Trong bài viết này, chúng ta xem xét Turbine và cách nó hoạt động trong không gian bao gồm giao dịch rộng hơn của Solana. Chúng tôi so sánh Turbine với các giải pháp sẵn có dữ liệu khác và thảo luận về các hướng nghiên cứu khác nhau mở ra cho 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 được 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ó cấu trúc để truyền bá dữ liệu khối giữa các trình xác thực một cách hiệu quả.

Tìm cách nâng cao tính khả dụng của dữ liệu và tăng hiệu quả truyền bá khối có thể thúc đẩy sự đổi mới trong cộng đồng blockchain rộng lớn hơn. Một phân tích so sánh về cơ chế lan truyền khối của Solana và Ethereum cho thấy những lợi thế và sự đánh đổi tương ứng của chúng, đồng thời truyền cảm hứng cho nhiều nghiên cứ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.

Các giải pháp để phổ biến dữ liệu hiệu quả và sẵn có dữ liệu vẫn chưa hoàn thiện. Tuy nhiên, cách tiếp cận và cam kết mạnh mẽ của Solana trong việc tối ưu hóa hiệu suất mạng mà không ảnh hưởng đến bảo mật và giảm thiểu niềm tin đã được hoan nghênh nồng nhiệt.

Liên kết gốc