Nostr2.0: เป็นชั้นจัดเก็บข้อมูลภายใต้เครือข่าย Bitcoin Layer 2

ผู้แต่ง: Colby Serpa ผู้เรียบเรียง: DAOrayaki

Nostr 2.0 อาจสามารถต่อยอดจาก Bitcoin เป็นเลเยอร์ 2 ซึ่งให้การจัดเก็บข้อมูลนอกเครือข่ายที่ปลอดภัย เช่นเดียวกับที่ Lightning Network ให้การชำระเงินนอกเครือข่ายทันทีในรูปแบบเลเยอร์ 2

บทความนี้จะอธิบายวิธีที่รีเลย์ Nostr ซิงโครไนซ์ข้อมูลในขณะที่รักษาลักษณะที่มีน้ำหนักเบา ทำให้ผู้ใช้สามารถเลือกลบข้อมูลได้ ซึ่งไม่มีในบล็อกเชนเลเยอร์ 1 ในขณะเดียวกัน เมื่อเทียบกับการจัดเก็บข้อมูลจำนวนมากในบล็อกเชน Bitcoin เนื่องจากความจุและความเร็วที่จำกัดของบล็อก Bitcoin การจัดเก็บข้อมูลโดยใช้รีเลย์ของ Nostr อาจถูกกว่า

การออกแบบวิทยาการคอมพิวเตอร์อย่างง่ายต่อไปนี้ช่วยปรับปรุงคุณสมบัติการกระจายของเครือข่าย Nostr ภายใต้เกณฑ์ทฤษฎีบท CAP ที่เป็นมาตรฐาน CAP ย่อมาจากความสอดคล้อง ความพร้อมใช้งาน และความทนทานต่อพาร์ติชัน

**Nostr รีเลย์ไม่รู้ว่าไฟล์คอนฟิกูเรชันไม่สมบูรณ์ รีเลย์ขาดความสม่ำเสมอ (C ในทฤษฎีบท CAP) **

รีเลย์ขาดความสม่ำเสมอ (C ในทฤษฎีบท CAP)

ความสอดคล้องหมายความว่าฐานข้อมูลที่ซิงโครไนซ์ในคอมพิวเตอร์แต่ละเครื่องจะเหมือนกัน Nostr รีเลย์ไม่สามารถทำการซิงโครไนซ์แบบลดความน่าเชื่อถือในลักษณะที่คล้ายกับวิธีที่บล็อกเชนซิงโครไนซ์ข้อมูลทีละบล็อก ซึ่งแตกต่างจากโหนดเต็มของ Bitcoin ฐานข้อมูลที่จัดเก็บโดย Nostr relay มักไม่สมบูรณ์ นอกเหนือจากการร้องขอโพสต์ทั้งหมดที่ลงนามโดยผู้ใช้เฉพาะแบบสุ่มสี่สุ่มห้าแล้ว Nostr relay ไม่สามารถค้นพบข้อมูลที่ขาดหายไปได้

ปัญหาความสอดคล้อง/การซิงค์ของ Nostr:

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

หากเราต้องการให้ผู้ใช้ Nostr สามารถมองเห็นโพสต์ของกันและกันได้ ดังนั้นรีเลย์ของ Nostr ทั้งหมดจึงต้องการวิธีการระบุข้อมูลที่ขาดหายไปในโปรไฟล์ผู้ใช้ เพื่อให้สามารถขอส่วนที่ขาดหายไปจากรีเลย์หรือผู้ใช้ Nostr คนอื่นๆ ได้

ใช้รูท Merkle บนเครือข่ายรายสัปดาห์และแฮชทรีเต็มเพื่อซิงค์ Nostr relay

