Sự phát triển "cấp độ hai" của Ethereum: Từ xác nhận nhanh chóng đến nén thanh toán, Interop loại bỏ thời gian chờ đợi như thế nào?

Nếu bạn thường xuyên chuyển đổi giữa Base, Arbitrum hoặc Optimism, có lẽ bạn đã từng trải qua cảm giác "mất kết nối" khó nhận biết.

Trong khi một giao dịch L2 đơn lẻ cho kết quả gần như tức thì, việc chuyển tài sản từ chuỗi A sang chuỗi B thường cần vài phút hoặc thậm chí lâu hơn. Điều này không phải vì bản thân L2 chậm, mà vì trong các quy trình truyền thống, một giao dịch liên quan đến nhiều lớp và nhiều chuỗi phải tuân theo một lộ trình dài và nghiêm ngặt:

Bộ phân loại L2 sắp xếp dữ liệu, sau đó dữ liệu được gửi đến L1. L1 đạt được sự đồng thuận và hoàn tất quá trình xử lý dữ liệu. Tóm lại, theo kiến trúc Ethereum hiện tại, quá trình hoàn tất xử lý của L1 thường mất hai chu kỳ (khoảng 13 phút). Điều này chắc chắn là cần thiết cho vấn đề bảo mật, nhưng lại quá chậm đối với khả năng tương tác giữa các hệ thống.

Xét cho cùng, nếu tầm nhìn lớn của Ethereum là có hàng trăm hoặc hàng nghìn phiên bản L2 trong tương lai, thì chúng không nên là những "đảo thực thi" biệt lập, mà phải hoạt động cùng nhau như một thể thống nhất. Câu hỏi quan trọng là liệu thời gian chờ đợi này có thể được rút ngắn đến mức tối đa hay không.

Chính trong bối cảnh đó, lộ trình Interop của Ethereum, trong giai đoạn Tăng tốc, đã đề xuất rõ ràng ba hướng cải tiến phối hợp chặt chẽ: Quy tắc xác nhận L1 nhanh, Khoảng thời gian L1 ngắn hơn và Thời gian thanh toán L2 ngắn hơn.

Đây không phải là một sự tối ưu hóa từng phần, mà là một sự tái cấu trúc hệ thống tập trung vào "sự xác nhận, nhịp điệu và sự ổn định".

I. Quy tắc xác nhận nhanh: Trước khi xác định kết quả cuối cùng, hãy cung cấp cho hệ thống một "câu trả lời đáng tin cậy".

Như đã biết, theo kiến trúc Ethereum hiện tại, khoảng thời gian tạo khối trên mạng chính là khoảng 12 giây. Các trình xác thực bỏ phiếu về trạng thái chuỗi hiện tại trong mỗi khoảng thời gian, trong khi tính xác thực cuối cùng bị trì hoãn sau một vài khoảng thời gian.

Tóm lại, ngay cả khi một giao dịch đã được đóng gói vào một khối, hệ thống vẫn cần chờ một khoảng thời gian đáng kể để chắc chắn rằng nó sẽ không bị sắp xếp lại hoặc hoàn tác. Hiện tại, phải mất khoảng hai kỷ nguyên (khoảng 13 phút) trước khi một giao dịch cuối cùng được coi là không thể hoàn tác, điều này chắc chắn là quá lâu đối với hầu hết các kịch bản tài chính trên chuỗi.

Trước khi đạt đến giai đoạn cuối cùng, liệu chúng ta có thể cung cấp cho các ứng dụng và hệ thống chuỗi chéo một tín hiệu xác nhận "đủ nhanh và đủ tin cậy" hay không? Đó chính là mục tiêu của Dự án số 4 của Ethereum, Quy tắc Xác nhận L1 Nhanh, được nêu rõ trong lộ trình Tương tác.

Mục tiêu cốt lõi của nó rất đơn giản: cho phép các ứng dụng và hệ thống chuỗi chéo nhận được tín hiệu xác nhận L1 "mạnh mẽ và có thể kiểm chứng" trong vòng 15-30 giây, mà không cần phải chờ 13 phút như yêu cầu để hoàn tất giao dịch.

