Aptos Labs đã giải quyết hai vấn đề mở quan trọng trong DAG BFT, thả đáng kể trễ, và lần đầu tiên loại bỏ nhu cầu về thời gian chờ trong giao thức thực sự xác định. Tổng thể, trong trường hợp không có lỗi, đã cải thiện trễ của Bullshark 40%, trong trường hợp có lỗi đã cải thiện 80%.
Shoal là một khung, thông qua pipeline và uy tín của người lãnh đạo để tăng cường bất kỳ giao thức đồng thuận nào dựa trên Narwhal ( như DAG-Rider, Tusk, Bullshark ). Pipeline giảm thiểu độ trễ sắp xếp DAG bằng cách giới thiệu các điểm neo trong mỗi vòng, trong khi uy tín của người lãnh đạo cải thiện thêm vấn đề độ trễ bằng cách đảm bảo rằng các đ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 người lãnh đạo cho phép Shoal tận dụng cấu trúc DAG bất đồng bộ để loại bỏ thời gian chờ trong tất cả các trường hợp. Điều này cho phép Shoal cung cấp thuộc tính phản hồi phổ quát, bao gồm cả phản hồi lạc quan thường cần thiết.
Công nghệ này rất đơn giả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ự. Vì vậy, khi chúng ta khởi tạo Bullshark, chúng ta có một nhóm "cá mập" đang tham gia vào một cuộc tiếp sức.
Bối cảnh
Trong việc theo đuổi hiệu suất cao của mạng blockchain, mọi người luôn chú ý đến việc Thả độ phức tạp 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 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 100k+ TPS.
Độ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 lãnh đạo, 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, đề xuất tất cả các xác thực viên truyền dữ liệu cùng một lúc, 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.
Quorum Store được giới thiệu trước đó là sự triển khai của Narwhal, tách biệt việc truyền dữ liệu và sự đồng thuận, nhằm mở rộng giao thức đồng thuận hiện tại là Jolteon. Jolteon là một giao thức dựa trên người lãnh đạo, kết hợp con đường nhanh tuyến tính của Tendermint và thay đổi quan điểm theo phong cách PBFT, giảm trễ của Hotstuff xuống 33%. Tuy nhiên, giao thức đồng thuận dựa trên người lãnh đạo không thể tận dụng đầy đủ tiềm năng thông lượng của Narwhal.
Do đó, quyết định triển khai Bullshark trên Narwhal DAG, một giao thức đồng thuận không có chi phí giao tiếp. Thật không may, cấu trúc DAG hỗ trợ thông lượng cao của Bullshark mang lại chi phí trễ 50% so với Jolteon.
Bài viết này giới thiệu cách Shoal giảm đáng kể độ trễ của Bullshark.
Bối cảnh DAG-BFT
Mỗi đỉnh trong Narwhal DAG đều được liên kết với một vòng. Để vào vòng r, người xác thực phải trước tiên nhận được n-f đỉnh từ vòng r-1. Mỗi người xác thực có thể phát sóng một đỉnh mỗi vòng, mỗi đỉnh phải tham chiếu ít nhất n-f đỉnh từ vòng trước. Do tính bất đồng bộ của mạng, các người xác thực khác nhau có thể quan sát các cái nhìn địa phương khác nhau của DAG tại bất kỳ thời điểm nào.
Một thuộc tính quan trọng của DAG là không mơ hồ: nếu hai nút xác thực có cùng đỉnh v trong cái nhìn địa phương của DAG, thì chúng có lịch sử nguyên nhân v hoàn toàn giống nhau.
Toàn thứ tự
Có thể đạt được sự đồng thuận toàn bộ trên tất cả các đỉnh của DAG mà không phải tốn thêm chi phí truyền thông. Để 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 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.
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 sau:
Điểm neo đã đặt: cứ vài vòng sẽ có một lãnh đạo được xác định trước, đỉnh điểm của lãnh đạo được gọi là điểm neo.
Điểm neo sắp xếp: Các validator độc lập nhưng xác định cách đặt hàng các điểm neo nào và bỏ qua các điểm neo nào.
Sắp xếp lịch sử nguyên nhân: Các xác thực viên lần lượt xử lý danh sách các điểm neo có thứ tự, sắp xếp tất cả các đỉnh không có thứ tự trước đó trong lịch sử nguyên nhân của từng điểm neo theo quy tắc xác định.
Điều quan trọng để đảm bảo an toàn là đảm bảo rằng trong bước (2), tất cả các nút xác minh trung thực tạo ra danh sách điểm neo có thứ tự chia sẻ cùng một tiền tố. Shoal đưa ra các quan sát sau về tất cả các giao thức này:
Tất cả các validator đều đồng ý với điểm neo đầu tiên có thứ tự.
Bullshark Trễ
Độ 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ù một số phiên bản đồng bộ có độ trễ tốt hơn phiên bản bất đồng bộ, nhưng vẫn chưa phải là tối ưu.
Vấn đề 1: Trễ khối trung bình. Trong Bullshark, mỗi vòng chẵn có một điểm neo, mỗi vòng lẻ đỉnh được hiểu là bỏ phiếu. Trong các trường hợp phổ biến, cần hai vòng DAG để đặt hàng 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ờ sắp xếp điểm neo. Thông thường, các đỉnh vòng lẻ cần ba vòng, các đỉnh không phải điểm neo vòng chẵn cần bốn vòng.
Vấn đề 2: Trễ trong trường hợp lỗi. Nếu một vòng lãnh đạo không kịp thời phát sóng điểm neo, thì không thể sắp xếp điểm neo ( bị bỏ qua ), tất cả các đỉnh chưa sắp xếp trong các vòng trước phải chờ đợi điểm neo tiếp theo được sắp xếp. Điều này làm giảm hiệu suất của mạng sao chép địa lý một cách đáng kể, đặc biệt là vì Bullshark sử dụng thời gian chờ lãnh đạo.
Khung Shoal
Shoal thông qua dây chuyền nâng cao Bullshark( hoặc bất kỳ giao thức BFT nào dựa trên Narwhal), cho phép mỗi vòng có điểm neo, 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, thiên về việc chọn lãnh đạo nhanh.
Thách thức
Trong bối cảnh giao thức DAG, vấn đề về độ tin cậy của pipeline và lãnh đạo được coi là vấn đề khó khăn, lý do như sau:
Những nỗ lực trước đây để sửa đổi logic chính của Bullshark dường như về bản chất là không thể.
Danh tiếng của lãnh đạo được đưa vào DiemBFT và chính thức hóa trong Carousel, lựa chọn lãnh đạo tương lai một cách động dựa trên hiệu suất trong quá khứ của các xác nhận viên (Bullshark中的锚). Mặc dù có sự khác biệt về danh tính lãnh đạo không vi phạm tính an toàn của các giao thức này, nhưng trong Bullshark có thể dẫn đến thứ tự hoàn toàn khác nhau, điều này đặt ra vấn đề cốt lõi: việc xác định động lựa chọn vòng neo là cần thiết để giải quyết sự đồng thuận, trong khi các xác nhận viên cần đạt được sự đồng thuận về lịch sử có thứ tự để chọn neo tương lai.
Là bằng chứng cho độ khó của vấn đề, việc triển khai Bullshark ( bao gồm ) 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.
Giao thức
Shoal dựa vào khả năng thực hiện tính toán cục bộ trên DAG để có thể 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 xác thực viên về cái nhìn đầu tiên của điểm neo có thứ tự, Shoal kết hợp tuần tự nhiều phiên bản Bullshark để xử lý theo quy trình, khiến cho ( điểm neo có thứ tự đầu tiên là điểm chuyển đổi phiên bản, ) 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òng chảy
V để ánh xạ vòng đến người lãnh đạo. Shoal chạy các phiên bản Bullshark một cách lần lượt, mỗi phiên bản có một đ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, 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 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 có thể xác định đồng ý từ vòng r+1 để diễn giải lại DAG. 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 hàng một cái neo cho mỗi vòng. Điểm neo của vòng đầu tiên được sắp xếp bởi thực thể đầu tiên. Sau đó, Shoal bắt đầu thực thể mới trong vòng thứ hai, nó có một điểm neo, cái neo được sắp xếp bởi thực thể đó, và sau đó một thực thể mới khác đặt hàng điểm neo trong vòng thứ ba, quá trình tiếp tục.
![Giải thích chi tiết về khung Shoal: Làm thế nào để Thả Bullshark trên Aptos?])https://img-cdn.gateio.im/webp-social/moments-0b0928cb6240e994c1514c75e080a4b2.webp###
( Danh tiếng của nhà lãnh đạo
Khi bỏ qua các điểm neo trong quá trình sắp xếp Bullshark, Trễ sẽ tăng lên. Trong trường hợp này, đường ống không thể làm gì, vì không thể khởi động một thực thể mới cho đến khi thực thể trước đó đặt hàng điểm neo. Shoal đảm bảo rằng các nhà lãnh đạo tương ứng ít có khả năng được chọn trong tương lai để xử lý các điểm neo bị mất bằng cách sử dụng cơ chế danh tiếng để phân bổ điểm dựa trên lịch sử hoạt động gần đây của từng nút xác thực. Các xác thực viên phản hồi và tham gia vào giao thức sẽ nhận được điểm cao, nếu không sẽ được phân bổ điểm thấp, vì nó có thể bị sập, chậm hoặc ác ý.
Nguyên tắc của nó là khi mỗi lần cập nhật điểm số, xác định lại một cách xác định ánh xạ đã được định nghĩa trước từ vòng đến người lãnh đạo F, ưu tiên cho những người lãnh đạo có điểm số cao hơn. Để các xác thực đạt được sự đồng thuận trên ánh xạ mới, họ nê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 để phát sinh điểm số.
Trong Shoal, dòng chảy 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, đó là giải thích lại DAG sau khi đồng thuận về điểm neo thứ nhất.
Điểm khác biệt duy nhất là, sau khi sắp xếp các điểm neo ở vòng r, các xác nhận viên chỉ cần dựa vào lịch sử nguyên nhân của các điểm neo theo thứ tự ở vòng r, bắt đầu tính toán ánh xạ mới F' từ vòng r+1. Sau đó, các nút xác thực sẽ bắt đầu sử dụng hàm chọn điểm neo cập nhật F' để thực hiện một phiên bản mới của Bullshark từ vòng r+1.
![Giải thích chi tiết Shoal framework: Làm thế nào để giảm thiểu trễ Bullshark trên Aptos?])https://img-cdn.gateio.im/webp-social/moments-859e732e16c3eee0e2c93422474debc2.webp###
( Không thời gian chờ
Thời gian quá hạn đóng vai trò quan trọng trong tất cả các triển khai BFT đồng bộ phần xác định 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, gia tăng độ phức tạp khi gỡ lỗi, cần nhiều kỹ thuật quan sát hơn.
Thời gian chờ cũng sẽ làm tăng đáng kể Trễ, vì việc cấu hình chúng đúng cách là rất quan trọng, thường cần điều chỉnh động, phụ thuộc nhiều vào môi trường ) mạng ###. Trước khi chuyển sang người lãnh đạo tiếp theo, giao thức sẽ trả toàn bộ hình phạt Trễ do thời gian chờ của người lãnh đạo gặp sự cố. Do đó, cài đặt thời gian chờ không thể quá bảo thủ, nhưng nếu quá ngắn, giao thức có thể bỏ qua những người lãnh đạo tốt. Ví dụ, chúng tôi đã quan sát thấy trong điều kiện tải cao, người lãnh đạo trong Jolteon/Hotstuff đã bị quá tải, thời gian chờ đã hết trước khi đạt được tiến bộ.
Thật không may, các giao thức dựa trên lãnh đạo ( như Hotstuff và Jolteon ) về cơ bản cần có thời gian trễ để đảm bảo rằng giao thức có thể tiến triển mỗi khi lãnh đạo gặp sự cố. Nếu không có thời gian trễ, ngay cả khi lãnh đạo bị sập cũng có thể dừng giao thức mãi mãi. Do không thể phân biệt lãnh đạo gặp sự cố và lãnh đạo chậm trong khoảng thời gian bất đồng bộ, thời gian trễ có thể dẫn đến việc các nút xác thực thay đổi tất cả lãnh đạo mà không có sự đồng thuận hoạt động.
Trong Bullshark, thời gian chờ được sử dụng để xây dựng DAG, nhằm đảm bảo rằng trong quá trình đồng bộ, các nhà lãnh đạo trung thực đủ nhanh để thêm điểm neo vào DAG để sắp xếp.
Chúng tôi quan sát thấy việc xây dựng DAG cung cấp "đồng hồ" ước lượng tốc độ mạng. Trong trường hợp không bị tạm dừng, chỉ cần n-f xác thực viên trung thực tiếp tục thêm đỉnh vào DAG, vòng sẽ tiếp tục tiến lên. Mặc dù Bullshark có thể không thể sắp xếp ( với tốc độ mạng do vấn đề lãnh đạo ), nhưng DAG vẫn phát triển với tốc độ mạng, mặc dù một số lãnh đạo gặp vấn đề hoặc mạng không đồng bộ. Cuối cùng, khi lãnh đạo không bị lỗi phát sóng điểm neo đủ nhanh, toàn bộ lịch sử nguyên nhân của điểm neo sẽ được sắp xếp.
Trong đánh giá của chúng tôi, đã so sánh Bullshark trong trường hợp có và không có trễ:
Nhà lãnh đạo nhanh chóng: nhanh hơn ít nhất so với các xác thực viên khác. Hai phương pháp cung cấp cùng độ trễ, vì neo có thứ tự và không sử dụng thời gian chờ.
Lãnh đạo sai: Bullshark không có thời gian chờ, cung cấp độ trễ tốt hơn, vì các nút xác thực lập tức bỏ qua nó.
Trang này có thể chứa nội dung của bên thứ ba, được cung cấp chỉ nhằm mục đích thông tin (không phải là tuyên bố/bảo đảm) và không được coi là sự chứng thực cho quan điểm của Gate hoặc là lời khuyên về tài chính hoặc chuyên môn. Xem Tuyên bố từ chối trách nhiệm để biết chi tiết.
10 thích
Phần thưởng
10
4
Đăng lại
Chia sẻ
Bình luận
0/400
HashRateHermit
· 5giờ trước
Trễ cải thiện 80%? Đợt này bò quá!
Xem bản gốcTrả lời0
SelfRugger
· 5giờ trước
80% Trễ giảm, Ma đẻ nhìn cũng kêu bull
Xem bản gốcTrả lời0
CommunitySlacker
· 5giờ trước
bull bia Trễ đã được tối ưu 80%
Xem bản gốcTrả lời0
Hash_Bandit
· 5giờ trước
chết tiệt, điều này giống như khi chúng tôi tối ưu hóa độ khó khai thác btc vào năm 2013... tăng tỷ lệ băm lớn thật
Khung Shoal: Tối ưu hóa độ trễ Bullshark trên Aptos
Khung Shoal: Cách Thả độ Trễ Bullshark trên Aptos
Aptos Labs đã giải quyết hai vấn đề mở quan trọng trong DAG BFT, thả đáng kể trễ, và lần đầu tiên loại bỏ nhu cầu về thời gian chờ trong giao thức thực sự xác định. Tổng thể, trong trường hợp không có lỗi, đã cải thiện trễ của Bullshark 40%, trong trường hợp có lỗi đã cải thiện 80%.
Shoal là một khung, thông qua pipeline và uy tín của người lãnh đạo để tăng cường bất kỳ giao thức đồng thuận nào dựa trên Narwhal ( như DAG-Rider, Tusk, Bullshark ). Pipeline giảm thiểu độ trễ sắp xếp DAG bằng cách giới thiệu các điểm neo trong mỗi vòng, trong khi uy tín của người lãnh đạo cải thiện thêm vấn đề độ trễ bằng cách đảm bảo rằng các đ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 người lãnh đạo cho phép Shoal tận dụng cấu trúc DAG bất đồng bộ để loại bỏ thời gian chờ trong tất cả các trường hợp. Điều này cho phép Shoal cung cấp thuộc tính phản hồi phổ quát, bao gồm cả phản hồi lạc quan thường cần thiết.
Công nghệ này rất đơn giả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ự. Vì vậy, khi chúng ta khởi tạo Bullshark, chúng ta có một nhóm "cá mập" đang tham gia vào một cuộc tiếp sức.
Bối cảnh
Trong việc theo đuổi hiệu suất cao của mạng blockchain, mọi người luôn chú ý đến việc Thả độ phức tạp 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 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 100k+ TPS.
Độ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 lãnh đạo, 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, đề xuất tất cả các xác thực viên truyền dữ liệu cùng một lúc, 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.
Quorum Store được giới thiệu trước đó là sự triển khai của Narwhal, tách biệt việc truyền dữ liệu và sự đồng thuận, nhằm mở rộng giao thức đồng thuận hiện tại là Jolteon. Jolteon là một giao thức dựa trên người lãnh đạo, kết hợp con đường nhanh tuyến tính của Tendermint và thay đổi quan điểm theo phong cách PBFT, giảm trễ của Hotstuff xuống 33%. Tuy nhiên, giao thức đồng thuận dựa trên người lãnh đạo không thể tận dụng đầy đủ tiềm năng thông lượng của Narwhal.
Do đó, quyết định triển khai Bullshark trên Narwhal DAG, một giao thức đồng thuận không có chi phí giao tiếp. Thật không may, cấu trúc DAG hỗ trợ thông lượng cao của Bullshark mang lại chi phí trễ 50% so với Jolteon.
Bài viết này giới thiệu cách Shoal giảm đáng kể độ trễ của Bullshark.
Bối cảnh DAG-BFT
Mỗi đỉnh trong Narwhal DAG đều được liên kết với một vòng. Để vào vòng r, người xác thực phải trước tiên nhận được n-f đỉnh từ vòng r-1. Mỗi người xác thực có thể phát sóng một đỉnh mỗi vòng, mỗi đỉnh phải tham chiếu ít nhất n-f đỉnh từ vòng trước. Do tính bất đồng bộ của mạng, các người xác thực khác nhau có thể quan sát các cái nhìn địa phương khác nhau của DAG tại bất kỳ thời điểm nào.
Một thuộc tính quan trọng của DAG là không mơ hồ: nếu hai nút xác thực có cùng đỉnh v trong cái nhìn địa phương của DAG, thì chúng có lịch sử nguyên nhân v hoàn toàn giống nhau.
Toàn thứ tự
Có thể đạt được sự đồng thuận toàn bộ trên tất cả các đỉnh của DAG mà không phải tốn thêm chi phí truyền thông. Để 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 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.
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 sau:
Điểm neo đã đặt: cứ vài vòng sẽ có một lãnh đạo được xác định trước, đỉnh điểm của lãnh đạo được gọi là điểm neo.
Điểm neo sắp xếp: Các validator độc lập nhưng xác định cách đặt hàng các điểm neo nào và bỏ qua các điểm neo nào.
Sắp xếp lịch sử nguyên nhân: Các xác thực viên lần lượt xử lý danh sách các điểm neo có thứ tự, sắp xếp tất cả các đỉnh không có thứ tự trước đó trong lịch sử nguyên nhân của từng điểm neo theo quy tắc xác định.
Điều quan trọng để đảm bảo an toàn là đảm bảo rằng trong bước (2), tất cả các nút xác minh trung thực tạo ra danh sách điểm neo có thứ tự chia sẻ cùng một tiền tố. Shoal đưa ra các quan sát sau về tất cả các giao thức này:
Tất cả các validator đều đồng ý với điểm neo đầu tiên có thứ tự.
Bullshark Trễ
Độ 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ù một số phiên bản đồng bộ có độ trễ tốt hơn phiên bản bất đồng bộ, nhưng vẫn chưa phải là tối ưu.
Vấn đề 1: Trễ khối trung bình. Trong Bullshark, mỗi vòng chẵn có một điểm neo, mỗi vòng lẻ đỉnh được hiểu là bỏ phiếu. Trong các trường hợp phổ biến, cần hai vòng DAG để đặt hàng 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ờ sắp xếp điểm neo. Thông thường, các đỉnh vòng lẻ cần ba vòng, các đỉnh không phải điểm neo vòng chẵn cần bốn vòng.
Vấn đề 2: Trễ trong trường hợp lỗi. Nếu một vòng lãnh đạo không kịp thời phát sóng điểm neo, thì không thể sắp xếp điểm neo ( bị bỏ qua ), tất cả các đỉnh chưa sắp xếp trong các vòng trước phải chờ đợi điểm neo tiếp theo được sắp xếp. Điều này làm giảm hiệu suất của mạng sao chép địa lý một cách đáng kể, đặc biệt là vì Bullshark sử dụng thời gian chờ lãnh đạo.
Khung Shoal
Shoal thông qua dây chuyền nâng cao Bullshark( hoặc bất kỳ giao thức BFT nào dựa trên Narwhal), cho phép mỗi vòng có điểm neo, 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, thiên về việc chọn lãnh đạo nhanh.
Thách thức
Trong bối cảnh giao thức DAG, vấn đề về độ tin cậy của pipeline và lãnh đạo được coi là vấn đề khó khăn, lý do như sau:
Những nỗ lực trước đây để sửa đổi logic chính của Bullshark dường như về bản chất là không thể.
Danh tiếng của lãnh đạo được đưa vào DiemBFT và chính thức hóa trong Carousel, lựa chọn lãnh đạo tương lai một cách động dựa trên hiệu suất trong quá khứ của các xác nhận viên (Bullshark中的锚). Mặc dù có sự khác biệt về danh tính lãnh đạo không vi phạm tính an toàn của các giao thức này, nhưng trong Bullshark có thể dẫn đến thứ tự hoàn toàn khác nhau, điều này đặt ra vấn đề cốt lõi: việc xác định động lựa chọn vòng neo là cần thiết để giải quyết sự đồng thuận, trong khi các xác nhận viên cần đạt được sự đồng thuận về lịch sử có thứ tự để chọn neo tương lai.
Là bằng chứng cho độ khó của vấn đề, việc triển khai Bullshark ( bao gồm ) 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.
Giao thức
Shoal dựa vào khả năng thực hiện tính toán cục bộ trên DAG để có thể 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 xác thực viên về cái nhìn đầu tiên của điểm neo có thứ tự, Shoal kết hợp tuần tự nhiều phiên bản Bullshark để xử lý theo quy trình, khiến cho ( điểm neo có thứ tự đầu tiên là điểm chuyển đổi phiên bản, ) 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òng chảy
V để ánh xạ vòng đến người lãnh đạo. Shoal chạy các phiên bản Bullshark một cách lần lượt, mỗi phiên bản có một đ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, 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 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 có thể xác định đồng ý từ vòng r+1 để diễn giải lại DAG. 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 hàng một cái neo cho mỗi vòng. Điểm neo của vòng đầu tiên được sắp xếp bởi thực thể đầu tiên. Sau đó, Shoal bắt đầu thực thể mới trong vòng thứ hai, nó có một điểm neo, cái neo được sắp xếp bởi thực thể đó, và sau đó một thực thể mới khác đặt hàng điểm neo trong vòng thứ ba, quá trình tiếp tục.
![Giải thích chi tiết về khung Shoal: Làm thế nào để Thả Bullshark trên Aptos?])https://img-cdn.gateio.im/webp-social/moments-0b0928cb6240e994c1514c75e080a4b2.webp###
( Danh tiếng của nhà lãnh đạo
Khi bỏ qua các điểm neo trong quá trình sắp xếp Bullshark, Trễ sẽ tăng lên. Trong trường hợp này, đường ống không thể làm gì, vì không thể khởi động một thực thể mới cho đến khi thực thể trước đó đặt hàng điểm neo. Shoal đảm bảo rằng các nhà lãnh đạo tương ứng ít có khả năng được chọn trong tương lai để xử lý các điểm neo bị mất bằng cách sử dụng cơ chế danh tiếng để phân bổ điểm dựa trên lịch sử hoạt động gần đây của từng nút xác thực. Các xác thực viên phản hồi và tham gia vào giao thức sẽ nhận được điểm cao, nếu không sẽ được phân bổ điểm thấp, vì nó có thể bị sập, chậm hoặc ác ý.
Nguyên tắc của nó là khi mỗi lần cập nhật điểm số, xác định lại một cách xác định ánh xạ đã được định nghĩa trước từ vòng đến người lãnh đạo F, ưu tiên cho những người lãnh đạo có điểm số cao hơn. Để các xác thực đạt được sự đồng thuận trên ánh xạ mới, họ nê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 để phát sinh điểm số.
Trong Shoal, dòng chảy 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, đó là giải thích lại DAG sau khi đồng thuận về điểm neo thứ nhất.
Điểm khác biệt duy nhất là, sau khi sắp xếp các điểm neo ở vòng r, các xác nhận viên chỉ cần dựa vào lịch sử nguyên nhân của các điểm neo theo thứ tự ở vòng r, bắt đầu tính toán ánh xạ mới F' từ vòng r+1. Sau đó, các nút xác thực sẽ bắt đầu sử dụng hàm chọn điểm neo cập nhật F' để thực hiện một phiên bản mới của Bullshark từ vòng r+1.
![Giải thích chi tiết Shoal framework: Làm thế nào để giảm thiểu trễ Bullshark trên Aptos?])https://img-cdn.gateio.im/webp-social/moments-859e732e16c3eee0e2c93422474debc2.webp###
( Không thời gian chờ
Thời gian quá hạn đóng vai trò quan trọng trong tất cả các triển khai BFT đồng bộ phần xác định 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, gia tăng độ phức tạp khi gỡ lỗi, cần nhiều kỹ thuật quan sát hơn.
Thời gian chờ cũng sẽ làm tăng đáng kể Trễ, vì việc cấu hình chúng đúng cách là rất quan trọng, thường cần điều chỉnh động, phụ thuộc nhiều vào môi trường ) mạng ###. Trước khi chuyển sang người lãnh đạo tiếp theo, giao thức sẽ trả toàn bộ hình phạt Trễ do thời gian chờ của người lãnh đạo gặp sự cố. Do đó, cài đặt thời gian chờ không thể quá bảo thủ, nhưng nếu quá ngắn, giao thức có thể bỏ qua những người lãnh đạo tốt. Ví dụ, chúng tôi đã quan sát thấy trong điều kiện tải cao, người lãnh đạo trong Jolteon/Hotstuff đã bị quá tải, thời gian chờ đã hết trước khi đạt được tiến bộ.
Thật không may, các giao thức dựa trên lãnh đạo ( như Hotstuff và Jolteon ) về cơ bản cần có thời gian trễ để đảm bảo rằng giao thức có thể tiến triển mỗi khi lãnh đạo gặp sự cố. Nếu không có thời gian trễ, ngay cả khi lãnh đạo bị sập cũng có thể dừng giao thức mãi mãi. Do không thể phân biệt lãnh đạo gặp sự cố và lãnh đạo chậm trong khoảng thời gian bất đồng bộ, thời gian trễ có thể dẫn đến việc các nút xác thực thay đổi tất cả lãnh đạo mà không có sự đồng thuận hoạt động.
Trong Bullshark, thời gian chờ được sử dụng để xây dựng DAG, nhằm đảm bảo rằng trong quá trình đồng bộ, các nhà lãnh đạo trung thực đủ nhanh để thêm điểm neo vào DAG để sắp xếp.
Chúng tôi quan sát thấy việc xây dựng DAG cung cấp "đồng hồ" ước lượng tốc độ mạng. Trong trường hợp không bị tạm dừng, chỉ cần n-f xác thực viên trung thực tiếp tục thêm đỉnh vào DAG, vòng sẽ tiếp tục tiến lên. Mặc dù Bullshark có thể không thể sắp xếp ( với tốc độ mạng do vấn đề lãnh đạo ), nhưng DAG vẫn phát triển với tốc độ mạng, mặc dù một số lãnh đạo gặp vấn đề hoặc mạng không đồng bộ. Cuối cùng, khi lãnh đạo không bị lỗi phát sóng điểm neo đủ nhanh, toàn bộ lịch sử nguyên nhân của điểm neo sẽ được sắp xếp.
Trong đánh giá của chúng tôi, đã so sánh Bullshark trong trường hợp có và không có trễ:
Nhà lãnh đạo nhanh chóng: nhanh hơn ít nhất so với các xác thực viên khác. Hai phương pháp cung cấp cùng độ trễ, vì neo có thứ tự và không sử dụng thời gian chờ.
Lãnh đạo sai: Bullshark không có thời gian chờ, cung cấp độ trễ tốt hơn, vì các nút xác thực lập tức bỏ qua nó.