Mạng thử nghiệm sẵn có hiện đang hoạt động. Khi người dùng bắt đầu tích hợp Avail vào thiết kế chuỗi của họ, một câu hỏi thường được đặt ra là: Avail có thể xử lý bao nhiêu giao dịch? Đây là bài viết cuối cùng trong loạt bài về khả năng mở rộng và sẽ thảo luận về hiệu suất hiện tại cũng như ngắn hạn của Avail và khả năng mở rộng lâu dài. Bạn có thể đọc phần một ở đây và phần hai ở đây.

Mô hình bên dưới mô tả một kiến ​​trúc trong đó các hành động đề xuất và xây dựng các khối (quyết định giao dịch/khối dữ liệu nào được đưa vào khối) được phân tách và thực hiện bởi các tác nhân khác nhau.

Bằng cách tạo thực thể trình tạo khối mới này, công việc tính toán cần thiết để tạo ra các cam kết hàng và tạo bằng chứng ô có thể được chia sẻ giữa những người tham gia khác nhau.

Chức năng cốt lõi của Avail là nhận dữ liệu và xuất dữ liệu theo yêu cầu. Hãy nghĩ về nó giống như một API. Avail cho phép mọi người lấy mẫu tính sẵn có của dữ liệu.

Trước khi nêu bật những điểm chúng tôi có thể cải thiện, trước tiên chúng tôi nêu chi tiết các yêu cầu của Avail đối với người đề xuất khối và trình xác thực/nút đầy đủ ở trạng thái hiện tại.

1. Nhà sản xuất khối tạo ra thân khối

• Thu thập giao dịch (gửi dữ liệu)

• Sắp xếp các giao dịch này vào ma trận dữ liệu Avail, trở thành phần thân khối

2. Nhà sản xuất khối tạo tiêu đề khối

• Tạo lời hứa cho mỗi hàng của ma trận

• Mở rộng các cam kết này bằng cách sử dụng phép nội suy đa thức (các cam kết được tạo và mở rộng trở thành tiêu đề khối)

3. Nhà sản xuất khối truyền bá khối (phần thân + tiêu đề)

4. Trình xác thực và các nút đầy đủ nhận khối

5. Trình xác thực và nút đầy đủ giải mã, xây dựng lại và xác minh các khối

• Xây dựng lại ma trận dữ liệu

• xây dựng lại các cam kết

• cam kết mở rộng

• Xác minh rằng tất cả dữ liệu họ nhận được đều khớp với lời hứa mà họ đã tạo

Bước thứ năm, yêu cầu nút đầy đủ tạo lại tiêu đề khối, là không cần thiết trong hệ thống như Avail.

Các nút đầy đủ hiện thực hiện việc này vì Avail kế thừa kiến ​​trúc của các chuỗi khối truyền thống, vốn yêu cầu người xác thực xác nhận rằng các hoạt động thực thi được hoàn thành chính xác. Avail không xử lý các hoạt động thực thi. Người đề xuất chặn, người xác thực và ứng dụng khách nhẹ chỉ quan tâm đến tính khả dụng của dữ liệu. Điều này có nghĩa là tất cả những người tham gia mạng Avail có thể chọn sử dụng lấy mẫu tính khả dụng của dữ liệu để xác nhận tính khả dụng của dữ liệu một cách đáng tin cậy.

Vì trình xác thực và nút đầy đủ có thể kiểm tra tính khả dụng của dữ liệu thông qua việc lấy mẫu nên chúng không cần phải xây dựng lại toàn bộ khối để đảm bảo tính bảo mật của mạng.

Người xác minh không cần phải làm lại mọi thứ mà nhà sản xuất đã làm để kiểm tra xem mọi thứ có đúng hay không. Thay vào đó, chúng có thể được kiểm tra bằng cách lấy mẫu một lượng nhỏ. Giống như với các máy khách nhẹ, khi đạt được sự đảm bảo về mặt thống kê về tính khả dụng của dữ liệu (sau 8 - 30 mẫu), người xác thực có thể thêm khối vào chuỗi. Vì Avail không xử lý việc thực thi dữ liệu nên thao tác này có thể được thực hiện một cách an toàn.

