# BEYUL Whitepaper — Pre-Testnet Edition: สถาปัตยกรรมและแบบจำลองการเปิดเผย

> **นี่คือฉบับแปล เวอร์ชันภาษาอังกฤษเป็นฉบับมาตรฐาน (canonical) เพียงฉบับเดียว และมีผลเหนือกว่าเมื่อมีข้อขัดแย้ง** ตัวระบุทางเทคนิค (BEYUL, BYL, `privacychain`, TDC, ADC, nullifier, commitment, viewing key, shielded pool, Groth16 ฯลฯ) คงไว้เป็นภาษาอังกฤษ ไม่แปล ฉบับแปลนี้สร้างโดยเครื่อง แนะนำให้ตรวจทานโดยเจ้าของภาษาก่อนเผยแพร่ (machine-translated; native review recommended).

**โครงการ:** BEYUL　**ประเภท:** ต้นแบบงานวิจัยของพับลิกเชนเชิงความเป็นส่วนตัว (pre-testnet) งานโปรโตคอล BEYUL ปัจจุบันพัฒนาอยู่ในรีโพ `privacychain`
**สถานะเอกสาร:** whitepaper ของ BEYUL, **ฉบับ pre-testnet (งานวิจัย)** — อธิบายสถาปัตยกรรมโปรโตคอล แบบจำลองการเปิดเผย และขอบเขตปัจจุบันก่อนเทสต์เน็ตสาธารณะ เอกสารนี้**ไม่ใช่**ข้อกำหนดโปรโตคอลระดับโปรดักชัน ไม่ใช่เอกสารการลงทุน ไม่ใช่ความเห็นด้านการปฏิบัติตามกฎ ไม่ใช่การตรวจสอบความปลอดภัย ไม่ใช่เอกสารออกโทเคน และไม่ใช่ประกาศเมนเน็ต ข้อกล่าวอ้างเรื่องความสามารถเป็นไปตามวินัยหลักฐานในข้อ §3.1 ไม่มีสิ่งใดในที่นี้ถูกอธิบายเกินระดับความพร้อมที่แท้จริงของมัน
**สถานะโทเคน:** tokenomics ยังไม่สรุป **BYL** เป็นเพียงรูปย่อ / ติ๊กเกอร์ของโครงการ มัน**ไม่ใช่** denomination ที่ถูกตรึงไว้ — denomination และพารามิเตอร์เชนยังรอการอนุมัติอย่างชัดเจนจาก Owner เอกสารนี้ไม่ได้กำหนดการจัดสรรโทเคนหรือการออกแบบยูทิลิตี โทเคนเทสต์เน็ต หากมีการใช้ ไม่มีมูลค่าทางการเงินและไม่มีคำสัญญาว่าจะแปลงเป็นเมนเน็ต
**ภาษามาตรฐาน:** เวอร์ชันภาษาอังกฤษเป็นฉบับมาตรฐานเพียงฉบับเดียว เวอร์ชันภาษาจีน (`beyul-whitepaper-pretestnet.zh.md`) เป็นข้อความทำงานประกอบ เมื่อมีข้อขัดแย้ง เวอร์ชันภาษาอังกฤษมีผลเหนือกว่า

---

## กรอบขอบเขตข้อกล่าวอ้าง (โปรดอ่านก่อน)

เอกสารนี้**ไม่**กล่าวอ้างสิ่งใดต่อไปนี้:

- ไม่กล่าวอ้างเรื่องการไม่เปิดเผยตัวตน การตามรอยไม่ได้ หรือ "ความปลอดภัยสัมบูรณ์";
- ไม่กล่าวอ้างเรื่องความปลอดภัย zero-knowledge ระดับโปรดักชัน (การพัฒนาปัจจุบันใช้วัสดุ development-key);
- ไม่กล่าวอ้างเรื่องความเป็นส่วนตัวระดับโปรดักชัน (ยอดฝากและถอนปัจจุบันเปิดเผยบนเชน);
- ไม่กล่าวอ้างเรื่องการอนุมัติจากหน่วยงานกำกับหรือ "compliance by design";
- การออกแบบปัจจุบันไม่รวม viewing key ระดับโกลบอลที่โครงการควบคุม คุณสมบัตินี้ต้องได้รับการตรวจสอบผ่านการพัฒนาแบบเปิด การทดสอบ และการตรวจสอบภายนอก;
- ไม่มีทั้งเทสต์เน็ตสาธารณะและเมนเน็ต; **ความพร้อมของเทสต์เน็ตกำลังดำเนินอยู่ — runbook แบบหลายโหนดและ gate ที่เกี่ยวข้องยังไม่เสร็จสมบูรณ์**;
- ไม่มีคำสัญญาเรื่องมูลค่าโทเคน airdrop ผลตอบแทน กำไร หรือการลิสต์บนกระดานเทรด; เอกสารนี้ไม่กล่าวถึงผลิตภัณฑ์วอลเล็ตหรือ DeFi;
- 16-character disclosure code ไม่ใช่หลักฐานยืนยันความปลอดภัยทางการเข้ารหัสพื้นฐาน (หมวด 7)

**การตั้งชื่อและตัวระบุทางเทคนิค** BEYUL เป็นชื่อโครงการ/ผลิตภัณฑ์; งานโปรโตคอล BEYUL ปัจจุบันพัฒนาอยู่ในรีโพ `privacychain` `privacychain` ยังคงเป็นตัวระบุทางเทคนิคปัจจุบัน — รีโพ, แพ็กเกจโปรโตคอล/โมดูล/proto, ไบนารี และ chain-id — และคงไว้โดยไม่เปลี่ยนแปลง **BYL** เป็นรูปย่อ / ติ๊กเกอร์; denomination และพารามิเตอร์เชนยังรอการอนุมัติอย่างชัดเจนจาก Owner ดังนั้น BYL จึงไม่ใช่ denomination ที่ถูกตรึงไว้ วินัยการตั้งชื่อนี้ใช้เฉพาะไปข้างหน้า: เอกสารในอดีตไม่ถูกเปลี่ยนชื่อย้อนหลัง

---

## 1. บทคัดย่อ

BEYUL เป็นโครงการพับลิกเชนเชิงความเป็นส่วนตัวใน**ขั้นต้นแบบงานวิจัย (pre-testnet)** ที่สำรวจโครงสร้างพื้นฐานการชำระเงินด้วย**ความเป็นส่วนตัวโดยค่าเริ่มต้น (เป้าหมายการออกแบบ)** และการเปิดเผยที่ผู้ใช้ควบคุม ในการออกแบบเป้าหมาย รายละเอียดธุรกรรมโดยค่าเริ่มต้นจะไม่เปิดเผยต่อสาธารณะ แต่เจ้าของสินทรัพย์สามารถเปิดเผยด้วยความสมัครใจ ในขอบเขตจำกัด ต่อฝ่ายที่เลือก — Transaction Disclosure Code (TDC) อธิบายธุรกรรมเดียว; Asset Disclosure Code (ADC) เปิดเผยสแนปช็อตสินทรัพย์ที่เลือก "ความเป็นส่วนตัวโดยค่าเริ่มต้น" อธิบายเป้าหมายการออกแบบ ไม่ใช่ต้นแบบปัจจุบัน (ดู §5)

