Trong mạng blockchain, làm cách nào để các nút đảm bảo rằng tất cả dữ liệu cho các khối mới được đề xuất đều có sẵn? Sao nó lại quan trọng?

Trong bài viết này, chúng ta sẽ đi sâu vào vấn đề về tính khả dụng của dữ liệu và cách nó ảnh hưởng đến khả năng mở rộng của Ethereum.

Các vấn đề về tính sẵn có của dữ liệu là gì?

Vấn đề về tính sẵn sàng của dữ liệu (DA): Làm thế nào để các nút trong mạng blockchain đảm bảo rằng tất cả dữ liệu trong các khối mới được đề xuất thực sự có sẵn? Nếu dữ liệu không có sẵn, khối có thể chứa các giao dịch độc hại bị nhà sản xuất khối ẩn. Ngay cả khi một khối chứa các giao dịch không độc hại, việc ẩn chúng có thể đe dọa đến tính bảo mật của hệ thống.

Ví dụ: giả sử Alice là toán tử ZK-Rollup. Cô ấy đã gửi ZK-Proof trên Ethereum và nó đã được xác minh. Nếu cô ấy không gửi tất cả dữ liệu giao dịch trên Ethereum, người dùng bản tổng hợp có thể vẫn không biết về số dư tài khoản hiện tại của họ, mặc dù bằng chứng của cô ấy xác nhận rằng tất cả các chuyển đổi trạng thái được thực hiện trong bản tổng hợp đều hợp lệ. Do tính chất không có kiến ​​thức nên bằng chứng được gửi không thể tiết lộ thông tin về trạng thái hiện tại.

Có một ví dụ tương tự trong kịch bản Tổng hợp lạc quan, trong đó Alice gửi một xác nhận trên Ethereum, nhưng vì dữ liệu giao dịch không có sẵn nên những người tham gia OPR không thể tính toán lại hoặc phản đối xác nhận đó.

Để đối phó với tình trạng trên, thiết kế của cả OPR và ZKR đều yêu cầu các nhà khai thác gửi tất cả chi tiết giao dịch tới Ethereum dưới dạng “calldata”. Mặc dù điều này cho phép họ tránh các vấn đề về DA trong thời gian ngắn, khi số lượng giao dịch trong một bản tổng hợp tăng lên, lượng dữ liệu cần được cam kết cũng tăng lên, hạn chế mức độ mở rộng mà các bản tổng hợp này có thể cung cấp.

Tệ hơn nữa, việc không có sẵn dữ liệu là một lỗi không thể xác định được một cách duy nhất. Điều này có nghĩa là người tham gia không thể chứng minh cho các nút khác rằng một khối dữ liệu cụ thể bị thiếu. Điều này là do Bob có thể thông báo rằng khối do Alice gửi bị thiếu dữ liệu, nhưng khi Charlie truy vấn Alice, cô ấy có thể cung cấp dữ liệu cho anh ấy.

Các vấn đề về tính sẵn có của dữ liệu ảnh hưởng đến các chuỗi khối hiện tại như thế nào?

Để trả lời câu hỏi này, trước tiên chúng ta hãy xem lại cấu trúc khối chung của một chuỗi khối giống Ethereum và các loại ứng dụng khách tồn tại trên bất kỳ mạng chuỗi khối nào.

Một khối có thể được chia thành hai phần chính:

• Tiêu đề khối: Tiêu đề khối nhỏ chứa tóm tắt và siêu dữ liệu liên quan đến các giao dịch có trong khối.

• Thân khối: chứa tất cả dữ liệu giao dịch và là phần chính của khối.

Trong các giao thức blockchain truyền thống, tất cả các nút được coi là nút đầy đủ, chúng đồng bộ hóa toàn bộ khối và xác minh tất cả các chuyển đổi trạng thái. Họ yêu cầu các nguồn lực đáng kể để kiểm tra tính hợp lệ của các giao dịch và khối lưu trữ. Ưu điểm là các nút này sẽ không chấp nhận bất kỳ giao dịch không hợp lệ nào.

