1/x

Chúng tôi tự hào giới thiệu @SuiNetwork: Mysticeti, một cái nhìn sâu sắc vào mô hình đồng thuận mới.

$Sui = Thực thi song song đầu tiên + Đồng thuận nhanh chóng

Và sự phát triển nhanh chóng của $Sui đã được hỗ trợ bởi cơ sở hạ tầng công nghệ vững mạnh.
______
Hãy cùng khám phá lý do tại sao Mysticeti lại hấp dẫn như vậy.

Cảm ơn: Đội ngũ $Sui @EmanAbio @0xAmoghGupta @weiduong @EvanWeb3 @theharrisonkim và những người khác

Cảm ơn: Trưởng nhóm nghiên cứu ContributionDAO và những người khác

______
Nó có vẻ dài nhưng các bạn nên dành thời gian để đọc và tìm nguồn cảm hứng từ nghiên cứu này
______

Mysticeti

Vào tháng 7, $Sui đã công bố việc chuyển đổi từ việc sử dụng Narwhal và Bullshark làm giao thức đồng thuận sang Mysticeti[1]. Trong bài viết này, tôi sẽ cố gắng đơn giản hóa tài liệu về Mysticeti và giải thích cách thức hoạt động của Mysticeti cũng như lý do tại sao nó được chọn từ góc nhìn của tôi, trong khi vẫn giữ nguyên các ý tưởng cốt lõi.

Tóm tắt về Narwhal và Bullshark

Để hiểu rõ nhu cầu về Mysticeti, trước tiên hãy xem xét Narwhal và Bullshark. Nếu bạn quen thuộc với các giao thức này, bạn có thể bỏ qua phần này. Để biết thêm chi tiết, hãy xem các tài liệu tham khảo [2], [3] và [4].
Narwhal và Bullshark là các giao thức đồng thuận dựa trên DAG đã được chứng nhận, được thiết kế để tăng cường thông lượng hệ thống bằng cách tách biệt việc phân phối dữ liệu khỏi logic đồng thuận. Narwhal hoạt động như một lớp mempool, quản lý luồng dữ liệu, trong khi Bullshark xử lý đồng thuận. Các validator diễn giải DAG cục bộ của họ được xây dựng bởi Narwhal mà không cần thêm giao tiếp, có nghĩa là đồng thuận không có chi phí giao tiếp, cải thiện hiệu quả.

Ở mức cao, Narwhal hoạt động như một mempool cho phép mỗi validator phát sóng các thông điệp và xây dựng một cái nhìn cục bộ về DAG. Trong vòng r, mỗi validator phát sóng khối (đỉnh) của mình tới các validator khác. Các yếu tố chính trong mỗi khối như sau:

1. Danh sách các giao dịch,
2. 2f+1 chứng chỉ từ vòng r-1,
3. Chữ ký của validator.

Khi nhận được một khối từ một validator khác, mỗi validator xác minh tính hợp lệ của khối, ký nó và gửi lại cho người gửi gốc. Khi một validator thu thập chữ ký từ 2f+1 validator khác nhau, họ có thể tạo một chứng chỉ cho khối của mình và chia sẻ nó với người khác. Khi một validator nhận được chứng chỉ, họ thêm khối (đỉnh) tương ứng vào DAG cục bộ của họ.
Một validator chuyển sang vòng r+1 sau khi nhận được 2f+1 chứng chỉ. Cấu trúc kết quả hình thành một DAG vì mỗi khối tham chiếu tới 2f+1 khối từ vòng trước, tạo ra các liên kết xây dựng trên các vòng trước.

Hình 1: Cấu trúc DAG dựa trên vòng trong Narwhal

Giờ đây, khi chúng ta có một DAG, chúng ta có thể giải thích nó bằng cách sử dụng Bullshark. Trong Bullshark, một validator cố gắng cam kết các khối sau mỗi hai vòng. Vay mượn từ ví dụ trong [4], một khối lãnh đạo được chọn trong mỗi vòng chẵn để sử dụng cho quy trình cam kết. Ví dụ, các khối của Validator 4 (L2) và Validator 1 (L4) được chọn làm các khối lãnh đạo trong các vòng 2 và 4, tương ứng.

Hình 2: L2 và L4 là lãnh đạo tại vòng 2 và 4, tương ứng, và được tô màu xanh lá cây.

Trong vòng lẻ tiếp theo, các khối bỏ phiếu cho lãnh đạo trong vòng trước, với các tham chiếu phục vụ như các phiếu bầu. Ví dụ, khối lãnh đạo L2 từ vòng 2 nhận được một phiếu bầu vì chỉ có một khối trong vòng 3 tham chiếu đến nó. Theo quy tắc cam kết trực tiếp, nếu một lãnh đạo nhận được nhiều hơn f+1 phiếu bầu, nó và lịch sử nguyên nhân của nó có thể được cam kết. Do đó, L4 có thể được cam kết trực tiếp vì nó nhận được 2 phiếu bầu, trong khi L2 không thể.

Hình 3: Quy tắc cam kết trực tiếp trong Bullshark