• ประมาณสัปดาห์ละครั้ง ผู้ใช้สามารถจัดระเบียบโพสต์ทั้งหมดของพวกเขาเป็นต้นไม้ Merkle
• ใบไม้แต่ละใบในต้นไม้ Merkle มีแฮชของโพสต์ เช่นเดียวกับใบไม้ใน Bitcoin แต่ละใบมีแฮชของธุรกรรม
• เมื่อผู้ใช้จัดระเบียบโปรไฟล์ทั้งหมดเป็น Merkle tree แล้ว พวกเขาจะเผยแพร่ Merkle root ใน OP_RETURN on-chain ด้านล่างธุรกรรม Bitcoin ปกติ นี่คือเหตุผลที่ Nostr 2.0 ไม่ต้องการการฮาร์ดฟอร์กของบล็อกเชนในการทำงาน OP_RETURN เป็นส่วนที่อยู่ด้านล่างของธุรกรรม Bitcoin ที่อนุญาตให้ต่อท้ายหมายเหตุขนาดเล็กก่อนลายเซ็นของผู้ส่ง
• นอกจากนี้ ผู้ใช้จะแฮชทรีทั้งหมดและอัปโหลดไปยังเชนพร้อมกับราก Merkle (ใน OP_RETURN) ราก Merkle เป็นเพียงแฮชของกิ่งด้านบน ไม่ใช่ต้นไม้ทั้งต้น แฮชของแผนผังทั้งหมดเป็นสิ่งสำคัญสำหรับผู้ใช้และผู้ส่งต่อเพื่อให้สามารถตรวจจับได้ว่าข้อมูลโปรไฟล์หายไปหรือไม่

• ในการรับแฮชของทั้งทรี ให้วางราก Merkle ที่รากของไฟล์ข้อความ จากนั้นวางกิ่ง Merkle ไว้ที่บรรทัดใต้ราก จากนั้นวางใบ Merkle ไว้ที่แถวใต้กิ่งไม้ เมื่อจัดเรียงต้นไม้ตามที่อธิบายไว้ ให้แฮชทั้งหมดในคราวเดียว ด้านล่างคือตัวอย่างการแฮชของต้นไม้ทั้งต้นว่าแฮชของต้นไม้ทั้งต้นจะมีลักษณะอย่างไรสำหรับต้นไม้ Merkle ที่แสดงด้านบน การแฮชทั้งทรี (การแฮชข้อมูลทรีของ Merkle ทั้งหมดในครั้งเดียว)

ราก Merkle และแฮชของต้นไม้ทั้งหมดมีหน้าที่สำคัญสองประการ:

• Merkle root ช่วยให้ผู้ใช้และผู้ส่งต่อดาวน์โหลดไฟล์การกำหนดค่าบางส่วนได้ในแต่ละครั้ง เช่น การดาวน์โหลดธุรกรรมโดยไม่ต้องดาวน์โหลดทั้งบล็อก
• การแฮชทรีทั้งหมดช่วยให้ผู้ใช้และผู้ส่งต่อทราบว่าไฟล์การกำหนดค่าที่เก็บไว้ไม่สมบูรณ์หรือไม่ ซึ่งแตกต่างจาก Merkle root แฮชของต้นไม้ทั้งหมดจะตรงกันก็ต่อเมื่อคุณมีบิตทั้งหมดใน Merkle tree

วิธีการราคาถูกนี้สามารถใช้เพื่ออัปเดตไฟล์การกำหนดค่าทั้งหมดเป็นรายสัปดาห์หรือความถี่ที่ผู้ใช้กำหนด Nostr จะยังคงใช้งานได้ตามปกติ แต่ผู้ใช้สามารถจ่าย sats เพื่อซิงค์ข้อมูลระหว่างรีเลย์ของ Nostr ได้เป็นครั้งคราว หากพวกเขาต้องการให้ผู้ใช้ทุกคนเห็นโพสต์ของตน

ผู้ใช้และผู้ส่งต่อสามารถดาวน์โหลดโพสต์ได้ครั้งละหนึ่งสาขา หลังจากแต่ละสาขา พวกเขาแฮชสาขานั้นกับสาขาอื่นที่ใกล้กับราก Merkle มากที่สุดเพื่อตรวจสอบว่าตรงกับรากของ Merkle ในห่วงโซ่หรือไม่ (คล้ายกับ SPV) หากสาขาเหล่านั้นรวมกันเพื่อให้ตรงกับรากของ Merkle พวกเขาจะรู้ว่าสาขานั้นเป็นส่วนหนึ่งของโปรไฟล์ผู้ใช้ แม้ว่าจะยังไม่มีโปรไฟล์ผู้ใช้แบบเต็มก็ตาม ผู้ใช้สามารถดาวน์โหลดสาขาต่างๆ ของไฟล์การกำหนดค่าเดียวกันจาก Nostr trunks ต่างๆ ในขณะที่ตรวจสอบความถูกต้องของแต่ละสาขาและตรวจสอบให้แน่ใจว่าไฟล์การกำหนดค่าที่ดาวน์โหลดมานั้นสมบูรณ์

