เนื่องจากเป็นหนึ่งในหลักการออกแบบหลักของ Bitcoin โมเดล UTXO จึงเป็นกระบวนทัศน์ทางเทคนิคที่สำคัญในโดเมนบล็อกเชนนับตั้งแต่เริ่มก่อตั้ง มีบทบาทสำคัญในการรับรองความปลอดภัยของธุรกรรมและการตรวจสอบย้อนกลับ โดยให้ทางเลือกอื่นนอกเหนือจากรูปแบบยอดเงินคงเหลือในบัญชีแบบเดิม ด้วยการพัฒนาและการขยายตัวอย่างต่อเนื่องของเทคโนโลยีบล็อกเชนในช่วงไม่กี่ปีที่ผ่านมา โมเดล UTXO เองก็มีการพัฒนาและขยายอย่างต่อเนื่อง เช่น eUTXO เซลล์ รายการเข้าถึงที่เข้มงวด และอื่นๆ
บทความนี้จะแนะนำโมเดล UTXO ในภาษาธรรมดา โดยให้ภาพรวมโดยย่อของโมเดล UTXO และวิธีการใช้งาน BTC, Sui, Cardano, Nervos และ Fuel
เพื่อแสดงให้เห็นโมเดล UTXO เราใช้ตัวอย่าง:
ลองนึกภาพคนสองคน อลิซและบ็อบ ซึ่งเริ่มแรกแต่ละคนมีเงิน 5 ดอลลาร์ ต่อจากนั้น เกิดความขัดแย้งขึ้น และอลิซถูกบ็อบปล้นไป 2 ดอลลาร์ การถือครองขั้นสุดท้ายสำหรับแต่ละรายการมีดังนี้:
เห็นได้ชัดว่าอลิซมีเงิน 3 ดอลลาร์ และในที่สุด Bob ก็ถือเงิน 7 ดอลลาร์ วิธีการบัญชีที่มีลักษณะคล้ายเลขคณิตเบื้องต้นนี้พบได้ทั่วไปในระบบธนาคาร และเรียกว่า "แบบจำลองบัญชี/ยอดคงเหลือ" ในแบบจำลองนี้ ยอดคงเหลือของบัญชีจะมีค่าเป็นตัวเลขเพียงค่าเดียว
หากเราต้องใช้แนวทางที่แตกต่างจากโมเดลบัญชี เช่น การใช้ UTXO เพื่อแสดงการโอนความมั่งคั่งระหว่าง Alice และ Bob แผนภาพตัวอย่างจะมีรูปลักษณ์ที่แตกต่างออกไป:
ณ จุดนี้ อลิซยังคงมีเงิน $3 และ Bob ยังคงมีเงิน $7 แต่ $7 เหล่านี้ไม่ได้แสดงด้วยค่าตัวเลขเพียงค่าเดียว แต่จะแบ่งออกเป็น “$5” และ “$2” แทน วิธีการแหวกแนวนี้รู้สึกไม่คุ้นเคยบ้างหรือไม่? นี่เป็นวิธีการบัญชีเฉพาะที่เรียกว่า UTXO
ตัวย่อภาษาอังกฤษ UTXO ย่อมาจาก Unspent Transaction Output ภายใต้แนวทางการบัญชีนี้ แต่ละธุรกรรมออนไลน์จะแสดงเป็นการเปลี่ยนแปลงและการโอนใน UTXO ตัวอย่างเช่น ในเหตุการณ์ธุรกรรมดังกล่าว “$5” ที่ Alice เป็นเจ้าของในตอนแรกทำหน้าที่เป็นพารามิเตอร์อินพุตซึ่งมีป้ายกำกับว่า UTXO_0 ซึ่งจะถูกทำเครื่องหมายว่าใช้จ่ายแล้ว พร้อมกัน ระบบจะสร้าง “$2” (UTXO_1) และ “$3” (UTXO_2) เป็นพารามิเตอร์เอาต์พุต UTXO_1 จะถูกโอนไปที่ Bob และ UTXO_2 จะถูกส่งคืนให้กับ Alice ซึ่งจะทำให้การโอนความมั่งคั่งระหว่าง Alice และ Bob เสร็จสมบูรณ์
ในโมเดล UTXO ไม่มีแนวคิดที่ชัดเจนเกี่ยวกับ "บัญชี" และ "ยอดคงเหลือ" UTXO ทำหน้าที่เป็นโครงสร้างข้อมูลที่ช่วยในการดำเนินธุรกรรม โดยบันทึกข้อมูล เช่น จำนวนเงินที่แสดงและดัชนีธุรกรรมที่เกี่ยวข้อง แต่ละ UTXO แสดงถึงอินพุตธุรกรรมที่ยังไม่ได้ใช้ โดยมีเจ้าของที่ได้รับมอบหมาย เมื่อธุรกรรมเกิดขึ้น UTXO บางตัวสามารถใช้เป็นอินพุตได้ และเมื่อถูกทำลาย UTXO ใหม่จะถูกสร้างขึ้นเป็นเอาท์พุตของธุรกรรม
นี่คือวิธีที่ Bitcoin เก็บบัญชี: ในแต่ละธุรกรรม UTXO เก่าจะถูกทำลาย และอันใหม่จะถูกสร้างขึ้น จำนวน UTXO ที่ถูกทำลายทั้งหมดจะเท่ากับจำนวน UTXO ที่สร้างขึ้นใหม่ (โดยส่วนที่จัดสรรเป็นค่าธรรมเนียมการทำธุรกรรมให้กับนักขุด) สิ่งนี้ทำให้แน่ใจได้ว่าเงินทุนจะไม่สามารถเพิ่มได้ตามอำเภอใจ
สมมติว่ากลุ่มผู้ใช้เริ่มต้นคำขอธุรกรรมจำนวนมากพร้อมกัน สถานการณ์จะได้รับการจัดการโดยใช้แบบจำลอง UTXO อย่างไรเมื่อเปรียบเทียบกับแบบจำลองบัญชี/ยอดคงเหลือ
ในแบบจำลองบัญชี/ยอดคงเหลือ ผู้ใช้แต่ละรายจะมีบัญชีที่มีข้อมูลยอดคงเหลือที่บันทึกไว้ เมื่อมีธุรกรรมเกิดขึ้น จำเป็นต้องอัพเดตยอดคงเหลือในบัญชีที่เกี่ยวข้อง ซึ่งเกี่ยวข้องกับการดำเนินการทั้ง "อ่าน" และ "เขียน" อย่างไรก็ตาม หากธุรกรรมสองรายการเกี่ยวข้องกับบัญชีเดียวกัน ก็มักจะส่งผลให้เกิดข้อขัดแย้งในการอ่านและเขียน ซึ่งนำไปสู่การโต้แย้งของรัฐ ซึ่งเป็นสถานการณ์ที่ต้องหลีกเลี่ยง
โดยทั่วไประบบฐานข้อมูลแบบเดิมจะจัดการกับข้อโต้แย้งในการอ่านและเขียนด้วยกลไก "การล็อค" ในสถานการณ์เช่นนี้ ธุรกรรมที่ทำให้เกิดการแย่งชิงข้อมูลเดียวกันมักจะต้องเข้าคิว เพื่อป้องกันการดำเนินการพร้อมกัน และลดประสิทธิภาพในการประมวลผลธุรกรรม เมื่อมีธุรกรรมจำนวนมากรอการประมวลผล สิ่งนี้สามารถสร้างปัญหาคอขวดด้านประสิทธิภาพที่สำคัญ โดยธุรกรรมที่อยู่ในความขัดแย้งต้องเผชิญกับเวลารอที่ยาวนานโดยไม่มีการประมวลผลที่รวดเร็ว
ตรงกันข้ามกับโมเดลยอดคงเหลือในบัญชี โมเดล UTXO ของ Bitcoin มีอุปกรณ์ที่ดีกว่าในการจัดการปัญหาการช่วงชิงข้อมูล ในแนวทางนี้ หน่วยงานที่ประมวลผลโดยตรงของแต่ละธุรกรรมจะไม่ใช่ "บัญชี" ที่เฉพาะเจาะจงอีกต่อไป แต่เป็น UTXO ที่เป็นอิสระและเป็นรายบุคคล เนื่องจาก UTXO ที่แตกต่างกันจะไม่รบกวนซึ่งกันและกัน แต่ละธุรกรรมในเครือข่าย Bitcoin จะดำเนินการอย่างเป็นอิสระ เป็นผลให้โหนดเครือข่าย Bitcoin สามารถประมวลผลธุรกรรมหลายรายการพร้อมกันได้โดยไม่จำเป็นต้อง "ล็อค" ปรับปรุงปริมาณงานของระบบและประสิทธิภาพการทำงานพร้อมกันอย่างมีนัยสำคัญ
นอกจากนี้ ในรูปแบบ UTXO กระเป๋าเงินที่เข้ารหัสมักจะสร้างที่อยู่ใหม่ให้กับผู้ใช้หลังจากเริ่มการทำธุรกรรม แนวทางนี้ช่วยเพิ่มความเป็นส่วนตัว ทำให้การเชื่อมโยงธุรกรรมกับบุคคลใดบุคคลหนึ่งมีความท้าทายมากขึ้น ในทางตรงกันข้าม โมเดลบัญชี/ยอดคงเหลือซึ่งใช้ที่อยู่คงที่ มีความอ่อนไหวต่อการวิเคราะห์การเชื่อมโยงมากกว่า
อย่างไรก็ตาม โมเดล UTXO มีข้อจำกัด ในตอนแรกได้รับการออกแบบมาเพื่ออำนวยความสะดวกในการโอนเงินอย่างง่ายและไม่เหมาะสำหรับการจัดการตรรกะทางธุรกิจที่ซับซ้อน ในขณะที่ฟังก์ชันพื้นฐาน เช่น multi-signature และการล็อคเวลาสามารถใช้งานได้โดยใช้ภาษาสคริปต์ ข้อมูลสถานะขั้นต่ำที่ UTXO ของ Bitcoin สามารถบันทึกได้ ทำให้มีความสามารถในการจัดการการดำเนินการที่ซับซ้อนน้อยลง
ข้อจำกัดของ UTXO ของ Bitcoin มีส่วนทำให้เกิด "Ethereum" ทางอ้อม Vitalik หนึ่งในผู้ร่วมให้ข้อมูลรายแรกๆ ของนิตยสาร Bitcoin ตระหนักดีถึงข้อบกพร่องของ Bitcoin โมเดลบัญชี/ยอดคงเหลือซึ่งคนส่วนใหญ่เข้าใจได้ง่ายกว่า จัดการกับความท้าทายที่ UTXO เผชิญในการจัดการแอปพลิเคชันที่มีสถานะร่ำรวย ดังที่ Vitalik ระบุไว้ในเอกสารปกขาวของ Ethereum:
UTXO สามารถใช้หรือไม่ได้ใช้ก็ได้ ไม่มีโอกาสสำหรับสัญญาหรือสคริปต์แบบหลายขั้นตอนที่จะรักษาสถานะภายในอื่นใดนอกเหนือจากนั้น สิ่งนี้ทำให้ยากต่อการทำสัญญาออปชั่นแบบหลายขั้นตอน ข้อเสนอการแลกเปลี่ยนแบบกระจายอำนาจ หรือโปรโตคอลความมุ่งมั่นในการเข้ารหัสแบบสองขั้นตอน (จำเป็นสำหรับค่าหัวในการคำนวณที่ปลอดภัย) นอกจากนี้ยังหมายความว่า UTXO สามารถใช้เพื่อสร้างสัญญาง่ายๆ แบบครั้งเดียวเท่านั้น และไม่ซับซ้อนกว่าสัญญา "เก็บสถานะ" เช่น องค์กรที่กระจายอำนาจ และทำให้เมตาโปรโตคอลยากต่อการนำไปใช้ สถานะไบนารีรวมกับการตาบอดค่ายังหมายความว่าแอปพลิเคชันที่สำคัญอื่น ๆ ซึ่งมีข้อจำกัดในการถอนนั้นเป็นไปไม่ได้
ก่อนที่จะเจาะลึกแอปพลิเคชันต่างๆ และการเพิ่มประสิทธิภาพของโมเดล UTXO เรามาวิเคราะห์พื้นที่สำหรับการปรับปรุงในขณะที่ยังคงรักษาข้อดีไว้ สิ่งเหล่านี้สามารถสรุปได้ดังนี้:
สรุปความหมายของสถานะที่เก็บไว้ใน UTXO
เป็นการหักล้างความเป็นเจ้าของของรัฐ
แก้ไขปัญหาการโต้แย้งของรัฐเมื่อแชร์ UTXO
ใน BTC ความหมายเพียงอย่างเดียวของรัฐคือปริมาณโทเค็น โดยทั่วไปความเป็นเจ้าของจะถูกกำหนดโดยใช้กุญแจสาธารณะ และการโต้แย้งของรัฐไม่ได้รับการแก้ไขอย่างกว้างขวาง เนื่องจาก BTC ไม่ได้ออกแบบมาสำหรับ dApps
Sui จัดเตรียมอ็อบเจ็กต์สองประเภทให้กับนักพัฒนา: OwnedObject และ SharedObject แบบแรกคล้ายกับ UTXO (เวอร์ชันปรับปรุงโดยเฉพาะ) ในขณะที่แบบหลังเทียบได้กับโมเดลบัญชี/ยอดคงเหลือ สามารถใช้ทั้งสองอย่างพร้อมกันได้
ออบเจ็กต์สามารถแชร์ได้ หมายความว่าใครๆ ก็สามารถอ่านหรือเขียนออบเจ็กต์นั้นได้ ไม่เหมือนกับ OwnedObject ที่ไม่แน่นอน (มีตัวเขียนเพียงคนเดียว) SharedObject ต้องการความเห็นพ้องต้องกันเพื่อสั่งการอ่านและเขียน
ในบล็อกเชนอื่นๆ ทุกออบเจ็กต์จะถูกแชร์ อย่างไรก็ตาม โดยปกติแล้วนักพัฒนา Sui จะสามารถเลือกได้ว่าจะใช้ OwnedObject, SharedObject หรือทั้งสองอย่างรวมกันเพื่อใช้กรณีการใช้งานเฉพาะ ตัวเลือกนี้อาจส่งผลกระทบต่อประสิทธิภาพ ความปลอดภัย และความซับซ้อนในการใช้งาน
ใน Sui นั้น Owned Objects นั้นคล้ายคลึงกับ UTXO และมีเพียงเจ้าของเท่านั้นที่สามารถดำเนินการกับวัตถุเหล่านั้นได้ ออบเจ็กต์ยังมีหมายเลขเวอร์ชัน และเวอร์ชันของออบเจ็กต์สามารถใช้ได้โดยเจ้าของเพียงครั้งเดียวเท่านั้น ดังนั้นเวอร์ชันของอ็อบเจ็กต์จึงสอดคล้องกับ UTXO เป็นหลัก
เกี่ยวกับปัญหาความขัดแย้งของรัฐ Sui กล่าวถึงพวกเขาผ่านการจัดการพิเศษ (การสั่งซื้อในท้องถิ่น คล้ายกับ Fuel) ใน SharedObjects
Cardano ใช้โมเดล UTXO แบบขยายที่เรียกว่า eUTXO eUTXO รองรับความสามารถในการตั้งโปรแกรมที่เพิ่มขึ้นในขณะที่ยังคงรักษาข้อดีของโมเดล Bitcoin UTXO ไว้
ใน Cardano ความหมายของรัฐถูกขยายออกไปอีกผ่านสคริปต์ และความเป็นเจ้าของของรัฐถูกกำหนดในลักษณะทั่วไปมากขึ้น ชุด UTXO ใช้เพื่อลดปัญหาความขัดแย้งของรัฐ โดยเฉพาะอย่างยิ่ง eUTXO ได้รับการปรับปรุงในสองด้าน:
โมเดล eUTXO มีที่อยู่ทั่วไปมากขึ้น ที่อยู่เหล่านี้ไม่ได้ขึ้นอยู่กับแฮชของกุญแจสาธารณะเท่านั้น แต่สามารถกำหนดได้ขึ้นอยู่กับตรรกะใดๆ ที่ระบุเงื่อนไขที่สามารถใช้ eUTXO ได้ ทำให้สามารถตั้งโปรแกรมความเป็นเจ้าของของรัฐได้
นอกเหนือจากที่อยู่และค่าแล้ว เอาต์พุตยังสามารถนำข้อมูล (เกือบ) ใดๆ มาใช้ ทำให้สามารถตั้งโปรแกรมความหมายของสถานะผ่านสคริปต์ได้
โดยเฉพาะอย่างยิ่ง eUTXO อนุญาตให้ผู้ใช้เพิ่มข้อมูลที่กำหนดเองในรูปแบบคล้าย JSON ให้กับ UTXO หรือที่เรียกว่า Datum Datum ช่วยให้นักพัฒนาสามารถมอบฟังก์ชันการทำงานที่เหมือนสถานะสำหรับสคริปต์ที่เกี่ยวข้องกับ UTXO ที่เฉพาะเจาะจง
นอกจากนี้ การทำธุรกรรมบน Cardano สามารถพกพาพารามิเตอร์ที่เกี่ยวข้องกับผู้ใช้เฉพาะที่เรียกว่าผู้ไถ่ถอน Redeemer ช่วยให้ผู้ริเริ่มธุรกรรมสามารถกำหนดวิธีการใช้ UTXO และนักพัฒนา dApp สามารถนำไปใช้เพื่อวัตถุประสงค์ต่างๆ ได้
เมื่อธุรกรรมได้รับการตรวจสอบ สคริปต์การตรวจสอบจะดำเนินการโดยใช้ Datum, Redeemer และบริบทที่มีข้อมูลธุรกรรม สคริปต์นี้มีตรรกะสำหรับการใช้ UTXO เมื่อตรงตามเงื่อนไข
เป็นที่น่าสังเกตว่า eUTXO ยังคงทำงานส่วนขยายผ่านสคริปต์และแตกต่างอย่างมีนัยสำคัญจากแนวคิดดั้งเดิมของ "สัญญาอัจฉริยะ" (Charles Hoskinson ผู้ก่อตั้ง แนะนำให้เรียกมันว่า "เครื่องมือตรวจสอบความถูกต้องแบบโปรแกรมได้" แต่คำว่า "สัญญาอัจฉริยะ" ได้รับการยอมรับอย่างกว้างขวางมากขึ้น ในตลาด).
ใน Nervos (CKB) ความหมายของสถานะจะถูกสรุปโดย TypeScript และความเป็นเจ้าของของรัฐจะถูกสรุปโดย lockscript โมเดลการปรับให้เหมาะสม UTXO อย่างง่ายในรูปแบบของโค้ดเซลล์มีดังนี้:
โครงสร้างผับ CellOutput {
ความจุผับ: ความจุ
ข้อมูลผับ: Vec<u8>,
ล็อคผับ: สคริปต์,
pub type_: Option<Script>,
}
สำหรับประเด็นความขัดแย้งของรัฐนั้น ขณะนี้ CKB กำลังพัฒนาการวิจัยเกี่ยวกับ Open Transaction ซึ่งผู้ใช้สามารถเสนอ UTXO บางส่วนที่ระบุวัตถุประสงค์ของธุรกรรม จากนั้นระบบจับคู่จะรวมเป็นธุรกรรมที่สมบูรณ์
โมเดลเซลล์ของ Nervos เป็นเวอร์ชัน "ทั่วไป" ของ UTXO และ Jan ได้ให้คำอธิบายโดยละเอียดเกี่ยวกับฟอรัม Nervos:
จุดเน้นของ Layer1 อยู่ที่สถานะ และด้วย Layer1 เป็นเป้าหมายการออกแบบ CKB จึงมุ่งเน้นไปที่สถานะโดยธรรมชาติ
Ethereum แยกประวัติการทำธุรกรรมและประวัติสถานะออกเป็นสองมิติ โดยที่บล็อกและธุรกรรมเป็นตัวแทนของเหตุการณ์ที่กระตุ้นให้เกิดการเปลี่ยนแปลงสถานะ แทนที่จะเป็นตัวสถานะเอง ในทางตรงกันข้าม โปรโตคอล Bitcoin จะรวมธุรกรรมและสถานะไว้ในมิติเดียว ธุรกรรมคือสถานะ และสถานะคือธุรกรรม เป็นสถาปัตยกรรมที่มีศูนย์กลางอยู่ที่รัฐ
ในเวลาเดียวกัน CKB มีเป้าหมายที่จะตรวจสอบและรักษาไม่เพียงแต่ nValue ในฐานะรัฐเท่านั้น แต่ยังรวมถึงข้อมูลใดๆ ที่ถือว่ามีคุณค่าและได้รับอนุมัติอย่างเป็นเอกฉันท์สำหรับการอนุรักษ์ในระยะยาว โครงสร้างธุรกรรมของ Bitcoin ไม่เพียงพอสำหรับจุดประสงค์นี้ แต่ก็ให้แรงบันดาลใจแก่เรามากมาย ด้วยการสรุป nValue และแปลงจากช่องว่างที่จัดเก็บจำนวนเต็มให้เป็นช่องว่างที่สามารถเก็บข้อมูลใด ๆ ได้ เราจะได้ "CTxOut" หรือเซลล์ที่เป็นลักษณะทั่วไปมากขึ้น
ในเซลล์ nValue จะกลายเป็นสองฟิลด์: ความจุและข้อมูล ช่องเหล่านี้ร่วมกันแสดงถึงพื้นที่จัดเก็บข้อมูล โดยที่ความจุเป็นจำนวนเต็มที่ระบุขนาดของพื้นที่เป็นไบต์ และข้อมูลคือตำแหน่งที่จัดเก็บสถานะและสามารถรองรับลำดับไบต์ใดๆ ได้ scriptPubKey กลายเป็นการล็อค เพียงแค่เปลี่ยนชื่อ โดยแสดงว่าใครเป็นเจ้าของพื้นที่ฉันทามตินี้—เฉพาะบุคคลที่สามารถจัดเตรียมพารามิเตอร์ (เช่น ลายเซ็นต์) เพื่อให้สคริปต์การล็อคดำเนินการได้สำเร็จเท่านั้นที่สามารถ "อัปเดต" สถานะในเซลล์นี้ได้ . จำนวนไบต์ทั้งหมดที่ใช้โดย CellOutput ทั้งหมดต้องน้อยกว่าหรือเท่ากับความจุ CKB มีเซลล์จำนวนมาก และคอลเลกชันของพวกเขาก่อให้เกิดสถานะปัจจุบันที่สมบูรณ์ของ CKB โดยจัดเก็บความรู้ที่แบ่งปันมากกว่าเพียงสกุลเงินดิจิทัลที่เฉพาะเจาะจง
ธุรกรรมยังคงแสดงถึงการเปลี่ยนแปลง/การโยกย้ายของรัฐ การเปลี่ยนแปลงสถานะหรือ "การอัปเดต" ของเนื้อหาเซลล์ทำได้จริงผ่านการทำลายและการสร้าง (ไม่ใช่โดยการแก้ไขเนื้อหาของเซลล์ดั้งเดิมโดยตรง) ธุรกรรมแต่ละรายการจะทำลายเซลล์ชุดหนึ่งอย่างมีประสิทธิภาพในขณะเดียวกันก็สร้างเซลล์ชุดใหม่ไปพร้อมๆ กัน เซลล์ที่สร้างขึ้นใหม่มีเจ้าของใหม่และจัดเก็บข้อมูลใหม่ แต่ความจุทั้งหมดที่ถูกทำลายจะมากกว่าหรือเท่ากับความจุทั้งหมดที่สร้างขึ้นเสมอ เพื่อให้แน่ใจว่าจะไม่มีใครสามารถเพิ่มความจุโดยพลการได้ เนื่องจากความจุสามารถถ่ายโอนได้แต่ไม่สามารถเพิ่มได้ตามอำเภอใจ การครอบครองความจุจึงเทียบเท่ากับการเป็นเจ้าของพื้นที่รัฐที่เป็นเอกฉันท์ในปริมาณที่สอดคล้องกัน ความจุเป็นทรัพย์สินดั้งเดิมในเครือข่าย CKB การทำลายเซลล์เป็นเพียงการทำเครื่องหมายว่า "ถูกทำลาย" คล้ายกับการใช้ Bitcoin UTXO ที่ยังไม่ได้ใช้และไม่ได้ถูกลบออกจากบล็อกเชน แต่ละเซลล์สามารถถูกทำลายได้เพียงครั้งเดียว เช่นเดียวกับแต่ละ UTXO ที่สามารถใช้ได้เพียงครั้งเดียว
ลักษณะของรุ่นนี้คือ:
รัฐมีความสำคัญเป็นอันดับแรก
ความเป็นเจ้าของเป็นคุณลักษณะของรัฐ โดยแต่ละรัฐมีเจ้าของเพียงคนเดียว
รัฐถูกทำลายและสร้างอย่างต่อเนื่อง
ดังนั้น เซลล์จึงเป็นเวอร์ชันทั่วไปของ UTXO
Fuel ใช้โมเดลรายการการเข้าถึงที่เข้มงวด ซึ่งเป็นการเพิ่มประสิทธิภาพ UTXO ตามแนวคิดของสัญญา UTXO
ตามที่แนะนำก่อนหน้านี้ UTXO แบบดั้งเดิมใน BTC มีเพียงสองคุณลักษณะเท่านั้น: ปริมาณเหรียญและเจ้าของ ในทางตรงกันข้าม สัญญา UTXO มอบคุณสมบัติพื้นฐานเพิ่มเติม รวมถึงปริมาณเหรียญ รหัสสัญญา แฮชโค้ดสัญญา และรูทการจัดเก็บข้อมูล
หากใช้โมเดลการดำเนินการไร้สถานะ เฉพาะ UTXO สัญญาเท่านั้นที่ต้องใช้แฮชโค้ดสัญญาและรูทพื้นที่เก็บข้อมูล ในโมเดลการดำเนินการแบบมีสถานะ สามารถละเว้นฟิลด์เหล่านี้ได้ในสัญญา UTXO แต่จำเป็นต้องมีประเภท Storage Element UTXO แยกต่างหาก UTXO ID ซึ่งเป็นตัวระบุที่ไม่ซ้ำกันสำหรับ UTXO แต่ละตัวที่ทำหน้าที่เป็นคีย์ในฐานข้อมูลการจัดเก็บคีย์-ค่า ถูกสร้างขึ้นจากจุดเอาท์พุตของ UTXO หรือตัวแปรของมัน (เช่น แฮชของจุดเอาท์พุตและฟิลด์ของมัน)
ในโมเดลนี้ Contract UTXO ซึ่งคล้ายกับสัญญาอัจฉริยะสามารถเรียกโดยใครก็ได้
สิ่งสำคัญที่ควรทราบคือ Fuel มีฟังก์ชันที่ใกล้เคียงกับสัญญาอัจฉริยะมากกว่าสคริปต์ ข้อจำกัดของโมเดล UTXO ทำให้การพัฒนาแอปพลิเคชันด้วย VM มีความท้าทาย โดยเฉพาะอย่างยิ่งในการจัดการปัญหาความขัดแย้ง UTXO โดยทั่วไปมีวิธีแก้ปัญหาสามประการ: ขั้นแรก ประมวลผลนอกเครือข่าย เช่น ในการยกเลิก; ประการที่สอง การจัดลำดับงานเพิ่มเติมล่วงหน้า ซึ่งเชื้อเพลิงใช้ ประการที่สาม ธุรกรรมแบบเปิดที่กล่าวถึงข้างต้นใน CKB ซึ่งผู้ใช้แต่ละรายสามารถเสนอธุรกรรมบางส่วนได้ และระบบจับคู่ (คล้ายกับเครื่องจัดลำดับ) จะรวมธุรกรรมเหล่านั้นเป็นธุรกรรมที่สมบูรณ์ โซลูชันที่เกี่ยวข้องใน BTC คือ PBST
บทสรุป
จากบทความนี้ เราได้รับความเข้าใจในหลักการพื้นฐานของ UTXO รับรู้ถึงจุดแข็งและจุดอ่อนของโมเดลเมื่อเปรียบเทียบกับโมเดลบัญชี/ยอดคงเหลือของ Ethereum และได้รับข้อมูลเชิงลึกที่ชัดเจนยิ่งขึ้นเกี่ยวกับแนวคิดของ UTXO และส่วนขยายที่เกี่ยวข้อง
เนื่องจากเป็นหนึ่งในหลักการออกแบบหลักของ Bitcoin โมเดล UTXO จึงมีบทบาทสำคัญในการรับรองความปลอดภัยและความสามารถในการตรวจสอบย้อนกลับของธุรกรรม ด้วยวิวัฒนาการและการขยายตัวอย่างต่อเนื่องของเทคโนโลยีบล็อกเชน โมเดล UTXO ได้รับการพัฒนา (เช่น EUTXO, เซลล์, รายการการเข้าถึงที่เข้มงวด) ให้ความเป็นไปได้มากขึ้นสำหรับการทำธุรกรรมและการจัดการสินทรัพย์ดิจิทัล ด้วยการวิจัยเชิงลึกและความเข้าใจเกี่ยวกับแนวคิด UTXO และส่วนขยายที่เกี่ยวข้อง เราจึงสามารถเข้าใจแก่นแท้ของเทคโนโลยีบล็อกเชนได้ดีขึ้น โดยวางรากฐานที่แข็งแกร่งยิ่งขึ้นสำหรับนวัตกรรมและแอปพลิเคชันในอนาคต
เนื่องจากเป็นหนึ่งในหลักการออกแบบหลักของ Bitcoin โมเดล UTXO จึงเป็นกระบวนทัศน์ทางเทคนิคที่สำคัญในโดเมนบล็อกเชนนับตั้งแต่เริ่มก่อตั้ง มีบทบาทสำคัญในการรับรองความปลอดภัยของธุรกรรมและการตรวจสอบย้อนกลับ โดยให้ทางเลือกอื่นนอกเหนือจากรูปแบบยอดเงินคงเหลือในบัญชีแบบเดิม ด้วยการพัฒนาและการขยายตัวอย่างต่อเนื่องของเทคโนโลยีบล็อกเชนในช่วงไม่กี่ปีที่ผ่านมา โมเดล UTXO เองก็มีการพัฒนาและขยายอย่างต่อเนื่อง เช่น eUTXO เซลล์ รายการเข้าถึงที่เข้มงวด และอื่นๆ
บทความนี้จะแนะนำโมเดล UTXO ในภาษาธรรมดา โดยให้ภาพรวมโดยย่อของโมเดล UTXO และวิธีการใช้งาน BTC, Sui, Cardano, Nervos และ Fuel
เพื่อแสดงให้เห็นโมเดล UTXO เราใช้ตัวอย่าง:
ลองนึกภาพคนสองคน อลิซและบ็อบ ซึ่งเริ่มแรกแต่ละคนมีเงิน 5 ดอลลาร์ ต่อจากนั้น เกิดความขัดแย้งขึ้น และอลิซถูกบ็อบปล้นไป 2 ดอลลาร์ การถือครองขั้นสุดท้ายสำหรับแต่ละรายการมีดังนี้:
เห็นได้ชัดว่าอลิซมีเงิน 3 ดอลลาร์ และในที่สุด Bob ก็ถือเงิน 7 ดอลลาร์ วิธีการบัญชีที่มีลักษณะคล้ายเลขคณิตเบื้องต้นนี้พบได้ทั่วไปในระบบธนาคาร และเรียกว่า "แบบจำลองบัญชี/ยอดคงเหลือ" ในแบบจำลองนี้ ยอดคงเหลือของบัญชีจะมีค่าเป็นตัวเลขเพียงค่าเดียว
หากเราต้องใช้แนวทางที่แตกต่างจากโมเดลบัญชี เช่น การใช้ UTXO เพื่อแสดงการโอนความมั่งคั่งระหว่าง Alice และ Bob แผนภาพตัวอย่างจะมีรูปลักษณ์ที่แตกต่างออกไป:
ณ จุดนี้ อลิซยังคงมีเงิน $3 และ Bob ยังคงมีเงิน $7 แต่ $7 เหล่านี้ไม่ได้แสดงด้วยค่าตัวเลขเพียงค่าเดียว แต่จะแบ่งออกเป็น “$5” และ “$2” แทน วิธีการแหวกแนวนี้รู้สึกไม่คุ้นเคยบ้างหรือไม่? นี่เป็นวิธีการบัญชีเฉพาะที่เรียกว่า UTXO
ตัวย่อภาษาอังกฤษ UTXO ย่อมาจาก Unspent Transaction Output ภายใต้แนวทางการบัญชีนี้ แต่ละธุรกรรมออนไลน์จะแสดงเป็นการเปลี่ยนแปลงและการโอนใน UTXO ตัวอย่างเช่น ในเหตุการณ์ธุรกรรมดังกล่าว “$5” ที่ Alice เป็นเจ้าของในตอนแรกทำหน้าที่เป็นพารามิเตอร์อินพุตซึ่งมีป้ายกำกับว่า UTXO_0 ซึ่งจะถูกทำเครื่องหมายว่าใช้จ่ายแล้ว พร้อมกัน ระบบจะสร้าง “$2” (UTXO_1) และ “$3” (UTXO_2) เป็นพารามิเตอร์เอาต์พุต UTXO_1 จะถูกโอนไปที่ Bob และ UTXO_2 จะถูกส่งคืนให้กับ Alice ซึ่งจะทำให้การโอนความมั่งคั่งระหว่าง Alice และ Bob เสร็จสมบูรณ์
ในโมเดล UTXO ไม่มีแนวคิดที่ชัดเจนเกี่ยวกับ "บัญชี" และ "ยอดคงเหลือ" UTXO ทำหน้าที่เป็นโครงสร้างข้อมูลที่ช่วยในการดำเนินธุรกรรม โดยบันทึกข้อมูล เช่น จำนวนเงินที่แสดงและดัชนีธุรกรรมที่เกี่ยวข้อง แต่ละ UTXO แสดงถึงอินพุตธุรกรรมที่ยังไม่ได้ใช้ โดยมีเจ้าของที่ได้รับมอบหมาย เมื่อธุรกรรมเกิดขึ้น UTXO บางตัวสามารถใช้เป็นอินพุตได้ และเมื่อถูกทำลาย UTXO ใหม่จะถูกสร้างขึ้นเป็นเอาท์พุตของธุรกรรม
นี่คือวิธีที่ Bitcoin เก็บบัญชี: ในแต่ละธุรกรรม UTXO เก่าจะถูกทำลาย และอันใหม่จะถูกสร้างขึ้น จำนวน UTXO ที่ถูกทำลายทั้งหมดจะเท่ากับจำนวน UTXO ที่สร้างขึ้นใหม่ (โดยส่วนที่จัดสรรเป็นค่าธรรมเนียมการทำธุรกรรมให้กับนักขุด) สิ่งนี้ทำให้แน่ใจได้ว่าเงินทุนจะไม่สามารถเพิ่มได้ตามอำเภอใจ
สมมติว่ากลุ่มผู้ใช้เริ่มต้นคำขอธุรกรรมจำนวนมากพร้อมกัน สถานการณ์จะได้รับการจัดการโดยใช้แบบจำลอง UTXO อย่างไรเมื่อเปรียบเทียบกับแบบจำลองบัญชี/ยอดคงเหลือ
ในแบบจำลองบัญชี/ยอดคงเหลือ ผู้ใช้แต่ละรายจะมีบัญชีที่มีข้อมูลยอดคงเหลือที่บันทึกไว้ เมื่อมีธุรกรรมเกิดขึ้น จำเป็นต้องอัพเดตยอดคงเหลือในบัญชีที่เกี่ยวข้อง ซึ่งเกี่ยวข้องกับการดำเนินการทั้ง "อ่าน" และ "เขียน" อย่างไรก็ตาม หากธุรกรรมสองรายการเกี่ยวข้องกับบัญชีเดียวกัน ก็มักจะส่งผลให้เกิดข้อขัดแย้งในการอ่านและเขียน ซึ่งนำไปสู่การโต้แย้งของรัฐ ซึ่งเป็นสถานการณ์ที่ต้องหลีกเลี่ยง
โดยทั่วไประบบฐานข้อมูลแบบเดิมจะจัดการกับข้อโต้แย้งในการอ่านและเขียนด้วยกลไก "การล็อค" ในสถานการณ์เช่นนี้ ธุรกรรมที่ทำให้เกิดการแย่งชิงข้อมูลเดียวกันมักจะต้องเข้าคิว เพื่อป้องกันการดำเนินการพร้อมกัน และลดประสิทธิภาพในการประมวลผลธุรกรรม เมื่อมีธุรกรรมจำนวนมากรอการประมวลผล สิ่งนี้สามารถสร้างปัญหาคอขวดด้านประสิทธิภาพที่สำคัญ โดยธุรกรรมที่อยู่ในความขัดแย้งต้องเผชิญกับเวลารอที่ยาวนานโดยไม่มีการประมวลผลที่รวดเร็ว
ตรงกันข้ามกับโมเดลยอดคงเหลือในบัญชี โมเดล UTXO ของ Bitcoin มีอุปกรณ์ที่ดีกว่าในการจัดการปัญหาการช่วงชิงข้อมูล ในแนวทางนี้ หน่วยงานที่ประมวลผลโดยตรงของแต่ละธุรกรรมจะไม่ใช่ "บัญชี" ที่เฉพาะเจาะจงอีกต่อไป แต่เป็น UTXO ที่เป็นอิสระและเป็นรายบุคคล เนื่องจาก UTXO ที่แตกต่างกันจะไม่รบกวนซึ่งกันและกัน แต่ละธุรกรรมในเครือข่าย Bitcoin จะดำเนินการอย่างเป็นอิสระ เป็นผลให้โหนดเครือข่าย Bitcoin สามารถประมวลผลธุรกรรมหลายรายการพร้อมกันได้โดยไม่จำเป็นต้อง "ล็อค" ปรับปรุงปริมาณงานของระบบและประสิทธิภาพการทำงานพร้อมกันอย่างมีนัยสำคัญ
นอกจากนี้ ในรูปแบบ UTXO กระเป๋าเงินที่เข้ารหัสมักจะสร้างที่อยู่ใหม่ให้กับผู้ใช้หลังจากเริ่มการทำธุรกรรม แนวทางนี้ช่วยเพิ่มความเป็นส่วนตัว ทำให้การเชื่อมโยงธุรกรรมกับบุคคลใดบุคคลหนึ่งมีความท้าทายมากขึ้น ในทางตรงกันข้าม โมเดลบัญชี/ยอดคงเหลือซึ่งใช้ที่อยู่คงที่ มีความอ่อนไหวต่อการวิเคราะห์การเชื่อมโยงมากกว่า
อย่างไรก็ตาม โมเดล UTXO มีข้อจำกัด ในตอนแรกได้รับการออกแบบมาเพื่ออำนวยความสะดวกในการโอนเงินอย่างง่ายและไม่เหมาะสำหรับการจัดการตรรกะทางธุรกิจที่ซับซ้อน ในขณะที่ฟังก์ชันพื้นฐาน เช่น multi-signature และการล็อคเวลาสามารถใช้งานได้โดยใช้ภาษาสคริปต์ ข้อมูลสถานะขั้นต่ำที่ UTXO ของ Bitcoin สามารถบันทึกได้ ทำให้มีความสามารถในการจัดการการดำเนินการที่ซับซ้อนน้อยลง
ข้อจำกัดของ UTXO ของ Bitcoin มีส่วนทำให้เกิด "Ethereum" ทางอ้อม Vitalik หนึ่งในผู้ร่วมให้ข้อมูลรายแรกๆ ของนิตยสาร Bitcoin ตระหนักดีถึงข้อบกพร่องของ Bitcoin โมเดลบัญชี/ยอดคงเหลือซึ่งคนส่วนใหญ่เข้าใจได้ง่ายกว่า จัดการกับความท้าทายที่ UTXO เผชิญในการจัดการแอปพลิเคชันที่มีสถานะร่ำรวย ดังที่ Vitalik ระบุไว้ในเอกสารปกขาวของ Ethereum:
UTXO สามารถใช้หรือไม่ได้ใช้ก็ได้ ไม่มีโอกาสสำหรับสัญญาหรือสคริปต์แบบหลายขั้นตอนที่จะรักษาสถานะภายในอื่นใดนอกเหนือจากนั้น สิ่งนี้ทำให้ยากต่อการทำสัญญาออปชั่นแบบหลายขั้นตอน ข้อเสนอการแลกเปลี่ยนแบบกระจายอำนาจ หรือโปรโตคอลความมุ่งมั่นในการเข้ารหัสแบบสองขั้นตอน (จำเป็นสำหรับค่าหัวในการคำนวณที่ปลอดภัย) นอกจากนี้ยังหมายความว่า UTXO สามารถใช้เพื่อสร้างสัญญาง่ายๆ แบบครั้งเดียวเท่านั้น และไม่ซับซ้อนกว่าสัญญา "เก็บสถานะ" เช่น องค์กรที่กระจายอำนาจ และทำให้เมตาโปรโตคอลยากต่อการนำไปใช้ สถานะไบนารีรวมกับการตาบอดค่ายังหมายความว่าแอปพลิเคชันที่สำคัญอื่น ๆ ซึ่งมีข้อจำกัดในการถอนนั้นเป็นไปไม่ได้
ก่อนที่จะเจาะลึกแอปพลิเคชันต่างๆ และการเพิ่มประสิทธิภาพของโมเดล UTXO เรามาวิเคราะห์พื้นที่สำหรับการปรับปรุงในขณะที่ยังคงรักษาข้อดีไว้ สิ่งเหล่านี้สามารถสรุปได้ดังนี้:
สรุปความหมายของสถานะที่เก็บไว้ใน UTXO
เป็นการหักล้างความเป็นเจ้าของของรัฐ
แก้ไขปัญหาการโต้แย้งของรัฐเมื่อแชร์ UTXO
ใน BTC ความหมายเพียงอย่างเดียวของรัฐคือปริมาณโทเค็น โดยทั่วไปความเป็นเจ้าของจะถูกกำหนดโดยใช้กุญแจสาธารณะ และการโต้แย้งของรัฐไม่ได้รับการแก้ไขอย่างกว้างขวาง เนื่องจาก BTC ไม่ได้ออกแบบมาสำหรับ dApps
Sui จัดเตรียมอ็อบเจ็กต์สองประเภทให้กับนักพัฒนา: OwnedObject และ SharedObject แบบแรกคล้ายกับ UTXO (เวอร์ชันปรับปรุงโดยเฉพาะ) ในขณะที่แบบหลังเทียบได้กับโมเดลบัญชี/ยอดคงเหลือ สามารถใช้ทั้งสองอย่างพร้อมกันได้
ออบเจ็กต์สามารถแชร์ได้ หมายความว่าใครๆ ก็สามารถอ่านหรือเขียนออบเจ็กต์นั้นได้ ไม่เหมือนกับ OwnedObject ที่ไม่แน่นอน (มีตัวเขียนเพียงคนเดียว) SharedObject ต้องการความเห็นพ้องต้องกันเพื่อสั่งการอ่านและเขียน
ในบล็อกเชนอื่นๆ ทุกออบเจ็กต์จะถูกแชร์ อย่างไรก็ตาม โดยปกติแล้วนักพัฒนา Sui จะสามารถเลือกได้ว่าจะใช้ OwnedObject, SharedObject หรือทั้งสองอย่างรวมกันเพื่อใช้กรณีการใช้งานเฉพาะ ตัวเลือกนี้อาจส่งผลกระทบต่อประสิทธิภาพ ความปลอดภัย และความซับซ้อนในการใช้งาน
ใน Sui นั้น Owned Objects นั้นคล้ายคลึงกับ UTXO และมีเพียงเจ้าของเท่านั้นที่สามารถดำเนินการกับวัตถุเหล่านั้นได้ ออบเจ็กต์ยังมีหมายเลขเวอร์ชัน และเวอร์ชันของออบเจ็กต์สามารถใช้ได้โดยเจ้าของเพียงครั้งเดียวเท่านั้น ดังนั้นเวอร์ชันของอ็อบเจ็กต์จึงสอดคล้องกับ UTXO เป็นหลัก
เกี่ยวกับปัญหาความขัดแย้งของรัฐ Sui กล่าวถึงพวกเขาผ่านการจัดการพิเศษ (การสั่งซื้อในท้องถิ่น คล้ายกับ Fuel) ใน SharedObjects
Cardano ใช้โมเดล UTXO แบบขยายที่เรียกว่า eUTXO eUTXO รองรับความสามารถในการตั้งโปรแกรมที่เพิ่มขึ้นในขณะที่ยังคงรักษาข้อดีของโมเดล Bitcoin UTXO ไว้
ใน Cardano ความหมายของรัฐถูกขยายออกไปอีกผ่านสคริปต์ และความเป็นเจ้าของของรัฐถูกกำหนดในลักษณะทั่วไปมากขึ้น ชุด UTXO ใช้เพื่อลดปัญหาความขัดแย้งของรัฐ โดยเฉพาะอย่างยิ่ง eUTXO ได้รับการปรับปรุงในสองด้าน:
โมเดล eUTXO มีที่อยู่ทั่วไปมากขึ้น ที่อยู่เหล่านี้ไม่ได้ขึ้นอยู่กับแฮชของกุญแจสาธารณะเท่านั้น แต่สามารถกำหนดได้ขึ้นอยู่กับตรรกะใดๆ ที่ระบุเงื่อนไขที่สามารถใช้ eUTXO ได้ ทำให้สามารถตั้งโปรแกรมความเป็นเจ้าของของรัฐได้
นอกเหนือจากที่อยู่และค่าแล้ว เอาต์พุตยังสามารถนำข้อมูล (เกือบ) ใดๆ มาใช้ ทำให้สามารถตั้งโปรแกรมความหมายของสถานะผ่านสคริปต์ได้
โดยเฉพาะอย่างยิ่ง eUTXO อนุญาตให้ผู้ใช้เพิ่มข้อมูลที่กำหนดเองในรูปแบบคล้าย JSON ให้กับ UTXO หรือที่เรียกว่า Datum Datum ช่วยให้นักพัฒนาสามารถมอบฟังก์ชันการทำงานที่เหมือนสถานะสำหรับสคริปต์ที่เกี่ยวข้องกับ UTXO ที่เฉพาะเจาะจง
นอกจากนี้ การทำธุรกรรมบน Cardano สามารถพกพาพารามิเตอร์ที่เกี่ยวข้องกับผู้ใช้เฉพาะที่เรียกว่าผู้ไถ่ถอน Redeemer ช่วยให้ผู้ริเริ่มธุรกรรมสามารถกำหนดวิธีการใช้ UTXO และนักพัฒนา dApp สามารถนำไปใช้เพื่อวัตถุประสงค์ต่างๆ ได้
เมื่อธุรกรรมได้รับการตรวจสอบ สคริปต์การตรวจสอบจะดำเนินการโดยใช้ Datum, Redeemer และบริบทที่มีข้อมูลธุรกรรม สคริปต์นี้มีตรรกะสำหรับการใช้ UTXO เมื่อตรงตามเงื่อนไข
เป็นที่น่าสังเกตว่า eUTXO ยังคงทำงานส่วนขยายผ่านสคริปต์และแตกต่างอย่างมีนัยสำคัญจากแนวคิดดั้งเดิมของ "สัญญาอัจฉริยะ" (Charles Hoskinson ผู้ก่อตั้ง แนะนำให้เรียกมันว่า "เครื่องมือตรวจสอบความถูกต้องแบบโปรแกรมได้" แต่คำว่า "สัญญาอัจฉริยะ" ได้รับการยอมรับอย่างกว้างขวางมากขึ้น ในตลาด).
ใน Nervos (CKB) ความหมายของสถานะจะถูกสรุปโดย TypeScript และความเป็นเจ้าของของรัฐจะถูกสรุปโดย lockscript โมเดลการปรับให้เหมาะสม UTXO อย่างง่ายในรูปแบบของโค้ดเซลล์มีดังนี้:
โครงสร้างผับ CellOutput {
ความจุผับ: ความจุ
ข้อมูลผับ: Vec<u8>,
ล็อคผับ: สคริปต์,
pub type_: Option<Script>,
}
สำหรับประเด็นความขัดแย้งของรัฐนั้น ขณะนี้ CKB กำลังพัฒนาการวิจัยเกี่ยวกับ Open Transaction ซึ่งผู้ใช้สามารถเสนอ UTXO บางส่วนที่ระบุวัตถุประสงค์ของธุรกรรม จากนั้นระบบจับคู่จะรวมเป็นธุรกรรมที่สมบูรณ์
โมเดลเซลล์ของ Nervos เป็นเวอร์ชัน "ทั่วไป" ของ UTXO และ Jan ได้ให้คำอธิบายโดยละเอียดเกี่ยวกับฟอรัม Nervos:
จุดเน้นของ Layer1 อยู่ที่สถานะ และด้วย Layer1 เป็นเป้าหมายการออกแบบ CKB จึงมุ่งเน้นไปที่สถานะโดยธรรมชาติ
Ethereum แยกประวัติการทำธุรกรรมและประวัติสถานะออกเป็นสองมิติ โดยที่บล็อกและธุรกรรมเป็นตัวแทนของเหตุการณ์ที่กระตุ้นให้เกิดการเปลี่ยนแปลงสถานะ แทนที่จะเป็นตัวสถานะเอง ในทางตรงกันข้าม โปรโตคอล Bitcoin จะรวมธุรกรรมและสถานะไว้ในมิติเดียว ธุรกรรมคือสถานะ และสถานะคือธุรกรรม เป็นสถาปัตยกรรมที่มีศูนย์กลางอยู่ที่รัฐ
ในเวลาเดียวกัน CKB มีเป้าหมายที่จะตรวจสอบและรักษาไม่เพียงแต่ nValue ในฐานะรัฐเท่านั้น แต่ยังรวมถึงข้อมูลใดๆ ที่ถือว่ามีคุณค่าและได้รับอนุมัติอย่างเป็นเอกฉันท์สำหรับการอนุรักษ์ในระยะยาว โครงสร้างธุรกรรมของ Bitcoin ไม่เพียงพอสำหรับจุดประสงค์นี้ แต่ก็ให้แรงบันดาลใจแก่เรามากมาย ด้วยการสรุป nValue และแปลงจากช่องว่างที่จัดเก็บจำนวนเต็มให้เป็นช่องว่างที่สามารถเก็บข้อมูลใด ๆ ได้ เราจะได้ "CTxOut" หรือเซลล์ที่เป็นลักษณะทั่วไปมากขึ้น
ในเซลล์ nValue จะกลายเป็นสองฟิลด์: ความจุและข้อมูล ช่องเหล่านี้ร่วมกันแสดงถึงพื้นที่จัดเก็บข้อมูล โดยที่ความจุเป็นจำนวนเต็มที่ระบุขนาดของพื้นที่เป็นไบต์ และข้อมูลคือตำแหน่งที่จัดเก็บสถานะและสามารถรองรับลำดับไบต์ใดๆ ได้ scriptPubKey กลายเป็นการล็อค เพียงแค่เปลี่ยนชื่อ โดยแสดงว่าใครเป็นเจ้าของพื้นที่ฉันทามตินี้—เฉพาะบุคคลที่สามารถจัดเตรียมพารามิเตอร์ (เช่น ลายเซ็นต์) เพื่อให้สคริปต์การล็อคดำเนินการได้สำเร็จเท่านั้นที่สามารถ "อัปเดต" สถานะในเซลล์นี้ได้ . จำนวนไบต์ทั้งหมดที่ใช้โดย CellOutput ทั้งหมดต้องน้อยกว่าหรือเท่ากับความจุ CKB มีเซลล์จำนวนมาก และคอลเลกชันของพวกเขาก่อให้เกิดสถานะปัจจุบันที่สมบูรณ์ของ CKB โดยจัดเก็บความรู้ที่แบ่งปันมากกว่าเพียงสกุลเงินดิจิทัลที่เฉพาะเจาะจง
ธุรกรรมยังคงแสดงถึงการเปลี่ยนแปลง/การโยกย้ายของรัฐ การเปลี่ยนแปลงสถานะหรือ "การอัปเดต" ของเนื้อหาเซลล์ทำได้จริงผ่านการทำลายและการสร้าง (ไม่ใช่โดยการแก้ไขเนื้อหาของเซลล์ดั้งเดิมโดยตรง) ธุรกรรมแต่ละรายการจะทำลายเซลล์ชุดหนึ่งอย่างมีประสิทธิภาพในขณะเดียวกันก็สร้างเซลล์ชุดใหม่ไปพร้อมๆ กัน เซลล์ที่สร้างขึ้นใหม่มีเจ้าของใหม่และจัดเก็บข้อมูลใหม่ แต่ความจุทั้งหมดที่ถูกทำลายจะมากกว่าหรือเท่ากับความจุทั้งหมดที่สร้างขึ้นเสมอ เพื่อให้แน่ใจว่าจะไม่มีใครสามารถเพิ่มความจุโดยพลการได้ เนื่องจากความจุสามารถถ่ายโอนได้แต่ไม่สามารถเพิ่มได้ตามอำเภอใจ การครอบครองความจุจึงเทียบเท่ากับการเป็นเจ้าของพื้นที่รัฐที่เป็นเอกฉันท์ในปริมาณที่สอดคล้องกัน ความจุเป็นทรัพย์สินดั้งเดิมในเครือข่าย CKB การทำลายเซลล์เป็นเพียงการทำเครื่องหมายว่า "ถูกทำลาย" คล้ายกับการใช้ Bitcoin UTXO ที่ยังไม่ได้ใช้และไม่ได้ถูกลบออกจากบล็อกเชน แต่ละเซลล์สามารถถูกทำลายได้เพียงครั้งเดียว เช่นเดียวกับแต่ละ UTXO ที่สามารถใช้ได้เพียงครั้งเดียว
ลักษณะของรุ่นนี้คือ:
รัฐมีความสำคัญเป็นอันดับแรก
ความเป็นเจ้าของเป็นคุณลักษณะของรัฐ โดยแต่ละรัฐมีเจ้าของเพียงคนเดียว
รัฐถูกทำลายและสร้างอย่างต่อเนื่อง
ดังนั้น เซลล์จึงเป็นเวอร์ชันทั่วไปของ UTXO
Fuel ใช้โมเดลรายการการเข้าถึงที่เข้มงวด ซึ่งเป็นการเพิ่มประสิทธิภาพ UTXO ตามแนวคิดของสัญญา UTXO
ตามที่แนะนำก่อนหน้านี้ UTXO แบบดั้งเดิมใน BTC มีเพียงสองคุณลักษณะเท่านั้น: ปริมาณเหรียญและเจ้าของ ในทางตรงกันข้าม สัญญา UTXO มอบคุณสมบัติพื้นฐานเพิ่มเติม รวมถึงปริมาณเหรียญ รหัสสัญญา แฮชโค้ดสัญญา และรูทการจัดเก็บข้อมูล
หากใช้โมเดลการดำเนินการไร้สถานะ เฉพาะ UTXO สัญญาเท่านั้นที่ต้องใช้แฮชโค้ดสัญญาและรูทพื้นที่เก็บข้อมูล ในโมเดลการดำเนินการแบบมีสถานะ สามารถละเว้นฟิลด์เหล่านี้ได้ในสัญญา UTXO แต่จำเป็นต้องมีประเภท Storage Element UTXO แยกต่างหาก UTXO ID ซึ่งเป็นตัวระบุที่ไม่ซ้ำกันสำหรับ UTXO แต่ละตัวที่ทำหน้าที่เป็นคีย์ในฐานข้อมูลการจัดเก็บคีย์-ค่า ถูกสร้างขึ้นจากจุดเอาท์พุตของ UTXO หรือตัวแปรของมัน (เช่น แฮชของจุดเอาท์พุตและฟิลด์ของมัน)
ในโมเดลนี้ Contract UTXO ซึ่งคล้ายกับสัญญาอัจฉริยะสามารถเรียกโดยใครก็ได้
สิ่งสำคัญที่ควรทราบคือ Fuel มีฟังก์ชันที่ใกล้เคียงกับสัญญาอัจฉริยะมากกว่าสคริปต์ ข้อจำกัดของโมเดล UTXO ทำให้การพัฒนาแอปพลิเคชันด้วย VM มีความท้าทาย โดยเฉพาะอย่างยิ่งในการจัดการปัญหาความขัดแย้ง UTXO โดยทั่วไปมีวิธีแก้ปัญหาสามประการ: ขั้นแรก ประมวลผลนอกเครือข่าย เช่น ในการยกเลิก; ประการที่สอง การจัดลำดับงานเพิ่มเติมล่วงหน้า ซึ่งเชื้อเพลิงใช้ ประการที่สาม ธุรกรรมแบบเปิดที่กล่าวถึงข้างต้นใน CKB ซึ่งผู้ใช้แต่ละรายสามารถเสนอธุรกรรมบางส่วนได้ และระบบจับคู่ (คล้ายกับเครื่องจัดลำดับ) จะรวมธุรกรรมเหล่านั้นเป็นธุรกรรมที่สมบูรณ์ โซลูชันที่เกี่ยวข้องใน BTC คือ PBST
บทสรุป
จากบทความนี้ เราได้รับความเข้าใจในหลักการพื้นฐานของ UTXO รับรู้ถึงจุดแข็งและจุดอ่อนของโมเดลเมื่อเปรียบเทียบกับโมเดลบัญชี/ยอดคงเหลือของ Ethereum และได้รับข้อมูลเชิงลึกที่ชัดเจนยิ่งขึ้นเกี่ยวกับแนวคิดของ UTXO และส่วนขยายที่เกี่ยวข้อง
เนื่องจากเป็นหนึ่งในหลักการออกแบบหลักของ Bitcoin โมเดล UTXO จึงมีบทบาทสำคัญในการรับรองความปลอดภัยและความสามารถในการตรวจสอบย้อนกลับของธุรกรรม ด้วยวิวัฒนาการและการขยายตัวอย่างต่อเนื่องของเทคโนโลยีบล็อกเชน โมเดล UTXO ได้รับการพัฒนา (เช่น EUTXO, เซลล์, รายการการเข้าถึงที่เข้มงวด) ให้ความเป็นไปได้มากขึ้นสำหรับการทำธุรกรรมและการจัดการสินทรัพย์ดิจิทัล ด้วยการวิจัยเชิงลึกและความเข้าใจเกี่ยวกับแนวคิด UTXO และส่วนขยายที่เกี่ยวข้อง เราจึงสามารถเข้าใจแก่นแท้ของเทคโนโลยีบล็อกเชนได้ดีขึ้น โดยวางรากฐานที่แข็งแกร่งยิ่งขึ้นสำหรับนวัตกรรมและแอปพลิเคชันในอนาคต