Avail: Sự hợp nhất của cơ sở hạ tầng tiền mã hóa

Điểm chính

Phí đăng dữ liệu từng là nút thắt cổ chai đối với các rollup và khi có nhiều rollup ra mắt hơn, khả năng tương tác sẽ là một thách thức lớn.
Avail đề xuất một giải pháp tiềm năng giải quyết vấn đề phân mảnh thông qua ba sản phẩm của mình: Avail DA, Nexus và Fusion, cùng mục đích thống nhất trải nghiệm web3.
Avail DA là lớp DA (data availability) sử dụng cơ chế lấy mẫu DA và bằng chứng hợp lệ để đạt được lớp cơ sở có hiệu suất cao và đảm bảo DA về mặt thuật toán.
Avail Nexus là một phối hợp ZK tùy chỉnh được xây dựng dựa trên Avail DA để xác minh và rollup các bằng chứng nhằm hỗ trợ khả năng tương tác xuyên chuỗi không đồng bộ.
Avail Fusion là một giải pháp bảo mật chung cho phép người dùng stake nhiều token blue-chip gốc khác nhau, cùng với token gốc của các chuỗi xây dựng trên Avail, để tăng cường bảo mật kinh tế trên nhiều lớp của Avail.

Tại thời điểm lịch sử của cuộc tranh luận về cơ sở hạ tầng, các rollup cho thấy rằng chi phí đăng tải dữ liệu là một trong những node thắt chính ảnh hưởng đến hiệu suất và là yếu tố hạn chế thông lượng của rollup. Vì các rollup bắt buộc phải xuất bản dữ liệu như dữ liệu gọi giao dịch lên lớp DA, nên chi phí đăng tải dữ liệu quá cao có nghĩa là các rollup không thể đăng một lượng lớn dữ liệu và do đó, không thể mở rộng thông lượng rollup. Kết quả là, nhiều lớp DA khác nhau với khả năng xuất bản dữ liệu lớn hơn nhiều được xây dựng cho xu hướng tương lai modular đã xuất hiện. Tuy nhiên, khi nhu cầu tăng lên, các giải pháp DA khác đã tung ra thị trường, bao gồm EigenDA, Avail và EIP 4844. Cuối cùng, các lớp DA có thể sẽ trở thành hàng hóa, nếu không muốn nói là điều này đã và đang diễn ra với các giải pháp đang phát triển hoặc nhiều giải pháp khác sắp ra mắt. Vì vậy, câu hỏi tự nhiên là khả năng tồn tại lâu dài trong kinh doanh của các lớp DA là gì và làm cách nào để xây dựng một sản phẩm có giá trị xung quanh nó?

Vấn đề

Trong một thế giới có hàng nghìn hoặc hàng chục nghìn rollup tiềm năng, nhiều người vẫn đang tự hỏi tương lai của khả năng tương tác giữa các rollup có thể ra sao. Tính thanh khoản bị phân mảnh và trải nghiệm người dùng bị phân mảnh do thiếu khả năng tương tác giữa các rollup là một rào cản đáng kể đối với người dùng hàng ngày. Khi Ethereum quyết tâm hiện thực hóa tương lai tập trung vào rollup và nhiều giao thức hơn khởi chạy rollup dành riêng cho ứng dụng, một thế giới modular phải được hỗ trợ bởi giao tiếp hiệu quả giữa các modular blockchain này.

Mấu chốt của giao tiếp giữa các rollup và khả năng phối hơp là ở việc đưa ra các giả định tin cậy mới ở mức tối thiểu. Các giao thức chuyển tin nhắn có thể được sử dụng và có thể thực thi công việc trọn vẹn nhưng thường có các vùng kiểm duyệt và đòi hỏi sự tin tưởng. Khi nói đến việc đặt hàng các giao dịch, đảm bảo thực thi chỉnh chu trên các rollup và các gói giao dịch phức tạp hơn trên các rollup, chúng đều thiếu sót.

Có một số câu hỏi phức tạp mà một “cầu nối” chung với yêu cầu tin tưởng tối thiểu phải trả lời. Ví dụ: làm cách nào rollup A biết được thứ tự chuẩn của rollup B? Việc xác minh trạng thái đa chuỗi sẽ diễn ra như thế nào mà không bị tắc nghẽn? Các rollup sẽ hiểu các sự kiện diễn ra trên các rollup khác trong hệ sinh thái như thế nào và thông điệp có thể không đồng bộ không?

Giao tiếp giữa các rollup là khả năng các chuỗi gửi tin nhắn với nhau; thường thì thông báo này là trạng thái của một chuỗi. Trạng thái của một chuỗi sau đó thường xác định thứ tự và thực hiện chính xác các giao dịch trên các chuỗi khác. Vì vậy, có hai câu hỏi chính mà một rollup cần trả lời khi nhận được thông báo (trạng thái) từ các rollup khác. Thứ tự chuẩn và thứ tự cuối cùng của quá trình rollup là gì và các lệnh thực thi có hợp lệ không? Các sản phẩm của Avail nhằm mục đích trả lời những câu hỏi này và đẩy nhanh quá trình hợp nhất web3 thông qua ba giải pháp cốt lõi: Avail DA, Avail Nexus và Avail Fusion.