Có thể có một loại nút khác không có (hoặc không muốn chi tiêu) tài nguyên để xác minh mọi giao dịch. Thay vào đó, họ chủ yếu quan tâm đến việc tìm hiểu trạng thái hiện tại của blockchain và liệu một số giao dịch liên quan đến chúng có được đưa vào chuỗi hay không. Lý tưởng nhất là những client nhẹ này cũng cần được bảo vệ khỏi bị giả mạo bởi các chuỗi chứa các giao dịch không hợp lệ. Điều này thực sự có thể đạt được bằng cách sử dụng cái gọi là bằng chứng gian lận. Những thông báo ngắn gọn này cho thấy rằng nội dung khối cụ thể chứa các giao dịch không hợp lệ. Bất kỳ nút đầy đủ nào cũng có thể tạo ra bằng chứng gian lận như vậy, vì vậy, các khách hàng nhẹ không cần phải tin tưởng vào một nút đầy đủ cụ thể. Họ chỉ cần đảm bảo rằng họ được kết nối tốt với mạng tin đồn để đảm bảo rằng nếu có bằng chứng gian lận về tiêu đề khối, họ sẽ nhận được nó.

Tuy nhiên, có một vấn đề với hệ thống này: Điều gì sẽ xảy ra nếu nhà sản xuất khối không tiết lộ toàn bộ dữ liệu đằng sau một khối? Trong trường hợp này, các nút đầy đủ rõ ràng sẽ từ chối khối vì theo quan điểm của họ, nếu một khối không đi kèm với phần thân khối thì nó thậm chí không phải là một khối. Tuy nhiên, các máy khách nhẹ có thể hiển thị chuỗi tiêu đề khối và không nhận thấy dữ liệu bị thiếu. Đồng thời, các nút đầy đủ không thể tạo ra bằng chứng gian lận vì chúng thiếu dữ liệu cần thiết để tạo bằng chứng gian lận.

Để giải quyết vấn đề này, chúng tôi cần một cơ chế để các máy khách nhẹ xác minh tính khả dụng của dữ liệu. Điều này sẽ đảm bảo rằng các nhà sản xuất khối che giấu dữ liệu không thể trốn tránh bằng cách thuyết phục các khách hàng nhẹ. Điều này cũng sẽ buộc các nhà sản xuất khối tiết lộ một phần dữ liệu, cho phép toàn bộ mạng truy cập dữ liệu của toàn bộ khối theo cách cộng tác.

Hãy hiểu vấn đề này sâu sắc hơn bằng một ví dụ. Giả sử nhà sản xuất khối Alice xây dựng khối B chứa các giao dịch tx 1, tx 2, ..., txn. Giả sử rằng tx 1 là một giao dịch độc hại. Nếu tx 1 được phát sóng, bất kỳ nút đầy đủ nào cũng có thể xác minh rằng nó độc hại và gửi thông tin này làm bằng chứng gian lận cho ứng dụng khách nhẹ, ứng dụng này sẽ biết ngay rằng khối này không được chấp nhận. Tuy nhiên, nếu Alice muốn ẩn tx 1 , cô ấy chỉ tiết lộ tiêu đề và tất cả dữ liệu giao dịch ngoại trừ tx 1 . Một nút đầy đủ không thể xác minh tính đúng đắn của tx 1.

Người ta có thể nghĩ rằng một giải pháp đơn giản là yêu cầu tất cả các khách hàng nhỏ lấy mẫu ngẫu nhiên các giao dịch và nếu họ thấy rằng mẫu của họ có sẵn, họ có thể tin tưởng rằng khối đó có sẵn. Nhưng nếu nút ánh sáng truy vấn ngẫu nhiên bất kỳ giao dịch nào, xác suất máy khách ánh sáng truy vấn tx 1 là 1/n. Do đó, Alice hầu như luôn có thể lừa một khách hàng nhẹ chấp nhận một giao dịch độc hại. Nói cách khác, hầu hết các client nhẹ sẽ bị giả mạo. Do tính chất không thể quy kết, một nút đầy đủ không thể chứng minh bằng bất kỳ cách nào rằng tx 1 không khả dụng. Thật không may, việc tăng kích thước mẫu cũng không làm mọi việc tốt hơn.