**สิ่งที่มีอยู่ในวันนี้เป็นเพียงต้นแบบการสืบทอด disclosure-code ฝั่งไคลเอนต์** (ทดสอบในเครื่องแล้ว; แพ็กเกจหลักฐานสาธารณะรอการรวบรวม) และต้นแบบ chain-application บนพื้นฐาน Cosmos SDK ส่วน grant ฝั่งเซิร์ฟเวอร์แบบ end-to-end, การตรวจสอบบนเชน และ ZK balance proof ยังไม่ได้พัฒนา; ไม่มี trusted setup ไม่มีการตรวจสอบภายนอก ไม่มีเทสต์เน็ตสาธารณะหรือเมนเน็ต; ยอดฝากและถอนปัจจุบันเปิดเผยบนเชน วัตถุประสงค์ของ whitepaper นี้ (ฉบับ pre-testnet) คือบันทึกทิศทางสถาปัตยกรรม แบบจำลองการเปิดเผย และขอบเขตปัจจุบันอย่างแม่นยำก่อนเปิดเทสต์เน็ตสาธารณะ — และจะถูกแทนที่ด้วยฉบับโปรดักชันเฉพาะเมื่อมีหลักฐานและการตรวจสอบที่สอดคล้องกันเท่านั้น

## 2. การวางตำแหน่งและปัญหา

บัญชีแยกประเภทสาธารณะเปิดเผยความสัมพันธ์การชำระเงิน ยอดคงเหลือ และกระแสเงินต่อผู้สังเกตการณ์ใด ๆ; ในขณะเดียวกัน ระบบความเป็นส่วนตัวเข้มข้นส่วนใหญ่ทำให้การเปิดเผยแบบ*เลือกเฉพาะ*ทำได้ยากในเชิงปฏิบัติ — การอธิบายธุรกรรมหนึ่งต่อฝ่ายหนึ่งมักหมายถึงการมอบความสามารถในการมองเห็นทุกอย่าง ช่องว่างที่ BEYUL สำรวจคือ: ทำให้ "การเปิดเผย" เป็น primitive ระดับชั้นหนึ่งเทียบเท่ากับ "การซ่อน" โดยการเปิดเผยทั้งหมดเริ่มต้นจากผู้ใช้

BEYUL ไม่แข่งขัน — และไม่มุ่งหวัง — เรื่องเล่า "ไม่เปิดเผยตัวตนอย่างสมบูรณ์ ตามรอยไม่ได้"

**วิสัยทัศน์** ความเป็นส่วนตัวทางการเงินบนบัญชีแยกประเภทสาธารณะนั้นกลับหัวกลับหาง: เปลือยเปล่าโดยค่าเริ่มต้น ในขณะที่การปกปิดเองกลับดูน่าสงสัย เป้าหมายของ BEYUL คือพลิกค่าเริ่มต้นนั้น — ความเป็นส่วนตัวเป็นสถานะเริ่มต้น และการเปิดเผยเป็นทางเลือกที่ผู้ใช้ตั้งใจและละเอียด: ธุรกรรมใด ฟิลด์ใด ให้ใคร และนานเท่าใด

**หลักการออกแบบ** ทุกส่วนของโปรโตคอลอยู่ภายใต้หลักการเหล่านี้:

1. **การเปิดเผยเป็นพลเมืองชั้นหนึ่ง** — primitive การเปิดเผยถูกออกแบบและทำต้นแบบในระดับเดียวกับ primitive การซ่อน
2. **สิทธิ์น้อยที่สุด** — แต่ละคีย์และหลักฐานยืนยันถือสิทธิ์น้อยที่สุดที่จุดประสงค์ของมันต้องการเท่านั้น
3. **spend authority เป็นสิ่งศักดิ์สิทธิ์** — ไม่มีกระบวนการเปิดเผยใดสัมผัส spend authority ได้; mnemonic ไม่เข้าสู่ขั้นตอนการเปิดเผยใด ๆ
4. **ไม่มีสิทธิพิเศษระดับโกลบอล** — โปรโตคอลถูก**ออกแบบให้ไม่จัดให้มี**ช่องทางการดูระดับโกลบอลใด ๆ แก่โครงการหรือบุคคลที่สาม; การที่ไม่มีสาขาเช่นนั้นเป็น**คุณสมบัติการออกแบบที่ต้องได้รับการตรวจสอบผ่านการพัฒนาแบบเปิด การทดสอบ และการตรวจสอบภายนอก (§6)** ยังไม่ใช่การรับประกัน
5. **ความซื่อตรงเรื่องขอบเขต** — แต่ละความสามารถประกาศสิ่งที่มันไม่ทำ; แบบจำลองภัยคุกคามและข้อจำกัดถูกเปิดเผยสู่สาธารณะ
6. **หลักฐานมาก่อน** — ข้อกล่าวอ้างเรื่องความสามารถจะยกระดับหลังจากมีหลักฐาน (โค้ด การทดสอบ การตรวจสอบ) เท่านั้น — อิงตาม gate ไม่มีคำสัญญาเรื่องวันที่

### 2.1 การเปรียบเทียบการเปิดเผยของ BEYUL

> ตารางเปรียบเทียบ**การออกแบบเป้าหมาย**ของ BEYUL กับ**ความสามารถที่ส่งมอบแล้วในปัจจุบัน**ของระบบอื่น จุดสร้างความแตกต่างของ BEYUL ด้านล่าง (การหมดอายุ การเพิกถอน การมองเห็นที่บังคับโดยฉันทามติ ขอบเขตแบบต่อธุรกรรม/ต่อสแนปช็อตพร้อมการตรวจสอบฝั่งเซิร์ฟเวอร์และบนเชน) ส่วนใหญ่**อยู่ระหว่างการวางแผนหรือเป็นต้นแบบฝั่งไคลเอนต์** (ดู §3, §7) ยังไม่ได้ส่งมอบ ข้อเท็จจริงเกี่ยวกับคู่แข่งระบุอย่างระมัดระวัง; รายการที่ยังไม่ได้ตรวจสอบซ้ำอย่างอิสระสำหรับ whitepaper นี้ทำเครื่องหมาย **【to verify】**

| ระบบ | กลไกการเปิดเผย | ความละเอียด | หมดอายุ/เพิกถอนได้ | การมองเห็นบังคับโดย |
|---|---|---|---|---|
| Zcash (Sapling/Orchard) | Full viewing key (FVK/IVK) | ระดับบัญชี ทั้งหมดหรือไม่มีเลย | ไม่ | การมองเห็นขาออกขึ้นกับข้อตกลงของวอลเล็ต (ciphertext ที่เข้ารหัสด้วย ovk) ไม่ใช่ฉันทามติ |
| Monero | View key | ระดับบัญชี (ขาเข้า) | ไม่ | วอลเล็ต / โปรโตคอล; ไม่มี primitive จำกัดต่อธุรกรรม |
| มิกเซอร์แบบ Tornado | ไม่มีในตัว (เครื่องมือภายนอก เช่น association/exclusion proofs) | — | — | — |
| Penumbra | viewing keys แบบเป็นชั้น (FVK/IVK/OVK) + detection key ต่อที่อยู่ (FMD / S-FMD) | viewing keys ระดับบัญชี; detection key = **การค้นพบฝั่งผู้รับ** (เชื่อมโยงเท่านั้น ไม่มีเนื้อหา) มอบหมายได้ต่อที่อยู่ | ไม่ระบุในเอกสาร【to verify】 | การมอบหมายคีย์เข้ารหัส (ไคลเอนต์/วอลเล็ต) ไม่ใช่ฉันทามติ |
| Aztec | viewing keys ขาเข้า/ขาออก + **master**; **note discovery แบบ tagging** (ไม่ใช่ FMD); ล็อกเข้ารหัส | master viewing key **ทั้งหมดหรือไม่มีเลยข้ามทุกคอนแทรกต์**; การเปิดเผยแบบจำกัด/ชั่วคราวทำได้เฉพาะที่ชั้นแอป (Noir) ไม่ใช่ native ของโปรโตคอล | เป็นเพียง "temporary view access" ที่ชั้นแอป ไม่ใช่ native【to verify】 | ตรรกะแอป/คอนแทรกต์ + ไคลเอนต์ (PXE) ไม่ใช่ฉันทามติพื้นฐาน |
| Namada (MASP) | Shielded viewing key (zvknam), หลายสินทรัพย์สายพันธุ์ Sapling | **ระดับบัญชี** (ยอดและประวัติขาเข้า+ขาออกของ shielded account หนึ่ง); "การเปิดเผยแบบเลือกเฉพาะ" = แชร์ viewing key (ทั้งบัญชี) ไม่ใช่ต่อธุรกรรม | viewing key ที่แชร์แล้วเพิกถอนแบบ native ไม่ได้ (ความหมายที่แม่นยำ【to verify】) | Viewing key (วอลเล็ต/ไคลเอนต์) |
| **BEYUL (การออกแบบเป้าหมาย)** | **TDC** (ต่อธุรกรรม) + **ADC** (ต่อสแนปช็อตสินทรัพย์) **แบ่งระดับ** (ADC L1/L2) | ต่อธุรกรรม / ต่อสแนปช็อต; ฟิลด์ที่จำกัดขอบเขต; แยกบทบาทผู้ส่ง/ผู้รับ | **หมดอายุ + เพิกถอน (อยู่ในแผน)** | **ขอบเขตการมองเห็นที่บังคับโดยฉันทามติ (ข้อกำหนดการออกแบบ §6); สองปัจจัย + อ่านอย่างเดียว** |

