Vấn đề sẵn có dữ liệu

Người mới bắt đầu1/2/2024, 10:46:41 AM
Bài viết này đi sâu vào vấn đề sẵn có dữ liệu và cách nó ảnh hưởng đến khả năng mở rộng của Ethereum.

Làm sao các đồng nghiệp trong một mạng blockchain có thể chắc chắn rằng tất cả dữ liệu của một khối mới được đề xuất có sẵn? Và tại sao điều đó lại quan trọng?

Trong bài viết này, chúng tôi đi sâu vào chi tiết về vấn đề sẵn có dữ liệu và cách nó có thể ảnh hưởng đến việc mở rộng trên Ethereum.

Vấn đề Khả dụng Dữ liệu là gì?

Vấn đề Khả dễ sẵn có (DA): Làm thế nào để các đồng nghiệp trong mạng blockchain có thể chắc chắn rằng tất cả dữ liệu của một 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 đang bị ẩn bởi người sản xuất khối. Ngay cả khi khối chứa các giao dịch không độc hại, việc ẩn chúng có thể đe dọa tính bảo mật của hệ thống.

Để cung cấp một ví dụ, giả sử Alice là một nhà vận hành của một ZK-Rollup (ZKR). Cô ấy gửi một Bằng chứng ZK trên Ethereum được xác minh. Nếu cô ấy không gửi tất cả dữ liệu giao dịch trên Ethereum, mặc dù bằng chứng của cô ấy chứng minh rằng tất cả các chuyển đổi trạng thái được thực hiện trong rollup đều hợp lệ, người dùng của rollup vẫn có thể bị mơ hồ về số dư tài khoản hiện tại của họ. Bằng chứng đã gửi không làm sáng tỏ trạng thái hiện tại vì tính chất Zero-Knowledge của nó.

Một ví dụ tương tự tồn tại trong Optimistic Rollup (OPR)setting, nơi Alice gửi một khẳng định trên Ethereum, nhưng không ai trong số các thành viên của OPR có thể thách thức được nó vì dữ liệu giao dịch không có sẵn và do đó họ không thể tính toán lại hoặc thách thức khẳng định.

Để đối phó với các tình huống trên, cả thiết kế OPR và ZKR đều yêu cầu các nhà điều hành gửi tất cả chi tiết giao dịch trên Ethereumnhư ‘calldata’. Điều này giúp chúng tránh được vấn đề DA trong tương lai ngắn hạn, vì khi số lượng giao dịch tăng lên bên trong rollups, lượng dữ liệu cần phải gửi cũng sẽ tăng lên, hạn chế khả năng mở rộng mà những rollups này có thể cung cấp.

Điều tồi tệ hơn, việc dữ liệu không khả dụng không phải là một lỗi mà có thể được chỉ định duy nhất. Điều này có nghĩa là các thành viên không thể chứng minh cho những người đồng đẳng khác rằng một phần dữ liệu cụ thể đang bị thiếu. Điều này xảy ra vì Bob có thể phát sóng rằng khối được gửi bởi Alice thiếu dữ liệu, nhưng khi Charlie truy vấn Alice, cô có thể cung cấp dữ liệu cho anh ta.

Làm thế nào điều này ảnh hưởng đến một chuỗi khối ngày nay?

Để trả lời câu hỏi này, hãy trở lại cấu trúc khối chung của một blockchain giống Ethereum và các loại khách hàng tồn tại trên mạng lưới blockchain nào.

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

  • Phần Header Khối: Một phần header khối nhỏ chứa bản tóm tắt và siêu dữ liệu liên quan đến các giao dịch được bao gồm trong khối.
  • Block Body: Điều này chứa tất cả dữ liệu giao dịch và chiếm đa số kích thước 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 đủ đồng bộ toàn bộ khối và xác minh tất cả các chuyển đổi trạng thái. Họ cần phải tiêu tốn một lượng tài nguyên đáng kể để kiểm tra tính hợp lệ của giao dịch và lưu trữ các khối. Mặt tích cực là những nút này không thể bắt buộc chấp nhận bất kỳ giao dịch không hợp lệ nào.

