Aptos labs đã giải quyết hai vấn đề mở quan trọng trong DAG BFT, Thả đáng kể Trễ, và lần đầu tiên loại bỏ nhu cầu về thời gian chờ trong giao thức thực sự quyết định. Tổng thể, khung Shoal đã cải thiện 40% Trễ của Bullshark trong trường hợp không có lỗi, và cải thiện 80% trong trường hợp có lỗi.
Shoal là một khung tăng cường giao thức đồng thuận dựa trên Narwhal ( thông qua đường ống và uy tín của người dẫn dắt như DAG-Rider, Tusk, Bullshark ). Đường ống giảm thiểu trễ sắp xếp DAG bằng cách giới thiệu một điểm neo trong mỗi vòng, trong khi uy tín của người dẫn dắt 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 dẫn dắt 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 thuộc tính mà chúng tôi gọi là 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ệ của Shoal rất đơn giản, 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 ta có một nhóm "cá mập" tham gia vào cuộc đua tiếp sức.
Bối cảnh
Khi 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ự 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.
Gần đây, sự đột phá 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 của giao thức lãnh đạo và có thể được hưởng lợi từ việc song song hóa. Hệ thống Narwhal tách biệt việc truyền dữ liệu với logic đồ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 cùng 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 mức thông lượng 160,000 TPS.
Aptos trước đây đã giới thiệu Quorum Store, đây là triển khai Narwhal của họ, tách biệt việc truyền dữ liệu và sự đồng thuận, và được sử dụng để 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 con đường nhanh tuyến tính của Tendermint và thay đổi cái nhìn theo phong cách PBFT, có thể 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 với sự gia tăng thông lượng, lãnh đạo của Hotstuff/Jolteon vẫn bị hạn chế.
Do đó, Aptos quyết định triển khai Bullshark, một giao thức đồng thuận không tốn chi phí truyền thông, trên Narwhal DAG. Thật không may, cấu trúc DAG hỗ trợ Bullshark với thông lượng cao hơn đã mang lại chi phí trễ 50% so với Jolteon.
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 r, các xác thực viên phải trước tiên thu đượ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 trong 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 không đồng bộ của mạng, các xác thực viên khác nhau có thể quan sát các chế độ xem cục bộ khác nhau của DAG vào bất kỳ thời điểm nào.
Một thuộc tính quan trọng của DAG 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.
Sắp xếp 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ần 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 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 của 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 đượ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 trong mỗi 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 nhà xác thực độc lập nhưng quyết định một cách chắc chắn điểm neo nào được sắp xếp và điểm neo nào bị bỏ qua.
Sắp xếp lịch sử nguyên nhân: các xác thực viên xử lý danh sách điểm neo có thứ tự của họ từng cái một, và đối với mỗi điểm neo, sắp xếp tất cả các đỉnh vô 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.
Điều quan trọng để đảm bảo an toàn là đảm bảo rằng trong các bước trên (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, có những quan sát sau về tất cả các giao thức 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 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ố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 giải thích 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, đỉnh trong lịch sử nguyên nhân của điểm neo cần nhiều vòng hơn để chờ đợ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 các trường hợp lỗi, phân tích trễ ở trên áp dụng cho các trường hợp không có lỗi, mặt khác, nếu nhà lãnh đạo của một vòng không phát sóng điểm neo đủ nhanh, thì không thể sắp xếp điểm neo ( vì vậy 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 đ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 đượ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 sử dụng pipeline, 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 ba vòng. Shoal cũng đã giới thiệu một cơ chế uy tín 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ề những lãnh đạo nhanh chóng.
Thách thức
Trong bối cảnh giao thức DAG, vấn đề về đường ống và uy tín của người lãnh đạo được coi là những vấn đề khó khăn, lý do như sau:
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ù có những bất đồng về danh tính lãnh đạo không vi phạm tính bảo mật trong các thỏa thuận này, nhưng trong Bullshark, điều này có thể dẫn đến các thứ tự hoàn toàn khác nhau, điều này dẫn đến cốt lõi của vấn đề, đó là việc lựa chọn 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 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 neo trong tương lai.
Là bằng chứng về độ khó của vấn đề, việc thực hiện của Bullshark, bao gồm cả việc thực hiện hiện tại trong môi trường sản xuất, đều không hỗ trợ các 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-0b0928cb6240e994c1514c75e080a4b2.webp(
Giao thức
Mặc dù có những thách thức nêu trên, nhưng như câu nói phổ biến, sự thật là giải pháp ẩn chứa đằng sau những điều đơn giản.
Tại 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 nhậ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 trường hợp Bullshark để xử lý chúng theo dạng ống dẫn, khiến cho )1( điểm neo có thứ tự đầu tiên trở thành điểm chuyển đổi của các trường hợp, cũng như )2( lịch sử nguyên nhân của điểm neo được sử dụng để tính toán uy tín của người lãnh đạo.
) Dòng chảy
V ánh xạ vòng đến người lãnh đạo. Shoal chạy các phiên bản của Bullshark lần lượt, như vậy đối với mỗi phiên bản, điểm neo được xác định trước bởi ánh xạ F. Mỗi phiên bản sắp xếp một điểm neo, đ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ó trật tự đầu tiên, chẳng hạn như trong vòng r. Tất cả các validator đều đồng ý với điểm neo này. Do đó, tất cả các validator có thể chắc chắn đồng ý 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 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 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, mà chính nó 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 sắp xếp 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 thiểu 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ệ đường ống không thể làm gì được, 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 í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ế tín nhiệm để gán 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 từng nút. 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 số cao, nếu không, các nút xác thực sẽ được gán điểm số thấp, vì chúng có thể bị sập, chậm hoặc có hành vi xấu.
Triết lý của nó là trong mỗi lần cập nhật điểm số, một cách xác định lại tính toán á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. Để cho các xác thực viên đạt được sự đồng thuận trên ánh xạ mới, họ nên đồ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à giải thích 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 đã được 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 các phiên bản mới của Bullshark bằng cách sử dụng hàm chọn điểm neo đã được cập nhật F'.
![Giải thích chi tiết về khung Shoal: Làm thế nào để giảm thiểu trễ Bullshark trên Aptos?]###https://img-cdn.gateio.im/webp-social/moments-9f789cb669f6fcc244ea7ff7648e48b4.webp(
) Không còn thời gian chờ nữa
Thời gian chờ đóng vai trò quan trọng trong tất cả các triển khai BFT đồng bộ phần tử xác định dựa trên leader. Tuy nhiên, sự phức tạp mà chúng mang lại đã làm tăng số lượng trạng thái nội bộ cần được quản lý và giám sát, điều này làm gia 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.
Timeout 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 lãnh đạo tiếp theo, giao thức sẽ trả hình phạt trễ tối đa cho lãnh đạo gặp sự cố. Do đó, việc thiết lập 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ể
Trang này có thể chứa nội dung của bên thứ ba, được cung cấp chỉ nhằm mục đích thông tin (không phải là tuyên bố/bảo đảm) và không được coi là sự chứng thực cho quan điểm của Gate hoặc là lời khuyên về tài chính hoặc chuyên môn. Xem Tuyên bố từ chối trách nhiệm để biết chi tiết.
11 thích
Phần thưởng
11
8
Chia sẻ
Bình luận
0/400
CryptoGoldmine
· 17giờ trước
80% tối ưu hóa Trễ về mặt kỹ thuật đã gần hoàn hảo về tỷ lệ chi phí và lợi ích
Xem bản gốcTrả lời0
just_here_for_vibes
· 07-27 18:20
Cải thiện hiệu suất nhiều như vậy? Cuộn thôi.
Xem bản gốcTrả lời0
BridgeNomad
· 07-26 20:35
hmm... độ trễ được cải thiện trông ổn nhưng vẫn cần xác minh những vector tin cậy để nói thật.
Xem bản gốcTrả lời0
BearMarketHustler
· 07-26 20:30
Ôi, Aptos khá giỏi đấy!
Xem bản gốcTrả lời0
Whale_Whisperer
· 07-26 20:28
Cải tiến này thật tuyệt, trước tiên hãy tích trữ một ít apt.
Xem bản gốcTrả lời0
CryptoMotivator
· 07-26 20:17
Aptos gogo～Trễ 80% là thật sự mạnh
Xem bản gốcTrả lời0
StakeHouseDirector
· 07-26 20:17
chuyên nghiệp ơi, tối ưu hiệu suất này thật mạnh mẽ
Khung Shoal đã Thả đáng kể độ trễ Bullshark trên Aptos.
Khung Shoal: Cách thả độ trễ Bullshark trên Aptos
Aptos labs đã giải quyết hai vấn đề mở quan trọng trong DAG BFT, Thả đáng kể Trễ, và lần đầu tiên loại bỏ nhu cầu về thời gian chờ trong giao thức thực sự quyết định. Tổng thể, khung Shoal đã cải thiện 40% Trễ của Bullshark trong trường hợp không có lỗi, và cải thiện 80% trong trường hợp có lỗi.
Shoal là một khung tăng cường giao thức đồng thuận dựa trên Narwhal ( thông qua đường ống và uy tín của người dẫn dắt như DAG-Rider, Tusk, Bullshark ). Đường ống giảm thiểu trễ sắp xếp DAG bằng cách giới thiệu một điểm neo trong mỗi vòng, trong khi uy tín của người dẫn dắt 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 dẫn dắt 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 thuộc tính mà chúng tôi gọi là 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ệ của Shoal rất đơn giản, 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 ta có một nhóm "cá mập" tham gia vào cuộc đua tiếp sức.
Bối cảnh
Khi 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ự 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.
Gần đây, sự đột phá 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 của giao thức lãnh đạo và có thể được hưởng lợi từ việc song song hóa. Hệ thống Narwhal tách biệt việc truyền dữ liệu với logic đồ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 cùng 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 mức thông lượng 160,000 TPS.
Aptos trước đây đã giới thiệu Quorum Store, đây là triển khai Narwhal của họ, tách biệt việc truyền dữ liệu và sự đồng thuận, và được sử dụng để 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 con đường nhanh tuyến tính của Tendermint và thay đổi cái nhìn theo phong cách PBFT, có thể 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 với sự gia tăng thông lượng, lãnh đạo của Hotstuff/Jolteon vẫn bị hạn chế.
Do đó, Aptos quyết định triển khai Bullshark, một giao thức đồng thuận không tốn chi phí truyền thông, trên Narwhal DAG. Thật không may, cấu trúc DAG hỗ trợ Bullshark với thông lượng cao hơn đã mang lại chi phí trễ 50% so với Jolteon.
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 r, các xác thực viên phải trước tiên thu đượ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 trong 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 không đồng bộ của mạng, các xác thực viên khác nhau có thể quan sát các chế độ xem cục bộ khác nhau của DAG vào bất kỳ thời điểm nào.
Một thuộc tính quan trọng của DAG 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.
Sắp xếp 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ần 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 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 của 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 đượ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 trong mỗi 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 nhà xác thực độc lập nhưng quyết định một cách chắc chắn điểm neo nào được sắp xếp và điểm neo nào bị bỏ qua.
Sắp xếp lịch sử nguyên nhân: các xác thực viên xử lý danh sách điểm neo có thứ tự của họ từng cái một, và đối với mỗi điểm neo, sắp xếp tất cả các đỉnh vô 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.
Điều quan trọng để đảm bảo an toàn là đảm bảo rằng trong các bước trên (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, có những quan sát sau về tất cả các giao thức 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 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ố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 giải thích 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, đỉnh trong lịch sử nguyên nhân của điểm neo cần nhiều vòng hơn để chờ đợ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 các trường hợp lỗi, phân tích trễ ở trên áp dụng cho các trường hợp không có lỗi, mặt khác, nếu nhà lãnh đạo của một vòng không phát sóng điểm neo đủ nhanh, thì không thể sắp xếp điểm neo ( vì vậy 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 đ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 đượ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 sử dụng pipeline, 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 ba vòng. Shoal cũng đã giới thiệu một cơ chế uy tín 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ề những lãnh đạo nhanh chóng.
Thách thức
Trong bối cảnh giao thức DAG, vấn đề về đường ống và uy tín của người lãnh đạo được coi là những vấn đề khó khăn, lý do như sau:
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ù có những bất đồng về danh tính lãnh đạo không vi phạm tính bảo mật trong các thỏa thuận này, nhưng trong Bullshark, điều này có thể dẫn đến các thứ tự hoàn toàn khác nhau, điều này dẫn đến cốt lõi của vấn đề, đó là việc lựa chọn 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 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 neo trong tương lai.
Là bằng chứng về độ khó của vấn đề, việc thực hiện của Bullshark, bao gồm cả việc thực hiện hiện tại trong môi trường sản xuất, đều không hỗ trợ các 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-0b0928cb6240e994c1514c75e080a4b2.webp(
Giao thức
Mặc dù có những thách thức nêu trên, nhưng như câu nói phổ biến, sự thật là giải pháp ẩn chứa đằng sau những điều đơn giản.
Tại 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 nhậ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 trường hợp Bullshark để xử lý chúng theo dạng ống dẫn, khiến cho )1( điểm neo có thứ tự đầu tiên trở thành điểm chuyển đổi của các trường hợp, cũng như )2( lịch sử nguyên nhân của điểm neo được sử dụng để tính toán uy tín của người lãnh đạo.
) Dòng chảy
V ánh xạ vòng đến người lãnh đạo. Shoal chạy các phiên bản của Bullshark lần lượt, như vậy đối với mỗi phiên bản, điểm neo được xác định trước bởi ánh xạ F. Mỗi phiên bản sắp xếp một điểm neo, đ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ó trật tự đầu tiên, chẳng hạn như trong vòng r. Tất cả các validator đều đồng ý với điểm neo này. Do đó, tất cả các validator có thể chắc chắn đồng ý 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 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 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, mà chính nó 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 sắp xếp 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 thiểu 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ệ đường ống không thể làm gì được, 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 í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ế tín nhiệm để gán 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 từng nút. 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 số cao, nếu không, các nút xác thực sẽ được gán điểm số thấp, vì chúng có thể bị sập, chậm hoặc có hành vi xấu.
Triết lý của nó là trong mỗi lần cập nhật điểm số, một cách xác định lại tính toán á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. Để cho các xác thực viên đạt được sự đồng thuận trên ánh xạ mới, họ nên đồ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à giải thích 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 đã được 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 các phiên bản mới của Bullshark bằng cách sử dụng hàm chọn điểm neo đã được cập nhật F'.
![Giải thích chi tiết về khung Shoal: Làm thế nào để giảm thiểu trễ Bullshark trên Aptos?]###https://img-cdn.gateio.im/webp-social/moments-9f789cb669f6fcc244ea7ff7648e48b4.webp(
) Không còn thời gian chờ nữa
Thời gian chờ đóng vai trò quan trọng trong tất cả các triển khai BFT đồng bộ phần tử xác định dựa trên leader. Tuy nhiên, sự phức tạp mà chúng mang lại đã làm tăng số lượng trạng thái nội bộ cần được quản lý và giám sát, điều này làm gia 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.
Timeout 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 lãnh đạo tiếp theo, giao thức sẽ trả hình phạt trễ tối đa cho lãnh đạo gặp sự cố. Do đó, việc thiết lập 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ể