Aptos Labs gần đây đã 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 giao thức thực tế xác định. Tổng thể, độ trễ của Bullshark đã cải thiện 40% trong trường hợp không có lỗi và 80% trong trường hợp có lỗi.
Shoal là một khung, thông qua pipeline và uy tín của người dẫn đầu để 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 độ trễ sắp xếp DAG bằng cách giới thiệu một điểm neo trong mỗi vòng, trong khi uy tín của người dẫn đầu cải thiện thêm độ trễ bằng cách đảm bảo rằng điểm neo liên kết với nút xác thực nhanh nhất. Hơn nữa, uy tín của người dẫn đầu cho phép Shoal khai thác cấu trúc DAG không đồng bộ để loại bỏ thời gian chờ trong tất cả các kịch bản. Đ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, bao gồm những phản hồi lạc quan thường cần thiết.
Về mặt kỹ thuật, Shoal chạy nhiều phiên bản của giao thức nền tảng theo thứ tự. Vì vậy, khi sử dụng Bullshark để khởi tạo, chúng ta có một nhóm "cá mập" đang tham gia vào một cuộc tiếp sức.
Độ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 độ phức tạp trong giao tiếp. Tuy nhiên, phương pháp này không mang lại sự cải thiện đáng kể về khả năng xử lý. Ví dụ, phiên bản đầu tiên của Diem triển khai Hotstuff chỉ đạt 3500 TPS, thấp hơn nhiều so với mục tiêu 100k+ TPS.
Gần đây, sự đột phá xuất phát từ việc nhận ra rằng việc truyền dữ liệu là nút thắt chính của giao thức lãnh đạo và 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à logic đồng thuận, đưa ra một kiến trúc mà trong đó tất cả các xác thực viên cùng truyền dữ liệu, còn các 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 về thông lượng 160.000 TPS.
Trước đây, chúng tôi đã giới thiệu Quorum Store, tức là việc triển khai Narwhal, tách biệt việc truyền 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 đường dẫn nhanh tuyến tính của Tendermint và thay đổi chế độ xem theo phong cách PBFT, có thể giảm độ trễ của Hotstuff xuống 33%. Tuy nhiên, giao thức đồng thuận dựa trên lãnh đạo rõ ràng không thể tận dụng hết tiềm năng thông lượng của Narwhal. Mặc dù đã tách biệt việc truyền dữ liệu và đồng thuận, nhưng khi thông lượng tăng lên, lãnh đạo của Hotstuff/Jolteon vẫn bị hạn chế.
Do đó, chúng tôi quyết định triển khai Bullshark, một giao thức đồng thuận không tốn 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ó công suất 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.
Bối cảnh DAG-BFT
Mỗi đỉnh trong Narwhal DAG đều liên quan đến một vòng. Để vào vòng thứ r, người xác minh phải trước tiên nhận được n-f đỉnh thuộc vòng thứ r-1. Mỗi người xác minh có thể phát sóng một đỉnh mỗi vòng, và mỗi đỉnh phải tham chiếu ít nhất n-f đỉnh của vòng trước. Do tính không đồng bộ của mạng, các người xác minh khác nhau có thể quan sát các cái nhìn cục bộ khác nhau về DAG tại bất kỳ thời điểm nào.
Một thuộc tính chính 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 cục bộ DAG của chúng, thì chúng có lịch sử nguyên nhân v hoàn toàn giống nhau.
Tổng tựa
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 nhận 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.
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: 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 người lãnh đạo được gọi là điểm neo;
Điểm neo sắp xếp: các xác thực độc lập nhưng quyết định một cách xác định về việc sắp xếp 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 xử lý danh sách điểm neo có thứ tự một cách lần lượt, đối với mỗi điểm neo, sắp xếp tất cả các đỉnh vô thứ tự trước đó trong lịch sử nguyên nhân của nó theo các quy tắc xác định.
Yếu tố then chốt để đả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ố. Trong Shoal, chúng tôi 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 đồ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?])https://img-cdn.gateio.im/webp-social/moments-b7ed8888da112bae8d34c0fdb338b138.webp(
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 dụng hơn có độ trễ tốt hơn so với phiên bản bất đồng bộ, nhưng vẫn còn xa mới đạt được mứ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 đều có một điểm neo, và đỉnh của mỗi vòng lẻ được giải thích là phiếu bầu. Trong trường hợp thông thường, cần hai vòng DAG để sắp xếp đ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ể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.
Vấn đề 2: Trường hợp lỗi bị chậm trễ. Phân tích chậm trễ trên áp dụng cho trường hợp không có lỗi, mặt khác, nếu một vòng lãnh đạo 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 vài 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 đáng kể hiệu suất của mạng sao chép địa lý, đặc biệt là vì Bullshark sử dụng thời gian chờ lãnh đạo.
![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-46d37add0d9e81b2f295edf8eddd907f.webp(
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òn giới thiệu cơ chế danh tiếng lãnh đạo không tốn kém trong DAG, điều này làm cho việc lựa chọn nghiêng về các lãnh đạo nhanh.
Thách thức
Trong bối cảnh giao thức DAG, vấn đề về đường ống và uy tín của người lãnh đạo được coi là khó khăn, lý do như sau:
Trước đây, dòng chảy đã cố gắng sửa đổi logic cốt lõi của Bullshark, nhưng điều này dường như về bản chất là không thể.
Danh tiếng của người lãnh đạo được giới thiệu trong DiemBFT và chính thức hóa trong Carousel, là việc lựa chọn động theo hiệu suất quá khứ của các xác thực viên cho các lãnh đạo tương lai trong Bullshark, ý tưởng về 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 một thứ tự hoàn toàn khác, điều này dẫn đến cốt lõi của vấn đề, tức là việc lựa chọn động và xác định neo vòng là cần thiết để giải quyết sự đồng thuận, và 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 các neo tương lai.
Là bằng chứng về độ khó của vấn đề, chúng tôi nhận thấy rằng việc triển khai của 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.
Thỏa thuận
Mặc dù có những thách thức nêu trên, nhưng thực tế chứng minh rằng giải pháp nằm ẩn giấu trong sự đơn giản.
Tại Shoal, chúng tôi dựa vào khả năng thực hiện tính toán địa phương 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. Với sự đồng thuận của tất cả các xác thực về điểm neo thứ tự đầu tiên, Shoal kết hợp tuần tự nhiều phiên bản Bullshark và xử lý chúng theo chuỗi, khiến cho ( điểm neo 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.
Dây chuyền sản xuất
V ánh xạ vòng vào người lãnh đạo. Shoal chạy một cách lần lượt các thực thể của Bullshark, để cho mỗi thực thể, điểm neo được xác định trước bởi ánh xạ F. Mỗi thực thể sẽ sắp xếp một điểm neo, điều này sẽ kích hoạt việc chuyển sang thực thể 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 có thể đồng ý một cách chắc chắn để giải thích lại DAG bắt đầu từ vòng r+1. Shoal chỉ đơn giản là 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 phiên bản đầu tiên. Sau đó, Shoal bắt đầu một phiên bản mới trong vòng thứ hai, phiên bản này có một điểm neo, điểm neo này được sắp xếp bởi phiên bản đó, sau đó, một phiên bản mới khác được sắp xếp điểm neo trong vòng thứ ba, và sau đó quá trình này tiếp tục.
Danh tiếng của nhà lãnh đạo
Trong quá trình sắp xếp Bullshark, khi bỏ qua điểm neo, độ trễ sẽ tăng lên. Trong trường hợp này, công nghệ pipeline không thể làm gì được, vì không thể khởi động một phiên bản mới trước khi sắp xếp điểm neo của phiên bản trước. Shoal đảm bảo rằng trong tương lai sẽ khó chọn được nhà lãnh đạo tương ứng để 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 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 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, ngược lại, các nút xác thực sẽ được phân bổ điểm thấp, vì chúng có thể bị sập, chậm hoặc làm điều xấu.
Ý tưởng của nó là trong mỗi lần cập nhật điểm số, tính toán lại một cách xác định ánh xạ định trước F từ vòng đến người lãnh đạo, thiên về những người lãnh đạo có điểm số cao hơn. Để các người xác minh đạ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 trên lịch sử được sử dụng để phát sinh điểm số.
Trong Shoal, quy trình và uy tín lãnh đạo có thể kết hợp một cách 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 đạt được sự đồng thuận về điểm neo có thứ tự đầu tiê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 viên chỉ cần dựa trên lịch sử nguyên nhân có thứ tự của các điểm neo trong vòng r để tính toán ánh xạ mới F' từ vòng r+1. Sau đó, các nút xác thực bắt đầu 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 lựa chọn điểm neo cập nhật F'.
Không còn thời gian chờ nữa
Thời gian vượt quá đóng một vai trò quan trọng trong tất cả các triển khai BFT đồng bộ phần chắc chắn dựa trên leader. Tuy nhiên, độ phức tạp mà chúng gây ra đã làm tăng số lượng trạng thái nội bộ cần được 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.
Timeout cũng sẽ làm tăng đáng kể độ trễ, 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 nhiều vào môi trường ( mạng ). Trước khi chuyển sang lãnh đạo tiếp theo, giao thức sẽ trả phạt độ trễ timeout đầy đủ cho lãnh đạo bị lỗi. Do đó, cài đặt timeout không thể quá bảo thủ, nhưng nếu thời gian timeout quá ngắn, giao thức có thể bỏ qua lãnh đạo tốt. Ví dụ, chúng tôi quan sát thấy, trong các trường hợp tải cao, lãnh đạo trong Jolteon/Hotstuff không chịu nổi và thời gian timeout đã hết trước khi họ thúc đẩy tiến triển.
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.
20 thích
Phần thưởng
20
4
Chia sẻ
Bình luận
0/400
DeFiChef
· 07-03 15:05
Cái tăng hiệu suất 40% này thật hấp dẫn.
Xem bản gốcTrả lời0
TokenEconomist
· 07-02 09:36
thực ra, kiến trúc của shoal là một kiệt tác lý thuyết trò chơi. hãy nghĩ về nó như một điểm cân bằng nash nơi các Người xác thực tối ưu hóa cho danh tiếng = f(tốc độ, độ tin cậy)...
Khung Shoal Thả đáng kể độ trễ Bullshark trên Aptos, quy trình và cơ chế danh tiếng nâng cao hiệu suất rõ rệt.
Khung Shoal: Cải tiến độ trễ Bullshark trên Aptos
Aptos Labs gần đây đã 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 giao thức thực tế xác định. Tổng thể, độ trễ của Bullshark đã cải thiện 40% trong trường hợp không có lỗi và 80% trong trường hợp có lỗi.
Shoal là một khung, thông qua pipeline và uy tín của người dẫn đầu để 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 độ trễ sắp xếp DAG bằng cách giới thiệu một điểm neo trong mỗi vòng, trong khi uy tín của người dẫn đầu cải thiện thêm độ trễ bằng cách đảm bảo rằng điểm neo liên kết với nút xác thực nhanh nhất. Hơn nữa, uy tín của người dẫn đầu cho phép Shoal khai thác cấu trúc DAG không đồng bộ để loại bỏ thời gian chờ trong tất cả các kịch bản. Đ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, bao gồm những phản hồi lạc quan thường cần thiết.
Về mặt kỹ thuật, Shoal chạy nhiều phiên bản của giao thức nền tảng theo thứ tự. Vì vậy, khi sử dụng Bullshark để khởi tạo, chúng ta có một nhóm "cá mập" đang tham gia vào một cuộc tiếp sức.
Độ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 độ phức tạp trong giao tiếp. Tuy nhiên, phương pháp này không mang lại sự cải thiện đáng kể về khả năng xử lý. Ví dụ, phiên bản đầu tiên của Diem triển khai Hotstuff chỉ đạt 3500 TPS, thấp hơn nhiều so với mục tiêu 100k+ TPS.
Gần đây, sự đột phá xuất phát từ việc nhận ra rằng việc truyền dữ liệu là nút thắt chính của giao thức lãnh đạo và 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à logic đồng thuận, đưa ra một kiến trúc mà trong đó tất cả các xác thực viên cùng truyền dữ liệu, còn các 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 về thông lượng 160.000 TPS.
Trước đây, chúng tôi đã giới thiệu Quorum Store, tức là việc triển khai Narwhal, tách biệt việc truyền 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 đường dẫn nhanh tuyến tính của Tendermint và thay đổi chế độ xem theo phong cách PBFT, có thể giảm độ trễ của Hotstuff xuống 33%. Tuy nhiên, giao thức đồng thuận dựa trên lãnh đạo rõ ràng không thể tận dụng hết tiềm năng thông lượng của Narwhal. Mặc dù đã tách biệt việc truyền dữ liệu và đồng thuận, nhưng khi thông lượng tăng lên, lãnh đạo của Hotstuff/Jolteon vẫn bị hạn chế.
Do đó, chúng tôi quyết định triển khai Bullshark, một giao thức đồng thuận không tốn 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ó công suất 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.
Bối cảnh DAG-BFT
Mỗi đỉnh trong Narwhal DAG đều liên quan đến một vòng. Để vào vòng thứ r, người xác minh phải trước tiên nhận được n-f đỉnh thuộc vòng thứ r-1. Mỗi người xác minh có thể phát sóng một đỉnh mỗi vòng, và mỗi đỉnh phải tham chiếu ít nhất n-f đỉnh của vòng trước. Do tính không đồng bộ của mạng, các người xác minh khác nhau có thể quan sát các cái nhìn cục bộ khác nhau về DAG tại bất kỳ thời điểm nào.
Một thuộc tính chính 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 cục bộ DAG của chúng, thì chúng có lịch sử nguyên nhân v hoàn toàn giống nhau.
Tổng tựa
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 nhận 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.
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: 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 người lãnh đạo được gọi là điểm neo;
Điểm neo sắp xếp: các xác thực độc lập nhưng quyết định một cách xác định về việc sắp xếp 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 xử lý danh sách điểm neo có thứ tự một cách lần lượt, đối với mỗi điểm neo, sắp xếp tất cả các đỉnh vô thứ tự trước đó trong lịch sử nguyên nhân của nó theo các quy tắc xác định.
Yếu tố then chốt để đả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ố. Trong Shoal, chúng tôi 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 đồ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?])https://img-cdn.gateio.im/webp-social/moments-b7ed8888da112bae8d34c0fdb338b138.webp(
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 dụng hơn có độ trễ tốt hơn so với phiên bản bất đồng bộ, nhưng vẫn còn xa mới đạt được mứ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 đều có một điểm neo, và đỉnh của mỗi vòng lẻ được giải thích là phiếu bầu. Trong trường hợp thông thường, cần hai vòng DAG để sắp xếp đ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ể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.
Vấn đề 2: Trường hợp lỗi bị chậm trễ. Phân tích chậm trễ trên áp dụng cho trường hợp không có lỗi, mặt khác, nếu một vòng lãnh đạo 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 vài 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 đáng kể hiệu suất của mạng sao chép địa lý, đặc biệt là vì Bullshark sử dụng thời gian chờ lãnh đạo.
![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-46d37add0d9e81b2f295edf8eddd907f.webp(
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òn giới thiệu cơ chế danh tiếng lãnh đạo không tốn kém trong DAG, điều này làm cho việc lựa chọn nghiêng về các lãnh đạo nhanh.
Thách thức
Trong bối cảnh giao thức DAG, vấn đề về đường ống và uy tín của người lãnh đạo được coi là khó khăn, lý do như sau:
Trước đây, dòng chảy đã cố gắng sửa đổi logic cốt lõi của Bullshark, nhưng điều này dường như về bản chất là không thể.
Danh tiếng của người lãnh đạo được giới thiệu trong DiemBFT và chính thức hóa trong Carousel, là việc lựa chọn động theo hiệu suất quá khứ của các xác thực viên cho các lãnh đạo tương lai trong Bullshark, ý tưởng về 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 một thứ tự hoàn toàn khác, điều này dẫn đến cốt lõi của vấn đề, tức là việc lựa chọn động và xác định neo vòng là cần thiết để giải quyết sự đồng thuận, và 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 các neo tương lai.
Là bằng chứng về độ khó của vấn đề, chúng tôi nhận thấy rằng việc triển khai của 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.
Thỏa thuận
Mặc dù có những thách thức nêu trên, nhưng thực tế chứng minh rằng giải pháp nằm ẩn giấu trong sự đơn giản.
Tại Shoal, chúng tôi dựa vào khả năng thực hiện tính toán địa phương 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. Với sự đồng thuận của tất cả các xác thực về điểm neo thứ tự đầu tiên, Shoal kết hợp tuần tự nhiều phiên bản Bullshark và xử lý chúng theo chuỗi, khiến cho ( điểm neo 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.
Dây chuyền sản xuất
V ánh xạ vòng vào người lãnh đạo. Shoal chạy một cách lần lượt các thực thể của Bullshark, để cho mỗi thực thể, điểm neo được xác định trước bởi ánh xạ F. Mỗi thực thể sẽ sắp xếp một điểm neo, điều này sẽ kích hoạt việc chuyển sang thực thể 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 có thể đồng ý một cách chắc chắn để giải thích lại DAG bắt đầu từ vòng r+1. Shoal chỉ đơn giản là 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 phiên bản đầu tiên. Sau đó, Shoal bắt đầu một phiên bản mới trong vòng thứ hai, phiên bản này có một điểm neo, điểm neo này được sắp xếp bởi phiên bản đó, sau đó, một phiên bản mới khác được sắp xếp điểm neo trong vòng thứ ba, và sau đó quá trình này tiếp tục.
Danh tiếng của nhà lãnh đạo
Trong quá trình sắp xếp Bullshark, khi bỏ qua điểm neo, độ trễ sẽ tăng lên. Trong trường hợp này, công nghệ pipeline không thể làm gì được, vì không thể khởi động một phiên bản mới trước khi sắp xếp điểm neo của phiên bản trước. Shoal đảm bảo rằng trong tương lai sẽ khó chọn được nhà lãnh đạo tương ứng để 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 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 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, ngược lại, các nút xác thực sẽ được phân bổ điểm thấp, vì chúng có thể bị sập, chậm hoặc làm điều xấu.
Ý tưởng của nó là trong mỗi lần cập nhật điểm số, tính toán lại một cách xác định ánh xạ định trước F từ vòng đến người lãnh đạo, thiên về những người lãnh đạo có điểm số cao hơn. Để các người xác minh đạ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 trên lịch sử được sử dụng để phát sinh điểm số.
Trong Shoal, quy trình và uy tín lãnh đạo có thể kết hợp một cách 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 đạt được sự đồng thuận về điểm neo có thứ tự đầu tiê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 viên chỉ cần dựa trên lịch sử nguyên nhân có thứ tự của các điểm neo trong vòng r để tính toán ánh xạ mới F' từ vòng r+1. Sau đó, các nút xác thực bắt đầu 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 lựa chọn điểm neo cập nhật F'.
Không còn thời gian chờ nữa
Thời gian vượt quá đóng một vai trò quan trọng trong tất cả các triển khai BFT đồng bộ phần chắc chắn dựa trên leader. Tuy nhiên, độ phức tạp mà chúng gây ra đã làm tăng số lượng trạng thái nội bộ cần được 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.
Timeout cũng sẽ làm tăng đáng kể độ trễ, 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 nhiều vào môi trường ( mạng ). Trước khi chuyển sang lãnh đạo tiếp theo, giao thức sẽ trả phạt độ trễ timeout đầy đủ cho lãnh đạo bị lỗi. Do đó, cài đặt timeout không thể quá bảo thủ, nhưng nếu thời gian timeout quá ngắn, giao thức có thể bỏ qua lãnh đạo tốt. Ví dụ, chúng tôi quan sát thấy, trong các trường hợp tải cao, lãnh đạo trong Jolteon/Hotstuff không chịu nổi và thời gian timeout đã hết trước khi họ thúc đẩy tiến triển.
Thật không may, dựa trên sự lãnh đạo