Giải thích chi tiết về sự phát triển của AppChain, những cơ hội nào khác đáng chú ý trong tương lai?

Lý do chọn AppChain

Ngày càng có nhiều nhà phát triển không còn chia sẻ Để triển khai hợp đồng thông minh trên không gian khối, thay vào đó hãy chọn AppChain vì ba lý do chính:

Hiệu suất

· Vì các DApp cạnh tranh với nhau để giành không gian khối trên cùng một mạng, nên các DApp phổ biến hiện nay thường tiêu tốn một lượng lớn tài nguyên, khiến các DApp khác (như Polygon và Arbitrum) tăng chi phí giao dịch và gây ra sự chậm trễ của mạng.

 

· AppChain cho phép giao dịch Chi phí và độ trễ mạng thấp được duy trì trong phạm vi có thể dự đoán được của nhóm dự án, mang lại trải nghiệm người dùng tốt hơn cho người dùng cuối.

 

Khả năng tùy chỉnh

· Khi lượng khán giả của DApp tăng dần, các nhà phát triển cần liên tục tối ưu hóa sản phẩm cho người dùng.

· Ứng dụng quy mô lớn yêu cầu sự đánh đổi trong thiết kế như thông lượng, tính hữu hạn, mức độ bảo mật, quyền, khả năng kết hợp, tính nhất quán của hệ sinh thái, v.v. Ví dụ: việc trở thành người xác nhận có thể có yêu cầu hiệu suất cao trên phần cứng (chẳng hạn như chạy SGX hoặc FPGA để tạo bằng chứng không có kiến thức).

· Dành cho các tổ chức truyền thống Nói chung, AppChain cung cấp một cách để vào Web3 mà không cần phải chấp nhận cách tiếp cận hoàn toàn không cần cấp phép ngay từ đầu; ví dụ: các công ty có thể yêu cầu người xác thực thực hiện KYC; các kỹ sư sàng lọc trước muốn phát triển trên mạng của họ; chọn Khởi đầu chuỗi chéo điểm và điểm cuối.

Nắm bắt giá trị

· Mặc dù các giải pháp mở rộng phổ quát giúp giảm chi phí giao dịch và duy trì trải nghiệm phát triển và bảo mật, nhưng các giải pháp này hầu như không mang lại cho các nhà phát triển cơ hội nhận được các lợi ích khác.

· Mặt khác hand , các sản phẩm hiện có có tác dụng trình diễn thương mại mạnh mẽ cho AppChain và các nhà phát triển có thể phân nhánh các giao thức hiện có trong các hệ sinh thái khác và thu được lợi ích (chẳng hạn như cơ chế AMM hoặc phí giao dịch NFT).

· AppChain's Mã thông báo có thể được bắt nguồn từ các mô hình bảo mật khác như đặt cược Mã thông báo hoặc khí đốt Mã thông báo )loại Mã thông báo giá giảm và Mã thông báo Trở lại L2 hoặc L1 trên thị trường Mã thông báo Lợi ích phải được bắt nguồn từ quá trình này.

· Ngoài ra, các ứng dụng có thể tránh MEV bằng cách chạy trình xác thực hoặc trình xác thực của riêng chúng, điều này sẽ có cơ hội tạo ra các mô hình kinh doanh mã hóa mới. Ví dụ: trình xác thực của dYdX có thể trở thành nhà tạo lập thị trường và giảm hoặc loại bỏ phí xử lý cho người dùng, nhưng không có Cung cấp giá thực hiện tốt nhất, tương tự như mô hình "Thanh toán cho luồng đơn hàng" (PFOF, Thanh toán cho luồng đơn hàng) của Robinhood.

· Trường hợp khác dành cho Ví dụ: nhiều trò chơi thành công có số lượng lớn mô-đun, thành phần mở rộng, giao diện và các yếu tố khác và trong quá trình phát triển trò chơi, các nhà phát triển sẽ cố gắng hết sức để làm cho mô-đun dễ dàng sửa đổi. Chỉ là hầu hết những sửa đổi này được thực hiện bởi những game thủ nghiệp dư, những người không thu được bất kỳ lợi ích tài chính nào. Nếu những trò chơi này có trên AppChain, các mod có thể mở rộng IP này thành Rollup để thu được lợi ích kinh tế từ không gian khối chung.

