Mạng chính Aptos sẽ sớm cho phép 🔒 tài sản bí mật 💸!! tức là, số dư được mã hóa & số tiền giao dịch 🔐, mặc dù địa chỉ người gửi & người nhận vẫn có thể nhìn thấy công khai 🌍! (Một bước một lần, mọi người...) Dưới đây là cách chúng hoạt động! 🤓👇

Tài sản bí mật của Aptos xây dựng dựa trên và mở rộng công việc trước đây. Chúng tôi mã hóa số dư trên chuỗi bằng cách sử dụng Twisted ElGamal, giống như PGC (). Điều này kết hợp tốt với Bulletproofs để chứng minh rằng một số dư đã được mã hóa đã bị trừ đúng cách sau khi gửi/rút bí mật.

Hoặc, như tôi thường nói [và bị chế nhạo ở điểm này]... "Xem blog của tôi!"

*Tính năng 1:* Khác với PGC và Solana, các ciphertext ElGamal xoắn của chúng tôi được _chia nhỏ một cách quyết liệt_ để đảm bảo giải mã siêu nhanh trong khi xử lý số dư & số lượng khoảng ~256 bit. Chúng tôi gọi đây là *ElGamal chia nhỏ và xoắn.* Để bạn biết, Aptos chỉ cần số dư 128 bit & số lượng 64 bit.

Đối với Aptos, việc chia nhỏ đảm bảo rằng trường hợp log rời (DL) tối đa cần được giải quyết trong quá trình giải mã là 32-bit, trong trường hợp xấu nhất (và nhỏ hơn nhiều trong thực tế). => dễ dàng giải quyết trong 2^16 phép cộng đường cong elliptic bằng cách sử dụng các thuật toán đơn giản như baby-step giant-step (BSGS)👇

*Tính năng 2:* Chúng tôi tăng tốc BSGS cho lựa chọn đường cong elliptic Ristretto255 của chúng tôi thông qua các nén theo lô. Chúng tôi cũng giảm kích thước bảng đã tính toán trước của nó xuống 4 lần (=> giảm kích thước SDK của các dapps bí mật & độ trễ) Chúng tôi gọi thuật toán mới này là *BSGS-k cắt ngắn (TBSGS-k).*

Tôi đã nói về thuật toán này trước đây: ...nhưng không nhấn mạnh được *tại sao*: TBSGS-k là xác định => dễ triển khai và kiểm tra hơn. TBSGS-k chỉ chậm hơn khoảng ~2 lần (10.6 ms so với 4.8 ms) so với thuật toán [BL12] phức tạp hơn, và chỉ có bảng lớn hơn 2 lần.

*Tính năng 3:* Khi kiểm toán được kích hoạt, chúng tôi duy trì một mã hóa có thể chứng minh là chính xác của số dư (có sẵn) của mỗi người dùng dưới khóa mã hóa của kiểm toán viên (EK). Điều này ngăn cản các kiểm toán viên quét các giao dịch của người dùng để tái tạo số dư của họ. Khóa: nó cho phép xoay vòng EK của kiểm toán viên 👌

*Tính năng 4:* Trong Aptos, việc _xoay vòng_ khóa ký của người dùng là một tính năng bảo mật trung tâm. Vì vậy: chúng tôi cũng thiết kế tài sản bảo mật để hỗ trợ việc xoay vòng khóa *giải mã* của người dùng! Hiện tại, các chính sách quản lý khóa được để cho các ứng dụng/ ví (những lời cuối nổi tiếng 🤞).

Tin tốt: Các dapp bảo mật không cần khóa có thể an toàn tái sử dụng 🌶️ của chúng như một khóa giải mã! () ==> không có gánh nặng quản lý khóa bổ sung nào được giới thiệu cho các ứng dụng như vậy ==> cách dễ nhất để xây dựng một dapp bảo mật là dưới dạng dapp không cần khóa; không cần [hỗ trợ] ví!

*Tính năng 5:* Triển khai crypto(*đồ họa*) bảo vệ quỹ của người dùng thực sự là điều đáng sợ. Để giảm thiểu lỗi (🤞), chúng tôi sử dụng một phương pháp mà hầu hết mọi người đều bỏ qua để thiết kế và xây dựng các giao thức Sigma một cách an toàn: *khung đồng nhất,* mà tôi đã phát hiện trong cuốn sách của @danboneh 🙏

*Tính năng 6:* Triển khai tài sản bí mật sẵn sàng cho sản xuất đầu tiên trong Move. Mã hiện đang ở chế độ riêng tư trong khi đang được kiểm toán, nhưng sẽ sớm được phát hành. Đây là một đoạn giới thiệu về cách mà việc chuyển giao bí mật có thể đơn giản như thế nào 👇

Ngoài ra, vì tôi không thể không làm điều đó, đây là một phần của khung homomorphism Sigma-protocol được triển khai trong Move 😍

*Tính năng 7:* Đặc tả mã hóa đầy đủ với các chứng minh an ninh. (Chà, có thể chúng ta có thể vibe mã nó trong @leanprover?) Sẽ sớm ra mắt, với những chi tiết hấp dẫn, trong một eprint bên cạnh bạn 👇

Cuối cùng, hãy ghi nhận công lao: Tài sản bí mật của Aptos xây dựng và mở rộng những ý tưởng được giới thiệu trong các công trình trước đây 👇 1. Zether (): giải quyết vấn đề "trước chạy" của mô hình tài khoản cố định thông qua số dư đang chờ.

2. PGC (): đề xuất Twisted ElGamal + Bulletproofs như một lựa chọn đơn giản hơn cho \Sigma-bullets. Điều này giảm đáng kể độ phức tạp trong việc triển khai: chúng ta chỉ cần tập trung vào việc thiết kế chính xác các giao thức Sigma của mình! Việc kết hợp an toàn được lập luận dưới đây 👇

3. Solana (): cho phép các khoản chuyển nhượng 48-bit bằng cách chia số dư đang chờ thành một phần "cao" 32-bit và một phần "thấp" 16-bit. Chúng tôi cho phép các khoản lớn hơn bằng cách sử dụng nhiều phần hơn & bằng cách chia nhỏ số dư có sẵn nữa.

Cuối cùng nhưng không kém phần quan trọng, tôi muốn cảm ơn @mstrakastrak và các bạn ở @distributedlab, những người đã giúp thiết kế phiên bản ban đầu của giao thức tài sản bí mật và triển khai nó trong Move và TypeScript 🖖 Hãy chú ý đến bài báo chung của chúng tôi sắp ra mắt!