Các bản tổng hợp ứng dụng đang nổi lên như là người chiến thắng rõ ràng trong việc mở rộng một nhóm ứng dụng cụ thể của Ethereum. Các ứng dụng này được hưởng lợi từ sự đảm bảo quyền sở hữu mạnh mẽ và không cần cấp phép nhưng không yêu cầu tương tác đồng thời giữa tất cả người dùng ứng dụng. Các trò chơi hoàn toàn trên chuỗi (FOG) là ví dụ điển hình nhất phù hợp với mô tả này. FOG được hưởng lợi từ quyền sở hữu tài sản trong trò chơi mạnh mẽ, việc tham gia trò chơi không được phép và việc sửa đổi trò chơi không được phép. Tuy nhiên, hầu hết các trò chơi không yêu cầu tất cả người chơi tương tác với nhau cùng một lúc. Các ứng dụng khác có thể hưởng lợi từ chiến lược mở rộng quy mô tổng hợp ứng dụng bao gồm thị trường NFT, sàn giao dịch vĩnh viễn và suy luận AI trên chuỗi.

Bản tổng hợp ứng dụng đã là phương pháp triển khai phù hợp cho nhiều trường hợp sử dụng này. Tuy nhiên, việc triển khai bản tổng hợp tiêu chuẩn, tức là bản tổng hợp EVM, vẫn có những giới hạn quan trọng về khả năng mở rộng. Họ có thể đạt được thông lượng khoảng 100 giao dịch mỗi giây. Thông lượng như vậy có thể đủ cho một số trò chơi trên chuỗi, tùy thuộc vào loại trò chơi. Tuy nhiên, hầu hết các trò chơi đều cần thông lượng cao hơn nhiều để hỗ trợ số lượng lớn (> 1000) người chơi đồng thời. Bài viết này tập trung vào các phương pháp mở rộng quy mô tổng hợp ứng dụng để tiếp cận hàng trăm nghìn người tham gia đồng thời. Đối với mỗi cách tiếp cận, tôi thảo luận về loại ứng dụng/trò chơi phù hợp và những thách thức mà nó phải đối mặt.

Những nhà xây dựng đang sử dụng bản tổng hợp ứng dụng hoặc những người đang xây dựng cơ sở hạ tầng để mở rộng quy mô tổng hợp ứng dụng được khuyến khích liên hệ với tôi và đăng ký vào Alliance. Tôi mong được làm việc với những người sáng lập xây dựng trong những lĩnh vực này.

Chia tỷ lệ theo chiều ngang

Khả năng mở rộng theo chiều ngang là cách tiếp cận đơn giản nhất để mở rộng quy mô tổng hợp ứng dụng. Tuy nhiên, sự đơn giản phải trả giá bằng việc mất khả năng kết hợp khiến chúng chỉ phù hợp với một nhóm nhỏ ứng dụng, chẳng hạn như trò chơi một người chơi.

Khả năng mở rộng theo chiều ngang có nghĩa là chỉ cần triển khai nhiều bản tổng hợp ứng dụng (OP hoặc ZK) với cùng một hợp đồng thông minh được triển khai cho tất cả các bản tổng hợp. Giao diện người dùng của ứng dụng sẽ hướng người dùng đến một trong các bản tổng hợp một cách liền mạch tùy thuộc vào dung lượng, vị trí hoặc các tùy chọn ứng dụng cụ thể. Alt Layer gần đây đã thể hiện khái niệm này bằng cách tung ra FOCG 2048 có thể mở rộng. Trong giao diện người dùng của trò chơi, người dùng có tùy chọn để chọn nhóm nào sẽ tham gia dựa trên vị trí địa lý của họ. Do tính đơn giản và sẵn có của các nhà cung cấp dịch vụ tổng hợp như Caldera , những người xử lý tất cả các công việc cơ sở hạ tầng liên quan đến quay và quản lý các bản tổng hợp này, nên phương pháp này có thể dễ dàng được các nhà phát triển trò chơi áp dụng.

