# pERC20: Tiêu chuẩn token riêng tư (Bản dự thảo)

Tác giả: Cyimon ( @Cyimon ) · Trạng thái: Bản nháp · Loại: Theo dõi tiêu chuẩn (Yêu cầu bình luận Ethereum (ERC)) · Đề xuất cải tiến Ethereum (EIP) : 8287 (PR) · Ngày tạo: 09/06/2026

Mô tả: Một Tiêu chuẩn token Có thể hoán đổi cho Máy ảo Ethereum (EVM) , mặc định là riêng tư.

Thảo luận: ethresear.ch #25089 · Ethereum Magicians #28702 · Triển khai: PERC20Labs/pERC20_

Chúng tôi mở rộng thiết kế giao thức pERC20 đã được công bố trước đó ( Ethereum Magicians #28702 / ethresear.ch #25089 ). Điểm bổ sung chính trong bản sửa đổi này là việc chi tiêu được phê duyệt theo chuẩn ERC-20 — approve , allowance và transferFrom — thông qua các tài khoản phụ ZIP-32 . Tiêu chuẩn được cập nhật hoàn chỉnh về khả năng với ERC-20 nhưng không tương thích về byte (ABI khác nhau, không có số dư công khai).

Dưới đây là tiêu chuẩn pERC20 mới nhất: Tiêu chuẩn token riêng tư .

Tóm tắt

pERC20 là một Tiêu chuẩn token Có thể hoán đổi, mặc định là riêng tư, dành cho Máy ảo Ethereum (EVM): phiên bản bảo mật của ERC-20 . Về cơ bản, nó sử dụng mô hình nhóm được bảo vệ Orchard từ Đặc tả Giao thức Zcash . Nó giữ nguyên giao diện phương thức đầy đủ của Yêu cầu bình luận Ethereum (ERC)-20, nhưng một số phương thức là riêng tư (chỉ người nắm giữ, Ngoài chuỗi) thay vì đọc công khai on-chain , và các thao tác transfer / approve / transferFrom đều xuất hiện on-chain như cùng một thao tác transfer . Xem Giao diện pERC20 bên dưới.

Động lực

Sổ cái công khai của Ethereum giúp mọi số dư, giao dịch chuyển khoản và hạn mức ERC-20 luôn hiển thị rõ ràng. Khi các hoạt động thanh toán, trả lương, Treasury và tài chính on-chain chuyển sang L1, người dùng và nhà phát hành cần các token Có thể hoán đổi riêng tư — chứ không chỉ là nhắn tin riêng tư xung quanh số dư công khai.

Vấn đề bảo mật ngày càng được giải quyết ở lớp giao thức. Ví dụ, Đề xuất cải tiến Ethereum (EIP)-8182 định nghĩa một nhóm bảo mật được quy định trong giao thức : người dùng gửi ETH công khai hoặc các token ERC-20 tương thích, chuyển giá trị một cách riêng tư trong nhóm chia sẻ và rút về dạng công khai. Mô hình đó bảo vệ các tài sản công khai hiện có ; nó không định nghĩa cách phát hành một Token được giữ bí mật ngay từ khi tạo ra .

pERC20 lấp đầy khoảng trống thứ hai. Nó là một Tiêu chuẩn token lớp ứng dụng dành cho các token Có thể hoán đổi riêng tư, có thể hoán đổi : được tạo, nắm giữ, chuyển nhượng và chi tiêu thông qua approve / transferFrom dưới dạng các ghi chú riêng tư ngay từ đầu, không có giai đoạn balanceOf công khai và không có khoản tiền gửi vào một nhóm được bảo vệ chung. Nó quy định phiên bản riêng tư tương ứng với ERC-20 — cùng một giao diện phương thức, nhưng độ mở khác nhau — do đó các nhà phát hành có thể ra mắt tài sản riêng tư ngay hôm nay trong khi tính riêng tư ở cấp độ giao thức (ví dụ: Đề xuất cải tiến Ethereum (EIP)-8182) đang phát triển song song. Hai tiêu chuẩn này bổ sung cho nhau, chứ không cạnh tranh: Đề xuất cải tiến Ethereum (EIP)-8182 tư nhân hóa tài sản công khai; pERC20 định nghĩa việc phát hành tài sản riêng tư.

Thông số kỹ thuật

Các từ khóa MUST , MUST NOT , SHOULD , MAY được hiểu theo RFC 2119. Cú pháp Solidity là phiên bản 0.8.20 trở lên.

Giao thức cơ bản

Giá trị được nắm giữ trong các ghi chú được bảo vệ, không phải số dư tài khoản. Định dạng ghi chú, các yếu tố hủy bỏ, cây cam kết, mã hóa ghi chú và cấu trúc hành động/gói tuân theo nhóm bảo vệ Orchard trong Đặc tả Giao thức Zcash , được điều chỉnh ở đây thành hợp đồng Máy ảo Ethereum (EVM) trên mỗi tài sản đã được xác minh bằng Groth16. Các định dạng cấp trường không được lặp lại bên dưới là tiêu chuẩn trong phần Triển khai Tham chiếu .

Giao diện pERC20

Phần này liệt kê tất cả các giao diện pERC20 ở cùng một chỗ và đánh dấu xem mỗi giao diện có tương ứng với giao diện tiêu chuẩn ERC-20 hay không. ERC-20 : yes = tiêu chuẩn ERC-20 ; extension = phần mở rộng chung (Mint/ghi); no = dành riêng cho pERC20. Lớp : on-chain = ABI hợp đồng; off-chain = ví/SDK (không phải phương thức hợp đồng).

Sự kiện

Tính không thể phân biệt on-chain . Các thao transfer , bước cấp vốn của approve , transferFrom và revoke-sweep đều là cùng một lệnh gọi on-chain : transfer(PrivacyCall) . Người quan sát không thể biết được thao tác ERC-20 nào đang được thực hiện.

Không được hỗ trợ nguyên bản. approve(contractAddress, amount) của Yêu cầu bình luận Ethereum (ERC)-20 — một hợp đồng tự động gọi transferFrom — không có phương thức tương đương nguyên bản: việc chi tiêu yêu cầu khóa riêng tư, mà hợp đồng không thể nắm giữ. Xem phần Giải thích.

Giao diện hợp đồng

pERC20 cung cấp một ABI on-chain ( IPERC20 ; xem Giao diện pERC20 ở trên). Các phương thức được đánh dấu Ngoài chuỗi trong bảng đó không có điểm truy cập hợp đồng; hành vi được chỉ định trong Ngữ nghĩa phương thức bên dưới.

 interface IPERC20 {struct PrivacyCall { bytes actions; uint256[3] bindingSig; }struct BundleAction {bytes32 cmx;bytes encCiphertext;bytes outCiphertext;bytes32 epk;bytes32 nfOld; // nullifier of the consumed (or dummy) input notebytes32 anchor; // historical root of the consumed (or dummy) input notebytes proof;uint256[8] pubFields;uint256[3] spendAuthSig;}// ERC-20-aligned public viewsfunction name() external view returns (string memory);function symbol() external view returns (string memory);function decimals() external view returns (uint8);function totalSupply() external view returns (uint256);function issuer() external view returns (address);// Value-changing operations (private parties; see Method Semantics)function transfer(PrivacyCall calldata call) external returns (bool success);function mint(uint256 amount, PrivacyCall calldata call) external;function burn(uint256 amount, PrivacyCall calldata call) external;// Compliancefunction cmxFrozenRoot() external view returns (uint256);function setFrozenRoot(uint256 newRoot) external; // onlyAdmin// Note state machine (Orchard commitment tree)function cmxRoot() external view returns (bytes32);function isValidAnchor(bytes32 root) external view returns (bool);function isSpent(bytes32 nf) external view returns (bool);function treeSize() external view returns (uint256);event Mint(address indexed issuer, uint256 amount);event Burn(uint256 amount);event FrozenRootUpdated(uint256 oldRoot, uint256 newRoot);event Perc20Created(address indexed pool, address indexed issuer,string name, string symbol, uint8 decimals);event NoteAdded(bytes32 indexed cmx, bytes encCiphertext, bytes outCiphertext,bytes32 epk, bytes32 nfOld, bytes32 cvNetX);event NoteConfirmed(bytes32 indexed cmx, bytes32 newRoot, uint256 position);event BundleExecuted(uint256 valueBalance, uint256 amount, bytes32 recipientMeta);}

Tuân thủ:

• Giao transfer khoản thành công PHẢI trả về true .
• Đường dẫn thực thi gói lõi KHÔNG ĐƯỢC phép gọi công khai (bất biến nguồn cung cấp; xem bên dưới).
• Các triển khai CÓ THỂ chia Solidity thành nhiều hợp đồng (ví dụ: IPERC20 + cơ sở xác minh), nhưng ABI quan sát được và các sự kiện PHẢI khớp với giao diện thống nhất ở trên.
• cmxRoot() là gốc cây cam kết mới nhất; isValidAnchor(root) trả về true nếu và chỉ nếu root đã từng hoạt động; isSpent(nf) hiển thị tập hợp nullifier; treeSize() là số lượng cam kết đã được chèn.

Định dạng cuộc gọi

Mỗi thao tác thay đổi giá trị đều gửi một PrivacyCall mã hóa một hoặc nhiều hành động Orchard ( Thông số kỹ thuật giao thức Zcash ):

• actions = abi.encode(BundleAction[]) .
• bindingSig = Chữ ký ràng buộc Schnorr [Rx, Ry, s] chứng minh sự bảo toàn giá trị.

Mỗi BundleAction là một hành động Orchard được điều chỉnh để xác minh Máy ảo Ethereum (EVM) : một cam kết ghi chú đầu ra ( cmx ) cộng với tài liệu chứng minh cho đầu vào (thực hoặc giả) của nó. pubFields PHẢI được sắp xếp theo thứ tự sau (đầu vào chính của Hành động Orchard):

Mỗi pubFields[i] PHẢI nhỏ < Fr , trong đó Fr là môđun trường vô hướng của đường cong SNARK được trình xác minh sử dụng (BN254 trong triển khai tham chiếu); nếu không thì hoàn tác ( PubFieldOutOfRange ). Các triển khai Hash tám trường thành một tín hiệu công khai Groth16 thông qua ActionPubHash (Poseidon sponge), khớp với PubHashAction() của mạch.

Liên kết với các trường dữ liệu cuộc gọi. Các đầu vào công khai của bằng chứng PHẢI khớp với các trường cấp cao nhất của hành động; các triển khai PHẢI hoàn nguyên nếu bất kỳ điều nào sau đây thất bại:

Nếu không có các kiểm tra về sự bằng nhau giữa pubFields và calldata, một bằng chứng hợp lệ có thể được phát lại với nfOld hoặc cmx khác, bỏ qua bộ vô hiệu hóa hoặc chèn một cam kết chưa được chứng minh.

encCiphertext PHẢI có kích thước 580 byte (văn bản gốc của ghi chú Orchard + thẻ AEAD dưới khóa của người nhận). Văn bản mã outCiphertext NÊN có kích thước 80 byte (khả năng tự phục hồi của người gửi dưới OVK). Các triển khai thay đổi bố cục mã hóa ghi chú PHẢI công bố một biến thể riêng của Yêu cầu bình luận Ethereum (ERC) này.

Chữ bindingSig cấp gói PHẢI được xác minh trên tất cả các bộ hủy hành động, cam kết và valueBalance của hoạt động trước khi thực hiện bất kỳ thay đổi trạng thái nào (xem Ngữ nghĩa phương thức để biết mã hóa).

Lưu ý rằng việc mã hóa và tạo khóa tuân theo định dạng ghi chú Orchard trong Đặc tả Giao thức Zcash ; mã hóa chính xác có trong kho lưu trữ triển khai tham chiếu.

Ngữ nghĩa phương pháp

name / symbol / decimals / totalSupply

Tương tự như ERC-20: hiển thị công khai on-chain .

transfer(PrivacyCall) → bool

Sử dụng các ghi chú Orchard đầu vào và tạo ghi chú đầu ra trong một gói hành động bảo toàn giá trị ( valueBalance == 0 ). Người gửi, người nhận và số tiền PHẢI được giữ bí mật. Trả về true nếu thành công; phát ra NoteAdded / NoteConfirmed , không phải Transfer(from,to,value) .

mint(amount, PrivacyCall) / burn(amount, PrivacyCall)

Quy trình xác minh hành động Orchard tương tự như transfer , với hạch toán totalSupply công khai:

• mint : totalSupply += amount ( onlyIssuer ); amount công khai, recipient riêng tư. Mint PHẢI sử dụng cùng một đường dẫn neo / vô hiệu hóa / ủy quyền chi tiêu như transfer (không có nhánh chỉ xuất). Mạch PHẢI giới hạn đầu vào đã tiêu thụ ở mức v = 0 để hành động thể hiện dòng tiền ròng; hợp đồng không đọc trực tiếp giá trị ghi chú.
• burn : totalSupply -= amount ; bất kỳ holder CÓ THỂ đốt tiền của chính mình; amount công khai, thiết bị đốt riêng tư.

balanceOf (Ngoài chuỗi, riêng tư)

Chỉ holder có thể tính toán số dư của họ bằng cách quét các sự kiện NoteAdded , giải mã thử các ghi chú Orchard bằng khóa xem của họ và loại trừ các mã hủy đã sử dụng. Không có balanceOf on-chain và không có cách nào để truy vấn số dư của bên thứ ba.

approve / allowance / transferFrom (ngữ nghĩa Ngoài chuỗi ; on-chain = transfer )

Chi tiêu được phê duyệt ( approve / allowance / transferFrom ) được xây dựng trên các tài khoản phân cấp ZIP-32 : mỗi người chi tiêu EOA nhận được một tài khoản phụ chuyên dụng ( account_S ) với các khóa chi tiêu và xem riêng, được cách ly về mặt mật mã khỏi tài khoản chính của chủ sở hữu và khỏi mọi người chi tiêu khác. ZIP-32 định nghĩa quá trình tạo khóa; Yêu cầu bình luận Ethereum (ERC) này ánh xạ ERC-20 approve / transferFrom lên đó như sau:

1. approve(spender, N) — Chủ sở hữu tạo ra một tài khoản phụ ZIP-32 chưa sử dụng, cấp vốn cho tài khoản đó bằng N thông qua transfer(PrivacyCall) và chuyển giao khóa chi tiêu của tài khoản phụ đó cho người chi tiêu EOA (được mã hóa Ngoài chuỗi). On-Chain: một lần transfer .
2. allowance(owner, spender) — Số dư còn lại của tài khoản phụ đó, được quét bằng khóa xem tài khoản phụ. Không có ánh xạ on-chain .
3. transferFrom(owner, to, amount) — Người chi tiêu dùng tiền từ tài khoản phụ để thanh toán to ; tiền thừa được trả lại vào tài khoản phụ. On-Chain: một transfer .
4. approve(spender, 0) / thu hồi — Chủ sở hữu chuyển transfer lại tài khoản phụ.

Giới hạn cho phép được thực thi bởi số dư thực tế của tài khoản phụ, chứ không phải bởi bộ đếm on-chain . Ví phân biệt tài sản "của riêng mình" và tài sản "được cho phép" bằng cách sử dụng khóa xem nào đã giải mã ghi chú — không có dấu hiệu nào on-chain .

Yêu cầu thực thi

Máy trạng thái on-chain được bảo vệ Orchard ( Thông số kỹ thuật giao thức Zcash ). Các triển khai PHẢI:

• Duy trì một tập hợp các bộ vô hiệu hóa; KHÔNG ĐƯỢC sử dụng cùng một nf hai lần.
• Duy trì cây cam kết chỉ cho phép thêm vào; các gốc lịch sử có thể được truy vấn thông qua isValidAnchor .
• Xác minh bằng chứng Groth16, xác thực chi tiêu và chữ ký ràng buộc, và tất cả các kiểm tra ràng buộc pubFields (không chỉ pubFields[7] ).
• Từ chối các cam kết trùng lặp hoặc bằng không; từ chối các mảng hành động trống; giới hạn số hành động mỗi lần gọi ( maxActions , một giới hạn dương hữu hạn có thể cấu hình).
• Chỉ công khai các thay đổi về giá trị thông qua mint / burn / transfer (không có điểm truy cập gói công khai).
• Phát ra Perc20Created một lần khi triển khai (khuyến nghị triển khai từ nhà máy nhưng không bắt buộc).

Tuân thủ. cmxFrozenRoot() là gốc của SMT danh sách đen Ngoài chuỗi ; mạch chứng minh việc không thuộc về các ghi chú đã chi tiêu. setFrozenRoot chỉ dành cho admin ; gốc ban đầu 0 biểu thị một danh sách đen trống. Các triển khai CÓ THỂ chấp nhận gốc ngay trước đó trong một khoảng thời gian ân hạn Short sau khi cập nhật để các bằng chứng đang xử lý không bị mắc kẹt.

Lý do

• Mô hình Orchard ZK-UTXO. Các ghi chú, bộ khử nhiễu và cây cam kết tuân theo Đặc tả Giao thức Zcash ; Yêu cầu bình luận Ethereum (ERC) này định nghĩa giao diện Token riêng tư và triển khai trên mỗi tài sản trên Máy ảo Ethereum (EVM).
• ERC-20 riêng tư, không phải là một loại tài sản khác. Phương thức xử lý vẫn như cũ; sự riêng tư làm thay đổi tính công khai (chế độ xem công khai so với truy vấn riêng tư so với chuyển giao không thể phân biệt), chứ không phải ý định của người dùng.
• Một thao tác on-chain cho tất cả các chuyển khoản. Việc gộp các thao tác transfer / approve / transferFrom sẽ loại bỏ siêu dữ liệu phê duyệt mà ERC-20 không thể tránh khỏi bị rò rỉ.
• Chi tiêu được phê duyệt thông qua các tài khoản phụ ZIP-32 . Mỗi người chi tiêu EOA nhận được một tài khoản phân cấp riêng biệt thay vì ánh xạ allowance on-chain ; xem Ngữ nghĩa phương thức.
• Không approve(contract) . Một hợp đồng không có khóa riêng; việc đặt khóa chi tiêu on-chain sẽ làm lộ nó cho mọi người. Chi tiêu riêng tư có thể lập trình (ghi chú được ủy quyền theo điều kiện, lưu ký MPC) là công việc trong tương lai, không phải là một phần của Yêu cầu bình luận Ethereum (ERC) này.
• Hành vi của ví nằm ngoài phạm vi của ABI on-chain . Việc bố trí tài khoản phụ, phân phối khóa mã hóa và quét ghi chú là trách nhiệm của ví/SDK; xem triển khai tham chiếu.

Khả năng tương thích ngược

pERC20 có đầy đủ khả năng tương thích với ERC-20 nhưng không tương thích về mặt byte : không có balanceOf công khai, không có allowance on-chain , không có ABI ` approve / transferFrom , không có các sự kiện ` Transfer / Approval . Các trình lập chỉ mục ERC-20 hiện có và các hợp đồng có thể kết hợp không thể vận hành nó nếu không có ví/SDK bảo mật thông tin.

Tùy chọn kết bridgeOut đến một thiết bị song sinh ERC-20 công cộng CÓ THỂ chấm dứt quyền riêng tư khi kết thúc; điều này không bắt buộc theo đề xuất này.

Các trường hợp thử nghiệm

Kho lưu trữ mã nguồn tham chiếu bao gồm:

• Các bài kiểm tra đơn vị Foundry ( test/PERC20Test.t.sol ): các điều kiện bảo vệ hàm tạo, tính toán Mint/đốt/chuyển, các bất biến nguồn cung.
• Kiểm tra đầu cuối ( test/PERC20E2E.t.sol , e2e/ ): bằng chứng Groth16 thực tế chống lại PERC20 đã triển khai, bao gồm Mint, chuyển, đốt và approve / transferFrom từ.

Triển khai tham chiếu

Mã số

Mã nguồn tham khảo: PERC20Labs/pERC20_ .

• Hợp đồng tài sản chuẩn: contracts/ptoken/PERC20.sol ( IPERC20 ).
• Các định dạng mã hóa và ví (tạo khóa, địa chỉ perc1 , mã hóa ghi chú, bộ khử nhiễu, đóng gói approve ): thư viện tham chiếu và SDK trong cùng một kho lưu trữ.

Các tiêu chuẩn và quy trình liên quan

• Đề xuất cải tiến Ethereum (EIP)-20 : Tiêu chuẩn token — giao diện Token Có thể hoán đổi công khai mà pERC20 ánh xạ tới.
• Đặc tả giao thức Zcash : Nhóm bảo vệ Orchard — các cam kết ghi chú, bộ hủy bỏ, mã hóa ghi chú và cấu trúc hành động được điều chỉnh ở đây để xác minh Máy ảo Ethereum (EVM) Groth16.
• ZIP-32 : Ví điện tử phân cấp xác định được bảo vệ — việc tạo tài khoản phân cấp được sử dụng cho các tài khoản phụ theo từng người chi tiêu trong approve / transferFrom .

Các vấn đề liên quan đến an ninh

• Bảo vệ chi tiêu kép : tập hợp nullifier + dẫn xuất nf chính xác. Mỗi pubFields[i] PHẢI nhỏ < Fr (nếu không nf + Fr sẽ sử dụng lại bằng chứng với khóa isSpent khác); pubFields[0] , [3] , [6] PHẢI bằng anchor , nfOld , cmx tương ứng (nếu không một bằng chứng hợp lệ có thể được liên kết với calldata khác nhau).
• Nguồn cung không thay đổi : giá trị chỉ thay đổi thông qua mint / burn / transfer ; đường dẫn thực thi cốt lõi KHÔNG ĐƯỢC phép gọi công khai.
• Bảo toàn giá trị : các chữ ký ràng buộc được xác minh trước khi trạng thái thay đổi.
• Bảo vệ chống phát lại : sighash liên kết chainId , địa chỉ hợp đồng và tất cả nf / cmx .
• Khóa chi tiêu tài khoản phụ : các khóa được cung cấp để approve CHỈ được xuất hiện dưới dạng mã hóa; không bao giờ được lưu trữ trong hợp đồng.
• Quyền hạn tuân thủ : setFrozenRoot là một vai trò quản trị viên có độ tin cậy cao; NÊN sử dụng multisig/timelock.

Vấn đề về quyền riêng tư

• Các hoạt động NÊN được gửi qua một trung gian để che giấu thông tin người gửi EOA.
• amount mint / burn và totalSupply là thông tin công khai; số tiền chuyển khoản và các mối quan hệ approve là thông tin riêng tư.
• approve / transferFrom không thể phân biệt được với transfer on-chain (cùng một bộ chọn transfer(PrivacyCall) ); mint / burn là các chức năng riêng biệt với số lượng công khai.
• Việc giải mã thử nghiệm là ranh giới tin cậy để xác nhận việc nhận tiền: chỉ riêng sự kiện NoteAdded không chứng minh được việc thanh toán; mạch điện không xác minh rằng encCiphertext khớp với cmx .
• setFrozenRoot cho phép quản trị viên đóng băng các ghi chú đã được xác định thông qua danh sách đen Ngoài chuỗi ; đây là sự đánh đổi rõ ràng về mặt tuân thủ so với sự không cần tin tưởng hoàn toàn.

Bản quyền

Bản quyền và các quyền liên quan đã được từ bỏ theo giấy phép CC0 .

Vui lòng trích dẫn tài liệu này như sau: Cyimon, “Yêu cầu bình luận Ethereum (ERC)-8287: Tiêu chuẩn token riêng tư”, Đề xuất cải tiến Ethereum , tháng 6 năm 2026.