Từ góc độ cơ chế, quy tắc xác nhận nhanh không giới thiệu một quy trình đồng thuận mới, mà chỉ tái sử dụng quá trình bỏ phiếu của người xác thực diễn ra trong mỗi khe thời gian của hệ thống PoS Ethereum. Khi một khối tích lũy đủ phiếu bầu của người xác thực trong một khe thời gian đầu, nó có thể được coi là "rất khó bị lật ngược lại theo một mô hình tấn công hợp lý" ngay cả khi nó chưa bước vào giai đoạn xác nhận cuối cùng.

Tóm lại, mức độ xác nhận này không thay thế cho tính chất cuối cùng, mà cung cấp một sự xác nhận mạnh mẽ được giao thức công nhận rõ ràng trước khi đạt được tính chất cuối cùng. Điều này đặc biệt quan trọng đối với Interop: các hệ thống chuỗi chéo, bộ giải quyết ý định và ví điện tử không còn cần phải chờ đợi một cách mù quáng cho đến khi đạt được tính chất cuối cùng, mà có thể an toàn tiến hành bước logic tiếp theo trong vòng 15-30 giây dựa trên các tín hiệu xác nhận ở cấp độ giao thức.

Hiện tại, việc xác nhận trước, được các câu chuyện Based Rollup quảng bá mạnh mẽ, đóng vai trò chuyển tiếp quan trọng theo hướng này ở giai đoạn hiện tại. Logic của nó rất đơn giản, đúng như tên gọi. Hãy tưởng tượng thế này:

Khi mua vé tàu trên hệ thống 12306, sau khi chọn hành trình và đặt vé (ký xác nhận giao dịch), hệ thống sẽ hiển thị thông báo xác nhận sơ bộ, thông báo rằng giao dịch mua (tương ứng với mỗi giao dịch) đã được chấp nhận và đang bước vào quy trình xác nhận tiếp theo. Lúc này, chúng ta có thể bắt đầu lên kế hoạch cho hành trình, chuẩn bị hành lý, v.v. Chỉ khi vé được xác nhận chính thức với toa và chỗ ngồi (giao dịch được chuyển đến L1) thì chúng ta mới có thể chính thức hoàn tất giao dịch mua vé và đặt chỗ.

Tóm lại, trong Based Rollup, xác nhận trước có nghĩa là hứa sẽ đưa một giao dịch vào khối trước khi nó được chính thức gửi đến L1 để xác nhận. Điều này tương đương với việc cung cấp cho người dùng tín hiệu xác nhận ban đầu, cho người dùng biết rằng giao dịch đã được chấp nhận và đang được xử lý.

"Trước tiên tôi sẽ đưa ra cam kết bằng lời nói chắc chắn, và xác nhận cuối cùng sẽ được thực hiện sau." Thông qua logic xác nhận nhiều lớp này, lộ trình tương tác Ethereum thực sự phân biệt rõ ràng các mức độ tin cậy khác nhau giữa "bảo mật" và "tốc độ", tạo ra trải nghiệm tương tác mượt mà hơn.

II. Rút ngắn khe L1: Tăng tốc chu kỳ "nhịp tim" của Ethereum

Đi kèm với "sự tái cấu trúc hợp lý ở cấp độ đồng thuận" của quy tắc xác nhận nhanh là một thay đổi cơ bản hơn và có ý nghĩa vật lý hơn—rút ngắn kích thước của khe thời gian.

Nếu việc xác nhận nhanh chóng giống như "ký vào giấy nợ" trước khi đạt được sự đồng thuận cuối cùng, thì việc rút ngắn thời gian L1 Slot giống như việc trực tiếp rút ngắn "chu kỳ thanh toán" của sổ cái. Trong lộ trình Interop, mục tiêu theo từng giai đoạn của Dự án #5 rất rõ ràng: giảm thời gian Slot của mạng chính Ethereum từ 12 giây hiện tại xuống còn 6 giây.

