Khung Shoal: Làm thế nào để giảm Trễ của 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 tế xác định. Tổng thể, trong trường hợp không có lỗi, độ trễ của Bullshark đã được cải thiện 40%, trong trường hợp có lỗi đã được cải thiện 80%.
Shoal là một khung, thông qua xử lý theo luồng và cơ chế uy tín của người lãnh đạo để tăng cường giao thức đồng thuận dựa trên Narwhal ( như DAG-Rider, Tusk, Bullshark ). Xử lý theo luồ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 người lãnh đạo cải thiện hơn nữa vấn đề độ trễ bằng cách đảm bảo điểm neo liên kết với các nút xác minh nhanh nhất. Ngoài ra, 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 bất đồng bộ để loại bỏ mọi tình huống bị quá thời gian. Điều này giúp Shoal cung cấp các đặc tính 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.
Công nghệ này rất đơn giản, liên quan đến việc chạy nhiều phiên bản của giao thức cơ sở theo thứ tự. Do đó, khi sử dụng Bullshark để khởi tạo, chúng tôi có một nhóm "cá mập" đang tham gia vào một cuộc tiếp sức.
Bối cảnh
Trong 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 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 100.000+ TPS.
Sự đột phá gần đây 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 các nhà lãnh đạo, có thể hưởng lợi từ việc phân tán. 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 nhận viên cùng lúc truyền 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 băng thông 160.000 TPS.
Aptos trước đây đã 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 người 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 người 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ù việc truyền dữ liệu và đồng thuận đã được tách rời, nhưng với việc tăng thông lượng, người lãnh đạo của Hotstuff/Jolteon vẫn bị hạn chế.
Do đó, Aptos quyết định triển khai Bullshark trên Narwhal DAG, một giao thức đồng thuận không có chi phí truyền thông. 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 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 gắn với một vòng. Để vào vòng r, các xác thực viên phải trước tiên thu được n-f đỉnh thuộc vòng r-1. Mỗi xác thực viên có thể phát sóng một đỉnh mỗi vòng, và mỗi đỉnh ít nhất phải tham chiếu đến 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 hình ảnh đị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à 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, thì chúng có lịch sử nguyên nhân v hoàn toàn giống nhau.
Tổng tự
Có thể đạt được sự đồng thuận về thứ tự tổng quát 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 validator 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 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 tập hợp 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 dự kiến: Sau mỗi vài vòng (, chẳng hạn như trong Bullshark, sẽ có một nhà lãnh đạo được xác định trước sau mỗi hai vòng ), đỉnh của nhà lãnh đạo được gọi là điểm neo.
Điểm neo sắp xếp: Người xác thực độc lập nhưng quyết định một cách xác định điểm neo nào được sắp xếp và điểm neo nào 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 các điểm neo có thứ tự của họ, và đối với mỗi điểm neo, thông qua một số quy tắc xác định, 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ó.
Yếu tố chính để đả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 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, có những quan sát sau về tất cả các giao thức được đề cập ở trên:
Tất cả các validator đều đồng ý với điểm neo có thứ tự đầu tiên.
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 thực dụng hơn phiên bản không đồng bộ về độ trễ, 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 đ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 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ễ trường hợp lỗi. Phân tích trễ ở trên áp dụng cho tình huống không có lỗi, mặt khác, nếu nhà lãnh đạo của một vòng không kịp thời phát sóng điểm neo, thì không thể sắp xếp các điểm neo ( do đó bị bỏ qua ), vì vậy tất cả các đỉnh chưa được sắp xếp trong các vòng trước phải chờ đợi điểm neo tiếp theo được sắp xếp. Điều này 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ờ để chờ nhà 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 quy trình, 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 cơ chế danh tiếng lãnh đạo không tốn kém trong DAG, điều này khiến cho việc chọn lựa thiên về các lãnh đạo nhanh.
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 lãnh đạo được coi là những vấn đề khó khăn, lý do như sau:
Các thử nghiệm xử lý dây chuyền trước đây đã cố gắng sửa đổi logic cốt lõi của Bullshark, nhưng điều này về bản chất có vẻ 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 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 thực viên trong (Bullshark và ý tưởng về các mỏ 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 này 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 đề, tức là việc lựa chọn 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, 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 mỏ neo tương lai.
Là bằng chứng về độ khó của vấn đề, 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.
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à đã hiện thực hóa khả năng lưu giữ và giải thích lại thông tin của các vòng trước. Với tất cả các xác thực viên đồng ý 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 và xử lý chúng theo chuỗi, khiến cho ( điểm neo có thứ tự đầu tiên là điểm chuyển giao giữa các phiên bản, cũng như ) lịch sử nguyên nhân của các điểm neo dùng để tính toán uy tín của người lãnh đạo.
Xử lý dòng chảy
V ánh xạ các lượt đến người lãnh đạo. Shoal chạy một cách tuần tự các实例 của Bullshark, vì vậy đối với mỗi实例, điểm neo được xác định trước bởi ánh xạ F. Mỗi实例 sắp xếp một điểm neo, điều này sẽ kích hoạt việc chuyển sang实例 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 đ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 rằng sẽ 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 neo trong mỗi vòng. Neo điểm 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 neo, 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 neo trong vòng thứ ba, và quy trình này tiếp tục.
Danh tiếng của nhà 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ể làm gì, vì không thể khởi động một instance mới trước khi điểm neo của instance trước đó được sắp xếp. Shoal đảm bảo rằng các nhà lãnh đạo tương ứng ít có khả năng được chọn trong tương lai để xử lý các điểm neo bị mất bằng cách sử dụng cơ chế danh tiếng để phân bổ điểm 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 nhà 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 cập nhật điểm số, tính toán lại một cách xác định ánh xạ đã được định nghĩa từ vòng đến lãnh đạo F, nghiêng về lãnh đạo có điểm số cao hơn. Để các xác nhận viên đạt được sự đồng thuận trên ánh xạ mới, họ cần đạt được sự đồng thuận về điểm số, từ đó đạt được sự đồng thuận về lịch sử được sử dụng để sinh ra điểm số.
Trong Shoal, xử lý theo luồng 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, tức là việc 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 r, các xác thực viên chỉ cần tính toán ánh xạ mới F' từ vòng r+1 dựa trên lịch sử nguyên nhân của các điểm neo có thứ tự trong vòng r. Sau đó, các nút xác thực bắt đầu từ vòng r+1 sử dụng hàm chọn điểm neo được cập nhật F' để thực hiện phiên bản mới của Bullshark.
Không còn quá thời gian 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 quyết định dựa trên người lãnh đạo. Tuy nhiên, độ 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à cần nhiều kỹ thuật quan sát hơn.
Thời gian chờ cũng sẽ tăng cường độ trễ một cách đáng kể, vì việc cấu hình chúng một cách thích hợp 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 lãnh đạo tiếp theo, giao thức sẽ trả toàn bộ hình phạt trễ cho lãnh đạo gặp sự cố. Do đó, thiết lập 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 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 trước khi họ thúc đẩy tiến bộ.
Không may, dựa trên giao thức của người lãnh đạo ( như
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
5
Chia sẻ
Bình luận
0/400
ChainSpy
· 11giờ trước
Đèn xanh rồi APT sẽ To da moon
Xem bản gốcTrả lời0
AirdropHunter007
· 22giờ trước
Trễ giảm 40%? Cơn này To da moon!
Xem bản gốcTrả lời0
BTCBeliefStation
· 23giờ trước
tuyệt vời sự tối ưu này làm tôi ngạc nhiên
Xem bản gốcTrả lời0
CounterIndicator
· 23giờ trước
bull à Trễ giảm một nửa hơn
Xem bản gốcTrả lời0
MoonRocketTeam
· 23giờ trước
Ôi, trễ trực tiếp cắt 50%! Cửa sổ phóng này sắp to da moon rồi.
Tối ưu hóa khung Shoal giao thức nhận thức chung Aptos Trễ Bullshark giảm mạnh
Khung Shoal: Làm thế nào để giảm Trễ của 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 tế xác định. Tổng thể, trong trường hợp không có lỗi, độ trễ của Bullshark đã được cải thiện 40%, trong trường hợp có lỗi đã được cải thiện 80%.
Shoal là một khung, thông qua xử lý theo luồng và cơ chế uy tín của người lãnh đạo để tăng cường giao thức đồng thuận dựa trên Narwhal ( như DAG-Rider, Tusk, Bullshark ). Xử lý theo luồ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 người lãnh đạo cải thiện hơn nữa vấn đề độ trễ bằng cách đảm bảo điểm neo liên kết với các nút xác minh nhanh nhất. Ngoài ra, 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 bất đồng bộ để loại bỏ mọi tình huống bị quá thời gian. Điều này giúp Shoal cung cấp các đặc tính 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.
Công nghệ này rất đơn giản, liên quan đến việc chạy nhiều phiên bản của giao thức cơ sở theo thứ tự. Do đó, khi sử dụng Bullshark để khởi tạo, chúng tôi có một nhóm "cá mập" đang tham gia vào một cuộc tiếp sức.
Bối cảnh
Trong 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 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 100.000+ TPS.
Sự đột phá gần đây 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 các nhà lãnh đạo, có thể hưởng lợi từ việc phân tán. 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 nhận viên cùng lúc truyền 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 băng thông 160.000 TPS.
Aptos trước đây đã 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 người 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 người 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ù việc truyền dữ liệu và đồng thuận đã được tách rời, nhưng với việc tăng thông lượng, người lãnh đạo của Hotstuff/Jolteon vẫn bị hạn chế.
Do đó, Aptos quyết định triển khai Bullshark trên Narwhal DAG, một giao thức đồng thuận không có chi phí truyền thông. 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 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 gắn với một vòng. Để vào vòng r, các xác thực viên phải trước tiên thu được n-f đỉnh thuộc vòng r-1. Mỗi xác thực viên có thể phát sóng một đỉnh mỗi vòng, và mỗi đỉnh ít nhất phải tham chiếu đến 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 hình ảnh đị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à 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, thì chúng có lịch sử nguyên nhân v hoàn toàn giống nhau.
Tổng tự
Có thể đạt được sự đồng thuận về thứ tự tổng quát 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 validator 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 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 tập hợp 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 dự kiến: Sau mỗi vài vòng (, chẳng hạn như trong Bullshark, sẽ có một nhà lãnh đạo được xác định trước sau mỗi hai vòng ), đỉnh của nhà lãnh đạo được gọi là điểm neo.
Điểm neo sắp xếp: Người xác thực độc lập nhưng quyết định một cách xác định điểm neo nào được sắp xếp và điểm neo nào 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 các điểm neo có thứ tự của họ, và đối với mỗi điểm neo, thông qua một số quy tắc xác định, 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ó.
Yếu tố chính để đả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 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, có những quan sát sau về tất cả các giao thức được đề cập ở trên:
Tất cả các validator đều đồng ý với điểm neo có thứ tự đầu tiên.
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 thực dụng hơn phiên bản không đồng bộ về độ trễ, 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 đ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 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ễ trường hợp lỗi. Phân tích trễ ở trên áp dụng cho tình huống không có lỗi, mặt khác, nếu nhà lãnh đạo của một vòng không kịp thời phát sóng điểm neo, thì không thể sắp xếp các điểm neo ( do đó bị bỏ qua ), vì vậy tất cả các đỉnh chưa được sắp xếp trong các vòng trước phải chờ đợi điểm neo tiếp theo được sắp xếp. Điều này 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ờ để chờ nhà 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 quy trình, 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 cơ chế danh tiếng lãnh đạo không tốn kém trong DAG, điều này khiến cho việc chọn lựa thiên về các lãnh đạo nhanh.
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 lãnh đạo được coi là những vấn đề khó khăn, lý do như sau:
Các thử nghiệm xử lý dây chuyền trước đây đã cố gắng sửa đổi logic cốt lõi của Bullshark, nhưng điều này về bản chất có vẻ 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 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 thực viên trong (Bullshark và ý tưởng về các mỏ 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 này 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 đề, tức là việc lựa chọn 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, 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 mỏ neo tương lai.
Là bằng chứng về độ khó của vấn đề, 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.
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à đã hiện thực hóa khả năng lưu giữ và giải thích lại thông tin của các vòng trước. Với tất cả các xác thực viên đồng ý 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 và xử lý chúng theo chuỗi, khiến cho ( điểm neo có thứ tự đầu tiên là điểm chuyển giao giữa các phiên bản, cũng như ) lịch sử nguyên nhân của các điểm neo dùng để tính toán uy tín của người lãnh đạo.
Xử lý dòng chảy
V ánh xạ các lượt đến người lãnh đạo. Shoal chạy một cách tuần tự các实例 của Bullshark, vì vậy đối với mỗi实例, điểm neo được xác định trước bởi ánh xạ F. Mỗi实例 sắp xếp một điểm neo, điều này sẽ kích hoạt việc chuyển sang实例 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 đ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 rằng sẽ 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 neo trong mỗi vòng. Neo điểm 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 neo, 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 neo trong vòng thứ ba, và quy trình này tiếp tục.
Danh tiếng của nhà 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ể làm gì, vì không thể khởi động một instance mới trước khi điểm neo của instance trước đó được sắp xếp. Shoal đảm bảo rằng các nhà lãnh đạo tương ứng ít có khả năng được chọn trong tương lai để xử lý các điểm neo bị mất bằng cách sử dụng cơ chế danh tiếng để phân bổ điểm 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 nhà 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 cập nhật điểm số, tính toán lại một cách xác định ánh xạ đã được định nghĩa từ vòng đến lãnh đạo F, nghiêng về lãnh đạo có điểm số cao hơn. Để các xác nhận viên đạt được sự đồng thuận trên ánh xạ mới, họ cần đạt được sự đồng thuận về điểm số, từ đó đạt được sự đồng thuận về lịch sử được sử dụng để sinh ra điểm số.
Trong Shoal, xử lý theo luồng 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, tức là việc 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 r, các xác thực viên chỉ cần tính toán ánh xạ mới F' từ vòng r+1 dựa trên lịch sử nguyên nhân của các điểm neo có thứ tự trong vòng r. Sau đó, các nút xác thực bắt đầu từ vòng r+1 sử dụng hàm chọn điểm neo được cập nhật F' để thực hiện phiên bản mới của Bullshark.
Không còn quá thời gian 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 quyết định dựa trên người lãnh đạo. Tuy nhiên, độ 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à cần nhiều kỹ thuật quan sát hơn.
Thời gian chờ cũng sẽ tăng cường độ trễ một cách đáng kể, vì việc cấu hình chúng một cách thích hợp 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 lãnh đạo tiếp theo, giao thức sẽ trả toàn bộ hình phạt trễ cho lãnh đạo gặp sự cố. Do đó, thiết lập 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 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 trước khi họ thúc đẩy tiến bộ.
Không may, dựa trên giao thức của người lãnh đạo ( như