Việc lấy mẫu dữ liệu cung cấp cho người xác thực một giải pháp thay thế nhanh hơn nhiều cho quy trình xác minh 1:1 rườm rà. Điều kỳ diệu của Avail là bằng cách chỉ sử dụng các tiêu đề khối, bất kỳ ai (trong trường hợp này là người xác nhận) đều có thể đạt được sự đồng thuận rằng họ đang đi theo đúng chuỗi.

Nếu làm được điều này, chúng ta có thể thay thế toàn bộ bước xây dựng lại tiêu đề khối bằng một vài mẫu.

Bài viết này sẽ tìm hiểu sự thay đổi trong yêu cầu của chúng tôi đối với trình xác thực cũng như một số cải tiến khác. Chúng tôi sẽ mô tả một hệ thống cải tiến trong đó những người đề xuất khối (vẫn) tạo và truyền bá các khối, nhưng tất cả những người tham gia mạng khác đều tương tác với mạng thông qua lấy mẫu dữ liệu sẵn có. Sau đó, chúng tôi sẽ giới thiệu một hệ thống khác tách biệt việc xây dựng khối và đề xuất khối, được vận hành bởi hai người tham gia mạng khác nhau.

Điều quan trọng cần lưu ý là những thay đổi này tương đối tiên tiến và vẫn đang được nghiên cứu tích cực.

Đối với Avail, một mô hình hiệu quả hơn là dành cho một nút duy nhất xây dựng và truyền bá các cam kết tới mạng. Sau đó, tất cả những người tham gia khác sẽ tạo và xác minh bằng chứng.

Đây là lần đầu tiên chúng tôi cho phép không chỉ các khách hàng hạng nhẹ mà còn bất kỳ bộ phận nào trong chuỗi thực hiện việc này. Chúng tôi cho phép người xác thực lấy mẫu theo cách tương tự như các ứng dụng khách nhẹ.

Trong mô hình này, một trình xác thực duy nhất đề xuất một khối, tạo các cam kết cho tất cả các hàng của ma trận dữ liệu và sau đó chỉ đề xuất tiêu đề khối.

• Bước 1: Người đề xuất chỉ truyền bá thông tin tiêu đề khối.

• Bước 2: Vì người xác thực chỉ nhận thông tin tiêu đề nên họ không thể giải mã hoặc xây dựng lại khối. Nhưng vì họ có thể lấy mẫu tính khả dụng của dữ liệu nên họ không cần phải làm vậy.

Trong trường hợp này, các trình xác thực khác hoạt động giống như các ứng dụng khách nhẹ.

Những người xác thực khác này sẽ sử dụng các lời hứa để lấy mẫu tính khả dụng của dữ liệu và chỉ chấp nhận các khối khi đáp ứng được đảm bảo về tính khả dụng.

Trong thế giới này, tất cả các nút sẽ chạy như những máy khách nhẹ. Người xác thực có thể tránh sử dụng nội dung khối để tạo lại các cam kết nhằm đảm bảo tính toán chính xác của người đề xuất khối.

Việc tạo ra các cam kết cho việc tính toán bằng chứng là không cần thiết khi người xác minh có thể chỉ cần dựa vào việc xác minh bằng chứng.

Vì chúng tôi không yêu cầu các nút đầy đủ xác minh việc thực thi các khối hợp lệ (Avail không thực hiện thực thi!), nên các nút đầy đủ có thể chắc chắn rằng chúng đang tuân theo đúng chuỗi chỉ dựa trên thông tin tiêu đề. Chúng tôi chỉ cần bằng chứng về tính khả dụng và thông tin tiêu đề (kết hợp với một số lượng nhỏ mẫu ngẫu nhiên) có thể cung cấp điều này. Điều này cho phép chúng tôi giảm số lượng tính toán cần thiết để trở thành người xác thực.