Các vấn đề với AppChain

Tính khả dụng hạn chế Thành phần và tính không thể tách rời

· AppChain tự kết nối với cơ sở hạ tầng cơ bản ở một mức độ nhất định và sự cô lập sinh thái khác . Mặc dù nó không phá vỡ khả năng kết hợp (sử dụng các cầu nối chuỗi chéo của cùng một VM để đạt được chuỗi chéo), nhưng nó phá vỡ tính không thể phân chia (thuộc tính "tất cả hoàn thành" hoặc "tất cả chưa hoàn thành", nghĩa là trong một giao dịch duy nhất Tất cả phụ -các hoạt động được thực thi hoặc không có hoạt động nào được thực thi).

· Nói cách khác , mặc dù tính không thể phân chia là đặc tính duy nhất của tất cả các ứng dụng trên cùng một lớp thanh toán nhưng nó không phải là đặc tính quan trọng nhất đối với nhiều ứng dụng (ví dụ: trò chơi P2E không dựa vào các khoản vay nhanh để duy trì hoạt động kinh tế của chúng).

Hạn chế quyền

· Giả sử rằng tất cả AppChain đều có quyền đọc và ghi, cấu trúc thị trường dẫn đến sẽ hạn chế sự đổi mới của các nhà phát triển về mặt không được phép và khả năng kết hợp. Quyền của người dùng trong việc thực hiện các giao dịch miễn phí và từ chối cũng sẽ bị hạn chế, điều này thay vào đó sẽ khiến các vấn đề cần được ngành công nghiệp mã hóa giải quyết lại xuất hiện trở lại.

Sự phân mảnh thanh khoản

· Khi sử dụng AppChain, tính thanh khoản và tài sản cơ bản khác cần sử dụng các cầu nối chuỗi chéo để chuyển đổi vào hệ sinh thái và ngược lại. Mặc dù không có gì sai khi sử dụng cầu nối chuỗi chéo, nhưng nó sẽ làm tăng sự bất tiện trong tương tác từ góc độ người dùng.

Mô hình bảo mật phản xạ

· Nếu áp dụng Mã thông báo Là một mô hình bảo mật, các trường hợp nguy hiểm có thể phát sinh, tức là nếu Mã thông báo Nếu giá trị được trả về 0 thì hệ thống kinh tế trong ứng dụng sẽ không còn an toàn.

Lãng phí tài nguyên

· Nếu tỷ lệ sử dụng ứng dụng trên chuỗi quá thấp thì chính AppChain đã gây lãng phí tài nguyên. Nếu AppChain có trình xác thực chuyên dụng thì những trình xác thực này có thể triển khai tài nguyên cho các hệ sinh thái khác.

Chi phí phát triển bổ sung

· Không giống như triển khai hợp đồng thông minh, quy trình phát triển AppChain rất cồng kềnh, do đó làm tăng khó khăn về mặt kỹ thuật khi quản lý cơ sở hạ tầng xung quanh (chẳng hạn như trình xác thực hoặc trình sắp xếp chuỗi).

Các công cụ hệ sinh thái và hỗ trợ kỹ thuật còn hạn chế

· Không có tài nguyên "có sẵn" nào để sử dụng, chẳng hạn như trình khám phá khối, nhà cung cấp RPC, người lập chỉ mục, nhà tiên tri, kênh fiat và quỹ sinh thái.

Các thị trường mới nổi cho AppChain

Do những hạn chế nêu trên có thể gặp phải khi thiết lập hệ sinh thái độc lập, AppChain phù hợp hơn với các ứng dụng có đặc điểm sau:

· Đạt quy mô nhất định ở một số khía cạnh nhất định, chẳng hạn như số lượng số người dùng và thỏa thuận Doanh thu, TVL, mức độ phù hợp với thị trường sản phẩm, v.v.

· Có lợi thế đáng kể về sản phẩm hoặc hiệu suất trong không gian khối chuyên dụng

· Yêu cầu thấp hơn về tính bảo mật và tính không thể phân chia, chẳng hạn như trò chơi P2E, NFT, mạng xã hội được mã hóa, v.v.

Do đó, thật hợp lý khi suy ra rằng hầu hết các ứng dụng cũng sẽ tiếp tục triển khai trên L1 và L2, chia sẻ không gian khối. Ngoài ra, do bối cảnh hiện tại của L2 vẫn còn rất phân mảnh nên các giao thức DeFi, đặc biệt là các giao thức DeFi, vẫn sẽ chọn khởi chạy trên L1 do cân nhắc về tính bảo mật, tính thanh khoản và tính không thể phân chia. Điều quan trọng cần nhấn mạnh là tính không thể phân chia ở đây đặc biệt quan trọng, bởi vì ngay cả khi bảng cân đối kế toán bằng 0, bạn vẫn có thể nhận được số tiền hiệu quả và không giới hạn bằng các khoản vay nhanh.

Ngoài ra, nếu không- Các ứng dụng DeFi Khi sự phát triển của chúng đã đạt đến một quy mô nhất định và hình thành hiệu ứng mạng và hệ sinh thái đủ lớn, chúng có thể chọn tung ra các sản phẩm trên L2 chung, sau đó chuyển sang L3 dựa trên ứng dụng hoặc khởi chạy trực tiếp trên L1 dựa trên ứng dụng này. , quá trình phát triển đại khái như sau:

Hầu hết các ứng dụng sẽ Chọn các lớp thực thi mô-đun (đặc biệt là các lớp cuộn) trên các chuỗi khối nguyên khối vì chúng không có vốn cần thiết để khởi chạy các bộ trình xác thực lớn. Ngoài ra, trình xác thực chất lượng cao sẽ không chọn Mã thông báo Triển khai với AppChain có giá thấp hơn hoặc không ổn định.

Mặc dù vậy, với mã hóa Với Với sự phát triển và phổ biến của ngành, hầu hết các ứng dụng sẽ tiếp tục ra mắt AppChain của riêng họ. Cấu trúc thị trường AppChain trong tương lai cũng sẽ rất đa dạng:

· Một blockchain nguyên khối dựa trên các ứng dụng cụ thể được kết nối thông qua các cầu nối chuỗi chéo khác nhau

· Các chuỗi bên dành riêng cho ứng dụng kết nối với các chuỗi khối nguyên khối

· Bản cuộn dành riêng cho ứng dụng trong một chuỗi khối nguyên khối

· Không cần lớp giải quyết và Bản cuộn dành riêng cho ứng dụng độc lập

Không gian thiết kế của AppChain

Khi chọn AppChain nào để phát triển, bạn cần cân nhắc các điểm sau:

Loại bảo mật: Việc tấn công chuỗi và thay đổi trạng thái của nó khó đến mức nào?

· Đã chia sẻ: Được bảo vệ bởi nhiều trình xác thực không đồng nhất và rất có thể được điều hành bởi các đối tượng khác nhau

(chẳng hạn như parachain của Polkadot, Skale)

· Isolated: Bảo mật được đảm bảo bởi chính ứng dụng; nó có thể sử dụng trình xác thực hoặc trình sắp xếp thứ tự đi kèm với ứng dụng; Mã thông báo của ứng dụng Được sử dụng để đặt cược nhằm thu được lợi ích kinh tế

(chẳng hạn như Cosmos, Axie Ronin)

· Kế thừa: Áp dụng lớp giải quyết hoặc đồng thuận cơ bản để đảm bảo an ninh

(chẳng hạn như zkSync, Optimism)

Nguồn an toàn: Đảm bảo an ninh đến từ đâu? Sự định cư xảy ra ở đâu?

