ARK: A Bitcoin Layer-2 Protocol
Ark คืออะไร ?
Ark คือโปรโตคอล Layer 2 ของบิตคอยน์ที่ออกแบบมาเพื่อให้การจ่ายเงินทำได้รวดเร็วและมีค่าธรรมเนียมต่ำ โดยการทำงานหลัก ๆ จะอยู่ “นอกบล็อกเชน” หรือ off-chain หมายความว่าการชำระเงินส่วนใหญ่จะไม่ถูกบันทึกลงในบล็อกเชนของบิตคอยน์โดยตรง แต่อย่างไรก็ตาม ผู้ใช้ยังคงสามารถถอนกลับไปยังเครือข่ายหลักได้หากต้องการ เพื่อรักษาความปลอดภัยและความมั่นใจว่าทรัพย์สินจะไม่สูญหาย
สิ่งที่ทำให้ Ark แตกต่างจาก Lightning Network ก็คือ Ark ไม่พึ่งพาใบแจ้งหนี้(invoice), ช่องทางการชำระเงิน(payment chanel), HTLC หรือกระบวนการ routing ที่ซับซ้อน แต่เลือกใช้โมเดลแบบ client-server ซึ่งให้ผู้ใช้ทุกคนจะติดต่อกับเซิร์ฟเวอร์กลางแทนที่จะเชื่อมต่อกันโดยตรงแบบ peer-to-peer การออกแบบนี้ช่วยลดความยุ่งยากของการใช้งาน แต่ก็ต้องแลกมากับการพึ่งพาเซิร์ฟเวอร์ที่มากกว่า (centralized กว่า)
Ark มีแนวคิดการทำงานแบบ optimistic กล่าวคือระบบจะสมมติว่าเซิร์ฟเวอร์จะทำงานได้ถูกต้องและประสานธุรกรรมให้สำเร็จ หากทุกอย่างเป็นไปตามปกติ การจ่ายเงินก็จะเร็วและราบรื่น แต่ถ้าเกิดปัญหา เช่น เซิร์ฟเวอร์ล่ม ไม่ตอบสนอง หรือจงใจกีดกันผู้ใช้งาน ผู้ใช้งานก็ยังสามารถถอนเงินออกจากระบบได้ด้วยตนเอง โดยการกลับไปทำธุรกรรมบนบล็อกเชนของบิตคอยน์ ซึ่งในสถานการณ์ปกติแล้ว ผู้ใช้มักถอนออกจากระบบโดยการร่วมมือกับเซิร์ฟเวอร์ ทำให้ไม่ค่อยจำเป็นต้องใช้วิธีถอนด้วยตนเอง
รูปแบบของการจ่ายเงินใน Ark คล้ายกับการทำธุรกรรมบนบล็อกเชนของบิตคอยน์ แต่แท้จริงแล้วคือธุรกรรมบิตคอยน์ที่ถูกเซ็นล่วงหน้าและจัดการกันอยู่นอกเครือข่าย ซึ่งข้อดีของมันคือผู้รับไม่จำเป็นต้องออนไลน์เพื่อที่จะรับเงิน อีกทั้งผู้ใช้ก็ไม่ต้องล็อกสภาพคล่องล่วงหน้าเหมือนกับ Lightning Network ซึ่งช่วยให้การใช้งานง่ายกว่าในหลายกรณี
Ark ยังเป็นโปรโตคอลที่ทำงานบนบิตคอยน์เท่านั้น มันไม่เกี่ยวข้องกับเหรียญอื่น, โทเคน Sidechain หรือการสร้างบล็อกเชนใหม่ และที่สำคัญคือ Ark ใช้งานได้แล้ววันนี้โดยไม่จำเป็นต้องเปลี่ยนแปลงกฎใด ๆ ของ บิตคอยน์ แม้ว่าในอนาคตหากบิตคอยน์ มีการเพิ่มฟีเจอร์อย่าง covenants เข้ามา ก็จะช่วยให้ Ark ทำงานได้ดียิ่งขึ้นไปอีก
เช่นเดียวกับโปรโตคอล Layer 2 อื่น ๆ Ark มีทั้งข้อดีและข้อจำกัด ทำให้มันเหมาะกับบางรูปแบบการใช้งานมากกว่าบางกรณี โดยจุดแข็งของมันคือความง่าย ความเร็ว และไม่ต้องมีการเตรียมสภาพคล่องล่วงหน้า ในขณะที่ข้อจำกัดคือการพึ่งพาเซิร์ฟเวอร์กลางเป็นหลัก ซึ่งแตกต่างจาก Lightning ที่ออกแบบมาให้กระจายศูนย์มากกว่า
|| บอกก่อนว่าผมไม่ได้เชี่ยวชาญ ark ขนาดนั้น ข้อมูลทั้งหมดมาจากการศึกษาของผมเอง ถ้ามันผิดตรงไหนใครรู้ช่วยกันแก้หน่อยนะครับ ||
Ark ทำงานยังไง
การเริ่มต้นใช้งานและการชำระเงินใน Ark
การเข้ามาใช้งาน Ark มีอยู่สองวิธี วิธีแรกคือการฝากเงินจากบล็อกเชนของบิตคอยน์ หรือ on-chain deposit ซึ่งก็คือการโอนบิตคอยน์ของคุณเข้าสู่ Ark ผ่านธุรกรรมบิตคอยน์ปกติบนบล็อกเชนหลัก วิธีนี้ใช้กลไกที่คุ้นเคยและไม่ซับซ้อน เพียงแต่คุณต้องจ่ายค่าธรรมเนียมเหมือนการทำธุรกรรมบิตคอยน์โดยทั่วไป
วิธีที่สองคือการรับการชำระเงินจากผู้ใช้ Ark คนอื่น หรือที่เรียกว่า Ark-to-Ark payment การทำธุรกรรมแบบนี้ถือว่าเป็นการเข้ามาใช้งาน Ark โดยอัตโนมัติทันทีที่คุณได้รับเงิน ไม่ต้องมีขั้นตอนการตั้งค่าล่วงหน้า และไม่ต้องเสียค่าธรรมเนียมบนบล็อกเชนของบิตคอยน์ เพราะทุกอย่างเกิดขึ้นนอกเครือข่าย
เมื่อคุณอยู่ใน Ark แล้ว การชำระเงินระหว่างผู้ใช้ Ark ด้วยกันทั้งหมดจะเกิดขึ้นแบบทันที มีค่าธรรมเนียมต่ำ และไม่แตะบล็อกเชนหลักเลย ทุกการโอนจะทำงานอยู่ภายในระบบ off-chain ของ Ark ซึ่งทำให้มันรวดเร็วและประหยัดมากกว่าการทำธุรกรรมแบบ on-chain
การเริ่มต้นใช้งาน Ark ด้วยการฝากแบบ on-chain ทำงานอย่างไร?
สมมติว่า Alice ต้องการเข้ามาใช้งาน Ark เธอเริ่มจากการใช้ UTXO ของตัวเอง (Alice input UTXO) เพื่อสร้างธุรกรรมที่เรียกว่า funding transaction ธุรกรรมนี้จะล็อกบิตคอยน์ของ Alice เอาไว้ โดยเงื่อนไขคือสามารถถูกใช้จ่ายได้สองแบบ
Alice กับ Ark Server ใช้จ่ายร่วมกันได้ตลอดเวลา
Ark Server ใช้จ่ายเพียงฝ่ายเดียวได้หลังจากผ่านไป 30 วัน
ก่อนที่ Alice จะเซ็นและส่งธุรกรรม funding นี้ขึ้นบล็อกเชน เธอและ Ark Server จะร่วมกันเซ็นธุรกรรมอีกชุดหนึ่งที่ off-chain เรียกว่า exit virtual transaction ซึ่งธุรกรรมนี้จะใช้จ่ายจาก output ของ funding transaction และมีเงื่อนไขตรงกันข้าม คือ
Alice กับ Ark Server สามารถใช้จ่ายร่วมกันได้ทันที
Alice เพียงคนเดียวสามารถใช้จ่ายได้ หลังจากรอการยืนยันบนบล็อกเชน 1 วัน
ด้วยโครงสร้างแบบนี้ Alice จึงมั่นใจได้ว่าในช่วงเวลา 30 วันหลังจากที่เธอฝากเงินเข้า Ark เธอจะยังมีสิทธิถอนกลับไป on-chain ได้เองเสมอ หาก Ark Server ไม่ให้ความร่วมมือหรือทำตัวผิดปกติ
นอกจากนี้ ธุรกรรมแบบ off-chain ที่เกี่ยวข้องยังมีการใส่ anchor output เพิ่มเข้ามาด้วย จุดประสงค์คือเพื่อให้สามารถปรับเพิ่มค่าธรรมเนียมในภายหลังได้ด้วยวิธี CPFP (Child Pays For Parent) ถึงแม้ในแผนภาพจะละส่วนนี้ออกเพื่อความง่าย แต่จริง ๆ แล้วมันมีบทบาทสำคัญในการทำให้ธุรกรรมสามารถยืนยันได้แม้ค่าธรรมเนียมในตอนแรกจะต่ำจนเกินไป
โอเคมาถึงตรงนี้อาจมีคำถามว่า ทำไม Ark Server ถึงสามารถอ้างสิทธิในเงินได้หลังผ่านไป 30 วันเต็ม ในขณะที่ Alice ต้องรออย่างน้อย 1 วันหากต้องการถอนแบบฝ่ายเดียว โดยคำตอบจะอยู่ในรายละเอียดการออกแบบ ซึ่งเกี่ยวข้องกับการสร้างแรงจูงใจ และการทำให้ระบบมีความสมดุลระหว่างผู้ใช้และเซิร์ฟเวอร์ ส่วนเหตุผลที่เลือกใช้ CPFP เป็นกลไกหลักในการจัดการค่าธรรมเนียมสำหรับธุรกรรมเสมือน (virtual transactions) ก็เพื่อให้มั่นใจได้ว่าธุรกรรมเหล่านี้จะถูกขุดแม้ในช่วงที่ค่าธรรมเนียมเครือข่ายมีการเปลี่ยนแปลงก็ตาม
ใน Ark ธุรกรรมและ UTXO ที่อยู่ off-chain จะถูกเรียกว่า VTXOs (Virtual UTXOs) และ Virtual Transactions เพื่อแยกออกจากธุรกรรมบนบล็อกเชนจริง ๆ
เพื่อบังคับใช้เงื่อนไขการใช้จ่ายเหล่านี้ Ark ใช้ Taproot scripts ที่ใช้ลายเซ็น Schnorr โดยการทำ multisig ระหว่าง Alice และ Ark Server ใช้โปรโตคอล MuSig2 MPC (Multi-Party Computation) ซึ่งจะรวมคีย์ของทั้งสองฝ่ายให้กลายเป็น public key เดียว และลงนามออกมาเป็นเพียงลายเซ็นเดียว ทำให้ธุรกรรมดูเรียบง่าย ปกป้องความเป็นส่วนตัว และมีประสิทธิภาพ
การเริ่มต้นใช้งาน Ark ด้วยการรับการชำระเงิน
สมมติว่า Alice ต้องการจ่ายเงินให้ Bob จำนวน 100,000 sats เธอจะใช้ VTXO ที่ตัวเองถืออยู่ (alice vtxo) มาสร้างธุรกรรม โดยเธอจะต้องปลดล็อกเงื่อนไขการใช้จ่ายที่กำหนดไว้ใน VTXO เดิม นั่นคือ Alice ต้องเซ็นธุรกรรมร่วมกับ Ark Server เมื่อธุรกรรมนี้ถูกสร้างขึ้น จะมีการส่งมอบ VTXO ใหม่ให้กับ Bob (bob vtxo) และในขณะเดียวกัน Alice ก็จะได้รับเงินทอนกลับมา 900,000 sats ในรูปแบบ VTXO ของตัวเอง (alice change vtxo)
เงื่อนไขการใช้จ่ายบน bob vtxo ถูกกำหนดเหมือนกับของ Alice ทุกประการ เพียงแต่แทนที่จะใช้กุญแจของ Alice ก็เปลี่ยนเป็นกุญแจของ Bob ส่วน alice change vtxo นั้นยังคงรักษาเงื่อนไขการถอนออกเหมือนกับ exit VTXO ดั้งเดิมของ Alice
จากจุดนี้ Bob สามารถใช้ VTXO ที่ได้รับเพื่อทำการจ่าย Ark ต่อไปยังคนอื่นได้เช่นเดียวกับ Alice แต่ bob vtxo จะมีความเสี่ยงบางอย่าง เนื่องจากธุรกรรมใน Ark เป็น off-chain มันจึงไม่มีระบบป้องกัน double-spend แบบที่บล็อกเชนของบิตคอยน์มีอยู่ ดังนั้น หาก Alice และ Ark Server สมรู้ร่วมคิดกัน พวกเขาสามารถนำ alice vtxo อันเดิมไปใช้ซ้ำในธุรกรรมอื่น ทำให้ bob vtxo กลายเป็นโมฆะได้โดยที่ Bob ไม่ได้มีส่วนเกี่ยวข้องเลย ตรงกันข้าม alice change vtxo ไม่มีความเสี่ยงแบบนี้ เพราะการโกงตัวเองย่อมไม่มีเหตุผลใด ๆ ให้ทำ
ถ้า Alice และ Ark Server ทำงานอย่างซื่อสัตย์ และไม่มีธุรกรรมที่ขัดแย้งถูกเผยแพร่ Bob ก็ยังคงปลอดภัย เขาสามารถถอนเงินของตัวเองกลับไปยังบล็อกเชนของบิตคอยน์ได้แบบฝ่ายเดียว โดยการเผยแพร่ payment virtual transaction ตามด้วย exit virtual transaction ลงบนบล็อกเชน แต่เขาจะต้องเป็นผู้รับผิดชอบค่าธรรมเนียมทั้งหมดเอง ผ่านกลไก CPFP (Child Pays for Parent)
เพื่อให้เห็นภาพง่ายขึ้น Ark จะแสดง VTXO ที่มีความเสี่ยง double-spend เป็นสีเหลือง ส่วน VTXO ที่ปลอดภัยจะถูกแสดงเป็นสีเขียว
จากตัวอย่างที่ Alice จ่ายเงินให้ Bob เราจะเห็นได้ว่าผู้ใช้ Ark สามารถโอนเงินหากันได้ตามปกติ แต่ปัญหาคือ VTXO ที่เกิดจาก VTXO ที่มีความเสี่ยง double-spend จะ “สืบทอดความเสี่ยง” นั้นต่อไปด้วย กล่าวคือ หาก VTXO ดั้งเดิมสามารถถูกใช้ซ้ำได้เพราะมีการสมรู้ร่วมคิดระหว่างเจ้าของกับ Ark Server VTXO ที่แตกแขนงออกมาก็มีความเสี่ยงเช่นกัน และยิ่งห่วงโซ่ VTXO ยาวขึ้น ความเสี่ยงก็ยิ่งมากขึ้น เพราะใครก็ตามที่อยู่ในสายต้นกำเนิดของ VTXO ร่วมกับ Ark Server สามารถสร้างธุรกรรมซ้ำที่ทำให้ VTXO ปัจจุบันกลายเป็นโมฆะได้ทั้งสิ้น
ในทางกลับกัน VTXO ที่เกิดจากการรับเงินทอน (change VTXO) หรือการโอนหาตัวเองโดยตรงจาก exit VTXO ดั้งเดิม เช่นกรณีของ Alice จะถูกมองว่าปลอดภัยจากความเสี่ยง double-spend เนื่องจากผู้ใช้ควบคุมทั้ง input และ output เอง ไม่มีแรงจูงใจใดที่จะสร้างธุรกรรมที่ขัดแย้งหรือไปสมรู้ร่วมคิดกับ Ark Server เพื่อตัดสิทธิ์ของตัวเอง
อีกประเด็นที่สำคัญคือ VTXO ที่เกิดจากสายโอนยาว ๆ หรือ long chain payment จะมีต้นทุนสูงหากผู้ใช้ต้องการถอนออกฝ่ายเดียวบนบล็อกเชน เพราะการถอนนั้นต้องเริ่มจาก exit virtual transaction ดั้งเดิม และผู้ใช้ต้องจ่ายค่าธรรมเนียมสำหรับธุรกรรมเสมือนทุกตัวในสายโอนนั้น ทำให้ต้นทุนสูงขึ้นตามความยาวของ chain
อย่างไรก็ตาม Ark ยังคงมีจุดแข็งตรงที่การจ่ายเงินทุกครั้งเกิดขึ้นแบบ off-chain ธุรกรรมเหล่านี้ถูกเซ็นโดยผู้ส่งและ Ark Server เท่านั้น จึงทำให้การชำระเงินเป็นไปอย่างรวดเร็ว ไม่ต้องเสียค่าธรรมเนียมบนเครือข่าย และไม่ก่อให้เกิดต้นทุนการทำธุรกรรมบนบล็อกเชนเลย
Ark ขยายระบบการรับผู้ใช้ใหม่และการชำระเงินได้อย่างไร
ผู้ใช้ทุกคนสามารถเข้ามาใช้งาน Ark ได้ด้วยการนำบิตคอยน์ที่มีอยู่บนเครือข่ายมาใช้ onboarding แบบเดียวกับที่ Alice ทำ ในตัวอย่างที่อธิบายไว้ก่อนหน้า ใคร ๆ ก็ onboard ผ่านธุรกรรม onchain ในลักษณะเดียวกันได้
อย่างไรก็ตาม การ onboard ด้วยวิธี onchain นั้นมีข้อจำกัดเรื่อง พื้นที่ในบล็อกของบิตคอยน์เพราะทุกธุรกรรมต้องไปแข่งขันกันถูกบันทึกลงในบล็อก ซึ่งมีจำนวนธุรกรรมที่บรรจุได้จำกัด
ในทางกลับกัน การชำระเงินด้วย Ark จะเกิดขึ้นนอกเชนทั้งหมด ไม่ต้องไปแย่งพื้นที่ในบล็อก ทำให้ไม่ถูกจำกัดโดย blockspace ความสามารถในการรองรับผู้ใช้และการทำธุรกรรมจึงขึ้นอยู่กับประสิทธิภาพและความสามารถของ Ark Server ในการประมวลผลและประสานงานธุรกรรมเหล่านี้แทน
Cooperative Exit
ในการทำ Cooperative Exit ผู้ใช้จะแจ้งกับ Ark Server ว่าต้องการแลก VTXO ของตนกลับมาเป็น UTXO บนเครือข่าย ผู้ใช้จะโอนยอดคงเหลือ VTXO ของตนไปยัง address ที่ควบคุมโดย Ark Server ในขณะเดียวกัน Ark Server ก็จะโอนจำนวนบิตคอยน์ที่เท่ากันจาก onchain ของตนไปยัง address ที่ผู้ใช้ควบคุม การแลกเปลี่ยนนี้ถูกทำให้เป็นแบบ atomic เพื่อให้แน่ใจว่ามีความยุติธรรม
ในกรณีข้างต้น ทั้ง Bob และ หลาม ต้องการออกจาก Ark ไปยัง onchain แบบ cooperative ซึ่ง Ark Server จะสร้างธุรกรรมบนเครือข่ายเพียงหนึ่งรายการ เรียกว่า batch transaction ซึ่งโอนบิตคอยน์ onchain ของ Ark Server ไปยังผู้ใช้ทั้งสอง ในขณะเดียวกัน จะมีการเตรียม forfeit transactions สองรายการเพื่อย้ายยอดคงเหลือ VTXO ของผู้ใช้ไปยัง address ที่ควบคุมโดย Ark Server
ในขั้นตอนนี้ ธุรกรรมทั้งสามรายการยังไม่ถูกเซ็น เนื่องจากทั้ง Ark Server และผู้ใช้ไม่ต้องการโอนยอดคงเหลือของตนออกไปก่อน เพราะนั่นจะทำให้เสี่ยงต่อการที่อีกฝ่ายปฏิเสธที่จะเซ็นการโอนเข้าที่จะได้รับ เพื่อทำให้การออกเป็นธรรมและปลอดภัย จึงจำเป็นต้องมีกลไกที่จะทำให้การเซ็นธุรกรรมเหล่านี้เกิดขึ้นแบบอะตอมมิก และทำให้แน่ใจว่ามีการแลกเปลี่ยน VTXO และ UTXO อย่างยุติธรรม
แนวคิดคือ หากเราสามารถทำให้ธุรกรรม forfeit ถูกใช้ได้ก็ต่อเมื่อธุรกรรม batch สามารถถูกใช้ได้เช่นกัน การแลกเปลี่ยนก็จะกลายเป็นแบบอะตอมมิกทันที
ตามที่แสดงไว้ในรูป เมื่อ connector output จาก batch transaction ถูกนำมาใช้เป็น input ใน forfeit transaction ผลลัพธ์ของ forfeit จึงจะสามารถใช้ได้บนเครือข่ายหลักก็ต่อเมื่อ batch transaction ถูกเซ็นและยืนยันแล้วเท่านั้น มูลค่าของ connector output ไม่มีความสำคัญ ตราบใดที่มันมีค่ามากกว่า dust limit ก็เพียงพอที่จะทำให้แน่ใจได้ว่า forfeit transaction จะถูกยืนยันได้ก็ต่อหลังจากที่ batch transaction ได้รับการยืนยันแล้ว
ลำดับการเซ็นมีความสำคัญ ผู้ใช้จะต้องเซ็น forfeit transaction ของตนเองก่อน ขั้นตอนนี้ปลอดภัยสำหรับผู้ใช้อย่างสมบูรณ์ เนื่องจากธุรกรรม forfeit จะไม่สามารถใช้งานได้ เว้นแต่ Ark Server จะเซ็น batch transaction ด้วย
หลังจากที่ Ark Server ได้รับ forfeit transaction ที่ผู้ใช้เซ็นแล้ว Ark Server จะดำเนินการขั้นตอนสุดท้ายด้วยการเซ็นและเผยแพร่ batch transaction เพื่อนำไปยืนยันบนเครือข่าย
ทำไมต้องมี “Bob after relative 1 day” เพิ่มเข้าไปใน VTXO?
หาก Bob พยายามโกง Ark Server ด้วยการพยายามดึง VTXO ที่เขาได้สละสิทธิ์ไปแล้วกลับคืน หลังจากที่เขาได้รับ Bitcoin บนเครือข่ายหลักผ่าน batch transaction เขาอาจจะเผยแพร่ธุรกรรมของ VTXO นั้นเพื่อเอาเงินกลับมาอีกครั้ง
สิ่งนี้ถูกป้องกันด้วย relative timelock หนึ่งวัน บน VTXO ที่ถูกสละสิทธิ์ ความล่าช้านี้ทำให้ Ark Server มีเวลาเพียงพอในการเผยแพร่และยืนยัน forfeit transaction ที่ Bob เคยร่วมเซ็นไว้แล้วภายใต้เงื่อนไขการใช้จ่าย Bob+Ark Server ซึ่งทำให้เซิร์ฟเวอร์สามารถอ้างสิทธิ์ใน VTXO บนเครือข่ายหลักได้ก่อนที่ Bob จะทำได้ ระยะเวลาของ timelock นี้สามารถกำหนดค่าได้โดยเซิร์ฟเวอร์
Connector outputs สามารถมีจำนวนมากขึ้นใน batch ได้ มีวิธีเพิ่มประสิทธิภาพหรือไม่?
จำนวนของ connector outputs ที่เชื่อมจาก batch transaction ไปยัง forfeit transactions จะเพิ่มขึ้นเป็นเส้นตรงตามจำนวน cooperative exit VTXOs และเนื่องจาก batch transaction อยู่บนเครือข่ายหลัก ขนาดและต้นทุนรวมของธุรกรรมจึงเพิ่มขึ้นตามไปด้วย
ดังที่แสดงในรูปข้างต้น การแทรกธุรกรรมตัวกลางที่เรียกว่า connector transaction จะช่วยให้ batch transaction มีเพียง connector output UTXO หนึ่งรายการ ซึ่งสามารถใช้เป็น input ให้กับ forfeit transactions ทั้งหมดได้ วิธีนี้ตัดความจำเป็นที่จะต้องมี connector output แยกสำหรับแต่ละ forfeit และแทนที่การเติบโตแบบเส้นตรงของจำนวน output ด้วย output เพียงหนึ่งเดียว จึงลดขนาดและต้นทุนของ batch transaction ได้อย่างมาก
ในอุดมคติแล้ว virtual transactions ของ VTXOs รวมถึง forfeit และ connector transactions จะไม่ถูกเผยแพร่ขึ้นบนเครือข่ายหลักเลย พวกมันมีไว้เป็นเพียงกลไกสำรอง เฉพาะในกรณีที่ผู้ใช้พยายามเผยแพร่ VTXO ที่สละสิทธิ์ไปแล้วพร้อมกับ ancestry ของ virtual transactions ทั้งหมดตั้งแต่ exit virtual transaction เป็นต้นมา
แล้วอะไรที่จะป้องกันไม่ให้ผู้ใช้โจมตีแบบ denial-of-service (DoS) โดยการเผยแพร่ VTXO ที่สละสิทธิ์? คำตอบคือ virtual transactions ทั้งหมดพึ่งพากลไก CPFP (Child Pays for Parent) ในการจ่ายค่าธรรมเนียม ดังนั้นผู้ใช้จะต้องเป็นฝ่ายจ่ายค่าธรรมเนียมสำหรับทั้ง chain ของธุรกรรม หากแม้ผู้ใช้จะทำสำเร็จ Ark Server ก็ยังสามารถกวาด VTXO ที่สละสิทธิ์นั้นไปได้ด้วย forfeit transaction ที่ถูกเซ็นไว้ล่วงหน้าอยู่แล้ว สิ่งนี้ทำให้การโจมตีดังกล่าวทั้งมีต้นทุนสูงและไร้ประโยชน์ จึงทำให้ผู้ใช้หมดแรงจูงใจที่จะลองทำ
ทำไมต้องมีเงื่อนไข “Ark Server after absolute 30 days” เพิ่มเข้าไปใน output UTXO?
เพราะว่า ผู้ใช้บางส่วนของ Ark Server สามารถร้องขอให้ออกจากระบบแบบ cooperative exit ได้ตลอดเวลา VTXOs ที่สร้างขึ้นจาก output UTXO ของ funding transaction ล้วนมีต้นกำเนิดมาจาก UTXO เดียวกันนี้โดยตรงหรือทางอ้อม ทำให้เกิดโครงสร้างสายสัมพันธ์หลายชั้น หมายความว่าผู้ใช้หลายคนต่างก็ “ใช้ร่วมกัน” กับ onchain UTXO ที่ได้จาก funding transaction เดียวกัน
อย่างไรก็ตาม Ark Server ไม่สามารถบังคับให้ผู้ใช้ทั้งหมดที่มีสายสัมพันธ์ร่วมกับผู้ใช้ที่ร้องขอ cooperative exit ต้องเข้าร่วมออกพร้อมกันด้วย เพราะจะทำให้ประสบการณ์ใช้งานแย่ลงและไม่สามารถทำได้จริง เนื่องจากบางคนอาจออฟไลน์หรือไม่สะดวกในขณะนั้น
เพื่อแก้ปัญหานี้ Ark Server จึงใช้วิธีนำบิตคอยน์ onchain ของตัวเองออกมาใช้ชั่วคราวเพื่ออำนวยความสะดวกให้ผู้ใช้ที่ต้องการออกแบบ cooperative exit ผ่าน batch transaction
แต่คำถามคือ Ark Server จะเอาเงินของตนเองที่ปล่อยออกไปกลับมาได้อย่างไร? วิธีหนึ่งคือการเผยแพร่ธุรกรรม forfeit พร้อมกับ ancestor VTXOs ทั้งหมด แต่สิ่งนี้จะบังคับให้ VTXOs อื่น ๆ ที่ไม่เกี่ยวข้องในสาย ancestry เดียวกันต้องออกสู่ onchain ด้วย ทำให้เกิดต้นทุนและความล่าช้าที่ไม่จำเป็น ซึ่งขัดกับเป้าหมายการออกแบบ Ark ที่เน้น offchain
ในขณะเดียวกัน Ark Server ก็ไม่สามารถยอมปล่อยให้สภาพคล่องของตนถูกล็อกไว้นานไม่มีกำหนด รอให้ผู้ใช้ทั้งหมดที่ผูกกับ output UTXO เดียวกันทยอยออกเอง เพราะนั่นจะทำให้ Ark Server แบกรับภาระที่ไม่ยั่งยืน และทำให้ระบบใช้งานไม่ได้จริงเมื่อขยายสเกล
ทางออกที่เหมาะสมกว่าคือการกำหนดเส้นตายที่ชัดเจน ซึ่งบังคับว่าผู้ใช้ทุกคนที่ผูกกับ funding UTXO ต้องทำ cooperative exit ให้เสร็จภายในเวลาที่กำหนด แล้วจะทำอย่างไรให้ enforce กฎนี้ได้?
คำตอบคือเพิ่มเงื่อนไข “Ark Server after absolute 30 days” ลงใน output UTXO เงื่อนไขนี้ทำให้ AS สามารถใช้ UTXO ได้เองฝ่ายเดียวหลังจากครบ 30 วัน ภายในระยะเวลานี้ผู้ใช้มีสิทธิ์ออกแบบ cooperative exit ได้ตลอดเวลา แต่หากผู้ใช้ไม่ดำเนินการภายในกำหนด VTXO ของพวกเขาก็จะถูก AS กวาดรวมไปกับของคนอื่น ไม่ว่าจะได้สละสิทธิ์ไว้ชัดเจนหรือไม่ก็ตาม
กลไกนี้ทำให้ Ark Server สามารถเรียกคืนสภาพคล่องของตนเองได้ภายในระยะเวลาที่คาดการณ์ได้ ทำให้ระบบดำเนินงานต่อไปอย่างมีประสิทธิภาพ โดยระยะเวลา deadline สามารถปรับค่าได้ตามการตั้งค่าของเซิร์ฟเวอร์
ข้อเสียคือ ผู้ใช้ที่ไม่ทันดำเนินการภายในกำหนดเวลาจะสูญเสียยอด VTXO ของตนให้กับ Ark Server
ปัญหาสามประการ
เราได้ระบุปัญหาสำคัญสามประการที่อาจทำให้ Ark ใช้งานจริงได้ยากหรือน่าสนใจน้อยลง:
ความเสี่ยงในการถูก double-spend ของ VTXOs ที่สร้างขึ้นจากการชำระเงินใน Ark
ความเสี่ยงที่ผู้ใช้อาจสูญเสียยอดคงเหลือ VTXO ให้กับ Ark Server หากไม่ออกภายในเส้นตาย 30 วัน
ความยากลำบากและต้นทุนที่สูงของการทำ unilateral exit โดยเฉพาะสำหรับผู้ใช้ที่ถือ VTXOs ซึ่งอยู่ลึกลงไปในสายของ virtual transaction ที่ยาว
สามารถทำอะไรได้บ้างเพื่อแก้ไขปัญหาสามประการใน Ark?
โชคดีที่ปัญหาเหล่านี้ทั้งหมดสามารถแก้ได้ด้วยวิธีเดียว คือ การสลับ VTXO ที่ได้รับผลกระทบกับ VTXO ใหม่จาก exit virtual transaction ที่ผู้ใช้แต่ละคนควบคุมเอง
เราสามารถแก้ปัญหาเหล่านี้ได้โดยใช้ batch transactions คล้ายกับกระบวนการ cooperative exit แทนที่ผู้ใช้จะได้รับ UTXO onchain โดยตรง ผู้ใช้แต่ละคนจะได้รับ VTXO ใหม่จาก exit virtual transaction ที่เพิ่งสร้างขึ้นแทน VTXO ใหม่นี้มีความปลอดภัยกว่า เพราะ
หลีกเลี่ยงความเสี่ยง double-spend
ไม่ติดอยู่ในสายธุรกรรมเสมือนที่ยาว
ช่วยขยายระยะเวลาหมดอายุออกไปอีก 30 วัน
ในตัวอย่างด้านบน munich กำลังทำการ atomic swap ระหว่าง VTXO เก่าที่มีความเสี่ยงต่อการถูก double-spend กับ VTXO ใหม่ที่ปลอดความเสี่ยง แทนที่จะทำ cooperative exit เพื่อรับ UTXO บนเชน Munich เลือกใช้ batch transaction เพื่อรับ VTXO ใหม่จาก exit virtual transaction อย่างปลอดภัย
เมื่อได้ VTXO ใหม่นี้ Munich ก็สามารถทำการจ่ายเงินผ่าน Ark ให้กับผู้ใช้อื่นได้ เช่นเดียวกับที่ Alice ทำการจ่ายจาก Exit virtual transaction VTXO ของเธอ
ถ้าสังเกตให้ดี เงื่อนไขการใช้จ่ายของ output UTXO บนเชนใน batch transaction จะเหมือนกันกับใน funding transaction ทุกประการ และเช่นเดียวกันกับ exit virtual transaction ความแตกต่างที่สำคัญคือ แหล่งที่มาของเงินทุน:
funding transaction ได้รับทุนจาก UTXO ของผู้ใช้เอง
batch transaction ได้รับทุนจาก UTXO ของ AS เอง
เหตุผลก็เหมือนกับตอนที่ Ark Server เป็นผู้จัดหา liquidity ชั่วคราวเพื่อช่วยให้ผู้ใช้สามารถทำ cooperative exit ได้ นั่นคือ Ark Server จะนำสภาพคล่องของตนมาใช้ชั่วคราวเพื่อให้ผู้ใช้สลับ VTXO เก่าเป็น VTXO ใหม่ เมื่อครบกำหนดอายุ 30 วันของ output UTXO แล้ว Ark Server สามารถกวาด (sweep) เงินกลับไปได้ เช่นเดียวกับในสถานการณ์ cooperative exit
เมื่อ VTXO ใหม่ใกล้หมดอายุ ผู้ใช้จะต้องทำการ swap อีกครั้งเพื่อรับ VTXO ใหม่ผ่านกระบวนการเดียวกัน เพื่อป้องกันไม่ให้ Ark Server กวาด VTXO ที่กำลังหมดอายุ หาก Ark Server ทำการกวาดไป ผู้ใช้ก็จะสูญเสียเหรียญให้กับเซิร์ฟเวอร์โดยตรง โปรโตคอลไม่ได้การันตีว่า มูลค่าของ VTXO ที่ถูกกวาดไปจะถูกคืนให้กับผู้ใช้ อย่างไรก็ตาม ในการใช้งานจริง Ark Server อาจออก VTXO ใหม่ที่มีมูลค่าเท่าเดิมให้ผู้ใช้เป็นการช่วยเหลือ เมื่อผู้ใช้กลับมาออนไลน์อีกครั้ง
ตามปกติแล้วการทำ swap แบบนี้เป็นระยะ ๆ จะมีค่าใช้จ่าย เนื่องจากเกี่ยวข้องกับ onchain batch transaction แต่ค่าใช้จ่ายโดยทั่วไปจะต่ำ เพราะถูกแชร์เฉลี่ยระหว่างผู้ใช้ที่เข้าร่วมทั้งหมด
หัวใจของการออกแบบให้ Ark ขยายตัวได้
ข้อได้เปรียบหลักของการออกแบบนี้คือ ความสามารถในการรองรับการใช้งานในวงกว้าง (scalability) ในตัวอย่างด้านบน ทั้ง Munich และ Kritta กำลังสลับ VTXO เดิมที่มีความเสี่ยงต่อการถูก double-spend ให้กลายเป็น VTXO ใหม่ที่ปลอดภัยจาก exit virtual transaction กระบวนการนี้สามารถรองรับผู้ใช้งานได้หลายพันคนภายใน batch เดียว โดยเพียงแค่เพิ่มกุญแจของผู้ใช้ลงไปใน multisig บนเชน และเพิ่มจำนวน VTXO ใน exit virtual transaction ได้ตามต้องการ
อย่างไรก็ตาม จุดที่เป็นคอขวดหลัก อยู่ที่ขั้นตอน การเซ็นแบบโต้ตอบ (interactive signing) ระหว่าง AS และผู้ใช้ทั้งหมดที่เข้าร่วมใน batch นั้น
เพิ่มเติมเกี่ยวกับ Batch Transaction และ Exit Virtual Transaction
Ark Server (AS) สร้าง batch transaction บ่อยแค่ไหน?
โดยทั่วไปแล้ว Ark Server จะสร้าง batch transaction ขึ้นมาในช่วงเวลาที่กำหนดไว้ล่วงหน้า เช่น ทุก ๆ หนึ่งชั่วโมง ผู้ใช้ที่ต้องการทำ cooperative exit หรือสลับ VTXO เดิมให้กลายเป็น VTXO ใหม่ที่ปลอดภัยและปราศจากความเสี่ยง สามารถส่งสัญญาณความต้องการไปยัง Ark Server ได้ จากนั้น Ark Server จะทำหน้าที่ประสานงานกับกระเป๋าเงินของผู้ใช้
ช่วงเวลาในการสร้าง batch transaction นี้สามารถปรับเปลี่ยนได้ตามการตั้งค่าของ Ark Server เอง และในช่วงที่มีความต้องการใช้งานสูง Ark Server อาจสร้าง batch transaction เพิ่มขึ้นนอกเหนือจากรอบปกติได้ตามความเหมาะสม
ข้อจำกัดของ Exit virtual transaction
ในรูปแบบพื้นฐานของ exit virtual transaction หากผู้ใช้คนหนึ่งเลือกที่จะ exit แบบฝ่ายเดียว (unilateral exit) จะทำให้ผู้ใช้อื่น ๆ ทั้งหมดใน batch เดียวกันต้อง exit ลงไปบนเชนด้วย ส่งผลให้ความต่อเนื่องของการทำงานแบบ offchain ถูกทำลาย เกิดค่าธรรมเนียมและความล่าช้าที่ไม่คาดคิด อีกทั้งทุกคนต้องกลับมาเริ่มกระบวนการ onboarding ใหม่อีกครั้ง
นอกจากนี้ ค่าธรรมเนียมในการ exit จะ เพิ่มขึ้นตามจำนวน VTXO ใน exit virtual transaction แบบเชิงเส้น ยกตัวอย่างเช่น หากมี 1,000 VTXO อยู่ใน batch ผู้ใช้ที่ต้องการ exit จะต้องจ่ายค่าธรรมเนียมบนเชนสำหรับเอาต์พุตทั้งหมด 1,000 รายการ ทำให้การ exit แบบฝ่ายเดียวมีต้นทุนสูงอย่างมาก
แล้วเราจะแก้ปัญหานี้ยังไง
เราสามารถใช้โครงสร้าง exit virtual transaction แบบต้นไม้ทวินาม (binary tree) แทนที่จะเป็น exit virtual transaction เดียวได้ ในการตั้งค่านี้ หาก Munich ตั้งใจจะทำการ exit แบบฝ่ายเดียวก่อนที่ผู้เข้าร่วมคนอื่นใน batch ที่ VTXO ของเธอถือกำเนิดขึ้นมา เขาจะต้องเผยแพร่ลำดับเฉพาะของ virtual transaction: เริ่มจาก root virtual transaction ที่เป็นตัว anchor ของทั้ง batch จากนั้นคือ branch virtual transaction ฝั่งซ้ายที่นำไปยังตำแหน่ง VTXO ของเขาใน tree และสุดท้ายคือ exit virtual transaction ของเขาเอง
หลังจากนั้น หาก A ซึ่ง VTXO ของเขาอยู่ใน branch เดียวกับของ Munich เลือกที่จะเริ่มทำ exit แบบฝ่ายเดียวของเขาเอง เขาสามารถทำได้ด้วยการเผยแพร่เพียง exit virtual transaction ของเขาเท่านั้น เนื่องจาก ancestor transaction ที่จำเป็นในเส้นทาง เช่น root และ branch virtual transaction ได้รับการยืนยันบนเชนแล้วในระหว่างการ exit ของ Munich
Tree-based exit virtual transaction มีข้อดีหลายประการเมื่อเทียบกับ exit virtual transaction แบบพื้นฐาน ในโครงสร้างพื้นฐาน การ exit แบบฝ่ายเดียวของผู้ใช้เพียงคนเดียวบังคับให้ผู้ใช้ทั้งหมดใน batch ต้อง exit บนเชนด้วยกัน ในทางตรงกันข้าม โครงสร้างแบบ tree ป้องกัน: ผู้ใช้ที่ไม่ใช่ผู้เริ่มต้นจะไม่ได้รับผลกระทบเมื่อมีใครบางคน exit ทำให้ไม่เกิด forced onchain exit และยังคงรักษาประสบการณ์แบบ offchain ไว้ได้
ภาระค่าธรรมเนียมของ unilateral exit ก็ลดลงอย่างมากเช่นกัน แทนที่จะเพิ่มขึ้นเชิงเส้นตามจำนวน VTXO ค่าธรรมเนียมจะเพิ่มขึ้นแบบลอการิทึมตามความลึกของ tree ทำให้การ exit แบบฝ่ายเดียวเข้าถึงได้ง่ายขึ้น ผู้ใช้ที่ไม่ใช่ผู้เริ่มต้นก็ได้รับประโยชน์เพิ่มเติม เนื่องจากพวกเขาจำเป็นต้องเผยแพร่เพียง sub-branch หรือ leaf transaction ของตนเองเท่านั้น ทำให้ค่าธรรมเนียมบนเชนของแต่ละคนลดลง
โครงสร้าง tree นี้ยังช่วยเพิ่ม scalability ทำให้รองรับ VTXO ต่อ batch ได้มากกว่าธุรกรรม batch แบบธรรมดา อย่างไรก็ตาม มันก็มาพร้อมกับความซับซ้อนที่เพิ่มขึ้น: การเซ็นแบบโต้ตอบจะเพิ่มขึ้นตามความลึกของ tree และต้องการการประสานงานมากขึ้นระหว่างผู้เข้าร่วม
เมื่อผู้ใช้เลือกที่จะทำการ exit แบบฝ่ายเดียว พวกเขาจะต้องยืนยันแต่ละลิงก์ใน tree ตั้งแต่ root จนถึง leaf ทำให้กระบวนการซับซ้อนมากขึ้น ถึงกระนั้น root และ branch transaction ก็ยังคงปฏิบัติตามกฎของสคริปต์และเงื่อนไขการหมดอายุเช่นเดียวกับ batch transaction บนเชน ความแตกต่างสำคัญคือธุรกรรมเหล่านี้ถูกเซ็นไว้ล่วงหน้าแบบ offchain และจะถูกเผยแพร่ก็ต่อเมื่อจำเป็นต้องใช้
สุดท้าย หากมีผู้ใช้ทำ exit แบบฝ่ายเดียว และภายหลัง Ark Server จำเป็นต้องกวาด VTXO ที่เหลือหลังหมดอายุ มันจะต้องเผยแพร่และยืนยัน branch transaction ที่เกี่ยวข้องเพื่อทำการกวาดให้เสร็จสิ้น
Last updated