Nghiên cứu về vấn đề phân tách thanh khoản trong thời đại Layer 2

Với việc Ethereum chuyển sang các giải pháp mở rộng dựa trên Layer 2, cùng với sự nổi lên của các công cụ như RaaS, nhiều chuỗi công khai đã phát triển nhanh chóng. Nhiều thực thể mong muốn xây dựng chuỗi riêng của mình để đại diện cho các mối quan tâm khác nhau và tìm kiếm mức định giá cao hơn. Tuy nhiên, sự bùng nổ của nhiều chuỗi công khai đã khiến cho sự phát triển của hệ sinh thái khó theo kịp với tốc độ của các chuỗi công khai, dẫn đến nhiều dự án đã phá sản ngay tại thời điểm TGE.

Nhờ OP Stack, một nền tảng giao dịch đã ra mắt Base Layer 2 của riêng mình, trong khi một nền tảng giao dịch khác phát hành Ink; nhờ công nghệ ZK, một nền tảng giao dịch đã ra mắt XLayer; Sony phát hành Soneium, LINE ra mắt Kaia, v.v. Ngày nay, vốn và ngưỡng kỹ thuật để xây dựng một chuỗi đã giảm đáng kể, chi phí vận hành một chuỗi dựa trên OP Stack khoảng 10,000 USD mỗi tháng.

Tương lai chắc chắn sẽ là thời đại của sự đồng tồn tại của nhiều chuỗi. Mặc dù những chuỗi Layer 2 này có thể chọn khả năng tương thích EVM để đạt được sự tương tác, nhưng do các thực thể Web2 đứng sau chúng có nhiều ứng dụng hạ nguồn, nên rất khó để xây dựng ứng dụng và đạt được sự đồng thuận trên cùng một chuỗi.

Hệ sinh thái đa chuỗi hiện tại đã mang đến một thách thức mới: Thanh khoản và trạng thái phân tán. Do sự tồn tại của đa chuỗi là điều tất yếu, nên khả năng tương tác là một lĩnh vực cần phải khám phá và giải quyết. Hiện tại có nhiều giải pháp thanh khoản, chẳng hạn như trừu tượng chuỗi, ý định, Clearing Execution, Native CrossChain, ZKSharding, nhưng bản chất cốt lõi của chúng đều giống nhau.

Chúng tôi sử dụng kiến trúc Cake được công nhận trong ngành để giới thiệu từ trên xuống dưới các thành phần cốt lõi của trừu tượng chuỗi chéo:

Lớp ứng dụng (Application Layer)

Đây là lớp mà người dùng tương tác trực tiếp, cũng là lớp trừu tượng nhất trong giải pháp thanh khoản, vì nó hoàn toàn che giấu các chi tiết của việc chuyển đổi thanh khoản. Ở lớp ứng dụng, người dùng tương tác với giao diện phía trước, không nhất thiết phải hiểu cơ chế chuyển đổi thanh khoản ở lớp dưới.

Lớp quyền (Permission Layer)

Nằm dưới lớp ứng dụng, người dùng kết nối ví với dApp và yêu cầu báo giá để đáp ứng ý định giao dịch. Ở đây, "ý định" đề cập đến kết quả giao dịch cuối cùng mà người dùng mong muốn (tức là đầu ra), chứ không phải là đường dẫn thực hiện giao dịch cụ thể.

Quản lý tài khoản và lớp trừu tượng (Quản lý chìa khóa và Trừu tượng tài khoản)

Do sự tồn tại của môi trường đa chuỗi, cần có một hệ thống quản lý tài khoản và trừu tượng hóa thích ứng với các chuỗi khác nhau để duy trì cấu trúc tài khoản độc đáo của từng chuỗi. Ví dụ, hệ thống tài khoản trung tâm đối tượng của SUI hoàn toàn khác với EVM. One Balance là dự án đại diện trong lĩnh vực này, nó xây dựng một hệ thống tài khoản đáng tin cậy, không cần thiết lập sự đồng thuận giữa các chuỗi, chỉ cần cam kết đáng tin cậy giữa các hệ thống tài khoản hiện có. Near Account đạt được quản lý trừu tượng hóa bằng cách tạo ví tài khoản đa chuỗi cho người dùng, tối ưu hóa trải nghiệm người dùng một cách đáng kể, giảm thiểu sự phân mảnh UX. Tuy nhiên, về mặt thanh khoản, chủ yếu tích hợp các chuỗi công khai hiện có.

Lớp Giải Quyết (Solver Layer)