Có thể có một nhóm 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 trạng thái hiện tại của chuỗi khối và xem xem một số giao dịch, mà liên quan đến họ, đã được bao gồm trong chuỗi hay không. Lý tưởng, những khách hàng nhẹ này cũng nên được bảo vệ khỏi việc theo dõi một chuỗi chứa các giao dịch không hợp lệ. Thực tế, điều này hoàn toàn có thể thông qua những bằng chứng lừa đảo gọi là. Đó là những tin nhắn ngắn gọn cho thấy rằng một thân hình khối cụ thể bao gồm một giao dịch không hợp lệ. Bất kỳ nút đầy đủ nào cũng có thể tạo ra một bằng chứng lừa đảo như vậy, và khách hàng nhẹ do đó không cần phải tin rằng một nút đầy đủ cụ thể là trung thực. Họ chỉ cần đảm bảo rằng họ kết nối tốt với mạng lưới đồn đại đảm bảo rằng nếu có bằng chứng lừa đảo có sẵn cho một 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: nếu một 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 đủ sẽ từ chối khối một cách rõ ràng vì theo họ, nếu nó không đi kèm với thân khối thì nó không phải là một khối. Tuy nhiên, các máy khách nhẹ có thể được trình bày với chuỗi tiêu đề và không cách nào nhận ra rằng dữ liệu đang thiếu. Đồng thời, các nút đầy đủ không thể tạo ra chứng minh gian lận, vì họ sẽ thiếu dữ liệu cần thiết để tạo ra chứng minh gian lận.

Để đối phó với điều này, chúng ta cần một cơ chế cho các máy khách nhẹ để xác minh sự có sẵn của dữ liệu. Điều này sẽ đảm bảo rằng một nhà sản xuất khối ẩn dữ liệu không thể thoát khỏi bằng cách thuyết phục một máy khách nhẹ khác. Nó cũng buộc nhà sản xuất khối phải tiết lộ các phần của dữ liệu, khiến toàn bộ mạng có quyền truy cập vào toàn bộ khối theo một cách cộng tác.

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

Một người có thể nghĩ một giải pháp đơn giản là nếu tất cả các máy khách nhẹ đơn giản chỉ lấy mẫu các giao dịch ngẫu nhiên và nếu họ thấy mẫu của họ có sẵn, họ có thể tự tin rằng khối đó có sẵn. Để cho phép các nút ánh sáng truy vấn cho bất kỳ một giao dịch nào, một cách đồng đều ngẫu nhiên. Xác suất mà máy khách nhẹ truy vấn tx1 là 1/n. Vì vậy, với một xác suất lớn, Alice có thể đánh lừa các máy khách 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 máy khách nhẹ sẽ bị đánh lừa. Do tính không thể rõ ràng, các nút đầy đủ không thể chứng minh bằng bất kỳ cách nào rằng tx1 không có sẵn. Thật không may, việc tăng số lượng mẫu không làm cho tình hình này tốt hơn nhiều.

Vậy, chúng ta nên làm gì về vấn đề này?

Giải pháp cho vấn đề này nằm ở việc giới thiệu sự dư thừa vào một khối. Có một bộ sưu tập phong phú về lý thuyết mã hóa nói chung, và mã hóa xóa cụ thể, có thể giúp chúng ta giải quyết vấn đề này.

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

Nếu chúng ta buộc nhà sản xuất khối mã hóa dữ liệu giao dịch tx1, tx2, …, txn, thì để che giấu một giao dịch duy nhất, nó sẽ cần phải che giấu n+1 phần dữ liệu vì bất kỳ n phần nào cũng đủ để xây dựng toàn bộ tập hợp giao dịch. Trong trường hợp này, một số lượng truy vấn không đổi đưa ra cho khách hàng nhẹ niềm tin rất cao rằng dữ liệu cơ bản thực sự có sẵn.

Wow, vậy là đây à?

