Avail: Lớp Khả năng Truy cập Dữ liệu mở rộng do Polygon phát hành

Original Title: "Tìm hiểu về Avail, Một Lớp Dữ Liệu Có Khả Năng Mở Rộng mới của Polygon"

Original Author: Polygon

Original Source: Road to DeFi

Avail — một phần quan trọng của cách mà tương lai của blockchain hoạt động. Avail là một blockchain thông dụng, có khả năng mở rộng, tập trung vào dữ liệu có sẵn, phù hợp cho các giải pháp chuỗi độc lập, chuỗi phụ và mở rộng ngoài chuỗi.

Avail cung cấp một lớp dữ liệu có sẵn mạnh mẽ thông qua việc sử dụng các cơ sở toán học cực kỳ an toàn — sử dụng mã mãnh đời với các đổi mới quan trọng để kiểm tra tính sẵn có của dữ liệu — chúng tôi sử dụng Cam kết Đa thức Kate để tạo ra một giải pháp dữ liệu có sẵn hai chiều, tránh sự chứng minh gian lận, không cần giả thiết đa số trung thực, và không phụ thuộc vào nút toàn trung thực để có niềm tin về sự có sẵn của dữ liệu.

Avail cung cấp một lớp dữ liệu có sẵn thông dụng mà các môi trường thực thi khác nhau có thể sử dụng, chẳng hạn như chuỗi độc lập, chuỗi phụ và giải pháp mở rộng ngoài chuỗi. Trong tương lai, nó sẽ hỗ trợ nhiều loại thử nghiệm liên quan đến môi trường thực thi và triển khai cuối cùng mà không cần đội ngũ và dự án phải khởi động bản thân về mặt an toàn. Các chuỗi được tạo ra bằng Polygon SDK, Cosmos SDK hoặc Substrate có thể hưởu lợi từ việc sử dụng Avail cho mục đích này.

Avail thực hiện việc tách rời việc thực thi giao dịch và tính hợp lệ từ lớp đồng thuận, do đó đồng thuận chỉ chịu trách nhiệm a) sắp xếp giao dịch và b) đảm bảo tính sẵn có của dữ liệu.

Mục Tiêu Chính

· Cho phép chuỗi độc lập hoặc chuỗi phụ với môi trường thực thi tùy ý, để hướng dẫn tính an toàn của người xác minh thông qua việc đảm bảo tính sẵn có của dữ liệu giao dịch mà không cần tạo và quản lý bộ xác minh riêng

· Cung cấp khả năng mở rộng thông qua các giải pháp Layer 2 như Validiums bằng cách sử dụng Avail làm lớp dữ liệu có sẵn ngoài chuỗi

Kể từ cuối năm 2020, chúng tôi đã tiến hành nghiên cứu về Avail một cách bí mật, hiện tại, nó đang ở giai đoạn Devnet. Mạng thử nghiệm đang được phát triển. Thêm thông tin chi tiết về vấn đề, kiến trúc và giải pháp có thể được tìm thấy trong tài liệu tham khảo, bao gồm cả tham khảo về kho lưu trữ mã nguồn.

Lịch Sử  

Trong hệ sinh thái ngày nay tương tự Ethereum, có ba loại nút chính:

· Nút xác thực

· Nút đầy đủ

· Khách hàng nhẹ

Một khối được gắn vào chuỗi bằng nút xác thực, nút này thu thập giao dịch từ bể bộ nhớ, thực thi chúng, tạo ra khối trước khi lan truyền qua mạng. Khối này chứa một tiêu đề khối nhỏ, bao gồm tóm tắt và siêu dữ liệu liên quan đến giao dịch có trong khối. Các nút đầy đủ trên toàn bộ mạng nhận khối này và xác minh tính đúng đắn của nó bằng cách thực thi lại các giao dịch có trong khối đó. Khách hàng nhẹ chỉ nhận tiêu đề khối và chi tiết giao dịch từ các nút đầy đủ láng giềng khi cần. Siêu dữ liệu trong tiêu đề khối cho phép khách hàng nhẹ xác minh tính trung thực của chi tiết giao dịch nhận.

