Khung Shoal: Giải pháp đổi mới nâng cao hiệu suất Blockchain Aptos
Aptos Labs gần đây đã đề xuất khung Shoal, nhằm giải quyết hai vấn đề chính trong đồng thuận DAG BFT, giảm đáng kể độ trễ và lần đầu tiên loại bỏ sự phụ thuộc vào thời gian chờ trong giao thức bất định. Nhìn chung, Shoal đã cải thiện độ trễ của Bullshark lên 40% trong trường hợp không có sự cố và 80% trong trường hợp có sự cố.
Shoal tăng cường giao thức đồng thuận dựa trên Narwhal ( thông qua cơ chế danh tiếng lãnh đạo và quy trình. Công nghệ quy trình 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 cơ chế danh tiếng lãnh đạo cải thiện thêm độ trễ bằng cách đảm bảo rằng điểm neo liên quan đến các nút xác thực nhanh nhất. Hơn nữa, danh tiếng lãnh đạo cho phép Shoal tận dụng việc xây dựng DAG bất đồng bộ để loại bỏ thời gian chờ trong tất cả các trường hợp, từ đó đạt được khả năng phản hồi toàn diện.
Ý tưởng cốt lõi của Shoal là chạy nhiều phiên bản của giao thức nền tảng theo thứ tự. Lấy Bullshark làm ví dụ, có thể tưởng tượng nó như một nhóm "cá mập" đang chạy 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ơ
Mạng blockchain luôn theo đuổi hiệu suất cao hơn, ban đầu chủ yếu tập trung vào việc giảm độ phức tạp của việc truyền thông. 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.
Gần đây, sự đột phá đến từ việc nhận ra rằng việc truyền dữ liệu là nút thắt chính dựa trên 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 và 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 truyền dữ liệu đồng thời, các thành phần đồng thuận chỉ sắp xếp một lượng nhỏ siêu dữ liệu, đạt được thông lượng 160.000 TPS.
Aptos trước đây đã giới thiệu Quorum Store, tức là việc thực hiện 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 đi nhanh tuyến tính của Tendermint và thay đổi quan điểm theo phong cách 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. Tuy nhiên, cấu trúc DAG hỗ trợ thông lượng cao của Bullshark đã mang lại chi phí độ trễ 50%. Mục tiêu của khung Shoal là giảm đáng kể độ trễ của Bullshark.
![Giải thích chi tiết về khung Shoal: Làm thế nào để giảm độ trễ Bullshark trên Aptos?])https://img-cdn.gateio.im/webp-social/moments-f6b6281c928e3fa7a2412a480c9c1806.webp(
Bối cảnh DAG-BFT
Mỗi đỉnh trong Narwhal DAG đều liên quan đến một vòng. Để vào vòng thứ r, cần phải có n-f đỉnh của vòng r-1. Mỗi người xác thực có thể phát sóng một đỉnh mỗi vòng, và mỗi đỉnh ít nhất phải tham chiếu đến n-f đỉnh của vòng trước. Do tính không đồ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 về DAG.
Một đặc điểm quan trọng của DAG là tính không mơ hồ: nếu hai nút xác minh có cùng đỉnh v trong cái nhìn DAG cục bộ, 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 độ trễ Bullshark trên Aptos?])https://img-cdn.gateio.im/webp-social/moments-b7ed8888da112bae8d34c0fdb338b138.webp(
Sắp xếp toàn thứ tự
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. Các giao thức như 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, còn các cạnh đại diện cho các phiếu bầu.
Mặc dù logic cụ thể 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 đặt trước: cứ sau vài vòng sẽ 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: Nhà xác thực độc lập nhưng quyết định một cách xác định các điểm neo nào sẽ được sắp xếp hoặc bỏ qua.
Sắp xếp lịch sử nguyên nhân: Các xác thực viên lần lượt xử lý danh sách các điểm neo có thứ tự, sắp xếp các đỉnh chưa được sắp xếp trước đó trong lịch sử nguyên nhân của mỗi điểm neo.
Yếu tố chính để đảm bảo an toàn là đảm bảo rằng danh sách các điểm neo có thứ tự được tạo ra bởi tất cả các nút xác thực trung thực chia sẻ cùng một tiền tố. Shoal đưa ra một quan sát quan trọng về tất cả các giao thức này: tất cả các xác thực viên đều đồng ý với điểm neo có thứ tự đầu tiên.
Vấn đề trễ của Bullshark
Độ 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ù một số phiên bản đồng bộ có độ trễ thấp hơn phiên bản bất đồng bộ, nhưng vẫn còn xa mới đạt tối ưu.
Chủ yếu có hai vấn đề:
Độ trễ khối trung bình: Trong các trường hợp phổ biến, đỉnh lẻ cần ba vòng để sắp xếp, đỉnh chẵn không phải điểm neo cần bốn vòng.
Tình trạng trục trặc trì hoãn: Nếu nhà lãnh đạo của một vòng không kịp thời phát sóng điểm neo, điểm neo đó sẽ bị bỏ qua, tất cả các đỉnh chưa được sắp xếp của 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 phân bố địa lý một cách đáng kể, đặc biệt là vì Bullshark sử dụng thời gian chờ hết hạn cho nhà lãnh đạo.
![Giải thích chi tiết về khuôn khổ Shoal: Làm thế nào để giảm độ trễ Bullshark trên Aptos?])https://img-cdn.gateio.im/webp-social/moments-46d37add0d9e81b2f295edf8eddd907f.webp(
Khung Shoal
Shoal cải thiện Bullshark) hoặc bất kỳ giao thức BFT nào dựa trên Narwhal( thông qua pipeline, cho phép mỗi vòng có một điểm neo, giảm độ trễ của tất cả các đỉnh không phải điểm neo 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 chi phí trong DAG, ưu tiên lựa chọn lãnh đạo nhanh.
) Thách thức
Việc triển khai pipeline và uy tín của người lãnh đạo trong giao thức DAG được coi là khó khăn:
Việc cố gắng sửa đổi logic cốt lõi của Bullshark dường như không khả thi.
Danh tiếng của người lãnh đạo có thể dẫn đến sự sắp xếp khác nhau, trong khi các xác nhận viên cần đạt được sự đồng thuận về lịch sử có thứ tự để chọn điểm neo trong tương lai.
Như một bằng chứng cho độ khó của vấn đề, hiện tại các triển khai Bullshark trong môi trường sản xuất không hỗ trợ những tính năng này.
giao thức
Giải pháp của Shoal tương đối đơn giản. Nó tận dụng khả năng thực hiện tính toán cục bộ trên DAG, để lưu trữ và giải thích lại thông tin từ những vòng trước. Dựa trên sự đồng thuận của tất cả các xác thực về cái nhìn đầu tiên về điểm neo có thứ tự, Shoal kết hợp theo thứ tự nhiều phiên bản Bullshark để xử lý theo dạng ống dẫn, cho phép:
Điểm neo có thứ tự đầu tiên là điểm chuyển đổi của phiên bản.
Lịch sử nguyên nhân của điểm neo được sử dụng để tính toán danh tiếng của nhà lãnh đạo
Dòng chảy
V ánh xạ các lượt đến người lãnh đạo. Shoal chạy các phiên bản Bullshark theo thứ tự, mỗi phiên bản sắp xếp một điểm neo và kích hoạt chuyển sang phiên bản tiếp theo.
Shoal từ giai đoạn đầu tiên của DAG khởi động phiên bản đầu tiên của Bullshark, cho đến khi xác định được điểm neo có thứ tự đầu tiên ### giả định ở 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ể đồng ý một cách chắc chắn để giải thích lại DAG từ vòng r+1. Shoal khởi động phiên bản Bullshark mới ở vòng r+1.
Trong điều kiện lý tưởng, điều này cho phép Shoal sắp xếp một điểm neo mỗi vòng. Điểm neo vòng đầu tiên được sắp xếp bởi phiên bản đầu tiên, sau đó trong vòng thứ hai, phiên bản mới sẽ sắp xếp điểm neo của vòng đó, và cứ như vậy.
![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-0b0928cb6240e994c1514c75e080a4b2.webp(
) Danh tiếng lãnh đạo
Khi Bullshark bỏ qua điểm neo, độ trễ sẽ tăng lên. Công nghệ pipeline trong trường hợp này không có tác dụng, vì phải chờ phiên bản trước sắp xếp điểm neo mới có thể khởi động phiên bản mới. Shoal phân bổ điểm cho từng nút xác thực thông qua cơ chế danh tiếng, dựa trên lịch sử hoạt động gần đây của nó. Những người xác thực phản hồi nhanh sẽ nhận được điểm cao, ngược lại sẽ nhận được điểm thấp.
Ý tưởng là trong mỗi lần cập nhật điểm số, xác định lại một cách chắc chắn ánh xạ F từ vòng đến người lãnh đạo, 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 ánh xạ mới, họ cần đạt được sự đồng thuận về điểm số, và từ đó đạt được sự đồng thuận trên lịch sử được sử dụng để suy diễn điểm số.
Trong Shoal, uy tín của dòng và lãnh đạo có thể tự nhiên kết hợp, vì cả hai đều dựa trên việc giải thích lại DAG sau khi đạt được sự đồng thuận ở điểm neo thứ nhất có thứ tự. Sự khác biệt duy nhất là, sau điểm neo thứ r, các xác thực tính toán ánh xạ mới F' bắt đầu từ vòng r+1 dựa trên lịch sử nguyên nhân của điểm neo đó. Sau đó, từ vòng r+1, thực hiện các ví dụ Bullshark mới với F' đã được cập nhật.
![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(
) Loại bỏ thời gian chờ
Thời gian chờ rất quan trọng trong tất cả các triển khai BFT đồng bộ phần dựa trên lãnh đạo có tính quyết định. Tuy nhiên, chúng làm tăng độ phức tạp, cần nhiều quản lý trạng thái nội bộ hơn và quan sát, khiến việc gỡ lỗi trở nên khó khăn hơn.
Thời gian chờ sẽ làm tăng độ trễ một cách đáng kể, vì việc cấu hình đúng là rất quan trọng và thường cần điều chỉnh động. Trước khi chuyển sang lãnh đạo tiếp theo, giao thức phải trả hình phạt độ trễ tối đa cho lãnh đạo bị lỗi. Do đó, cài đặt thời gian chờ không thể quá bảo thủ, nhưng nếu quá ngắn có thể bỏ qua lãnh đạo tốt.
Thật không may, giao thức dựa trên người lãnh đạo ### như Hotstuff và Jolteon ( về cơ bản cần có thời gian chờ để đảm bảo tiến trình khi người lãnh đạo gặp sự cố. Nếu không có thời gian chờ, ngay cả người lãnh đạo đã sập cũng có thể ngừng giao thức mãi mãi. Do không thể phân biệt giữa sự cố và người 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 thay thế tất cả người lãnh đạo mà không có mức độ đồng thuận hoạt động.
Trong Bullshark, thời gian chờ được sử dụng để xây dựng DAG, nhằm đảm bảo rằng trong quá trình đồng bộ, các nhà lãnh đạo trung thực có thể thêm các điểm neo vào DAG đủ nhanh để sắp xếp.
Chúng tôi quan sát thấy việc xây dựng DAG cung cấp một "đồng hồ" ước lượng tốc độ mạng. Chừng nào n-f nhà xác nhận trung thực tiếp tục thêm đỉnh vào DAG, vòng sẽ tiến lên. Mặc dù Bullshark có thể không sắp xếp theo tốc độ mạng, nhưng DAG vẫn phát triển với tốc độ mạng. Cuối cùng, khi một nhà lãnh đạo không bị lỗi 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.
Trong đánh giá, chúng tôi đã so sánh Bullshark có và không có thời gian chờ:
Nhà lãnh đạo nhanh chóng: Hai phương pháp trì hoãn giống nhau, vì điểm neo được sắp xếp và không sử dụng thời gian chờ.
Lãnh đạo sai: Bullshark không có thời gian chờ đợi, độ trễ thấp hơn, vì các nút xác thực sẽ ngay lập tức bỏ qua điểm neo của nó.
Nhà lãnh đạo chậm: Có Bullshark vượt trội hơn trong trường hợp timeout, vì các xác thực sẽ chờ điểm neo, trong khi không có timeout có thể bỏ qua điểm neo.
Trong Shoal, việc tránh thời gian chờ lâu có liên quan chặt chẽ đến danh tiếng của người lãnh đạo. Việc chờ đợi những người lãnh đạo chậm sẽ làm tăng độ trễ, trong khi cơ chế danh tiếng loại trừ những người xác minh chậm được chọn làm lãnh đạo. Như vậy, hệ thống có thể hoạt động với tốc độ mạng trong tất cả các tình huống thực tế.
Cần lưu ý rằng, kết quả không thể của FLP chỉ ra rằng không có giao thức đồng thuận xác định nào có thể hoàn toàn tránh được thời gian chờ. Shoal không thể vượt qua kết quả này, vì về lý thuyết tồn tại các lịch trình sự kiện đối kháng có thể ngăn chặn tất cả các điểm neo được sắp xếp. Ngược lại, sau số lượng điểm neo có thể cấu hình liên tiếp, Shoal sẽ trở lại trạng thái chờ. Nhưng trên thực tế, tình huống này rất khó xảy ra.
) Đáp ứng phổ biến
Bài báo Hotstuff phổ biến khái niệm phản hồi lạc quan, trực quan có nghĩa là giao thức có thể hoạt động với tốc độ mạng ### trong các tình huống tốt, bao gồm lãnh đạo nhanh và mạng đồng bộ (.
Shoal cung cấp một tính năng tốt hơn, được gọi là khả năng phản hồi phổ quát. Cụ thể, so với Hotstuff, ngay cả khi người lãnh đạo thất bại trong một số vòng liên tiếp có thể cấu hình hoặc mạng trải qua các chu kỳ bất đồng bộ, Shoal vẫn tiếp tục hoạt động với tốc độ mạng.
Độ phản hồi phổ biến cung cấp đảm bảo tiến độ tốt hơn đáng kể trong thời gian không đồng bộ và khi có sự cố với người lãnh đạo. Trong thời gian đồng bộ với người lãnh đạo chậm, những đặc điểm này không thể so sánh trực tiếp vì phụ thuộc vào tốc độ của người lãnh đạo. Tuy nhiên, với cơ chế danh tiếng của người lãnh đạo, người lãnh đạo chậm trong Shoal nên hiếm khi xuất hiện.
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.
18 thích
Phần thưởng
18
7
Đăng lại
Chia sẻ
Bình luận
0/400
GasGrillMaster
· 8giờ trước
Ôi trời ơi Trễ cắt một nửa bull wow
Xem bản gốcTrả lời0
MysteriousZhang
· 08-12 04:51
Bốn mươi phần trăm cũng dám khoe? kkk
Xem bản gốcTrả lời0
SerumSquirter
· 08-12 04:50
Cuối cùng cũng có thể tiếp tục đổ tiền vào đây.
Xem bản gốcTrả lời0
ContractCollector
· 08-12 04:48
Đợt tối ưu hóa trễ này thật mạnh mẽ!
Xem bản gốcTrả lời0
LiquidityWitch
· 08-12 04:44
Cái này quá mạnh mẽ, Trễ nâng 40
Xem bản gốcTrả lời0
GateUser-26d7f434
· 08-12 04:41
Tăng tốc 40% có thể chạy với Mạng chính?
Xem bản gốcTrả lời0
YieldHunter
· 08-12 04:41
về mặt kỹ thuật mà nói... 40% thì cũng không tệ nhưng hiển thị cho tôi các số liệu lợi suất
Khung Shoal: Tăng 40% Trễ trên chuỗi Aptos và loại bỏ sự phụ thuộc vào thời gian hết hạn
Khung Shoal: Giải pháp đổi mới nâng cao hiệu suất Blockchain Aptos
Aptos Labs gần đây đã đề xuất khung Shoal, nhằm giải quyết hai vấn đề chính trong đồng thuận DAG BFT, giảm đáng kể độ trễ và lần đầu tiên loại bỏ sự phụ thuộc vào thời gian chờ trong giao thức bất định. Nhìn chung, Shoal đã cải thiện độ trễ của Bullshark lên 40% trong trường hợp không có sự cố và 80% trong trường hợp có sự cố.
Shoal tăng cường giao thức đồng thuận dựa trên Narwhal ( thông qua cơ chế danh tiếng lãnh đạo và quy trình. Công nghệ quy trình 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 cơ chế danh tiếng lãnh đạo cải thiện thêm độ trễ bằng cách đảm bảo rằng điểm neo liên quan đến các nút xác thực nhanh nhất. Hơn nữa, danh tiếng lãnh đạo cho phép Shoal tận dụng việc xây dựng DAG bất đồng bộ để loại bỏ thời gian chờ trong tất cả các trường hợp, từ đó đạt được khả năng phản hồi toàn diện.
Ý tưởng cốt lõi của Shoal là chạy nhiều phiên bản của giao thức nền tảng theo thứ tự. Lấy Bullshark làm ví dụ, có thể tưởng tượng nó như một nhóm "cá mập" đang chạy 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ơ
Mạng blockchain luôn theo đuổi hiệu suất cao hơn, ban đầu chủ yếu tập trung vào việc giảm độ phức tạp của việc truyền thông. 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.
Gần đây, sự đột phá đến từ việc nhận ra rằng việc truyền dữ liệu là nút thắt chính dựa trên 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 và 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 truyền dữ liệu đồng thời, các thành phần đồng thuận chỉ sắp xếp một lượng nhỏ siêu dữ liệu, đạt được thông lượng 160.000 TPS.
Aptos trước đây đã giới thiệu Quorum Store, tức là việc thực hiện 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 đi nhanh tuyến tính của Tendermint và thay đổi quan điểm theo phong cách 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. Tuy nhiên, cấu trúc DAG hỗ trợ thông lượng cao của Bullshark đã mang lại chi phí độ trễ 50%. Mục tiêu của khung Shoal là giảm đáng kể độ trễ của Bullshark.
![Giải thích chi tiết về khung Shoal: Làm thế nào để giảm độ trễ Bullshark trên Aptos?])https://img-cdn.gateio.im/webp-social/moments-f6b6281c928e3fa7a2412a480c9c1806.webp(
Bối cảnh DAG-BFT
Mỗi đỉnh trong Narwhal DAG đều liên quan đến một vòng. Để vào vòng thứ r, cần phải có n-f đỉnh của vòng r-1. Mỗi người xác thực có thể phát sóng một đỉnh mỗi vòng, và mỗi đỉnh ít nhất phải tham chiếu đến n-f đỉnh của vòng trước. Do tính không đồ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 về DAG.
Một đặc điểm quan trọng của DAG là tính không mơ hồ: nếu hai nút xác minh có cùng đỉnh v trong cái nhìn DAG cục bộ, 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 độ trễ Bullshark trên Aptos?])https://img-cdn.gateio.im/webp-social/moments-b7ed8888da112bae8d34c0fdb338b138.webp(
Sắp xếp toàn thứ tự
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. Các giao thức như 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, còn các cạnh đại diện cho các phiếu bầu.
Mặc dù logic cụ thể 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 đặt trước: cứ sau vài vòng sẽ 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: Nhà xác thực độc lập nhưng quyết định một cách xác định các điểm neo nào sẽ được sắp xếp hoặc bỏ qua.
Sắp xếp lịch sử nguyên nhân: Các xác thực viên lần lượt xử lý danh sách các điểm neo có thứ tự, sắp xếp các đỉnh chưa được sắp xếp trước đó trong lịch sử nguyên nhân của mỗi điểm neo.
Yếu tố chính để đảm bảo an toàn là đảm bảo rằng danh sách các điểm neo có thứ tự được tạo ra bởi tất cả các nút xác thực trung thực chia sẻ cùng một tiền tố. Shoal đưa ra một quan sát quan trọng về tất cả các giao thức này: tất cả các xác thực viên đều đồng ý với điểm neo có thứ tự đầu tiên.
Vấn đề trễ của Bullshark
Độ 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ù một số phiên bản đồng bộ có độ trễ thấp hơn phiên bản bất đồng bộ, nhưng vẫn còn xa mới đạt tối ưu.
Chủ yếu có hai vấn đề:
Độ trễ khối trung bình: Trong các trường hợp phổ biến, đỉnh lẻ cần ba vòng để sắp xếp, đỉnh chẵn không phải điểm neo cần bốn vòng.
Tình trạng trục trặc trì hoãn: Nếu nhà lãnh đạo của một vòng không kịp thời phát sóng điểm neo, điểm neo đó sẽ bị bỏ qua, tất cả các đỉnh chưa được sắp xếp của 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 phân bố địa lý một cách đáng kể, đặc biệt là vì Bullshark sử dụng thời gian chờ hết hạn cho nhà lãnh đạo.
![Giải thích chi tiết về khuôn khổ Shoal: Làm thế nào để giảm độ trễ Bullshark trên Aptos?])https://img-cdn.gateio.im/webp-social/moments-46d37add0d9e81b2f295edf8eddd907f.webp(
Khung Shoal
Shoal cải thiện Bullshark) hoặc bất kỳ giao thức BFT nào dựa trên Narwhal( thông qua pipeline, cho phép mỗi vòng có một điểm neo, giảm độ trễ của tất cả các đỉnh không phải điểm neo 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 chi phí trong DAG, ưu tiên lựa chọn lãnh đạo nhanh.
) Thách thức
Việc triển khai pipeline và uy tín của người lãnh đạo trong giao thức DAG được coi là khó khăn:
Việc cố gắng sửa đổi logic cốt lõi của Bullshark dường như không khả thi.
Danh tiếng của người lãnh đạo có thể dẫn đến sự sắp xếp khác nhau, trong khi các xác nhận viên cần đạt được sự đồng thuận về lịch sử có thứ tự để chọn điểm neo trong tương lai.
Như một bằng chứng cho độ khó của vấn đề, hiện tại các triển khai Bullshark trong môi trường sản xuất không hỗ trợ những tính năng này.
giao thức
Giải pháp của Shoal tương đối đơn giản. Nó tận dụng khả năng thực hiện tính toán cục bộ trên DAG, để lưu trữ và giải thích lại thông tin từ những vòng trước. Dựa trên sự đồng thuận của tất cả các xác thực về cái nhìn đầu tiên về điểm neo có thứ tự, Shoal kết hợp theo thứ tự nhiều phiên bản Bullshark để xử lý theo dạng ống dẫn, cho phép:
Dòng chảy
V ánh xạ các lượt đến người lãnh đạo. Shoal chạy các phiên bản Bullshark theo thứ tự, mỗi phiên bản sắp xếp một điểm neo và kích hoạt chuyển sang phiên bản tiếp theo.
Shoal từ giai đoạn đầu tiên của DAG khởi động phiên bản đầu tiên của Bullshark, cho đến khi xác định được điểm neo có thứ tự đầu tiên ### giả định ở 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ể đồng ý một cách chắc chắn để giải thích lại DAG từ vòng r+1. Shoal khởi động phiên bản Bullshark mới ở vòng r+1.
Trong điều kiện lý tưởng, điều này cho phép Shoal sắp xếp một điểm neo mỗi vòng. Điểm neo vòng đầu tiên được sắp xếp bởi phiên bản đầu tiên, sau đó trong vòng thứ hai, phiên bản mới sẽ sắp xếp điểm neo của vòng đó, và cứ như vậy.
![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-0b0928cb6240e994c1514c75e080a4b2.webp(
) Danh tiếng lãnh đạo
Khi Bullshark bỏ qua điểm neo, độ trễ sẽ tăng lên. Công nghệ pipeline trong trường hợp này không có tác dụng, vì phải chờ phiên bản trước sắp xếp điểm neo mới có thể khởi động phiên bản mới. Shoal phân bổ điểm cho từng nút xác thực thông qua cơ chế danh tiếng, dựa trên lịch sử hoạt động gần đây của nó. Những người xác thực phản hồi nhanh sẽ nhận được điểm cao, ngược lại sẽ nhận được điểm thấp.
Ý tưởng là trong mỗi lần cập nhật điểm số, xác định lại một cách chắc chắn ánh xạ F từ vòng đến người lãnh đạo, 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 ánh xạ mới, họ cần đạt được sự đồng thuận về điểm số, và từ đó đạt được sự đồng thuận trên lịch sử được sử dụng để suy diễn điểm số.
Trong Shoal, uy tín của dòng và lãnh đạo có thể tự nhiên kết hợp, vì cả hai đều dựa trên việc giải thích lại DAG sau khi đạt được sự đồng thuận ở điểm neo thứ nhất có thứ tự. Sự khác biệt duy nhất là, sau điểm neo thứ r, các xác thực tính toán ánh xạ mới F' bắt đầu từ vòng r+1 dựa trên lịch sử nguyên nhân của điểm neo đó. Sau đó, từ vòng r+1, thực hiện các ví dụ Bullshark mới với F' đã được cập nhật.
![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(
) Loại bỏ thời gian chờ
Thời gian chờ rất quan trọng trong tất cả các triển khai BFT đồng bộ phần dựa trên lãnh đạo có tính quyết định. Tuy nhiên, chúng làm tăng độ phức tạp, cần nhiều quản lý trạng thái nội bộ hơn và quan sát, khiến việc gỡ lỗi trở nên khó khăn hơn.
Thời gian chờ sẽ làm tăng độ trễ một cách đáng kể, vì việc cấu hình đúng là rất quan trọng và thường cần điều chỉnh động. Trước khi chuyển sang lãnh đạo tiếp theo, giao thức phải trả hình phạt độ trễ tối đa cho lãnh đạo bị lỗi. Do đó, cài đặt thời gian chờ không thể quá bảo thủ, nhưng nếu quá ngắn có thể bỏ qua lãnh đạo tốt.
Thật không may, giao thức dựa trên người lãnh đạo ### như Hotstuff và Jolteon ( về cơ bản cần có thời gian chờ để đảm bảo tiến trình khi người lãnh đạo gặp sự cố. Nếu không có thời gian chờ, ngay cả người lãnh đạo đã sập cũng có thể ngừng giao thức mãi mãi. Do không thể phân biệt giữa sự cố và người 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 thay thế tất cả người lãnh đạo mà không có mức độ đồng thuận hoạt động.
Trong Bullshark, thời gian chờ được sử dụng để xây dựng DAG, nhằm đảm bảo rằng trong quá trình đồng bộ, các nhà lãnh đạo trung thực có thể thêm các điểm neo vào DAG đủ nhanh để sắp xếp.
Chúng tôi quan sát thấy việc xây dựng DAG cung cấp một "đồng hồ" ước lượng tốc độ mạng. Chừng nào n-f nhà xác nhận trung thực tiếp tục thêm đỉnh vào DAG, vòng sẽ tiến lên. Mặc dù Bullshark có thể không sắp xếp theo tốc độ mạng, nhưng DAG vẫn phát triển với tốc độ mạng. Cuối cùng, khi một nhà lãnh đạo không bị lỗi 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.
Trong đánh giá, chúng tôi đã so sánh Bullshark có và không có thời gian chờ:
Nhà lãnh đạo nhanh chóng: Hai phương pháp trì hoãn giống nhau, vì điểm neo được sắp xếp và không sử dụng thời gian chờ.
Lãnh đạo sai: Bullshark không có thời gian chờ đợi, độ trễ thấp hơn, vì các nút xác thực sẽ ngay lập tức bỏ qua điểm neo của nó.
Nhà lãnh đạo chậm: Có Bullshark vượt trội hơn trong trường hợp timeout, vì các xác thực sẽ chờ điểm neo, trong khi không có timeout có thể bỏ qua điểm neo.
Trong Shoal, việc tránh thời gian chờ lâu có liên quan chặt chẽ đến danh tiếng của người lãnh đạo. Việc chờ đợi những người lãnh đạo chậm sẽ làm tăng độ trễ, trong khi cơ chế danh tiếng loại trừ những người xác minh chậm được chọn làm lãnh đạo. Như vậy, hệ thống có thể hoạt động với tốc độ mạng trong tất cả các tình huống thực tế.
Cần lưu ý rằng, kết quả không thể của FLP chỉ ra rằng không có giao thức đồng thuận xác định nào có thể hoàn toàn tránh được thời gian chờ. Shoal không thể vượt qua kết quả này, vì về lý thuyết tồn tại các lịch trình sự kiện đối kháng có thể ngăn chặn tất cả các điểm neo được sắp xếp. Ngược lại, sau số lượng điểm neo có thể cấu hình liên tiếp, Shoal sẽ trở lại trạng thái chờ. Nhưng trên thực tế, tình huống này rất khó xảy ra.
) Đáp ứng phổ biến
Bài báo Hotstuff phổ biến khái niệm phản hồi lạc quan, trực quan có nghĩa là giao thức có thể hoạt động với tốc độ mạng ### trong các tình huống tốt, bao gồm lãnh đạo nhanh và mạng đồng bộ (.
Shoal cung cấp một tính năng tốt hơn, được gọi là khả năng phản hồi phổ quát. Cụ thể, so với Hotstuff, ngay cả khi người lãnh đạo thất bại trong một số vòng liên tiếp có thể cấu hình hoặc mạng trải qua các chu kỳ bất đồng bộ, Shoal vẫn tiếp tục hoạt động với tốc độ mạng.
Độ phản hồi phổ biến cung cấp đảm bảo tiến độ tốt hơn đáng kể trong thời gian không đồng bộ và khi có sự cố với người lãnh đạo. Trong thời gian đồng bộ với người lãnh đạo chậm, những đặc điểm này không thể so sánh trực tiếp vì phụ thuộc vào tốc độ của người lãnh đạo. Tuy nhiên, với cơ chế danh tiếng của người lãnh đạo, người lãnh đạo chậm trong Shoal nên hiếm khi xuất hiện.
![Giải thích chi tiết Shoal Framework: Cách giảm