Giảm độ trễ Bullshark trên Aptos: Giải thích khung Shoal
Aptos labs đã 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ề sự tạm dừng trong giao thức thực sự 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%.
Khung Shoal tăng cường giao thức đồng thuận dựa trên Narwhal ( thông qua cơ chế ống dẫn và uy tín của người lãnh đạo như DAG-Rider, Tusk, Bullshark ). Ống dẫn giới thiệu một điểm neo mỗi vòng để giảm độ trễ sắp xếp DAG, trong khi uy tín của người lãnh đạo đảm bảo rằng điểm neo liên kết với các nút xác thực nhanh nhất, cải thiện thêm độ trễ. 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ỏ thời gian chờ trong mọi kịch bản, từ đó đạt được thuộc tính phản hồi phổ quát.
Công nghệ của Shoal rất đơn giản, chạy nhiều phiên bản của giao thức cơ sở theo thứ tự. Khi được khởi tạo bằng Bullshark, nó giống như một nhóm "cá mập" đang tham gia một cuộc tiếp sức.
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 giảm độ phức tạp của giao tiếp, nhưng điều này không dẫn đến sự gia tăng đáng kể về thông lượng. Ví dụ, Hotstuff được triển khai trong Diem ban đầu chỉ đạt 3500 TPS, thấp hơn nhiều so với mục tiêu 100k+ TPS.
Gần đây, sự đột phá xuất phát từ việc nhận ra việc truyền dữ liệu là nút thắt chính dựa trên giao thức lãnh đạo, có thể 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 khỏi logic đồng thuận cốt lõi, tất cả các xác thực viên đều truyền dữ liệu cùng một lúc, 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.
Aptos đã giới thiệu Quorum Store, tức là triển khai Narwhal, tách biệt việc truyền dữ liệu và đồng thuận, và được sử dụng để mở rộng giao thức đồng thuận hiện tại Jolteon. Jolteon kết hợp đường dẫn nhanh tuyến tính của Tendermint và thay đổi chế độ xem theo kiểu PBFT, giảm độ 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.
Do đó, Aptos 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, cấu trúc DAG hỗ trợ thông lượng cao của Bullshark đã mang lại 50% chi phí trễ.
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 liên quan đến 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 của vòng thứ 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 phải tham chiếu đến ít nhất n-f đỉnh của vòng trước. Do tính không đồng bộ của mạng, các xác thực viên khác nhau có thể quan sát các quan điểm cục bộ khác nhau của DAG.
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ó đỉnh giống nhau v trong chế độ xem DAG cục bộ của chúng, thì chúng có lịch sử nguyên nhân v hoàn toàn giống nhau.
Sắp xếp tổng thể
Có thể đạt được sự đồng thuận về tổng thứ tự của tất cả các đỉnh trong DAG mà không tốn thêm chi phí truyền thông. Các validator trong DAG-Rider, Tusk và Bullshark giải thích cấu trúc DAG như một giao thức đồng thuận, trong đó các đỉnh đại diện cho các đề xuất và các cạnh đại diện cho các phiếu bầu.
Mặc dù logic giao thoa nhóm trên cấu trúc DAG là khác nhau, nhưng tất cả các giao thức đồng thuận dựa trên Narwhal đều có cấu trúc sau:
Điểm neo được dự định: cứ vài vòng lại có một nhà lãnh đạo được xác định trước, đỉnh của nó được gọi là điểm neo.
Điểm neo sắp xếp: Các validator độc lập nhưng xác định quyết định sắp xếp những điểm neo nào và bỏ qua những điểm nào.
Lịch sử nguyên nhân được sắp xếp: Các xác thực xử lý từng mục trong danh sách điểm neo có thứ tự, sắp xếp các đỉnh không theo thứ tự trước đó trong lịch sử nguyên nhân của mỗi điểm neo.
Chìa khóa để đảm bảo an toàn là đảm bảo rằng trong bước (2), danh sách các điểm neo có thứ tự do các nút xác minh trung thực tạo ra chia sẻ cùng một tiền tố. Trong Shoal, chúng tôi đã quan sát thấy:
Tất cả các xác thực viên đều đồng ý với điểm neo thứ nhất có thứ tự.
Bullshark trì hoãn
Độ 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ột số phiên bản đồng bộ có độ trễ tốt hơn phiên bản bất đồng bộ, nhưng vẫn không phải là tốt nhất.
Câu hỏi 1: Độ trễ khối trung bình. Trong Bullshark, mỗi vòng chẵn có một điểm neo, đỉnh vòng lẻ được hiểu là phiếu bầu. Trong các trường hợp phổ biến, cần hai vòng DAG để sắp xếp điểm neo, nhưng 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ờ điểm neo được sắp xếp. Trong các trường hợp phổ biến, đỉnh vòng lẻ cần ba vòng, còn đỉnh vòng chẵn không phải điểm neo cần bốn vòng.
Vấn đề 2: Tình trạng lỗi bị trì hoãn. Nếu một vòng lãnh đạo không kịp thời phát sóng điểm neo, thì không thể sắp xếp ( bị bỏ qua ), tất cả các đỉnh chưa được sắp xếp trong các vòng trước phải chờ đợi điểm neo tiếp theo được sắp xếp. Điều này 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ờ lãnh đạo.
Khung Shoal
Shoal thông qua quy trình nâng cao Bullshark( hoặc bất kỳ giao thức BFT nào dựa trên Narwhal), cho phép có một điểm neo trong mỗi vòng, 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ế tín nhiệm lãnh đạo không tốn kém trong DAG, thiên về việc chọn lãnh đạo nhanh.
Thách thức
Trong giao thức DAG, vấn đề đường ống và uy tín của người lãnh đạo được coi là vấn đề khó khăn, lý do như sau:
Những 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 nhà lãnh đạo được giới thiệu trong DiemBFT và chính thức hóa trong Carousel, chọn nhà lãnh đạo tương lai một cách động dựa trên hiệu suất trong quá khứ của các xác thực viên (Neo trong Bullshark ). Mặc dù sự khác biệt về danh tính của nhà lãnh đạo không vi phạm tính bảo mật của những giao thức này, nhưng có thể dẫn đến thứ tự hoàn toàn khác nhau trong Bullshark, đưa ra vấn đề cốt lõi: việc chọn đường dẫn động và xác định là cần thiết để giải quyết sự đồng thuận, 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 đường dẫn tương lai.
Là bằng chứng về độ khó của vấn đề, việc thực hiện của Bullshark ( bao gồm ) trong môi trường sản xuất hiện tại đề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 nêu trên, nhưng giải pháp lại ẩn chứa trong sự đơn giản.
Shoal dựa vào khả năng thực hiện tính toán cục bộ trên DAG, đạt được khả năng lưu trữ và giải thích lại thông tin từ các vòng trước. Dựa trên sự đồng thuận của tất cả các validator về cái nhìn đầu tiên của điểm neo có thứ tự, Shoal kết hợp tuần tự nhiều instance Bullshark để xử lý theo đường ống, khiến cho (1) điểm neo có thứ tự đầu tiên trở thành điểm chuyển giao của các instance, (2) lịch sử nguyên nhân của điểm neo được sử dụng để tính toán uy tín của lãnh đạo.
Dây chuyền sản xuất
V ánh xạ các vòng vào các lãnh đạo. Shoal tuần tự chạy các phiên bản Bullshark, mỗi phiên bản có điểm neo được xác định trước bởi ánh xạ F. Mỗi phiên bản sắp xếp một điểm neo, 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, hoạt động cho đến khi xác định được điểm neo có thứ tự đầu tiên ( như là vòng r ). Tất cả các xác thực viên đều đồng ý với điểm neo này, do đó có thể xác định rõ ràng để đồng ý tái giải thích DAG từ vòng r+1. Shoal khởi động 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 neo trong mỗi vòng. Neo điểm vòng đầu tiên được sắp xếp bởi thực thể đầu tiên. Sau đó, Shoal bắt đầu một thực thể mới trong vòng thứ hai, nó có neo điểm riêng và được sắp xếp bởi thực thể đó, sau đó một thực thể mới khác sắp xếp neo điểm trong vòng thứ ba, và cứ tiếp tục như vậy.
Uy tín lãnh đạo
Khi Bullshark bỏ qua điểm neo trong sắp xếp, độ trễ sẽ tăng lên. Trong trường hợp này, đường ống không thể làm gì, vì không thể khởi động các phiên bản mới trước khi sắp xếp điểm neo của phiên bản trước. Shoal phân bổ điểm cho mỗi nút xác thực thông qua cơ chế tín nhiệm, đảm bảo rằng các lãnh đạo tương ứng có khả năng bị chọn để xử lý các điểm neo bị mất trong tương lai là thấp dựa trên lịch sử hoạt động gần đây của họ. 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 cao, nếu không sẽ nhận được điểm thấp ( có thể sụp đổ, chậm hoặc xấu xa ).
Khái niệm là trong mỗi lần cập nhật điểm số, tính toán lại xác định bản đồ đã định nghĩa F từ vòng đến người lãnh đạo một cách chắc chắn, thiên về người lãnh đạo có điểm số cao. Để các xác thực viên đạ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 trên lịch sử được sử dụng để phát sinh điểm số.
Trong Shoal, dây chuyền và độ tin cậy của người lãnh đạo tự nhiên kết hợp với nhau, vì chúng sử dụng cùng một công nghệ cốt lõi: giải thích lại DAG sau khi đạt được sự đồng thuận về điểm neo thứ tự đầu tiên.
Điểm khác biệt duy nhất là, sau điểm neo thứ r trong việc sắp xếp, các xác thực viên sẽ tính toán ánh xạ mới F' bắt đầu 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ó thứ tự trong vòng thứ r. Sau đó, các nút xác thực sẽ thực hiện các phiên bản mới của Bullshark từ vòng thứ r+1 trở đi 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êm thời gian
Thời gian quá hạn là rất quan trọng trong tất cả các triển khai BFT đồng bộ theo phần nhất quán dựa trên người 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à theo dõi, làm tăng độ phức tạp của quy trình gỡ lỗi, cần nhiều kỹ thuật quan sát hơn.
Thời gian chờ cũng làm tăng đáng kể độ trễ, vì việc cấu hình đúng cho chúng là rất quan trọng, thường cần điều chỉnh động, phụ thuộc nhiều vào môi trường ( mạng ). Trước khi chuyển sang lãnh đạo tiếp theo, giao thức sẽ trả toàn bộ hình phạt độ trễ thời gian chờ cho lãnh đạo gặp sự cố. Do đó, việc thiết lập thời gian chờ không thể quá bảo thủ, nhưng nếu 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 rằng trong điều kiện tải cao, lãnh đạo trong Jolteon/Hotstuff bị quá tải và thời gian chờ đã hết trước khi có thể thúc đẩy tiến trình.
Thật không may, các giao thức lãnh đạo dựa trên ( như Hotstuff và Jolteon) về cơ bản cần có thời gian chờ để đảm bảo rằng giao thức có thể tiến triển mỗi khi lãnh đạo gặp sự cố. Nếu không có thời gian chờ, ngay cả những lãnh đạo bị sập cũng có thể dừng giao thức mãi mãi. Do không thể phân biệt giữa lãnh đạo gặp sự cố và lãnh đạo chậm trong thời gian bất đồng bộ, thời gian chờ có thể dẫn đến việc các nút xác thực xem xét việc thay đổi tất cả lãnh đạo mà không có hoạt động đồng thuận.
Trong Bullshark, thời gian chờ được sử dụng cho việc xây dựng DAG, để đảm bảo rằng trong quá trình đồng bộ, các lãnh đạo trung thực sẽ thêm các điểm neo vào DAG với tốc độ đủ nhanh để có thể sắp xếp chúng.
Chúng tôi quan sát thấy rằng cấu trúc DAG cung cấp một "đồng hồ" để ước tính tốc độ mạng. Miễn là n-f người xác thực trung thực tiếp tục thêm đỉnh vào DAG mà không có bất kỳ sự tạm dừng nào, các vòng sẽ tiếp tục tiến lên. Mặc dù Bullshark có thể không thể sắp xếp ( theo tốc độ mạng do vấn đề lãnh đạo ), nhưng DAG vẫn phát triển với tốc độ mạng, mặc dù một số lãnh đạo gặp vấn đề hoặc mạng không đồng bộ. Cuối cùng, khi các lãnh đạo không gặp sự cố phát sóng các điểm neo đủ nhanh, toàn bộ lịch sử nguyên nhân của các điểm neo sẽ được sắp xếp.
Đang đánh giá, chúng tôi đã so sánh Bullshark trong các trường hợp có hoặc không có thời gian chờ:
Nhà lãnh đạo nhanh chóng, ít nhất là nhanh hơn các xác nhận viên khác. Trong trường hợp này, hai phương pháp cung cấp độ trễ giống nhau vì các mỏ neo có thứ tự và không sử dụng thời gian chờ.
Lãnh đạo sai, trong trường hợp này, Bullshark không có tạm dừng cung cấp độ trễ tốt hơn, vì các nút xác minh sẽ ngay lập tức bỏ qua điểm neo của nó, trong khi các nút xác minh có tạm dừng sẽ chờ chúng hết hạn trước khi tiếp tục.
Người lãnh đạo chậm, đây là trường hợp duy nhất mà hiệu suất vượt trội của Bullshark có thể xảy ra. Bởi vì không có tạm dừng, các điểm neo có thể bị bỏ qua, vì người lãnh đạo không thể phát sóng đủ nhanh, và khi có tạm dừng, các xác thực sẽ chờ đợi điểm neo.
Trong Shoal, việc tránh thời gian chờ quá lâu có mối liên hệ chặt chẽ với uy tín của nhà lãnh đạo. Chờ đợi lặp lại.
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.
Aptos giới thiệu khung Shoal Thả đáng kể độ trễ Bullshark và loại bỏ yêu cầu thời gian chờ
Giảm độ trễ Bullshark trên Aptos: Giải thích khung Shoal
Aptos labs đã 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ề sự tạm dừng trong giao thức thực sự 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%.
Khung Shoal tăng cường giao thức đồng thuận dựa trên Narwhal ( thông qua cơ chế ống dẫn và uy tín của người lãnh đạo như DAG-Rider, Tusk, Bullshark ). Ống dẫn giới thiệu một điểm neo mỗi vòng để giảm độ trễ sắp xếp DAG, trong khi uy tín của người lãnh đạo đảm bảo rằng điểm neo liên kết với các nút xác thực nhanh nhất, cải thiện thêm độ trễ. 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ỏ thời gian chờ trong mọi kịch bản, từ đó đạt được thuộc tính phản hồi phổ quát.
Công nghệ của Shoal rất đơn giản, chạy nhiều phiên bản của giao thức cơ sở theo thứ tự. Khi được khởi tạo bằng Bullshark, nó giống như một nhóm "cá mập" đang tham gia một cuộc tiếp sức.
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 giảm độ phức tạp của giao tiếp, nhưng điều này không dẫn đến sự gia tăng đáng kể về thông lượng. Ví dụ, Hotstuff được triển khai trong Diem ban đầu chỉ đạt 3500 TPS, thấp hơn nhiều so với mục tiêu 100k+ TPS.
Gần đây, sự đột phá xuất phát từ việc nhận ra việc truyền dữ liệu là nút thắt chính dựa trên giao thức lãnh đạo, có thể 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 khỏi logic đồng thuận cốt lõi, tất cả các xác thực viên đều truyền dữ liệu cùng một lúc, 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.
Aptos đã giới thiệu Quorum Store, tức là triển khai Narwhal, tách biệt việc truyền dữ liệu và đồng thuận, và được sử dụng để mở rộng giao thức đồng thuận hiện tại Jolteon. Jolteon kết hợp đường dẫn nhanh tuyến tính của Tendermint và thay đổi chế độ xem theo kiểu PBFT, giảm độ 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.
Do đó, Aptos 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, cấu trúc DAG hỗ trợ thông lượng cao của Bullshark đã mang lại 50% chi phí trễ.
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 liên quan đến 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 của vòng thứ 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 phải tham chiếu đến ít nhất n-f đỉnh của vòng trước. Do tính không đồng bộ của mạng, các xác thực viên khác nhau có thể quan sát các quan điểm cục bộ khác nhau của DAG.
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ó đỉnh giống nhau v trong chế độ xem DAG cục bộ của chúng, thì chúng có lịch sử nguyên nhân v hoàn toàn giống nhau.
Sắp xếp tổng thể
Có thể đạt được sự đồng thuận về tổng thứ tự của tất cả các đỉnh trong DAG mà không tốn thêm chi phí truyền thông. Các validator trong DAG-Rider, Tusk và Bullshark giải thích cấu trúc DAG như một giao thức đồng thuận, trong đó các đỉnh đại diện cho các đề xuất và các cạnh đại diện cho các phiếu bầu.
Mặc dù logic giao thoa nhóm trên cấu trúc DAG là khác nhau, nhưng tất cả các giao thức đồng thuận dựa trên Narwhal đều có cấu trúc sau:
Điểm neo được dự định: cứ vài vòng lại có một nhà lãnh đạo được xác định trước, đỉnh của nó được gọi là điểm neo.
Điểm neo sắp xếp: Các validator độc lập nhưng xác định quyết định sắp xếp những điểm neo nào và bỏ qua những điểm nào.
Lịch sử nguyên nhân được sắp xếp: Các xác thực xử lý từng mục trong danh sách điểm neo có thứ tự, sắp xếp các đỉnh không theo thứ tự trước đó trong lịch sử nguyên nhân của mỗi điểm neo.
Chìa khóa để đảm bảo an toàn là đảm bảo rằng trong bước (2), danh sách các điểm neo có thứ tự do các nút xác minh trung thực tạo ra chia sẻ cùng một tiền tố. Trong Shoal, chúng tôi đã quan sát thấy:
Tất cả các xác thực viên đều đồng ý với điểm neo thứ nhất có thứ tự.
Bullshark trì hoãn
Độ 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ột số phiên bản đồng bộ có độ trễ tốt hơn phiên bản bất đồng bộ, nhưng vẫn không phải là tốt nhất.
Câu hỏi 1: Độ trễ khối trung bình. Trong Bullshark, mỗi vòng chẵn có một điểm neo, đỉnh vòng lẻ được hiểu là phiếu bầu. Trong các trường hợp phổ biến, cần hai vòng DAG để sắp xếp điểm neo, nhưng 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ờ điểm neo được sắp xếp. Trong các trường hợp phổ biến, đỉnh vòng lẻ cần ba vòng, còn đỉnh vòng chẵn không phải điểm neo cần bốn vòng.
Vấn đề 2: Tình trạng lỗi bị trì hoãn. Nếu một vòng lãnh đạo không kịp thời phát sóng điểm neo, thì không thể sắp xếp ( bị bỏ qua ), tất cả các đỉnh chưa được sắp xếp trong các vòng trước phải chờ đợi điểm neo tiếp theo được sắp xếp. Điều này 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ờ lãnh đạo.
Khung Shoal
Shoal thông qua quy trình nâng cao Bullshark( hoặc bất kỳ giao thức BFT nào dựa trên Narwhal), cho phép có một điểm neo trong mỗi vòng, 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ế tín nhiệm lãnh đạo không tốn kém trong DAG, thiên về việc chọn lãnh đạo nhanh.
Thách thức
Trong giao thức DAG, vấn đề đường ống và uy tín của người lãnh đạo được coi là vấn đề khó khăn, lý do như sau:
Những 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 nhà lãnh đạo được giới thiệu trong DiemBFT và chính thức hóa trong Carousel, chọn nhà lãnh đạo tương lai một cách động dựa trên hiệu suất trong quá khứ của các xác thực viên (Neo trong Bullshark ). Mặc dù sự khác biệt về danh tính của nhà lãnh đạo không vi phạm tính bảo mật của những giao thức này, nhưng có thể dẫn đến thứ tự hoàn toàn khác nhau trong Bullshark, đưa ra vấn đề cốt lõi: việc chọn đường dẫn động và xác định là cần thiết để giải quyết sự đồng thuận, 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 đường dẫn tương lai.
Là bằng chứng về độ khó của vấn đề, việc thực hiện của Bullshark ( bao gồm ) trong môi trường sản xuất hiện tại đề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 nêu trên, nhưng giải pháp lại ẩn chứa trong sự đơn giản.
Shoal dựa vào khả năng thực hiện tính toán cục bộ trên DAG, đạt được khả năng lưu trữ và giải thích lại thông tin từ các vòng trước. Dựa trên sự đồng thuận của tất cả các validator về cái nhìn đầu tiên của điểm neo có thứ tự, Shoal kết hợp tuần tự nhiều instance Bullshark để xử lý theo đường ống, khiến cho (1) điểm neo có thứ tự đầu tiên trở thành điểm chuyển giao của các instance, (2) lịch sử nguyên nhân của điểm neo được sử dụng để tính toán uy tín của lãnh đạo.
Dây chuyền sản xuất
V ánh xạ các vòng vào các lãnh đạo. Shoal tuần tự chạy các phiên bản Bullshark, mỗi phiên bản có điểm neo được xác định trước bởi ánh xạ F. Mỗi phiên bản sắp xếp một điểm neo, 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, hoạt động cho đến khi xác định được điểm neo có thứ tự đầu tiên ( như là vòng r ). Tất cả các xác thực viên đều đồng ý với điểm neo này, do đó có thể xác định rõ ràng để đồng ý tái giải thích DAG từ vòng r+1. Shoal khởi động 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 neo trong mỗi vòng. Neo điểm vòng đầu tiên được sắp xếp bởi thực thể đầu tiên. Sau đó, Shoal bắt đầu một thực thể mới trong vòng thứ hai, nó có neo điểm riêng và được sắp xếp bởi thực thể đó, sau đó một thực thể mới khác sắp xếp neo điểm trong vòng thứ ba, và cứ tiếp tục như vậy.
Uy tín lãnh đạo
Khi Bullshark bỏ qua điểm neo trong sắp xếp, độ trễ sẽ tăng lên. Trong trường hợp này, đường ống không thể làm gì, vì không thể khởi động các phiên bản mới trước khi sắp xếp điểm neo của phiên bản trước. Shoal phân bổ điểm cho mỗi nút xác thực thông qua cơ chế tín nhiệm, đảm bảo rằng các lãnh đạo tương ứng có khả năng bị chọn để xử lý các điểm neo bị mất trong tương lai là thấp dựa trên lịch sử hoạt động gần đây của họ. 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 cao, nếu không sẽ nhận được điểm thấp ( có thể sụp đổ, chậm hoặc xấu xa ).
Khái niệm là trong mỗi lần cập nhật điểm số, tính toán lại xác định bản đồ đã định nghĩa F từ vòng đến người lãnh đạo một cách chắc chắn, thiên về người lãnh đạo có điểm số cao. Để các xác thực viên đạ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 trên lịch sử được sử dụng để phát sinh điểm số.
Trong Shoal, dây chuyền và độ tin cậy của người lãnh đạo tự nhiên kết hợp với nhau, vì chúng sử dụng cùng một công nghệ cốt lõi: giải thích lại DAG sau khi đạt được sự đồng thuận về điểm neo thứ tự đầu tiên.
Điểm khác biệt duy nhất là, sau điểm neo thứ r trong việc sắp xếp, các xác thực viên sẽ tính toán ánh xạ mới F' bắt đầu 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ó thứ tự trong vòng thứ r. Sau đó, các nút xác thực sẽ thực hiện các phiên bản mới của Bullshark từ vòng thứ r+1 trở đi 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êm thời gian
Thời gian quá hạn là rất quan trọng trong tất cả các triển khai BFT đồng bộ theo phần nhất quán dựa trên người 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à theo dõi, làm tăng độ phức tạp của quy trình gỡ lỗi, cần nhiều kỹ thuật quan sát hơn.
Thời gian chờ cũng làm tăng đáng kể độ trễ, vì việc cấu hình đúng cho chúng là rất quan trọng, thường cần điều chỉnh động, phụ thuộc nhiều vào môi trường ( mạng ). Trước khi chuyển sang lãnh đạo tiếp theo, giao thức sẽ trả toàn bộ hình phạt độ trễ thời gian chờ cho lãnh đạo gặp sự cố. Do đó, việc thiết lập thời gian chờ không thể quá bảo thủ, nhưng nếu 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 rằng trong điều kiện tải cao, lãnh đạo trong Jolteon/Hotstuff bị quá tải và thời gian chờ đã hết trước khi có thể thúc đẩy tiến trình.
Thật không may, các giao thức lãnh đạo dựa trên ( như Hotstuff và Jolteon) về cơ bản cần có thời gian chờ để đảm bảo rằng giao thức có thể tiến triển mỗi khi lãnh đạo gặp sự cố. Nếu không có thời gian chờ, ngay cả những lãnh đạo bị sập cũng có thể dừng giao thức mãi mãi. Do không thể phân biệt giữa lãnh đạo gặp sự cố và lãnh đạo chậm trong thời gian bất đồng bộ, thời gian chờ có thể dẫn đến việc các nút xác thực xem xét việc thay đổi tất cả lãnh đạo mà không có hoạt động đồng thuận.
Trong Bullshark, thời gian chờ được sử dụng cho việc xây dựng DAG, để đảm bảo rằng trong quá trình đồng bộ, các lãnh đạo trung thực sẽ thêm các điểm neo vào DAG với tốc độ đủ nhanh để có thể sắp xếp chúng.
Chúng tôi quan sát thấy rằng cấu trúc DAG cung cấp một "đồng hồ" để ước tính tốc độ mạng. Miễn là n-f người xác thực trung thực tiếp tục thêm đỉnh vào DAG mà không có bất kỳ sự tạm dừng nào, các vòng sẽ tiếp tục tiến lên. Mặc dù Bullshark có thể không thể sắp xếp ( theo tốc độ mạng do vấn đề lãnh đạo ), nhưng DAG vẫn phát triển với tốc độ mạng, mặc dù một số lãnh đạo gặp vấn đề hoặc mạng không đồng bộ. Cuối cùng, khi các lãnh đạo không gặp sự cố phát sóng các điểm neo đủ nhanh, toàn bộ lịch sử nguyên nhân của các điểm neo sẽ được sắp xếp.
Đang đánh giá, chúng tôi đã so sánh Bullshark trong các trường hợp có hoặc không có thời gian chờ:
Nhà lãnh đạo nhanh chóng, ít nhất là nhanh hơn các xác nhận viên khác. Trong trường hợp này, hai phương pháp cung cấp độ trễ giống nhau vì các mỏ neo có thứ tự và không sử dụng thời gian chờ.
Lãnh đạo sai, trong trường hợp này, Bullshark không có tạm dừng cung cấp độ trễ tốt hơn, vì các nút xác minh sẽ ngay lập tức bỏ qua điểm neo của nó, trong khi các nút xác minh có tạm dừng sẽ chờ chúng hết hạn trước khi tiếp tục.
Người lãnh đạo chậm, đây là trường hợp duy nhất mà hiệu suất vượt trội của Bullshark có thể xảy ra. Bởi vì không có tạm dừng, các điểm neo có thể bị bỏ qua, vì người lãnh đạo không thể phát sóng đủ nhanh, và khi có tạm dừng, các xác thực sẽ chờ đợi điểm neo.
Trong Shoal, việc tránh thời gian chờ quá lâu có mối liên hệ chặt chẽ với uy tín của nhà lãnh đạo. Chờ đợi lặp lại.