อธิบาย Shielded Pool, Unified Address และ Viewing Key ของ Zcash

ใน Zcash pool ไม่ใช่กระดานแลกเปลี่ยนหรือบริษัทที่รับฝากเงิน แต่เป็นสถานะของมูลค่าที่อยู่ภายใต้กฎฉันทามติบางอย่าง พูลแบบโปร่งใสใช้ UTXO สาธารณะ ผู้อ่านบล็อกเชนสามารถเห็น output ที่สร้างขึ้น ธุรกรรมภายหลังที่ใช้ output นั้น และจำนวนเงินที่แสดง ที่อยู่เพียงอย่างเดียวไม่ได้บอกตัวตนทางกฎหมาย แต่บันทึกสาธารณะอาจแสดงการใช้ที่อยู่และความเชื่อมโยงของกระแสเงิน

Shielded pool ใช้ note แทน UTXO ที่มองเห็นได้ เครือข่ายบันทึกข้อมูล note ที่เข้ารหัส ต้นไม้ commitment และการตรวจสอบยอดคงเหลือของพูล proof ทำให้ฉันทามติตรวจสอบความถูกต้อง การรักษามูลค่า และการป้องกันการใช้จ่ายซ้ำได้ โดยไม่เปิดให้ผู้สังเกตทั่วไปเห็นผู้รับและจำนวน note แบบ output โปร่งใส Zcash Protocol Specification อธิบายการทำงานทั้งสองแบบ

Sapling และ Orchard เป็น shielded pool แยกกัน มี protocol และต้นไม้ commitment ของ note คนละชุด ยอดคงเหลือจึงไม่ใช่สถานะเดียวที่ใช้แทนกันได้ Sprout เป็น shielded protocol รุ่นแรกของ Zcash หลัง ZIP 211 มีผล จะไม่สามารถเพิ่มมูลค่าใหม่เข้า Sprout pool ได้ แม้ธุรกรรม Sprout เก่ายังคงอยู่ในประวัติบล็อกเชน

ควรระบุวันที่ของสถานะเครือข่าย ดัชนี ZIP อย่างเป็นทางการระบุว่า NU6.2 เป็นการอัปเกรด Mainnet ล่าสุดที่เสร็จสมบูรณ์ และเริ่มใช้ที่บล็อก 3,364,600 เมื่อวันที่ 3 มิถุนายน 2026 NU6.2 เปิดใช้ Orchard action อีกครั้งหลังมาตรการลดความเสี่ยงชั่วคราว พร้อมกฎ circuit ที่แก้ไขแล้ว ส่วน NU6.3 และ Ironwood pool ยังเป็นข้อเสนอฉบับร่าง ไม่ใช่กฎ Mainnet ปัจจุบัน ดู ZIP 257, ดัชนี ZIP และ ร่าง ZIP 258

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

เมื่อใช้จ่าย note ธุรกรรมจะเปิดเผย nullifier ที่เกี่ยวข้อง ผู้ใช้จ่ายพิสูจน์ว่าตนรู้ note และเผยแพร่ nullifier เครือข่ายตรวจสอบว่าไม่เคยมีการใช้ nullifier นี้มาก่อน ผู้สังเกตเห็น nullifier และต้นไม้ commitment ได้ แต่ไม่ควรระบุได้ว่า nullifier เชื่อมกับ commitment เก่าใด วิธีนี้ป้องกันการใช้จ่ายซ้ำโดยไม่ต้องซ่อนข้อมูลฉันทามติทั้งหมด Sapling และ Orchard ใช้แนวคิดเดียวกันในระดับกว้าง แต่ใช้การเข้ารหัสและ proof คนละแบบ การใช้จ่ายยังต้องมีสิทธิ์ส่วนตัวที่ตรงกัน

Unified Address (UA) คือสตริงเข้ารหัสรายการเดียวที่อาจมี receiver ของ Orchard, Sapling, P2SH แบบโปร่งใส และ P2PKH แบบโปร่งใส UA Revision 0 ที่ใช้งานอยู่ต้องมี shielded receiver อย่างน้อยหนึ่งรายการ สตริงนี้ตั้งใจทำให้ดูไม่ออกด้วยตาเปล่าว่ามี receiver ประเภทใดอยู่ ZIP 316 แยก Revision 0 ที่ใช้อยู่จาก Revision 2 ที่เสนอไว้

กระเป๋าผู้ส่งไม่ได้จ่ายไปยัง receiver ทุกตัว ใน Revision 0 ลำดับความสำคัญคือ Orchard, Sapling, P2SH แบบโปร่งใส แล้วจึง P2PKH แบบโปร่งใส ผู้ส่งต้องใช้ receiver ที่มีลำดับสูงสุดในบรรดาที่กระเป๋ารองรับ หากรองรับ Orchard ก็เลือก Orchard หากไม่รองรับ Orchard แต่รองรับ Sapling ก็เลือก Sapling ได้ ดังนั้นพูลที่ใช้จริงขึ้นอยู่กับความสามารถของกระเป๋าผู้ส่ง ไม่ใช่แค่สตริงที่อยู่ที่แสดง

ร่าง Revision 2 เสนอ prefix zu สำหรับที่อยู่ shielded เท่านั้น และ tu สำหรับรูปแบบที่อาจมี receiver แบบโปร่งใส ดัชนี ZIP อย่างเป็นทางการยังระบุ Revision 2 ว่าเป็นร่าง อย่านำ prefix เหล่านี้ไปอธิบายว่าเป็นรูปแบบ UA บน Mainnet ที่ใช้กันทั่วไป ก่อนส่งให้ตรวจประเภทที่อยู่ เครือข่าย และ receiver ที่กระเป๋าเลือกในหน้าตรวจสอบ

การโอนจากแบบโปร่งใสไปยัง shielded (t→z) อาจใช้ UTXO สาธารณะและสร้าง note ของ Sapling หรือ Orchard ผู้สังเกตเครือข่ายเห็น input แบบโปร่งใส การเปลี่ยนแปลงในพูลแบบโปร่งใส และมูลค่าสุทธิที่เข้าสู่ shielded pool แต่ไม่เห็นที่อยู่รับ shielded ทั่วไปหรือจำนวน note แต่ละรายการเหมือน UTXO แบบโปร่งใส การนำมูลค่าเข้า shielded pool จึงยังทิ้งข้อมูลที่ขอบเขตพูล

ในการโอนกลับ (z→t) ที่อยู่และจำนวนของ output แบบโปร่งใสเป็นข้อมูลสาธารณะ และอาจสังเกตเห็นการเปลี่ยนแปลงที่สอดคล้องกันของมูลค่าใน shielded pool การชำระเงินที่สร้าง note ภายในพูลเดียวอาจซ่อนผู้รับกับจำนวนเงินได้ แต่การโอนระหว่าง Sapling กับ Orchard อาจทำให้การเปลี่ยนยอดแยกตามพูลมีความหมาย มูลค่าที่ขอบเขตซึ่งเปิดเผยต่อสาธารณะอย่างเดียวไม่ได้ระบุตัวบุคคลหรือ note เก่า แต่สามารถเทียบกับจำนวน เวลา และบันทึกภายนอกได้

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

ZIP 316 นิยาม viewing key ว่าเป็นข้อมูลที่จำเป็นต่อการดูการชำระเงินที่ส่งมายังที่อยู่ Full Viewing Key (FVK) ยังดูข้อมูลการชำระเงินที่ส่งออกจากที่อยู่นั้นได้ Incoming Viewing Key (IVK) สร้างมาจาก FVK ได้ และสามารถสร้างที่อยู่จาก IVK ได้ Unified Viewing Key รวมส่วนของ viewing key จากหลาย protocol