จุดสร้างความแตกต่างที่ตั้งใจไม่ใช่ "การซ่อนที่แข็งแกร่งกว่า" แต่เป็น**การเปิดเผยที่ละเอียดกว่า มีกำหนดเวลา และผู้ใช้เป็นผู้ออก**: ในขณะที่ viewing key ของ Zcash/Monero เป็นสิทธิ์อ่านระดับบัญชี ทั้งหมดหรือไม่มีเลย และไม่มีกำหนด หลักฐานการเปิดเผยของ BEYUL ถูกจำกัดขอบเขตไว้ที่ธุรกรรมเดียว (TDC) หรือสแนปช็อตสินทรัพย์เดียว (ADC) มีการหมดอายุ และถูกออกแบบให้เพิกถอนได้ — โดยชุดฟิลด์ที่มองเห็นถูกบังคับโดยฉันทามติแทนที่จะเป็นข้อตกลงของวอลเล็ต คุณสมบัติเหล่านี้เป็นเป้าหมายการออกแบบ; สถานะการพัฒนาถูกติดตามอย่างซื่อตรงใน §3 และ §7

> **แหล่งที่มา** Zcash/Monero: รายงานการวิจัยเชิงลึก ZEC/XMR ของโครงการนี้ (แหล่งปฐมภูมิ — Zcash Protocol Specification; เอกสาร Monero; ณ 2026-06-12) แถว Penumbra / Aztec / Namada อธิบาย**เอกสารทางการของแต่ละโครงการ ณ 2026-06** (Penumbra: protocol.penumbra.zone — viewing keys, FMD; Aztec: docs.aztec.network — keys, note discovery; Namada: docs.namada.net — shielded accounts) รายการ 【to verify】 ที่เหลือ — การหมดอายุ/เพิกถอนและความหมาย transaction-perspective ของ Penumbra, การหมดอายุ/เพิกถอนแบบ native ของ Aztec, ความหมายการเพิกถอนที่แม่นยำของ Namada — รอการยืนยัน แถวเหล่านี้ระบุสิ่งที่เอกสารของแต่ละโครงการอธิบาย ไม่ใช่ข้อกล่าวอ้างว่าระบบอื่น "ทำไม่ได้"

## 3. สถานะปัจจุบัน

| ด้าน | สถานะ | หมายเหตุ |
|---|---|---|
| Chain-application | ต้นแบบ | Cosmos SDK / Ignite |
| แบบจำลองฉันทามติ / validator | การออกแบบเทสต์เน็ต | CometBFT BFT + ชุด validator เริ่มต้นแบบ PoS และโมดูล staking; ไม่ใช่ PoW; ไม่ใช่ความปลอดภัยเชิงเศรษฐกิจ PoS ระดับเมนเน็ต |
| Shielded module | ต้นแบบ | ฝาก ถอน spend ลงทะเบียน viewing-key เปิดเผย note |
| Commitments / Merkle tree / nullifiers | ต้นแบบ | พฤติกรรมเชิงกำหนดและการปฏิเสธ double-spend มีการทดสอบครอบคลุม |
| สแต็กคีย์ไคลเอนต์ disclosure-code (สืบทอด TDC/ADC) | ต้นแบบ ทดสอบในเครื่องแล้ว | **แพ็กเกจหลักฐานสาธารณะ (commit/CI) รอการรวบรวม** |
| สแต็ก grant เซิร์ฟเวอร์ / ตรวจสอบการเปิดเผยบนเชน / ZK balance proof | ยังไม่พัฒนา | อยู่ในแผน |
| แยก view-key ขาเข้า/ขาออก / audit key / การหมดอายุและเพิกถอนการเปิดเผย | ยังไม่พัฒนา | อยู่ในแผน |
| Trusted setup / การตรวจสอบภายนอก | ยังไม่เสร็จ / ยังไม่เริ่ม | เงื่อนไขเบื้องต้นของข้อกล่าวอ้างโปรดักชันใด ๆ |
| เทสต์เน็ตสาธารณะ / เมนเน็ต | ยังไม่ deploy | **ความพร้อมเทสต์เน็ตกำลังดำเนินอยู่: runbook หลายโหนดและ gate ที่เกี่ยวข้องยังไม่เสร็จ** |
| วอลเล็ตทางการ | ไม่มีอยู่ | มีเพียงเครื่องมือพัฒนาและทดสอบ; "วอลเล็ตทางการ" ใด ๆ คือของปลอม |
| เศรษฐศาสตร์โทเคน | ยังไม่สรุป | เอกสารนี้ไม่มีการออกแบบโทเคน |

### 3.1 ห่วงโซ่หลักฐาน

แต่ละแถว "ต้นแบบพัฒนาแล้ว" ข้างต้นผูกกับบันทึกหลักฐาน — ไม่ใช่กล่าวอ้างด้วยร้อยแก้ว ห่วงโซ่หลักฐาน (commit hash, บันทึก CI, คำสั่งทดสอบและเอาต์พุตที่แม่นยำ, คำแนะนำการรันที่ทำซ้ำได้) ถูกเก็บไว้ใน **Evidence Appendix** และแต่ละความสามารถถูกจัดระดับบนสเกลความพร้อมเชิงวิจัย **L0–L5** (ออกแบบ → ต้นแบบ → ทำซ้ำได้ → ผ่านการทบทวน → หลักฐานเครือข่าย → โปรดักชัน) whitepaper นี้อ้างอิงทะเบียนนั้นแทนที่จะกล่าวซ้ำหลักฐานดิบ

