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: “Avail có thể xử lý bao nhiêu giao dịch?” Trong bài viết này, chúng ta sẽ so sánh Ethereum và Avail dựa trên kiến ​​trúc hiện tại của hai chuỗi thông lượng.

Đây là bài viết đầu tiên trong loạt bài viết về khả năng mở rộng của Avail, thảo luận về hiệu suất hiện tại của Avail cũng như khả năng mở rộng quy mô trong ngắn hạn và dài hạn.

Avail vs Ethereum

Các khối của Ethereum có thể chứa tới 1,875 MB dữ liệu và thời gian tạo khối là khoảng 13 giây. Tuy nhiên, các khối Ethereum thường không được lấp đầy. Hầu hết mọi khối sẽ không đạt đến giới hạn trên của dữ liệu do đã đạt đến giới hạn gas, bởi vì cả việc thực thi và thanh toán đều tiêu tốn gas. Do đó, lượng dữ liệu được lưu trữ trong mỗi khối có thể thay đổi.

Nhu cầu kết hợp việc thực thi, giải quyết và tính sẵn có của dữ liệu trong cùng một khối là vấn đề cốt lõi trong một kiến ​​trúc blockchain duy nhất. Việc triển khai L2 đã bắt đầu phong trào hướng tới các chuỗi khối mô-đun, cho phép xử lý các hoạt động thực thi trên một chuỗi riêng biệt với các khối của chuỗi đó dành riêng cho việc thực thi. Avail tiếp tục áp dụng thiết kế mô-đun để tách riêng tính khả dụng của dữ liệu, cho phép các khối của chuỗi được dành riêng cho tính khả dụng của dữ liệu.

Hiện tại, thời gian tạo khối của Avail là 20 giây và mỗi khối có thể chứa khoảng 2 MB dữ liệu. Giả sử kích thước giao dịch trung bình là 250 byte, mỗi khối Avail ngày nay có thể chứa khoảng 8.400 giao dịch (420 giao dịch mỗi giây).

Hơn nữa, Avail luôn có thể lấp đầy các khối đến giới hạn lưu trữ và tăng kích thước khi cần. Chúng tôi có một số đòn bẩy có thể được điều chỉnh nhanh chóng để tăng số lượng giao dịch trên mỗi khối lên hơn 500.000 (25.000 giao dịch mỗi giây) nếu cần.

Chúng ta có thể tăng thông lượng không?

Để tăng thông lượng (đặc biệt là các giao dịch mỗi giây), các kiến ​​trúc sư của chuỗi cần tăng kích thước khối hoặc giảm thời gian tạo khối.

Để được thêm vào chuỗi, mỗi khối phải tạo ra các cam kết, xây dựng bằng chứng, truyền bá chúng và được tất cả các nút khác xác minh những bằng chứng này. Các bước này luôn mất thời gian, điều này đặt ra giới hạn trên tự nhiên về thời gian tạo và xác nhận khối.

Do đó, chúng ta không thể đơn giản giảm thời gian chặn xuống còn một giây. Điều này đơn giản là không cho phép có đủ thời gian để tạo ra các cam kết, tạo bằng chứng và truyền bá những phần này đến tất cả những người tham gia trên toàn mạng. Trong thời gian khối một giây về mặt lý thuyết, ngay cả khi mọi người tham gia mạng chạy các máy mạnh nhất có khả năng tạo ra các cam kết và bằng chứng ngay lập tức, thì nút thắt cổ chai vẫn là việc truyền bá dữ liệu. Do hạn chế về tốc độ Internet, mạng không thể thông báo đủ nhanh cho tất cả các nút đầy đủ của khối. Vì vậy, chúng ta phải đảm bảo rằng thời gian tạo khối đủ cao để cho phép dữ liệu được phân phối vào mạng sau khi đạt được sự đồng thuận.

Ngược lại, thông lượng cũng có thể được tăng lên bằng cách tăng kích thước khối, tức là tăng lượng dữ liệu chúng ta có thể chứa trên mỗi khối.

