Khung Shoal: Cải thiện độ trễ nhận thức chung 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ề thời gian chờ trong giao thức xác định bất đồng bộ. Tổng thể, trong tình huống không có lỗi, đã cải thiện trễ của Bullshark lên tới 40%, trong tình huống có lỗi cải thiện lên tới 80%.
Shoal là một giao thức nhằm cải thiện giao thức nhận thức chung dựa trên Narwhal ( thông qua xử lý theo chuỗi và cơ chế danh tiếng của người lãnh đạo, như DAG-Rider, Tusk, Bullshark ). Xử lý theo chuỗi 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, cơ chế danh tiếng 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 điểm neo liên kết với các nút xác thực nhanh nhất. Hơn nữa, danh tiếng 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 kịch bản. Điều này cho phép Shoal cung cấp một thuộc tính được gọi là phản hồi phổ quát, bao gồm phản hồi lạc quan thường cần thiết.
Công nghệ của Shoal tương đối đơn giản, liên quan đến việc chạy nhiều实例 của giao thức cơ sở theo thứ tự. Khi được khởi tạo với Bullshark, chúng ta có một nhóm "cá mập" đang tham gia một cuộc tiếp sức.
Bối cảnh và Đ动 cơ
Trong quá trình 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 của 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ề 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 xuất phát từ việc nhận thức rằng việc truyền dữ liệu là nút thắt chính dựa trên các giao thức của người 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 nhận thức chung cốt lõi, đề xuất một kiến trúc mà 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 nhận thức 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.
Trong bài viết trước, chúng tôi đã giới thiệu về Quorum Store. Narwhal thực hiện việc tách biệt việc truyền dữ liệu với Nhận thức chung, cũng như cách sử dụng nó để mở rộng giao thức Nhận thức chung hiện tại là Jolteon. Jolteon là một giao thức dựa trên lãnh đạo, kết hợp giữa đường đi nhanh tuyến tính của Tendermint và sự thay đổi nhìn theo phong cách PBFT, có thể giảm độ trễ của Hotstuff xuống 33%. Tuy nhiên, các giao thức Nhận thức chung 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ù đã tách biệt việc truyền dữ liệu với Nhận thức chung, 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 trên Narwhal DAG, một giao thức nhận thức chung không tốn phí truyền thông. Thật không may, so với Jolteon, cấu trúc DAG hỗ trợ Bullshark với khả năng thông lượng cao đã mang lại chi phí trễ 50%.
Bài viết này sẽ 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 thứ r, người xác thực phải đầu tiên nhận được n-f đỉnh thuộc vòng thứ r-1. Mỗi người xác thực 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 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 góc nhìn địa phương khác nhau của DAG vào 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 minh có cùng đỉnh v trong cái nhìn địa phương của chúng về DAG, thì chúng có lịch sử nguyên nhân v hoàn toàn giống nhau.
Sắp xếp 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í truyền thông bổ sung. Để làm điều này, các xác thực trong DAG-Rider, Tusk và Bullshark giải thích cấu trúc của DAG như một giao thức nhận thức chung, 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 của nhóm trên cấu trúc DAG là khác nhau, nhưng tất cả các giao thức nhận thức chung dựa trên Narwhal hiện có đều có cấu trúc như sau:
Điểm neo dự kiến: Sau mỗi 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.
Sắp xếp điểm neo: Các xác thực quyết định một cách độc lập nhưng chắc chắn điểm neo nào sẽ được sắp xếp và điểm neo nào sẽ được bỏ qua.
Phân loại lịch sử nguyên nhân: Các xác thực xử lý danh sách điểm neo có thứ tự một cách tuần tự và 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.
Chìa khóa để đảm bảo sự an toàn 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ả danh sách chia sẻ cùng một tiền tố. Trong Shoal, chúng tôi đã đưa ra 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 đều đồng ý với điểm neo đầu tiên được sắp xếp.
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ộ phần thực tế nhất của Bullshark có độ trễ tốt hơn phiên bản bất đồng bộ, nhưng nó vẫn còn xa mới đạt yêu cầu 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, trong khi đỉnh của mỗi vòng lẻ được giải thích là một phiếu bầu. Trong trường hợp chung, 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ểm neo được sắp xếp. Trong trường hợp chung, 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 các trường hợp lỗi. Phân tích trễ ở trên áp dụng cho các tình huống không có lỗi, mặt khác, nếu người lãnh đạo của một vòng không kịp thời phát sóng các điểm neo, thì không thể sắp xếp các đ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 đ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ờ để chờ người lãnh đạo.
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 xử lý theo kiểu ống, 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 một cơ chế danh tiếng lãnh đạo không tốn phí trong DAG, điều này làm cho việc chọn lựa thiên về lãnh đạo nhanh.
Thử thách
Trong bối cảnh giao thức DAG, xử lý theo dạng ống và uy tín của người lãnh đạo được coi là những vấn đề khó khăn, lý do như sau:
Các nỗ lực xử lý dòng chảy trước đây đã cố gắng sửa đổi logic Bullshark cốt lõi, nhưng điều này về bản chất có vẻ 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, được lựa chọn một cách động cho các lãnh đạo tương lai dựa trên hiệu suất trong quá khứ của các xác nhận viên trong (Bullshark và ý tưởng về các neo trong ). 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 trong các giao thức này, nhưng trong Bullshark, điều đó 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 rằng việc chọn các neo theo cách động và xác định là cần thiết để giải quyết Nhận thức chung, 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 các neo trong tương lai.
Là bằng chứng về độ khó của vấn đề, chúng tôi nhận thấy 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, đều 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 nêu trên, nhưng giải pháp ẩn chứa 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 cục bộ trên DAG và đã hiện thực hóa 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 tất cả các xác thực viên đồng ý về nhận thức chung 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实例 Bullshark để xử lý chúng theo chuỗi, khiến cho ( điểm neo có thứ tự đầu tiên trở thành điểm chuyển tiếp của các实例, 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 các lãnh đạo.
( Xử lý theo dòng
V ánh xạ các vòng đến các lãnh đạo. Shoal chạy từng phiên bản của Bullshark, vì vậy đố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 sắp xếp một điểm neo, điều này sẽ kích hoạt việc 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ư ở vòng r. Tất cả các người xác thực đều đồng ý với điểm neo này. Do đó, tất cả các người xác thực có thể đồng ý một cách chắc chắn để giải thích lại DAG từ vòng r+1 trở đi. Shoal chỉ đơn giản là khởi động một phiên bản Bullshark mới ở 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 mỏ neo trong mỗi vòng. Mỏ neo của 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, nó có một mỏ neo, 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 mỏ neo trong vòng thứ ba, và sau đó quá trình tiếp tục.
![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-0b0928cb6240e994c1514c75e080a4b2.webp###
( Danh tiếng của nhà lãnh đạo
Trong quá trình sắp xếp Bullshark, khi bỏ qua các điểm neo, Trễ sẽ tăng lên. Trong trường hợp này, công nghệ xử lý theo dạng ống sẽ không có hiệu quả, vì không thể khởi động các实例 mới trước khi sắp xếp điểm neo của实例 trước đó. Shoal đảm bảo rằng các nhà lãnh đạo tương ứng ít có khả năng được chọn để xử lý các điểm neo bị mất trong tương lai 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 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 gán điểm thấp, vì chúng có thể bị sập, chậm hoặc có hành vi xấu.
Ý tưởng của nó là khi cập nhật điểm số, sẽ tính toán lại một cách xác định ánh xạ định trước F từ vòng tới người lãnh đạo, thiên về những người lãnh đạo có điểm số cao hơn. Để các xác minh viên đạt được sự Nhận thức chung 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, xử lý theo chuỗi và danh tiếng của người 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, tức là giải thích lại DAG sau khi đạt được sự nhận thức chung 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' từ vòng thứ r+1 dựa trên lịch sử nguyên nhân của các điểm neo theo thứ tự trong vòng thứ r. Sau đó, các nút xác thực bắt đầu thực hiện một phiên bản mới của Bullshark từ vòng thứ r+1 bằng cách sử dụng hàm lựa chọn điểm neo đã được cập nhật F'.
![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ò rất 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 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à 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 đá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 đ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 lãnh đạo tiếp theo, giao thức sẽ chịu hình phạt thời gian chờ đầy đủ cho 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 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 bị quá tải và thời gian chờ đã hết hạn trước khi họ thúc đẩy tiến trình.
Không may, giao thức dựa trên người lãnh đạo ( như Hotstuff
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.
9 thích
Phần thưởng
9
6
Đăng lại
Chia sẻ
Bình luận
0/400
SchrodingerProfit
· 18giờ trước
Giờ thì aptos lại sắp To da moon rồi
Xem bản gốcTrả lời0
CodeAuditQueen
· 08-11 05:48
Tối ưu hóa thuật toán phức tạp cũng có rủi ro tái nhập khả năng tính toán, hy vọng không bị lật thuyền trong cống.
Khung Shoal nâng cao hiệu quả nhận thức chung Aptos: Bullshark thả lớn 40-80%
Khung Shoal: Cải thiện độ trễ nhận thức chung 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ề thời gian chờ trong giao thức xác định bất đồng bộ. Tổng thể, trong tình huống không có lỗi, đã cải thiện trễ của Bullshark lên tới 40%, trong tình huống có lỗi cải thiện lên tới 80%.
Shoal là một giao thức nhằm cải thiện giao thức nhận thức chung dựa trên Narwhal ( thông qua xử lý theo chuỗi và cơ chế danh tiếng của người lãnh đạo, như DAG-Rider, Tusk, Bullshark ). Xử lý theo chuỗi 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, cơ chế danh tiếng 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 điểm neo liên kết với các nút xác thực nhanh nhất. Hơn nữa, danh tiếng 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 kịch bản. Điều này cho phép Shoal cung cấp một thuộc tính được gọi là phản hồi phổ quát, bao gồm phản hồi lạc quan thường cần thiết.
Công nghệ của Shoal tương đối đơn giản, liên quan đến việc chạy nhiều实例 của giao thức cơ sở theo thứ tự. Khi được khởi tạo với Bullshark, chúng ta có một nhóm "cá mập" đang tham gia một cuộc tiếp sức.
Bối cảnh và Đ动 cơ
Trong quá trình 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 của 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ề 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 xuất phát từ việc nhận thức rằng việc truyền dữ liệu là nút thắt chính dựa trên các giao thức của người 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 nhận thức chung cốt lõi, đề xuất một kiến trúc mà 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 nhận thức 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.
Trong bài viết trước, chúng tôi đã giới thiệu về Quorum Store. Narwhal thực hiện việc tách biệt việc truyền dữ liệu với Nhận thức chung, cũng như cách sử dụng nó để mở rộng giao thức Nhận thức chung hiện tại là Jolteon. Jolteon là một giao thức dựa trên lãnh đạo, kết hợp giữa đường đi nhanh tuyến tính của Tendermint và sự thay đổi nhìn theo phong cách PBFT, có thể giảm độ trễ của Hotstuff xuống 33%. Tuy nhiên, các giao thức Nhận thức chung 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ù đã tách biệt việc truyền dữ liệu với Nhận thức chung, 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 trên Narwhal DAG, một giao thức nhận thức chung không tốn phí truyền thông. Thật không may, so với Jolteon, cấu trúc DAG hỗ trợ Bullshark với khả năng thông lượng cao đã mang lại chi phí trễ 50%.
Bài viết này sẽ 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 thứ r, người xác thực phải đầu tiên nhận được n-f đỉnh thuộc vòng thứ r-1. Mỗi người xác thực 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 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 góc nhìn địa phương khác nhau của DAG vào 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 minh có cùng đỉnh v trong cái nhìn địa phương của chúng về DAG, thì chúng có lịch sử nguyên nhân v hoàn toàn giống nhau.
Sắp xếp 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í truyền thông bổ sung. Để làm điều này, các xác thực trong DAG-Rider, Tusk và Bullshark giải thích cấu trúc của DAG như một giao thức nhận thức chung, 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 của nhóm trên cấu trúc DAG là khác nhau, nhưng tất cả các giao thức nhận thức chung dựa trên Narwhal hiện có đều có cấu trúc như sau:
Điểm neo dự kiến: Sau mỗi 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.
Sắp xếp điểm neo: Các xác thực quyết định một cách độc lập nhưng chắc chắn điểm neo nào sẽ được sắp xếp và điểm neo nào sẽ được bỏ qua.
Phân loại lịch sử nguyên nhân: Các xác thực xử lý danh sách điểm neo có thứ tự một cách tuần tự và 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.
Chìa khóa để đảm bảo sự an toàn 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ả danh sách chia sẻ cùng một tiền tố. Trong Shoal, chúng tôi đã đưa ra 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 đều đồng ý với điểm neo đầu tiên được sắp xếp.
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ộ phần thực tế nhất của Bullshark có độ trễ tốt hơn phiên bản bất đồng bộ, nhưng nó vẫn còn xa mới đạt yêu cầu 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, trong khi đỉnh của mỗi vòng lẻ được giải thích là một phiếu bầu. Trong trường hợp chung, 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ểm neo được sắp xếp. Trong trường hợp chung, 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 các trường hợp lỗi. Phân tích trễ ở trên áp dụng cho các tình huống không có lỗi, mặt khác, nếu người lãnh đạo của một vòng không kịp thời phát sóng các điểm neo, thì không thể sắp xếp các đ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 đ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ờ để chờ người lãnh đạo.
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 xử lý theo kiểu ống, 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 một cơ chế danh tiếng lãnh đạo không tốn phí trong DAG, điều này làm cho việc chọn lựa thiên về lãnh đạo nhanh.
Thử thách
Trong bối cảnh giao thức DAG, xử lý theo dạng ống và uy tín của người lãnh đạo được coi là những vấn đề khó khăn, lý do như sau:
Các nỗ lực xử lý dòng chảy trước đây đã cố gắng sửa đổi logic Bullshark cốt lõi, nhưng điều này về bản chất có vẻ 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, được lựa chọn một cách động cho các lãnh đạo tương lai dựa trên hiệu suất trong quá khứ của các xác nhận viên trong (Bullshark và ý tưởng về các neo trong ). 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 trong các giao thức này, nhưng trong Bullshark, điều đó 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 rằng việc chọn các neo theo cách động và xác định là cần thiết để giải quyết Nhận thức chung, 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 các neo trong tương lai.
Là bằng chứng về độ khó của vấn đề, chúng tôi nhận thấy 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, đều 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 nêu trên, nhưng giải pháp ẩn chứa 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 cục bộ trên DAG và đã hiện thực hóa 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 tất cả các xác thực viên đồng ý về nhận thức chung 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实例 Bullshark để xử lý chúng theo chuỗi, khiến cho ( điểm neo có thứ tự đầu tiên trở thành điểm chuyển tiếp của các实例, 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 các lãnh đạo.
( Xử lý theo dòng
V ánh xạ các vòng đến các lãnh đạo. Shoal chạy từng phiên bản của Bullshark, vì vậy đố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 sắp xếp một điểm neo, điều này sẽ kích hoạt việc 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ư ở vòng r. Tất cả các người xác thực đều đồng ý với điểm neo này. Do đó, tất cả các người xác thực có thể đồng ý một cách chắc chắn để giải thích lại DAG từ vòng r+1 trở đi. Shoal chỉ đơn giản là khởi động một phiên bản Bullshark mới ở 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 mỏ neo trong mỗi vòng. Mỏ neo của 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, nó có một mỏ neo, 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 mỏ neo trong vòng thứ ba, và sau đó quá trình tiếp tục.
![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-0b0928cb6240e994c1514c75e080a4b2.webp###
( Danh tiếng của nhà lãnh đạo
Trong quá trình sắp xếp Bullshark, khi bỏ qua các điểm neo, Trễ sẽ tăng lên. Trong trường hợp này, công nghệ xử lý theo dạng ống sẽ không có hiệu quả, vì không thể khởi động các实例 mới trước khi sắp xếp điểm neo của实例 trước đó. Shoal đảm bảo rằng các nhà lãnh đạo tương ứng ít có khả năng được chọn để xử lý các điểm neo bị mất trong tương lai 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 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 gán điểm thấp, vì chúng có thể bị sập, chậm hoặc có hành vi xấu.
Ý tưởng của nó là khi cập nhật điểm số, sẽ tính toán lại một cách xác định ánh xạ định trước F từ vòng tới người lãnh đạo, thiên về những người lãnh đạo có điểm số cao hơn. Để các xác minh viên đạt được sự Nhận thức chung 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, xử lý theo chuỗi và danh tiếng của người 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, tức là giải thích lại DAG sau khi đạt được sự nhận thức chung 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' từ vòng thứ r+1 dựa trên lịch sử nguyên nhân của các điểm neo theo thứ tự trong vòng thứ r. Sau đó, các nút xác thực bắt đầu thực hiện một phiên bản mới của Bullshark từ vòng thứ r+1 bằng cách sử dụng hàm lựa chọn điểm neo đã được cập nhật F'.
![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ò rất 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 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à 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 đá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 đ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 lãnh đạo tiếp theo, giao thức sẽ chịu hình phạt thời gian chờ đầy đủ cho 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 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 bị quá tải và thời gian chờ đã hết hạn trước khi họ thúc đẩy tiến trình.
Không may, giao thức dựa trên người lãnh đạo ( như Hotstuff