= 6 sats
Each routing node sets its own policy. Actual costs may differ. Liquidity constraints can force longer paths. Not financial advice.
ค่าธรรมเนียม Lightning Network ทำงานยังไง
Lightning Network ทำให้การจ่ายเงิน Bitcoin ยืนยันในมิลลิวินาที เสียเศษเซ็นต์ และขยายถึงล้าน transaction ต่อวินาที — โดยไม่แตะ Bitcoin blockchain สำหรับทุกการจ่ายเงินรายตัว เพื่อทำสิ่งนี้ Lightning route การจ่ายเงินข้ามเครือข่ายของ payment channel และแต่ละ routing node บน path คิดค่าธรรมเนียมเล็กน้อยสำหรับการ forward calculator นี้ model ค่าธรรมเนียมนั้นด้วยสูตรค่าธรรมเนียม Lightning มาตรฐาน
model ค่าธรรมเนียม: base + proportional
ทุก Lightning node ที่ forward การจ่ายเงินคิดตาม 2 parameter ที่ตั้งเองอิสระ:
Base fee: ค่าธรรมเนียม flat เป็น millisatoshi (msat) คิดครั้งเดียวต่อการจ่ายเงินไม่ว่าขนาดเท่าไร routing node ส่วนใหญ่ตั้งระหว่าง 0 ถึง 1,000 msat (0-1 sat) base fee 1,000 msat หมายความว่า node คิด 1 sat พอดีสำหรับการ forward การจ่ายเงินใดๆ ไม่ว่าจะเป็น 1,000 sats หรือ 100,000,000 sats
Proportional fee (ppm): ค่าธรรมเนียมที่แสดงเป็น parts per million ของจำนวนการจ่ายเงิน อัตรา 10 ppm หมายความว่า node คิด 10 satoshi ต่อล้าน satoshi ที่ route หรือเท่ากับ 0.001% ของการจ่ายเงิน ที่อัตรานี้ การ forward 100,000 sats เสีย 1 sat การ forward 1,000,000 sats เสีย 10 sats
สูตรค่าธรรมเนียมรวมสำหรับ hop เดียว:
hop_fee = base_fee_sats + (payment_amount_sats × ppm) / 1_000_000สำหรับการจ่ายเงินหลาย hop ข้าม N hops ค่าธรรมเนียมรวมสะสมข้ามทุก routing node:
total_fee = N × (base_fee_sats + (amount × ppm) / 1_000_000)นี่คือ model ที่ทำให้ง่ายลงที่สมมติว่านโยบาย channel สม่ำเสมอทุก hop ในความจริง แต่ละ hop มี base fee และ ppm ของตัวเอง เครื่องมือนี้ให้คุณตั้งนโยบายเดียวแล้วใช้สม่ำเสมอ — ซึ่งเป็นการประมาณที่ดีสำหรับวัตถุประสงค์การวางแผนและเข้าใจความไวของค่าธรรมเนียม
ทำไมค่าธรรมเนียม Lightning มักเป็นเพนนี
ตัวเลขข้างบนเน้นว่าทำไม Lightning ถึงเปลี่ยนเกมสำหรับการจ่ายเงิน Bitcoin เล็กๆ ลองดูการจ่าย $10 ที่ราคา BTC $100,000:
- $10 = 10,000 sats
- ที่ 3 hops ด้วย 1 sat base fee และ 10 ppm ต่ออัน:
- ค่าธรรมเนียมรวม = 3 × (1 + 10,000 × 10 / 1,000,000) = 3 × (1 + 0.1) = 3.3 sats
- ที่ $100,000/BTC 3.3 sats ≈ $0.0033 — หนึ่งในสามของเซ็นต์
เทียบกับ Bitcoin on-chain ที่ transaction ปกติที่ 5 sat/vbyte สำหรับ Native SegWit transaction เสียประมาณ 700 sats — ประมาณ $0.70 ที่ราคาเดียวกัน Lightning ถูกกว่าประมาณ 200 เท่าสำหรับตัวอย่างนี้ และข้อได้เปรียบเพิ่มขึ้นเมื่อค่าธรรมเนียมแสดงต่อ hop ไม่ใช่ต่อ byte
เครือข่าย credit card คิดร้านค้า 1.5-3.5% ของมูลค่า transaction ที่ 10 ppm ต่อ hop และ 3 hops Lightning คิด 0.003% — น้อยกว่า 3 เท่าของสิบ
Multi-hop paths และ path finding
จำนวน hop ใน Lightning payment path ขึ้นกับ topology ของเครือข่าย channel ตรงระหว่างผู้จ่ายกับผู้รับเสียค่าธรรมเนียม routing 0 (คุณจ่ายแค่ค่าธรรมเนียม commitment transaction on-chain เมื่อเปิดและปิด channel) เมื่อไม่มี channel ตรง algorithm หา path ของโหนด Lightning เลือก route ผ่าน intermediate node ลด cost ค่าธรรมเนียมตามข้อจำกัด liquidity
การจ่ายเงินปกติบน Lightning Network ผ่าน 2-5 hops การจ่ายเงินที่ hop น้อยกว่าถูกกว่า การจ่ายเงินที่ต้องหลาย hop (6+) ผิดปกติในเครือข่ายที่เชื่อมต่อกันดีและส่งสัญญาณโหนดที่อยู่ในตำแหน่งไม่ดีหรือ path ที่ liquidity ต่ำ
ช่วง 1-8 hop ใน calculator นี้ครอบคลุม spectrum จริงเต็ม การจ่ายเงินตรงคือ 0 hop ด้วย 0 routing fee (ตั้ง hops เป็น 1 ด้วย 0 base fee และ 0 ppm เพื่อจำลอง routing เกือบตรง) 8 hop คือขอบบนที่จะเกิดเฉพาะในกราฟเครือข่ายที่แตกเป็นเศษมาก
Channel liquidity และทำไมค่าธรรมเนียมต่างกัน
ไม่ใช่ทุก channel มี liquidity เพียงพอในทั้ง 2 ทิศทาง ถ้า Alice ต้องการจ่าย Bob ผ่าน Carol channel ระหว่าง Alice กับ Carol ต้องมี outbound liquidity เพียงพอ (จากฝั่ง Alice) และ channel ระหว่าง Carol กับ Bob ต้องมี inbound liquidity เพียงพอ (จากฝั่ง Carol) เมื่อ liquidity แน่นบน path เฉพาะ algorithm หา path หา route ทางเลือกซึ่งอาจมีค่าธรรมเนียมสูงหรือ hop มากกว่า
ข้อจำกัด liquidity นี้คือเหตุผลหลักที่ค่าธรรมเนียม routing จริงบางครั้งเกินสูตรง่ายๆ ในเครือข่ายที่สมดุลดีด้วย liquidity ลึก ค่าธรรมเนียมเข้าใกล้ขั้นต่ำทฤษฎี ในช่วงเครือข่ายเครียดหรือสำหรับการจ่ายเงินใหญ่ผิดปกติ ค่าธรรมเนียมอาจสูงกว่าหลายเท่าเมื่อ algorithm ใช้ path ถูกๆ หมดและ fall back ไป route แพงกว่า
FAQ
ทำไมค่าธรรมเนียม Lightning ถูกกว่าค่าธรรมเนียม on-chain มาก?
ค่าธรรมเนียม on-chain ชดเชย miner สำหรับการเก็บ transaction ของคุณใน blockchain ของ Bitcoin ถาวร — ทรัพยากรที่ผู้ใช้ Bitcoin ทุกคนใช้ร่วมกันตลอดอายุของเครือข่าย ค่าธรรมเนียม Lightning ชดเชย routing node เฉพาะสำหรับการใช้ทุนที่ล็อกไว้ใน payment channel ชั่วคราว และบริการให้เกือบทันที เศรษฐศาสตร์ต่างกันโดยพื้นฐาน: ค่าธรรมเนียม on-chain คือค่าธรรมเนียมสำหรับพื้นที่เก็บข้อมูลโลกถาวร ค่าธรรมเนียม Lightning คือค่าธรรมเนียมสำหรับการใช้ทุนชั่วขณะ
ppm หมายถึงอะไร?
PPM ย่อมาจาก parts per million เป็นหน่วยสำหรับแสดงอัตราส่วนเล็กมาก 1 ppm = 0.0001% = 0.000001 (เป็นตัวคูณทศนิยม) node ที่คิด 100 ppm ได้ 100 satoshi ต่อล้าน satoshi ที่ forward หรือ 0.01% ของการจ่ายเงิน routing node ที่แข่งขันส่วนใหญ่คิด 1-500 ppm ที่ 10-100 ppm พบทั่วไปสำหรับ node ที่เชื่อมต่อดีบน corridor การจ่ายเงินยอดนิยม
channel liquidity กระทบ routing ยังไง?
แต่ละ payment channel มี total capacity คงที่และแบ่งระหว่าง local balance (ฝั่งคุณ) กับ remote balance (ฝั่งอีกโหนด) การจ่ายเงินไหลในทิศทางเฉพาะเมื่อมี balance เพียงพอฝั่งส่ง ถ้า channel ของ Alice ไปยัง Bob มี capacity 100,000 sats แต่ทั้งหมดอยู่ฝั่ง Bob (remote balance) Alice route การจ่ายเงินผ่าน channel นั้นไปฝั่ง Bob ไม่ได้ การจัดการ channel liquidity — รักษาการแบ่งเงินที่สมเหตุสมผล — คือความท้าทายในการดำเนินการหลักสำหรับ Lightning routing node
จ่าย 0 routing fee ได้ไหม?
ได้ ใน 2 scenario: (1) คุณมี channel ตรงกับผู้รับและการจ่ายเงินพอดี outbound balance ของคุณ หรือ (2) routing node ตั้งทั้ง base fee และ ppm เป็น 0 บาง node ตั้ง 0 fee บาง channel เพื่อดึงดูด flow และเก็บ proportional fee บน corridor volume สูงกว่า ในทางปฏิบัติ routing 0 fee มีสำหรับการจ่ายเงินเล็ก ทิศทางทั่วไป บน corridor ที่ก่อตั้งมาดี
ค่าธรรมเนียมจริงสำหรับการจ่ายเงินปกติคือเท่าไร?
สำหรับการจ่ายเงิน 10,000-100,000 sats (ประมาณ $10-$100 ที่ $100k/BTC) ข้าม 3 hops ที่ 1 sat base fee และ 10 ppm ค่าธรรมเนียม routing รวมปกติ 3-4 sats — ต่ำกว่า 1 US cent สำหรับการจ่ายเงินใหญ่ (1,000,000 sats = 0.01 BTC ≈ $1,000) นโยบายเดียวกันได้ประมาณ 33 sats หรือประมาณ $0.033 ค่าธรรมเนียม Lightning scale มีประสิทธิภาพมากกับขนาดการจ่ายเงิน
เครื่องมือนี้คำนึง HTLC overhead ไหม?
ไม่ นอกจาก routing fee แต่ละ hop ใน Lightning payment เกี่ยวข้องกับ HTLC (Hash Time-Locked Contract) ซึ่งเพิ่มความต้องการทุน reserved เล็กน้อยและในกรณี failure ค่าธรรมเนียม fallback on-chain สำหรับการจ่ายเงินที่สำเร็จ HTLC overhead ไม่ได้คิดแยก — parameter ค่าธรรมเนียมข้างต้นคือ cost ครบ เครื่องมือนี้ model เฉพาะนโยบายค่าธรรมเนียมมาตรฐานและละเลย edge case อย่างการจ่ายเงิน fail หรือ force-close channel