Luận điểm nông về Redstone: Nó không phải là Plasma, mà là một biến thể Optimium
Tuyển chọn TechFlowTuyển chọn TechFlow
Luận điểm nông về Redstone: Nó không phải là Plasma, mà là một biến thể Optimium
Bài viết này sẽ giới thiệu với mọi người nguyên lý của Plasma, lý do tại sao nó không thân thiện với hợp đồng thông minh và DeFi, cũng như Redstone thực chất là gì.
Chuyên sâu báo cáo Web3Tác giả: Faust, Geeker Web3
Gần đây, một dự án tên là Redstone đã trở thành tâm điểm chú ý. Cơ sở hạ tầng Layer2 chuyên về game trên chuỗi do đội ngũ Lattice phát triển này đã chính thức ra mắt vào ngày 15 tháng 11 và hiện đã lên mạng thử nghiệm. Điều thú vị là đội ngũ Lattice tuyên bố rằng "Redstone là một chuỗi Alt-DA được truyền cảm hứng từ Plasma".
Chỉ một ngày trước khi Redstone ra mắt, Vitalik vừa đăng bài viết “Exit games for EVM validiums: the return of Plasma”, trong đó ông nhắc lại ngắn gọn giải pháp công nghệ “Plasma” – từng bị lãng quên trong hệ sinh thái Ethereum, đồng thời chỉ ra rằng có thể áp dụng bằng chứng hiệu lực (không nên nhầm với ZK Proof) để khắc phục các vấn đề của Plasma.
Vì thế, không ít người cho rằng Vitalik viết bài này nhằm cổ vũ cho Redstone, thậm chí trong cộng đồng Geeker Web3 còn có người đồn rằng Vitalik có thể đã đầu tư vào Redstone. Thêm vào đó, trước đó đã rộ lên tranh cãi về “định nghĩa Layer2 của Ethereum”, khiến nhiều người tin rằng sắp tới sẽ xảy ra “sự hồi sinh của Plasma”, và các giải pháp DA nằm ngoài hệ sinh thái Ethereum như Celestia có thể bị ảnh hưởng, vì Plasma không yêu cầu nghiêm ngặt về tính sẵn có dữ liệu (DA).
Tuy nhiên, theo tìm hiểu của tác giả bài viết này, Redstone không thực sự phù hợp với khung cơ bản của Plasma, việc tự nhận là “được truyền cảm hứng từ Plasma” có khả năng cao là đang lợi dụng chủ đề nóng từ bài viết của Vitalik, chứ không phải Vitalik thật sự đang ủng hộ Redstone. Ngoài ra, cơ chế xử lý thách thức DA của Redstone khá giống với giải pháp mà dự án Layer2 Metis đã ra mắt vào tháng 4 năm 2022, chỉ khác ở thứ tự giữa hai bước cập nhật Stateroot và phát hành dữ liệu DA.
Do đó, tình hình thực tế là có thể mọi người đã “hiểu quá mức” về Redstone. Phần tiếp theo sẽ dùng một số lập luận đơn giản để giúp độc giả hiểu rõ cơ chế hoạt động của Plasma, vì sao nó không thân thiện với hợp đồng thông minh và DeFi, cũng như Redstone thực chất là gì.
Plasma: Gặp tấn công giữ dữ liệu thì phải rút tiền khẩn cấp
Lịch sử của Plasma bắt nguồn từ thời kỳ bùng nổ ICO Ethereum năm 2017, khi nhu cầu giao dịch của người dùng tăng vọt và ETH với TPS thấp không chịu nổi áp lực. Trong hoàn cảnh đó, phiên bản lý thuyết đầu tiên của Plasma được công bố, đề xuất một giải pháp mở rộng lớp 2 có thể xử lý “gần như mọi tình huống tài chính trên thế giới”.
Đơn giản hóa, Plasma là một phương án mở rộng chỉ đưa phần header khối/Lớp Merkle Root lên Layer1, còn phần dữ liệu ngoài header/Merkle Root (dữ liệu DA) thì chỉ được phát hành ngoài chuỗi. Nếu trình sắp xếp (operator) của Plasma đăng lên L1 một Merkle Root liên kết với giao dịch vô hiệu (như chữ ký sai), người dùng liên quan có thể gửi bằng chứng gian lận để chứng minh root đó chứa giao dịch không hợp lệ.
Tuy nhiên, vấn đề nằm ở chỗ việc gửi bằng chứng gian lận cần đảm bảo dữ liệu DA không bị giữ lại, nhưng Plasma không yêu cầu nghiêm ngặt về lớp DA, nên không thể đảm bảo người dùng hay nút L2 có thể nhận được dữ liệu. Nếu operator phát động tấn công giữ dữ liệu (còn gọi là vấn đề tính sẵn có dữ liệu), chỉ phát hành header khối mới/Merkle root mà không phát hành block body tương ứng, khiến người khác không thể kiểm tra tính hợp lệ của root, lúc đó người dùng chỉ còn cách coi operator là “vô phương cứu chữa” và sử dụng cơ chế rút khẩn cấp “Exit Game” để chuyển tài sản từ Layer2 về Layer1.
Thao tác này yêu cầu người dùng gửi Merkle Proof để chứng minh họ thực sự sở hữu tài sản tương ứng trên L2, ta gọi đây là "bằng chứng tài sản". Điều thú vị là Exit Game của Plasma khác với chế độ thoát hiểm của ZK Rollup: người dùng ZK Rollup phải gửi Merkle Proof tương ứng với Stateroot hợp lệ gần nhất, còn người dùng Plasma có thể gửi proof tương ứng với Merkle Root từ rất lâu trước đó.
Tại sao thiết kế như vậy? Bởi vì Stateroot mà ZK Rollup gửi lên sẽ được hợp đồng trên Layer1 kiểm tra ngay lập tức (xem bằng chứng hiệu lực có hợp lệ không). Nếu Stateroot vừa gửi là hợp lệ và hợp pháp, người dùng phải gửi Merkle Proof tương ứng với Stateroot hợp pháp đó làm bằng chứng tài sản.
Nhưng Merkle Root mà operator Plasma gửi lên thì hợp đồng L1 không thể xác định tính hợp lệ, chỉ có thể để nút L2 chủ động thách thức để loại bỏ root vô hiệu, do đó có cơ chế thách thức, khiến nguyên lý vận hành của Plasma và ZK Rollup hoàn toàn khác biệt.
Giả sử operator vừa phát hành Merkle Root 101 vô hiệu, đồng thời phát động tấn công giữ dữ liệu khiến nút L2 không thể chứng minh root 101 là vô hiệu, lúc này người dùng có thể gửi Merkle Proof tương ứng với root 100 hoặc cũ hơn để rút tài sản.
Tất nhiên, vẫn có một vấn đề cần giải quyết: một người dùng có thể gửi bằng chứng tài sản tương ứng với root 30 hoặc cũ hơn để yêu cầu rút tài sản về L1, nhưng sau khi root 30 được phát hành, tình trạng tài sản của họ có thể đã thay đổi. Nói cách khác, họ đang gửi bằng chứng tài sản lỗi thời — đây là kiểu tấn công tiêu kép điển hình.
Để xử lý điều này, Plasma cho phép bất kỳ ai đưa ra bằng chứng gian lận nếu thấy một người rút tiền đang dùng "bằng chứng tài sản" lỗi thời. Nhờ cơ chế “ai cũng có thể thách thức yêu cầu rút tiền của người khác”, Plasma không cần xử lý yêu cầu rút khẩn cấp như ZK Rollup.
Tuy nhiên, vẫn có một trường hợp: operator trước tiên chuyển tài sản của người khác vào tài khoản L2 của mình, rồi phát động tấn công giữ dữ liệu để ngăn người khác thách thức hành vi gian lận. Sau đó, tài khoản của operator khởi động rút tiền khẩn cấp, gửi “bằng chứng tài sản” khẳng định đúng là sở hữu những tài sản đó trên L2.
Rõ ràng, lúc này do thiếu một đoạn lịch sử, người ta không thể trực tiếp chứng minh nguồn gốc tài sản của operator có vấn đề. Vậy phải làm sao? Các phiên bản sớm của Plasma, ví dụ Plasma MVP, đã tính đến điều này và đề xuất khái niệm “ưu tiên rút tiền”. Nếu ai đó gửi bằng chứng tài sản ứng với root càng cũ, yêu cầu rút tiền của họ sẽ được ưu tiên xử lý.
Giả sử operator thực hiện hành vi gian lận khi gửi root 101 và khởi động rút tiền, người dùng có thể gửi bằng chứng tài sản tương ứng với root 99 hoặc cũ hơn để rút khẩn cấp. Rõ ràng, miễn là operator không thể sửa đổi lịch sử đã đăng lên Layer1, người dùng luôn có đường thoát.
Nhưng Plasma vẫn có một lỗi chết người: Chỉ cần operator phát động giữ dữ liệu, mọi người phải dựa vào rút tiền khẩn cấp (Exit Game) để bảo vệ tài sản. Nếu trong thời gian ngắn có quá nhiều người rút tiền cùng lúc, Layer1 rất dễ quá tải;
nghiêm trọng hơn, tài sản được ghi nhận trên hợp đồng DeFi thì ai sẽ rút về Layer1? Ví dụ ai đó nạp 100 ETH vào nhóm thanh khoản DEX, sau đó operator Plasma gặp lỗi hoặc hành xử ác ý, mọi người cần rút khẩn cấp, nhưng lúc này 100 ETH vẫn đang do hợp đồng DEX kiểm soát — vậy ai sẽ rút số tài sản này về L1?
Cách tốt nhất lẽ ra là để người dùng trước tiên rút tài sản khỏi nhóm DEX, rồi tự tay rút tiền về L1. Nhưng vấn đề là operator Plasma đã lỗi/hành ác, người dùng không thể thực hiện thao tác rút. Còn nếu cho phép owner của hợp đồng DEX rút tài sản về L1, rõ ràng sẽ trao quyền sở hữu cho owner, người này có thể bất cứ lúc nào rút hết tài sản và biến mất — thật đáng sợ!
Cuối cùng, việc xử lý những “tài sản công cộng” do hợp đồng DeFi quản lý là một quả bom hẹn giờ khổng lồ. Nếu dựa vào đồng thuận xã hội để xây lại một hợp đồng gương phản chiếu hợp đồng DeFi trên L2 tại L1, có thể làm được, nhưng sẽ tạo ra rắc rối lớn, tăng chi phí cơ hội. Ai sẽ bỏ phiếu quyết định cách xử lý hợp đồng gương cũng là vấn đề nan giải. Đây thực chất là bài toán phân bổ quyền lực công cộng — trước đây Húng Mả đã từng đề cập trong phỏng vấn “Blockchain công suất cao khó tạo chuyện mới, hợp đồng thông minh dính đến phân bổ quyền lực”.
Dĩ nhiên, trong bài viết gần đây “Exit games for EVM validiums: the return of Plasma”, Vitalik cũng chỉ ra điều này, và nhấn mạnh đây là một trong những yếu tố khiến Plasma không thân thiện với hợp đồng thông minh. Các biến thể Plasma nổi tiếng trước đây như Plasma MVP hay Plasma Cash đều dùng mô hình UTXO hoặc tương tự thay cho mô hình địa chỉ tài khoản của Ethereum, đồng thời không hỗ trợ hợp đồng thông minh — để tránh vấn đề “phân bổ quyền sở hữu tài sản”. Dù mỗi UTXO thuộc sở hữu rõ ràng của người dùng, nhưng bản thân UTXO lại có nhiều hạn chế và không thân thiện với hợp đồng thông minh. Vì vậy, Plasma phù hợp nhất với các trường hợp đơn giản như thanh toán hay sàn giao dịch dạng sổ lệnh.
Sau này, cùng với sự phổ biến của ZK Rollup, Plasma dần lui vào dĩ vãng, bởi Rollup không gặp vấn đề giữ dữ liệu như Plasma. Nếu trình sắp xếp ZK Rollup phát động tấn công giữ dữ liệu, chỉ gửi Stateroot lên chuỗi ETH mà không có dữ liệu DA, root đó sẽ bị đánh giá là vô hiệu và bị từ chối ngay bởi hợp đồng Verifier trên L1. Do đó, dữ liệu DA tương ứng với Stateroot hợp lệ chắc chắn có thể truy vấn được trên chuỗi ETH. Như vậy không tồn tại “chỉ phát hành header khối hoặc merkle root mà không phát hành block body” — tức là giải quyết được vấn đề tính sẵn có dữ liệu/tấn công giữ dữ liệu.
Hơn nữa, dữ liệu DA trước đây của Rollup có thể tra cứu trên Ethereum, bất kỳ ai cũng có thể dùng lịch sử trên chuỗi ETH để khởi chạy nút Layer2, nhờ đó giảm đáng kể độ khó triển khai trình sắp xếp phi tập trung và không cần cấp phép. Ngược lại, Plasma không yêu cầu nghiêm ngặt về DA, nên việc thực hiện trình sắp xếp phi tập trung cũng khó khăn hơn (muốn có trình sắp xếp phi tập trung có thể thay thế, trước tiên phải đảm bảo mọi nút L2 đều chấp nhận block giống nhau — điều này đặt ra yêu cầu nghiêm ngặt đối với cách triển khai DA).
Ngoài ra, nếu trình sắp xếp ZK Rollup cố gắng đưa giao dịch vô hiệu vào khối L2 thì cũng không thể thành công, nhờ nguyên lý của bằng chứng hiệu lực.
Tóm lại, không gian hành ác của trình sắp xếp ZK Rollup nhỏ hẹp hơn nhiều so với Plasma — nó nhiều nhất chỉ khiến việc cập nhật Stateroot bị đình trệ (về mặt trải nghiệm người dùng giống như ngừng hoạt động), hoặc từ chối yêu cầu của một số người dùng (gọi là kiểm duyệt giao dịch). Đồng thời, nếu trình sắp xếp Rollup gặp lỗi, các nút khác thay thế sẽ dễ dàng hơn nhiều. Trong trạng thái lý tưởng, Rollup có thể giảm xác suất kích hoạt cơ chế Exit Game (trong ZK Rollup gọi là buồng thoát hiểm) xuống 0.
(Cột Proposer Failure trên L2BEAT cho thấy các giải pháp L2 khác nhau xử lý lỗi trình sắp xếp ra sao, Self Propose thường nghĩa là các nút khác có thể thay thế trình sắp xếp đang ngừng hoạt động)
Ngày nay, gần như không còn nhóm nào trong hệ sinh thái Ethereum kiên trì theo đuổi hướng đi Plasma, hầu hết các dự án Plasma đều chết yểu.
(Vitalik giải thích vì sao ZK Rollup vượt trội hơn Plasma, trong đó có đề cập đến việc vận hành trình sắp xếp không cần cấp phép và vấn đề DA)
Redstone là gì: Nó không phải Plasma, mà là biến thể của Optimium
Phần trên đã sơ lược Plasma và lý do nó bị Rollup thay thế. Còn về Redstone, hẳn bạn cũng nhận ra sự khác biệt giữa nó và Plasma: Redstone có thể giải quyết vấn đề tấn công giữ dữ liệu, ví dụ nó sẽ không lập tức phát hành stateroot mới, mà trước tiên phát hành dữ liệu DA gốc ngoài chuỗi ETH, sau đó đưa datahash của dữ liệu DA làm bằng chứng cam kết (commitment) lên chuỗi ETH, tuyên bố rằng dữ liệu đầy đủ tương ứng với datahash đã được phát hành ngoài chuỗi.
(Giải thích chính thức của Redstone về cách phòng chống tấn công giữ dữ liệu)
Bất kỳ ai cũng có thể thách thức rằng trình sắp xếp Redstone chưa phát hành dữ liệu gốc tương ứng với datahash đó ngoài chuỗi. Lúc này, trình sắp xếp phải đăng dữ liệu tương ứng với datahash lên chuỗi để đáp trả thách thức. Nếu sau khi bị thách thức, trình sắp xếp không kịp thời đăng dữ liệu lên chuỗi ETH, thì datahash/commitment trước đó của nó sẽ bị coi là vô hiệu.
Nếu trình sắp xếp phản hồi kịp thời yêu cầu của người thách thức, người thách thức có thể lấy được dữ liệu DA gốc tương ứng với datahash. Cuối cùng, hầu hết các nút L2 đều có thể thu thập được dữ liệu DA cần thiết, từ đó giải quyết vấn đề giữ dữ liệu. Tất nhiên, người thách thức phải trả trước một khoản phí, xấp xỉ chi phí mà trình sắp xếp đăng dữ liệu DA gốc lên ETH — biện pháp này nhằm ngăn kẻ xấu thách thức không tốn chi phí, gây thiệt hại cho trình sắp xếp.
Cuối cùng, sau khi giai đoạn thách thức datahash kết thúc, trình sắp xếp sẽ đăng stateroot tương ứng, tức là root tạo ra sau khi thực thi dãy giao dịch trong dữ liệu DA tương ứng với datahash. Lúc này, nút L2 có thể dùng hệ thống bằng chứng gian lận để thách thức các root vô hiệu. Nếu trước đó một datahash bị thách thức mà trình sắp xếp không kịp thời đăng dữ liệu DA gốc, thì dù sau này có đăng stateroot tương ứng với datahash đó, nó cũng bị coi là vô hiệu.
Do Redstone phát hành dữ liệu DA trước, sau đó mới phát hành Stateroot hợp lệ tương ứng, nên trực tiếp giải quyết được vấn đề giữ dữ liệu (trình sắp xếp chỉ đăng root mà không đăng DA).
Rõ ràng mô hình này khác với Optimium thông thường (OP Rollup không dùng Ethereum để thực hiện DA, ví dụ Arbitrum Nova), Optimium thường phụ thuộc vào ủy ban DAC ngoài chuỗi để đảm bảo tính sẵn có dữ liệu, DAC định kỳ gửi giao dịch đa chữ ký lên chuỗi, hợp đồng Rollup trên L1 khi nhận được giao dịch này sẽ mặc định trình sắp xếp đã phát hành dữ liệu DA mới nhất ngoài chuỗi.
(Nguồn ảnh: L2beat)
Trong khi đó, Metis và Arbitrum Nova lại đồng thời gửi Stateroot và datahash; nếu ai nghi ngờ trình sắp xếp giữ dữ liệu DA, họ sẽ cố gắng thách thức, và trình sắp xếp sẽ đưa dữ liệu DA tương ứng lên chuỗi.
Vì vậy, sự khác biệt then chốt giữa Redstone và Metis nằm ở bước này: Redstone trước tiên phát hành datahash, đợi giai đoạn thách thức DA kết thúc mới phát hành stateroot; Metis thì đồng thời phát hành stateroot và datahash, nếu có thách thức thì mới đưa dữ liệu DA lên chuỗi. Rõ ràng giải pháp của Redstone an toàn hơn, vì với Metis, nếu trình sắp xếp mãi không phản hồi yêu cầu dữ liệu DA, vấn đề giữ dữ liệu không thể giải quyết nhanh, chỉ còn cách rút khẩn cấp, dựa vào đồng thuận xã hội hoặc để nút khác thay thế trình sắp xếp;
Nhưng với Redstone, nếu trình sắp xếp giữ dữ liệu, stateroot mà nó đăng sẽ bị coi là vô hiệu ngay lập tức, do đó stateroot và dữ liệu DA có mối quan hệ ràng buộc chặt chẽ, giúp Redstone đạt được mức đảm bảo DA gần giống Rollup, về bản chất là một biến thể Optimium vượt trội hơn Arbitrum Nova và Metis.
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
@godrealmx