Mặc dù đơn giản nhưng có một số vấn đề trong phương pháp mở rộng quy mô đa cuộn. Đầu tiên là chuyển đổi mạng cuộn lên. Ví hiện tại, ví dụ: Metamask, yêu cầu phê duyệt thủ công để kết nối với mạng mới, tức là phiên bản tổng hợp. Điều này dẫn đến trải nghiệm người dùng khó khăn và khó hiểu đối với những người chơi cần kết nối thủ công với nhiều “mạng” để chơi cùng một trò chơi. May mắn thay, có thể loại bỏ sự phức tạp này bằng các giải pháp AA. Tức là EIP 4337 và các ví được nhúng như Privy và 0xPass.

Một thách thức khác là việc quản lý trạng thái của người chơi trong quá trình chuyển đổi giữa quá trình tổng hợp. Trong một số trường hợp, chẳng hạn như giảm dung lượng, ứng dụng có thể cần hợp nhất nhiều phiên bản tổng hợp thành một phiên bản duy nhất để tiết kiệm tài nguyên. Trong trường hợp như vậy, tất cả trạng thái của trình phát đang hoạt động cần được chuyển sang phiên bản mới. Các giải pháp bắc cầu hiện tại, đặc biệt là cầu zk, có thể rất quan trọng trong việc giải quyết vấn đề này. Bằng cách sử dụng các giải pháp này, có thể kết nối trạng thái trò chơi của người chơi với một phiên bản tổng hợp mới trong khi vẫn duy trì bằng chứng về tính hợp lệ của trạng thái này. Tuy nhiên, độ trễ của các giải pháp bắc cầu hiện có có thể kém tối ưu hơn cho các trường hợp sử dụng trò chơi.

Kênh trạng thái ZK

Một phương pháp mở rộng quy mô tổng hợp ứng dụng khác phù hợp hơn với các trò chơi nhiều người chơi, ví dụ: Poker, là các kênh trạng thái zk. Trong những trò chơi này, sự tương tác giữa người chơi diễn ra giữa một số ít người chơi, ví dụ: 2–10. Việc chơi trò chơi giữa những người chơi này chỉ quan trọng khi trò chơi đang diễn ra. Tuy nhiên, kết quả cuối cùng của trò chơi quan trọng hơn vì nó ảnh hưởng đến số dư tài sản của mỗi người chơi. Do đó, điều quan trọng là lưu trữ kết quả trong một lớp liên tục được chia sẻ.

Trong trường hợp này, bản tổng hợp ứng dụng đại diện cho lớp thông tin được chia sẻ nơi lưu trữ kết quả trò chơi và nơi tồn tại nội dung trò chơi. Đối với mỗi trò chơi trong danh sách, Kênh trạng thái ZK có thể được khởi tạo để phục vụ trò chơi này. Trong quá trình chơi trò chơi, mỗi người chơi thực hiện các giao dịch và tạo ZKP để chứng minh rằng họ đã tuân thủ các quy tắc của trò chơi. Bằng chứng từ sự tương tác của người chơi khác tổng hợp các bằng chứng trước đó bằng cách sử dụng bằng chứng đệ quy. Khi trò chơi kết thúc, ZKP cuối cùng sẽ được gửi vào danh sách ứng dụng để chứng minh tính hợp lệ của việc chơi trò chơi và tính hợp lệ của kết quả cuối cùng. Sự thay đổi trạng thái do trò chơi gây ra sẽ thay đổi trạng thái của người chơi khi tổng hợp ứng dụng.

Các kênh trạng thái ZK chuyển các tương tác trò chơi ra khỏi chuỗi. Do đó, các hoạt động và giao dịch trong trò chơi không được tính vào thông lượng của quá trình tổng hợp ứng dụng. Bằng cách sử dụng phương pháp này, các bản tổng hợp ứng dụng có thể mở rộng quy mô lớn để hỗ trợ hàng chục hoặc hàng trăm nghìn người chơi đồng thời. Các giao dịch tổng hợp ứng dụng sẽ chỉ là quá trình xác minh ZKP được tạo và các giao dịch cập nhật trạng thái dẫn đến hệ số mở rộng là 100–1000x. Nhiều nhóm bao gồm Ontropy đã tập trung phát triển công nghệ này.

