Khung Shoal thả Aptos Bullshark trễ 40%-80%

Khung Shoal: Thả đáng kể độ trễ Bullshark trên Aptos

Aptos Labs gần đây đã 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. Nhìn chung, 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%.

Shoal là một khung, thông qua pipeline và uy tín của người dẫn đầu để 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 ). Pipeline 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, uy tín của người dẫn đầu cải thiện thêm độ trễ bằng cách đảm bảo điểm neo liên kết với các nút xác thực nhanh nhất. Hơn nữa, uy tín của người dẫn đầu cho phép Shoal tận dụng cấu trúc DAG bất đồng bộ để loại bỏ thời gian chờ trong tất cả các tình huống. Điều này cho phép Shoal cung cấp cái gọi là phản hồi phổ quát, bao gồm phản hồi lạc quan thường cần thiết.

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

Giải thích chi tiết khung Shoal: Làm thế nào để giảm thiểu trễ Bullshark trên Aptos?

Động cơ

Trong việc theo đuổi hiệu suất cao của mạng blockchain, mọi người luôn quan tâm đến việc Thả độ phức tạp giao tiếp. Tuy nhiên, phương pháp này không dẫn đến việc gia tăng đáng kể 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 rất nhiều so với mục tiêu 100k+ TPS mà chúng tôi đạt được.

Sự đột phá gần đây bắt nguồn từ việc nhận thức rằng việc truyền dữ liệu là nút thắt cổ chai 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ớ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 đồng thời truyền dữ liệu, thành phần đồng thuận chỉ sắp xếp một lượng nhỏ siêu dữ liệu. Bài báo Narwhal báo cáo thông lượng 160,000 TPS.

Trong bài viết trước, chúng tôi đã giới thiệu Quorum Store. Triển khai Narwhal của chúng tôi tách biệt việc truyền dữ liệu và đồng thuận, cũng như cách 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 đường dẫn nhanh tuyến tính của Tendermint và sự thay đổi góc nhìn theo phong cách PBFT, có thể Thả độ trễ của Hotstuff xuống 33%. Tuy nhiên, rõ ràng là các giao thức đồng thuận dựa trên lãnh đạo không thể tận dụng đầy đủ tiềm năng thông lượng của Narwhal. Mặc dù việc truyền dữ liệu và đồng thuận được tách biệt, nhưng với việc tăng thông lượng, 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, một giao thức đồng thuận không tốn chi phí truyền thông, trên Narwhal DAG. Thật không may, cấu trúc DAG hỗ trợ Bullshark với thông lượng cao so với Jolteon đã mang lại chi phí trễ 50%.

Bài viết này giới thiệu cách Shoal thực hiện việc thả trễ Bullshark.

Giải thích chi tiết về khung Shoal: Làm thế nào để thả độ trễ Bullshark trên Aptos?

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 r, các xác thực viên phải trước tiên nhận được n-f đỉnh thuộc vòng r-1. Mỗi xác thực viên có thể phát sóng một đỉnh trong 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 xác thực viên khác nhau có thể quan sát các cái nhìn địa phương khác nhau của DAG vào 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 chế độ xem địa phương của DAG của chúng, thì chúng có lịch sử nguyên nhân v hoàn toàn giống nhau.

Giải thích chi tiết về khung Shoal: Làm thế nào để giảm trễ Bullshark trên Aptos?

Tổng序

Có thể đạt được sự đồng thuận về thứ tự tổng thể của tất cả các đỉnh trong DAG mà không có chi phí truyền thông 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 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 của các 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: cứ sau vài vòng ( ví dụ, trong Bullshark có hai vòng ) sẽ có một nhà lãnh đạo được xác định trước, đỉnh của nhà lãnh đạo được gọi là điểm neo;

  2. Điểm neo sắp xếp: Các xác thực độc lập nhưng quyết định một cách chắc chắn việc sắp xếp những điểm neo nào và bỏ qua những điểm neo nào;

  3. Sắp xếp lịch sử nguyên nhân: Các xác nhận viên xử lý từng đ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ó theo một số quy tắc xác định.

Điều quan trọng để đảm bảo an ninh là đảm bảo rằng trong bước (2), tất cả các nút xác thực trung thực tạo ra một danh sách điểm neo có thứ tự, để tất cả danh sách chia sẻ cùng một tiền tố. Trong Shoal, chúng tôi có những quan sát sau về tất cả các giao thức trên:

Tất cả các validator đều đồng ý với điểm neo đầu tiên theo thứ tự.

Bullshark Trễ

Độ trễ của Bullshark phụ thuộc vào số vòng giữa các điểm neo có thứ tự trong DAG. Mặc dù phiên bản đồng bộ của Bullshark có độ trễ tốt hơn phiên bản bất đồng bộ, nhưng vẫn chưa phải là tốt nhất.

Vấn đề 1: Trễ khối trung bình. Trong Bullshark, mỗi vòng chẵn có một điểm neo, và đỉnh trong mỗi vòng lẻ được giải thích là phiếu bầu. Trong các 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 các 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 anchor trong vòng chẵn cần bốn vòng.

Vấn đề 2: Trễ trong trường hợp lỗi. Phân tích trễ trên áp dụng cho trường hợp không có lỗi, mặt khác, nếu nhà lãnh đạo của một vòng không phát sóng điểm neo đủ nhanh, thì không thể sắp xếp điểm neo ( do đó bị bỏ qua ), vì vậy tất cả các đỉnh chưa được sắp xếp trong vài vòng trước phải chờ điểm neo tiếp theo được sắp xếp. Điều này sẽ làm giảm hiệu suất của mạng sao chép địa lý một cách đáng kể, đặc biệt là vì Bullshark sử dụng thời gian chờ để chờ nhà lãnh đạo.

Giải thích chi tiết Shoal framework: Làm thế nào để giảm trễ Bullshark trên Aptos?

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 pipeline, cho phép có một điểm neo trong mỗi vòng và giảm độ trễ của tất cả các đỉnh không phải 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 làm cho việc lựa chọn thiên về lãnh đạo nhanh.

Thách thức

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

  1. Các nỗ lực trước đây của dây chuyền sản xuất đã cố gắng sửa đổi logic cốt lõi của Bullshark, nhưng về bản chất dường như điều này là không thể.

  2. Danh tiếng của lãnh đạo được đưa vào DiemBFT và chính thức hóa trong Carousel, được lựa chọn một cách động cho các lãnh đạo tương lai dựa trên hiệu suất trong quá khứ của các xác nhận viên trong (Bullshark và ý tưởng về neo ). Mặc dù có sự khác biệt về danh tính lãnh đạo không vi phạm tính an toàn trong các giao thức này, nhưng trong Bullshark, điều này có thể dẫn đến sắp xếp hoàn toàn khác, đưa ra vấn đề cốt lõi, đó là việc chọn neo vòng một cách động và xác định là cần thiết để giải quyết sự đồng thuận, trong khi các xác nhận viên cần đạt được sự đồng thuận về lịch sử có thứ tự để chọn neo tương lai.

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

Giao thức

Mặc dù có những thách thức nêu trên, nhưng sự thật là 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 của những vòng 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 theo thứ 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 tiếp của các phiên bản, cũng như ) 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.

Giải thích chi tiết về khung Shoal: Làm thế nào để giảm trễ Bullshark trên Aptos?

Dòng chảy

V ánh xạ các vòng vào người lãnh đạo. Shoal chạy từng instance của Bullshark, để cho mỗi instance, điểm neo được xác định trước bởi ánh xạ F. Mỗi instance đặt hàng một điểm neo, điều này sẽ kích hoạt chuyển sang instance 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ó trật 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 trường hợp tốt nhất, điều này cho phép Shoal đặt hàng một cái neo trong mỗi vòng. Các điểm neo của vòng đầu tiên được sắp xếp theo các thể hiện đầu tiên. Sau đó, Shoal bắt đầu một thể hiện mới trong vòng thứ hai, nó có một điểm neo, cái neo được sắp xếp bởi thể hiện đó, sau đó, một thể hiện mới khác đặt hàng điểm neo trong vòng thứ ba, và sau đó quá trình này tiếp tục.

