Các chức năng rút tiền bắt buộc và thoát hiểm quan trọng như thế nào đối với Lớp 2?

Tác giả: Faust, Geek Web3

Trong thế giới thực, hầu hết mọi tòa nhà cao tầng đều có một thành phần không thể thiếu: lối thoát hiểm an toàn. Khi các trường hợp khẩn cấp như hỏa hoạn và động đất rơi xuống, lối thoát hiểm an toàn là cứu cánh để đảm bảo an toàn cho cuộc sống của người dân. Trong hệ thống nền tảng lưu ký Ethereum Lớp 2, mang tài sản hàng chục tỷ đô la, chức năng “rút tiền bắt buộc”, cho phép người dùng rút tài sản một cách an toàn sang Lớp 1, đã trở thành một phương tiện không thể thiếu và cần thiết.

Trong bài viết gần đây của mình “Các loại lớp 2 khác nhau”, Vitalik cũng nhấn mạnh rằng khả năng người dùng rút tài sản suôn sẻ từ Lớp 2 sang Lớp 1 là một chỉ số bảo mật rất quan trọng.

Tuy nhiên, vấn đề “rút tiền suôn sẻ” dường như không nhận được nhiều sự quan tâm của hầu hết mọi người trong quá khứ, thậm chí nhiều dự án Layer 2 chưa ra mắt chức năng “rút tiền bắt buộc” hay “escape pod”. Trong thời đại mà hệ sinh thái L2 chưa phát triển mạnh mẽ, 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 bây giờ Lớp 2 có tài sản hơn 12 tỷ đô la, nó đã trở thành một tòa nhà “quá lớn để thất bại”. Nếu một tòa nhà chọc trời như vậy không có lối thoát an toàn, hậu quả đơn giản là không thể tưởng tượng được.

Với mục đích khiến người đọc chú ý đến các rủi ro bảo mật của Layer 2, “Geek Web3” sẽ lấy Loopring Protocol V3 và Arbitrum làm ví dụ dưới đây để giải thích tại sao “chức năng rút tiền không được phép” như rút cưỡng bức và thoát hiểm là một phần không thể thiếu của Layer 2.

(Theo trình duyệt L2BEAT dYdX, chức năng giao dịch / rút tiền bắt buộc dYdX đã được sử dụng 152 lần cho đến nay và đã có 7 lần rút tiền lớn hơn 1 triệu đô la.)

Chống kiểm duyệt là vấn đề lớn: Phải làm gì nếu trình tự cố tình từ chối yêu cầu của bạn ****

Trước đây, các bài báo khoa học phổ biến về Lớp 2 thường có một vấn đề, đó là hầu hết thời gian họ tập trung vào “bảo mật” và “khả năng sử dụng” trên bề mặt, nhưng bỏ qua “khả năng chống kiểm duyệt”. Ngay cả khi nói về các giải pháp giải trình tự phi tập trung, nhiều người chú ý đến việc MEV có phi tập trung hay không, không phải chống kiểm duyệt.

Nói cách khác, hầu hết mọi người có xu hướng tập trung vào việc chuyển đổi trạng thái Lớp 2 có hợp lệ hay không, liệu trình sắp xếp trình tự có thể ăn cắp tiền hay không và liệu hệ thống bằng chứng gian lận / hợp lệ có được sử dụng hay không, nhưng họ bỏ qua một rủi ro không nên bỏ qua: điều gì sẽ xảy ra nếu Sequencer tiếp tục từ chối các yêu cầu giao dịch của bạn, hoặc đơn giản là thất bại trong một thời gian dài, hoặc thậm chí bị hỏng? **

Bạn biết đấy, trong thời gian ngừng hoạt động của Solana, có những người không thể trang trải vị trí của họ kịp thời vì tài sản của họ đang phải đối mặt với việc thanh lý, khiến hàng triệu đô la tài sản gặp rủi ro. **Một khi việc từ chối yêu cầu của người dùng xảy ra, thiệt hại kinh tế gây ra không đáng kể.

Ngay cả khi chỉ có một vài người có thể ở trong tình huống này, nếu nó rơi vào một con cá voi nào đó với rất nhiều tiền, toàn bộ thị trường có thể bị ảnh hưởng (giả sử ai đó có hàng trăm triệu đô la tài sản trên giao thức cho vay Defi trên Ethereum có thể được thanh lý trong một tuần, nhưng anh ta nằm trong danh sách trừng phạt của OFAC vì sử dụng Tornado). Hầu hết các khoản tiền của người này đều nằm trong OP và trình sắp xếp chuỗi OP làm việc với OFAC để từ chối yêu cầu của họ)

