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】

จุดสร้างความแตกต่างที่ตั้งใจไม่ใช่ "การซ่อนที่แข็งแกร่งกว่า" แต่เป็นการเปิดเผยที่ละเอียดกว่า มีกำหนดเวลา และผู้ใช้เป็นผู้ออก: ในขณะที่ 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. สถานะปัจจุบัน

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

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

การประเมินตนเองปัจจุบัน: วัสดุส่วนใหญ่อยู่ระดับ 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. แบบจำลองความเป็นส่วนตัวและข้อจำกัดปัจจุบัน

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

ในช่วง 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

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

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

7.4 FAQ เรื่อง disclosure code

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, คำสั่งทดสอบ และเอาต์พุต

ลำดับย้อนกลับไม่ได้: 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 และการมอนิเตอร์ เอกสารผู้เข้าร่วม จนกว่าหลักฐานที่สอดคล้องกันจะมีอยู่ โครงการนี้จะไม่กล่าวอ้างเรื่องเมนเน็ต โทเคน ความเป็นส่วนตัวโปรดักชัน หรือการปฏิบัติตามกฎ