การดาวน์โหลด fork ทีละอันช่วยป้องกันการโจมตีแบบดีเลย์ที่อาจทำลายเครือข่ายแบบกระจายจำนวนมาก ซึ่งเป็นเหตุผลว่าทำไม Merkle root และ fork จึงถูกนำมาใช้ในสมุดปกขาว Bitcoin เพื่อปกป้อง SPV light wallets

**ทำไม Merkle root ถึงทำงานเหมือนแฮชต้นไม้ทั้งต้นไม่ได้? **

**หากการถ่ายทอดของ Nostr ขึ้นอยู่กับราก Merkle เท่านั้น พวกเขาจะไม่สามารถรู้ได้ว่าเมื่อใดที่ Merkle tree เสร็จสมบูรณ์ เนื่องจากกิ่งก้านทุกคู่ที่ใกล้กับ Merkle root จะแฮชเข้าไปในราก Merkle เดียวกัน **

เพื่อให้แน่ใจว่าโปรไฟล์ของผู้ใช้เสร็จสมบูรณ์ รีเลย์หรือผู้ใช้จะแฮชทรี Merkle ที่อัปเดตทั้งหมดและตรวจสอบว่าตรงกับแฮชทรีทั้งหมดบนเชน หากแฮชของต้นไม้ทั้งหมดตรงกัน แสดงว่าข้อมูลผู้ใช้เสร็จสมบูรณ์ หากแฮชของทรีทั้งหมดไม่ตรงกัน รีเลย์หรือผู้ใช้สามารถบอกรีเลย์ตัวอื่นถึงหมายเลขลีฟล่าสุดของตน และขอสาขาที่หายไปจนกว่าแฮชของทรีทั้งหมดจะตรงกัน เพื่อติดตามรากของ Merkle ใหม่ทั้งหมดที่เพิ่มเข้ามาทุกๆ สัปดาห์ การส่งต่อของ Nostr จะต้องกลายเป็นโหนดเต็มของ Bitcoin รีเลย์ Nostr 2.0 จ่ายทางอ้อมเพื่อจัดเก็บ Bitcoin blockchain ในขณะที่เพิ่มความปลอดภัยให้กับ Bitcoin และ Nostr

ขีดจำกัดของพื้นที่เก็บข้อมูล Nostr: กฎง่ายๆ ของผู้ใช้

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

การลดความไว้วางใจสามชั้น

• ระดับที่ 1: การจัดเก็บข้อมูลที่ไม่เปลี่ยนรูปและมีราคาแพงซึ่งยากต่อการเซ็นเซอร์ (บล็อกในห่วงโซ่ซิงโครไนซ์โหนดเต็มของ Bitcoin ทั้งหมด)
• ระดับที่ 2: การจัดเก็บข้อมูลที่ไม่แน่นอนและราคาถูก การเซ็นเซอร์ที่ยากปานกลาง (ต้นไม้ Merkle ออฟไลน์และแฮชบนเชน, รีเลย์ Nostr แบบซิงโครนัสตามความต้องการ)
• ที่เก็บข้อมูลในเครื่องซิงค์กับอุปกรณ์ในเครื่องทั้งหมด ง่ายต่อการถูกเซ็นเซอร์ (รวมศูนย์ท้องถิ่น)

การแลกเปลี่ยนขั้นพื้นฐานระหว่างบล็อกเชนที่อิงตามฉันทามติของ Nakamoto และ Nostr

**ยิ่งมีการถ่ายทอด Nostr ที่เก็บข้อมูลสำหรับที่อยู่ใดที่อยู่หนึ่งๆ มากเท่าไหร่ การเซ็นเซอร์ข้อมูลนั้นก็ยากขึ้นเท่านั้น ซึ่งหมายความว่าข้อมูลยอดนิยมที่โฮสต์โดยรีเลย์ Nostr จำนวนมากอาจถูกเซ็นเซอร์ได้ยากกว่าข้อมูลที่ไม่เป็นที่นิยมซึ่งดาวน์โหลดไม่บ่อยนัก **