Việc "giảm một nửa" tưởng chừng đơn giản này thực chất sẽ kích hoạt một phản ứng dây chuyền trong toàn bộ chuỗi. Điều này rất dễ hiểu: khoảng thời gian càng ngắn, giao dịch càng được đưa vào khối nhanh hơn, được phân phối để xác minh và được theo dõi để xác nhận, dẫn đến độ trễ thấp hơn ở lớp giao thức tổng thể.

Tác động trực tiếp đến trải nghiệm thực tế của người dùng bao gồm việc xác nhận tương tác L1 nhanh hơn (như chuyển khoản ETH), tốc độ gửi trạng thái L2 lên L1 nhanh hơn, và thậm chí cả các khe thời gian ngắn hơn kết hợp với các quy tắc xác nhận nhanh, về cơ bản tạo thành "phản hồi trên chuỗi gần như thời gian thực". Điều này cũng có nghĩa là các DApp, ví và giao thức xuyên chuỗi trong hệ sinh thái có thể xây dựng trải nghiệm xác nhận cấp độ hai tốt hơn.

Đối với các giao thức tương tác chuỗi chéo, việc giảm thời gian cũng đồng nghĩa với bước nhảy vọt trong việc sử dụng vốn. Hiện tại, các cầu nối chuỗi chéo hoặc các nhà tạo lập thị trường phải chịu rủi ro "tiền đang vận chuyển" trong vài phút hoặc thậm chí lâu hơn khi xử lý chuyển giao tài sản giữa các chuỗi khác nhau. Để phòng ngừa rủi ro biến động trong thời gian này, họ phải tính phí giao dịch cao hơn.

Khi chu kỳ thanh toán L1 rút ngắn và dòng tiền tăng gấp đôi, lượng vốn bị ràng buộc trong quá trình chuyển tiền sẽ giảm đáng kể. Kết quả rất rõ ràng: chi phí giao dịch thấp hơn, phí người dùng thấp hơn và thời gian thanh toán ngắn hơn sẽ khuyến khích mạnh mẽ các nhà phát triển và người dùng quay trở lại lớp thanh toán L1 an toàn, thay vì dựa vào các bên trung gian thứ ba dễ bị tổn thương.

Dĩ nhiên, việc tăng gấp đôi tần số "nhịp tim" không phải là điều dễ dàng. Nhiều nhóm làm việc trong Quỹ Ethereum đang đồng thời thúc đẩy dự án phức tạp này:

• Phân tích mạng: Nhóm nghiên cứu (bao gồm các nhà nghiên cứu như Maria Silva) đang tiến hành phân tích dữ liệu nghiêm ngặt để đảm bảo rằng các khe thời gian ngắn hơn không dẫn đến rủi ro tái cấu trúc nghiêm trọng do độ trễ mạng, hoặc gây áp lực tập trung lên các nút mạng có băng thông kém;
• Triển khai phía máy khách: Việc này bao gồm việc tái cấu trúc toàn diện cả lớp đồng thuận và lớp thực thi. Điều đáng chú ý là công việc này độc lập với EIP-7732 (tách biệt người đặt cược và người xây dựng ePBS gốc), có nghĩa là chương trình tăng tốc nhịp tim có thể tiếp tục hoạt động độc lập bất kể tiến độ của ePBS.

Nhìn chung, khi kết hợp khoảng thời gian 6 giây với quy tắc xác nhận nhanh, Ethereum dự kiến sẽ thực sự có "phản hồi trên chuỗi gần như thời gian thực", cho phép các dApp và ví trong hệ sinh thái xây dựng trải nghiệm xác nhận cấp độ hai chưa từng có.

III. Rút ngắn chu kỳ thanh toán L2: Cho phép "rút tài sản ngay lập tức".

Trong lộ trình Interop, Dự án số 6: Rút ngắn thời gian thanh toán L2 là dự án gây tranh cãi nhất, nhưng cũng giàu trí tưởng tượng nhất.

Trong kiến trúc hiện tại, Optimistic Rollups thường dựa vào khoảng thời gian thử thách lên đến 7 ngày, và ngay cả ZK Rollups cũng bị hạn chế bởi tốc độ tạo và xác minh bằng chứng. Trên thực tế, thiết kế này hoàn hảo về mặt bảo mật, nhưng nó lại gây ra một vấn đề thực sự ở cấp độ khả năng tương tác:

