L1 so với L2, Bản tổng hợp so với Tích hợp, Mục đích chung so với Ứng dụng cụ thể

Trung cấp1/10/2024, 4:10:38 PM
Bài viết này phác thảo sự cân bằng giữa Rollup và tích hợp, L1 và L2, cũng như các chuỗi dành riêng cho ứng dụng và chuỗi có mục đích chung.

Giới thiệu loại coin

Bài đăng ngắn này sẽ mô tả sự cân bằng cụ thể của:

  • L1 so với L2
  • Bản tổng hợp so với tích hợp
  • Ứng dụng cụ thể so với mục đích chung

Chúng ta cần hiểu rõ hơn về những kiến trúc nào cần xây dựng và khi nào. Nếu không, chúng ta sẽ tiếp tục gặp phải một mớ cơ sở hạ tầng khó hiểu mà không người dùng nào có thể hiểu hoặc tương tác được. Đây là lỗi phổ biến nhất tôi thấy:

Như đã lưu ý trong bài giới thiệu của Eclipse trước khi ra mắt mạng chính sắp tới của họ:

Thường có sự phân đôi sai lầm giữa tầm nhìn tổng hợp theo mô-đun và khả năng có một chuỗi duy nhất với quy mô lớn, thực thi song song và trạng thái chia sẻ. “Mô-đun” thường được kết hợp với “dành riêng cho ứng dụng”, điều này sẽ khiến bạn tin rằng việc tổng hợp có nghĩa là một thế giới gồm nhiều chuỗi phân mảnh và thông lượng thấp. Chúng tôi thách thức ý tưởng đó.

Rollup và L2 không phải là UX tệ. Các bản tổng hợp bị phân mảnh và L2 là UX kém. Các bản cuộn và L2 được thiết kế phù hợp sẽ cải thiện UX.

Bản tổng hợp so với tích hợp

Cuối cùng, tất cả các chuỗi đều có thể áp dụng công nghệ tốt nhất (ví dụ: DAS + ZK) nếu nó tỏ ra hữu ích. Như đã thảo luận trong báo cáo trước của tôi Bản tổng hợp có kế thừa bảo mật không?, sự khác biệt mà chúng ta còn lại đại khái là như sau:

  • “Cuộn” hay còn gọi là “Mô-đun” - Xây dựng các chuỗi riêng biệt một cách hợp lý để đăng dữ liệu lên chuỗi máy chủ của chúng (lớp DA). Họ sử dụng lại sự đồng thuận của chuỗi máy chủ.
  • “Tích hợp” hay còn gọi là “Monolithic” - Tích hợp mọi thứ vào một giao thức với sự đồng thuận riêng. Không đăng dữ liệu lên một chuỗi máy chủ riêng biệt. (Ngay cả khi lớp DA và lớp thực thi theo một nghĩa nào đó là các phần tách biệt về mặt logic của giao thức dùng chung).

Solana và Eclipse biểu thị các đường dẫn song song, như được trình bày tương tự trong Luận án Solana của Syncracy:

Như tôi đã thảo luận trong tập Uncommon Core gần đây với Hasu, cả hai cách tiếp cận đều sẽ có giá trị lâu dài.

Solana áp dụng phương pháp gộp mọi thứ thành một sự đồng thuận. Nó theo đuổi độ trễ tối thiểu (thời gian hiện tại trung bình là ~400-500 mili giây với hy vọng sẽ đạt 200 mili giây trong tương lai) trong khi vẫn duy trì bộ trình xác thực lớn (~2.000). Thành tựu đáng kinh ngạc này đòi hỏi một số đột phá về mặt kỹ thuật.

Tuy nhiên, hai mục tiêu này (phân cấp tối đa + độ trễ tối thiểu) vốn có mâu thuẫn. Việc giữ cho bộ đồng thuận này ổn định trong khi chạy ở tốc độ và thông lượng tối đa là một thách thức vô cùng lớn. TowerBFT không có phân tích chính thức về độ an toàn hoặc tính sống động và không rõ liệu bằng chứng lịch sử hiện có hữu ích và linh hoạt trong mô hình đối nghịch hay đơn giản là có thể bị loại bỏ. Tất nhiên, tính kinh tế của một hệ thống có độ trễ thấp cũng làm tăng động cơ tập trung hóa.

Eclipse áp dụng cách tiếp cận đồng thuận tách nhóm. Bản tổng hợp có thể có bộ trình tự sắp xếp được chọn thủ công nhỏ hơn (thậm chí có thể được điều hành bởi một người vận hành) để vận hành một môi trường được kiểm soát. Điều này có thể tăng độ tin cậy và giảm độ trễ hơn nữa, cung cấp sản phẩm Web2 với những lợi ích của đường ray tiền điện tử. Code, một ứng dụng thanh toán được triển khai như một phần của L2 trên Solana bằng cách sử dụng các nonces bền bỉ, cũng có mong muốn thanh toán ngay lập tức và đáng tin cậy. Ngoài trải nghiệm người dùng tuyệt vời có độ trễ gần như tức thời, việc đẩy giới hạn dưới hơn nữa cũng là điều cần thiết đối với các ứng dụng tài chính có độ trễ thấp, giá trị cao.

Sau đó, các tập hợp có thể đăng dữ liệu của họ lên một nhóm đồng thuận phi tập trung khác để xác minh mạnh mẽ hơn ở quy mô thời gian chậm hơn. Ví dụ: Celestia có thời gian chặn là 15 giây với độ chính xác của một khe duy nhất, điều này thực sự không quá khác biệt so với Solana! Solana có xác nhận ~ 400 mili giây, sau đó đạt được kết quả cuối cùng sau 32 vị trí (~ 12,8 giây).

Ở đây không có bữa trưa miễn phí. Có thể có sự cân bằng giữa các thuộc tính của bộ trình xác thực thời gian thực (ví dụ: Solana có nhiều trình xác thực hơn so với các bản tổng hợp thực hiện trình sắp xếp chuỗi) so với các đảm bảo được cung cấp (ví dụ: môi trường có khả năng phục hồi được kiểm soát, thậm chí độ trễ thấp hơn, v.v.). Mức độ cam kết phù hợp được đưa ra (và ở quy mô thời gian nào) là một phạm vi. Các câu hỏi kỹ thuật mở vẫn còn và sự phù hợp nhất có thể sẽ thay đổi tùy theo trường hợp sử dụng. Không cần phải nói rằng ở đây chi phí cũng rất cần thiết, do đó, các lớp DA có thể mở rộng như Celestia (mà Eclipse sử dụng) sẽ là cần thiết.

Eclipse rõ ràng sẽ không thay thế Solana. Mỗi người thực hiện những đánh đổi khác nhau và theo đuổi một thị trường khác nhau. Solana vẫn là trái tim và linh hồn của sự phát triển SVM và kết quả là có thể sẽ thấy nhiều ứng dụng mới được triển khai ở đó. Tuy nhiên, rõ ràng là sẽ có nhiều hơn một chuỗi SVM trong dài hạn (Pyth thậm chí đã có). Tương lai không phải là chuỗi đơn và SVM đơn giản là công nghệ tuyệt vời. Eclipse đang bắt đầu xu hướng xuất nó sang L2, nhưng tôi mong những người khác nhận ra giá trị ở đây và làm theo sự dẫn dắt của họ.