**ในทางกลับกัน บล็อกเชนที่สอดคล้องกันของ Nakamoto จะป้องกันการเซ็นเซอร์ตามอายุของข้อมูล ยิ่งข้อมูลอยู่ใน blockchain นานเท่าใด การลบข้อมูลโดยใช้การโจมตี 51% ก็ยิ่งยากขึ้นเท่านั้น **

เนื่องจากเราสามารถตรวจสอบได้ว่า Fork บางตัวเป็นของผู้ใช้เฉพาะ จึงสามารถจ่าย Nostr รีเลย์ได้ทุกครั้งที่ส่งข้อมูลเล็กๆ น้อยๆ ไปยังผู้ใช้ เพื่อให้บรรลุเป้าหมายนี้ ผู้ใช้จำเป็นต้องดาวน์โหลดส่วนหัวของบล็อกเชน (เช่นเดียวกับใน SPV) เพื่อให้สามารถใช้งานฟังก์ชันทั่วไปของกระเป๋าเงินขนาดเล็กได้ ผู้ใช้จะใช้ประโยชน์จากฟังก์ชัน SPV ของ light wallet เพื่อดึงธุรกรรมเฉพาะจากเชน ซึ่งจะรวม Merkle root ของโปรไฟล์ผู้ใช้และแฮชทรีทั้งหมดใน OP_RETURN ขณะนี้ผู้ใช้สามารถจ่ายรีเลย์เพื่อดาวน์โหลดโปรไฟล์ของผู้ใช้รายนั้นทีละสาขา และยืนยันแต่ละสาขาด้วยการแฮชให้ตรงกับ Merkle root on-chain

เพื่อส่ง sats (หน่วยที่เล็กที่สุดของ Bitcoin) ไปยังรีเลย์ Nostr เพื่อแลกกับการให้ข้อมูล เราใช้การออกแบบ ZKCP ของ Gregory Maxwell (นักพัฒนา Bitcoin Core ที่มีชื่อเสียง) (การชำระเงินแบบมีเงื่อนไขแบบไม่มีความรู้) [1] ZKCSP เวอร์ชันที่พัฒนาขึ้น: หลักฐานการเรียกคืนข้อมูล [2] รวมกับเครือข่ายสายฟ้า

ตามคำอธิบายของเอกสารไวท์เปเปอร์ ZKCSP:

"...ไม่จำเป็นต้องมีบุคคลที่สามที่เชื่อถือได้...เรายังใช้โปรโตคอล ZKCSP สำหรับกรณีการพิสูจน์การเรียกคืน โดยไคลเอนต์จ่ายเงินให้เซิร์ฟเวอร์เพื่อพิสูจน์ว่าข้อมูลของลูกค้าถูกจัดเก็บอย่างถูกต้องบนเซิร์ฟเวอร์" [2]

• ผู้ใช้เริ่มต้นสัญญาอัจฉริยะ Lightning กับนักการเงินหลายคน
• ผู้ใช้ส่งคำขอไปยังนักการเงินโดยรอบ นักการเงินลงนามในคำขอ
• ผู้ใช้ส่งคำขอที่ลงนามโดยนักการเงินโดยตรงไปยังรีเลย์ของ Nostr ที่เชื่อมต่อกับนักการเงินเหล่านั้น
• ขณะนี้ผู้ใช้เริ่มสร้าง ZKCSP เพื่อให้แน่ใจว่า Nostr รีเลย์จะได้รับเงินจากนักการเงินหลังจากส่งข้อมูลที่ร้องขออย่างถูกต้องเท่านั้น

เมื่อขั้นตอนที่ 3 เกิดขึ้น ผู้ใช้จะทำการแก้ไขเพิ่มเติมจากคำขอเดิมที่ลงนามโดยนักการเงินก่อนที่จะเริ่มสร้าง ZKCSP ในขั้นตอนที่ 4 ผู้ใช้จะเพิ่มส่วนพิเศษที่ด้านบนของคำขอเดิม โดยระบุจำนวนเงินที่จะหักจากยอดคงเหลือทั้งของผู้ใช้และของนักการเงิน (ต้องเป็นจำนวนเงินที่เท่ากัน บวกกับค่าธรรมเนียมของนักการเงิน) ซึ่งผู้ใช้จะต่อท้ายข้อความเดิม เนื้อหาที่จะลงนาม

