Nghiên cứu vấn đề phân tách thanh khoản trong thời đại Layer 2
Kể từ khi Ethereum chuyển sang các giải pháp mở rộng tập trung vào 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 cộng đã phát triển nhanh chóng. Nhiều thực thể muốn xây dựng chuỗi riêng của mình để đại diện cho các yêu cầu lợi ích khác nhau và tìm kiếm giá trị đánh giá cao hơn. Tuy nhiên, sự bùng nổ của nhiều chuỗi công cộng đã khiến phát triển hệ sinh thái không theo kịp bước tiến của các chuỗi công cộng, dẫn đến nhiều dự án đã giảm giá ngay khi TGE.
Nhờ vào OP Stack, một nền tảng giao dịch đã ra mắt Base Layer 2 của riêng mình, nền tảng giao dịch khác đã phát hành Ink; nhờ vào công nghệ ZK, một nền tảng đã ra mắt XLayer; Sony đã phát hành Soneium, LINE đã ra mắt Kaia, v.v. Hiện nay, chi phí 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 đô la 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ù các chuỗi Layer 2 này có thể chọn tính tương thích EVM để đạt được sự liên thông, nhưng do các thực thể Web2 đứng sau chúng có nhiều ứng dụng hạ nguồ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 không thể tránh khỏi, vì vậy 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 cấu thành các thành phần cốt lõi của trừu tượng chuỗi chéo từ trên xuống dưới:
Ứng dụng Layer 2 (Application Layer )
Đây là lớp tương tác trực tiếp với người dùng, 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 chi tiết của việc chuyển đổi thanh khoản. Tại lớp ứng dụng, người dùng tương tác với giao diện phía trước, có thể không hiểu cơ chế chuyển đổi thanh khoản ở lớp dưới.
Quyền truy cập lớp (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 đợi ( tức là đầu ra ), chứ không phải lộ trình thực hiện giao dịch cụ thể.
Quản lý tài khoản và quản lý khóa ( và trừu tượng hóa tài khoản )
Do sự tồn tại của môi trường đa chuỗi, cần 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 thực hiện 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ó.
Giải quyết lớp (Solver Layer)
Lớp này chịu trách nhiệm nhận và thực hiện ý định giao dịch của người dùng, vai trò Solver cạnh tranh ở đây để 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 nhanh hơn. Trên nền tảng này, các dự án dựa trên ý định đã xây dựng nhiều giải pháp dựa trên ý đị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 toán lớp (Settlement Layer)
Đây là lớp trung gian được sử dụng để giải quyết lớp 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à phân tán trạng thái 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 xuyên chuỗi ) Bridges (: chịu trách nhiệm về việc truyền tải thông tin và Thanh khoản xuyên chuỗi.
Xác nhận trước kế hoạch )Pre-Confirmation(: Rút ngắn thời gian xác nhận chéo.
Tính khả dụng dữ liệu)DA(: Cung cấp khả năng truy cập dữ liệu.
Ngoài ra, cần xem xét các yếu tố như thanh khoản giữa các chuỗi, tính chắc chắn cuối cùng )Finality(, cơ chế chứng minh Layer 2, để đảm bảo hoạt động hiệu quả của toàn bộ hệ thống đa chuỗi.
![Nghiên cứu về vấn đề chia cắt thanh khoản trong thời đại Layer2])https://img-cdn.gateio.im/webp-social/moments-a94f0982457fcb1d9c6ef2493b0a499f.webp(
Hiện tại, trên thị trường có nhiều giải pháp để chơi đùa với mọi người thanh khoản, sau khi xem xét nhiều giải pháp, chúng tôi nhận thấy chủ yếu có vài cách sau:
Tập trung vào RaaS: Giải pháp Rollup giống như OP Stack, thông qua việc thêm các bộ sắp xếp chia sẻ cụ thể và cầu nối xuyên chuỗi để hỗ trợ việc xây dựng Rollup trên OP Stack chia sẻ thanh khoản và trạng thái. Điều này hy vọng có thể giải quyết thanh khoản và trạng thái phân tán theo một hướng cao hơn. Ở đây có một phần thiết kế riêng cho bộ sắp xếp chia sẻ, giải pháp này chủ yếu nhắm đến Layer 2, không có tính phổ quát.
Lấy tài khoản làm trung tâm: Tương tự như NEAR, xây dựng một ví tài khoản toàn chuỗi, thông qua một công nghệ gọi là "chữ ký chuỗi" hỗ trợ ký và thực hiện giao dịch trên nhiều giao thức blockchain khác nhau. 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. Mặc dù giải pháp này có thể giải quyết rất nhiều 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 được về bản chất vấn đề thanh khoản và trạng thái phân tán.
Tập trung vào mạng ý định ngoài chuỗi: tức là mạng Solver trong sơ đồ kiến trúc "Giới thiệu" của bánh kem, cốt lõi là người dùng gửi ý định đến mạng Solver, vai trò Solver 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, những Solver này có thể là AI Agent, CEX, Nhà tạo lập thị trường đến chính giao thức tích hợp. Mặc dù ý định về lý thuyết có thể thực hiện các hoạt động xuyên chuỗi phức tạp với bất kỳ độ khó nào, nhưng trong thực hiện cần có đủ Solver thanh khoản để hỗ trợ, và khi gặp một số nhu cầu ngoài chuỗi, khả năng gian lận của Solver có thể xảy ra, nếu đưa vào các biện pháp như bằng chứng gian lận, độ khó trong việc thực hiện mạng Solver sẽ trở nên cao hơn, và ngưỡng để vận hành Solver cũng sẽ cao hơn.
Tập trung vào mạng lưới thanh khoản trên chuỗi: Hướng đi này chuyên tối ưu hóa vấn đề thanh khoản xuyên chuỗi, nhưng không giải quyết được vấn đề phân tán trạng thái trên chuỗi khác. Cốt lõi là xây dựng một lớp thanh khoản, trên lớp đó phát triển ứng dụng để chia sẻ thanh khoản toàn chuỗi.
Tập trung vào ứng dụng trên chuỗi: Những ứng dụng này xây dựng ứng dụng có tính thanh khoản cao bằng cách tích hợp MM lớn hoặc các ứng dụng bên thứ ba. Những dự án này cần quản lý quy trình liên chuỗi phức tạp, yêu cầu rất 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.
![Nghiên cứu về vấn đề chia tách thanh khoản trong thời đại Layer 2])https://img-cdn.gateio.im/webp-social/moments-e170f453d0b5b33f7ffc55facc9626c8.webp(
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, 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ư chuỗi chéo, oracle, Pre-Confirmation, 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 trừu tượng hoặc thanh khoản mà chúng tôi đã liệt kê ở trên được xây dựng theo các hướng khác nhau tương ứng với các cấp độ khác nhau trong mối quan hệ giữa các bên. Nhưng những giải pháp này vẫn không phải là giải pháp nguyên tử, vấn đề chia cắt thanh khoản toàn bộ đã mang lại nhiều vấn đề phức tạp khác xuất hiện, vì vậy đối với khả năng tương tác, đã phát sinh đủ loại giải pháp. 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 về khái niệm trừu tượng chuỗi, để xem mỗi dự án giải quyết vấn đề chia cắt 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, Asset, v.v., và cũng 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ể sử dụng ngay lập tức. Điều này tương đương với các đầu xây dựng ứng dụng khác, nhưng cuối cùng thanh khoản được đặt trên lớp thanh khoản của Infinit. Tuy nhiên, hiện tại vẫn chưa công bố nguyên lý làm việc của nó.
Mạng Khalani
Khalani xây dựng ba thành phần cốt lõi, lần lượt là 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 ý định bên ngoài thành định dạng mà giao thức Solver có thể nhận diện, định dạng chuẩn hóa được sử dụng là ngôn ngữ Validity. Nút Khalani chịu trách nhiệm nộp kết quả cuối cùng cho lớp thanh toán chung thông qua cầu chuỗi chéo, công nghệ thanh toán nhanh chóng, 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.
Liquorice
Liquorice là một ứng dụng phi tập trung, có khả năng phát hiện giá dựa trên đấu giá và các pool thanh khoản một chiều. 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ông cụ quản lý hàng tồn kho hiệu quả, và dễ dàng kết nối với các giao thức DeFi cốt lõi khi thực hiệ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.
Xion
Xion đượ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ũ nhận ra rằng có một vấn đề lớn về sự phân mảnh trong 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 trên giao thức đồng thuận Comet BFT. Giao tiếp đa chuỗi mà nó sử dụng dựa trên Cosmos IBC, do đó an toàn và nguyên bản hơn so với các cầu nối đa chuỗi khác.
![Nghiên cứu về vấn đề phân tách thanh khoản trong thời đại Layer 2]###https://img-cdn.gateio.im/webp-social/moments-0f51232f5a7495ce85432c8feb374ed1.webp(
)# =nil; Quỹ
nil là nhà phát triển thị trường sức mạnh ZK, bộ xử lý ZK và Layer 2 của Ethereum, độ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 ngang mạng chính Ethereum, thực hiện xử lý giao dịch song song qua phân đoạn và tạo ra ZKP, trong khi phân đoạn chính xác minh 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ý sự phân bố 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 gần đây. =nil; L2 từ đầu đã tích hợp giao tiếp giữa các phân đoạn vào giao thức. Tin nhắn giữa các phân đoạn được ủy ban xác thực của mỗi phân đoạn xác minh như là giao dịch.
Ý tưởng cơ bản của nó là, thông qua kiến trúc Layer 2 phân đoạn, để xây dựng một kiến trúc giao tiếp xuyên phân đoạn tương tự như IBC, như vậy sẽ giải quyết được vấn đề thanh khoản và trạng thái phân tán. Tuy nhiên, ý tưởng cốt lõi của nó không hợp lý, vì vấn đề phân tán thanh khoản là vấn đề đa chuỗi, mà nó xây dựng là một Layer 2 đơn nhất, có nghĩa là để giải quyết, cần tất cả các chuỗi trở thành một phân đoạn của ZK-sharding, điều này khó có thể thực hiện.
ERC-7683
Ethereum cũng đang tìm cách giải quyết vấn đề thanh khoản xuyên chuỗi này, hiện có nhiều nền tảng công khai hỗ trợ tiêu chuẩn ERC7683, cũng sử dụng phương pháp xuyên chuỗi dựa trên Intent. Mục tiêu cốt lõi là thiết lập tiêu chuẩn chung cho các hoạt động xuyên chuỗi giữa L2 và các sidechain, chuẩn hóa các giao diện đặt hàng và thanh toán, thực hiện thực thi xuyên chuỗi liền mạch, cốt lõi chính là một Filler cũng có thể được coi là vai trò Solver trong trừu tượng chuỗi đảm nhận thanh toán. Đề xuất này được xây dựng bởi hai dự án, hiện đang được nhóm Cake xem xét.
![Nghiên cứu vấn đề phân tách thanh khoản trong thời đại Layer 2]###https://img-cdn.gateio.im/webp-social/moments-e4d53accc40f8c915eaabbd2909f51d4.webp(
)# OP Stack
OP Stack, ERC-7683, và zkSharding cũng giống như nhau, đều là giải pháp cho sự phân mảnh thanh khoản giữa các Layer 2 trong nội bộ Ethereum, giải quyết ở các cấp độ kiến trúc, đồng thuận và ứ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 mọi vấn đề về truyền thông và phi tập trung hóa Sequencer, khi bạn sử dụng kiến trúc OP Stack, nó sẽ tự động triển khai hợp đồng đa chuỗi, đồng thời sẽ có một Supervisor để thách thức, tránh việc truyền tải thông tin đa chuỗi giả mạo. Hiện tại có nhiều dự án nổi tiếng đang sử dụng kiến trúc OP Stack.
Trong đó, một ví dụ điển hình là Unichain. Unichain chủ yếu thông qua
Xem bản gốc
Trang này có thể chứa nội dung của bên thứ ba, được cung cấp chỉ nhằm mục đích thông tin (không phải là tuyên bố/bảo đảm) và không được coi là sự chứng thực cho quan điểm của Gate hoặc là lời khuyên về tài chính hoặc chuyên môn. Xem Tuyên bố từ chối trách nhiệm để biết chi tiết.
Phân tích thách thức và giải pháp của sự chia cắt thanh khoản trong thời đại Layer 2
Nghiên cứu vấn đề phân tách thanh khoản trong thời đại Layer 2
Kể từ khi Ethereum chuyển sang các giải pháp mở rộng tập trung vào 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 cộng đã phát triển nhanh chóng. Nhiều thực thể muốn xây dựng chuỗi riêng của mình để đại diện cho các yêu cầu lợi ích khác nhau và tìm kiếm giá trị đánh giá cao hơn. Tuy nhiên, sự bùng nổ của nhiều chuỗi công cộng đã khiến phát triển hệ sinh thái không theo kịp bước tiến của các chuỗi công cộng, dẫn đến nhiều dự án đã giảm giá ngay khi TGE.
Nhờ vào OP Stack, một nền tảng giao dịch đã ra mắt Base Layer 2 của riêng mình, nền tảng giao dịch khác đã phát hành Ink; nhờ vào công nghệ ZK, một nền tảng đã ra mắt XLayer; Sony đã phát hành Soneium, LINE đã ra mắt Kaia, v.v. Hiện nay, chi phí 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 đô la 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ù các chuỗi Layer 2 này có thể chọn tính tương thích EVM để đạt được sự liên thông, nhưng do các thực thể Web2 đứng sau chúng có nhiều ứng dụng hạ nguồ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 không thể tránh khỏi, vì vậy 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 cấu thành các thành phần cốt lõi của trừu tượng chuỗi chéo từ trên xuống dưới:
Ứng dụng Layer 2 (Application Layer )
Đây là lớp tương tác trực tiếp với người dùng, 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 chi tiết của việc chuyển đổi thanh khoản. Tại lớp ứng dụng, người dùng tương tác với giao diện phía trước, có thể không hiểu cơ chế chuyển đổi thanh khoản ở lớp dưới.
Quyền truy cập lớp (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 đợi ( tức là đầu ra ), chứ không phải lộ trình thực hiện giao dịch cụ thể.
Quản lý tài khoản và quản lý khóa ( và trừu tượng hóa tài khoản )
Do sự tồn tại của môi trường đa chuỗi, cần 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 thực hiện 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ó.
Giải quyết lớp (Solver Layer)
Lớp này chịu trách nhiệm nhận và thực hiện ý định giao dịch của người dùng, vai trò Solver cạnh tranh ở đây để 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 nhanh hơn. Trên nền tảng này, các dự án dựa trên ý định đã xây dựng nhiều giải pháp dựa trên ý đị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 toán lớp (Settlement Layer)
Đây là lớp trung gian được sử dụng để giải quyết lớp 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à phân tán trạng thái bao gồm:
Ngoài ra, cần xem xét các yếu tố như thanh khoản giữa các chuỗi, tính chắc chắn cuối cùng )Finality(, cơ chế chứng minh Layer 2, để đảm bảo hoạt động hiệu quả của toàn bộ hệ thống đa chuỗi.
![Nghiên cứu về vấn đề chia cắt thanh khoản trong thời đại Layer2])https://img-cdn.gateio.im/webp-social/moments-a94f0982457fcb1d9c6ef2493b0a499f.webp(
Hiện tại, trên thị trường có nhiều giải pháp để chơi đùa với mọi người thanh khoản, sau khi xem xét nhiều giải pháp, chúng tôi nhận thấy chủ yếu có vài cách sau:
Tập trung vào RaaS: Giải pháp Rollup giống như OP Stack, thông qua việc thêm các bộ sắp xếp chia sẻ cụ thể và cầu nối xuyên chuỗi để hỗ trợ việc xây dựng Rollup trên OP Stack chia sẻ thanh khoản và trạng thái. Điều này hy vọng có thể giải quyết thanh khoản và trạng thái phân tán theo một hướng cao hơn. Ở đây có một phần thiết kế riêng cho bộ sắp xếp chia sẻ, giải pháp này chủ yếu nhắm đến Layer 2, không có tính phổ quát.
Lấy tài khoản làm trung tâm: Tương tự như NEAR, xây dựng một ví tài khoản toàn chuỗi, thông qua một công nghệ gọi là "chữ ký chuỗi" hỗ trợ ký và thực hiện giao dịch trên nhiều giao thức blockchain khác nhau. 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. Mặc dù giải pháp này có thể giải quyết rất nhiều 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 được về bản chất vấn đề thanh khoản và trạng thái phân tán.
Tập trung vào mạng ý định ngoài chuỗi: tức là mạng Solver trong sơ đồ kiến trúc "Giới thiệu" của bánh kem, cốt lõi là người dùng gửi ý định đến mạng Solver, vai trò Solver 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, những Solver này có thể là AI Agent, CEX, Nhà tạo lập thị trường đến chính giao thức tích hợp. Mặc dù ý định về lý thuyết có thể thực hiện các hoạt động xuyên chuỗi phức tạp với bất kỳ độ khó nào, nhưng trong thực hiện cần có đủ Solver thanh khoản để hỗ trợ, và khi gặp một số nhu cầu ngoài chuỗi, khả năng gian lận của Solver có thể xảy ra, nếu đưa vào các biện pháp như bằng chứng gian lận, độ khó trong việc thực hiện mạng Solver sẽ trở nên cao hơn, và ngưỡng để vận hành Solver cũng sẽ cao hơn.
Tập trung vào mạng lưới thanh khoản trên chuỗi: Hướng đi này chuyên tối ưu hóa vấn đề thanh khoản xuyên chuỗi, nhưng không giải quyết được vấn đề phân tán trạng thái trên chuỗi khác. Cốt lõi là xây dựng một lớp thanh khoản, trên lớp đó phát triển ứng dụng để chia sẻ thanh khoản toàn chuỗi.
Tập trung vào ứng dụng trên chuỗi: Những ứng dụng này xây dựng ứng dụng có tính thanh khoản cao bằng cách tích hợp MM lớn hoặc các ứng dụng bên thứ ba. Những dự án này cần quản lý quy trình liên chuỗi phức tạp, yêu cầu rất 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.
![Nghiên cứu về vấn đề chia tách thanh khoản trong thời đại Layer 2])https://img-cdn.gateio.im/webp-social/moments-e170f453d0b5b33f7ffc55facc9626c8.webp(
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, 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ư chuỗi chéo, oracle, Pre-Confirmation, 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 trừu tượng hoặc thanh khoản mà chúng tôi đã liệt kê ở trên được xây dựng theo các hướng khác nhau tương ứng với các cấp độ khác nhau trong mối quan hệ giữa các bên. Nhưng những giải pháp này vẫn không phải là giải pháp nguyên tử, vấn đề chia cắt thanh khoản toàn bộ đã mang lại nhiều vấn đề phức tạp khác xuất hiện, vì vậy đối với khả năng tương tác, đã phát sinh đủ loại giải pháp. 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 về khái niệm trừu tượng chuỗi, để xem mỗi dự án giải quyết vấn đề chia cắt 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, Asset, v.v., và cũng 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ể sử dụng ngay lập tức. Điều này tương đương với các đầu xây dựng ứng dụng khác, nhưng cuối cùng thanh khoản được đặt trên lớp thanh khoản của Infinit. Tuy nhiên, hiện tại vẫn chưa công bố nguyên lý làm việc của nó.
Mạng Khalani
Khalani xây dựng ba thành phần cốt lõi, lần lượt là 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 ý định bên ngoài thành định dạng mà giao thức Solver có thể nhận diện, định dạng chuẩn hóa được sử dụng là ngôn ngữ Validity. Nút Khalani chịu trách nhiệm nộp kết quả cuối cùng cho lớp thanh toán chung thông qua cầu chuỗi chéo, công nghệ thanh toán nhanh chóng, 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.
Liquorice
Liquorice là một ứng dụng phi tập trung, có khả năng phát hiện giá dựa trên đấu giá và các pool thanh khoản một chiều. 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ông cụ quản lý hàng tồn kho hiệu quả, và dễ dàng kết nối với các giao thức DeFi cốt lõi khi thực hiệ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.
Xion
Xion đượ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ũ nhận ra rằng có một vấn đề lớn về sự phân mảnh trong 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 trên giao thức đồng thuận Comet BFT. Giao tiếp đa chuỗi mà nó sử dụng dựa trên Cosmos IBC, do đó an toàn và nguyên bản hơn so với các cầu nối đa chuỗi khác.
![Nghiên cứu về vấn đề phân tách thanh khoản trong thời đại Layer 2]###https://img-cdn.gateio.im/webp-social/moments-0f51232f5a7495ce85432c8feb374ed1.webp(
)# =nil; Quỹ
nil là nhà phát triển thị trường sức mạnh ZK, bộ xử lý ZK và Layer 2 của Ethereum, độ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 ngang mạng chính Ethereum, thực hiện xử lý giao dịch song song qua phân đoạn và tạo ra ZKP, trong khi phân đoạn chính xác minh 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ý sự phân bố 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 gần đây. =nil; L2 từ đầu đã tích hợp giao tiếp giữa các phân đoạn vào giao thức. Tin nhắn giữa các phân đoạn được ủy ban xác thực của mỗi phân đoạn xác minh như là giao dịch.
Ý tưởng cơ bản của nó là, thông qua kiến trúc Layer 2 phân đoạn, để xây dựng một kiến trúc giao tiếp xuyên phân đoạn tương tự như IBC, như vậy sẽ giải quyết được vấn đề thanh khoản và trạng thái phân tán. Tuy nhiên, ý tưởng cốt lõi của nó không hợp lý, vì vấn đề phân tán thanh khoản là vấn đề đa chuỗi, mà nó xây dựng là một Layer 2 đơn nhất, có nghĩa là để giải quyết, cần tất cả các chuỗi trở thành một phân đoạn của ZK-sharding, điều này khó có thể thực hiện.
ERC-7683
Ethereum cũng đang tìm cách giải quyết vấn đề thanh khoản xuyên chuỗi này, hiện có nhiều nền tảng công khai hỗ trợ tiêu chuẩn ERC7683, cũng sử dụng phương pháp xuyên chuỗi dựa trên Intent. Mục tiêu cốt lõi là thiết lập tiêu chuẩn chung cho các hoạt động xuyên chuỗi giữa L2 và các sidechain, chuẩn hóa các giao diện đặt hàng và thanh toán, thực hiện thực thi xuyên chuỗi liền mạch, cốt lõi chính là một Filler cũng có thể được coi là vai trò Solver trong trừu tượng chuỗi đảm nhận thanh toán. Đề xuất này được xây dựng bởi hai dự án, hiện đang được nhóm Cake xem xét.
![Nghiên cứu vấn đề phân tách thanh khoản trong thời đại Layer 2]###https://img-cdn.gateio.im/webp-social/moments-e4d53accc40f8c915eaabbd2909f51d4.webp(
)# OP Stack
OP Stack, ERC-7683, và zkSharding cũng giống như nhau, đều là giải pháp cho sự phân mảnh thanh khoản giữa các Layer 2 trong nội bộ Ethereum, giải quyết ở các cấp độ kiến trúc, đồng thuận và ứ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 mọi vấn đề về truyền thông và phi tập trung hóa Sequencer, khi bạn sử dụng kiến trúc OP Stack, nó sẽ tự động triển khai hợp đồng đa chuỗi, đồng thời sẽ có một Supervisor để thách thức, tránh việc truyền tải thông tin đa chuỗi giả mạo. Hiện tại có nhiều dự án nổi tiếng đang sử dụng kiến trúc OP Stack.
Trong đó, một ví dụ điển hình là Unichain. Unichain chủ yếu thông qua