BEYUL Whitepaper — Pre-Testnet Edition: Kiến trúc và mô hình tiết lộ

Đây là bản dịch. Phiên bản tiếng Anh là phiên bản chuẩn (canonical) duy nhất và được ưu tiên khi có mâu thuẫn. Các định danh kỹ thuật (BEYUL, BYL, privacychain, TDC, ADC, nullifier, commitment, viewing key, shielded pool, Groth16, v.v.) được giữ nguyên tiếng Anh, không dịch.

Dự án: BEYUL　Loại: nguyên mẫu nghiên cứu của một public chain riêng tư (pre-testnet). Công việc giao thức BEYUL hiện được phát triển trong kho privacychain. Trạng thái tài liệu: whitepaper của BEYUL, ấn bản pre-testnet (nghiên cứu) — mô tả kiến trúc giao thức, mô hình tiết lộ và các ranh giới hiện tại trước testnet công khai. Đây không phải là đặc tả giao thức sản xuất, không phải tài liệu đầu tư, không phải ý kiến tuân thủ, không phải kiểm toán bảo mật, không phải tài liệu phát hành token, không phải thông báo mainnet. Các tuyên bố về năng lực tuân theo kỷ luật bằng chứng ở §3.1; không có gì ở đây được mô tả vượt quá độ trưởng thành thực tế của nó. Trạng thái token: tokenomics chưa hoàn thiện. BYL chỉ là dạng viết tắt / ticker của dự án; nó không phải là một denomination đã đóng băng — denomination và các tham số chuỗi vẫn đang chờ Owner phê duyệt rõ ràng. Tài liệu này không định nghĩa phân bổ token hay thiết kế tiện ích. Token testnet, nếu được dùng, không có giá trị tiền tệ và không hứa hẹn chuyển đổi sang mainnet. Ngôn ngữ chuẩn: phiên bản tiếng Anh là phiên bản chuẩn duy nhất. Phiên bản tiếng Trung (beyul-whitepaper-pretestnet.zh.md) là văn bản công tác đi kèm; khi có mâu thuẫn, phiên bản tiếng Anh được ưu tiên.

Hộp ranh giới tuyên bố (đọc trước tiên)

Tài liệu này không đưa ra bất kỳ tuyên bố nào sau đây:

• Không tuyên bố về tính ẩn danh, không thể truy vết hay "an toàn tuyệt đối";
• Không tuyên bố về bảo mật zero-knowledge cấp sản xuất (triển khai hiện tại dùng vật liệu development-key);
• Không tuyên bố về quyền riêng tư cấp sản xuất (số tiền nạp và rút hiện công khai on-chain);
• Không tuyên bố về sự chấp thuận của cơ quan quản lý hay "compliance by design";
• Thiết kế hiện tại không bao gồm viewing key toàn cục do dự án kiểm soát; thuộc tính này phải được xác minh thông qua triển khai mở, kiểm thử và kiểm toán bên ngoài;
• Không tồn tại testnet công khai hay mainnet; việc sẵn sàng testnet đang tiến hành — runbook đa nút và các gate liên quan chưa hoàn tất;
• Không hứa hẹn về giá trị token, airdrop, lợi suất, lợi nhuận hay niêm yết sàn; tài liệu này không bàn về sản phẩm ví hay DeFi;
• 16-character disclosure code không phải là một thông tin xác thực bảo mật mật mã nền tảng (Mục 7).

Đặt tên và định danh kỹ thuật. BEYUL là tên dự án/sản phẩm; công việc giao thức BEYUL hiện được phát triển trong kho privacychain. privacychain vẫn là định danh kỹ thuật hiện tại — kho, gói giao thức/mô-đun/proto, binary và chain-id — và được giữ nguyên không đổi. BYL là dạng viết tắt / ticker; denomination và các tham số chuỗi vẫn chờ Owner phê duyệt rõ ràng, nên BYL không phải là một denomination đã đóng băng. Kỷ luật đặt tên này chỉ áp dụng về phía trước: các tài liệu lịch sử không được đổi tên hồi tố.

1. Tóm tắt