Avail DA

Dựa trên các vấn đề nêu trên mà modular trong tương lai cần giải quyết, cấp cơ sở của thiết kế thống nhất phải là lớp DA cung cấp sự đồng thuận về thứ tự các giao dịch của rollup. Avail DA là một giải pháp như vậy: một lớp DA tối ưu được xây dựng bằng cách lấy mẫu tính khả dụng của dữ liệu (DAS) dựa trên bằng chứng hợp lệ. Lớp DA đóng vai trò là nguồn của sự tin cậy, sắp xếp các giao dịch và đạt được sự đồng thuận về thứ tự của các giao dịch đó.

Avail DA cung cấp một mạng lưới có thể nhập và gọi dữ liệu giao dịch. Lớp này được dành riêng để lưu trữ dữ liệu trong một khoảng thời gian vừa đủ (với validator có thể đưa ra lựa chọn của riêng họ về việc giảm tải dữ liệu) và đảm bảo tính khả dụng của nó, điều này rất quan trọng đối với các rollup để các optimistic rollup có sẵn dữ liệu giao dịch để xây dựng bằng chứng gian lận, và ZK-rollup có sẵn dữ liệu trạng thái để bất kỳ ai cũng có thể xác thực chuỗi một cách độc lập. Với dữ liệu trạng thái này, bất kỳ ai cũng có thể tái tạo trạng thái của rollup và tự xác thực chuỗi mà không cần phải dựa vào các node đầy đủ. Lớp DA đảm bảo rằng mọi node đầy đủ của rollup không cần thực hiện các giao dịch và nhờ đó có thể hoạt động hiệu quả hơn nhiều so với blockchain chính của rollup.

Avail sử dụng DAS, giống như Celestia. Tuy nhiên, không giống như Celestia, Avail có mô hình đồng thuận PoS đề cử với sự đồng thuận BABE/GRANDPA và sử dụng bằng chứng hợp lệ được tạo ra thông qua các cam kết của KZG thay vì bằng chứng gian lận để đảm bảo tính chính xác của quá trình xóa mã vô hướng (Erasure coding – EC). Cam kết của KZG là cam kết của validator rằng quá trình EC được thực hiện chính xác. Bằng chứng hợp lệ có thể được tạo ra dựa trên cam kết của KZG, sau đó có thể được sử dụng để xác minh các cam kết của DA. Những bằng chứng hợp lệ này cho phép mọi người xác minh rằng các khối được xử lý EC một cách chính xác mà không cần phải tải xuống toàn bộ blob dữ liệu. Điều này loại bỏ nhu cầu về thiểu số trung thực thông qua các đảm bảo DA về mặt thuật toán, trái ngược hoàn toàn với các lớp DA dựa trên bằng chứng gian lận.

Có bốn loại node trong Avail:

Các node đầy đủ: Các node đầy đủ tải xuống và xác minh tính chính xác của các khối nhưng không tham gia vào sự đồng thuận. Các node đầy đủ là không cần thiết nhưng sẽ chỉ chạy như một mức độ dự phòng và khả năng phục hồi bổ sung.
Các node xác thực: Các node xác thực giúp mạng đạt được sự đồng thuận và đạt được điều này bằng cách tạo các khối, quyết định đưa vào giao dịch và duy trì thứ tự giao dịch.
Light client: Light client cho phép mọi người tương tác với Avail DA mà không yêu cầu node đầy đủ cũng như không có giả định tin cậy đối với các máy ngang hàng ở xa. Điều này được thực hiện bằng cách tận dụng cơ chế DAS được thực hiện bởi light client trên mỗi khối mới được tạo.
Các node RPC: Các node RPC hiển thị API cho các tương tác từ xa, đóng vai trò là cổng để các nhà phát triển và khách hàng bên ngoài tương tác với mạng Avail.

Light client xem xét trên mạng Avail để tìm các khối cuối cùng và thực hiện DAS trên số lượng ô được xác định trước trên mỗi khối mới. Sau khi xác minh khối thành công, độ tin cậy của khối được tính cho một số ô trong ma trận, với số lượng tùy thuộc vào tỷ lệ phần trăm chắc chắn mà người dùng mong muốn đạt được.

Vòng xử lý trên Avail DA như sau:

Gửi giao dịch: Giống như hầu hết các rollup hiện có, dữ liệu cuộc gọi giao dịch được tập hợp lại và gốc trạng thái được gửi tới Avail DA, với một ID ứng dụng duy nhất biểu thị nguồn gốc rollup.
Mở rộng dữ liệu và EC: Các giao dịch được gửi tới Avail DA được xử lý thông qua EC, trong đó các khối được chia thành n khối ban đầu và mở rộng thành 2n, cho phép xây dựng lại từ n bất kỳ trong số 2n khối.
Tạo cam kết: Avail DA lấy dữ liệu dư thừa và áp dụng các cam kết đa thức KZG cho từng khối. Những cam kết này đóng vai trò là bằng chứng mật mã về tính chính xác của dữ liệu, đảm bảo rằng những gì được lưu trữ là chính xác và chống giả mạo.
Truyền trong khối: Validator nhận các khối có cam kết KZG và tạo lại các cam kết để xác minh tính chính xác của chúng và đạt được sự đồng thuận về khối.
Mạng light client: Light client sử dụng DAS để xác minh tính toàn vẹn của dữ liệu khối. Điều này đạt được bằng cách kiểm tra các đa thức KZG so với các cam kết trong tiêu đề khối cho từng ô được lấy mẫu. Điều này loại bỏ nhu cầu xây dựng lại các cam kết đầy đủ của KZG hoặc dựa vào bằng chứng gian lận.
Xác minh bằng chứng: Light client thực hiện xác minh bằng chứng thông qua bằng chứng được tạo từ ma trận dữ liệu.