Viewing key เพียงอย่างเดียวไม่สามารถลงนามใช้จ่าย ต้องมี spending key แยกต่างหากหรือระบบลงนาม อย่างไรก็ตาม viewing key ไม่ใช่ข้อมูลสาธารณะที่ไม่มีความเสี่ยง ประเภท key และวิธีทำงานของกระเป๋ากำหนดว่ามองเห็นธุรกรรมใดได้ key ระดับบัญชีอาจเปิดเผยได้มากกว่าที่อยู่รับเพียงรายการเดียว ก่อนแบ่งปันให้ผู้ตรวจสอบบัญชีหรือบริการ ให้ตรวจขอบเขต ระยะเวลาเก็บรักษา วิธีลบ และการรวมกับที่อยู่อื่น

Viewing key ไม่ได้ลบร่องรอยที่เปิดเผยอยู่แล้ว input และ output แบบโปร่งใส จำนวนเงิน และเวลาอาจถูกวิเคราะห์ได้โดยไม่ต้องใช้ key ในทางกลับกัน explorer หรือกระเป๋าที่ไม่รองรับพูลที่เกี่ยวข้องอาจไม่แสดงธุรกรรม shielded ที่เครือข่ายบันทึกแล้ว “แอปไม่แสดง” ไม่ได้หมายความว่า “ไม่มีอยู่บนเชน”

สิ่งที่มองเห็นขึ้นอยู่กับ pool และชนิด receiver เส้นทางที่โปร่งใสทั้งหมดเปิดเผยที่อยู่ จำนวนเงิน และความเชื่อมโยงของ UTXO การชำระเงินแบบ shielded เข้ารหัสผู้รับและมูลค่าของ note แต่ commitment, nullifier, เวลา และข้อมูล protocol ยังปรากฏบนเชน การข้ามขอบเขตพูล พูลที่กระเป๋ารองรับ เวลาชำระเงินที่ทราบ บันทึก exchange และ viewing key ที่แชร์ อาจเป็นเบาะแสแยกกัน

Unified Address ไม่ได้บังคับให้ทุกการชำระเงินใช้ Orchard receiver ที่เลือกอาจขึ้นอยู่กับรุ่นกระเป๋า การตั้งค่า วิธีติดตั้ง และเส้นทางธุรกรรม อย่าสรุปเรื่องความเป็นส่วนตัวจากการวางที่อยู่ลงไปเพียงอย่างเดียว ให้ดูหน้าตรวจสอบหรือผลธุรกรรม [คู่มือความเป็นส่วนตัวของ Monero](/th/learn/monero-private-transactions-stealth-addresses-ring-signatures-ringct-explained) อธิบายการออกแบบคนละแบบ ส่วน [คู่มือการใช้ที่อยู่ Bitcoin ซ้ำ](/th/learn/bitcoin-address-reuse-privacy-transaction-linkability-explained) เปรียบเทียบกับบัญชีแยกประเภทแบบโปร่งใส

ความเป็นส่วนตัวของเครือข่ายเป็นอีกชั้นหนึ่ง ผู้ให้บริการ RPC เซิร์ฟเวอร์ light-wallet exchange หรือบริการชำระเงินอาจเห็นคำขอสร้างหรือส่งต่อธุรกรรม และเก็บ IP บัญชี หรือเวลาไว้นอกเชน proof ทางคริปโตไม่ได้ลบบันทึกของบริการโดยอัตโนมัติ แทนที่จะอ้างระดับการไม่เปิดเผยตัวตนแบบเด็ดขาด ให้ตรวจว่าใครได้รับ metadata และเก็บไว้อย่างไร

ก่อนอื่นยืนยันว่ากระเป๋าเชื่อมต่อกับ Mainnet หรือ Testnet ที่ตั้งใจไว้ ในหน้าตรวจสอบการชำระเงิน ให้ยืนยันว่าผู้รับส่ง Unified Address มา และดูว่ากระเป๋าจะเลือก receiver ใด สตริง UA ไม่แสดงรายการ receiver ด้วยสายตา ให้ตรวจ pool จำนวน memo และค่าธรรมเนียมในกระเป๋า หากผู้รับขอการชำระเงินแบบ shielded แต่หน้าตรวจสอบแสดง output โปร่งใส ให้ตรวจการรองรับ protocol ในกระเป๋าทั้งสองก่อนส่ง

