Khung Shoal: Làm thế nào để Thả độ Trễ Bullshark trên Aptos?
Tóm tắt
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 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, đã cải thiện trễ của Bullshark lên 40%, và trong trường hợp có lỗi, đã cải thiện 80%.
Shoal là một khung, thông qua ống dẫn và uy tín của người 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 ). Ống dẫn 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, và uy tín của người lãnh đạo cải thiện thêm vấn đề độ trễ bằng cách đảm bảo rằng điểm neo liên kết với 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ỏ thời gian chờ trong tất cả các kịch bản. Điều này cho phép Shoal cung cấp thuộc tính phản hồi phổ quát, bao gồm cả 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 tuần tự nhiều phiên bản của giao thức cơ sở. Do đó, khi khởi tạo với Bullshark, chúng ta có một nhóm "cá mập" đang tham gia một cuộc tiếp sức.
Động cơ
Trong việc theo đuổi hiệu suất cao của mạng blockchain, 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 nâng cao đáng kể 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.
Gần đây, sự đột phá bắt nguồn từ việc nhận ra rằng việc truyền dữ liệu là nút thắt chính của giao thức lãnh đạo, có thể hưởng lợi từ việc phân cấp. 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 truyền dữ liệu đồng thời, trong khi thành phần đồng thuận chỉ đặt hàng 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.
Trước đây đã giới thiệu về Quorum Store, tách biệt việc phát tán dữ liệu và sự đồ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 nhà lãnh đạo, kết hợp con đường nhanh tuyến tính của Tendermint và sự thay đổi quan điểm theo phong cách PBFT, có thể làm Thả độ trễ của Hotstuff xuống 33%. Tuy nhiên, giao thức đồng thuận dựa trên nhà 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 phát tán dữ liệu và sự đồng thuận, khi thông lượng tăng lên, nhà lãnh đạo của Hotstuff/Jolteon vẫn bị giới hạn.
Do đó, quyết định triển khai Bullshark, một giao thức đồng thuận không có 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 giới thiệu cách Shoal giảm đáng kể trễ của Bullshark.
Bối cảnh DAG-BFT
Trong Narwhal DAG, mỗi đỉnh đều liên kết với số vòng. Để vào vòng thứ r, người xác thực phải trước tiên nhận được n-f đỉnh thuộc vòng thứ r-1. Mỗi người xác thực có thể phát 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 không đồng bộ của mạng, các người xác thực khác nhau có thể quan sát các khung 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 cái nhìn cục bộ của DAG, thì chúng có lịch sử nguyên nhân v hoàn toàn giống nhau.
Tổng thứ tự
Có thể đạt được sự đồng thuận về thứ tự tổng thể của tất cả các đỉnh trong DAG mà không có chi phí giao tiếp 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 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 giữa các nhóm trên cấu trúc DAG là 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 đã được đặt trước: Cứ sau vài vòng ( như trong Bullshark, sẽ có một nhà lãnh đạo được xác định trước cho mỗi hai vòng ), đỉnh của nó được gọi là điểm neo.
Điểm neo sắp xếp: Các nhà xác thực độc lập nhưng chắc chắn quyết định thứ tự các điểm neo nào và bỏ qua những điểm nào.
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 không có thứ tự trước đó trong lịch sử nguyên nhân của nó theo các quy tắc xác định.
Yêu cầu quan trọng để đả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 danh sách các điểm neo có thứ tự, khiến tất cả các danh sách chia sẻ cùng một tiền tố. Trong Shoal, có các 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ễ
Độ 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 phiên bản bất đồng bộ, nhưng vẫn chưa phải là tốt nhất.
Câu hỏi 1: Độ trễ khối trung bình. Trong Bullshark, mỗi vòng chẵn có điểm neo, mỗi đỉnh của 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 đ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, 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ường hợp lỗi trễ, 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 một vòng lãnh đạo không đủ nhanh để phát sóng điểm neo, thì không thể sắp xếp điểm neo ( do đó bị bỏ qua ), tất cả các đỉnh chưa được sắp xếp trong những vòng trước phải chờ đợi điểm neo tiếp theo được sắp xếp. Điều này 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ờ 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 việc sử dụng pipeline, cho phép có đ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 làm cho việc lựa chọn thiên về lãnh đạo nhanh.
Thách thức
Trong bối cảnh giao thức DAG, độ tin cậy của pipeline và leader được coi là vấn đề khó khăn, lý do như sau:
Các 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 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, là việc chọn lựa người lãnh đạo tương lai một cách động dựa trên hiệu suất trong quá khứ của các validator trong (Bullshark, với ý 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 của các giao thức này, nhưng trong Bullshark có thể dẫn đến thứ tự hoàn toàn khác nhau, điều này nêu bật vấn đề cốt lõi, tức là việc chọn mỏ neo theo cách động và xác định là cần thiết để giải quyết sự đồng thuận, trong khi các validator cần đạt được sự đồng thuận về lịch sử có thứ tự để 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, đề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 nêu trên, nhưng giải pháp ẩn chứa sau những điều đơ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à giải thích lạ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 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ý 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 điểm neo được sử dụng để tính toán danh tiếng của các nhà lãnh đạo.
Dòng chảy
V để ánh xạ vòng thành leader. Shoal chạy các instance của Bullshark lần lượt, do đó đối với mỗi instance, điểm neo được xác định trước bởi ánh xạ F. Mỗi instance đặt hàng một điểm neo, điều này sẽ kích hoạt việc chuyển sang instance 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 người xác thực đều đồng ý về điểm neo này. Do đó, tất cả các người xác thực có thể đồng ý một cách chắc chắn để bắt đầu giải thích lại DAG 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. Điểm neo của vòng đầu tiên được sắp xếp theo thể hiện đầu tiên. Sau đó, Shoal bắt đầu một thể hiện mới trong vòng thứ hai, nó có một điểm neo, cái neo được sắp xếp bởi thể hiện đó, sau đó, một thể hiện 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.
Danh tiếng lãnh đạo
Trong quá trình 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 ống không thể phát huy tác dụng, vì không thể khởi động phiên bản mới trước khi đặt hàng đ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à không cao 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 mỗi nút xác thực. Các xác thực viên phản hồi và tham gia vào giao thức sẽ nhận được điểm cao, 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 gây hại.
Ý 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ạ F đã được định nghĩa trước 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 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 để tạo ra điểm số.
Trong Shoal, dòng chảy và danh tiếng 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à giải thích lại DAG sau khi đạt được sự đồng thuận tại điểm neo thứ tự đầu tiê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 r, các xác thực viên chỉ cần 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 r, để tính toán ánh xạ mới F' bắt đầu từ vòng r+1. Sau đó, các nút xác thực bắt đầu từ vòng r+1 sẽ thực hiện các phiên bản mới của Bullshark bằng cách sử dụng hàm lựa chọn điểm neo được cập nhật F'.
Không còn thời gian chờ nữa
Thời gian trễ đóng vai trò quan trọng trong tất cả các triển khai BFT đồng bộ phần tử xác định dựa trên 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 phải quản lý và quan sát, điều này làm tăng độ phức tạp của quá trình gỡ lỗi và cần nhiều kỹ thuật quan sát hơn.
Thời gian chờ cũng sẽ làm tăng đáng kể trễ, vì việc cấu hình chúng một cách thích hợp là rất quan trọng, và thường cần điều chỉnh động, vì nó phụ thuộc rất nhiều vào môi trường ( mạng ). Trước khi chuyển sang nhà lãnh đạo tiếp theo, giao thức sẽ trả toàn bộ hình phạt trễ do thời gian chờ cho nhà 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 những nhà 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, nhà lãnh đạo trong Jolteon/Hotstuff không thể chịu đựng và thời gian chờ đã hết trước khi họ thúc đẩy tiến trình.
Thật không may, các giao thức của người 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 người lãnh đạo gặp sự cố. Nếu không có thời gian chờ, ngay cả người 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 được trong thời gian bất đồng bộ.
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.
23 thích
Phần thưởng
23
6
Chia sẻ
Bình luận
0/400
VirtualRichDream
· 07-25 11:15
Trễ降这么多 aptos要To da moon了
Xem bản gốcTrả lời0
CoffeeNFTs
· 07-22 19:02
Cái thả trễ này có vẻ hấp dẫn nhỉ
Xem bản gốcTrả lời0
RugDocDetective
· 07-22 19:01
Quá tuyệt vời, đã chờ lâu lắm rồi mà cuối cùng giải pháp Aptos cũng ra mắt!
Xem bản gốcTrả lời0
RuntimeError
· 07-22 19:00
aptos cách mới này liệu có hiệu quả không
Xem bản gốcTrả lời0
UnluckyValidator
· 07-22 18:58
Trễ cao cuối cùng cũng đã đến hồi kết, mệt mỏi suốt nửa năm.
Khung Shoal thả đáng kể độ trễ Bullshark trên Aptos on-chain tăng 40-80%
Khung Shoal: Làm thế nào để Thả độ Trễ Bullshark trên Aptos?
Tóm tắt
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 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, đã cải thiện trễ của Bullshark lên 40%, và trong trường hợp có lỗi, đã cải thiện 80%.
Shoal là một khung, thông qua ống dẫn và uy tín của người 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 ). Ống dẫn 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, và uy tín của người lãnh đạo cải thiện thêm vấn đề độ trễ bằng cách đảm bảo rằng điểm neo liên kết với 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ỏ thời gian chờ trong tất cả các kịch bản. Điều này cho phép Shoal cung cấp thuộc tính phản hồi phổ quát, bao gồm cả 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 tuần tự nhiều phiên bản của giao thức cơ sở. Do đó, khi khởi tạo với Bullshark, chúng ta có một nhóm "cá mập" đang tham gia một cuộc tiếp sức.
Động cơ
Trong việc theo đuổi hiệu suất cao của mạng blockchain, 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 nâng cao đáng kể 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.
Gần đây, sự đột phá bắt nguồn từ việc nhận ra rằng việc truyền dữ liệu là nút thắt chính của giao thức lãnh đạo, có thể hưởng lợi từ việc phân cấp. 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 truyền dữ liệu đồng thời, trong khi thành phần đồng thuận chỉ đặt hàng 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.
Trước đây đã giới thiệu về Quorum Store, tách biệt việc phát tán dữ liệu và sự đồ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 nhà lãnh đạo, kết hợp con đường nhanh tuyến tính của Tendermint và sự thay đổi quan điểm theo phong cách PBFT, có thể làm Thả độ trễ của Hotstuff xuống 33%. Tuy nhiên, giao thức đồng thuận dựa trên nhà 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 phát tán dữ liệu và sự đồng thuận, khi thông lượng tăng lên, nhà lãnh đạo của Hotstuff/Jolteon vẫn bị giới hạn.
Do đó, quyết định triển khai Bullshark, một giao thức đồng thuận không có 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 giới thiệu cách Shoal giảm đáng kể trễ của Bullshark.
Bối cảnh DAG-BFT
Trong Narwhal DAG, mỗi đỉnh đều liên kết với số vòng. Để vào vòng thứ r, người xác thực phải trước tiên nhận được n-f đỉnh thuộc vòng thứ r-1. Mỗi người xác thực có thể phát 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 không đồng bộ của mạng, các người xác thực khác nhau có thể quan sát các khung 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 cái nhìn cục bộ của DAG, thì chúng có lịch sử nguyên nhân v hoàn toàn giống nhau.
Tổng thứ tự
Có thể đạt được sự đồng thuận về thứ tự tổng thể của tất cả các đỉnh trong DAG mà không có chi phí giao tiếp 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 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 giữa các nhóm trên cấu trúc DAG là 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 đã được đặt trước: Cứ sau vài vòng ( như trong Bullshark, sẽ có một nhà lãnh đạo được xác định trước cho mỗi hai vòng ), đỉnh của nó được gọi là điểm neo.
Điểm neo sắp xếp: Các nhà xác thực độc lập nhưng chắc chắn quyết định thứ tự các điểm neo nào và bỏ qua những điểm nào.
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 không có thứ tự trước đó trong lịch sử nguyên nhân của nó theo các quy tắc xác định.
Yêu cầu quan trọng để đả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 danh sách các điểm neo có thứ tự, khiến tất cả các danh sách chia sẻ cùng một tiền tố. Trong Shoal, có các 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ễ
Độ 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 phiên bản bất đồng bộ, nhưng vẫn chưa phải là tốt nhất.
Câu hỏi 1: Độ trễ khối trung bình. Trong Bullshark, mỗi vòng chẵn có điểm neo, mỗi đỉnh của 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 đ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, 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ường hợp lỗi trễ, 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 một vòng lãnh đạo không đủ nhanh để phát sóng điểm neo, thì không thể sắp xếp điểm neo ( do đó bị bỏ qua ), tất cả các đỉnh chưa được sắp xếp trong những vòng trước phải chờ đợi điểm neo tiếp theo được sắp xếp. Điều này 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ờ 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 việc sử dụng pipeline, cho phép có đ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 làm cho việc lựa chọn thiên về lãnh đạo nhanh.
Thách thức
Trong bối cảnh giao thức DAG, độ tin cậy của pipeline và leader được coi là vấn đề khó khăn, lý do như sau:
Các 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 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, là việc chọn lựa người lãnh đạo tương lai một cách động dựa trên hiệu suất trong quá khứ của các validator trong (Bullshark, với ý 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 của các giao thức này, nhưng trong Bullshark có thể dẫn đến thứ tự hoàn toàn khác nhau, điều này nêu bật vấn đề cốt lõi, tức là việc chọn mỏ neo theo cách động và xác định là cần thiết để giải quyết sự đồng thuận, trong khi các validator cần đạt được sự đồng thuận về lịch sử có thứ tự để 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, đề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 nêu trên, nhưng giải pháp ẩn chứa sau những điều đơ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à giải thích lạ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 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ý 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 điểm neo được sử dụng để tính toán danh tiếng của các nhà lãnh đạo.
Dòng chảy
V để ánh xạ vòng thành leader. Shoal chạy các instance của Bullshark lần lượt, do đó đối với mỗi instance, điểm neo được xác định trước bởi ánh xạ F. Mỗi instance đặt hàng một điểm neo, điều này sẽ kích hoạt việc chuyển sang instance 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 người xác thực đều đồng ý về điểm neo này. Do đó, tất cả các người xác thực có thể đồng ý một cách chắc chắn để bắt đầu giải thích lại DAG 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. Điểm neo của vòng đầu tiên được sắp xếp theo thể hiện đầu tiên. Sau đó, Shoal bắt đầu một thể hiện mới trong vòng thứ hai, nó có một điểm neo, cái neo được sắp xếp bởi thể hiện đó, sau đó, một thể hiện 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.
Danh tiếng lãnh đạo
Trong quá trình 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 ống không thể phát huy tác dụng, vì không thể khởi động phiên bản mới trước khi đặt hàng đ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à không cao 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 mỗi nút xác thực. Các xác thực viên phản hồi và tham gia vào giao thức sẽ nhận được điểm cao, 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 gây hại.
Ý 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ạ F đã được định nghĩa trước 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 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 để tạo ra điểm số.
Trong Shoal, dòng chảy và danh tiếng 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à giải thích lại DAG sau khi đạt được sự đồng thuận tại điểm neo thứ tự đầu tiê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 r, các xác thực viên chỉ cần 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 r, để tính toán ánh xạ mới F' bắt đầu từ vòng r+1. Sau đó, các nút xác thực bắt đầu từ vòng r+1 sẽ thực hiện các phiên bản mới của Bullshark bằng cách sử dụng hàm lựa chọn điểm neo được cập nhật F'.
Không còn thời gian chờ nữa
Thời gian trễ đóng vai trò quan trọng trong tất cả các triển khai BFT đồng bộ phần tử xác định dựa trên 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 phải quản lý và quan sát, điều này làm tăng độ phức tạp của quá trình gỡ lỗi và cần nhiều kỹ thuật quan sát hơn.
Thời gian chờ cũng sẽ làm tăng đáng kể trễ, vì việc cấu hình chúng một cách thích hợp là rất quan trọng, và thường cần điều chỉnh động, vì nó phụ thuộc rất nhiều vào môi trường ( mạng ). Trước khi chuyển sang nhà lãnh đạo tiếp theo, giao thức sẽ trả toàn bộ hình phạt trễ do thời gian chờ cho nhà 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 những nhà 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, nhà lãnh đạo trong Jolteon/Hotstuff không thể chịu đựng và thời gian chờ đã hết trước khi họ thúc đẩy tiến trình.
Thật không may, các giao thức của người 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 người lãnh đạo gặp sự cố. Nếu không có thời gian chờ, ngay cả người 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 được trong thời gian bất đồng bộ.