Khung Shoal: Giảm đáng kể Trễ của Bullshark trên Aptos
Aptos Labs gần đây đã 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ề timeout trong giao thức thực dụng xác định. Tổng thể, trong trường hợp không có lỗi, Bullshark đã cải thiện độ trễ lên 40%, trong trường hợp có lỗi đã cải thiện 80%.
Shoal là một khung, thông qua đường ống và cơ chế danh tiếng của người dẫn đầu để tăng cường giao thức đồng thuận dựa trên Narwhal ( như DAG-Rider, Tusk, Bullshark ). Đường ống 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à danh tiếng của người dẫn đầu 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 các nút xác thực nhanh nhất. Hơn nữa, danh tiếng của người dẫn đầu cho phép Shoal tận dụng việc xây dựng 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 phổ quát, bao gồm 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ự từng cái một. Do đó, khi sử dụng Bullshark để khởi tạo, chúng tôi có một nhóm "cá mập" đang tham gia vào một cuộc tiếp sức.
Bối cảnh
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 giảm độ phức tạp của giao tiếp. Tuy nhiên, phương pháp này không dẫn đến sự cải thiện đáng kể về thông lượng. Ví dụ, Hotstuff được triển khai trong phiên bản đầu tiên của Diem chỉ đạt 3500 TPS, thấp hơn nhiều so với mục tiêu trên 100.000 TPS.
Những đột phá gần đây bắt nguồn từ việc nhận thức 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ể thu được lợi ích từ việc phân tán. 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, đề xuất một kiến trúc mà tất cả các xác thực viên cùng lúc 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 rằng có khả năng thông lượng lên tới 160.000 TPS.
Trước đây, chúng tôi đã giới thiệu Quorum Store, tức là việc thực hiện 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 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à sự 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à các giao thức đồng thuận dựa trên người lãnh đạo không thể khai thác đầy đủ tiềm năng băng thô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 với việc tăng băng thông, 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, một giao thức đồng thuận không tốn chi phí giao tiếp. Thật không may, so với Jolteon, cấu trúc DAG hỗ trợ Bullshark 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 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 nhận được 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 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 xác thực viên khác nhau có thể quan sát những cái nhìn đị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 quan trọng của DAG là không mập mờ: nếu hai nút xác thực có cùng đỉnh v trong tầm 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.
Tổng tựa
Có thể đạt được sự đồng thuận về tổng thứ tự của tất cả các đỉnh trong DAG mà không cần chi phí truyền thông bổ sung. Để làm điều này, các validator 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 tập hợp 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: cứ sau vài vòng ( như trong Bullshark, cứ mỗi hai vòng ) sẽ có một nhà lãnh đạo được xác định trước, đỉnh của nhà lãnh đạo được gọi là điểm neo.
Điểm neo phân loại: Các xác thực quyết định độc lập nhưng có tính xác định điểm neo nào được phân loại và điểm neo nào bị bỏ qua.
Sắp xếp lịch sử nguyên nhân: các xác nhận viên lần lượt xử lý danh sách các đ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 một số quy tắc xác định.
Chìa khóa để đảm bảo an toàn là đảm bảo rằng trong bước (2), danh sách điểm neo có thứ tự được tạo ra 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 đưa ra những quan sát sau về tất cả các giao thức này:
Tất cả các trình 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 thực tiễn 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.
Câu hỏi 1: Độ trễ trung bình của khối. 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à 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, 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 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 người lãnh đạo của một vòng nào đó không phát sóng điểm neo đủ nhanh, thì không thể sắp xếp điểm neo đó ( do đó bị bỏ qua ), vì vậy tất cả các đỉnh chưa sắp xếp trong vài vòng trước phải đợi điểm neo tiếp theo được sắp xếp. Điều này sẽ giảm hiệu suất của mạng sao chép địa lý một cách đáng kể, đặc biệt là vì Bullshark sử dụng thời gian chờ để đợi người lãnh đạo.
Khung Shoal
Shoal đã giải quyết được 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 xử lý theo 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ế danh tiếng lãnh đạo không tốn kém trong DAG, điều này khiến cho việc lựa chọn thiên về các lãnh đạo nhanh.
Thách thức
Trong bối cảnh 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:
Các nỗ lực trước đây của dòng sản phẩm đã 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 nhà lãnh đạo được giới thiệu trong DiemBFT và chính thức hóa trong Carousel, là dựa trên việc lựa chọn động các nhà lãnh đạo tương lai trong (Bullshark dựa trên hiệu suất trong quá khứ của các xác thực viên. Mặc dù có sự khác biệt trong danh tính của 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 này có thể dẫn đến thứ tự hoàn toàn khác nhau, điều này làm nổi bật vấn đề cốt lõi, đó là việc lựa chọn động và xác định các bánh xe neo 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 thuận về lịch sử có thứ tự để lựa chọn các bánh neo tương lai.
Là bằng chứng về độ khó của vấn đề, chúng tôi lưu ý rằng triển khai của Bullshark, bao gồm cả triển khai hiện tại trong môi trường sản xuất, không hỗ trợ những tính năng này.
![Giải thích chi tiết về khung Shoal: Làm thế nào để giảm Trễ Bullshark trên Aptos?])https://img-cdn.gateio.im/webp-social/moments-859e732e16c3eee0e2c93422474debc2.webp(
Giao thức
Mặc dù có những thách thức trên, nhưng thực tế cho thấy 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à đạt được 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 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 trường hợp Bullshark để xử lý chúng 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 trường hợp, 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 lãnh đạo.
Dòng chảy
V ánh xạ các vòng đến người lãnh đạo. Shoal chạy từng phiên bản của Bullshark, vì vậy 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, điều này sẽ kích hoạt việc chuyển sang phiên bản tiếp theo.
Ban đầu, Shoal đã khởi động phiên bản đầu tiên của Bullshark trong vòng đầu tiên của DAG và chạy nó cho đến khi xác định điểm neo có thứ tự đầu tiên, chẳng hạn như ở vòng r. Tất cả các xác thực viên đều đồng ý với điểm neo này. Do đó, tất cả các xác thực viên có thể đồng ý một cách chắc chắn rằng từ vòng r+1 trở đi 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 sắp xếp một mỏ neo trong mỗi vòng. 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, chính nó có một mỏ neo, mỏ neo đó được sắp xếp bởi thể hiện đó, sau đó, một thể hiện mới khác được sắp xếp mỏ neo trong vòng thứ ba, và sau đó quá trình này 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-9f789cb669f6fcc244ea7ff7648e48b4.webp(
Danh tiếng của nhà 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ệ pipeline không thể phát huy tác dụng, vì không thể khởi động một 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 các nhà lãnh đạo tương ứng sẽ í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ổ một điểm số 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. 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 số cao, ngược lại, các nút xác thực sẽ được phân bổ điểm số thấp, vì chúng có thể bị sập, chậm hoặc có hành vi 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 trước F từ vòng đến người lãnh đạo, thiên về những người lãnh đạo có điểm số cao hơn. Để các xác 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 trên lịch sử được sử dụng để suy ra điểm số.
Trong Shoal, đường ống 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à giải thích lại DAG sau khi đạt được sự đồng thuận về đ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 trong vòng r, các xác thực viên 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ử dụng hàm chọn điểm neo F' đã được cập nhật để 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-1baf540693f376d93cb18ef3193593cc.webp(
Không còn thời gian chờ nữa
Thời gian vượt quá đóng vai trò rất quan trọng trong tất cả các triển khai BFT đồng bộ phần 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 được quản lý và theo dõi, điều này làm tăng độ phức tạp của quá trình gỡ lỗi và cần nhiều kỹ thuật quan sát hơn.
Thời gian chờ cũng sẽ làm tăng đá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 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 thời gian chờ cho nhà lãnh đạo gặp sự cố.
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.
12 thích
Phần thưởng
12
6
Chia sẻ
Bình luận
0/400
CryptoSurvivor
· 9giờ trước
Bull Ồ, đợt nâng cấp này đã giúp Aptos tăng tốc.
Xem bản gốcTrả lời0
SelfSovereignSteve
· 9giờ trước
Cái cập nhật này thật sự quá tốt, tăng 40% thật sự mạnh.
Xem bản gốcTrả lời0
GasFeeCrier
· 9giờ trước
Hơi căng, vấn đề trễ này đã ổn định.
Xem bản gốcTrả lời0
MissedTheBoat
· 9giờ trước
Giao dịch tiền điện tử đồ ngốc cuối cùng đã có lãi
Khung Shoal thả trễ Bullshark Aptos Blockchain
Khung Shoal: Giảm đáng kể Trễ của Bullshark trên Aptos
Aptos Labs gần đây đã 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ề timeout trong giao thức thực dụng xác định. Tổng thể, trong trường hợp không có lỗi, Bullshark đã cải thiện độ trễ lên 40%, trong trường hợp có lỗi đã cải thiện 80%.
Shoal là một khung, thông qua đường ống và cơ chế danh tiếng của người dẫn đầu để tăng cường giao thức đồng thuận dựa trên Narwhal ( như DAG-Rider, Tusk, Bullshark ). Đường ống 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à danh tiếng của người dẫn đầu 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 các nút xác thực nhanh nhất. Hơn nữa, danh tiếng của người dẫn đầu cho phép Shoal tận dụng việc xây dựng 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 phổ quát, bao gồm 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ự từng cái một. Do đó, khi sử dụng Bullshark để khởi tạo, chúng tôi có một nhóm "cá mập" đang tham gia vào một cuộc tiếp sức.
Bối cảnh
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 giảm độ phức tạp của giao tiếp. Tuy nhiên, phương pháp này không dẫn đến sự cải thiện đáng kể về thông lượng. Ví dụ, Hotstuff được triển khai trong phiên bản đầu tiên của Diem chỉ đạt 3500 TPS, thấp hơn nhiều so với mục tiêu trên 100.000 TPS.
Những đột phá gần đây bắt nguồn từ việc nhận thức 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ể thu được lợi ích từ việc phân tán. 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, đề xuất một kiến trúc mà tất cả các xác thực viên cùng lúc 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 rằng có khả năng thông lượng lên tới 160.000 TPS.
Trước đây, chúng tôi đã giới thiệu Quorum Store, tức là việc thực hiện 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 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à sự 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à các giao thức đồng thuận dựa trên người lãnh đạo không thể khai thác đầy đủ tiềm năng băng thô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 với việc tăng băng thông, 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, một giao thức đồng thuận không tốn chi phí giao tiếp. Thật không may, so với Jolteon, cấu trúc DAG hỗ trợ Bullshark 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 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 nhận được 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 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 xác thực viên khác nhau có thể quan sát những cái nhìn đị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 quan trọng của DAG là không mập mờ: nếu hai nút xác thực có cùng đỉnh v trong tầm 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.
Tổng tựa
Có thể đạt được sự đồng thuận về tổng thứ tự của tất cả các đỉnh trong DAG mà không cần chi phí truyền thông bổ sung. Để làm điều này, các validator 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 tập hợp 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: cứ sau vài vòng ( như trong Bullshark, cứ mỗi hai vòng ) sẽ có một nhà lãnh đạo được xác định trước, đỉnh của nhà lãnh đạo được gọi là điểm neo.
Điểm neo phân loại: Các xác thực quyết định độc lập nhưng có tính xác định điểm neo nào được phân loại và điểm neo nào bị bỏ qua.
Sắp xếp lịch sử nguyên nhân: các xác nhận viên lần lượt xử lý danh sách các đ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 một số quy tắc xác định.
Chìa khóa để đảm bảo an toàn là đảm bảo rằng trong bước (2), danh sách điểm neo có thứ tự được tạo ra 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 đưa ra những quan sát sau về tất cả các giao thức này:
Tất cả các trình 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 thực tiễn 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.
Câu hỏi 1: Độ trễ trung bình của khối. 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à 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, 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 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 người lãnh đạo của một vòng nào đó không phát sóng điểm neo đủ nhanh, thì không thể sắp xếp điểm neo đó ( do đó bị bỏ qua ), vì vậy tất cả các đỉnh chưa sắp xếp trong vài vòng trước phải đợi điểm neo tiếp theo được sắp xếp. Điều này sẽ giảm hiệu suất của mạng sao chép địa lý một cách đáng kể, đặc biệt là vì Bullshark sử dụng thời gian chờ để đợi người lãnh đạo.
Khung Shoal
Shoal đã giải quyết được 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 xử lý theo 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ế danh tiếng lãnh đạo không tốn kém trong DAG, điều này khiến cho việc lựa chọn thiên về các lãnh đạo nhanh.
Thách thức
Trong bối cảnh 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:
Các nỗ lực trước đây của dòng sản phẩm đã 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 nhà lãnh đạo được giới thiệu trong DiemBFT và chính thức hóa trong Carousel, là dựa trên việc lựa chọn động các nhà lãnh đạo tương lai trong (Bullshark dựa trên hiệu suất trong quá khứ của các xác thực viên. Mặc dù có sự khác biệt trong danh tính của 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 này có thể dẫn đến thứ tự hoàn toàn khác nhau, điều này làm nổi bật vấn đề cốt lõi, đó là việc lựa chọn động và xác định các bánh xe neo 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 thuận về lịch sử có thứ tự để lựa chọn các bánh neo tương lai.
Là bằng chứng về độ khó của vấn đề, chúng tôi lưu ý rằng triển khai của Bullshark, bao gồm cả triển khai hiện tại trong môi trường sản xuất, không hỗ trợ những tính năng này.
![Giải thích chi tiết về khung Shoal: Làm thế nào để giảm Trễ Bullshark trên Aptos?])https://img-cdn.gateio.im/webp-social/moments-859e732e16c3eee0e2c93422474debc2.webp(
Giao thức
Mặc dù có những thách thức trên, nhưng thực tế cho thấy 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à đạt được 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 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 trường hợp Bullshark để xử lý chúng 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 trường hợp, 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 lãnh đạo.
Dòng chảy
V ánh xạ các vòng đến người lãnh đạo. Shoal chạy từng phiên bản của Bullshark, vì vậy 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, điều này sẽ kích hoạt việc chuyển sang phiên bản tiếp theo.
Ban đầu, Shoal đã khởi động phiên bản đầu tiên của Bullshark trong vòng đầu tiên của DAG và chạy nó cho đến khi xác định điểm neo có thứ tự đầu tiên, chẳng hạn như ở vòng r. Tất cả các xác thực viên đều đồng ý với điểm neo này. Do đó, tất cả các xác thực viên có thể đồng ý một cách chắc chắn rằng từ vòng r+1 trở đi 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 sắp xếp một mỏ neo trong mỗi vòng. 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, chính nó có một mỏ neo, mỏ neo đó được sắp xếp bởi thể hiện đó, sau đó, một thể hiện mới khác được sắp xếp mỏ neo trong vòng thứ ba, và sau đó quá trình này 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-9f789cb669f6fcc244ea7ff7648e48b4.webp(
Danh tiếng của nhà 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ệ pipeline không thể phát huy tác dụng, vì không thể khởi động một 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 các nhà lãnh đạo tương ứng sẽ í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ổ một điểm số 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. 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 số cao, ngược lại, các nút xác thực sẽ được phân bổ điểm số thấp, vì chúng có thể bị sập, chậm hoặc có hành vi 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 trước F từ vòng đến người lãnh đạo, thiên về những người lãnh đạo có điểm số cao hơn. Để các xác 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 trên lịch sử được sử dụng để suy ra điểm số.
Trong Shoal, đường ống 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à giải thích lại DAG sau khi đạt được sự đồng thuận về đ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 trong vòng r, các xác thực viên 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ử dụng hàm chọn điểm neo F' đã được cập nhật để 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-1baf540693f376d93cb18ef3193593cc.webp(
Không còn thời gian chờ nữa
Thời gian vượt quá đóng vai trò rất quan trọng trong tất cả các triển khai BFT đồng bộ phần 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 được quản lý và theo dõi, điều này làm tăng độ phức tạp của quá trình gỡ lỗi và cần nhiều kỹ thuật quan sát hơn.
Thời gian chờ cũng sẽ làm tăng đá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 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 thời gian chờ cho nhà lãnh đạo gặp sự cố.