Giải thích Monad chuỗi công khai EVM L1 song song: Những tối ưu hóa nào giúp TPS đạt 10.000

Tác giả: Rachit Srivastava, Người xây dựng Avail; Bản dịch: Golden Finance xiaozou

Monad là chuỗi L1 tương thích với EVM, nhưng có một số suy nghĩ lại lớn về các trụ cột cốt lõi của Ethereum. Do đó, Monad có khả năng xử lý tới 10.000 giao dịch mỗi giây. Gần đây Monad đã phát hành devnet của họ.

Nó áp dụng hai khái niệm sau: Pipeline và I/O không đồng bộ. Pipeline là một kỹ thuật để đạt được tính song song bằng cách chia một nhiệm vụ thành một loạt các nhiệm vụ nhỏ hơn có thể được xử lý song song. I/O không đồng bộ là một dạng xử lý đầu vào/đầu ra cho phép CPU thực hiện thực thi đồng thời trong khi quá trình giao tiếp đang diễn ra.

Vậy MonadBFT có gì khác biệt? MonadBFT là thuật toán BFT hai giai đoạn theo đường ống với dạng phản hồi lạc quan, sử dụng chi phí truyền thông tuyến tính trong trường hợp chung và chi phí truyền thông bậc hai trong trường hợp hết thời gian chờ.

Dưới đây chúng tôi giả định rằng tất cả các nút đều có cùng sở thích.

--MonadBFT yêu cầu 2/3 số nút để đạt được sự đồng thuận.

--Người lãnh đạo gửi một khối mới cùng với "QC" hoặc "TC" (Chữ ký ngưỡng là một kỹ thuật mã hóa phân phối khả năng tạo chữ ký số cho nhiều bên. Không một bên nào có thể đại diện cho toàn bộ nhóm để ký, một tập hợp con ("ngưỡng") của các bên phải cộng tác để tạo chữ ký.)

--Người xác nhận xác minh khối và gửi phản hồi Có hoặc Không cho người đứng đầu. Người lãnh đạo lấy được QC (Chứng chỉ đại biểu ) bằng cách tổng hợp phiếu Có và Không (thông qua chữ ký ngưỡng).

--Nếu xác minh không thành công, người xác minh sẽ phát một thông báo hết thời gian chờ đã ký tới tất cả các nút. Thông báo này bao gồm QC cao nhất mà người xác thực quan sát được. Nếu các yêu cầu hết thời gian chờ này được tích lũy bởi bất kỳ trình xác thực nào vượt quá 2/3 số lượng trình xác thực, thì TC (Chứng chỉ hết thời gian chờ) sẽ được tạo và gửi đến người đứng đầu tiếp theo.

--Mỗi người xác thực có thể hoàn thiện khối được đề xuất ở vòng thứ k sau khi nhận được vòng QC k+1.

--Nếu giả định rằng người đứng đầu có hành động ác ý ở vòng k+1, ở vòng k+2, thì ít nhất một người xác nhận sẽ tạo TC cho vòng k+1 và ở vòng k+2. trưởng nhóm sẽ kiểm tra và tạo TC cho vòng này.

Thực thi bị trì hoãn

Trong Ethereum, việc thực thi là điều kiện tiên quyết cho sự đồng thuận, vì vậy khi các nút đồng ý về một khối, họ đồng ý về danh sách các giao dịch trong khối Đồng thuận, tức là sự đồng thuận trên thư mục gốc Merkle tóm tắt tất cả các trạng thái sau khi thực hiện danh sách giao dịch này. Do đó, người đứng đầu phải thực hiện tất cả các giao dịch trong khối được đề xuất trước khi chia sẻ đề xuất và các nút xác thực phải thực hiện các giao dịch này trước khi bỏ phiếu phản hồi.