**หากผู้ใช้ระบุให้ส่ง sats มากกว่าที่ตนเป็นเจ้าของ หรือมากกว่าที่นักการเงินระงับไว้ในรีเลย์ของ Nostr นั้น รีเลย์ของ Nostr จะปฏิเสธคำขอเนื่องจากรีเลย์จะไม่สามารถรับเงินได้ **

ด้วยวิธีนี้ ผู้ใช้สามารถเชื่อมต่อกับรีเลย์ของ Nostr จำนวนมากในขณะที่ระงับเงินทุนของพวกเขาด้วยผู้ให้ทุนเพียงไม่กี่ราย แนวทางที่คล้ายกันนี้สามารถใช้กับ Lightning Network ซึ่งนักการเงินที่ลดความน่าเชื่อถือลงแล้วจะเป็นสื่อกลางที่ไม่ได้รับอนุญาตระหว่างผู้ใช้และผู้ค้า การกระโดดสายฟ้า P2P แบบปกติมีให้ใช้งานใน Nostr 2.0 เช่นกัน แต่อาจมีประโยชน์หากการจัดเส้นทางและการสร้างสมดุลของช่องสัญญาณล้มเหลวบ่อยครั้ง

** รายการที่อนุญาตพิเศษ ปลดล็อก Nostr Relay แบบชำระเงิน **

Nostr รีเลย์สามารถอนุญาตคีย์บางคีย์ได้หากต้องการจัดเก็บข้อมูลที่ดูโดยผู้ใช้เหล่านี้ทั้งหมด หากรีเลย์ของ Nostr ไม่สามารถไวท์ลิสต์ผู้ใช้ที่ต้องการเก็บข้อมูลได้ พวกเขาจะเก็บข้อมูลใดๆ ที่ส่งถึงพวกเขา หากผู้ใช้สามารถส่งข้อมูลไปยังรีเลย์ได้ฟรีตลอดเวลา ผู้ใช้ก็จะไม่ต้องจ่ายเงินสำหรับรีเลย์ Nostr Nostr สามารถเสนอตัวเลือกการชำระเงินได้ก็ต่อเมื่อผู้ส่งต่อมีตัวเลือกในการปฏิเสธการจัดเก็บข้อมูลที่ไม่สามารถชำระเงินได้ รีเลย์ฟรียังคงมีอยู่ แต่ตัวเลือกสำหรับรีเลย์แบบชำระเงินไม่มีอยู่ในขณะนี้

แทนที่จะพยายามเก็บข้อมูล Nostr ทั้งหมดแบบฟรีๆ ผู้ส่งต่อ Nostr แบบชำระเงินสามารถใช้รายการที่อนุญาตพิเศษเพื่อเลือกเก็บข้อมูลทั้งหมดที่ผู้ใช้ที่จ่ายเงินดูในแต่ละวัน รีเลย์ของ Nostr บางตัวจะยังคงทำงานในโมเดลฟรีต่อไป แต่ในระดับที่ใหญ่ที่สุด สิ่งนี้ไม่ยั่งยืนเนื่องจากรีเลย์ฟรีส่วนใหญ่เป็นเพียงผู้ที่มีความกระตือรือร้น การอนุญาตพิเศษ (แม้ว่าเราจะสามารถกำหนดคีย์สาธารณะให้กับแต่ละโปรไฟล์ของ Nostr ได้อย่างปลอดภัย) การให้ความสามารถในการถ่ายทอดของ Nostr ในการตัดสินใจว่าจะจัดเก็บข้อมูลใดจะไม่สามารถทำได้

หนึ่งคีย์สาธารณะต่อหนึ่งโปรไฟล์จะปลดล็อกฟีเจอร์รายการที่อนุญาต: ที่อยู่ Bitcoin จะกลายเป็นคีย์สาธารณะ Nostr ของคุณ