Tài sản và trạng thái được "khóa thời gian" giữa các chuỗi. Điều này không chỉ làm tăng chi phí giao dịch giữa các chuỗi mà còn làm tăng đáng kể gánh nặng cân bằng lại cho Solver, cuối cùng dẫn đến phí người dùng cao hơn. Do đó, rút ngắn chu kỳ thanh toán được coi là một trong những đòn bẩy chính cho việc triển khai Interop có khả năng mở rộng. Các hướng kỹ thuật chính hiện tại bao gồm (đọc thêm: " ZK Route 'Dawn': Is Ethereum Endgame Roadmap Accelerating? "):

• Bằng chứng thời gian thực ZK: Với sự phát triển của công nghệ tăng tốc phần cứng và các phương pháp chứng minh đệ quy, thời gian tạo bằng chứng đang được rút ngắn từ vài phút xuống còn vài giây.
• Các cơ chế giải quyết nhanh hơn: ví dụ, giới thiệu mô hình giải quyết an toàn 2 trên 3;
• Lớp thanh toán chung: Cho phép nhiều giao dịch L2 hoàn tất thay đổi trạng thái theo ngữ nghĩa thanh toán thống nhất, thay vì "rút tiền - chờ - gửi tiền";

Dĩ nhiên, một câu hỏi cốt lõi không thể tránh khỏi trong cuộc thảo luận về khả năng tương tác giữa các hệ thống là liệu việc rút ngắn thời gian xử lý yêu cầu từ 7 ngày truyền thống xuống còn 1 giờ để đạt được xác nhận xuyên chuỗi nhanh hơn có tạo điều kiện cho kẻ tấn công thực hiện hành vi xấu hay không.

Về mặt lý thuyết, những lo ngại ở đây không phải là không có cơ sở. Không giống như "kiểm duyệt mạnh" (các bên xác minh cùng nhau thực hiện hành vi xấu), điều đáng báo động hơn trong thực tế là kiểu tấn công kiểm duyệt mềm này do người xây dựng khối dẫn đầu: kẻ tấn công không cần kiểm soát sự đồng thuận, mà chỉ cần liên tục ngăn chặn bên bảo vệ trong quá trình đấu thầu, ngăn không cho các giao dịch quan trọng được ghi lại trên chuỗi.

Điều thú vị là, phân tích kinh tế có hệ thống duy nhất về kịch bản này cho đến nay đến từ bài báo "Trò chơi kiểm duyệt kinh tế trong bằng chứng gian lận" của Offchain Labs, được xuất bản vào tháng 2 năm 2025. Bài báo này xây dựng ba mô hình, từ bi quan nhất đến tương đối lạc quan, dựa trên các giả định sau:

• Mô hình G¹: Nội dung của một lô hàng hoàn toàn được quyết định bởi người trả giá cao nhất;
• Mô hình G¹ₖ: Một số trình xác thực luôn xây dựng các khối cục bộ;
• Mô hình Gᵐ: Nhiều trình xác thực cùng nhau quyết định nội dung khối, và chỉ cần một bên chọn giao dịch bảo vệ.

Trong kỹ thuật thực tế, vì người kiểm chứng có thể chọn bỏ qua các vị trí kiểm thử, một số thiết kế thậm chí có thể thoái hóa thành trường hợp G¹ bi quan hơn. Do đó, bài báo này chọn bắt đầu phân tích từ trường hợp xấu nhất.

Dựa trên tiền đề này, các nhà nghiên cứu đã đề xuất một phương pháp phòng thủ có ý nghĩa thực tiễn rất lớn—một cơ chế phòng thủ trì hoãn thời gian theo kiểu "đầu tư nhỏ, lợi nhuận lớn". Logic cốt lõi của nó là bên phòng thủ có quyền "trì hoãn chỉ bằng một cú nhấp chuột", nghĩa là bên phòng thủ không cần phải hoàn thành tất cả các quy trình kiểm tra lỗi phức tạp trong một khoảng thời gian ngắn, mà chỉ cần gửi thành công một giao dịch quan trọng.

