
Hướng dẫn nhập môn Monad: Hiểu nhanh về EVM song song và cải thiện hiệu suất
Tuyển chọn TechFlowTuyển chọn TechFlow

Hướng dẫn nhập môn Monad: Hiểu nhanh về EVM song song và cải thiện hiệu suất
Việc thực hiện lại không phải là điểm nghẽn, điểm nghẽn nằm ở việc truy cập bộ nhớ của Ethereum.
Tác giả: Decentralised.Co
Biên dịch: TechFlow
Mở rộng khả năng giao dịch luôn là chủ đề nóng. Trong vài tuần qua, chúng tôi đã tìm hiểu cách Monad hỗ trợ mở rộng TPS.
Dưới đây là bài viết chi tiết của Saurabh Deshpande về cách thức hoạt động của Monad.
TPS là một chỉ số mà chúng tôi rất quan tâm. Chúng tôi muốn chuỗi của mình có thể hỗ trợ TPS cao hơn vì điều đó đồng nghĩa với việc hỗ trợ được nhiều người dùng và ứng dụng hơn. Biểu đồ dưới đây cho thấy con số TPS của Ethereum và các L2. Chưa có chuỗi nào từng vượt qua mốc 100 TPS. Lưu ý rằng TPS là một thuật ngữ chung để đo quy mô. Tuy nhiên, TPS không hoàn toàn chính xác vì không phải tất cả các giao dịch đều giống nhau – chúng khác nhau về độ phức tạp. Nhưng để đơn giản, chúng tôi sử dụng TPS như một thước đo quy mô.

Nếu chúng ta muốn tăng TPS, chúng ta nên làm gì?
-
Phương pháp đầu tiên là xây dựng một hệ thống hoàn toàn mới, giống như Solana đã làm. Họ hy sinh tính tương thích EVM để đổi lấy tốc độ. Họ sử dụng cơ chế thực thi đa luồng thay vì đơn luồng (tưởng tượng như CPU đa nhân so với CPU đơn nhân), thực hiện song song các giao dịch và sử dụng cơ chế đồng thuận khác biệt.
-
Phương pháp thứ hai là thực hiện bên ngoài chuỗi (off-chain execution) và sử dụng bộ sắp xếp tập trung để mở rộng Ethereum.
-
Phương pháp thứ ba là tách EVM thành các thành phần riêng biệt và tối ưu hóa từng phần để nâng cao khả năng mở rộng.
Monad là một L1 mới tương thích EVM, gần đây đã huy động được 225 triệu USD, đang xây dựng lại EVM từ đầu thay vì sử dụng trực tiếp EVM hiện tại. Nó chọn phương pháp thứ ba này để cải thiện khả năng mở rộng.
Chúng tôi sẽ thảo luận về một số thay đổi lớn mà Monad mang lại.
Thực thi song song
Máy ảo Ethereum (EVM) thực thi các giao dịch theo trình tự. Trước khi thực thi một giao dịch, giao dịch kế tiếp phải chờ đợi. Hãy hình dung như sau: Giả sử trong một xưởng lắp ráp xe máy có một bến đỗ duy nhất. Nhiều xe tải vận chuyển các bộ phận xe máy đến (mỗi xe tải chở đủ linh kiện để lắp ráp 50 xe máy). Xưởng thực hiện bốn chức năng khác nhau: dỡ hàng, phân loại, lắp ráp và chất hàng.

Trong thiết lập EVM hiện tại, chỉ có một bến đỗ duy nhất và việc chất/dỡ hàng diễn ra tại cùng một vị trí. Do đó, khi xe tải vào đỗ, các bộ phận xe máy được dỡ xuống, phân loại, lắp ráp rồi chất lại lên cùng xe tải đó. Khi đội phân loại đang làm việc, các đội khác đều phải chờ. Nếu coi công việc của họ là các khe thời gian khác nhau, mỗi đội chỉ làm việc một lần trong bốn khe. Điều này dẫn đến sự kém hiệu quả rõ rệt, cho thấy nhu cầu cần một phương pháp mượt mà hơn.
Bây giờ hãy tưởng tượng có bốn bến đỗ riêng biệt với khu vực chất/dỡ hàng khác nhau. Dù đội dỡ hàng mỗi lúc chỉ làm việc với một xe tải, nhưng họ không cần phải chờ ba khe còn lại. Sau khi dỡ xong, họ có thể chuyển ngay sang xe tải tiếp theo.
Các đội phân loại, lắp ráp và chất hàng cũng vậy. Ngay khi dỡ hàng xong, xe tải di chuyển đến khu vực chất hàng để chờ đội chất hàng đưa xe máy đã lắp ráp lên. Vì vậy, kho hàng với một bến duy nhất và khu chất/dỡ chung sẽ thực hiện mọi việc theo trình tự, trong khi kho hàng với 4 bến và khu vực riêng biệt có thể thực hiện song song.

