Google Cloud tham gia, liệu Puffer UniFi có thể lấp đầy chặng đường cuối cùng của Based Rollup?

Việc một ông lớn Web2 tham gia đã đưa "Gateway" – một khái niệm mới trước đây chủ yếu tồn tại trong bối cảnh kỹ thuật – đến với tầm nhìn của công chúng.

Ngày 22 tháng 9, Puffer tuyên bố hợp tác với Google Cloud. Google Cloud sẽ là đối tác hạ tầng quan trọng, vận hành Gateway thông qua Puffer Preconf, hỗ trợ lớp thực thi của Puffer UniFi, giúp xử lý giao dịch và cung cấp Execution Preconfirmation trước khi giao dịch được thanh toán cuối cùng trên Ethereum.

Đáng chú ý hơn, Puffer UniFi sẽ trở thành Rollup đầu tiên sử dụng Google Cloud Gateway.

Tuy nhiên, nếu chỉ hiểu điều này là "lại thêm một ông lớn Web2 nữa bước vào Web3", có thể sẽ bỏ lỡ phần đáng bàn luận hơn đằng sau sự hợp tác này.

Bởi vì lần này Google Cloud đóng vai trò không phải là vai trò ngoại vi theo nghĩa truyền thống như cung cấp sức mạnh tính toán, lưu trữ node hay dịch vụ đám mây cho các dự án blockchain. Ngược lại, nó đang trực tiếp bước vào kiến trúc thực thi thời gian thực của Puffer UniFi, trở thành một trong những lớp Gateway kết nối xử lý giao dịch, Preconfirmation và thanh toán cuối cùng trên Ethereum.

Điều này cũng dẫn đến một câu hỏi lớn hơn: Puffer UniFi rốt cuộc đang xây dựng điều gì? Tại sao nó cần Gateway? Và tại sao Google Cloud lại chọn tiến vào Ethereum từ vị trí tương đối nền tảng này?

Câu trả lời có lẽ phải bắt đầu từ giai đoạn mới mà Ethereum L2 đang bước vào.

1. Puffer UniFi: Một câu trả lời cho Rollup ở hiệp hai

Bước sang năm 2026, chiến lược Rollup của Ethereum rõ ràng đang ở một thời điểm tế nhị.

Kể từ khi Vitalik Buterin khơi lên sự phản tư về con đường L2, sứ mệnh lịch sử theo giai đoạn của L2 với tư cách công cụ mở rộng quy mô cho Ethereum đã được tuyên bố hoàn thành trên phương diện thị trường và dư luận.

Một câu hỏi bắt đầu trở nên ngày càng sắc bén: khi L2 không còn chỉ là công cụ mở rộng quy mô để chia sẻ áp lực tắc nghẽn cho L1, rốt cuộc nó nên định nghĩa sự tồn tại của mình như thế nào? Và làm thế nào để tái thiết lập mối quan hệ thống nhất hơn với L1 về bảo mật, sắp xếp thứ tự, thanh khoản và khả năng kết hợp?

Puffer UniFi đang cố gắng đưa ra một trong những câu trả lời đó.

Puffer UniFi lựa chọn không tiếp tục vận hành một hệ thống sắp xếp thứ tự tập trung tương đối độc lập, mà đi theo hướng Based Rollup: để quyền sắp xếp thứ tự của Rollup neo trực tiếp hơn vào Ethereum L1, do hệ thống validator của Ethereum tham gia sắp xếp thứ tự, và cuối cùng kế thừa bảo mật cùng tính trung lập của chính Ethereum.

Điều này không có nghĩa là L2 đã mất đi ý nghĩa.

Chính xác hơn, khi nhiệm vụ theo giai đoạn của việc mở rộng quy mô thuần túy dần hoàn thành, Rollup bắt đầu cần trả lời lại định vị giá trị của mình: trong tương lai, nó sẽ tiếp tục tồn tại như một lớp thực thi tổng quát, hay trở thành hạ tầng ứng dụng phối hợp chặt chẽ hơn với Ethereum, xoay quanh những ứng dụng, kịch bản và trải nghiệm người dùng rõ ràng hơn?

Suy cho cùng, với Ethereum của 5 năm trước, mở rộng quy mô L2 có thể coi là một con đường rất thực tế và cũng rất thành công, nhưng 5 năm sau, tài sản và thanh khoản bị phân tán trên hàng chục hòn đảo độc lập, Rollup cần được định vị lại, chẳng hạn như hướng ứng dụng chain với kịch bản ứng dụng và ranh giới nghiệp vụ rõ ràng mà Vitalik cổ vũ.

