Tối ưu hóa nhận thức chung DAG: Cách khung Shoal 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, thả đáng kể độ trễ và lần đầu tiên loại bỏ nhu cầu về thời gian chờ trong giao thức bất đồng bộ xác định. Tổng thể, khung Shoal đã cải thiện độ trễ của Bullshark 40% trong trường hợp không có lỗi và 80% trong trường hợp có lỗi.
Shoal là một giao thức đồng thuận dựa trên Narwhal được tăng cường thông qua đường ống và uy tín của người lãnh đạo ( như khung của DAG-Rider, Tusk, Bullshark ). Đường ống giảm thiểu độ trễ sắp xếp DAG bằng cách giới thiệu một điểm neo trong mỗi vòng, trong khi uy tín của người lãnh đạo cải thiện thêm độ trễ bằng cách đảm bảo rằng điểm neo được liên kết với các nút xác thực nhanh nhất. Hơn nữa, uy tín 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ỏ tất cả các tình huống thời gian chờ. Điều này khiến Shoal có khả năng cung cấp tính phản hồi phổ quát, bao gồm cả tính 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 phiên bản của giao thức cơ sở theo thứ tự. Khi sử dụng Bullshark để khởi tạo, chúng ta có một nhóm "cá mập" đang tham gia vào 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 thả độ phức tạp trong giao tiếp. Tuy nhiên, phương pháp này không dẫn đến việc tăng đáng kể 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 100k+ TPS.
Gần đây, sự đột phá 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 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 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à 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 đồ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 công suất 160.000 TPS.
Trong bài viết trước, chúng tôi đã giới thiệu về Quorum Store. Triển khai Narwhal của chúng tôi tách biệt việc truyền dữ liệu và 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 Jolteon. Jolteon là một giao thức dựa trên người dẫn dắt, kết hợp con đường nhanh tuyến tính của Tendermint và thay đổi tầm nhìn theo phong cách PBFT, có thể giảm thiểu độ trễ của Hotstuff xuống 33%. Tuy nhiên, giao thức nhận thức chung dựa trên người dẫn dắt rõ ràng 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à nhận thức chung, nhưng khi thông lượng tăng lên, người dẫn dắt của Hotstuff/Jolteon vẫn bị hạn chế.
Vì vậy, 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 chi phí truyền thông. Thật không may, so với Jolteon, cấu trúc DAG hỗ trợ Bullshark có 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 thả đá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, 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 sóng một đỉnh trong 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 không đồng bộ của mạng, các xác thực viên khác nhau có thể quan sát các cái 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 một đỉ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.
Toàn thứ tự
Có thể đạt được sự đồng thuận toàn thứ tự về 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 trình xác thực trong DAG-Rider, Tusk và Bullshark sẽ giải thích cấu trúc DAG như một giao thức nhận thức chung, 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 nhận thức chung dựa trên Narwhal hiện có đều có cấu trúc sau:
Điểm neo đã được đặt trước: cứ sau một vài vòng sẽ có một người lãnh đạo đã được xác định trước, đỉnh của nó được gọi là điểm neo.
Điểm neo sắp xếp: Các người xác thực độc lập nhưng một cách xác định quyết định sắp xếp những điểm neo nào và bỏ qua những điểm neo nào.
Sắp xếp lịch sử nguyên nhân: Các xác thực xử lý từng danh sách điểm neo có thứ 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 từng điểm neo.
Điều quan trọng để đảm bảo an toàn là đảm bảo rằng trong bước (2), danh sách các điểm neo có thứ tự được tạo bởi tất cả các nút xác thực trung thực chia sẻ cùng một tiền tố. Trong Shoal, chúng tôi có những quan sát sau về tất cả các giao thức này:
Tất cả các xác thực viên đều đồng ý với điểm neo thứ nhất theo thứ tự.
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 tế hơn có độ trễ tốt hơn so với phiên bản bất đồng bộ, nhưng nó vẫn còn xa mới đạt 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à các đỉnh của mỗi vòng lẻ được hiểu là bỏ phiếu. Trong trường hợp phổ biến, 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. 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: Tình trạng trễ sự cố. Nếu người lãnh đạo của 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 ( và do đó bị bỏ qua ), 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ờ để đợi người lãnh đạo.
Khung Shoal
Shoal đã cải tiến Bullshark( hoặc bất kỳ giao thức BFT nào dựa trên Narwhal thông qua đường ố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 cơ chế danh tiếng lãnh đạo không tốn kém trong DAG, làm cho việc lựa chọn nghiêng về lãnh đạo nhanh.
Thách thức
Trong bối cảnh giao thức DAG, vấn đề về đường ống và uy tín của người lãnh đạo được coi là những vấn đề khó khăn, lý do như sau:
Các nỗ lực trước đây để sửa đổi logic Bullshark cốt lõi dường như về bản chất là không thể.
Danh tiếng của người lãnh đạo được giới thiệu trong DiemBFT và chính thức hóa trong Carousel, là 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ề neo trong (. Mặc dù sự phân kỳ danh tính lãnh đạo không vi phạm tính an toàn của các giao thức này, nhưng có thể dẫn đến thứ tự hoàn toàn khác nhau trong Bullshark, điều này đặt ra vấn đề cốt lõi: việc chọn neo vòng một cách động và chắc chắn là cần thiết để giải quyết nhận thức chung, 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 neo tương lai.
Như bằng chứng về độ khó của vấn đề, chúng tôi nhận thấy rằng việc triển khai của Bullshark, bao gồm cả việc triển khai hiện tại trong môi trường sản xuất, không hỗ trợ những tính năng này.
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.
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 tất cả các xác thực viên đồng ý với cái nhìn cốt lõi về đ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ý theo chuỗi, khiến cho ) điểm neo có thứ tự đầu tiên là điểm chuyển đổi của các phiên bản, cũng như ( lịch sử nguyên nhân của các điểm neo dùng để tính toán danh tiếng của người lãnh đạo.
![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-46d37add0d9e81b2f295edf8eddd907f.webp(
Dòng chảy
V ánh xạ vòng đến người lãnh đạo. Shoal chạy lần lượt các phiên bản Bullshark, do đó đố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, 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à hoạt động 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ểm neo này. Do đó, tất cả các xác thực viên đều có thể chắc chắn đồng ý tái diễn giải DAG từ vòng r+1. Shoal chỉ khởi động 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 mỏ neo cho mỗi vòng. Mỏ neo của vòng đầu tiên được sắp xếp bởi 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 thể hiện sắp xếp, sau đó một thể hiện mới khác sắp xếp mỏ neo trong vòng thứ ba, sau đó quy 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 thời gian sắp xếp Bullshark, việc bỏ qua điểm neo sẽ làm tăng độ trễ. Trong trường hợp này, công nghệ ống dẫn không có tác dụng, vì không thể khởi động phiên bản mới trước khi sắp xếp điểm neo của phiên bản trước. Shoal đảm bảo rằng những 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 từng nút xác thực. Những người 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ì nó có thể gặp sự cố, chậm hoặc ác ý.
Triết lý của nó là trong mỗi lần cập nhật điểm 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ề người lãnh đạo có điểm số cao hơn. Để giúp các xác thực 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 trong lịch sử được sử dụng để phát sinh điểm số.
Trong Shoal, quy trình và uy tín lãnh đạo có thể kết hợp tự nhiên, vì chúng đều sử dụng cùng một công nghệ cốt lõi, đó là diễn giải lại DAG sau khi đạt được sự đồng thuận về điểm neo thứ nhất có thứ tự.
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 ở vòng thứ r, các xác thực viên 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ó thứ tự trong vòng thứ r. Sau đó, các nút xác thực sẽ thực hiện phiên bản mới của Bullshark từ vòng thứ r+1 bằng cách sử dụng hàm 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 thiểu độ 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ò quan trọng trong tất cả các triển khai BFT đồng bộ phần dựa trên người dẫn đầu. 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à giám sát, điều này làm tăng độ phức tạp của quá trình gỡ lỗi và yêu cầu 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 phải điều chỉnh động, vì nó phụ thuộc cao 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ả tiền phạt trễ thời gian chờ đầy đủ cho lãnh đạo bị lỗi. 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 lãnh đạo tốt. Ví dụ, chúng tôi quan sát thấy, trong các trường hợp tải cao, lãnh đạo trong Jolteon/Hotstuff không chịu nổi và thời gian chờ đã hết hạn trước khi họ thúc đẩy tiến trình.
Thật không may, các giao thức dựa trên lãnh đạo ) như Hotstuff và Jolteon ( về cơ bản cần có thời gian chờ, để đảm bảo rằng giao thức có thể tiến triển mỗi khi lãnh đạo gặp sự cố. Nếu không có thời gian chờ, ngay cả lãnh đạo bị sập cũng có thể dừng giao thức mãi mãi. Do không thể phân biệt lãnh đạo bị lỗi và lãnh đạo chậm trong thời gian không đồng bộ, thời gian chờ có thể dẫn đến các nút xác thực xem xét thay đổi tất cả lãnh đạo mà không có nhận thức chung.
Trong Bullshark, trễ được sử dụng để xây dựng DAG, nhằm đảm bảo rằng trong quá trình đồng bộ, các nhà lãnh đạo trung thực sẽ thêm điểm neo vào
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.
11 thích
Phần thưởng
11
6
Đăng lại
Chia sẻ
Bình luận
0/400
GateUser-c799715c
· 6giờ trước
Nâng cao hiệu suất khá tốt đấy~
Xem bản gốcTrả lời0
AllInAlice
· 9giờ trước
Là một người quyết đoán 40% giảm Trễ
Xem bản gốcTrả lời0
0xSherlock
· 9giờ trước
Trễ đợt này có thể xử lý đẹp trai một chút.
Xem bản gốcTrả lời0
BrokenYield
· 9giờ trước
thôi, một "tối ưu hóa" khác có lẽ sẽ tạo ra nhiều rủi ro hệ thống hơn là giải quyết... dòng tiền thông minh đã bắt đầu bảo hiểm chống lại điều này
Tối ưu hóa khung Shoal DAG nhận thức chung Thả đáng kể trễ Bullshark trên Aptos
Tối ưu hóa nhận thức chung DAG: Cách khung Shoal 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, thả đáng kể độ trễ và lần đầu tiên loại bỏ nhu cầu về thời gian chờ trong giao thức bất đồng bộ xác định. Tổng thể, khung Shoal đã cải thiện độ trễ của Bullshark 40% trong trường hợp không có lỗi và 80% trong trường hợp có lỗi.
Shoal là một giao thức đồng thuận dựa trên Narwhal được tăng cường thông qua đường ống và uy tín của người lãnh đạo ( như khung của DAG-Rider, Tusk, Bullshark ). Đường ống giảm thiểu độ trễ sắp xếp DAG bằng cách giới thiệu một điểm neo trong mỗi vòng, trong khi uy tín của người lãnh đạo cải thiện thêm độ trễ bằng cách đảm bảo rằng điểm neo được liên kết với các nút xác thực nhanh nhất. Hơn nữa, uy tín 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ỏ tất cả các tình huống thời gian chờ. Điều này khiến Shoal có khả năng cung cấp tính phản hồi phổ quát, bao gồm cả tính 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 phiên bản của giao thức cơ sở theo thứ tự. Khi sử dụng Bullshark để khởi tạo, chúng ta có một nhóm "cá mập" đang tham gia vào 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 thả độ phức tạp trong giao tiếp. Tuy nhiên, phương pháp này không dẫn đến việc tăng đáng kể 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 100k+ TPS.
Gần đây, sự đột phá 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 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 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à 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 đồ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 công suất 160.000 TPS.
Trong bài viết trước, chúng tôi đã giới thiệu về Quorum Store. Triển khai Narwhal của chúng tôi tách biệt việc truyền dữ liệu và 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 Jolteon. Jolteon là một giao thức dựa trên người dẫn dắt, kết hợp con đường nhanh tuyến tính của Tendermint và thay đổi tầm nhìn theo phong cách PBFT, có thể giảm thiểu độ trễ của Hotstuff xuống 33%. Tuy nhiên, giao thức nhận thức chung dựa trên người dẫn dắt rõ ràng 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à nhận thức chung, nhưng khi thông lượng tăng lên, người dẫn dắt của Hotstuff/Jolteon vẫn bị hạn chế.
Vì vậy, 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 chi phí truyền thông. Thật không may, so với Jolteon, cấu trúc DAG hỗ trợ Bullshark có 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 thả đá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, 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 sóng một đỉnh trong 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 không đồng bộ của mạng, các xác thực viên khác nhau có thể quan sát các cái 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 một đỉ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.
Toàn thứ tự
Có thể đạt được sự đồng thuận toàn thứ tự về 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 trình xác thực trong DAG-Rider, Tusk và Bullshark sẽ giải thích cấu trúc DAG như một giao thức nhận thức chung, 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 nhận thức chung dựa trên Narwhal hiện có đều có cấu trúc sau:
Điểm neo đã được đặt trước: cứ sau một vài vòng sẽ có một người lãnh đạo đã được xác định trước, đỉnh của nó được gọi là điểm neo.
Điểm neo sắp xếp: Các người xác thực độc lập nhưng một cách xác định quyết định sắp xếp những điểm neo nào và bỏ qua những điểm neo nào.
Sắp xếp lịch sử nguyên nhân: Các xác thực xử lý từng danh sách điểm neo có thứ 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 từng điểm neo.
Điều quan trọng để đảm bảo an toàn là đảm bảo rằng trong bước (2), danh sách các điểm neo có thứ tự được tạo bởi tất cả các nút xác thực trung thực chia sẻ cùng một tiền tố. Trong Shoal, chúng tôi có những quan sát sau về tất cả các giao thức này:
Tất cả các xác thực viên đều đồng ý với điểm neo thứ nhất theo thứ tự.
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 tế hơn có độ trễ tốt hơn so với phiên bản bất đồng bộ, nhưng nó vẫn còn xa mới đạt 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à các đỉnh của mỗi vòng lẻ được hiểu là bỏ phiếu. Trong trường hợp phổ biến, 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. 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: Tình trạng trễ sự cố. Nếu người lãnh đạo của 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 ( và do đó bị bỏ qua ), 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ờ để đợi người lãnh đạo.
Khung Shoal
Shoal đã cải tiến Bullshark( hoặc bất kỳ giao thức BFT nào dựa trên Narwhal thông qua đường ố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 cơ chế danh tiếng lãnh đạo không tốn kém trong DAG, làm cho việc lựa chọn nghiêng về lãnh đạo nhanh.
Thách thức
Trong bối cảnh giao thức DAG, vấn đề về đường ống và uy tín của người lãnh đạo được coi là những vấn đề khó khăn, lý do như sau:
Các nỗ lực trước đây để sửa đổi logic Bullshark cốt lõi dường như về bản chất là không thể.
Danh tiếng của người lãnh đạo được giới thiệu trong DiemBFT và chính thức hóa trong Carousel, là 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ề neo trong (. Mặc dù sự phân kỳ danh tính lãnh đạo không vi phạm tính an toàn của các giao thức này, nhưng có thể dẫn đến thứ tự hoàn toàn khác nhau trong Bullshark, điều này đặt ra vấn đề cốt lõi: việc chọn neo vòng một cách động và chắc chắn là cần thiết để giải quyết nhận thức chung, 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 neo tương lai.
Như bằng chứng về độ khó của vấn đề, chúng tôi nhận thấy rằng việc triển khai của Bullshark, bao gồm cả việc triển khai hiện tại trong môi trường sản xuất, không hỗ trợ những tính năng này.
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.
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 tất cả các xác thực viên đồng ý với cái nhìn cốt lõi về đ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ý theo chuỗi, khiến cho ) điểm neo có thứ tự đầu tiên là điểm chuyển đổi của các phiên bản, cũng như ( lịch sử nguyên nhân của các điểm neo dùng để tính toán danh tiếng của người lãnh đạo.
![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-46d37add0d9e81b2f295edf8eddd907f.webp(
Dòng chảy
V ánh xạ vòng đến người lãnh đạo. Shoal chạy lần lượt các phiên bản Bullshark, do đó đố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, 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à hoạt động 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ểm neo này. Do đó, tất cả các xác thực viên đều có thể chắc chắn đồng ý tái diễn giải DAG từ vòng r+1. Shoal chỉ khởi động 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 mỏ neo cho mỗi vòng. Mỏ neo của vòng đầu tiên được sắp xếp bởi 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 thể hiện sắp xếp, sau đó một thể hiện mới khác sắp xếp mỏ neo trong vòng thứ ba, sau đó quy 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 thời gian sắp xếp Bullshark, việc bỏ qua điểm neo sẽ làm tăng độ trễ. Trong trường hợp này, công nghệ ống dẫn không có tác dụng, vì không thể khởi động phiên bản mới trước khi sắp xếp điểm neo của phiên bản trước. Shoal đảm bảo rằng những 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 từng nút xác thực. Những người 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ì nó có thể gặp sự cố, chậm hoặc ác ý.
Triết lý của nó là trong mỗi lần cập nhật điểm 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ề người lãnh đạo có điểm số cao hơn. Để giúp các xác thực 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 trong lịch sử được sử dụng để phát sinh điểm số.
Trong Shoal, quy trình và uy tín lãnh đạo có thể kết hợp tự nhiên, vì chúng đều sử dụng cùng một công nghệ cốt lõi, đó là diễn giải lại DAG sau khi đạt được sự đồng thuận về điểm neo thứ nhất có thứ tự.
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 ở vòng thứ r, các xác thực viên 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ó thứ tự trong vòng thứ r. Sau đó, các nút xác thực sẽ thực hiện phiên bản mới của Bullshark từ vòng thứ r+1 bằng cách sử dụng hàm 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 thiểu độ 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ò quan trọng trong tất cả các triển khai BFT đồng bộ phần dựa trên người dẫn đầu. 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à giám sát, điều này làm tăng độ phức tạp của quá trình gỡ lỗi và yêu cầu 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 phải điều chỉnh động, vì nó phụ thuộc cao 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ả tiền phạt trễ thời gian chờ đầy đủ cho lãnh đạo bị lỗi. 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 lãnh đạo tốt. Ví dụ, chúng tôi quan sát thấy, trong các trường hợp tải cao, lãnh đạo trong Jolteon/Hotstuff không chịu nổi và thời gian chờ đã hết hạn trước khi họ thúc đẩy tiến trình.
Thật không may, các giao thức dựa trên lãnh đạo ) như Hotstuff và Jolteon ( về cơ bản cần có thời gian chờ, để đảm bảo rằng giao thức có thể tiến triển mỗi khi lãnh đạo gặp sự cố. Nếu không có thời gian chờ, ngay cả lãnh đạo bị sập cũng có thể dừng giao thức mãi mãi. Do không thể phân biệt lãnh đạo bị lỗi và lãnh đạo chậm trong thời gian không đồng bộ, thời gian chờ có thể dẫn đến các nút xác thực xem xét thay đổi tất cả lãnh đạo mà không có nhận thức chung.
Trong Bullshark, trễ được sử dụng để xây dựng DAG, nhằm đảm bảo rằng trong quá trình đồng bộ, các nhà lãnh đạo trung thực sẽ thêm điểm neo vào