Chúng tôi cũng có thể dự đoán vấn đề này lên các chuỗi công khai như tuyết lở hoặc đa giác, độc lập với Ethereum. Nếu hơn 2/3 số nút đồng thuận của trình xác thực trên Avalanche quyết định kiểm duyệt các giao dịch của bạn, họ có thể từ chối đưa Txn của bạn vào một khối hoặc không nhận ra khối chứa Txn của bạn. Tại thời điểm này, tiền của bạn về cơ bản bị chôn vùi trong chuỗi này và không thể thoát ra được: **

Trừ khi bạn có thể chọn một số trình xác thực để ít hơn 2/3 số trình xác thực có liên quan đến cuộc tấn công kiểm duyệt hoặc bạn có thể kêu gọi một số người phân nhánh Avalanche thông qua sự đồng thuận xã hội. Rõ ràng, tại thời điểm này, bạn vẫn có cách để nhanh chóng rút tiền từ Avalanche và chúng tôi phải xem xét rằng hơn 2/3 Người xác thực hợp lực để bắt đầu xem xét giao dịch của một địa chỉ nhất định, bản thân địa chỉ này phải mất một thời gian để đạt được, điều này sẽ để lại đủ thời gian cho người dùng bị kiểm duyệt “thoát”.

Nhưng trên Lớp 2, tình hình có thể rất khác. Layer 2 Sequencer thường được điều hành bởi chính quan chức và nếu Sequencer muốn khởi động một cuộc tấn công kiểm duyệt vào bạn, nó có thể “đóng băng tiền của bạn trong Lớp 2”, nghĩa là từ chối hoàn toàn yêu cầu giao dịch của bạn để chuyển tài sản từ L2 sang L1. Rõ ràng, theo cơ chế hoạt động của L2, nếu bạn không thể bỏ qua trình sắp xếp để thực hiện thao tác rút tiền, hoàn toàn có khả năng Sequencer sẽ đóng băng tài sản trong L2 và không thể chuyển được.

Vậy làm thế nào để giải quyết loại vấn đề này? Trên thực tế, nói một cách thẳng thắn, làm thế nào để thực hiện chức năng rút tiền “không được phép”, để người dùng có thể rút tài sản của họ về Lớp 1 mà không bị tổn hại gì khi chúng được các bên dự án Sequencer hoặc Layer 2 xem xét? Có một số dự án đã đề xuất Sequencer phi tập trung, nhưng đây không phải là một giải pháp giảm nhẹ và nếu một số lượng rất hạn chế các trình sắp xếp hợp lực để xem xét bạn, bạn vẫn có thể “đóng băng” tài sản của mình và chống phù thủy của các nút POS cũng là một vấn đề khó khăn (xem các sự kiện Multichain).

Cách hiệu quả nhất để làm điều này là thiết lập “thoát” trực tiếp trên chuỗi L1, cho phép người dùng rút tiền từ L2 thông qua lối thoát chuyên dụng trên L1 nếu họ không nhận được phản hồi từ Sequencer trong một thời gian dài. **

**** Giao thức vòng lặp V3 Mô hình thanh lý buộc rút tiền và phá sản ****

Ở đây chúng tôi lấy phiên bản V3 của giao thức Loopring làm ví dụ, liệt kê hai kịch bản khác nhau cho việc rút tiền bắt buộc do người dùng khởi tạo, trường hợp đầu tiên là:

Người dùng có thể bắt đầu rút tiền bắt buộc trực tiếp trên Lớp 1 thông qua chức năng forcedWithdraw trong hợp đồng ExchangeV3 và khai báo họ có tài khoản L2 nào trong giao thức Loopring và loại mã thông báo họ muốn rút. Sau đó, hợp đồng ExchangeV3 ném một sự kiện trên chuỗi để chỉ ra rằng ai đó đã bắt đầu yêu cầu rút tiền bắt buộc. Vì tất cả các nút của giao thức Loopring (bao gồm cả Sequencer) đang chạy các máy khách Geth, nên được biết từ khối Ethereum rằng ai đó đã bắt đầu rút tiền bắt buộc và kích hoạt sự kiện trên chuỗi tương ứng.

