Nghiên cứu vấn đề phân tách thanh khoản trong thời đại Layer 2
Giới thiệu
Với việc Ethereum chuyển sang các giải pháp mở rộng tập trung vào Layer 2 và sự nổi lên của các công cụ như RaaS, nhiều blockchain công khai đang 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 lợi ích khác nhau và theo đuổi mức định giá cao hơn. Tuy nhiên, sự xuất hiện của nhiều blockchain công khai khiến cho sự phát triển của hệ sinh thái không thể theo kịp tốc độ của các blockchain công khai, dẫn đến nhiều dự án phải đối mặt với việc giảm giá ngay từ khi phát hành token ban đầu.
Nhờ vào công nghệ OP Stack, một nền tảng giao dịch đã ra mắt mạng Layer 2 của riêng mình là Base, trong khi một nền tảng giao dịch khác thì phát hành Ink; sử dụng công nghệ ZK, một nền tảng giao dịch đã ra mắt XLayer; Sony phát hành Soneium, LINE đã giới thiệu Kaia, v.v. Ngày 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ự tồn tại đồng thờ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ự giao tiếp, nhưng do các thực thể Web2 đứng sau chúng có nhiều ứng dụng hạ nguồn, nên chúng 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à không thể tránh khỏi, 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 cấu trúc Cake được công nhận trong ngành để giới thiệu từ trên xuống dưới về cấu thành của 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 tương tác trực tiếp của người dùng, cũng là lớp trừu tượng nhất trong các 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, chưa chắc đã 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 đợi (tức là đầu ra), chứ không phải là con đường thực hiện giao dịch cụ thể.
Quản lý tài khoản và trừu tượng hóa tài khoản (Key Management and Account Abstraction)
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 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 mà không cần thiết lập đồ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 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 cộng hiện có.
Lớp Giải (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ò của 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 cao hơn. Trên cơ sở 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 khác nhau. 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ể.
Lớp thanh toán (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à 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 (Bridges): Chịu trách nhiệm chuyển giao 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 chuỗi chéo.
Khả năng sử dụng dữ liệu (DA): Cung cấp khả năng truy cập dữ liệu.
Ngoài ra, còn cần xem xét tính 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 tại, trên thị trường có nhiều giải pháp để giải quyết tình trạng Thanh khoản bị chia cắt, sau khi xem xét nhiều giải pháp, chúng tôi nhận thấy chủ yếu có những cách sau đây:
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ẻ cụ thể và cầu nối chuỗi chéo để hỗ trợ chia sẻ thanh khoản và trạng thái của Rollup được xây dựng trên OP Stack. Đ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. Có một phần được phân loại hơn đó là thiết kế bộ sắp xếp chia sẻ riêng, 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: Bằng cách xây dựng một ví tài khoản toàn chuỗi, hỗ trợ ký và thực hiện giao dịch qua nhiều giao thức blockchain khác nhau. Thành phần cốt lõi là mạng MPC, thay mặt 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ề 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 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 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 cho đến chính giao thức tích hợp. Mặc dù ý định lý thuyết có thể thực hiện các thao tác chéo chuỗi phức tạp ở bất kỳ độ khó nào, nhưng trên thực tế cần có đủ Solver thanh khoản để hỗ trợ, và khi gặp một số nhu cầu bên ngoài chuỗi, có khả năng xảy ra gian lận từ Solver.
Trung tâm là 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 các chuỗi khác. Cốt lõi của nó 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.
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ó 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. Các dự án này cần quản lý quy trình đa 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 sự cố 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 tất cả. 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, Settlement Layer là giải pháp ở mức nguyên tử nhất, trên những giải pháp nguyên tử như cross-chain, oracle, và 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 được xây dựng theo nhiều hướng khác nhau mà chúng tôi đã liệt kê ở trên phù hợp với các cấp độ khác nhau của bộ quy tắc này, 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 đề toàn bộ thanh khoản bị chia cắt đã mang lại nhiều vấn đề phức tạp phát sinh, vì vậy để giải quyết tính tương tác, nhiều giải pháp phong phú đã được đưa ra. 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 trong khái niệm trừu tượng chuỗi, để xem từng dự án giải quyết vấn đề thanh khoản bị chia cắt 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 cho 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., đồng thời cũng cung cấp các thành phần như Giao dịch Kích thích và Chiến lược Lợi nhuận có thể được kích hoạt ngay lập tức. Điều này tương đương với các ứng dụng xây 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 họ vẫn chưa công bố nguyên lý hoạt động bên dưới. Hiện tại, INFINIT đã nhận được 6 triệu đô la trong vòng gọi vốn hạt giống.
Mạng Khalani
Khalani đã xây dựng ba thành phần cốt lõi, đó 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 các ý đị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. Node 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 nối 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 công bố thêm chi tiết công việc. Nó đã nhận được 2,2 triệu đô la Mỹ trong vòng gọi vốn hạt giống vào tháng 8.
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 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ác công cụ quản lý 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 thanh toán giao dịch với ý định sử dụng. Trong khi đó, Liquorice đã tạo ra một thị trường cho vay, để thực hiện các giao dịch cho vay. Ứng dụng này tập trung 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.
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 cho người tiêu dùng, sau đó đội ngũ nhận thấy vấn đề phân mảnh lớn 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, vì vậy nó an toàn và nguyên bản hơn so với các cầu nối đa chuỗi khác. Nó đã trải qua bốn vòng gọi vốn.
=nil; Foundation
nil là nhà phát triển thị trường công suất ZK, bộ xử lý đồng ZK và Layer 2 của Ethereum, đội ngũ có nền tảng kỹ thuật 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 phân đoạn và tạo ra ZKP, trong khi phân đoạn chính 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 người xác thực. Phân đoạn chính cũng quản lý sự phân phối của các người xác thực và tài khoản trong phân đoạn thực thi. Giao thức đồng thuận mà ủ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 từ đầu đã nhúng giao tiếp giữa các phân đoạn vào giao thức.
Ý 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 nhúng giống như IBC, như vậy có thể 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 của nó không hợp lý, vì vấn đề mà giải quyết phân tán thanh khoản 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 thì tất cả các chuỗi đều cần 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 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, và phương pháp sử dụng cũng dựa trên cách thức 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à sidechain, tiêu chuẩn hóa 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, và 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 để thanh toán. Đề xuất này hiện đang được nhóm làm việc Cake xem xét.
OP Stack
OP Stack, ERC-7683, và zkSharding đều là giải pháp cho vấn đề phân mảnh thanh khoản giữa các Layer2 trong Ethereum, được giải quyết từ các khía cạnh kiến trúc, đồng thuận và ứng dụng. OP Stack thiết kế một giải pháp đa Layer2 hoàn chỉnh để giải quyết một lần cho vấn đề truyền thông tin và phân quyền Sequencer. Khi bạn sử dụng kiến trúc OP Stack, nó sẽ tự động triển khai hợp đồng liên chuỗi, đồng thời sẽ có một Supervisor để thách thức nhằm tránh việc truyền tải thông tin liên chuỗi sai lệch. Hiện tại có nhiều nền tảng giao dịch nổi tiếng sử dụng kiến trúc OP Stack.
Trong đó, điển hình nhất là
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 vấn đề phân tách thanh khoản trong hệ sinh thái Layer 2 và giải pháp.
Nghiên cứu vấn đề phân tách thanh khoản trong thời đại Layer 2
Giới thiệu
Với việc Ethereum chuyển sang các giải pháp mở rộng tập trung vào Layer 2 và sự nổi lên của các công cụ như RaaS, nhiều blockchain công khai đang 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 lợi ích khác nhau và theo đuổi mức định giá cao hơn. Tuy nhiên, sự xuất hiện của nhiều blockchain công khai khiến cho sự phát triển của hệ sinh thái không thể theo kịp tốc độ của các blockchain công khai, dẫn đến nhiều dự án phải đối mặt với việc giảm giá ngay từ khi phát hành token ban đầu.
Nhờ vào công nghệ OP Stack, một nền tảng giao dịch đã ra mắt mạng Layer 2 của riêng mình là Base, trong khi một nền tảng giao dịch khác thì phát hành Ink; sử dụng công nghệ ZK, một nền tảng giao dịch đã ra mắt XLayer; Sony phát hành Soneium, LINE đã giới thiệu Kaia, v.v. Ngày 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ự tồn tại đồng thờ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ự giao tiếp, nhưng do các thực thể Web2 đứng sau chúng có nhiều ứng dụng hạ nguồn, nên chúng 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à không thể tránh khỏi, 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 cấu trúc Cake được công nhận trong ngành để giới thiệu từ trên xuống dưới về cấu thành của 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 tương tác trực tiếp của người dùng, cũng là lớp trừu tượng nhất trong các 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, chưa chắc đã 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 đợi (tức là đầu ra), chứ không phải là con đường thực hiện giao dịch cụ thể.
Quản lý tài khoản và trừu tượng hóa tài khoản (Key Management and Account Abstraction)
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 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 mà không cần thiết lập đồ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 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 cộng hiện có.
Lớp Giải (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ò của 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 cao hơn. Trên cơ sở 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 khác nhau. 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ể.
Lớp thanh toán (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à trạng thái phân tán bao gồm:
Ngoài ra, còn cần xem xét tính 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 tại, trên thị trường có nhiều giải pháp để giải quyết tình trạng Thanh khoản bị chia cắt, sau khi xem xét nhiều giải pháp, chúng tôi nhận thấy chủ yếu có những cách sau đây:
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ẻ cụ thể và cầu nối chuỗi chéo để hỗ trợ chia sẻ thanh khoản và trạng thái của Rollup được xây dựng trên OP Stack. Đ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. Có một phần được phân loại hơn đó là thiết kế bộ sắp xếp chia sẻ riêng, 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: Bằng cách xây dựng một ví tài khoản toàn chuỗi, hỗ trợ ký và thực hiện giao dịch qua nhiều giao thức blockchain khác nhau. Thành phần cốt lõi là mạng MPC, thay mặt 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ề 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 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 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 cho đến chính giao thức tích hợp. Mặc dù ý định lý thuyết có thể thực hiện các thao tác chéo chuỗi phức tạp ở bất kỳ độ khó nào, nhưng trên thực tế cần có đủ Solver thanh khoản để hỗ trợ, và khi gặp một số nhu cầu bên ngoài chuỗi, có khả năng xảy ra gian lận từ Solver.
Trung tâm là 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 các chuỗi khác. Cốt lõi của nó 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.
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ó 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. Các dự án này cần quản lý quy trình đa 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 sự cố 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 tất cả. 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, Settlement Layer là giải pháp ở mức nguyên tử nhất, trên những giải pháp nguyên tử như cross-chain, oracle, và 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 được xây dựng theo nhiều hướng khác nhau mà chúng tôi đã liệt kê ở trên phù hợp với các cấp độ khác nhau của bộ quy tắc này, 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 đề toàn bộ thanh khoản bị chia cắt đã mang lại nhiều vấn đề phức tạp phát sinh, vì vậy để giải quyết tính tương tác, nhiều giải pháp phong phú đã được đưa ra. 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 trong khái niệm trừu tượng chuỗi, để xem từng dự án giải quyết vấn đề thanh khoản bị chia cắt 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 cho 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., đồng thời cũng cung cấp các thành phần như Giao dịch Kích thích và Chiến lược Lợi nhuận có thể được kích hoạt ngay lập tức. Điều này tương đương với các ứng dụng xây 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 họ vẫn chưa công bố nguyên lý hoạt động bên dưới. Hiện tại, INFINIT đã nhận được 6 triệu đô la trong vòng gọi vốn hạt giống.
Mạng Khalani
Khalani đã xây dựng ba thành phần cốt lõi, đó 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 các ý đị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. Node 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 nối 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 công bố thêm chi tiết công việc. Nó đã nhận được 2,2 triệu đô la Mỹ trong vòng gọi vốn hạt giống vào tháng 8.
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 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ác công cụ quản lý 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 thanh toán giao dịch với ý định sử dụng. Trong khi đó, Liquorice đã tạo ra một thị trường cho vay, để thực hiện các giao dịch cho vay. Ứng dụng này tập trung 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.
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 cho người tiêu dùng, sau đó đội ngũ nhận thấy vấn đề phân mảnh lớn 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, vì vậy nó an toàn và nguyên bản hơn so với các cầu nối đa chuỗi khác. Nó đã trải qua bốn vòng gọi vốn.
=nil; Foundation
nil là nhà phát triển thị trường công suất ZK, bộ xử lý đồng ZK và Layer 2 của Ethereum, đội ngũ có nền tảng kỹ thuật 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 phân đoạn và tạo ra ZKP, trong khi phân đoạn chính 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 người xác thực. Phân đoạn chính cũng quản lý sự phân phối của các người xác thực và tài khoản trong phân đoạn thực thi. Giao thức đồng thuận mà ủ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 từ đầu đã nhúng giao tiếp giữa các phân đoạn vào giao thức.
Ý 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 nhúng giống như IBC, như vậy có thể 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 của nó không hợp lý, vì vấn đề mà giải quyết phân tán thanh khoản 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 thì tất cả các chuỗi đều cần 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 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, và phương pháp sử dụng cũng dựa trên cách thức 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à sidechain, tiêu chuẩn hóa 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, và 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 để thanh toán. Đề xuất này hiện đang được nhóm làm việc Cake xem xét.
OP Stack
OP Stack, ERC-7683, và zkSharding đều là giải pháp cho vấn đề phân mảnh thanh khoản giữa các Layer2 trong Ethereum, được giải quyết từ các khía cạnh kiến trúc, đồng thuận và ứng dụng. OP Stack thiết kế một giải pháp đa Layer2 hoàn chỉnh để giải quyết một lần cho vấn đề truyền thông tin và phân quyền Sequencer. Khi bạn sử dụng kiến trúc OP Stack, nó sẽ tự động triển khai hợp đồng liên chuỗi, đồng thời sẽ có một Supervisor để thách thức nhằm tránh việc truyền tải thông tin liên chuỗi sai lệch. Hiện tại có nhiều nền tảng giao dịch nổi tiếng sử dụng kiến trúc OP Stack.
Trong đó, điển hình nhất là