L1 so với L2

Tôi đang sử dụng L1 và L2 ở đây theo nghĩa phổ biến hơn để bao gồm các bản tổng hợp, xác thực, v.v. Như được trình bày trong Các loại lớp 2 khác nhau của Vitalik:

Cầu nối xác thực hai chiều gần như đủ để biến một chuỗi thành một hợp lệ. Thành phần chính còn lại là một cam kết xã hội rằng nếu có điều gì đó đặc biệt xảy ra trong Ethereum khiến cây cầu không còn hoạt động nữa thì chuỗi kia sẽ hard fork để phản ứng.

Điều tạo nên L1 so với L2 là cách nó xử lý các nhánh một cách hiệu quả. Một validium sẽ hoàn nguyên nếu L1 của nó hoàn nguyên một khối và nó sẽ phân nhánh cứng nếu phân nhánh cứng ở lớp cơ sở của nó. Để nâng cấp L2, một số hình thức quản trị L2 phải tồn tại trên L1 như một hợp đồng cầu nối mà L1 có thể đọc được.

Bây giờ, tại sao chúng ta lại sử dụng một thứ như vậy? Liệu việc một chuỗi ủy quyền lựa chọn nhánh của nó cho L1 cơ bản và bám rễ xung quanh cây cầu của nó ở đó có hợp lý không?

Bất chấp niềm tin chung rằng cuộc chiến L1 đã kết thúc, Ethereum đã giành chiến thắng và tất cả các đối thủ cạnh tranh của Ethereum đều muốn trở thành L2 ngay bây giờ - Ethereum L2 không phải là giải pháp tốt nhất cho tất cả các chuỗi.

Ethereum L2 thường được xem là cách an toàn và có thể mở rộng nhất để xây dựng chuỗi. Tuy nhiên, những đặc tính bảo mật này thường bị hiểu lầm sâu sắc như đã thảo luận trong báo cáo trước của tôi. Chỉ cần đăng một bằng chứng lên Ethereum và ủy thác quy tắc lựa chọn ngã ba của bạn ở đó không làm cho chuỗi của bạn trở nên siêu an toàn một cách kỳ diệu.

Lập luận rằng tất cả các chuỗi phải triển khai dưới dạng Ethereum L2 để bảo mật cho riêng chúng thường không chính xác. Thay vào đó, lợi ích chính của L2 là khả năng khai thác các hiệu ứng mạng của Ethereum (người dùng, tính thanh khoản, nhà phát triển, công cụ, v.v.). Đó là một chiến lược tiếp cận thị trường.

Đấu tranh để giành được sự chú ý là điều hợp lý vì sự chú ý là nguồn tài nguyên khan hiếm duy nhất trong tiền điện tử. L2 đương nhiên trở thành trung tâm của các nhà phát triển, người dùng, phương tiện truyền thông, v.v., những điều quan trọng nhất. Trở thành L2 đã từng đủ để thu hút sự chú ý đó.

Tuy nhiên, sự chú ý nhận được từ việc trở thành L2 đang giảm dần. Danh sách các Ethereum L2 đang hoạt động và sắp ra mắt hiện quá dài để bất kỳ cá nhân nào có thể theo dõi. Các chuỗi xoay quanh L2 không nhận được sự chú ý nhiều hơn những chuỗi đi đầu đã làm (ví dụ: Lạc quan và Trọng tài). Ngay cả làn sóng zkEVM được chờ đợi từ lâu cũng đang gặp khó khăn trong việc thu hút người dùng, ứng dụng và giá trị.

Vì vậy, trở thành L2 một mình không đảm bảo được sự chú ý của mọi người nữa. Tuy nhiên, nó vẫn có thể mang lại lợi thế về sản phẩm so với các chuỗi độc lập nếu bạn có thể thu hút sự chú ý theo một số cách khác. Ví dụ: biến sơ đồ kim tự tháp thành hình vuông có thể thu hút ~ 700 triệu đô la vào đa chữ ký không có L2. Ngoài ra, bạn có thể xây dựng SVM L2 đầu tiên của Ethereum.

Giả sử bạn có một sản phẩm được chú ý, bây giờ chúng ta hãy xem xét việc trở thành L2 có thể giúp chuỗi tiếp cận cơ sở người dùng Ethereum và mang lại trải nghiệm sản phẩm tốt hơn như thế nào. Nó sẽ làm như vậy chủ yếu bằng cách tận dụng các tài sản gốc Ethereum (ví dụ: ETH) theo cách thuận lợi (ví dụ: các cầu nối có bảo mật và/hoặc UX hấp dẫn).

Giá trị của điều này phụ thuộc rộng rãi vào hai giả định cốt lõi:

1. Tài sản Ethereum hiện có rất quan trọng đối với trường hợp sử dụng nhất định (ví dụ: DeFi phụ thuộc vào ETH)

Nếu ứng dụng của bạn phụ thuộc nhiều vào tài sản của hệ sinh thái Ethereum thì kiến trúc L2 có thể có giá trị. Nếu bạn hoàn toàn không quan tâm đến tài sản Ethereum thì việc trở thành Ethereum L2 không có giá trị đặc biệt. Tài sản dựa trên Ethereum rõ ràng là tài sản quan trọng nhất trong tiền điện tử ngày nay, vì vậy ngày nay có một thị trường lớn được phục vụ ở đây.

Nhìn về phía trước ở cấp độ ngành, câu hỏi cốt lõi ở đây là việc tạo ra trạng thái mới và có giá trị của tiền điện tử sẽ như thế nào trong tương lai?

  • Nếu trạng thái tương lai này ngày càng không bị ràng buộc với trạng thái gốc Ethereum hiện tại (ví dụ: trạng thái mới duy nhất, RWA, v.v.), thì sức hấp dẫn của L2 có thể giảm đi.
  • Nếu trạng thái tương lai này phụ thuộc nhiều vào trạng thái gốc Ethereum hiện tại (ví dụ: giao dịch ETH), thì L2 có thể đóng một vai trò nổi bật.

Kịch bản trước đây đưa ra quan điểm rằng chúng ta chỉ thấy sự sụt giảm trong nhóm tiền điện tử sẽ là gì và bạn không nên lập chỉ mục quá mức về những gì ở đây ngày hôm nay. Kịch bản thứ hai đưa ra quan điểm rằng việc phát triển và ứng dụng tiền điện tử sẽ phụ thuộc rất nhiều vào lộ trình, do đó trạng thái hiện tại sẽ ảnh hưởng đến kết quả.

Cả hai đều đúng ở một mức độ nào đó, nhưng tôi nghĩ mọi quan điểm lạc quan về triển vọng dài hạn của ngành đều nghiêng về quan điểm đầu tiên. Sẽ có rất nhiều trạng thái mới và độc đáo mà chúng ta thậm chí không thể lý giải được rằng nó không bị ràng buộc với trạng thái ngày nay. Trạng thái hiện tại của tiền điện tử là rất thấp so với trạng thái dự kiến trong tương lai.

Ví dụ: “đảm bảo thanh toán” thường được trích dẫn của Ethereum có ý nghĩa rất nhỏ đối với các tài sản trong thế giới thực (RWA) chẳng hạn như stablecoin (ví dụ: USDC) hoặc tín phiếu kho bạc được mã hóa. Chúng được “giải quyết” khi nhà phát hành (ví dụ: Circle) cho là như vậy.