Điều quan trọng cần lưu ý là việc rút tiền bắt buộc không được xử lý ngay lập tức, nhưng được đặt trong hàng đợi ForcedWithdrawals đang chờ xử lý và đang chờ xử lý. **Sequencer nhận thấy rằng sau khi ai đó bắt đầu rút tiền bắt buộc ở Lớp 1, chức năng Quy trình trong hợp đồng ExchangeV3 được kích hoạt trong vòng 15 ngày để chuyển mã thông báo cho người khởi tạo rút tiền trên chuỗi Ethereum (từ địa chỉ tiền gửi của bên dự án L2 trên chuỗi Ethereum để chuyển tiền cho người rút tiền).

Nếu Sequencer không phản hồi yêu cầu rút tiền 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 để yêu cầu hợp đồng ExchangeV3 ném một sự kiện có tên WithdrawalModeActivated để thông báo cho nút đầy đủ của giao thức Loopring rằng chế độ thanh lý phá sản đã được kích hoạt. **

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

Tuy nhiên, trong chế độ thanh lý phá sản, người dùng vẫn có thể rút tài sản của mình trên Lớp 1, nhưng họ cần gửi bằng chứng merkle để chứng minh tình trạng / trạng thái tài sản của họ, có thể được kiểm tra trên cây trạng thái L2. (** Chứng minh rằng số dư tài sản của bạn trong Lớp 2 phù hợp với số tiền bạn đã khai báo khi bắt đầu rút tiền **)

Mô hình thanh lý phá sản này của Loopring Protocol còn được gọi là cơ chế Escape Hatch trên L2BEAT. Chế độ này được kích hoạt theo điều kiện tiên quyết để trình sắp xếp chuỗi không phản hồi yêu cầu rút tiền bắt buộc của người dùng trong thời gian quy định hoặc nếu trình sắp xếp chuỗi bị lỗi hoặc thời gian chết lâu dài. Tại thời điểm này, người dùng có thể tự kích hoạt hợp đồng Rollup vào chế độ đóng băng / ngừng chạy. Sau đó, người dùng có thể xây dựng bằng chứng merkle để chứng minh tài sản của họ trên Lớp 2 và rút tài sản của chính họ từ địa chỉ tiền gửi của bên dự án L2 tại L1. **

Trong tài liệu của StarkEx, một sơ đồ chuyên dụng của quá trình này cũng được vẽ. Nếu người dùng L2 không nhận được phản hồi trình tự vào cuối cửa sổ 7 ngày khi người dùng L2 gửi yêu cầu rút tiền bắt buộc trên L1, người dùng L2 có thể gọi hàm yêu cầu đóng băng để khiến L2 bước vào giai đoạn đóng băng. Trong trường hợp này, bộ giải trình tự L2 sẽ không thể cập nhật trạng thái L2 trên L1 và sẽ mất 1 năm sau khi trạng thái L2 bị đóng băng để không bị đóng băng. Sau đó, người dùng có thể gửi Bằng chứng Merkle và rút tiền.

Tuy nhiên, để xây dựng Merkle Proof, trước tiên bạn cần biết cây trạng thái L2 hoàn chỉnh, tức là bạn cần tìm một nút đầy đủ L2 để yêu cầu dữ liệu, đồng thời, bạn cần một đoạn mã để tạo Merkle Proof, rõ ràng đòi hỏi một ngưỡng kỹ thuật nhất định. Để thuận tiện cho đa số người dùng, L2BEAT trước đây đã tuyên bố rằng Lớp 2 nên thiết lập một số nút đầy đủ với quyền mở và mã nguồn mở để giúp người dùng biết trạng thái của tất cả các tài khoản trên L2 (bao gồm số dư, số lượng giao dịch, v.v.). Động thái này cũng cho thấy tầm quan trọng của việc rút tiền bắt buộc và cơ chế thoát hiểm.

Tính năng “Bắt buộc bao gồm giao dịch” của Arbitrum

Nhưng 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 thức “buộc đưa vào các giao dịch”, trước tiên người dùng có thể gửi Txn/rút tiền cần được Sequencer xử lý trong hợp đồng Inbox bị trì hoãn trên L1 và nếu Sequencer không xử lý quá 24 giờ, người dùng có thể gọi hàm Inclusion bắt buộc của hợp đồng Sequencer Inbox trên L1. Hãy để Txn được đưa trực tiếp vào chuỗi giao dịch của Arbitrum ** (tổ chức một sự kiện trên chuỗi để thông báo cho các nút đầy đủ của Arbitrum rằng Txn với một vài bản ghi hộp thư đến bị trì hoãn cần được đưa vào sổ cái L2).