Ý nghĩa của Based Rollup nằm ở việc cố gắng điều chỉnh lại mối quan hệ này.

Ý tưởng cốt lõi của nó không phức tạp: vì Rollup cuối cùng vẫn dựa vào Ethereum để hoàn thành thanh toán và xác minh bảo mật, thì quyền sắp xếp thứ tự cũng có thể quay trở lại trực tiếp hơn với Ethereum L1, do hệ thống validator của Ethereum chịu trách nhiệm sắp xếp thứ tự Rollup, điều đó về mặt lý thuyết không chỉ có thể loại bỏ sự phụ thuộc của Rollup vào một sequencer duy nhất, mà còn có thể thực sự đạt được khả năng kết hợp đồng bộ giữa L1 và L2.

Nói cách khác, Based Rollup đưa ra không phải "tạo thêm một L2 nhanh hơn", mà là một câu trả lời gần hơn với con đường bản địa của Ethereum – để việc mở rộng quy mô không còn đồng nghĩa với chia rẽ, để sự tăng trưởng của L2 nuôi dưỡng trở lại bảo mật và giá trị của L1.

Đây là một hướng đi gần như không thể chê trách về mặt lý thuyết, nhưng vấn đề nằm ở chỗ, giải pháp tối ưu về mặt lý thuyết không tự động đồng nghĩa với một hệ thống khả dụng trong thực tế:

• Ràng buộc thực tế đầu tiên là tốc độ. Thời gian tạo block của Ethereum L1 khoảng 12 giây. Nếu việc sắp xếp thứ tự Rollup hoàn toàn theo nhịp của L1, thì mỗi giao dịch đều phải chờ ít nhất một block L1 mới có được xác nhận tương đối đáng tin cậy. Với chuyển khoản thông thường thì có thể chấp nhận được, nhưng với thanh toán tức thời, sổ lệnh, hợp đồng vĩnh viễn hay các ứng dụng DeFi tần suất cao, rõ ràng không thể so sánh với phản hồi dưới một giây mà sequencer tập trung cung cấp (đọc thêm《Preconfs 进化论：从「补丁」到「基建」，UniFi AVS 如何影响 Based Rollup 的游戏规则？》);
• Ràng buộc thứ hai là gánh nặng thực thi. Như đã biết, Ethereum từ lâu kiên trì giảm ngưỡng xác minh, nỗ lực để nhiều phần cứng thông thường và node cá nhân có thể tham gia đồng thuận mạng, nhưng Based Rollup yêu cầu validator L1 trực tiếp đảm nhận vai trò sắp xếp thứ tự tần suất cao, thực thi độ trễ thấp, khó tránh khỏi việc đẩy cao ngưỡng phần cứng, mạng và vận hành của validator, thay vào đó có thể tạo áp lực tập trung mới ở lớp thực thi;
• Ràng buộc thứ ba đến từ cấu trúc khuyến khích. Với nhiều đội ngũ L2, nếu chuyển sang kiến trúc Based đồng nghĩa với độ phức tạp kỹ thuật tăng lên mà lại không có đủ lợi nhuận, thì tiếp tục duy trì sequencer tập trung của riêng mình vẫn là lựa chọn lý trí hơn;

Vì vậy, vấn đề của Based Rollup chưa bao giờ là hướng đi sai, mà là còn thiếu một lớp hạ tầng thực tế để thực sự khả dụng – chỉ cần hệ thống hoàn toàn bị khóa vào nhịp 12 giây của L1, nó khó có thể cân bằng được tốc độ; còn nếu muốn không tái tập trung hóa, vừa giữ được tính trung lập của mainnet, vừa có trải nghiệm tương tác gần với sequencer tập trung, thì phải đưa vào lớp thực thi một sự phân công vai trò mới.

Đây cũng chính là mâu thuẫn cốt lõi mà Puffer UniFi phải giải quyết.

Puffer Preconf chính là được đưa vào ngăn xếp công nghệ cốt lõi của Puffer UniFi trong bối cảnh này – với tư cách một bộ dịch vụ preconfirmation được xây dựng trên EigenCloud (trước đây là EigenLayer), quyền sắp xếp thứ tự vẫn neo vào Ethereum L1, nhưng việc sắp xếp thứ tự hiệu năng cao, phản hồi độ trễ thấp và execution preconfirmation không nhất thiết phải do L1 Validator tự mình thực hiện toàn bộ.