Giải thích chi tiết Shoal framework: Làm thế nào để giảm trễ Bullshark trên Aptos?

Danh tiếng của nhà lãnh đạo

Trong thời gian sắp xếp Bullshark, khi bỏ qua các điểm neo, Trễ sẽ tăng lên. Trong trường hợp này, công nghệ đường ống không thể làm gì, vì không thể khởi động một phiên bản mới trước khi điểm neo của phiên bản trước đó được đặt hàng. Shoal đảm bảo rằng khả năng chọn lãnh đạo tương ứng để xử lý các điểm neo bị mất trong tương lai là ít khả năng xảy ra hơn bằng cách sử dụng cơ chế tín nhiệm để 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 từng nút xác thực. 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 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ì nó có thể bị sập, chậm hoặc có hành vi xấu.

Ý tưởng 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ạ đã được định nghĩa trước F 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. Để cho các xác thực viên đạt được sự đồng thuận trên ánh xạ mới, họ cần đồng thuận trên điểm số, từ đó đạt được sự đồng thuận trong lịch sử được sử dụng để sinh ra điểm số.

Trong Shoal, pipeline 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 ở vòng thứ r, các xác nhận viên 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 nhận sẽ bắt đầu từ vòng thứ r+1 sử dụng hàm lựa chọn điểm neo được cập nhật F' để thực hiện một instance mới của Bullshark.

Giải thích chi tiết Shoal framework: Làm thế nào để giảm trễ Bullshark trên Aptos?

Không còn thời gian chờ

Thời gian quá hạn đóng vai trò quan trọng trong tất cả các triển khai BFT đồng bộ phần dựa trên leader. Tuy nhiên, sự phức tạp mà chúng gây ra 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.

Timeout cũng sẽ làm tăng đáng kể Trễ, vì việc cấu hình chúng một cách thích hợp rất quan trọng, và thường cần phải điều chỉnh động, vì nó phụ thuộc cao 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ễ timeout cho nhà lãnh đạo gặp sự cố. Do đó, việc thiết lập timeout không thể quá bảo thủ, nhưng nếu thời gian timeout quá ngắn, giao thức có thể bỏ qua nhà lãnh đạo tốt. Ví dụ, chúng tôi đã quan sát thấy, trong điều kiện tải cao, Jolteon/

Xem bản gốc
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.
  • Phần thưởng
  • 5
  • Chia sẻ
Bình luận
0/400
BlockchainFriesvip
· 07-21 02:44
Chờ đã, 40% còn 80% chắc chắn không phải đang vẽ bánh chứ?
Xem bản gốcTrả lời0
YouMustMakeBigMoneyEveryvip
· 07-20 12:23
Còn chưa đẩy mạnh. Quá tệ. Phá vỡ 6 nhân tăng vị thế
Xem bản gốcTrả lời0
HalfBuddhaMoneyvip
· 07-20 09:59
Trễ giảm nhiều như vậy, aptos đáng mong đợi quá.
Xem bản gốcTrả lời0
SleepyArbCatvip
· 07-20 09:58
Ngày này sắp sáng rồi, aptos cuối cùng cũng đẩy mạnh rồi kìa... Trễ mà thấp hơn chút nữa thì có thể ăn cơm miễn phí rồi.
Xem bản gốcTrả lời0
GasFeeCryingvip
· 07-20 09:55
Trễ giảm 40, đợt này ổn rồi.
Xem bản gốcTrả lời0
  • Ghim
Giao dịch tiền điện tử mọi lúc mọi nơi
qrCode
Quét để tải xuống ứng dụng Gate
Cộng đồng
Tiếng Việt
  • 简体中文
  • English
  • Tiếng Việt
  • 繁體中文
  • Español
  • Русский
  • Français (Afrique)
  • Português (Portugal)
  • Bahasa Indonesia
  • 日本語
  • بالعربية
  • Українська
  • Português (Brasil)