โครงการ Named Data Networking (ต่อไปนี้จะเรียกว่า NDN) เป็นโครงการเรือธงที่เน้นข้อมูลเป็นศูนย์กลางในด้านเครือข่าย โปรเจกต์กำลังสร้างเลเยอร์เครือข่าย โปรโตคอลสแต็กที่เน้นข้อความเป็นศูนย์กลาง (เช่น ระบุที่อยู่เนื้อหาได้) เริ่มต้นเมื่อประมาณ 10 ปีที่แล้ว โดยได้รับทุนสนับสนุนจาก NSF และร่วมมือกับมหาวิทยาลัย 10 แห่งในสหรัฐอเมริกา

IPFS และ NDN แบ่งปันวิสัยทัศน์เดียวกันของเครือข่ายที่อยู่เนื้อหาได้ แต่ทำงานในรูปแบบที่แตกต่างกันมาก NDN เป็นโมเดลเลเยอร์เครือข่ายดั้งเดิม ในขณะที่ IPFS เป็นโมเดลเลเยอร์ของแอปพลิเคชัน

ด้วยวิสัยทัศน์ร่วมกันของโครงการ เรารู้สึกตื่นเต้นมากกับช่วงการแสดงโชว์ โดยเฉพาะอย่างยิ่งการอภิปรายและข้อเสนอแนะ รวมกว่า 20 คนเข้าร่วมในการปราศรัย

ด้านล่างนี้คือบทสรุปของคำถามที่ถามในระหว่างการนำเสนอ

ถาม: ขนาดบล็อกคืออะไร? ผู้ใช้สามารถใช้บล็อคขนาดต่างๆ ได้หรือไม่?

ตอบ: ขนาดบล็อกเริ่มต้นที่ใช้คือ 256 KB ได้ ผู้ใช้/แอปพลิเคชันสามารถใช้อ็อพชัน -s (--chunker) ของคำสั่ง ipfs add เพื่อกำหนดขนาดก้อนและอัลกอริทึมของก้อน

ถาม: Merkle-Tree ถูกสร้างขึ้นอย่างไร

ตอบ: เมื่อผู้ใช้เพิ่มไฟล์ไปยังโหนด IPFS ภายในเครื่อง โครงสร้าง Merkle-DAG (รู้จักกันในชื่อ Interplanetary Linked Data หรือ IPLD) จะถูกสร้างขึ้นภายในเครื่อง เมื่อเผยแพร่ไฟล์ในเครือข่าย IPFS ไฟล์จะไม่ถูกจำลองแบบในโหนดอื่น นี่เป็นเจตนาที่จะหลีกเลี่ยงการเพิ่มเนื้อหาลงในที่จัดเก็บในเครื่องของลูกค้าโดยไม่ได้รับความยินยอมจากลูกค้า ไฟล์จะถูกแจกจ่ายในขั้นต้นโดยตัวแทนผู้ใช้ ซึ่งเผยแพร่ไปยังเครือข่ายเมื่อมีการร้องขอ ในเวลาเดียวกัน โหนดใดๆ ที่ดึงข้อมูลมาจากไฟล์ต้นฉบับยังสามารถทำหน้าที่เป็นผู้ให้บริการวัสดุ ซึ่งจะเป็นการสร้างเครือข่ายแคชสำหรับเนื้อหา เมื่อมีการเผยแพร่ไฟล์ไปยังเครือข่าย "บันทึกผู้ให้บริการ" จะถูกวางไว้ใน DHT เพื่อชี้ไปยังโหนดภายในเครื่องเพื่อดึงข้อมูล ไฟล์ยังสามารถ "ล็อก" ได้หากไคลเอนต์อื่นในเครือข่ายต้องการเป็นผู้ให้บริการไฟล์อย่างถาวร หากพวกเขาไม่ล็อกไฟล์ ไฟล์นั้นจะถูก "เก็บขยะ" ในที่สุด

ถาม: ไฟล์จะเพิ่มเข้าไปในระบบจากมุมมองทางสถาปัตยกรรมได้อย่างไร โดยเฉพาะอย่างยิ่ง คุณจะบอกให้โลกรู้ว่าคุณเพิ่มอะไรและที่ไหน เช่นเดียวกัน ฉันจะรู้ได้อย่างไรว่าคนอื่นถูกเพิ่มเข้ามาในระบบแล้ว?

