Khung Shoal Thả độ trễ Bullshark trên Aptos lên đến 80%

Khung Shoal: Làm thế nào để giảm độ trễ Bullshark trên Aptos?

Tổng quan

Aptos labs đã giải quyết hai vấn đề mở quan trọng trong DAG BFT, giảm đáng kể độ trễ và lần đầu tiên loại bỏ nhu cầu về việc tạm dừng trong các giao thức thực sự xác định. Tổng thể, trong trường hợp không có sự cố, độ trễ của Bullshark đã được cải thiện 40%, và trong trường hợp có sự cố, đã cải thiện 80%.

Shoal là một khung, thông qua pipeline và uy tín của các lãnh đạo để tăng cường bất kỳ giao thức đồng thuận dựa trên Narwhal nào ( như DAG-Rider, Tusk, Bullshark ). Pipeline giảm độ trễ sắp xếp DAG bằng cách giới thiệu một điểm neo trong mỗi vòng, uy tín của lãnh đạo cải thiện thêm vấn đề độ trễ bằng cách đảm bảo điểm neo liên kết với các nút xác thực nhanh nhất. Hơn nữa, uy tín của lãnh đạo cho phép Shoal tận dụng cấu trúc DAG không đồng bộ để loại bỏ tất cả các tình huống vượt thời gian. Điều này cho phép Shoal cung cấp thuộc tính mà chúng tôi gọi là phản hồi phổ quát, nó chứa phản hồi lạc quan thường cần thiết.

Công nghệ này rất đơn giản, nó liên quan đến việc chạy nhiều phiên bản của giao thức cơ sở theo thứ tự, từng cái một. Do đó, khi được khởi tạo bằng Bullshark, chúng ta có một nhóm "cá mập" đang tham gia một cuộc tiếp sức.

Giải thích chi tiết về khung Shoal: Làm thế nào để giảm độ trễ của Bullshark trên Aptos?

Động cơ

Khi theo đuổi hiệu suất cao của mạng blockchain, mọi người luôn chú ý đến việc giảm bớt độ phức tạp của giao tiếp. Tuy nhiên, phương pháp này không dẫn đến sự gia tăng đáng kể về thông lượng. Ví dụ, Hotstuff được triển khai trong các phiên bản đầu tiên của Diem chỉ đạt 3500 TPS, thấp hơn nhiều so với mục tiêu trên 100k TPS.

Sự đột phá gần đây bắt nguồn từ việc nhận ra rằng việc truyền dữ liệu là nút thắt chính dựa trên giao thức của các nhà lãnh đạo, và nó có thể hưởng lợi từ việc song song hóa. Hệ thống Narwhal tách biệt việc truyền dữ liệu với logic đồng thuận cốt lõi, và đề xuất một kiến trúc trong đó tất cả các xác thực viên đồng thời truyền dữ liệu, trong khi thành phần đồng thuận chỉ sắp xếp một lượng nhỏ siêu dữ liệu. Bài báo Narwhal báo cáo khả năng thông lượng 160,000 TPS.

Trước đây đã giới thiệu Quorum Store - Narwhal thực hiện việc tách biệt việc phân phối dữ liệu và đồng thuận, cũng như cách sử dụng nó để mở rộng giao thức đồng thuận hiện tại Jolteon. Jolteon là một giao thức dựa trên lãnh đạo, kết hợp giữa đường dẫn nhanh tuyến tính của Tendermint và thay đổi chế độ nhìn theo phong cách PBFT, có thể giảm độ trễ của Hotstuff xuống 33%. Tuy nhiên, rõ ràng rằng các giao thức đồng thuận dựa trên lãnh đạo không thể tận dụng đầy đủ tiềm năng thông lượng của Narwhal. Mặc dù việc tách biệt phân phối dữ liệu và đồng thuận, nhưng với sự gia tăng thông lượng, lãnh đạo của Hotstuff/Jolteon vẫn bị hạn chế.