Trong trường hợp này, sức hấp dẫn của việc trở thành Ethereum L2 có thể giảm đi theo tỷ lệ ứng dụng. Một ứng dụng thanh toán mới dựa trên USDC vốn không quan tâm liệu đó có phải là Ethereum L2 hay không. Họ chỉ muốn cơ sở hạ tầng rẻ nhất, nhanh nhất, đáng tin cậy nhất cho phép họ cung cấp cho người dùng trải nghiệm sản phẩm tốt nhất.

Việc thành lập nhà nước mới trong lịch sử luôn là một trở ngại đối với Solana, mặc dù chúng ta thấy rõ gió đang thay đổi ở đây. Nhiều dự án cơ sở hạ tầng và DeFi nổi tiếng trên Solana hiện đang tung ra các token và sẽ còn nhiều hơn nữa. Đây là bước khởi động bánh đà Solana.

2.Ethereum đó ←→ Cầu L2 thích hợp hơn Ethereum ←→ Cầu L1 (ví dụ: vì lý do bảo mật và/hoặc UX)

Giả sử rằng giả định đầu tiên thực sự được đáp ứng cho một trường hợp sử dụng nhất định (tức là, nguồn gốc Ethereum khá có giá trị đối với ứng dụng của bạn). Sau đó, chúng ta cần hỏi xem liệu L2 có thể hiển thị những tài sản này theo cách thuận lợi hơn so với L1 riêng biệt hay không. Giả sử người dùng có một số ETH và họ muốn đổi nó lấy USDC. Họ đi đâu?

Mặc dù an ninh cầu đường thường được coi là động lực ở đây nhưng lập luận này có vẻ khó hiểu dựa trên thông tin sẵn có. Nhiều cầu nối tổng hợp lớn nhất thậm chí không có bằng chứng, có bằng chứng được đưa vào danh sách trắng, các bản nâng cấp được kiểm soát bằng nhiều chữ ký hoặc thậm chí chúng thậm chí không có L2 theo đúng nghĩa đen.

Điều này so sánh với cầu nối xác minh đồng thuận cổ điển (ví dụ: IBC). Trong thực tế, không có lỗi nghiêm trọng nào về số lượng người xác thực trong các tình huống như vậy. Lỗi cầu nối thường xảy ra do bị hack và/hoặc đa chữ kí cầu nối bị xâm phạm (điều mà L2 đều dễ mắc phải).

Mặc dù các cải tiến về bảo mật kém thuyết phục hơn đối với tôi ở đây, nhưng theo quan điểm của tôi, việc truy cập thuận tiện vào người dùng và tài sản Ethereum là lợi ích chính của việc kết nối L2 ngày nay. Các bản tổng hợp như Base, Optimism và Arbitrum có cảm giác giống như các phần mở rộng của Ethereum hơn. Người dùng giữ các ví và địa chỉ giống nhau, mã thông báo gas gốc là một phiên bản chuẩn duy nhất của ETH, ETH thống trị DeFi chẳng hạn như tất cả các cặp giao dịch, ứng dụng xã hội định giá NFT bằng ETH và trả tiền cho người sáng tạo bằng ETH (ví dụ: friend.tech), tiền gửi vào L2 là ngay lập tức (vì chúng sẽ được tổ chức lại cùng nhau), v.v.

Người dùng không thể suy luận nên sử dụng cây cầu nào, phân tích các giả định bảo mật khác nhau, nhận một trong số các mã thông báo được bao bọc có sẵn, lấy mã thông báo gốc của chuỗi để lấy gas, v.v. Họ chỉ muốn kết nối ETH của mình, nhận ETH ở phía bên kia và tiếp tục sử dụng L2 như cách họ sẽ sử dụng Ethereum hoặc bất kỳ L2 nào khác. Đây là lý do tại sao Eclipse sẽ chỉ sử dụng ETH làm mã thông báo gốc được sử dụng làm gas. Việc buộc sử dụng mã thông báo gas mới sẽ gây bất lợi cho UX.

Vậy tại sao Solana không thể cung cấp những lợi thế tương tự như Ethereum L2? Điều này thực sự trở thành một câu hỏi kỹ thuật hơn là bất cứ điều gì cơ bản và nó sẽ trở nên dễ dàng hơn theo thời gian. Điều này đúng với mã thông báo gas cũng như các thách thức UX khác liên quan đến việc không sử dụng EVM (vốn không có ở L1 so với L2):

  • Mã thông báo gas - Thanh toán gas có thể được loại bỏ khỏi người dùng, cho phép người dùng thanh toán bằng bất kỳ mã thông báo gas nào họ chọn.
  • Cầu nối - Cầu nối có khả năng được củng cố và tiêu chuẩn hóa nhiều hơn theo thời gian, dẫn đến ít nhầm lẫn hơn từ người dùng và sự phân mảnh thanh khoản.
  • Ví - Snaps được công bố gần đây của MetaMask mở rộng hỗ trợ MetaMask cho các chuỗi không phải EVM thông qua tích hợp của bên thứ ba được xây dựng trên cùng, chẳng hạn như thông qua MetaMask Snaps của Drift hoặc Solflare.
  • Trải nghiệm của nhà phát triển - Rào cản ngôn ngữ sẽ bị phá bỏ. Các dự án như Solang và Neon có thể giúp các nhà phát triển Solidity xây dựng trên Solana và các dự án như Stylus có thể giúp các nhà phát triển Rust xây dựng trên Arbitrum.

Trong tương lai, ETH thậm chí có thể đóng một vai trò trong Solana DeFi nếu người dùng bày tỏ sự ưa thích mạnh mẽ đối với ETH với tốc độ và quy mô của Solana. Trên thực tế, nhiều khả năng những người dùng có tài sản gốc Ethereum này sẽ tiếp tục sử dụng chúng trong hệ sinh thái Ethereum L2 vì những lý do mà chúng ta đã thảo luận, giả sử họ có quyền truy cập vào các L2 có khả năng mở rộng tương đương.

Dành riêng cho ứng dụng so với mục đích chung

Bất kể chuỗi là L1 hay L2, rõ ràng cần phải tăng thông lượng chuỗi đơn bằng cách mở rộng quy mô thực thi. Bản tổng hợp không được ngụ ý sự phân mảnh. Việc hợp nhất nhiều chuỗi đồng nhất dưới một trình sắp xếp được chia sẻ có trạng thái sẽ trông giống như một chuỗi song song xét từ góc độ mở rộng quy mô với trải nghiệm người dùng đầy thách thức hơn.

Chúng tôi thường thấy “không gian khối chuyên dụng” được coi là lý do để triển khai một bản tổng hợp dành riêng cho ứng dụng. Tuy nhiên, quan niệm sai lầm này đã nảy sinh phần lớn do những hạn chế không cần thiết của EVM đơn luồng với thị trường phí toàn cầu. Một SVM song song với thị trường phí địa phương giúp giảm đáng kể nhu cầu về chuỗi ứng dụng. Lưu trữ nhiều ứng dụng hơn trên cơ sở hạ tầng dùng chung giúp giảm đáng kể sự phức tạp của nhà phát triển và người dùng. Trải nghiệm người dùng chuỗi chéo và độ phức tạp của nhà phát triển trong thế giới nhiều chuỗi là một rủi ro hiện hữu bị đánh giá thấp.

