ในบทความก่อนหน้านี้วิธีการทำงานของ Lightning Network (2),“เราได้สำรวจหลักการทำงานของ Lightning Network ของ Bitcoin โดยพื้นฐานแล้ว Lightning Network เป็นระบบช่องการชำระเงินที่ออกแบบอย่างระมัดระวังซึ่งเชื่อมต่อช่องการชำระเงินแต่ละช่องเป็นเครือข่ายการชำระเงินที่ใหญ่มากที่เชื่อมต่อกัน สิ่งนี้ทำให้ฝ่ายที่ไม่ได้เชื่อมต่อโดยตรงสามารถทำการชำระเงินให้กับกันผ่านการเส้นทางการส่งผ่านหลายช่อง โดยที่สัญญาเช่น HTLC และ PTLC รับรองความปลอดภัยของเส้นทาง

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

ขาดความต้องการของเครือข่ายโดยรวม

ตามสถิติล่าสุดจาก Mempool ระบบ Bitcoin Lightning Network ปัจจุบันมีโหนด 12,389 โหนดและ 48,000 ช่องการชำระเงิน โดยมีความจุช่องรวมทั้งหมด 5,311.8 BTC

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

ก่อนอื่น สิ่งสำคัญที่สุดคือลดอุปสรรคในการติดตั้งและบำรุงรักษาโหนด Lightning Network โดยทำให้ผู้ใช้ที่ไม่มีความรู้ทางเทคนิคสามารถเรียกใช้โหนด Lightning Network ได้อย่างง่ายดาย มีทีมหลายทีมในระบบ Bitcoin ที่ได้นำเสนอแนวคิดฮาร์ดแวร์ปลั๊กอินแล้ว เช่นกล่องฮาร์ดแวร์ของ Umbrel ที่รองรับการเรียกใช้โหนด Bitcoin Lightning Network อย่างเป็นตัวอย่าง นอกจากนี้ Fi5Box ไม่เพียงสนับสนุนการทำงานของ Bitcoin Lightning Network เท่านั้น แต่ยังสามารถรองรับการเรียกใช้โหนดสำหรับเครือข่ายอื่นๆ เช่น CKB's Fiber Network อุปกรณ์เหล่านี้จะให้การแก้ไขโหนดที่ไม่ต้องการการบำรุงรักษาจากผู้ใช้งาน

ประการที่สองการแนะนํากลไกแรงจูงใจเพิ่มเติมเป็นกุญแจสําคัญในการสร้างลูปข้อเสนอแนะเชิงบวกสําหรับเครือข่าย Lightning เมื่อเปิดช่องทางการชําระเงินบนเครือข่าย Lightning เงินจะถูกล็อค ตัวอย่างเช่นหากอลิซต้องการทําหน้าที่เป็นผู้ให้บริการ Lightning (LSP) และช่องเปิดที่มีคน 100 คนจัดสรร 1 BTC ต่อช่องเธอจะต้องล็อค 100 BTC กองทุนเหล่านี้สร้างรายได้เฉพาะเมื่อเคลื่อนไหวเท่านั้น เงินที่ไม่ได้ใช้งานไม่ได้ นี่เป็นเพราะรายได้หลักสําหรับโหนด Lightning Network มาจากค่าธรรมเนียมการทําธุรกรรมซึ่งโดยทั่วไปจะคํานวณเป็น "ค่าธรรมเนียมพื้นฐาน + อัตราค่าธรรมเนียมต่อซาโตชิ" ค่าธรรมเนียมพื้นฐานเป็นจํานวนเงินคงที่ที่เรียกเก็บสําหรับแต่ละธุรกรรมโดยไม่คํานึงถึงขนาดในขณะที่อัตราค่าธรรมเนียมคือเปอร์เซ็นต์ที่เรียกเก็บต่อซาโตชิในการทําธุรกรรม

ตามสถิติของ Mempool ค่าธรรมเนียมพื้นฐานเฉลี่ยในปัจจุบันใน Bitcoin Lightning Network คือ 950 mSat (0.95 sat) และอัตราค่าธรรมเนียมเฉลี่ยคือ 764 ppm (0.000764 Sat per satoshi) ซึ่งหมายความว่าสําหรับการทําธุรกรรม 10,000 satoshis (0.0001 BTC ปัจจุบันมีมูลค่าประมาณ $ 6.50) โหนดการกําหนดเส้นทางจะได้รับค่าธรรมเนียมน้อยกว่า 9 satoshis ยิ่งไปกว่านั้นปริมาณธุรกรรมบน Lightning Network ยังค่อนข้างต่ําและธุรกรรมจํานวนมากไม่ต้องการโหนดการกําหนดเส้นทางเลย (เนื่องจากทั้งสองฝ่ายที่เกี่ยวข้องมีช่องทางการชําระเงินโดยตรง) ด้วยเหตุนี้ผู้ที่ถือ BTC และกําลังมองหาผลตอบแทนจากการลงทุนจึงไม่ได้เลือกที่จะล็อค BTC ไว้ในเครือข่าย Lightning เพื่อรับค่าธรรมเนียมการทําธุรกรรมเป็นหลัก แต่พวกเขาชอบที่จะให้ยืม BTC ของพวกเขาในการแลกเปลี่ยนหรือมีส่วนร่วมในโครงการที่เกิดขึ้นใหม่ที่เสนอโอกาสในการปักหลัก / Restaking

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

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