Do đó, quyết định triển khai Bullshark, một giao thức đồng thuận không có chi phí giao tiếp, trên Narwhal DAG. Thật không may, so với Jolteon, cấu trúc DAG hỗ trợ Bullshark có thông lượng cao đã mang lại chi phí trễ 50%.

Bài viết này giới thiệu cách Shoal giảm đáng kể độ trễ của Bullshark.

Giải thích chi tiết Shoal Framework: Làm thế nào để giảm độ trễ Bullshark trên Aptos?

Bối cảnh DAG-BFT

Mỗi đỉnh trong Narwhal DAG đều liên quan đến một vòng. Để tham gia vòng thứ r, các xác thực viên phải trước tiên thu thập n-f đỉnh thuộc vòng thứ r-1. Mỗi xác thực viên có thể phát sóng một đỉnh mỗi vòng, và mỗi đỉnh ít nhất phải tham chiếu đến n-f đỉnh của vòng trước. Do tính không đồng bộ của mạng, các xác thực viên khác nhau có thể quan sát các góc nhìn cục bộ khác nhau của DAG tại bất kỳ thời điểm nào.

Một thuộc tính chính của DAG không phải là mơ hồ: nếu hai nút xác minh có cùng đỉnh v trong cái nhìn cục bộ của DAG của chúng, thì chúng có lịch sử nguyên nhân v hoàn toàn giống nhau.

Giải thích chi tiết về khung Shoal: Làm thế nào để giảm độ trễ Bullshark trên Aptos?

Toàn thứ tự

Có thể đạt được sự đồng thuận về thứ tự tổng thể của tất cả các đỉnh trong DAG mà không cần chi phí truyền thông bổ sung. Để làm điều này, các xác thực trong DAG-Rider, Tusk và Bullshark sẽ giải thích cấu trúc của DAG như một giao thức đồng thuận, trong đó các đỉnh đại diện cho các đề xuất, và các cạnh đại diện cho các phiếu bầu.

Mặc dù logic giao thoa nhóm trên cấu trúc DAG khác nhau, nhưng tất cả các giao thức đồng thuận dựa trên Narwhal hiện có đều có cấu trúc như sau:

  1. Điểm neo được đặt trước: cứ sau vài vòng sẽ có một nhà lãnh đạo đã được xác định trước, đỉnh của nhà lãnh đạo được gọi là điểm neo;

  2. Điểm neo sắp xếp: Các xác thực độc lập nhưng một cách chắc chắn quyết định thứ tự của các điểm neo nào và bỏ qua các điểm neo nào;

  3. Lịch sử nguyên nhân theo thứ tự: Các xác thực xử lý danh sách các điểm neo có thứ tự của họ một cách từng cái một, và đối với mỗi điểm neo, họ sắp xếp tất cả các đỉnh trước đó không có thứ tự trong lịch sử nguyên nhân của nó thông qua một số quy tắc xác định.

Chìa khóa để đảm bảo an ninh là đảm bảo rằng trong bước 2, tất cả các nút xác thực trung thực tạo ra một danh sách điểm neo có thứ tự, để tất cả các danh sách chia sẻ cùng một tiền tố. Trong Shoal, có những quan sát sau về tất cả các giao thức nêu trên:

Tất cả các xác thực viên đều đồng ý với điểm neo có thứ tự đầu tiên.

Giải thích chi tiết về khung Shoal: Làm thế nào để giảm độ trễ Bullshark trên Aptos?

Bullshark trì hoãn

Độ trễ của Bullshark phụ thuộc vào số vòng giữa các điểm neo có thứ tự trong DAG. Mặc dù phiên bản đồng bộ của Bullshark thực tế hơn có độ trễ tốt hơn so với phiên bản bất đồng bộ, nhưng nó vẫn còn xa mới đạt được tối ưu.

