ไอเดียใหม่ในการขยายบิตคอยน์: LayerTree จะทำให้คนนับล้านใช้ UTXO ร่วมกันได้หรือไม่?

ผู้เขียน: 798.eth

Olaoluwa Osuntokun ผู้ร่วมก่อตั้ง Lightning Labs เพิ่งเผยแพร่การออกแบบการขยายบิตคอยน์ชุดใหม่ชื่อว่า LayerTree

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

ฟังดูขัดแย้งกันเล็กน้อย

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

LayerTree พยายามหาจุดยืนใหม่ระหว่างสองสิ่งนี้

บนเชนเก็บ UTXO ไว้เพียงรายการเดียว จำนวนบิตคอยน์ที่แต่ละคนถืออยู่ถูกบันทึกไว้ใน Merkle Sum Tree นอกเชน ผู้ให้บริการรับผิดชอบดูแลบริการประจำวัน แต่ไม่สามารถแก้ไขยอดคงเหลือของผู้ใช้ตามอำเภอใจ และไม่สามารถ阻止ผู้ใช้เดิมนำเงินของตนกลับขึ้นเชนได้

ต้นไม้หนึ่งต้นแทนยอดคงเหลือของทุกคนได้อย่างไร

ใน LayerTree ผู้ใช้แต่ละคนมีโหนดใบหนึ่งโหนด

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

สมมติว่าต้นไม้มีสี่คน:

Alice มี 5 BTC, Bob มี 3 BTC, Carol และ David มีคนละ 1 BTC

UTXO ที่ใช้ร่วมกันบนเชนถือครองทั้งหมด 10 BTC รากต้นไม้ให้คำมั่นว่าสี่คนนี้ถือครองยอดคงเหลือเท่าใด และยอดคงเหลือทั้งหมดรวมกันเท่ากับ 10 BTC พอดี

ใครก็ตามแก้ไขโหนดใบหนึ่งโหนด รากต้นไม้จะเปลี่ยนไป หากมีคนพยายามเพิ่มยอดคงเหลือโดยไม่มีสิทธิ์ การตรวจสอบจำนวนเงินที่โหนดรากจะล้มเหลว

บนเชนบิตคอยน์ไม่ต้องเก็บต้นไม้ทั้งต้น เพียงเก็บรากนี้ และ UTXO ที่สอดคล้องกับยอดรวมในต้นไม้

นี่เทียบเท่ากับการบีบอัดบันทึกสิทธิ์ในทรัพย์สินของผู้ใช้จำนวนมากให้เป็นคำมั่นสัญญาทางการเข้ารหัสหนึ่งรายการ

ผู้ใช้ถอนออกฝ่ายเดียวได้อย่างไร

เมื่อ Alice ต้องการถอนออก เธอไม่ต้องได้รับการอนุมัติจากผู้ให้บริการ และไม่ต้องให้ผู้ใช้คนอื่นออนไลน์

เธอเพียงส่งโหนดใบของตน หลักฐาน Merkle จากโหนดใบไปยังรากต้นไม้ และลายเซ็นของตน

สคริปต์บิตคอยน์จะตรวจสอบว่า Alice อยู่ในต้นไม้นี้จริง ยืนยันว่าเธอถือครองยอดคงเหลือที่สอดคล้องกัน แล้วทำสองสิ่งในธุรกรรมเดียว:

หนึ่ง จ่ายยอดคงเหลือของ Alice ไปยังที่อยู่ถอนที่เธอกำหนด

สอง ลบโหนดใบของ Alice และนำเงินที่เหลือใส่ UTXO ที่ให้คำมั่นกับรากต้นไม้ใหม่

ไม่ว่าต้นไม้จะมีหนึ่งร้อยคนหรือหนึ่งล้านคน Alice ก็เพียงกระจายธุรกรรมการถอนหนึ่งรายการ

การถอนแบบ O(1) ที่ LayerTree กล่าวถึง หมายถึงจำนวนธุรกรรมที่ต้องใช้ในการถอนมีเพียงหนึ่งรายการเสมอ ขนาดของหลักฐาน Merkle ยังคงเพิ่มขึ้นตามจำนวนสมาชิก ประมาณตาม O(log N)

