Lightning Network

Lightning เป็นส่วนของ Bitcoin ที่ทำให้คนฉลาดงงเยอะที่สุด พอได้ยินคำว่า “network” หลายคนก็เผลอคิดว่ามันต้องเป็นเหรียญแยก เป็น sidechain หรือ Bitcoin spinoff อะไรสักอย่าง แต่ไม่ใช่เลยสักข้อ Lightning คือ payment layer ที่ซ้อนอยู่บน Bitcoin — เป็น BTC เดิม คีย์เดิม แค่เป็นวิธีโยกมูลค่าโดยไม่ต้องเขียนทุกธุรกรรมลงบน base chain ผมรัน Lightning node ของตัวเองมาตั้งแต่ปี 2019 บวกกับใช้ Phoenix บนมือถือ และได้ดูเครือข่ายนี้เติบโตจากของเล่นกลายเป็นโครงสร้างพื้นฐานที่รับการจ่ายเงินจริงทุกวินาที

หน้านี้อธิบายว่าตัวเลขบนหน้า dashboard คืออะไร ตัวเลขพวกนั้นสำคัญยังไง และอะไรที่มันไม่ได้บอกคุณ

Lightning ก็คือ Bitcoin แค่เร็วกว่า

ไม่มีสิ่งที่เรียกว่า “เหรียญ Lightning” เวลาคุณเปิด channel บน Lightning คุณส่ง BTC จริง ๆ ไปยังที่อยู่ 2-of-2 multisig บน base chain BTC ก้อนนั้นจะนอนอยู่ตรงนั้น โดยคุณกับคู่ channel ถือร่วมกัน จนกว่า channel จะปิด — ตอนนั้นแหละถึงจะเขียน settlement สุดท้ายกลับลง L1

ทุกอย่างที่เกิดขึ้นระหว่างทาง — การจ่ายเงินทุกครั้ง การ routing ทุก hop การ tip รายนาทีของ podcast — คือคู่สัญญาทั้งสองเซ็น commitment transaction เวอร์ชันใหม่ของ multisig output ตัวเดิม ตกลงกันว่าตอนนี้ใครเป็นเจ้าของกี่สัตส์ ไม่มี miner คนไหนเห็น update พวกนี้ มันเกิด off-chain แต่บังคับใช้บน chain ได้ทุกเมื่อด้วย cryptography

หัวใจสำคัญ: Bitcoin base layer คือศาล ส่วน Lightning คือสัญญา คุณไปศาลเฉพาะตอนที่จำเป็นเท่านั้น

channel

Alice กับผมเปิด channel ด้วยการเอาเงินมารวมกันใน 2-of-2 multisig สมมติว่าผมใส่ 1,000,000 sats Alice ใส่ 0 ธุรกรรมเปิด channel ยืนยันบน chain ตอนนี้เราถือ “commitment transaction” ร่วมกันที่บอกว่า 1,000,000 sats เป็นของผม 0 เป็นของ Alice

พอผมจ่ายเธอ 50,000 sats เราจะเซ็น commitment ใหม่: 950,000 ของผม 50,000 ของเธอ commitment เก่าจะถูกยกเลิกผ่านการแลก revocation key ใครจะ broadcast commitment ล่าสุดแล้วเดินจากไปพร้อมส่วนของตัวเองเมื่อไหร่ก็ได้ แต่ถ้าฝ่ายไหนโกงโดยพยายาม publish state เก่าที่ตัวเองได้เปรียบ อีกฝ่ายจะใช้ revocation key เคลมเงินทั้ง channel เป็นค่าปรับได้

กลไกค่าปรับนี้แหละที่ทำให้ trust model ของมันใช้ได้จริง — โกงเมื่อไหร่ เสียทั้งกระเป๋า

graph ของเครือข่าย

channel หนึ่งคือสองฝ่าย แต่เครือข่ายคือ channel หลายหมื่นเส้นที่ถูกต่อกันเป็นโครงข่าย public node ทุกตัวจะประกาศ channel ของตัวเองผ่าน gossip protocol — นี่คือวิธีที่ mempool.space และ 1ml.com เอามาทำ dashboard เวลาผมจ่ายให้ใครที่อยู่ห่างไป 4 hop node ของผมจะหา path A → B → C → D แล้วสร้างการจ่ายเงินที่เดินผ่านเส้นทางนั้น