Câu hỏi 1: Độ trễ khối trung bình. Trong Bullshark, mỗi vòng chẵn có một điểm neo, và mỗi đỉnh của vòng lẻ được hiểu là một phiếu bầu. Trong trường hợp thông thường, cần hai vòng DAG để sắp xếp các điểm neo, tuy nhiên, các đỉnh trong lịch sử nguyên nhân của điểm neo cần nhiều vòng hơn để chờ các điểm neo được sắp xếp. Trong trường hợp thông thường, các đỉnh trong vòng lẻ cần ba vòng, trong khi các đỉnh không phải điểm neo trong vòng chẵn cần bốn vòng.

Câu hỏi 2: Trường hợp lỗi bị trì hoãn, phân tích trì hoãn nêu trên áp dụng cho trường hợp không có lỗi, mặt khác, nếu nhà lãnh đạo trong một vòng không truyền đạt điểm neo đủ nhanh, thì không thể sắp xếp điểm neo ( do đó bị bỏ qua ), vì vậy tất cả các đỉnh chưa được sắp xếp trong những vòng trước phải chờ đợi điểm neo tiếp theo được sắp xếp. Điều này sẽ giảm đáng kể hiệu suất của mạng sao chép địa lý, đặc biệt là vì thời gian chờ của Bullshark được sử dụng để chờ nhà lãnh đạo.

Giải thích chi tiết về khung Shoal: Làm thế nào để giảm độ trễ Bullshark trên Aptos?

Khung Shoal

Shoal đã giải quyết hai vấn đề độ trễ này, nó đã tăng cường Bullshark( hoặc bất kỳ giao thức BFT nào dựa trên Narwhal) thông qua việc sử dụng pipeline, cho phép có một điểm neo trong mỗi vòng, và giảm độ trễ của tất cả các đỉnh không phải điểm neo trong DAG xuống còn ba vòng. Shoal cũng đã giới thiệu cơ chế danh tiếng lãnh đạo không tốn kém trong DAG, điều này khiến cho việc lựa chọn nghiêng về các lãnh đạo nhanh chóng.

Thách thức

Trong bối cảnh giao thức DAG, vấn đề về quy trình và uy tín của người lãnh đạo được coi là khó khăn, lý do như sau:

  1. Dây chuyền sản xuất trước đây đã cố gắng sửa đổi logic Bullshark cốt lõi, nhưng về bản chất điều này dường như là không thể.

  2. Danh tiếng của người lãnh đạo được đưa vào DiemBFT và chính thức hóa trong Carousel, là việc lựa chọn người lãnh đạo tương lai một cách linh hoạt dựa trên hiệu suất trong quá khứ của các xác thực viên trong Bullshark, nơi có những mỏ neo (. Mặc dù sự khác biệt về danh tính lãnh đạo không vi phạm tính bảo mật trong các giao thức này, nhưng trong Bullshark, điều này có thể dẫn đến thứ tự hoàn toàn khác nhau, điều này dẫn đến cốt lõi của vấn đề, đó là việc lựa chọn mỏ neo vòng một cách động và xác định là cần thiết để giải quyết sự đồng thuận, trong khi các xác thực viên cần đạt được sự đồng thuận về lịch sử có thứ tự để chọn mỏ neo trong tương lai.

Là bằng chứng về độ khó của vấn đề, việc thực hiện của Bullshark, bao gồm cả việc thực hiện hiện tại trong môi trường sản xuất, không hỗ trợ những tính năng này.

![Giải thích chi tiết Shoal framework: Làm thế nào để giảm độ trễ Bullshark trên Aptos?])https://img-cdn.gateio.im/webp-social/moments-859e732e16c3eee0e2c93422474debc2.webp(

Thỏa thuận

Mặc dù có những thách thức trên, nhưng giải pháp lại ẩn chứa phía sau sự đơn giản.