Ngược lại, cách tiếp cận của Arbitrum đơn giản hơn, nhưng nó vẫn còn thiếu một chút: nó chỉ đưa ra một sự kiện trên chuỗi nói với nút Arbitrum rằng có một vài giao dịch mà trình sắp xếp bỏ qua cần được đưa vào chuỗi dài nhất L2, thay vì cho phép người dùng rút tiền trực tiếp trên L1 như Loopring Protocol và chế độ phá sản / escape pod của StarkEx. Nếu các nút thách thức của Arbitrum liên kết với nhau để khởi động một cuộc tấn công kiểm duyệt, có vẻ như vẫn có thể đóng băng tiền của người dùng tại L2. **

Vì vậy, lực lượng của Arbitrum Inclusion không đủ không được phép, và mặc dù sẽ rất tuyệt khi nói rằng trình sắp xếp đã bỏ qua yêu cầu forceInclusion của người dùng miễn là có một nút trung thực sẵn sàng đăng bằng chứng gian lận, điều này vẫn giới thiệu một mức độ giả định tin cậy nhất định, mặc dù ở mức độ thấp hơn.

Chính xác hơn, “các giao dịch cần được bao gồm bắt buộc” phải được công nhận bởi ít nhất một nút thách thức ARB, hiện có 9 nút có quyền quyết định thông điệp chuỗi chéo L2-L1 nào được phép và bây giờ chỉ họ mới có thể đưa ra bằng chứng gian lận. **Miễn là 9 nút này thông đồng với nhau, về mặt lý thuyết, “giao dịch bắt buộc” của người dùng vẫn có thể bị vô hiệu. **

Do đó, việc bắt buộc đưa các giao dịch/rút tiền vào Arbitrum hiện nay không giống như mô hình thanh lý phá sản của Loopring và StarkEx không yêu cầu sự cho phép của nút L2. Tuy nhiên, L2BEAT vẫn đánh giá cao Arbitrum cho giải pháp này. Bởi vì trong tương lai, Arbitrum sẽ khởi chạy một cơ chế phát hành bằng chứng gian lận Permissionless được gọi là BOLD, và sẽ rất khó hoặc không thể cho các nút thách thức thông đồng tại thời điểm đó (thực sự rất khó để thông đồng ngay bây giờ).

Theo L2BEAT, TVL hiện tại là hơn 50 triệu đô la và không có phản hồi nào đối với bất kỳ Lỗi Trình sắp xếp hoặc Lỗi Người đề xuất nào: **OP Mainnet, Base, zkSync Era, Mantle, Starknet, Linea, Polygon zkEVM, Metis. Những L2 này có thể khiến tài sản người dùng bị đóng băng trong L2 trong những trường hợp cực đoan. **

Vì vậy, rõ ràng, mô hình rút tiền bắt buộc hoặc thanh lý phá sản có sự cần thiết của nó, mặc dù hiện tại nó chỉ dựa vào trình tự người dùng như một trò chơi đối tác để hoạt động, ** chưa thực sự “sẵn sàng rút tiền” ** (Arbitrum có độ trễ 24 giờ và có thể thất bại, Loopring có độ trễ tối đa là 15 ngày, StarkEx có độ trễ tối đa là 7 ngày), nhưng rõ ràng là “một cái gì đó tốt hơn là không có gì”. Hơn nữa, vấn đề chậm trễ trong việc rút tiền bắt buộc được cho là sẽ được giải quyết đúng đắn trong tương lai với thiết kế cơ chế tinh vi hơn ** (hiện tại, chủ yếu là do một số nhà khoa học MEV có thể sử dụng forceInclusion để bắt đầu các giao dịch chạy trước, vì vậy cần phải đưa ra sự chậm trễ.) Để biết thêm chi tiết, vui lòng tham khảo các tài liệu chính thức của các bên dự án L2 lớn).

Với việc đưa Sequencer phi tập trung vào ngày càng nhiều lộ trình L2 và Ethereum Foundation do Vitalik dẫn đầu tiếp tục giáo dục mọi người về bảo mật Lớp 2, các tính năng giao dịch chống kiểm duyệt như rút tiền bắt buộc chắc chắn sẽ được chú ý nhiều hơn, điều này sẽ làm cho hệ thống Ethereum Layer2 gần hơn với hệ thống cơ sở hạ tầng tài chính chống kiểm duyệt, không tin cậy. Nếu Lớp 2 thực hiện quyền truy cập không tin cậy vào các quỹ, người ta tin rằng nhiều nhà tạo lập thị trường và nhà cung cấp thanh khoản sẽ tham gia vào cơ sở hạ tầng L2 và việc áp dụng hàng loạt toàn bộ web3 sẽ được đẩy thêm một bước nữa.