Lớp này chịu trách nhiệm tiếp nhận và thực hiện ý định giao dịch của người dùng, vai trò Solver ở đây cạnh tranh để cung cấp trải nghiệm người dùng tốt hơn, bao gồm thời gian giao dịch nhanh hơn và tốc độ thực hiện cao hơn. Trên nền tảng này, các dự án dựa trên ý định đã xây dựng ra nhiều giải pháp được điều khiển bởi ý định. Các sản phẩm phái sinh của loại ý định này như thành phần Predicate, có thể thực hiện ý định của người dùng theo các quy tắc cụ thể.

Kết Sổ Lớp (Settlement Layer)

Đây là lớp trung gian được sử dụng để giải quyết lớp yêu cầu nhằm thực hiện ý định của người dùng. Các thành phần cốt lõi của giải pháp thanh khoản và trạng thái phân tán bao gồm:

• Oracle: Được sử dụng để lấy thông tin trạng thái từ các chuỗi khác.
• Cầu nối chuỗi chéo (Bridges): Chịu trách nhiệm truyền tải thông tin và thanh khoản giữa các chuỗi.
• Xác nhận trước kế hoạch (Pre-Confirmation): Rút ngắn thời gian xác nhận giữa các chuỗi.
• Khả năng truy cập dữ liệu (DA): Cung cấp khả năng truy cập dữ liệu.

Ngoài ra, cũng cần xem xét thanh khoản giữa các chuỗi, tính xác nhận cuối cùng (Finality), cơ chế chứng minh Layer 2 và các yếu tố khác để đảm bảo hoạt động hiệu quả của toàn bộ hệ thống đa chuỗi.

Giải pháp

Hiện nay, trên thị trường có nhiều giải pháp để giải quyết vấn đề thanh khoản bị割, sau khi xem xét nhiều giải pháp, chúng tôi nhận thấy chủ yếu có một số cách sau:

1. Tập trung vào RaaS: Giải pháp Rollup như OP Stack, thông qua việc thêm các bộ sắp xếp chia sẻ và cầu nối đa chuỗi cụ thể để hỗ trợ chia sẻ thanh khoản và trạng thái cho các Rollup xây dựng trên OP Stack. Hy vọng điều này có thể giải quyết sự phân tán của thanh khoản và trạng thái theo một hướng cao hơn. Một điều phân khúc hơn là thiết kế bộ sắp xếp chia sẻ riêng biệt, giải pháp này chủ yếu nhắm đến Layer 2, không có tính phổ quát.

2. Tập trung vào tài khoản: Xây dựng một ví tài khoản toàn chuỗi, thông qua một công nghệ được gọi là "chuỗi ký" hỗ trợ ký và thực hiện giao dịch trên nhiều giao thức blockchain. Thành phần cốt lõi là mạng MPC, thay thế người dùng ký giao dịch đa chuỗi. Giải pháp này, mặc dù có thể giải quyết rất lớn vấn đề phân mảnh UX, nhưng đối với các nhà phát triển, điều này liên quan đến việc thực hiện backend phức tạp và không giải quyết về cơ bản vấn đề thanh khoản và phân tán trạng thái.

3. Tập trung vào mạng lưới ý định ngoài chuỗi: Cốt lõi là người dùng gửi ý định đến mạng lưới Solver, vai trò Solver này sẽ cạnh tranh để báo giá, cung cấp thời gian hoàn thành và giá giao dịch tối ưu nhất, các Solver này có thể là AI Agent, CEX, Market Maker hoặc thậm chí là giao thức tích hợp. Mặc dù ý định lý thuyết có thể thực hiện các hoạt động liên chuỗi phức tạp với độ khó tùy ý, nhưng về mặt thực hiện, cần phải có đủ Solver có thanh khoản để hỗ trợ, và khi gặp một số yêu cầu ngoài chuỗi, có khả năng xảy ra gian lận từ Solver, nếu áp dụng các biện pháp như chứng minh gian lận, độ khó trong việc thực hiện mạng lưới Solver sẽ tăng lên, và ngưỡng để vận hành Solver cũng sẽ cao hơn.

4. Tập trung vào mạng thanh khoản trên chuỗi: Hướng đi này được thiết kế đặc biệt để tối ưu hóa vấn đề thanh khoản liên chuỗi, nhưng không giải quyết vấn đề phân tán trạng thái trên các chuỗi khác. Cốt lõi là xây dựng một lớp thanh khoản, trên lớp này sẽ xây dựng các ứng dụng để chia sẻ thanh khoản toàn chuỗi.