Avail sử dụng hai cơ chế đồng thuận. Đầu tiên, BABE, viết tắt của Blind Missionment for Blockchain Extension, đóng vai trò là công cụ sản xuất khối. BABE hoạt động độc lập và cung cấp trạng thái cuối tương đối, nhưng trong trường hợp của Avail, được tích hợp với cơ chế cuối cùng được gọi là GRANDPA, viết tắt của Ghost-based Recursive Ancestor Deriving Prefix Agreement. Bản thân GRANDPA là một thuật toán hoàn thiện khối và do đó, phải được kết hợp với cơ chế sản xuất khối.

BABE hoạt động theo thuật toán dựa trên vị trí, với mỗi vị trí (khối) kéo dài trong 20 giây. Mỗi vị trí có một tác giả chính được chọn bởi chức năng VRF. Tuy nhiên, trong một số trường hợp, có thể không có tác giả chính. Trong những tình huống như vậy, BABE sử dụng hệ thống vòng tròn để chỉ định những người dẫn đầu.

BABE và GRANDPA được chọn làm cơ chế đồng thuận vì Avail muốn duy trì một sổ cái kết hợp. Hầu hết các chuỗi ngày nay đều chọn sự an toàn (safety) hơn là tính trung thực (liveness)của mạng, điều đó có nghĩa là mọi khối cần phải được hoàn thiện trước khi khối tiếp theo có thể được sản xuất. Tuy nhiên, trong giai đoạn phân vùng mạng hoặc nếu một số lượng lớn các node không đạt được sự đồng thuận thì bản thân chuỗi sẽ bị ảnh hưởng về mặt hoạt động. Mặt khác, chuỗi POW thường thiên về tính trung thực hơn tính hoàn thành và do đó, bất kỳ sự hoàn thành nào cũng đều mang tính xác suất. Câu hỏi liệu lớp DA nên ưu tiên sự an toàn hay tính trung thực là một chủ đề đáng thảo luận. Ví dụ: các rollup sẽ ưu tiên tính trung thực vì việc chốt các giao dịch của người dùng xuất phát từ hệ thống tạo ra khối của lớp cơ sở. Lớp cơ sở ít nhất cần đưa ra một sự đảm bảo sơ bộ về thứ tự của các giao dịch nếu không các rollup được xây dựng trên nó không thể hoạt động. Mặt khác, sự an toàn cũng rất quan trọng vì, chẳng hạn, đối với một sequencer chung, quá trình hoàn thiện xảy ra trên các rollup được phân nhóm cùng nhau và một sequencer xác định thứ tự trên các rollup, do đó không cần đảm bảo thứ tự từ lớp DA. Trong trường hợp này, lớp DA chỉ được dựa vào để đảm bảo bước hoàn thiện và đó là lúc mà sự an toàn trở nên quan trọng. Có nhiều tính năng mong muốn khác nhau của lớp DA tùy thuộc vào loại rollup nào đã được xây dựng trên nó. Ví dụ, khả năng chống kiểm duyệt đến từ lớp cơ sở và do đó tính trung thực của nó rất quan trọng. Mặt khác, tính hữu hạn đến từ sự đảm bảo an toàn của lớp cơ sở có thể được trừu tượng hóa bởi các rollup.

Trong trường hợp của Avail, GRANDPA được sử dụng làm công cụ hoàn tất và BABE được sử dụng để sản xuất khối và quan trọng là GRANDPA hoàn thiện nhiều khối cùng lúc thay vì các khối riêng lẻ. Kết quả hoàn thành đạt được thông qua các vòng bỏ phiếu liên tiếp của các node xác thực. Với thiết lập như vậy, Avail có thể mang lại lợi ích tốt nhất cho cả mặt an toàn và tính trung thực, đạt được thời gian đạt đến trạng thái cuối cùng là ~40 giây (2 khối) trong các trường hợp bình thường với sự đảm bảo về độ chính xác mạnh mẽ.