Mặc dù kiến trúc này rất an toàn và đã được triển khai rộng rãi, nhưng nó đối mặt với một số hạn chế thực tế nghiêm trọng. Vì khách hàng nhẹ không tải toàn bộ khối, họ có thể bị lừa để chấp nhận khối mà dữ liệu cơ bản không khả dụng. Người tạo khối có thể đưa các giao dịch độc hại vào một khối mà không tiết lộ toàn bộ nội dung cho mạng. Điều này được gọi là vấn đề về khả dụng dữ liệu, một mối đe dọa nghiêm trọng đối với khách hàng nhẹ. Hơn nữa, việc dữ liệu không khả dụng là một loại lỗi không thể dánh sách, giúp chúng ta không thể áp dụng cấu trúc chứng minh lừa đảo, cho phép nút đầy đủ thông báo cho khách hàng nhẹ cách mạng dữ liệu bị mất một cách thuyết phục.

So sánh Blockchain hiện tại với Polygon Avail

Ngược lại, Avail chọn một phương pháp khác để giải quyết vấn đề này — nó không xác minh trạng thái ứng dụng, mà tập trung vào đảm bảo tính khả dụng của dữ liệu giao dịch được công bố và đảm bảo thứ tự các giao dịch. Chỉ khi dữ liệu đằng sau khối được khả dụng, khối có sự nhất quán mới được coi là hợp lệ. Điều này nhằm ngăn chặn người tạo khối phát hành tiêu đề khối mà không phát hành dữ liệu đằng sau, điều này sẽ ngăn người dùng đọc các giao dịch cần thiết để tính toán trạng thái ứng dụng của họ.

Avail đơn giản hóa vấn đề xác minh khối thành xác minh khả dụng dữ liệu, điều này có thể hoàn thành một cách hiệu quả với chi phí cố định thông qua kiểm tra khả dụng dữ liệu. Kiểm tra khả dụng dữ liệu tận dụng mã mất mát, được sử dụng rộng rãi trong thiết kế dữ liệu dự trữ.

Kiểm tra khả dụng dữ liệu yêu cầu mỗi khách hàng nhẹ lấy mẫu một lượng rất nhỏ các khối ngẫu nhiên từ mỗi khối trên chuỗi. Một nhóm khách hàng nhẹ có thể tổ chức cách này để tập trung lấy mẫu cả chuỗi khối. Một mô hình tư duy tốt là hệ thống chia sẻ tập tin p2p như Torrent, nơi các nút khác nhau thường chỉ lưu trữ một số phần của tập tin.

Vui lòng lưu ý rằng các công nghệ này sẽ được sử dụng rộng rãi trong Ethereum 2.0 và hệ thống Celestia (trước đây được gọi là LazyLedger).

Điều này cũng dẫn đến một kết quả thú vị: càng có nhiều nút không đồng thuận tồn tại trong mạng, bạn càng có thể an toàn sở hữu kích thước khối (cũng như khả năng xử lý). Đây là một thuộc tính hữu ích vì điều đó có nghĩa rằng các nút không đồng thuận cũng có thể đóng góp vào khả năng xử lý và an ninh của mạng.

KZG Thỏa Thuận Dựa Trên Cam Kết  

Trong hệ thống dựa trên KZG Cam Kết được sử dụng trong Avail, có ba đặc điểm chính:

· Dữ liệu dự phòng làm cho người tạo khối khó che giấu bất kỳ phần nào của khối.

· Cam kết vô lừa đảm bảo mã sửa lỗi chính xác

· Cam kết vector, cho phép nút đầy đủ sử dụng bằng chứng gọn để thuyết phục nút nhẹ chứa giao dịch.