5. Tập trung vào ứng dụng trên chuỗi: Các ứng dụng này xây dựng ứng dụng có tính thanh khoản cao thông qua việc tích hợp MM lớn hoặc các ứng dụng bên thứ ba. Các dự án này cần quản lý quy trình liên chuỗi phức tạp, yêu cầu cao đối với các nhà phát triển, do đó cũng rất dễ xảy ra các sự kiện tấn công của hacker.

Giải quyết vấn đề thanh khoản là một đề tài rất quan trọng, trong thế giới tài chính, thanh khoản thường đại diện cho mọi thứ. Nếu có thể xây dựng một nền tảng tích hợp thanh khoản, đặc biệt là tích hợp thanh khoản toàn chuỗi rời rạc lại với nhau, sẽ có tiềm năng rất lớn, và chúng tôi cũng đã xem xét nhiều giải pháp khác nhau.

Trong hai loại phân loại trên, chúng ta có thể thấy rằng theo cấu trúc bánh kem, Settlement Layer là giải pháp ở cấp độ nguyên tử nhất. Trên những giải pháp nguyên tử như xuyên chuỗi, oracle, và Pre-Confirmation, được xây dựng một lớp trừu tượng hơn, đó là Solver Layer, Permission Layer và Application Layer. Các giải pháp về trừu tượng hoặc thanh khoản mà chúng tôi đã liệt kê ở trên đều tương ứng với các cấp độ khác nhau và có thể hiểu như là mối quan hệ giữa thượng nguồn và hạ nguồn. Tuy nhiên, những giải pháp này vẫn không phải là giải pháp nguyên tử. Vấn đề phân tách thanh khoản đã gây ra nhiều vấn đề phát sinh phức tạp, do đó đã sản sinh ra nhiều giải pháp đa dạng cho tính tương tác. Nhưng về bản chất, vẫn phải phụ thuộc vào những thành phần này. Tiếp theo, chúng ta sẽ thảo luận về một số dự án điển hình của khái niệm trừu tượng chuỗi, để xem mỗi dự án đã giải quyết vấn đề phân tách thanh khoản từ điểm xuất phát của mình như thế nào.

INFINIT

INFINIT đã xây dựng một dịch vụ RaaS trong lĩnh vực DeFi, có khả năng cung cấp các thành phần cần thiết để xây dựng trực tiếp cho các giao thức DeFi, như Oracle, Pool Type, IRM, Tài sản, v.v., và còn có thể cung cấp các thành phần như Giao dịch Đòn bẩy và Chiến lược Sinh lời có thể được kích hoạt ngay lập tức. Tương đương với đầu cuối xây dựng ứng dụng khác, nhưng tính thanh khoản cuối cùng được đặt trên lớp thanh khoản của Infinit. Tuy nhiên, hiện tại nó vẫn chưa công bố nguyên lý hoạt động cơ bản. Hiện tại, INFINIT đã nhận được 6 triệu USD trong vòng gọi vốn hạt giống từ một số tổ chức đầu tư.

Mạng Khalani

Khalani xây dựng ba thành phần cốt lõi, bao gồm lớp tương thích Intent, Validity và lớp thanh toán chung.

Các ứng dụng bên ngoài hoặc lớp ý định có thể phát hành ý định cho Khalani, sau đó lớp tương thích ý định của Khalani có thể chuyển đổi các ý định bên ngoài thành định dạng mà Solver giao thức có thể nhận dạng, định dạng chuẩn hóa được sử dụng là ngôn ngữ Validity. Node Khalani chịu trách nhiệm gửi kết quả cuối cùng đến lớp thanh toán chung thông qua cầu nối chuỗi chéo, công nghệ thanh toán nhanh, v.v. Dự án này vẫn đang trong giai đoạn xây dựng, chưa tiết lộ thêm chi tiết công việc. Vào tháng 8, nó đã nhận được 2,2 triệu đô la từ một số tổ chức đầu tư trong vòng gọi vốn hạt giống.

Liquorice

Liquorice là một ứng dụng phi tập trung, cho phép phát hiện giá dựa trên đấu giá và các bể thanh khoản đơn phương. Sứ mệnh chính của Liquorice là cung cấp cho các công ty giao dịch chuyên nghiệp các công cụ quản lý tồn kho hiệu quả, đồng thời dễ dàng kết nối với các giao thức DeFi cốt lõi khi thực hiện thanh toán giao dịch theo ý định sử dụng. Trong khi đó, Liquorice đã tạo ra thị trường cho vay, phục vụ cho các giao dịch cho vay của mình. Ứng dụng này tập trung nhiều hơn vào chính giao dịch. Hiện tại vẫn đang trong giai đoạn phát triển, nó đã công bố vào tháng 7 rằng đã nhận được 1,2 triệu USD trong vòng gọi vốn Pre-seed do một tổ chức đầu tư dẫn đầu.