| ความสามารถ | ระดับความพร้อม | การผูกหลักฐาน |
|---|---|---|
| แกนไคลเอนต์ disclosure-code (สืบทอด TDC/ADC, สองปัจจัย, แยกโดเมน, AEAD/AAD, erasure keys, เวกเตอร์) | L1–L2 | ทำซ้ำแบบอ่านอย่างเดียว 2026-06-19: ทดสอบในเครื่องผ่าน **13/13**; commit บันทึกใน Evidence Appendix E1; CI **【to be supplied】** |
| Shielded module (commitment/nullifier/Merkle, ปฏิเสธ double-spend) | L1 | ทำซ้ำแบบอ่านอย่างเดียว 2026-06-19: ทดสอบ double-spend และ nullifier ผ่าน; Evidence Appendix E3; CI **【to be supplied】** |
| เส้นทาง spend แบบ Groth16 | L1 (dev-key) | dev/skeleton VK, ไม่มี trusted setup; ทดสอบ dev-path + production-VK-guard ทำซ้ำเมื่อ 2026-06-19; Evidence Appendix E4 |
| สแต็ก grant เซิร์ฟเวอร์ / ตรวจสอบบนเชน / ZK balance proof | L0 (อยู่ในแผน) | ยังไม่พัฒนา; ดู Roadmap §10 |

> การประเมินตนเองปัจจุบัน: วัสดุส่วนใหญ่อยู่ระดับ **L1–L2** ไม่มีสิ่งใดอยู่ที่ L5 จนกว่ารายการ Evidence Appendix จะถูกเติม (commit/CI) สื่อสาธารณะจะกล่าวว่า "ตรวจสอบในเครื่องแล้ว; แพ็กเกจหลักฐานสาธารณะรอการรวบรวม" ไม่ใช่ "พัฒนาแล้วพร้อมหลักฐานสาธารณะ" ความสามารถที่ไม่มีบันทึกหลักฐานที่ลงทะเบียนไม่สามารถอธิบายเกินระดับความพร้อมของมัน Evidence Appendix อยู่ที่ `docs/evidence-appendix.md` (ภายใน; จะเผยแพร่พร้อมแพ็กเกจหลักฐานสาธารณะ); E1/E3/E4 ถูกทำซ้ำแบบอ่านอย่างเดียวเมื่อ 2026-06-19 การผูก CI ยังรอดำเนินการ

## 4. แบบจำลองทางเทคนิค

ต้นแบบมีศูนย์กลางอยู่ที่ state machine ของ shielded-pool สำหรับผู้ที่ไม่ใช่นักเข้ารหัส วงจรชีวิตของยอดคงเหลือส่วนตัวดำเนินดังนี้:

1. **Note** ยอดที่ใช้จ่ายได้คือ *note* — บันทึกของ (เจ้าของ จำนวนเงิน ความสุ่ม) ตัว note เองไม่เคยปรากฏบนเชน
2. **Commitment** เชนเก็บเพียง *commitment* ต่อ note (แฮชผูกมัดทางเดียว) ที่ต่อท้ายลงใน **Merkle commitment tree** แบบเพิ่มอย่างเดียว จาก commitment เพียงอย่างเดียว ผู้สังเกตไม่ทราบทั้งเจ้าของและจำนวนเงิน
3. **Spend → nullifier** ในการใช้ note เจ้าของเผยแพร่ *nullifier* ที่สืบทอดจากมัน ผู้สังเกตภายนอกเชื่อมโยง nullifier กับ commitment ไม่ได้ แต่มันเป็นเชิงกำหนดสำหรับ note นั้น — ดังนั้น note เดียวกันถูกทำให้เป็นโมฆะได้เพียงครั้งเดียว
4. **การปฏิเสธ double-spend** เชนรักษาเซ็ตของ nullifier; nullifier ที่ซ้ำถูกปฏิเสธ สิ่งนี้ป้องกัน double-spend **โดยไม่เปิดเผยว่า note ใดถูกใช้**
5. **หลักฐานความถูกต้อง** แต่ละ spend มาพร้อมหลักฐาน zero-knowledge ว่า "ฉันเป็นเจ้าของ note ที่มี commitment อยู่ในต้นไม้ และฉันสืบทอด nullifier ของมันถูกต้อง" โดยไม่เปิดเผยค่าใด ๆ เหล่านั้น การตรวจสอบผ่านเส้นทาง Groth16

**ตัวตรวจสอบปัจจุบันใช้วัสดุ verifying-key แบบ development/skeleton โดยไม่มี trusted setup และไม่สถาปนา soundness หรือความเป็นส่วนตัวระดับโปรดักชัน** ถ้อยคำมาตรฐานสำหรับภายนอก: "ต้นแบบรวมเส้นทางตรวจสอบ Groth16 แบบ development-key ยังไม่ให้ความปลอดภัย zero-knowledge ระดับโปรดักชัน" สำหรับนิยามรูปนัยของรูปแบบ note, สคีม commitment, การสืบทอด nullifier และความหมายของต้นไม้ ดู yellow paper §§5–7 และ §10

### 4.1 ทำไมต้องเชนอิสระ และทำไมต้อง Cosmos

แบบจำลองการเปิดเผยต้องการการควบคุมสิ่งต่าง ๆ ที่การ deploy สมาร์ตคอนแทรกต์บน L1 ที่แชร์กัน หรือ rollup ทั่วไป ไม่ให้มาอย่างสะอาด:

- **การมองเห็นการเปิดเผยที่บังคับโดยฉันทามติ** (§6) และ **กฎความสมบูรณ์ของอุปทาน** ของ shielded pool ต้องอยู่ที่ชั้นการเปลี่ยนสถานะ/ฉันทามติ ไม่ใช่ภายในคอนแทรกต์ที่ validator ของเชนโฮสต์และตลาดค่าธรรมเนียมอยู่นอกการควบคุมของโครงการ
- **สถานะ shielded แบบ native** (commitment tree, เซ็ต nullifier, การบัญชี value-balance) ถูกกว่าและตรวจสอบได้ง่ายกว่าเมื่อเป็นสถานะเชนชั้นหนึ่ง มากกว่าการเป็นที่เก็บคอนแทรกต์ และหลีกเลี่ยงการที่ mempool สาธารณะและแบบจำลองเมทาดาทาของเชนโฮสต์รั่วไหลมากกว่าที่ตั้งใจ
- **ชุด validator แบบ bonded-PoS** ทำให้ความสมบูรณ์ของอุปทานถูกคำนวณซ้ำได้โดยทุก full node และให้ finality ทันทีที่เหมาะกับการชำระเงิน

**Cosmos SDK + CometBFT** ถูกเลือกเพราะสแต็ก BFT-PoS ที่เติบโตเต็มที่พร้อมโมดูล staking/slashing การกำกับการอัปเกรดแบบอธิปไตย และ finality ทันที — ไม่ใช่การรับรองแบบจำลองโทเคนใด ๆ (ไม่มีแบบจำลองใดถูกสรุป) นี่คือเหตุผลการเลือกสถาปัตยกรรม ไม่ใช่ข้อกล่าวอ้างว่าเชนอิสระถูก deploy แล้ว; สถานะจริงดู §3 และ §8

### 4.2 ลักษณะเฉพาะด้านประสิทธิภาพ

ตัวเลขสองชนิดถูกแยกออกจากกัน **โดยธรรมชาติ (ระดับสคีม อ้างอิงได้):** Groth16 บนเส้นโค้ง BN254 มี**หลักฐานขนาดคงที่** (สามองค์ประกอบกลุ่ม — ราวไม่กี่ร้อยไบต์บน BN254) และ**การตรวจสอบเวลาคงที่** (จำนวนการตรวจ pairing คงที่และน้อย ไม่ขึ้นกับขนาดวงจร) สิ่งเหล่านี้เป็นผลจากระบบพิสูจน์เอง ไม่ใช่จากการพัฒนาของ BEYUL **ระดับระบบ (ยังไม่ได้วัด):** เวลาในการพิสูจน์ ปริมาณงานธุรกรรม (TPS) และขนาดวงจร (จำนวนข้อจำกัด) ขึ้นกับวงจรโปรดักชัน ซึ่งวงจรโปรดักชัน**ยังไม่ถูกสร้าง** — เส้นทางปัจจุบันใช้ verifying key แบบ dev/skeleton (§4) ดังนั้นตัวเลขเช่นนั้นใด ๆ จึงเป็น **target / 【to be supplied】** ที่จะถูก benchmark เมื่อมีวงจรโปรดักชันและเส้นทาง trusted-setup-หรือ-การพิสูจน์แบบโปร่งใส (Roadmap §10, Phase 6) เหนือเส้นนี้ไม่มีการกล่าวอ้างตัวเลขประสิทธิภาพระดับระบบใด ๆ

