ผู้เขียนต้นฉบับ: Colby Serpa

เรียบเรียงต้นฉบับ: DAOrayaki

คำอธิบายภาพ

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

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

รีเลย์ Nostr ไม่รู้เมื่อไฟล์ปรับแต่งไม่สมบูรณ์ รีเลย์ขาดความสม่ำเสมอ (C ในทฤษฎีบท CAP)

Sync Nostr ถ่ายทอดด้วยรูท Merkle บนเครือข่ายรายสัปดาห์และแฮชแบบเต็มของต้นไม้

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

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

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

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

Sync Nostr ถ่ายทอดด้วยรูท Merkle บนเครือข่ายรายสัปดาห์และแฮชแบบเต็มของต้นไม้

• ใบไม้แต่ละใบในต้นไม้ Merkle มีแฮชของโพสต์ เช่นเดียวกับใบไม้ใน Bitcoin แต่ละใบมีแฮชของธุรกรรม

• ใบไม้แต่ละใบในต้นไม้ Merkle มีแฮชของโพสต์ เช่นเดียวกับใบไม้ใน Bitcoin แต่ละใบมีแฮชของธุรกรรม

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

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

• หากต้องการแฮชของทั้งทรี ให้วาง Merkle root ที่รูทของไฟล์ข้อความ จากนั้นวางกิ่ง 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 เสร็จสมบูรณ์ เนื่องจากกิ่งก้านทุกคู่ที่อยู่ใกล้กับรากของ Merkle จะแฮชเข้าไปในรากของ Merkle เดียวกัน

Nostr Storage Limits: กฎง่ายๆ ของผู้ใช้

Nostr Storage Limits: กฎง่ายๆ ของผู้ใช้

ZKCSP และ Lightning Network Payment Nostr Relay โดยใช้ Proof-of-Retrievability

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

• ชั้นที่ 1: ที่เก็บข้อมูลที่ไม่เปลี่ยนรูปและมีราคาแพงซึ่งยากต่อการเซ็นเซอร์ (บล็อกในห่วงโซ่ซิงโครไนซ์โหนดเต็มของ Bitcoin ทั้งหมด)

• ชั้นที่ 2: ที่เก็บข้อมูลที่ไม่แน่นอนและราคาถูก การเซ็นเซอร์ที่ยากปานกลาง (ต้นไม้ Merkle ออฟไลน์และแฮชบนเชน, รีเลย์ Nostr แบบซิงโครนัสตามความต้องการ)

• ที่เก็บข้อมูลในเครื่องจะซิงค์กับอุปกรณ์ในเครื่องทั้งหมดและตรวจสอบได้ง่าย (รวมศูนย์ท้องถิ่น)

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

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

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

ZKCSP และ Lightning Network Payment Nostr Relay โดยใช้ Proof-of-Retrievability

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

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

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

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

• ผู้ใช้เริ่มต้นสัญญาอัจฉริยะ Lightning กับนักการเงินหลายราย

• ผู้ใช้ส่งคำขอไปยังนักการเงินโดยรอบ นักการเงินลงนามในคำขอ

• ผู้ใช้ส่งคำขอที่ลงนามโดยนักการเงินโดยตรงไปยังรีเลย์ของ Nostr ที่เชื่อมต่อกับนักการเงินเหล่านั้น

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

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

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

สรุปแล้ว

รายการที่อนุญาตพิเศษปลดล็อกการจ่าย 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 หลายร้อยตัว

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

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

สรุปแล้ว

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

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

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