คำตอบ: ไม่มีกลไกในสถาปัตยกรรม IPFS เพื่อติดตามไฟล์ที่เผยแพร่ในเครือข่าย สิ่งนี้จะต้องเกิดขึ้น "นอกวง" หากโลกต้องรับรู้ถึงเนื้อหา/CID ที่เพิ่มเข้ามาใหม่ หัวข้อนี้เกี่ยวข้องกับการอภิปรายอย่างต่อเนื่องในชุมชน IPFS เกี่ยวกับ "เสิร์ชเอ็นจิ้นแบบกระจายอำนาจ" แต่จนถึงตอนนี้ ยังไม่มีอะไรเป็นรูปธรรม อย่างไรก็ตาม หัวข้อนี้ได้รับความสนใจอย่างมากจาก Protocol Labs และชุมชนโดยรวม IPNS และโปรโตคอล PubSub ที่รองรับ เป็นอีกวิธีหนึ่งในการเผยแพร่ข้อมูลเกี่ยวกับเนื้อหาที่เผยแพร่ใหม่ แอปพลิเคชันสามารถใช้ตัวเลือกนี้เพื่อเผยแพร่ (เช่น พุช) ข้อมูลเกี่ยวกับเนื้อหาใหม่ภายในโดเมนของแอปพลิเคชันเอง เมื่อ IPNS ทำงานบน DHT ก็สามารถทำงานตามการดึงได้เช่นกัน

ถาม: ฉันจำเป็นต้องมีโครงสร้างทั้งหมดของ Merkle-Tree เพื่อเรียกคืนส่วนหนึ่งของมันหรือไม่ หากฉันต้องการดึงไฟล์เพียงบางส่วน รูท CID นั้นแทบไม่มีความหมายเลย

ตอบ: ผู้ใช้ไม่จำเป็นต้องมีโครงสร้างทั้งหมดของ Merkle-DAG เพื่อดึงข้อมูลบางส่วน ในการดึงข้อมูล Merkle-DAG เพียงบางส่วน (ประกอบด้วยบล็อก CID หนึ่งบล็อกขึ้นไป) ผู้ใช้จำเป็นต้องเก็บ CID เหล่านั้นไว้ นอกจากนี้ คุณสามารถใช้รูต CID และสัญลักษณ์พาธเพื่อเข้าถึงไฟล์ใน Merkle-DAG เช่น Qmcri6S86LuivUY4FDcM1phu5REXcFYootxn1GsRoqnFN5/path/to/some/file.png

ถาม: เมื่อบล็อกถูกกำหนดให้เป็น CID แล้ว บล็อกนั้นจะเปลี่ยนรูปไม่ได้หรือไม่

คำตอบ: ใช่ เมื่อคำนวณ CID ของบล็อกแล้ว ก็จะคงเดิมตลอดไป อย่างที่เราทราบกันดีว่าในระบบควบคุมเวอร์ชันเช่น SVN และ git นี่เป็นแนวคิดพื้นฐานของ "เว็บถาวร" เราเชื่อว่านี่เป็นคุณสมบัติที่สำคัญของระบบจัดเก็บและจัดส่ง แน่นอนว่าบล็อกนั้นไม่คงที่และสามารถเปลี่ยนแปลงได้ อย่างไรก็ตาม CID ของไฟล์ใหม่จะไม่ตรงกับไฟล์เก่า ดังนั้นจึงต้องเพิ่มเวอร์ชันใหม่แยกต่างหาก (เว้นแต่เนื้อหาจะเผยแพร่ภายใต้คีย์สาธารณะผ่าน IPNS)

ถาม: จะยกเลิก CID จากเครือข่าย IPFS ได้อย่างไร

ตอบ: CID ดังกล่าวเป็นแบบถาวรและไม่สามารถ "เพิกถอน" ได้ เนื่องจากเป็นแฮชของบางสิ่งที่เฉพาะเจาะจง (ดูความคิดเห็นด้านบนใน "เว็บถาวร") ผู้ใช้ที่ไม่ต้องการให้เข้าถึงเนื้อหาบางอย่างอีกต่อไปสามารถหยุด "จัดหา" เนื้อหานั้น หรืออีกนัยหนึ่งคือหยุดเผยแพร่บันทึกของผู้ให้บริการที่เกี่ยวข้อง อย่างไรก็ตาม ไม่ได้หมายความว่าเนื้อหาจะหายไปจากเครือข่าย เนื่องจากไคลเอนต์อื่นที่ดึงเนื้อหามาอาจยังคงมีเนื้อหานั้นอยู่ในแคชและให้บริการ นอกจากนี้ เกตเวย์ IPFS ที่ให้บริการโดย Protocol Labs ยังมีรายการปฏิเสธ CID CID ในรายการนี้ได้รับการแฮชสองครั้งเพื่อป้องกันเนื้อหา และเกตเวย์ IPFS จะตรวจสอบเพื่อดูว่าเนื้อหาถูกปฏิเสธ/บล็อกหรือไม่ก่อนที่จะให้บริการ

