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ề thời gian chờ trong giao thức thực dụng xác định. Tổng thể, khung Shoal đã cải thiện trễ của Bullshark 40% 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 công tác nâng cao bất kỳ giao thức đồng thuận dựa trên Narwhal nào, như DAG-Rider, Tusk, Bullshark (, thông qua cơ chế đường ống và uy tín của người dẫn đầu. Đường ống giúp 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, còn uy tín của người dẫn đầu cải thiện thêm thời gian trễ bằng cách đảm bảo rằng 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 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 thời gian chờ. Điều này cho phép Shoal cung cấp một đặc tính được gọi là phản hồi phổ quát, bao gồm những phản hồi lạc quan thường cần thiết.
Ý tưởng cốt lõi của Shoal rất đơn giản, đó là 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 bằng Bullshark, chúng ta có một nhóm "cá mập" đang tham gia vào một cuộc tiếp sứ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-8d6acd885bad7b8f911bdce15a7c884f.webp(
Động cơ
Trong quá trình theo đuổi hiệu suất cao của mạng blockchain, mọi người luôn chú ý đến việc thả độ phức tạp 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 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 100.000+ TPS.
Đột phá gần đây xuất phát từ việc nhận ra rằng việc phát tán dữ liệu là điểm nghẽn chính dựa trên giao thức lãnh đạo, có thể thu lợi từ việc song song hóa. Hệ thống Narwhal tách rời việc phát tán dữ liệu với logic đồng thuận cốt lõi, đề xuất một kiến trúc trong đó tất cả các xác thực viên đồng thời phát tá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 thông lượng 160.000 TPS.
Trong bài viết trước, chúng tôi đã giới thiệu Quorum Store - triển khai Narwhal của chúng tôi, nó tách biệt việc truyền dữ liệu và đồng thuận, cũng như cách chúng tôi sử dụng nó để mở rộng giao thức đồng thuận hiện tại Jolteon. Jolteon là một giao thức dựa trên người lãnh đạo, kết hợp đường dẫn nhanh tuyến tính của Tendermint và thay đổi chế độ xem theo phong cách PBFT, có thể Thả độ 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ể tận dụng đầy đủ tiềm năng thông lượng của Narwhal. Mặc dù việc truyền dữ liệu và đồng thuận được tách biệt, nhưng với việc thông lượng tăng lên, người lãnh đạo của Hotstuff/Jolteon vẫn bị hạn chế.
Do đó, chúng tôi quyết định triển khai Bullshark trên Narwhal DAG, một giao thức đồng thuận có chi phí giao tiếp bằng không. Thật không may, so với Jolteon, cấu trúc DAG hỗ trợ Bullshark có thông lượng cao đã mang lại chi phí trễ 50%.
Bài viết này giới thiệu cách Shoal thực hiện việc thả trễ Bullshark.
Bối cảnh DAG-BFT
Mỗi đỉnh trong Narwhal DAG đều liên kết với một vòng. Để vào vòng thứ r, các xác thực viên phải nhận đượ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, và mỗi đỉnh ít nhất phải tham chiếu đến n-f đỉnh của vòng trước. Do mạng không đồng bộ, các xác thực viên khác nhau có thể quan sát những cái 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 là tính không mâu thuẫn: nếu hai nút xác thực có cùng đỉnh v trong cái nhìn địa phương của DAG của chúng, thì chúng có lịch sử nguyên nhân hoàn toàn giống nhau của v.
![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-f6b6281c928e3fa7a2412a480c9c1806.webp(
Tổng序
Có thể đạt được sự đồng thuận về thứ tự tổng thể của tất cả các đỉnh trong DAG mà không có chi phí giao tiếp bổ sung. Để làm điều này, các xác 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 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 được đặt trước: Sau mỗi vài vòng ) như trong Bullshark, sẽ có một nhà lãnh đạo được đặt 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 xác nhận viên độc lập nhưng quyết định một cách xác định điểm neo nào sẽ được sắp xếp và điểm neo nào sẽ bị bỏ qua.
Sắp xếp lịch sử nguyên nhân: Các xác thực viên xử lý từng danh sách điểm neo có thứ tự, đố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ó bằng cách sử dụng các 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), tất cả các nút xác thực trung thực tạo ra một danh sách điểm neo có thứ tự, để tất cả các danh sách chia sẻ cùng một tiền tố. Trong Shoal, chúng tôi đưa ra những quan sát sau về tất cả các giao thức trên:
Tất cả các validator đều đồng ý với điểm neo đầu tiên theo thứ tự.
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 thực dụng nhất của Bullshark có độ trễ tốt hơn phiên bản bất đồng bộ, nhưng nó vẫn còn xa mới 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, mỗi đỉnh của vòng lẻ được hiểu là một 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ờ 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ễ trong các trường hợp lỗi. 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 một vòng lãnh đạ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 đượ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ẽ làm 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 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 là điểm neo trong DAG xuống ba vòng. Shoal cũng đã giới thiệu cơ chế danh tiếng lãnh đạo không tốn kém trong DAG, điều này khiến việc lựa chọn nghiêng về phía 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 với các lý do sau:
Các nỗ lực trước đây để sửa đổi logic Bullshark cốt lõi dường như về bản chất 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à lựa chọn động cho người 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 (Bullshark, ý tưởng về một cái neo trong ). Mặc dù có sự khác biệt trong danh tính người 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, điều này nêu bật vấn đề cốt lõi, tức là việc lựa 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 viên cần đạt được sự đồng thuận về lịch sử có thứ tự để chọn cái neo tương lai.
Như một bằng chứng cho độ khó của vấn đề, chúng tôi lưu ý rằng việc triển khai 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.
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ằm 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à đã实现 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 ý của tất cả các xác thực viên về cái nhìn cốt lõi của điểm neo có thứ tự đầu tiên, Shoal kết hợp tuần tự nhiều phiên bản Bullshark để xử lý theo chuỗi, khiến cho ( điểm neo có thứ tự đầu tiên là điểm chuyển giao của các phiên bản, cũng như ) lịch sử nguyên nhân của các điểm neo được sử dụng để tính toán danh tiếng của người lãnh đạo.
Dòng chảy
V sẽ ánh xạ vòng đến người lãnh đạo. Shoal chạy một phiên bản của Bullshark theo thứ tự, để 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 xếp hạng một điểm neo, điều này sẽ kích hoạt chuyển sang phiên bản tiếp theo.
Ban đầu, Shoal khởi động phiên bản đầu tiên của Bullshark trong vòng đầu tiên của DAG và vận hành nó cho đến khi xác định được điểm neo có thứ tự đầu tiên, chẳng hạn như trong vòng r. Tất cả các xác thực viên đều đồng ý với điểm neo này. Do đó, tất cả các xác thực viên có thể đồng ý một cách chắc chắn rằng sẽ giải thích lại DAG bắt đầu 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 xếp hạng 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 ví dụ đầu tiên. Sau đó, Shoal bắt đầu một ví dụ mới trong vòng thứ hai, nó có một điểm neo, điểm neo đó được sắp xếp bởi ví dụ đó, sau đó, một ví dụ mới khác xếp hạng điểm neo trong vòng thứ ba, và sau đó quá trình này tiếp tục.
Danh tiếng của lãnh đạo
Khi bỏ qua điểm neo trong thời gian sắp xếp Bullshark, Trễ sẽ tăng lên. Trong trường hợp này, công nghệ đường ống không thể làm gì, vì không thể khởi động 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 khả năng chọn lãnh đạo tương ứng để xử lý các điểm neo bị mất trong tương lai là không cao bằng cách sử dụng cơ chế danh tiếng để phân bổ điểm cho mỗi nút xác minh dựa trên lịch sử hoạt động gần đây của chúng. Các xác minh viên phản hồi và tham gia vào giao thức sẽ nhận được điểm cao, nếu không, các nút xác minh 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 ác.
Ý tưởng của nó là mỗi khi cập nhật điểm số, sẽ tính toán lại một cách xác định ánh xạ đã định nghĩa trước từ vòng đến người dẫn dắt F, thiên về những người dẫn dắt có điểm số cao hơn. Để các trình xác thực đạ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 để phát sinh điểm số.
Trong Shoal, quy trình và uy tín 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, tức là tái giải thích DAG sau khi đạt được sự đồng thuận ở điểm neo thứ nhất.
Trên thực tế, sự khác biệt duy nhất là, sau khi sắp xếp các điểm neo trong vòng thứ r, các xác thực chỉ cần dựa vào lịch sử nguyên nhân của các điểm neo đã sắp xếp trong vòng thứ r để tính toán ánh xạ mới F' từ vòng thứ r+1. Sau đó, các nút xác thực bắt đầu sử dụng hàm lựa chọn điểm neo được cập nhật F' để thực hiện các phiên bản mới của Bullshark từ vòng thứ r+1.
Không còn thời gian 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 định hướng 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ẽ tăng đáng kể trễ, vì việc cấu hình chúng một cách phù hợp là rất quan trọng, và thường cần phải điều chỉnh động, vì nó phụ thuộc rất 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ả toàn bộ hình phạt trễ thời gian chờ cho 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 lãnh đạo tốt. Ví dụ, chúng tôi quan sát thấy, trong các tình huống tải cao, 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 độ.
Không may, dựa trên giao thức của nhà lãnh đạo ( như Hotstuff
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.
16 thích
Phần thưởng
16
10
Chia sẻ
Bình luận
0/400
TokenomicsTrapper
· 07-16 23:24
khói và gương vc cổ điển... 40% không có nghĩa gì nếu độ trễ cơ bản là rác thật lòng mà nói
Xem bản gốcTrả lời0
rekt_but_resilient
· 07-16 17:01
Trễ giảm tám thành? Phải to da moon rồi.
Xem bản gốcTrả lời0
NestedFox
· 07-16 09:09
Tám mươi độ cải tiến tuyệt vời rồi
Xem bản gốcTrả lời0
Blockwatcher9000
· 07-15 13:37
Còn đang chiến thắng Trễ nha mạnh
Xem bản gốcTrả lời0
GasFeePhobia
· 07-14 02:57
40 không 80 quá mạnh rồi? Hiệu quả khá tốt.
Xem bản gốcTrả lời0
MEVHunterBearish
· 07-14 02:55
Điều này có ích gì? Chúng ta chỉ là nhìn tăng lên chứ không nhìn giảm.
Khung Shoal thả đáng kể trễ Bullshark trên Aptos, đạt được nhận thức chung không có thời gian hết hạn.
Khung Shoal: Thả lớn 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ề thời gian chờ trong giao thức thực dụng xác định. Tổng thể, khung Shoal đã cải thiện trễ của Bullshark 40% 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 công tác nâng cao bất kỳ giao thức đồng thuận dựa trên Narwhal nào, như DAG-Rider, Tusk, Bullshark (, thông qua cơ chế đường ống và uy tín của người dẫn đầu. Đường ống giúp 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, còn uy tín của người dẫn đầu cải thiện thêm thời gian trễ bằng cách đảm bảo rằng 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 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 thời gian chờ. Điều này cho phép Shoal cung cấp một đặc tính được gọi là phản hồi phổ quát, bao gồm những phản hồi lạc quan thường cần thiết.
Ý tưởng cốt lõi của Shoal rất đơn giản, đó là 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 bằng Bullshark, chúng ta có một nhóm "cá mập" đang tham gia vào một cuộc tiếp sứ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-8d6acd885bad7b8f911bdce15a7c884f.webp(
Động cơ
Trong quá trình theo đuổi hiệu suất cao của mạng blockchain, mọi người luôn chú ý đến việc thả độ phức tạp 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 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 100.000+ TPS.
Đột phá gần đây xuất phát từ việc nhận ra rằng việc phát tán dữ liệu là điểm nghẽn chính dựa trên giao thức lãnh đạo, có thể thu lợi từ việc song song hóa. Hệ thống Narwhal tách rời việc phát tán dữ liệu với logic đồng thuận cốt lõi, đề xuất một kiến trúc trong đó tất cả các xác thực viên đồng thời phát tá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 thông lượng 160.000 TPS.
Trong bài viết trước, chúng tôi đã giới thiệu Quorum Store - triển khai Narwhal của chúng tôi, nó tách biệt việc truyền dữ liệu và đồng thuận, cũng như cách chúng tôi sử dụng nó để mở rộng giao thức đồng thuận hiện tại Jolteon. Jolteon là một giao thức dựa trên người lãnh đạo, kết hợp đường dẫn nhanh tuyến tính của Tendermint và thay đổi chế độ xem theo phong cách PBFT, có thể Thả độ 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ể tận dụng đầy đủ tiềm năng thông lượng của Narwhal. Mặc dù việc truyền dữ liệu và đồng thuận được tách biệt, nhưng với việc thông lượng tăng lên, người lãnh đạo của Hotstuff/Jolteon vẫn bị hạn chế.
Do đó, chúng tôi quyết định triển khai Bullshark trên Narwhal DAG, một giao thức đồng thuận có chi phí giao tiếp bằng không. Thật không may, so với Jolteon, cấu trúc DAG hỗ trợ Bullshark có thông lượng cao đã mang lại chi phí trễ 50%.
Bài viết này giới thiệu cách Shoal thực hiện việc thả trễ Bullshark.
Bối cảnh DAG-BFT
Mỗi đỉnh trong Narwhal DAG đều liên kết với một vòng. Để vào vòng thứ r, các xác thực viên phải nhận đượ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, và mỗi đỉnh ít nhất phải tham chiếu đến n-f đỉnh của vòng trước. Do mạng không đồng bộ, các xác thực viên khác nhau có thể quan sát những cái 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 là tính không mâu thuẫn: nếu hai nút xác thực có cùng đỉnh v trong cái nhìn địa phương của DAG của chúng, thì chúng có lịch sử nguyên nhân hoàn toàn giống nhau của v.
![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-f6b6281c928e3fa7a2412a480c9c1806.webp(
Tổng序
Có thể đạt được sự đồng thuận về thứ tự tổng thể của tất cả các đỉnh trong DAG mà không có chi phí giao tiếp bổ sung. Để làm điều này, các xác 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 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 được đặt trước: Sau mỗi vài vòng ) như trong Bullshark, sẽ có một nhà lãnh đạo được đặt 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 xác nhận viên độc lập nhưng quyết định một cách xác định điểm neo nào sẽ được sắp xếp và điểm neo nào sẽ bị bỏ qua.
Sắp xếp lịch sử nguyên nhân: Các xác thực viên xử lý từng danh sách điểm neo có thứ tự, đố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ó bằng cách sử dụng các 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), tất cả các nút xác thực trung thực tạo ra một danh sách điểm neo có thứ tự, để tất cả các danh sách chia sẻ cùng một tiền tố. Trong Shoal, chúng tôi đưa ra những quan sát sau về tất cả các giao thức trên:
Tất cả các validator đều đồng ý với điểm neo đầu tiên theo thứ tự.
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 thực dụng nhất của Bullshark có độ trễ tốt hơn phiên bản bất đồng bộ, nhưng nó vẫn còn xa mới 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, mỗi đỉnh của vòng lẻ được hiểu là một 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ờ 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ễ trong các trường hợp lỗi. 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 một vòng lãnh đạ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 đượ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ẽ làm 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 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 là điểm neo trong DAG xuống ba vòng. Shoal cũng đã giới thiệu cơ chế danh tiếng lãnh đạo không tốn kém trong DAG, điều này khiến việc lựa chọn nghiêng về phía 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 với các lý do sau:
Các nỗ lực trước đây để sửa đổi logic Bullshark cốt lõi dường như về bản chất 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à lựa chọn động cho người 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 (Bullshark, ý tưởng về một cái neo trong ). Mặc dù có sự khác biệt trong danh tính người 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, điều này nêu bật vấn đề cốt lõi, tức là việc lựa 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 viên cần đạt được sự đồng thuận về lịch sử có thứ tự để chọn cái neo tương lai.
Như một bằng chứng cho độ khó của vấn đề, chúng tôi lưu ý rằng việc triển khai 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.
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ằm 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à đã实现 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 ý của tất cả các xác thực viên về cái nhìn cốt lõi của điểm neo có thứ tự đầu tiên, Shoal kết hợp tuần tự nhiều phiên bản Bullshark để xử lý theo chuỗi, khiến cho ( điểm neo có thứ tự đầu tiên là điểm chuyển giao của các phiên bản, cũng như ) lịch sử nguyên nhân của các điểm neo được sử dụng để tính toán danh tiếng của người lãnh đạo.
Dòng chảy
V sẽ ánh xạ vòng đến người lãnh đạo. Shoal chạy một phiên bản của Bullshark theo thứ tự, để 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 xếp hạng một điểm neo, điều này sẽ kích hoạt chuyển sang phiên bản tiếp theo.
Ban đầu, Shoal khởi động phiên bản đầu tiên của Bullshark trong vòng đầu tiên của DAG và vận hành nó cho đến khi xác định được điểm neo có thứ tự đầu tiên, chẳng hạn như trong vòng r. Tất cả các xác thực viên đều đồng ý với điểm neo này. Do đó, tất cả các xác thực viên có thể đồng ý một cách chắc chắn rằng sẽ giải thích lại DAG bắt đầu 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 xếp hạng 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 ví dụ đầu tiên. Sau đó, Shoal bắt đầu một ví dụ mới trong vòng thứ hai, nó có một điểm neo, điểm neo đó được sắp xếp bởi ví dụ đó, sau đó, một ví dụ mới khác xếp hạng điểm neo trong vòng thứ ba, và sau đó quá trình này tiếp tục.
Danh tiếng của lãnh đạo
Khi bỏ qua điểm neo trong thời gian sắp xếp Bullshark, Trễ sẽ tăng lên. Trong trường hợp này, công nghệ đường ống không thể làm gì, vì không thể khởi động 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 khả năng chọn lãnh đạo tương ứng để xử lý các điểm neo bị mất trong tương lai là không cao bằng cách sử dụng cơ chế danh tiếng để phân bổ điểm cho mỗi nút xác minh dựa trên lịch sử hoạt động gần đây của chúng. Các xác minh viên phản hồi và tham gia vào giao thức sẽ nhận được điểm cao, nếu không, các nút xác minh 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 ác.
Ý tưởng của nó là mỗi khi cập nhật điểm số, sẽ tính toán lại một cách xác định ánh xạ đã định nghĩa trước từ vòng đến người dẫn dắt F, thiên về những người dẫn dắt có điểm số cao hơn. Để các trình xác thực đạ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 để phát sinh điểm số.
Trong Shoal, quy trình và uy tín 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, tức là tái giải thích DAG sau khi đạt được sự đồng thuận ở điểm neo thứ nhất.
Trên thực tế, sự khác biệt duy nhất là, sau khi sắp xếp các điểm neo trong vòng thứ r, các xác thực chỉ cần dựa vào lịch sử nguyên nhân của các điểm neo đã sắp xếp trong vòng thứ r để tính toán ánh xạ mới F' từ vòng thứ r+1. Sau đó, các nút xác thực bắt đầu sử dụng hàm lựa chọn điểm neo được cập nhật F' để thực hiện các phiên bản mới của Bullshark từ vòng thứ r+1.
Không còn thời gian 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 định hướng 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ẽ tăng đáng kể trễ, vì việc cấu hình chúng một cách phù hợp là rất quan trọng, và thường cần phải điều chỉnh động, vì nó phụ thuộc rất 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ả toàn bộ hình phạt trễ thời gian chờ cho 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 lãnh đạo tốt. Ví dụ, chúng tôi quan sát thấy, trong các tình huống tải cao, 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 độ.
Không may, dựa trên giao thức của nhà lãnh đạo ( như Hotstuff