Không. Mặc dù mẹo đơn giản này làm cho việc che giấu khó khăn hơn, nhưng vẫn có khả năng rằng nhà sản xuất khối chỉ cố ý thực hiện mã hóa xóa một cách sai lầm. Tuy nhiên, một nút đầy đủ có thể xác minh xem mã hóa xóa này đã được thực hiện đúng cách và nếu không, nó có thể chứng minh điều này cho một khách hàng nhẹ. Đây là một loại chứng minh gian lận khác, giống như trong trường hợp các giao dịch độc hại ở trên. Thú vị là, cần có một hàng xóm nút đầy đủ trung thực duy nhất của một khách hàng nhẹ để chắc chắn rằng nếu khối đó là độc hại, thì nó sẽ nhận được một chứng minh gian lận. Điều này đảm bảo rằng khách hàng nhẹ có quyền truy cập vào một 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 một cách ngây thơ, kích thước của một số bằng chứng gian lận có thể ở cùng một mức với kích thước của khối. Giả định tài nguyên mà chúng tôi đặt ra cho khách hàng nhẹ ngăn cản chúng tôi sử dụng một thiết kế như vậy. Đã có những cải tiến trong lĩnh vực này bằng cách sử dụng các kỹ thuật mã hóa xóa nhiều chiều giảm kích thước của các bằng chứng gian lận với chi phí kích thước cam kết. Vì sự ngắn gọn, chúng tôi không đề cập đến những điều này nhưng bài báo nàycó một phân tích chi tiết về nó.

Vấn đề với các giải pháp dựa trên chứng minh gian lận là rằng các máy khách nhẹ không bao giờ hoàn toàn chắc chắn về bất kỳ khối nào mà nó chưa nhận được chứng minh gian lận. Ngoài ra, họ liên tục tin tưởng vào sự trung thực của các đồng nghiệp nút đầy đủ của mình. Các nút trung thực cũng cần được khuyến khích để liên tục kiểm tra khối.

Chúng tôi tập trung sự chú ý vào các 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 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ẽ xem xét về việc mã hóa khối đảm bảo rằng chỉ có những mã hóa hợp lệ mới có thể được cam kết vào chuỗi. Điều này tiêu diệt nhu cầu cho bằng chứng gian lận chứng minh lỗi mã hóa. Những giải pháp dựa trên bằng chứng tính hợp lệ này cho phép các ứng dụng sử dụng hệ thống mà không cần phải chờ đợi những bằng chứng gian lận như vậy từ các nút đầy đủ.

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

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

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

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

Một biểu đồ mô tả sơ đồ của khối

Những chi tiết tinh tế của kế hoạch cùng với việc tối ưu hóa và ước lượng chi phí chi tiết vượt ra 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 tôi thảo luận về một kế hoạch 2D ở đây, các cam kết tương tự cũng có thể được cung cấp với một kế hoạch 1D, có kích thước tiêu đề nhỏ hơn với chi phí ít song song hơn và hiệu suất lấy mẫu máy khách nhẹ. Chúng tôi sẽ đi sâu vào đề tài này trong các bài viết tiếp theo.

Các phương án thay thế khác là gì và tiếp theo là gì?

Các mã xóa chiều cao hơn và cam kết KZG không phải là cách duy nhất để tiếp cận vấn đề DA. Có những cách khác mà chúng tôi đã bỏ qua ở đây như Cây Merkle mã hóa, Cây xen kẽ được mã hóa, FRI, và các phương pháp dựa trên 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 đã đang làm việc trên một giải pháp Sẵn sàng Dữ liệu bằng cách sử dụng cam kết KZG. Trong các bài đăng sau, chúng tôi sẽ đề cập đến các chi tiết triển khai, cách bạn có thể sử dụng nó ngay hôm nay và cách chúng tôi nhắm đến việc biến đổi không gian vấn đề DA. Để biết thêm thông tin về Avail, theo dõi chúng tôi trên Twittervà tham gia cùng chúng tôiDiscord server.

Disclaimer:

  1. Bài viết này được tái bản từ [GateĐội Avail]. Tất cả bản quyền thuộc về tác giả gốc [Đội Avail]. Nếu có bất kỳ ý kiến phản đối nào về việc tái bản này, vui lòng liên hệ với [GateGate Học] team, và họ sẽ xử lý nhanh chóng.

  2. Liability Disclaimer: Quan điểm và ý kiến được thể hiện trong bài viết này chỉ thuộc về tác giả và không cấu thành bất kỳ lời khuyên đầu tư nào.

  3. Bản dịch của 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 nêu, việc sao chép, phân phối hoặc đạo văn bản dịch là cấm.

Vấn đề sẵn có dữ liệu