BEYUL là một dự án public chain riêng tư ở giai đoạn nguyên mẫu nghiên cứu (pre-testnet) khám phá hạ tầng thanh toán với quyền riêng tư theo mặc định (một mục tiêu thiết kế) và tiết lộ do người dùng kiểm soát. Trong thiết kế mục tiêu, chi tiết giao dịch mặc định không hiển thị công khai, nhưng chủ sở hữu tài sản có thể tự nguyện tiết lộ, với phạm vi giới hạn, cho một bên được chọn — Transaction Disclosure Code (TDC) giải thích một giao dịch; Asset Disclosure Code (ADC) tiết lộ một ảnh chụp tài sản được chọn. "Quyền riêng tư theo mặc định" mô tả mục tiêu thiết kế, không phải nguyên mẫu hiện tại (xem §5).

Những gì tồn tại hôm nay chỉ là một nguyên mẫu suy dẫn disclosure-code phía client (đã kiểm thử cục bộ; gói bằng chứng công khai đang chờ hợp nhất) và một nguyên mẫu chain-application dựa trên Cosmos SDK. Các grant phía máy chủ đầu-cuối, xác minh on-chain và ZK balance proof chưa được triển khai; không có trusted setup, không kiểm toán bên ngoài, không testnet công khai hay mainnet; số tiền nạp và rút hiện công khai on-chain. Mục đích của whitepaper này (ấn bản pre-testnet) là ghi lại một cách chính xác hướng kiến trúc, mô hình tiết lộ và các ranh giới hiện tại trước khi ra mắt testnet công khai — và chỉ được thay thế bằng ấn bản sản xuất khi có bằng chứng và kiểm toán tương ứng.

2. Định vị và vấn đề

Các sổ cái công khai phơi bày quan hệ thanh toán, số dư và dòng tiền cho bất kỳ người quan sát nào; trong khi đó, hầu hết các hệ thống riêng tư mạnh khiến tiết lộ chọn lọc khó về mặt vận hành — giải thích một giao dịch cho một bên thường có nghĩa là trao đi khả năng xem mọi thứ. Khoảng trống mà BEYUL khám phá: biến "tiết lộ" thành một primitive hạng nhất ngang hàng với "ẩn giấu", với mọi tiết lộ do người dùng khởi xướng.

BEYUL không cạnh tranh — và không nhắm tới — một câu chuyện "hoàn toàn ẩn danh, không thể truy vết".

Tầm nhìn. Quyền riêng tư tài chính trên các sổ cái công khai bị đảo ngược: trần trụi theo mặc định, trong khi việc che giấu tự nó trông đáng ngờ. Mục tiêu của BEYUL là đảo ngược mặc định đó — quyền riêng tư là trạng thái mặc định, và tiết lộ là lựa chọn có chủ đích, chi tiết của người dùng: giao dịch nào, trường nào, cho ai và trong bao lâu.

Nguyên tắc thiết kế. Mọi phần của giao thức đều tuân theo những điều này:

1. Tiết lộ là công dân hạng nhất — các primitive tiết lộ được thiết kế và làm nguyên mẫu ngang hàng với các primitive ẩn giấu.
2. Quyền tối thiểu — mỗi khóa và thông tin xác thực chỉ mang quyền tối thiểu mà mục đích của nó cần.
3. spend authority là bất khả xâm phạm — không luồng tiết lộ nào được chạm vào spend authority; mnemonic không bao giờ đi vào bất kỳ bước tiết lộ nào.
4. Không đặc quyền toàn cục — giao thức được thiết kế để không cung cấp bất kỳ kênh xem toàn cục nào cho dự án hay bên thứ ba; việc không tồn tại bất kỳ nhánh nào như vậy là một thuộc tính thiết kế cần được xác minh thông qua triển khai mở, kiểm thử và kiểm toán bên ngoài (§6), chưa phải là một bảo đảm.
5. Trung thực về ranh giới — mỗi năng lực tuyên bố điều nó không làm; mô hình mối đe dọa và các giới hạn được giữ công khai.
6. Bằng chứng trước — các tuyên bố về năng lực chỉ được nâng cấp sau khi có bằng chứng (mã, kiểm thử, kiểm toán) — dựa trên gate, không hứa hẹn ngày tháng.

2.1 So sánh tiết lộ của BEYUL

Bảng so sánh thiết kế mục tiêu của BEYUL với các năng lực đã phát hành hiện tại của các hệ thống khác. Những điểm khác biệt của BEYUL dưới đây (hết hạn, thu hồi, khả năng hiển thị do đồng thuận cưỡng chế, phạm vi theo-giao-dịch/theo-ảnh-chụp với xác minh phía máy chủ và on-chain) phần lớn là đang lên kế hoạch hoặc nguyên mẫu phía client (xem §3, §7), chưa được phát hành. Các sự kiện về đối thủ được nêu một cách thận trọng; những điểm chưa được tái xác minh độc lập cho whitepaper này được đánh dấu 【to verify】.

Điểm khác biệt dự kiến không phải là "ẩn giấu mạnh hơn" mà là tiết lộ chi tiết hơn, có giới hạn thời gian, do người dùng phát hành: nơi viewing key của Zcash/Monero là một quyền đọc toàn tài khoản, tất-cả-hoặc-không và vô thời hạn, thì thông tin xác thực tiết lộ của BEYUL được giới hạn vào một giao dịch (TDC) hoặc một ảnh chụp tài sản (ADC), mang một hạn hết hạn và được thiết kế để thu hồi được — với tập trường hiển thị do đồng thuận cưỡng chế thay vì quy ước ví. Những thuộc tính này là mục tiêu thiết kế; trạng thái triển khai của chúng được theo dõi trung thực ở §3 và §7.

Nguồn. Zcash/Monero: báo cáo nghiên cứu chuyên sâu ZEC/XMR của dự án này (nguồn sơ cấp — Zcash Protocol Specification; tài liệu Monero; tính đến 2026-06-12). Các hàng Penumbra / Aztec / Namada mô tả tài liệu chính thức của mỗi dự án tính đến 2026-06 (Penumbra: protocol.penumbra.zone — viewing keys, FMD; Aztec: docs.aztec.network — keys, note discovery; Namada: docs.namada.net — shielded accounts). Các điểm 【to verify】 còn lại — hết hạn/thu hồi và ngữ nghĩa transaction-perspective của Penumbra, hết hạn/thu hồi native của Aztec, ngữ nghĩa thu hồi chính xác của Namada — đang chờ xác nhận. Các hàng này nêu những gì tài liệu của mỗi dự án mô tả, không phải tuyên bố về điều mà các hệ thống khác "không thể làm".

3. Trạng thái hiện tại

3.1 Chuỗi bằng chứng

Mỗi hàng "nguyên mẫu đã triển khai" ở trên được gắn với một bản ghi bằng chứng — không phải khẳng định bằng văn xuôi. Chuỗi bằng chứng (commit hash, bản ghi CI, lệnh kiểm thử và đầu ra chính xác, hướng dẫn chạy có thể tái lập) được lưu trong Evidence Appendix, và mỗi năng lực được xếp hạng trên thang độ trưởng thành nghiên cứu L0–L5 (thiết kế → nguyên mẫu → tái lập được → đã rà soát → bằng chứng mạng → sản xuất). Whitepaper này tham chiếu đến sổ đăng ký đó thay vì nêu lại bằng chứng thô.

Tự đánh giá hiện tại: phần lớn tài liệu ở mức L1–L2, không có gì ở L5. Cho đến khi các mục Evidence Appendix được điền (commit/CI), tài liệu công khai nói "đã xác minh cục bộ; gói bằng chứng công khai đang chờ hợp nhất", không phải "đã triển khai với bằng chứng công khai". Một năng lực không có bản ghi bằng chứng đã đăng ký không được mô tả vượt quá mức độ trưởng thành của nó. Evidence Appendix nằm tại docs/evidence-appendix.md (nội bộ; sẽ được công bố cùng gói bằng chứng công khai); E1/E3/E4 đã được tái lập ở chế độ chỉ đọc vào 2026-06-19, việc gắn CI vẫn đang chờ.

4. Mô hình kỹ thuật

Nguyên mẫu xoay quanh một máy trạng thái shielded-pool. Đối với người không phải nhà mật mã học, vòng đời của một số dư riêng tư diễn ra như sau:

1. Note. Một số dư có thể chi tiêu là một note — bản ghi gồm (chủ sở hữu, số tiền, tính ngẫu nhiên). Bản thân note không bao giờ xuất hiện on-chain.
2. Commitment. Chuỗi chỉ lưu một commitment tới note (một hash ràng buộc một chiều), được nối vào một Merkle commitment tree chỉ-thêm. Chỉ từ commitment, người quan sát không biết được chủ sở hữu lẫn số tiền.
3. Spend → nullifier. Để chi tiêu một note, chủ sở hữu công bố một nullifier suy dẫn từ nó. nullifier được thiết kế để người quan sát bên ngoài không thể liên kết với commitment (theo giả định PRF của nullifier-key; yellow paper §7.1), nhưng nó tất định đối với note đó — nên cùng một note chỉ có thể bị vô hiệu một lần.
4. Từ chối double-spend. Chuỗi duy trì một tập nullifier; một nullifier lặp lại bị từ chối. Điều này ngăn double-spend mà không tiết lộ note nào đã bị chi tiêu.
5. Bằng chứng hợp lệ. Mỗi spend mang một bằng chứng zero-knowledge rằng "tôi sở hữu một note có commitment trong cây, và tôi đã suy dẫn nullifier của nó đúng cách", mà không tiết lộ bất kỳ giá trị nào trong số đó. Việc xác minh đi qua một đường Groth16.

Bộ xác minh hiện tại dùng vật liệu verifying-key development/skeleton mà không có trusted setup và không thiết lập soundness hay quyền riêng tư cấp sản xuất. Cách diễn đạt đối ngoại chuẩn: "Nguyên mẫu bao gồm một đường xác minh Groth16 development-key. Nó chưa cung cấp bảo mật zero-knowledge cấp sản xuất." Để biết các định nghĩa hình thức của định dạng note, lược đồ commitment, suy dẫn nullifier và ngữ nghĩa cây, xem yellow paper §§5–7 và §10.

4.1 Tại sao một chuỗi độc lập, và tại sao Cosmos

Mô hình tiết lộ cần kiểm soát đối với những thứ mà việc triển khai smart-contract trên một L1 dùng chung, hay một rollup tổng quát, không trao một cách gọn gàng:

• Khả năng hiển thị tiết lộ do đồng thuận cưỡng chế (§6) và các quy tắc toàn vẹn nguồn cung của shielded pool phải nằm ở lớp chuyển trạng thái / đồng thuận, không phải bên trong một contract mà validator của chuỗi chủ và thị trường phí nằm ngoài tầm kiểm soát của dự án.
• Trạng thái shielded native (commitment tree, tập nullifier, hạch toán value-balance) rẻ hơn và dễ kiểm toán hơn khi là trạng thái chuỗi hạng nhất so với lưu trữ contract, và tránh việc mô hình mempool công khai và siêu dữ liệu của chuỗi chủ rò rỉ nhiều hơn dự định.
• Một tập validator bonded-PoS cho phép tính toàn vẹn nguồn cung được tính lại bởi mỗi full node và cho tính chung kết tức thời phù hợp cho thanh toán.

Cosmos SDK + CometBFT được chọn vì một ngăn xếp BFT-PoS trưởng thành với các mô-đun staking/slashing, quản trị nâng cấp có chủ quyền và tính chung kết tức thời — không phải là sự xác nhận cho bất kỳ mô hình token nào (không có mô hình nào được hoàn thiện). Đây là lý do lựa chọn kiến trúc, không phải tuyên bố rằng chuỗi độc lập đã được triển khai; trạng thái thực tế xem §3 và §8.

4.2 Đặc tính hiệu năng

Hai loại con số được giữ tách biệt. Cố hữu (cấp lược đồ, có thể trích dẫn): Groth16 trên đường cong BN254 có bằng chứng kích thước hằng số (ba phần tử nhóm: 2×G1 + 1×G2, ~128 B nén / ~256 B không nén trên BN254) và xác minh thời gian hằng số (một số lượng cố định, nhỏ các phép kiểm tra pairing, độc lập với kích thước mạch). Điều này xuất phát từ chính hệ thống chứng minh, không phải từ triển khai của BEYUL. Cấp hệ thống (chưa đo lường): thời gian chứng minh, thông lượng giao dịch (TPS) và kích thước mạch (số ràng buộc) phụ thuộc vào mạch sản xuất, mà mạch sản xuất chưa được xây dựng — đường hiện tại dùng một verifying key dev/skeleton (§4). Do đó bất kỳ con số nào như vậy đều là một target / 【to be supplied】, sẽ được đo benchmark khi mạch sản xuất và một đường trusted-setup-hoặc-chứng-minh-minh-bạch tồn tại (Roadmap §10, Phase 6). Phía trên đường này, không có con số hiệu năng cấp hệ thống nào được tuyên bố.