## 5. แบบจำลองความเป็นส่วนตัวและข้อจำกัดปัจจุบัน

| มิติ | แบบจำลองเป้าหมาย | ต้นแบบปัจจุบัน |
|---|---|---|
| จำนวนเงินในพูลและการเชื่อมโยงผู้ส่ง/ผู้รับ | ซ่อน | เส้นทางต้นแบบ ไม่ใช่โปรดักชัน |
| จำนวนเงินฝาก / ถอน | รอการออกแบบ | **เปิดเผย** |
| เวลา / ช่องทางข้างค่าธรรมเนียม / mempool | รอการบรรเทาหรือนอกขอบเขต | ยังไม่บรรเทา |
| การจัดลำดับ validator / การเซ็นเซอร์ / MEV | บางส่วนนอกขอบเขตโปรโตคอล | ยังไม่บรรเทา |
| เมทาดาทาชั้นเครือข่ายและกระดานเทรด/บริดจ์ | นอกขอบเขตโปรโตคอล | นอกขอบเขต |

**ต้นแบบปัจจุบันไม่ใช่ความเป็นส่วนตัวระดับโปรดักชัน**

ในช่วง pre-testnet / การใช้งานต่ำ anonymity-set มีขนาดเล็กหรือว่างเปล่า; หากไม่มีผู้ใช้จริง ความเป็นส่วนตัวภายในพูลก็ไม่ได้ถูกสถาปนาอย่างมีความหมาย — **ความเป็นส่วนตัวที่แข็งแกร่งขึ้นอยู่กับ anonymity-set ขนาดใหญ่และมีการใช้งานจริง และจะไม่ถูกกล่าวอ้างจนกว่าจะมีการใช้งานจริง** การจัดลำดับ/MEV ในชั้น validator และเมทาดาทาเครือข่ายยังคงไม่ได้รับการบรรเทา

กรอบรูปนัยของ anonymity-set (anonymity-set ของ shielded pool ถูกนิยามและจำกัดอย่างไร) ถูกเก็บไว้ใน yellow paper (§15); หมวดนี้ระบุเป้าหมายความเป็นส่วนตัวและข้อจำกัดปัจจุบัน ไม่ใช่แบบจำลองรูปนัยนั้น

## 6. แบบจำลองคีย์และการเปิดเผย

จากสิทธิ์สูงไปต่ำ: **Spend Key** (สิทธิ์ใช้จ่ายเดียว; ไม่เคยออกจากอุปกรณ์ผู้ใช้; ไม่เคยมีส่วนร่วมในกระบวนการเปิดเผย) → **Full View Key** (อ่านอย่างเดียว; วางแผนแยกขาเข้า/ขาออก) → **Audit Key** (อยู่ในแผน: ผู้ใช้ออกด้วยความสมัครใจ; จำกัดเวลา จำกัดขอบเขต เพิกถอนได้; ไม่ใช่ช่องทางที่โปรโตคอลบังคับ) → **Disclosure Credential** (หน่วยการเปิดเผยน้อยที่สุดที่ผูกกับธุรกรรมหนึ่งหรือสแนปช็อตสินทรัพย์หนึ่ง) → **16-character disclosure code** (รหัสสั้นทางเข้า; ไม่ใช่คีย์)

**ขอบเขตสิทธิ์การดูของโครงการ**: การออกแบบปัจจุบันไม่รวม master viewing key ที่โครงการควบคุม คุณสมบัตินี้ต้องได้รับการตรวจสอบผ่านการพัฒนาแบบเปิด การทดสอบ และการตรวจสอบภายนอก แทนที่จะอิงความไว้วางใจในทีม — เส้นทางการสืบทอดคีย์ถูกส่งมอบเป็นโอเพนซอร์ส และบุคคลที่สามใด ๆ สามารถตรวจสอบกราฟการสืบทอดว่าไม่มีสาขาใดนำไปสู่โครงการ จนกว่าการตรวจสอบภายนอกจะเสร็จสมบูรณ์ นี่เป็น "คุณสมบัติการออกแบบที่ต้องได้รับการตรวจสอบ" ไม่ใช่ "การรับประกัน"

**นโยบาย mnemonic (การวางแผนสถาปัตยกรรม ไม่ใช่ผลิตภัณฑ์ที่ส่งมอบแล้ว)**: คีย์รากของวอลเล็ตโดยค่าเริ่มต้นใช้ mnemonic 24 คำ (BIP39) โดยคีย์ปลายน้ำถูกสืบทอดผ่านการแยกโดเมน (HKDF + domain tags) **mnemonic ต้องไม่ปรากฏในกระบวนการเปิดเผยใด ๆ**; ทั้ง disclosure code และ `link_secret` ต้องไม่ถูกสืบทอดจาก mnemonic เพียงอย่างเดียว — grant TDC/ADC ถูกสร้างในขณะที่เปิดเผยด้วยความสมัครใจโดยใช้ CSPRNG และการอนุญาตในเครื่อง

**ขอบเขตการมองเห็นการเปิดเผย (ข้อกำหนดการออกแบบ)**: ขอบเขตที่มองเห็นของหลักฐานการเปิดเผย — รวมถึงการมองเห็นทิศทางขาออก — ถูกวางแผนให้รับประกันด้วยกฎชั้นฉันทามติแทนที่จะเป็นข้อตกลงการพัฒนาวอลเล็ต (บทเรียนของอุตสาหกรรมจาก Zcash ที่การมองเห็นขาออกขึ้นกับข้อตกลงของวอลเล็ต); ข้อกำหนดนี้มาพร้อมสแต็กการตรวจสอบบนเชน (roadmap Phase 5) และยังไม่ได้พัฒนาในวันนี้

## 7. ต้นแบบการเปิดเผย TDC / ADC

### 7.1 คำศัพท์และการเข้ารหัส

คำศัพท์ทางการคือ "**16-character Crockford Base32 disclosure code**" (ชุดอักขระตัด I/L/O/U ที่สับสนง่ายออก; เอนโทรปีรหัสสั้น ~80 บิต) ย่อเป็น "16-character disclosure code" ไม่ใช้ถ้อยคำเช่น "16-digit code" หรือ "16-digit security code" — สคีมตัวเลขล้วน (~53 บิต) ถูกปฏิเสธเพราะงบเอนโทรปีไม่เพียงพอ

> **"16-character disclosure code ไม่ใช่หลักฐานยืนยันความปลอดภัยทางการเข้ารหัสพื้นฐาน มันเป็นจุดเข้าถึงที่เป็นมิตรกับผู้ใช้; การอนุญาตที่แท้จริงต้องได้รับการปกป้องร่วมกันโดย disclosure credential เอนโทรปีสูง ลายเซ็น การจำกัดขอบเขต การหมดอายุ และตรรกะการตรวจสอบ"**

### 7.2 สถานะปัจจุบันที่แท้จริง (ต้องอ่าน)