Avail sử dụng hệ thống proof-of-stake để xác định ai có thể tham gia đồng thuận. Trong các hệ thống PoS điển hình, các người ủy nhiệm phải suy nghĩ về ROI của họ khi chọn trình xác thực nào để ủy quyền và điều này thường có tác dụng tập trung vì người ta sẽ luôn chọn validator có số stake nhất vì họ sẽ đề xuất nhiều khối nhất ( tất cả những thứ khác đều bằng nhau) và qua đó nhận được nhiều phần thưởng nhất. Đối với Avail, thuật toán lựa chọn người lãnh đạo hơi khác một chút được sử dụng. Các nhà lãnh đạo sẽ được chọn theo cách tối đa hóa sự phân cấp của mạng, theo đó mọi người được đề cử có thể tham gia và chọn danh sách ưu tiên gồm tối đa 16 validator mà họ muốn phân phối phần stake của mình và thuật toán lựa chọn người lãnh đạo xem tất cả những validator được bầu trên cơ sở bình đẳng bất kể quy mô stake của họ hoặc số lượng người đề cử ủng hộ họ. Những validator có lượng stake lớn hơn và số lượng người đề cử cao hơn vẫn có xác suất được bầu cao hơn, tuy nhiên, bất kể quy mô stake, những validatorđều chia sẻ khối lượng công việc như nhau.

Có một số tính năng cốt lõi của Avail DA khiến nó nổi bật so với các đối thủ cạnh tranh. Đầu tiên là việc sử dụng bằng chứng hợp lệ thay vì bằng chứng gian lận. Khi cam kết các khối mới vào chuỗi, Avail sử dụng các cam kết KZG để người dùng không cần tin tưởng Avail rằng dữ liệu có sẵn, và người dùng có thể tự xác minh dữ liệu đó. Với bằng chứng hợp lệ, việc chứng minh và xác minh tính sẵn có của dữ liệu theo cách có thể mở rộng sẽ hiệu quả về mặt tính toán. Sau khi Avail hoàn tất trong thời gian khoảng 40 giây, nhanh hơn nhiều so với lớp cơ sở Ethereum, điều này có nghĩa là validatorđã tạo ra cam kết KZG và đưa chúng vào tiêu đề khối, với các khối đó được hoàn thiện. Từ đó, các light client có thể thực hiện lấy mẫu tính khả dụng của dữ liệu và xác minh các mẫu dựa trên tiêu đề.

Trong các thiết kế chống gian lận, các cam kết trong tiêu đề không đủ để xác minh rằng các mẫu là chính xác và khối được xây dựng chính xác (EC được thực hiện chính xác). Trong cấu trúc như vậy, các light client sẽ lấy mẫu và phải chờ xem liệu có bất kỳ node đầy đủ nào cảnh báo về một khối không hợp lệ hay không, tương tự như các giai đoạn thử thách bằng chứng gian lận trong các optimistic rollup. Điều này có nghĩa là cần phải trôi qua một khoảng thời gian thử thách nhất định trước khi light client có thể xác minh các đảm bảo của DA. Trong thiết kế dựa trên bằng chứng hợp lệ của Avail, các cam kết của KZG giúp xác minh rằng các mẫu là chính xác và khối được xây dựng chính xác, điều đó có nghĩa là các đảm bảo của DA có thể được xác minh nhanh hơn và ngắn gọn hơn nhiều so với các bằng chứng gian lận khác dựa trên lớp DA. Điều này rất quan trọng vì các giải pháp về khả năng tương tác và an toàn rollup thường phụ thuộc vào các đảm bảo DA như vậy và các đảm bảo DA này càng được xác minh kịp thời thì các giải pháp về khả năng tương tác khả thi hơn và đảm bảo an toàn rollup chắc chắn hơn.

Nếu muốn xác định trạng thái của rollup, người ta cần có hai sự đảm bảo. Đầu tiên là sự đảm bảo về tính đúng đắn của việc thực thi và thứ hai là sự đảm bảo của DA. Trong trường hợp rollup ZK được xây dựng dựa trên lớp DA dựa trên bằng chứng gian lận, thì khi cần xác minh tính chính xác của việc thực thi, người ta có thể dựa vào bằng chứng hợp lệ hoặc bằng chứng ZK. Tuy nhiên, khi nói đến việc xác minh sự đảm bảo của DA, trong lớp DA dựa trên bằng chứng gian lận, sẽ có một khoảng thời gian thử thách trong đó quá trình rollup sẽ phải chờ và do đó, rollup ZK sẽ khó có thể sử dụng cơ sở dữ liệu bằng chứng gian lận dựa vào lớp DA do quyết định thiết kế đã được đưa ra để tránh các bằng chứng gian lận/thời gian thử thách. Các cam kết của KZG và EC cho phép Avail tránh được các bằng chứng gian lận.

EC, cụ thể là trong bối cảnh của Avail DA, là một quá trình trong đó dữ liệu được gửi tới Avail được sao chép và xuất bản trong mỗi khối. Tất cả các node đầy đủ của Avail đều lưu trữ toàn bộ các khối được EC, do đó, đối với một ứng dụng light client không tải xuống khối nhưng muốn biết rằng dữ liệu có sẵn thì >50% khối sẽ không có sẵn cho dữ liệu phải bị đàn áp. Nếu có sẵn >50% khối, ứng dụng khách nhẹ có thể sử dụng dữ liệu được mã hóa xóa (trùng lặp) để xây dựng lại dữ liệu bị thiếu. Điều này ngăn tác nhân độc hại có thể ẩn bất kỳ phần nào của khối có kích thước dư thừa (50%) và khiến việc lấy mẫu ngẫu nhiên từ các light client có nhiều khả năng phát hiện ra các lỗ hổng trong dữ liệu. Một cách hiệu quả, EC sẽ bổ sung thêm phần dư thừa cho DA.