5. Mô hình quyền riêng tư và các giới hạn hiện tại

Nguyên mẫu hiện tại không phải là quyền riêng tư cấp sản xuất.

Ở pre-testnet / mức sử dụng thấp, anonymity-set nhỏ hoặc rỗng; không có người dùng thực, quyền riêng tư trong pool không được thiết lập một cách có ý nghĩa — quyền riêng tư mạnh phụ thuộc vào một anonymity-set lớn và hoạt động tích cực, và KHÔNG được tuyên bố cho đến khi tồn tại việc sử dụng thực. Việc sắp xếp/MEV ở lớp validator và siêu dữ liệu mạng vẫn chưa được giảm thiểu.

Một khung hình thức anonymity-set (cách anonymity-set của shielded pool được định nghĩa và giới hạn) được duy trì trong yellow paper (§15); mục này nêu các mục tiêu quyền riêng tư và giới hạn hiện tại, không phải mô hình hình thức đó.

6. Mô hình khóa và tiết lộ

Từ quyền cao đến thấp: Spend Key (quyền chi tiêu duy nhất; không bao giờ rời thiết bị người dùng; không bao giờ tham gia các luồng tiết lộ) → Full View Key (chỉ đọc; dự kiến tách đến/đi) → Audit Key (đang lên kế hoạch: do người dùng tự nguyện phát hành; giới hạn thời gian, giới hạn phạm vi, thu hồi được; không phải kênh do giao thức bắt buộc) → Disclosure Credential (đơn vị tiết lộ tối thiểu, gắn với một giao dịch hoặc một ảnh chụp tài sản) → 16-character disclosure code (mã ngắn lối vào; không phải một khóa).

Ranh giới quyền xem của dự án: thiết kế hiện tại không bao gồm một master viewing key do dự án kiểm soát. Thuộc tính này phải được xác minh thông qua triển khai mở, kiểm thử và kiểm toán bên ngoài thay vì tin cậy đội ngũ — các đường suy dẫn khóa được phát hành dưới dạng open source, và bất kỳ bên thứ ba nào cũng có thể kiểm toán đồ thị suy dẫn để xác minh không tồn tại bất kỳ nhánh nào dẫn tới dự án. Cho đến khi kiểm toán bên ngoài hoàn tất, đây là "thuộc tính thiết kế cần được xác minh", không phải "bảo đảm".

Chính sách mnemonic (lập kế hoạch kiến trúc, không phải sản phẩm đã phát hành): khóa gốc của ví mặc định dùng mnemonic 24 từ (BIP39), với các khóa hạ nguồn được suy dẫn qua tách miền (HKDF + domain tags). Mnemonic không bao giờ được xuất hiện trong bất kỳ luồng tiết lộ nào; cả disclosure code lẫn link_secret đều không được suy dẫn chỉ từ mnemonic — grant TDC/ADC được tạo vào thời điểm tiết lộ tự nguyện bằng CSPRNG và ủy quyền cục bộ.

Ranh giới khả năng hiển thị tiết lộ (yêu cầu thiết kế): phạm vi hiển thị của một thông tin xác thực tiết lộ — bao gồm khả năng hiển thị hướng gửi đi — được dự kiến đảm bảo bằng các quy tắc lớp đồng thuận thay vì quy ước triển khai ví (một bài học ngành từ Zcash, nơi khả năng hiển thị gửi đi phụ thuộc vào quy ước ví); yêu cầu này đi cùng ngăn xếp xác minh on-chain (roadmap Phase 5) và chưa được triển khai hôm nay.

Lớp Disclosure Grant (chờ rà soát độc lập): lớp Disclosure Grant — phạm vi, hết hạn, thu hồi, nhật ký kiểm toán và quyền viewer — đang chờ một cuộc rà soát độc lập về sản phẩm và bảo mật. Cho đến khi cuộc rà soát đó hoàn tất, không được dựa vào bất kỳ thuộc tính ranh giới nào trong số này, và không tài liệu nào được ngụ ý rằng chúng đã được thiết lập.