· Ethereum: Sử dụng Ethereum làm lớp giải quyết cho bằng chứng gian lận, bằng chứng xác thực và các cuộc tấn công chi tiêu gấp đôi phổ biến để đảm bảo an ninh mạng

(chẳng hạn như Arbitrum, zkSync)

· Non-Ethereum L1: Lợi dụng tính bảo mật của non-Ethereum L1, khả năng cao sẽ có một L1 hoàn toàn khác mô hình đồng thuận

(chẳng hạn như NEAR Aurora, Tezos rollups)

· Ứng dụng Mã thông báo : sẽ áp dụng Mã thông báo Là sự đảm bảo an ninh cho hệ sinh thái

(chẳng hạn như Mạng con của Avalanche, chuỗi con trong hệ sinh thái Cosmos)

Quyền: Các nút được chọn như thế nào? Ai có thể đọc hoặc viết trạng thái?

· Không có giấy phép : Bất kỳ ai cũng có thể đọc và viết hợp đồng cũng như xác minh quá trình chuyển đổi trạng thái

(chẳng hạn như Optimism, StarkNet)

· Quyền chọn lọc: Chỉ những người xác thực hoặc nhà phát triển có trong danh sách cho phép mới có thể đọc, viết hoặc xác minh trạng thái của chuỗi (chẳng hạn như Supernets của Polygon, Subnets của Avalanche)

Khả năng kết hợp: trong cùng một hệ sinh thái, dòng chảy Dễ dàng như thế nào và có an toàn khi chuyển các thuộc tính và trạng thái sang các ứng dụng khác nhau không?

· Không giới hạn : Có thể được chuyển sang bất kỳ ứng dụng nào với độ trễ thấp và độ bảo mật cao

(chẳng hạn như giao thức XCMP của Polkadot, giao thức IBC của Cosmos)

· Limited: Có những hạn chế về khả năng kết nối, độ trễ hoặc bảo mật

(Chẳng hạn như Mạng con của Avalanche, Siêu mạng của Polygon) 

Tính cuối cùng: Khi nào một giao dịch được coi là hoàn tất?

(giả sử "cuối cùng" là trạng thái hoàn thành thực sự)

· Instant: thường sử dụng cơ chế đồng thuận BFT (như NEAR Aurora, Evmos)

· Yêu cầu có điều kiện: thường sử dụng sơ đồ cuộn lên, giao dịch có thể được coi là cuối cùng sau khi khối được gửi đến L1 (giả sử dữ liệu có sẵn) (Chẳng hạn như Trọng tài, zkSync)

Gas Mã thông báo : Người dùng sử dụng cái nào? Mã thông báo Trả tiền bằng gas?

· Không ứng dụng Mã thông báo : Thông thường là tài sản cơ bản của L1 hoặc L2 nơi đặt ứng dụng

(chẳng hạn như Ethereum, Evmos)

· Áp dụng Mã thông báo :ứng dụng Mã thông báo Nó chạy trên L1 hoặc L2 dựa trên các ứng dụng cụ thể

(chẳng hạn như Mạng con, Thẩm thấu của Avalanche)

· Không tốn gas: Trình xác thực L1 hoặc L2 hoặc chính ứng dụng cung cấp cho người dùng khoản trợ cấp chi phí phần cứng

(Chẳng hạn như AltLayer, Skale)

Các yếu tố tham chiếu quan trọng khác:

·Yêu cầu đặt cược: Ứng dụng cần cam kết bao nhiêu? Mã thông báo , cho phép người xác thực đảm bảo mạng hoạt động bình thường

· TPS: Thước đo chủ quan về thông lượng sẽ thay đổi theo kích thước của dòng giao dịch

(tức là các giao dịch lớn hơn sẽ làm giảm thông lượng và ngược lại)

·Hỗ trợ EVM: Hỗ trợ cả mã Solidity và EVM mà nhà phát triển không cần sửa đổi cơ sở mã của họ

Dựa trên các điểm trên, giải pháp AppChain hiện tại có thể được tóm tắt là: