Dự án Mạng dữ liệu được đặt tên (sau đây gọi là NDN) là một dự án hàng đầu tập trung vào thông tin trong lĩnh vực mạng. Dự án đang xây dựng một lớp mạng, ngăn xếp giao thức tập trung vào thông báo (nghĩa là có thể định địa chỉ nội dung). Bắt đầu cách đây khoảng mười năm, được tài trợ bởi NSF và hợp tác với 10 trường đại học ở Hoa Kỳ.

IPFS và NDN chia sẻ cùng tầm nhìn về mạng nội dung có thể định địa chỉ, nhưng hoạt động theo những cách rất khác nhau. NDN là mô hình lớp mạng gốc, trong khi IPFS là mô hình lớp ứng dụng.

Với tầm nhìn chung của dự án, chúng tôi rất vui mừng về phiên giới thiệu, đặc biệt là các cuộc thảo luận và phản hồi. Tổng cộng có hơn 20 người tham gia phát biểu.

Dưới đây là tổng hợp các câu hỏi được đặt ra trong buổi thuyết trình.

Q: Kích thước khối là gì? Người dùng có thể sử dụng các khối có kích thước khác nhau không?

Đ: Kích thước khối mặc định được sử dụng là 256 KB. Có, người dùng/ứng dụng có thể sử dụng tùy chọn -s (--chunker) của lệnh ipfs add để xác định kích thước khối cũng như thuật toán khối.

Q: Merkle-Tree được tạo ra như thế nào?

Đ: Khi người dùng thêm tệp vào nút IPFS cục bộ của họ, cấu trúc Merkle-DAG (được gọi là Dữ liệu liên kết giữa các hành tinh hoặc IPLD) được tạo cục bộ. Khi một tệp được xuất bản trong mạng IPFS, tệp sẽ không được sao chép trong các nút khác. Điều này được cố ý để tránh thêm nội dung vào bộ nhớ cục bộ của khách hàng mà không có sự đồng ý của khách hàng. Thay vào đó, tệp ban đầu được phân phối bởi các tác nhân người dùng, những người xuất bản tệp lên mạng theo yêu cầu. Đồng thời, bất kỳ nút nào truy xuất từ ​​tệp gốc cũng có thể đóng vai trò là nhà cung cấp tài liệu, do đó tạo ra một mạng bộ đệm cho nội dung. Khi một tệp được xuất bản lên mạng, một "bản ghi nhà cung cấp" được đặt trong DHT để trỏ đến một nút cục bộ để truy xuất. Các tệp cũng có thể bị "khóa" nếu các máy khách khác trong mạng muốn trở thành nhà cung cấp tệp lâu dài. Nếu họ không khóa tệp, cuối cùng tệp sẽ bị "thu gom rác".

H: Làm cách nào để các tệp được thêm vào hệ thống từ quan điểm kiến ​​trúc? Đặc biệt, làm thế nào để bạn cho cả thế giới biết bạn đã thêm gì và ở đâu? Tương tự như vậy, làm cách nào để tôi biết rằng những người khác đã được thêm vào hệ thống?

Trả lời: Không có cơ chế nào trong kiến ​​trúc IPFS để theo dõi các tệp được xuất bản trên mạng. Điều này phải xảy ra "ngoài băng tần" nếu thế giới được biết về nội dung/CID mới được thêm vào. Chủ đề này liên quan nhiều đến các cuộc thảo luận đang diễn ra trong cộng đồng IPFS về một "công cụ tìm kiếm phi tập trung", nhưng cho đến nay, vẫn chưa có gì đáng kể về nó. Điều đó nói rằng, chủ đề này đã nhận được rất nhiều sự chú ý từ Phòng thí nghiệm giao thức và cộng đồng nói chung. IPNS và giao thức PubSub được hỗ trợ của nó là một phương pháp khác để phổ biến thông tin về nội dung mới xuất bản. Các ứng dụng có thể sử dụng tùy chọn này để phổ biến (nghĩa là đẩy) thông tin về nội dung mới trong chính miền của ứng dụng. Khi IPNS chạy trên DHT, nó cũng có thể thực hiện công việc dựa trên kéo.

H: Tôi có cần phải có toàn bộ cấu trúc của Merkle-Tree để lấy một phần của nó không? Nếu tôi chỉ muốn truy xuất một phần của tệp, gốc CID dường như gần như vô nghĩa.