Trong Shoal, nhờ vào khả năng thực hiện tính toán cục bộ dựa trên DAG và khả năng lưu trữ và giải thích lại thông tin từ các vòng trước. Với sự đồng thuận của tất cả các nhà xác thực về cái nhìn cốt lõi của điểm neo có thứ tự đầu tiên, Shoal kết hợp tuần tự nhiều phiên bản Bullshark để xử lý chúng theo luồng, khiến cho ) điểm neo có thứ tự đầu tiên là điểm chuyển đổi của các phiên bản, cũng như ( lịch sử nguyên nhân của điểm neo được sử dụng để tính toán danh tiếng của người lãnh đạo.

Dây chuyền sản xuất

V ánh xạ vòng đến người lãnh đạo. Shoal lần lượt chạy các phiên bản của Bullshark, do đó đối với mỗi phiên bản, điểm neo được xác định trước bởi ánh xạ F. Mỗi phiên bản đặt hàng một điểm neo, điều này sẽ kích hoạt chuyển sang phiên bản tiếp theo.

Ban đầu, Shoal đã khởi động phiên bản đầu tiên của Bullshark trong vòng đầu tiên của DAG và chạy nó cho đến khi xác định được điểm neo có thứ tự đầu tiên, chẳng hạn như trong vòng r. Tất cả các xác thực viên đều đồng ý với điểm neo này. Do đó, tất cả các xác thực viên đều có thể đồng ý một cách chắc chắn để bắt đầu giải thích lại DAG từ vòng r+1. Shoal chỉ khởi động một phiên bản Bullshark mới trong vòng r+1.

Trong trường hợp tốt nhất, điều này cho phép Shoal đặt một mỏ neo trong mỗi vòng. Điểm neo trong vòng đầu tiên được sắp xếp theo thể thức của trường hợp đầu tiên. Sau đó, Shoal bắt đầu một trường hợp mới trong vòng thứ hai, nó có một điểm neo, và điểm neo đó được sắp xếp theo trường hợp đó, sau đó, một trường hợp mới khác đặt điểm neo trong vòng thứ ba, và quá trình này tiếp tục.

![Giải thích chi tiết về khung Shoal: Làm thế nào để giảm độ trễ Bullshark trên Aptos?])https://img-cdn.gateio.im/webp-social/moments-9f789cb669f6fcc244ea7ff7648e48b4.webp(

Danh tiếng lãnh đạo

Trong quá trình sắp xếp Bullshark, việc bỏ qua các điểm neo sẽ làm tăng độ trễ. Trong trường hợp này, công nghệ đường ống không phát huy tác dụng, vì không thể khởi động một phiên bản mới trước khi đặt hàng điểm neo của phiên bản trước đó. Shoal đảm bảo rằng các nhà lãnh đạo liên quan ít có khả năng được chọn trong tương lai bằng cách sử dụng cơ chế tín nhiệm để phân bổ điểm số cho mỗi nút xác thực dựa trên lịch sử hoạt động gần đây của chúng. Các nhà xác thực phản hồi và tham gia vào giao thức sẽ nhận được điểm số cao, ngược lại, các nút xác thực sẽ được phân bổ điểm số thấp, vì chúng có thể gặp sự cố, chậm chạp hoặc có hành vi xấu.

Ý tưởng của nó là tính toán lại ánh xạ F đã được định nghĩa trước từ vòng đến người lãnh đạo một cách chắc chắn mỗi khi điểm số được cập nhật, nghiêng về người lãnh đạo có điểm số cao hơn. Để các xác thực đồng thuận trên ánh xạ mới, họ cần đạt được sự đồng thuận về điểm số, từ đó đạt được sự đồng thuận trong lịch sử được sử dụng để suy ra điểm số.

Trong Shoal, quy trình và uy tín lãnh đạo có thể kết hợp tự nhiên, vì chúng đều sử dụng cùng một công nghệ cốt lõi, tức là diễn giải lại DAG sau khi đạt được sự đồng thuận về điểm neo thứ nhất.

