Khung Shoal: Cách thả độ trễ Bullshark của Aptos

Aptos Labs đã giải quyết hai vấn đề mở quan trọng trong DAG BFT, Thả đáng kể độ trễ và lần đầu tiên loại bỏ nhu cầu về thời gian chờ trong giao thức thực tế 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 là 80%.

Shoal là một khung, tăng cường bất kỳ giao thức đồng thuận nào dựa trên Narwhal ( như DAG-Rider, Tusk, Bullshark ) thông qua xử lý theo luồng và cơ chế uy tín của người lãnh đạo. Xử lý theo luồng giảm độ trễ sắp xếp DAG bằng cách giới thiệu một điểm neo trong mỗi vòng, trong khi 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 rằng điểm neo được liên kết với các nút xác nhận 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 cấu trúc DAG không đồng bộ để loại bỏ mọi tình huống về thời gian chờ. Điều này giúp Shoal cung cấp thuộc tính mà chúng tôi gọi là phản hồi phổ quát, nó chứa đựng những phản hồi lạc quan thường cần thiết.

Công nghệ của chúng tôi rất đơn giản, nó liên quan đến việc chạy nhiều phiên bản của giao thức cơ sở theo thứ tự từng cái một. Do đó, khi được khởi tạo với Bullshark, chúng tôi có một nhóm "cá mập" đang tham gia một cuộc tiếp sức.

Động cơ

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 của giao tiếp. Tuy nhiên, phương pháp này không dẫn đến sự cải thiện đáng kể về thông lượng. Ví dụ, Hotstuff được triển khai trong 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 100000+ TPS của chúng tôi.

Nhưng những độ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 của giao thức lãnh đạo và có thể được hưởng lợi từ việc song song hóa. Hệ thống Narwhal tách biệt việc truyền dữ liệu với logic đồng thuận cốt lõi, đề 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ỉ đặt hàng một lượng nhỏ siêu dữ liệu. Bài báo Narwhal báo cáo công suất 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 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 lãnh đạo, kết hợp con đường nhanh tuyến tính của Tendermint và sự thay đổi tầm nhìn theo phong cách PBFT, có thể giảm Trễ của Hotstuff xuống 33%. Tuy nhiên, rõ ràng là các giao thức đồng thuận dựa trên 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 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, đây là một giao thức đồng thuận với 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 sẽ giới thiệu cách Shoal thực hiện việc thả trễ Bullshark.

Bối cảnh DAG-BFT

Hãy để chúng ta hiểu rõ về bối cảnh liên quan. Về mô tả chi tiết của Narwhal và Bullshark, vui lòng tham khảo bài viết DAG meets BFT.

Mỗi đỉnh trong Narwhal DAG đều liên kết với một vòng. Để vào vòng thứ r, người xác thực phải trước tiên nhận đượ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, 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 cái nhìn địa phương khác nhau của DAG tại bất kỳ thời điểm nào.

Một thuộc tính quan trọng của DAG là không mơ 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.

Toàn Tự

Có thể đạt được sự đồng thuận về tổng thứ tự của tất cả các đỉnh trong DAG mà không cần chi phí 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 của 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:

1. Điểm neo đã được đặt trước: Sau vài vòng (, cứ như trong Bullshark, sẽ có một người lãnh đạo được xác định trước, đỉnh của người lãnh đạo được gọi là điểm neo;

2. Sắp xếp điểm neo: Các thẩm định viên độc lập nhưng quyết định một cách chắc chắn các điểm neo nào sẽ được đặt hàng và các điểm neo nào sẽ bị bỏ qua;

3. Sắp xếp lịch sử nguyên nhân: Người xác nhận xử lý từng danh sách điểm neo theo 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ó thông qua một số quy tắc xác định.

Chìa khóa để đảm bảo an toàn là đảm bảo rằng trong bước )2(, 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ự, khiến 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 các quan sát sau về tất cả các giao thức trên:

Tất cả các trình xác thực đều đồng ý với điểm neo có thứ tự đầu tiên.

) Bullshark Trễ

Trễ của Bullshark phụ thuộc vào số vòng giữa các điểm neo có thứ tự trong DAG. Mặc dù phiên bản đồng bộ phần thực tế 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 được tối ưu.

Vấn đề 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 giải thích là một phiếu bầu. Trong trường hợp phổ biến, cần hai vòng DAG để đặt hàng điểm neo, tuy nhiên, các đỉnh trong lịch sử nguyên nhân của anchor cần nhiều vòng hơn để chờ anchor được sắp xếp. Trong trường hợp phổ biến, các đỉnh trong vòng lẻ cần ba vòng, trong khi các đỉnh không phải là anchor trong vòng chẵn cần bốn vòng.

Câu hỏi 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 người dẫn dắt của một vòng không kịp thời phát sóng điểm neo, thì không thể sắp xếp điểm neo ### do đó bị bỏ qua (, vì vậy tất cả các đỉnh chưa sắp xếp trong vài vòng trước phải chờ đ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ì thời gian Bullshark được sử dụng để chờ người dẫn dắt.

![Giải thích chi tiết về khung Shoal: Làm thế nào để thả Bullshark trên Aptos?])https://img-cdn.gateio.im/webp-social/moments-b7ed8888da112bae8d34c0fdb338b138.webp(

) 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 quy trình, cho phép có một điểm neo trong mỗi vòng và giảm trễ của tất cả các đỉnh không phải điểm neo trong DAG xuống còn ba vòng. Shoal cũng đã giới thiệu cơ chế danh tiếng lãnh đạo không tốn kém trong DAG, điều này khiến cho việc lựa chọn nghiêng về các lãnh đạo nhanh chóng.

) Thách thức

