นี่คือบทบรรณาธิการความคิดเห็นโดย Shinobi นักการศึกษาที่เรียนรู้ด้วยตนเองในพื้นที่ Bitcoin และโฮสต์พอดคาสต์ Bitcoin ที่เน้นเทคโนโลยี
ฉันขอแนะนำให้คุณอ่านก่อนอ่าน บทความก่อนหน้านี้ฉันได้เขียนอธิบายว่า Nostr คืออะไรและทำงานอย่างไรในระดับสูง. จากนั้นคุณควรมีแนวคิดที่ดีเกี่ยวกับการออกแบบหลักของระบบ ณ จุดนั้น ดังนั้นตอนนี้ มาดูปัญหาที่เป็นไปได้ที่จะเกิดขึ้นเมื่อมีการนำไปใช้มากขึ้น ด้วยแพลตฟอร์ม กลายเป็นที่นิยมสำหรับชุมชน Bitcoin, ปัญหาเหล่านี้เป็นสิ่งที่ควรระวัง
ตามที่ฉันได้กล่าวไว้ในบทความก่อนหน้านี้ คู่คีย์สาธารณะ/ส่วนตัวของผู้ใช้เป็นส่วนสำคัญต่อวิธีที่ Nostr ทำงานเป็นโปรโตคอล ไม่มีชื่อผู้ใช้หรือตัวระบุประเภทใดๆ ที่เซิร์ฟเวอร์ส่งต่อควบคุมเพื่อเชื่อมโยงกับผู้ใช้แต่ละราย มันเป็นเพียงคีย์ของผู้ใช้ที่อยู่ภายใต้การควบคุมของพวกเขาอย่างสมบูรณ์
การทำงานนี้เป็นการผูกมัดที่แน่นแฟ้นระหว่างผู้ใช้จริงและวิธีระบุตัวตนของผู้ใช้รายอื่น ซึ่งป้องกันไม่ให้เซิร์ฟเวอร์ส่งต่อใดๆ ยกเลิกการผูกสองสิ่งนี้ เช่น การให้ตัวระบุของใครบางคนกับผู้ใช้รายอื่น สิ่งนี้ช่วยแก้ปัญหาพื้นฐานที่ใหญ่ที่สุดประการหนึ่งของแพลตฟอร์มที่ใช้สำหรับการสื่อสารระหว่างผู้คน: การขาดการควบคุมตัวตนของผู้ใช้ แต่ยังแนะนำปัญหาทั้งหมดของการจัดการคีย์ที่ผู้ที่มีคีย์ส่วนตัวประสบ คีย์อาจสูญหายและคีย์อาจถูกบุกรุกได้ และหากเหตุการณ์ดังกล่าวเกิดขึ้น ผู้ใช้จะไม่มีใครไปขอความช่วยเหลือ เช่นเดียวกับ Bitcoin ไม่มีการสนับสนุนลูกค้าที่จะกู้คืนอะไร คุณเสียมันไป แค่นั้นแหละ
สิ่งนี้จะมีความจำเป็นอย่างหลีกเลี่ยงไม่ได้สำหรับผู้ใช้ในการหมุนเวียนจากคู่กุญแจหนึ่งไปยังอีกคู่หนึ่งในลักษณะที่ตรวจสอบได้และค้นพบได้สำหรับผู้ใช้รายอื่นที่พวกเขาโต้ตอบด้วยผ่านโปรโตคอล โปรโตคอลทั้งหมดขึ้นอยู่กับการพิสูจน์ว่าเหตุการณ์มาจากผู้ใช้เฉพาะ (รหัสประจำตัว) ดังนั้นการรับประกันทั้งหมดจึงออกไปนอกหน้าต่างเมื่อคีย์ของใครบางคนถูกบุกรุก
คุณจัดการกับสิ่งนั้นอย่างไร? เพียงแค่ไปตรวจสอบบัญชี Twitter ของพวกเขา? นั่นไม่ใช่ระบบที่มีการกระจายอำนาจมากนัก ท้ายที่สุดแล้ว ถ้าคุณต้องการใช้แพลตฟอร์มแบบรวมศูนย์ที่พวกเขาไม่ได้อยู่ในการควบคุมตัวตนเพื่อยืนยันตัวตนของ Nostr
มีผู้ใช้รายอื่นยืนยันความถูกต้องของคีย์ใหม่หรือไม่ ซึ่งไม่ได้กล่าวถึงสถานการณ์ต่างๆ เช่น การประนีประนอมของคีย์มวล หรือการไม่รู้จักใครที่ใกล้ชิดกับพวกเขาดีพอที่จะเชื่อถือการรับรองของพวกเขา
Nostr ต้องการโครงร่างการเข้ารหัสจริงที่ผูกการหมุนของคีย์หนึ่งไปยังอีกคีย์หนึ่ง มี ข้อเสนอจากนักพัฒนา fiatjaf สำหรับแผนพื้นฐานที่อาจแก้ปัญหานี้ได้ แนวคิดพื้นฐานคือการใช้ชุดที่อยู่แบบยาวที่ได้มาจาก master seed หนึ่งชุด และสร้างชุดของคีย์ "tweaked" ที่คล้ายกับวิธีที่ Taproot tree ผูกมัดกับคีย์ Bitcoin Taproot ใช้ราก Merkle tree ของ Taproot tree และ "เพิ่ม" ลงในรหัสสาธารณะเพื่อสร้างรหัสสาธารณะใหม่ สิ่งนี้สามารถทำซ้ำได้โดยการเพิ่ม Merkle tree root นั้นในคีย์ส่วนตัวเพื่อให้ได้คีย์ส่วนตัวที่ตรงกันสำหรับคีย์สาธารณะใหม่ แนวคิดของ Fiatjaf คือการผูกมัดต่อเนื่องกันตั้งแต่ต้นจนจบ เพื่อให้คีย์ที่ปรับแต่งแต่ละคีย์มีหลักฐานว่าคีย์ที่ปรับแต่งถัดไปถูกใช้เพื่อสร้างมันขึ้นมา
ลองจินตนาการว่าเริ่มต้นด้วยคีย์ Z ซึ่งเป็นคีย์สุดท้ายในห่วงโซ่ คุณจะปรับแต่งสิ่งนี้ด้วยบางสิ่ง จากนั้นย้อนกลับและสร้างคีย์ Y เวอร์ชันที่ปรับแต่งแล้วโดยใช้คีย์ Z ที่ปรับแต่งแล้ว (Z' + Y = Y') จากที่นี่ คุณจะใช้ Y' แล้วใช้เพื่อปรับแต่ง X (Y' + X = X') คุณจะทำสิ่งนี้ตลอดทางกลับไปที่คีย์ A เพื่อรับ A' จากนั้นเริ่มใช้คีย์นั้น เมื่อถูกบุกรุก ผู้ใช้สามารถออกอากาศเหตุการณ์ที่มีคีย์ A ที่ยังไม่ได้ปรับแต่งและคีย์ B' ที่ปรับแต่งแล้ว ซึ่งจะมีข้อมูลทั้งหมดที่จำเป็นในการแสดง B' ถูกใช้เพื่อสร้าง A' และผู้ใช้สามารถหยุดติดตาม A' ได้ทันทีและติดตาม B' แทน พวกเขาจะรู้แน่ชัดว่า B' คือคีย์ถัดไปของผู้ใช้รายนั้นและจะทำตามนั้นแทน
ข้อเสนอนี้ยังคงมีปัญหาอยู่บ้าง ขั้นแรก คุณต้องสร้างคีย์ทั้งหมดที่คุณเคยใช้ล่วงหน้า และไม่มีทางที่จะหมุนเวียนเป็นคีย์ชุดใหม่ทั้งหมดได้ สิ่งนี้สามารถจัดการได้โดยการผูกมัดกับมาสเตอร์คีย์ในโครงร่างนี้ที่สามารถรับรองการหมุนดังกล่าวได้ หรือเพียงแค่สร้างคีย์ชุดใหญ่ตั้งแต่เริ่มต้น ทั้งสองเส้นทางเป็นเส้นทางที่ถูกต้อง แต่ท้ายที่สุดแล้วจะต้องมีการรักษาคีย์รูทหรือเนื้อหาคีย์ให้ปลอดภัยและเปิดเผยเฉพาะคีย์ลัดแต่ละรายการต่อไคลเอนต์ Nostr เท่านั้น
อย่างไรก็ตาม โครงร่างนี้ไม่ได้ทำอะไรเพื่อปกป้องผู้ใช้หรือเสนอกลไกในการกู้คืนข้อมูลประจำตัวในกรณีที่วัสดุหลักสูญหายหรือถูกบุกรุก นี่ไม่ได้หมายความว่าไม่มีประโยชน์สำหรับแผนการของ fiatjaf แต่มีอย่างแน่นอน แต่สิ่งสำคัญคือต้องทำให้ประเด็นว่าไม่มีวิธีแก้ปัญหาใดที่สามารถแก้ปัญหาได้ทุกปัญหา
เพื่ออธิบายถึงวิธีแก้ปัญหาที่เป็นไปได้ที่นี่ ลองนึกภาพแทนที่จะใช้ห่วงโซ่ของคีย์ที่ปรับแต่งอย่างที่เขาเสนอ คีย์นั้นได้รับการปรับแต่งด้วยคีย์เย็นหลักที่ต้องใช้ในการเซ็นชื่อเหตุการณ์ที่หมุนจากคีย์หนึ่งไปยังอีกคีย์หนึ่ง คุณมีคีย์ A' ซึ่งได้มาจากการเพิ่ม A และ M (คีย์หลัก) และเหตุการณ์การหมุนจะเป็น A, M และ B' (สร้างขึ้นโดยการเพิ่ม B และ M) พร้อมลายเซ็นจาก M M อาจเป็น คีย์เกณฑ์หลายซิก — สองในสาม สามในห้า เป็นต้น สิ่งนี้อาจเพิ่มความซ้ำซ้อนเพื่อป้องกันการสูญเสีย รวมทั้งให้กลไกที่ปลอดภัยสำหรับการหมุนเวียนคีย์ นี่เป็นการเปิดประตูสู่การใช้บริการเพื่อช่วยในการกู้คืนหรือกระจายกุญแจเหล่านั้นไปยังเพื่อนที่ไว้ใจได้ มันมอบความยืดหยุ่นแบบเดียวกับที่ multisig ทำกับ Bitcoin เอง
เอ็นไอพี26 ยังเป็นข้อเสนอที่อาจเป็นประโยชน์อย่างมากในการจัดการกับปัญหานี้ สิ่งนี้ระบุส่วนขยายของโปรโตคอลไปยังเหตุการณ์ที่อนุญาตให้ลายเซ็นจากคีย์หนึ่งอนุญาตให้คีย์อื่นโพสต์เหตุการณ์ในนามของมัน จากนั้น "โทเค็น" หรือหลักฐานการมอบสิทธิ์ที่มีลายเซ็นจะถูกรวมไว้ในกิจกรรมทั้งหมดที่โพสต์โดยคีย์สาธารณะที่สองในนามของคนแรก มันสามารถจำกัดเวลาได้ ดังนั้นโทเค็นการมอบสิทธิ์จะหมดอายุโดยอัตโนมัติและต้องต่ออายุ
สุดท้ายก็แก้ปัญหานี้ มี เพื่อแก้ปัญหาให้กับ Nostr ในระยะยาว โปรโตคอลที่อิงตามคู่คีย์สาธารณะ/ส่วนตัวที่ใช้เป็นข้อมูลประจำตัวนั้นไม่สามารถดึงดูดและนำไปใช้ได้หากไม่สามารถปกป้องและรักษาความสมบูรณ์ของข้อมูลประจำตัวเหล่านั้นสำหรับผู้ใช้ ซึ่งท้ายที่สุดแล้วจะต้องใช้งานแพลตฟอร์มนอกแบนด์และรวมศูนย์อย่างต่อเนื่องเพื่อตรวจสอบคีย์ใหม่และประสานงานผู้คนที่ติดตามตัวตนใหม่ของคุณเมื่อมีบางสิ่งสูญหายหรือถูกบุกรุก และเมื่อถึงจุดนั้น แพลตฟอร์มอื่นๆ เหล่านั้นก็กลายเป็นช่องทางในการหว่านความสับสน และมีส่วนร่วมในการเซ็นเซอร์
ปัญหาของการจัดการคีย์และความปลอดภัยเป็นปัญหาใหญ่กับพื้นที่การออกแบบขนาดใหญ่มากซึ่งเต็มไปด้วยจุดเสียและจุดบอด แต่เป็นปัญหาที่จะต้องแก้ไขภายในบริบทของ Nostr เพื่อให้มันทำงานได้ ในบทความหน้า ผมจะสรุปประเด็นบางประเด็นที่เห็นว่าเป็นปัญหาเกี่ยวกับสถาปัตยกรรมเซิร์ฟเวอร์รีเลย์และปัญหาการปรับสเกลที่นักพัฒนาซอฟต์แวร์ Nostr จะต้องเผชิญเนื่องจากโครงสร้างข้อมูลพื้นฐานที่ Nostr สร้างขึ้น
สำหรับใครก็ตามที่อ่านและสงสัยว่าทำไมฉันถึงไม่พูดถึงตัวระบุแบบกระจายอำนาจ (DIDs): ใช่ นั่นเป็นวิธีแก้ปัญหาที่เป็นไปได้สำหรับปัญหาเหล่านี้ ซึ่งในความเห็นของฉัน ค่อนข้างครอบคลุม อย่างไรก็ตาม นักพัฒนาของ Nostr ดูเหมือนจะลังเลมากที่จะรวม DID เข้ากับโปรโตคอลหรือไคลเอ็นต์ เนื่องจากข้อเท็จจริงที่ว่ามันจะสร้างการพึ่งพาภายนอกภายนอกโปรโตคอล Nostr หากคุณไม่คุ้นเคยกับวิธีการทำงานของ DID ในระดับเทคนิคและสนใจ บทความนี้โดย Level 39 เป็นการสรุปวิธีการทำงานที่เป็นลายลักษณ์อักษรได้ดีมาก
นี่คือแขกโพสต์โดย Shinobi ความคิดเห็นที่แสดงออกมานั้นเป็นความคิดเห็นของตนเองทั้งหมด และไม่จำเป็นต้องสะท้อนความคิดเห็นของ BTC Inc หรือ Bitcoin Magazine
- เนื้อหาที่ขับเคลื่อนด้วย SEO และการเผยแพร่ประชาสัมพันธ์ รับการขยายวันนี้
- เพลโตบล็อคเชน Web3 Metaverse ข่าวกรอง ขยายความรู้. เข้าถึงได้ที่นี่.
- ที่มา: https://bitcoinmagazine.com/technical/solving-nostr-key-management-issues
- 7
- a
- อย่างแน่นอน
- ลงชื่อเข้าใช้
- จริง
- ที่อยู่
- ที่อยู่
- เพิ่ม
- การนำมาใช้
- กับ
- ก่อน
- ช่วย
- ทั้งหมด
- การอนุญาต
- และ
- อื่น
- ทุกคน
- สถาปัตยกรรม
- รอบ
- บทความ
- ความช่วยเหลือ
- ภาคี
- อนุญาต
- อัตโนมัติ
- กลับ
- ตาม
- ขั้นพื้นฐาน
- กลายเป็น
- จะกลายเป็น
- ก่อน
- การเริ่มต้น
- กำลัง
- ประโยชน์
- ระหว่าง
- ใหญ่
- ที่ใหญ่ที่สุด
- ผูกพัน
- บิต
- Bitcoin
- นิตยสาร Bitcoin
- ออกอากาศ
- BTC
- BTC อิงค์
- สร้าง
- ไม่ได้
- เซ็นเซอร์
- ส่วนกลาง
- โซ่
- ตรวจสอบ
- ลูกค้า
- ปิดหน้านี้
- มุ่งมั่น
- การกระทำ
- การสื่อสาร
- อย่างสมบูรณ์
- ครอบคลุม
- ที่ถูกบุกรุก
- ความสับสน
- ไม่หยุดหย่อน
- สิ่งแวดล้อม
- ควบคุม
- ประสานงาน
- แกน
- ได้
- คอร์ส
- สร้าง
- การเข้ารหัสลับ
- ลูกค้า
- Customer Support
- ข้อมูล
- ซึ่งกระจายอำนาจ
- ที่ได้มา
- ออกแบบ
- ผู้พัฒนา
- นักพัฒนา
- กล่าวถึง
- ประตู
- ลง
- แต่ละ
- บทบรรณาธิการ
- ทั้ง
- ว่าจ้าง
- พอ
- ทั้งหมด
- อย่างสิ้นเชิง
- ฯลฯ
- แม้
- เหตุการณ์
- เหตุการณ์
- ในที่สุด
- เคย
- อธิบาย
- แสดง
- นามสกุล
- ภายนอก
- คุ้นเคย
- เฟียตจาฟ
- ชื่อจริง
- ความยืดหยุ่น
- ปฏิบัติตาม
- ดังต่อไปนี้
- เพื่อน
- ราคาเริ่มต้นที่
- เต็ม
- ฟังก์ชั่น
- พื้นฐาน
- ได้รับ
- สร้าง
- สร้าง
- การสร้าง
- ได้รับ
- กำหนด
- ให้
- Go
- ไป
- ดี
- เติบโต
- การค้ำประกัน
- แขก
- โพสต์ของผู้เข้าพัก
- จัดการ
- การจัดการ
- มี
- โปรดคลิกที่นี่เพื่ออ่านรายละเอียดเพิ่มเติม
- ลังเล
- จุดสูง
- เจ้าภาพ
- สรุป ความน่าเชื่อถือของ Olymp Trade?
- อย่างไรก็ตาม
- HTTPS
- ความคิด
- ระบุ
- ระบุ
- อัตลักษณ์
- เอกลักษณ์
- ทันที
- สำคัญ
- in
- รวม
- เป็นรายบุคคล
- ย่อม
- แทน
- สำคัญ
- รวบรวม
- ความสมบูรณ์
- โต้ตอบ
- สนใจ
- เปิดตัว
- ปัญหา
- ปัญหา
- IT
- ตัวเอง
- การเก็บรักษา
- คีย์
- กุญแจ
- ทราบ
- รู้ดี
- ไม่มี
- ใหญ่
- ชื่อสกุล
- ถูกต้องตามกฎหมาย
- ชั้น
- น่าจะ
- ถูก จำกัด
- นาน
- ดู
- สูญเสีย
- ปิด
- นิตยสาร
- ทำ
- การจัดการ
- มวล
- เจ้านาย
- การจับคู่
- วัสดุ
- วิธี
- กลไก
- กล่าวถึง
- มัลติซิก
- จำเป็นต้อง
- ความต้องการ
- ใหม่
- ถัดไป
- นอสเตอร์
- เสนอ
- เสนอ
- ONE
- เปิด
- ความคิดเห็น
- ความคิดเห็น
- ใบสั่ง
- อื่นๆ
- ผลิตภัณฑ์อื่นๆ
- ด้านนอก
- ของตนเอง
- อาการเจ็บปวด
- คู่
- เส้นทาง
- คน
- เวที
- แพลตฟอร์ม
- เพลโต
- เพลโตดาต้าอินเทลลิเจนซ์
- เพลโตดาต้า
- พอดคาสต์
- จุด
- จุด
- ยอดนิยม
- โพสต์
- โพสต์
- ที่มีศักยภาพ
- ที่อาจเกิดขึ้น
- ก่อน
- ส่วนตัว
- คีย์ส่วนตัว
- ปัญหา
- ปัญหาที่เกิดขึ้น
- พิสูจน์
- ข้อเสนอ
- เสนอ
- ป้องกัน
- การป้องกัน
- โปรโตคอล
- ให้
- สาธารณะ
- คีย์สาธารณะ
- อ่าน
- การอ่าน
- กู้
- การฟื้นตัว
- สะท้อน
- ความนับถือ
- ซึ่งได้ทำใหม่
- การจำลองแบบ
- ต้องการ
- กลับ
- ราก
- ปลอดภัย
- เดียวกัน
- ปรับ
- โครงการ
- ที่สอง
- ปลอดภัย
- ความปลอดภัย
- เมล็ดพันธุ์
- บริการ
- ชุด
- น่า
- โชว์
- ลงชื่อ
- คล้ายคลึงกัน
- ง่ายดาย
- เดียว
- สถานการณ์
- So
- ทางออก
- โซลูชัน
- แก้
- แก้ปัญหา
- บาง
- บางคน
- บางสิ่งบางอย่าง
- ช่องว่าง
- โดยเฉพาะ
- การแพร่กระจาย
- ที่เริ่มต้น
- ยังคง
- หยุด
- อย่างเช่น
- สรุป
- สนับสนุน
- ระบบ
- เอา
- ใช้เวลา
- รากแก้ว
- วิชาการ
- พื้นที่
- ของพวกเขา
- สิ่ง
- สาม
- ธรณีประตู
- ตลอด
- เวลา
- ไปยัง
- โทเค็น
- ราชสกุล
- แรงฉุด
- การค้า
- ต้นไม้
- วางใจ
- ที่เชื่อถือ
- พูดเบาและรวดเร็ว
- ในที่สุด
- ภายใต้
- ใช้
- ผู้ใช้งาน
- ผู้ใช้
- ตรวจสอบ
- รุ่น
- อะไร
- ที่
- จะ
- ภายใน
- สงสัย
- งาน
- โรงงาน
- จะ
- เขียน
- X
- คุณ
- ของคุณ
- YouTube
- ลมทะเล