Cùng Coin Moi so sánh khả năng tương tác của 4 Layer 2 tiềm năng: StarkEx Vs. Loopring Vs. Hermez Vs. Connext nhé!
Tổng quan
Hiện tại các giải pháp mở rộng Ethereum Layer 2 như Polygon và Arbitrum đã bắt đầu đi vào hoạt động, hệ sinh thái Ethereum Layer 2 đang phát triển với tốc độ chóng mặt. Đồng thời, ngày càng có nhiều giao thức DeFi công bố hợp tác với các giải pháp Layer 2 để triển khai hoặc di chuyển giao thức sang Layer 2. Các giao thức DeFi khác nhau có nhu cầu mở rộng khác nhau đồng nghĩa với việc họ sẽ lựa chọn các Layer 2 khác nhau. Do đó, câu hỏi đặt ra là làm thế nào để tăng tương tác giữa Layer 1 và Layer 2 hoặc chuyển tiền linh hoạt quả giữa các Layer 2 riêng biệt.
Ví dụ: nếu người dùng cần chuyển tiền giữa dYdX và DeversiFi, thông qua L2, họ cần rút tiền từ dYdX sang L1 và sau đó gửi tiền từ L1 sang DeversiFi. Như vậy, người dùng sẽ phải trả hai lần phí gas và mất một khoảng thời gian dài chờ đợi. Đối với các giải pháp L2 có khả năng chống gian lận (fraud-proof), việc rút tiền về L1 thậm chí có thể mất nhiều ngày.
Vì lý do này, việc tiên quyết các dự án L2 cần làm đó chính là đạt được khả năng tương tác giữa các L2. StarkWare đã đưa ra khái niệm về khả năng tương tác L2, tức là chuyển tiền giữa các L2 với khả năng giảm thiểu rào cản tối đa trên L1 trong quá trình chuyển. Các giải pháp L2 khác nhau có các phương thức tương tác khác nhau. Dưới đây là so sánh ngắn gọn giữa các phương thức tương tác của StarkEx, Loopring, Hermez và Connext.
STARKEX
StarkEx đã định nghĩa một giao dịch ban đầu được gọi là Giao dịch có điều kiện [a] [b], trong đó một giao dịch có được xác thực hay không phụ thuộc vào việc giao dịch đó có đáp ứng các điều kiện tiên quyết cho giao dịch đó hay không.
Các giao dịch có điều kiện sử dụng hợp đồng Fact Registry để theo dõi các sự kiện trong chuỗi. Một sự kiện trước tiên phải được “đăng ký” với hợp đồng Fact Registry trước khi có thể sử dụng một giao dịch có điều kiện. Ví dụ: nếu Alice chuyển 1 ETH cho Bob trực tiếp qua Ethereum mà không đăng ký hợp đồng Fact Registry, sẽ không có sự kiện trực tuyến nào có thể được sử dụng như một giao dịch có điều kiện.
Hợp đồng Fact Registry có hai chức năng, tức là transfer () và isValid ().
Ví dụ: Nếu Alice cần chuyển 1 ETH cho Bob, cô ấy sẽ gửi địa chỉ của Bob làm tham số cho hàm transfer (), sau đó hàm này sẽ thực hiện hai việc.
- Nó chuyển 1 ETH cho Bob;
- Nó giữ một bản ghi về việc chuyển tiền, ví dụ, nó lưu thông tin về người gửi, người nhận và hàm băm của số tiền chuyển.
Hàm isValid () chấp nhận một băm làm tham số và cho kết quả True nếu băm đầu vào bằng với một băm được ghi trước đó trong hợp đồng Fact Registry để băm được ghi trong hợp đồng có thể được coi là “Fact”, có nghĩa là một sự kiện đã xảy ra. Quá trình này thường được gọi là “Fact Registration
Một sự kiện trên chuỗi đã ký trong một giao dịch có điều kiện chứa hai trường (băm): địa chỉ của hợp đồng Fact Registry và “Fact” cần được đăng ký trước khi giao dịch có điều kiện được thực hiện.
Sơ đồ trên cho thấy quy trình làm việc của các giao dịch có điều kiện trong hợp đồng Fact Registry. Trong giải pháp zkRollup của StarkEx, nếu một giao dịch có điều kiện được bao gồm trong một lô giao dịch, nó sẽ đảm bảo rằng Dữ kiện liên quan của nó được đăng ký, nếu không, toàn bộ lô sẽ được khôi phục lại.
StarkEx (L2) → Ethereum (L1) — Fast Withdrawal
Có hai tác nhân trong use case này, trong đó Alice cần rút 1 ETH từ L2 đến L1 và Nhà cung cấp thanh khoản (LP) có một số tiền nhất định trên L1. Đầu tiên, Alice bắt đầu giao dịch với LP, trả 1 ETH trên L2 đến địa chỉ của LP với điều kiện LP trả 1 ETH trên L1 đến địa chỉ của Alice. Sau đó, Alice nhận được 1 ETH trên L1 và các điều kiện của giao dịch này được thỏa mãn. Tại thời điểm này, LP gửi giao dịch này đến Operator trên L2 và đợi nó được đóng gói vào lô giao dịch đã được chứng minh tiếp theo. Sau khi bằng chứng về giao dịch có điều kiện được gửi đến L1 để xác minh và phê duyệt, địa chỉ của LP ở L2 sẽ được tăng thêm 1 ETH, là số tiền nhận được từ Alice. (Để rút tiền nhanh theo cách này, Alice cần trả phí cho LP.)
Vì tiền của LP trên L1 tiếp tục giảm và tiền trên L2 tiếp tục tăng khi dịch vụ rút tiền được cung cấp, LP cần định kỳ rút tiền từ L2 đến L1 để cân bằng lại tiền.
StarkEx (L2) → StarkEx (L2)
Use case 2 tương tự như Use case 1, Alice bắt đầu giao dịch với LP, hứa hẹn trả 1 ETH cho địa chỉ của LP trên L2_1, với điều kiện LP trả 1 ETH cho địa chỉ của Alice trên L2_2. (Alice và LP cũng được yêu cầu trả phí và cân đối lại quỹ.)
Dựa trên phân tích ở trên, cả hai hệ thống sử dụng bằng chứng xác thực (zkRollup) và hệ thống sử dụng bằng chứng gian lận (Optimistic Rollup) đều có thể áp dụng phương pháp giao dịch có điều kiện này. Tất nhiên, có một điểm bất lợi trong hiệu quả tài trợ của LP sử dụng Optimistic Rollup so với những LP sử dụng zkRollup, có xác nhận rút tiền nhanh hơn.
Rút tiền từ L2 đến L1 trong bất kỳ giải pháp L2 nào đều yêu cầu hoàn thiện cập nhật trạng thái của L2, bao gồm cả việc rút tiền. Để xác thực, người dùng thường cần đợi tối thiểu 10 phút. Trong một hệ thống chống gian lận, có thể mất vài ngày. Việc sử dụng rút tiền nhanh dựa trên giao dịch có điều kiện giúp giải phóng việc rút tiền khỏi sự phụ thuộc vào cập nhật trạng thái L2 và cho phép chuyển tiền ở cấp độ “blockchain-time”.
StarkEx đề xuất các giao dịch có điều kiện để đạt được khả năng tương tác L2 và ý tưởng này rất giống với Rollup. Nghĩa là, nhiều khoản phí cho mỗi lần rút tiền của người dùng được chuyển thành một khoản phí duy nhất cho LP rút từ L2 đến L1 khi cân bằng lại tiền. So với phí gas cao như ở L1, rõ ràng người dùng trả một khoản phí nhỏ cho LP sẽ tiết kiệm chi phí hơn.
LOOPRING
Loopring đã đề xuất Ethport [c], một sản phẩm Bridge trên L1, L2 và CEX, bằng cách kết hợp các thành phần của bộ công cụ hiện có của nó.
Về sự tương tác giữa L1 và L2, giải pháp của Loopring là thực hiện theo lô nhiều giao dịch L1 như một cách để chia sẻ phí gas với L1. Gần giống với ý tưởng trên, Loopring cũng thiết lập vai trò của nhà cung cấp thanh khoản trên L2. Tuy nhiên, khi xem xét hiệu quả tài trợ của nhà cung cấp thanh khoản, Loopring đề xuất Single Phase Converter (SPC). (ảnh dưới)
Single Pahase Converter sử dụng tính năng Flash Minting của L2 [d]. Nghĩa là, Flash Minting được sử dụng để tạo ra các token mà người dùng muốn mua để tất cả các giao dịch có thể được hoàn thành trên L2 (với tỷ lệ chuyển đổi mã thông báo dự kiến). Sau đó, tất cả các mã thông báo mà người dùng bán được rút về L1, nơi các giao dịch được thực hiện và người dùng nhận được Token muốn mua (đã được phân phối trước đó thông qua Flash Minting). Cuối cùng, những Token này được hoàn trả cho Flash Minting.
VÍ dụ phía trên là một trường hợp khá lý tưởng. Trong thực tế, tỷ lệ chuyển đổi Token có thể thay đổi và có khả năng giao dịch trên L1 có thể không thành công. Điều này gây ra rủi ro không thể hoàn trả Flash Minting, có nghĩa là tất cả các giao dịch trước đó trên L2 sẽ được khôi phục lại.
Theo quan điểm của vấn đề này, Loopring sau đó đã đề xuất Double Phase Converter (DPC).
(DPC).
Double Phase Converter chia giao dịch thành hai giai đoạn.
Trong giai đoạn đầu, bộ chuyển đổi thu thập tất cả tiền của người dùng trong Vault (đối với một Token cụ thể) và cấp cho họ một Token đại diện trong Vault, thay vì chuyển đổi Token trực tiếp. Tiếp theo là một giao dịch trên L1, xác định tỷ lệ chuyển đổi.
Trong giai đoạn thứ hai, Token đã chuyển đổi có thể được phân phối tới người dùng theo tỷ lệ, do đó giải quyết được vấn đề về tỷ lệ chuyển đổi không ổn định.
Ngoài ra, cơ chế Bridge cho phép người dùng gửi tiền hàng loạt vào Loopring thông qua các hợp đồng thông minh trên L1, thay vì tham gia mạng L2 riêng lẻ. Thiết kế này kết hợp nhiều giao dịch tiền gửi lại thành một giao dịch duy nhất, giảm chi phí khí đốt. Với Bridge, các sàn giao dịch tập trung cũng có thể sử dụng cơ sở hạ tầng L1 tiêu chuẩn để hỗ trợ mạng L2 của Loopring.
Ethport, dựa trên các thành phần trên, trước tiên sử dụng tính thanh khoản trên L2 càng nhiều càng tốt trong thực tế. Nếu có sẵn Converter, nó được sử dụng để gộp các giao dịch L1 và giảm chi phí giao dịch. Nếu các điều kiện trên không được đáp ứng thì có thể được chuyển qua cơ chế Bridge.
Hermez
Hermez đã được giới thiệu bởi nhóm iden3 và giải pháp được đề xuất cho tương tác L2 là Di chuyển khối lượng lớn (Massive Migration) [e].
Ý tưởng là đầu tiên, hợp đồng thông minh chịu trách nhiệm thực hiện chuyển tiền L1 có địa chỉ trên L2_1. Khi cần chuyển tiền chéo qua L2, người dùng sẽ chuyển tiền đến địa chỉ đó. Sau đó, giao thức Hermez sẽ nhóm và trích xuất một loạt chuyển khoản L2 có cùng địa chỉ L2_2 và sử dụng hàm Hermez tiêu chuẩn để rút tổng số tiền từ lô chuyển khoản L2 này sang L1 và gửi vào L2_2.
Giao thức Hermez bao gồm thông tin cần thiết để tạo lại các lần chuyển L2_1 ban đầu trên L2_2 và thông tin người dùng tương ứng khi thực hiện các giao dịch rút tiền tổng hợp được mô tả ở trên. L2_2 chịu trách nhiệm xử lý các giao dịch rút tiền từ L1 và phân tách dòng tiền từ thông tin giao dịch trước khi chuyển đến địa chỉ L2_2 tương ứng với địa chỉ L2_1 của người dùng.
CONNEXT
Connext là một giải pháp mở rộng Ethereum (state channel) L2 dựa trên nền tảng hỗ trợ các giao dịch nhanh chóng giữa các chuỗi tương thích với EVM và các hệ thống L2. Đầu năm nay, Connext đã phát hành phiên bản 0.1.0 của Vector, một sản phẩm chuyển tiền chéo L2 tức thì được thiết kế để kết nối tính thanh khoản giữa các giải pháp L2 và cho phép chuyển tiền chéo L2. Vào tháng 3, Connext đã ra mắt phiên bản beta của xDai-Polygon Bridge, cho phép người dùng sử dụng kênh trạng thái để chuyển xDai sang Dai trên Polygon hoặc ngược lại sử dụng state chanel.
Connext cho phép chuyển tiền chéo L2 qua bộ định tuyến [f]. Bộ định tuyến Connext thực sự là ltự động chuyển tiếp các giao dịch được gửi đến nó trong state channel. Đối với các giao dịch xuyên chuỗi, bộ định tuyến đóng vai trò là một nhà cung cấp thanh khoản bằng cách chuyển tiền cho người dùng trong state channel trên chainB để đổi lấy tiền của người dùng trên chainA, tương tự như ý tưởng của StarkEx và Loopring.
Ví dụ: nếu Alice muốn gửi 100 USDC từ Polygon đến Arbitrum, cô ấy cần sử dụng bộ định tuyến để gửi 100 USDC vào một kênh trạng thái trên Polygon. Alice sau đó sẽ gửi một chuyển tới bộ định tuyến đó trong State channel, với điều kiện Alice nhận được giao dịch trong state channel tương ứng trên Arbitrum, kênh này dựa vào băm (Hashlock) [g]. Các chuyển tiền này được mở khóa theo cách nguyên tử, cho phép triển khai không cần tin cậy. Bộ định tuyến (router) có thể kiếm được khoản phí do Alice trả trong quá trình chuyển chéo L2.
Tuy nhiên, các giải pháp chuyển chéo L2 dưới sự trợ giúp của các nhà cung cấp thanh khoản phải đối mặt với vấn đề về hiệu quả tài trợ. Do đó, Connext đề xuất AMM ảo (Virtual AMM) để giải quyết vấn đề này.
Trên Uniswap, tỷ lệ chuyển đổi của pool càng không cân bằng thì mức chênh lệch giá càng lớn. Điều này cũng tạo ra cơ hội kiếm thêm lợi nhuận từ chênh lệch giá ngày càng tăng. AMM ảo dựa trên khái niệm cốt lõi của Uniswap để định giá chuyển tiền giữa các L2.
Hãy xem xét tình huống tại một thời điểm nào đó số lượng ETH trong nhóm Arbitrum cho LP lớn hơn số ETH của nó trong Optimism pool và hệ thống muốn cân bằng lượng ETH trong cả hai nhóm. Theo phương trình trên trong sơ đồ, nếu 0,99 ETH trên Optimism pool có thể đổi lấy 1 ETH trên Arbitrum, thì sẽ có cơ hội kinh doanh chênh lệch giá. Bằng cách này, đối với LP, số lượng ETH trong pool trở nên lớn hơn và số lượng ETH trong nhóm Arbitrum trở nên nhỏ hơn, do đó tính thanh khoản được cân bằng thông qua các hoạt động chênh lệch giá.
Ngoài ra, bất kỳ ai trên Connext cũng có thể cung cấp tính thanh khoản thông qua Router, do đó tính thanh khoản sẽ không được tổng hợp vì một số Router có thể bị quá tải và một số có thể không được sử dụng. Sau đó, Connext đã đưa ra khái niệm Đấu giá thanh khoản, phương thức này sẽ tự động tìm ra Router cung cấp chi phí thấp nhất.
Khi giao dịch được thực hiện, người dùng sẽ truyền cho mạng thanh khoản sẽ được gửi hoặc nhận. Router gửi trực tiếp “Sealed Bid” cho người dùng để hoàn tất việc chuyển giao với mức phí thấp nhất. Điều này phần nào tương tự với việc Uber điều hướng người dùng tới các tài xế gần và chi phí chuyến đi thấp nhất.
KẾT
Bốn dự án được đề cập ở trên sử dụng một phương pháp tương tự để giải quyết các vấn đề về khả năng tương tác chéo giữa L2 và L1 bằng cách giới thiệu một nhà cung cấp thanh khoản để tổng hợp nhiều giao dịch thành một giao dịch duy nhất. Đối với vấn đề hiệu quả sử dụng vốn của các nhà cung cấp thanh khoản, mỗi dự án đề xuất các giải pháp khác nhau và có những ưu nhược điểm riêng. Với số lượng người dùng và TVL chưa cao, chúng ta cần thêm thời gian để biết được giải pháp nào sẽ chiếm ưu thế. Các bạn có suy nghĩ như thế nào về các giải pháp Layer 2 này? Hãy chia sẻ cho Mecap biết nhé!!