Các light client cũng đóng một vai trò quan trọng trong Avail DA. Lợi ích của light client là chúng có thể chạy ở hầu hết mọi nơi với yêu cầu phần cứng cực kỳ tối thiểu, chẳng hạn như trên điện thoại/trong ví/thông qua tiện ích mở rộng trình duyệt và do đó, giảm đáng kể rào cản trong việc xác minh tính khả dụng của dữ liệu. Điều này đạt được thông qua việc lấy mẫu tính khả dụng của dữ liệu được thực hiện bởi các light client trên mỗi khối mới được tạo. Với đủ số lượng light client và mẫu được lấy, người ta có thể chắc chắn rằng dữ liệu trong khối có sẵn đầy đủ. Số lượng light client càng lớn thì khả năng đảm bảo tính khả dụng của dữ liệu càng mạnh. Điều này cho phép các lớp thực thi dễ dàng xác minh tính khả dụng của dữ liệu một cách hiệu quả, thông qua các light client đơn giản thực hiện DAS trên dữ liệu được EC. Không giống như các light client thông thường dựa vào giả định rằng trạng thái của chuỗi được biểu thị bằng tiêu đề khối là hợp lệ, các lớp DA có DAS không đưa ra giả định đa số trung thực về tính hợp lệ của trạng thái vì chúng cũng có thể xác minh phần thân của khối thông qua việc lấy mẫu DA.

Avail DA sẽ có mạng P2P bao gồm nhiều light client mà người dùng có thể lấy mẫu từ đó. Điều này có thể thực hiện được khi các light client đem về một số dữ liệu ban đầu từ các khối cuối cùng trong khi tiến hành DAS, nó sẽ sử dụng dữ liệu đó để điền đồng thời vào bảng băm phân tán thông qua triển khai Kademlia. Vì mỗi light client lưu trữ một đoạn dữ liệu nhỏ nên với đủ light client, toàn bộ khối có thể được lưu trữ trong mạng light client P2P. Các light client không chỉ xác minh các đảm bảo của DA mà còn có thể tự đóng góp vào tính khả dụng của dữ liệu. Thay vì chỉ lấy mẫu dữ liệu, các light client cũng sẽ giữ các mẫu có sẵn trên mạng P2P này. Với đủ số lượng light client, mạng lưới đảm bảo tỉ lệ cao cao tính khả dụng của dữ liệu vì có một số lượng lớn các khối lấy mẫu light client. Điều này sẽ khiến Avail trở thành lớp DA duy nhất có thể lấy mẫu từ mạng P2P light client thay vì dựa vào các node đầy đủ. Về mặt lý thuyết, với đủ số lượng light client, mạng P2P phía trên sẽ có tất cả các thành phần trong một khối và do đó người ta có thể truy vấn toàn bộ khối mà không cần dựa vào RPC. Thật ấn tượng, chỉ cần 50% khối trong bảng băm phân tán của light client để có thể thực hiện được điều này nhờ vào EC, trong đó chỉ cần có 50% mỗi cột của ma trận để toàn bộ ma trận dữ liệu có thể được xây dựng lại.

Avail Nexus

Đối với các rollup, lớp DA cung cấp sự đồng thuận về thứ tự các giao dịch của nó. Đây là chìa khóa mở khóa cho Avail Nexus, một trung tâm xác minh hợp nhất các rollup sử dụng Avail DA làm nguồn tin cậy. Điều này có thể thực hiện được vì các rollup sử dụng cùng một lớp DA có tính bảo mật thống nhất và thứ tự của tất cả các giao dịch được đăng lên cùng một lớp DA được xác định bởi cùng một cơ chế đồng thuận và do đó, ngay cả với rủi ro tổ chức lại ở lớp DA, tất cả thứ tự giao dịch rollup sẽ bị ảnh hưởng như nhau bởi việc tổ chức lại.

Nếu bạn còn nhớ, hai câu hỏi mà chúng ta phải trả lời về khả năng tương tác giữa các rollup là “Thứ tự chuẩn và cuối cùng của quá trình rollup là gì và các lệnh thực thi có hợp lệ không?” Avail DA giải quyết vấn đề về thứ tự chuẩn và thứ tự cuối cùng của quá trình rollup. Để chứng minh liệu việc thực hiện giao dịch có hợp lệ hay không là một vấn đề phức tạp hơn nhiều. Khi ngày càng có nhiều rollup tìm cách kết nối với nhau, trong thế giới phân mảnh hiện tại, người ta sẽ yêu cầu một phiên bản cầu nối duy nhất giữa mỗi rollup gốc và rollup đích, dẫn đến vô sống trường hợp cầu nối cho N số rollup . Ngoài ra, mỗi rollup có thể có các Hàm chuyển đổi trạng thái duy nhất và việc xác thực thực thi có thể phụ thuộc vào nhiều hệ thống chứng minh khác nhau. Về lý thuyết, các rollup không cần phải biết về chức năng chuyển đổi trạng thái của các rollup khác mà chỉ cần xác minh tính hợp lệ thực thi và một số đầu ra trạng thái có liên quan.