สิ่งที่ BEYUL มีคือ **ต้นแบบการสืบทอด TDC/ADC ฝั่งไคลเอนต์ที่ทดสอบในเครื่องแล้ว** ส่วน grant เซิร์ฟเวอร์แบบ end-to-end การตรวจสอบสถานะเชน และ ZK balance proof **อยู่ในแผนและยังไม่พัฒนา** ดังนั้นจึงต้องไม่ระบุว่า: การเปิดเผยที่ตรวจสอบได้ถูกพัฒนาแล้ว; เงินทุนสามารถพิสูจน์ได้แล้ว; ADC สามารถพิสูจน์ยอดที่แม่นยำได้; หรือ disclosure code สามารถตรวจสอบบนเชนได้

ต้นแบบไคลเอนต์ครอบคลุม (ทดสอบในเครื่องแล้ว): KEK สองปัจจัย (`link_secret` + รหัส 16 อักขระ ต้องมีทั้งคู่); การเข้ารหัสแบบบัญญัติ; การผูกบทบาทผู้ส่ง/ผู้รับของ TDC; การแยกโดเมน TDC/ADC (อันหนึ่งเปิดอีกอันไม่ได้); AEAD envelope พร้อมการป้องกันการปลอมแปลง AAD; ตัวตรวจสอบรหัสแบบ slow-hash (ชุดเป้าหมาย Argon2id; อะแดปเตอร์โปรดักชันยังไม่ต่อ); crypto-shredding ของ erasure-key; เวกเตอร์ข้ามภาษาที่ถูกตรึง

### 7.3 ความหมายของ TDC และ ADC

| ความสามารถ | เปิดเผย | ไม่เปิดเผย | สถานะ |
|---|---|---|---|
| TDC — Transaction Disclosure Code | ฟิลด์ที่จำกัดขอบเขตของธุรกรรม/เอาต์พุตหนึ่ง แยกบทบาทผู้ส่ง/ผู้รับ | spend authority, ประวัติเต็ม, ธุรกรรมอนาคต | ต้นแบบสืบทอดไคลเอนต์; การตรวจสอบเซิร์ฟเวอร์และเชนยังไม่พัฒนา |
| ADC_L1 — Asset Disclosure Code, ระดับขอบล่าง | proof-of-funds / คำกล่าวขอบล่างที่ผู้ใช้เลือก | ยอดเต็ม, notes, nullifiers, คู่สัญญา, ประวัติ | ต้นแบบสืบทอดไคลเอนต์; **ระบบพิสูจน์ยังไม่พัฒนา** |
| ADC_L2 — Asset Disclosure Code, ระดับแม่นยำ | สแนปช็อตยอดที่แม่นยำของสินทรัพย์ที่เลือก ณ ความสูงที่ finalize แล้ว | notes, nullifiers, คู่สัญญา, ประวัติ | **ออกแบบเท่านั้น**; ต้องการแหล่งความสมบูรณ์ + ZK balance proof |

**ไตรลักษณ์การเปิดเผย**: ระบบที่ซ่อนความเป็นเจ้าของไม่สามารถสัญญาความสมบูรณ์ของยอด การไม่รั่วไหลของประวัติ และการไม่มอบ viewing key พร้อมกันได้ — ผู้ใช้พิสูจน์ความเป็นเจ้าของ notes ที่เลือกได้ แต่หากขาดแหล่งความสมบูรณ์เพิ่มเติม พิสูจน์ไม่ได้ว่าไม่มีสิ่งใดถูกละเว้น ดังนั้น ADC จึงถูกแบ่งระดับ และ ADC เปิดเผยยอดของชุดสินทรัพย์ที่เลือก ณ ความสูงที่เลือกอย่างแม่นยำ — ต้องไม่อธิบายว่า "ไม่เปิดเผยยอด"

ความเสี่ยง ADC (คงเปิดเผย): สแนปช็อตซ้ำต่อฝ่ายเดียวกันเปิดเผยการเปลี่ยนแปลงยอดตามเวลา; การเปิดเผยมูลค่าสุทธิเป็นความเสี่ยงด้านความปลอดภัยทางร่างกายและการบังคับ (ADC ปิดโดยค่าเริ่มต้นและต้องการการยืนยันอย่างชัดเจน); การหมุนเวียนไม่สามารถเรียกคืนสิ่งที่ผู้สังเกตเห็นแล้ว

### 7.4 FAQ เรื่อง disclosure code

| คำถาม | คำตอบ |
|---|---|
| TDC คืออะไร | transaction disclosure code; เปิดเผยเฉพาะข้อมูลที่จำกัดขอบเขตของธุรกรรม/เอาต์พุตหนึ่ง |
| ADC คืออะไร | asset disclosure code; เปิดเผยสแนปช็อตยอดสินทรัพย์ที่ผู้ใช้เลือก |
| ADC เปิดเผยยอดหรือไม่ | ใช่ — ADC เปิดเผยสแนปช็อตยอดที่เลือก (selected balance snapshot) |
| disclosure code ใช้จ่ายเงินได้หรือไม่ | ไม่ได้ ทุก disclosure credential ต้องมี `canSpend=false` (ค่าคงที่ระดับโปรโตคอล) |
| disclosure code ถาวรหรือไม่ | ไม่ **อายุ 24 ชั่วโมงเป็นค่าเริ่มต้นตามการออกแบบ ไม่ใช่คุณสมบัติที่ถูกบังคับในปัจจุบัน** — การหมดอายุและเพิกถอนถูกบังคับโดยบริการ grant และการตรวจสอบ Layer 2 ในอนาคต (roadmap Phase 5) ไม่ใช่วันนี้ ตามการออกแบบ หลักฐานยืนยันถูกจำกัดเวลาและผู้ใช้กำหนดค่าได้: การเปิดเผยที่นานกว่าต้องการการยืนยันอย่างชัดเจน การเปิดเผยถาวรไม่ใช่ค่าเริ่มต้น และการเพิกถอน (เมื่อถูกบังคับแล้ว) ป้องกันการเข้าถึงในอนาคตแต่ลบข้อมูลที่ถูกดูหรือคัดลอกแล้วไม่ได้ |
| disclosure code สืบทอดจากวลีกู้คืนหรือไม่ | ไม่ disclosure credential เป็นแบบอ่านอย่างเดียว **ไม่เคยถูกสร้างอัตโนมัติเมื่อสร้างวอลเล็ต ไม่เคยสืบทอดจากวลีกู้คืน** และมอบ spend authority ไม่ได้ (`canSpend=false`) TDC เป็นการเปิดเผยต่อธุรกรรม; ADC เป็น grant ระดับสินทรัพย์แบบ opt-in |
| disclosure code ถูกปกป้องอย่างไร | สองปัจจัย (`link_secret` + รหัส 16 อักขระ), AEAD envelope, การผูก AAD, ตัวตรวจสอบ slow-hash; **การจำกัดอัตราฝั่งเซิร์ฟเวอร์และการตอบสนองข้อผิดพลาดแบบรวมยังต้องพัฒนา** |
| disclosure code เป็นคีย์ส่วนตัวหรือไม่ | ไม่ มันย้ายสินทรัพย์ไม่ได้และแทนคีย์ Spend/View/Audit ไม่ได้; แต่อย่าแชร์อย่างไม่ระวัง — ข้อมูลที่เปิดเผยแล้วเรียกคืนไม่ได้ |

## 8. แผนเทสต์เน็ต (จุดโฟกัสปัจจุบัน)

### 8.1 แบบจำลอง validator

เทสต์เน็ตใช้**แบบจำลอง validator BFT แบบ PoS**: Cosmos SDK + CometBFT, ชุด validator เริ่มต้น และกระบวนการทดสอบโมดูล staking มันไม่ใช่ PoW และ**ไม่ใช่ความปลอดภัยเชิงเศรษฐกิจ PoS ระดับเมนเน็ต** — แบบจำลองเศรษฐกิจเมนเน็ตเป็นงานวิจัยระยะยาวนอกขอบเขตของ whitepaper นี้