Nhược điểm của phương pháp này là nó yêu cầu người chơi chạy logic trò chơi và tạo ZKP trên thiết bị của họ. Thông thường, những bằng chứng này rất nhẹ và bằng cách tận dụng các hệ thống chứng minh tiên tiến như Halo2, việc chứng minh có thể mất ít hơn vài giây. Tuy nhiên, điều này vẫn có thể dẫn đến trải nghiệm người dùng bị suy giảm đối với người chơi có thiết bị hạn chế về tài nguyên.

Một sửa đổi đối với cách tiếp cận này có thể làm giảm bớt vấn đề này là chỉ định một trong những người tham gia kênh trạng thái zk làm trình sắp xếp thứ tự tạm thời. Trình sắp xếp thứ tự này sẽ nhận các giao dịch của từng người chơi và tạo ZKP tương ứng và chia sẻ ZKP với tất cả những người tham gia kênh. Bản sửa đổi này có thể được coi là những chiếc ZK L3 phù hợp với bản tổng hợp ứng dụng. Nhóm Cartridge đã triển khai kiến trúc này bằng cách thiết kế một trình sắp xếp chuỗi chuyên dụng có tên Katana.

Cách tiếp cận kênh trạng thái zk có rất nhiều tiềm năng. Tuy nhiên, có một số câu hỏi mở liên quan đến môi trường thực thi bên trong kênh trạng thái zk và cách tối ưu hóa nó để chứng minh đệ quy. Môi trường zkEVM hiện tại không hiệu quả lắm và hầu hết chúng hiện không hỗ trợ đệ quy bằng chứng. Các lựa chọn thay thế bao gồm zkVM nhẹ hoặc thậm chí sử dụng các mạch zk chuyên dụng để tương tác với người chơi nếu số lượng hành động có thể thực hiện được của người chơi bị hạn chế.

Thay đổi môi trường thực thi

Cách tiếp cận thứ ba đối với khả năng mở rộng bản tổng hợp ứng dụng là thay đổi môi trường thực thi của bản tổng hợp. Bất chấp sự trưởng thành và phong phú của các công cụ phát triển EVM, chúng không phù hợp với các ứng dụng hiệu suất cao như trò chơi. Hơn nữa, mô hình lưu trữ và thực thi đơn luồng EVM dẫn đến thông lượng giảm có thể được cải thiện.

Ưu điểm chính của phương pháp này là Cải thiện thông lượng tổng hợp không yêu cầu hy sinh khả năng kết hợp hoặc hạn chế số lượng trường hợp sử dụng. Cách tiếp cận này có thể hoạt động với bất kỳ ứng dụng Web 3 nào miễn là môi trường thực thi có thể đạt được thông lượng mà ứng dụng yêu cầu. Điều này khiến chúng trở thành giải pháp khả thi duy nhất cho các ứng dụng yêu cầu truy cập trạng thái chia sẻ như AMM, giao thức cho vay và các ứng dụng DeFi khác.

Mở rộng chức năng EVM thông qua tiền biên dịch

Cách tiếp cận đầu tiên là để bản tổng hợp vẫn tương thích với EVM và giải quyết một số hạn chế về thông lượng thông qua các phần biên dịch trước. Ý tưởng ở đây rất đơn giản. Biên dịch trước chỉ đơn giản là di chuyển các hoạt động EVM tốn kém về mặt tính toán xuống cấp độ nút. Một hoạt động cần hàng trăm hoặc hàng nghìn EVM OP và tiêu thụ hơn 100 nghìn gas có thể được đơn giản hóa thành một hoạt động duy nhất với chi phí gas thấp hơn 100 lần. Mở rộng môi trường tổng hợp bằng tiền biên dịch thường được gọi là EVM+. Ví dụ về cách tiếp cận này bao gồm hỗ trợ quyền riêng tư trên chuỗi và hỗ trợ các sơ đồ chữ ký hiệu quả hơn, ví dụ: chữ ký BLS. Ví dụ: trò chơi poker zkHoldem sử dụng các hoạt động FHE và zk chuyên dụng để đạt được việc chia và tiết lộ thẻ poker riêng tư. Việc phát triển các bản biên dịch trước chuyên biệt này thường là nỗ lực chung giữa nhà phát triển bản tổng hợp ứng dụng và nhà cung cấp Raas, những người quản lý việc triển khai và bảo trì cơ sở hạ tầng của bản tổng hợp ứng dụng.

