Trong thế giới thực, gần như mọi tòa nhà chọc trời đều có một yếu tố không thể thiếu: lối thoát hiểm. Khi các sự kiện không lường trước như hỏa hoạn hoặc động đất xảy ra, những lối thoát này là cứu cánh đối với an toàn của người dân. Tương tự, trong hệ sinh thái Layer 2 của Ethereum, nơi giữ hàng tỷ đô la trong tài sản, tính năng “rút tiền bắt buộc” cho phép người dùng đưa tài sản một cách an toàn trở lại Layer 1 đã trở thành một cơ sở quan trọng.

Vitalik cũng nhấn mạnh trong bài viết gần đây của mình “Các Loại Layer 2 Khác Nhau” rằng khả năng cho người dùng rút tài sản một cách mượt mà từ Layer 2 về Layer 1 là một chỉ số an toàn rất quan trọng.

Tuy nhiên, vấn đề "rút tiền suôn sẻ" dường như đã bị hầu hết bỏ qua trong quá khứ và nhiều nhóm dự án Lớp 2 đã không thực hiện chức năng "rút tiền bắt buộc" hoặc "thoát hiểm". Trong thời đại mà hệ sinh thái Lớp 2 chưa trưởng thành, việc bỏ qua "rút tiền không được phép" dường như không phải là vấn đề. Nhưng giờ đây, với việc Lớp 2 xử lý hơn 12 tỷ đô la tài sản, nó đã trở thành một tòa nhà chọc trời "quá lớn để thất bại". Việc không có lối thoát an toàn trong một tòa nhà cao chót vót như vậy là không thể tưởng tượng được.

Với mục đích nâng cao nhận thức của độc giả về các rủi ro an toàn của Layer 2, "Geek Web3" sẽ sử dụng Loopring Protocol V3 và Arbitrum làm ví dụ trong văn bản sau để giải thích tại sao "các chức năng rút tiền không được phép" như rút bắt buộc và thoát hiểm là thành phần không thể thiếu của Layer 2.

(Theo trình duyệt L2BEAT dYdX, cho đến nay, chức năng giao dịch/rút tiền bắt buộc của dYdX đã được sử dụng tổng cộng 152 lần, với số lần rút tiền lớn vượt quá một triệu đô la lên đến 7 trường hợp) Khả năng chống kiểm duyệt là một vấn đề lớn: Imagine nếu Sequencer cố ý từ chối yêu cầu của bạn?

Các bài viết khoa học phổ biến trước đây về Layer 2 thường có một vấn đề: chúng chủ yếu nhấn mạnh vào “an ninh” và “dễ sử dụng” một cách nông cạn nhưng bỏ qua “khả năng chống kiểm duyệt”. Ngay cả khi thảo luận về các giải pháp sequencer phi tập trung, điều mà nhiều người chú ý là MEV có phải là phi tập trung hay không, thay vì cải thiện khả năng chống kiểm duyệt.

Nói cách khác, hầu hết mọi người thường tập trung vào việc xem liệu sự chuyển tiếp trạng thái trong Layer 2 có hiệu quả, liệu người ghi có thể đánh cắp tiền, và liệu hệ thống chứng minh gian lận/chứng minh tính hợp lệ có được áp dụng hay không. Tuy nhiên, họ bỏ qua một rủi ro không nên bỏ qua: Điều gì sẽ xảy ra nếu người ghi liên tục từ chối yêu cầu giao dịch của bạn, hoặc đơn giản là gặp sự cố trong một khoảng thời gian kéo dài, hoặc thậm chí là đóng cửa?

Đáng chú ý rằng trong thời gian Solana tạm ngừng hoạt động, đã có những trường hợp mà người dùng không thể thêm tài sản đảm bảo kịp thời do rủi ro thanh lý tài sản, dẫn đến hàng triệu đô la tài sản bị đe dọa. Những tình huống từ chối yêu cầu của người dùng như vậy có thể dẫn đến mất mát kinh tế đáng kể.