ถาม: เป็นไปได้หรือไม่ที่จะตรวจสอบสถานะการลบ CID เฉพาะเจาะจง (เช่น ได้ถูกเพิ่มไปยังรายการปฏิเสธ)

ตอบ: ในการตรวจสอบว่า CID อยู่ในรายการปฏิเสธสำหรับเกตเวย์ที่กำหนดหรือไม่ คุณสามารถลองแก้ไข CID นั้นบนเกตเวย์และรับรหัสตอบกลับ HTTP ซึ่งจะแจ้งให้คุณทราบหากถูกปฏิเสธ รายการปฏิเสธแต่ละรายการจะได้รับการดูแลแยกกันโดยองค์กรที่ดำเนินการ - ไม่มีรายการปฏิเสธส่วนกลางสำหรับเครือข่าย IPFS ทั้งหมด

ถาม: รายชื่อผู้ปฏิเสธดูเหมือนจะไม่อยู่ในโครงสร้างพื้นฐานแบบกระจายอำนาจ

ตอบ: บุคคลหรือองค์กรใดๆ สามารถเรียกใช้เกตเวย์ IPFS สาธารณะและดำเนินการรายการปฏิเสธของตนเองได้ ในแง่นี้ (เนื้อหา) ของรายการปฏิเสธไม่ได้ถูกกำหนดโดยเอนทิตีส่วนกลาง

ถาม: บันทึก IPNS ถูกเก็บไว้ที่ไหน

ตอบ: IPNS ใช้โครงสร้างพื้นฐานเดียวกันกับการกำหนดเส้นทางเนื้อหา ซึ่งก็คือ DHT คีย์สาธารณะของไคลเอนต์หลายแฮชถูกลงทะเบียนบน DHT เพื่อชี้ไปยังเนื้อหาที่ไม่แน่นอน ในขณะเดียวกัน มีวิธีอื่นๆ ในการเผยแพร่บันทึก IPNS: โปรโตคอล pubsub (รวมถึงข้อมูลจำเพาะ) ที่เรียกว่า gossipsub ถูกนำมาใช้เพื่อจุดประสงค์นี้ เพื่อเป็นวิธีเผยแพร่บันทึก IPNS อย่างรวดเร็ว ดังที่ได้กล่าวไว้ก่อนหน้านี้ ความแตกต่างระหว่าง IPNS บน PubSub และ DHT คือความแตกต่างระหว่างโหมดพุช (PubSub) และโหมดดึง (DHT)

ถาม: โหนดอื่นๆ รู้ได้อย่างไรว่าตนมีคีย์ที่ถูกต้องสำหรับชื่อ

ตอบ: เมื่อโหนดค้นหาชื่อ IPNS บน DHT โหนดจะดึงบันทึกจากไคลเอนต์ทั้งหมดที่ระบุโดย DHT เพื่อจัดเก็บข้อมูล เนื่องจากเร็กคอร์ดมีหมายเลขซีเรียล ไคลเอนต์จึงสามารถระบุค่าล่าสุดที่สอดคล้องกับคีย์ IPNS ได้อย่างง่ายดาย นอกจากนี้ยังมีทางลัดการค้นหา DHT ซึ่งแทนที่จะรอให้การค้นหาเสร็จสิ้น ผู้ใช้สามารถตัดสินใจที่จะรอให้ครบองค์ประชุม Q ของการรับเรกคอร์ด (ปัจจุบันตั้งค่าเป็น Q=16) ก่อนตรวจสอบให้แน่ใจว่ามีข้อมูลเพียงพอที่จะระบุข้อมูลล่าสุดนี้ บันทึก.

ถาม: หากโหนดที่จัดเก็บระเบียน IPNS ออฟไลน์ ระเบียน IPNS จะสูญหายและไม่สามารถให้บริการได้หากมีคนไม่อัปเดตภายใน 24 ชั่วโมง

ตอบ: สิ่งนี้ถูกต้อง และผู้เผยแพร่บันทึก IPFS ก็เช่นกัน (เช่น CID ที่ไม่เปลี่ยนรูป) หนึ่งในสองสิ่งนี้สามารถเกิดขึ้นได้: หากเนื้อหาได้รับการร้องขอ และเนื้อหานั้นถูกเรียกค้นและแคชโดยโหนดอื่นแล้ว เนื้อหานั้นสามารถให้บริการโดยโหนดแคชได้