Người mới bắt đầu1/2/2024, 10:46:41 AM
Bài viết này đi sâu vào vấn đề sẵn có dữ liệu và cách nó ảnh hưởng đến khả năng mở rộng của Ethereum.

Làm sao các đồng nghiệp trong một mạng blockchain có thể chắc chắn rằng tất cả dữ liệu của một khối mới được đề xuất có sẵn? Và tại sao điều đó lại quan trọng?

Trong bài viết này, chúng tôi đi sâu vào chi tiết về vấn đề sẵn có dữ liệu và cách nó có thể ảnh hưởng đến việc mở rộng trên Ethereum.

Vấn đề Khả dụng Dữ liệu là gì?

Vấn đề Khả dễ sẵn có (DA): Làm thế nào để các đồng nghiệp trong mạng blockchain có thể chắc chắn rằng tất cả dữ liệu của một 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 đang bị ẩn bởi người sản xuất khối. Ngay cả khi khối chứa các giao dịch không độc hại, việc ẩn chúng có thể đe dọa tính bảo mật của hệ thống.

Để cung cấp một ví dụ, giả sử Alice là một nhà vận hành của một ZK-Rollup (ZKR). Cô ấy gửi một Bằng chứng ZK trên Ethereum được xác minh. Nếu cô ấy không gửi tất cả dữ liệu giao dịch trên Ethereum, mặc dù bằng chứng của cô ấy chứng minh rằng tất cả các chuyển đổi trạng thái được thực hiện trong rollup đều hợp lệ, người dùng của rollup vẫn có thể bị mơ hồ về số dư tài khoản hiện tại của họ. Bằng chứng đã gửi không làm sáng tỏ trạng thái hiện tại vì tính chất Zero-Knowledge của nó.

Một ví dụ tương tự tồn tại trong Optimistic Rollup (OPR)setting, nơi Alice gửi một khẳng định trên Ethereum, nhưng không ai trong số các thành viên của OPR có thể thách thức được nó vì dữ liệu giao dịch không có sẵn và do đó họ không thể tính toán lại hoặc thách thức khẳng định.

Để đối phó với các tình huống trên, cả thiết kế OPR và ZKR đều yêu cầu các nhà điều hành gửi tất cả chi tiết giao dịch trên Ethereumnhư ‘calldata’. Điều này giúp chúng tránh được vấn đề DA trong tương lai ngắn hạn, vì khi số lượng giao dịch tăng lên bên trong rollups, lượng dữ liệu cần phải gửi cũng sẽ tăng lên, hạn chế khả năng mở rộng mà những rollups này có thể cung cấp.

Điều tồi tệ hơn, việc dữ liệu không khả dụng không phải là một lỗi mà có thể được chỉ định duy nhất. Điều này có nghĩa là các thành viên không thể chứng minh cho những người đồng đẳng khác rằng một phần dữ liệu cụ thể đang bị thiếu. Điều này xảy ra vì Bob có thể phát sóng rằng khối được gửi bởi Alice thiếu dữ liệu, nhưng khi Charlie truy vấn Alice, cô có thể cung cấp dữ liệu cho anh ta.

Làm thế nào điều này ảnh hưởng đến một chuỗi khối ngày nay?

Để trả lời câu hỏi này, hãy trở lại cấu trúc khối chung của một blockchain giống Ethereum và các loại khách hàng tồn tại trên mạng lưới blockchain nào.

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

  • Phần Header Khối: Một phần header khối nhỏ chứa bản tóm tắt và siêu dữ liệu liên quan đến các giao dịch được bao gồm trong khối.
  • Block Body: Điều này chứa tất cả dữ liệu giao dịch và chiếm đa số kích thước 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 đủ đồng bộ toàn bộ khối và xác minh tất cả các chuyển đổi trạng thái. Họ cần phải tiêu tốn một lượng tài nguyên đáng kể để kiểm tra tính hợp lệ của giao dịch và lưu trữ các khối. Mặt tích cực là những nút này không thể bắt buộc chấp nhận bất kỳ giao dịch không hợp lệ nào.