Như có thể thấy ở trên, sau khi trình tự giao dịch được xác định chính thức, trạng thái thực sự cũng được xác định hoàn toàn. Tiết lộ trạng thái thực sự cần phải thực hiện, nhưng trạng thái thực sự đã được xác định. Đây là cơ sở của tối ưu hóa Monad. Monad tận dụng thông tin chi tiết này và loại bỏ yêu cầu thực thi nút trước khi đạt được sự đồng thuận. Thỏa thuận nút chỉ liên quan đến thứ tự giao dịch chính thức. Mỗi nút thực hiện độc lập các giao dịch trong khối N và bắt đầu đạt được sự đồng thuận về khối N+1.

Cách tiếp cận của Ethereum sử dụng sự đồng thuận để triển khai sao chép máy trạng thái theo một cách rất nghiêm ngặt: sau khi các nút đạt được sự đồng thuận, chúng tôi biết rằng phần lớn các nút đồng ý về thứ tự chính thức và trạng thái được tạo ra bởi thứ tự đó. Monads đã nới lỏng phần nào sự nghiêm khắc này.

--Tính hữu hạn của Monad là một khe duy nhất (1 giây)

--Tính hữu hạn của kết quả thực hiện giao dịch (thành công hay thất bại? Số dư sau đó là bao nhiêu? ) thường là Độ trễ sẽ nhỏ hơn 1 giây trên nút đầy đủ.

--Bất kỳ ai muốn truy vấn kết quả giao dịch một cách an toàn mà không cần chạy nút đầy đủ đều có thể chạy ứng dụng khách nhẹ để truy vấn số dư nút đầy đủ bằng cách sử dụng bằng chứng Merkle. Trong trường hợp này, truy vấn sẽ bị trì hoãn do độ trễ của gốc Merkle.

Chi phí thực hiện

Có một khoản phí để thực hiện các giao dịch mạng theo khối trên mạng. Khoản phí này tách biệt với chi phí thực hiện. Số dư dự trữ được sử dụng để trang trải chi phí vận chuyển. Số dư thực hiện được sử dụng để thanh toán cho việc thực hiện giao dịch.

Thực thi song song

Monad sử dụng thực thi lạc quan. Điều này có nghĩa là Monad sẽ bắt đầu thực hiện các giao dịch trước khi lô giao dịch trước đó trong khối được hoàn thành. Đôi khi (nhưng không phải luôn luôn) điều này dẫn đến lỗi thực thi.

Nếu tất cả các giao dịch phụ thuộc vào giao dịch trước đó, việc thực thi lạc quan sẽ giải quyết vấn đề này bằng cách theo dõi dữ liệu đầu vào được sử dụng khi thực hiện giao dịch 2 và so sánh nó với dữ liệu đầu ra của giao dịch 1.

Nếu hai dữ liệu không nhất quán và chúng tôi phát hiện giao dịch 2 đã sử dụng dữ liệu sai khi thực thi, chúng tôi cần thực hiện lại giao dịch đó bằng dữ liệu chính xác. Khi một Monad thực hiện các giao dịch song song, các cập nhật trạng thái cho mỗi giao dịch sẽ được "hợp nhất" một cách tuần tự.

MonadDb

MonadDb là cơ sở dữ liệu tùy chỉnh được sử dụng để lưu trữ trạng thái blockchain. Hầu hết các máy khách Ethereum đều sử dụng cơ sở dữ liệu khóa-giá trị, được triển khai dưới dạng cấu trúc dữ liệu B-Tree (như LMDB) hoặc LSM-Tree (như LevelDB và RocksDB).

MonadDb triển khai cấu trúc dữ liệu Patricia Trie trên đĩa và trong bộ nhớ. Monad thực hiện nhiều giao dịch song song. Khi một giao dịch cần đọc trạng thái từ đĩa, thay vì đợi thao tác hoàn tất, nó sẽ bắt đầu thao tác đọc và bắt đầu xử lý một giao dịch khác trong thời gian chờ đợi.