7. Nguyên mẫu tiết lộ TDC / ADC

7.1 Thuật ngữ và mã hóa

Thuật ngữ chính thức là "16-character Crockford Base32 disclosure code" (bảng chữ cái loại trừ các ký tự dễ nhầm I/L/O/U; entropy mã ngắn ~80 bit), viết tắt "16-character disclosure code". Các cách diễn đạt như "16-digit code" hay "16-digit security code" không được dùng — một lược đồ chỉ-số (~53 bit) đã bị bác bỏ vì ngân sách entropy không đủ.

"16-character disclosure code không phải là một thông tin xác thực bảo mật mật mã nền tảng. Nó là một điểm vào truy cập thân thiện với người dùng; sự ủy quyền thực sự phải được bảo vệ đồng thời bởi một disclosure credential entropy cao, chữ ký, hạn chế phạm vi, hết hạn và logic xác minh."

7.2 Trạng thái thực tế hiện tại (bắt buộc đọc)

Những gì BEYUL có là một nguyên mẫu suy dẫn TDC/ADC phía client đã kiểm thử cục bộ. Các grant máy chủ đầu-cuối, xác minh trạng thái chuỗi và ZK balance proof đang lên kế hoạch và chưa triển khai. Do đó KHÔNG được nêu rằng: tiết lộ có thể xác minh đã được triển khai; tiền đã có thể được chứng minh; ADC có thể chứng minh số dư chính xác; hoặc disclosure code có thể được xác minh on-chain.

Nguyên mẫu client bao phủ (đã kiểm thử cục bộ): KEK hai yếu tố (link_secret + mã 16 ký tự, cả hai bắt buộc); mã hóa chuẩn tắc; ràng buộc vai trò người gửi/người nhận của TDC; tách miền TDC/ADC (cái này không mở được cái kia); AEAD envelope với bảo vệ chống giả mạo AAD (envelope TDC/ADC phía client; AAD của envelope on-chain MsgDiscloseNote vẫn là một target — yellow paper §2.3); bộ xác minh mã slow-hash (bộ mục tiêu Argon2id; bộ chuyển đổi sản xuất chưa nối); crypto-shredding erasure-key.

7.3 Ngữ nghĩa TDC và ADC

Tam nan tiết lộ: một hệ thống ẩn quyền sở hữu không thể đồng thời hứa hẹn tính đầy đủ số dư, không rò rỉ lịch sử và không trao viewing key — người dùng có thể chứng minh quyền sở hữu các notes đã chọn nhưng, nếu thiếu một nguồn đầy đủ bổ sung, không thể chứng minh không có gì bị bỏ sót. Do đó ADC được phân tầng, và một ADC tiết lộ chính xác số dư của tập tài sản đã chọn tại chiều cao đã chọn — không được mô tả là "không tiết lộ số dư".

Rủi ro ADC (giữ công khai): các ảnh chụp lặp lại cho cùng một bên tiết lộ thay đổi số dư theo thời gian; phơi bày giá trị ròng là rủi ro an toàn thân thể và cưỡng ép (ADC mặc định tắt và yêu cầu xác nhận rõ ràng); việc xoay vòng không thể thu hồi những gì người xem đã thấy.

7.4 FAQ về disclosure code

8. Kế hoạch testnet (trọng tâm hiện tại)

8.1 Mô hình validator

Testnet dùng một mô hình validator BFT kiểu PoS: Cosmos SDK + CometBFT, một tập validator ban đầu, và các luồng kiểm thử mô-đun staking. Nó không phải PoW, và không phải an ninh kinh tế PoS cấp mainnet — mô hình kinh tế mainnet là nghiên cứu dài hạn ngoài phạm vi của whitepaper này.

8.2 Sự sẵn sàng của testnet (nói thẳng)

Sự sẵn sàng của testnet đang tiến hành: runbook đa nút và các gate liên quan chưa hoàn tất (các pull request liên quan chưa được merge hết và các check chưa qua). Cho đến khi các gate đó đóng và bằng chứng được đăng ký, dự án này không dùng cách diễn đạt "testnet-ready".

