ข้อเสนอเครือข่ายสายฟ้าของ Antoine Riard สามารถลดการโจมตีแบบ Channel Jamming ได้หรือไม่?

นี่คือบทบรรณาธิการความคิดเห็นโดย Shinobi นักการศึกษาที่เรียนรู้ด้วยตนเองในพื้นที่ Bitcoin และโฮสต์พอดคาสต์ Bitcoin ที่เน้นเทคโนโลยี

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

เมื่อเดือนที่แล้ว Antoine Riard ผู้พัฒนาเกม Lightning ได้เสนอข้อกำหนดอย่างเป็นทางการสำหรับวิธีแก้ปัญหานี้ ในเดือนสิงหาคม Riard และ Gleb Naumenko ตีพิมพ์ การวิจัย ดูที่ปัญหาทั่วไปรวมถึงวิธีแก้ไขปัญหาต่างๆ ที่อาจใช้เพื่อบรรเทาหรือแก้ไขได้ หนึ่งในโซลูชันที่เสนอคือรูปแบบของข้อมูลประจำตัวที่ไม่ระบุตัวตนซึ่งโหนดสามารถใช้เพื่อสร้างระบบการให้คะแนนชื่อเสียงสำหรับผู้ใช้ที่กำหนดเส้นทางการชำระเงินผ่านพวกเขาโดยไม่ต้อง dox หรือเชื่อมโยงชื่อเสียงนั้นกับตัวระบุแบบคงที่ซึ่งจะส่งผลเสียต่อความเป็นส่วนตัวของผู้คน โซลูชันนี้ได้กลายเป็น ข้อเสนอโปรโตคอลอย่างเป็นทางการ สร้างโดย Riard เมื่อเดือนที่แล้ว

ภายในข้อเสนอการลดปัญหาการติดขัดของช่องสัญญาณ

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

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

หาก HTLC ตกลงสำเร็จโดยมีการเปิดเผยพรีอิมเมจ ทุกโหนดตามเส้นทางการชำระเงินจะลงนามและรวมถึงโทเค็น Chaumian ที่ออกใหม่เพื่อส่งคืนกลับไปยังผู้ส่งพร้อมกับพรีอิมเมจ HTLC หาก HTLC ชำระไม่สำเร็จ โหนดเส้นทางจะ “เบิร์น” โทเค็นโดยรวมไว้ในตารางโทเค็นที่ใช้แล้วและไม่ออกโทเค็นใหม่ สิ่งนี้บังคับให้ผู้ส่งต้องได้รับโทเค็นใหม่จากโหนดเหล่านั้นเพื่อกำหนดเส้นทางการชำระเงินผ่านพวกเขาอีกครั้ง แนวคิดทั้งหมดคือการโจมตีแบบติดขัดมักจะไม่สามารถแก้ไขได้ ดังนั้นในแผนนี้ โทเค็นเหล่านี้ที่ออกโดยแต่ละโหนดที่คุณกำหนดเส้นทางจะถูกเผาหากคุณทำการโจมตีแบบติดขัดและสร้างต้นทุนในการรับเพิ่มเติมเพื่อดำเนินการอีกครั้ง ในตอนนี้ การโจมตีแบบติดขัดไม่มีค่าใช้จ่ายใดๆ นอกจากเวลา ดังนั้นสิ่งนี้จะเพิ่มต้นทุนทางเศรษฐกิจให้กับพวกเขา

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