Điều này không có nghĩa là cuối cùng sẽ chỉ có một chuỗi. Nhìn chung, tôi thấy có bốn đối số để triển khai chuỗi của riêng bạn:

  1. Khả năng mở rộng & Không gian khối chuyên dụng - Như đã đề cập ở trên, điều này thường không thuyết phục. Một xưởng đúc NFT sẽ không thể đóng cửa phần còn lại của chuỗi một cách hiệu quả, nhưng câu trả lời nói chung là không tạo ra một chuỗi khác. Điều này được giảm bớt nhờ VM song song với thị trường phí địa phương. Tuy nhiên, trong trường hợp băng thông của toàn bộ mạng đã bão hòa, thị trường phí địa phương sẽ không giúp ích được gì (tức là phí cho chuỗi chia sẻ sẽ tăng trên toàn cầu). Sau đó, bạn cần một chuỗi khác.
  2. Chủ quyền - Quản trị tiền điện tử vẫn còn khá kém và việc có chuỗi phân nhánh của riêng bạn có thể là một cơ chế phối hợp hữu ích. Trực giác của tôi cho rằng đây là một trường hợp rất hiếm gặp nhưng khó có thể nói chắc chắn. Điều này phù hợp với mối quan tâm của MakerDAO đối với chuỗi ứng dụng.
  3. Khả năng tùy chỉnh - Các tùy chỉnh ở cấp độ đồng thuận có thể có giá trị đối với một số ứng dụng nhất định (ví dụ: dYdX v4), nhưng những trường hợp này về mặt thực nghiệm cho đến nay rất ít và xa. Ngay cả dYdX, ví dụ điển hình của chuỗi ứng dụng, “có thể sẽ hướng nhiều hơn đến việc thực thi tổng quát trên chuỗi dYdX” theo Antonio trong tập Bell Curve gần đây của anh ấy. Nhu cầu về khả năng tùy chỉnh toàn bộ không thể giải quyết được trên chuỗi chia sẻ nói chung là thiếu đối với hầu hết các loại tiền điện tử. Gần như tất cả các đợt giới thiệu mới tiếp tục chỉ là các đợt phân nhánh EVM thông thường với các mã thông báo mới.
  4. Nắm bắt giá trị - Đây được cho là một tập hợp con của khả năng tùy chỉnh, nhưng nó khá quan trọng nên chúng tôi sẽ tách nó ra. Việc nội hóa giá trị trên cơ sở hạ tầng dùng chung vốn không được xây dựng chỉ dành cho ứng dụng của bạn có thể khó khăn hơn. Chuỗi ứng dụng có thể giúp phân bổ giá trị cho các ứng dụng có trách nhiệm dễ dàng hơn. Tuy nhiên, đây là một nỗ lực kỹ thuật hơn là một nỗ lực cơ bản và ở Solana đang có nghiên cứu về cách thực hiện chính xác điều này. Ngoài ra, hãy lưu ý rằng việc triển khai chuỗi của riêng bạn sẽ tốn rất nhiều chi phí so với chi phí khấu hao trên cơ sở hạ tầng dùng chung.

Động lực chính để khởi chạy chuỗi ứng dụng ngày nay thường là khả năng tăng cường tường thuật và/hoặc tiện ích mã thông báo cho một dự án đang gặp khó khăn. Sự suy thoái của thị trường gấu và sự thiếu tăng trưởng ứng dụng tương ứng đã khuyến khích sự phát triển và tài trợ cho một kiến trúc quá phức tạp, dẫn đến các dự án mới cần thiết để giải quyết những vấn đề phức tạp tự gây ra.

Việc ra mắt chuỗi của riêng bạn ngay hôm nay mang lại những đánh đổi đau đớn và không cần thiết (độ phức tạp, chi phí, trải nghiệm người dùng kém hơn, tính thanh khoản bị phân mảnh, v.v.) mà hầu hết các ứng dụng không thể biện minh cho những lợi ích gia tăng. Cơ sở hạ tầng cần thiết để làm cho UX này có tính cạnh tranh dường như còn xa vời. Điều này không có nghĩa là không có lý do gì để chuỗi ứng dụng tồn tại (chắc chắn là có). Đúng hơn, chúng tôi vừa lập chỉ mục quá mức theo hướng kể chuyện này với tư cách là một ngành, và do đó, xu hướng kết hợp lại hiện tại rõ ràng là có lợi trong tình trạng hiện tại.

Phần kết luận

Solana đúng là đã đạt được rất nhiều động lực trong những tháng gần đây. Sự điều chỉnh mạnh mẽ này phần lớn là sự thừa nhận tình trạng hiện tại của UX đa chuỗi - nó bị phân mảnh và đau đớn. Trải nghiệm người dùng của việc sử dụng ứng dụng Solana đơn giản là không thể tin được. Nhẹ nhàng và nhanh chóng.

Rollups và L2 đã mang tiếng xấu cho UX, nhưng vấn đề thực sự là sự phân mảnh. Chúng tôi liên kết các bản tổng hợp và L2 với tỷ lệ chia tỷ lệ theo chiều ngang bị phân mảnh vì trên thực tế, hầu hết chúng đều đã phân nhánh EVM nguyên trạng và sử dụng băng thông DA bị hạn chế. Chúng trở nên đắt tiền và cồng kềnh khi sử dụng.

Tuy nhiên, đây không phải là cơ bản. Chia tỷ lệ theo chiều dọc với máy ảo mạnh mẽ trên lớp DA có thể mở rộng sẽ giải quyết các vấn đề về UX và chi phí này. Một số mức độ đóng gói lại ngăn xếp cho cả L1 và L2 có thể xảy ra. L2 và bản tổng hợp sẽ cải thiện UX nếu được sử dụng đúng cách. Đó phải là điểm bán hàng thực sự của họ.

Cả hai cách tiếp cận đều có giá trị của chúng. Chúng ta chỉ cần làm tốt hơn việc tự hỏi bản thân trước tiên “sản phẩm này đang cố gắng giải quyết thị trường nào?” và “làm thế nào kiến trúc này có thể giải quyết được những gì tôi cần?” trước khi chúng ta xây dựng L1, L2, L3 tiếp theo…

Tuyên bố từ chối trách nhiệm:

  1. Bài viết này được in lại từ [dba]. Mọi bản quyền thuộc về tác giả gốc [Jon Charbonneau]. Nếu có ý kiến phản đối việc tái bản này, vui lòng liên hệ với nhóm Gate Learn , họ sẽ xử lý kịp thời.
  2. Tuyên bố miễn trừ trách nhiệm pháp lý: Các quan điểm và ý kiến trình bày trong bài viết này chỉ là của tác giả và không cấu thành bất kỳ lời khuyên đầu tư nào.
  3. Việc dịch bài viết sang các ngôn ngữ khác được thực hiện bởi nhóm Gate Learn. Trừ khi được đề cập, việc sao chép, phân phối hoặc đạo văn các bài viết đã dịch đều bị cấm.

L1 so với L2, Bản tổng hợp so với Tích hợp, Mục đích chung so với Ứng dụng cụ thể

