Khung Shoal: Làm thế nào để giảm độ trễ Bullshark trên Aptos?
Tổng quan
Aptos labs đã 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 tạm dừng trong các giao thức thự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ải thiện 80%.
Shoal là một khung, thông qua việc xử lý theo chuỗi và cơ chế danh tiếng lãnh đạo để 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 ). Chuỗi xử lý 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, danh tiếng lãnh đạo cải thiện hơn nữa vấn đề độ trễ bằng cách đảm bảo rằng điểm neo liên quan đến các nút xác thực nhanh nhất. Hơn nữa, danh tiếng 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 trường hợp. Đ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, nó chứa đự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ự, một cái sau cái khác. Do đó, khi được khởi tạo bằng Bullshark, 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ơ
Trong việc 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.
Sự đột phá gần đây bắt nguồn từ việc nhận ra rằng việc phát tán dữ liệu là nút thắt chính dựa trên giao thức lãnh đạo, có thể hưởng lợi từ việc song song hóa. Hệ thống Narwhal tách việc phát tán dữ liệu ra khỏi logic đồng thuận cốt lõi, đề xuất một kiến trúc trong đó tất cả các xác thực viên phát tán dữ liệu cùng một lúc, trong khi 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 năng suất 160.000 TPS.
Quorum Store được giới thiệu trước đây là một triển khai của Narwhal, tách biệt việc truyền dữ liệu và đồng thuận, nhằm 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 quan điểm theo kiểu 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 không thể tận dụng tối đa 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, người lãnh đạo của Hotstuff/Jolteon vẫn bị hạn chế.
Do đó, quyết định triển khai Bullshark trên Narwhal DAG, đây là một giao thức đồng thuận không tốn chi phí giao tiếp. 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 liên quan đến một vòng. Để vào vòng thứ r, những người xác thực phải trước tiên thu thập n-f đỉnh thuộc về 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 í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 người xác thực khác nhau có thể nhìn thấy các cái nhìn cục bộ khác nhau của DAG tại bất kỳ thời điểm nào.
Một thuộc tính quan trọng của DAG là 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 DAG của chúng, thì chúng có lịch sử nguyên nhân v hoàn toàn giống nhau.
Thứ tự tổng thể
Có thể đạt được sự đồng thuận về thứ tự tổng thể của tất cả các đỉnh trong DAG mà không cần 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 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 và các cạnh đại diện cho các phiếu bầu.
Mặc dù logic giao thoa nhóm dựa trên cấu trúc DAG là khác nhau, nhưng tất cả các giao thức đồng thuận hiện có dựa trên Narwhal đều có cấu trúc sau:
Điểm neo đã đặt: 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;
Đ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 về việc đặt hàng các điểm neo nào và bỏ qua các điểm neo nào;
Lịch sử nguyên nhân được sắp xếp: Các xác thực viên xử lý danh sách điểm neo có thứ tự từng cái một, 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 mỗi điểm neo.
Chìa khóa để đảm bảo tính an toàn là đảm bảo rằng trong bước (2), danh sách điểm neo có thứ tự do tất cả các nút xác thực trung thực tạo ra chia sẻ cùng một tiền tố. Trong Shoal, chúng tôi có những quan sát sau về tất cả các giao thức trên:
Tất cả các xác thực viên đều đồng ý với điểm neo có thứ tự đầu tiên.
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ễ khối trung bình. Trong Bullshark, mỗi vòng chẵn có một điểm neo, và đỉnh của mỗi vòng lẻ được giải thích là bỏ phiếu. Trong trường hợp thông thường, 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ờ các đ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ễ trong 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 người lãnh đạo trong một vòng không phát sóng điểm neo đủ nhanh, thì không thể sắp xếp điểm neo ( do đó bị bỏ qua ), vì vậy 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 hiệu suất của mạng sao chép địa lý một cách đáng kể, đặc biệt là vì Bullshark sử dụng thời gian chờ để đợi người lãnh đạo.
Khung Shoal
Shoal đã cải thiện Bullshark( hoặc bất kỳ giao thức BFT nào dựa trên Narwhal thông qua xử lý dòng chảy, 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 neo trong DAG xuống 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 lựa chọn thiên về các lãnh đạo nhanh chóng.
Thử thách
Trong bối cảnh giao thức DAG, việc xử lý theo dạng pipeline và uy tín của người lãnh đạo được coi là vấn đề khó khăn, lý do như sau:
Các nỗ lực xử lý theo 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 khả thi.
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, dựa trên việc lựa chọn động các lãnh đạo tương lai theo hiệu suất trong quá khứ của các xác thực viên trong )Bullshark, khái niệm về những cái neo trong (. 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 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 đưa ra vấn đề cốt lõi rằng việc lựa chọn động và xác định các cái 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ự để chọn các cái neo trong tương lai.
Với tư cách là bằng chứng cho độ khó của vấn đề, chúng tôi nhận thấy rằng việc triển khai 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.
![Giải thích chi tiết về khung Shoal: Làm thế nào để giảm độ trễ của Bullshark trên Aptos?])https://img-cdn.gateio.im/webp-social/moments-0b0928cb6240e994c1514c75e080a4b2.webp(
Thỏa thuận
Mặc dù có những thách thức nêu 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 đị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 của các vòng trước. Với sự đồng thuận của tất cả các xác thực về cái nhìn cốt lõi của điểm neo có thứ tự đầu tiên, Shoal kết hợp tuần tự nhiều phiên bản Bullshark để xử lý chúng theo dòng, khiến cho ) trở thành điểm chuyển giao của các phiên bản và ( lịch sử nguyên nhân của điểm neo được sử dụng để tính toán danh tiếng 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 lần lượt các phiên bản của Bullshark, như 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 đặt hàng 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à chạy nó cho đến khi xác định điểm neo thứ nhất, 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 thuận chắc chắn để 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 đặt hàng một cái neo trong mỗi vòng. Các điểm neo của vòng đầu tiên được sắp xếp theo thứ tự của các trường hợp đầu tiên. Sau đó, Shoal bắt đầu một trường hợp mới trong vòng thứ hai, chính nó có một điểm neo, cái neo được sắp xếp bởi trường hợp đó, sau đó, một trường hợp mới khác đặt hàng điểm neo trong vòng thứ ba, và quá trình này tiếp tục.
![Giải thích chi tiết về khung Shoal: Làm thế nào để giảm độ trễ Bullshark trên Aptos?])https://img-cdn.gateio.im/webp-social/moments-859e732e16c3eee0e2c93422474debc2.webp(
Danh tiếng của nhà lãnh đạo
Trong quá trình sắp xếp Bullshark, việc bỏ qua các điểm neo sẽ làm tăng độ trễ. Trong trường hợp này, công nghệ xử lý theo dòng 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 điểm neo của phiên bản trước được đặt hàng. Shoal đảm bảo rằng các nhà lãnh đạo tương ứng trong tương lai ít có khả năng được chọn để xử lý các điểm neo bị mất bằng cách sử dụng cơ chế tín nhiệm để phân bổ một đ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. 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, ngược lại, các nút xác thực sẽ được phân bổ điểm thấp, vì nó có thể bị sập, chậm hoặc làm điều ác.
Ý tưởng của nó là khi mỗi lần cập nhật điểm số, sẽ xác định lại một cách chắc chắn ánh xạ đã được định nghĩa 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 xác nhận viên đạt được sự đồng thuận trên ánh xạ mới, họ nên đạt được sự đồng thuận về điểm số, từ đó đạt được sự đồng thuận về lịch sử được sử dụng để phát sinh điểm số.
Trong Shoal, xử lý dòng chảy và uy tín của người lãnh đạo có thể kết hợp tự nhiên, 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ự đồng thuận về điểm neo 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 đã đượ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ử dụng hàm lựa chọn điểm neo đã được cập nhật F' để thực hiện một phiên bản mới của Bullshark.
![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-9f789cb669f6fcc244ea7ff7648e48b4.webp(
Không còn thời gian chờ nữa
Thời gian chờ đóng vai trò quan trọng trong tất cả các thực hiện BFT đồng bộ dựa trên lãnh đạo có tính xác định. 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ẽ làm tăng độ trễ đáng kể, 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 nhà lãnh đạo tiếp theo, giao thức sẽ trả toàn bộ hình phạt độ trễ thời gian chờ cho nhà lãnh đạo gặp sự cố. Do đó, cài đặt thời gian chờ không thể quá bảo thủ, nhưng nếu thời gian chờ quá ngắn, giao thức có thể bỏ qua nhà lãnh đạo tốt. Ví dụ, chúng tôi nhận thấy rằng, trong các trường hợp tải cao, nhà lãnh đạo trong Jolteon/Hotstuff bị quá tải và họ không thể tiến triển trước khi hết thời gian chờ.
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.
21 thích
Phần thưởng
21
9
Chia sẻ
Bình luận
0/400
RektCoaster
· 08-03 07:00
Trễ giảm nhiều như vậy? bull啊
Xem bản gốcTrả lời0
Degen4Breakfast
· 08-02 20:25
Thôi thì, làm neo cũng không cần phiền phức như vậy.
Xem bản gốcTrả lời0
SatoshiLegend
· 08-02 17:14
DAG tối ưu tuy tốt nhưng không thay đổi bản chất mới có thể đạt được đạo. Dưới mã nguồn không có bí mật.
Xem bản gốcTrả lời0
NonFungibleDegen
· 08-01 16:37
tăng giá af trên aptos rn... 80% nhanh hơn? có lẽ không có gì ser
Xem bản gốcTrả lời0
Ser_This_Is_A_Casino
· 07-31 12:48
Giảm một chút Trễ cũng có thể cuốn thành như vậy
Xem bản gốcTrả lời0
BearMarketBro
· 07-31 12:48
Có vẻ không tệ nhỉ
Xem bản gốcTrả lời0
ApeShotFirst
· 07-31 12:25
Chà, Aptos lại chơi đồ mới rồi!
Xem bản gốcTrả lời0
GasFeeCrybaby
· 07-31 12:25
Bao giờ phí gas có thể giảm xuống?
Xem bản gốcTrả lời0
ImpermanentLossFan
· 07-31 12:24
Cuối cùng đã có người nhớ đến Cổ phiếu A Aptos của tôi.
Khung Shoal đáng kể nâng cao hiệu suất Bullshark trên chuỗi Aptos, giảm tối đa độ trễ 80%.
Khung Shoal: Làm thế nào để giảm độ trễ Bullshark trên Aptos?
Tổng quan
Aptos labs đã 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 tạm dừng trong các giao thức thự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ải thiện 80%.
Shoal là một khung, thông qua việc xử lý theo chuỗi và cơ chế danh tiếng lãnh đạo để 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 ). Chuỗi xử lý 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, danh tiếng lãnh đạo cải thiện hơn nữa vấn đề độ trễ bằng cách đảm bảo rằng điểm neo liên quan đến các nút xác thực nhanh nhất. Hơn nữa, danh tiếng 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 trường hợp. Đ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, nó chứa đự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ự, một cái sau cái khác. Do đó, khi được khởi tạo bằng Bullshark, 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ơ
Trong việc 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.
Sự đột phá gần đây bắt nguồn từ việc nhận ra rằng việc phát tán dữ liệu là nút thắt chính dựa trên giao thức lãnh đạo, có thể hưởng lợi từ việc song song hóa. Hệ thống Narwhal tách việc phát tán dữ liệu ra khỏi logic đồng thuận cốt lõi, đề xuất một kiến trúc trong đó tất cả các xác thực viên phát tán dữ liệu cùng một lúc, trong khi 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 năng suất 160.000 TPS.
Quorum Store được giới thiệu trước đây là một triển khai của Narwhal, tách biệt việc truyền dữ liệu và đồng thuận, nhằm 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 quan điểm theo kiểu 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 không thể tận dụng tối đa 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, người lãnh đạo của Hotstuff/Jolteon vẫn bị hạn chế.
Do đó, quyết định triển khai Bullshark trên Narwhal DAG, đây là một giao thức đồng thuận không tốn chi phí giao tiếp. 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 liên quan đến một vòng. Để vào vòng thứ r, những người xác thực phải trước tiên thu thập n-f đỉnh thuộc về 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 í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 người xác thực khác nhau có thể nhìn thấy các cái nhìn cục bộ khác nhau của DAG tại bất kỳ thời điểm nào.
Một thuộc tính quan trọng của DAG là 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 DAG của chúng, thì chúng có lịch sử nguyên nhân v hoàn toàn giống nhau.
Thứ tự tổng thể
Có thể đạt được sự đồng thuận về thứ tự tổng thể của tất cả các đỉnh trong DAG mà không cần 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 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 và các cạnh đại diện cho các phiếu bầu.
Mặc dù logic giao thoa nhóm dựa trên cấu trúc DAG là khác nhau, nhưng tất cả các giao thức đồng thuận hiện có dựa trên Narwhal đều có cấu trúc sau:
Điểm neo đã đặt: 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;
Đ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 về việc đặt hàng các điểm neo nào và bỏ qua các điểm neo nào;
Lịch sử nguyên nhân được sắp xếp: Các xác thực viên xử lý danh sách điểm neo có thứ tự từng cái một, 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 mỗi điểm neo.
Chìa khóa để đảm bảo tính an toàn là đảm bảo rằng trong bước (2), danh sách điểm neo có thứ tự do tất cả các nút xác thực trung thực tạo ra chia sẻ cùng một tiền tố. Trong Shoal, chúng tôi có những quan sát sau về tất cả các giao thức trên:
Tất cả các xác thực viên đều đồng ý với điểm neo có thứ tự đầu tiên.
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ễ khối trung bình. Trong Bullshark, mỗi vòng chẵn có một điểm neo, và đỉnh của mỗi vòng lẻ được giải thích là bỏ phiếu. Trong trường hợp thông thường, 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ờ các đ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ễ trong 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 người lãnh đạo trong một vòng không phát sóng điểm neo đủ nhanh, thì không thể sắp xếp điểm neo ( do đó bị bỏ qua ), vì vậy 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 hiệu suất của mạng sao chép địa lý một cách đáng kể, đặc biệt là vì Bullshark sử dụng thời gian chờ để đợi người lãnh đạo.
Khung Shoal
Shoal đã cải thiện Bullshark( hoặc bất kỳ giao thức BFT nào dựa trên Narwhal thông qua xử lý dòng chảy, 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 neo trong DAG xuống 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 lựa chọn thiên về các lãnh đạo nhanh chóng.
Thử thách
Trong bối cảnh giao thức DAG, việc xử lý theo dạng pipeline và uy tín của người lãnh đạo được coi là vấn đề khó khăn, lý do như sau:
Các nỗ lực xử lý theo 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 khả thi.
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, dựa trên việc lựa chọn động các lãnh đạo tương lai theo hiệu suất trong quá khứ của các xác thực viên trong )Bullshark, khái niệm về những cái neo trong (. 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 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 đưa ra vấn đề cốt lõi rằng việc lựa chọn động và xác định các cái 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ự để chọn các cái neo trong tương lai.
Với tư cách là bằng chứng cho độ khó của vấn đề, chúng tôi nhận thấy rằng việc triển khai 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.
![Giải thích chi tiết về khung Shoal: Làm thế nào để giảm độ trễ của Bullshark trên Aptos?])https://img-cdn.gateio.im/webp-social/moments-0b0928cb6240e994c1514c75e080a4b2.webp(
Thỏa thuận
Mặc dù có những thách thức nêu 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 đị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 của các vòng trước. Với sự đồng thuận của tất cả các xác thực về cái nhìn cốt lõi của điểm neo có thứ tự đầu tiên, Shoal kết hợp tuần tự nhiều phiên bản Bullshark để xử lý chúng theo dòng, khiến cho ) trở thành điểm chuyển giao của các phiên bản và ( lịch sử nguyên nhân của điểm neo được sử dụng để tính toán danh tiếng 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 lần lượt các phiên bản của Bullshark, như 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 đặt hàng 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à chạy nó cho đến khi xác định điểm neo thứ nhất, 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 thuận chắc chắn để 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 đặt hàng một cái neo trong mỗi vòng. Các điểm neo của vòng đầu tiên được sắp xếp theo thứ tự của các trường hợp đầu tiên. Sau đó, Shoal bắt đầu một trường hợp mới trong vòng thứ hai, chính nó có một điểm neo, cái neo được sắp xếp bởi trường hợp đó, sau đó, một trường hợp mới khác đặt hàng điểm neo trong vòng thứ ba, và quá trình này tiếp tục.
![Giải thích chi tiết về khung Shoal: Làm thế nào để giảm độ trễ Bullshark trên Aptos?])https://img-cdn.gateio.im/webp-social/moments-859e732e16c3eee0e2c93422474debc2.webp(
Danh tiếng của nhà lãnh đạo
Trong quá trình sắp xếp Bullshark, việc bỏ qua các điểm neo sẽ làm tăng độ trễ. Trong trường hợp này, công nghệ xử lý theo dòng 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 điểm neo của phiên bản trước được đặt hàng. Shoal đảm bảo rằng các nhà lãnh đạo tương ứng trong tương lai ít có khả năng được chọn để xử lý các điểm neo bị mất bằng cách sử dụng cơ chế tín nhiệm để phân bổ một đ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. 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, ngược lại, các nút xác thực sẽ được phân bổ điểm thấp, vì nó có thể bị sập, chậm hoặc làm điều ác.
Ý tưởng của nó là khi mỗi lần cập nhật điểm số, sẽ xác định lại một cách chắc chắn ánh xạ đã được định nghĩa 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 xác nhận viên đạt được sự đồng thuận trên ánh xạ mới, họ nên đạt được sự đồng thuận về điểm số, từ đó đạt được sự đồng thuận về lịch sử được sử dụng để phát sinh điểm số.
Trong Shoal, xử lý dòng chảy và uy tín của người lãnh đạo có thể kết hợp tự nhiên, 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ự đồng thuận về điểm neo 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 đã đượ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ử dụng hàm lựa chọn điểm neo đã được cập nhật F' để thực hiện một phiên bản mới của Bullshark.
![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-9f789cb669f6fcc244ea7ff7648e48b4.webp(
Không còn thời gian chờ nữa
Thời gian chờ đóng vai trò quan trọng trong tất cả các thực hiện BFT đồng bộ dựa trên lãnh đạo có tính xác định. 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ẽ làm tăng độ trễ đáng kể, 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 nhà lãnh đạo tiếp theo, giao thức sẽ trả toàn bộ hình phạt độ trễ thời gian chờ cho nhà lãnh đạo gặp sự cố. Do đó, cài đặt thời gian chờ không thể quá bảo thủ, nhưng nếu thời gian chờ quá ngắn, giao thức có thể bỏ qua nhà lãnh đạo tốt. Ví dụ, chúng tôi nhận thấy rằng, trong các trường hợp tải cao, nhà lãnh đạo trong Jolteon/Hotstuff bị quá tải và họ không thể tiến triển trước khi hết thời gian chờ.