Kiến trúc hiện tại: Thêm một khối vào chuỗi

Trước tiên, hãy xem các bước cần thiết để thêm một khối vào chuỗi. Có ba bước chính cần thiết để thêm từng khối vào chuỗi. Điều này bao gồm thời gian cần thiết để tạo một khối, truyền bá khối và xác thực khối.

1. Tạo khối

Bước này bao gồm thời gian cần thiết để thu thập và sắp xếp các giao dịch Lịch phát sóng, xây dựng các cam kết và mở rộng (xóa mã) ma trận dữ liệu.

Việc tạo khối đo thời gian cần thiết để tạo một khối, vì quá trình này luôn mất ít nhất một khoảng thời gian. Do đó, chúng ta phải xem xét không chỉ thời điểm trong trường hợp tốt nhất mà còn cả thời gian trong trường hợp trung bình và trường hợp xấu nhất trên các máy khác nhau.

Máy yếu nhất có thể tham gia vào việc tạo khối mới là máy đạt đến giới hạn hiệu suất trong các trường hợp trung bình. Tất cả các máy chậm hơn cuối cùng sẽ bị tụt lại phía sau vì chúng không thể bắt kịp các máy nhanh hơn.

2. Độ trễ lan truyền

Độ trễ lan truyền là thước đo thời gian cần thiết để truyền các khối từ nhà sản xuất đến người xác thực và mạng ngang hàng.

Hiện tại, kích thước khối của Avail là 2 MB. Trong giới hạn thời gian khối hiện tại là 20 giây, kích thước khối như vậy có thể được phổ biến. Kích thước khối lớn hơn làm cho việc truyền bá phức tạp hơn.

Ví dụ: nếu chúng tôi tăng Tính khả dụng để hỗ trợ các khối 128 MB thì quá trình tính toán có thể mở rộng (khoảng 7 giây). Tuy nhiên, nút cổ chai trở thành thời gian cần thiết để gửi và tải xuống các khối này qua mạng.

Gửi một khối 128 MB đi khắp thế giới qua mạng ngang hàng trong 5 giây có lẽ là giới hạn của những gì hiện có thể đạt được.

Giới hạn 128 MB không liên quan gì đến tính khả dụng của dữ liệu hoặc gói cam kết của chúng tôi mà là vấn đề về giới hạn băng thông liên lạc.

Nhu cầu tính đến độ trễ truyền này cung cấp cho chúng tôi giới hạn kích thước khối lý thuyết hiện tại của Avail.

3. Chặn xác minh

Sau khi được phổ biến, những người xác thực tham gia không chỉ tin tưởng vào khối do người đề xuất khối cung cấp cho họ—họ cần xác minh rằng khối được tạo ra thực sự chứa dữ liệu mà nhà sản xuất đã xác nhận quyền sở hữu.

Có một sự căng thẳng nhất định giữa ba bước này. Chúng tôi có thể có tất cả các trình xác nhận đều là những cỗ máy mạnh mẽ và được kết nối chặt chẽ bởi một mạng tuyệt vời trong cùng một trung tâm dữ liệu - điều này sẽ giảm thời gian sản xuất và xác minh, đồng thời cho phép chúng tôi truyền bá lượng lớn dữ liệu hơn. Tuy nhiên, vì chúng tôi cũng muốn có một mạng lưới phi tập trung, đa dạng với nhiều loại người tham gia khác nhau nên đây không phải là một cách tiếp cận lý tưởng.

Thay vào đó, cải thiện thông lượng sẽ đạt được bằng cách hiểu các bước cần thiết để thêm khối vào chuỗi Avail và những bước nào có thể được tối ưu hóa.

Hiện tại, trình xác thực sử dụng Avail sẽ lấy toàn bộ khối và sao chép tất cả các cam kết do người đề xuất tạo ra để xác thực khối. Điều này có nghĩa là nhà sản xuất khối và tất cả người xác thực cần thực hiện từng bước trong sơ đồ trên.