Mặc dù chỉ một số cá nhân có thể gặp phải tình huống như vậy, nhưng nếu điều này xảy ra với một số ‘cá voi’ nắm giữ số lượng lớn tiền, toàn bộ thị trường có thể chịu tổn thất. Ví dụ, giả sử có ai đó với hàng trăm triệu đô la tài sản trong một giao thức cho vay DeFi trên Ethereum đối mặt với việc thanh lý trong vòng một tuần nhưng bị trừng phạt bởi OFAC do sử dụng Tornado. Hầu hết số tiền của họ đang ở trên Optimism (OP), và OP Sequencer, tuân thủ với OFAC, từ chối yêu cầu của họ.

Hãy chiếu vấn đề này lên các blockchain độc lập như Avalanche hoặc Polygon, hoàn toàn riêng biệt với Ethereum. Nếu hơn hai phần ba số nút đồng thuận của Validator trên Avalanche quyết định tiến hành kiểm tra giao dịch đối với bạn, họ có thể từ chối bao gồm các giao dịch của bạn vào một khối hoặc từ chối công nhận một khối chứa các giao dịch của bạn. Trong trường hợp này, số tiền của bạn về cơ bản bị chôn vùi trong chuỗi này và không thể rút ra:

Trừ khi bạn có thể thuyết phục một số Validators để có ít hơn hai phần ba tham gia vào cuộc tấn công kiểm tra, hoặc bạn có thể kêu gọi mọi người đồng thuận xã hội để phân nhánh Avalanche. Rõ ràng, vào thời điểm này, bạn vẫn có cách để rút tiền nhanh chóng từ Avalanche. Tuy nhiên, chúng ta phải xem xét rằng mất thời gian cho hơn hai phần ba của Validators để đoàn kết và khởi xướng một cuộc tấn công kiểm tra đối với một địa chỉ cụ thể, cung cấp cho người dùng bị kiểm tra đủ thời gian để 'thoát ra'.

Nhưng tình hình có thể hoàn toàn khác trên Lớp 2. Trình tự trên Lớp 2 thường được điều hành bởi nhóm chính thức. Nếu một Sequencer muốn khởi động một cuộc tấn công giám sát chống lại bạn, nó có thể 'đóng băng tiền của bạn trên Lớp 2', từ chối hiệu quả yêu cầu chuyển tài sản của bạn từ L2 sang L1. Theo cơ chế hoạt động của L2, nếu bạn không thể bỏ qua Sequencer để thực hiện rút tiền, Sequencer hoàn toàn có thể đóng băng tài sản của bạn trên L2, ngăn chặn việc chuyển tiền của chúng.

Vậy, làm thế nào để giải quyết vấn đề này? Đơn giản là làm thế nào chúng ta có thể triển khai một chức năng rút tiền 'không cần phép' cho phép người dùng rút tài sản của họ về Lớp 1 một cách an toàn ngay cả khi bị kiểm tra bởi Một Sequencer hoặc một nhóm dự án Lớp 2? Một số nhóm dự án đã đề xuất ý tưởng về Sequencers phi tập trung, nhưng đây chỉ là một giải pháp nông cạn. Nếu những Sequencers giới hạn này kết hợp để kiểm tra bạn, họ vẫn có thể 'đóng băng' tài sản của bạn. Hơn nữa, vấn đề của các cuộc tấn công chống Sybil trong các nút Proof of Stake (PoS) cũng là một vấn đề (như đã thấy trong sự cố Multichain).

Giải pháp hiệu quả nhất là thiết lập một 'lối thoát' dành riêng trên blockchain Layer 1, cho phép người dùng rút tiền từ Layer 2 thông qua lối thoát L1 này trong trường hợp họ không nhận được phản hồi từ Sequencer trong một khoảng thời gian dài.

Trong ngữ cảnh của phiên bản 3 của Giao thức Loopring, nó chỉ ra hai kịch bản khác nhau cho việc rút tiền ép buộc do người dùng khởi xướng. Kịch bản đầu tiên như sau:

Người dùng có thể trực tiếp khởi tạo việc rút bắt buộc trên Lớp 1 bằng cách sử dụng hàm forcedWithdraw trong hợp đồng ExchangeV3. Họ cần khai báo tài khoản Lớp 2 của họ trong Giao thức Loopring và Token mà họ muốn rút. Sau đó, hợp đồng ExchangeV3 phát ra một sự kiện blockchain, báo hiệu rằng có ai đó đã khởi tạo một yêu cầu rút bắt buộc. Khi tất cả các nút trong Giao thức Loopring, bao gồm cả Sequencer, chạy trên khách hàng Geth, họ sẽ được thông báo về việc rút bắt buộc và sự kiện blockchain tương ứng từ dữ liệu khối Ethereum.

Lưu ý rằng việc rút bắt buộc không được xử lý ngay lập tức, mà được đặt trong hàng đợi pendingForcedWithdrawals, chờ xử lý. Khi nhận thấy một rút bắt buộc được khởi tạo trên Layer 1, Sequencer thường kích hoạt hàm Process trong hợp đồng ExchangeV3 trong vòng 15 ngày. Hàm này thực hiện việc chuyển token trên chuỗi Ethereum cho người khởi tạo rút (từ địa chỉ gửi tiền của dự án Layer 2 trên chuỗi Ethereum đến người rút).

Nếu Sequencer không phản hồi yêu cầu rút lui bắt buộc của người dùng trong vòng 15 ngày, người dùng có thể gọi hàm notifyForcedRequestTooOld. Hành động này khuyến khích hợp đồng ExchangeV3 phát ra sự kiện có tên WithdrawalModeActivated, thông báo cho tất cả các nút trong Giao thức Loopring rằng chế độ thanh lý phá sản đã được kích hoạt.

Nếu chế độ thanh lý phá sản được kích hoạ, Giao thức V3 của Loopring sẽ ngừng nhận các khối L2 mới được gửi bởi Sequencer, điều này có nghĩa là toàn bộ Giao thức Loopring sẽ ngừng hoạt động vào thời điểm này. Quá trình này sẽ kéo dài ít nhất 30 ngày.

Tuy nhiên, trong chặn khến phá sản, người dùng về cờ về tài sản của hệ thống trên Layer1, nhưng hầu như hầu hết cần phải nổ một chứng minh merkle để chứng minh tình trạng/tình trạng tài sản của hệ thống, điều này có thể được kiểm tra trên cây trạng thái L2. (Chỉ minh rằng số dư tài sản của bạn trong Layer 2 không khác biệt với số tiền bạn tuyên bộ khi bạn khởi tạo việc rút tử.)

Bài viết mô tả mô hình thanh lý phá sản của Giao thức Loopring, còn được biết đến với cơ chế “Escape Hatch” trên L2BEAT. Mô hình này được kích hoạt trong các điều kiện nhất định, như khi bộ sắp xếp không đáp ứng yêu cầu rút bắt buộc của người dùng trong thời gian quy định, hoặc nếu Bộ sắp xếp gặp sự cố hoặc tắt dài hạn. Trong những trường hợp như vậy, người dùng có thể kích hoạt thủ công một quy trình đưa hợp đồng Rollup vào trạng thái đóng băng hoặc tạm dừng. Người dùng sau đó có thể xây dựng Chứng minh Merkle để chứng minh tình hình tài sản của họ trên Layer 2 và rút phần tài sản của họ từ địa chỉ gửi tiền của dự án Layer 2 trên Layer 1.

Trong tài liệu StarkEx, có một biểu đồ cụ thể minh họa quá trình này. Nếu yêu cầu Rút Bắt Buộc của người dùng Layer 2 được nộp trên Layer 1 mà không nhận được phản hồi từ bộ xếp hạng trong khoảng thời gian 7 ngày, người dùng có thể kích hoạt chức năng Yêu Cầu đóng băng để khởi động một giai đoạn đóng băng cho Layer 2. Trong thời gian này, bộ xếp hạng Layer 2 không thể cập nhật trạng thái của Layer 2 trên Layer 1. Trạng thái đóng băng của Layer 2 kéo dài một năm trước khi có thể được mở đóng băng. Sau đó, người dùng có thể nộp chứng minh Merkle và rút tiền của họ.

Nhưng để xây dựng một Bằng chứng Merkle, người ta cần trước hết thu được toàn bộ cây trạng thái L2, điều này có nghĩa là cần có dữ liệu từ một nút đầy đủ L2. Ngoài ra, cần một đoạn mã cụ thể để tạo ra Bằng chứng Merkle, rõ ràng đòi hỏi một mức độ rào cản kỹ thuật nhất định. Để thuận tiện cho đa số người dùng, L2BEAT trước đó đã tuyên bố rằng Layer 2 nên thiết lập một loạt các nút đầy đủ có sẵn và mã nguồn mở, để giúp người dùng thu được trạng thái của tất cả các tài khoản trên L2 (bao gồm cân bằng, số giao dịch, v.v.). Bước này cũng nhấn mạnh tầm quan trọng của cơ chế rút tiền bắt buộc và cơ chế thoát.

Tính năng 'Bao Gồm Giao Dịch Bắt Buộc' của Arbitrum

Tuy nhiên, buộc phải rút / thoát khỏi pod dường như không phải là giải pháp chống kiểm duyệt duy nhất. Ví dụ: Arbitrum sử dụng phương pháp 'bao gồm giao dịch bắt buộc', trong đó người dùng trước tiên có thể gửi các giao dịch / rút tiền cần được xử lý bởi Trình sắp xếp vào hợp đồng Hộp thư đến bị trì hoãn trên Lớp 1 (L1). Nếu Sequencer không xử lý chúng trong vòng 24 giờ, người dùng có thể gọi hàm Inclusion bắt buộc trên hợp đồng Hộp thư đến L1 Sequencer, cho phép giao dịch được đưa trực tiếp vào chuỗi giao dịch của Arbitrum (bằng cách đưa ra một sự kiện trên chuỗi thông báo cho các nút Arbitrum rằng một số giao dịch được ghi lại trên Hộp thư đến bị trì hoãn cần được đưa vào sổ cái L2).

Đoạn văn thảo luận về các phương pháp của các giao thức blockchain khác nhau trong xử lý giao dịch, tập trung đặc biệt vào Arbitrum so với Loopring và StarkEx. Đây là bản dịch:

"So với các phương pháp khác, phương pháp của Arbitrum đơn giản hơn một chút, nhưng vẫn có nhược điểm. Nó chỉ đơn giản là phát ra một sự kiện trên chuỗi để thông báo cho các nút Arbitrum rằng một số giao dịch bị bỏ qua bởi bộ sắp xếp cần được bao gồm trong chuỗi dài nhất của L2, không giống như giao thức Loopring và chế độ phá sản/escape pod của StarkEx, cho phép người dùng rút tiền trực tiếp trên L1. Nếu các nút thách thức trong Arbitrum thông đồng để tiến hành một cuộc tấn công kiểm duyệt, có vẻ có khả năng đóng băng các khoản tiền của người dùng trên L2."

Do đó, cơ chế bắt buộc của Arbitrum không hoàn toàn không cần sự cho phép. Mặc dù một nút trung thực có thể xuất bản bằng chứng gian lận để chỉ ra yêu cầu bắt buộc của người dùng bị bỏ qua bởi trình tự viên, điều này vẫn giới thiệu một mức độ giả định về sự tin tưởng, mặc dù là một phần nhỏ.

Cụ thể hơn, 'các giao dịch cần phải bắt buộc bao gồm' phải được ít nhất một nút thách thức ARB công nhận. Hiện tại, có chín nút này, và họ có quyền quyết định những thông điệp chéo chuỗi giữa L2 và L1 nào được chấp nhận, và họ cũng là những người duy nhất có thể phát ra bằng chứng gian lận. Nếu chín nút này âm mưu cùng nhau, họ có thể lý thuyết hủy bỏ một 'giao dịch bắt buộc' của người dùng.

