Phân tích vấn đề phân mảnh thanh khoản và giải pháp trong thời đại đa chuỗi

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

Sau khi Ethereum chuyển sang 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, rất 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 họ để đại diện cho các lợi ích 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 bước tiến của các chuỗi công khai, dẫn đến nhiều dự án gặp khó khăn ngay từ giai đoạn đầu.

Nhờ có OP Stack, một nền tảng giao dịch đã ra mắt Layer 2 của riêng mình, một nền tảng giao dịch khác đã phát hành dự án blockchain mới; nhờ công nghệ ZK, một nền tảng giao dịch đã ra mắt một lớp mới. Một số công ty công nghệ lớn cũng lần lượt phát hành dự án blockchain của riêng mình. 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ự đồ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ự giao tiếp, nhưng do các công ty công nghệ truyền thống đứng sau chúng có rất nhiều ứng dụng hạ nguồn, nên rất khó để họ 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, 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.

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

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 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.

Lớp ứng dụng: Đâ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 chi tiết của việc chuyển đổi thanh khoản. Trong 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.

Quyền hạn lớp: 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, chứ không phải là lộ trình thực hiện giao dịch cụ thể.

Quản lý tài khoản và lớp trừu tượng: 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 trưng của từng chuỗi. Một số dự án đã xây dựng hệ thống tài khoản 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 tin cậy giữa các hệ thống tài khoản hiện có. Còn một số dự án khác thông qua việc tạo ví tài khoản đa chuỗi cho người dùng để thực hiện quản lý trừu tượng, tối ưu hóa rất lớn trải nghiệm người dùng, 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: 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. 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. Các sản phẩm phái sinh của các 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ể.

Tầng thanh toán: Đây là tầng trung gian được sử dụng để giải quyết ý đị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ầu nối chuỗi chéo, kế hoạch xác nhận trước và khả năng sẵn có của 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, 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.

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

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ị割, sau khi xem xét nhiều giải pháp, chúng tôi phát hiện ra rằng chủ yếu có các cách sau đây:

  1. Tập trung vào RaaS: Giống như một số giải pháp Rollup, thông qua việc kết nối các bộ sắp xếp chia sẻ cụ thể và cầu nối xuyên chuỗi để hỗ trợ chia sẻ thanh khoản và trạng thái cho các Rollup được xây dựng trên đó. Đ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 theo một hướng cao hơn. Trong đó có một phần thiết kế chia sẻ sắp xếp 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, hỗ trợ ký và thực hiện giao dịch qua nhiều giao thức blockchain thông qua một công nghệ gọi là "chuỗi chữ ký". Thành phần cốt lõi là mạng MPC, thay mặt người dùng ký cho 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 triển khai backend phức tạp và không giải quyết được bản chất vấn đề Thanh khoản và trạng thái phân tán.

  3. Tập trung vào mạng lưới ý định ngoài chuỗi: tức là mạng lưới Solver trong sơ đồ cấu trúc "Giới thiệu" của chúng tô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 để đưa ra 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, sàn giao dịch, nhà tạo lập thị trường hoặc thậm chí là 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 chuỗi chéo phức tạp với bất kỳ độ khó nào, nhưng về mặt thực hiện, cần có đủ thanh khoản của Solver để hỗ trợ, và khi gặp một số nhu cầu ngoài chuỗi, có khả năng xảy ra gian lận ở 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à rào cản để vận hành Solver cũng sẽ cao hơn.

  4. Tập trung vào mạng lưới thanh khoản trên chuỗi: Hướng này chuyên tối ưu hóa vấn đề thanh khoản giữa các chuỗi, nhưng chưa 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 này xây dựng ứng dụng, nhằm 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 thanh khoản cao bằng cách tích hợp các nhà tạo lập thị trường 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 xuyê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ễ xuất hiện lỗ hổng bảo mật.

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 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 dựa trên cấu trúc bánh cake, 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ư cross-chain, oracle, Pre-Confirmation, thì đượ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 trừu tượng hoặc thanh khoản mà chúng tôi đã liệt kê ở trên theo những hướng khác nhau để xây dựng phù hợp với các cấp độ khác nhau này, có thể hiểu là 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 đề toàn bộ thanh khoản bị cắt rời đã mang lại nhiều vấn đề phức tạp phát sinh, do đó, đối với tính tương tác, đã phát sinh ra vô số giải pháp khác nhau. Nhưng về bản chất vẫn phải dựa vào những thành phần này.

Nghiên cứu về vấn đề chia cắt thanh khoản trong thời đại Layer2