Có thể có một nhóm 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 trạng thái hiện tại của chuỗi khối và xem xem một số giao dịch, mà liên quan đến họ, đã được bao gồm trong chuỗi hay không. Lý tưởng, những khách hàng nhẹ này cũng nên được bảo vệ khỏi việc theo dõi một chuỗi chứa các giao dịch không hợp lệ. Thực tế, điều này hoàn toàn có thể thông qua những bằng chứng lừa đảo gọi là. Đó là những tin nhắn ngắn gọn cho thấy rằng một thân hình khối cụ thể bao gồm một giao dịch không hợp lệ. Bất kỳ nút đầy đủ nào cũng có thể tạo ra một bằng chứng lừa đảo như vậy, và khách hàng nhẹ do đó không cần phải tin rằng một nút đầy đủ cụ thể là trung thực. Họ chỉ cần đảm bảo rằng họ kết nối tốt với mạng lưới đồn đại đảm bảo rằng nếu có bằng chứng lừa đảo có sẵn cho một 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: nếu một 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 đủ sẽ từ chối khối một cách rõ ràng vì theo họ, nếu nó không đi kèm với thân khối thì nó không phải là một khối. Tuy nhiên, các máy khách nhẹ có thể được trình bày với chuỗi tiêu đề và không cách nào nhận ra rằng dữ liệu đang thiếu. Đồng thời, các nút đầy đủ không thể tạo ra chứng minh gian lận, vì họ sẽ thiếu dữ liệu cần thiết để tạo ra chứng minh gian lận.

Để đối phó với điều này, chúng ta cần một cơ chế cho các máy khách nhẹ để xác minh sự có sẵn của dữ liệu. Điều này sẽ đảm bảo rằng một nhà sản xuất khối ẩn dữ liệu không thể thoát khỏi bằng cách thuyết phục một máy khách nhẹ khác. Nó cũng buộc nhà sản xuất khối phải tiết lộ các phần của dữ liệu, khiến toàn bộ mạng có quyền truy cập vào toàn bộ khối theo một cách cộng tác.

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

Một người có thể nghĩ một giải pháp đơn giản là nếu tất cả các máy khách nhẹ đơn giản chỉ lấy mẫu các giao dịch ngẫu nhiên và nếu họ thấy mẫu của họ có sẵn, họ có thể tự tin rằng khối đó có sẵn. Để cho phép các nút ánh sáng truy vấn cho bất kỳ một giao dịch nào, một cách đồng đều ngẫu nhiên. Xác suất mà máy khách nhẹ truy vấn tx1 là 1/n. Vì vậy, với một xác suất lớn, Alice có thể đánh lừa các máy khách 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 máy khách nhẹ sẽ bị đánh lừa. Do tính không thể rõ ràng, các nút đầy đủ không thể chứng minh bằng bất kỳ cách nào rằng tx1 không có sẵn. Thật không may, việc tăng số lượng mẫu không làm cho tình hình này tốt hơn nhiều.

Vậy, chúng ta nên làm gì về vấn đề này?

Giải pháp cho vấn đề này nằm ở việc giới thiệu sự dư thừa vào một khối. Có một bộ sưu tập phong phú về lý thuyết mã hóa nói chung, và mã hóa xóa cụ thể, có thể giúp chúng ta giải quyết vấn đề này.

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

Nếu chúng ta buộc nhà sản xuất khối mã hóa dữ liệu giao dịch tx1, tx2, …, txn, thì để che giấu một giao dịch duy nhất, nó sẽ cần phải che giấu n+1 phần dữ liệu vì bất kỳ n phần nào cũng đủ để xây dựng toàn bộ tập hợp giao dịch. Trong trường hợp này, một số lượng truy vấn không đổi đưa ra cho khách hàng nhẹ niềm tin rất cao rằng dữ liệu cơ bản thực sự có sẵn.

Wow, vậy là đây à?