Trung cấp1/10/2024, 4:10:38 PM
Bài viết này phác thảo sự cân bằng giữa Rollup và tích hợp, L1 và L2, cũng như các chuỗi dành riêng cho ứng dụng và chuỗi có mục đích chung.

Giới thiệu loại coin

Bài đăng ngắn này sẽ mô tả sự cân bằng cụ thể của:

  • L1 so với L2
  • Bản tổng hợp so với tích hợp
  • Ứng dụng cụ thể so với mục đích chung

Chúng ta cần hiểu rõ hơn về những kiến trúc nào cần xây dựng và khi nào. Nếu không, chúng ta sẽ tiếp tục gặp phải một mớ cơ sở hạ tầng khó hiểu mà không người dùng nào có thể hiểu hoặc tương tác được. Đây là lỗi phổ biến nhất tôi thấy:

Như đã lưu ý trong bài giới thiệu của Eclipse trước khi ra mắt mạng chính sắp tới của họ:

Thường có sự phân đôi sai lầm giữa tầm nhìn tổng hợp theo mô-đun và khả năng có một chuỗi duy nhất với quy mô lớn, thực thi song song và trạng thái chia sẻ. “Mô-đun” thường được kết hợp với “dành riêng cho ứng dụng”, điều này sẽ khiến bạn tin rằng việc tổng hợp có nghĩa là một thế giới gồm nhiều chuỗi phân mảnh và thông lượng thấp. Chúng tôi thách thức ý tưởng đó.

Rollup và L2 không phải là UX tệ. Các bản tổng hợp bị phân mảnh và L2 là UX kém. Các bản cuộn và L2 được thiết kế phù hợp sẽ cải thiện UX.

Bản tổng hợp so với tích hợp

Cuối cùng, tất cả các chuỗi đều có thể áp dụng công nghệ tốt nhất (ví dụ: DAS + ZK) nếu nó tỏ ra hữu ích. Như đã thảo luận trong báo cáo trước của tôi Bản tổng hợp có kế thừa bảo mật không?, sự khác biệt mà chúng ta còn lại đại khái là như sau:

  • “Cuộn” hay còn gọi là “Mô-đun” - Xây dựng các chuỗi riêng biệt một cách hợp lý để đăng dữ liệu lên chuỗi máy chủ của chúng (lớp DA). Họ sử dụng lại sự đồng thuận của chuỗi máy chủ.
  • “Tích hợp” hay còn gọi là “Monolithic” - Tích hợp mọi thứ vào một giao thức với sự đồng thuận riêng. Không đăng dữ liệu lên một chuỗi máy chủ riêng biệt. (Ngay cả khi lớp DA và lớp thực thi theo một nghĩa nào đó là các phần tách biệt về mặt logic của giao thức dùng chung).

Solana và Eclipse biểu thị các đường dẫn song song, như được trình bày tương tự trong Luận án Solana của Syncracy:

Như tôi đã thảo luận trong tập Uncommon Core gần đây với Hasu, cả hai cách tiếp cận đều sẽ có giá trị lâu dài.

Solana áp dụng phương pháp gộp mọi thứ thành một sự đồng thuận. Nó theo đuổi độ trễ tối thiểu (thời gian hiện tại trung bình là ~400-500 mili giây với hy vọng sẽ đạt 200 mili giây trong tương lai) trong khi vẫn duy trì bộ trình xác thực lớn (~2.000). Thành tựu đáng kinh ngạc này đòi hỏi một số đột phá về mặt kỹ thuật.

Tuy nhiên, hai mục tiêu này (phân cấp tối đa + độ trễ tối thiểu) vốn có mâu thuẫn. Việc giữ cho bộ đồng thuận này ổn định trong khi chạy ở tốc độ và thông lượng tối đa là một thách thức vô cùng lớn. TowerBFT không có phân tích chính thức về độ an toàn hoặc tính sống động và không rõ liệu bằng chứng lịch sử hiện có hữu ích và linh hoạt trong mô hình đối nghịch hay đơn giản là có thể bị loại bỏ. Tất nhiên, tính kinh tế của một hệ thống có độ trễ thấp cũng làm tăng động cơ tập trung hóa.

Eclipse áp dụng cách tiếp cận đồng thuận tách nhóm. Bản tổng hợp có thể có bộ trình tự sắp xếp được chọn thủ công nhỏ hơn (thậm chí có thể được điều hành bởi một người vận hành) để vận hành một môi trường được kiểm soát. Điều này có thể tăng độ tin cậy và giảm độ trễ hơn nữa, cung cấp sản phẩm Web2 với những lợi ích của đường ray tiền điện tử. Code, một ứng dụng thanh toán được triển khai như một phần của L2 trên Solana bằng cách sử dụng các nonces bền bỉ, cũng có mong muốn thanh toán ngay lập tức và đáng tin cậy. Ngoài trải nghiệm người dùng tuyệt vời có độ trễ gần như tức thời, việc đẩy giới hạn dưới hơn nữa cũng là điều cần thiết đối với các ứng dụng tài chính có độ trễ thấp, giá trị cao.

Sau đó, các tập hợp có thể đăng dữ liệu của họ lên một nhóm đồng thuận phi tập trung khác để xác minh mạnh mẽ hơn ở quy mô thời gian chậm hơn. Ví dụ: Celestia có thời gian chặn là 15 giây với độ chính xác của một khe duy nhất, điều này thực sự không quá khác biệt so với Solana! Solana có xác nhận ~ 400 mili giây, sau đó đạt được kết quả cuối cùng sau 32 vị trí (~ 12,8 giây).

Ở đây không có bữa trưa miễn phí. Có thể có sự cân bằng giữa các thuộc tính của bộ trình xác thực thời gian thực (ví dụ: Solana có nhiều trình xác thực hơn so với các bản tổng hợp thực hiện trình sắp xếp chuỗi) so với các đảm bảo được cung cấp (ví dụ: môi trường có khả năng phục hồi được kiểm soát, thậm chí độ trễ thấp hơn, v.v.). Mức độ cam kết phù hợp được đưa ra (và ở quy mô thời gian nào) là một phạm vi. Các câu hỏi kỹ thuật mở vẫn còn và sự phù hợp nhất có thể sẽ thay đổi tùy theo trường hợp sử dụng. Không cần phải nói rằng ở đây chi phí cũng rất cần thiết, do đó, các lớp DA có thể mở rộng như Celestia (mà Eclipse sử dụng) sẽ là cần thiết.

Eclipse rõ ràng sẽ không thay thế Solana. Mỗi người thực hiện những đánh đổi khác nhau và theo đuổi một thị trường khác nhau. Solana vẫn là trái tim và linh hồn của sự phát triển SVM và kết quả là có thể sẽ thấy nhiều ứng dụng mới được triển khai ở đó. Tuy nhiên, rõ ràng là sẽ có nhiều hơn một chuỗi SVM trong dài hạn (Pyth thậm chí đã có). Tương lai không phải là chuỗi đơn và SVM đơn giản là công nghệ tuyệt vời. Eclipse đang bắt đầu xu hướng xuất nó sang L2, nhưng tôi mong những người khác nhận ra giá trị ở đây và làm theo sự dẫn dắt của họ.