การออกแบบนี้บีบอัดผู้ใช้จำนวนมากในสถานะปกติให้อยู่ใน UTXO เดียว ขณะเดียวกันก็รักษาช่องทางหลบหนีบนเชนในสถานะผิดปกติ

วิธีการโอนสองแบบใน LayerTree

หากผู้ใช้แก้ไขรากต้นไม้ทุกครั้งที่โอน ธุรกรรมทั้งหมดก็ยังต้องขึ้นเชนตามลำดับ ผลการขยายจะจำกัดมาก

ดังนั้น LayerTree จึงทำการชำระเงินประจำวันแบบนอกเชน โดยมีสองวิธีหลัก: channel leaf และ voucher

Channel leaf: ใส่ช่อง Lightning ลงในโหนดใบ

โหนดใบหนึ่งโหนดสามารถแทนช่อง Lightning ระหว่างผู้ใช้กับผู้ให้บริการ

เอาต์พุตเงินทุนของช่องยังไม่ปรากฏเป็น UTXO แยกบนเชนชั่วคราว แต่มันถูกรวมอยู่ในเอาต์พุตที่ใช้ร่วมกันของ LayerTree ทั้งต้น เมื่อผู้ใช้ชำระเงินระหว่างกัน จะส่งต่อ HTLC ของ Lightning ธรรมดาผ่านผู้ให้บริการ

ระหว่างการชำระเงิน รากต้นไม้ของ LayerTree ไม่เปลี่ยนแปลง และไม่เกิดธุรกรรมบนเชน

ดังนั้น ความเร็วในการชำระเงินของ channel leaf จึงใกล้เคียงกับ Lightning ธรรมดา โดยปกติเสร็จภายในไม่กี่วินาที ผู้ให้บริการทำหน้าที่เป็นโหนดเส้นทางตรงนี้ ส่วน LayerTree รับผิดชอบบีบอัด UTXO บนเชนที่ช่องต้องการ

มันคล้ายกับศูนย์กลาง Lightning ขนาดใหญ่ที่ใช้เอาต์พุตเดียวบนเชน

Voucher: เช็คดิจิทัลที่นำไปขึ้นเงินบนเชนได้

ส่วนที่สร้างสรรค์กว่าของ LayerTree คือ voucher

Voucher เข้าใจได้ว่าเป็นเช็คดิจิทัลที่ผู้ใช้ลงนาม และสคริปต์บิตคอยน์ให้ความสามารถในการบังคับใช้ขั้นสุดท้าย

สมมติว่าโหนดใบของ Alice มี 100,000 sats เธอต้องการจ่าย Bob 10,000 sats

Alice ไม่ต้องแก้ไขต้นไม้ทั้งต้นทันที เธอเพียงลงนามข้อความหนึ่ง ระบุว่า voucher นี้เป็นของ LayerTree ต้นใด เงินทุนมาจากโหนดใบใด Bob จะได้รับโหนดใบใหม่แบบใด จำนวนเงินที่จ่ายเท่าใด และหมายเลขลำดับสถานะปัจจุบันของโหนดใบ Alice

Alice ส่ง voucher ที่ลงนามแล้วให้ Bob การชำระเงินนอกเชนก็เสร็จสิ้น

กระบวนการนี้เกี่ยวข้องเพียงลายเซ็นและการส่งผ่านเครือข่าย ความเร็วใกล้เคียงกับการโอนภายในกระดานเทรด

ข้อแตกต่างสำคัญคือ สิ่งที่ Bob ได้รับไม่ใช่แค่บันทึกยอดคงเหลือในฐานข้อมูลของผู้ให้บริการ เขาได้รับคำสั่งชำระเงินที่สามารถส่งให้สคริปต์บิตคอยน์ดำเนินการได้

