Phân tích lý do Plasma không hỗ trợ hợp đồng thông minh: Giữ lại dữ liệu và bằng chứng gian lận
Tuyển chọn TechFlowTuyển chọn TechFlow
Phân tích lý do Plasma không hỗ trợ hợp đồng thông minh: Giữ lại dữ liệu và bằng chứng gian lận
Plasma không thể giải quyết vấn đề giữ lại dữ liệu, cũng không thuận lợi cho việc di chuyển trạng thái hợp đồng lên Layer1, chắc chắn sẽ bị loại bỏ.
Chuyên sâu báo cáo Web3Tác giả: Faust, Geeker web3
Lý do tại sao Plasma bị lãng quên trong thời gian dài và vì sao Vitalik mạnh mẽ ủng hộ Rollup chủ yếu nằm ở hai điểm: việc thực hiện DA (Data Availability) ngoài chuỗi Ethereum là không đáng tin cậy, dễ xảy ra tình trạng giữ lại dữ liệu; một khi dữ liệu bị giữ lại, việc chứng minh gian lận sẽ trở nên khó khăn. Cơ chế thiết kế của Plasma vốn dĩ cực kỳ thiếu thân thiện với hợp đồng thông minh, đặc biệt khó hỗ trợ việc di chuyển trạng thái hợp đồng lên Layer1. Hai điểm này khiến Plasma về cơ bản chỉ có thể sử dụng mô hình UTXO hoặc tương tự.
Để hiểu rõ hai quan điểm then chốt trên, trước tiên ta hãy bắt đầu từ khái niệm DA và vấn đề giữ lại dữ liệu. DA là viết tắt của Data Availability, dịch nghĩa là tính sẵn có dữ liệu. Hiện nay nhiều người đang dùng sai thuật ngữ này, dẫn đến nhầm lẫn nghiêm trọng với cụm “lịch sử dữ liệu có thể tra cứu”. Thực tế, “lịch sử dữ liệu có thể tra cứu” và “bằng chứng lưu trữ” đã được Filecoin và Arweave giải quyết từ lâu. Theo định nghĩa của Ethereum Foundation và Celestia, vấn đề DA đơn thuần tập trung vào các kịch bản giữ lại dữ liệu.
Cây Merkle, Gốc Merkle và Bằng chứng Merkle
Để làm rõ tấn công giữ lại dữ liệu và vấn đề DA thực chất là gì, trước hết cần trình bày sơ lược về Gốc Merkle và Cây Merkle. Trên Ethereum hay hầu hết các blockchain công khai, người ta sử dụng một cấu trúc dữ liệu dạng cây gọi là Cây Merkle để đóng vai trò tóm tắt/danh mục cho toàn bộ trạng thái tài khoản, hoặc ghi nhận các giao dịch được đóng gói trong mỗi khối.
Các nút lá ở tầng dưới cùng của Cây Merkle được tạo thành từ giá trị băm (hash) của dữ liệu gốc như giao dịch hay trạng thái tài khoản. Những giá trị hash này được nhóm đôi và tính tổng, sau đó lặp đi lặp lại quá trình này, cuối cùng thu được một Gốc Merkle (Merkle Root).
(Các record ở dưới cùng trong hình chính là tập dữ liệu gốc tương ứng với các nút lá)
Gốc Merkle có một tính chất: Nếu một nút lá nào đó ở đáy Cây Merkle thay đổi, thì Gốc Merkle tính được cũng sẽ thay đổi. Do đó, các Cây Merkle ứng với các tập dữ liệu gốc khác nhau sẽ có các Gốc Merkle khác nhau, giống như mỗi người có một dấu vân tay riêng biệt. Kỹ thuật kiểm chứng gọi là Bằng chứng Merkle (Merkle Proof) tận dụng chính tính chất này của Cây Merkle.
Lấy ví dụ từ hình vẽ trên: Giả sử Lý Cương chỉ biết giá trị Gốc Merkle trong hình, mà không biết Cây Merkle đầy đủ gồm những dữ liệu nào. Chúng ta muốn chứng minh cho Lý Cương thấy rằng Record 3 thực sự có liên hệ với Gốc trong hình, nói cách khác, chứng minh rằng hash của Record 3 tồn tại trên Cây Merkle tương ứng với Gốc đó.
Chúng ta chỉ cần gửi cho Lý Cương Record 3 và 3 khối dữ liệu digest được đánh dấu màu xám trong hình, chứ không cần gửi toàn bộ Cây Merkle hay tất cả các nút lá, đây chính là tính gọn nhẹ của Bằng chứng Merkle. Khi số lượng bản ghi ở tầng đáy Cây Merkle rất lớn, ví dụ chứa tới 2^20 khối dữ liệu (khoảng một triệu), Bằng chứng Merkle tối thiểu chỉ cần chứa 21 khối dữ liệu.
(Hai khối dữ liệu 30 và H2 trong hình có thể tạo thành Bằng chứng Merkle, chứng minh rằng khối dữ liệu 30 tồn tại trên Cây Merkle tương ứng với H0)
Trong Bitcoin, Ethereum hay các cầu nối xuyên chuỗi, thường xuyên sử dụng tính "gọn nhẹ" này của Bằng chứng Merkle. Các nút nhẹ (light node) mà chúng ta biết chính là nhân vật Lý Cương vừa nhắc đến – họ chỉ nhận tiêu đề khối (header) từ các nút đầy đủ (full node), chứ không nhận toàn bộ khối. Cần nhấn mạnh rằng Ethereum dùng một loại cây Merkle gọi là State Trie để tóm tắt toàn bộ tài khoản. Chỉ cần trạng thái tài khoản nào đó liên quan đến State Trie thay đổi, thì Gốc Merkle của State Trie – gọi là StateRoot – cũng sẽ thay đổi.
Trong tiêu đề khối của Ethereum, sẽ ghi lại StateRoot, đồng thời cũng ghi lại Gốc Merkle của cây giao dịch (gọi tắt là Txn Root). Sự khác biệt giữa cây giao dịch và cây trạng thái nằm ở dữ liệu đại diện cho các nút lá ở đáy. Ví dụ nếu khối thứ 100 chứa 300 giao dịch, thì các nút lá của cây giao dịch đại diện cho 300 giao dịch đó.
Sự khác biệt khác là kích thước dữ liệu tổng thể của State Trie rất lớn, các nút lá đáy tương ứng với tất cả địa chỉ trên mạng Ethereum (thực tế còn nhiều hash trạng thái lỗi thời), do đó tập dữ liệu gốc tương ứng với State Trie sẽ không được đăng tải vào khối, mà chỉ ghi lại StateRoot trong tiêu đề khối. Trong khi đó, tập dữ liệu gốc của cây giao dịch chính là dữ liệu giao dịch (Txn) trong từng khối, và TxnRoot của cây này sẽ được ghi vào tiêu đề khối.
Vì nút nhẹ chỉ nhận tiêu đề khối, chỉ biết StateRoot và TxnRoot, không thể suy ngược lại toàn bộ Cây Merkle từ Root (do tính chất của Cây Merkle và hàm băm), nên nút nhẹ không thể biết dữ liệu giao dịch bên trong khối, cũng không biết tài khoản nào trong State Trie đã thay đổi.
Nếu Vương Cường muốn chứng minh cho một nút nhẹ (tức Lý Cương vừa nói) rằng khối thứ 100 chứa một giao dịch nhất định, và nút nhẹ đã biết tiêu đề khối 100 cũng như TxnRoot, thì bài toán trở thành: chứng minh giao dịch đó tồn tại trên Cây Merkle tương ứng với TxnRoot. Lúc này, Vương Cường chỉ cần gửi Bằng chứng Merkle tương ứng là được.
Trong nhiều cầu nối xuyên chuỗi dựa trên phương án nút nhẹ, thường xuyên sử dụng tính gọn nhẹ và hiệu quả của nút nhẹ và Bằng chứng Merkle như vừa trình bày. Ví dụ, Map Protocol và các cầu ZK khác sẽ thiết lập một hợp đồng trên chuỗi ETH chuyên tiếp nhận tiêu đề khối từ các chuỗi khác (ví dụ Polygon). Khi Relayer gửi tiêu đề khối thứ 100 của Polygon lên hợp đồng trên ETH, hợp đồng sẽ xác minh tính hợp lệ của tiêu đề (ví dụ có đủ chữ ký từ 2/3 nút POS trong mạng Polygon hay chưa).
Nếu tiêu đề hợp lệ, và một người dùng tuyên bố rằng anh ta đã khởi tạo giao dịch xuyên chuỗi từ Polygon sang ETH, và giao dịch này đã được đóng gói vào khối thứ 100 của Polygon. Anh ta chỉ cần dùng Bằng chứng Merkle để chứng minh rằng giao dịch xuyên chuỗi mình khởi tạo khớp với TxnRoot trong tiêu đề khối 100 (nói cách khác, chứng minh rằng giao dịch xuyên chuỗi của mình có ghi chép trong khối 100 của Polygon). Tuy nhiên, các cầu ZK sẽ dùng bằng chứng không kiến thức (zero-knowledge proof) để nén lượng tính toán cần thiết khi xác minh Bằng chứng Merkle, từ đó giảm thêm chi phí xác minh cho hợp đồng cầu nối.
DA và vấn đề tấn công giữ lại dữ liệu
Sau khi đã trình bày về Cây Merkle, Gốc Merkle và Bằng chứng Merkle, giờ ta quay lại vấn đề DA và tấn công giữ lại dữ liệu như đã đề cập ở đầu bài viết. Vấn đề này đã được thảo luận từ trước năm 2017, và bài báo gốc của Celestia có khảo cứu nguồn gốc vấn đề DA. Bản thân Vitalik trong một tài liệu từ năm 2017-2018 đã đề cập rằng người tạo khối có thể cố ý che giấu một phần dữ liệu khối, phát hành khối không đầy đủ ra bên ngoài, điều này khiến các nút đầy đủ không thể xác minh tính đúng đắn của việc thực thi giao dịch/chuyển trạng thái.
Lúc này, người tạo khối có thể đánh cắp tài sản người dùng, ví dụ chuyển toàn bộ coin trong tài khoản A sang địa chỉ khác, nhưng các nút đầy đủ không thể xác định liệu A có thực sự làm vậy hay không, vì họ không biết dữ liệu giao dịch đầy đủ trong khối mới nhất.
Trên các blockchain công khai lớp 1 như Bitcoin hay Ethereum, các nút đầy đủ trung thực sẽ trực tiếp từ chối các khối vô hiệu như vậy. Nhưng nút nhẹ thì khác, họ chỉ nhận tiêu đề khối (Header) từ mạng, chỉ biết StateRoot và TxnRoot, chứ không biết liệu khối gốc tương ứng với Header và hai Root có hợp lệ hay không.
Trong sách trắng Bitcoin, thực tế đã có ý tưởng xử lý trường hợp này: Satoshi Nakamoto từng cho rằng đa số người dùng sẽ chạy nút nhẹ có yêu cầu cấu hình thấp hơn, và nút nhẹ không thể xác định khối có hợp lệ hay không; nếu một khối vô hiệu, các nút đầy đủ trung thực sẽ gửi cảnh báo tới nút nhẹ.
Tuy nhiên, Nakamoto chưa phân tích sâu hơn về giải pháp này. Sau này, Vitalik và Mustafa – nhà sáng lập Celestia – đã phát triển ý tưởng này, kết hợp với thành quả của những người đi trước, đưa vào khái niệm lấy mẫu dữ liệu DA (data sampling), đảm bảo các nút đầy đủ trung thực có thể tái tạo lại dữ liệu đầy đủ của mọi khối và phát cảnh báo khi cần thiết.
Bằng chứng gian lận của Plasma
Tóm lại, Plasma là một giải pháp mở rộng quy mô chỉ đăng tiêu đề khối Layer2 lên Layer1, còn dữ liệu DA (tập dữ liệu giao dịch đầy đủ/thay đổi trạng thái từng tài khoản) chỉ được phát hành ngoài chuỗi. Nói cách khác, Plasma giống như một cầu nối xuyên chuỗi dựa trên nút nhẹ: trên chuỗi ETH dùng hợp đồng để hiện thực nút nhẹ của Layer2. Khi người dùng tuyên bố rút tài sản từ L2 về L1, họ phải gửi Bằng chứng Merkle để chứng minh quyền sở hữu tài sản đó.
Logic xác minh việc rút tài sản từ L2 về L1 khá giống với cầu ZK đã nói trước đó, chỉ khác là mô hình cầu nối của Plasma dựa trên bằng chứng gian lận (fraud proof), thay vì bằng chứng ZK, và gần với khái niệm “cầu lạc quan” (optimistic bridge). Yêu cầu rút tiền từ L2 về L1 trong mạng Plasma sẽ không được xử lý ngay lập tức, mà có một “giai đoạn thách thức”. Mục đích của giai đoạn này sẽ được giải thích bên dưới.
Plasma không đặt yêu cầu nghiêm ngặt về việc phát hành dữ liệu/DA. Bộ sắp xếp (sequencer/Operator) chỉ phát tán từng khối L2 ngoài chuỗi, các nút muốn lấy khối L2 sẽ tự lấy. Sau đó, bộ sắp xếp sẽ đăng tiêu đề khối L2 lên Layer1. Ví dụ: sequencer trước tiên phát tán khối thứ 100 ngoài chuỗi, rồi mới đăng tiêu đề khối lên chuỗi. Nếu khối 100 chứa giao dịch vô hiệu, bất kỳ nút Plasma nào cũng có thể trước khi kết thúc “giai đoạn thách thức”, gửi Bằng chứng Merkle lên hợp đồng trên ETH để chứng minh tiêu đề khối 100 liên kết đến một giao dịch vô hiệu, đây là một tình huống điển hình của bằng chứng gian lận.
Các tình huống ứng dụng bằng chứng gian lận của Plasma còn bao gồm:
1. Giả sử tiến độ mạng Plasma đã đến khối thứ 200, lúc này người dùng A tuyên bố rút tiền, nói rằng ở khối 100 anh ta có 10 ETH. Nhưng thực tế, sau khối 100, A đã tiêu hết số ETH đó.
Do đó, hành vi của A thực chất là: sau khi đã tiêu 10 ETH, lại tuyên bố rằng trước đó anh ta từng có 10 ETH và cố gắng rút số tiền này đi. Đây là kiểu “rút tiền kép” điển hình, hay còn gọi là double-spend. Lúc này, bất kỳ ai cũng có thể gửi Bằng chứng Merkle để chứng minh tình trạng tài sản mới nhất của A không đáp ứng yêu cầu rút tiền, tức chứng minh rằng A không còn số tiền đó sau khối 100 (các phương án Plasma khác nhau có cách chứng minh khác nhau cho trường hợp này, mô hình địa chỉ tài khoản phức tạp hơn nhiều so với chứng minh double-spend theo mô hình UTXO).
2. Nếu là phương án Plasma theo mô hình UTXO (trước đây chủ yếu là loại này), tiêu đề khối không chứa StateRoot, chỉ có TxnRoot (UTXO không hỗ trợ mô hình địa chỉ tài khoản như Ethereum, cũng không có thiết kế trạng thái toàn cục như State Trie). Nói cách khác, chuỗi dùng mô hình UTXO chỉ có ghi chép giao dịch, không có ghi chép trạng thái.
Lúc này, chính bộ sắp xếp có thể phát động tấn công double-spend, ví dụ dùng lại một UTXO đã bị tiêu, hoặc tạo thêm UTXO từ hư không cho một người dùng nào đó. Bất kỳ người dùng nào cũng có thể gửi Bằng chứng Merkle để chứng minh UTXO đó từng xuất hiện trong các khối trước (đã bị tiêu), hoặc chứng minh nguồn gốc lịch sử của UTXO đó có vấn đề.
3. Đối với các phương án Plasma tương thích EVM/hỗ trợ State Trie, bộ sắp xếp có thể nộp StateRoot vô hiệu. Ví dụ, sau khi thực thi các giao dịch trong khối 100, StateRoot lẽ ra phải chuyển thành ST+, nhưng bộ sắp xếp lại nộp lên Layer1 là ST-.
Bằng chứng gian lận trong trường hợp này khá phức tạp, cần phát lại các giao dịch trong khối 100 trên chuỗi Ethereum, lượng tính toán và tham số đầu vào sẽ tiêu tốn rất nhiều gas. Các nhóm phát triển Plasma ban đầu khó thực hiện bằng chứng gian lận phức tạp như vậy, nên phần lớn chọn mô hình UTXO, bởi bằng chứng gian lận dựa trên UTXO rất gọn nhẹ và dễ triển khai (Rollup đầu tiên triển khai bằng chứng gian lận là Fuel, cũng dựa trên UTXO).
Giữ lại dữ liệu và Trò chơi rút tiền (Exit Game)
Tất nhiên, các bằng chứng gian lận nêu trên chỉ có hiệu lực khi DA/dữ liệu được phát hành hợp lệ. Nếu bộ sắp xếp giữ lại dữ liệu, không phát hành đầy đủ khối ngoài chuỗi, các nút Plasma sẽ không thể xác minh tiêu đề khối trên Layer1 có hợp lệ hay không, và dĩ nhiên không thể đưa ra bằng chứng gian lận một cách thuận lợi.
Lúc này, bộ sắp xếp có thể đánh cắp tài sản người dùng, ví dụ tự tiện chuyển toàn bộ coin trong tài khoản A sang tài khoản B, rồi từ B chuyển cho C, cuối cùng dùng danh nghĩa C để rút tiền. Tài khoản B và C thuộc sở hữu của bộ sắp xếp, giao dịch B->C dù công khai cũng chẳng sao; nhưng bộ sắp xếp có thể giữ lại dữ liệu giao dịch vô hiệu A->B, khiến người khác không thể chứng minh nguồn gốc tài sản của B và C có vấn đề (để chứng minh nguồn gốc tài sản của B có vấn đề, cần chỉ ra rằng giao dịch chuyển tiền cho B có chữ ký số sai).
Các phương án Plasma dựa trên UTXO có biện pháp đối phó, ví dụ bất kỳ ai rút tiền đều phải nộp toàn bộ lịch sử nguồn gốc tài sản, sau này còn có nhiều cải tiến hơn. Nhưng nếu là phương án Plasma tương thích EVM, sẽ rất bất lực trong khía cạnh này. Vì nếu liên quan đến giao dịch hợp đồng, việc xác minh quá trình chuyển trạng thái trên chuỗi sẽ phát sinh chi phí khổng lồ, do đó Plasma hỗ trợ mô hình địa chỉ tài khoản và hợp đồng thông minh khó triển khai phương án xác minh tính hợp lệ khi rút tiền.
Hơn nữa, bỏ qua chủ đề trên, dù là Plasma dựa trên UTXO hay mô hình địa chỉ tài khoản, một khi xảy ra giữ lại dữ liệu, về cơ bản đều gây hoảng loạn, vì bạn không biết bộ sắp xếp đã thực thi những giao dịch nào. Các nút Plasma sẽ cảm thấy bất thường, nhưng lại không thể đưa ra bằng chứng gian lận cụ thể, vì dữ liệu cần cho bằng chứng gian lận không được bộ sắp xếp Plasma phát hành.
Lúc này, người ta chỉ nhìn thấy tiêu đề khối tương ứng, mà không biết bên trong khối có gì, không biết tài sản tài khoản mình đã biến thành thế nào, mọi người sẽ đồng loạt đưa ra tuyên bố rút tiền, dùng Bằng chứng Merkle tương ứng với khối lịch sử để cố rút tiền, dẫn đến tình huống cực đoan gọi là “Trò chơi rút tiền” (Exit Game), gây ra hiện tượng “giẫm đạp”, khiến Layer1 tắc nghẽn nghiêm trọng và vẫn khiến một số người thiệt hại tài sản (những người không nhận được thông báo từ nút trung thực hoặc không theo dõi Twitter sẽ hoàn toàn không biết bộ sắp xếp đang ăn cắp tiền).
Vì vậy, Plasma là một giải pháp mở rộng quy mô Layer2 không đáng tin cậy, một khi xảy ra tấn công giữ lại dữ liệu sẽ kích hoạt “Exit Game”, dễ khiến người dùng chịu tổn thất, đây là một trong những lý do chính khiến nó bị bỏ rơi.
Lý do Plasma khó hỗ trợ hợp đồng thông minh
Sau khi đã trình bày về Exit Game và vấn đề giữ lại dữ liệu, giờ ta xem xét lý do Plasma khó hỗ trợ hợp đồng thông minh, chủ yếu có hai nguyên nhân:
Thứ nhất, nếu là tài sản từ hợp đồng DeFi, thì ai sẽ là người rút lên Layer1? Vì thực chất đây là việc di chuyển trạng thái hợp đồng từ Layer2 lên Layer1. Giả sử một người gửi 100 ETH vào pool LP của một DEX, sau đó bộ sắp xếp Plasma làm điều ác, mọi người cần rút tiền khẩn cấp, lúc này 100 ETH của người dùng vẫn đang do hợp đồng DEX kiểm soát. Vậy thì ai sẽ là người rút số tài sản này lên Layer1?
Cách tốt nhất dường như là để người dùng trước tiên rút tài sản khỏi DEX, rồi tự họ rút tiền lên L1. Nhưng vấn đề là bộ sắp xếp Plasma đã làm điều ác, có thể隨時 từ chối yêu cầu của người dùng.
Vậy nếu chúng ta trước đó cấp quyền Owner cho hợp đồng DEX, cho phép anh ta trong tình huống khẩn cấp rút tài sản hợp đồng lên L1 thì sao? Rõ ràng điều này sẽ trao quyền sở hữu tài sản công cộng cho Owner hợp đồng, anh ta có thể随时 rút tài sản này lên L1 và bỏ trốn, điều này thật quá đáng sợ?
Rõ ràng, việc xử lý “tài sản công cộng” do hợp đồng DeFi kiểm soát là một quả bom nổ chậm. Điều này thực chất liên quan đến vấn đề phân bổ quyền lực công cộng. Trước đây, Xiang Ma từng đề cập điều này trong phỏng vấn mang tên “Blockchain công suất cao khó tạo chuyện mới, hợp đồng thông minh liên quan đến phân bổ quyền lực”.
Thứ hai, nếu không cho phép hợp đồng di chuyển trạng thái, sẽ khiến nó chịu tổn thất nặng; nếu cho phép hợp đồng tự di chuyển trạng thái lên Layer1, sẽ xuất hiện tình trạng rút tiền kép mà bằng chứng gian lận Plasma khó giải quyết:
Ví dụ, giả sử Plasma áp dụng mô hình địa chỉ tài khoản của Ethereum, hỗ trợ hợp đồng thông minh, có một máy trộn tiền hiện đang giữ 100 ETH, Owner của máy trộn do Bob kiểm soát;
Giả sử Bob ở khối 100 rút 50 ETH từ máy trộn. Sau đó Bob đưa ra tuyên bố rút tiền, chuyển 50 ETH này lên Layer1;
Sau đó, Bob dùng bản chụp trạng thái hợp đồng trong quá khứ (ví dụ khối 70) để di chuyển trạng thái cũ của máy trộn lên Layer1, điều này sẽ chuyển cả 100 ETH mà máy trộn "từng sở hữu" lên Layer1;
Rõ ràng, đây là kiểu “rút tiền kép” điển hình, hay còn gọi là double-spend. Bob đã rút tổng cộng 150 ETH lên Layer1, nhưng mạng Layer2 chỉ nhận được 100 ETH từ người dùng gửi vào máy trộn/Bob, có 50 ETH bị rút đi từ hư không. Điều này dễ dàng rút cạn quỹ dự trữ của Plasma. Về lý thuyết, người ta có thể đưa ra bằng chứng gian lận để chứng minh trạng thái hợp đồng máy trộn đã thay đổi sau khối 70.
Nhưng giả sử sau khối 70, mọi giao dịch tương tác với hợp đồng máy trộn đều không thay đổi trạng thái hợp đồng, ngoại trừ giao dịch Bob rút 50 ETH; nếu bạn muốn đưa ra bằng chứng rằng trạng thái hợp đồng máy trộn đã thay đổi sau khối 70, bạn phải chạy lại tất cả các giao dịch này trên chuỗi Ethereum, cuối cùng mới khiến hợp đồng Plasma xác nhận rằng trạng thái hợp đồng máy trộn thực sự đã thay đổi (sự phức tạp này do cấu trúc bản thân Plasma quyết định). Nếu số lượng giao dịch này rất lớn, bằng chứng gian lận cơ bản không thể đăng lên Layer1 (vượt quá giới hạn gas của một khối Ethereum).
Về mặt lý thuyết, trong tình huống double-spend trên, dường như chỉ cần nộp bản chụp trạng thái hiện tại của máy trộn (thực chất là bằng chứng Merkle tương ứng StateRoot) là được. Nhưng thực tế, do Plasma không đăng dữ liệu giao dịch trên chuỗi, hợp đồng không thể xác định bản chụp trạng thái bạn nộp có hợp lệ hay không. Bởi vì bộ sắp xếp có thể tự phát động giữ lại dữ liệu, nộp bản chụp trạng thái vô hiệu, vu khống bất kỳ người rút tiền nào.
Ví dụ, khi bạn tuyên bố tài khoản mình có 50 ETH và yêu cầu rút tiền, bộ sắp xếp có thể tự tiện đặt số dư tài khoản bạn về 0, rồi phát động giữ lại dữ liệu, nộp một StateRoot vô hiệu lên chuỗi cùng bản chụp trạng thái tương ứng, buộc tội bạn không có tiền. Lúc này mọi người không thể chứng minh StateRoot và bản chụp trạng thái mà bộ sắp xếp nộp là vô hiệu, vì anh ta đã phát động giữ lại dữ liệu, bạn không nhận được đủ dữ liệu cần thiết cho bằng chứng gian lận.
Để ngăn chặn tình huống này, khi nút Plasma đưa ra bản chụp trạng thái để chứng minh ai đó double-spend, họ còn phải phát lại toàn bộ giao dịch trong khoảng thời gian đó, nhằm ngăn bộ sắp xếp dùng giữ lại dữ liệu để cản trở người khác rút tiền. Trong khi đó, với Rollup, nếu gặp tình huống rút tiền kép như trên, về lý thuyết không cần phát lại giao dịch lịch sử, vì Rollup không có vấn đề giữ lại dữ liệu, sẽ “bắt buộc” bộ sắp xếp đăng dữ liệu DA lên chuỗi. Nếu bộ sắp xếp Rollup nộp StateRoot/bản chụp trạng thái vô hiệu, hoặc sẽ không qua được xác minh hợp đồng (ZK Rollup), hoặc sẽ sớm bị thách thức (OP Rollup).
Thực tế, ngoài ví dụ máy trộn tiền vừa nêu, các trường hợp như hợp đồng đa chữ ký cũng có thể dẫn đến rút tiền kép trên mạng Plasma. Mà hiệu quả xử lý của bằng chứng gian lận đối với các tình huống này rất thấp. Diễn đàn ETH Research đã có phân tích về trường hợp này.
Tóm lại, vì giải pháp Plasma bất lợi cho hợp đồng thông minh, cơ bản không hỗ trợ việc di chuyển trạng thái hợp đồng lên Layer1, các giải pháp Plasma phổ biến đành chọn cơ chế UTXO hoặc tương tự, bởi UTXO không có vấn đề xung đột quyền sở hữu tài sản, đồng thời hỗ trợ rất tốt bằng chứng gian lận (kích thước nhỏ hơn nhiều), nhưng đổi lại là phạm vi ứng dụng đơn điệu, cơ bản chỉ hỗ trợ chuyển tiền hoặc sàn giao dịch sổ lệnh.
Hơn nữa, do bản thân bằng chứng gian lận phụ thuộc mạnh vào dữ liệu DA, nếu lớp DA không đáng tin cậy, sẽ khó xây dựng hệ thống bằng chứng gian lận hiệu quả. Trong khi Plasma xử lý vấn đề DA quá sơ sài, không thể giải quyết tấn công giữ lại dữ liệu, cùng với sự trỗi dậy của Rollup, Plasma dần dần mờ nhạt khỏi sân khấu lịch sử.
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