L1 so với L2

Tôi đang sử dụng L1 và L2 ở đây theo nghĩa phổ biến hơn để bao gồm các bản tổng hợp, xác thực, v.v. Như được trình bày trong Các loại lớp 2 khác nhau của Vitalik:

Cầu nối xác thực hai chiều gần như đủ để biến một chuỗi thành một hợp lệ. Thành phần chính còn lại là một cam kết xã hội rằng nếu có điều gì đó đặc biệt xảy ra trong Ethereum khiến cây cầu không còn hoạt động nữa thì chuỗi kia sẽ hard fork để phản ứng.

Điều tạo nên L1 so với L2 là cách nó xử lý các nhánh một cách hiệu quả. Một validium sẽ hoàn nguyên nếu L1 của nó hoàn nguyên một khối và nó sẽ phân nhánh cứng nếu phân nhánh cứng ở lớp cơ sở của nó. Để nâng cấp L2, một số hình thức quản trị L2 phải tồn tại trên L1 như một hợp đồng cầu nối mà L1 có thể đọc được.

Bây giờ, tại sao chúng ta lại sử dụng một thứ như vậy? Liệu việc một chuỗi ủy quyền lựa chọn nhánh của nó cho L1 cơ bản và bám rễ xung quanh cây cầu của nó ở đó có hợp lý không?

Bất chấp niềm tin chung rằng cuộc chiến L1 đã kết thúc, Ethereum đã giành chiến thắng và tất cả các đối thủ cạnh tranh của Ethereum đều muốn trở thành L2 ngay bây giờ - Ethereum L2 không phải là giải pháp tốt nhất cho tất cả các chuỗi.

Ethereum L2 thường được xem là cách an toàn và có thể mở rộng nhất để xây dựng chuỗi. Tuy nhiên, những đặc tính bảo mật này thường bị hiểu lầm sâu sắc như đã thảo luận trong báo cáo trước của tôi. Chỉ cần đăng một bằng chứng lên Ethereum và ủy thác quy tắc lựa chọn ngã ba của bạn ở đó không làm cho chuỗi của bạn trở nên siêu an toàn một cách kỳ diệu.

Lập luận rằng tất cả các chuỗi phải triển khai dưới dạng Ethereum L2 để bảo mật cho riêng chúng thường không chính xác. Thay vào đó, lợi ích chính của L2 là khả năng khai thác các hiệu ứng mạng của Ethereum (người dùng, tính thanh khoản, nhà phát triển, công cụ, v.v.). Đó là một chiến lược tiếp cận thị trường.

Đấu tranh để giành được sự chú ý là điều hợp lý vì sự chú ý là nguồn tài nguyên khan hiếm duy nhất trong tiền điện tử. L2 đương nhiên trở thành trung tâm của các nhà phát triển, người dùng, phương tiện truyền thông, v.v., những điều quan trọng nhất. Trở thành L2 đã từng đủ để thu hút sự chú ý đó.

Tuy nhiên, sự chú ý nhận được từ việc trở thành L2 đang giảm dần. Danh sách các Ethereum L2 đang hoạt động và sắp ra mắt hiện quá dài để bất kỳ cá nhân nào có thể theo dõi. Các chuỗi xoay quanh L2 không nhận được sự chú ý nhiều hơn những chuỗi đi đầu đã làm (ví dụ: Lạc quan và Trọng tài). Ngay cả làn sóng zkEVM được chờ đợi từ lâu cũng đang gặp khó khăn trong việc thu hút người dùng, ứng dụng và giá trị.

Vì vậy, trở thành L2 một mình không đảm bảo được sự chú ý của mọi người nữa. Tuy nhiên, nó vẫn có thể mang lại lợi thế về sản phẩm so với các chuỗi độc lập nếu bạn có thể thu hút sự chú ý theo một số cách khác. Ví dụ: biến sơ đồ kim tự tháp thành hình vuông có thể thu hút ~ 700 triệu đô la vào đa chữ ký không có L2. Ngoài ra, bạn có thể xây dựng SVM L2 đầu tiên của Ethereum.

Giả sử bạn có một sản phẩm được chú ý, bây giờ chúng ta hãy xem xét việc trở thành L2 có thể giúp chuỗi tiếp cận cơ sở người dùng Ethereum và mang lại trải nghiệm sản phẩm tốt hơn như thế nào. Nó sẽ làm như vậy chủ yếu bằng cách tận dụng các tài sản gốc Ethereum (ví dụ: ETH) theo cách thuận lợi (ví dụ: các cầu nối có bảo mật và/hoặc UX hấp dẫn).

Giá trị của điều này phụ thuộc rộng rãi vào hai giả định cốt lõi:

1. Tài sản Ethereum hiện có rất quan trọng đối với trường hợp sử dụng nhất định (ví dụ: DeFi phụ thuộc vào ETH)

Nếu ứng dụng của bạn phụ thuộc nhiều vào tài sản của hệ sinh thái Ethereum thì kiến trúc L2 có thể có giá trị. Nếu bạn hoàn toàn không quan tâm đến tài sản Ethereum thì việc trở thành Ethereum L2 không có giá trị đặc biệt. Tài sản dựa trên Ethereum rõ ràng là tài sản quan trọng nhất trong tiền điện tử ngày nay, vì vậy ngày nay có một thị trường lớn được phục vụ ở đây.

Nhìn về phía trước ở cấp độ ngành, câu hỏi cốt lõi ở đây là việc tạo ra trạng thái mới và có giá trị của tiền điện tử sẽ như thế nào trong tương lai?

  • Nếu trạng thái tương lai này ngày càng không bị ràng buộc với trạng thái gốc Ethereum hiện tại (ví dụ: trạng thái mới duy nhất, RWA, v.v.), thì sức hấp dẫn của L2 có thể giảm đi.
  • Nếu trạng thái tương lai này phụ thuộc nhiều vào trạng thái gốc Ethereum hiện tại (ví dụ: giao dịch ETH), thì L2 có thể đóng một vai trò nổi bật.

Kịch bản trước đây đưa ra quan điểm rằng chúng ta chỉ thấy sự sụt giảm trong nhóm tiền điện tử sẽ là gì và bạn không nên lập chỉ mục quá mức về những gì ở đây ngày hôm nay. Kịch bản thứ hai đưa ra quan điểm rằng việc phát triển và ứng dụng tiền điện tử sẽ phụ thuộc rất nhiều vào lộ trình, do đó trạng thái hiện tại sẽ ảnh hưởng đến kết quả.

Cả hai đều đúng ở một mức độ nào đó, nhưng tôi nghĩ mọi quan điểm lạc quan về triển vọng dài hạn của ngành đều nghiêng về quan điểm đầu tiên. Sẽ có rất nhiều trạng thái mới và độc đáo mà chúng ta thậm chí không thể lý giải được rằng nó không bị ràng buộc với trạng thái ngày nay. Trạng thái hiện tại của tiền điện tử là rất thấp so với trạng thái dự kiến trong tương lai.

Ví dụ: “đảm bảo thanh toán” thường được trích dẫn của Ethereum có ý nghĩa rất nhỏ đối với các tài sản trong thế giới thực (RWA) chẳng hạn như stablecoin (ví dụ: USDC) hoặc tín phiếu kho bạc được mã hóa. Chúng được “giải quyết” khi nhà phát hành (ví dụ: Circle) cho là như vậy.