หากลูกค้ารายหนึ่ง (หรือบางราย) ที่ดึงข้อมูล (และแคชไว้) เนื้อหาตัดสินใจที่จะบันทึก/ให้บริการต่อไป พวกเขาสามารถ "ล็อค" เนื้อหาได้ ซึ่งหมายความว่าพวกเขาได้กลายเป็นผู้ให้บริการเนื้อหาอย่างถาวร

ถาม: เมื่อทำการแคชเนื้อหา ระบบจะรู้ได้อย่างไรว่าสิ่งใดถูกแคช และจะใช้/แยกวิเคราะห์อย่างไร

คำตอบ: ไคลเอนต์ที่แคชเนื้อหายังเผยแพร่บันทึกของผู้ให้บริการไปยัง DHT เพื่อประกาศว่าพวกเขาเป็นผู้ให้บริการรายการเนื้อหาทั้งหมดในแคชด้วย

ถาม: เนื้อหาที่แคชไว้เหมือนกับสำเนาต้นฉบับของเนื้อหาหรือไม่

ตอบ: จนกว่าจะถึงวัน "รวบรวมขยะ" ถัดไป ในช่วงเวลาดังกล่าว เนื้อหาที่แคชสามารถถูกแยกวิเคราะห์และให้บริการ และจะหมดอายุ เว้นแต่ว่าเนื้อหาที่แคชไว้จะถูก "ล็อค" (มิฉะนั้น จะถูกคัดลอกอย่างถาวรจนกว่าผู้ใช้จะทำการเปลี่ยนแปลง) โปรดทราบว่าในขณะที่เขียน การรวบรวมขยะจะถูกปิดโดยค่าเริ่มต้น

ถาม: คุณต้องรู้แน่ชัดว่าจะมองหาอะไร DHT นั้นดี แต่ก็ยากที่จะรู้ว่ามีอะไรอยู่ในนั้น การผูกมัดระหว่าง CID และข้อมูลระบุตัวตนที่แท้จริงเกิดขึ้นที่ใด

ตอบ: IPFS เป็นระบบไฟล์แบบกระจายสำหรับใช้ในการค้นหาเนื้อหาที่ผู้ใช้ปลายทางเห็น (เช่น วิธีการใช้ HTTP ในปัจจุบันเพื่อระบุที่อยู่/โฮสต์ไซต์สำหรับบริการค้นหาของ Google) IPFS จัดการการให้บริการ จัดเก็บ และดึงเนื้อหาสำหรับ CID เฉพาะ ส่วนที่เหลือ (เชื่อมต่อผู้ใช้กับ CID ที่เชื่อมโยงกับแอปนั้นหรือค้นหาแอปตั้งแต่แรก) จะต้องสร้างเลเยอร์เหนือ IPFS เอง

ถาม: ในตอนต้นของการสนทนา คุณกล่าวว่าจุดประสงค์คือเพื่อลบความเชื่อใจออกจากเครือข่าย (เช่น หน่วยงานภายนอก) คุณสามารถอธิบายรายละเอียดได้หรือไม่? คุณจะเชื่อได้อย่างไรว่าเนื้อหาบางอย่างจะได้รับการเผยแพร่ด้วยรหัสเฉพาะ

ตอบ: การตั้งชื่อเนื้อหาตามแฮชของตัวเองและเผยแพร่ในเครือข่าย P2P แบบกระจายจะช่วยแก้ปัญหาบางอย่างที่เกี่ยวข้องกับการไว้วางใจในหน่วยงานภายนอก เช่น การโฮสต์เนื้อหาและเอนทิตีการแก้ไขเนื้อหา เนื้อหามีการตรวจสอบความถูกต้องด้วยตนเอง ดังนั้นจึงสามารถตรวจสอบได้ในเครื่อง ตราบใดที่เนื้อหาได้รับการลงนามโดยรหัสส่วนตัวของผู้เผยแพร่ ผู้บริโภคเนื้อหาสามารถตรวจสอบความถูกต้องของเนื้อหาได้โดยไม่ต้องพึ่งพาหน่วยงานภายนอก

ขอขอบคุณทุกคนที่เข้าร่วมการพูดคุยครั้งนี้ และ NDN ที่จัดกิจกรรมนี้และเชิญเรา!