Khung Shoal: Giải pháp sáng tạo giảm trễ Bullshark trên Aptos
Aptos Labs gần đây đã đạt được những bước đột phá quan trọng trong lĩnh vực DAG BFT, giải quyết hai vấn đề chính, giảm đáng kể Trễ, và lần đầu tiên loại bỏ nhu cầu về thời gian chờ trong các giao thức có tính xác định. Nhìn chung, trong trường hợp không có lỗi, độ trễ của Bullshark đã được cải thiện 40%, và trong trường hợp có lỗi, đã được cải thiện 80%.
Shoal là một khung công tác để 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 ) thông qua xử lý theo chuỗi và uy tín của người lãnh đạo. Xử lý theo chuỗi giảm độ 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 độ trễ bằng cách đảm bảo rằng các điểm neo được 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 việc xây dựng DAG không đồng bộ để loại bỏ tất cả các kịch bản thời gian chờ. Điều này cho phép Shoal cung cấp tính năng mà chúng tôi gọi là "tính phản hồi phổ quát", bao gồm những gì thường cần thiết cho tính phản hồi lạc quan.
Công nghệ của chúng tôi rất đơn giản, về cơ bản là chạy nhiều phiên bản của giao thức nền tảng theo thứ tự. Do đó, khi sử dụng Bullshark để khởi tạo, chúng tôi có một nhóm "cá mập" đang chạy trong một cuộc tiếp sức.
Bối cảnh và động lực
Trong quá trình theo đuổi hiệu suất cao của mạng blockchain, việc giảm độ phức tạp trong giao tiếp luôn là trọng tâm, nhưng phương pháp này không mang lại sự cải thiện đáng kể nào về thông lượng. Ví dụ, phiên bản đầu tiên của Diem thực hiện Hotstuff chỉ đạt 3500 TPS, thấp hơn nhiều so với mục tiêu trên 100.000 TPS.
Gần đây, sự đột phá đến từ việc nhận ra rằng việc truyền tải dữ liệu là nút thắt chính trong giao thức của các nhà lãnh đạo, có thể được hưởng lợi từ việc song song hóa. Hệ thống Narwhal tách biệt việc truyền tải dữ liệu với logic đồng thuận cốt lõi, đưa ra một kiến trúc trong đó tất cả các xác thực viên cùng truyền tải 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.
Chúng tôi đã giới thiệu Quorum Store trước đây, việc triển khai Narwhal của chúng tôi tách biệt việc truyền dữ liệu và đồng thuận, cùng với 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 người lãnh đạo, kết hợp con đường nhanh tuyến tính của Tendermint và các thay đổi view kiểu PBFT, có thể giảm độ trễ của Hotstuff xuống 33%. Tuy nhiên, rõ ràng là các 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. Mặc dù việc tách biệt việc truyền dữ liệu và đồng thuận, nhưng với việc tăng thông lượng, người lãnh đạo của Hotstuff/Jolteon vẫn bị giới hạn.
Do đó, chúng tôi 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 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 của 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 ít nhất phải tham chiếu tới n-f đỉnh của 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 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 quan trọng của DAG là tính 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 của chúng, thì chúng có lịch sử nguyên nhân hoàn toàn giống nhau của v.
Thứ tự tổng thể
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ó chi phí giao tiếp 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 DAG như một giao thức đồng thuận, trong đó các đỉnh đại diện cho các đề xuất, còn 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 là 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 sau:
Điểm neo đã được đặt trước: Sau mỗi vài vòng (, như trong Bullshark, sẽ có một người lãnh đạo đã được xác định trước, đỉnh của nó được gọi là điểm neo.
Điểm neo sắp xếp: Các validator độc lập nhưng một cách xác định sẽ quyết định sắp xếp những điểm neo nào và bỏ qua những điểm neo nào.
Sắp xếp lịch sử nguyên nhân: các xác thực viên xử lý danh sách điểm neo theo thứ tự, đối với mỗi điểm neo, sắp xếp tất cả các đỉnh chưa có thứ tự trước đó trong lịch sử nguyên nhân của nó theo một số quy tắc xác định.
Yêu cầu chính để đảm bảo an ninh là đảm bảo rằng trong bước )2(, danh sách điểm neo có thứ tự được tạo ra bởi tất cả các nút xác thực trung thực chia sẻ cùng một tiền tố. Trong Shoal, chúng tôi có những quan sát sau về tất cả các giao thức trên:
Tất cả các xác thực viên đều đồng ý với điểm neo đầu tiên theo 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ù phiên bản đồng bộ của Bullshark 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ễ trung bình của khối. Trong Bullshark, mỗi vòng chẵn có một điểm neo, và đỉnh của mỗi vòng lẻ được hiểu là một phiếu bầu. Trong trường hợp phổ biến, 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ờ đợi điểm neo được sắp xếp. Trong trường hợp phổ biến, 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.
Vấn đề 2: Trễ trong trường hợp lỗi. Phân tích trễ trên áp dụng cho trường hợp không có lỗi, mặt khác, nếu người lãnh đạo trong một vòng không phát sóng điểm neo đủ nhanh, thì không thể sắp xếp điểm neo ) vì vậy bị bỏ qua (, do đó tất cả các đỉnh chưa được sắp xếp trong các vòng trước phải chờ điểm neo tiếp theo được sắp xếp. Điều này sẽ 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ờ để đợi người 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?])https://img-cdn.gateio.im/webp-social/moments-b7ed8888da112bae8d34c0fdb338b138.webp(
Khung Shoal
Shoal thông qua quy trình xử lý đã tăng cường Bullshark) hoặc bất kỳ giao thức BFT nào dựa trên Narwhal(, cho phép có một điểm neo 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 việc lựa chọn nghiêng về những lãnh đạo nhanh chóng.
Thách thức
Trong bối cảnh giao thức DAG, xử lý theo dạng ống và uy tín của người dẫn đầu được coi là những vấn đề khó khăn, lý do như sau:
Các nỗ lực trước đây để sửa đổi logic Bullshark cốt lõi dường như về bản chất là không thể.
Danh tiếng của nhà lãnh đạo được giới thiệu trong DiemBFT và chính thức hóa trong Carousel, dựa trên việc lựa chọn động các nhà lãnh đạo tương lai theo hiệu suất trong quá khứ của các xác thực viên, với ý tưởng về điểm neo trong Bullshark ). Mặc dù có sự khác biệt trong 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, điều này có thể dẫn đến thứ tự hoàn toàn khác, điều này đưa ra vấn đề cốt lõi, đó là việc lựa chọn điể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ự để lựa chọn điểm neo tương lai.
Như là bằng chứng cho độ khó của vấn đề, chúng tôi nhận thấy rằng việc triển khai Bullshark, bao gồm cả việc triển khai 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
Mặc dù có những thách thức trên, nhưng giải pháp lại ẩn chứa trong sự đơn giản.
Trong Shoal, chúng tôi dựa vào khả năng thực hiện tính toán cục bộ trên DAG và đã đạt được khả năng lưu trữ và giải thích lại thông tin từ các vòng trước. Nhờ vào sự đồng thuận của tất cả các xác nhận viên 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ý theo dạng chuỗi, khiến cho ( điểm neo có thứ tự đầu tiên là điểm chuyển giao của các phiên bản, cũng như ) lịch sử nguyên nhân của các điểm neo được sử dụng để tính toán uy tín của người lãnh đạo.
( Xử lý theo dòng
V ánh xạ các vòng đến người lãnh đạo. Shoal chạy lần lượt các instance của Bullshark, do đó cho mỗi instance, điểm neo được xác định trước bởi ánh xạ F. Mỗi instance sắp xếp một điểm neo, điều này sẽ kích hoạt việc chuyển sang instance 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à vận hành 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ể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 sắp xếp một điểm neo trong mỗi vòng. Điểm neo trong vòng đầu tiên được sắp xếp theo thể hiện đầu tiên. Sau đó, Shoal bắt đầu một thể hiện mới trong vòng thứ hai, có một điểm neo, điểm neo đó được sắp xếp bởi thể hiện đó, sau đó, một thể hiện mới khác sắp xếp điểm neo trong vòng thứ ba, và quá trình đó 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-0b0928cb6240e994c1514c75e080a4b2.webp(
) Danh tiếng của lãnh đạo
Khi bỏ qua đ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, công nghệ xử lý theo dòng không thể 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 điểm neo của phiên bản trước đó được sắp xếp. Shoal đảm bảo rằng khả năng chọn lãnh đạo tương ứng để xử lý các điểm neo bị mất trong tương lai là thấp bằng cách sử dụng cơ chế danh tiếng để gán một đ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 nó. Các người xác thực phản hồi và tham gia vào giao thức sẽ nhận được điểm số cao, nếu không, các nút xác thực sẽ bị gán điểm số thấp, vì nó có thể bị sập, chậm hoặc làm điều ác.
Ý tưởng của nó là khi mỗi lần cập nhật điểm số, xác định một cách chắc chắn để tính toán lại ánh xạ đã được định nghĩa từ vòng đến người lãnh đạo F, thiên về những người lãnh đạo có điểm số cao hơn. Để các xác thực viên đạ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, xử lý theo chuỗi và uy tín của nhà lãnh đạo có thể tự nhiên kết hợp với nhau, 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 đạt được sự đồng thuận về điểm neo có thứ tự đầu tiên.
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 thứ r, các xác thực viên chỉ cần tính toán ánh xạ mới F' bắt đầu từ vòng thứ 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 thứ r. Sau đó, các nút xác thực sẽ sử dụng hàm chọn điểm neo cập nhật F' để thực hiện các phiên bản mới của Bullshark bắt đầu từ vòng thứ r+1.
![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-859e732e16c3eee0e2c93422474debc2.webp(
) Không còn thời gian chờ nữa
Thời gian chờ đóng vai trò quan trọng trong tất cả các triển khai BFT đồng bộ phần tử xác định dựa trên người 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 được quản lý và theo dõi, điều này làm tăng độ phức tạp của quá trình gỡ lỗi và yêu cầu 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 một cách hợp lý là rất quan trọng, và thường cần điều chỉnh động, vì nó phụ thuộc 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 sẽ trả toàn bộ hình phạt trễ cho nhà 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 thời gian chờ quá ngắn, giao thức có thể bỏ qua những nhà lãnh đạo tốt. Ví dụ, chúng tôi quan sát thấy, trong trường hợp tải cao, nhà lãnh đạo trong Jolteon/Hotstuff bị quá tải, và thời gian chờ đã hết trước khi họ có thể thúc đẩy tiến triển.
Không may, các giao thức của người lãnh đạo ) như Hotstuff và Jolteon ### về cơ bản yêu cầu có độ trễ, để đảm bảo rằng mỗi khi người lãnh đạo gặp sự cố.
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.
13 thích
Phần thưởng
13
6
Đăng lại
Chia sẻ
Bình luận
0/400
SandwichDetector
· 7giờ trước
Hiệu suất được nâng cao thật là bull ah 80% nâng cao không thể tưởng tượng được.
Xem bản gốcTrả lời0
NFTRegretful
· 7giờ trước
Có vẻ ổn, chỉ là tốc độ vẫn chưa đủ nhanh.
Xem bản gốcTrả lời0
BearMarketSurvivor
· 8giờ trước
Trễ thả 80% đây chính là sức mạnh cứng của việc triển khai chiến trường, mong chờ hiệu suất thực chiến.
Xem bản gốcTrả lời0
CoinBasedThinking
· 8giờ trước
Dự án đáng tin cậy nâng cấp công nghệ, hy vọng không chỉ bắt đầu mà không kết thúc.
Khung Shoal nâng cao hiệu quả nhận thức chung Aptos, Bullshark thả 80%
Khung Shoal: Giải pháp sáng tạo giảm trễ Bullshark trên Aptos
Aptos Labs gần đây đã đạt được những bước đột phá quan trọng trong lĩnh vực DAG BFT, giải quyết hai vấn đề chính, giảm đáng kể Trễ, và lần đầu tiên loại bỏ nhu cầu về thời gian chờ trong các giao thức có tính xác định. Nhìn chung, trong trường hợp không có lỗi, độ trễ của Bullshark đã được cải thiện 40%, và trong trường hợp có lỗi, đã được cải thiện 80%.
Shoal là một khung công tác để 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 ) thông qua xử lý theo chuỗi và uy tín của người lãnh đạo. Xử lý theo chuỗi giảm độ 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 độ trễ bằng cách đảm bảo rằng các điểm neo được 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 việc xây dựng DAG không đồng bộ để loại bỏ tất cả các kịch bản thời gian chờ. Điều này cho phép Shoal cung cấp tính năng mà chúng tôi gọi là "tính phản hồi phổ quát", bao gồm những gì thường cần thiết cho tính phản hồi lạc quan.
Công nghệ của chúng tôi rất đơn giản, về cơ bản là chạy nhiều phiên bản của giao thức nền tảng theo thứ tự. Do đó, khi sử dụng Bullshark để khởi tạo, chúng tôi có một nhóm "cá mập" đang chạy trong một cuộc tiếp sức.
Bối cảnh và động lực
Trong quá trình theo đuổi hiệu suất cao của mạng blockchain, việc giảm độ phức tạp trong giao tiếp luôn là trọng tâm, nhưng phương pháp này không mang lại sự cải thiện đáng kể nào về thông lượng. Ví dụ, phiên bản đầu tiên của Diem thực hiện Hotstuff chỉ đạt 3500 TPS, thấp hơn nhiều so với mục tiêu trên 100.000 TPS.
Gần đây, sự đột phá đến từ việc nhận ra rằng việc truyền tải dữ liệu là nút thắt chính trong giao thức của các nhà lãnh đạo, có thể được hưởng lợi từ việc song song hóa. Hệ thống Narwhal tách biệt việc truyền tải dữ liệu với logic đồng thuận cốt lõi, đưa ra một kiến trúc trong đó tất cả các xác thực viên cùng truyền tải 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.
Chúng tôi đã giới thiệu Quorum Store trước đây, việc triển khai Narwhal của chúng tôi tách biệt việc truyền dữ liệu và đồng thuận, cùng với 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 người lãnh đạo, kết hợp con đường nhanh tuyến tính của Tendermint và các thay đổi view kiểu PBFT, có thể giảm độ trễ của Hotstuff xuống 33%. Tuy nhiên, rõ ràng là các 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. Mặc dù việc tách biệt việc truyền dữ liệu và đồng thuận, nhưng với việc tăng thông lượng, người lãnh đạo của Hotstuff/Jolteon vẫn bị giới hạn.
Do đó, chúng tôi 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 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 của 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 ít nhất phải tham chiếu tới n-f đỉnh của 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 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 quan trọng của DAG là tính 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 của chúng, thì chúng có lịch sử nguyên nhân hoàn toàn giống nhau của v.
Thứ tự tổng thể
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ó chi phí giao tiếp 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 DAG như một giao thức đồng thuận, trong đó các đỉnh đại diện cho các đề xuất, còn 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 là 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 sau:
Điểm neo đã được đặt trước: Sau mỗi vài vòng (, như trong Bullshark, sẽ có một người lãnh đạo đã được xác định trước, đỉnh của nó được gọi là điểm neo.
Điểm neo sắp xếp: Các validator độc lập nhưng một cách xác định sẽ quyết định sắp xếp những điểm neo nào và bỏ qua những điểm neo nào.
Sắp xếp lịch sử nguyên nhân: các xác thực viên xử lý danh sách điểm neo theo thứ tự, đối với mỗi điểm neo, sắp xếp tất cả các đỉnh chưa có thứ tự trước đó trong lịch sử nguyên nhân của nó theo một số quy tắc xác định.
Yêu cầu chính để đảm bảo an ninh là đảm bảo rằng trong bước )2(, danh sách điểm neo có thứ tự được tạo ra bởi tất cả các nút xác thực trung thực chia sẻ cùng một tiền tố. Trong Shoal, chúng tôi có những quan sát sau về tất cả các giao thức trên:
Tất cả các xác thực viên đều đồng ý với điểm neo đầu tiên theo 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ù phiên bản đồng bộ của Bullshark 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ễ trung bình của khối. Trong Bullshark, mỗi vòng chẵn có một điểm neo, và đỉnh của mỗi vòng lẻ được hiểu là một phiếu bầu. Trong trường hợp phổ biến, 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ờ đợi điểm neo được sắp xếp. Trong trường hợp phổ biến, 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.
Vấn đề 2: Trễ trong trường hợp lỗi. Phân tích trễ trên áp dụng cho trường hợp không có lỗi, mặt khác, nếu người lãnh đạo trong một vòng không phát sóng điểm neo đủ nhanh, thì không thể sắp xếp điểm neo ) vì vậy bị bỏ qua (, do đó tất cả các đỉnh chưa được sắp xếp trong các vòng trước phải chờ điểm neo tiếp theo được sắp xếp. Điều này sẽ 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ờ để đợi người 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?])https://img-cdn.gateio.im/webp-social/moments-b7ed8888da112bae8d34c0fdb338b138.webp(
Khung Shoal
Shoal thông qua quy trình xử lý đã tăng cường Bullshark) hoặc bất kỳ giao thức BFT nào dựa trên Narwhal(, cho phép có một điểm neo 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 việc lựa chọn nghiêng về những lãnh đạo nhanh chóng.
Thách thức
Trong bối cảnh giao thức DAG, xử lý theo dạng ống và uy tín của người dẫn đầu được coi là những vấn đề khó khăn, lý do như sau:
Các nỗ lực trước đây để sửa đổi logic Bullshark cốt lõi dường như về bản chất là không thể.
Danh tiếng của nhà lãnh đạo được giới thiệu trong DiemBFT và chính thức hóa trong Carousel, dựa trên việc lựa chọn động các nhà lãnh đạo tương lai theo hiệu suất trong quá khứ của các xác thực viên, với ý tưởng về điểm neo trong Bullshark ). Mặc dù có sự khác biệt trong 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, điều này có thể dẫn đến thứ tự hoàn toàn khác, điều này đưa ra vấn đề cốt lõi, đó là việc lựa chọn điể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ự để lựa chọn điểm neo tương lai.
Như là bằng chứng cho độ khó của vấn đề, chúng tôi nhận thấy rằng việc triển khai Bullshark, bao gồm cả việc triển khai 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
Mặc dù có những thách thức trên, nhưng giải pháp lại ẩn chứa trong sự đơn giản.
Trong Shoal, chúng tôi dựa vào khả năng thực hiện tính toán cục bộ trên DAG và đã đạt được khả năng lưu trữ và giải thích lại thông tin từ các vòng trước. Nhờ vào sự đồng thuận của tất cả các xác nhận viên 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ý theo dạng chuỗi, khiến cho ( điểm neo có thứ tự đầu tiên là điểm chuyển giao của các phiên bản, cũng như ) lịch sử nguyên nhân của các điểm neo được sử dụng để tính toán uy tín của người lãnh đạo.
( Xử lý theo dòng
V ánh xạ các vòng đến người lãnh đạo. Shoal chạy lần lượt các instance của Bullshark, do đó cho mỗi instance, điểm neo được xác định trước bởi ánh xạ F. Mỗi instance sắp xếp một điểm neo, điều này sẽ kích hoạt việc chuyển sang instance 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à vận hành 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ể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 sắp xếp một điểm neo trong mỗi vòng. Điểm neo trong vòng đầu tiên được sắp xếp theo thể hiện đầu tiên. Sau đó, Shoal bắt đầu một thể hiện mới trong vòng thứ hai, có một điểm neo, điểm neo đó được sắp xếp bởi thể hiện đó, sau đó, một thể hiện mới khác sắp xếp điểm neo trong vòng thứ ba, và quá trình đó 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-0b0928cb6240e994c1514c75e080a4b2.webp(
) Danh tiếng của lãnh đạo
Khi bỏ qua đ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, công nghệ xử lý theo dòng không thể 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 điểm neo của phiên bản trước đó được sắp xếp. Shoal đảm bảo rằng khả năng chọn lãnh đạo tương ứng để xử lý các điểm neo bị mất trong tương lai là thấp bằng cách sử dụng cơ chế danh tiếng để gán một đ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 nó. Các người xác thực phản hồi và tham gia vào giao thức sẽ nhận được điểm số cao, nếu không, các nút xác thực sẽ bị gán điểm số thấp, vì nó có thể bị sập, chậm hoặc làm điều ác.
Ý tưởng của nó là khi mỗi lần cập nhật điểm số, xác định một cách chắc chắn để tính toán lại ánh xạ đã được định nghĩa từ vòng đến người lãnh đạo F, thiên về những người lãnh đạo có điểm số cao hơn. Để các xác thực viên đạ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, xử lý theo chuỗi và uy tín của nhà lãnh đạo có thể tự nhiên kết hợp với nhau, 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 đạt được sự đồng thuận về điểm neo có thứ tự đầu tiên.
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 thứ r, các xác thực viên chỉ cần tính toán ánh xạ mới F' bắt đầu từ vòng thứ 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 thứ r. Sau đó, các nút xác thực sẽ sử dụng hàm chọn điểm neo cập nhật F' để thực hiện các phiên bản mới của Bullshark bắt đầu từ vòng thứ r+1.
![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-859e732e16c3eee0e2c93422474debc2.webp(
) Không còn thời gian chờ nữa
Thời gian chờ đóng vai trò quan trọng trong tất cả các triển khai BFT đồng bộ phần tử xác định dựa trên người 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 được quản lý và theo dõi, điều này làm tăng độ phức tạp của quá trình gỡ lỗi và yêu cầu 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 một cách hợp lý là rất quan trọng, và thường cần điều chỉnh động, vì nó phụ thuộc 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 sẽ trả toàn bộ hình phạt trễ cho nhà 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 thời gian chờ quá ngắn, giao thức có thể bỏ qua những nhà lãnh đạo tốt. Ví dụ, chúng tôi quan sát thấy, trong trường hợp tải cao, nhà lãnh đạo trong Jolteon/Hotstuff bị quá tải, và thời gian chờ đã hết trước khi họ có thể thúc đẩy tiến triển.
Không may, các giao thức của người lãnh đạo ) như Hotstuff và Jolteon ### về cơ bản yêu cầu có độ trễ, để đảm bảo rằng mỗi khi người lãnh đạo gặp sự cố.