Việc song song hóa EVM có ý nghĩa gì? Hay là hồi kết dưới ách bá quyền của EVM?
Tuyển chọn TechFlowTuyển chọn TechFlow
Việc song song hóa EVM có ý nghĩa gì? Hay là hồi kết dưới ách bá quyền của EVM?
Parallel EVM có thể giúp các ứng dụng phi tập trung hiện tại đạt được hiệu năng ở cấp độ internet không?
Chuyên sâu báo cáo Web3Tác giả: ZHIXIONG PAN
TL;DR
-
Khái niệm Parallel EVM đang được một số quỹ VC hàng đầu rót vốn: Paradigm, Jump, Dragonfly, v.v.
-
Các dự án tiêu biểu là Monad, ngoài ra còn có Sei, MegaETH, Polygon, Neon EVM, BSC... Một số là L1, một số là L2. Sự khác biệt cụ thể giữa các đội ngũ hiện chưa có thông tin công khai đầy đủ.
-
Mặc dù từ ngữ "Parallel EVM" chỉ mang nghĩa "xử lý song song", nhưng thực tế đây cũng là nỗ lực tối ưu hiệu suất ở nhiều thành phần của EVM, do đó rất có thể nó đại diện cho giới hạn hiệu năng trong chuẩn EVM.
-
Khó khăn: Ngoài việc phải tái cấu trúc toàn bộ stack kỹ thuật, còn có vấn đề dự đoán trước giao dịch nào sẽ xung đột khi xử lý song song, và hiệu quả thực thi lại sau khi phát sinh xung đột.
-
Thách thức: Làm thế nào để tạo ra sự khác biệt trong hệ sinh thái mã nguồn mở, và tìm được điểm cân bằng giữa tính phi tập trung và hiệu năng.
Sau khi các công nghệ như thuật toán đồng thuận, lớp dữ liệu (DA), và chứng minh kiến thức không tiết lộ (zero-knowledge proof) đã được nghiên cứu và cải tiến rộng rãi, công nghệ tiếp theo thu hút sự chú ý là Parallel EVM — lĩnh vực này đã nhận được hàng trăm triệu USD đầu tư từ thị trường vốn và hình thành nhiều startup đạt mức kỳ lân.
Phong trào cộng đồng bắt đầu quan tâm đến Parallel EVM (EVM song song) khởi nguồn từ việc Georgios Konstantopoulos (CTO của Paradigm) và Haseeb Qureshi (Dragonfly) độc lập với nhau đều nhắc tới cùng một từ khóa này khi dự báo xu hướng năm 2024 vào cuối năm 2023. Tuy nhiên, chi tiết thảo luận về chủ đề này vẫn còn ít, và nhiều người cho rằng đây không phải khái niệm mới — cả EVM và tính toán song song đều là những khái niệm tương đối trưởng thành — vậy tại sao kết hợp hai từ này lại trở thành một xu hướng quan trọng?
Tuy nhiên, đây vẫn là một chủ đề rất hàn lâm, đến mức nếu đọc qua các báo cáo tổng kết hoặc dự báo xu hướng hàng năm của nhiều tổ chức nghiên cứu, ta gần như không thấy nhắc đến Parallel EVM. Do đó, đây vẫn là một khái niệm chưa đạt được sự đồng thuận lớn. Và giống như các chủ đề về thuật toán đồng thuận hay DA, đây là chủ đề hoàn toàn kỹ thuật nên lượng người theo dõi càng ít hơn.
Lợi thế trực tiếp nhất của Parallel EVM là giúp các ứng dụng phi tập trung hiện tại đạt được hiệu năng ở cấp độ Internet. Có thể nói rằng Parallel EVM là công nghệ duy nhất vừa tận dụng được (số lượng lớn) hợp đồng thông minh đã trưởng thành, vừa có thể đạt được hiệu suất cao và thông lượng chuỗi công khai song song.
Paradigm mong chờ tham gia từ lâu, Jump đặt cược mạnh tay
Theo tờ Fortune báo cáo, Paradigm đang lên kế hoạch dẫn dắt vòng gọi vốn mới nhất của Monad, định giá 3 tỷ USD để huy động 200 triệu USD. Dù đây là đội ngũ đầu tiên theo khái niệm Parallel EVM mà Paradigm đầu tư, thực tế họ đã theo dõi công nghệ này nhiều năm — Georgios Konstantopoulos (CTO của Paradigm) từng đề cập đến khái niệm này từ năm 2021.
Nguồn gốc tên gọi "Monad" cũng rất thú vị. Trong hệ thống triết học của triết gia Leibniz, Monad là đơn vị cơ bản cấu thành vũ trụ — chúng là thực thể bất khả phân, không chịu ảnh hưởng vật lý, mỗi Monad phản ánh toàn bộ vũ trụ. Trong tiếng Trung, từ này từng được dịch là "đơn tử".
Trong khoa học máy tính, Monad là một mẫu thiết kế (design pattern) trong ngôn ngữ lập trình hàm, giúp lập trình viên xử lý sự phức tạp của thế giới thực gần như với sự thuần khiết toán học, làm cho mã nguồn trở nên mô-đun hóa hơn, dễ hiểu và bảo trì hơn.
Một điều thú vị khác là "Monad" và "Nomad" là anagram (ghép chữ đảo vị trí). Nomad nghĩa là người du mục, còn digital nomad là dân du mục số/dân chăn nuôi số.
Ngoài Monad, khi thảo luận về chủ đề này, Georgios cũng nhắc đến Sei và Polygon. Một lý do khác khiến ông đánh giá cao Parallel EVM là vì họ đang phát triển một client Ethereum tên Reth — sản phẩm này định vị là client tầng thực thi Ethereum hiệu suất cao, được viết bằng Rust. Reth đang phát triển rất nhanh và vừa bước vào giai đoạn Beta. Có lẽ họ sẽ cân nhắc triển khai Parallel EVM trực tiếp trên Reth, nhưng xét về quy mô kỹ thuật, thì đầu tư vào các đội ngũ khác để thúc đẩy Parallel EVM có thể là lựa chọn tốt hơn. Theo tài liệu của Monad, họ chủ yếu sử dụng C++ và Rust trong kỹ thuật.
Khi ra mắt, Reth từng bị thành viên nhóm Erigon cáo buộc sao chép mã nguồn mở Akula, dẫn đến dự án Akula thiếu kinh phí và ngừng phát triển. Georgios phản hồi rằng Reth không phải là bản fork của bất kỳ client nào khác, mã nguồn cũng không đến từ client khác, nhưng的确 chịu ảnh hưởng và cảm hứng từ Geth, Erigon và Akula. (https://thedefiant.io/paradigm-accused-copying-code)
Một bên tham gia trọng yếu khác là Jump Trading và Jump Capital. Người sáng lập Monad đến từ Jump Trading, có kinh nghiệm dày dặn trong giao dịch tần suất cao. Nhà đầu tư của Sei có Jump Capital, và Jump cũng tham gia sâu vào hệ sinh thái Solana, cả về cơ sở hạ tầng lẫn các dự án.
Dragonfly — nhà đầu tư sớm của Monad — cũng luôn theo dõi lĩnh vực liên quan, từng đầu tư vào NEAR chuyên về công nghệ phân mảnh (sharding), cũng như các blockchain như Aptos, Avalanche, Nervos.
Chỉ nâng cấp thuật toán đồng thuận là chưa đủ, đến lượt tầng thực thi
Trong các cuộc chiến blockchain trước đây, tầng thực thi luôn bị bỏ quên — mọi người gần như chỉ bàn về đổi mới thuật toán đồng thuận, dù là Solana, Avalanche hay EOS. Dù họ có nhiều đổi mới ở tầng thực thi, cộng đồng vẫn nhớ rõ nhất là thuật toán đồng thuận họ dùng, và cả cộng đồng thường cho rằng hiệu năng cao của các blockchain này đến từ đổi mới thuật toán đồng thuận.
Nhưng thực tế không phải vậy. Muốn có một blockchain hiệu năng cao, cần phối hợp đồng bộ giữa thuật toán đồng thuận và tầng thực thi — đúng như nguyên tắc thùng gỗ (hiệu năng bị giới hạn bởi tấm ván ngắn nhất). Với các blockchain EVM chỉ cải tiến thuật toán đồng thuận, để tăng hiệu năng cần yêu cầu nút mạnh hơn. Ví dụ, BSC giới hạn gas mỗi khối ở mức xử lý khoảng 2000 TPS, đòi hỏi cấu hình máy gấp nhiều lần so với nút đầy đủ Ethereum. Polygon lý thuyết có thể đạt 1000 TPS, nhưng thông thường chỉ vài chục đến vài trăm.
Nút lưu trữ BSC cần tối thiểu CPU 16 nhân và RAM 128GB, trong khi nút Ethereum chỉ cần tối thiểu CPU 4 nhân và RAM 16GB.
Đội ngũ BSC cũng sớm nhận ra vấn đề này, nên đã hợp tác với NodeReal để phát triển công nghệ Parallel EVM. Chỉ như vậy mới nâng được số lượng giao dịch xử lý mỗi khối, cho phép nhiều giao dịch thực thi song song và tăng giới hạn TPS.
Song song: Không chỉ nâng từ CPU đơn nhân lên đa nhân
Trong hầu hết các hệ thống blockchain, giao dịch được thực thi tuần tự — bạn có thể hình dung như một CPU đơn nhân, chỉ khi hoàn tất phép tính hiện tại mới sang phép tính tiếp theo. Cách này tuy chậm nhưng ưu điểm là đơn giản và độ phức tạp hệ thống thấp.
Nhưng nếu tương lai hệ thống blockchain cần phục vụ quy mô người dùng cấp độ Internet, CPU đơn nhân chắc chắn không đủ. Vì vậy, nâng cấp lên máy ảo song song kiểu CPU đa nhân có thể xử lý nhiều giao dịch đồng thời, tăng thông lượng. Tuy nhiên, điều này đặt ra nhiều thách thức kỹ thuật — ví dụ, nếu hai giao dịch đang xử lý song song cùng ghi dữ liệu vào một hợp đồng thông minh thì sao? Cần thiết kế một cơ chế mới để giải quyết mâu thuẫn này. Đối với các hợp đồng thông minh hoàn toàn không liên quan, có thể xử lý song song theo số luồng, tăng thông lượng theo tỷ lệ.
Hơn nữa, Parallel EVM không chỉ nâng cao khả năng song song mà còn tối ưu hiệu suất thực thi đơn luồng. CEO của Monad, Keone Hon phát biểu: "... (EVM) thực sự bị nghẽn ở chỗ thường xuyên đọc/ghi trạng thái khi xử lý giao dịch..." Ông cũng cho biết thực thi song song chỉ là một phần lộ trình, sứ mệnh lớn hơn của Monad là tối ưu EVM để đạt hiệu quả cao nhất có thể.
Vì vậy, mặc dù từ ngữ “Parallel EVM” chỉ mang nghĩa “xử lý song song”, thực tế nó còn bao gồm các tối ưu hiệu suất chuyên sâu cho từng thành phần của EVM, do đó nỗ lực của nó rất có thể đại diện cho giới hạn hiệu năng dưới chuẩn EVM.
EVM không đồng nghĩa với Solidity
Viết hợp đồng thông minh là kỹ năng bắt buộc của đa số lập trình viên blockchain. Kỹ sư có thể dùng Solidity hoặc ngôn ngữ cao cấp khác để viết logic theo nhu cầu nghiệp vụ. Nhưng EVM không thể trực tiếp hiểu được logic Solidity — cần một bước "dịch" sang ngôn ngữ cấp thấp máy có thể hiểu (opcode / bytecode) trước khi máy ảo thực thi. Quá trình dịch này, lập trình viên Solidity không cần hiểu rõ vì đã có công cụ trưởng thành hỗ trợ.
Vì là "dịch", nên sẽ phát sinh một số overhead (chi phí phát sinh). Những kỹ sư có kinh nghiệm mã cấp thấp có thể dùng opcode trực tiếp trong Solidity để viết logic chương trình, đạt hiệu năng cao nhất — giúp người dùng tiết kiệm Gas khi giao dịch. Ví dụ, giao thức Seaport của Opensea sử dụng rất nhiều assembly nội tuyến trong hợp đồng thông minh để giảm chi phí Gas cho người dùng.
Do đó, nếu Parallel EVM cuối cùng được hiện thực hóa, không chỉ mang lại khả năng xử lý song song mà còn tối ưu toàn bộ hiệu suất stack EVM. Các nhà phát triển ứng dụng thông thường sẽ không cần mất công cực tối ưu để tiết kiệm chút Gas, vì máy ảo nền tảng đã đủ mạnh để san bằng sự khác biệt đó.
Hiệu suất EVM khác nhau, “chuẩn” không đồng nghĩa “thực tiễn kỹ thuật”
“Máy ảo” còn được gọi là “tầng thực thi” — nơi hợp đồng thông minh sau khi biên dịch thành opcode được tính toán và xử lý. Bytecode do Ethereum Virtual Machine (EVM) định nghĩa hiện đã trở thành chuẩn ngành. Dù là các mạng lớp 2 trên Ethereum hay các blockchain độc lập khác, đều sẵn sàng tuân thủ hoàn toàn chuẩn EVM — lập trình viên viết một lần hợp đồng thông minh có thể triển khai trên nhiều mạng, hiệu quả cao.
Vì vậy, chỉ cần hoàn toàn tương thích với chuẩn “bytecode” của EVM, có thể gọi là EVM, nhưng cách hiện thực có thể rất khác nhau. Ví dụ, client Ethereum Geth dùng ngôn ngữ Go để hiện thực chuẩn EVM. Nhưng đội nghiên cứu tầng thực thi của Ethereum Foundation, Ipsilon, duy trì một bản hiện thực EVM độc lập bằng C++, các client Ethereum khác có thể trực tiếp gọi thư viện này làm engine thực thi EVM.
Ví dụ, nhiều sản phẩm công nghiệp sản xuất hàng loạt đều có tiêu chuẩn quốc tế tương ứng — ví dụ, một sản phẩm xuất xưởng cần đảm bảo số lượng vi khuẩn nhỏ hơn một ngưỡng nhất định mới được bán, đó là “tiêu chuẩn”. Nhưng để đạt tiêu chuẩn này, mỗi nhà máy có thể chọn từ hàng chục phương pháp khử trùng khác nhau, và một số nhà máy tìm được cách hiệu quả hơn để đáp ứng yêu cầu — đó là “thực tiễn”.
Vì đã có bản hiện thực evmone, nên cũng có thể làm các bản hiện thực khác. Trong trường hợp EVM, chuẩn EVM định nghĩa một số thao tác cơ bản “bytecode” (ví dụ hỗ trợ cộng trừ nhân chia), mỗi bytecode có đầu vào xác định thì có đầu ra xác định. Khi đáp ứng chuẩn này, cách hiện thực (thực tiễn) có thể rất khác nhau, có không gian tùy biến lớn và tiềm năng tối ưu kỹ thuật phong phú.
Sự giống và khác nhau giữa các Parallel EVM
Trong赛道 Parallel EVM, ngoài cái tên nóng nhất là Monad, còn có Sei, MegaETH, Polygon, Neon EVM, BSC, và client Reth của Paradigm cũng muốn hiện thực chức năng song song.
Xét về định vị, Monad, Sei, Polygon, BSC đều là blockchain lớp 1, trong khi MegaETH có thể là lớp 2, Neon EVM dựa trên mạng Solana. Ngoài ra, Reth là một client mã nguồn mở, MegaETH cũng sẽ phát triển một phần dựa trên công trình của Reth.
Dĩ nhiên, các đội ngũ này có cạnh tranh lẫn nhau, và chưa công bố đầy đủ chi tiết kỹ thuật hay tài liệu kỹ thuật. So sánh chi tiết hơn cần đợi họ dần công khai. Có thể đây lại là một cuộc đua vũ trang — như BTC Layer 2, Restaking, Ethereum Layer 2 — dù công nghệ có khác biệt nhỏ (và mã nguồn mở), nhưng điều quan trọng hơn là xây dựng sự độc đáo cho hệ sinh thái.
Khó khăn kỹ thuật của Parallel EVM
Với giao dịch thực thi tuần tự, điểm nghẽn nằm ở CPU và quá trình đọc/ghi trạng thái. Nhưng lợi thế là cách này đủ đơn giản, ít sai sót, mọi giao dịch đều thực thi ổn định. Với máy ảo xử lý song song, có thể xảy ra xung đột trạng thái, nên cần thêm cơ chế kiểm tra trước hoặc sau khi thực thi.
Ví dụ đơn giản: Nếu máy ảo hỗ trợ 4 luồng xử lý song song, mỗi luồng xử lý một giao dịch, mà cả 4 giao dịch đều giao dịch với cùng một pool Uniswap, thì không thể tính song song — vì mỗi giao dịch sẽ ảnh hưởng đến giá trong pool. Nhưng nếu 4 luồng xử lý 4 việc hoàn toàn không liên quan, thì không có vấn đề gì.
Điều này liên quan đến thiết kế và hiện thực kỹ thuật của từng đội ngũ, nhưng ít nhất cần đảm bảo sau khi thực thi song song, phải có một module phát hiện xung đột, nếu gặp xung đột thì thực thi lại. Tất nhiên, nếu có thể dự đoán trước và sàng lọc các giao dịch có khả năng xung đột, cũng có thể tăng hiệu suất song song của toàn bộ máy ảo.
Ngoài sự khác biệt hiện thực kỹ thuật ở máy ảo Parallel EVM, các đội ngũ thường cũng thiết kế lại và tăng cường hiệu suất đọc/ghi cơ sở dữ liệu trạng thái, đồng thời thiết kế thuật toán đồng thuận phù hợp — ví dụ như MonadDb và MonadBFT do Monad thiết kế.
Thách thức
Đối với Parallel EVM, có hai thách thức tiềm tàng: giá trị kỹ thuật dài hạn có bị Ethereum hấp thụ không; và sự tập trung hóa nút.
Do các đội ngũ vẫn đang trong giai đoạn phát triển và thử nghiệm Parallel EVM, nên chưa công khai toàn bộ chi tiết kỹ thuật — đây là một trong những hào phòng thủ hiện tại. Nhưng khi vào giai đoạn testnet và mainnet, các tài liệu kỹ thuật này sẽ bị công khai, có thể bị Ethereum hoặc các blockchain khác hấp thụ. Vì vậy, tại thời điểm đó, cần đẩy nhanh xây dựng hệ sinh thái, tạo thêm nhiều hào phòng thủ ở tầng hệ sinh thái.
Tuy nhiên, vấn đề này cũng không quá nghiêm trọng. Một mặt, với lập trình viên Crypto hiện nay có nhiều lựa chọn giấy phép mã nguồn mở hơn (ví dụ như loại giấy phép Uniswap, cho phép công khai mã nhưng cấm fork thành dự án thương mại). Mặt khác, định vị của Monad vốn đã khác với Ethereum. Ngay cả khi Ethereum trong tương lai đạt được trạng thái kết thúc trong một slot (SSF), tính dứt khoát giao dịch vẫn mất ít nhất 12 giây — điều này hoàn toàn không đủ cho các kịch bản ứng dụng tần suất cao hơn.
Thách thức thứ hai giống như mọi blockchain hiệu năng cao: làm thế nào triển khai thêm nhiều nút để đáp ứng yêu cầu cơ bản của người dùng về quyền truy cập không cần cấp phép (permissionless) và không cần tin tưởng (trustless): tính phi tập trung. Có thể định lượng một số chỉ số ở đây, ví dụ như «TPS chia cho yêu cầu phần cứng nút», như vậy có thể kiểm soát biến số, so sánh trong điều kiện yêu cầu phần cứng xác định, blockchain/client nào có TPS cao hơn. Dù sao thì, yêu cầu phần cứng nút càng thấp, số lượng nút có thể càng nhiều.
Tiếp theo, chúng tôi sẽ tiếp tục theo dõi sát sao tiến độ của các dự án Parallel EVM và thảo luận chi tiết sâu sắc về công nghệ và sự khác biệt giữa chúng.
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
@ChainFeedsxyz