Nexus Avail hoạt động như một trung tâm xác minh, là một rollup phối hợp ZK tùy chỉnh nằm giữa các rollup khác nhau và lớp DA của Avail, với vai trò là rollup và xác minh bằng chứng, cùng với việc lựa chọn trình tự sắp xếp/điều hành một cuộc đấu giá vị trí. Thay vì cần xác minh bằng chứng hợp lệ của các rollup riêng lẻ, mỗi bên liên quan giờ đây chỉ phải xác minh một bằng chứng rollup duy nhất để xác minh bằng chứng hợp lệ của tất cả các rollup gửi bằng chứng hợp lệ của họ cho Avail Nexus. Avail Nexus gửi bằng chứng rollup ngắn gọn cho cả Ethereum và Avail DA để xác minh, với một modular tùy chỉnh trong Avail DA để xác minh bằng chứng rollup. Bằng chứng được đăng lên Ethereum thông qua cầu Vector, đây là bằng chứng dựa trên ZKP về cầu nối đồng thuận từ Avail đến Ethereum. Ethereum vẫn có thể xác minh bằng chứng thực thi rollup và không phải dựa vào trình xác thực Avail cho bất kỳ điều gì khác ngoài DA và các đảm bảo lệnh liên quan, không khác gì các giả định tin cậy cho quy trình xác thực tiêu chuẩn. Việc sử dụng một trung tâm phối hợp chuỗi chéo chung giữa các rollup cùng đăng dữ liệu lên một lớp DA có nghĩa là không có giả định tin cậy mới nào, vì tất cả các rollup đều phụ thuộc vào cùng một lớp DA để có được sự đồng thuận và an ninh kinh tế được liên kết với nó. Do đó, với bằng chứng ngắn gọn duy nhất này, mọi rollup được kết nối đều có thể xác minh trạng thái của bất kỳ rollup nào khác. Avail Nexus hoạt động như lớp hợp nhất cho các rollup và Ethereum sử dụng rollup ZK tùy chỉnh này làm nguồn thông tin xác thực cho các đảm bảo của nó. Điều này cho phép các rollup chuyển sang Ethereum, nhưng giảm đáng kể chi phí thực hiện từ việc xác minh một bằng chứng cho mỗi lần xác thực đến xác minh một bằng chứng duy nhất cho tất cả các rollup tham gia Avail Nexus.

Một điểm thú vị của Avail Nexus là về mặt lý thuyết, ngay cả các optimistic rollup cũng có thể tham gia, điều này không xảy ra đối với các lớp rollup tương tự khác. Các optimistic rollup có thể gửi biên nhận và gốc trạng thái của họ tới Avail Nexus và thay vì sử dụng bằng chứng gian lận thông thường, bằng chứng gian lận ZK được sử dụng để cho phép thời gian thử thách ngắn hơn nhiều. Tuy nhiên, trọng tâm chính vẫn sẽ là các rollup ZK tại thời điểm hiện tại, với nhiều thử nghiệm hơn cần thiết, chẳng hạn như thêm những thứ như bằng chứng đồng thuận/bằng chứng lưu trữ để hỗ trợ optimistic rollup.

Với Avail Nexus, các rollup được kết nối cuối cùng sẽ có quyền truy cập tối thiểu tin cậy vào các rollup khác thông qua cơ chế tổng hợp bằng chứng và đảm bảo đặt lệnh. Tất cả các rollup được kết nối sẽ tồn tại và hoạt động tương tác như thể chúng nằm trong cùng một mạng, tạo ra trải nghiệm người dùng dễ dàng hơn nhiều bằng sự phân mảnh thanh khoản tối thiểu và không đưa ra các giả định tin cậy mới, dù là để phát hành tài sản hoặc đảm bảo rollup. Người ta có thể hình dung một thế giới với hàng trăm rollup dành riêng cho ứng dụng, mỗi rollup xuất sắc trong một chức năng hoặc loại giao thức cụ thể và bất cứ khi nào người dùng muốn thực hiện một loạt hành động, ví hoặc một số dịch vụ khác chỉ cần thực hiện gọi tin nhắn không đồng bộ để sử dụng sản phẩm/dịch vụ của bất kỳ rollup nào vượt trội ở chức năng đó. Thế giới như vậy chỉ có thể thành hiện thực trong một tương lai tập trung vào mục đích, nơi người dùng có thể bày tỏ ý định làm điều gì đó và từ đó Avail Nexus cung cấp nền tảng cho một trình giải quyết thực hiện nhiệm vụ, gộp một chuỗi các giao dịch trên nhiều rollup lại với nhau và sau đó cung cấp đảm bảo cho gói nói trên.

Avail Fusion