### 8.2 ความพร้อมของเทสต์เน็ต (ตรงไปตรงมา)

ความพร้อมของเทสต์เน็ต**กำลังดำเนินอยู่**: runbook หลายโหนดและ gate ที่เกี่ยวข้องยังไม่เสร็จสมบูรณ์ (pull request ที่เกี่ยวข้องยังไม่ถูก merge ทั้งหมด และ check ยังไม่ผ่าน) จนกว่า gate เหล่านี้จะปิดและหลักฐานถูกลงทะเบียน โครงการนี้ไม่ใช้ถ้อยคำ "testnet-ready"

เช็กลิสต์ก่อนเปิดตัว: แพ็กเกจหลักฐานปิด; chain-id และ genesis ของเทสต์เน็ต; คู่มือ onboarding validator; runbook หลายโหนด 3+ โหนด; นโยบาย faucet และการจำกัดอัตรา; นโยบาย RPC/API สาธารณะ; แดชบอร์ดมอนิเตอร์; กระบวนการตอบสนองเหตุการณ์; รายการข้อจำกัดที่ทราบ; กระแสคำสั่งของผู้เข้าร่วม; ประกาศโทเคนเทสต์เน็ตไร้มูลค่า

### 8.3 เทสต์เน็ตตรวจสอบอะไรได้ / พิสูจน์อะไรไม่ได้

**ตรวจสอบได้**: การทำงานของโหนดและการสร้างบล็อก กระบวนการโมดูล staking faucet RPC การมอนิเตอร์และตอบสนองเหตุการณ์ กระแสสาธิต disclosure-code กระแสต้นแบบ shielded module
**พิสูจน์ไม่ได้**: ความเป็นส่วนตัวโปรดักชัน ความปลอดภัยเชิงเศรษฐกิจ PoS ของเมนเน็ต มูลค่าโทเคน การยอมรับด้านกฎระเบียบ ZK soundness โปรดักชัน การเปิดเทสต์เน็ตต้องไม่ถูกโปรโมตว่าเป็น "การตรวจสอบโปรดักชัน"

### 8.4 ข้อแนะนำสำหรับผู้เข้าร่วม

โทเคนเทสต์เน็ตไม่มีมูลค่าทางการเงินและไม่มีคำสัญญาแปลงเป็นเมนเน็ต; ไม่มีวอลเล็ตทางการ — เข้าร่วมด้วยเครื่องมือบรรทัดคำสั่งและเอกสารที่เผยแพร่ทางการเท่านั้น; **ไม่มีกระบวนการใดร้องขอให้ mnemonic ของคุณเข้าสู่ขั้นตอนการเปิดเผย** — "ทางการ" ใด ๆ ที่ขอ mnemonic ของคุณคือมิจฉาชีพ; ปัจจุบันไม่มีการขายโทเคน รอบส่วนตัว whitelist หรือการลงทะเบียน airdrop ใด ๆ

### 8.5 การกำกับดูแล การอัปเกรด และขอบเขตเศรษฐกิจ

ในขั้น pre-testnet นี้ BEYUL **ไม่มีการกำกับดูแลแบบกระจายศูนย์** การอัปเกรดโปรโตคอลและ pin ที่สำคัญต่อความปลอดภัย — พารามิเตอร์ genesis และ **verifying key ที่ถูกตรึง (pinned)** — ถูกควบคุมโดย**ชุด validator เริ่มต้นร่วมกับ Owner** นี่เป็นแบบจำลองความไว้วางใจแบบรวมศูนย์ที่ระบุอย่างตรงไปตรงมา; มันจะถูกกระจายศูนย์ทีละน้อยเมื่อเครือข่ายและการกำกับดูแลของมันเติบโตเท่านั้น (ไม่มี DAO ไม่มีคำสัญญาเรื่องไทม์ไลน์การกระจายศูนย์) การรัน validator เองไม่มอบสิทธิ์การอัปเกรด; pinned VK และ genesis ถูกเปลี่ยนผ่านเส้นทางการอัปเกรด "ชุด validator + Owner" เท่านั้น

**ขอบเขตเศรษฐกิจ** denomination, อุปทาน และพารามิเตอร์เศรษฐกิจเป็น**การตัดสินใจของ Owner — มี gate และไม่ถูกนิยามใน whitepaper นี้** (ดูสถานะโทเคนด้านบน) ไม่มีสิ่งใดในที่นี้ตรึง denomination, อุปทาน หรือแบบจำลองเศรษฐกิจโทเคน

## 9. แบบจำลองภัยคุกคาม (เปิดเผยจนกว่าจะบรรเทา)

จัดระเบียบตามชั้นของฝ่ายตรงข้าม สอดคล้องกับแบบจำลองฝ่ายตรงข้ามของ yellow paper (A1–A4) นี่เป็นบทสรุป; yellow paper เป็นข้ออ้างอิงที่เชื่อถือได้ของแบบจำลองภัยคุกคาม และเอกสารทั้งสองต้องไม่เคลื่อนออกจากกัน — เมื่อมีความต่าง yellow paper มีผลเหนือกว่า

- **A1 — ผู้สังเกตเชนแบบพาสซีฟ** (อ่านเฉพาะข้อมูลเชนสาธารณะ): สหสัมพันธ์จำนวนเงินที่ฝาก/ถอนสาธารณะ สหสัมพันธ์เวลา ช่องทางข้างค่าธรรมเนียม/gas — **ยังไม่บรรเทา** commitments, nullifiers, anchors และบัญชีกระแสสุทธิของพูลเปิดเผยตามการออกแบบ
- **A2 — ฝ่ายตรงข้ามเครือข่าย/โครงสร้างพื้นฐาน** (mempool, RPC, การจัดลำดับ validator, IP): การสังเกต mempool การจัดลำดับและเซ็นเซอร์ validator เมทาดาทาชั้นเครือข่าย — **ยังไม่บรรเทา** (การจัดลำดับ/เซ็นเซอร์บางส่วนนอกขอบเขตโปรโตคอล); เมทาดาทากระดานเทรด/บริดจ์นอกโปรโตคอล — **นอกขอบเขต**
- **A3 — ฝ่ายตรงข้ามด้านการเปิดเผย** (ผู้รับการเปิดเผยหรือผู้ถือรหัส): การที่ผู้รับส่งต่อการเปิดเผย**ควบคุมไม่ได้ในเชิงการเข้ารหัส**; การเพิกถอน**ยังไม่พัฒนา**; การเปิดเผยอนุกรมเวลาและมูลค่าสุทธิของ ADC เมื่อสแนปช็อตซ้ำ; การออกภายใต้การบังคับ — **ระบุตรงไปตรงมา ยังไม่บรรเทา**
- **A4 — ฝ่ายตรงข้ามเอนด์พอยต์/วิศวกรรมสังคม** (อุปกรณ์ผู้ใช้ ฟิชชิง): ฟิชชิงและวิศวกรรมสังคมเพื่อเอา mnemonic หรือรหัส วอลเล็ตปลอมและช่องทางทางการปลอม — **ยังไม่บรรเทา**; จัดการผ่านการให้ความรู้ผู้ใช้และรายการช่องทางทางการ

ข้ามตัด ยังไม่แก้ไข: บั๊กวงจร trusted setup การตรวจสอบภายนอก — **ยังไม่ตรวจสอบ / ยังไม่แก้ไข / ยังไม่เสร็จ** ความสับสนเรื่องมูลค่าโทเคนเทสต์เน็ตและรางวัล**ไม่อนุญาต** — โทเคนทดสอบไร้มูลค่า และการบัญชีรางวัลใด ๆ เป็นการจำลอง