เคล็ดลับคือ HTLCs — Hashed Time-Locked Contracts ผู้รับสร้าง secret ขึ้นมา hash มัน แล้วส่ง hash มาให้ผม ผมไปบอกแต่ละ hop ว่า “ผมจะปล่อยสัตส์ก้อนนี้ ถ้าคุณส่ง preimage มาให้ภายใน X block” แต่ละ hop จะ forward ต่อก็ต่อเมื่อ hop ถัดไปยอมผูกเงื่อนไขเดียวกัน พอผู้รับเปิดเผย preimage ความลับนั้นจะวิ่งย้อนกลับขึ้นมาตามเส้นทาง และทุก hop จะ settle พร้อมกันแบบ atomic

ไม่จ่ายสำเร็จทั้งหมด ก็ไม่จ่ายเลย ไม่มี hop ไหนขโมยกลางทางได้ — เงินจะปล่อยก็ต่อเมื่อมี preimage มาแลกเท่านั้น

ทำไมมันใช้งานได้

มี 3 คุณสมบัติที่ทำให้ Lightning มีประโยชน์:

• ทันใจ การ update channel ใช้เวลาแค่ระดับมิลลิวินาทีถึงวินาที ไม่ต้องรอ block 10 นาที
• ถูก ค่า routing โดยทั่วไปแค่ไม่กี่ sats หรือเศษของ sat ต้นทุน marginal ของการจ่ายเงินแทบเป็นศูนย์
• scale ได้ throughput ถูกจำกัดด้วยจำนวน channel ไม่ใช่ block 1MB ของ Bitcoin channel เดียวรองรับการจ่ายเงินได้หลายพันครั้งต่อวินาที

ราคาที่ต้องจ่ายคือเงินทุนที่ถูกล็อกไว้ — sats ต้องนอนอยู่ใน multisig จนกว่า channel จะปิด แลก capital efficiency เพื่อ transaction efficiency

ตัวเลขบน dashboard นี้

ตัวเลขหลัก ๆ:

• Public capacity: ราว 5,000–7,000 BTC ในช่วงปลายปี 2024 ถึง 2026 — รวม BTC ใน channel ที่ประกาศต่อสาธารณะ
• Channel count: ประมาณ 50,000 ถึง 70,000 public channel
• Node count: ประมาณ 17,000 ถึง 20,000 public node
• 30-day delta: สัญญาณการเติบโตแบบ rolling เป็นบวกแปลว่ามี capacity ใหม่ ติดลบมักหมายถึงการรวบ channel หรือ channel ปิดไป

ตัวเลขทั้งหมดนี้มาจาก gossip protocol ที่ mempool.space กับ 1ml.com ไป scrape มา แม่นยำในแง่สิ่งที่มันวัด — แต่สิ่งที่มันวัดนั้นไม่ครบ

public กับ private channel

นี่คือจุดที่ dashboard “โกหกด้วยการไม่พูด”

Public channel จะถูกประกาศ ทั้ง capacity และนโยบายค่าธรรมเนียมจะถูก gossip ไปทุก node นี่คือวิธีที่ routing ทำงาน

Private channel (ไม่ประกาศ) มองไม่เห็น mobile wallet ส่วนใหญ่ — Phoenix, Wallet of Satoshi, Breez, Mutiny — เปิด private channel ไปยัง service node ของตัวเอง ผู้ใช้ส่งและรับเงินได้ปกติ แต่ channel นั้นไม่เคยโผล่ในกราฟสาธารณะเลย

private channel โตเร็วมาก ลำพัง Phoenix เจ้าเดียวก็มีผู้ใช้หลายแสนคน แต่ละคนมี channel ไปหา ACINQ capacity Lightning จริงที่ใช้งานอยู่น่าจะหลายเท่าของตัวเลขสาธารณะ ให้อ่าน “5,500 BTC ของ public capacity” เป็นพื้นล่าง ไม่ใช่ความจริงทั้งหมด

custodial กับ non-custodial

มันเป็นสเปกตรัม ไม่ใช่ขาวดำ:

• custodial Wallet of Satoshi, Strike พวกเขารัน node คุณมีแค่ยอดบัญชี เริ่มใช้ง่าย แต่เขาอาจ freeze ทำเงินหาย หรือถูกสั่งปิดได้ Not your keys, not your coins
• non-custodial บนมือถือ Phoenix, Breez, Mutiny, Zeus คุณถือคีย์เอง wallet จัดการ channel ให้อัตโนมัติ มักจะคิด premium เล็กน้อย
• self-hosted LND, Core Lightning (CLN), Eclair คุมเองเต็ม รับผิดชอบเองเต็ม — คุณดูแล liquidity คู่ channel และ uptime เอง อันนี้คือสิ่งที่คนรัน node และร้านค้าต่าง ๆ ใช้กัน

