
Layer 2 bị biến đổi: Tương lai của mô-đun hóa là lối vào mới cho «Layer 1»?
Tuyển chọn TechFlowTuyển chọn TechFlow

Layer 2 bị biến đổi: Tương lai của mô-đun hóa là lối vào mới cho «Layer 1»?
Layer 2 không còn đơn thuần là Layer 2 của Ethereum nữa.
Tác giả: Haotian
Thị trường đang xuất hiện một câu chuyện mới mang tên "EVM song song", điều này đặc biệt thú vị đối với layer2, có thể tạo ra một mô hình Rollup mới theo hướng “tinh gọn”, thậm chí phóng đại hơn thì có thể biến Solana thành một layer2 kiểu cách mạng của Ethereum.
Theo tôi, EVM song song chỉ là biểu hiện rõ rệt của xu hướng "mô-đun hóa" cực độ trong Rollup, là thời điểm lớp thực thi VM tiếp tục bị xâm chiếm sau khi lớp DA đã bị bên thứ ba thay thế. Trong tương lai, layer2 sẽ được định nghĩa lại. Vì sao? Hãy phân tích dưới góc nhìn phổ cập như sau:
Để hiểu chủ đề này, trước tiên cần làm rõ mô hình thực thi đơn luồng (single-threaded) của "EVM".
Mô hình này quy định các giao dịch phải được xử lý và xác nhận tuần tự, từng cái một, điều này ảnh hưởng trực tiếp đến tốc độ xử lý giao dịch, thời gian tạo khối và thông lượng giao dịch – cũng chính là nguyên nhân chủ yếu khiến mạng chính Ethereum luôn chịu phí Gas cao và tắc nghẽn. Hơn nữa, lý do thiết kế theo kiểu đơn luồng một phần cũng vì những giới hạn lịch sử.
Do các giao dịch trên Ethereum được các nút độc lập phân tán xác minh và thực thi, đồng thời phải đảm bảo dữ liệu ở mọi địa chỉ như số dư, mã hợp đồng thông minh... giữ trạng thái nhất quán giữa các nút, đồng thời phải loại trừ khả năng xảy ra hiện tượng chi tiêu kép (double spend) cùng một tài sản.
Điều này buộc các giao dịch phải được xử lý theo hàng đợi tuần tự. Nếu cho phép giao dịch song song, rất dễ dẫn đến lỗi đồng bộ dữ liệu giữa các nút, nghiêm trọng hơn là gây ra giao dịch chi tiêu kép.
Giải thích đơn giản: ngân hàng chỉ có một quầy phục vụ, khách hàng rút tiền phải xếp hàng theo thứ tự, dù là gửi tiền, rút tiền hay vay vốn, phải hoàn tất giao dịch của khách này mới chuyển sang khách tiếp theo. Ưu điểm là mọi thao tác trong hệ thống tài khoản ngân hàng đều được ghi chép chính xác; tuy nhiên thời gian chờ đợi của khách sẽ khá lâu.
Nếu ngân hàng mở nhiều quầy phục vụ, khách hàng có thể chọn quầy để xử lý các nghiệp vụ khác nhau, sẽ dễ xảy ra tình trạng hai quầy cùng lúc cố gắng trích tiền từ một tài khoản. Nếu hệ thống tài khoản giữa các quầy không kịp đối chiếu, sẽ dẫn đến chi tiêu kép. Rõ ràng hiệu suất được nâng cao đáng kể, nhưng logic kế toán phức tạp sẽ gây áp lực lớn lên hệ thống sổ sách.
Trong bối cảnh chuỗi độc lập layer1, nếu nền tảng底层 hỗ trợ xử lý song song thì vấn đề sẽ được giải quyết triệt để. Solana nhờ tách biệt tính toán và trạng thái lưu trữ, nên khi VM nhận được nhiều giao dịch từ người dùng, các nút sẽ sắp xếp lại thứ tự các giao dịch đó, rồi gọi tới hệ thống lưu trữ trạng thái độc lập để kiểm tra xung đột trạng thái. Nếu không có xung đột, các giao dịch sẽ được đóng gói vào cùng một khối; nếu có xung đột, các giao dịch xung đột sẽ bị loại khỏi khối lần này.
Ngược lại, trạng thái lưu trữ của Ethereum được tính toán theo thời gian thực, mỗi giao dịch phải chờ giao dịch trước hoàn tất mới được cập nhật trạng thái, do đó không thể tiến hành sàng lọc giao dịch trước khi đóng gói, điều này hạn chế khả năng xử lý song song.
Trong bối cảnh chuỗi Rollup layer2, cách thức đạt được xử lý song song cũng tương tự. Bạn có thể coi quá trình tính toán giao dịch và kiểm tra trạng thái lưu trữ của Solana trong lúc chờ dấu thời gian POH như quá trình Sequencer xử lý giao dịch trên chuỗi Rollup rồi gửi Batch về mạng chính.
Hiện tại, trước khi Batch, Sequencer trên layer2 sẽ gán nonce theo thứ tự thời gian cho các giao dịch, rồi gửi Batch theo thứ tự về mạng chính. Làm thế nào để đạt được đa luồng?
1) Có thể dựa vào mô hình tài khoản AA (Account Abstraction), từ trạng thái tài khoản cho phép khởi tạo nhiều giao dịch đồng thời. Ví dụ, nếu thực hiện đồng thời hai lệnh Transfer, hợp đồng thông minh AA sẽ gán nonce và yêu cầu thực thi tuần tự; nhưng nếu một lệnh là Transfer, một lệnh là Approve thì có thể xử lý song song linh hoạt mà không bị giới hạn bởi nonce. Trong mô hình tài khoản AA, mỗi tài khoản có thể tự định nghĩa logic xử lý giao dịch, từ đó kết hợp với nonce để đạt mức độ đồng thời cao.
2) Có thể xử lý "tinh gọn" các giao dịch trong Sequencer. Khi giao dịch layer2 được gửi tới Sequencer, Sequencer có thể nhanh chóng phân tích logic giao dịch, sắp xếp tinh tế và sàng lọc. Ví dụ, nếu cùng một tài khoản gửi hai lệnh Transfer, lệnh thứ hai sẽ bị loại ra, chờ Batch lần tiếp theo; nếu cùng một tài khoản gửi hai thao tác khác bản chất, có thể cùng lúc đưa vào một khối.
Nghe có vẻ đơn giản? Nhưng thực tế không hề dễ dàng. Chỉ xét riêng trường hợp DeFi, Sequencer muốn quản lý giao dịch một cách tinh vi sẽ đối mặt hai thách thức lớn:
1) Phải phân tích dữ liệu giao dịch theo thời gian thực, hiểu rõ phương thức gọi hợp đồng thông minh và các tham số truyền vào. Lấy ví dụ phổ biến là Staking trong DeFi, một thao tác Staking liên quan đến việc chuyển token, cập nhật trạng thái, thời hạn đặt cọc, và tính toán phần thưởng tiềm năng. Nếu đồng thời có lượng lớn người dùng gửi giao dịch đặt cọc, trong đó pha lẫn cả giao dịch Transfer sau khi đặt cọc, cộng thêm các yếu tố giá Oracle phức tạp… Chỉ cần Sequencer không xử lý chính xác một bước, có thể gây ra sự cố nghiêm trọng.
2) Sequencer phải đảm bảo tính phi tập trung. Hiện tại, ngay cả khi Sequencer trên layer2 chỉ đơn thuần đóng vai trò Batch giao dịch, quyền lực của nó đã quá lớn. Nếu vấn đề phi tập trung của Sequencer chưa được giải quyết, mà lại tiến thêm bước "Rollup tinh gọn", tức là trao thêm nhiều quyền hạn hơn nữa. Nếu Sequencer gian lận, chèn giao dịch giả, công khai thực hiện MEV sandwich, hay cố ý thao túng thanh lý Oracle… tất cả đều có thể phát sinh.
Gần đây, Metis được săn đón. Nhìn bề ngoài dường như chỉ là việc Sequencer đạt được phi tập trung, nhưng sâu xa hơn, đây chính là xây dựng tiền đề đồng thuận cơ bản cho việc triển khai Rollup tinh gọn trong tương lai.
Dĩ nhiên, việc dựa vào Sequencer để đạt được mức độ hội tụ và xử lý giao dịch Rollup cực kỳ tinh gọn hiện vẫn chỉ là một giả thuyết. May mắn thay, mô hình tài khoản AA, tư tưởng tổ hợp mở theo hướng mô-đun hóa toàn diện của blockchain đã tạo điều kiện tiên quyết để hiện thực hóa giả thuyết này.
Trên đây.
Hơn nữa, như đã nói ở trên, hiện nay layer2 ngày càng mang tính mô-đun mạnh mẽ: nhúng công nghệ ZK vào khung OP Stack để đạt mở rộng riêng tư; thay thế lớp DA ban đầu của Ethereum bằng các bên thứ ba như Celestia nhằm giảm chi phí; dần loại bỏ việc dùng ETH làm phí Gas truyền thống, trao thêm tiện ích thực tế cho token layer2; thậm chí layer2 hoàn toàn có thể Batch giao dịch xong rồi gửi tới các môi trường thực thi VM khác nhau, phân bổ giao dịch xử lý trên cả Solana và Ethereum.
Lúc đó, một mô hình hoàn toàn mới sẽ xuất hiện: layer2 ngày nay không còn đơn thuần là layer2 của Ethereum nữa, Solana cũng có thể trở thành layer2 của Ethereum, thậm chí định nghĩa về layer2 cũng sẽ bị "độ" lại.
Hãy tưởng tượng lớn膽 hơn: layer2 hiện tại trở thành một "layer1" cấp cổng vào, tích hợp khả năng xử lý giao dịch đồng thời quy mô lớn, trong khi các "layer1" trước đây như Ethereum, Solana lại trở thành những "layer2" mới chuyên lo thanh toán tài sản và đảm bảo an ninh.
Layer2 từ xưa đến nay chưa bao giờ là một khái niệm cứng nhắc. Các nền tảng layer2 vẫn luôn mang sứ mệnh giải quyết bài toán xử lý giao dịch quy mô lớn, thu hút nhóm người dùng thị trường gia tăng.
Nếu sứ mệnh này hoàn thành, dưới tư tưởng mô-đun hóa, không chỉ tính chính thống của layer1 Ethereum bị phá vỡ, mà toàn bộ hạ tầng gồm tính sẵn có dữ liệu DA xuyên chuỗi, lớp thực thi VM, thậm chí cả khả năng giao tiếp interoperability đều sẽ trở thành cơ sở hạ tầng (infra) giúp các layer2 đạt được ứng dụng đại chúng (Mass Adoption).
Lúc ấy, layer2 không còn đơn thuần là phần bổ trợ cho layer1, mà trở thành một nền tảng tổng hợp mạnh mẽ chuyên hội tụ và phân phối xử lý giao dịch. Vậy thử hỏi, ai mới thực sự là layer2 của ai?
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