Trong bối cảnh giao thức DAG, việc xếp hàng và uy tín của người lãnh đạo được coi là những vấn đề khó khăn, lý do như sau:

1### Trước đây, quy trình xử lý dòng chảy đã cố gắng thay đổi logic Bullshark cốt lõi, nhưng điều này về bản chất dường như là không thể.

2. Danh tiếng của người lãnh đạo được giới thiệu trong DiemBFT và được chính thức hóa trong Carousel, được lựa chọn một cách linh hoạt dựa trên hiệu suất trong quá khứ của các xác thực để chọn ra những người lãnh đạo tương lai trong )Bullshark. Mặc dù có sự khác biệt trong danh tính lãnh đạo không vi phạm tính an toàn của các thỏa thuận này, nhưng trong Bullshark, điều này có thể dẫn đến một thứ tự hoàn toàn khác, điều này đưa ra câu hỏi cốt lõi rằng việc chọn các bánh xe neo 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ó trật tự để chọn ra các neo trong tương lai.

Là bằng chứng về độ khó của vấn đề, chúng tôi nhận thấy 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, không hỗ trợ những đặc tính này.

( Giao thức

Mặc dù có những thách thức trên, nhưng như câu nói đã nói, sự thật chứng minh rằng giải pháp ẩn chứa trong sự đơn giản.

Trong Shoal, chúng tôi dựa vào khả năng thực hiện tính toán cục bộ trên DAG và đạt được khả năng lưu trữ và giải thích lại thông tin từ những lượt trước. Với sự đồng ý của tất cả các xác thực về cái nhìn cốt lõi của điểm neo có thứ tự đầu tiên, Shoal kết hợp tuần tự nhiều 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 để tính toán uy tín của nhà lãnh đạo.

( Xử lý dây chuyền

V ánh xạ các vòng đến người lãnh đạo. Shoal lần lượt chạy các phiên bản của Bullshark, như vậy 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 đặt hàng một điểm neo, điều này sẽ kích hoạt việc chuyển sang phiên bản tiếp theo.

Ban đầu, Shoal đã khởi động phiên bản đầu tiên của Bullshark trong vòng đầu tiên của DAG và chạy nó cho đến khi xác định đượ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 đề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ỉ khởi động một phiên bản Bullshark mới trong vòng r+1.

Trong điều kiện tốt nhất, điều này cho phép Shoal đặt hàng một mỏ neo trong mỗi vòng. Điểm mỏ neo của vòng đầu tiên được sắp xếp theo các phiên bản đầu tiên. Sau đó, Shoal bắt đầu một phiên bản mới trong vòng thứ hai, chính nó có một điểm mỏ neo, mỏ neo đó được sắp xếp bởi phiên bản đó, sau đó, một phiên bản mới khác đặt hàng điểm mỏ neo trong vòng thứ ba, và quá trình này tiếp tụ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-0b0928cb6240e994c1514c75e080a4b2.webp(

) Danh tiếng lãnh đạo

Trong quá trình sắp xếp Bullshark, khi bỏ qua điểm neo, Trễ sẽ tăng lên. Trong trường hợp này, công nghệ xử lý theo ống không có tác dụng, vì không thể khởi động một phiên bản mới trước khi điểm neo trong phiên bản trước được đặt hàng. Shoal đảm bảo rằng khả năng chọn nhà lãnh đạo tương ứng để xử lý các điểm neo bị mất trong tương lai là thấp bằng cách sử dụng cơ chế danh tiếng, phân bổ một điểm số cho mỗi nút xác thực dựa trên lịch sử hoạt động gần đây của chúng. Các nhà xác thực phản hồi và tham gia vào giao thức sẽ nhận được điểm số cao, nếu không, các nút xác thực sẽ được phân bổ điểm số thấp, vì chúng có thể bị sập, chậm hoặc gian lận.

Triết lý của nó là trong mỗi lần cập nhật điểm số, tính toán lại một cách xác định ánh xạ F đã được định nghĩa từ vòng đến người lãnh đạo, thiên về những người lãnh đạo có điểm số cao hơn. Để các xác minh viên đạt được sự đồng thuận trên ánh xạ mới, họ nên đạt được sự đồng thuận về điểm số, từ đó đạt được sự đồng thuận về lịch sử được sử dụng để phát sinh điểm số.

Trong Shoal, dòng chảy và uy tín lãnh đạo có thể tự nhiên kết hợp, vì chúng đều sử dụng cùng một công nghệ cốt lõi, tức là giải thích lại DAG sau khi đạt được sự đồng thuận về điểm neo có thứ tự đầu tiên.

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 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 đã được 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 một 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 cập nhật F'.

![Giải thích chi tiết về khung Shoal: Làm thế nào để giảm trễ Bullshark trên Aptos?]###https://img-cdn.gateio.im/webp-social/moments-859e732e16c3eee0e2c93422474debc2.webp(

) Không còn thời gian chờ nữa

Thời gian chờ đóng một vai trò rất quan trọng trong tất cả các triển khai BFT đồng bộ phần chắc chắn dựa trên leader. 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 quản lý và quan sát, đ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 hết hạn cũng sẽ tăng đáng kể trễ, vì việc cấu hình chúng một cách hợp lý 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 nhà lãnh đạo tiếp theo, giao thức sẽ trả toàn bộ hình phạt trễ thời gian hết hạn cho nhà lãnh đạo gặp sự cố. Do đó, cài đặt thời gian hết hạn không thể quá bảo thủ, nhưng nếu thời gian hết hạn quá ngắn, giao thức có thể bỏ qua những nhà lãnh đạo tốt. Ví dụ, chúng tôi đã quan sát thấy, trong các trường hợp tải cao, Jolt