> For the complete documentation index, see [llms.txt](https://rs0-5.gitbook.io/righttech/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://rs0-5.gitbook.io/righttech/common/utreexo-utxo-bitcoin.md).

# Utreexo: โครงสร้างและการย่อขนาด UTXO ใน Bitcoin

<figure><img src="/files/RbHTWobVG3CnofOPXR0Z" alt=""><figcaption></figcaption></figure>

ภาพประกอบด้านบนแสดงการเติบโตของชุดข้อมูล UTXO ของ Bitcoin (ขนาดหน่วย GB) ตั้งแต่ปี 2019 จนถึง 2024 โดยเห็นว่าชุดข้อมูล UTXO เพิ่มขึ้นอย่างรวดเร็ว [\[1\]](https://bitcoinmagazine.com/technical/bitcoins-growing-utxo-problem-and-how-utreexo-can-help-solve-it#:~:text=Bitcoin%20nodes%2C%20therefore%2C%20have%20two,which%20new%20transactions%20are%20valid) การเติบโตนี้ทำให้โหนด (node) แบบเดิมต้องใช้หน่วยความจำและพื้นที่จัดเก็บมากขึ้นเรื่อยๆ (ปัจจุบันมี UTXO ถึงประมาณ 60 ล้านรายการ หรือ \~12 GB) [\[2\]](https://bitcoinops.org/en/newsletters/2024/05/15/#release-of-utreexod-beta) ซึ่งอาจจะเป็นอุปสรรคต่อการรัน Bitcoin Full node ได้ในอนาคต Utreexo เป็นแนวคิดใหม่ที่แก้ปัญหานี้โดยใช้ *cryptographic accumulator* แทนฐานข้อมูล UTXO แบบเดิม โดย Utreexo สามารถแทนข้อมูล UTXO หลายล้านรายการไว้ด้วยข้อมูลขนาดเล็กเพียงไม่กี่ร้อยไบต์ (ตัว accumulator มีขนาด <1 KB) [\[3\]](https://www.dci.mit.edu/projects/utreexo#:~:text=Utreexo%20is%20a%20novel%20hash,the%20owner%20of%20those%20funds) แนวคิดนี้คือการแทนที่โหนดทุกเครื่องจะต้องเก็บ UTXO ทั้งหมดเอาไว้จะเปลี่ยนเป็นโหนดจะเก็บเพียงสถานะตัวสะสม (accumulator) เท่านั้น ส่วนผู้ถือเหรียญจะรักษาหลักฐาน (*proof*) ของ UTXO ที่ตนเป็นเจ้าของ เมื่อสร้างธุรกรรมจะส่งหลักฐานดังกล่าวแนบมากับธุรกรรมด้วย เพื่อตรวจสอบได้ว่าเหรียญที่ใช้จ่ายมีอยู่จริงในตัวสะสม ซึ่งวิธีนี้จะลดขนาดข้อมูลสถานะลงอย่างมากแลกกับการส่งข้อมูลเพิ่มเพียงเล็กน้อย (overhead ประมาณ +25% ในการดาวน์โหลดข้อมูลเทียบกับเดิม) [\[4\]](https://eprint.iacr.org/2019/611.pdf#:~:text=accumulator%20to%20locally%20represent%20the,to%20the%20amount%20otherwise%20downloaded)

### โครงสร้างข้อมูลพื้นฐาน: Merkle Forest และ Accumulator

Utreexo ใช้หลักการ *hash-based dynamic accumulator* ซึ่งอธิบายได้ว่าเป็น “ป่า Merkle (Merkle forest)” – คือต้นของ Merkle หลาย ๆ ต้นมาทำงานร่วมกัน [\[5\]](https://lukechampine.com/utreexo-talk.html#:~:text=The%20Utreexo%20accumulator%20is%20a,I%27m%20pretty%20enamored%20with) โดยแต่ละต้นมีใบเป็นข้อมูล UTXO และเมื่อมีการเพิ่ม UTXO ใหม่เข้าไปจะเพิ่มเป็นใบใหม่ในต้นที่เหมาะสม และเมื่อมีการใช้จ่ายใบใบนั้นจะถูกลบออกจาก accumulator โดยในทางปฏิบัติ accumulator นี้ถูกเก็บเป็นอาร์เรย์ของค่า root hashes ของแต่ละต้น (เช่น acc\[n] คือรากของต้นที่ระดับ n หรือ ∅ หากไม่มีต้นระดับนั้น) และเนื่องจากเก็บเพียงค่า root ของแต่ละต้น ทำให้ในโค้ด accumulator มีเพียงอาร์เรย์ของค่าแฮชและจำนวนใบ (กิ่งก้านสาขา) เท่านั้น ขนาดของตัว accumulator จะโตขึ้นช้ามากเป็นแบบลอการิทึมตามจำนวน UTXO ซึ่งหมายความว่าแม้จำนวน UTXO จะเป็นล้านๆ ต้นก็ใช้พื้นที่จัดเก็บเพียงเล็กน้อย.&#x20;

นอกจากนี้ Utreexo ไม่ต้องการ trusted setup ใด ๆ และรักษาระดับความปลอดภัยแบบเต็มรูปแบบเทียบเท่า full node แบบเดิม

คุณสมบัติสำคัญของตัว accumulator ใน Utreexo ได้แก่:

* การรับรองการเพิ่มและลบ UTXO แบบไดนามิก: สามารถเพิ่ม UTXO ใหม่เข้าไปได้ง่าย และใช้กระบวนการเฉพาะในการลบ UTXO ที่ถูกใช้ไปจาก Merkle forest โดยไม่ต้อง hash ใหม่ทั้งหมด
* ขนาดเล็ก – accumulator มีขนาดเติบโตช้าเป็นสเกลลอการิทึมกับจำนวน UTXO (เช่น ค่า root มีคงที่เพียงไม่กี่ร้อยไบต์ แม้ UTXO เป็นล้านรายการ)
* ไม่ต้องมีการตั้งค่ากลาง (trusted setup) – ใช้ hash อย่าง SHA-256 เพียงอย่างเดียว จึงไม่มีการเสียความปลอดภัยเพิ่มเติม

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

### การย่อขนาด UTXO ด้วย Accumulator

วิธีการย่อขนาด UTXO set ของ Utreexo คือการแทนที่รายการ UTXO ทั้งหมดด้วย *ตัวสะสม* ที่เป็นค่าแฮชขนาดเล็ก และเมื่อมีการใช้จ่าย UTXO โหนดจะรับหลักฐานยืนยันการมีอยู่ของ UTXO นั้นจากผู้ใช้ กล่าวคือ ในบิตคอยน์แบบเดิม เมื่อโหนดยืนยันธุรกรรมใด โหนดจะต้องค้นหา UTXO ทั้งหมดในฐานข้อมูลเพื่อยืนยันว่าผู้ใช้มีเหรียญเหล่านั้นจริง แต่กับ Utreexo ผู้ใช้จะถือหลักฐาน (Merkle proof) ที่พิสูจน์ว่า UTXO ยังอยู่ในตัวสะสม ทุกครั้งที่สร้างธุรกรรม ผู้ใช้จึงแนบหลักฐานนี้ไปพร้อมกับธุรกรรม โหนดอื่น ๆ ที่เก็บแค่ accumulator state สามารถตรวจสอบหลักฐานนี้ได้ว่ารากของต้นใดเป็นสมาชิกกับ root ของตัวสะสมของเครือข่าย จึงไม่ต้องเก็บรายชื่อ UTXO ทั้งหมดไว้ หลังจากตรวจสอบความถูกต้องของหลักฐานแล้ว หลักฐานนั้นอาจถูกทิ้งได้ และโหนดจะ *อัปเดตตัวสะสม* โดยเพิ่ม UTXO ใหม่และลบใบเก่า (UTXO ที่ถูกใช้จ่าย) ออกจาก Merkle forest

กระบวนการนี้ทำให้ข้อมูลของโหนดเล็กลงมาก แต่แลกกับเพิ่ม overhead เล็กน้อยในการส่งข้อมูล หลักฐานการมีอยู่ของ UTXO (inclusion proof) แต่ละรายการมีขนาดเล็ก (โดย Dryja ระบุว่าอยู่ไม่เกิน \~1 KB ต่อ UTXO) [\[3\]](https://www.dci.mit.edu/projects/utreexo#:~:text=Utreexo%20is%20a%20novel%20hash,the%20owner%20of%20those%20funds) แม้จะเพิ่มปริมาณข้อมูลที่ส่งระหว่างโหนดและกระบวนการบันทึกข้อมูลเล็กน้อย (ประมาณ +25% ของข้อมูลที่ต้องดาวน์โหลดทั้งหมดในการซิงค์บล็อกเชน) แต่โดยรวมถือว่ายังเป็นระดับที่จัดการได้สำหรับการลดข้อจำกัดด้านพื้นที่จัดเก็บของโหนดรวมทั้ง Utreexo ยังมีวิธีรวมหลักฐานเพื่อลดขนาดซ้ำซ้อน และใช้การเก็บ *sparse forest* ที่แบ่งเบาข้อมูลการพิสูจน์ด้วย

### ประเภทของโหนดและการซิงค์ข้อมูล

Utreexo แนะนำวิธีจัดโหนดออกเป็นสองประเภทหลัก เพื่อรองรับการทำงานร่วมกันระหว่างโหนดเก่าและโหนดใหม่:

* **โหนดเต็ม (Full Node)** – คือโหนดตามปกติที่เก็บข้อมูลบล็อกเชนทั้งหมด และอาจเก็บ UTXO set หรือ accumulator ได้ สำหรับการสนับสนุน Utreexo อาจแบ่งเป็นโหนดเต็มทั่วไป (regular full node ที่ไม่รู้จัก Utreexo) และ *โหนดสะพาน (Bridge Node)* ที่เป็นโหนดเต็มอีกแบบหนึ่ง โหนดเต็มทั่วไปทำงานเหมือนเดิม ให้รับส่งบล็อกและธุรกรรมโดยไม่มีการเปลี่ยนแปลง ส่วน **โหนดสะพาน** เป็นโหนดเต็มที่เก็บ Merkle forest ของ UTXO ทั้งหมดเอาไว้ด้วย เพื่อสร้างหลักฐานให้กับโหนดกะทัดรัดตามที่ต้องการ โหนดสะพานจะเชื่อมเครือข่ายระหว่างโหนดกะทัดรัดและโหนดเต็มโดยไม่เปลี่ยนโปรโตคอล: โดยเมื่อโหนดเต็มส่งธุรกรรมไปยังโหนดกะทัดรัด จะต้องผ่านโหนดสะพานก่อน โหนดสะพานจะค้นหาว่า UTXO ที่ใช้จ่ายนั้นอยู่ตรงไหนจาก Merkle forest แล้วสร้าง inclusion proof ให้ พร้อมส่งธุรกรรมพร้อมหลักฐานนั้นต่อไปยังโหนดกะทัดรัด (ในทางกลับกัน โหนดกะทัดรัดสามารถส่งธุรกรรมไปโหนดเต็มได้โดยไม่ต้องมีหลักฐาน เพราะโหนดเต็มไม่ต้องตรวจสอบกับ accumulator)
* **โหนดกะทัดรัด (Compact State Node)** – เป็นโหนดที่เก็บเพียงตัวสะสม (accumulator state) และไม่เก็บ UTXO รายการใด ๆ ทำให้ใช้พื้นที่น้อยมาก เนื่องจากไม่เก็บข้อมูล UTXO โหนดกะทัดรัดจึงจำเป็นต้องรับหลักฐานรวม (inclusion proofs) ทุกครั้งที่ตรวจสอบธุรกรรม เมื่อโหนดกะทัดรัดสร้างธุรกรรมใหม่ มันจะแนบหลักฐาน UTXO ที่ถูกใช้จ่ายไปกับธุรกรรมนั้นด้วย จากนั้นจะกระจายธุรกรรมและหลักฐานไปยังโหนดกะทัดรัดอื่น ๆ ต่อไป (ทุกโหนดกะทัดรัดมีข้อมูล accumulator เดียวกันจึงสามารถตรวจสอบหลักฐานได้) เมื่อธุรกรรมถูกยืนยันในบล็อกแล้ว ก็สามารถทิ้งหลักฐานที่ใช้ไปได้ เนื่องจากการอัปเดตตัวสะสมได้ทำขึ้นแล้วและไม่ต้องเก็บไว้ในระยะยาว

### ข้อได้เปรียบของ Utreexo

* **ลดการใช้หน่วยความจำและดิสก์** – ใน Utreexo ตัวสะสมมีขนาดเล็ก เทียบกับฐานข้อมูล UTXO ดั้งเดิม ตามตัวอย่างการทดสอบ อุปกรณ์ Utreexo สามารถบันทึกสถานะ UTXO ได้เป็นคอมมิทเมนต์ขนาดแค่ 32 ไบต์ เทียบกับขนาด UTXO ปัจจุบัน \~12 GB โดยขนาด chainstate ย่อเหลือเพียง \~1/1,000,000 ของโหนดเต็มแบบเดิม หากรันโหนดแบบ prune ร่วมด้วย พื้นที่ดิสก์จะคงที่เล็กน้อยเท่านั้น ซึ่งประหยัดกว่านักโหนดแบบเต็มที่ prune ปกติซึ่ง chainstate อาจขยายจนเกินขนาดฮาร์ดแวร์
* **ซิงค์เร็วและใช้ทรัพยากรต่ำ** – ด้วยข้อมูลสถานะที่เล็กมาก โหนด Utreexo สามารถเปิดตัวและซิงค์กับเครือข่ายได้รวดเร็ว เช่น Luke Champine ระบุว่า “โหนดที่ใช้ Utreexo จะใช้พื้นที่เพียงไม่กี่กิโลไบต์ และสามารถยืนยันบล็อกใหม่จากศูนย์ได้ในไม่ถึงหนึ่งวินาที” [\[5\]](https://lukechampine.com/utreexo-talk.html#:~:text=The%20Utreexo%20accumulator%20is%20a,I%27m%20pretty%20enamored%20with) ตัวสะสมนี้ยังไม่ต้องใช้ I/O ดิสก์มาก ทำให้เหมาะกับอุปกรณ์ประสิทธิภาพต่ำ เช่น เครื่องที่ใช้ microSD (ซึ่งไม่ทำให้ SD card สึกกร่อน)
* **ความปลอดภัยเต็มรูปแบบ (ไม่มี loss-of-security)** – Utreexo เป็นเพียงการเปลี่ยนโครงสร้างจัดเก็บข้อมูล ไม่ได้ลดทอนหลักการความปลอดภัยของ Bitcoin แต่อย่างใด ตัวสะสมเป็นเพียงค่ารวมของ UTXO โดยการเข้ารหัสแฮช ดังนั้นยังต้องผ่านการตรวจสอบแบบ cryptographic เหมือนเดิมและ Utreexo ไม่ต้องการแก้ไขโปรโตคอลของบิตคอยน์ จึงสามารถนำมาใช้กับเครือข่ายปัจจุบันได้ทันทีโดยโหนดแบบเดิมไม่ถูกรบกวน
* **กระจายภาระให้ถูกจุด** – ระบบตระหนักว่าแต่ละผู้ใช้ต้องดูแลหลักฐาน UTXO ของตนเองไว้ (UTXO owners ถือ proof ของตัวเอง ทำให้ภาระไปอยู่ที่เจ้าของเหรียญโดยตรง แทนที่จะกระจายให้ทุกโหนดเต็มต้องเก็บทั้งหมด โหนดขนาดเล็กที่มี UTXO ไม่มากก็ต้องเก็บหลักฐานเพียงเล็กน้อยเท่านั้น, ขณะที่ผู้ให้บริการหรือธุรกรรมจำนวนมากอาจต้องเก็บหลักฐานมากขึ้นตาม

### ข้อจำกัดของ Utreexo

* **เพิ่มภาระแบนด์วิดท์** – การใช้ inclusion proofs เพิ่มปริมาณข้อมูลที่ส่งผ่านเครือข่ายพอสมควร งานวิจัยของ Dryja ระบุว่ามี overhead ประมาณ 25% ในปริมาณข้อมูลที่โหนดต้องดาวน์โหลดเมื่อซิงค์บล็อกเชน  [\[4\]](https://eprint.iacr.org/2019/611.pdf#:~:text=accumulator%20to%20locally%20represent%20the,to%20the%20amount%20otherwise%20downloaded) ในการใช้งานจริง (จากโครงการ Utreexod) พบว่าการดาวน์โหลดบล็อกใช้ข้อมูลประมาณ 1.7 เท่าของปกติและธุรกรรมบางรายการอาจส่งข้อมูลได้สูงสุดถึง 4 เท่า กล่าวคือ เพื่อแลกกับการประหยัดพื้นที่อย่างมาก โหนดต้องรับภาระแบนด์วิดท์เพิ่มขึ้นราวสองเท่าในกรณีแย่ที่สุด
* **ความซับซ้อนเพิ่มเติม** – Utreexo ต้องการให้ผู้ใช้และโหนดเตรียมจัดการกับหลักฐาน (proof) เพิ่มเติม Wallet จะต้องสามารถจัดเก็บและหา proof ของ UTXO ได้, และโหนดต้องแนบ proof เมื่อส่งธุรกรรม แม้โครงสร้างจะคล้ายกับ Merkle tree ธรรมดา แต่ก็เป็นกระบวนการใหม่ที่ต้องพัฒนาและทดสอบ ขณะนี้โค้ด Utreexo ยังอยู่ในสถานะเบต้าและยังไม่ได้รับการตรวจสอบอย่างกว้างขวาง จึงมีความเสี่ยงจากบั๊กหรือการเปลี่ยนแปลงด้านเทคนิค
* **ไม่เข้ากันกับกระเป๋าเงินหรือโครงสร้างปัจจุบันทันที** – แม้ Utreexo จะไม่เปลี่ยน consensus แต่โหนดกะทัดรัดไม่สามารถทำงานกับ node ทั่วไปได้โดยตรง (ต้องผ่านโหนดสะพาน), จึงต้องมีการพัฒนาเพิ่มเติมให้ wallet และซอฟต์แวร์กระจายธุรกรรมรองรับ ปัจจุบันไม่มีแผนรวม Utreexo เข้ากับ Bitcoin Core โดยตรง, แม้ว่านักพัฒนาสามารถทดลองใช้ได้เองก็ตาม
* **ความเสี่ยงการรวมศูนย์ของโหนดสะพาน** – เพื่อให้เครือข่ายทำงานร่วมกันได้จำเป็นต้องมี *โหนดสะพาน* จำนวนหนึ่งมาคอยให้บริการสร้างหลักฐาน เนื่องจากโหนดสะพานต้องเก็บ UTXO set เต็มและ Merkle forest ทั้งหมดพร้อมสร้าง proof จึงใช้พื้นที่มากกว่าปกติ หากโหนดสะพานมีน้อย อาจเกิดภาวะรวมศูนย์ (centralization) หรือความล้าช้าจากการรอหน่วยงานใดหน่วยงานหนึ่งสร้าง proof ให้

### การทดลองใช้งานจริงและสถานะปัจจุบัน

แม้ Utreexo จะยังไม่ถูกนำเข้าใน Bitcoin Core อย่างเป็นทางการ แต่มีโครงการวิจัยและพัฒนาหลายอย่างที่นำ Utreexo ไปใช้จริงแล้ว หนึ่งในนั้นคือ **Utreexod** โดยพัฒนาเป็นซอฟต์แวร์ Bitcoin full node ที่เขียนขึ้นด้วยภาษา Go ที่รองรับ accumulator Utreexod มีคุณสมบัติดังนี้: สามารถ *บูตสตาร์ทโหนดได้ทันที* ด้วยการฝัง state เริ่มต้นของ UTXO ไว้ในโค้ด จึงสามารถข้ามการดาวน์โหลดบล็อกตั้งต้นได้ โหนดนี้ใช้หน่วยความจำน้อยมาก (เพียงหลักสิบหรือร้อย MB เทียบกับหลาย GB ของโหนดปกติ) และมี I/O ดิสก์ต่ำมาก ไม่ทำให้ microSD เสื่อมสภาพง่าย อย่างไรก็ตาม การใช้ Utreexod ต้องแลกกับแบนด์วิดท์ที่สูงขึ้น: การดาวน์โหลดบล็อกใช้ข้อมูลประมาณ 1.7× ของปกติ และบางธุรกรรมอาจต้องใช้ข้อมูลได้ถึง 4× ปัจจุบัน Utreexod ยังอยู่ในสถานะเบต้า (ออกเวอร์ชัน v0.4.1 ในปี 2024) และผู้พัฒนายังแนะนำให้ใช้เฉพาะในเครือข่ายทดสอบหรือกับจำนวน Bitcoin น้อยๆ เท่านั้น

นอกจากนี้ ยังมีความพยายามอื่นๆ ของชุมชนในการใช้งาน Utreexo เช่น โครงการ **ZeroSync** ของ Lightning Labs ซึ่งใช้แนวคิดใกล้เคียงกับ Utreexo เพื่อเร่งการซิงค์บล็อกฯ (แต่เฉพาะในเครือข่าย LN) และไลบรารีต่าง ๆ (เช่น LibFlorestra) สำหรับผสาน Utreexo เข้ากับแอปพลิเคชัน อย่างไรก็ตาม เทคโนโลยี Utreexo ยังอยู่ในช่วงเริ่มต้น สถานะการทดลอง และยังต้องมีการพัฒนาต่อเนื่องก่อนจะมีการนำมาใช้อย่างแพร่หลายใน Bitcoin เครือข่ายหลัก

### อ้างอิง

\[1] <https://bitcoinmagazine.com/technical/bitcoins-growing-utxo-problem-and-how-utreexo-can-help-solve-it>

\[2] <https://bitcoinops.org/en/newsletters/2024/05/15/#release-of-utreexod-beta>

\[3] <https://www.dci.mit.edu/projects/utreexo#:~:text=Utreexo%20is%20a%20novel%20hash,the%20owner%20of%20those%20funds>

\[4] <https://eprint.iacr.org/2019/611.pdf#:~:text=accumulator%20to%20locally%20represent%20the,to%20the%20amount%20otherwise%20downloaded>

\[5] <https://lukechampine.com/utreexo-talk.html#:~:text=The%20Utreexo%20accumulator%20is%20a,I%27m%20pretty%20enamored%20with>