Để đơn giản, toàn bộ dữ liệu trong một khối được sắp xếp thành một ma trận hai chiều. Bằng cách mã hóa xóa từng cột của ma trận để làm tăng gấp đôi kích thước cột ban đầu, dữ liệu dự phòng được giới thiệu. Cam kết Kate được sử dụng để cam kết từng hàng, và cam kết được bao gồm trong tiêu đề khối. Hệ thống này có thể dễ dàng bắt giữ các cố gắng giấu dữ liệu, vì bất kỳ khách hàng nhẹ nào chỉ có thể truy vấn một ô ngẫu nhiên trong ma trận và nhận được một chứng minh ngắn có thể kiểm tra dựa trên tiêu đề khối (nhờ cam kết Kate). Dữ liệu dự phòng buộc người tạo khối phải giấu phần lớn của khối, ngay cả khi họ chỉ muốn giấu một giao dịch đơn lẻ, làm cho nó dễ bị bắt gặp trong một mẫu ngẫu nhiên. Chúng ta tránh được sự cần thiết của chứng minh lừa đảo, bởi vì sự ràng buộc của cam kết Kate làm cho việc xây dựng cam kết sai lầm bởi người tạo khối mà không bị phát hiện trên mặt tính toán là cực kỳ không khả thi. Ngoài ra, có thể tính toán cam kết mở rộng hàng bằng tính chất đồng cấu của hệ thống cam kết KZG.

  Hệ Thống Cam Kết KZG

Mặc dù chúng tôi chỉ đề cập đến các tính năng chính được xây dựng của Avail ở đây, nhưng còn có các tính năng khác như truy xuất dữ liệu một phần và bảo đảm khả dụng cộng tác. Chúng tôi đã bỏ qua các chi tiết ở đây và sẽ thảo luận lại chúng trong các bài viết sau này.

Bây giờ có lẽ là thời điểm tốt để đưa ra một ví dụ và thực hành một ứng dụng thực tế. Giả sử một ứng dụng mới muốn triển khai một chuỗi độc lập dành riêng cho ứng dụng. Nó sử dụng SDK Polygon hoặc bất kỳ nền tảng nào khác tương tự (như Cosmos SDK hoặc Substrate) để khởi động một chuỗi PoS mới và nhúng logic doanh nghiệp vào đó. Nhưng nó đối mặt với vấn đề khởi đầu an ninh đủ bằng cách stake từ các validator.

Để tránh tình huống này, nó sử dụng Avail để sắp xếp giao dịch và tính khả dụng dữ liệu. Người dùng ứng dụng gửi giao dịch vào chuỗi SDK Polygon, những giao dịch này sẽ tự động chuyển tiếp đến Avail, nơi chúng tự quản lí đơn hàng. Các giao dịch được sắp xếp được một (hoặc nhiều) người điều hành chọn lựa và xây dựng trạng thái cuối cùng của ứng dụng dựa trên logic doanh nghiệp. Người dùng ứng dụng có thể yên tâm rằng dữ liệu được sắp xếp sẵn có và họ có thể tự mình xây dựng lại trạng thái ứng dụng bất cứ lúc nào, giúp họ có thể sử dụng chuỗi mà Avail cung cấp bảo đảm an toàn mạnh mẽ.

Mặc dù ví dụ trên đề cập đến việc sử dụng Avail để đảm bảo an ninh cho một chuỗi độc lập mới, nhưng nền tảng này là phổ quát, bất kỳ chuỗi hiện có nào cũng có thể sử dụng nó để đảm bảo tính khả dụng dữ liệu. Trong phần tiếp theo, chúng tôi sẽ đề cập ngắn gọn đến cách Avail giúp mở rộng tổng hợp hiện tại trên Ethereum.  

Giải thích về tính khả dụng dữ liệu của giải pháp mở rộng dưới chuỗi của chuỗi Ethereum  

