Địa chỉ ẩn danh + Tài khoản phụ cho tài khoản 7702

Chào mọi người!! Tôi muốn trình bày ý tưởng của mình (nghiên cứu + bằng chứng khái niệm) và nhận một số phản hồi hoặc góp ý.

Địa chỉ ẩn danh + Tài khoản phụ (3) 1920×1124 90.4 KB

Những điểm chính:

1. Khóa gốc có thể là một tài khoản 7702 hiện có.

2. Khóa chi tiêu và Khóa xem phải được cất giữ trong hộp an toàn (ví dụ: KMS/HSM/MPC).

3. Việc phát hiện địa chỉ ẩn danh yêu cầu lưu trữ siêu dữ liệu Yêu cầu bình luận Ethereum (ERC)-5564: viewTag (1 byte) và ephemeralPublicKey (33 byte).

4. Siêu dữ liệu này có thể được lưu trữ trong bộ nhớ hợp đồng, nhật ký sự kiện, bộ nhớ cục bộ/máy khách hoặc máy chủ phụ trợ (tùy thuộc vào yêu cầu về trải nghiệm người dùng và quyền riêng tư).

Ghi chú:

1. Có thể tạo ra N địa chỉ ẩn từ một địa chỉ meta duy nhất.

2. Mỗi địa chỉ được tạo ra có thể đại diện cho một tài khoản phụ chuyên dụng dành cho các dịch vụ đăng ký, giao dịch riêng tư, thanh toán riêng tư hoặc kênh thanh toán.

3. Yêu cầu tạo tài khoản có thể đến từ bên thứ ba (thông qua API), được người dùng phê duyệt, và sau đó được thực thi đối với việc triển khai tài khoản với chính sách chi tiêu trên tài khoản phụ on-chain.

4. Tài khoản phụ có thể được nạp tiền theo cách không liên kết bằng cách sử dụng Privacy Pools hoặc các cơ chế tài trợ bảo mật khác hiện có trên thị trường.

