Các phòng thí nghiệm của Aptos đã giải quyết được hai vấn đề mở quan trọng trong DAG BFT, giúp giảm đáng kể độ trễ và lần đầu tiên loại bỏ nhu cầu tạm dừng trong các giao thức thực tế xác định. Nhìn chung, điều này giúp cải thiện độ trễ của Bullshark lên 40% trong trường hợp không có lỗi và 80% trong trường hợp có lỗi.
Shoal là một khuôn khổ nâng cao bất kỳ giao thức đồng thuận dựa trên Kỳ lân biển nào (ví dụ: DAG-Rider, Tusk, Bullshark) thông qua đường ống dẫn và danh tiếng của nhà lãnh đạo. Hệ thống đường ống giảm độ trễ đặt hàng DAG bằng cách giới thiệu một điểm cố định cho mỗi vòng và danh tiếng của người dẫn đầu sẽ cải thiện độ trễ hơn nữa bằng cách đảm bảo rằng các điểm cố định được liên kết với trình xác thực nhanh nhất. Ngoài ra, danh tiếng của nhà lãnh đạo cho phép Shoal tận dụng cấu trúc DAG không đồng bộ để loại bỏ thời gian chờ trong mọi tình huống. Điều này cho phép Shoal cung cấp một thuộc tính mà chúng tôi đặt tên là Phản hồi toàn cầu, chứa Phản hồi lạc quan thường được yêu cầu.
Kỹ thuật của chúng tôi rất đơn giản, nó liên quan đến việc chạy tuần tự nhiều phiên bản của giao thức cơ bản. Vì vậy, khi khởi tạo với Bullshark, chúng ta có một nhóm "cá mập" đang chạy tiếp sức.
Động lực
Để theo đuổi hiệu suất cao trong các mạng chuỗi khối, đã có sự tập trung liên tục vào việc giảm độ phức tạp của giao tiếp. Tuy nhiên, cách tiếp cận này không dẫn đến sự gia tăng đáng kể về thông lượng. Ví dụ: việc triển khai Hotstuff trong phiên bản đầu tiên của Diem chỉ đạt được 3500 TPS, thấp hơn nhiều so với mục tiêu của chúng tôi là đạt được 100k+ TPS.
Tuy nhiên, những đột phá gần đây bắt nguồn từ việc nhận ra rằng việc truyền dữ liệu là nút cổ chai chính của các giao thức dựa trên người dẫn đầu và nó có thể được hưởng lợi từ việc song song hóa. Hệ thống Narwhal tách việc truyền dữ liệu khỏi logic đồng thuận cốt lõi và đề xuất một kiến trúc trong đó tất cả các trình xác thực truyền dữ liệu đồng thời, trong khi các thành phần đồng thuận chỉ yêu cầu một lượng siêu dữ liệu nhỏ hơn. Bài viết về Kỳ lân biển báo cáo thông lượng là 160.000 TPS.
Trong một bài viết trước, chúng tôi đã giới thiệu Quorum Store. Việc triển khai Narwhal của chúng tôi tách riêng việc truyền bá dữ liệu khỏi sự đồng thuận và cách chúng tôi sử dụng điều này để mở rộng giao thức đồng thuận hiện tại của chúng tôi, Jolteon. Jolteon là một giao thức dựa trên nhà lãnh đạo kết hợp đường dẫn nhanh tuyến tính của Tendermint với các thay đổi chế độ xem kiểu PBFT để giảm 33% độ trễ của Hotstuff. Tuy nhiên, rõ ràng là một giao thức đồng thuận dựa trên nhà lãnh đạo không thể khai thác hết tiềm năng thông lượng của Kỳ lân biển. Mặc dù tách biệt việc truyền dữ liệu khỏi sự đồng thuận, các nhà lãnh đạo của Hotstuff/Jolteon vẫn bị hạn chế khi thông lượng tăng lên.
Do đó, chúng tôi đã quyết định triển khai Bullshark, một giao thức đồng thuận với chi phí liên lạc bằng không, trên Narwhal DAG. Thật không may, cấu trúc DAG hỗ trợ thông lượng cao của Bullshark đi kèm với hình phạt về độ trễ 50% so với Jolteon.
Trong bài đăng này, chúng tôi mô tả cách Shoal giảm đáng kể độ trễ của Bullshark.
Nền DAG-BFT
Hãy bắt đầu bằng cách tìm hiểu nền tảng liên quan của bài viết này. Để biết mô tả chi tiết về Kỳ lân biển và Cá mập bò, vui lòng tham khảo bài đăng DAG gặp BFT.
Mỗi đỉnh trong DAG kỳ lân biển được liên kết với một số tròn. Để vào vòng r, trước tiên người xác minh phải có được nf đỉnh thuộc vòng r-1. Mỗi trình xác minh có thể phát một đỉnh trong mỗi vòng và mỗi đỉnh tham chiếu đến ít nhất nf đỉnh trong vòng trước đó. Do mạng không đồng bộ, các trình xác thực khác nhau có thể quan sát các chế độ xem cục bộ khác nhau của DAG tại bất kỳ thời điểm nào. Dưới đây là một minh họa về một chế độ xem một phần có thể:
Hình 1: Lịch sử nhân quả của các đỉnh được xác định bởi nút xác thực vòng 2 2 được đánh dấu bằng màu xanh lục
Một thuộc tính quan trọng của DAG không phải là sự mơ hồ: hai trình xác thực có lịch sử nhân quả giống hệt nhau của v nếu chúng có cùng một đỉnh v trong chế độ xem cục bộ của chúng về DAG.
Tổng đơn hàng
Có thể đồng ý về tổng thứ tự của tất cả các đỉnh trong DAG mà không cần thêm chi phí liên lạc. Để đạt được mục tiêu này, các trình xác thực trong DAG-Rider, Tusk và Bullshark diễn giải 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 điểm nhóm khác nhau về cấu trúc DAG, nhưng tất cả các giao thức đồng thuận dựa trên Kỳ lân biển hiện có đều có cấu trúc sau:
Các mỏ neo được xác định trước, cứ sau vài vòng sẽ có một người dẫn đầu được xác định trước (ví dụ: hai vòng trong Bullshark) và các đỉnh của người dẫn đầu được gọi là mỏ neo;
Đặt hàng các neo, người xác minh quyết định một cách độc lập nhưng dứt khoát nên đặt các neo nào và bỏ qua các neo nào;
Sắp xếp lịch sử nhân quả, trong đó trình xác thực xử lý từng danh sách neo được sắp xếp theo thứ tự của họ và đối với mỗi neo, sắp xếp tất cả các đỉnh không có thứ tự trước đó trong lịch sử nhân quả của nó theo một số quy tắc xác định.
Hình 2: Minh họa về chế độ xem một phần có thể có của DAG trong giao thức Bullshark. Trong ví dụ này, các neo màu đỏ và màu vàng được sắp xếp, trong khi màu xanh lá cây (không có trong DAG) bị bỏ qua. Do đó, để đặt hàng DAG, trình xác thực sẽ sắp xếp thứ tự lịch sử nhân quả của các neo màu đỏ trước, sau đó là các neo màu vàng.
Chìa khóa để đáp ứng tính bảo mật là đảm bảo rằng ở bước (2) ở trên, tất cả các trình xác thực trung thực đều tạo một danh sách các điểm neo được sắp xếp theo thứ tự sao cho tất cả các danh sách đều có chung một tiền tố. Tại Shoal, chúng tôi thực hiện các quan sát sau đối với tất cả các giao thức trên:
** Tất cả những người xác thực đều đồng ý về mỏ neo được đặt hàng đầu tiên. **
Độ trễ của Bullshark
Độ trễ của Bullshark phụ thuộc vào số vòng giữa các neo được sắp xếp theo thứ tự trong DAG. Mặc dù phiên bản đồng bộ một phần hữu ích nhất của Bullshark có độ trễ tốt hơn phiên bản không đồng bộ, nhưng nó không phải là tối ưu.
Vấn đề 1: Độ trễ khối trung bình. Trong Bullshark, mỗi vòng chẵn đều có một mỏ neo và các đỉnh của mỗi vòng lẻ được hiểu là phiếu bầu. Thông thường, phải mất hai vòng DAG để đặt hàng các mỏ neo, tuy nhiên, các đỉnh trong lịch sử nhân quả của một mỏ neo sẽ mất nhiều vòng hơn để chờ một mỏ neo được đặt hàng. Trong trường hợp phổ biến, các đỉnh trong các vòng lẻ yêu cầu ba vòng, trong khi các đỉnh không neo trong các vòng chẵn yêu cầu bốn vòng (xem Hình 3).
Hình 3: Trong trường hợp phổ biến, các neo ở vòng i+1 cần được sắp xếp cho hai vòng. Các đỉnh trong vòng i được sắp xếp đồng thời nên độ trễ của chúng là ba vòng. Tuy nhiên, các đỉnh trong vòng i+1 phải đợi neo tiếp theo được sắp xếp (đỉnh trong vòng i+3), vì vậy độ trễ sắp xếp của chúng là bốn vòng.
Vấn đề 2: Độ trễ của trường hợp lỗi, phân tích độ trễ ở trên áp dụng cho trường hợp không lỗi, mặt khác, nếu người dẫn đầu vòng không phát các neo đủ nhanh, các neo không thể được đặt hàng (và do đó bị bỏ qua), vì vậy Tất cả các đỉnh chưa được sắp xếp trong các vòng trước phải đợi neo tiếp theo được sắp xếp. Điều này có thể làm giảm đáng kể hiệu suất của mạng được sao chép địa lý, đặc biệt là khi Bullshark sử dụng thời gian chờ chờ người dẫn đầu.
Khuôn khổ Shoal
Shoal giải quyết cả hai vấn đề về độ trễ này bằng cách tăng cường Bullshark (hoặc bất kỳ giao thức BFT dựa trên Kỳ lân biển nào khác) bằng cách tạo đường ống, cho phép neo trong mỗi vòng và giảm độ trễ của tất cả các đỉnh không phải neo trong DAG xuống còn ba vòng. Shoal cũng giới thiệu một cơ chế danh tiếng của nhà lãnh đạo không có chi phí chung trong DAG, cơ chế này thiên về lựa chọn có lợi cho những nhà lãnh đạo nhanh.
thử thách
Trong ngữ cảnh của các giao thức DAG, đường ống dẫn và danh tiếng của nhà lãnh đạo được coi là những vấn đề khó khăn vì những lý do sau:
Những nỗ lực trước đây của đường ống để sửa đổi logic cốt lõi của Bullshark, nhưng điều này dường như là không thể
Danh tiếng của nhà lãnh đạo, được giới thiệu trong DiemBFT và được chính thức hóa trong Carousel, là ý tưởng lựa chọn động các nhà lãnh đạo trong tương lai (các mỏ neo trong Bullshark) dựa trên hiệu suất trước đây của các trình xác nhận. Mặc dù sự bất đồng về danh tính người lãnh đạo không vi phạm tính bảo mật trong các giao thức này, nhưng trong Bullshark, điều đó có thể dẫn đến một trật tự hoàn toàn khác, điều này dẫn đến trọng tâm của câu hỏi, đó là việc lựa chọn neo bánh xe năng động và xác định là chìa khóa để giải quyết sự đồng thuận cần thiết , trong khi những người xác thực cần thống nhất về lịch sử được sắp xếp để chọn các điểm neo trong tương lai.
Bằng chứng về độ khó của vấn đề, chúng tôi lưu ý rằng việc triển khai của Bullshark, bao gồm cả việc triển khai hiện tại trong sản xuất, không hỗ trợ các tính năng này.
hiệp định
Bất chấp những thách thức đã nói ở trên, hóa ra các giải pháp, như người ta vẫn nói, nằm đằng sau 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à triển khai khả năng lưu giữ và diễn giải lại thông tin từ các vòng trước. Với thông tin chi tiết cốt lõi rằng tất cả các trình xác thực đều đồng ý với neo được đặt hàng đầu tiên, Shoal sắp xếp chúng bằng cách kết hợp nhiều phiên bản Bullshark theo trình tự sao cho (1) neo được đặt hàng đầu tiên là điểm chuyển đổi cho các phiên bản và (2) Lịch sử nhân quả của neo được sử dụng để tính toán danh tiếng của nhà lãnh đạo.
Đường ống
Tương tự như Bullshark, những người xác thực đồng ý trước về các mỏ neo tiềm năng, tức là có một ánh xạ F: R -> V đã biết làm tròn các vòng ánh xạ tới người dẫn đầu. Shoal lần lượt chạy các phiên bản của Bullshark sao cho đối với mỗi phiên bản, mỏ neo được xác định trước bởi bản đồ F. Mỗi phiên bản đặt hàng một 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 chạy 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 mỏ neo được đặt hàng đầu tiên, chẳng hạn như ở vòng r. Tất cả các trình xác nhận đều đồng ý về mỏ neo này. Do đó, tất cả các trình xác thực có thể đồng ý một cách xác định để diễn giải lại DAG bắt đầu từ vòng r+1. Shoal chỉ bắt đầu một phiên bản mới của Bullshark ở vòng r+1.
Trong trường hợp tốt nhất, điều này cho phép Shoal đặt hàng một mỏ neo mỗi vòng. Các neo cho vòng đầu tiên được sắp xếp theo trường hợp đầu tiên. Sau đó, Shoal bắt đầu một phiên bản mới trong vòng thứ hai, bản thân phiên bản này có một mỏ neo được sắp xếp theo đối tượng, sau đó một phiên bản mới khác sắp xếp các mỏ neo trong vòng thứ ba và quá trình tiếp tục. Vui lòng xem hình minh họa dưới đây:
Hình 4: Các đỉnh tương ứng với các nhà lãnh đạo được xác định bởi F được đánh dấu bằng vương miện. Phiên bản đầu tiên của Bullshark lần đầu tiên diễn giải DAG với các điểm neo trong vòng 1, 3 và 5. Bullshark xác định các điểm neo trong vòng 1 (trong dấu kiểm màu xanh lục mark) là thứ đầu tiên được sắp xếp trong trường hợp đầu tiên. (Lưu ý rằng trong trường hợp chung, mỏ neo này có thể được bỏ qua, trong khi một số mỏ neo khác sẽ được sắp xếp trước.) Sau đó, phần còn lại của phiên bản đầu tiên bị bỏ qua và một phiên bản mới của Bullshark bắt đầu từ vòng 2, Điểm neo được đánh dấu ở vòng 2 và 4.
Danh tiếng nhà lãnh đạo
Tăng độ trễ khi bỏ qua các neo trong quá trình phân loại Bullshark. Trong trường hợp này, kỹ thuật Đường ống là bất lực vì một phiên bản mới không thể được bắt đầu cho đến khi phiên bản trước đó đã đặt hàng một mỏ neo. Shoal đảm bảo rằng người lãnh đạo thích hợp ít có khả năng được bầu chọn trong tương lai để giải quyết vấn đề neo bị mất bằng cách sử dụng cơ chế danh tiếng để chỉ định cho mỗi người xác thực một điểm số dựa trên lịch sử hoạt động gần đây của họ. Trình xác nhận phản hồi và tham gia vào giao thức sẽ được cho điểm cao, nếu không, trình xác nhận sẽ được chỉ định điểm thấp vì nó có thể bị sập, chậm hoặc độc hại.
Ý tưởng là tính toán lại một cách xác định ánh xạ F được xác định trước từ các vòng đến người dẫn đầu ở mỗi lần cập nhật điểm, ưu tiên người dẫn đầu có điểm cao hơn. Để những người xác thực đồng ý với ánh xạ mới, họ phải đồng ý về điểm số và do đó, lịch sử được sử dụng để tính điểm.
Ở Shoal, danh tiếng của đường ống và khả năng lãnh đạo có thể được kết hợp một cách tự nhiên vì cả hai đều sử dụng cùng một kỹ thuật cốt lõi là diễn giải lại DAG sau khi thống nhất về mỏ neo được đặt hàng đầ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, trình xác thực chỉ cần tính toán ánh xạ F' mới từ vòng r+1 dựa trên lịch sử nhân quả của các điểm neo được sắp xếp trong vòng r . Sau đó, trình xác thực thực thi một phiên bản mới của Bullshark bắt đầu từ vòng r+1 bằng cách sử dụng chức năng lựa chọn neo được cập nhật F'. Xem hình ảnh dưới đây:
Hình 5. Các đỉnh tương ứng với các nhà lãnh đạo được xác định bởi F được đánh dấu bằng vương miện trong suốt. Phiên bản đầu tiên của Bullshark đặt hàng một mỏ neo trong vòng 1, được đánh dấu bằng dấu kiểm màu lục, sau đó tính toán một ánh xạ F' mới dựa trên thông tin trong lịch sử nhân quả của mỏ neo. Các nhà lãnh đạo được xác định bởi F' được đánh dấu bằng vương miện màu.
Không còn thời gian chờ nữa
Hết thời gian chờ đóng một vai trò quan trọng trong tất cả các triển khai BFT đồng bộ một phần xác định dựa trên chỉ dẫn. Tuy nhiên, độ phức tạp mà chúng đưa vào làm tăng số lượng trạng thái bên trong cần được quản lý và quan sát, điều này làm phức tạp 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 có thể làm tăng đáng kể độ trễ, vì điều quan trọng là phải định cấu hình chúng một cách thích hợp và thường cần được điều chỉnh động vì thời gian chờ phụ thuộc nhiều vào môi trường (mạng). Giao thức trả cho người lãnh đạo bị lỗi toàn bộ hình phạt chậm trễ khi hết thời gian chờ trước khi chuyển sang người lãnh đạo tiếp theo. Do đó, cài đặt thời gian chờ không thể quá thận trọng, nhưng nếu thời gian chờ quá ngắn, giao thức có thể bỏ qua các nhà lãnh đạo tốt. Ví dụ: chúng tôi đã quan sát thấy rằng dưới tải trọng cao, các nhà lãnh đạo trong Jolteon/Hotstuff đã bị quá tải và hết thời gian chờ trước khi họ có thể đẩy tiến độ.
Thật không may, các giao thức dựa trên người lãnh đạo như Hotstuff và Jolteon vốn yêu cầu thời gian chờ để đảm bảo rằng giao thức có thể đạt được tiến bộ mỗi khi người lãnh đạo không thành công. Nếu không có thời gian chờ, ngay cả một nhà lãnh đạo bị lỗi cũng có thể tạm dừng giao thức mãi mãi. Do không thể phân biệt giữa một đường dẫn bị lỗi và một đường dẫn chậm trong quá trình không đồng bộ, thời gian chờ có thể khiến người xác thực thấy các thay đổi đối với tất cả các đường dẫn mà không có sự đồng thuận.
Trong Bullshark, thời gian chờ được sử dụng trong quá trình xây dựng DAG để đảm bảo rằng trong quá trình đồng bộ hóa, một nhà lãnh đạo trung thực sẽ thêm các neo vào DAG đủ nhanh để chúng được đặt hàng.
Chúng tôi nhận thấy rằng cấu trúc DAG cung cấp một "đồng hồ" để ước tính tốc độ của mạng. Trong trường hợp không có tạm dừng, các vòng tiếp tục diễn ra miễn là những người xác thực trung thực nf tiếp tục thêm các đỉnh vào DAG. Trong khi Bullshark có thể không sắp xếp được ở tốc độ mạng (do đường dẫn có vấn đề), DAG vẫn phát triển theo tốc độ mạng mặc dù một số đường dẫn gặp sự cố hoặc mạng không đồng bộ. Cuối cùng, khi một nhà lãnh đạo không có lỗi phát sóng các mỏ neo đủ nhanh, toàn bộ lịch sử nhân quả của các mỏ neo sẽ được sắp xếp.
Trong đánh giá của mình, chúng tôi đã so sánh Bullshark có và không có thời gian chờ trong các trường hợp sau:
Dẫn đầu nhanh, nghĩa là ít nhất nhanh hơn các trình xác thực khác. Trong trường hợp này, cả hai phương pháp đều cung cấp độ trễ như nhau vì các điểm neo được sắp xếp theo thứ tự và thời gian chờ không được sử dụng.
Người dẫn đầu sai, trong trường hợp này, Bullshark không tạm dừng cung cấp độ trễ tốt hơn vì người xác nhận sẽ ngay lập tức bỏ qua các neo của nó, trong khi người xác thực có tạm dừng sẽ đợi họ đến trước khi tiếp tục Mong đợi.
Người dẫn đầu chậm chạp, đây là trường hợp duy nhất Bullshark có hiệu suất thời gian chờ tốt hơn. Điều này là do, nếu không tạm dừng, phần neo có thể bị bỏ qua vì phần dẫn đầu không thể phát đủ nhanh, trong khi khi tạm dừng, trình xác nhận sẽ đợi phần neo.
Tại Shoal, việc tránh hết thời gian chờ và danh tiếng lãnh đạo luôn đi đôi với nhau. Việc chờ đợi liên tục một người dẫn đầu chậm sẽ làm tăng độ trễ và cơ chế danh tiếng của người dẫn đầu ngăn cản những người xác thực chậm được bầu làm người dẫn đầu. Bằng cách này, hệ thống sử dụng các nút xác thực nhanh để chạy ở tốc độ mạng trong tất cả các tình huống trong thế giới thực.
Lưu ý rằng kết quả không thể thực hiện được của FLP cho thấy rằng không có giao thức đồng thuận xác định nào có thể tránh được thời gian chờ. Shoal không thể phá vỡ kết quả này bởi vì tồn tại một lịch trình lý thuyết về các sự kiện đối nghịch sẽ ngăn cản tất cả các mỏ neo được chỉ huy. Thay vào đó, Shoal rơi trở lại thời gian chờ sau một số lần bỏ qua neo liên tiếp có thể định cấu hình. Trong thực tế, điều này cực kỳ khó xảy ra.
Phản hồi chung
Bài viết của Hotstuff đã phổ biến khái niệm phản hồi lạc quan, mặc dù không được định nghĩa chính thức, nhưng trực giác có nghĩa là giao thức có thể chạy ở tốc độ mạng trong các điều kiện tốt bao gồm đường dẫn nhanh và mạng đồng bộ.
Shoal cung cấp một thuộc tính thậm chí còn tốt hơn, mà chúng tôi gọi là Phản hồi toàn cầu. Cụ thể, trái ngược với Hotstuff, Shoal tiếp tục chạy ở tốc độ mạng ngay cả khi đầu dẫn không thành công trong một số vòng liên tiếp có thể định cấu hình hoặc các chu kỳ không đồng bộ mà mạng đi qua. Xem một so sánh chi tiết hơn trong bảng dưới đây.
Lưu ý rằng khả năng đáp ứng phổ quát cung cấp các đảm bảo tiến độ tốt hơn trong các giai đoạn không đồng bộ và khi người dẫn đầu thất bại. Trong quá trình đồng bộ hóa với đường dẫn chậm, các thuộc tính này không thể so sánh được vì nó phụ thuộc vào mức độ chậm của đường dẫn. Tuy nhiên, với danh tiếng của nhà lãnh đạo, những nhà lãnh đạo chậm chạp hiếm khi xuất hiện ở Shoal.
Đánh giá
Chúng tôi đã triển khai Bullshark và Shoal trên Cửa hàng đại biểu triển khai Narwhal của chúng tôi. Bạn có thể tìm thấy so sánh chi tiết giữa Shoal, Bullshark và Jolteon trong phần đánh giá của bài viết về Shoal, nơi chúng tôi cung cấp một số điểm nổi bật.
Đầu tiên, để chứng minh sức mạnh của việc xây dựng DAG không đồng bộ, chúng tôi so sánh Bullshark có và không có tạm dừng. Bài viết đầy đủ của Bullshark giả định một mạng không đồng bộ, nhưng cung cấp chế độ đường dẫn nhanh, do đó yêu cầu tạm dừng trong tất cả các vòng. Chúng tôi gọi phiên bản này là Vanilla Bullshark. Chúng tôi quan sát thấy rằng đối với các phiên bản giả thuyết mạng đồng bộ một phần độc lập, không cần tạm dừng trong các vòng bỏ phiếu. Chúng tôi gọi phiên bản này là Vanilla Bullshark khi hết thời gian bỏ phiếu mà không hết thời gian bỏ phiếu, Baseline Bullshark là phiên bản không có thời gian chờ.
Biểu đồ bên dưới so sánh tác động của thời gian chờ đối với độ trễ của Bullshark khi có và không có lỗi. Rõ ràng, Baseline Bullshark (không có thời gian chờ) hoạt động tốt nhất trong trường hợp xảy ra lỗi. Không có sai sót nào, Baseline Bullshark có thể so sánh với Vanilla Bullshark mà không bị đình chỉ bỏ phiếu. Điều này là do, như đã đề cập trước đó, nếu không có cơ chế danh tiếng của người lãnh đạo, thời gian chờ có thể có lợi hơn trong các tình huống mà người lãnh đạo giỏi nhưng chậm chạp.
Hình 6.: Tác động của thời gian chờ đối với độ trễ Bullshark khi không có lỗi (trái) và có lỗi (phải), với 50 trình xác nhận trong trường hợp lỗi
Tiếp theo, chúng tôi khởi tạo Shoal bằng cách sử dụng Baseline Bullshark (không có thời gian chờ) và chứng minh những cải tiến về độ trễ của đường ống và cơ chế danh tiếng của người dẫn đầu khi có và không có lỗi, đồng thời, để hoàn thiện, chúng tôi cũng so sánh nó với Jolteon có và không có lỗi.
Hình 7 bên dưới cho thấy trường hợp không có lỗi và trong khi cả danh tiếng của người dẫn đầu và hệ thống đường ống đều có thể giảm độ trễ riêng lẻ, việc kết hợp chúng sẽ mang lại độ trễ tốt nhất.
Đối với Jolteon, nó không thể mở rộng tới hơn 20 trình xác thực và ngay cả khi nó chạy trên Quorum Store, nó chỉ có thể đạt được khoảng một nửa thông lượng của Bullshark/Shoal, giúp loại bỏ nút cổ chai truyền dữ liệu.
Kết quả cho thấy Shoal cải thiện đáng kể độ trễ của Bullshark. Đối với Jolteon, điều quan trọng cần lưu ý là mặc dù chúng tôi chỉ đo độ trễ đồng thuận. Vì Jolteon không thể chạy tự nhiên trên DAG nên nó yêu cầu độ trễ bổ sung để tách riêng quá trình truyền dữ liệu mà chúng tôi không đo lường được. Do đó, dưới tải cao, Shoal phải phù hợp với độ trễ từ đầu đến cuối của Jolteon.
Hình 7: Thông lượng và độ trễ không có lỗi, Shoal PL và Shaol LR chỉ hỗ trợ đường ống và danh tiếng của nhà lãnh đạo tương ứng.
Hình 8 bên dưới cho thấy một trường hợp thất bại với 50 người xác thực, trong đó cơ chế danh tiếng của người dẫn đầu cải thiện đáng kể độ trễ bằng cách giảm xác suất một người xác thực không thành công được bầu làm người dẫn đầu. Lưu ý rằng với 16 lỗi trong số 50 lỗi, độ trễ của Shoal thấp hơn 65% so với Baseline Bullshark.
Xem bản gốc
This page may contain third-party content, which is provided for information purposes only (not representations/warranties) and should not be considered as an endorsement of its views by Gate, nor as financial or professional advice. See Disclaimer for details.
Giải thích về khung 4D Shoal: Cách giảm độ trễ Bullshark trên Aptos?
Bản gốc: Phòng thí nghiệm Aptos
Biên soạn: Aptos Global
Tổng quan
Các phòng thí nghiệm của Aptos đã giải quyết được hai vấn đề mở quan trọng trong DAG BFT, giúp giảm đáng kể độ trễ và lần đầu tiên loại bỏ nhu cầu tạm dừng trong các giao thức thực tế xác định. Nhìn chung, điều này giúp cải thiện độ trễ của Bullshark lên 40% trong trường hợp không có lỗi và 80% trong trường hợp có lỗi.
Shoal là một khuôn khổ nâng cao bất kỳ giao thức đồng thuận dựa trên Kỳ lân biển nào (ví dụ: DAG-Rider, Tusk, Bullshark) thông qua đường ống dẫn và danh tiếng của nhà lãnh đạo. Hệ thống đường ống giảm độ trễ đặt hàng DAG bằng cách giới thiệu một điểm cố định cho mỗi vòng và danh tiếng của người dẫn đầu sẽ cải thiện độ trễ hơn nữa bằng cách đảm bảo rằng các điểm cố định được liên kết với trình xác thực nhanh nhất. Ngoài ra, danh tiếng của nhà lãnh đạo cho phép Shoal tận dụng cấu trúc DAG không đồng bộ để loại bỏ thời gian chờ trong mọi tình huống. Điều này cho phép Shoal cung cấp một thuộc tính mà chúng tôi đặt tên là Phản hồi toàn cầu, chứa Phản hồi lạc quan thường được yêu cầu.
Kỹ thuật của chúng tôi rất đơn giản, nó liên quan đến việc chạy tuần tự nhiều phiên bản của giao thức cơ bản. Vì vậy, khi khởi tạo với Bullshark, chúng ta có một nhóm "cá mập" đang chạy tiếp sức.
Động lực
Để theo đuổi hiệu suất cao trong các mạng chuỗi khối, đã có sự tập trung liên tục vào việc giảm độ phức tạp của giao tiếp. Tuy nhiên, cách tiếp cận này không dẫn đến sự gia tăng đáng kể về thông lượng. Ví dụ: việc triển khai Hotstuff trong phiên bản đầu tiên của Diem chỉ đạt được 3500 TPS, thấp hơn nhiều so với mục tiêu của chúng tôi là đạt được 100k+ TPS.
Tuy nhiên, những đột phá gần đây bắt nguồn từ việc nhận ra rằng việc truyền dữ liệu là nút cổ chai chính của các giao thức dựa trên người dẫn đầu và nó có thể được hưởng lợi từ việc song song hóa. Hệ thống Narwhal tách việc truyền dữ liệu khỏi logic đồng thuận cốt lõi và đề xuất một kiến trúc trong đó tất cả các trình xác thực truyền dữ liệu đồng thời, trong khi các thành phần đồng thuận chỉ yêu cầu một lượng siêu dữ liệu nhỏ hơn. Bài viết về Kỳ lân biển báo cáo thông lượng là 160.000 TPS.
Trong một bài viết trước, chúng tôi đã giới thiệu Quorum Store. Việc triển khai Narwhal của chúng tôi tách riêng việc truyền bá dữ liệu khỏi sự đồng thuận và cách chúng tôi sử dụng điều này để mở rộng giao thức đồng thuận hiện tại của chúng tôi, Jolteon. Jolteon là một giao thức dựa trên nhà lãnh đạo kết hợp đường dẫn nhanh tuyến tính của Tendermint với các thay đổi chế độ xem kiểu PBFT để giảm 33% độ trễ của Hotstuff. Tuy nhiên, rõ ràng là một giao thức đồng thuận dựa trên nhà lãnh đạo không thể khai thác hết tiềm năng thông lượng của Kỳ lân biển. Mặc dù tách biệt việc truyền dữ liệu khỏi sự đồng thuận, các nhà lãnh đạo của Hotstuff/Jolteon vẫn bị hạn chế khi thông lượng tăng lên.
Do đó, chúng tôi đã quyết định triển khai Bullshark, một giao thức đồng thuận với chi phí liên lạc bằng không, trên Narwhal DAG. Thật không may, cấu trúc DAG hỗ trợ thông lượng cao của Bullshark đi kèm với hình phạt về độ trễ 50% so với Jolteon.
Trong bài đăng này, chúng tôi mô tả cách Shoal giảm đáng kể độ trễ của Bullshark.
Nền DAG-BFT
Hãy bắt đầu bằng cách tìm hiểu nền tảng liên quan của bài viết này. Để biết mô tả chi tiết về Kỳ lân biển và Cá mập bò, vui lòng tham khảo bài đăng DAG gặp BFT.
Mỗi đỉnh trong DAG kỳ lân biển được liên kết với một số tròn. Để vào vòng r, trước tiên người xác minh phải có được nf đỉnh thuộc vòng r-1. Mỗi trình xác minh có thể phát một đỉnh trong mỗi vòng và mỗi đỉnh tham chiếu đến ít nhất nf đỉnh trong vòng trước đó. Do mạng không đồng bộ, các trình xác thực khác nhau có thể quan sát các chế độ xem cục bộ khác nhau của DAG tại bất kỳ thời điểm nào. Dưới đây là một minh họa về một chế độ xem một phần có thể:
Hình 1: Lịch sử nhân quả của các đỉnh được xác định bởi nút xác thực vòng 2 2 được đánh dấu bằng màu xanh lục
Một thuộc tính quan trọng của DAG không phải là sự mơ hồ: hai trình xác thực có lịch sử nhân quả giống hệt nhau của v nếu chúng có cùng một đỉnh v trong chế độ xem cục bộ của chúng về DAG.
Tổng đơn hàng
Có thể đồng ý về tổng thứ tự của tất cả các đỉnh trong DAG mà không cần thêm chi phí liên lạc. Để đạt được mục tiêu này, các trình xác thực trong DAG-Rider, Tusk và Bullshark diễn giải 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 điểm nhóm khác nhau về cấu trúc DAG, nhưng tất cả các giao thức đồng thuận dựa trên Kỳ lân biển hiện có đều có cấu trúc sau:
Các mỏ neo được xác định trước, cứ sau vài vòng sẽ có một người dẫn đầu được xác định trước (ví dụ: hai vòng trong Bullshark) và các đỉnh của người dẫn đầu được gọi là mỏ neo;
Đặt hàng các neo, người xác minh quyết định một cách độc lập nhưng dứt khoát nên đặt các neo nào và bỏ qua các neo nào;
Sắp xếp lịch sử nhân quả, trong đó trình xác thực xử lý từng danh sách neo được sắp xếp theo thứ tự của họ và đối với mỗi neo, sắp xếp tất cả các đỉnh không có thứ tự trước đó trong lịch sử nhân quả của nó theo một số quy tắc xác định.
Hình 2: Minh họa về chế độ xem một phần có thể có của DAG trong giao thức Bullshark. Trong ví dụ này, các neo màu đỏ và màu vàng được sắp xếp, trong khi màu xanh lá cây (không có trong DAG) bị bỏ qua. Do đó, để đặt hàng DAG, trình xác thực sẽ sắp xếp thứ tự lịch sử nhân quả của các neo màu đỏ trước, sau đó là các neo màu vàng.
Chìa khóa để đáp ứng tính bảo mật là đảm bảo rằng ở bước (2) ở trên, tất cả các trình xác thực trung thực đều tạo một danh sách các điểm neo được sắp xếp theo thứ tự sao cho tất cả các danh sách đều có chung một tiền tố. Tại Shoal, chúng tôi thực hiện các quan sát sau đối với tất cả các giao thức trên:
** Tất cả những người xác thực đều đồng ý về mỏ neo được đặt hàng đầu tiên. **
Độ trễ của Bullshark
Độ trễ của Bullshark phụ thuộc vào số vòng giữa các neo được sắp xếp theo thứ tự trong DAG. Mặc dù phiên bản đồng bộ một phần hữu ích nhất của Bullshark có độ trễ tốt hơn phiên bản không đồng bộ, nhưng nó không phải là tối ưu.
Vấn đề 1: Độ trễ khối trung bình. Trong Bullshark, mỗi vòng chẵn đều có một mỏ neo và các đỉnh của mỗi vòng lẻ được hiểu là phiếu bầu. Thông thường, phải mất hai vòng DAG để đặt hàng các mỏ neo, tuy nhiên, các đỉnh trong lịch sử nhân quả của một mỏ neo sẽ mất nhiều vòng hơn để chờ một mỏ neo được đặt hàng. Trong trường hợp phổ biến, các đỉnh trong các vòng lẻ yêu cầu ba vòng, trong khi các đỉnh không neo trong các vòng chẵn yêu cầu bốn vòng (xem Hình 3).
Hình 3: Trong trường hợp phổ biến, các neo ở vòng i+1 cần được sắp xếp cho hai vòng. Các đỉnh trong vòng i được sắp xếp đồng thời nên độ trễ của chúng là ba vòng. Tuy nhiên, các đỉnh trong vòng i+1 phải đợi neo tiếp theo được sắp xếp (đỉnh trong vòng i+3), vì vậy độ trễ sắp xếp của chúng là bốn vòng.
Vấn đề 2: Độ trễ của trường hợp lỗi, phân tích độ trễ ở trên áp dụng cho trường hợp không lỗi, mặt khác, nếu người dẫn đầu vòng không phát các neo đủ nhanh, các neo không thể được đặt hàng (và do đó bị bỏ qua), vì vậy Tất cả các đỉnh chưa được sắp xếp trong các vòng trước phải đợi neo tiếp theo được sắp xếp. Điều này có thể làm giảm đáng kể hiệu suất của mạng được sao chép địa lý, đặc biệt là khi Bullshark sử dụng thời gian chờ chờ người dẫn đầu.
Khuôn khổ Shoal
Shoal giải quyết cả hai vấn đề về độ trễ này bằng cách tăng cường Bullshark (hoặc bất kỳ giao thức BFT dựa trên Kỳ lân biển nào khác) bằng cách tạo đường ống, cho phép neo trong mỗi vòng và giảm độ trễ của tất cả các đỉnh không phải neo trong DAG xuống còn ba vòng. Shoal cũng giới thiệu một cơ chế danh tiếng của nhà lãnh đạo không có chi phí chung trong DAG, cơ chế này thiên về lựa chọn có lợi cho những nhà lãnh đạo nhanh.
thử thách
Trong ngữ cảnh của các giao thức DAG, đường ống dẫn và danh tiếng của nhà lãnh đạo được coi là những vấn đề khó khăn vì những lý do sau:
Những nỗ lực trước đây của đường ống để sửa đổi logic cốt lõi của Bullshark, nhưng điều này dường như là không thể
Danh tiếng của nhà lãnh đạo, được giới thiệu trong DiemBFT và được chính thức hóa trong Carousel, là ý tưởng lựa chọn động các nhà lãnh đạo trong tương lai (các mỏ neo trong Bullshark) dựa trên hiệu suất trước đây của các trình xác nhận. Mặc dù sự bất đồng về danh tính người lãnh đạo không vi phạm tính bảo mật trong các giao thức này, nhưng trong Bullshark, điều đó có thể dẫn đến một trật tự hoàn toàn khác, điều này dẫn đến trọng tâm của câu hỏi, đó là việc lựa chọn neo bánh xe năng động và xác định là chìa khóa để giải quyết sự đồng thuận cần thiết , trong khi những người xác thực cần thống nhất về lịch sử được sắp xếp để chọn các điểm neo trong tương lai.
Bằng chứng về độ khó của vấn đề, chúng tôi lưu ý rằng việc triển khai của Bullshark, bao gồm cả việc triển khai hiện tại trong sản xuất, không hỗ trợ các tính năng này.
hiệp định
Bất chấp những thách thức đã nói ở trên, hóa ra các giải pháp, như người ta vẫn nói, nằm đằng sau 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à triển khai khả năng lưu giữ và diễn giải lại thông tin từ các vòng trước. Với thông tin chi tiết cốt lõi rằng tất cả các trình xác thực đều đồng ý với neo được đặt hàng đầu tiên, Shoal sắp xếp chúng bằng cách kết hợp nhiều phiên bản Bullshark theo trình tự sao cho (1) neo được đặt hàng đầu tiên là điểm chuyển đổi cho các phiên bản và (2) Lịch sử nhân quả của neo được sử dụng để tính toán danh tiếng của nhà lãnh đạo.
Đường ống
Tương tự như Bullshark, những người xác thực đồng ý trước về các mỏ neo tiềm năng, tức là có một ánh xạ F: R -> V đã biết làm tròn các vòng ánh xạ tới người dẫn đầu. Shoal lần lượt chạy các phiên bản của Bullshark sao cho đối với mỗi phiên bản, mỏ neo được xác định trước bởi bản đồ F. Mỗi phiên bản đặt hàng một 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 chạy 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 mỏ neo được đặt hàng đầu tiên, chẳng hạn như ở vòng r. Tất cả các trình xác nhận đều đồng ý về mỏ neo này. Do đó, tất cả các trình xác thực có thể đồng ý một cách xác định để diễn giải lại DAG bắt đầu từ vòng r+1. Shoal chỉ bắt đầu một phiên bản mới của Bullshark ở vòng r+1.
Trong trường hợp tốt nhất, điều này cho phép Shoal đặt hàng một mỏ neo mỗi vòng. Các neo cho vòng đầu tiên được sắp xếp theo trường hợp đầu tiên. Sau đó, Shoal bắt đầu một phiên bản mới trong vòng thứ hai, bản thân phiên bản này có một mỏ neo được sắp xếp theo đối tượng, sau đó một phiên bản mới khác sắp xếp các mỏ neo trong vòng thứ ba và quá trình tiếp tục. Vui lòng xem hình minh họa dưới đây:
Hình 4: Các đỉnh tương ứng với các nhà lãnh đạo được xác định bởi F được đánh dấu bằng vương miện. Phiên bản đầu tiên của Bullshark lần đầu tiên diễn giải DAG với các điểm neo trong vòng 1, 3 và 5. Bullshark xác định các điểm neo trong vòng 1 (trong dấu kiểm màu xanh lục mark) là thứ đầu tiên được sắp xếp trong trường hợp đầu tiên. (Lưu ý rằng trong trường hợp chung, mỏ neo này có thể được bỏ qua, trong khi một số mỏ neo khác sẽ được sắp xếp trước.) Sau đó, phần còn lại của phiên bản đầu tiên bị bỏ qua và một phiên bản mới của Bullshark bắt đầu từ vòng 2, Điểm neo được đánh dấu ở vòng 2 và 4.
Danh tiếng nhà lãnh đạo
Tăng độ trễ khi bỏ qua các neo trong quá trình phân loại Bullshark. Trong trường hợp này, kỹ thuật Đường ống là bất lực vì một phiên bản mới không thể được bắt đầu cho đến khi phiên bản trước đó đã đặt hàng một mỏ neo. Shoal đảm bảo rằng người lãnh đạo thích hợp ít có khả năng được bầu chọn trong tương lai để giải quyết vấn đề neo bị mất bằng cách sử dụng cơ chế danh tiếng để chỉ định cho mỗi người xác thực một điểm số dựa trên lịch sử hoạt động gần đây của họ. Trình xác nhận phản hồi và tham gia vào giao thức sẽ được cho điểm cao, nếu không, trình xác nhận sẽ được chỉ định điểm thấp vì nó có thể bị sập, chậm hoặc độc hại.
Ý tưởng là tính toán lại một cách xác định ánh xạ F được xác định trước từ các vòng đến người dẫn đầu ở mỗi lần cập nhật điểm, ưu tiên người dẫn đầu có điểm cao hơn. Để những người xác thực đồng ý với ánh xạ mới, họ phải đồng ý về điểm số và do đó, lịch sử được sử dụng để tính điểm.
Ở Shoal, danh tiếng của đường ống và khả năng lãnh đạo có thể được kết hợp một cách tự nhiên vì cả hai đều sử dụng cùng một kỹ thuật cốt lõi là diễn giải lại DAG sau khi thống nhất về mỏ neo được đặt hàng đầ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, trình xác thực chỉ cần tính toán ánh xạ F' mới từ vòng r+1 dựa trên lịch sử nhân quả của các điểm neo được sắp xếp trong vòng r . Sau đó, trình xác thực thực thi một phiên bản mới của Bullshark bắt đầu từ vòng r+1 bằng cách sử dụng chức năng lựa chọn neo được cập nhật F'. Xem hình ảnh dưới đây:
Hình 5. Các đỉnh tương ứng với các nhà lãnh đạo được xác định bởi F được đánh dấu bằng vương miện trong suốt. Phiên bản đầu tiên của Bullshark đặt hàng một mỏ neo trong vòng 1, được đánh dấu bằng dấu kiểm màu lục, sau đó tính toán một ánh xạ F' mới dựa trên thông tin trong lịch sử nhân quả của mỏ neo. Các nhà lãnh đạo được xác định bởi F' được đánh dấu bằng vương miện màu.
Không còn thời gian chờ nữa
Hết thời gian chờ đóng một vai trò quan trọng trong tất cả các triển khai BFT đồng bộ một phần xác định dựa trên chỉ dẫn. Tuy nhiên, độ phức tạp mà chúng đưa vào làm tăng số lượng trạng thái bên trong cần được quản lý và quan sát, điều này làm phức tạp 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 có thể làm tăng đáng kể độ trễ, vì điều quan trọng là phải định cấu hình chúng một cách thích hợp và thường cần được điều chỉnh động vì thời gian chờ phụ thuộc nhiều vào môi trường (mạng). Giao thức trả cho người lãnh đạo bị lỗi toàn bộ hình phạt chậm trễ khi hết thời gian chờ trước khi chuyển sang người lãnh đạo tiếp theo. Do đó, cài đặt thời gian chờ không thể quá thận trọng, nhưng nếu thời gian chờ quá ngắn, giao thức có thể bỏ qua các nhà lãnh đạo tốt. Ví dụ: chúng tôi đã quan sát thấy rằng dưới tải trọng cao, các nhà lãnh đạo trong Jolteon/Hotstuff đã bị quá tải và hết thời gian chờ trước khi họ có thể đẩy tiến độ.
Thật không may, các giao thức dựa trên người lãnh đạo như Hotstuff và Jolteon vốn yêu cầu thời gian chờ để đảm bảo rằng giao thức có thể đạt được tiến bộ mỗi khi người lãnh đạo không thành công. Nếu không có thời gian chờ, ngay cả một nhà lãnh đạo bị lỗi cũng có thể tạm dừng giao thức mãi mãi. Do không thể phân biệt giữa một đường dẫn bị lỗi và một đường dẫn chậm trong quá trình không đồng bộ, thời gian chờ có thể khiến người xác thực thấy các thay đổi đối với tất cả các đường dẫn mà không có sự đồng thuận.
Trong Bullshark, thời gian chờ được sử dụng trong quá trình xây dựng DAG để đảm bảo rằng trong quá trình đồng bộ hóa, một nhà lãnh đạo trung thực sẽ thêm các neo vào DAG đủ nhanh để chúng được đặt hàng.
Chúng tôi nhận thấy rằng cấu trúc DAG cung cấp một "đồng hồ" để ước tính tốc độ của mạng. Trong trường hợp không có tạm dừng, các vòng tiếp tục diễn ra miễn là những người xác thực trung thực nf tiếp tục thêm các đỉnh vào DAG. Trong khi Bullshark có thể không sắp xếp được ở tốc độ mạng (do đường dẫn có vấn đề), DAG vẫn phát triển theo tốc độ mạng mặc dù một số đường dẫn gặp sự cố hoặc mạng không đồng bộ. Cuối cùng, khi một nhà lãnh đạo không có lỗi phát sóng các mỏ neo đủ nhanh, toàn bộ lịch sử nhân quả của các mỏ neo sẽ được sắp xếp.
Trong đánh giá của mình, chúng tôi đã so sánh Bullshark có và không có thời gian chờ trong các trường hợp sau:
Dẫn đầu nhanh, nghĩa là ít nhất nhanh hơn các trình xác thực khác. Trong trường hợp này, cả hai phương pháp đều cung cấp độ trễ như nhau vì các điểm neo được sắp xếp theo thứ tự và thời gian chờ không được sử dụng.
Người dẫn đầu sai, trong trường hợp này, Bullshark không tạm dừng cung cấp độ trễ tốt hơn vì người xác nhận sẽ ngay lập tức bỏ qua các neo của nó, trong khi người xác thực có tạm dừng sẽ đợi họ đến trước khi tiếp tục Mong đợi.
Người dẫn đầu chậm chạp, đây là trường hợp duy nhất Bullshark có hiệu suất thời gian chờ tốt hơn. Điều này là do, nếu không tạm dừng, phần neo có thể bị bỏ qua vì phần dẫn đầu không thể phát đủ nhanh, trong khi khi tạm dừng, trình xác nhận sẽ đợi phần neo.
Tại Shoal, việc tránh hết thời gian chờ và danh tiếng lãnh đạo luôn đi đôi với nhau. Việc chờ đợi liên tục một người dẫn đầu chậm sẽ làm tăng độ trễ và cơ chế danh tiếng của người dẫn đầu ngăn cản những người xác thực chậm được bầu làm người dẫn đầu. Bằng cách này, hệ thống sử dụng các nút xác thực nhanh để chạy ở tốc độ mạng trong tất cả các tình huống trong thế giới thực.
Lưu ý rằng kết quả không thể thực hiện được của FLP cho thấy rằng không có giao thức đồng thuận xác định nào có thể tránh được thời gian chờ. Shoal không thể phá vỡ kết quả này bởi vì tồn tại một lịch trình lý thuyết về các sự kiện đối nghịch sẽ ngăn cản tất cả các mỏ neo được chỉ huy. Thay vào đó, Shoal rơi trở lại thời gian chờ sau một số lần bỏ qua neo liên tiếp có thể định cấu hình. Trong thực tế, điều này cực kỳ khó xảy ra.
Phản hồi chung
Bài viết của Hotstuff đã phổ biến khái niệm phản hồi lạc quan, mặc dù không được định nghĩa chính thức, nhưng trực giác có nghĩa là giao thức có thể chạy ở tốc độ mạng trong các điều kiện tốt bao gồm đường dẫn nhanh và mạng đồng bộ.
Shoal cung cấp một thuộc tính thậm chí còn tốt hơn, mà chúng tôi gọi là Phản hồi toàn cầu. Cụ thể, trái ngược với Hotstuff, Shoal tiếp tục chạy ở tốc độ mạng ngay cả khi đầu dẫn không thành công trong một số vòng liên tiếp có thể định cấu hình hoặc các chu kỳ không đồng bộ mà mạng đi qua. Xem một so sánh chi tiết hơn trong bảng dưới đây.
Lưu ý rằng khả năng đáp ứng phổ quát cung cấp các đảm bảo tiến độ tốt hơn trong các giai đoạn không đồng bộ và khi người dẫn đầu thất bại. Trong quá trình đồng bộ hóa với đường dẫn chậm, các thuộc tính này không thể so sánh được vì nó phụ thuộc vào mức độ chậm của đường dẫn. Tuy nhiên, với danh tiếng của nhà lãnh đạo, những nhà lãnh đạo chậm chạp hiếm khi xuất hiện ở Shoal.
Đánh giá
Chúng tôi đã triển khai Bullshark và Shoal trên Cửa hàng đại biểu triển khai Narwhal của chúng tôi. Bạn có thể tìm thấy so sánh chi tiết giữa Shoal, Bullshark và Jolteon trong phần đánh giá của bài viết về Shoal, nơi chúng tôi cung cấp một số điểm nổi bật.
Đầu tiên, để chứng minh sức mạnh của việc xây dựng DAG không đồng bộ, chúng tôi so sánh Bullshark có và không có tạm dừng. Bài viết đầy đủ của Bullshark giả định một mạng không đồng bộ, nhưng cung cấp chế độ đường dẫn nhanh, do đó yêu cầu tạm dừng trong tất cả các vòng. Chúng tôi gọi phiên bản này là Vanilla Bullshark. Chúng tôi quan sát thấy rằng đối với các phiên bản giả thuyết mạng đồng bộ một phần độc lập, không cần tạm dừng trong các vòng bỏ phiếu. Chúng tôi gọi phiên bản này là Vanilla Bullshark khi hết thời gian bỏ phiếu mà không hết thời gian bỏ phiếu, Baseline Bullshark là phiên bản không có thời gian chờ.
Biểu đồ bên dưới so sánh tác động của thời gian chờ đối với độ trễ của Bullshark khi có và không có lỗi. Rõ ràng, Baseline Bullshark (không có thời gian chờ) hoạt động tốt nhất trong trường hợp xảy ra lỗi. Không có sai sót nào, Baseline Bullshark có thể so sánh với Vanilla Bullshark mà không bị đình chỉ bỏ phiếu. Điều này là do, như đã đề cập trước đó, nếu không có cơ chế danh tiếng của người lãnh đạo, thời gian chờ có thể có lợi hơn trong các tình huống mà người lãnh đạo giỏi nhưng chậm chạp.
Hình 6.: Tác động của thời gian chờ đối với độ trễ Bullshark khi không có lỗi (trái) và có lỗi (phải), với 50 trình xác nhận trong trường hợp lỗi
Tiếp theo, chúng tôi khởi tạo Shoal bằng cách sử dụng Baseline Bullshark (không có thời gian chờ) và chứng minh những cải tiến về độ trễ của đường ống và cơ chế danh tiếng của người dẫn đầu khi có và không có lỗi, đồng thời, để hoàn thiện, chúng tôi cũng so sánh nó với Jolteon có và không có lỗi.
Hình 7 bên dưới cho thấy trường hợp không có lỗi và trong khi cả danh tiếng của người dẫn đầu và hệ thống đường ống đều có thể giảm độ trễ riêng lẻ, việc kết hợp chúng sẽ mang lại độ trễ tốt nhất.
Đối với Jolteon, nó không thể mở rộng tới hơn 20 trình xác thực và ngay cả khi nó chạy trên Quorum Store, nó chỉ có thể đạt được khoảng một nửa thông lượng của Bullshark/Shoal, giúp loại bỏ nút cổ chai truyền dữ liệu.
Kết quả cho thấy Shoal cải thiện đáng kể độ trễ của Bullshark. Đối với Jolteon, điều quan trọng cần lưu ý là mặc dù chúng tôi chỉ đo độ trễ đồng thuận. Vì Jolteon không thể chạy tự nhiên trên DAG nên nó yêu cầu độ trễ bổ sung để tách riêng quá trình truyền dữ liệu mà chúng tôi không đo lường được. Do đó, dưới tải cao, Shoal phải phù hợp với độ trễ từ đầu đến cuối của Jolteon.
Hình 7: Thông lượng và độ trễ không có lỗi, Shoal PL và Shaol LR chỉ hỗ trợ đường ống và danh tiếng của nhà lãnh đạo tương ứng.
Hình 8 bên dưới cho thấy một trường hợp thất bại với 50 người xác thực, trong đó cơ chế danh tiếng của người dẫn đầu cải thiện đáng kể độ trễ bằng cách giảm xác suất một người xác thực không thành công được bầu làm người dẫn đầu. Lưu ý rằng với 16 lỗi trong số 50 lỗi, độ trễ của Shoal thấp hơn 65% so với Baseline Bullshark.