หาก Alice หรือผู้ให้บริการหยุดให้ความร่วมมือ Bob สามารถส่ง voucher ขึ้นเชนด้วยตนเอง สัญญา LayerTree จะหักจำนวนเงินที่สอดคล้องกันจากโหนดใบของ Alice และสร้างโหนดใบใหม่ให้ Bob พร้อมกัน

กระบวนการทั้งหมดเรียกว่า CLAIM

Alice ไม่ต้องลงนามอีกครั้ง และผู้ให้บริการก็ไม่สามารถขัดขวาง Bob ขึ้นเงินได้

ทำไม voucher หนึ่งใบใช้ได้เพียงครั้งเดียว

โหนดใบของ LayerTree ทุกโหนดมีหมายเลขลำดับสถานะ เรียกว่า seq

สมมติว่า seq ปัจจุบันของ Alice คือ 7 voucher ที่เธอลงนามจะผูกกับ seq 7 อย่างชัดเจน

เมื่อ voucher หนึ่งใบถูกขึ้นเงินแล้ว ยอดคงเหลือของ Alice จะลดลง และ seq จะเพิ่มจาก 7 เป็น 8 voucher เก่าทั้งหมดที่ผูกกับ seq 7 จะหมดอายุตามไปด้วย

นี่ป้องกันไม่ให้เช็คใบเดียวกันถูกขึ้นเงินซ้ำ

หาก Alice จ่ายเงินให้ Bob บ่อยครั้ง เธอก็ไม่ต้องสร้าง voucher อิสระแยกกันทุกครั้ง

การจ่ายครั้งแรก 10,000 sats Alice สามารถลงนาม voucher ที่มียอดสะสม 10,000 sats ครั้งที่สองจ่ายอีก 20,000 sats เธอสามารถลงนามใหม่เป็น voucher ที่มียอดสะสม 30,000 sats

Bob เพียงเก็บใบล่าสุดไว้ใบเดียว

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

Voucher ไม่สามารถขจัดความเสี่ยงด้านเครดิต

Voucher มีลายเซ็นจริงและมีเส้นทางขึ้นเงินบนเชน แต่ก่อนที่มันจะถูกขึ้นเงิน มันยังคงมีความเสี่ยงด้านเครดิตของผู้ออก

สมมติว่าโหนดใบของ Alice มีเพียง 100,000 sats

เธอสามารถลงนาม voucher 80,000 sats ให้ Bob และลงนาม voucher อีก 80,000 sats ให้ Carol พร้อมกัน

ลายเซ็นบน voucher ทั้งสองใบเป็นของจริง แต่ยอดคงเหลือของ Alice ไม่สามารถครอบคลุมทั้งสองใบพร้อมกันได้

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

Alice ยังอาจอัปเดตโหนดใบของตนผ่านการดำเนินการที่ถูกต้องอื่น ๆ ทำให้ seq เพิ่มขึ้น voucher บนสถานะเก่าก็จะหมดอายุตามไป

ดังนั้น voucher ที่ยังไม่ชำระจึงคล้ายกับเช็คแบบดั้งเดิม:

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

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

เว็บไซต์ทางการของ LayerTree ยังระบุชัดเจนว่า ผู้รับเงินควรมอง voucher เป็น credit จนกว่าจะถูกขึ้นเงินหรือชำระด้วยวิธีอื่น

ความเสี่ยงด้านเครดิตนี้คือราคาที่ต้องจ่ายเพื่อประสิทธิภาพสูงของ voucher

ทำไมต้องออกแบบ voucher

เมื่อมีความเสี่ยงด้านเครดิต ทำไมไม่ใช้ช่อง Lightning ทั้งหมด?

เพราะโครงสร้างของ voucher ง่ายกว่าและยืดหยุ่นกว่า

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

LayerTree ออกแบบ credit leaf ชนิดหนึ่งไว้รับการชำระเงินจาก Lightning

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

กระบวนการพื้นฐานมีหน้าต่างความไว้วางใจสั้น ๆ: ผู้ให้บริการได้รับการชำระเงิน Lightning แล้ว แต่ยังไม่ได้ลงนาม voucher ให้ผู้รับเงิน บทความยังออกแบบ pending pair โดยใช้ hash lock, voucher ที่ลงนามล่วงหน้า และหน้าต่างชำระ เพื่อให้ผู้รับเงินได้รับหลักฐานที่บังคับใช้ได้ก่อน แล้วจึงปล่อย preimage ของการชำระ Lightning