Ví dụ có sẵn:
dựa trên: stealth/contracts/STEALTH_ARCHITECTURE.md openfort-xyz/stealth-addresses Bob sở hữu tài khoản 7702. Trong phần triển khai có các lối thoát:

 event Announcement ( uint256 indexed schemeId, address indexed caller, bytes1 indexed viewTag, bytes ephemeralPubKey, bytes metadata ) ;bytes public stealthMetaAddress; error InvalidEphemeralPubKeyLength () ; error EmptyMetadata () ; function announce ( uint256 schemeId, bytes calldata ephemeralPubKey, bytes calldata metadata ) external { // Validate ephemeral public key length (66) if (ephemeralPubKey.length != 66 ) { revert InvalidEphemeralPubKeyLength () ;} // Validate metadata contains at least viewTag if (metadata.length == 0 ) { revert EmptyMetadata () ;} // Extract viewTag from first byte of metadata bytes1 viewTag = metadata[ 0 ]; emit Announcement ( schemeId, msg.sender, viewTag, ephemeralPubKey, metadata ) ;}

Trong trường hợp này, Bob có thể tạo một tài khoản ẩn danh dựa trên st:eth:0x<spendingPubKey><viewingPubKey> của mình và gọi Stealth.announce() để công bố dữ liệu.

Thao tác này sẽ phát ra một sự kiện và lưu trữ dữ liệu một cách tiết kiệm chi phí, được gắn với tài khoản chính của Bob.

Từ góc nhìn của người ngoài, nó sẽ trông giống như dữ liệu ngẫu nhiên. Sẽ không thể suy ra địa chỉ ẩn danh hoặc khóa. Người quan sát có thể suy luận rằng Bob đang sử dụng địa chỉ ẩn danh, nhưng họ vẫn không thể LINK (Chainlink) liệu Bob đã tự thông báo cho chính mình hay cho địa chỉ ẩn danh của người dùng khác.

Mặt khác, Alice cũng có thể thông báo cho Bob rằng cô ấy đã gửi khoản thanh toán đến địa chỉ bí mật mà Bob yêu cầu.

Trong cả hai trường hợp, chúng ta đều duy trì tính không thể liên kết giữa địa chỉ ẩn danh và chủ sở hữu của nó.

Ngoài ra, khóa xem riêng tư có thể được ủy quyền cho một hệ thống giám sát đáng tin cậy, hệ thống này có thể quét siêu dữ liệu, phát hiện xem địa chỉ ẩn danh có được tạo cho khóa công khai chi tiêu cụ thể hay không và gửi tín hiệu. Sau đó, để khôi phục địa chỉ ẩn danh, chúng ta có thể thực hiện ngoại tuyến (ví dụ: trong môi trường an toàn) và khôi phục khóa riêng tư một cách an toàn để liên kết địa chỉ ẩn danh với chủ sở hữu tài khoản 7702 trong giao diện người dùng của chúng ta.

Đây là cách rẻ nhất và ít Không cần tin cậy nhất để lưu trữ siêu dữ liệu địa chỉ ẩn danh mà không cần lưu trữ khóa riêng tư ẩn danh trên máy khách hoặc máy chủ.

ERC5564 (Địa chỉ ẩn) là gì?: https://github.com/openfort-xyz/-stealth-addresses/tree/0xkoiner/dev/documentation

Diễn viên / chìa khóa

• Tài khoản ROOT 7702 : tài khoản chính của người dùng (cấp vốn + điều phối).

• KMS : lưu trữ các mã bí mật chi tiêu/xem Yêu cầu bình luận Ethereum (ERC)-5564 (hoặc bảo vệ chúng thông qua HSM/MPC).

• Khóa không thể trích xuất P-256 : khóa ký dài hạn cho việc triển khai tài khoản phụ.

• Quỹ riêng tư : được sử dụng để cấp vốn cho các tài khoản phụ mà không thể liên kết với nhau.

Giai đoạn 0 — Cung cấp “Địa chỉ siêu dữ liệu ẩn” (Yêu cầu bình luận Ethereum (ERC)-5564)

1. Tạo cặp khóa chi tiêu và cặp khóa xem (khóa nhận Yêu cầu bình luận Ethereum (ERC)-5564).

2. Lưu trữ spend_sk và view_sk trong KMS (tốt nhất là sử dụng Threshold / split-control ; chi tiết hơn ở bên dưới).

3. Công bố địa chỉ meta ẩn (= spend_pk + view_pk) ở bất cứ đâu bạn muốn (hồ sơ người dùng, registry ứng dụng, mã QR).

Lý do điều này quan trọng: bạn có thể xác định được nhiều địa chỉ ẩn dùng một lần mà không cần lưu trữ chúng.

Quan điểm của bạn vẫn đúng: bạn không lưu trữ các khóa riêng tư ẩn danh được tạo ra , mà chỉ lưu trữ các khóa gốc của người nhận .

Giai đoạn 1 — Tạo địa chỉ tài khoản phụ mới (đổi địa chỉ Yêu cầu bình luận Ethereum (ERC)-5564)

Đối với mỗi tài khoản phụ mới mà bạn muốn:

1. Tạo một cặp khóa tạm thời .

2. Tính toán (stealthAddress, viewTag) từ (epk, metaAddress) theo Yêu cầu bình luận Ethereum (ERC)-5564.

3. Tùy chọn tạo bản ghi/sự kiện thông báo để ví có thể phát hiện (nếu bạn muốn trải nghiệm người dùng thanh toán của bên thứ ba; không thực sự cần thiết đối với các tài khoản phụ tự quản lý).

Đến bước này, bạn đã có địa chỉ EOA mới , địa chỉ này sẽ trở thành tài khoản phụ 7702 của bạn.

Giai đoạn 2 — Khởi tạo tài khoản phụ 7702 bằng cách sử dụng khóa EOA được tạo ra (không lưu trữ)

Mục tiêu: sử dụng khả năng ECDSA (secp256k1) của địa chỉ ẩn danh chính xác một lần để cài đặt mã + xoay vòng quyền hạn.

1. Bên trong phạm vi dịch vụ đáng tin cậy, trích xuất khóa riêng tư ẩn danh ngay lập tức :

   • Sử dụng view_sk để quét/xác định mục tiêu (hoặc nếu bạn là người tạo ra nó, bạn đã biết đó là mục tiêu nào rồi).

   • Sử dụng spend_sk + epk (và bất kỳ thứ gì mà Yêu cầu bình luận Ethereum (ERC)-5564 quy định để tạo ra) để tính toán khóa riêng dùng một lần cho địa chỉ ẩn danh đó.

2. Chỉ sử dụng khóa riêng được tạo ra đó để ký xác thực Đề xuất cải tiến Ethereum (EIP)-7702 , xác thực này sẽ thiết lập mã cho tài khoản (việc triển khai tùy chỉnh của bạn).

3. Trong cùng quy trình thiết lập, hãy gọi initialize(...) để:

   • Đặt khóa công khai P-256 làm người ký chính (không thể trích xuất).

   • Thiết lập mô-đun giới hạn /quyền hạn của bạn.

   • Tùy chọn thiết lập chính sách “ủy quyền / khóa phiên”.

4. Xóa ngay lập tức khóa riêng ẩn được tạo ra trong bộ nhớ.

Lưu ý quan trọng (về bảo mật):

Ngay cả khi bạn "xóa bỏ" khóa riêng tư ẩn danh được tạo ra, nếu sau này ai đó xâm nhập được vào KMS (và nó có thể tính toán lại các bí mật chi tiêu/xem), họ có thể tạo lại khóa đó và ký các ủy quyền 7702 mới. Vì vậy, gốc rễ thực sự của các gốc rễ sẽ trở thành KMS . Hãy coi nó như một tài sản cấp ví phần cứng.

Giai đoạn 3 — Cấp vốn cho tài khoản phụ một cách riêng tư thông qua Privacy Pools

1. ROOT 7702 gửi ETH/ USDC/ ETC vào các Nhóm Bảo mật.

2. Sau đó, rút ​​tiền từ Privacy Pools sang stealthAddress (hiện là tài khoản thông minh 7702) .

Cách làm tốt nhất: sử dụng cơ chế chuyển tiếp/phí gốc của Privacy Pools (hoặc một bên chuyển tiếp) để tránh việc tài khoản phụ phải có sẵn ETH để trả phí gas trước khi được nạp tiền .

Giai đoạn 4 — Bắt đầu sử dụng AA bình thường (4337 + người trả lương)

Hiện tại tài khoản phụ đã có tiền và quyền kiểm soát dài hạn là P-256:

1. Sử dụng userOps 4337 được ký bởi P-256 .

2. Nếu bạn muốn được tài trợ gas:

   • hoặc giữ lại một ít ETH trong tài khoản phụ, hoặc

   • Hãy sử dụng một máy chủ thanh toán (paymaster) tính phí ERC-20 và tương thích với mô hình thực thi của bạn.

Paymaster + “rút tiền + phê duyệt trong cùng một thao tác người dùng”

Hãy cẩn thận: việc xác thực người trả tiền diễn ra trước khi thực hiện giao dịch. Vì vậy, quy trình “rút tiền rồi phê duyệt rồi trả lại cho người trả tiền” có thể khiến người trả tiền phải chịu rủi ro trừ khi hệ thống được thiết kế để chấp nhận rủi ro đó. Quy trình an toàn hơn là:

• Việc rút tiền qua PayPal sẽ chuyển tiền vào tài khoản trước , sau đó người dùng vận hành (userOps) mới có thể thanh toán/phê duyệt một cách an toàn.

Use Case: Tài khoản phụ đăng ký do người bán tạo, không thể liên kết với nhau.

Mục tiêu

Hãy để một dịch vụ đáng tin cậy (Spotify/YouTube/ChatGPT) tạo một tài khoản phụ riêng cho các đăng ký:

• Không thể liên kết on-chain với tài khoản ROOT của người dùng trên chuỗi khối.

• do người bán kiểm soát (vì vậy họ có thể tính phí hàng tháng),

• có giới hạn chi tiêu nghiêm ngặt (để người bán không thể rút hết tiền),

• Người dùng có thể thu hồi/hủy bỏ bất cứ lúc nào và lấy lại số tiền còn lại.

Một dịch vụ đáng tin cậy (Spotify, YouTube, ChatGPT) có thể yêu cầu người dùng cấp cho mình một tài khoản phụ đăng ký riêng thông qua API.

Người dùng phê duyệt yêu cầu này từ tài khoản ROOT 7702 của họ, bao gồm chính sách đăng ký (giới hạn hàng tháng, Token được phép, người nhận được phép) và khóa công khai P-256 của dịch vụ sẽ kiểm soát việc chi tiêu.

Sau khi được chấp thuận, nền tảng sẽ tạo ra một địa chỉ ẩn danh Yêu cầu bình luận Ethereum (ERC)-5564 mới thông qua KMS (do đó không cần lưu trữ khóa riêng tư được tạo ra, nhưng vẫn có thể khôi phục). Tài khoản ROOT của người dùng sau đó sẽ gửi tiền vào Privacy Pools, và sau đó số tiền đó sẽ được rút về tài khoản phụ ẩn danh mới được tạo ra theo cách tránh liên kết on-chain giữa tài khoản ROOT và tài khoản phụ.

Sau khi tài khoản phụ nhận được tiền, nó sẽ được nâng cấp thông qua ủy quyền Đề xuất cải tiến Ethereum (EIP)-7702 thành một triển khai tài khoản thông minh tùy chỉnh và được khởi tạo sao cho khóa P-256 của dịch vụ trở thành người ký hoạt động, với các giới hạn chi tiêu nghiêm ngặt và quyền thực thi được thực thi on-chain.

Kể từ thời điểm đó, dịch vụ có thể tính phí đăng ký định kỳ trong phạm vi các giới hạn đã cấu hình, trong khi người dùng vẫn giữ được một lối thoát: Root Key có thể thu hồi dịch vụ bất cứ lúc nào, khôi phục quyền kiểm soát (thông qua đường dẫn dẫn xuất/khôi phục được hỗ trợ bởi KMS) và rút bất kỳ số dư còn lại nào mà không tiết lộ kết nối trực tiếp on-chain với tài khoản ROOT chính.