ระบบนี้ช่วยให้เรากำหนดรหัสสาธารณะให้กับไฟล์กำหนดค่าแต่ละไฟล์ได้ในที่สุด

ไม่มีประโยชน์สำหรับผู้ใช้ในการสร้างรหัสสาธารณะใหม่สำหรับแต่ละโพสต์... เนื่องจากทั้งหมดเชื่อมโยงกับโปรไฟล์ของพวกเขา! สิ่งนี้ไม่เหมือนกับที่อยู่ Bitcoin ซึ่งแตกต่างจาก Bitcoin การให้ผู้ใช้มีกุญแจสาธารณะหลายอันภายในแอปพลิเคชันเดียวกันนั้นไม่ได้ปรับปรุงความเป็นส่วนตัว

**รหัสสาธารณะของโปรไฟล์ Nostr ต้องตรงกับรหัสสาธารณะของธุรกรรม Bitcoin ที่มีแฮชรายสัปดาห์ (ราก Merkle ของโพสต์ทั้งหมดของผู้ใช้และแฮชต้นไม้ทั้งหมด) ไม่เหมือนกับผู้ใช้ Nostr ที่ใช้ลายเซ็นของ Schnorr พวกเขาจะต้องใช้กระเป๋าเงิน Bitcoin (กระเป๋าเงินมือถือ/กระเป๋าเงินเบาหรือโหนดเต็ม) เพื่อลงนาม **

ข้อดีของสิ่งนี้คือบัญชี Nostr แต่ละบัญชีจะแสดงด้วยที่อยู่ Bitcoin** ซึ่งหมายความว่าผู้ใช้สามารถส่งการชำระเงินโดยตรงไปยังบัญชี Nostr โดยไม่ต้องขอรหัสสาธารณะสองอันที่แตกต่างกัน สิ่งนี้จะช่วยลดต้นทุนการรับรู้ของผู้ใช้ใหม่ในระบบ แทนที่จะใช้ชื่อผู้ใช้ ผู้ใช้ยังคงต้องส่งคีย์สาธารณะหรือ DNS ให้หากันใน Nostr **

หากแอปพลิเคชัน Nostr อื่นๆ ใช้พับลิกคีย์ที่แตกต่างกัน พวกเขายังคงสามารถแนบกับข้อมูลประจำตัวแบบกระจายศูนย์ (DID) เดียวกันได้ - ด้วยวิธีนี้ วิธีการระบุบัญชีของคุณจะยังคงสอดคล้องกันในแอปพลิเคชันต่างๆ อย่างไรก็ตาม กฎฉันทามติของ Nostr นี้จะจำกัดการใช้คีย์สาธารณะเพียงรหัสเดียวต่อโปรไฟล์ในแต่ละแอปพลิเคชันของ Nostr

DHT ทำหน้าที่เป็นลีดเดอร์บอร์ดสำหรับการค้นหาเพื่อน

รีเลย์สามารถใช้ตารางแฮชแบบกระจาย (DHT) เพื่อค้นหารีเลย์อื่นๆ รีเลย์สามารถแบ่งปันรายการที่อนุญาตพิเศษของพวกเขาในตารางแฮชแบบกระจายโดยการแสดงรายการคีย์สาธารณะที่เก็บข้อมูล ด้วยวิธีนี้ รีเลย์ที่มีส้อมข้อมูลขาดหายไปสำหรับคีย์สาธารณะบางตัวสามารถสแกน DHT และเชื่อมต่อโดยตรงกับที่อยู่ IP ของรีเลย์อื่นที่อ้างว่าเก็บส้อมที่ขาดหายไปเหล่านั้น รีเลย์สามารถดาวน์โหลดสาขาที่หายไปได้โดยตรงจากรีเลย์ Nostr เหล่านี้