ในโครงสร้างนี้ voucher กลายเป็นสะพานเชื่อมระหว่างการชำระ Lightning กับยอดคงเหลือ UTXO ที่ใช้ร่วมกัน

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

LayerTree พึ่งพาการอัปเกรดบิตคอยน์ใดบ้าง

ปัจจุบัน LayerTree ยังไม่สามารถทำงานบนเมนเน็ตบิตคอยน์ได้

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

โครงการออกแบบชุด opcode สี่แบบ

เวอร์ชัน FULL พึ่งพา BIP 441, BIP 440, OP_TX, BIP 348 และชุด opcode เส้นโค้งวงรี

BIP 441 กู้คืนความสามารถสคริปต์บางส่วนที่ถูกปิดใช้งานในช่วงแรก และสนับสนุนการจัดการข้อมูลและค่าตัวเลขที่ยืดหยุ่นกว่า BIP 440 จัดสรรงบประมาณการคำนวณให้การดำเนินการต้นทุนแปรผันเหล่านี้

เวอร์ชัน MID พึ่งพา OP_CAT ของ BIP 347, OP_TX, OP_CHECKSIGFROMSTACK ของ BIP 348 และ OP_TWEAKADD ของ BIP 449

OP_CAT ใช้ต่อข้อมูลในสคริปต์ OP_TX ให้สคริปต์อ่านและจำกัดธุรกรรมปัจจุบัน OP_TWEAKADD ใช้คำนวณกุญแจสาธารณะ Taproot ที่ให้คำมั่นกับสถานะใหม่

ในจำนวนนี้ BIP 348 สำคัญต่อ voucher เป็นพิเศษ มันอนุญาตให้สคริปต์บิตคอยน์ตรวจสอบลายเซ็นบนข้อมูลใดก็ได้ หากไม่มีความสามารถนี้ สคริปต์จะตรวจสอบเช็คดิจิทัลที่ Alice ลงนามนอกเชนได้ยาก

เวอร์ชัน MIN พึ่งพาเพียง OP_CAT และ OP_TWEAKADD แต่ทำได้เพียงการถอนและ SPLIT ไม่รองรับ voucher และ channel leaf มันเหมือนกับการทดลองพิสูจน์ขอบเขตความสามารถขั้นต่ำของ LayerTree

เวอร์ชัน CCV พึ่งพา OP_CHECKCONTRACTVERIFY ของ BIP 443, OP_TX และ BIP 348 ที่เตรียมไว้สำหรับ voucher

BIP 443 ทำให้ UTXO พกคำมั่นสถานะพลวัตได้ และจำกัดว่าเอาต์พุตใหม่ต้องสืบทอดสถานะที่อัปเดตแล้ว มันเข้ากันได้ดีกับเครื่องสถานะบนเชนแบบ LayerTree และเป็นหนึ่งในสี่ตัวเลือกที่มีขนาดการถอนเล็กที่สุด

อย่างไรก็ตาม BIP เหล่านี้ยังไม่ถูกเปิดใช้งานบนเมนเน็ตบิตคอยน์

“คนล้านคนใช้ UTXO ร่วมกัน” ยังมีเงื่อนไขเพิ่มเติมอีกข้อ

เวอร์ชันที่มีประสิทธิภาพสวยที่สุดในการโปรโมตของ LayerTree ยังพึ่งพา opcode เฉพาะชื่อ OP_MERKLESUMUPDATE

มันสามารถตรวจสอบหลักฐาน Merkle Sum และคำนวณรากต้นไม้ใหม่หลังจากแทนที่โหนดใบหนึ่งได้โดยตรง

ด้วยมัน LayerTree ที่มีสมาชิก 65,536 คน การถอนคนเดียวใช้ประมาณ 540 vB จำนวนสมาชิกเพิ่มขึ้นเท่าตัว ธุรกรรมการถอนเพิ่มเพียงประมาณ 10 vB