Cuối cùng, tính bảo mật của Avail Nexus bắt nguồn từ lớp DA của Avail và một trong những lợi ích của việc xây dựng rollup là khả năng kế thừa tính bảo mật từ lớp cơ sở thay vì phải khởi động bộ validator của riêng bạn và hệ thống bảo mật kinh tế liên quan. Để thực hiện đề xuất giá trị này và xây dựng lớp cơ sở với mức độ bảo mật kinh tế lớn, Avail đang phát triển Avail Fusion, cho phép sử dụng tài sản gốc từ các blockchain lớn được thiết lập để bảo mật lớp cơ sở Avail. Các tài sản đã nói bao gồm các token như BTC, ETH và SOL, cùng với token sắp ra mắt của Avail, trong khi một % nhỏ trong tổng số stake sẽ được dành cho các token rolluo mới nổi. Một % nhỏ trong tổng số stake đang được dành riêng cho việc xây dựng token rollup mới nổi trên Avail, vì các nhà phát triển rolluo có thể muốn khả năng tương tác đi kèm với Avail Nexus và điều này thúc đẩy sự liên kết kinh tế nhưng cũng cho phép token rollup gốc của họ tích lũy giá trị dưới một số hình thức, ví dụ: phí sequencer/phí tạo bằng chứng mà giờ đây họ có thể nhận dưới dạng token rollup gốc giúp bảo mật một phần Avail Fusion.

Avail Fusion là sự kết hợp của các ý tưởng hiện có từ các giao thức như EigenLayer, Babylon Chain và Osmosis, nơi hiện thực hóa các ý tưởng staking và vay mượn tính bảo mật kinh tế từ các tài sản khác.

Có hai cách tiếp cận tiềm năng mà Avail Fusion có thể thực hiện. Đầu tiên là staking trên blockchain Avail. Tính năng này sẽ hỗ trợ nhiều token ngoài mạng thông qua pallet tài sản trong node Avail. Thứ hai là cơ chế staking để chuyển đổi tài sản, sẽ cho phép chuyển đổi tài sản ngoài mạng thành token gốc của Avail, khi vẫn duy trì tỷ giá chuyển đổi tại thời điểm chuyển đổi. Cách tiếp cận nào sẽ được chọn vẫn chưa được xác định và sẽ chỉ được thực hiện sau khi xem xét các yếu tố khác nhau như rủi ro kinh tế, hạn chế lạm phát, v.v.

Avail Token

Token Avail sẽ được stake để bảo mật cả ba sản phẩm của Avail, Avail DA, Avail Nexus và Avail Fusion. Phí giao dịch và phí cầu nối sẽ được thanh toán bằng token gốc của Avail. Do đó, bất kỳ rollup nào muốn tăng cường khả năng tương tác đi kèm với Avail Nexus, bảo mật được chia sẻ bắt nguồn từ Avail Fusion và sự đảm bảo của Avail DA, tất cả đều làm tăng giá trị và tiện ích của token gốc của Avail. Hệ sinh thái rollup càng lớn thì nhu cầu sở hữu token gốc của Avail càng lớn vì người ta cần stake nó để trở thành một phần của nhóm sequencer và nhóm tổng hợp bằng chứng, với lượng lớn giá trị thu được dự kiến sẽ xảy ra ở cả hai nhóm trong cả hai quá quá trình.

Cách token AVAIL: vận hành trong hệ sinh thái Avail

Sự tương thích

Người ta có thể dễ dàng nghĩ rằng các lớp DA sẽ trở thành hàng hóa. Có sự khác biệt về kiến trúc kỹ thuật, nhưng có khả năng là hầu hết các rollup sẽ chọn tham gia vào các lớp DA với chi phí thấp nhất so với các đảm bảo về mật mã/kinh tế tiền mã hóa nếu chỉ xem xét từ khía cạnh dịch vụ DA đem lại. Chi phí DA sẽ không chỉ được “trợ cấp” mà còn có khả năng là cuộc đua về 0. Các mô hình doanh thu lớp DA hiện tại có thể không bền vững khi hoạt động độc lập, như ta thấy lớp DA như Celestia chỉ tạo ra doanh thu 11.558 đô la cho đến nay.

Do đó, các lớp DA có thể sẽ phải, a.) tạo ra sự khác biệt thông qua việc cung cấp các đảm bảo khác nhau và b.) xây dựng hệ sinh thái của riêng mình. Tuy nhiên, một hệ sinh thái chỉ tốt khi có khả năng tương tác giữa tất cả các chuỗi khác nhau trong hệ sinh thái. Do đó, lý do để Avail xây dựng bộ ba lớp DA, giải pháp khả năng tương tác dưới dạng Avail Nexus và giải pháp bảo mật chung dưới dạng Avail Fusion.

Có các đối thủ cạnh tranh trong mọi lĩnh vực mà Avail đang phát triển, cụ thể là Celestia/EigenDA trong lớp DA, các giải pháp như lớp Agg của Polygon hoặc các sequencer chung trong lớp tương tác và các sản phẩm như EigenLayer/Babylon để bảo mật chung. Một thành phần quan trọng của tiền mã hóa đó là trong thời gian gần đây đã giảm thiểu các giả định về độ tin cậy bổ sung khi giới thiệu một lớp cơ sở hạ tầng mới, cả từ quan điểm mật mã lẫn quan điểm kinh tế tiền mã hóa. Bằng cách tích hợp theo chiều dọc lớp DA, lớp tương tác và bảo mật được chia sẻ, với cùng các giả định về độ tin cậy về kinh tế mật mã và các giả định về độ tin cậy về mật mã mới ở mức tối thiểu, các lựa chọn thiết kế của Avail có thể chứng tỏ là hình thái cuối khả thi cho các lớp DA nhờ sự phối hợp tự nhiên giữa các lớp DA và giải pháp tương tác. Ví dụ: EigenLayer + EigenDA đã là một hình thức tích hợp dọc và người ta không nên ngạc nhiên nếu AVS có khả năng tương tác xuyên rollup ra mắt dựa trên bảo mật chia sẻ EigenLayer nhờ sự phối hợp tự nhiên này.