ผมใช้ Phoenix บนมือถือสำหรับจ่ายเงินรายวัน และ Eclair node ส่วนตัวเอาไว้ทดลอง routing

liquidity คือปัญหาตัวจริง

capacity ไม่เท่ากับ liquidity ที่ใช้งานได้ channel หนึ่งมีสองด้านเสมอ:

• outbound liquidity — sats ฝั่งคุณ คือสิ่งที่คุณจ่ายออกได้
• inbound liquidity — sats ฝั่งคู่สัญญา คือสิ่งที่คุณรับได้

channel ที่คุณเป็นคนใส่เงินทั้งหมดจะมี outbound 100% และ inbound 0% คุณจะรับอะไรไม่ได้เลยจนกว่าจะใช้จ่ายออกไปก่อน สำหรับร้านค้า เรื่องนี้คือปัญหาปวดหัวหลักในการดำเนินงาน

บริการอย่าง Magma (Amboss), Lightning Pool และ LSP ต่าง ๆ (Lightning Service Providers) ให้คุณซื้อ inbound liquidity ได้ — จ่ายค่าธรรมเนียม แล้วเขาจะเปิด channel มาหาคุณโดยมี sats ฝั่งโน้นรออยู่แล้ว Phoenix ฝังเรื่องนี้ลงใน UX ผ่าน splicing และ just-in-time channel ทำให้ปัญหานี้ถูกซ่อนไว้ แลกกับค่าธรรมเนียมเล็กน้อยต่อการรับเงินแต่ละครั้ง

routing ในชีวิตจริง

การจ่ายเงินส่วนใหญ่ที่ต่ำกว่า 100,000 sats จะ route ภายในไม่กี่วินาทีผ่าน 2 ถึง 5 hop การหาเส้นทาง (เป็นแบบ Dijkstra ที่ถ่วงน้ำหนักด้วยค่าธรรมเนียม + ความน่าเชื่อถือ) จะเลือกเส้นทางที่บาลานซ์ระหว่างต้นทุนกับโอกาสสำเร็จ

สำหรับการจ่ายก้อนใหญ่ MPP (Multi-Part Payments) จะแยกการจ่ายออกเป็นหลายเส้นทางขนานกัน เงิน 5 ล้าน sats อาจวิ่งเป็น 10 shard ละ 500,000 sats ผ่าน 10 เส้นทาง HTLC จะเป็น atomic ที่ปลายทาง — ไม่ทุก shard มาถึงและเปิด preimage พร้อมกัน ก็ไม่ settle เลย

นี่ก็เป็นเหตุผลว่าทำไม Lightning ไม่เหมาะกับการโยก bitcoin เป็นก้อนใหญ่ ๆ ทั้งเหรียญ — base chain จัดการเรื่องนั้นได้ดีกว่า

ทำไมค่าธรรมเนียมถึงต่ำมาก

ธุรกรรม on-chain ทั่วไปมีค่าใช้จ่ายราว $0.50 ถึง $5+ (ราว 17–170 บาท) ตามสภาพ mempool ส่วนการจ่าย Lightning ทั่วไปมีค่าใช้จ่ายต่ำกว่า 1 เซ็นต์ (ไม่ถึง 35 สตางค์) เหตุผลคือเชิงโครงสร้าง: ต้นทุน marginal ของการ routing คือแบนด์วิดท์กับ opportunity cost ของ liquidity ที่ถูกใช้ route เท่านั้น ไม่มีการแย่ง block space กัน node ที่ทำ routing ตั้งค่าธรรมเนียมตาม utilization และการแข่งขันก็กดให้ค่าธรรมเนียมต่ำอยู่

อะไรที่อาจพังได้

โหมดความล้มเหลวหลักคือ force-close คู่สัญญาคุณ offline ไป หรือคุณสงสัยว่าเขาจะโกง คุณก็เลย publish commitment ล่าสุดออกไปฝ่ายเดียว sats ปลอดภัยอยู่ แต่จะถูกล็อกไว้ใต้ timelock 144 block (~24 ชั่วโมง) — เป็นช่วงเซฟตี้เผื่อกรณีคู่สัญญาพยายาม publish state เก่ากว่า คุณยังต้องจ่ายค่าธรรมเนียม on-chain ด้วย ซึ่งวันที่ค่าธรรมเนียมแพงก็อาจเป็นเงินก้อนพอสมควร