หากตรวจสอบธุรกรรมที่เกิดขึ้นแล้ว ให้เทียบ ID ธุรกรรมและเครือข่าย แล้วดูว่า input และ output อยู่ในพูลใด ที่อยู่และจำนวนแบบโปร่งใสแสดงใน explorer สาธารณะ ส่วนรายละเอียด note อาจไม่แสดงในเครื่องมือที่ไม่รองรับ หากต้องใช้ viewing key ให้กำหนดเหตุผลและข้อมูลที่จะเปิดเผย อย่าวาง spending key หรือ viewing key ลงในเว็บไซต์ที่ไม่รู้จัก คู่มือกระเป๋าแบบ custodial และ non-custodial อธิบายความรับผิดชอบในการลงนามด้วย

อย่าสรุปว่า “ใช้ที่อยู่ shielded แล้วการชำระเงินเป็นส่วนตัวทั้งหมด” หรือ “explorer ไม่แสดงมูลค่า แปลว่าการโอนไม่เกิดขึ้น” ประวัติกระเป๋า เครือข่าย ID ธุรกรรม สถานะเชน จำนวน confirmation และสิทธิ์ดูข้อมูลเป็นข้อเท็จจริงคนละอย่าง หากผู้รับต้องยืนยันว่าได้รับแล้ว ให้ตรวจด้วยว่ากระเป๋าของผู้รับรองรับและซิงค์พูลที่เกี่ยวข้องแล้ว

สมมติว่า Lee ส่ง 1.25 ZEC จาก UTXO แบบโปร่งใสไปยัง Unified Address Revision 0 ที่มี receiver ของ Orchard, Sapling และแบบโปร่งใส จำนวนนี้เป็นเพียงตัวอย่าง ไม่ใช่อัตราค่าธรรมเนียมหรือค่าตั้งต้นของกระเป๋า หากกระเป๋าของ Lee รองรับ Orchard กฎลำดับความสำคัญของ ZIP 316 จะเลือก receiver ของ Orchard เชนสาธารณะแสดง input แบบโปร่งใสและข้อมูลขอบเขต เช่น มูลค่าสุทธิที่เข้าสู่ shielded pool แต่ไม่แสดงที่อยู่รับแบบ shielded และจำนวน note เป็น output สาธารณะทั่วไป

หากกระเป๋าของ Lee ไม่รองรับ Orchard แต่รองรับ Sapling ก็เลือก Sapling ได้ กระเป๋าที่ไม่รองรับ shielded pool ใดเลยอาจใช้ receiver แบบโปร่งใส หากมี receiver และรูปแบบชำระเงินนั้น UA Revision 0 ต้องมี receiver แบบ shielded แต่ผู้ส่งเลือกได้เฉพาะ receiver ที่กระเป๋ารองรับ UA เดียวกันจึงอาจใช้พูลและแสดงข้อมูลขอบเขตสาธารณะต่างกันเมื่อใช้กับกระเป๋าคนละแบบ

สุดท้าย หากผู้รับแบ่งปัน viewing key แยกต่างหากกับบริการบัญชี บริการนั้นอาจเห็นกิจกรรม shielded ในขอบเขตของ key การแสดงการรับเงินในกระเป๋า การที่ explorer ไม่แสดงรายละเอียด note และการที่เชนบันทึกธุรกรรมตามฉันทามติเป็นข้อเท็จจริงสามอย่าง Unified Address ทำให้เข้ากันได้ง่ายขึ้นระหว่าง protocol หลายรุ่น แต่ไม่ได้รับประกันความเป็นส่วนตัวทั้งหมดหรือแทนความรับผิดชอบเรื่องการเลือก receiver การจัดการ key และการเปิดเผยข้อมูลเครือข่าย

• Zcash Protocol Specification v2026.7.0（NU6.2）
• ZIP 316: Unified Addresses and Unified Viewing Keys
• ZIP 211: Disabling New Value to the Sprout Pool
• ZIP 257: NU6.2 and the Orchard Temporary Mitigation
• ZIP 258: Draft NU6.3 Deployment
• ดัชนี ZIP อย่างเป็นทางการ: สถานะ Mainnet และสถานะข้อเสนอ