Vì vậy, làm thế nào để chúng ta giải quyết vấn đề này?

Giải pháp cho vấn đề này nằm ở việc đưa tính dự phòng vào các khối. Có một tài liệu phong phú về lý thuyết mã hóa và đặc biệt là mã hóa xóa, có thể giúp chúng ta giải quyết vấn đề này.

Nói tóm lại, mã hóa xóa cho phép chúng ta mở rộng n khối dữ liệu bất kỳ thành 2n khối dữ liệu, sao cho bất kỳ n nào trong số 2n đều đủ để tái tạo lại dữ liệu gốc (các tham số có thể điều chỉnh được, nhưng ở đây chúng tôi giữ nó đơn giản và xem xét tình huống này).

Nếu chúng ta buộc các nhà sản xuất khối xóa mã các giao dịch tx 1, tx 2, ..., txn, thì để ẩn một giao dịch, nó sẽ cần ẩn n+1 khối dữ liệu, vì n khối dữ liệu bất kỳ cũng đủ để xây dựng toàn bộ giao dịch bộ. Trong trường hợp này, một số lượng nhỏ truy vấn có thể mang lại cho client mức độ tin cậy cao rằng dữ liệu cơ bản thực sự có sẵn.

Woah,À chính nó đấy?

KHÔNG. Mặc dù thủ thuật đơn giản này khiến việc giấu dữ liệu trở nên khó khăn hơn nhưng vẫn có khả năng nhà sản xuất khối đã cố tình xóa mã hóa sai cách. Tuy nhiên, một nút đầy đủ có thể xác minh rằng việc mã hóa xóa này được thực hiện chính xác và nếu không, nó có thể chứng minh điều này với máy khách hạng nhẹ. Đây là một loại bằng chứng gian lận khác, giống như giao dịch độc hại đã đề cập ở trên. Điều thú vị là, tất cả chỉ cần một nút đầy đủ trung thực đóng vai trò là hàng xóm của ứng dụng khách nhẹ để đảm bảo rằng nếu một khối là độc hại, nó sẽ nhận được bằng chứng gian lận. Điều này đảm bảo rằng các client đơn giản có thể truy cập vào chuỗi không có giao dịch độc hại với xác suất rất cao.

Nhưng có một vấn đề. Nếu thực hiện quá đơn giản, một số bằng chứng gian lận có thể lớn bằng chính kích thước của khối đó. Các giả định về tài nguyên của chúng tôi về các client nhẹ cấm chúng tôi sử dụng một thiết kế như vậy. Những cải tiến đã được thực hiện thông qua việc sử dụng các kỹ thuật mã hóa xóa đa chiều nhằm giảm quy mô của bằng chứng gian lận nhưng phải trả giá bằng việc tăng quy mô của cam kết. Để ngắn gọn, chúng tôi không đi sâu vào chi tiết về những điều này ở đây, nhưng bài viết nàygiấyĐiều này đã được phân tích chi tiết.

Vấn đề với các giải pháp dựa trên bằng chứng gian lận là một client nhỏ không bao giờ có thể hoàn toàn chắc chắn về bất kỳ khối nào mà họ chưa nhận được bằng chứng gian lận. Đồng thời, họ tiếp tục tin tưởng vào các nút đầy đủ của mình một cách trung thực. Các nút trung thực cũng cần được khuyến khích để liên tục xem xét các khối.

Điều chúng tôi tập trung ở đây là những hệ thống đảm bảo rằng nếu mã hóa khối không hợp lệ, các nút đầy đủ có thể phát hiện ra nó và cung cấp bằng chứng cho các máy khách nhẹ để thuyết phục họ về hành vi sai trái. Tuy nhiên, trong phần tiếp theo, chúng tôi sẽ tập trung vào mã hóa khối để đảm bảo rằng chỉ những mã hóa hợp lệ mới được gửi tới chuỗi. Điều này giúp loại bỏ sự cần thiết của bằng chứng gian lận chứng minh lỗi mã hóa. Các giải pháp dựa trên bằng chứng hợp lệ cho phép các ứng dụng sử dụng hệ thống mà không cần phải đợi các nút đầy đủ cung cấp bằng chứng gian lận đó.