Sử dụng môi trường thực thi không phải EVM

Một cách tiếp cận khác để cải thiện môi trường thực thi tổng hợp là thoát khỏi EVM. Cách tiếp cận này ngày càng phổ biến hơn đối với các nhà phát triển mới làm quen với hệ sinh thái Ethereum và các nhà phát triển tin rằng Solidity không phải là ngôn ngữ tốt nhất để phát triển các ứng dụng phức tạp.

Ngày nay chúng ta có các ứng dụng tổng hợp chạy trên WASM, SVM, Cairo và thậm chí cả thời gian chạy Linux. Hầu hết các phương pháp này cho phép các nhà phát triển viết hợp đồng thông minh của họ bằng các ngôn ngữ cấp cao như Rust hoặc C. Nhược điểm là khả năng tương tác với các hợp đồng Solidity hiện tại thường bị mất. Tuy nhiên, vẫn có thể tạo khả năng tương thích với EVM. Ví dụ: bút cảm ứng của Aributrum sử dụng bộ đồng xử lý để làm cho các hợp đồng Stylus tương thích với EVM. Thiết kế này đưa Stylus đến gần hơn với kiến trúc EVM+ hơn là không phải EVM.

Môi trường thực thi kết hợp

Cách tiếp cận thứ ba đặc biệt phổ biến trong FOG là kết hợp các tính năng tốt nhất trong hai cách tiếp cận trước đó. Cách tiếp cận này kết hợp khả năng tương thích EVM với môi trường thực thi không phải EVM chuyên dụng. Các môi trường không phải EVM tập trung vào việc thực thi các nguyên tắc cốt lõi của trò chơi với hiệu suất cao. Quản lý tài sản trong trò chơi, ví dụ: giao dịch NFT trong trò chơi có thể được xử lý bằng hợp đồng Solidity tiêu chuẩn.

Ưu điểm của phương pháp này là khả năng tương thích EVM đảm bảo sự phù hợp với hệ sinh thái lớn hơn gồm các nhà phát triển và sản phẩm hiện có. Nó cũng cho phép khả năng kết hợp không được phép. Các nhà phát triển có thể sửa đổi và mở rộng logic trò chơi bằng cách thêm các hợp đồng thông minh EVM/solidity. Trong khi đó, công cụ trò chơi không phải EVM chuyên dụng đạt được thông lượng cao mà EVM không thể đáp ứng được.

Ví dụ về phương pháp này là World Engine của Argus và Keystone của Curio. World Engine tách việc thực thi logic trò chơi thành một lớp riêng gọi là Game Shard chạy trên lớp tương thích EVM. Game Shard cũng được thiết kế để cho phép chia tỷ lệ theo chiều ngang để điều chỉnh tổng thông lượng tổng hợp dựa trên nhu cầu. Tương tự, kiến trúc Keystone của Curio kết hợp một công cụ trò chơi có hiệu suất cao với EVM làm môi trường thực thi tổng hợp. Thử thách ở đây là đạt được khả năng tương tác liền mạch giữa công cụ EVM và công cụ trò chơi.

Cân nhắc về tính sẵn có của dữ liệu