Danh mục kiểm tra trước ra mắt: gói bằng chứng đã đóng; chain-id và genesis của testnet; hướng dẫn onboarding validator; runbook đa nút 3+ nút; chính sách faucet và rate-limiting; chính sách RPC/API công khai; bảng giám sát; quy trình ứng phó sự cố; danh sách giới hạn đã biết; luồng lệnh của người tham gia; thông báo token testnet không có giá trị.

8.3 Testnet có thể xác thực gì / không thể chứng minh gì

Có thể xác thực: vận hành nút và sản xuất block, các luồng mô-đun staking, faucet, RPC, giám sát và ứng phó sự cố, luồng demo disclosure-code, luồng nguyên mẫu shielded module. Không thể chứng minh: quyền riêng tư sản xuất, an ninh kinh tế PoS của mainnet, giá trị token, sự chấp nhận của cơ quan quản lý, ZK soundness sản xuất. Việc ra mắt testnet không được tiếp thị như "xác thực sản xuất".

8.4 Lưu ý cho người tham gia

Token testnet không có giá trị tiền tệ và không hứa hẹn chuyển đổi sang mainnet; không có ví chính thức — chỉ tham gia bằng công cụ dòng lệnh và tài liệu được công bố chính thức; không luồng nào bao giờ yêu cầu mnemonic của bạn đi vào một bước tiết lộ — bất kỳ ai "chính thức" hỏi mnemonic của bạn đều là kẻ lừa đảo; hiện không có bất kỳ đợt bán token, vòng riêng tư, whitelist hay đăng ký airdrop nào.

8.5 Quản trị, nâng cấp và ranh giới kinh tế

Ở giai đoạn pre-testnet này, BEYUL không có quản trị phi tập trung. Các nâng cấp giao thức và các pin quan trọng về bảo mật — tham số genesis và verifying key đã ghim (pinned) — được kiểm soát bởi tập validator ban đầu cùng với Owner. Đây là một mô hình tin cậy tập trung được nêu thẳng; nó sẽ chỉ được phi tập trung hóa dần khi mạng và sự quản trị của nó trưởng thành (không có DAO, không hứa hẹn lộ trình phi tập trung). Việc vận hành một validator tự nó không trao quyền nâng cấp; pinned VK và genesis chỉ được thay đổi qua đường nâng cấp "tập validator + Owner".

Ranh giới kinh tế. Denomination, nguồn cung và các tham số kinh tế là quyết định của Owner — có gate, và không được định nghĩa trong whitepaper này (xem Trạng thái token ở trên). Không có gì ở đây cố định một denomination, một nguồn cung hay một mô hình kinh tế token.

9. Mô hình mối đe dọa (công khai cho đến khi giảm thiểu)

Được tổ chức theo lớp đối thủ, đồng bộ với mô hình đối thủ của yellow paper (A1–A4). Đây là một bản tóm tắt; yellow paper là tham chiếu có thẩm quyền về mô hình mối đe dọa, và hai tài liệu không được trôi dạt — khi có khác biệt, yellow paper được ưu tiên.

• A1 — Người quan sát chuỗi thụ động (chỉ đọc dữ liệu chuỗi công khai): tương quan số tiền ở nạp/rút công khai, tương quan thời điểm, kênh phụ phí/gas — chưa giảm thiểu. Commitments, nullifiers, anchors và tài khoản dòng ròng của pool là công khai theo thiết kế.
• A2 — Đối thủ mạng/hạ tầng (mempool, RPC, sắp xếp validator, IP): quan sát mempool, sắp xếp và kiểm duyệt validator, siêu dữ liệu lớp mạng — chưa giảm thiểu (sắp xếp/kiểm duyệt một phần ngoài phạm vi giao thức); siêu dữ liệu sàn/cầu nối ngoài giao thức — ngoài phạm vi.
• A3 — Đối thủ phía tiết lộ (người nhận tiết lộ hoặc người giữ một mã): việc một người nhận chuyển tiếp tiết lộ là không kiểm soát được về mặt mật mã; thu hồi chưa triển khai; phơi bày chuỗi thời gian và giá trị ròng của ADC khi chụp lặp lại; phát hành bị cưỡng ép — nói thẳng, chưa giảm thiểu.
• A4 — Đối thủ endpoint/social (thiết bị người dùng, phishing): phishing và social engineering nhắm mnemonic hoặc mã, ví giả và kênh chính thức giả — chưa giảm thiểu; xử lý qua giáo dục người dùng và danh sách kênh chính thức.