Trả lời: Người dùng không cần phải có toàn bộ cấu trúc của Merkle-DAG để truy xuất một phần của nó. Để chỉ truy xuất một phần của Merkle-DAG (bao gồm một hoặc nhiều khối CID), người dùng cần giữ các CID cụ thể đó. Ngoài ra, bạn có thể sử dụng CID gốc và ký hiệu đường dẫn để truy cập các tệp trong Merkle-DAG, ví dụ: Qmcri6S86LuivUY4FDcM1phu5REXcFYootxn1GsRoqnFN5/path/to/some/file.png.

Hỏi: Sau khi một khối được gán CID, khối đó có bất biến không?

Trả lời: Có, một khi CID của một khối được tính toán, nó sẽ giữ nguyên mãi mãi. Như chúng ta đã biết, trong các hệ thống kiểm soát phiên bản như SVN và git, đây là khái niệm cơ bản về "Web vĩnh viễn". Chúng tôi tin rằng đây là một tài sản quan trọng của hệ thống lưu trữ và phân phối. Tất nhiên, bản thân khối không tĩnh và có thể thay đổi. Tuy nhiên, CID của tệp mới sẽ không khớp với tệp cũ nên phiên bản mới phải được thêm riêng (trừ khi nội dung được xuất bản dưới khóa công khai qua IPNS)

Q: Làm cách nào để thu hồi CID từ mạng IPFS?

Trả lời: CID như vậy là vĩnh viễn và không thể bị "thu hồi" vì nó là hàm băm của một thứ cụ thể (xem nhận xét ở trên về "web vĩnh viễn"). Người dùng không còn muốn cung cấp quyền truy cập vào một số nội dung nhất định có thể chỉ cần ngừng "cung cấp" nội dung đó, nói cách khác, ngừng xuất bản hồ sơ của nhà cung cấp tương ứng. Tuy nhiên, điều này không có nghĩa là nội dung biến mất khỏi mạng vì các máy khách khác đã truy xuất nội dung vẫn có thể có nội dung đó trong bộ đệm của họ và phục vụ nội dung đó. Ngoài ra, cổng IPFS do Phòng thí nghiệm giao thức cung cấp có danh sách từ chối CID. , các CID trong danh sách này được băm kép để bảo vệ nội dung của chúng và Cổng IPFS kiểm tra xem liệu nội dung có bị từ chối/chặn trước khi phân phối nội dung đó hay không.

H: Có thể kiểm tra trạng thái xóa của một CID cụ thể (tức là nó đã được thêm vào danh sách từ chối) chưa?

Trả lời: Để kiểm tra xem CID có nằm trong danh sách từ chối của một cổng nhất định hay không, bạn có thể thử giải quyết CID đó trên cổng và nhận mã phản hồi HTTP sẽ thông báo cho bạn nếu nó bị từ chối. Mỗi danh sách từ chối được tổ chức điều hành duy trì riêng lẻ - không có danh sách từ chối toàn cầu cho toàn bộ mạng IPFS.

H: Danh sách người từ chối dường như không thuộc về cơ sở hạ tầng phi tập trung.

Trả lời: Bất kỳ cá nhân hoặc tổ chức nào cũng có thể chạy cổng IPFS công khai và vận hành danh sách từ chối của riêng họ. Theo nghĩa này, (nội dung) của danh sách từ chối không được xác định bởi một thực thể tập trung.

H: Bản ghi IPNS được lưu ở đâu?

Đ: IPNS sử dụng cơ sở hạ tầng giống như định tuyến nội dung, cụ thể là DHT. Nhiều mã băm của khóa công khai của máy khách được đăng ký trên DHT để trỏ đến nội dung có thể thay đổi. Trong khi đó, có nhiều cách khác để phân phối các bản ghi IPNS: giao thức pubsub (cũng là một đặc điểm kỹ thuật) được gọi là Gogssub được sử dụng cho mục đích này, như một cách để phân phối các bản ghi IPNS một cách nhanh chóng. Như đã đề cập trước đó, sự khác biệt giữa IPNS so với PubSub và DHT là sự khác biệt giữa chế độ đẩy (PubSub) và kéo (DHT).

H: Làm thế nào để các nút khác biết rằng chúng có khóa chính xác cho tên?