Do đó, các giao dịch bao gồm hoặc rút tiền hiện tại trong Arbitrum không phải là hoàn toàn không cần sự cho phép như chế độ thanh lý phá sản của Loopring và StarkEx. Tuy nhiên, L2BEAT vẫn đánh giá cao phương pháp này từ Arbitrum. Trong tương lai, Arbitrum sẽ ra mắt một cơ chế xuất bản chứng minh gian lận không cần sự cho phép mang tên BOLD, khiến cho việc các nút đối thủ lập âm mưu trở nên khó khăn, nếu không phải là không thể (điều này đã khó khăn ngay bây giờ).

Theo dữ liệu từ L2BEAT, hiện tại, các nền tảng Layer 2 (L2) với Tổng Giá Trị Khóa (TVL) vượt quá 50 triệu USD, không cung cấp biện pháp để giải quyết sự cố Sequencer Failure hoặc Proposer Failure, bao gồm OP Mainnet, Base, zkSync Era, Mantle, Starknet, Linea, Polygon zkEVM và Metis. Các nền tảng L2 này có thể, trong trường hợp cực kỳ, dẫn đến tài sản của người dùng bị đóng băng và không thể rút khỏi L2.

Do đó, rõ ràng là cần có cơ chế như rút tiền ép buộc hoặc chế độ thanh lý phá sản. Mặc dù hiện nay, chúng chủ yếu dựa vào lý thuyết trò chơi giữa người dùng và người sắp xếp (người tạo đơn), và không thể coi là thực sự 'rút bất kỳ lúc nào' (Arbitrum có độ trễ 24 giờ có thể thất bại, Loopring có độ trễ lên đến 15 ngày, StarkEx có độ trễ tối đa 7 ngày), nhưng có cơ chế này rõ ràng tốt hơn là không có chúng. Vấn đề về độ trễ trong việc rút tiền ép buộc có thể được giải quyết trong tương lai với các thiết kế cơ chế phức tạp hơn. Các thiết kế hiện tại xem xét khai thác MEV (Giá trị rút trích tối đa) tiềm năng thông qua forceInclusion, đòi hỏi sự giới thiệu của độ trễ. Để biết thêm chi tiết, cần tham khảo tài liệu chính thức từ các dự án L2 khác nhau.

Với sự bao gồm ngày càng nhiều Sequencers phi tập trung trong nhiều lộ trình L2 và nỗ lực liên tục từ các tổ chức như Ethereum Foundation, do Vitalik Buterin dẫn đầu, để giáo dục mọi người về tính an toàn của Layer 2, các tính năng như chức năng giao dịch chống kiểm duyệt trong việc rút tiền buộc sẽ có khả năng thu hút nhiều sự chú ý hơn. Điều này sẽ đưa hệ sinh thái Ethereum Layer 2 gần hơn với cơ sở hạ tầng tài chính chống kiểm duyệt, trung gian tối thiểu. Nếu Layer 2 đạt được cách thức tối thiểu hóa niềm tin trong việc chuyển tiền vào và ra, dự kiến sẽ có nhiều nhà tạo lập thị trường và nhà cung cấp thanh khoản tham gia hạ tầng L2, đẩy mạnh một bước tiến về việc áp dụng rộng rãi của web3.

Tuyên bố:

1. Bài viết này được sao chép từ [ Faust, Web3 của những người đam mê công nghệ]. Tất cả bản quyền thuộc về tác giả gốc [Faust, Web3 của những người đam mê công nghệ]. Nếu có ý kiến ​​phản đối về việc tái bản này, vui lòng liên hệ với Cổng Họcđội ngũ, và họ sẽ xử lý nó ngay lập tức.
2. Miễn trừ trách nhiệm: Các quan điểm và ý kiến được thể hiện trong bài viết này chỉ thuộc về tác giả và không cấu thành bất kỳ lời khuyên đầu tư nào.
3. Các bản dịch của bài viết sang các ngôn ngữ khác được thực hiện bởi nhóm Gate Learn. Trừ khi được nêu, việc sao chép, phân phối hoặc đạo văn các bài viết dịch là không được cho phép.