## 10. Roadmap (อิงตาม gate ไม่มีคำสัญญาเรื่องวันที่)

> แต่ละความสามารถต้องอยู่ในสถานะใดสถานะหนึ่งพอดี: Implemented / Local tested / Prototype / Documentation only / Planned / Unverified / Not implemented ไม่มีข้อกล่าวอ้างใดเขียนว่า "พัฒนาแล้ว" ได้โดยไม่มี commit, บันทึก CI, คำสั่งทดสอบ และเอาต์พุต

| เฟส | เป้าหมาย | เกณฑ์ออก (สรุป) |
|---|---|---|
| Phase 0 — ปิดหลักฐานและกำหนดขอบเขตเอกสาร **← ปัจจุบัน** | ปิด evidence appendix; จำกัดเรื่องเล่าสาธารณะให้อยู่ที่เทสต์เน็ต | ทุกข้อกล่าวอ้างที่พัฒนาแล้วมีหลักฐาน; ไม่มีนัยเรื่องโทเคน/วอลเล็ต/DeFi/เมนเน็ต |
| Phase 1 — ความพร้อมเทสต์เน็ต | ทำเช็กลิสต์ §8.2 ให้เสร็จ | devnet 3+ โหนดเสถียร; runbook ทำซ้ำได้; check PR เขียว |
| Phase 2 — เทสต์เน็ตสาธารณะ | การทดลองสาธารณะแบบควบคุม | โหนดภายนอกเข้าร่วมได้; การใช้ faucet ในทางที่ผิดถูกควบคุม; ไม่ชี้นำผิดเรื่องเมนเน็ตหรือผลตอบแทน |
| Phase 3 — TDC MVP | grant ธุรกรรมเดียวแบบ end-to-end | พฤติกรรมเมื่อรหัสผิด/หมดอายุ/หมดปลอดภัย; การมีอยู่ของ grant ไม่รั่ว; เฉพาะฟิลด์ที่จำกัดขอบเขต |
| Phase 4 — ADC_L1 | proof of funds ขอบล่าง | ไม่อธิบายว่าเป็นยอดที่แม่นยำเลย; ความเสี่ยงอนุกรมเวลาเปิดเผย; TDC/ADC เปิดกันและกันไม่ได้ |
| Phase 5 — การตรวจสอบการเปิดเผยบนเชน | การตรวจสอบแบบ root-bound | chain/root/scope/asset ผิดถูกปฏิเสธทั้งหมด; การป้องกัน replay |
| Phase 6 — เส้นทาง ZK โปรดักชัน | ระบบพิสูจน์ที่ตรวจสอบได้ | เลิกใช้ dev verifying keys; การตรวจสอบการเข้ารหัสภายนอก; ไม่กล่าวอ้าง "production ZK" ก่อนเสร็จ |
| Phase 7 — ADC_L2 | สแนปช็อตยอดที่แม่นยำ | ความสมบูรณ์พิสูจน์ได้; ไม่รั่วประวัติ; ไม่กลายเป็น viewing key ที่อยู่ยาว |
| Phase 8 — การตรวจสอบภายนอกและ pre-mainnet | การทบทวน pre-mainnet | การตรวจสอบโปรโตคอล/การเข้ารหัส/การพัฒนา; การทบทวนกฎหมาย; แพ็กเกจหลักฐานสาธารณะ |

ลำดับย้อนกลับไม่ได้: **testnet → TDC MVP → ADC_L1 → root-bound verification → production ZK → ADC_L2 → audit → pre-mainnet**

## 11. ขอบเขตการปฏิบัติตามกฎ

BEYUL ไม่ใช่โซลูชันการปฏิบัติตามกฎ: มันไม่พัฒนากระบวนการ AML, KYC, travel-rule, การอายัด, การคัดกรองมาตรการคว่ำบาตร หรือการรายงาน และไม่กล่าวอ้าง "compliant by design" การเปิดเผยทั้งหมดเริ่มต้นจากผู้ใช้; โปรโตคอลไม่มีช่องทางการเปิดเผยแบบบังคับ; การออกแบบปัจจุบันไม่รวม viewing key ระดับโกลบอลที่โครงการควบคุม (จะตรวจสอบผ่านการพัฒนาแบบเปิดและการตรวจสอบ) สถาบันและบุคคลควรประเมินจุดยืนด้านกฎระเบียบของเขตอำนาจศาลของตนต่อสินทรัพย์เชิงความเป็นส่วนตัวอย่างอิสระ

## 12. คำชี้แจงความเสี่ยงและข้อปฏิเสธความรับผิด

เอกสารนี้มีไว้เพื่อข้อมูลเท่านั้น และไม่ก่อให้เกิด และไม่ควรถูกตีความว่าเป็น: การเสนอขายหรือขายหลักทรัพย์ สินค้าโภคภัณฑ์ หรือเครื่องมือทางการเงิน; คำแนะนำด้านการลงทุน กฎหมาย ภาษี หรือการเงิน; หรือคำกล่าวเรื่องการปฏิบัติตามกฎในเขตอำนาจศาลใด ๆ เอกสารนี้มีคำกล่าวเชิงคาดการณ์อนาคต (เป้าหมายการออกแบบ แผนเทสต์เน็ต roadmap) ที่อยู่ภายใต้ความไม่แน่นอนอย่างมีนัยสำคัญ; ผลลัพธ์จริงอาจแตกต่างอย่างมีนัยสำคัญ

ปัจจุบันโครงการนี้**ไม่มีโทเคนที่ออกแล้ว**; โทเคนเทสต์เน็ต หากมีการใช้ ไม่มีมูลค่าทางการเงิน การเข้าร่วมในเครือข่ายสินทรัพย์คริปโตมีความเสี่ยงอย่างมีนัยสำคัญ โปรดทำการวิจัยด้วยตนเองและปรึกษาที่ปรึกษามืออาชีพ เมื่อฉบับแปลใดขัดแย้งกับฉบับมาตรฐานภาษาอังกฤษนี้ ฉบับภาษาอังกฤษนี้มีผลเหนือกว่า ข้อปฏิเสธความรับผิดนี้เป็นเทมเพลตทั่วไปและต้องได้รับการทบทวนโดยที่ปรึกษากฎหมายในเขตอำนาจศาลที่เกี่ยวข้องก่อนการเผยแพร่สาธารณะอย่างเป็นทางการใด ๆ

## 13. บทสรุป

ทิศทางของ BEYUL คือความเป็นส่วนตัวโดยค่าเริ่มต้นพร้อมการเปิดเผยที่ผู้ใช้ควบคุม สินทรัพย์ที่น่าเชื่อถือในวันนี้: ต้นแบบ chain-application, ต้นแบบการสืบทอด TDC/ADC ฝั่งไคลเอนต์ที่ทดสอบในเครื่องแล้ว และตารางสถานะกับแบบจำลองภัยคุกคามที่จัดให้สอดคล้องกับการพัฒนาอย่างเคร่งครัด จุดโฟกัสเดียวในปัจจุบันคือ**เงื่อนไขเบื้องต้นของการเปิดเทสต์เน็ตสาธารณะ**: การปิดหลักฐาน runbook หลายโหนด faucet และการมอนิเตอร์ เอกสารผู้เข้าร่วม จนกว่าหลักฐานที่สอดคล้องกันจะมีอยู่ โครงการนี้จะไม่กล่าวอ้างเรื่องเมนเน็ต โทเคน ความเป็นส่วนตัวโปรดักชัน หรือการปฏิบัติตามกฎ