Khung Shoal: Thả độ trễ Bullshark trên Aptos bằng giải pháp mới
Aptos Labs gần đây đã 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 dụng xác định. Tổng thể, trong trường hợp không có lỗi, độ trễ của Bullshark đã được cải thiện 40%, trong trường hợp có lỗi đã được cải thiện 80%.
Shoal là một khung tăng cường giao thức đồng thuận dựa trên Narwhal ( thông qua xử lý theo dòng và cơ chế uy tín của người lãnh đạo. Xử lý theo dòng giảm trễ sắp xếp DAG bằng cách giới thiệu các điểm neo trong mỗi vòng, trong khi cơ chế 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 các điểm neo 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 việc xây dựng DAG bất đồng bộ để loại bỏ thời gian chờ trong tất cả các kịch bản. Điều này cho phép Shoal cung cấp thuộc tính được gọi là "phản hồi phổ quát", nó bao gồm phản hồi lạc quan thường cần thiết.
Công nghệ của Shoal khá đơ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ự một cách tuần 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 một cuộc tiếp sức.
![Giải thích chi tiết Shoal framework: Làm thế nào để Thả Bullshark trên Aptos?])https://img-cdn.gateio.im/webp-social/moments-8d6acd885bad7b8f911bdce15a7c884f.webp(
Bối cảnh
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 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 của chúng tôi.
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 các giao thức của các nhà lãnh đạo, 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, đề 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. Tài liệu Narwhal báo cáo khả năng thông lượng 160,000 TPS.
Chúng tôi đã thực hiện Quorum Store của Narwhal để tách biệt việc truyền dữ liệu và đồng thuận, nhằm mở rộng giao thức đồng thuận hiện tại là Jolteon. Jolteon là một giao thức dựa trên lãnh đạo, kết hợp giữa đường dẫn nhanh tuyến tính của Tendermint và sự thay đổi quan điểm theo phong cách PBFT, có thể Thả độ trễ của Hotstuff xuống 33%. Tuy nhiên, 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ù đã tách biệt việc truyền dữ liệu và đồng thuận, 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 trên Narwhal DAG, một giao thức đồng thuận không tốn chi phí truyền thô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 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, người xác thực phải trước tiên có được n-f đỉnh thuộc vòng r-1. Mỗi người xác thực 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 người xác thực khác nhau có thể quan sát các quan điểm 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 chính 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 DAG của chúng, thì chúng có lịch sử nguyên nhân v hoàn toàn giống nhau.
![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-f6b6281c928e3fa7a2412a480c9c1806.webp(
Tổng序
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ó chi phí giao tiếp bổ sung. Để làm được đ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, còn các cạnh đại diện cho việc bỏ phiế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 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 sắp xếp: Các người xác thực độc lập nhưng một cách xác định quyết định sắp xếp 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 nhận viên xử lý từng điểm neo theo thứ tự trong danh sách điểm neo có thứ tự, và đối với mỗi điểm neo, họ sắp xếp tất cả các đỉnh chưa có thứ tự trước đó trong lịch sử nguyên nhân của nó theo các quy tắc xác định.
Điều quan trọng để đảm bảo an toàn là đảm bảo rằng trong bước )2(, tất cả các nút xác thực trung thực tạo ra 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 nêu trên:
Tất cả các xác thực viên đều đồng ý với điểm neo có thứ tự đầu tiên.
Bullshark Trễ
Độ trễ của Bullshark phụ thuộc vào số vòng giữa các điểm neo có thứ tự trong DAG. Mặc dù phiên bản đồng bộ của Bullshark 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.
Vấn đề 1: Thời gian trễ trung bình của khối. Trong Bullshark, mỗi vòng chẵn có một điểm neo, và các đỉnh của vòng lẻ được hiểu là bỏ phiế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 các điểm neo cần nhiều vòng hơn để chờ các đ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.
Vấn đề 2: Trường hợp lỗi trễ, phân tích trễ nêu 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 thể 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 đượ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ì Bullshark sử dụng thời gian chờ để chờ nhà 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-b7ed8888da112bae8d34c0fdb338b138.webp(
Khung Shoal
Shoal đã cải thiện Bullshark) hoặc bất kỳ giao thức BFT nào dựa trên Narwhal thông qua 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ế uy tín lãnh đạo không tốn kém 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 giao thức DAG, xử lý theo chuỗi 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:
Các quy trình trước đây đã cố gắng chỉnh sửa 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 đưa vào DiemBFT và chính thức hóa trong Carousel, dựa trên hiệu suất trong quá khứ của các xác thực để lựa chọn động người lãnh đạo tương lai trong (Bullshark, là ý tưởng về cái neo của ). Mặc dù sự khác biệt về danh tính lãnh đạo không vi phạm tính an toàn của các giao thức này, nhưng trong Bullshark, điều đó 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 chọn cái neo vòng một cách động và xác định là cần thiết để giải quyết sự đồng thuận, trong khi các xác thực cần đạt được sự đồng thuận về lịch sử có thứ tự để chọn cái neo tương lai.
Như là bằng chứng cho độ khó của vấn đề, chúng tôi nhận thấy 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, đều không hỗ trợ những tính năng này.
Thỏa thuận
Mặc dù có những thách thức như đã nêu ở trên, nhưng 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à thực hiện khả năng lưu trữ và giải thích lại thông tin từ các vòng trước. Nhờ vào 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 theo thứ tự nhiều phiên bản Bullshark và xử lý chúng theo chuỗi, khiến cho ( điểm neo có thứ tự đầu tiên là điểm chuyển tiếp 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 uy tín của lãnh đạo.
Xử lý dây chuyền
V ánh xạ vòng đến người lãnh đạo. Shoal chạy một phiên bản của Bullshark liên tiếp, vì 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ẽ sắp xếp 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à chạy nó cho đến khi xác định được điểm neo có thứ tự đầu tiên, chẳng hạn như trong vòng r. Tất cả các người xác minh đều đồng ý với điểm neo này. Do đó, tất cả các người xác minh đều có thể đồng ý một cách chắc chắn để giải thích lại DAG từ vòng r+1. Shoal chỉ đơn giản là đã 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 điểm neo trong mỗi vòng. Điểm neo của vòng đầu tiên được sắp xếp theo thể hiện đầu tiên. Sau đó, Shoal bắt đầu một thể hiện mới ở vòng thứ hai, chính nó có một điểm neo, điểm neo đó được sắp xếp bởi thể hiện đó, sau đó, một thể hiện mới khác sắp xếp điểm neo trong vòng thứ ba, và sau đó quá trình này tiếp tục.
Danh tiếng của nhà lãnh đạo
Khi bỏ qua điểm neo trong quá trình sắp xếp Bullshark, độ trễ sẽ tăng lên. Trong trường hợp này, công nghệ xử lý theo đườ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 điểm neo của phiên bản trước đó được sắp xếp. 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ế danh tiếng để phân bổ điểm cho mỗi nút xác thực dựa trên lịch sử hoạt động gần đây của 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 số cao, ngược lại, các nút xác thực sẽ bị phân bổ điểm 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 bản đồ đã được định nghĩa trước F từ vòng đến người dẫn đầu, thiên về người dẫn đầu có điểm số cao hơn. Để các người xác minh đạt được sự đồng thuận trên bản đồ mới, họ nên đạt được sự đồng thuận về điểm số, từ đó đạt được sự đồng thuận về lịch sử được sử dụng để phát sinh điểm số.
Trong Shoal, xử lý theo dòng và uy tín của người lãnh đạo có thể kết hợp tự nhiên, vì chúng đều sử dụng cùng một công nghệ cốt lõi, đó là giải thích lại DAG sau khi đạt được sự đồng thuận về điểm neo 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 nhận viên 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 đã 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ẽ thực hiện các phiên bản mới của Bullshark bằng cách sử dụng hàm lựa chọn điểm neo đã cập nhật F'.
Không còn thời gian chờ nữa
Thời gian quá hạn đóng một vai trò quan trọng trong tất cả các triển khai BFT đồng bộ phần dựa trên 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 được quản lý và giám sát, điều này làm tăng độ phức tạp của quá trình gỡ lỗi và yêu cầu 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 thời gian chờ cho người lãnh đạo gặp sự cố. Do đó, 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ể bỏ qua những lãnh đạo tốt. Ví dụ, chúng tôi quan sát thấy, trong 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ọ có thể thúc đẩy tiến trình.
Thật không may, giao thức dựa trên người lãnh đạo ( như Hotstuff và Jolteon ) về cơ bản cần có thời gian trễ, để đảm bảo rằng mỗi khi người 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.
14 thích
Phần thưởng
14
9
Chia sẻ
Bình luận
0/400
ChainComedian
· 13giờ trước
Trễ giảm nhiều như vậy, cảm giác có thể làm một cú lớn.
Xem bản gốcTrả lời0
YouMustMakeBigMoneyEvery
· 07-19 04:14
vượt qua so l
Xem bản gốcTrả lời0
YouMustMakeBigMoneyEvery
· 07-19 04:14
Kiên định HODL💎
Xem bản gốcTrả lời0
VirtualRichDream
· 07-19 03:33
Trễ Thả这么多 aptos走起来了
Xem bản gốcTrả lời0
FOMOSapien
· 07-19 03:33
Giảm Trễ còn không bằng trực tiếp A xuống tổng thống
Xem bản gốcTrả lời0
BearEatsAll
· 07-19 03:30
aptos còn nhanh hơn nữa? bull啊
Xem bản gốcTrả lời0
PaperHandsCriminal
· 07-19 03:26
Quỷ biết việc thả trễ này có tác dụng gì, vẫn không thể ngăn cản tôi bị chơi đùa với mọi người.
Xem bản gốcTrả lời0
ApeShotFirst
· 07-19 03:23
lại tăng lên không chết trễ thì hủy niêm yết
Xem bản gốcTrả lời0
BlockchainFries
· 07-19 03:15
Nhìn thấy trễ giảm nhiều như vậy, thì trước tiên mua một vị thế nhỏ thôi.
Khung Shoal thả trễ nhận thức chung Bullshark trên Aptos
Khung Shoal: Thả độ trễ Bullshark trên Aptos bằng giải pháp mới
Aptos Labs gần đây đã 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 dụng xác định. Tổng thể, trong trường hợp không có lỗi, độ trễ của Bullshark đã được cải thiện 40%, trong trường hợp có lỗi đã được cải thiện 80%.
Shoal là một khung tăng cường giao thức đồng thuận dựa trên Narwhal ( thông qua xử lý theo dòng và cơ chế uy tín của người lãnh đạo. Xử lý theo dòng giảm trễ sắp xếp DAG bằng cách giới thiệu các điểm neo trong mỗi vòng, trong khi cơ chế 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 các điểm neo 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 việc xây dựng DAG bất đồng bộ để loại bỏ thời gian chờ trong tất cả các kịch bản. Điều này cho phép Shoal cung cấp thuộc tính được gọi là "phản hồi phổ quát", nó bao gồm phản hồi lạc quan thường cần thiết.
Công nghệ của Shoal khá đơ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ự một cách tuần 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 một cuộc tiếp sức.
![Giải thích chi tiết Shoal framework: Làm thế nào để Thả Bullshark trên Aptos?])https://img-cdn.gateio.im/webp-social/moments-8d6acd885bad7b8f911bdce15a7c884f.webp(
Bối cảnh
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 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 của chúng tôi.
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 các giao thức của các nhà lãnh đạo, 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, đề 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. Tài liệu Narwhal báo cáo khả năng thông lượng 160,000 TPS.
Chúng tôi đã thực hiện Quorum Store của Narwhal để tách biệt việc truyền dữ liệu và đồng thuận, nhằm mở rộng giao thức đồng thuận hiện tại là Jolteon. Jolteon là một giao thức dựa trên lãnh đạo, kết hợp giữa đường dẫn nhanh tuyến tính của Tendermint và sự thay đổi quan điểm theo phong cách PBFT, có thể Thả độ trễ của Hotstuff xuống 33%. Tuy nhiên, 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ù đã tách biệt việc truyền dữ liệu và đồng thuận, 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 trên Narwhal DAG, một giao thức đồng thuận không tốn chi phí truyền thô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 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, người xác thực phải trước tiên có được n-f đỉnh thuộc vòng r-1. Mỗi người xác thực 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 người xác thực khác nhau có thể quan sát các quan điểm 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 chính 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 DAG của chúng, thì chúng có lịch sử nguyên nhân v hoàn toàn giống nhau.
![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-f6b6281c928e3fa7a2412a480c9c1806.webp(
Tổng序
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ó chi phí giao tiếp bổ sung. Để làm được đ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, còn các cạnh đại diện cho việc bỏ phiế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 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 sắp xếp: Các người xác thực độc lập nhưng một cách xác định quyết định sắp xếp 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 nhận viên xử lý từng điểm neo theo thứ tự trong danh sách điểm neo có thứ tự, và đối với mỗi điểm neo, họ sắp xếp tất cả các đỉnh chưa có thứ tự trước đó trong lịch sử nguyên nhân của nó theo các quy tắc xác định.
Điều quan trọng để đảm bảo an toàn là đảm bảo rằng trong bước )2(, tất cả các nút xác thực trung thực tạo ra 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 nêu trên:
Tất cả các xác thực viên đều đồng ý với điểm neo có thứ tự đầu tiên.
Bullshark Trễ
Độ trễ của Bullshark phụ thuộc vào số vòng giữa các điểm neo có thứ tự trong DAG. Mặc dù phiên bản đồng bộ của Bullshark 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.
Vấn đề 1: Thời gian trễ trung bình của khối. Trong Bullshark, mỗi vòng chẵn có một điểm neo, và các đỉnh của vòng lẻ được hiểu là bỏ phiế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 các điểm neo cần nhiều vòng hơn để chờ các đ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.
Vấn đề 2: Trường hợp lỗi trễ, phân tích trễ nêu 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 thể 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 đượ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ì Bullshark sử dụng thời gian chờ để chờ nhà 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-b7ed8888da112bae8d34c0fdb338b138.webp(
Khung Shoal
Shoal đã cải thiện Bullshark) hoặc bất kỳ giao thức BFT nào dựa trên Narwhal thông qua 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ế uy tín lãnh đạo không tốn kém 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 giao thức DAG, xử lý theo chuỗi 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:
Các quy trình trước đây đã cố gắng chỉnh sửa 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 đưa vào DiemBFT và chính thức hóa trong Carousel, dựa trên hiệu suất trong quá khứ của các xác thực để lựa chọn động người lãnh đạo tương lai trong (Bullshark, là ý tưởng về cái neo của ). Mặc dù sự khác biệt về danh tính lãnh đạo không vi phạm tính an toàn của các giao thức này, nhưng trong Bullshark, điều đó 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 chọn cái neo vòng một cách động và xác định là cần thiết để giải quyết sự đồng thuận, trong khi các xác thực cần đạt được sự đồng thuận về lịch sử có thứ tự để chọn cái neo tương lai.
Như là bằng chứng cho độ khó của vấn đề, chúng tôi nhận thấy 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, đều không hỗ trợ những tính năng này.
Thỏa thuận
Mặc dù có những thách thức như đã nêu ở trên, nhưng 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à thực hiện khả năng lưu trữ và giải thích lại thông tin từ các vòng trước. Nhờ vào 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 theo thứ tự nhiều phiên bản Bullshark và xử lý chúng theo chuỗi, khiến cho ( điểm neo có thứ tự đầu tiên là điểm chuyển tiếp 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 uy tín của lãnh đạo.
Xử lý dây chuyền
V ánh xạ vòng đến người lãnh đạo. Shoal chạy một phiên bản của Bullshark liên tiếp, vì 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ẽ sắp xếp 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à chạy nó cho đến khi xác định được điểm neo có thứ tự đầu tiên, chẳng hạn như trong vòng r. Tất cả các người xác minh đều đồng ý với điểm neo này. Do đó, tất cả các người xác minh đều có thể đồng ý một cách chắc chắn để giải thích lại DAG từ vòng r+1. Shoal chỉ đơn giản là đã 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 điểm neo trong mỗi vòng. Điểm neo của vòng đầu tiên được sắp xếp theo thể hiện đầu tiên. Sau đó, Shoal bắt đầu một thể hiện mới ở vòng thứ hai, chính nó có một điểm neo, điểm neo đó được sắp xếp bởi thể hiện đó, sau đó, một thể hiện mới khác sắp xếp điểm neo trong vòng thứ ba, và sau đó quá trình này tiếp tục.
Danh tiếng của nhà lãnh đạo
Khi bỏ qua điểm neo trong quá trình sắp xếp Bullshark, độ trễ sẽ tăng lên. Trong trường hợp này, công nghệ xử lý theo đườ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 điểm neo của phiên bản trước đó được sắp xếp. 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ế danh tiếng để phân bổ điểm cho mỗi nút xác thực dựa trên lịch sử hoạt động gần đây của 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 số cao, ngược lại, các nút xác thực sẽ bị phân bổ điểm 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 bản đồ đã được định nghĩa trước F từ vòng đến người dẫn đầu, thiên về người dẫn đầu có điểm số cao hơn. Để các người xác minh đạt được sự đồng thuận trên bản đồ mới, họ nên đạt được sự đồng thuận về điểm số, từ đó đạt được sự đồng thuận về lịch sử được sử dụng để phát sinh điểm số.
Trong Shoal, xử lý theo dòng và uy tín của người lãnh đạo có thể kết hợp tự nhiên, vì chúng đều sử dụng cùng một công nghệ cốt lõi, đó là giải thích lại DAG sau khi đạt được sự đồng thuận về điểm neo 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 nhận viên 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 đã 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ẽ thực hiện các phiên bản mới của Bullshark bằng cách sử dụng hàm lựa chọn điểm neo đã cập nhật F'.
Không còn thời gian chờ nữa
Thời gian quá hạn đóng một vai trò quan trọng trong tất cả các triển khai BFT đồng bộ phần dựa trên 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 được quản lý và giám sát, điều này làm tăng độ phức tạp của quá trình gỡ lỗi và yêu cầu 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 thời gian chờ cho người lãnh đạo gặp sự cố. Do đó, 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ể bỏ qua những lãnh đạo tốt. Ví dụ, chúng tôi quan sát thấy, trong 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ọ có thể thúc đẩy tiến trình.
Thật không may, giao thức dựa trên người lãnh đạo ( như Hotstuff và Jolteon ) về cơ bản cần có thời gian trễ, để đảm bảo rằng mỗi khi người lãnh đạo gặp sự cố.