ข้อเสนอของ Riard คือการซื้อโทเค็นเหล่านี้โดยตรงจากแต่ละโหนดเป็นการซื้อครั้งเดียว จากจุดนั้น แทนที่จะจ่ายค่าธรรมเนียมล่วงหน้าสำหรับการชำระเงินทุกครั้ง ตราบเท่าที่การชำระเงินก่อนหน้านี้ได้รับการชำระเงินเรียบร้อยแล้ว คุณจะได้รับ "routing token" ใหม่ที่จะช่วยให้การชำระเงินที่เสนอครั้งต่อไปของคุณได้รับการกำหนดเส้นทางโดยไม่มีค่าธรรมเนียม ด้วยวิธีนี้ การชำระเงินที่สำเร็จจะชำระค่าธรรมเนียมการโอนจริงเท่านั้น และการชำระเงินที่ล้มเหลวจะชำระค่าธรรมเนียมล่วงหน้าเท่านั้น เพื่อป้องกันไม่ให้เกิด "ค่าธรรมเนียมสองเท่า" สำหรับการชำระเงินที่สำเร็จ อย่างน้อยในเชิงเศรษฐกิจ ให้คิดว่ามันเป็นการประนีประนอมระหว่างสถานการณ์ปัจจุบันที่การชำระเงินล้มเหลวไม่มีค่าใช้จ่ายใดๆ และการชำระเงินที่สำเร็จเท่านั้นที่ต้องจ่ายค่าธรรมเนียม และรูปแบบค่าธรรมเนียมล่วงหน้าเต็มจำนวนที่การชำระเงินทั้งหมดจ่ายค่าธรรมเนียมล่วงหน้าและ คนที่ประสบความสำเร็จจ่ายค่าธรรมเนียมการกำหนดเส้นทางเช่นกัน

ประเด็นจากข้อเสนอ

โดยส่วนตัวแล้ว ฉันคิดว่าการชำระเงินโดยตรงสำหรับโทเค็นล่วงหน้าแบบนี้อาจทำให้ UX เสียดทานในระดับมากในกระบวนการใช้ Lightning Network อย่างไรก็ตาม ฉันคิดว่ามีวิธีแก้ไขที่ค่อนข้างง่ายสำหรับความไม่ลงรอยกันนั้นโดยการปรับเปลี่ยนข้อเสนอเล็กน้อย

แทนที่จะต้องจ่ายเงินให้แต่ละโหนดโดยตรงสำหรับโทเค็น Chaumian ล่วงหน้า ข้อเสนอนี้สามารถผสมโดยตรงกับข้อเสนอค่าธรรมเนียมล่วงหน้า หากคุณมีโทเค็นสำหรับโหนด ให้รวมโทเค็นเหล่านั้นไว้ใน Onion blob หากไม่ชำระค่าธรรมเนียมล่วงหน้าโดยตรงภายในข้อเสนอ HTLC และหากการชำระเงินสำเร็จ คุณจะได้รับโทเค็น Chaumian คืนตามสัดส่วนที่คุณมี - ค่าธรรมเนียมแรกเข้า ด้วยวิธีนี้ แทนที่จะต้องรวบรวมโทเค็นจากโหนดต่างๆ ล่วงหน้า คุณเพียงแค่ได้รับโทเค็นเหล่านี้ในระหว่างการชำระเงินครั้งแรก จนกว่าคุณจะมีคอลเลกชันที่ดีจากโหนดต่างๆ ที่คุณใช้บ่อยและแทบไม่ต้องเสียค่าใช้จ่าย ของค่าธรรมเนียมล่วงหน้าเพื่อให้ได้มา

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

สิ่งนี้อาจทำให้ผู้ส่งการชำระเงินมีต้นทุนทางเศรษฐกิจตามปกติ หรือกำหนดให้พวกเขาเช็คอินเป็นระยะเพื่อให้แน่ใจว่าจะออกใหม่เมื่อโทเค็นเก่าหมดอายุ ในทางปฏิบัติ สิ่งนี้สามารถทำได้โดยอัตโนมัติสำหรับผู้ที่ใช้โหนด Lightning ของตนเอง และสำหรับกระเป๋าเงินใด ๆ ที่สร้างขึ้นจากโมเดลผู้ให้บริการ Lightning (LSP) ตัว LSP เองสามารถจัดการการได้มาและการบำรุงรักษาโทเค็นในนามของผู้ใช้จริง ๆ โดยจัดการกับ การจัดสรรโทเค็นสำหรับการชำระเงินของผู้ใช้ อย่างไรก็ตาม หากไม่มีโหนด Lightning หรือ LSP เต็มรูปแบบ สิ่งนี้อาจกลายเป็นเรื่องน่ารำคาญเล็กน้อยสำหรับผู้ใช้กระเป๋าเงินขนาดเล็ก

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

นี่คือแขกโพสต์โดย Shinobi ความคิดเห็นที่แสดงออกมานั้นเป็นความคิดเห็นของตนเองทั้งหมด และไม่จำเป็นต้องสะท้อนความคิดเห็นของ BTC Inc หรือ Bitcoin Magazine