Đã được đề xuất nhiều loại giải pháp Layer 2 Ethereum, chẳng hạn như Optimistic Rollup, ZK Rollup và Validiums. Những giải pháp này di chuyển thực thi vào dưới chuỗi, đồng thời đảm bảo xác thực ứng dụng và tính khả dụng dữ liệu trên chuỗi. Mặc dù kiến trúc dựa trên thực thi dưới chuỗi đã nâng cao khả năng xử lý, nhưng nó vẫn bị giới hạn bởi lượng dữ liệu mà chuỗi trung tâm như Ethereum có thể xử lý. Điều này là vì mặc dù thực thi diễn ra dưới chuỗi, nhưng xác thực hoặc giải quyết tranh chấp vẫn chặt chẽ diễn ra trên chuỗi. Dữ liệu giao dịch được gửi lên Ethereum dưới dạng calldata để đảm bảo dữ liệu có sẵn để tái tạo trong tương lai. Điều này rất quan trọng.

Trong trường hợp của Optimistic Rollup, người vận hành có thể gửi các giao dịch không hợp lệ, sau đó tấn công một phần khối trong toàn bộ chuỗi. Bằng cách này, các nút đầy đủ trong hệ thống sẽ không thể xác minh xem tuyên bố đã nộp có chính xác hay không. Bởi vì không có dữ liệu, họ sẽ không thể tạo ra bất kỳ bằng chứng gian lận/challenge nào để chứng minh rằng tuyên bố đó thật sự không hợp lệ.

Trong trường hợp của Rollup dựa trên Zero-Knowledge, tính bền vững của ZKP đảm bảo các giao dịch được chấp nhận là hợp lệ. Tuy nhiên, ngay cả khi có sự đảm bảo như vậy, việc không tiết lộ dữ liệu hỗ trợ giao dịch cũng có thể gây ra những tác động phụ nghiêm trọng.

Điều này có thể dẫn đến việc các bên xác minh khác không thể tính toán trạng thái hiện tại của hệ thống, cũng như người dùng bị loại khỏi hệ thống và số dư của họ bị đóng băng vì họ không có thông tin cần thiết về số dư đó (chứng kiến).

Chúng tôi nhận thức rằng, để đạt được hiệu suất xử lý cao hơn, chúng ta không chỉ cần đặt việc thực thi nằm ngoài chuỗi, mà còn cần có một lớp lưu trữ dữ liệu có thể mở rộng để đảm bảo tính khả dụng của dữ liệu.

Thiết kế blockchain này cần giải quyết các phần sau:

· Lưu trữ và sắp xếp dữ liệu: Phần này sẽ nhận dữ liệu giao dịch và sắp xếp chúng mà không cần thực thi nào. Sau đó nó sẽ lưu trữ dữ liệu và đảm bảo tính khả dụng đầy đủ của dữ liệu theo cách phân tán. Điều này là rất quan trọng cho Avail.

· Thực thi: Bộ phận thực thi nên lấy các giao dịch được sắp xếp từ Avail và thực thi chúng. Nó nên tạo ra một điểm kiểm tra/khẳng định/chứng minh và gửi nó cho lớp xác minh dữ liệu. Chúng tôi gọi đây là lớp thực thi.

· Xác minh/Giải quyết tranh chấp: Phần này đại diện cho chuỗi chính mà hệ thống gắn kết vào. Tính an toàn của thiết kế phụ thuộc vào tính bền vững và thuộc tính an toàn của phần này. Các điểm kiểm tra/khẳng định/chứng minh được nộp bởi lớp thực thi sẽ được xử lý bởi phần này để đảm bảo rằng chỉ chấp nhận các chuyển đổi trạng thái hợp lệ trong hệ thống (với điều kiện là dữ liệu khả dụng). Chúng tôi gọi phần này là lớp xác minh dữ liệu.

Liên kết bài gốc

Chào mừng bạn tham gia cộng đồng chính thức của BlockBeats:

Nhóm Telegram đăng ký: https://t.me/theblockbeats

Nhóm Telegram thảo luận: https://t.me/BlockBeats_App

Tài khoản Twitter chính thức: https://twitter.com/BlockBeatsAsia