Lĩnh vực bị bỏ qua của mô-đun: tầng thực thi, thanh toán và tập hợp
Tuyển chọn TechFlowTuyển chọn TechFlow
Lĩnh vực bị bỏ qua của mô-đun: tầng thực thi, thanh toán và tập hợp
Các ngăn xếp mô-đun không chỉ có DA và lớp sắp xếp là đáng chú ý.
Chuyên sâu báo cáo Web3Tác giả: Bridget Harris
Biên dịch: Luffy, Foresight News
Xét về mức độ quan tâm và tính đổi mới, các thành phần của ngăn xếp mô-đun không hoàn toàn giống nhau. Trong khi trước đây có rất nhiều dự án đã đổi mới ở lớp khả dụng dữ liệu (DA) và lớp sắp thứ tự, thì gần đây các lớp thực thi và thanh toán mới bắt đầu được chú trọng như một phần của ngăn xếp mô-đun.
Lĩnh vực bộ sắp thứ tự chia sẻ đang cạnh tranh khốc liệt, với nhiều dự án như Espresso, Astria, Radius, Rome và Madara đang tranh giành thị phần. Ngoài ra còn có các nhà cung cấp RaaS như Caldera và Conduit, những bên này xây dựng bộ sắp thứ tự chia sẻ cho các Rollup được phát triển trên nền tảng của họ. Những nhà cung cấp RaaS này có thể cung cấp phí thấp hơn cho Rollup vì mô hình kinh doanh cơ bản của họ không hoàn toàn phụ thuộc vào doanh thu từ việc sắp thứ tự. Nhiều Rollup khác chọn tự vận hành bộ sắp thứ tự để hưởng toàn bộ phí tạo ra.
Thị trường bộ sắp thứ tự là độc đáo so với lĩnh vực DA. Lĩnh vực DA về cơ bản là một dạng độc quyền do ba ông lớn Celestia, Avail và EigenDA thống trị, khiến cho các đối thủ nhỏ mới gia nhập khó có thể thành công phá vỡ thị trường. Các dự án hoặc là tận dụng lựa chọn "sẵn có" (Ethereum), hoặc chọn một trong các lớp DA trưởng thành phù hợp với loại ngăn xếp kỹ thuật và yêu cầu nhất quán của riêng họ. Mặc dù sử dụng lớp DA giúp tiết kiệm đáng kể chi phí, nhưng việc thuê ngoài bộ sắp thứ tự không phải là lựa chọn rõ ràng (xét về mặt phí, chứ không phải an ninh), chủ yếu do chi phí cơ hội từ việc từ bỏ doanh thu sắp thứ tự. Nhiều người cũng cho rằng DA sẽ trở thành hàng hóa, nhưng trong tiền mã hóa chúng ta thấy rằng hào bảo vệ về tính thanh khoản siêu mạnh kết hợp với công nghệ nền tảng độc đáo (khó sao chép) khiến việc hàng hóa hóa bất kỳ tầng nào trong ngăn xếp đều cực kỳ khó khăn. Dù các tranh luận này diễn ra thế nào đi nữa, vẫn có rất nhiều sản phẩm DA và sắp thứ tự tiếp tục ra mắt. Tóm lại, đối với một số ngăn xếp mô-đun, “mỗi dịch vụ đều có vài đối thủ cạnh tranh”.
Tôi cho rằng các tầng thực thi, thanh toán (và tập hợp) hiện tại chưa được khám phá đầy đủ, nhưng chúng đang bắt đầu được lặp lại theo cách mới để phù hợp tốt hơn với phần còn lại của ngăn xếp mô-đun.
Mối quan hệ giữa lớp thực thi và lớp thanh toán
Lớp thực thi và lớp thanh toán được tích hợp chặt chẽ, trong đó lớp thanh toán có thể đóng vai trò là nơi xác định kết quả cuối cùng của trạng thái thực thi. Lớp thanh toán cũng có thể bổ sung chức năng nâng cao cho kết quả thực thi, làm cho lớp thực thi mạnh mẽ và an toàn hơn. Trong thực tế, điều này có thể mang nhiều ý nghĩa khác nhau, ví dụ như lớp thanh toán có thể hoạt động như môi trường giải quyết tranh chấp gian lận, xác minh bằng chứng và kết nối với các lớp thực thi khác.
Cần lưu ý rằng một số nhóm hỗ trợ trực tiếp việc phát triển môi trường thực thi tùy chỉnh trong giao thức riêng của họ, ví dụ như Repyh Labs, đang xây dựng một L1 tên là Delta. Về bản chất, thiết kế này trái ngược với ngăn xếp mô-đun, nhưng vẫn cung cấp sự linh hoạt trong một môi trường thống nhất và có lợi thế về tính tương thích kỹ thuật, bởi vì nhóm không cần dành thời gian để tích hợp thủ công từng phần của ngăn xếp mô-đun. Tất nhiên, nhược điểm là bị cô lập về mặt thanh khoản, không thể lựa chọn các tầng mô-đun phù hợp nhất với thiết kế của mình, đồng thời chi phí quá cao.
Các nhóm khác chọn xây dựng L1 chuyên biệt cho một chức năng hoặc ứng dụng chính. Hyperliquid là một ví dụ, khi họ xây dựng một L1 chuyên dụng cho ứng dụng gốc chủ lực của mình (sàn giao dịch phái sinh vĩnh viễn). Mặc dù người dùng của họ cần bridge từ Arbitrum, nhưng kiến trúc cốt lõi của họ không phụ thuộc vào Cosmos SDK hay các framework khác, nhờ đó có thể tùy chỉnh và tối ưu hóa nhanh chóng cho trường hợp sử dụng chính.
Tiến triển ở lớp thực thi
Ở chu kỳ trước, đặc điểm duy nhất giúp các alt-L1 phổ quát vượt trội hơn Ethereum là thông lượng cao hơn. Điều này có nghĩa rằng nếu một dự án muốn cải thiện hiệu suất đáng kể, họ gần như phải bắt đầu xây dựng L1 riêng từ đầu, chủ yếu vì bản thân Ethereum vẫn chưa có công nghệ đó. Xét về lịch sử, điều này đơn giản chỉ là việc nhúng trực tiếp các cơ chế hiệu quả vào giao thức phổ quát. Ở chu kỳ này, những cải tiến hiệu suất này đạt được thông qua thiết kế mô-đun, và ngay trên nền tảng hợp đồng thông minh hàng đầu là Ethereum. Nhờ vậy, cả các dự án hiện tại và mới đều có thể tận dụng hạ tầng lớp thực thi mới mà không phải hy sinh thanh khoản, an ninh và hào cộng đồng của Ethereum.
Hiện tại, chúng ta cũng thấy ngày càng nhiều việc kết hợp và lựa chọn linh hoạt các máy ảo khác nhau (môi trường thực thi) như một phần của mạng chia sẻ, điều này mang lại sự linh hoạt cho nhà phát triển và khả năng tùy chỉnh tốt hơn ở lớp thực thi. Ví dụ, Layer N cho phép các nhà phát triển chạy các nút Rollup phổ quát (như SolanaVM, MoveVM, v.v.) và các nút Rollup chuyên biệt theo ứng dụng (ví dụ: DEX phái sinh vĩnh viễn, DEX sổ lệnh) trên máy trạng thái chia sẻ của họ. Họ cũng đang nỗ lực đạt được khả năng kết hợp hoàn toàn và chia sẻ thanh khoản giữa các kiến trúc VM khác nhau—một vấn đề kỹ thuật trên chuỗi vốn khó thực hiện quy mô lớn từ trước đến nay. Mỗi ứng dụng trên Layer N có thể truyền tin nhắn không đồng bộ mà không có độ trễ về mặt đồng thuận, vốn thường là vấn đề "chi phí liên lạc" trong tiền mã hóa. Mỗi xVM cũng có thể sử dụng các kiến trúc cơ sở dữ liệu khác nhau, như RocksDB, LevelDB hoặc cơ sở dữ liệu đồng bộ / bất đồng bộ tùy chỉnh được tạo từ đầu. Phần tương tác hoạt động thông qua "hệ thống snapshot" (một thuật toán tương tự Chandy-Lamport), trong đó các chuỗi có thể chuyển sang khối mới một cách bất đồng bộ mà không cần tạm dừng hệ thống. Về an ninh, nếu chuyển đổi trạng thái sai, có thể nộp bằng chứng gian lận. Với thiết kế này, mục tiêu của họ là giảm thiểu thời gian thực thi đồng thời tối đa hóa thông lượng tổng thể của mạng.
Layer N
Để thúc đẩy tính tùy chỉnh, Movement Labs sử dụng ngôn ngữ Move (ban đầu được Facebook thiết kế và dùng cho các mạng như Aptos và Sui) cho VM/thực thi. So với các framework khác, Move có lợi thế cấu trúc nổi bật, chủ yếu về tính an toàn và sự linh hoạt cho nhà phát triển. Đây là hai vấn đề chính khi xây dựng ứng dụng trên chuỗi bằng công nghệ hiện có. Quan trọng là, nhà phát triển vẫn có thể viết bằng Solidity và triển khai trên Movement. Để đạt được điều này, Movement đã tạo một runtime EVM hoàn toàn tương thích bytecode, có thể dùng song song với stack Move. Rollup M2 của họ tận dụng BlockSTM để song song hóa, cho phép thông lượng cao hơn đồng thời vẫn truy cập được hào thanh khoản của Ethereum (trước đây, BlockSTM chỉ dùng cho các alt-L1 như Aptos, vốn rõ ràng thiếu khả năng tương thích EVM).
MegaETH cũng đang thúc đẩy tiến bộ trong lĩnh vực lớp thực thi, đặc biệt thông qua động cơ song song hóa và cơ sở dữ liệu bộ nhớ, trong đó bộ sắp thứ tự có thể lưu trữ toàn bộ trạng thái trong bộ nhớ. Về kiến trúc, họ sử dụng:
-
Biên dịch mã gốc giúp hiệu suất L2 vượt trội hơn (nếu hợp đồng đòi hỏi tính toán nặng, chương trình có thể tăng tốc đáng kể; nếu không, vẫn đạt được tốc độ nhanh hơn khoảng 2 lần).
-
Sản xuất khối tương đối tập trung, nhưng xác minh và xác nhận khối phi tập trung.
-
Đồng bộ trạng thái hiệu quả, trong đó các nút đầy đủ không cần thực thi lại giao dịch, nhưng phải hiểu các thay đổi trạng thái để áp dụng lên cơ sở dữ liệu cục bộ.
-
Cấu trúc cập nhật cây Merkle (thường chiếm nhiều dung lượng lưu trữ), phương pháp của họ là một cấu trúc dữ liệu trie mới hiệu quả về bộ nhớ và đĩa. Việc tính toán trong bộ nhớ cho phép nén trạng thái chuỗi vào bộ nhớ, nên khi thực thi giao dịch, chúng chỉ cần truy cập bộ nhớ chứ không cần truy cập đĩa.
Là một phần của ngăn xếp mô-đun, một thiết kế khác đang được khám phá và lặp lại gần đây là tập hợp bằng chứng: được định nghĩa là một bộ chứng minh tạo ra một bằng chứng gọn nhẹ duy nhất từ nhiều bằng chứng gọn nhẹ. Trước tiên, hãy cùng xem xét tổng thể về tầng tập hợp và lịch sử, xu hướng hiện tại của nó trong lĩnh vực tiền mã hóa.
Giá trị của tầng tập hợp
Xét về lịch sử, trong thị trường phi tiền mã hóa, thị phần của các aggregator nhỏ hơn so với các nền tảng:
Mặc dù tôi không chắc điều này có đúng trong mọi trường hợp tiền mã hóa hay không, nhưng đối với sàn giao dịch phi tập trung (DEX), cầu nối xuyên chuỗi và giao thức cho vay, nhận định này vẫn đúng.
Ví dụ, tổng vốn hóa thị trường của 1inch và 0x (hai DEX aggregator chính) vào khoảng 1 tỷ USD, chỉ bằng một phần nhỏ so với khoảng 7,6 tỷ USD của Uniswap. Tình trạng tương tự xảy ra với cầu nối: so với các nền tảng như Across, các aggregator cầu nối như Li.Fi và Socket/Bungee có thị phần nhỏ hơn. Mặc dù Socket hỗ trợ 15 cầu nối khác nhau, tổng khối lượng giao dịch cầu nối thực tế của họ tương đương Across (Socket - 2,2 tỷ USD, Across - 1,7 tỷ USD), trong khi Across chỉ chiếm một phần nhỏ khối lượng giao dịch gần đây của Socket/Bungee.
Trong lĩnh vực cho vay, Yearn Finance là giao thức tập hợp lợi nhuận cho vay phi tập trung đầu tiên, vốn hóa hiện khoảng 250 triệu USD. So sánh, các nền tảng như Aave (khoảng 1,4 tỷ USD) và Compound (khoảng 560 triệu USD) có định giá cao hơn.
Tình hình thị trường tài chính truyền thống cũng tương tự. Ví dụ, ICE (Intercontinental Exchange) US và tập đoàn CME có vốn hóa thị trường khoảng 75 tỷ USD, trong khi các "aggregator" như Charles Schwab và Robinhood có vốn hóa khoảng 132 tỷ USD và 15 tỷ USD. Ở Charles Schwab, nơi định tuyến dòng lệnh khách hàng qua nhiều địa điểm như ICE và CME, tỷ lệ khối lượng giao dịch định tuyến qua các địa điểm này không tương xứng với tỷ lệ vốn hóa thị trường của họ. Robinhood mỗi tháng xử lý khoảng 119 triệu hợp đồng quyền chọn, trong khi ICE khoảng 35 triệu – và hợp đồng quyền chọn thậm chí không phải là phần cốt lõi trong mô hình kinh doanh của Robinhood. Dù vậy, ICE được định giá công khai cao hơn Robinhood khoảng 5 lần. Do đó, với tư cách là giao diện tổng hợp cấp ứng dụng, Charles Schwab và Robinhood định tuyến dòng lệnh khách hàng tới các địa điểm khác nhau, mặc dù khối lượng giao dịch lớn nhưng định giá không cao bằng ICE và CME.
Là người tiêu dùng, chúng ta đánh giá thấp giá trị của các aggregator.
Tuy nhiên, điều này có thể không đúng nếu tầng tập hợp được tích hợp sâu vào sản phẩm/nền tảng/chain. Nếu aggregator được tích hợp chặt chẽ trực tiếp vào chuỗi, rõ ràng đây là một kiến trúc khác biệt, và tôi rất tò mò về cách nó sẽ phát triển. Một ví dụ là AggLayer của Polygon, nơi các nhà phát triển có thể dễ dàng kết nối L1 và L2 của họ vào một mạng lưới có thể tập hợp bằng chứng và đạt được tầng thanh khoản thống nhất giữa các chuỗi sử dụng CDK.
AggLayer
Mô hình này hoạt động tương tự như tầng tương tác Nexus của Avail, bao gồm tập hợp bằng chứng và cơ chế đấu giá sắp thứ tự, làm cho sản phẩm DA của họ mạnh mẽ hơn. Giống như AggLayer của Polygon, mỗi chuỗi hoặc Rollup tích hợp với Avail đều có thể tương tác trong hệ sinh thái hiện tại của Avail. Ngoài ra, Avail tập hợp dữ liệu giao dịch đã được sắp thứ tự từ nhiều nền tảng blockchain và Rollup khác nhau, bao gồm Ethereum, tất cả các Rollup Ethereum, chuỗi Cosmos, Avail Rollup, Celestia Rollup và các cấu trúc lai như Validiums, Optimiums và các parachain Polkadot. Nhà phát triển từ bất kỳ hệ sinh thái nào cũng có thể xây dựng tự do trên lớp DA của Avail đồng thời sử dụng Avail Nexus, vốn phục vụ tập hợp bằng chứng và truyền tin nhắn xuyên hệ sinh thái.
Avail Nexus
Nebra tập trung vào tập hợp bằng chứng và thanh toán, có khả năng tập hợp giữa các hệ thống bằng chứng khác nhau. Ví dụ, tập hợp bằng chứng từ hệ thống xyz và abc, để bạn có agg_xyzabc (thay vì tập hợp bên trong từng hệ thống, để bạn có agg_xyz và agg_abc). Kiến trúc này sử dụng UniPlonK, chuẩn hóa công việc của bộ xác minh cho loạt mạch, giúp việc xác minh bằng chứng giữa các mạch PlonK khác nhau hiệu quả và khả thi hơn. Về bản chất, nó sử dụng chính bằng chứng không kiến thức (SNARK đệ quy) để mở rộng phần xác minh (thường là điểm nghẽn trong các hệ thống này). Đối với khách hàng, việc thanh toán "chặng cuối cùng" trở nên dễ dàng hơn vì Nebra xử lý tất cả việc tập hợp và thanh toán theo lô, đội ngũ chỉ cần thay đổi lời gọi hợp đồng API.
Astria đang nghiên cứu một số thiết kế thú vị, xoay quanh việc bộ sắp thứ tự chia sẻ của họ hoạt động thế nào cùng với tập hợp bằng chứng. Họ để phần thực thi cho chính Rollup đảm nhiệm, Rollup chạy phần mềm lớp thực thi trên namespace đã cho của bộ sắp thứ tự, về cơ bản chỉ là "API thực thi", là cách Rollup chấp nhận dữ liệu từ lớp sắp thứ tự. Họ cũng có thể dễ dàng thêm hỗ trợ bằng chứng hiệu lực tại đây để đảm bảo khối không vi phạm các quy tắc máy trạng thái EVM.
Tại đây, các sản phẩm như Astria đóng vai trò quá trình #1 → #2 (giao dịch chưa sắp → khối đã sắp), các nút lớp thực thi/Rollup là #2 → #3, và các giao thức như Nebra đóng vai trò chặng cuối #3 → #4 (khối thực thi → bằng chứng gọn). Nebra cũng có thể là bước thứ năm lý thuyết, nơi bằng chứng được tập hợp rồi xác minh. Sovereign Labs cũng đang nghiên cứu một khái niệm tương tự cho bước cuối cùng, trong đó cầu nối dựa trên tập hợp bằng chứng là cốt lõi kiến trúc của họ.
Nhìn chung, một số ứng dụng bắt đầu sở hữu hạ tầng nền tảng, một phần vì nếu họ không kiểm soát ngăn xếp nền tảng, thì việc chỉ giữ lại ứng dụng cấp trên có thể dẫn đến vấn đề khuyến khích và chi phí áp dụng người dùng cao. Mặt khác, khi cạnh tranh và tiến bộ công nghệ liên tục giảm chi phí hạ tầng, việc tích hợp ứng dụng/chain ứng dụng với các thành phần mô-đun trở nên rẻ hơn. Tôi tin rằng động lực này sẽ ngày càng mạnh mẽ, ít nhất là hiện tại.
Với tất cả các đổi mới này (lớp thực thi, lớp thanh toán, lớp tập hợp), hiệu quả cao hơn, tích hợp dễ dàng hơn, khả năng tương tác mạnh mẽ hơn và chi phí thấp hơn trở nên khả thi. Tất cả những điều này cuối cùng mang lại ứng dụng tốt hơn cho người dùng, trải nghiệm phát triển tốt hơn cho nhà phát triển. Đây là một tổ hợp thành công, có thể dẫn đến nhiều đổi mới hơn và tốc độ đổi mới nhanh hơn.
Chào mừng tham gia cộng đồng chính thức TechFlow
Nhóm Telegram:https://t.me/TechFlowDaily
Tài khoản Twitter chính thức:https://x.com/TechFlowPost
Tài khoản Twitter tiếng Anh:https://x.com/BlockFlow_News
@bridge__harris
