Nguồn: ASXN; Biên dịch bởi: Jinse Finance xiaozou
1. Giới thiệu
Monad là L1 tương thích với EVM được tối ưu hóa hiệu suất cao với 10.000 TPS (1 tỷ gas mỗi giây), tần số khối 500 mili giây và độ trễ 1 giây. Chuỗi này được xây dựng từ đầu để giải quyết một số vấn đề mà EVM gặp phải, cụ thể:
*EVM xử lý các giao dịch theo trình tự, gây ra tình trạng tắc nghẽn trong thời gian mạng hoạt động cao, do đó kéo dài thời gian giao dịch, đặc biệt là trong thời gian mạng bị tắc nghẽn.
* Thông lượng thấp, chỉ 12-15 TPS và thời gian chặn dài là 12 giây.
*EVM yêu cầu phải trả phí gas cho mỗi giao dịch và mức phí này dao động rất lớn, đặc biệt khi nhu cầu mạng cao, phí gas có thể trở nên cực kỳ đắt đỏ.
2. Tại sao phải mở rộng EVM?
Monad cung cấp khả năng tương thích hoàn toàn với EVM bytecode và Ethereum RPC API, cho phép các nhà phát triển và người dùng tích hợp mà không cần thay đổi quy trình làm việc hiện tại của họ.
Một câu hỏi thường gặp là tại sao phải mở rộng EVM khi có những giải pháp thay thế hiệu quả hơn như SVM. SVM cung cấp thời gian xử lý khối nhanh hơn, phí thấp hơn và thông lượng cao hơn so với hầu hết các triển khai EVM. Tuy nhiên, EVM có một số lợi thế quan trọng xuất phát từ hai yếu tố chính: lượng lớn trong hệ sinh thái EVM và nguồn lực phát triển dồi dào.
(1) Cơ sở vốn
EVM có giá trị vốn hóa lượng lớn, Ethereum đạt gần 52 tỷ đô la và Solana là 7 tỷ đô la. Các L2 như Arbitrum và Base mỗi công ty nắm giữ khoảng 2,5-3 tỷ đô la TVL. Monad và Chuỗi tương thích EVM khác có thể được hưởng lợi từ nguồn vốn lớn trên Chuỗi EVM thông qua các cầu nối chuẩn và cầu nối của bên thứ ba tích hợp với ít ma sát nhất. Cơ sở vốn EVM lớn này tương đối năng động và có thể thu hút người dùng và nhà phát triển vì:
* Người dùng thích thanh khoản và khối lượng giao dịch cao.
Các nhà phát triển đang tìm kiếm khối lượng giao dịch cao, mức phí cao và khả năng hiển thị trong ứng dụng của họ.
(2) Tài nguyên dành cho nhà phát triển
Các công cụ và nghiên cứu mật mã ứng dụng của Ethereum tích hợp trực tiếp vào Monad, đồng thời đạt được thông lượng và quy mô cao hơn thông qua:
*ứng dụng
* Công cụ dành cho nhà phát triển (Hardhat, Apeworx, Foundry)
*Ví (Rabby, Metamask, Phantom)
*Phân tích/Chỉ số (Etherscan, Dune)
Báo cáo dành cho nhà phát triển của Electric Capital cho thấy tính đến tháng 7 năm 2024, Ethereum sẽ có 2.788 nhà phát triển toàn thời gian, Base sẽ có 889 và Polygon sẽ có 834. Solana xếp thứ bảy với 664 nhà phát triển, sau Polkadot, Arbitrum và Cosmos. Trong khi một số người cho rằng tổng số nhà phát triển trong lĩnh vực crypto vẫn còn nhỏ và do đó nên bỏ qua phần lớn (nên tập trung nguồn lực vào việc thu hút nhân tài bên ngoài), thì rõ ràng là có lượng lớn nhân tài EVM trong nhóm "nhỏ" các nhà phát triển crypto . Ngoài ra, vì hầu hết nhân tài đều làm việc trong EVM và hầu hết các công cụ đều nằm trong EVM nên các nhà phát triển mới có thể sẽ phải hoặc lựa chọn học và phát triển trong EVM. Như Keone đã đề cập trong một cuộc phỏng vấn, các nhà phát triển có thể lựa chọn:
* Xây dựng các ứng dụng di động cho EVM, cho phép triển khai đa chuỗi, nhưng với thông lượng hạn chế và phí cao
*Xây dựng các ứng dụng hiệu suất cao và chi phí thấp trong một hệ sinh thái cụ thể như Solana, Aptos hoặc Sui.
Monad được thiết kế để kết hợp hai phương pháp này. Vì hầu hết các công cụ và tài nguyên đều được thiết kế riêng cho EVM nên các ứng dụng được phát triển trong hệ sinh thái của nó có thể được chuyển đổi liền mạch. Kết hợp với hiệu suất và hiệu quả tương đối của nó — nhờ vào khả năng tối ưu hóa monad — EVM rõ ràng là một rào cản cạnh tranh mạnh mẽ.
Ngoài các nhà phát triển, người dùng cũng thích quy trình làm việc quen thuộc. Thông qua các công cụ như Rabby, MetaMask và Etherscan, quy trình làm việc EVM đã trở thành tiêu chuẩn. Các nền tảng trưởng thành này tạo điều kiện thuận lợi cho tích hợp các cầu nối và giao thức. Ngoài ra, các ứng dụng cơ bản (AMM, thị trường tiền tệ, cầu nối) có thể được khởi chạy ngay lập tức. Những nguyên lý cơ bản này rất quan trọng đối với tính bền vững của Chuỗi cũng như các ứng dụng mới.
3. Mở rộng EVM
Có hai phương pháp chính mở rộng EVM:
* Di chuyển thực thi ra khỏi Chuỗi: chuyển tải thực thi sang các máy ảo khác thông qua rollups, sử dụng kiến trúc mô-đun .
* Cải thiện hiệu suất: Cải thiện hiệu suất của Chuỗi cơ sở EVM thông qua tối ưu hóa sự đồng thuận và tăng kích thước khối và giới hạn gas .
(1) Kiến trúc cuộn và mô-đun
Vitalik đã giới thiệu rollups vào tháng 10 năm 2020 như là giải pháp mở rộng chính của Ethereum , phù hợp với các nguyên tắc blockchain mô-đun . Do đó, lộ trình mở rộng của Ethereum chuyển giao việc thực hiện cho các rollup, là các máy ảo ngoài Chuỗi tận dụng tính bảo mật Ethereum . Rollup có khả năng thực hiện vượt trội, với thông lượng cao hơn, độ trễ thấp hơn và chi phí giao dịch thấp hơn. Chu kỳ phát triển lặp đi lặp lại của chúng ngắn hơn Ethereum— các bản cập nhật mất nhiều năm trên Ethereum có thể chỉ mất vài tháng trên bản phát hành chung vì chi phí và tổn thất tiềm ẩn thấp hơn.
Rollup có thể hoạt động bằng cách sử dụng sắp xếp tập trung trong khi vẫn duy trì các cửa thoát hiểm giúp chúng vượt qua một số yêu cầu phi tập trung. Điều quan trọng cần lưu ý là nhiều đợt triển khai (bao gồm Arbitrum , Base và OP Mainnet) vẫn đang trong giai đoạn đầu (Giai đoạn 0 hoặc Giai đoạn 1). Trong đợt triển khai Giai đoạn 1, việc gửi bằng chứng gian lận chỉ giới hạn cho những người tham gia được liệt kê trong danh sách trắng và nâng cấp không liên quan đến lỗi có thể chứng minh Chuỗi phải cung cấp cho người dùng thời hạn thoát ít nhất là 30 ngày. Bản cập nhật Giai đoạn 0 cung cấp cho người dùng thời gian chưa đầy 7 ngày để thoát trong trường hợp ngừng hoạt động hoặc bị kiểm duyệt bởi nhà điều hành được cấp phép.
Trong Ethereum, kích thước giao dịch điển hình là 156 byte, trong đó chữ ký chứa nhiều dữ liệu nhất. Rollup cho phép gộp nhiều giao dịch lại với nhau, giúp giảm tổng quy mô giao dịch và tối ưu hóa chi phí gas. Nói tóm lại, rollup đạt được hiệu quả bằng cách gom nhiều giao dịch thành lần và gửi chúng đến mạng chủ Ethereum . Điều này làm giảm quá trình xử lý dữ liệu Chuỗi nhưng lại làm tăng tính phức tạp trong hệ sinh thái vì các kết nối tổng hợp đòi hỏi các yêu cầu về cơ sở hạ tầng mới. Ngoài ra, bản rollup cũng áp dụng kiến trúc mô-đun , chuyển hoạt động thực thi sang L3 để giải quyết những hạn chế về thông lượng rollup cơ bản, đặc biệt là đối với các ứng dụng chơi game.
Mặc dù về mặt lý thuyết, rollup sẽ loại bỏ tình trạng bắc cầu và phân mảnh thanh khoản bằng cách trở thành một Chuỗi hoàn chỉnh trên Ethereum , nhưng các triển khai hiện tại vẫn chưa phải là Chuỗi“hoàn chỉnh” hoàn toàn. Ba dự án lớn nhất của TVL — Arbitrum, OP Mainnet và Base — duy trì các hệ sinh thái và nhóm người dùng khác nhau, mỗi dự án đều xuất sắc trong một số lĩnh vực nhất định nhưng không cung cấp giải pháp toàn diện.
Tóm lại, người dùng phải truy cập nhiều Chuỗi khác nhau để có được trải nghiệm tương tự như khi sử dụng một Chuỗi duy nhất (chẳng hạn như Solana ). Việc thiếu trạng thái chia sẻ thống nhất trong hệ sinh thái Ethereum(một trong những đề xuất cốt lõi của blockchain) hạn chế rất nhiều các trường hợp sử dụng Chuỗi- đặc biệt là vì các khối cạnh tranh không thể dễ dàng hiểu được trạng thái của nhau do tính phân mảnh của thanh khoản và trạng thái. Sự phân mảnh trạng thái cũng mang lại nhu cầu bổ sung về các cầu nối và giao thức nhắn tin chuỗi Chuỗi có thể kết nối các bản tổng hợp và trạng thái với nhau, nhưng đi kèm với một số sự đánh đổi. Blockchain không gặp phải những vấn đề phân mảnh này vì chỉ có một sổ cái duy nhất ghi lại trạng thái.
Mỗi bản cập nhật có phương pháp khác nhau về mặt tối ưu hóa và tập trung vào lĩnh vực cụ thể của nó. Optimism giới thiệu mô-đun bổ sung thông qua Superchain và do đó dựa vào các L2 khác để xây dựng bằng cách sử dụng ngăn xếp của mình và cạnh tranh để thu phí. Arbitrum chủ yếu tập trung vào DeFi, cụ thể là sàn giao dịch quyền chọn và vĩnh viễn, đồng thời mở rộng sang L3 với Xai và Sanko. Các giải pháp tổng hợp hiệu suất cao mới như MegaETH và Base đã xuất hiện với khả năng xử lý thông lượng cao hơn nhằm mục đích cung cấp một Chuỗi lớn duy nhất. MegaETH vẫn chưa được ra mắt và Base rất ấn tượng về mặt triển khai, nhưng vẫn còn thiếu sót ở một số khía cạnh, bao gồm giao dịch phái sinh(quyền chọn và hợp đồng vĩnh viễn) và DePIN.
(2) Mở rộng L2 sớm
Optimism và Arbitrum
Thế hệ L2 đầu tiên cung cấp khả năng thực thi được cải thiện so với Ethereum nhưng vẫn chậm hơn các giải pháp siêu tối ưu mới hơn. Ví dụ, Arbitrum xử lý 37,5 giao dịch mỗi giây (“TPS”) và Optimism Mainnet xử lý 11 TPS. Trong khi đó, Base là khoảng 80 TPS, MegaETH đang nhắm tới 100.000 TPS, BNB Chain là 65,1 TPS và Monad đang nhắm tới 10.000 TPS.
Trong khi Mainnet Arbitrum và Optimism không thể hỗ trợ các ứng dụng có thông lượng cực cao như sổ lệnh hoàn toàn trên Chuỗi , chúng có mở rộng thông qua các lớp Chuỗi bổ sung — L3 cho Arbitrum và Chuỗi cho Optimism — và sắp xếp tập trung.
Arbitrum, tập trung vào L3, Xai và Proof of Play cho trò chơi, đã chứng minh phương pháp này. Chúng được xây dựng trên nền tảng Arbitrum Orbit và quyết toán trên Arbitrum bằng cách sử dụng tính khả dụng dữ liệu AnyTrust. Xai đạt 67,5 TPS, trong khi Proof of Play Apex đạt 12,2 TPS và Proof of Play Boss là 10 TPS. Các L3 này đưa ra các giả định tin cậy bổ sung thông qua quyết toán Arbitrum , trái ngược với mạng chủ Ethereum , đồng thời phải đối mặt với những thách thức tiềm ẩn của lớp khả dụng dữ liệu ít phi tập trung hơn. Các L2 của Optimism — Base, Blast và Unichain sắp ra mắt — duy trì tính bảo mật mạnh mẽ hơn thông qua quyết toán Ethereum và tính khả dụng của dữ liệu blob.
Cả hai mạng đều ưu tiên mở rộng theo chiều ngang. Optimism cung cấp cơ sở hạ tầng L2, hỗ trợ triển khai Chuỗi và các cầu nối chia sẻ có khả năng tương tác thông qua OP Stack. Arbitrum chuyển giao các trường hợp sử dụng cụ thể cho L3, đặc biệt là các ứng dụng trò chơi trong đó giả định về độ tin cậy bổ sung có rủi ro vốn thấp hơn so với các ứng dụng tài chính.
(3) Tối ưu hóa hiệu suất Chuỗi và EVM
Phương pháp mở rộng thay thế tập trung vào việc thực hiện tối ưu hóa hoặc nhắm mục tiêu vào sự đánh đổi để tăng thông lượng và TPS bằng cách mở rộng theo chiều dọc thay vì theo chiều ngang. Base, MegaETH, Avalanche và BNB Chain là hiện thân của chiến lược này.
Base Base công bố kế hoạch đạt mục tiêu 1 Ggas/s bằng cách tăng dần mục tiêu gas. Vào tháng 9, họ nâng mục tiêu lên 11 Mgas/giây và tăng giới hạn gas lên 33 Mgas. Khối ban đầu xử lý 258 giao dịch và duy trì khoảng 70 TPS trong năm giờ. Đến ngày 18 tháng 12, mục tiêu gas đạt 20 Mgas/s, thời gian khối là 2 giây và mỗi khối hỗ trợ 40M gas. Trong khi đó, Arbitrum là 7 Mgas/s và OP Mainnet là 2,5 Mgas/s.
Base đã nổi lên như một đối thủ cạnh tranh của Solana và Chuỗi có năng suất cao khác. Tính đến điểm hiện tại, Base đã vượt qua các L2 khác về mặt hoạt động, như được chứng minh bởi:
* Tính đến tháng 1 năm 2025, phí hàng tháng của nền tảng này đạt 15,6 triệu đô la - gấp 7,5 lần so với Arbitrum và gấp 23 lần so với OP Mainnet.
* Tính đến tháng 1 năm 2025, khối lượng giao dịch tích lũy của nó đạt 329,7 triệu, gấp 6 lần Arbitrum(57,9 triệu) và gấp 14 lần OP Mainnet (24,5 triệu). LƯU Ý: Âm lượng có thể bị thay đổi và có thể gây hiểu lầm.
Đội ngũ Base tập trung vào việc cung cấp trải nghiệm thống nhất hơn bằng cách tối ưu hóa tốc độ, thông lượng và mức phí thấp, trái ngược với phương pháp mô-đun của Arbitrum và Optimism . Người dùng đang thể hiện sự ưu tiên cho trải nghiệm thống nhất hơn, điều này được thể hiện qua số liệu hoạt động và thu nhập của Base. Ngoài ra, sự hỗ trợ và phân phối của Coinbase cũng rất hữu ích.
MegaETH
MegaETH là L2 tương thích với EVM. Về cơ bản, các giao dịch được xử lý thông qua kiến trúc kết hợp sử dụng nút sắp xếp chuyên dụng. MegaETH tách biệt nhiệm vụ về hiệu suất và bảo mật trong kiến trúc của mình, kết hợp với hệ thống quản lý trạng thái mới thay thế Merkle Patricia Trie truyền thống để giảm thiểu các hoạt động I/O đĩa.
Hệ thống xử lý 100.000 giao dịch mỗi giây với độ trễ dưới một phần nghìn giây trong khi vẫn duy trì khả năng tương thích EVM hoàn toàn và khả năng xử lý hàng terabyte dữ liệu trạng thái. MegaETH sử dụng EigenDA để đảm bảo tính khả dụng dữ liệu, phân phối chức năng trên ba loại nút chuyên biệt:
* Sắp xếp: Một nút đơn hiệu suất cao (100 lõi, RAM 1-4TB) quản lý sắp xếp và thực hiện giao dịch, lưu giữ trạng thái trong RAM để truy cập nhanh. Nó tạo ra các khối với khoảng cách khoảng 10 mili giây, chứng kiến xác thực khối và theo dõi sự khác biệt về trạng thái khi trạng thái blockchain thay đổi. Sắp xếp đạt hiệu suất cao thông qua thực thi EVM song song và hỗ trợ ưu tiên, không có chi phí đồng thuận trong quá trình hoạt động bình thường.
* Provers: Nút nhẹ này (1 lõi, RAM 0,5 GB) tính toán các bằng chứng crypto để xác minh nội dung khối. Họ xác thực các khối không đồng bộ và không theo thứ tự, sử dụng xác thực không trạng thái, mở rộng mở rộng và tạo bằng chứng cho xác thực toàn bộ nút. Hệ thống hỗ trợ chống gian lận và không cần thông tin.
* Full Nút: Chạy trên phần cứng vừa phải (4-8 lõi, RAM 16GB), full nút kết nối prover, sắp xếp và EigenDA. Chúng xử lý các khác biệt về trạng thái được nén qua mạng ngang hàng, áp dụng các khác biệt mà không cần thực hiện lại giao dịch, xác minh các khối bằng cách sử dụng bằng chứng do trình chứng minh tạo ra, duy trì gốc trạng thái bằng cách sử dụng Merkle Patricia Trie được tối ưu hóa và hỗ trợ đồng bộ hóa nén 19 lần.
(4) Các vấn đề với Rollups
Monad về cơ bản khác với rollup và những đánh đổi vốn có của chúng. Hầu hết các hoạt động tổng hợp ngày nay đều dựa vào một sắp xếp tập trung, mặc dù các giải pháp sắp xếp chia sẻ và phi tập trung đang được phát triển. Việc tập trung sắp xếp và bộ đề xuất gây ra lỗ hổng trong hoạt động. Việc kiểm soát bởi một thực thể duy nhất có thể dẫn đến các vấn đề về tính sống động và giảm khả năng chống kiểm duyệt. Mặc dù có các cửa thoát hiểm, sắp xếp tập trung vẫn có thể điều chỉnh tốc độ giao dịch hoặc thứ tự để rút MEV. Chúng cũng tạo ra một điểm lỗi duy nhất; nếu sắp xếp bị lỗi, toàn bộ mạng L2 sẽ không hoạt động bình thường.
Ngoài rủi ro tập trung, việc triển khai còn mang lại những giả định và đánh đổi về độ tin cậy bổ sung, đặc biệt là xung quanh khả năng tương tác:
Người dùng gặp phải nhiều hình thức của cùng một tài sản không thể thay thế cho nhau. Ba bản cập nhật chính — Arbitrum, Optimism và Base — duy trì các hệ sinh thái, trường hợp sử dụng và nhóm người dùng khác nhau. Người dùng phải kết nối giữa các bản tổng hợp để truy cập các ứng dụng cụ thể hoặc các giao thức phải khởi chạy trên nhiều rollups, thanh khoản về thanh khoản và người dùng trong khi quản lý sự phức tạp và rủi ro bảo mật đi kèm với tích hợp cầu nối.
Các vấn đề về khả năng tương tác bổ sung bắt nguồn từ những hạn chế về mặt kỹ thuật (số lượng giao dịch mỗi giây ở lớp L2 cơ sở bị giới hạn), dẫn đến mô-đun nhiều hơn và đẩy việc thực thi lên L3, đặc biệt là đối với trò chơi. Sự tập trung hóa đặt ra những thách thức bổ sung.
Chúng tôi đã thấy các gói được tối ưu hóa như Base và MegaETH cải thiện hiệu suất thông qua sắp xếp tập trung và tối ưu hóa EVM khi các giao dịch được sắp xếp và thực hiện mà không cần yêu cầu đồng thuận. Điều này cho phép giảm thời gian xử lý khối và tăng kích thước khối bằng cách sử dụng một máy có công suất cao duy nhất, nhưng cũng tạo ra một điểm lỗi duy nhất và một vectơ kiểm duyệt tiềm ẩn.
Monad có phương pháp khác, đòi hỏi phần cứng mạnh hơn mạng chủ Ethereum. Trong khi trình xác thực Ethereum L1 yêu cầu CPU 2 lõi, bộ nhớ 4-8 GB và băng thông 25 Mbps, Monad yêu cầu CPU 16 lõi, bộ nhớ 32 GB, ổ SSD 2 TB và băng thông 100 Mbps. Trong khi thông số kỹ thuật của Monad có vẻ lớn hơn nhiều so với Ethereum, thì Ethereum vẫn giữ các yêu cầu nút ở mức tối thiểu để phù hợp với các trình xác thực độc lập, mặc dù phần cứng mà Monad đề xuất hiện đã có thể truy cập được.
Ngoài thông số kỹ thuật phần cứng, Monad đang thiết kế lại ngăn xếp phần mềm của mình để đạt được phi tập trung cao hơn L2 thông qua phân phối nút . Trong khi L2 ưu tiên cải tiến phần cứng cho một sắp xếp duy nhất với cái giá phải trả là phi tập trung, Monad lại tăng yêu cầu về phần cứng đồng thời sửa đổi ngăn xếp phần mềm để cải thiện hiệu suất trong khi vẫn giữ cho nút được phân bổ.
(5) Fork Ethereum ban đầu của EVM Monad chủ yếu sửa đổi cơ chế đồng thuận, chẳng hạn như Avalanche, trong khi vẫn duy trì máy trạm Go Ethereum để thực thi. Mặc dù máy trạm Ethereum có thể chạy bằng nhiều ngôn ngữ lập trình khác nhau, nhưng về cơ bản chúng đều sao chép thiết kế gốc. Monad khác biệt ở chỗ xây dựng lại các thành phần đồng thuận và thực thi từ những nguyên tắc đầu tiên.
Monad ưu tiên tối đa hóa việc sử dụng phần cứng. Ngược lại, mạng chủ Ethereum tập trung vào việc hỗ trợ những người đặt cược độc lập sẽ hạn chế việc tối ưu hóa hiệu suất vì nó yêu cầu khả năng tương thích với phần cứng yếu hơn. Giới hạn này ảnh hưởng đến việc cải thiện kích thước khối, thông lượng và thời gian khối — cuối cùng, tốc độ của mạng chỉ bằng trình xác thực chậm nhất của nó.
Tương tự như phương pháp của Solana , Monad sử dụng phần cứng mạnh hơn để tăng băng thông và giảm độ trễ. Chiến lược này sử dụng tất cả các lõi, bộ nhớ và ổ SSD có sẵn để tăng tốc độ. Với chi phí ngày giảm của phần cứng mạnh mẽ, việc tối ưu hóa cho các thiết bị hiệu suất cao sẽ thực tế hơn là hạn chế khả năng của các thiết bị chất lượng thấp hơn.
Máy trạm Geth hiện tại thực thi thông qua một quy trình tuần tự luồng đơn. Các khối chứa sắp xếp giao dịch tuyến tính giúp chuyển đổi trạng thái trước đó thành trạng thái mới. Trạng thái này bao gồm tất cả tài khoản, hợp đồng thông minh và dữ liệu được lưu trữ. Thay đổi trạng thái xảy ra khi giao dịch được xử lý và xác thực, ảnh hưởng đến số dư tài khoản, hợp đồng thông minh, quyền sở hữu token và dữ liệu khác.
Các giao dịch thường diễn ra độc lập. Trạng thái blockchain bao gồm nhiều tài khoản khác nhau, mỗi tài khoản thực hiện giao dịch độc lập và các giao dịch này thường không tương tác với nhau. Dựa trên ý tưởng này, Monad sử dụng phương pháp thực thi song song lạc quan.
Thực thi song song lạc quan cố gắng chạy các giao dịch song song để đạt được lợi ích hiệu suất tiềm năng - ban đầu giả định rằng sẽ không có xung đột. Nhiều giao dịch chạy đồng thời, ban đầu không cần quan tâm đến xung đột hoặc sự phụ thuộc tiềm ẩn của chúng. Sau khi thực hiện, hệ thống sẽ kiểm tra xem các giao dịch song song có thực sự xung đột với nhau hay không và sửa chúng nếu có xung đột.
4. Thực hiện song song các cơ chế giao thức
(1) Thực hiện song song Solana
Khi người dùng nghĩ đến thực thi song song, họ thường nghĩ đến Solana và SVM, cho phép các giao dịch được thực hiện song song thông qua danh sách truy cập. Giao dịch trên Solana bao gồm một tiêu đề, một khóa tài khoản (địa chỉ của các hướng dẫn có trong giao dịch), một hàm băm khối (hàm băm có khi giao dịch được tạo), các hướng dẫn và một mảng chữ ký cho tất cả các tài khoản được yêu cầu dựa trên các hướng dẫn giao dịch.
Hướng dẫn cho mỗi giao dịch bao gồm một địa chỉ chương trình, chỉ định chương trình sẽ được gọi; tài khoản, liệt kê tất cả các tài khoản mà hướng dẫn đọc và ghi; và dữ liệu hướng dẫn, chỉ định trình xử lý hướng dẫn (hàm xử lý hướng dẫn) và bất kỳ dữ liệu bổ sung nào mà trình xử lý hướng dẫn yêu cầu.
Mỗi hướng dẫn nêu rõ ba chi tiết chính cho từng tài khoản liên quan:
* Địa chỉ công khai của tài khoản
*Tài khoản có cần phải ký giao dịch hay không
*Liệu hướng dẫn có sửa đổi dữ liệu tài khoản không
Solana sử dụng các danh sách tài khoản được chỉ định này để xác định trước các xung đột giao dịch. Vì tất cả các tài khoản đều được chỉ định trong hướng dẫn, bao gồm thông tin chi tiết về việc chúng có thể ghi hay không, nên các giao dịch có thể được xử lý song song nếu chúng không chứa bất kỳ tài khoản nào ghi vào cùng một trạng thái.
Quá trình này như sau:
* Solana kiểm tra danh sách các tài khoản được cung cấp trong mỗi giao dịch
* Xác định tài khoản nào sẽ được ghi vào
* Kiểm tra xem có xung đột giữa các giao dịch không (chúng có ghi vào cùng một tài khoản không)
* Các giao dịch không ghi vào bất kỳ tài khoản nào giống nhau sẽ được xử lý song song, trong khi các giao dịch có hoạt động ghi xung đột sẽ được xử lý tuần tự
Một cơ chế tương tự tồn tại trong EVM, nhưng không được sử dụng vì Ethereum không yêu cầu danh sách truy cập. Người dùng phải trả nhiều tiền hơn ngay từ đầu vì họ bao gồm danh sách truy cập này trong giao dịch của mình. Các giao dịch trở nên lớn hơn và tốn kém hơn, nhưng người dùng sẽ được giảm giá khi chỉ định danh sách truy cập.
(2) Thực thi song song của Monad khác với Solana . Monad sử dụng thực thi song song lạc quan. Thay vì xác định giao dịch nào ảnh hưởng đến tài khoản nào và thực hiện song song dựa trên điều đó ( phương pháp của Solana ), Monad cho rằng các giao dịch có thể được thực hiện song song mà không ảnh hưởng lẫn nhau.
Khi Monad chạy các giao dịch song song, nó sẽ giả định rằng các giao dịch bắt đầu tại cùng một điểm. Khi nhiều giao dịch được chạy song song, Chuỗi sẽ tạo ra kết quả đang chờ xử lý cho từng giao dịch. Trong bối cảnh này, kết quả đang chờ xử lý đề cập đến việc ghi chép sổ sách mà Chuỗi thực hiện để theo dõi các đầu vào và đầu ra của một giao dịch và cách chúng ảnh hưởng đến trạng thái. Những kết quả đang chờ xử lý này được gửi theo thứ tự ban đầu của các giao dịch (tức là dựa trên phí ưu tiên).
Để xác nhận kết quả đang chờ xử lý, các đầu vào sẽ được kiểm tra để đảm bảo chúng vẫn hợp lệ - nếu các đầu vào cho kết quả đang chờ xử lý đã bị thay đổi/sửa đổi (tức là nếu các giao dịch không thể hoạt động song song vì chúng truy cập vào cùng một tài khoản và sẽ ảnh hưởng lẫn nhau, thì các giao dịch sẽ được xử lý tuần tự (các giao dịch sau sẽ được thực hiện lại)). Việc thực hiện lại chỉ nhằm mục đích duy trì tính chính xác. Kết quả không phải là các giao dịch mất nhiều thời gian hơn mà là cần phải tính toán nhiều hơn.
Trong lần thực thi lần, Monad đã kiểm tra các xung đột hoặc sự phụ thuộc vào các giao dịch khác. Do đó, khi giao dịch được thực hiện lần thứ hai (sau khi lần thực hiện song song lạc quan lần không thành công), tất cả các giao dịch trước đó trong khối đã được thực hiện, đảm bảo rằng lần thử lần sẽ thành công. Mặc dù tất cả các giao dịch trong Monad đều phụ thuộc lẫn nhau, nhưng chúng chỉ được thực hiện tuần tự, tạo ra kết quả giống như một EVM không song song khác.
Monad theo dõi các tập lệnh đọc và ghi của mỗi giao dịch trong quá trình thực hiện, sau đó hợp nhất các kết quả theo thứ tự giao dịch ban đầu. Nếu một giao dịch chạy song song sử dụng dữ liệu lỗi thời (vì một giao dịch trước đó đã cập nhật nội dung nó đọc), monad sẽ phát hiện điều này khi nó hợp nhất và thực hiện lại giao dịch đó với trạng thái cập nhật chính xác. Điều này đảm bảo rằng kết quả cuối cùng sẽ giống với kết quả thực thi tuần tự của các khối, duy trì ngữ nghĩa tương thích với Ethereum. Việc thực hiện lại này có chi phí tối thiểu - các bước tốn kém như xác minh chữ ký hoặc tải dữ liệu không cần phải lặp lại từ đầu và thường thì trạng thái bắt buộc đã được lưu vào bộ nhớ đệm ngay từ lần chạy lần.
Ví dụ:
Ở trạng thái ban đầu, người dùng A có 100 USDC, người dùng B có 0 USDC và người dùng C có 300 USDC.
Có ba giao dịch:
*Giao dịch 1: Người dùng A gửi 10 USDC cho Người dùng B
*Giao dịch 2: Người dùng A gửi 10 USDC cho Người dùng C
Quy trình thực thi tuần tự Sử dụng quy trình thực thi tuần tự đơn giản hơn nhưng kém hiệu quả hơn. Mỗi giao dịch được thực hiện theo trình tự:
* Người dùng A đầu tiên gửi 10 USDC cho Người dùng B.
*Sau đó, người dùng A gửi 10 USDC cho người dùng C.
Ở trạng thái cuối cùng, để thực thi tuần tự (không phải Monad):
*Người dùng A còn 80 USDC (đã gửi 10 USDC cho B và C).
* Người dùng B có 10 USDC.
* Người dùng C có 310 USDC.
Tiến trình thực hiện song song
Với việc thực hiện song song, quá trình này phức tạp hơn nhưng hiệu quả hơn. Nhiều giao dịch được xử lý đồng thời, thay vì chờ từng giao dịch hoàn tất tuần tự. Mặc dù các giao dịch diễn ra song song, hệ thống vẫn theo dõi dữ liệu đầu vào và đầu ra của chúng. Trong giai đoạn “hợp nhất” tuần tự, nếu phát hiện một giao dịch đã sử dụng đầu vào đã bị thay đổi bởi một giao dịch trước đó, giao dịch đó sẽ được thực hiện lại bằng cách sử dụng trạng thái đã cập nhật.
Quy trình từng bước như sau:
*Người dùng A ban đầu có 100 USDC, Người dùng B ban đầu có 0 USDC và Người dùng C ban đầu có 300 USDC.
* Với thực thi song song lạc quan, nhiều giao dịch chạy đồng thời, ban đầu giả định rằng tất cả chúng đều bắt đầu hoạt động từ cùng một trạng thái ban đầu.
* Trong trường hợp này, giao dịch 1 và giao dịch 2 được thực hiện song song. Cả hai giao dịch đều cho thấy trạng thái ban đầu của Người dùng A là 100 USDC.
*Giao dịch 1 có kế hoạch gửi 10 USDC từ người dùng A đến người dùng B, giảm số dư của người dùng A xuống 90 và tăng số dư của người dùng B lên 10.
*Đồng thời, giao dịch 2 cũng đọc được số dư ban đầu của người dùng A là 100 và có kế hoạch chuyển 10 USDC cho người dùng C, cố gắng giảm số dư của người dùng A xuống 90 và tăng số dư của người dùng C lên 310.
* Khi Chuỗi xác minh các giao dịch này theo thứ tự, giao dịch 1 sẽ được kiểm tra trước. Vì giá trị đầu vào khớp với trạng thái ban đầu nên nó được gửi đi, số dư của người dùng A trở thành 90 và người dùng B nhận được 10 USDC.
*Khi Chuỗi kiểm tra giao dịch 2, nó phát hiện ra vấn đề: giao dịch 2 được lên kế hoạch với giả định rằng người dùng A có 100 USDC, nhưng hiện tại người dùng A chỉ có 90 USDC. Do sự không khớp này, Giao dịch 2 phải được thực hiện lại.
* Trong quá trình thực hiện lại, Giao dịch 2 đọc trạng thái cập nhật của Người dùng A là 90 USDC. Sau đó, 10 USDC được chuyển thành công từ người dùng A sang người dùng C, người dùng A còn lại 80 USDC và số dư của người dùng C tăng lên 310 USDC.
*Trong trường hợp này, vì người dùng A có đủ tiền để thực hiện lần giao dịch nên cả hai giao dịch đều được hoàn thành thành công.
Ở trạng thái cuối cùng, để thực thi song song (Monad):
Kết quả đều giống nhau:
*Người dùng A còn 80 USDC (đã gửi 10 USDC cho B và C).
* Người dùng B có 10 USDC.
* Người dùng C có 310 USDC.
* Người dùng D có 100 USDC trừ đi chi phí NFT và số NFT đúc.
5. Thực hiện chậm trễ
Khi blockchain xác minh và đạt được sự đồng thuận về các giao dịch, nút trên toàn thế giới phải giao tiếp với nhau. Hình thức liên lạc toàn cầu này gặp phải những hạn chế về mặt vật lý vì dữ liệu mất thời gian để truyền giữa các điểm xa nhau như Tokyo và New York.
Hầu hết blockchain đều sử dụng phương pháp tuần tự , trong đó quá trình thực hiện được kết hợp chặt chẽ với sự đồng thuận. Trong các hệ thống này, thực hiện là điều kiện tiên quyết để đạt được sự đồng thuận — nút phải thực hiện giao dịch trước khi một khối có thể được hoàn tất.
Sau đây là thông tin chi tiết:
Việc thực hiện diễn ra trước khi có sự đồng thuận để các khối được hoàn thiện trước khi bắt đầu khối tiếp theo. Nút đầu tiên đạt được sự đồng thuận về thứ tự giao dịch, sau đó đạt được sự đồng thuận về gốc Merkle của bản tóm tắt trạng thái sau khi thực hiện các giao dịch. Người đứng đầu phải thực hiện trong đó các giao dịch trong khối được đề xuất trước khi chia sẻ khối đó và nút xác thực phải thực hiện mọi giao dịch trước khi đạt được sự đồng thuận. Quá trình này giới hạn thời gian thực hiện vì nó diễn ra lần trong khi vẫn cho phép nhiều vòng giao tiếp toàn cầu đạt được sự đồng thuận. Ví dụ, Ethereum có thời gian tạo khối là 12 giây, trong khi thực thi thực tế chỉ mất 100 mili giây (thời gian thực thi thực tế thay đổi rất nhiều tùy thuộc vào độ phức tạp của khối và mức sử dụng gas).
Một số hệ thống cố gắng tối ưu hóa điều này bằng cách xen kẽ thực thi, chia nhiệm vụ thành các phân đoạn nhỏ hơn xen kẽ giữa các quy trình. Mặc dù quá trình xử lý vẫn diễn ra tuần tự, với một nhiệm vụ duy nhất được thực thi tại bất kỳ thời điểm nào, việc chuyển đổi nhanh chóng tạo ra tính đồng thời đáng kể. Tuy nhiên, phương pháp này về cơ bản vẫn hạn chế năng suất vì việc thực hiện và sự đồng thuận vẫn phụ thuộc lẫn nhau.
Monad giải quyết những hạn chế của việc thực thi tuần tự và xen kẽ bằng cách tách việc thực thi khỏi sự đồng thuận. Nút đạt được sự đồng thuận về thứ tự của các giao dịch mà không cần thực hiện chúng — hai quy trình song song xảy ra:
* Nút thực hiện các giao dịch đã đạt được sự đồng thuận.
*Sự đồng thuận tiếp tục với khối tiếp theo mà không cần chờ thực thi hoàn tất và thực thi theo sau sự đồng thuận.
Cấu trúc này cho phép hệ thống cam kết lượng lớn thông qua sự đồng thuận trước khi bắt đầu thực hiện, cho phép Monad xử lý các khối lớn hơn và nhiều giao dịch hơn bằng cách phân bổ thêm thời gian. Hơn nữa, nó cho phép mỗi tiến trình sử dụng toàn bộ thời gian khối một cách độc lập - sự đồng thuận có thể sử dụng toàn bộ thời gian khối cho giao tiếp toàn cầu và quá trình thực thi có thể sử dụng toàn bộ thời gian khối để tính toán mà không chặn lẫn nhau.
Để duy trì tính an toàn và tính nhất quán của trạng thái trong khi tách quá trình thực thi khỏi sự đồng thuận, Monad sử dụng gốc Merkle bị trì hoãn trong đó mỗi khối chứa một gốc Merkle của trạng thái cách N khối trước đó (N dự kiến là 10 khi khởi chạy và được đặt thành 3 trong mạng thử nghiệm hiện tại), cho phép nút xác minh rằng chúng đã đạt đến cùng một trạng thái sau khi thực thi. Gốc Merkle bị trì hoãn cho phép Chuỗi xác minh tính nhất quán của trạng thái: gốc Merkle bị trì hoãn hoạt động như một điểm kiểm tra - N khối sau đó, nút phải chứng minh rằng chúng đã đến cùng một gốc trạng thái, nếu không, chúng đã thực hiện sai điều gì đó. Hơn nữa, nếu quá trình thực thi của nút tạo ra trạng thái gốc khác, nó sẽ phát hiện ra điều này sau N khối và có thể khôi phục và thực thi lại để đạt được sự đồng thuận. Điều này giúp loại bỏ rủi ro nút có hành vi độc hại. Gốc Merkle bị trì hoãn kết quả có thể được máy trạm nhẹ sử dụng để xác minh trạng thái — mặc dù có độ trễ là N khối.
Do việc thực hiện bị trì hoãn và diễn ra sau khi đã có sự đồng thuận, nên một vấn đề tiềm ẩn là kẻ xấu (hoặc người dùng thông thường vô tình) liên tục gửi các giao dịch cuối cùng sẽ thất bại do không đủ tiền. Ví dụ, nếu người dùng có tổng số dư là 10 MON thực hiện 5 giao dịch, thì mỗi giao dịch riêng lẻ cố gắng gửi 10 MON có thể gây ra sự cố. Tuy nhiên, nếu không kiểm tra, các giao dịch này có thể đạt được sự đồng thuận nhưng lại thất bại trong quá trình thực hiện. Để giải quyết vấn đề này và giảm thiểu thư rác tiềm ẩn, nút triển khai biện pháp bảo vệ trong quá trình đồng thuận bằng cách theo dõi các giao dịch đang diễn ra.
Đối với mỗi tài khoản, nút sẽ kiểm tra số dư tài khoản cách đây N khối (vì đây là trạng thái chính xác được xác minh gần đây nhất). Sau đó, đối với mỗi giao dịch đang chờ xử lý "đang chuyển tiếp" cho tài khoản đó (đã đạt được sự đồng thuận nhưng chưa thực hiện), họ sẽ trừ giá trị đang được chuyển (ví dụ: gửi 1 MON) và chi phí gas tối đa có thể, được tính bằng gas_limit nhân với maxFeePerGas.
Quá trình này tạo ra “số dư khả dụng” đang chạy được sử dụng để xác thực các giao dịch mới trong quá trình đồng thuận. Nếu giá trị của một giao dịch mới cộng với chi phí gas tối đa vượt quá số dư khả dụng này, giao dịch sẽ bị từ chối trong quá trình đồng thuận, thay vì để giao dịch đó được thực hiện rồi thất bại trong quá trình thực hiện.
Vì sự đồng thuận của Monad tiến hành với chế độ xem trạng thái hơi chậm trễ (do tách biệt thực thi), nên nó thực hiện biện biện pháp bảo vệ chống lại việc bao gồm các giao dịch mà người gửi cuối cùng không thể thanh toán. Trong Monad, mỗi tài khoản đều có số dư khả dụng hoặc "dự trữ" trong quá trình đồng thuận. Khi các giao dịch được thêm vào các khối được đề xuất, giao thức sẽ khấu trừ chi phí tối đa có thể của giao dịch ( gas * phí tối đa + giá trị chuyển khoản) từ số dư khả dụng này. Nếu số dư khả dụng của một tài khoản giảm xuống dưới 0, các giao dịch tiếp theo từ tài khoản đó sẽ không được đưa vào các khối.
Cơ chế này (đôi khi được mô tả là tính phí vận chuyển vào số dư dự trữ) đảm bảo rằng chỉ những giao dịch có thể thanh toán mới được đề xuất, do đó ngăn chặn các cuộc tấn công DoS khi kẻ tấn công cố gắng làm ngập mạng bằng các giao dịch vô dụng với số tiền bằng 0. Khi các khối được hoàn thiện và thực hiện, số dư sẽ được điều chỉnh cho phù hợp, nhưng trong giai đoạn đồng thuận, nút Monad luôn kiểm tra số dư có thể chi tiêu của các giao dịch đang chờ xử lý.
6. Đơn dBFT
(1) Sự đồng thuận
Đồ Hot
MonadBFT là cơ chế đồng thuận Byzantine Fault Tolerant ("BFT") có độ trễ thấp, thông lượng cao bắt nguồn từ cơ chế đồng thuận HotStuff.
Hotstuff được tạo ra bởi VMresearch và được cải tiến thêm bởi LibraBFT từ đội ngũ blockchain Meta trước đây. Nó đạt được những thay đổi về chế độ xem tuyến tính và khả năng phản hồi, nghĩa là nó có thể xoay vòng các nhà lãnh đạo một cách hiệu quả trong khi thực hiện ở tốc độ mạng thực tế thay vì thời gian chờ được xác định trước. HotStuff cũng sử dụng chữ ký ngưỡng để tăng hiệu quả và triển khai đường ống, cho phép đề xuất các khối mới trước khi khối trước đó được xác nhận.
Tuy nhiên, những lợi ích này đi kèm với một số đánh đổi nhất định: so với giao thức BFT hai vòng cổ điển, lần bổ sung sẽ dẫn đến độ trễ cao hơn và khả năng fork trong quá trình xử lý. Bất chấp những đánh đổi này, thiết kế của HotStuff khiến nó phù hợp hơn với các triển khai blockchain quy mô lớn, mặc dù nó chậm hơn so với các giao thức BFT hai vòng.
Sau đây là lời giải thích của HotStuff:
*Khi giao dịch xảy ra, chúng sẽ được gửi đến người xác thực của mạng lưới, được gọi là Người dẫn đầu.
*Người dẫn đầu biên soạn các giao dịch này thành một khối và truyền nó tới những người xác thực khác trong mạng.
*Sau đó, người xác thực sẽ xác thực khối bằng cách bỏ phiếu và phiếu bầu sẽ được gửi đến Người đứng đầu khối tiếp theo.
* Để bảo vệ chống lại những tác nhân độc hại hoặc lỗi giao tiếp, các khối phải trải qua nhiều vòng bỏ phiếu trước khi trạng thái của chúng được hoàn thiện.
*Tùy thuộc vào cách triển khai cụ thể, một khối chỉ có thể được cam kết sau khi vượt qua thành công hai hoặc ba vòng, đảm bảo tính mạnh mẽ và bảo mật của sự đồng thuận.
Mặc dù MonadBFT có nguồn gốc từ HotStuff, nhưng nó đưa ra những sửa đổi độc đáo và các khái niệm mới có thể được khám phá sâu hơn.
Thỏa thuận giao dịch
MonadBFT được thiết kế riêng để triển khai các giao thức giao dịch trong điều kiện đồng bộ một phần — nghĩa là Chuỗi có thể đạt được sự đồng thuận ngay cả trong các giai đoạn không đồng bộ khi độ trễ của tin nhắn là không thể đoán trước.
Cuối cùng, mạng lưới ổn định và truyền tải tin nhắn (trong một khung thời gian đã biết). Các giai đoạn không đồng bộ này phát sinh từ kiến trúc của Monad, vì Chuỗi phải triển khai một số cơ chế nhất định để tăng tốc độ, thông lượng và thực thi song song.
Hệ thống bánh xe kép
Không giống như HotStuff, ban đầu triển khai hệ thống ba bánh, MonadBFT sử dụng hệ thống hai bánh tương tự như Jolteon, DiemBFT và Fast HotStuff.
Một vòng bao gồm các bước cơ bản sau:
*Trong mỗi vòng, Người dẫn chương trình sẽ phát một khối mới và chứng chỉ (QC hoặc TC) của vòng trước.
*Mỗi người xác thực sẽ xem xét khối và gửi phiếu chữ ký cho Người dẫn đầu vòng tiếp theo
*Khi thu thập đủ số phiếu bầu (2/3), một QC sẽ được thành lập. QC có nghĩa là những người xác thực của mạng đã đạt được sự đồng thuận để thêm một khối, trong khi TC có nghĩa là vòng đồng thuận đã thất bại và cần phải bắt đầu lại.
"Vòng đôi" cụ thể đề cập đến các quy tắc nộp bài. Để gửi một khối trong hệ thống hai vòng:
* Vòng 1: Khối ban đầu được đề xuất và nhận QC
*Vòng 2: Khối tiếp theo được đề xuất và nhận được QC. Nếu hai vòng này được hoàn thành liên tiếp, khối đầu tiên có thể được cam kết.
DiemBFT trước đây sử dụng hệ thống ba vòng nhưng nâng cấp lên hệ thống hai vòng. Hệ thống hai vòng cho phép gửi bài nhanh hơn bằng cách giảm số lần giao tiếp. Nó cho phép độ trễ thấp hơn vì các giao dịch có thể được gửi nhanh hơn vì không cần phải chờ xác nhận bổ sung.
Quy trình cụ thể
Quá trình đồng thuận trong MonadBFT như sau:
*Hoạt động của người dẫn đầu và đề xuất khối: Quá trình bắt đầu khi người dẫn đầu được chỉ định của vòng hiện tại khởi xướng sự đồng thuận. Người dẫn đầu tạo và phát một khối mới chứa các giao dịch của người dùng và bằng chứng về vòng đồng thuận trước đó dưới dạng QC hoặc TC. Điều này tạo ra một cấu trúc đường ống trong đó mỗi đề xuất khối đều mang thông tin xác thực của khối trước đó.
*Hoạt động của trình xác thực: Khi trình xác thực nhận được đề xuất khối từ Người dẫn đầu, họ sẽ bắt đầu quy trình xác minh. Mỗi trình xác thực sẽ xem xét cẩn thận tính hợp lệ của khối theo các quy tắc của giao thức. Một khối hợp lệ sẽ nhận được phiếu bầu CÓ có chữ ký và được gửi đến vòng Lãnh đạo tiếp theo. Tuy nhiên, nếu trình xác thực không nhận được khối hợp lệ trong thời gian mong đợi, họ sẽ khởi tạo quy trình tạm dừng bằng cách phát thông báo Tạm dừng đã ký bao gồm QC cao nhất mà họ biết. Phương pháp theo hai hướng này đảm bảo rằng giao thức có thể đạt được tiến triển ngay cả khi đề xuất khối không thành công.
* Tạo chứng chỉ: Giao thức sử dụng hai loại chứng chỉ để theo dõi tiến trình đồng thuận. Khi Người dẫn đầu thu thập được phiếu bầu CÓ từ hai phần ba số người xác thực, một QC sẽ được tạo ra, chứng minh sự đồng thuận rộng rãi về khối. Ngoài ra, nếu hai phần ba số người xác thực hết thời gian chờ mà không nhận được đề xuất hợp lệ, họ sẽ tạo TC, cho phép giao thức tiến hành vòng tiếp theo một cách an toàn. Cả hai loại chứng chỉ đều đóng vai trò là bằng chứng quan trọng chứng minh sự tham gia của bên xác thực.
*Hoàn tất khối (Quy tắc cam kết hai Chuỗi): MonadBFT sử dụng quy tắc cam kết hai Chuỗi để hoàn tất khối. Khi người xác thực quan sát thấy hai khối đã được chứng nhận liền kề từ các vòng liên tiếp tạo thành Chuỗi B ← QC ← B' ← QC', họ có thể cam kết khối B và tất cả các khối tổ tiên của nó một cách an toàn. Phương pháp hai Chuỗi này mang lại tính bảo mật và tính sống động trong khi vẫn duy trì hiệu suất.
Kiến trúc nhóm bộ nhớ cục bộ
Monad sử dụng kiến trúc nhóm bộ nhớ cục bộ thay vì nhóm bộ nhớ toàn cục truyền thống. Trong hầu hết blockchain, các giao dịch đang chờ xử lý được truyền đến tất cả nút, có thể chậm (nhiều bước nhảy mạng) và tốn nhiều băng thông do truyền tải dư thừa. Ngược lại, trong Monad, mỗi trình xác thực duy trì nhóm bộ nhớ riêng; các giao dịch được chuyển tiếp bởi nút RPC trực tiếp đến một vài người dẫn đầu được xác định trước tiếp theo (hiện tại là N=3 người dẫn đầu tiếp theo) để đưa vào.
Điều này tận dụng các lịch trình của người dẫn đầu đã biết (tránh phát sóng không cần thiết tới những người không phải là người dẫn đầu) và đảm bảo rằng các giao dịch mới sẽ đến được với những người đề xuất khối một cách nhanh chóng. Người dẫn đầu tiếp theo thực hiện kiểm tra xác thực và thêm giao dịch vào nhóm bộ nhớ cục bộ của họ, do đó khi đến lượt người xác thực dẫn đầu, giao dịch có liên quan đã được xếp hàng đợi. Thiết kế này làm giảm độ trễ truyền dẫn và tiết kiệm băng thông, đạt được thông lượng cao hơn.
(2) Chim săn mồi
Monad sử dụng giao thức đa hướng chuyên dụng có tên là RaptorCast để nhanh chóng truyền các khối từ người dẫn đầu đến tất cả người xác thực. Thay vì gửi toàn bộ các khối theo trình tự đến từng đối tác hoặc dựa vào các chương trình phát sóng đơn giản, người đứng đầu sử dụng một lược đồ mã hóa xóa (theo RFC 5053) để chia dữ liệu đề xuất khối thành các khối được mã hóa và phân phối các khối này một cách hiệu quả thông qua một cây chuyển tiếp hai cấp. Trên thực tế, người đứng đầu sẽ gửi các khối khác nhau đến một tập hợp nút xác thực bậc nhất, sau đó các nút này sẽ chuyển tiếp nút đến những người khác để cuối cùng, mọi nút xác thực đều nhận được đủ khối để tái tạo lại một khối hoàn chỉnh. Việc phân phối các khối được tính theo trọng số cổ phần (mỗi trình xác thực có trách nhiệm chuyển tiếp một phần các khối) để đảm bảo cân bằng tải. Theo cách này, toàn bộ khả năng tải lên của mạng được sử dụng để truyền các khối nhanh chóng, giảm thiểu độ trễ, đồng thời vẫn chấp nhận nút Byzantine (độc hại hoặc lỗi) có thể làm mất tin nhắn. RaptorCast cho phép Monad đạt được khả năng phát khối nhanh và đáng tin cậy ngay cả với các khối lớn, điều này rất quan trọng để đạt được thông lượng cao.
Chữ ký BLS và ECDSA
QC và TC được triển khai bằng cách sử dụng chữ ký BLS và ECDSA, đây là hai loại lược đồ chữ ký số khác nhau được sử dụng trong mật mã.
Monad sử dụng kết hợp chữ ký BLS và chữ ký ECDSA để cải thiện tính bảo mật và mở rộng . Chữ ký BLS hỗ trợ tổng hợp chữ ký, trong khi chữ ký ECDSA thường được xác minh nhanh hơn.
Chữ ký ECDSA
Mặc dù chữ ký không thể được tổng hợp, nhưng chữ ký ECDSA lại nhanh hơn. Monad sử dụng chúng cho QC và TC.
Tạo QC:
*Người lãnh đạo đề xuất một khối
* Người xác thực đồng ý bằng cách ký vào phiếu bầu
* Khi thu thập đủ các phần bỏ phiếu cần thiết, chúng có thể được kết hợp thành một QC.
*QC chứng minh rằng trình xác thực đồng ý với khối
TC Tạo:
*Nếu trình xác thực không nhận được khối hợp lệ trong thời gian đã lên lịch
* Nó phát đi một thông báo hết thời gian đã ký cho các đồng nghiệp
* Nếu thu thập đủ tin nhắn hết thời gian chờ, chúng sẽ hình thành TC.
*TC cho phép bạn vào vòng tiếp theo ngay cả khi bạn trượt vòng hiện tại
BLS Signature Monad sử dụng chữ ký BLS cho nhiều chữ ký vì nó cho phép các chữ ký được tổng hợp dần dần thành một chữ ký duy nhất. Tính năng này chủ yếu được sử dụng cho các loại tin nhắn tổng hợp như thăm dò ý kiến và tạm dừng.
Phiếu bầu là thông điệp được người xác thực gửi đi khi họ đồng ý với khối được đề xuất. Chúng chứa các chữ ký thể hiện sự chấp thuận của khối và được sử dụng để xây dựng QC.
Hết thời gian chờ là thông báo được trình xác thực gửi đi khi không nhận được khối hợp lệ trong thời gian mong đợi. Chúng chứa một thông điệp đã ký với số vòng hiện tại, QC cao nhất của trình xác thực và chữ ký của các giá trị này. Chúng được sử dụng để xây dựng TC.
Cả bỏ phiếu và thời gian chờ đều có thể sử dụng kết hợp/tổng hợp chữ ký BLS để tiết kiệm không gian và cải thiện hiệu quả. Như đã đề cập trước đó, BLS chậm hơn so với chữ ký ECDSA.
Monad sử dụng kết hợp ECDSA và BLS để tận dụng hiệu quả của cả hai. Mặc dù chương trình BLS chậm hơn nhưng nó cho phép tổng hợp chữ ký và do đó đặc biệt hữu ích cho việc bỏ phiếu và thời gian chờ, trong khi ECDSA nhanh hơn nhưng không cho phép tổng hợp.
7. Đơn tử MEV
Nói một cách đơn giản, MEV đề cập đến giá trị mà các bên có thể rút bằng cách sắp xếp , bao gồm hoặc loại trừ các giao dịch trong một khối. MEV thường được phân loại thành MEV “tốt”, tức là MEV giúp thị trường lành mạnh và hiệu quả (ví dụ: thanh lý, chênh lệch giá) hoặc MEV “xấu” (ví dụ: tấn công sandwich).
Việc thực thi chậm trễ của Monad ảnh hưởng đến cách thức hoạt động của MEV trên Chuỗi. Trên Ethereum, thực thi là điều kiện tiên quyết để đạt được sự đồng thuận — nghĩa là khi nút đồng ý về một khối, chúng sẽ đồng ý về danh sách và thứ tự của các giao dịch, cũng như trạng thái kết quả. Trước khi đề xuất một khối mới, người đứng đầu phải thực hiện tất cả các giao dịch và tính toán trạng thái cuối cùng, cho phép người tìm kiếm và người xây dựng khối mô phỏng các giao dịch một cách đáng tin cậy so với trạng thái được xác nhận gần đây nhất.
Ngược lại, trên Monad, sự đồng thuận và thực hiện được tách biệt. Nút chỉ cần thống nhất về thứ tự giao dịch trong khối gần đây nhất, trong khi sự đồng thuận về trạng thái có thể đạt được sau đó. Điều này có nghĩa là trình xác thực có thể hoạt động dựa trên dữ liệu trạng thái từ các khối cũ hơn, khiến chúng không thể mô phỏng theo các khối mới nhất. Bên cạnh sự phức tạp do thiếu thông tin trạng thái được xác nhận, thời gian tạo khối 1 giây của Monad có thể khiến người xây dựng gặp khó khăn trong việc mô phỏng các khối để tối ưu hóa các khối mà họ xây dựng.
Người tìm kiếm cần phải có quyền truy cập vào dữ liệu trạng thái mới nhất vì nó cung cấp cho họ giá tài sản đã được xác nhận, số dư nhóm thanh khoản và trạng thái hợp đồng thông minh trên DEX, cùng nhiều thông tin khác — cho phép họ xác định các cơ hội chênh lệch giá tiềm năng và phát hiện các sự kiện thanh lý. Nếu dữ liệu trạng thái mới nhất không được xác nhận, trình tìm kiếm không thể mô phỏng khối trước khi khối tiếp theo được tạo và phải đối mặt với rủi ro giao dịch bị hủy trước khi trạng thái được xác nhận.
Do sự chậm trễ trong các khối Monad, bối cảnh MEV có thể tương tự như Solana.
Để bối cảnh, trên Solana, các khối được tạo ra trong một khe cắm sau mỗi ~400ms, nhưng thời gian giữa khi một khối được tạo ra và được "gốc" (hoàn thiện) dài hơn nhiều — thường là 2000-4000ms. Sự chậm trễ này không phải do quá trình sản xuất khối mà do thời gian thu thập đủ số phiếu bầu có trọng số để hoàn tất một khối.
Trong thời gian bỏ phiếu này, mạng lưới tiếp tục xử lý các khối mới song song. Vì phí giao dịch rất thấp và các khối mới có thể được xử lý song song nên điều này đã tạo ra "tình trạng chạy đua" khi những người tìm kiếm sẽ gửi lượng lớn giao dịch với hy vọng được đưa vào — điều này khiến nhiều giao dịch bị hủy bỏ. Ví dụ, trong tháng 12, 1,3 tỷ trong số 3,16 tỷ giao dịch không có quyền biểu quyết trên Solana(khoảng 41%) đã bị hủy bỏ. Jito’s Buffalu đã nhấn mạnh ngay từ năm 2023 rằng “98% giao dịch chênh lệch giá trên Solana đều thất bại”.
Do hiệu ứng trì hoãn khối tương tự trên Monad, nơi thông tin trạng thái xác nhận cho khối mới nhất không tồn tại và các khối mới được xử lý song song, người tìm kiếm có thể được khích lệ gửi lượng lớn giao dịch - điều này có thể thất bại vì các giao dịch bị hủy bỏ và trạng thái đã xác nhận khác với trạng thái họ sử dụng để mô phỏng.
8. Cơ sở dữ liệu Monad
Monad đã quyết định xây dựng một cơ sở dữ liệu tùy chỉnh, được gọi là MonadDB, để lưu trữ và truy cập dữ liệu blockchain . Một vấn đề phổ biến với mở rộng Chuỗi là tăng trưởng trạng thái — khi kích thước dữ liệu vượt quá khả năng của nút. Paradigm đã công bố một bài nghiên cứu ngắn về tăng trưởng của trạng thái vào tháng 4, nêu bật sự khác biệt giữa tăng trưởng của trạng thái, tăng trưởng lịch sử và quyền truy cập của trạng thái, mà họ cho rằng thường bị nhầm lẫn mặc dù đây là những khái niệm riêng biệt ảnh hưởng đến hiệu suất phần cứng nút.
Như họ chỉ ra:
* Tăng trưởng trạng thái đề cập đến sự tích lũy các tài khoản mới (số dư tài khoản và nonce) và hợp đồng (mã byte hợp đồng và lưu trữ). Nút cần có đủ dung lượng lưu trữ và bộ nhớ để đáp ứng tăng trưởng của trạng thái.
* Tăng trưởng lịch sử đề cập đến sự tích lũy các khối và giao dịch mới. Nút cần có đủ băng thông để chia sẻ dữ liệu khối và đủ không gian lưu trữ để lưu trữ dữ liệu khối.
*Truy cập trạng thái đề cập đến các hoạt động đọc và ghi được sử dụng để xây dựng và xác minh các khối.
Như đã đề cập trước đó, cả tăng trưởng trạng thái và tăng trưởng lịch sử đều ảnh hưởng đến mở rộng của Chuỗi , vì kích thước dữ liệu có thể vượt quá khả năng của nút. Nút cần lưu trữ dữ liệu tron