แต่ปัจจุบัน OP_MERKLESUMUPDATE เป็นเพียงการออกแบบและการจำลองในคลังของโครงการ ยังไม่เป็น BIP อย่างเป็นทางการ และยังไม่เข้าสู่กระบวนการอัปเกรดบิตคอยน์

หากใช้เฉพาะข้อเสนอ opcode ที่มีอยู่แล้ว ต้นทุนการถอนที่ขนาด 65,536 คนอยู่ที่ประมาณ 908 ถึง 1,473 vB

ดังนั้น “ต้นไม้หนึ่งต้นรองรับคนหลายล้าน” จึงเป็นจริงในเชิงโครงสร้างการเข้ารหัส แต่การนำไปใช้อย่างมีประสิทธิภาพยังพึ่งพาความสามารถสคริปต์บิตคอยน์ที่ก้าวหน้ากว่า BIP ปัจจุบัน

มันแก้ปัญหาการแห่ถอนขนาดใหญ่ได้หรือไม่

LayerTree สามารถบีบอัดการใช้พื้นที่บนเชนในสถานะปกติได้อย่างมาก แต่ไม่สามารถเพิ่มความจุของบล็อกบิตคอยน์เองได้

การอัปเดตสถานะทั้งหมดของต้นไม้เดียวกันต้องใช้จ่ายและสร้าง UTXO ที่ใช้ร่วมกันเดียวกันใหม่ ดังนั้นการถอนแยกกันต้องเข้าคิวดำเนินการ

ตามการคำนวณของโครงการเอง หากผู้ใช้ 65,536 คนถอนออกจากต้นไม้เดียวกันแยกกัน ต้องใช้ประมาณ 2,622 บล็อก ใกล้ 18 วัน

การนำไปใช้จริงต้องกระจายผู้ใช้ไปยังต้นไม้ขนาดเล็กจำนวนมาก พร้อมใช้การเข้าร่วมเป็นชุด การชำระเป็นชุด และการถอนเป็นชุด

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

ความหมายของ LayerTree

LayerTree ยังมีผู้ให้บริการที่ชัดเจนหนึ่งราย

ผู้ให้บริการรับผิดชอบรับผู้ใช้ ดูแลบริการ เส้นทางการชำระเงิน และจัดการอัปเดตเป็นชุด มันสามารถปฏิเสธผู้ใช้ใหม่ และหยุดให้บริการแบบเรียลไทม์ได้ ต้นไม้ LayerTree ต้นเดียวจึงไม่กระจายศูนย์อย่างสมบูรณ์

มันเหมาะกว่าที่จะเรียกว่าระบบ UTXO ที่ใช้ร่วมกันแบบไม่ต้องฝากทรัพย์

ผู้ให้บริการถือทางเข้าบริการ ผู้ใช้ถือสิทธิ์ถอนเงินทุน ผู้ให้บริการอาจปิดประตู หรือปฏิเสธบริการ แต่ตามการออกแบบโปรโตคอล มันไม่สามารถนำยอดคงเหลือในโหนดใบของผู้ใช้ไปตามอำเภอใจ

ส่วนที่น่าสนใจที่สุดของ LayerTree คือมันแสดงรูปแบบเงินทุนอีกรูปแบบหนึ่ง นอกเหนือจาก UTXO ธรรมดา ช่อง Lightning และฐานข้อมูลแบบฝากทรัพย์:

เช็คดิจิทัลที่หมุนเวียนได้ทันที สะสมต่อเนื่อง และสุดท้ายส่งให้สคริปต์บิตคอยน์บังคับขึ้นเงิน

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

มันจำกัดเครดิตไว้ที่ขั้นตอนการชำระเงินนอกเชน ขณะเดียวกันก็รักษาเส้นทางบังคับใช้บนเชนแบบไม่ต้องขออนุญาตให้ผู้รับเงิน

นี่เป็นแนวคิดการขยายบิตคอยน์ที่สร้างสรรค์พอสมควร