ปัญหาการกระจาย Likuiditi

แม้ว่าปัญหาขาดความเหลือทุนโดยรวมจะได้รับการแก้ไข การกระจายความเหลือทุนนี้อย่างมีประสิทธิภาพยังเป็นความท้าทาย

เรามาดูตัวอย่างที่เอลิสทำการชำระเงินให้แครอลผ่านโหนดเราทิ่มบ๊อบ ตอนแรกทั้งเอลิสและแครอลมีสตอชิส 20,000 ในช่องของพวกเขาในขณะที่บ๊อบมีสตอชิส 10,000 ในแต่ละช่อง หลังจากมีธุรกรรมหลายๆ รายการ การกระจายสมดุลในช่องอาจมีลักษณะดังนี้ (เพื่อความง่าย เราไม่พิจารณารายได้จากการเดินทางของบ๊อบ):

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

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

ในตัวอย่างข้างต้น หนึ่งทางเลือกคือปิดช่องทางระหว่าง Bob และ Carol และเปิดใหม่ อย่างไรก็ตาม วิธีการนี้ไม่เหมาะสมต่อความคุ้มค่าเนื่องจากการปิดและเปิดช่องทางต้องใช้ธุรกรรมในเครือข่าย ซึ่งต้องเสียค่าธุรกรรมใน Bitcoin miner วัตถุมงคล จุดมุ่งหลักของระบบ Lightning Network คือลดการดำเนินการในเครือข่าย และย้ายการทำธุรกรรมให้มากที่สุดเท่าที่จะเป็นไปได้ไปยังช่องทางนอกเครือข่าย ถ้าเปิดและปิดช่องทางล้านๆ ใน Lightning Network ทุกวัน บล็อกเชน Bitcoin จะเต็มไปด้วยและค่าธุรกรรมใน Bitcoin miner จะเพิ่มขึ้นอย่างรวดเร็ว

เพื่อแก้ไขปัญหานี้ ชุมชนบิตคอยน์ได้เสนอหลายวิธีนวัตกรรมเพื่อแก้ไขปัญหาการกระจาย Likvidity

การแลกเปลี่ยนภายใต้น้ำ (การแลกเปลี่ยนภายใต้น้ำ)

ในคำพูดที่เข้าใจง่าย การแลกเปลี่ยน Submarine ช่วยให้ผู้ใช้ส่ง BTC จากช่องของพวกเขาไปยังบริการสลับเงินระหว่างเครือข่าย Lightning นอกจากนี้ บริการสลับเงินจะส่ง BTC จำนวนเท่ากันไปยังที่อยู่ที่ระบุบนบล็อกเชน Bitcoin หรือกลับกัน: ผู้ใช้สามารถส่ง BTC บนเครือข่ายไปยังบริการสลับเงิน ซึ่งจากนั้นจะส่ง BTC จากช่องไปยังโหนดที่ได้รับการระบุ ผ่านกระบวนการนี้แม้ว่าจะเกี่ยวข้องกับบริการสลับเงิน แต่มันเป็นไปได้แบบที่เชื่อถือได้แบบเต็มที่ด้วย HTLC (Hash Time-Locked Contracts)

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

โดยเฉพาะอย่างยิ่งกระบวนการทำงานดังต่อไปนี้:

1. บ็อบสร้างค่าลับ R (preimage) และค่าแฮช H ของมัน
2. บ็อบสร้าง HTLC บนบล็อกเชน Bitcoin โดยใช้แฮช H: เขาจะจ่ายแครอล 10,000 satoshi หากเขาสามารถเปิดเผยความลับ R ภายใน 5 บล็อก; มิฉะนั้นเงินทุนจะกลับมายังบ็อบ
3. Carol สร้าง HTLC ในช่องการชำระเงินของเขากับ Bob โดยใช้ hash เดียวกัน H: เขาจะจ่าย Bob 10,000 satoshis จากช่อง โดยเงื่อนไขคือเขาสามารถเปิดเผย secret R ภายใน 4 บล็อก; มิฉะนั้น ทุนจะคืนมาที่ Carol (เพื่อความง่าย ของเราไม่พิจารณาค่าบริการที่เรียกเก็บโดยศูนย์บริการแลกเปลี่ยนใด ๆ)
4. บ๊อบใช้ R ลับเพื่อปลดล็อก HTLC ในช่องและรับซาโตชิ 10,000 ตัว
5. หลังจากที่บ็อบถอนเงิน แครอลก็ทราบความลับ R และใช้มันเพื่อปลดล็อก HTLC บนบล็อกเชนของบิตคอยน์เพื่อถอน 10,000 ซาโตชิ

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

การต่อ