Điều này có thêm lợi ích là có khả năng giảm thời gian liên lạc.

Độ phức tạp

Chúng tôi do dự trong việc hoàn thành mô hình này trong thời gian ngắn vì nó đòi hỏi phải tách khỏi cấu trúc cơ bản của Chất nền. Chúng tôi cần loại bỏ gốc bên ngoài, điều này sẽ phá vỡ mọi quyền truy cập vào các công cụ Substrate, mặc dù đây là một cải tiến mà chúng tôi đang tích cực khám phá.

Một mô hình khác mượn từ mô hình phân mảnh blob trong EIP-4844.https://eips.ethereum.org/EIPS/eip-4844?ref=blog.availproject.org

Hãy tưởng tượng hệ thống này:

1. Mỗi hàng của ma trận dữ liệu khối được xây dựng bởi một trình tạo khác nhau và bao gồm cam kết đa thức liên quan của hàng.

• Người xây dựng chia sẻ hàng của họ với mạng p2p và chuyển lời hứa cho người đề xuất.

2. Tạo tiêu đề: Một người đề xuất khối duy nhất thu thập các cam kết này.

• Người đề xuất lấy mẫu từ các nhà xây dựng (và mạng p2p) để xác nhận rằng một cam kết nhất định có thể tạo ra bằng chứng mở hợp lệ trước khi xóa cam kết được mã hóa. Sự kết hợp giữa lời hứa ban đầu + lời hứa mở rộng này trở thành tiêu đề.

3. Người đề xuất chia sẻ tiêu đề này với người xác thực.

4. Người đề xuất và người xác nhận thực hiện lấy mẫu tính khả dụng của dữ liệu bằng cách lấy mẫu các đơn vị ngẫu nhiên từ mạng p2p (hoặc người xây dựng) và xác nhận rằng dữ liệu tạo ra bằng chứng mở hợp lệ.

5. Sau khi trình xác thực đạt được sự đảm bảo về mặt thống kê về tính khả dụng, tiêu đề khối sẽ được thêm vào chuỗi.

Người đề xuất chặn không cần phải làm nhiều việc vì có nhiều người tham gia đưa ra cam kết.

Mô hình người đề xuất lười biếng có một người đề xuất duy nhất cho một khối. Sau đó, những người tham gia có thể được phân chia theo cách tương tự như cách phân chia người đề xuất-người xây dựng được mô tả ở trên.

Có thể có nhiều người xây dựng tạo ra các phần nhỏ của một khối. Tất cả đều gửi các khối này đến một thực thể (người đề xuất), thực thể này lấy mẫu ngẫu nhiên từng phần để xây dựng tiêu đề mà nó đề xuất.

Phần thân khối được xây dựng bằng cách sử dụng các cấu trúc logic.

một ví dụ

Điều làm cho mô hình người đề xuất lười biếng trở nên khác biệt là người xây dựng khối và người đề xuất khối là những thực thể riêng biệt.

Giả sử có bốn trình tạo khối, mỗi trình tạo có một hàng ma trận dữ liệu. Mỗi người xây dựng tạo ra một lời hứa bằng cách sử dụng dòng này.

Sau đó, mỗi người xây dựng sẽ gửi các hàng và cam kết xây dựng của mình tới một người đề xuất được chỉ định, người này sẽ lấy mẫu dữ liệu từ nội dung khối để xác nhận cam kết đã cho. Sau đó, người đề xuất sẽ nội suy các cam kết một cách đa thức để họ không chỉ có bốn trong số các cam kết được xây dựng ban đầu mà còn có cả tám. Ma trận dữ liệu hiện đã được mã hóa xóa và mở rộng.

Tám dòng và tám lời hứa này được xác nhận bởi cùng một người đề xuất.