Trên thực tế, sự khác biệt duy nhất là, sau khi sắp xếp các điểm neo trong vòng r, các xác thực chỉ cần tính toán ánh xạ mới F' từ vòng r+1 dựa trên lịch sử nguyên nhân của các điểm neo đã sắp xếp trong vòng r. Sau đó, các nút xác thực từ vòng r+1 sẽ thực hiện một phiên bản mới của Bullshark bằng cách sử dụng hàm chọn điểm neo cập nhật F'.

![Giải thích chi tiết Shoal framework: Làm thế nào để giảm độ trễ Bullshark trên Aptos?])https://img-cdn.gateio.im/webp-social/moments-1baf540693f376d93cb18ef3193593cc.webp(

Không còn thời gian tối đa

Thời gian vượt quá đóng vai trò rất quan trọng trong tất cả các triển khai BFT đồng bộ dựa trên lãnh đạo. Tuy nhiên, sự phức tạp mà chúng mang lại đã làm tăng số lượng trạng thái nội bộ cần quản lý và quan sát, điều này làm tăng độ phức tạp của quá trình gỡ lỗi và cần nhiều kỹ thuật quan sát hơn.

Thời gian chờ cũng sẽ làm tăng độ trễ một cách đáng kể, vì việc cấu hình chúng một cách thích hợp là rất quan trọng và thường cần phải điều chỉnh động, vì nó phụ thuộc rất nhiều vào môi trường ) mạng (. Trước khi chuyển sang nhà lãnh đạo tiếp theo, giao thức này

Xem bản gốc
This page may contain third-party content, which is provided for information purposes only (not representations/warranties) and should not be considered as an endorsement of its views by Gate, nor as financial or professional advice. See Disclaimer for details.
  • Phần thưởng
  • 9
  • Chia sẻ
Bình luận
0/400
OptionWhisperervip
· 07-11 02:28
Aptos chơi thật mượt, đợt này thao tác ổn định.
Xem bản gốcTrả lời0
OffchainWinnervip
· 07-10 09:26
Mạnh quá, aptos còn có thể chơi như vậy.
Xem bản gốcTrả lời0
AirdropSweaterFanvip
· 07-09 08:34
Trễ đều đã bị loại bỏ rồi, cái gì mà ác liệt vậy?
Xem bản gốcTrả lời0
ZeroRushCaptainvip
· 07-08 09:08
Tốc độ tăng lên thì có làm sao, dù sao tôi cũng mất tiền nhanh như vậy.
Xem bản gốcTrả lời0
LeekCuttervip
· 07-08 09:05
Đợt này không biết gì cả, chỉ biết là bull là xong.
Xem bản gốcTrả lời0
GateUser-1a2ed0b9vip
· 07-08 09:02
shoal不错哦 Trễ giảm nhiều như vậy
Xem bản gốcTrả lời0
HodlNerdvip
· 07-08 08:59
hmm, cuối cùng cũng có một số ý nghĩa thống kê thực sự trong tối ưu hóa giao thức... giảm 80% Trễ của bullshark là vẻ đẹp toán học thuần khiết không nói dối
Xem bản gốcTrả lời0
JustHereForAirdropsvip
· 07-08 08:51
Trễ thả thật tuyệt, bò lớn đã đến.
Xem bản gốcTrả lời0
WalletWhisperervip
· 07-08 08:46
Tốc độ To da moon tuyệt vời了
Xem bản gốcTrả lời0
Xem thêm
  • Ghim
Giao dịch tiền điện tử mọi lúc mọi nơi
qrCode
Quét để tải xuống ứng dụng Gate
Cộng đồng
Tiếng Việt
  • 简体中文
  • English
  • Tiếng Việt
  • 繁體中文
  • Español
  • Русский
  • Français (Afrique)
  • Português (Portugal)
  • Bahasa Indonesia
  • 日本語
  • بالعربية
  • Українська
  • Português (Brasil)