Trong trường hợp này, sức hấp dẫn của việc trở thành Ethereum L2 có thể giảm đi theo tỷ lệ ứng dụng. Một ứng dụng thanh toán mới dựa trên USDC vốn không quan tâm liệu đó có phải là Ethereum L2 hay không. Họ chỉ muốn cơ sở hạ tầng rẻ nhất, nhanh nhất, đáng tin cậy nhất cho phép họ cung cấp cho người dùng trải nghiệm sản phẩm tốt nhất.

Việc thành lập nhà nước mới trong lịch sử luôn là một trở ngại đối với Solana, mặc dù chúng ta thấy rõ gió đang thay đổi ở đây. Nhiều dự án cơ sở hạ tầng và DeFi nổi tiếng trên Solana hiện đang tung ra các token và sẽ còn nhiều hơn nữa. Đây là bước khởi động bánh đà Solana.

2.Ethereum đó ←→ Cầu L2 thích hợp hơn Ethereum ←→ Cầu L1 (ví dụ: vì lý do bảo mật và/hoặc UX)

Giả sử rằng giả định đầu tiên thực sự được đáp ứng cho một trường hợp sử dụng nhất định (tức là, nguồn gốc Ethereum khá có giá trị đối với ứng dụng của bạn). Sau đó, chúng ta cần hỏi xem liệu L2 có thể hiển thị những tài sản này theo cách thuận lợi hơn so với L1 riêng biệt hay không. Giả sử người dùng có một số ETH và họ muốn đổi nó lấy USDC. Họ đi đâu?

Mặc dù an ninh cầu đường thường được coi là động lực ở đây nhưng lập luận này có vẻ khó hiểu dựa trên thông tin sẵn có. Nhiều cầu nối tổng hợp lớn nhất thậm chí không có bằng chứng, có bằng chứng được đưa vào danh sách trắng, các bản nâng cấp được kiểm soát bằng nhiều chữ ký hoặc thậm chí chúng thậm chí không có L2 theo đúng nghĩa đen.

Điều này so sánh với cầu nối xác minh đồng thuận cổ điển (ví dụ: IBC). Trong thực tế, không có lỗi nghiêm trọng nào về số lượng người xác thực trong các tình huống như vậy. Lỗi cầu nối thường xảy ra do bị hack và/hoặc đa chữ kí cầu nối bị xâm phạm (điều mà L2 đều dễ mắc phải).

Mặc dù các cải tiến về bảo mật kém thuyết phục hơn đối với tôi ở đây, nhưng theo quan điểm của tôi, việc truy cập thuận tiện vào người dùng và tài sản Ethereum là lợi ích chính của việc kết nối L2 ngày nay. Các bản tổng hợp như Base, Optimism và Arbitrum có cảm giác giống như các phần mở rộng của Ethereum hơn. Người dùng giữ các ví và địa chỉ giống nhau, mã thông báo gas gốc là một phiên bản chuẩn duy nhất của ETH, ETH thống trị DeFi chẳng hạn như tất cả các cặp giao dịch, ứng dụng xã hội định giá NFT bằng ETH và trả tiền cho người sáng tạo bằng ETH (ví dụ: friend.tech), tiền gửi vào L2 là ngay lập tức (vì chúng sẽ được tổ chức lại cùng nhau), v.v.

Người dùng không thể suy luận nên sử dụng cây cầu nào, phân tích các giả định bảo mật khác nhau, nhận một trong số các mã thông báo được bao bọc có sẵn, lấy mã thông báo gốc của chuỗi để lấy gas, v.v. Họ chỉ muốn kết nối ETH của mình, nhận ETH ở phía bên kia và tiếp tục sử dụng L2 như cách họ sẽ sử dụng Ethereum hoặc bất kỳ L2 nào khác. Đây là lý do tại sao Eclipse sẽ chỉ sử dụng ETH làm mã thông báo gốc được sử dụng làm gas. Việc buộc sử dụng mã thông báo gas mới sẽ gây bất lợi cho UX.

Vậy tại sao Solana không thể cung cấp những lợi thế tương tự như Ethereum L2? Điều này thực sự trở thành một câu hỏi kỹ thuật hơn là bất cứ điều gì cơ bản và nó sẽ trở nên dễ dàng hơn theo thời gian. Điều này đúng với mã thông báo gas cũng như các thách thức UX khác liên quan đến việc không sử dụng EVM (vốn không có ở L1 so với L2):

  • Mã thông báo gas - Thanh toán gas có thể được loại bỏ khỏi người dùng, cho phép người dùng thanh toán bằng bất kỳ mã thông báo gas nào họ chọn.
  • Cầu nối - Cầu nối có khả năng được củng cố và tiêu chuẩn hóa nhiều hơn theo thời gian, dẫn đến ít nhầm lẫn hơn từ người dùng và sự phân mảnh thanh khoản.
  • Ví - Snaps được công bố gần đây của MetaMask mở rộng hỗ trợ MetaMask cho các chuỗi không phải EVM thông qua tích hợp của bên thứ ba được xây dựng trên cùng, chẳng hạn như thông qua MetaMask Snaps của Drift hoặc Solflare.
  • Trải nghiệm của nhà phát triển - Rào cản ngôn ngữ sẽ bị phá bỏ. Các dự án như Solang và Neon có thể giúp các nhà phát triển Solidity xây dựng trên Solana và các dự án như Stylus có thể giúp các nhà phát triển Rust xây dựng trên Arbitrum.

Trong tương lai, ETH thậm chí có thể đóng một vai trò trong Solana DeFi nếu người dùng bày tỏ sự ưa thích mạnh mẽ đối với ETH với tốc độ và quy mô của Solana. Trên thực tế, nhiều khả năng những người dùng có tài sản gốc Ethereum này sẽ tiếp tục sử dụng chúng trong hệ sinh thái Ethereum L2 vì những lý do mà chúng ta đã thảo luận, giả sử họ có quyền truy cập vào các L2 có khả năng mở rộng tương đương.

Dành riêng cho ứng dụng so với mục đích chung

Bất kể chuỗi là L1 hay L2, rõ ràng cần phải tăng thông lượng chuỗi đơn bằng cách mở rộng quy mô thực thi. Bản tổng hợp không được ngụ ý sự phân mảnh. Việc hợp nhất nhiều chuỗi đồng nhất dưới một trình sắp xếp được chia sẻ có trạng thái sẽ trông giống như một chuỗi song song xét từ góc độ mở rộng quy mô với trải nghiệm người dùng đầy thách thức hơn.

Chúng tôi thường thấy “không gian khối chuyên dụng” được coi là lý do để triển khai một bản tổng hợp dành riêng cho ứng dụng. Tuy nhiên, quan niệm sai lầm này đã nảy sinh phần lớn do những hạn chế không cần thiết của EVM đơn luồng với thị trường phí toàn cầu. Một SVM song song với thị trường phí địa phương giúp giảm đáng kể nhu cầu về chuỗi ứng dụng. Lưu trữ nhiều ứng dụng hơn trên cơ sở hạ tầng dùng chung giúp giảm đáng kể sự phức tạp của nhà phát triển và người dùng. Trải nghiệm người dùng chuỗi chéo và độ phức tạp của nhà phát triển trong thế giới nhiều chuỗi là một rủi ro hiện hữu bị đánh giá thấp.