Hãy coi Monad như cơ sở hạ tầng tương đương với một kho hàng có nhiều bến xe tải. Nhưng không đơn giản như vậy. Sự phức tạp gia tăng khi các xe tải phụ thuộc lẫn nhau. Ví dụ, nếu một xe tải không có đầy đủ linh kiện để lắp 50 xe máy thì sao? Các giao dịch cũng không phải lúc nào cũng độc lập. Do đó, khi Monad thực thi song song, nó phải xử lý những giao dịch phụ thuộc lẫn nhau.
Vậy làm thế nào? Nó sử dụng một phương pháp gọi là "thực thi song song lạc quan". Giao thức chỉ có thể thực thi song song các giao dịch độc lập. Ví dụ, xét 4 giao dịch sau, với số dư ban đầu của Joel là 1 ETH:
-
Joel gửi 0,2 ETH cho Saurabh
-
Sid tạo một NFT
-
Joel gửi 0,1 ETH cho Sid
-
Shlok mua PEPE
Tất cả các giao dịch này được thực thi song song, các kết quả tạm thời được nộp lần lượt. Nếu đầu ra của kết quả tạm thời xung đột với đầu vào gốc của bất kỳ giao dịch nào, giao dịch đó sẽ được thực thi lại. Giao dịch 2 và 4 không có xung đột vì chúng độc lập với nhau. Nhưng giao dịch 1 và 3 lại không độc lập.
Lưu ý rằng do cả 4 giao dịch đều bắt đầu từ cùng một trạng thái (số dư Joel là 1 ETH). Sau khi Joel gửi đi 0,2 ETH, số dư còn lại là 0,8 ETH. Sau khi Joel gửi thêm 0,1 ETH cho Sid, số dư sẽ là 0,9 ETH. Các kết quả tạm thời được nộp lần lượt để đảm bảo đầu ra không xung đột với đầu vào nào. Sau khi nộp kết quả tạm thời của giao dịch 1, số dư mới của Joel là 0,8 ETH.
Kết quả này xung đột với đầu vào của giao dịch 3. Do đó, giao dịch 3 phải được thực thi lại với đầu vào là 0,8 ETH. Sau khi thực thi xong, số dư của Joel còn 0,7 ETH.
MonadDb

Tại thời điểm này, một câu hỏi hiển nhiên đặt ra là: Làm thế nào để biết rằng chúng ta không cần thực thi lại phần lớn các giao dịch? Câu trả lời nằm ở chỗ việc thực thi lại không phải là điểm nghẽn. Điểm nghẽn thực sự là việc truy cập bộ nhớ của Ethereum. Hóa ra, cách Ethereum lưu trữ trạng thái trong cơ sở dữ liệu khiến việc truy cập trở nên khó khăn (tốn thời gian và do đó tốn kém). Đây chính là cải tiến khác của Monad: MonadDb. Cách Monad xây dựng cơ sở dữ liệu giúp giảm đáng kể chi phí liên quan đến các thao tác đọc.
Khi một giao dịch cần thực thi lại, mọi đầu vào đã có sẵn trong bộ nhớ đệm, nơi dễ truy cập hơn nhiều so với toàn bộ trạng thái.
Solana đạt 50k TPS trên mạng thử nghiệm, nhưng hiện tại trên mainnet chỉ khoảng 1k TPS. Monad tuyên bố đã đạt được 10k TPS thực tế trên mạng thử nghiệm nội bộ. Mặc dù điều này chưa chắc phản ánh đúng hiệu suất thực tế, nhưng chúng tôi háo hức chờ xem Monad sẽ thể hiện như thế nào trong thực tiễn.
Chào mừng tham gia cộng đồng chính thức TechFlow
Nhóm Telegram:https://t.me/TechFlowDaily
Tài khoản Twitter chính thức:https://x.com/TechFlowPost
Tài khoản Twitter tiếng Anh:https://x.com/BlockFlow_News