Xuyên suốt, chưa giải quyết: lỗi mạch, trusted setup, kiểm toán bên ngoài — chưa xác minh / chưa giải quyết / chưa hoàn tất. Tính toàn vẹn nguồn cung của pool (gate G-S) đang mở; bảo toàn và double-spend không được tuyên bố là thuộc tính sản xuất, đang chờ value-balance in-circuit và keeper với tính nhất quán độ rộng 128↔64 bit (phản chiếu yellow paper §12.3). Sự nhầm lẫn về giá trị token testnet và phần thưởng không được phép — token thử nghiệm không có giá trị, và mọi hạch toán phần thưởng đều là mô phỏng.

10. Roadmap (dựa trên gate, không hứa hẹn ngày tháng)

Mỗi năng lực phải ở đúng một trạng thái: Implemented / Local tested / Prototype / Documentation only / Planned / Unverified / Not implemented. Không tuyên bố nào có thể được viết là "đã triển khai" mà không có commit, bản ghi CI, lệnh kiểm thử và đầu ra.

Thứ tự không thể đảo ngược: testnet → TDC MVP → ADC_L1 → root-bound verification → production ZK → ADC_L2 → audit → pre-mainnet.

11. Ranh giới tuân thủ

BEYUL không phải một giải pháp tuân thủ: nó không triển khai các quy trình AML, KYC, travel-rule, đóng băng, sàng lọc trừng phạt hay báo cáo, và không tuyên bố "compliant by design". Mọi tiết lộ do người dùng khởi xướng; giao thức không có kênh tiết lộ cưỡng bức; thiết kế hiện tại không bao gồm một viewing key toàn cục do dự án kiểm soát (sẽ xác minh qua triển khai mở và kiểm toán). Các tổ chức và cá nhân nên tự đánh giá độc lập lập trường quản lý của khu vực tài phán của mình đối với tài sản riêng tư.

12. Tuyên bố rủi ro và miễn trừ

Tài liệu này chỉ nhằm mục đích thông tin và không cấu thành, và không được diễn giải là: một lời chào bán hay bán một chứng khoán, hàng hóa hoặc công cụ tài chính; tư vấn đầu tư, pháp lý, thuế hoặc tài chính; hoặc một tuyên bố về tuân thủ ở bất kỳ khu vực tài phán nào. Nó chứa các tuyên bố hướng tới tương lai (mục tiêu thiết kế, kế hoạch testnet, roadmap) chịu sự bất định đáng kể; kết quả thực tế có thể khác biệt đáng kể.

Dự án này hiện không có token nào được phát hành; token testnet, nếu được dùng, không có giá trị tiền tệ. Tham gia các mạng tài sản tiền mã hóa tiềm ẩn rủi ro đáng kể. Hãy tự nghiên cứu và tham vấn cố vấn chuyên môn. Khi bất kỳ bản dịch nào mâu thuẫn với phiên bản tiếng Anh chuẩn này, phiên bản tiếng Anh này được ưu tiên. Tuyên bố miễn trừ này là một mẫu chung và phải được luật sư ở khu vực tài phán liên quan rà soát trước bất kỳ công bố công khai chính thức nào.

13. Kết luận

Hướng đi của BEYUL là quyền riêng tư theo mặc định với tiết lộ do người dùng kiểm soát. Các tài sản đáng tin cậy của nó hôm nay: một nguyên mẫu chain-application, một nguyên mẫu suy dẫn TDC/ADC phía client đã kiểm thử cục bộ, và một bảng trạng thái cùng mô hình mối đe dọa được giữ căn chỉnh chặt chẽ với triển khai. Trọng tâm duy nhất hiện tại là các điều kiện tiên quyết để ra mắt testnet công khai: đóng bằng chứng, runbook đa nút, faucet và giám sát, tài liệu người tham gia. Cho đến khi bằng chứng tương ứng tồn tại, dự án này không đưa ra tuyên bố về mainnet, token, quyền riêng tư sản xuất hay tuân thủ.