นี่แหละเหตุผลที่บางครั้งผู้ใช้มือถือตื่นมาเจอข้อความ “channel force-closed” ส่วนใหญ่ไม่ได้มีใครจะโกง — LSP ขยับ liquidity หรือ node restart แล้วเจอ state เก่า เงินคุณยังอยู่ครบ แค่ต้องรอ

ถ้าคุณ offline นานพอ คู่สัญญาอาจลอง publish state เก่า watchtower คือบริการของบุคคลที่สามที่คอยเฝ้าดู chain แทนคุณ และจะ broadcast ธุรกรรมลงโทษให้ถ้าเห็นการโกง ผู้ใช้ทั่วไปส่วนใหญ่ไม่จำเป็นต้องใช้ ส่วนร้านค้าและ operator ที่ offline เป็นปกติมักสมัครใช้

คำแนะนำเชิงปฏิบัติ

ถ้าคุณเพิ่งเริ่มใช้ Lightning:

1. เริ่มที่ wallet แบบ custodial (Wallet of Satoshi, Strike) เพื่อทำความรู้จัก UX ก่อน
2. ขยับมา non-custodial บนมือถือ (Phoenix คือตัวที่ผมเลือก) เพื่อ self-custody พร้อม default ที่สมเหตุสมผล
3. ถ้าอยากร่วมเครือข่ายเต็มตัว รัน node ของตัวเองเลย Umbrel, Start9 และ RaspiBlitz มี Bitcoin Core บวก Lightning มัดรวมไว้บน Raspberry Pi เรียบร้อย

ที่สำคัญที่สุด: อย่าเก็บเงินออมไว้บน Lightning channel คือรางจ่ายเงิน — ไว้ใช้ liquidity ไม่ใช่เก็บระยะยาว เก็บกองหลักไว้ใน cold storage และเก็บเงินค่าใช้จ่ายไว้บน Lightning

สถานะของ Lightning ตอนนี้

การ adopt จริง ๆ กำลังเกิดขึ้น แค่กระจายไม่เท่ากัน Strike ประมวลผล remittance volume เข้าเอลซัลวาดอร์และฟิลิปปินส์เป็นเรื่องเป็นราว Nostr ใช้ Lightning zap เป็นกลไก tip default Bitcoin podcast แบ่ง sats ต่อนาทีให้พิธีกรผ่าน Podcasting 2.0

frontier ตอนนี้คือการแก้ UX โปรโตคอลที่สำคัญมี 2 ตัว:

• BOLT12 offers — request การชำระเงินที่ใช้ซ้ำได้ ทำงานเหมือน QR code static ลบขั้นตอนชวนหงุดหงิดอย่าง “สร้าง invoice ใหม่ทุกครั้ง” ออกไป
• Taproot Assets — ออก token (รวม USD stablecoin) บน Bitcoin แล้ว route ผ่าน Lightning เริ่ม deploy ในปี 2025–2026 อันนี้อาจเปิด Lightning ให้รองรับการจ่ายเงินที่ไม่ใช่ BTC ได้ โดยไม่ต้องทิ้ง base layer

แหล่งอ้างอิง

• BOLT specifications — โปรโตคอล
• mempool.space lightning dashboard — สถิติของ public graph
• 1ML statistics — มุมมองกราฟอีกแบบ
• Amboss — analytic ของ node และตลาด liquidity
• Lightning whitepaper, Poon-Dryja 2016 — แบบดีไซน์ดั้งเดิม
• Mastering Lightning — reference เชิงลึกแบบ open-source

Lightning ยังไม่ใช่ของที่เสร็จสมบูรณ์ การจัดการ liquidity ยังยากสำหรับผู้ใช้ทั่วไป ความน่าเชื่อถือของการ routing ดีขึ้น แต่ก็ยังไม่สมบูรณ์แบบ dashboard ก็นับ activity จริงต่ำกว่าความเป็นจริง แต่มันใช้งานได้จริงในวันนี้ ตามที่มันอ้างไว้ — คือจ่าย Bitcoin ได้ทันใจและถูก อย่าเชื่อผม รัน node ของตัวเองแล้วดู sats วิ่งด้วยตัวคุณเอง