Xion

Xion là một sản phẩm được nâng cấp từ thương hiệu Burnt, trước đây Burnt tập trung vào các ứng dụng dành cho người tiêu dùng, sau đó đội ngũ phát hiện ra rằng có một vấn đề lớn về sự phân mảnh trong các tương tác trên chuỗi, vì vậy đã xây dựng Xion để cải thiện vấn đề này. Xion được xây dựng dựa trên giao thức đồng thuận Comet BFT. Giao tiếp xuyên chuỗi mà nó áp dụng dựa trên Cosmos IBC, vì vậy nó an toàn và nguyên bản hơn so với các cầu nối xuyên chuỗi khác. Nó đã trải qua bốn vòng gọi vốn và nhận được sự hỗ trợ từ nhiều tổ chức đầu tư.

=nil; Foundation

nil là nhà phát triển thị trường sức mạnh ZK của Ethereum, bộ đồng xử lý ZK và Layer 2, đội ngũ có nền tảng công nghệ ZK vững chắc. Đã đề xuất giải pháp zkSharding, giải pháp này sử dụng công nghệ ZK để mở rộng theo chiều ngang mạng chính Ethereum, thực hiện xử lý giao dịch song song và tạo ra ZKP, trong khi đó, phân đoạn chính xác thực hiện xác thực dữ liệu, giao tiếp với Ethereum và đồng bộ trạng thái mạng giữa tất cả các xác thực viên. Phân đoạn chính cũng quản lý phân phối của các xác thực viên và tài khoản trong phân đoạn thực thi. Giao thức đồng thuận được ủy ban xác thực sử dụng cũng là Hotstuff, điều này rất phổ biến trong các dự án thực thi song song mới nhất. =nil; L2 ngay từ đầu đã nhúng khả năng giao tiếp giữa các phân đoạn vào trong giao thức. Tin nhắn liên phân đoạn được ủy ban xác thực của mỗi phân đoạn xác thực như là giao dịch.

Ý tưởng cơ bản là thông qua kiến trúc Layer 2 phân mảnh để xây dựng một kiến trúc giao tiếp xuyên phân mảnh tương tự như IBC được nhúng, từ đó giải quyết vấn đề thanh khoản và phân tán trạng thái. Tuy nhiên, ý tưởng cốt lõi không hợp lý vì vấn đề mà việc phân tán thanh khoản giải quyết là vấn đề đa chuỗi, trong khi đó nó xây dựng một Layer 2 duy nhất, có nghĩa là để giải quyết vấn đề này, tất cả các chuỗi cần trở thành một phân mảnh của ZK-sharding, điều này khó có thể thực hiện.

ERC-7683

Ethereum cũng đang nỗ lực giải quyết vấn đề thanh khoản xuyên chuỗi này, hiện tại một số dự án nổi tiếng đã công khai hỗ trợ tiêu chuẩn ERC7683, tiêu chuẩn này cũng dựa trên phương thức xuyên chuỗi dựa trên Intent. Mục tiêu cốt lõi của nó là thiết lập tiêu chuẩn chung cho các hoạt động xuyên chuỗi giữa L2 và sidechain, tiêu chuẩn hóa giao diện đơn hàng và thanh toán, thực hiện thực thi xuyên chuỗi mượt mà, cốt lõi chính là một Filler cũng có thể nói là vai trò Solver trong trừu tượng chuỗi thay mặt thanh toán. Đề xuất này được xây dựng bởi một số dự án nổi tiếng, hiện đang được nhóm Cake xem xét.

OP Stack

OP Stack, ERC-7683, và zkSharding đều là giải pháp cho việc phân mảnh thanh khoản giữa các Layer 2 trong nội bộ của Ethereum, lần lượt giải quyết ở cấp độ kiến trúc, cấp độ đồng thuận và cấp độ ứng dụng. OP Stack thiết kế một giải pháp đa Layer 2 hoàn chỉnh để giải quyết một lần cho tất cả các vấn đề truyền thông và phân quyền của Sequencer. Khi bạn sử dụng kiến trúc OP Stack, nó sẽ tự động triển khai hợp đồng xuyên chuỗi, đồng thời sẽ có một Supervisor để thách thức nhằm tránh việc truyền thông tin xuyên chuỗi giả mạo. Hiện tại, có nhiều sàn giao dịch và dự án nổi tiếng đang sử dụng kiến trúc OP Stack.

Trong đó, điển hình nhất là Unichain. Unichain chủ yếu thông qua việc kết hợp với