Khung Shoal: Làm thế nào để Thả độ Trễ Bullshark trên Aptos?
Tổng quan
Aptos labs đã giải quyết hai vấn đề mở quan trọng trong DAG BFT, thả trễ một cách đáng kể và lần đầu tiên loại bỏ nhu cầu về thời gian chờ trong giao thức thực sự 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 framework cải thiện giao thức đồng thuận dựa trên Narwhal ( thông qua pipeline và uy tín của người lãnh đạo như DAG-Rider, Tusk, Bullshark ). Pipeline 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 đượ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ỏ 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 một thuộc tính gọi là phản hồi tổng quát, nó 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实例 của giao thức cơ sở theo thứ tự. Do đó, khi được khởi tạo bằng Bullshark, chúng ta có một nhóm "cá mập" đang tham gia cuộc tiếp sức.
Động lực
Trong quá trình theo đuổi hiệu suất cao của mạng blockchain, mọi người luôn chú ý đến việc thả độ phức tạp trong giao tiếp. Tuy nhiên, phương pháp này không dẫn đến sự tăng trưởng đá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.
Gần đây, sự đột phá đế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 và 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 khỏi logic đồng thuận cốt lõi, đưa ra một kiến trúc trong đó tất cả các xác thực viên đều truyền dữ liệu cùng một lúc, 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 lên tới 160,000 TPS.
Trong bài viết trước, chúng tôi đã giới thiệu Quorum Store. Triển khai Narwhal của chúng tôi tách biệt việc truyền dữ liệu và đồng thuận, cũng như cách chúng tôi sử dụng nó để mở rộng giao thức đồng thuận hiện tại Jolteon. Jolteon là một giao thức dựa trên người lãnh đạo, kết hợp con đường nhanh tuyến tính của Tendermint và thay đổi quan điểm theo phong cách PBFT, có thể giảm độ trễ của Hotstuff xuống 33%. Tuy nhiên, rõ ràng là giao thức đồng thuận dựa trên người lãnh đạo không thể tận dụng đầy đủ tiềm năng thông lượng của Narwhal. Mặc dù việc truyền dữ liệu và đồng thuận được tách biệt, 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 đó, chúng tôi quyết định triển khai Bullshark trên Narwhal DAG, đây là một giao thức đồng thuận với chi phí giao tiếp bằng khô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ực hiện giảm thiểu trễ Bullshark một cách đáng kể.
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, người xác thực phải trước tiên có được n-f đỉnh thuộc vòng thứ r-1. Mỗi người xác thực 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 bất đồng bộ của mạng, các người xác thực khác nhau có thể quan sát các view địa phương khác nhau của DAG tại bất kỳ thời điểm nào.
Một thuộc tính chính của DAG là không mơ hồ: nếu hai nút xác thực có cùng đỉnh v trong chế độ xem địa phương của chúng về DAG, thì chúng có lịch sử nguyên nhân v hoàn toàn giống nhau.
Xếp hạng 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ó chi phí giao tiếp bổ sung. Để làm điều này, các xác nhận viên trong DAG-Rider, Tusk và Bullshark sẽ giải thích cấu trúc của DAG như một giao thức đồng thuận, trong đó các đỉnh đại diện cho 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 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 (, ví dụ, trong Bullshark, sẽ có một nhà lãnh đạo được xác định trước cho hai vòng ), đỉ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 nhận viên độc lập nhưng một cách chắc chắn quyết định đặt hàng 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 viên lần lượt xử lý danh sách điểm neo có thứ tự của họ, và đối với mỗi điểm neo, họ 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ó thông qua một số quy tắc xác định.
Điều quan trọng để đảm bảo an ninh là đảm bảo rằng trong bước (2), tất cả các nút xác thực trung thực tạo ra một danh sách điểm neo có thứ tự, để tất cả các danh sách chia sẻ cùng một tiền tố. Trong Shoal, chúng tôi đưa ra những quan sát sau về tất cả các giao thức nêu trên:
Tất cả các xác thực đề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 phần 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 nó vẫn còn xa mới đạt được tối ưu.
Vấn đề 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à một cuộc bỏ phiếu. Trong trường hợp thông thường, cần hai vòng DAG để sắp xếp điểm neo, tuy nhiên, đỉnh trong lịch sử nguyên nhân của điểm neo cần nhiều vòng hơn để đợi điểm neo được sắp xếp. Trong trường hợp thông thường, đỉnh trong vòng lẻ cần ba vòng, trong khi đỉ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 nhà lãnh đạo trong một vòng không đủ nhanh để 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 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 thời gian chờ được sử dụng để 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 việc lập kê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 việc lựa chọn nghiêng về các lãnh đạo nhanh chóng.
Thách thức
Trong bối cảnh của giao thức DAG, vấn đề đường ống và uy tín của người lãnh đạo được coi là khó khăn, lý do như sau:
Trước đây, dây chuyền sản xuất đã cố gắng sửa đổi logic Bullshark cốt lõi, nhưng điều này về bản chất dường như là không thể.
Danh tiếng của người lãnh đạo được giới thiệu trong DiemBFT và chính thức hóa trong Carousel, 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 ý tưởng về neo trong Bullshark (. Mặc dù sự khác biệt trong danh tính lãnh đạo không vi phạm tính bảo mật của các giao thức này, nhưng trong Bullshark, điều đó có thể dẫn đến thứ tự hoàn toàn khác, điều này gợi ra vấn đề cốt lõi, đó là việc lựa chọn động và xác định các neo vòng là cần thiết để giải quyết sự đồng thuận, trong khi các xác thực viên cần đạt được sự đồng nhất về lịch sử có trật tự để lựa chọn các neo tương lai.
Là bằng chứng cho độ khó của vấn đề, chúng tôi nhận thấy rằng việc thực hiện 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.
![Giải thích chi tiết về khung Shoal: Làm thế nào để thả Bullshark trên Aptos?])https://img-cdn.gateio.im/webp-social/moments-0b0928cb6240e994c1514c75e080a4b2.webp(
Thỏa thuận
Mặc dù có những thách thức trên, nhưng như người ta thường nói, sự thật là giải pháp ẩn chứa trong sự đơn giản.
Trong Shoal, chúng tôi dựa vào khả năng thực hiện tính toán cục bộ trên DAG và đã hiện thực hóa khả năng lưu trữ và diễn giải lại thông tin của các vòng trước. Với sự đồng ý của tất cả các xác thực viên về cái nhìn cốt lõi của điểm neo có thứ tự đầu tiên, Shoal kết hợp tuần tự nhiều实例 Bullshark và thực hiện xử lý theo chuỗi, khiến cho ) điểm neo có thứ tự đầu tiên là điểm chuyển giao của các实例, cũng như ( lịch sử nguyên nhân của các điểm neo được sử dụng để tính toán danh tiếng của người lãnh đạo.
Dòng chảy
V ánh xạ các vòng đến người lãnh đạo. Shoal chạy lần lượt các phiên bản của 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 đặ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à 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ể chắc chắn đồng ý rằng bắt đầu từ vòng r+1, sẽ diễn giải lại DAG. 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 một móc neo trong mỗi vòng. Điểm neo của vòng đầu tiên được sắp xếp theo phiên bản đầu tiên. Sau đó, Shoal bắt đầu một phiên bản mới trong vòng thứ hai, nó có một điểm neo, điểm neo đó được sắp xếp bởi phiên bản đó, sau đó, một phiên bản mới khác đặt đ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 lãnh đạo
Trong quá trình sắp xếp Bullshark, khi bỏ qua điểm neo, Trễ sẽ tăng lên. Trong trường hợp này, công nghệ pipeline không thể làm gì vì không thể khởi động một thể hiện mới trước khi đặt hàng điểm neo trước đó. Shoal đảm bảo rằng các lãnh đạo tương ứng ít có khả năng được chọn để xử lý các điểm neo bị mất trong tương lai bằng cách sử dụng cơ chế tín nhiệm để 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 đáp ứng 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 xấu.
Ý tưởng của nó là trong 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ạ đã được định nghĩa từ vòng đến người lãnh đạo F, 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 có thể đạ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 trên lịch sử được sử dụng để sinh ra điểm số.
Trong Shoal, quy trình và uy tín lãnh đạo có thể kết hợp một cách tự nhiên, vì chúng đều sử dụng cùng một công nghệ cốt lõi, đó là tái giải thích 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 thứ r, các xác thực 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ẽ sử dụng hàm 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 vượt quá đóng vai trò quan trọng trong tất cả các triển khai BFT đồng bộ phần định hướng dựa trên leader. Tuy nhiên, sự phức tạp mà chúng mang lại đã tăng số lượng trạng thái nội bộ cần được 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 phù 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 lãnh đạo tiếp theo, giao thức sẽ chịu phạt trễ toàn bộ 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
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.
14 thích
Phần thưởng
14
6
Đăng lại
Chia sẻ
Bình luận
0/400
SlowLearnerWang
· 16giờ trước
Trễ giảm 40%...bug này sửa thật là bò nhỉ?
Xem bản gốcTrả lời0
NFTArchaeologis
· 16giờ trước
Như những dấu ấn của văn tự giáp cốt khắc trên các khối chuỗi số, khung của Shoal cách mạng hóa khi bị ô nhiễm.
Xem bản gốcTrả lời0
PumpDetector
· 16giờ trước
hmm bullshark đang nhanh hơn nhưng vẫn đọc giữa các dòng... có gì đó không ổn thật sự
Tối ưu hóa khung Shoal Nhận thức chung Aptos Thả đáng kể trễ Bullshark
Khung Shoal: Làm thế nào để Thả độ Trễ Bullshark trên Aptos?
Tổng quan
Aptos labs đã giải quyết hai vấn đề mở quan trọng trong DAG BFT, thả trễ một cách đáng kể và lần đầu tiên loại bỏ nhu cầu về thời gian chờ trong giao thức thực sự 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 framework cải thiện giao thức đồng thuận dựa trên Narwhal ( thông qua pipeline và uy tín của người lãnh đạo như DAG-Rider, Tusk, Bullshark ). Pipeline 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 đượ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ỏ 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 một thuộc tính gọi là phản hồi tổng quát, nó 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实例 của giao thức cơ sở theo thứ tự. Do đó, khi được khởi tạo bằng Bullshark, chúng ta có một nhóm "cá mập" đang tham gia cuộc tiếp sức.
Động lực
Trong quá trình theo đuổi hiệu suất cao của mạng blockchain, mọi người luôn chú ý đến việc thả độ phức tạp trong giao tiếp. Tuy nhiên, phương pháp này không dẫn đến sự tăng trưởng đá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.
Gần đây, sự đột phá đế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 và 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 khỏi logic đồng thuận cốt lõi, đưa ra một kiến trúc trong đó tất cả các xác thực viên đều truyền dữ liệu cùng một lúc, 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 lên tới 160,000 TPS.
Trong bài viết trước, chúng tôi đã giới thiệu Quorum Store. Triển khai Narwhal của chúng tôi tách biệt việc truyền dữ liệu và đồng thuận, cũng như cách chúng tôi sử dụng nó để mở rộng giao thức đồng thuận hiện tại Jolteon. Jolteon là một giao thức dựa trên người lãnh đạo, kết hợp con đường nhanh tuyến tính của Tendermint và thay đổi quan điểm theo phong cách PBFT, có thể giảm độ trễ của Hotstuff xuống 33%. Tuy nhiên, rõ ràng là giao thức đồng thuận dựa trên người lãnh đạo không thể tận dụng đầy đủ tiềm năng thông lượng của Narwhal. Mặc dù việc truyền dữ liệu và đồng thuận được tách biệt, 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 đó, chúng tôi quyết định triển khai Bullshark trên Narwhal DAG, đây là một giao thức đồng thuận với chi phí giao tiếp bằng khô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ực hiện giảm thiểu trễ Bullshark một cách đáng kể.
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, người xác thực phải trước tiên có được n-f đỉnh thuộc vòng thứ r-1. Mỗi người xác thực 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 bất đồng bộ của mạng, các người xác thực khác nhau có thể quan sát các view địa phương khác nhau của DAG tại bất kỳ thời điểm nào.
Một thuộc tính chính của DAG là không mơ hồ: nếu hai nút xác thực có cùng đỉnh v trong chế độ xem địa phương của chúng về DAG, thì chúng có lịch sử nguyên nhân v hoàn toàn giống nhau.
Xếp hạng 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ó chi phí giao tiếp bổ sung. Để làm điều này, các xác nhận viên trong DAG-Rider, Tusk và Bullshark sẽ giải thích cấu trúc của DAG như một giao thức đồng thuận, trong đó các đỉnh đại diện cho 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 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 (, ví dụ, trong Bullshark, sẽ có một nhà lãnh đạo được xác định trước cho hai vòng ), đỉ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 nhận viên độc lập nhưng một cách chắc chắn quyết định đặt hàng 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 viên lần lượt xử lý danh sách điểm neo có thứ tự của họ, và đối với mỗi điểm neo, họ 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ó thông qua một số quy tắc xác định.
Điều quan trọng để đảm bảo an ninh là đảm bảo rằng trong bước (2), tất cả các nút xác thực trung thực tạo ra một danh sách điểm neo có thứ tự, để tất cả các danh sách chia sẻ cùng một tiền tố. Trong Shoal, chúng tôi đưa ra những quan sát sau về tất cả các giao thức nêu trên:
Tất cả các xác thực đề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 phần 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 nó vẫn còn xa mới đạt được tối ưu.
Vấn đề 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à một cuộc bỏ phiếu. Trong trường hợp thông thường, cần hai vòng DAG để sắp xếp điểm neo, tuy nhiên, đỉnh trong lịch sử nguyên nhân của điểm neo cần nhiều vòng hơn để đợi điểm neo được sắp xếp. Trong trường hợp thông thường, đỉnh trong vòng lẻ cần ba vòng, trong khi đỉ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 nhà lãnh đạo trong một vòng không đủ nhanh để 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 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 thời gian chờ được sử dụng để 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 việc lập kê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 việc lựa chọn nghiêng về các lãnh đạo nhanh chóng.
Thách thức
Trong bối cảnh của giao thức DAG, vấn đề đường ống và uy tín của người lãnh đạo được coi là khó khăn, lý do như sau:
Trước đây, dây chuyền sản xuất đã cố gắng sửa đổi logic Bullshark cốt lõi, nhưng điều này về bản chất dường như là không thể.
Danh tiếng của người lãnh đạo được giới thiệu trong DiemBFT và chính thức hóa trong Carousel, 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 ý tưởng về neo trong Bullshark (. Mặc dù sự khác biệt trong danh tính lãnh đạo không vi phạm tính bảo mật của các giao thức này, nhưng trong Bullshark, điều đó có thể dẫn đến thứ tự hoàn toàn khác, điều này gợi ra vấn đề cốt lõi, đó là việc lựa chọn động và xác định các neo vòng là cần thiết để giải quyết sự đồng thuận, trong khi các xác thực viên cần đạt được sự đồng nhất về lịch sử có trật tự để lựa chọn các neo tương lai.
Là bằng chứng cho độ khó của vấn đề, chúng tôi nhận thấy rằng việc thực hiện 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.
![Giải thích chi tiết về khung Shoal: Làm thế nào để thả Bullshark trên Aptos?])https://img-cdn.gateio.im/webp-social/moments-0b0928cb6240e994c1514c75e080a4b2.webp(
Thỏa thuận
Mặc dù có những thách thức trên, nhưng như người ta thường nói, sự thật là giải pháp ẩn chứa trong sự đơn giản.
Trong Shoal, chúng tôi dựa vào khả năng thực hiện tính toán cục bộ trên DAG và đã hiện thực hóa khả năng lưu trữ và diễn giải lại thông tin của các vòng trước. Với sự đồng ý của tất cả các xác thực viên về cái nhìn cốt lõi của điểm neo có thứ tự đầu tiên, Shoal kết hợp tuần tự nhiều实例 Bullshark và thực hiện xử lý theo chuỗi, khiến cho ) điểm neo có thứ tự đầu tiên là điểm chuyển giao của các实例, cũng như ( lịch sử nguyên nhân của các điểm neo được sử dụng để tính toán danh tiếng của người lãnh đạo.
Dòng chảy
V ánh xạ các vòng đến người lãnh đạo. Shoal chạy lần lượt các phiên bản của 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 đặ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à 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ể chắc chắn đồng ý rằng bắt đầu từ vòng r+1, sẽ diễn giải lại DAG. 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 một móc neo trong mỗi vòng. Điểm neo của vòng đầu tiên được sắp xếp theo phiên bản đầu tiên. Sau đó, Shoal bắt đầu một phiên bản mới trong vòng thứ hai, nó có một điểm neo, điểm neo đó được sắp xếp bởi phiên bản đó, sau đó, một phiên bản mới khác đặt đ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 lãnh đạo
Trong quá trình sắp xếp Bullshark, khi bỏ qua điểm neo, Trễ sẽ tăng lên. Trong trường hợp này, công nghệ pipeline không thể làm gì vì không thể khởi động một thể hiện mới trước khi đặt hàng điểm neo trước đó. Shoal đảm bảo rằng các lãnh đạo tương ứng ít có khả năng được chọn để xử lý các điểm neo bị mất trong tương lai bằng cách sử dụng cơ chế tín nhiệm để 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 đáp ứng 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 xấu.
Ý tưởng của nó là trong 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ạ đã được định nghĩa từ vòng đến người lãnh đạo F, 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 có thể đạ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 trên lịch sử được sử dụng để sinh ra điểm số.
Trong Shoal, quy trình và uy tín lãnh đạo có thể kết hợp một cách tự nhiên, vì chúng đều sử dụng cùng một công nghệ cốt lõi, đó là tái giải thích 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 thứ r, các xác thực 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ẽ sử dụng hàm 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 vượt quá đóng vai trò quan trọng trong tất cả các triển khai BFT đồng bộ phần định hướng dựa trên leader. Tuy nhiên, sự phức tạp mà chúng mang lại đã tăng số lượng trạng thái nội bộ cần được 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 phù 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 lãnh đạo tiếp theo, giao thức sẽ chịu phạt trễ toàn bộ 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