Không. Mặc dù mẹo đơn giản này làm cho việc che giấu khó khăn hơn, nhưng vẫn có khả năng rằng nhà sản xuất khối chỉ cố ý thực hiện mã hóa xóa một cách sai lầm. Tuy nhiên, một nút đầy đủ có thể xác minh xem mã hóa xóa này đã được thực hiện đúng cách và nếu không, nó có thể chứng minh điều này cho một khách hàng nhẹ. Đây là một loại chứng minh gian lận khác, giống như trong trường hợp các giao dịch độc hại ở trên. Thú vị là, cần có một hàng xóm nút đầy đủ trung thực duy nhất của một khách hàng nhẹ để chắc chắn rằng nếu khối đó là độc hại, thì nó sẽ nhận được một chứng minh gian lận. Điều này đảm bảo rằng khách hàng nhẹ có quyền truy cập vào một 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 một cách ngây thơ, kích thước của một số bằng chứng gian lận có thể ở cùng một mức với kích thước của khối. Giả định tài nguyên mà chúng tôi đặt ra cho khách hàng nhẹ ngăn cản chúng tôi sử dụng một thiết kế như vậy. Đã có những cải tiến trong lĩnh vực này bằng cách sử dụng các kỹ thuật mã hóa xóa nhiều chiều giảm kích thước của các bằng chứng gian lận với chi phí kích thước cam kết. Vì sự ngắn gọn, chúng tôi không đề cập đến những điều này nhưng bài báo nàycó một phân tích chi tiết về nó.

Vấn đề với các giải pháp dựa trên chứng minh gian lận là rằng các máy khách nhẹ không bao giờ hoàn toàn chắc chắn về bất kỳ khối nào mà nó chưa nhận được chứng minh gian lận. Ngoài ra, họ liên tục tin tưởng vào sự trung thực của các đồng nghiệp nút đầy đủ của mình. Các nút trung thực cũng cần được khuyến khích để liên tục kiểm tra khối.

Chúng tôi tập trung sự chú ý vào các 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 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ẽ xem xét về việc mã hóa khối đảm bảo rằng chỉ có những mã hóa hợp lệ mới có thể được cam kết vào chuỗi. Điều này tiêu diệt nhu cầu cho bằng chứng gian lận chứng minh lỗi mã hóa. Những giải pháp dựa trên bằng chứng tính hợp lệ này cho phép các ứng dụng sử dụng hệ thống mà không cần phải chờ đợi những bằng chứng gian lận như vậy từ các nút đầy đủ.

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

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

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

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

Một biểu đồ mô tả sơ đồ của khối

Những chi tiết tinh tế của kế hoạch cùng với việc tối ưu hóa và ước lượng chi phí chi tiết vượt ra 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 tôi thảo luận về một kế hoạch 2D ở đây, các cam kết tương tự cũng có thể được cung cấp với một kế hoạch 1D, có kích thước tiêu đề nhỏ hơn với chi phí ít song song hơn và hiệu suất lấy mẫu máy khách nhẹ. Chúng tôi sẽ đi sâu vào đề tài này trong các bài viết tiếp theo.

Các phương án thay thế khác là gì và tiếp theo là gì?

Các mã xóa chiều cao hơn và cam kết KZG không phải là cách duy nhất để tiếp cận vấn đề DA. Có những cách khác mà chúng tôi đã bỏ qua ở đây như Cây Merkle mã hóa, Cây xen kẽ được mã hóa, FRI, và các phương pháp dựa trên 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 đã đang làm việc trên một giải pháp Sẵn sàng Dữ liệu bằng cách sử dụng cam kết KZG. Trong các bài đăng sau, chúng tôi sẽ đề cập đến các chi tiết triển khai, cách bạn có thể sử dụng nó ngay hôm nay và cách chúng tôi nhắm đến việc biến đổi không gian vấn đề DA. Để biết thêm thông tin về Avail, theo dõi chúng tôi trên Twittervà tham gia cùng chúng tôiDiscord server.

Disclaimer:

  1. Bài viết này được tái bản từ [GateĐội Avail]. Tất cả bản quyền thuộc về tác giả gốc [Đội Avail]. Nếu có bất kỳ ý kiến phản đối nào về việc tái bản này, vui lòng liên hệ với [GateGate Học] team, và họ sẽ xử lý nhanh chóng.

  2. Liability Disclaimer: Quan điểm và ý kiến được thể hiện trong bài viết này chỉ thuộc về tác giả và không cấu thành bất kỳ lời khuyên đầu tư nào.

  3. Bản dịch của 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 nêu, việc sao chép, phân phối hoặc đạo văn bản dịch là cấm.

ابدأ التداول الآن
اشترك وتداول لتحصل على جوائز ذهبية بقيمة
100 دولار أمريكي
و
5500 دولارًا أمريكيًا
لتجربة الإدارة المالية الذهبية!