Nghiên cứu 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 đang phát triển nhanh chóng. Nhiều thực thể hy vọng 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à tìm kiếm định giá cao hơn. Tuy nhiên, sự xuất hiện của nhiều chuỗi công khai đã khiến sự phát triển của hệ sinh thái khó theo kịp nhịp độ của các chuỗi công khai, dẫn đến nhiều dự án bị 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 giao dịch đã 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 USD mỗi tháng.
Thế giới tương lai chắc chắn sẽ là thời đại của sự đồng tồn 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, chúng khó có thể xây dựng ứng dụng trên cùng một chuỗi và đạt được sự đồng thuận.
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, 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 rộng rãi trong ngành để giới thiệu từ trên xuống dưới cấu thành các thành phần cốt lõi của trừu tượng cross-chain:
Lớp ứng dụng (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 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á để thỏa mãn ý đị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 phù hợp 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 hệ thống tài khoản đáng tin cậy mà 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 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 (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 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. Trên cơ sở đó, 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à phân tán trạng thái bao gồm:
Oracle (Dự đoán): dùng để获取 thông tin trạng thái từ các chuỗi khác.
Cầu nối chuỗi (Bridges): Chịu trách nhiệm về việc 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 chuỗi chéo.
Tính khả dụng của 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 xác nhận cuối cùng (Finality), cơ chế chứng minh Layer 2, v.v. để đả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ị cắt đứt, chúng tôi đã xem xét nhiều giải pháp và nhận thấy chủ yếu có một số cách sau:
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 chuỗi chéo cụ thể để hỗ trợ chia sẻ thanh khoản và trạng thái cho các Rollup được xây dựng trên OP Stack. Điều này hy vọng có thể giải quyết sự phân tán thanh khoản và trạng thái ở một cấp độ cao hơn. Có một phần phân tách 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.
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ệ gọi là "chuỗi chữ ký" 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. Giải pháp này, mặc dù có thể giải quyế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 ý định ngoại tuyến: Cốt lõi là người dùng gửi ý định cho 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 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 xuyên chuỗi phức tạp với bất kỳ độ khó nào, nhưng trong thực tế, cần có đủ Solver thanh khoản để hỗ trợ, và khi gặp một số nhu cầu ngoại tuyến, 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ó thực hiện mạng Solver sẽ tăng lên, và ngưỡng tham gia để 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 được thiết kế đặc biệt để tối ưu hóa vấn đề thanh khoản giữa các 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 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 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 đ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 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 qua nhiều giải pháp khác nhau.
Trong hai phân loại trên, chúng ta có thể thấy rằng theo cấu trúc bánh sinh nhật, Settlement Layer là giải pháp ở cấp độ nguyên tử nhất, và trên những giải pháp nguyên tử như cross-chain, oracle, Pre-Confirmation, một lớp trừu tượng hơn được xây dựng, đó là Solver Layer, Permission Layer và Application Layer. Các giải pháp trừu tượng hoặc thanh khoản 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 trong mối quan hệ giữa hạ nguồn và thượng 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 đề cắt đứt thanh khoản toàn bộ đã gây ra nhiều vấn đề phức tạp phát sinh, do đó đã phát sinh ra nhiều giải pháp đa dạng nhằm giải quyết tính tương tác. Nhưng về bản chất, vẫn cần phải dựa vào những thành phần này. Tiếp theo, chúng ta sẽ thảo luận về một vài dự án tiêu biểu về khái niệm trừu tượng chuỗi, để xem mỗi dự án đã giải quyết vấn đề cắt đứt thanh khoản như thế nào từ điểm xuất phát của riêng mình.
Một dự án đã 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, chẳng hạn như Oracle, Pool Type, IRM, Asset, v.v., và còn cung cấp các thành phần như Giao dịch Đòn bẩy và Chiến lược Lợi suất có thể được kích hoạt ngay lập tức. Tương đương với các ứng dụng xây dựng khác, nhưng thanh khoản cuối cùng được đặt trên lớp thanh khoản của dự án đó. Tuy nhiên, hiện tại nó vẫn chưa tiết lộ nguyên lý hoạt động cơ bản.
Một dự án khác đã 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 tổng quát. Các ứng dụng bên ngoài hoặc lớp ý định có thể phát hành ý định cho dự án này, sau đó lớp tương thích Intent của nó có thể chuyển đổi ý định bên ngoài thành định dạng mà Solver giao thức có thể nhận diện, định dạng chuẩn hóa được sử dụng là ngôn ngữ Validity. Các nút của dự án này có trách nhiệm gửi kết quả cuối cùng đến lớp thanh toán tổng quát 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 và chưa công bố thêm chi tiết công việc.
Còn một ứng dụng phi tập trung, có thể thực hiện việc phát hiện giá dựa trên đấu giá và bể thanh khoản một chiều. Sứ mệnh chính của nó là cung cấp cho các công ty giao dịch chuyên nghiệp những công cụ quản lý hàng tồn kho hiệu quả, và kết nối dễ dàng đến các giao thức DeFi cốt lõi khi thanh toán giao dịch theo ý định sử dụng. Trong lúc đó, dự án này đã tạo ra một thị trường cho vay, để thực hiện giao dịch cho vay. Ứng dụng này tập trung nhiều hơn vào bản thân giao dịch. Hiện tại vẫn đang trong giai đoạn phát triển.
Một dự án được xây dựng dựa trên giao thức đồng thuận Comet BFT. Giao tiếp chuỗi chéo được áp dụng dựa trên Cosmos IBC, vì vậy nó nguyên bản và an toàn hơn so với các cầu nối chuỗi chéo khác.
Còn một dự án là thị trường sức mạnh tính toán ZK của Ethereum, bộ đồng xử lý ZK và các nhà phát triển Layer 2, độ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 theo chiều 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ộ hóa 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 bố 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. Dự án L2 đã nhúng giao tiếp giữa các phân đoạn vào giao thức ngay từ đầu. 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 thực 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 giữa các phân đoạn tích hợp giống như IBC, từ đó 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 đề phân tán thanh khoản giải quyết các 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, tất cả các chuỗi cần trở thành một phân đoạn của ZK-sharding, điều này rất khó thực hiện.
Ethereum cũng đang nỗ lực giải quyết vấn đề thanh khoản liên chuỗi này, hiện tại một số dự án đã công khai hỗ trợ tiêu chuẩn ERC7683, mà cách thức sử dụng cũng dựa trên phương pháp liê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 liên chuỗi giữa L2 và sidechain, tiêu chuẩn hóa các giao diện đặt hàng và thanh toán, thực hiện việc thực thi liê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 thay mặt thanh toán. Đề xuất này hiện đang được nhóm Cake xem xét.
OP Stack, ERC-7683, và zkSharding đều là các giải pháp cho việc phân mảnh thanh khoản giữa các Layer 2 trong Ethereum, được 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 các vấn đề truyền thông tin và phi tập trung hóa Sequencer. Khi bạn sử dụng kiến trúc OP Stack, các hợp đồng liên chuỗi sẽ được triển khai tự động và 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, một số nền tảng giao dịch chính đ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 nối với mạng Superchain.
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.
Thời đại Layer 2: Nghiên cứu vấn đề phân tách thanh khoản và giải pháp
Nghiên cứu 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 đang phát triển nhanh chóng. Nhiều thực thể hy vọng 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à tìm kiếm định giá cao hơn. Tuy nhiên, sự xuất hiện của nhiều chuỗi công khai đã khiến sự phát triển của hệ sinh thái khó theo kịp nhịp độ của các chuỗi công khai, dẫn đến nhiều dự án bị 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 giao dịch đã 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 USD mỗi tháng.
Thế giới tương lai chắc chắn sẽ là thời đại của sự đồng tồn 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, chúng khó có thể xây dựng ứng dụng trên cùng một chuỗi và đạt được sự đồng thuận.
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, 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 rộng rãi trong ngành để giới thiệu từ trên xuống dưới cấu thành các thành phần cốt lõi của trừu tượng cross-chain:
Lớp ứng dụng (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 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á để thỏa mãn ý đị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 phù hợp 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 hệ thống tài khoản đáng tin cậy mà 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 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 (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 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. Trên cơ sở đó, 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à 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 xác nhận cuối cùng (Finality), cơ chế chứng minh Layer 2, v.v. để đả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ị cắt đứt, chúng tôi đã xem xét nhiều giải pháp và nhận thấy chủ yếu có một số cách sau:
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 chuỗi chéo cụ thể để hỗ trợ chia sẻ thanh khoản và trạng thái cho các Rollup được xây dựng trên OP Stack. Điều này hy vọng có thể giải quyết sự phân tán thanh khoản và trạng thái ở một cấp độ cao hơn. Có một phần phân tách 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.
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ệ gọi là "chuỗi chữ ký" 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. Giải pháp này, mặc dù có thể giải quyế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 ý định ngoại tuyến: Cốt lõi là người dùng gửi ý định cho 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 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 xuyên chuỗi phức tạp với bất kỳ độ khó nào, nhưng trong thực tế, cần có đủ Solver thanh khoản để hỗ trợ, và khi gặp một số nhu cầu ngoại tuyến, 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ó thực hiện mạng Solver sẽ tăng lên, và ngưỡng tham gia để 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 được thiết kế đặc biệt để tối ưu hóa vấn đề thanh khoản giữa các 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 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 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 đ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 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 qua nhiều giải pháp khác nhau.
Trong hai phân loại trên, chúng ta có thể thấy rằng theo cấu trúc bánh sinh nhật, Settlement Layer là giải pháp ở cấp độ nguyên tử nhất, và trên những giải pháp nguyên tử như cross-chain, oracle, Pre-Confirmation, một lớp trừu tượng hơn được xây dựng, đó là Solver Layer, Permission Layer và Application Layer. Các giải pháp trừu tượng hoặc thanh khoản 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 trong mối quan hệ giữa hạ nguồn và thượng 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 đề cắt đứt thanh khoản toàn bộ đã gây ra nhiều vấn đề phức tạp phát sinh, do đó đã phát sinh ra nhiều giải pháp đa dạng nhằm giải quyết tính tương tác. Nhưng về bản chất, vẫn cần phải dựa vào những thành phần này. Tiếp theo, chúng ta sẽ thảo luận về một vài dự án tiêu biểu về khái niệm trừu tượng chuỗi, để xem mỗi dự án đã giải quyết vấn đề cắt đứt thanh khoản như thế nào từ điểm xuất phát của riêng mình.
Một dự án đã 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, chẳng hạn như Oracle, Pool Type, IRM, Asset, v.v., và còn cung cấp các thành phần như Giao dịch Đòn bẩy và Chiến lược Lợi suất có thể được kích hoạt ngay lập tức. Tương đương với các ứng dụng xây dựng khác, nhưng thanh khoản cuối cùng được đặt trên lớp thanh khoản của dự án đó. Tuy nhiên, hiện tại nó vẫn chưa tiết lộ nguyên lý hoạt động cơ bản.
Một dự án khác đã 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 tổng quát. Các ứng dụng bên ngoài hoặc lớp ý định có thể phát hành ý định cho dự án này, sau đó lớp tương thích Intent của nó có thể chuyển đổi ý định bên ngoài thành định dạng mà Solver giao thức có thể nhận diện, định dạng chuẩn hóa được sử dụng là ngôn ngữ Validity. Các nút của dự án này có trách nhiệm gửi kết quả cuối cùng đến lớp thanh toán tổng quát 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 và chưa công bố thêm chi tiết công việc.
Còn một ứng dụng phi tập trung, có thể thực hiện việc phát hiện giá dựa trên đấu giá và bể thanh khoản một chiều. Sứ mệnh chính của nó là cung cấp cho các công ty giao dịch chuyên nghiệp những công cụ quản lý hàng tồn kho hiệu quả, và kết nối dễ dàng đến các giao thức DeFi cốt lõi khi thanh toán giao dịch theo ý định sử dụng. Trong lúc đó, dự án này đã tạo ra một thị trường cho vay, để thực hiện giao dịch cho vay. Ứng dụng này tập trung nhiều hơn vào bản thân giao dịch. Hiện tại vẫn đang trong giai đoạn phát triển.
Một dự án được xây dựng dựa trên giao thức đồng thuận Comet BFT. Giao tiếp chuỗi chéo được áp dụng dựa trên Cosmos IBC, vì vậy nó nguyên bản và an toàn hơn so với các cầu nối chuỗi chéo khác.
Còn một dự án là thị trường sức mạnh tính toán ZK của Ethereum, bộ đồng xử lý ZK và các nhà phát triển Layer 2, độ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 theo chiều 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ộ hóa 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 bố 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. Dự án L2 đã nhúng giao tiếp giữa các phân đoạn vào giao thức ngay từ đầu. 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 thực 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 giữa các phân đoạn tích hợp giống như IBC, từ đó 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 đề phân tán thanh khoản giải quyết các 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, tất cả các chuỗi cần trở thành một phân đoạn của ZK-sharding, điều này rất khó thực hiện.
Ethereum cũng đang nỗ lực giải quyết vấn đề thanh khoản liên chuỗi này, hiện tại một số dự án đã công khai hỗ trợ tiêu chuẩn ERC7683, mà cách thức sử dụng cũng dựa trên phương pháp liê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 liên chuỗi giữa L2 và sidechain, tiêu chuẩn hóa các giao diện đặt hàng và thanh toán, thực hiện việc thực thi liê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 thay mặt thanh toán. Đề xuất này hiện đang được nhóm Cake xem xét.
OP Stack, ERC-7683, và zkSharding đều là các giải pháp cho việc phân mảnh thanh khoản giữa các Layer 2 trong Ethereum, được 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 các vấn đề truyền thông tin và phi tập trung hóa Sequencer. Khi bạn sử dụng kiến trúc OP Stack, các hợp đồng liên chuỗi sẽ được triển khai tự động và 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, một số nền tảng giao dịch chính đ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 nối với mạng Superchain.