Đ: Khi một nút tra cứu tên IPNS trên DHT, nó sẽ truy xuất các bản ghi từ tất cả các máy khách do DHT chỉ định để lưu trữ dữ liệu. Vì các bản ghi có số sê-ri, khách hàng có thể dễ dàng xác định giá trị gần đây nhất tương ứng với khóa IPNS. Ngoài ra còn có một phím tắt tra cứu DHT, trong đó thay vì đợi quá trình tra cứu hoàn tất, người dùng có thể quyết định đợi đủ số lượng bản ghi Q nhận được (hiện được đặt thành Q=16) trước khi đảm bảo có đủ thông tin để xác định bản ghi mới nhất này. ghi.

H: Nếu nút lưu trữ bản ghi IPNS ngoại tuyến, bản ghi IPNS sẽ bị mất và không thể phục vụ nếu ai đó không cập nhật bản ghi đó trong vòng 24 giờ?

Trả lời: Điều này đúng và nhà xuất bản của bản ghi IPFS (tức là CID không thay đổi) cũng vậy. Một trong hai điều có thể xảy ra: Nếu nội dung đã được yêu cầu và nó đã được một số nút khác truy xuất và lưu vào bộ đệm, thì nội dung đó có thể được phục vụ bởi nút bộ nhớ đệm.

Nếu một (hoặc một số) ứng dụng khách đã truy xuất (và lưu vào bộ nhớ cache) nội dung quyết định tiếp tục lưu/cung cấp nội dung đó, thì họ có thể "khóa" nội dung đó, nghĩa là họ đã trở thành nhà cung cấp nội dung vĩnh viễn.

H: Khi lưu trữ nội dung vào bộ đệm ẩn, làm cách nào để hệ thống biết nội dung được lưu vào bộ đệm ẩn và cách sử dụng/phân tích cú pháp nội dung đó?

Trả lời: Các máy khách có nội dung trong bộ nhớ cache cũng xuất bản bản ghi của nhà cung cấp cho DHT để tuyên bố rằng họ cũng là nhà cung cấp tất cả các mục nội dung trong bộ nhớ cache của họ.

Câu hỏi: Nội dung được lưu trong bộ nhớ cache có giống với bản gốc của nội dung không?

Đ: Cho đến ngày "thu gom rác" tiếp theo, trong thời gian đó, nội dung được lưu trong bộ nhớ đệm có thể được phân tích cú pháp và phục vụ, đồng thời hết hạn trừ khi nội dung được lưu trong bộ nhớ đệm bị "khóa" (nếu không, nội dung được sao chép vĩnh viễn cho đến khi người dùng thực hiện thay đổi). Lưu ý rằng tại thời điểm viết bài, bộ sưu tập rác được tắt theo mặc định.

H: Bạn phải biết chính xác những gì cần tìm kiếm. DHT là tốt, nhưng thật khó để biết những gì trong đó. Sự ràng buộc giữa CID và thông tin nhận dạng thực diễn ra ở đâu?

Đ: IPFS là một hệ thống tệp phân tán để sử dụng trong khám phá nội dung hướng tới người dùng cuối (ví dụ: cách HTTP hiện được sử dụng để đánh địa chỉ/lưu trữ các trang web cho dịch vụ tìm kiếm của Google). IPFS quản lý việc cung cấp, lưu trữ và tìm nạp nội dung cho một CID cụ thể; phần còn lại (kết nối người dùng với CID được liên kết với ứng dụng đó hoặc tìm ứng dụng ngay từ đầu) phải xảy ra ở một lớp bên trên chính IPFS.

H: Khi bắt đầu cuộc trò chuyện, bạn đã đề cập rằng mục đích là để loại bỏ lòng tin khỏi mạng (tức là các thực thể bên ngoài). Bạn có thể xây dựng? Làm thế nào bạn có thể tin tưởng rằng một nội dung nhất định sẽ được xuất bản với một khóa nhất định?

Đ: Việc đặt tên nội dung theo hàm băm của chính nội dung đó và xuất bản nội dung đó trong mạng P2P phân tán về cơ bản khắc phục được một số vấn đề liên quan đến việc đặt niềm tin vào các thực thể bên ngoài, chẳng hạn như các thực thể lưu trữ nội dung và phân giải nội dung. Nội dung tự xác thực, vì vậy nó có thể được xác minh cục bộ. Miễn là nội dung được ký bởi khóa riêng của nhà xuất bản, người tiêu dùng nội dung có thể xác minh tính xác thực của nội dung mà không cần dựa vào các thực thể bên ngoài.

Cảm ơn tất cả mọi người đã tham dự buổi nói chuyện này, và cảm ơn NDN đã tổ chức sự kiện này và mời chúng tôi!