Mục đích của giao dịch quan trọng này rất rõ ràng: một khi được ghi lại trên blockchain, nó sẽ tự động gia hạn thời gian thử thách từ 1 giờ trở lại thời gian truyền thống là 7 ngày. Ví dụ, khi một người phòng thủ phát hiện ra sự bất thường trong trạng thái L2, họ không cần phải hoàn thành tất cả các quy trình kiểm tra lỗi phức tạp trong vòng 1 giờ. Họ chỉ cần gửi thành công một giao dịch đặc biệt đến L1. Giao dịch này giống như việc phát tín hiệu báo động không kích, ngay lập tức gia hạn thời gian thử thách trở lại thời gian truyền thống là 7 ngày.

Điều này cũng có nghĩa là những kẻ tấn công sẽ bị buộc phải tham gia vào một cuộc chiến tiêu hao không cân xứng cao độ. Để ngăn chặn giao dịch được ghi lại trên blockchain, những kẻ tấn công phải liên tục trả phí ưu tiên cao hơn so với bên phòng thủ trong mỗi khối, và cuộc đối đầu này cần được duy trì trong suốt toàn bộ thời gian thử thách.

Bài báo trình bày các kết quả định lượng rất trực quan. Theo tính toán, nếu một kẻ tấn công hùng mạnh sẵn sàng chi 10 tỷ đô la cho một cuộc tấn công kiểm duyệt dai dẳng, thì:

• Trong khoảng thời gian một giờ đó, hậu vệ chỉ cần ngân sách xăng dầu 33 triệu đô la để phát động một cuộc phản công;
• Nếu cơ chế trì hoãn được kích hoạt thành công, kéo dài thời gian thách thức lên 7 ngày, chi phí cho cuộc phản công của bên phòng thủ thậm chí có thể giảm xuống khoảng 200.000 đô la.

Nói cách khác, đây là một lợi thế cấu trúc quan trọng: chi phí mà kẻ tấn công phải chịu sẽ tăng tuyến tính, trong khi bên phòng thủ chỉ cần hoàn thành một thao tác thành công trên chuỗi.

Chính sự khác biệt rõ rệt giữa chi phí tấn công và chi phí phòng thủ đã đảm bảo Ethereum vẫn mạnh mẽ về mặt an ninh kinh tế, ngay cả với chu kỳ thanh toán được rút ngắn đáng kể.

Điều này cũng rất quan trọng đối với Interop, vì việc xác nhận nhanh chóng và chu kỳ thanh toán ngắn hơn không nhất thiết phải đánh đổi bằng sự an toàn. Điều đó cũng có nghĩa là, trong một thiết kế thể chế hợp lý, an ninh chuỗi chéo cấp hai và an ninh kinh tế có thể cùng tồn tại, ít nhất là cung cấp cho Interop sự tự tin vững chắc nhất để đạt được an ninh chuỗi chéo cấp hai.

Tóm lại

Một số người có thể thắc mắc, tại sao phải tốn công tối ưu hóa độ trễ vài giây hoặc vài phút?

Trong thời kỳ đỉnh cao của Web3, chúng ta đã quen với việc chờ đợi, thậm chí tin rằng "chờ đợi" là cái giá cần thiết phải trả cho sự phi tập trung. Tuy nhiên, khi Web3 hướng đến số đông, người dùng không nên và không cần phải quan tâm đến việc họ đang hoạt động trên chuỗi nào, chứ đừng nói đến việc tính toán logic hoàn thiện của L1.

Xác nhận nhanh chóng, nhịp tim 6 giây và các cơ chế phòng thủ bất đối xứng về cơ bản đều làm một việc duy nhất—xóa bỏ yếu tố "thời gian" khỏi nhận thức của người dùng.

Như tôi đã nói trước đây: hình thức công nghệ tốt nhất là hình thức cho phép sự phức tạp hoàn toàn biến mất trong quá trình xác nhận nhanh chóng.