Trong một blockchain duy nhất, thông lệ mặc định cho mỗi trình xác nhận là xây dựng lại toàn bộ khối. Tuy nhiên, trên một chuỗi như Avail, nơi các giao dịch không được thực hiện, việc tái thiết này là không cần thiết. Do đó, một cách chúng tôi có thể tối ưu hóa Lịch phát sóng là cho phép người xác thực đạt được sự đảm bảo của riêng họ về tính khả dụng của dữ liệu thông qua việc lấy mẫu, thay vì bằng cách xây dựng lại các khối. Điều này đòi hỏi ít tài nguyên hơn đối với người xác nhận so với việc yêu cầu họ sao chép tất cả các cam kết. Những nội dung liên quan khác sẽ được giới thiệu ở những bài viết tiếp theo.

Lấy mẫu tính khả dụng của dữ liệu Discovery hoạt động như thế nào?

Trong Avail, ứng dụng khách nhẹ sử dụng ba công cụ cốt lõi để xác nhận tính khả dụng của dữ liệu: mẫu, cam kết và chứng thực.

• Máy khách hạng nhẹ hiện đang thực hiện các thao tác mẫu, trong đó chúng yêu cầu giá trị của một ô cụ thể và chứng chỉ hợp lệ liên quan của ô đó từ mạng Avail. Càng thu thập nhiều mẫu, họ càng tự tin rằng tất cả dữ liệu đều có sẵn.

• Một cam kết được tạo bởi người đề xuất khối và tóm tắt toàn bộ hàng dữ liệu trong khối Avail. (Mẹo: Đây là bước chúng tôi sẽ tối ưu hóa ở phần sau của loạt bài này.)

• Mỗi ô trong mạng tạo ra một bằng chứng. Light client sử dụng bằng chứng và hứa hẹn sẽ xác minh rằng giá trị của ô được cung cấp cho họ là chính xác.

Sau đó, bằng cách sử dụng những công cụ này, ứng dụng khách nhẹ sẽ thực hiện ba bước.

• Quyết định: Độ tin cậy về tính khả dụng cần thiết sẽ xác định số lượng mẫu được thực hiện bởi máy khách hạng nhẹ. Họ không yêu cầu nhiều mẫu (8-30 mẫu) để đạt được đảm bảo tính khả dụng trên 99,95%.

• Tải xuống: Sau đó, máy khách hạng nhẹ sẽ yêu cầu các mẫu này và các bằng chứng liên quan của chúng rồi tải chúng xuống từ mạng (nút đầy đủ hoặc máy khách hạng nhẹ khác).

• Xác minh: Họ xem xét cam kết trong tiêu đề khối (máy khách nhẹ luôn có thể truy cập được) và xác minh bằng chứng của từng ô đối với cam kết.

Chỉ với điều này, các client nhẹ có thể xác nhận tính khả dụng của tất cả dữ liệu trong một khối mà không cần tải xuống phần lớn nội dung của khối. Các bước bổ sung do ứng dụng khách nhẹ thực hiện cũng góp phần tăng cường bảo mật cho Avail nhưng không được liệt kê ở đây. Ví dụ: các máy khách nhẹ có thể chia sẻ các mẫu và bằng chứng đã tải xuống của họ với các máy khách nhẹ khác trong trường hợp họ cần. Nhưng đây là cách ứng dụng khách nhẹ xác nhận tính khả dụng của dữ liệu!

Trong phần thứ hai của loạt bài này, chúng ta sẽ xem xét các cách cải thiện thông lượng của Avail trong thời gian ngắn. Chúng tôi sẽ giải thích lý do chúng tôi tin rằng Avail có thể đáp ứng nhu cầu của bất kỳ mạng nào trong năm tới và cách chúng tôi có thể cải thiện mạng để đáp ứng những thách thức trong những năm tới.