---
title: "โมเดล UTXO"
description: "ทำความเข้าใจว่า Bitcoin ใช้เอาต์พุตธุรกรรมที่ยังไม่ถูกใช้แทนมูลค่าที่ใช้จ่ายได้ ตรวจสอบการใช้จ่าย สร้างเงินทอน และทำให้ต้องชั่งน้ำหนักการเลือกเหรียญ ค่าธรรมเนียม และความเป็นส่วนตัวอย่างไร"
image: "https://wiki.fcontext.com/og.png"
---

> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.

# โมเดล UTXO

> เนื้อหานี้มีไว้เพื่อการศึกษาเท่านั้น ไม่ใช่คำแนะนำด้านการลงทุน การลงทุนอาจทำให้เกิดการขาดทุนได้

<a id="answer"></a>

## คำตอบโดยตรง

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

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

<a id="mechanism"></a>

## กลไกการทำงาน

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

`fee = sum(inputs) - sum(outputs)`

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

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

ราคาพื้นที่บล็อกของ Bitcoin ขึ้นอยู่กับน้ำหนักธุรกรรมและอัตราค่าธรรมเนียมเป็นหลัก ไม่ใช่จำนวนเงินที่โอน BIP 141 นิยาม `virtual size = ceil(weight / 4)` โดยทั่วไปอินพุตเพิ่มข้อมูลธุรกรรมมากกว่าเอาต์พุต การใช้ UTXO ขนาดเล็กหลายรายการจึงอาจแพงกว่าการใช้ UTXO ขนาดใหญ่หนึ่งรายการที่อัตราเดียวกัน ขนาดที่แน่นอนขึ้นอยู่กับประเภทสคริปต์และ witness ที่ใช้

ธุรกรรมที่ใช้ UTXO ต่างกันมีการพึ่งพาอินพุตแยกกัน จึงอาจตรวจสอบและสร้างแบบขนานได้ง่ายขึ้น แต่ไม่ได้เป็นอิสระต่อกันโดยอัตโนมัติในทุกการใช้งาน: ธุรกรรมสองรายการที่เลือกเอาต์พุตเดียวกันจะขัดแย้งกัน และธุรกรรมลูกขึ้นอยู่กับธุรกรรมแม่ที่ยังไม่ยืนยัน การเลือกเหรียญของกระเป๋าเงินต้องประสานการพึ่งพาเหล่านี้

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

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

<a id="example"></a>

## ตัวอย่างคำนวณ

Alice ควบคุม UTXO มูลค่า `0.08 BTC`, `0.12 BTC` และ `0.50 BTC` เมื่อต้องการจ่าย Bob `0.15 BTC` กระเป๋าเงินจะเลือกสองอินพุตแรก รวมเป็น `0.20 BTC` และประมาณค่าธรรมเนียมไว้ที่ `0.0002 BTC` แล้วสร้างเอาต์พุตดังนี้:

- Bob: `0.15 BTC`
- เงินทอนของ Alice: `0.0498 BTC`

การคำนวณคือ `0.20 - 0.15 - 0.0002 = 0.0498 BTC` เมื่อยืนยันแล้ว เอาต์พุต `0.08 BTC` และ `0.12 BTC` จะถูกใช้ ส่วนเอาต์พุตของ Bob และเงินทอนของ Alice จะเป็น UTXO ใหม่ ขณะที่เอาต์พุต `0.50 BTC` ยังคงเดิม

หากธุรกรรมสร้างเฉพาะเอาต์พุตของ Bob ที่ `0.15 BTC` ส่วน `0.05 BTC` ที่ไม่ได้ระบุจะกลายเป็นค่าธรรมเนียม ไม่ใช่เงินคืนอัตโนมัติ กระเป๋าเงินอาจเลือกชุดอินพุตอื่น รวมการชำระหลายรายการ หรือรวมเอาต์พุตขนาดเล็กเมื่ออัตราค่าธรรมเนียมต่ำลง ทางเลือกเหล่านี้ต้องชั่งน้ำหนักค่าธรรมเนียมปัจจุบันและอนาคต ความน่าเชื่อถือของการยืนยัน และความเป็นส่วนตัว

<a id="risks"></a>

## ความเสี่ยงและการควบคุม

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

<a id="misconceptions"></a>

## ความเข้าใจผิดที่พบบ่อย

### แอดเดรสคือบัญชีถาวร

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

### ค่าธรรมเนียมแปรตามจำนวนเงินที่จ่าย

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

### โปรโตคอลสร้างเงินทอนอัตโนมัติ

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

### ยังไม่ยืนยันหมายถึงชำระแล้ว

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

<a id="related"></a>

## หัวข้อที่เกี่ยวข้อง

- [โมเดลแบบบัญชี](/th/crypto/account-based-model/)
- [Bitcoin](/th/crypto/bitcoin/)
- [การยืนยันบล็อก](/th/crypto/block-confirmation/)
- [Mempool](/th/crypto/mempool/)
- [การโจมตีแบบ Dust](/th/crypto/dust-attack/)

<a id="sources"></a>

## แหล่งข้อมูล

- [Bitcoin: A Peer-to-Peer Electronic Cash System](https://bitcoincore.org/bitcoin.pdf) - Satoshi Nakamoto (เข้าถึงเมื่อ: 2026-08-22)
- [Transactions — Bitcoin Developer Guide](https://developer.bitcoin.org/devguide/transactions.html) - Bitcoin.org (เข้าถึงเมื่อ: 2026-08-22)
- [Block Chain — Bitcoin Developer Guide](https://developer.bitcoin.org/devguide/block_chain.html) - Bitcoin.org (เข้าถึงเมื่อ: 2026-08-22)
- [BIP 141: Segregated Witness (Consensus layer)](https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki) - Bitcoin Improvement Proposals (เข้าถึงเมื่อ: 2026-08-22)
- [BIP 125: Opt-in Full Replace-by-Fee Signaling](https://github.com/bitcoin/bips/blob/master/bip-0125.mediawiki) - Bitcoin Improvement Proposals (เข้าถึงเมื่อ: 2026-08-22)

Source: https://wiki.fcontext.com/th/crypto/utxo-model/index.mdx