Tiếp theo, chúng ta sẽ thảo luận về một số dự án điển hình của các khái niệm trừu tượng chuỗi, để xem mỗi dự án giải quyết vấn đề thanh khoản割 từ điểm khởi đầu của mình như thế nào.

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, như Oracle, Pool Type, IRM, Asset, v.v. Nó 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 Lợi nhuận có thể sử dụng ngay lập tức. Tương đương với các ứng dụng xây dựng ở đầu khác, nhưng thanh khoản cuối cùng được đặt trên lớp thanh khoản của dự án này. 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 chung. 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 các ý đị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 chung thông qua cầu nối đa chuỗi, công nghệ thanh toán nhanh, v.v. Dự án này vẫn đang trong giai đoạn xây dựng và chưa tiết lộ thêm chi tiết công việc.

Còn một dự án là một ứng dụng phi tập trung, có thể thực hiện 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 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ý tồn kho hiệu quả, và kết nối dễ dàng với các giao thức DeFi cốt lõi khi thanh toán giao dịch theo ý định sử dụng. Trong khi đó, dự án đã tạo ra thị trường cho vay, để thực hiện các giao dịch cho vay. Ứng dụng này còn tập trung nhiều hơn vào bản thân giao dịch.

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

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

Một quỹ là nhà phát triển thị trường sức mạnh ZK của Ethereum, bộ xử lý ZK và Layer 2, đội ngũ có nền tảng vững chắc về công nghệ ZK. Đã đề 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 việc xử lý giao dịch song song 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ộ hóa trạng thái mạng giữa tất cả các nhà xác thực. Phân đoạn chính cũng quản lý sự phân phối của các nhà xác thực 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. Giải pháp này đã tích hợp việc truyền thông qua các phân đoạn vào giao thức ngay từ đầu. Tin nhắn qua 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 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, như vậy có thể giải quyết 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 đề giải quyết sự phân tán thanh khoản là vấn đề của nhiều chuỗi, trong khi nó xây dựng một Layer 2 đơn lẻ, 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 mảnh của ZK-sharding, điều này khó có thể thực hiện.

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

Ethereum cũng đang giải quyết vấn đề thanh khoản đa chuỗi này, hiện có một vài dự án lớn công khai hỗ trợ một tiêu chuẩn ERC nào đó, cách thức sử dụng cũng dựa trên phương pháp đa 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 đa chuỗi qua L2 và các chuỗi bên, tiêu chuẩn hóa các giao diện đặt hàng và thanh toán, thực hiện thực thi đa chuỗi liền mạch, 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 chi trả. Đề xuất này được xây dựng bởi hai dự án chính và hiện đang được nhóm làm việc xem xét.

Một ngăn xếp công nghệ, tiêu chuẩn ERC trên, và zkSharding giống nhau, đều là giải pháp cho vấn đề 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. Ngăn xếp công nghệ này 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 tin và phi tập trung hóa Sequencer, khi bạn sử dụng kiến trúc ngăn xếp công nghệ này, 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 thông tin liên chuỗi giả. Hiện tại có nhiều dự án nổi tiếng đang sử dụng kiến trúc ngăn xếp công nghệ này.

Nghiên cứu về vấn đề phân chia thanh khoản trong thời đại Layer2

Giải quyết vấn đề thanh khoản xuyên chuỗi là một lĩnh vực rất phức tạp và có nhiều giải pháp khác nhau, chẳng hạn như các giải pháp Layer 2 được phân chia từ việc tích hợp thông điệp xuyên chuỗi trong Ethereum, đặc biệt là các tiêu chuẩn ERC được đề cập ở trên, và còn có các Sequencer chia sẻ được xây dựng từ một công nghệ cụ thể để giải quyết. Ra khỏi bối cảnh Layer 2, tất cả các Layer 1 cũng...

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 thưởng
  • 5
  • Chia sẻ
Bình luận
0/400
HalfPositionRunnervip
· 07-07 10:37
Lại là một mớ hỗn độn... chơi đùa với mọi người thật triệt để
Xem bản gốcTrả lời0
ThreeHornBlastsvip
· 07-06 21:46
L2 quá nhiều thật rối. Khi nào mới có thể thống nhất?
Xem bản gốcTrả lời0
LeverageAddictvip
· 07-06 21:45
Chơi đa chuỗi lộn xộn như thế nào?
Xem bản gốcTrả lời0
ForkLibertarianvip
· 07-06 21:36
Mọi người đều muốn trở thành chain daddy phải không?
Xem bản gốcTrả lời0
SybilAttackVictimvip
· 07-06 21:22
thế giới tiền điện tử chơi đùa với mọi người này ai gánh chịu? Thật sự ai cũng muốn trở thành ông lớn L2 thôi.
Xem bản gốcTrả lời0
Giao dịch tiền điện tử mọi lúc mọi nơi
qrCode
Quét để tải xuống ứng dụng Gate
Cộng đồng
Tiếng Việt
  • 简体中文
  • English
  • Tiếng Việt
  • 繁體中文
  • Español
  • Русский
  • Français (Afrique)
  • Português (Portugal)
  • Bahasa Indonesia
  • 日本語
  • بالعربية
  • Українська
  • Português (Brasil)