Khung Shoal: Giải pháp đổi mới để Thả độ 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ề thời gian chờ trong giao thức thực định. Tổng thể, đã cải thiện Trễ của Bullshark lên 40% trong trường hợp không có lỗi và cải thiện 80% khi có lỗi.
Shoal là một khung làm tăng cường giao thức đồng thuận dựa trên Narwhal ( thông qua xử lý theo dòng và cơ chế uy tín của nhà lãnh đạo như DAG-Rider, Tusk, Bullshark ). Xử lý theo dòng 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 cơ chế uy tín của nhà 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 quan đến các nút xác thực nhanh nhất. Hơn nữa, uy tín của nhà lãnh đạo cho phép Shoal tận dụng xây dựng DAG bất đồng bộ để loại bỏ cơ chế hết thời gian trong tất cả các tình huống. Điều này cho phép Shoal cung cấp một đặc tính mà chúng tôi gọi là "phản hồi phổ quát", nó bao gồm những đặc tính phản hồi lạc quan thường cần thiết.
Công nghệ của Shoal rất đơn giản, bao gồm việc chạy nhiều phiên bản của giao thức cơ sở theo thứ tự. Do đó, khi sử dụng Bullshark để khởi tạo, hiệu ứng mà chúng ta có được giống như một nhóm "cá mập" đang tham gia vào 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, 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 các phiên bản đầu tiên của Diem chỉ đạt 3500 TPS, thấp hơn nhiều so với mục tiêu 100000+ TPS của chúng tôi.
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 dựa trên giao thức của người lãnh đạo, và 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 dữ liệu với logic đồng thuận cốt lõi, đề xuất một kiến trúc mà tất cả các xác thực viên đều truyền dữ liệu đồng thời, 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 thông lượng 160.000 TPS.
Trong bài viết trước, chúng tôi đã giới thiệu Quorum Store - triển khai Narwhal của chúng tôi, nó tách biệt việc truyền dữ liệu với sự đồng thuận, và cách chúng tôi 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 đường dẫn nhanh tuyến tính của Tendermint và việc thay đổi chế độ giống như PBFT, có thể giảm thiểu 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ù đã tách biệt việc truyền dữ liệu với sự đồ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 - 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 với thông lượng cao đã mang lại chi phí trễ 50%.
Bài viết này sẽ giới thiệu Shoal làm thế nào để 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, các xác thực viên phải trước tiên thu thập n-f đỉnh thuộc vòng thứ r-1. Mỗi xác thực viên có thể phát 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 xác thực viên khác nhau có thể quan sát các góc nhìn cục bộ khác nhau của DAG tại bất kỳ thời điểm nào.
Một thuộc tính 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 chế độ xem địa phương DAG của chúng, thì chúng có cùng lịch sử nguyên nhân v.
Sắp xếp tổng序
Có thể đạt được sự đồng thuận về tổng thứ tự 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 nhận viên trong DAG-Rider, Tusk và Bullshark sẽ giải thích cấu trúc của DAG như một giao thức đồng thuận, trong đó các đỉnh đại diện cho đề xuất và các cạnh đại diện cho phiếu bầu.
Mặc dù logic giao thoa nhóm trên cấu trúc DAG khác nhau, nhưng tất cả các giao thức đồng thuận dựa trên Narwhal hiện có đều có cấu trúc sau:
Điểm neo đã đặt: Sau mỗi vài vòng (, như trong Bullshark, 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.
Điểm neo sắp xếp: Các xác thực quyết định một cách độc lập nhưng có tính xác định điểm neo nào sẽ được sắp xếp và điểm neo nào sẽ bị bỏ qua.
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 điểm neo có 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ự trong lịch sử nguyên nhân của nó theo một số quy tắc xác định.
Điều quan trọng để đảm bảo an ninh là đảm bảo rằng trong bước 2, tất cả các nút xác thực trung thực tạo ra một danh sách điểm neo có thứ tự, để tất cả các danh sách chia sẻ cùng một tiền tố. Trong Shoal, 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 đều đồng ý điểm neo đầu tiên theo thứ tự.
![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(
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 không đồng bộ, nhưng nó vẫn còn xa mới đạt 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, mỗi đỉnh của vòng lẻ được hiểu là một phiếu bầu. Trong trường hợp thường gặp, 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 gặp, 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: Tình trạng lỗi trễ. Phân tích trễ nêu trên áp dụng cho trường hợp không có lỗi, ngược lại, nếu người dẫn dắt của một vòng nào đó không đủ nhanh để phát sóng điểm neo, thì không thể sắp xếp điểm neo ) vì vậy bị bỏ qua (, dẫn đến tất cả các đỉnh không đượ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ẽ 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ờ để đợi người dẫn dắt.
![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(
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 dò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ò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 khiến việc lựa chọn có xu hướng về các lãnh đạo nhanh.
Thử thách
Trong bối cảnh giao thức DAG, xử lý theo hình thức ống dẫn 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 dường như 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 động dựa trên hiệu suất trong quá khứ của các xác thực viên để xác định người lãnh đạo tương lai trong )Bullshark. Mặc dù có sự khác biệt về danh tính người 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 nhau, điều này dẫn đến cốt lõi của vấn đề, đó là việc lựa chọn động và xác định các bánh ră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ự để chọn các điểm 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.
Thỏa thuận
Mặc dù có những thách thức trên, nhưng thực tế cho thấy giải pháp ẩ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à tái diễn giả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 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 instance Bullshark để xử lý theo dòng, khiến cho ( điểm neo có thứ tự đầu tiên là điểm chuyển giao của các instance, 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 nhà lãnh đạo.
( Xử lý dây chuyền
V ánh xạ vòng đến người lãnh đạo. Shoal chạy một cách lần lượt các phiên bản của Bullshark, như vậy cho 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 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à vận hành nó cho đến khi xác định được điểm neo có thứ tự đầu tiên, ví dụ như trong vòng r. Tất cả các xác thực viên đều đồng ý với điểm neo này. Do đó, tất cả các xác thực viên đều có thể đồng ý một cách xác định để giải thích lại DAG bắt đầu 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 của vòng đầu tiên được sắp xếp bởi 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 phiên bản đó sắp xếp, sau đó, một phiên bản mới khác sắp xếp điểm neo trong vòng thứ ba, quá trình này 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-9f789cb669f6fcc244ea7ff7648e48b4.webp(
) Danh tiếng 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ý chuỗi không thể hoạt động, vì không thể khởi động mới một phiên bản trước điểm neo của phiên bản trước đó. Shoal đảm bảo rằng trong tương lai, khả năng chọn lãnh đạo tương ứng để xử lý các điểm neo bị mất là thấp 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 từng nút xác thực. Các nút xác thực phản hồi và tham gia vào giao thức sẽ nhận được điểm cao, nếu không, 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 có hành vi xấu.
Ý tưởng của nó là khi 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 nghĩa 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 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ố, qua đó đạt được sự đồng thuận trong lịch sử được sử dụng để tạo ra điểm số.
Trong Shoal, xử lý theo chuỗi và uy tín của người lãnh đạo có thể tự nhiên kết hợp, vì chúng đều sử dụng cùng một công nghệ cốt lõi, đó là tái diễn giải DAG sau khi đạt được sự đồng thuận về mốc 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, người xác thực 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 được sắp xếp trong vòng thứ r. Sau đó, các nút xác thực bắt đầu từ vòng thứ r+1 sẽ thực hiện các trường hợp mới của Bullshark bằng cách sử dụng hàm chọn điểm neo đã cập nhật F'.
![Giải thích chi tiết về khung Shoal: Làm thế nào để giảm thiểu trễ Bullshark trên Aptos?]###https://img-cdn.gateio.im/webp-social/moments-1baf540693f376d93cb18ef3193593cc.webp(
) Xóa bỏ trễ
Thời gian chờ đóng một 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 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 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à cần nhiều kỹ thuật quan sát hơ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
Chia sẻ
Bình luận
0/400
ZKProofEnthusiast
· 21giờ trước
Ừm, những cái có soal đều tăng lên một cách khá điên rồ.
Xem bản gốcTrả lời0
SchrodingerWallet
· 21giờ trước
Đợt này 3比 sẽ To da moon không
Xem bản gốcTrả lời0
SmartContractPlumber
· 21giờ trước
Nhận thức chung cải tiến là điều dễ gây ra rủi ro chuỗi. Chưa có lỗ hổng mới thì hãy nói sau.
Shoal: Khung mới Aptos giảm mạnh Trễ Bullshark loại bỏ nhu cầu quá thời gian
Khung Shoal: Giải pháp đổi mới để Thả độ 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ề thời gian chờ trong giao thức thực định. Tổng thể, đã cải thiện Trễ của Bullshark lên 40% trong trường hợp không có lỗi và cải thiện 80% khi có lỗi.
Shoal là một khung làm tăng cường giao thức đồng thuận dựa trên Narwhal ( thông qua xử lý theo dòng và cơ chế uy tín của nhà lãnh đạo như DAG-Rider, Tusk, Bullshark ). Xử lý theo dòng 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 cơ chế uy tín của nhà 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 quan đến các nút xác thực nhanh nhất. Hơn nữa, uy tín của nhà lãnh đạo cho phép Shoal tận dụng xây dựng DAG bất đồng bộ để loại bỏ cơ chế hết thời gian trong tất cả các tình huống. Điều này cho phép Shoal cung cấp một đặc tính mà chúng tôi gọi là "phản hồi phổ quát", nó bao gồm những đặc tính phản hồi lạc quan thường cần thiết.
Công nghệ của Shoal rất đơn giản, bao gồm việc chạy nhiều phiên bản của giao thức cơ sở theo thứ tự. Do đó, khi sử dụng Bullshark để khởi tạo, hiệu ứng mà chúng ta có được giống như một nhóm "cá mập" đang tham gia vào 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, 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 các phiên bản đầu tiên của Diem chỉ đạt 3500 TPS, thấp hơn nhiều so với mục tiêu 100000+ TPS của chúng tôi.
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 dựa trên giao thức của người lãnh đạo, và 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 dữ liệu với logic đồng thuận cốt lõi, đề xuất một kiến trúc mà tất cả các xác thực viên đều truyền dữ liệu đồng thời, 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 thông lượng 160.000 TPS.
Trong bài viết trước, chúng tôi đã giới thiệu Quorum Store - triển khai Narwhal của chúng tôi, nó tách biệt việc truyền dữ liệu với sự đồng thuận, và cách chúng tôi 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 đường dẫn nhanh tuyến tính của Tendermint và việc thay đổi chế độ giống như PBFT, có thể giảm thiểu 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ù đã tách biệt việc truyền dữ liệu với sự đồ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 - 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 với thông lượng cao đã mang lại chi phí trễ 50%.
Bài viết này sẽ giới thiệu Shoal làm thế nào để 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, các xác thực viên phải trước tiên thu thập n-f đỉnh thuộc vòng thứ r-1. Mỗi xác thực viên có thể phát 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 xác thực viên khác nhau có thể quan sát các góc nhìn cục bộ khác nhau của DAG tại bất kỳ thời điểm nào.
Một thuộc tính 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 chế độ xem địa phương DAG của chúng, thì chúng có cùng lịch sử nguyên nhân v.
Sắp xếp tổng序
Có thể đạt được sự đồng thuận về tổng thứ tự 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 nhận viên trong DAG-Rider, Tusk và Bullshark sẽ giải thích cấu trúc của DAG như một giao thức đồng thuận, trong đó các đỉnh đại diện cho đề xuất và các cạnh đại diện cho phiếu bầu.
Mặc dù logic giao thoa nhóm trên cấu trúc DAG khác nhau, nhưng tất cả các giao thức đồng thuận dựa trên Narwhal hiện có đều có cấu trúc sau:
Điểm neo đã đặt: Sau mỗi vài vòng (, như trong Bullshark, 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.
Điểm neo sắp xếp: Các xác thực quyết định một cách độc lập nhưng có tính xác định điểm neo nào sẽ được sắp xếp và điểm neo nào sẽ bị bỏ qua.
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 điểm neo có 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ự trong lịch sử nguyên nhân của nó theo một số quy tắc xác định.
Điều quan trọng để đảm bảo an ninh là đảm bảo rằng trong bước 2, tất cả các nút xác thực trung thực tạo ra một danh sách điểm neo có thứ tự, để tất cả các danh sách chia sẻ cùng một tiền tố. Trong Shoal, 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 đều đồng ý điểm neo đầu tiên theo thứ tự.
![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(
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 không đồng bộ, nhưng nó vẫn còn xa mới đạt 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, mỗi đỉnh của vòng lẻ được hiểu là một phiếu bầu. Trong trường hợp thường gặp, 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 gặp, 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: Tình trạng lỗi trễ. Phân tích trễ nêu trên áp dụng cho trường hợp không có lỗi, ngược lại, nếu người dẫn dắt của một vòng nào đó không đủ nhanh để phát sóng điểm neo, thì không thể sắp xếp điểm neo ) vì vậy bị bỏ qua (, dẫn đến tất cả các đỉnh không đượ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ẽ 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ờ để đợi người dẫn dắt.
![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(
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 dò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ò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 khiến việc lựa chọn có xu hướng về các lãnh đạo nhanh.
Thử thách
Trong bối cảnh giao thức DAG, xử lý theo hình thức ống dẫn 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 dường như 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 động dựa trên hiệu suất trong quá khứ của các xác thực viên để xác định người lãnh đạo tương lai trong )Bullshark. Mặc dù có sự khác biệt về danh tính người 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 nhau, điều này dẫn đến cốt lõi của vấn đề, đó là việc lựa chọn động và xác định các bánh ră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ự để chọn các điểm 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.
Thỏa thuận
Mặc dù có những thách thức trên, nhưng thực tế cho thấy giải pháp ẩ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à tái diễn giả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 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 instance Bullshark để xử lý theo dòng, khiến cho ( điểm neo có thứ tự đầu tiên là điểm chuyển giao của các instance, 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 nhà lãnh đạo.
( Xử lý dây chuyền
V ánh xạ vòng đến người lãnh đạo. Shoal chạy một cách lần lượt các phiên bản của Bullshark, như vậy cho 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 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à vận hành nó cho đến khi xác định được điểm neo có thứ tự đầu tiên, ví dụ như trong vòng r. Tất cả các xác thực viên đều đồng ý với điểm neo này. Do đó, tất cả các xác thực viên đều có thể đồng ý một cách xác định để giải thích lại DAG bắt đầu 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 của vòng đầu tiên được sắp xếp bởi 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 phiên bản đó sắp xếp, sau đó, một phiên bản mới khác sắp xếp điểm neo trong vòng thứ ba, quá trình này 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-9f789cb669f6fcc244ea7ff7648e48b4.webp(
) Danh tiếng 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ý chuỗi không thể hoạt động, vì không thể khởi động mới một phiên bản trước điểm neo của phiên bản trước đó. Shoal đảm bảo rằng trong tương lai, khả năng chọn lãnh đạo tương ứng để xử lý các điểm neo bị mất là thấp 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 từng nút xác thực. Các nút xác thực phản hồi và tham gia vào giao thức sẽ nhận được điểm cao, nếu không, 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 có hành vi xấu.
Ý tưởng của nó là khi 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 nghĩa 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 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ố, qua đó đạt được sự đồng thuận trong lịch sử được sử dụng để tạo ra điểm số.
Trong Shoal, xử lý theo chuỗi và uy tín của người lãnh đạo có thể tự nhiên kết hợp, vì chúng đều sử dụng cùng một công nghệ cốt lõi, đó là tái diễn giải DAG sau khi đạt được sự đồng thuận về mốc 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, người xác thực 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 được sắp xếp trong vòng thứ r. Sau đó, các nút xác thực bắt đầu từ vòng thứ r+1 sẽ thực hiện các trường hợp mới của Bullshark bằng cách sử dụng hàm chọn điểm neo đã cập nhật F'.
![Giải thích chi tiết về khung Shoal: Làm thế nào để giảm thiểu trễ Bullshark trên Aptos?]###https://img-cdn.gateio.im/webp-social/moments-1baf540693f376d93cb18ef3193593cc.webp(
) Xóa bỏ trễ
Thời gian chờ đóng một 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 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 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à cần nhiều kỹ thuật quan sát hơn.
Siêu thời gian cũng sẽ tăng đáng kể trễ