Điều này không có nghĩa là cuối cùng sẽ chỉ có một chuỗi. Nhìn chung, tôi thấy có bốn đối số để triển khai chuỗi của riêng bạn:

  1. Khả năng mở rộng & Không gian khối chuyên dụng - Như đã đề cập ở trên, điều này thường không thuyết phục. Một xưởng đúc NFT sẽ không thể đóng cửa phần còn lại của chuỗi một cách hiệu quả, nhưng câu trả lời nói chung là không tạo ra một chuỗi khác. Điều này được giảm bớt nhờ VM song song với thị trường phí địa phương. Tuy nhiên, trong trường hợp băng thông của toàn bộ mạng đã bão hòa, thị trường phí địa phương sẽ không giúp ích được gì (tức là phí cho chuỗi chia sẻ sẽ tăng trên toàn cầu). Sau đó, bạn cần một chuỗi khác.
  2. Chủ quyền - Quản trị tiền điện tử vẫn còn khá kém và việc có chuỗi phân nhánh của riêng bạn có thể là một cơ chế phối hợp hữu ích. Trực giác của tôi cho rằng đây là một trường hợp rất hiếm gặp nhưng khó có thể nói chắc chắn. Điều này phù hợp với mối quan tâm của MakerDAO đối với chuỗi ứng dụng.
  3. Khả năng tùy chỉnh - Các tùy chỉnh ở cấp độ đồng thuận có thể có giá trị đối với một số ứng dụng nhất định (ví dụ: dYdX v4), nhưng những trường hợp này về mặt thực nghiệm cho đến nay rất ít và xa. Ngay cả dYdX, ví dụ điển hình của chuỗi ứng dụng, “có thể sẽ hướng nhiều hơn đến việc thực thi tổng quát trên chuỗi dYdX” theo Antonio trong tập Bell Curve gần đây của anh ấy. Nhu cầu về khả năng tùy chỉnh toàn bộ không thể giải quyết được trên chuỗi chia sẻ nói chung là thiếu đối với hầu hết các loại tiền điện tử. Gần như tất cả các đợt giới thiệu mới tiếp tục chỉ là các đợt phân nhánh EVM thông thường với các mã thông báo mới.
  4. Nắm bắt giá trị - Đây được cho là một tập hợp con của khả năng tùy chỉnh, nhưng nó khá quan trọng nên chúng tôi sẽ tách nó ra. Việc nội hóa giá trị trên cơ sở hạ tầng dùng chung vốn không được xây dựng chỉ dành cho ứng dụng của bạn có thể khó khăn hơn. Chuỗi ứng dụng có thể giúp phân bổ giá trị cho các ứng dụng có trách nhiệm dễ dàng hơn. Tuy nhiên, đây là một nỗ lực kỹ thuật hơn là một nỗ lực cơ bản và ở Solana đang có nghiên cứu về cách thực hiện chính xác điều này. Ngoài ra, hãy lưu ý rằng việc triển khai chuỗi của riêng bạn sẽ tốn rất nhiều chi phí so với chi phí khấu hao trên cơ sở hạ tầng dùng chung.

Động lực chính để khởi chạy chuỗi ứng dụng ngày nay thường là khả năng tăng cường tường thuật và/hoặc tiện ích mã thông báo cho một dự án đang gặp khó khăn. Sự suy thoái của thị trường gấu và sự thiếu tăng trưởng ứng dụng tương ứng đã khuyến khích sự phát triển và tài trợ cho một kiến trúc quá phức tạp, dẫn đến các dự án mới cần thiết để giải quyết những vấn đề phức tạp tự gây ra.

Việc ra mắt chuỗi của riêng bạn ngay hôm nay mang lại những đánh đổi đau đớn và không cần thiết (độ phức tạp, chi phí, trải nghiệm người dùng kém hơn, tính thanh khoản bị phân mảnh, v.v.) mà hầu hết các ứng dụng không thể biện minh cho những lợi ích gia tăng. Cơ sở hạ tầng cần thiết để làm cho UX này có tính cạnh tranh dường như còn xa vời. Điều này không có nghĩa là không có lý do gì để chuỗi ứng dụng tồn tại (chắc chắn là có). Đúng hơn, chúng tôi vừa lập chỉ mục quá mức theo hướng kể chuyện này với tư cách là một ngành, và do đó, xu hướng kết hợp lại hiện tại rõ ràng là có lợi trong tình trạng hiện tại.

Phần kết luận

Solana đúng là đã đạt được rất nhiều động lực trong những tháng gần đây. Sự điều chỉnh mạnh mẽ này phần lớn là sự thừa nhận tình trạng hiện tại của UX đa chuỗi - nó bị phân mảnh và đau đớn. Trải nghiệm người dùng của việc sử dụng ứng dụng Solana đơn giản là không thể tin được. Nhẹ nhàng và nhanh chóng.

Rollups và L2 đã mang tiếng xấu cho UX, nhưng vấn đề thực sự là sự phân mảnh. Chúng tôi liên kết các bản tổng hợp và L2 với tỷ lệ chia tỷ lệ theo chiều ngang bị phân mảnh vì trên thực tế, hầu hết chúng đều đã phân nhánh EVM nguyên trạng và sử dụng băng thông DA bị hạn chế. Chúng trở nên đắt tiền và cồng kềnh khi sử dụng.

Tuy nhiên, đây không phải là cơ bản. Chia tỷ lệ theo chiều dọc với máy ảo mạnh mẽ trên lớp DA có thể mở rộng sẽ giải quyết các vấn đề về UX và chi phí này. Một số mức độ đóng gói lại ngăn xếp cho cả L1 và L2 có thể xảy ra. L2 và bản tổng hợp sẽ cải thiện UX nếu được sử dụng đúng cách. Đó phải là điểm bán hàng thực sự của họ.

Cả hai cách tiếp cận đều có giá trị của chúng. Chúng ta chỉ cần làm tốt hơn việc tự hỏi bản thân trước tiên “sản phẩm này đang cố gắng giải quyết thị trường nào?” và “làm thế nào kiến trúc này có thể giải quyết được những gì tôi cần?” trước khi chúng ta xây dựng L1, L2, L3 tiếp theo…

Tuyên bố từ chối trách nhiệm:

  1. Bài viết này được in lại từ [dba]. Mọi bản quyền thuộc về tác giả gốc [Jon Charbonneau]. Nếu có ý kiến phản đối việc tái bản này, vui lòng liên hệ với nhóm Gate Learn , họ sẽ xử lý kịp thời.
  2. Tuyên bố miễn trừ trách nhiệm pháp lý: Các quan điểm và ý kiến trình bày trong bài viết này chỉ là của tác giả và không cấu thành bất kỳ lời khuyên đầu tư nào.
  3. Việc dịch bài viết sang các ngôn ngữ khác được thực hiện bởi nhóm Gate Learn. Trừ khi được đề cập, việc sao chép, phân phối hoặc đạo văn các bài viết đã dịch đều bị cấm.
Bắt đầu giao dịch
Đăng ký và giao dịch để nhận phần thưởng USDTEST trị giá
$100
$5500