Khung Shoal: Giảm đáng kể 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 lên 80%.
Shoal là một khung để tăng cường bất kỳ 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. Pipeline 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, 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 quan đến 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 kịch bản hết thời gian. Điều này cho phép Shoal cung cấp thuộc tính phản hồi toàn cầu, 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 nhiều phiên bản của giao thức cơ sở theo thứ tự. Do đó, khi được khởi tạo với Bullshark, chúng ta có đượ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 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.
Sự đột phá gần đây xuất phát từ việc nhận ra rằng việc truyền dữ liệu là nút thắt chính dựa trên giao thức lãnh đạo, có thể hưởng lợi từ sự song song hóa. Hệ thống Narwhal tách biệt việc truyền dữ liệu với logic đồng thuận, đề xuất một kiến trúc mà tất cả các xác thực viên đều truyền dữ liệu đồng thời, 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 về Narwhal báo cáo khả năng thông lượng 160.000 TPS.
Trước đây, chúng tôi đã giới thiệu Quorum Store, việc triển khai Narwhal của chúng tôi tách biệt việc truyền dữ liệu với 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 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 phong cách PBFT, giảm độ trễ của Hotstuff xuống 33%. Tuy nhiên, các giao thức đồng thuận dựa trên 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à sự đồng thuận được tách biệt, nhưng khi thông lượng tăng lên, 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, một giao thức đồng thuận không tốn kém truyền thông, 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
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 có được n-f đỉnh thuộc vòng r-1. Mỗi xác thực viên có thể phát sóng một đỉnh mỗi vòng, mỗi đỉnh ít nhất phải tham chiếu đến n-f đỉnh của vòng trước. Do tính bất đồng bộ của mạng, các xác thực viên khác nhau có thể quan sát các góc 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 không phải là mơ hồ: nếu hai nút xác thực có cùng đỉnh v trong cái nhìn địa phương của chúng về DAG, thì chúng có lịch sử nguyên nhân v hoàn toàn giống nhau.
Tổng tự
Có thể đạt được sự đồng thuận về thứ tự tổng thể của tất cả các đỉnh trong DAG mà không có chi phí truyền thông bổ sung. Để làm được đ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 đề xuất và các cạnh đại diện cho phiếu bầu.
Mặc dù logic giao thoa của các 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 đã đặt: cứ vài vòng lại 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;
Đặt hàng điểm neo: các xác thực quyết định độc lập nhưng xác định điểm neo nào sẽ được đặt hàng và điểm neo nào sẽ bị bỏ qua;
Đặt hàng lịch sử nguyên nhân: các xác thực xử lý danh sách các điểm neo có thứ tự một cách tuần tự và 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.
Yếu tố then chốt để đảm bảo an toàn là đảm bảo rằng trong bước (2), tất cả các nút xác thực trung thực tạo ra một danh sách điểm neo có thứ tự, để tất cả các danh sách chia sẻ cùng một tiền tố. Trong Shoal, 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 validator đều đồng ý với điểm neo có thứ tự đầu tiên.
Bullshark Trễ
Độ trễ của Bullshark phụ thuộc vào số vòng giữa các điểm neo có thứ tự trong DAG. Mặc dù phiên bản đồng bộ phần Bullshark thực dụng hơn có độ trễ tốt hơn so với phiên bản không đồng bộ, nhưng nó 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ó một điểm neo, và đỉnh của mỗi vòng lẻ được hiểu là phiếu bầ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ờ đ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.
Câu hỏi 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 của một vòng 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 ), do đó 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 đáng kể hiệu suất của mạng sao chép địa lý, đặc biệt là vì thời gian chờ Bullshark đượ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 dò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ế uy tín lãnh đạo không tốn chi phí trong DAG, điều này khiến cho việc lựa chọn nghiêng về các lãnh đạo nhanh.
Thách thức
Trong bối cảnh của giao thức DAG, vấn đề về đường ống và danh tiếng của người lãnh đạo được coi là khó khăn, lý do như sau:
Trước đây, các nỗ lực sửa đổi logic Bullshark cốt lõi của dây chuyền sản xuất dường như về bản chất là không thể.
Danh tiếng của nhà 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 nhà lãnh đạo tương lai dựa trên hiệu suất trong quá khứ của các nhà xác thực trong ý tưởng về các mỏ neo trong Bullshark (. Mặc dù có sự khác biệt trong danh tính lãnh đạo không vi phạm độ 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 nêu bật cốt lõi của vấn đề, 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, và các nhà xác thực cần đạt được sự đồng thuận về lịch sử có thứ tự để chọn mỏ neo trong tương lai.
Như một bằng chứng về độ khó của vấn đề, chúng tôi lưu ý 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 như câu nói đã nói, sự thật chứng minh rằng giải pháp ẩn chứa phí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 của các vòng trước. Với sự đồng thuận của tất cả các xác nhận về điểm neo 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 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 người lãnh đạo.
![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-0b0928cb6240e994c1514c75e080a4b2.webp(
Dòng chảy
V ánh xạ vòng đến người lãnh đạo. Shoal chạy từng phiên bản của Bullshark, để cho 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 thứ 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ể chắc chắn đồng ý rằng bắt đầu từ vòng thứ r+1, sẽ giải thích lại DAG. Shoal chỉ khởi động một phiên bản Bullshark mới trong vòng thứ r+1.
Trong trường hợp tốt nhất, điều này cho phép Shoal đặt hàng một mỏ neo trong mỗi vòng. 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, phiên bản này có một mỏ neo, 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 hàng 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, khi bỏ qua điểm neo, Trễ sẽ tăng lên. Trong trường hợp này, công nghệ dòng chảy không thể giúp ích, vì không thể khởi động một phiên bản mới trước khi phiên bản trước đó đặt hàng điểm neo. Shoal đảm bảo rằng những nhà lãnh đạo tương ứng có khả năng xử lý các điểm neo bị mất trong tương lai ít hơn 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 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, ngược lại, 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 làm điều sai trá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 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 trên 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ể tự nhiên kết hợp với nhau, 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 có thứ tự đầu tiên.
Trên thực tế, sự khác biệt duy nhất là, sau khi sắp xếp các điểm neo trong vòng r, các xác thực chỉ cần tính toán ánh xạ mới F' từ vòng r+1 dựa trên lịch sử nguyên nhân của các điểm neo đã sắp xếp trong vòng r. Sau đó, các nút xác thực bắt đầu từ vòng r+1 sẽ thực hiện một phiên bản mới của Bullshark bằng cách sử dụng hàm chọn điểm neo đã cập nhật F'.
![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-9f789cb669f6fcc244ea7ff7648e48b4.webp(
Không còn thời gian chờ nữa
Thời gian chờ đóng vai trò rất 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 người lãnh đạo. 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 phải quản lý và theo dõi, điều này làm tăng sự phức tạp của quá trình gỡ lỗi và cần nhiều kỹ thuật quan sát hơn.
Thời gian chờ cũng sẽ tăng đá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 người lãnh đạo tiếp theo, giao thức sẽ trả toàn bộ hình phạt độ trễ do thời gian chờ của người 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ững người 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, người lãnh đạo trong Jolteon/Hotstuff bị quá tải và thời gian chờ đã hết hạn trước khi họ thúc đẩy tiến trình.
Trang này có thể chứa nội dung của bên thứ ba, được cung cấp chỉ nhằm mục đích thông tin (không phải là tuyên bố/bảo đảm) và không được coi là sự chứng thực cho quan điểm của Gate hoặc là lời khuyên về tài chính hoặc chuyên môn. Xem Tuyên bố từ chối trách nhiệm để biết chi tiết.
7 thích
Phần thưởng
7
5
Chia sẻ
Bình luận
0/400
SchrodingersFOMO
· 08-05 13:55
Trễ giảm这么多 bull bull
Xem bản gốcTrả lời0
SchroedingerMiner
· 08-05 12:20
Tốc độ này tăng lên nhanh hơn cả nhiệt độ máy khai thác của nhà tôi.
Khung Shoal nâng cao hiệu suất Bullshark trên Aptos giảm trễ 40%-80%
Khung Shoal: Giảm đáng kể 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 lên 80%.
Shoal là một khung để tăng cường bất kỳ 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. Pipeline 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, 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 quan đến 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 kịch bản hết thời gian. Điều này cho phép Shoal cung cấp thuộc tính phản hồi toàn cầu, 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 nhiều phiên bản của giao thức cơ sở theo thứ tự. Do đó, khi được khởi tạo với Bullshark, chúng ta có đượ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 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.
Sự đột phá gần đây xuất phát từ việc nhận ra rằng việc truyền dữ liệu là nút thắt chính dựa trên giao thức lãnh đạo, có thể hưởng lợi từ sự song song hóa. Hệ thống Narwhal tách biệt việc truyền dữ liệu với logic đồng thuận, đề xuất một kiến trúc mà tất cả các xác thực viên đều truyền dữ liệu đồng thời, 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 về Narwhal báo cáo khả năng thông lượng 160.000 TPS.
Trước đây, chúng tôi đã giới thiệu Quorum Store, việc triển khai Narwhal của chúng tôi tách biệt việc truyền dữ liệu với 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 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 phong cách PBFT, giảm độ trễ của Hotstuff xuống 33%. Tuy nhiên, các giao thức đồng thuận dựa trên 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à sự đồng thuận được tách biệt, nhưng khi thông lượng tăng lên, 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, một giao thức đồng thuận không tốn kém truyền thông, 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
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 có được n-f đỉnh thuộc vòng r-1. Mỗi xác thực viên có thể phát sóng một đỉnh mỗi vòng, mỗi đỉnh ít nhất phải tham chiếu đến n-f đỉnh của vòng trước. Do tính bất đồng bộ của mạng, các xác thực viên khác nhau có thể quan sát các góc 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 không phải là mơ hồ: nếu hai nút xác thực có cùng đỉnh v trong cái nhìn địa phương của chúng về DAG, thì chúng có lịch sử nguyên nhân v hoàn toàn giống nhau.
Tổng tự
Có thể đạt được sự đồng thuận về thứ tự tổng thể của tất cả các đỉnh trong DAG mà không có chi phí truyền thông bổ sung. Để làm được đ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 đề xuất và các cạnh đại diện cho phiếu bầu.
Mặc dù logic giao thoa của các 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 đã đặt: cứ vài vòng lại 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;
Đặt hàng điểm neo: các xác thực quyết định độc lập nhưng xác định điểm neo nào sẽ được đặt hàng và điểm neo nào sẽ bị bỏ qua;
Đặt hàng lịch sử nguyên nhân: các xác thực xử lý danh sách các điểm neo có thứ tự một cách tuần tự và 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.
Yếu tố then chốt để đảm bảo an toàn là đảm bảo rằng trong bước (2), tất cả các nút xác thực trung thực tạo ra một danh sách điểm neo có thứ tự, để tất cả các danh sách chia sẻ cùng một tiền tố. Trong Shoal, 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 validator đều đồng ý với điểm neo có thứ tự đầu tiên.
Bullshark Trễ
Độ trễ của Bullshark phụ thuộc vào số vòng giữa các điểm neo có thứ tự trong DAG. Mặc dù phiên bản đồng bộ phần Bullshark thực dụng hơn có độ trễ tốt hơn so với phiên bản không đồng bộ, nhưng nó 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ó một điểm neo, và đỉnh của mỗi vòng lẻ được hiểu là phiếu bầ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ờ đ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.
Câu hỏi 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 của một vòng 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 ), do đó 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 đáng kể hiệu suất của mạng sao chép địa lý, đặc biệt là vì thời gian chờ Bullshark đượ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 dò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ế uy tín lãnh đạo không tốn chi phí trong DAG, điều này khiến cho việc lựa chọn nghiêng về các lãnh đạo nhanh.
Thách thức
Trong bối cảnh của giao thức DAG, vấn đề về đường ống và danh tiếng của người lãnh đạo được coi là khó khăn, lý do như sau:
Trước đây, các nỗ lực sửa đổi logic Bullshark cốt lõi của dây chuyền sản xuất dường như về bản chất là không thể.
Danh tiếng của nhà 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 nhà lãnh đạo tương lai dựa trên hiệu suất trong quá khứ của các nhà xác thực trong ý tưởng về các mỏ neo trong Bullshark (. Mặc dù có sự khác biệt trong danh tính lãnh đạo không vi phạm độ 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 nêu bật cốt lõi của vấn đề, 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, và các nhà xác thực cần đạt được sự đồng thuận về lịch sử có thứ tự để chọn mỏ neo trong tương lai.
Như một bằng chứng về độ khó của vấn đề, chúng tôi lưu ý 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 như câu nói đã nói, sự thật chứng minh rằng giải pháp ẩn chứa phí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 của các vòng trước. Với sự đồng thuận của tất cả các xác nhận về điểm neo 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 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 người lãnh đạo.
![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-0b0928cb6240e994c1514c75e080a4b2.webp(
Dòng chảy
V ánh xạ vòng đến người lãnh đạo. Shoal chạy từng phiên bản của Bullshark, để cho 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 thứ 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ể chắc chắn đồng ý rằng bắt đầu từ vòng thứ r+1, sẽ giải thích lại DAG. Shoal chỉ khởi động một phiên bản Bullshark mới trong vòng thứ r+1.
Trong trường hợp tốt nhất, điều này cho phép Shoal đặt hàng một mỏ neo trong mỗi vòng. 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, phiên bản này có một mỏ neo, 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 hàng 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, khi bỏ qua điểm neo, Trễ sẽ tăng lên. Trong trường hợp này, công nghệ dòng chảy không thể giúp ích, vì không thể khởi động một phiên bản mới trước khi phiên bản trước đó đặt hàng điểm neo. Shoal đảm bảo rằng những nhà lãnh đạo tương ứng có khả năng xử lý các điểm neo bị mất trong tương lai ít hơn 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 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, ngược lại, 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 làm điều sai trá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 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 trên 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ể tự nhiên kết hợp với nhau, 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 có thứ tự đầu tiên.
Trên thực tế, sự khác biệt duy nhất là, sau khi sắp xếp các điểm neo trong vòng r, các xác thực chỉ cần tính toán ánh xạ mới F' từ vòng r+1 dựa trên lịch sử nguyên nhân của các điểm neo đã sắp xếp trong vòng r. Sau đó, các nút xác thực bắt đầu từ vòng r+1 sẽ thực hiện một phiên bản mới của Bullshark bằng cách sử dụng hàm chọn điểm neo đã cập nhật F'.
![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-9f789cb669f6fcc244ea7ff7648e48b4.webp(
Không còn thời gian chờ nữa
Thời gian chờ đóng vai trò rất 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 người lãnh đạo. 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 phải quản lý và theo dõi, điều này làm tăng sự phức tạp của quá trình gỡ lỗi và cần nhiều kỹ thuật quan sát hơn.
Thời gian chờ cũng sẽ tăng đá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 người lãnh đạo tiếp theo, giao thức sẽ trả toàn bộ hình phạt độ trễ do thời gian chờ của người 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ững người 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, người lãnh đạo trong Jolteon/Hotstuff bị quá tải và thời gian chờ đã hết hạn trước khi họ thúc đẩy tiến trình.
Không may