Vậy các giải pháp này hoạt động như thế nào?

Gần đây, các cam kết đa thức đã tạo ra sự quan tâm mới đối với không gian blockchain. Các cam kết đa thức này, đặc biệt là các cam kết KZG/Kate có kích thước không đổi đối với đa thức, có thể được sử dụng để thiết kế sơ đồ Tính sẵn sàng Dữ liệu (DA) gọn gàng mà không yêu cầu bằng chứng gian lận. Nói tóm lại, cam kết KZG cho phép chúng tôi cam kết một đa thức bằng cách sử dụng một phần tử nhóm đường cong elip duy nhất. Hơn nữa, sơ đồ này cho phép chúng ta chứng minh rằng tại một số điểm i, đa thức φ có giá trị φ(i), sử dụng các nhân chứng có kích thước không đổi. Kế hoạch cam kết này có tính ràng buộc về mặt tính toán và đồng hình, cho phép chúng tôi tránh được các bằng chứng gian lận một cách gọn gàng.

Chúng tôi buộc nhà sản xuất khối sắp xếp dữ liệu giao dịch thô thành ma trận hai chiều có kích thước nxm. Nó sử dụng phép nội suy đa thức để mở rộng từng cột có kích thước n thành cột có kích thước 2 n . Mỗi hàng của ma trận mở rộng này tạo ra một cam kết đa thức và những cam kết này được gửi như một phần của tiêu đề khối. Dưới đây là sơ đồ biểu diễn các khối.

Máy khách nhẹ truy vấn bất kỳ ô nào của ma trận mở rộng này để tìm bằng chứng, điều này cho phép nó xác minh ngay lập tức đối với tiêu đề khối. Bằng chứng kích thước không đổi của tư cách thành viên giúp việc lấy mẫu cực kỳ hiệu quả. Bản chất đồng cấu của các cam kết đảm bảo rằng bằng chứng chỉ có thể được xác minh nếu khối được xây dựng chính xác, trong khi phép nội suy đa thức đảm bảo rằng số lượng mẫu thành công không đổi có nghĩa là xác suất có sẵn dữ liệu là rất cao.

Sơ đồ biểu diễn các khối

Các chi tiết chi tiết hơn của sơ đồ này cũng như khả năng tối ưu hóa và ước tính chi phí sâu hơn đều nằm ngoài phạm vi của bài viết này. Tuy nhiên, chúng tôi muốn chỉ ra rằng mặc dù chúng ta đang thảo luận về sơ đồ hai chiều ở đây, những đảm bảo tương tự cũng có thể được cung cấp bởi sơ đồ một chiều, có kích thước tiêu đề khối nhỏ hơn, nhưng phải trả giá bằng việc giảm tính song song và ánh sáng. hiệu quả lấy mẫu của khách hàng. Chúng ta sẽ khám phá điều này sâu hơn trong bài viết tiếp theo.

Các lựa chọn thay thế khác là gì? Chuyện gì xảy ra tiếp theo?

Các cam kết mã hóa xóa chiều cao và KZG không phải là giải pháp duy nhất cho các vấn đề về tính sẵn có của dữ liệu. Ở đây chúng tôi đã bỏ qua một số phương pháp khác, chẳng hạn như cây Merkle được mã hóa, cây xen kẽ được mã hóa, các phương pháp dựa trên FRI và STARK, nhưng mỗi phương pháp đều có những ưu điểm và nhược điểm riêng.

Tại Avail, chúng tôi đã phát triển các giải pháp sẵn có của dữ liệu bằng cách sử dụng Cam kết KZG. Trong các bài viết tiếp theo, chúng tôi sẽ đề cập đến các chi tiết triển khai, cách sử dụng nó và cách chúng tôi dự định thay đổi không gian vấn đề về tính khả dụng của dữ liệu. Để tìm hiểu thêm về Avail, hãy theo dõi chúng tôi trên Twitter và tham gia máy chủ Discord của chúng tôi.

Twitter：https://twitter.com/AvailProject

Discord：https://discord.com/invite/jTkvDrZ54r

Bạn cũng có thể theo dõi tài khoản Twitter của Module 101: @Modular 101