Rủi ro

Có một số rủi ro đối với sự thành công của Avail trong tương lai xa phía trước. Ví dụ: có thể tiền mã hóa tồn tại trong một thế giới có nhiều rollup lớn có hệ sinh thái được thiết lập riêng với giải pháp tương tác nội bộ hoặc nhiều rollup dành riêng cho ứng dụng không quan tâm đến khả năng tương tác với nhau. Trong cả hai trường hợp, các rollup nói trên sẽ không yêu cầu hệ thống tương tác “bên ngoài”, điều này sẽ làm giảm vị thế của Avail Nexus. Tuy nhiên, điều này khó có thể xảy ra do số lượng lớn các rollup dành riêng cho ứng dụng đang được tung ra và những vấn đề đau đầu mà người dùng gặp phải ngày nay với sự phân mảnh cực độ.

Ngoài ra, có rất nhiều giải pháp DA sẽ sớm ra mắt, bao gồm Celestia đã đi vào hoạt động và các giải pháp khác như EigenDA mới đi vào hoạt động gần đây. Hơn nữa, Ethereum đã triển khai EIP-4844 đã giới thiệu các blobs như một tùy chọn xuất bản dữ liệu. Do sự cạnh tranh khốc liệt giữa các lớp DA, các rollup có thể ít nhạy cảm hơn về giá đối với chi phí xuất bản dữ liệu và chúng tôi có thể đã đạt đến điểm đó ở một mức độ nào đó, hoàn toàn có khả năng các rollup đó sẽ chọn tham gia vào các giải pháp DA có sẵn đã được “thử nghiệm thực chiến” để tận hưởng lợi thế của người đi đầu, chọn “liên kết” với một số hệ sinh thái khác hoặc chọn sử dụng Ethereum khi danksharding đã hoàn thành. Chi phí xuất bản dữ liệu và khả năng xuất bản dữ liệu sẽ không phải là yếu tố khác biệt lớn đối với hầu hết các trường hợp sử dụng.

Đối với Avail Fusion, dự án cung cấp bảo mật được chia sẻ thông qua nhiều token blue-chip và token AVAIL, có một số rủi ro tiềm ẩn. Đầu tiên là các nhà phát triển chỉ muốn bảo mật được chia sẻ từ một tài sản đơn lẻ như ETH hoặc BTC, thay vì dựa vào nhiều token để đảm bảo kinh tế tiền mã hóa. Tương tự, nếu Avail không thể khởi động đủ mức bảo mật do thiếu tài sản staking hỗ trợ lớp DA thông qua Avail Fusion thì các nhà phát triển có thể xem điều đó theo hướng tiêu cực và chọn sử dụng các giải pháp DA khác với mức độ bảo mật kinh tế hơn. Hơn nữa, các sản phẩm restaking/bảo mật chung khác có thể có một hệ sinh thái lớn gồm các giải pháp phần mềm trung gian/giải pháp giá trị gia tăng, được phục vụ đặc biệt cho các rollup. Ví dụ: EigenLayer có thể có AVS hỗ trợ quá trình xếp giao dịch phi tập trung, lớp DA, hoàn tất giao dịch nhanh (fast finality), mạng keeper, mạng watcher, v.v. Điều này có thể làm tăng giá trị của việc “liên kết” với các hệ sinh thái đó, mặc dù không có gì ngăn cản các rollup dựa trên Avail DA sử dụng một số AVS đó.

Tổng kết

Khả năng tương tác là ưu tiên hàng đầu và là trung tâm của nhiều nhà xây dựng, nhà tư tưởng cũng như người dùng. Tiền mã hóa vẫn bị phân mảnh như trước đây và nếu có lúc nào đó để bắt đầu suy nghĩ về tương lai của khả năng tương tác sẽ như thế nào thì đó chính là lúc này. Nếu không có lớp DA chung, các chuỗi chỉ có thể tương tác với các giả định tin cậy bổ sung, chịu thêm rủi ro về các đảm bảo lệnh giao dịch và tính hoàn thiện của các chuỗi khác, cùng với những lo ngại về khả năng thực thi.

Việc sử dụng lớp DA chung với một số hình thức rollup tông hợp bằng chứng hợp lệ rất có thể là trạng thái cuối cùng của tương lai modular, khi một số hệ sinh thái hiện tại đang khám phá các thiết kế tương tự. Do đó, việc sử dụng lớp DA chung và cơ chế tương tác với cùng các giả định tin cậy và hỗ trợ kinh tế tiền mã hóa là sự phát triển hợp lý vì lớp DA dùng chung là cần thiết để tạo điều kiện thuận lợi cho khả năng tương tác ngay từ đầu. Avail DA, Avail Nexus và Avail Fusion kết hợp với nhau sẵn sàng trở thành ngọn cờ tiên phong của thiết kế như vậy và có thể mở đường cho một tương lai có thể tương tác, chi phí thấp và có thể mở rộng cho các blockchain.