Khi nhìn vào toàn bộ ma trận, chúng ta có thể thấy một nửa số hàng được xây dựng bởi những người đề xuất (được mã hóa bằng cách xóa) và nửa còn lại được cung cấp cho họ.

Sau đó, nhà sản xuất đề xuất một tiêu đề khối và mọi người đều chấp nhận nó. Điều này dẫn đến các khối trông giống hệt với các khối hiện đang được mạng thử nghiệm Avail tạo ra, mặc dù chúng được xây dựng hiệu quả hơn.

Mô hình đề xuất lười biếng của Avail hiệu quả hơn nhưng cũng khá phức tạp. Mặc dù có những cơ hội khác dễ dàng hơn để tối ưu hóa toàn bộ hệ thống nhưng nhóm Avail rất hào hứng khám phá việc triển khai mô hình này.

So sánh các giao dịch blockchain truyền thống với mô hình người đề xuất lười biếng

Mô hình người đề xuất lười biếng không khác mấy so với cách xử lý các giao dịch blockchain riêng lẻ trên các chuỗi khối không có Avail ngày nay.

Ngày nay, khi bất kỳ ai thực hiện giao dịch trên hầu hết mọi chuỗi, họ sẽ gửi thông báo về giao dịch này đến tất cả các nút. Chẳng bao lâu nữa, mỗi nút sẽ có giao dịch này trong mempool của nó.

Vậy các nhà sản xuất khối làm gì?

Các nhà sản xuất khối lấy các giao dịch từ mempool của họ, tổng hợp chúng lại với nhau và tạo ra một khối. Đây là vai trò điển hình của một nhà sản xuất khối.

Trong Avail, các khối dữ liệu và các cam kết của chúng được xử lý tương tự như các giao dịch riêng lẻ. Các khối dữ liệu + kết hợp cam kết này được truyền bá trên hệ thống giống như các giao dịch riêng lẻ được gửi trên chuỗi truyền thống.

Chẳng bao lâu nữa, mọi người sẽ có cam kết đối với những khối dữ liệu này. Với những cam kết này, những người đề xuất có thể bắt đầu lấy mẫu ngẫu nhiên để đảm bảo tính sẵn có của dữ liệu. Với đủ độ tin cậy lấy mẫu, nút sẽ mở rộng các cam kết này, chấp nhận dữ liệu trong phần nội dung và xây dựng tiêu đề khối - từ đó tạo ra khối tiếp theo.

Phần kết luận

Những đề xuất kiến ​​trúc được đề xuất cho Avail này nhằm mục đích chứng minh tầm quan trọng của việc tách lớp sẵn có của dữ liệu khỏi chức năng cốt lõi khác của chuỗi khối.

Khi tính khả dụng của dữ liệu được xử lý riêng biệt, việc tối ưu hóa có thể được thực hiện để coi tính khả dụng của dữ liệu như một lớp độc lập, điều này có thể dẫn đến những cải tiến lớn hơn so với khi tính khả dụng của dữ liệu được gắn với các chức năng blockchain khác như thực thi.

Cho dù chúng được gọi là giải pháp lớp 3, chuỗi khối mô-đun hay giải pháp mở rộng quy mô ngoài chuỗi, chúng tôi rất vui khi thấy các nhóm ý tưởng mới nghĩ ra cách tận dụng lớp sẵn có dữ liệu chuyên dụng này. Các nhóm có thể yên tâm rằng Avail sẽ có thể mở rộng quy mô trực tiếp với bất kỳ chuỗi hoặc ứng dụng nào được xây dựng trên đó. Khi chúng tôi xây dựng một mạng chuỗi khối mô-đun với hàng trăm trình xác thực, hàng nghìn khách hàng đơn giản và nhiều chuỗi mới sắp ra mắt, chúng tôi dự kiến ​​sẽ không gặp bất kỳ vấn đề nào để đáp ứng nhu cầu.