Nói cách khác, nếu Based Rollup trả lời câu hỏi Puffer UniFi "cuối cùng dựa vào ai để sắp xếp thứ tự và thanh toán", thì Puffer Preconf giải quyết câu hỏi "trước khi thanh toán cuối cùng, người dùng làm thế nào có được trải nghiệm thực thi theo thời gian thực và đáng tin cậy".

Và đây cũng chính là điểm khởi đầu để hiểu về Gateway.

2. Thực thi thời gian thực: Tại sao Puffer UniFi cần Preconf?

Trước khi hiểu Gateway, trước tiên cần hiểu Preconfirmation thực sự đang cam kết điều gì.

Thực tế, trong các L2 chủ đạo, lý do người dùng có thể nhanh chóng thấy phản hồi giao dịch thường là vì sequencer tập trung đưa ra một loại soft guarantee trước, cho bạn biết giao dịch này đã vào hàng đợi, frontend cũng nhanh chóng hiển thị kết quả thực thi, khiến người dùng cảm thấy "đã được xác nhận" về mặt trải nghiệm.

Nhưng nghiêm ngặt mà nói, phản hồi nhanh này phần lớn được xây dựng trên sự tin tưởng vào một sequencer duy nhất.

Một khi sequencer gặp sự cố, độ trễ, hành xử xấu hoặc bị kiểm duyệt, cam kết này thường thiếu ràng buộc kinh tế đủ mạnh và cơ chế trách nhiệm có thể xác minh. Nói cách khác, "nhanh" của Rollup truyền thống phần lớn đến từ uy tín của chính sequencer.

Với Puffer UniFi, điều này rõ ràng là chưa đủ, và Puffer Preconf muốn giải quyết chính là vấn đề này.

Nó cố gắng nâng "xác nhận nhanh" từ một sự tin tưởng vào một nhà vận hành duy nhất lên thành một cam kết thực thi được hỗ trợ bởi bảo đảm kinh tế, cam kết chữ ký và cơ chế trách nhiệm – điều này không chỉ khiến Puffer UniFi nhanh hơn, mà còn khiến sự "nhanh" này trở nên đáng tin cậy.

Muốn hiểu kiến trúc này, phải nhìn rõ sự phân công vai trò của nó.

Trong thiết kế của Puffer Preconf, validator L1 vẫn là nguồn gốc cuối cùng của quyền sắp xếp thứ tự, cũng là điểm neo cho bảo mật và tính trung lập của Ethereum, nhưng không cần tự vận hành hệ thống sắp xếp thứ tự hiệu năng cao, cũng không cần trực tiếp đảm nhận toàn bộ công việc thực thi độ trễ thấp. Ngược lại, thông qua cơ chế restaking và ủy quyền, validator có thể giao phần công việc phức tạp này cho các Gateway chuyên nghiệp hơn, để Gateway thay mặt họ đảm nhận Sequencing và Execution Pre-Confirmation.

Nói cách khác, vai trò thực sự đảm nhận trách nhiệm sắp xếp thứ tự và preconfirmation là vai trò mới Gateway.

Nó không phải là sự đổi tên đơn giản của Sequencer tập trung truyền thống, càng không phải là một "plugin tăng tốc" nào đó gắn thêm vào Rollup, nó giống như một lớp đại lý thực thi chuyên nghiệp, dưới chủ quyền của L1, được ủy quyền đảm nhận trách nhiệm sắp xếp thứ tự và preconfirmation:

• Một mặt, nó giúp L1 Proposer cung cấp dịch vụ sắp xếp thứ tự và preconfirmation hiệu năng cao hơn;
• Mặt khác, nó thông qua các cơ chế như đặt cọc, cam kết chữ ký, phạt và phân phối lợi nhuận để tránh tự biến mình thành một node tập trung không bị ràng buộc mới;

Gateway giúp validator không phải tự vận hành một hệ thống sắp xếp thứ tự hiệu năng cao, nhưng quyền sắp xếp thứ tự cuối cùng vẫn neo vào Ethereum L1.

Điều này cũng giải thích tại sao Puffer nhấn mạnh Execution Pre-Confirmation, chứ không chỉ là Inclusion Promise: Inclusion promise chỉ cam kết giao dịch này sẽ được đưa vào block, Execution Preconfirmation giải quyết thêm câu hỏi "liệu giao dịch này