Trong cuộc thảo luận trước đó, trọng tâm là khía cạnh chính của việc mở rộng quy mô tổng hợp ứng dụng, điều này đang làm tăng thông lượng giao dịch tổng hợp. Có các chủ đề khác liên quan đến thông lượng tăng lên này như Tính khả dụng của Dữ liệu (DA), phân cấp trình sắp xếp chuỗi và tốc độ giải quyết. Tính khả dụng của dữ liệu là vấn đề cấp bách nhất trong số này đối với các bản tổng hợp ứng dụng có hiệu suất cao.

Một bản tổng hợp ứng dụng có khả năng đạt được thông lượng vượt quá 10 nghìn tps. Không thể sử dụng Ethereum làm lớp DA cho các giao dịch này. Đầu tiên, chi phí trung bình để xuất bản dữ liệu của một lần chuyển ETH L2 đơn giản trên L1 có thể vượt quá 0,10 USD. Những chi phí này quá cao đối với hầu hết các lần giới thiệu ứng dụng. Quan trọng hơn, L1 của Ethereum hiện không thể hỗ trợ nhiều hơn khoảng 8k TPS [1] cho các bản tổng hợp sử dụng L1 cho DA.

Việc tổng hợp ứng dụng sẽ chủ yếu phụ thuộc vào các giải pháp DA bên ngoài. Celestia và EigenDA hiện được định vị là lựa chọn khả thi nhất cho việc tổng hợp ứng dụng. Ví dụ: Eclipse có kế hoạch sử dụng Celestia cho quá trình tổng hợp dựa trên SVM thông lượng cao. Argus và các công cụ trò chơi có thông lượng cao ban đầu cũng có kế hoạch sử dụng Celestia. Tương tự, EigenDA hứa hẹn thông lượng dữ liệu lên tới 10 MB/giây có thể là một giải pháp khả thi cho nhiều lần tổng hợp ứng dụng.

Tuy nhiên, việc tích hợp Celestia hoặc EigneDA có nhược điểm chính là rò rỉ giá trị kinh tế. Việc triển khai ứng dụng phải trả phí cho lớp DA bên cạnh phí thanh toán trên Ethereum L1. Phí thanh toán rất quan trọng đối với quá trình triển khai ứng dụng vì nó điều chỉnh bảo mật triển khai với bảo mật của Ethereum. Bảo đảm DA ít quan trọng hơn, đặc biệt trong bối cảnh FOG nơi giá trị giao dịch nhỏ hơn nhiều. Hơn nữa, Celestia và EigenDA hứa hẹn mức phí thấp vì các mạng này còn mới và ban đầu sẽ có mức sử dụng thấp. Khi các mạng DA này đạt được mức sử dụng cao, phí DA cũng có thể trở nên quá mức. Theo ý kiến của tôi, thay vào đó, các bản tổng hợp ứng dụng nên sử dụng Ủy ban sẵn có dữ liệu (DAC) đơn giản để chứng thực tính khả dụng của dữ liệu tổng hợp[3] .

Tóm lại, tôi tin rằng việc tổng hợp ứng dụng là giải pháp tốt nhất hiện có để mở rộng quy mô các ứng dụng có thông lượng cao nói chung và các trò chơi hoàn toàn trên chuỗi nói riêng. Mở rộng quy mô các bản tổng hợp ứng dụng này là chìa khóa để đạt được sự chấp nhận rộng rãi vượt xa người dùng tiền điện tử bản địa. Tại Alliance, chúng tôi muốn biến tầm nhìn này thành hiện thực bằng cách hỗ trợ những người sáng lập đang xây dựng tầm nhìn này

Tôi xin cảm ơn Matt Katz, Kevin Zhang, Tarrence van As và Larry Liu vì những phản hồi quý giá của họ về bài viết này.

[1] Giả sử 50% giới hạn gas khối của Ethereum sẽ chỉ để lưu trữ dữ liệu bằng cách sử dụng calldata, kích thước tx trung bình 10 byte. Thời gian khối 12 giây

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

1. Bài viết này được in lại từ [Liên minh]. Mọi bản quyền thuộc về tác giả gốc [Mohamed Fouda]. 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.