การประกบช่องเป็นวิธีการปรับสมดุลแบบ on-chain ที่โหนดปิดแชนเนลแล้วเปิดแชนเนลใหม่ในธุรกรรมเดียวซึ่งจะเปลี่ยนยอดคงเหลือที่ล็อคไว้ในแชนเนล เมื่อโหนดล็อคเงินมากขึ้นผ่านกระบวนการนี้จะเรียกว่า "ประกบกัน"; หากลดเงินที่ล็อคไว้จะเรียกว่า "ประกบกัน" ในตัวอย่างข้างต้นช่องระหว่าง Bob และ Carol สามารถขยายได้ผ่านการประกบช่อง

การต่อเชื่อมช่อง (Channel splicing) สะดวกมากกว่าการใช้ธุรกรรมสองรายการเพื่อปิดและเปิดช่องใหม่ อย่างไรก็ตาม ยังจำเป็นต้องกระจายธุรกรรมทั่วเครือข่าย ชำระค่าธรรมเนียมในเหรียญบนเชน และรอให้ธุรกรรมได้รับการยืนยัน

การชำระเงินแบบหลายเส้นทาง (MPP)

การชำระเงินแบบหลายเส้นทางช่วยให้การชำระเงินสามารถแบ่งออกเป็นส่วนหลาย ๆ ส่วนที่สามารถถือหรือเส้นทางผ่านช่องทางที่แตกต่างกันพร้อม ๆ กัน ตัวอย่างเช่น หาก Alice ต้องการจ่ายเงินให้กับ Carol 10,000 satoshis และ Bob ไม่สามารถเส้นทางการชำระเงินอีกต่อไป Alice สามารถจ่ายเงินให้ Carol 6,000 satoshis ผ่านช่องทางการเส้นทางของ David และ 4,000 satoshis ผ่านช่องทางการเส้นทางของ Eva โดยนี้ Alice สามารถทำการชำระเงิน 10,000 satoshis ของเธอได้โดยใช้การชำระเงินแบบหลายเส้นทาง

ความตั้งใจเดิมของเทคโนโลยีการชําระเงินแบบหลายเส้นทางคือการเอาชนะข้อ จํากัด ของการชําระเงินแบบเส้นทางเดียวทําให้สามารถชําระเงินได้มากขึ้นโดยแบ่งออกเป็นส่วนเล็ก ๆ ตัวอย่างเช่นธุรกรรม Lightning Network 1 BTC สามารถแบ่งออกเป็น 100 ธุรกรรมละ 0.01 BTC การชําระเงินแบบหลายเส้นทางเป็นประโยชน์ต่อการกระจายอํานาจเครือข่ายและความเป็นส่วนตัวของธุรกรรม ในแง่ของความปลอดภัยเทคโนโลยีการชําระเงินแบบหลายเส้นทางอะตอม (AMP) ช่วยให้มั่นใจได้ว่าหากเส้นทางหนึ่งล้มเหลวในการชําระเงินการชําระเงินทั้งหมดจะล้มเหลวป้องกันความสับสนและการฉ้อโกง

นอกจากนี้ในเครือข่าย Lightning Network ธุรกรรมขนาดใหญ่ยังสามารถดำเนินการผ่านช่อง Wumbo ได้ ช่อง Wumbo นั้นเอาขีดจำกัดที่มีในจำนวน Bitcoin ที่ช่อง Lightning ปกติสามารถรองรับออก (0.1667 BTC) ออกไป ทำให้โหนดสามารถมีความจุของช่องที่สูงขึ้นและสนับสนุนธุรกรรมที่ใหญ่ขึ้น

สรุป

ความเหนื่อยหน่ายเป็นหนึ่งในปัจจัยหลักที่จำกัดการพัฒนาของ Lightning Network โดยการลดอุปสรรคในการตั้งค่าและบำรุงรักษาโหนด Lightning Network และการนำเสนอกลไกส่วนติดตั้งเพิ่มเติม เครือข่ายสามารถแก้ไขปัญหาความไม่เพียงพอของ Likuidity โดย Solotions เช่น Submarine Swap การตัดแต่งช่องทางและการชำระเงินหลายเส้นทาง ยังช่วยเพิ่มปริมาณการกระจาย Likuidity ในเครือข่าย

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

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

Disclaimer：

1. บทความนี้ถูกคัดลอกมาจาก [ พัดลม RGB++]. All copyrights belong to the original author [Byte CKB]. หากมีคำประสงค์เรื่องการเผยแพร่นี้ กรุณาติดต่อGate เรียนรู้ทีม และพวกเขาจะดำเนินการด้วยรวดเร็ว
2. คำประกาศความรับผิดชอบ: มุมมองและความคิดเห็นที่แสดงในบทความนี้เป็นเพียงของผู้เขียนเท่านั้นและไม่เป็นที่ปรึกษาการลงทุนใดๆ
3. การแปลบทความเป็นภาษาอื่นๆ นำไปทำโดยทีม Gate Learn นอกเหนือจากที่กล่าวถึงไว้ไว้ว่า การคัดลอก การแจกจ่าย หรือการลอกเลียนบทความที่ถูกแปลนั้นถูกห้าม