รีเลย์จะสามารถค้นหารีเลย์ที่ใช้งานมากที่สุดโดยการตรวจสอบจำนวนธุรกรรม ZKCSP ก่อนหน้านี้ที่รีเลย์เหล่านั้นแก้ไขบนเชน - ล่าสุดและตลอดเวลา ในระบบนี้ รีเลย์ของ Nostr ทั้งหมดจะกลายเป็นโหนดเต็มรูปแบบ ดังนั้นการตรวจสอบธุรกรรมก่อนหน้าของรีเลย์อื่นๆ จะไม่ยุ่งยาก สิ่งนี้จะทำให้การปลอมแปลงความน่าเชื่อถือมีราคาแพง เนื่องจากการทำธุรกรรมออนไลน์ต้องมีค่าธรรมเนียมการทำธุรกรรมเสมอ หากรีเลย์ของ Nostr เปิดหลายช่องทางเพื่อสร้างความไว้วางใจให้กับตัวเองเพื่อให้ได้รับความไว้วางใจจากรีเลย์อื่นๆ เขาจะต้องจ่ายค่าธรรมเนียมการทำธุรกรรมจำนวนมากเพื่อรักษาชื่อเสียงปลอมทุกสัปดาห์ หลังจากที่ผู้โจมตีล้มเหลวในการจัดหาสาขาที่ขาดหายไป การหมดเวลาจะทำให้รีเลย์ตัดการเชื่อมต่อ - ดังนั้นนี่จึงเป็นเพียงการโจมตีชั่วคราวที่มีราคาแพง (เหมือนกับการโจมตี 51% ที่เป็นการโจมตีชั่วคราวที่มีราคาแพง)

DHT ไม่ระบุตัวตนเหมือนการขุด เนื่องจากคีย์สาธารณะของรีเลย์ Nostr แต่ละรายการจะแสดงถัดจากที่อยู่ IP ใน DHT แต่จะหลีกเลี่ยงความจำเป็นในการส่งต่อเพื่อส่งคำขอสุ่มสี่สุ่มห้าผ่านเครือข่าย - ในสเกลที่ใหญ่พอ จะโอเวอร์โหลดเครือข่าย ผู้ส่งต่อ Nostr ที่ต้องการความเป็นส่วนตัวมากขึ้นสามารถใช้ VPN หรือบริการป้องกัน IP อื่นๆ ได้

ผู้ใช้จะไม่สามารถเข้าถึงระบบความเชื่อถือเดียวกันนี้ได้เนื่องจากไม่ใช่โหนดแบบเต็ม อย่างไรก็ตามผู้ใช้สามารถวางใจได้

นักเล่นจะเชื่อมต่อทางอ้อมกับรีเลย์ Nostr หลายร้อยตัว

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

**นักการเงิน (นักขุด) ต้องล็อค sat ของพวกเขาด้วยรีเลย์ Nostr โดยไม่ต้องส่งข้อมูลระหว่างผู้ใช้และรีเลย์ **นักการเงิน (คนขุดแร่) เพียงแค่ต้องลงนามในคำขอของผู้ใช้ เพื่อให้ผู้ใช้สามารถโต้ตอบโดยตรงกับรีเลย์ Nostr ทั้งหมดที่นักการเงินเชื่อมต่ออยู่ - 4 ขั้นตอนสำหรับ ZKCSP+Lightning ตามด้านบน

สรุปแล้ว

เครือข่าย Lightning จะไม่สามารถดำรงอยู่ได้หากไม่มีบล็อกเชนที่สอดคล้องกันของ Bitcoin เนื่องจากผู้ใช้จะไม่มีที่เก็บหลักฐานการทำธุรกรรมนอกเครือข่ายที่รวมไว้

เช่นเดียวกับที่ผู้ใช้รวมธุรกรรม Lightning Network ทั้งหมดเข้าด้วยกันและใส่หลักฐานเล็กๆ น้อยๆ ลงในบล็อกเชน เราจะรวมข้อมูล Nostr ทั้งหมดและใส่หลักฐานเล็กๆ น้อยๆ ลงในบล็อกเชน ในลักษณะเดียวกับที่ Lightning Network ให้บริการชำระเงินทันทีที่เลเยอร์ที่สอง Nostr อาจสามารถให้บริการพื้นที่จัดเก็บข้อมูลที่เลเยอร์ที่สองได้โดยไม่มีความเสี่ยงจากไซด์เชนที่ไม่ปลอดภัย **

**ใช้แนวทางเดียวกับ Lightning Network โดยมี Bitcoin's Nakamoto consensus blockchain ในชั้นแรก และ Nostr+ZKCSP Lightning ในชั้นที่สอง **