Tác giả: ChiHaoLu (chihaolu.eth) Nguồn: medium Dịch: Shanoba, Golden Finance

Bài viết này tập trung vào việc phát triển Account Abstraction (AA) trong giải pháp Aztec Layer 2 và các nội dung liên quan. Tôi trích dẫn một số tài nguyên chính thức của Aztec, bao gồm tài liệu chính thức, blog và hướng dẫn. Hãy tìm những tài nguyên tuyệt vời này trong phần tài liệu tham khảo ở cuối bài viết!

Bối cảnh

Do sự phức tạp ngày càng tăng của Aztec so với các triển khai AA gốc khác trong ZK-Rollups, độc giả có thể được hưởng lợi từ việc có một số bối cảnh để hiểu rõ hơn về bài viết này.

• Làm quen với ví hợp đồng thông minh và các tính năng của chúng
• Làm quen với EIP-4337
• Làm quen với trừu tượng tài khoản gốc trong ZK-Rollups
• Các khái niệm cơ bản của UTXO
• Khái niệm cơ bản về ZK-Rollups
• Các khái niệm cơ bản về các chương trình chứng minh không có kiến thức

Giới thiệu

Hãy xem nhanh tiếng Aztec

Aztec là một mạng Lớp 2 mã nguồn mở được thiết kế để cung cấp khả năng mở rộng và bảo vệ quyền riêng tư cho Ethereum. Aztec tận dụng các bằng chứng zkSNARK để cung cấp bảo vệ quyền riêng tư và khả năng mở rộng thông qua dịch vụ ZK-Rollup. Người dùng Aztec không cần bất kỳ bên thứ ba đáng tin cậy nào hoặc cơ chế đồng thuận bổ sung để truy cập các giao dịch riêng tư.

Chúng ta đều biết rằng trong ZK-Rollups truyền thống, “ZK” không nhất thiết có nghĩa là quyền riêng tư; Nó có nghĩa là sử dụng bằng chứng không có kiến thức (ZKP) để chứng minh rằng một số tính toán nhất định đã được thực hiện chính xác ngoài chuỗi. Tuy nhiên, ở Aztec, quyền riêng tư được thực hiện trong ZK-Rollup ngoài khả năng mở rộng. Tìm hiểu sâu hơn, trong quá khứ, các chi tiết của mỗi giao dịch được hiển thị công khai trên chuỗi, nhưng tại Aztec, đầu vào và đầu ra của mỗi giao dịch được mã hóa. Các giao dịch này được ZKP xác minh để chứng minh rằng thông tin được mã hóa là chính xác và có nguồn gốc từ bản rõ. Chỉ người dùng xây dựng các giao dịch riêng tư này mới biết thông tin văn bản rõ thực tế.

Ngay cả các ký tự quan trọng trong ZK-Rollup, chẳng hạn như Sequencer và Prover, cũng không thể xác định bản rõ là gì. Tất cả thông tin về giao dịch, bao gồm người gửi, người nhận, dữ liệu giao dịch và giá trị chuyển khoản, đều bị ẩn. Mặc dù chỉ có bản thân người dùng biết chi tiết của giao dịch, họ vẫn có thể tin tưởng vào tính đúng đắn của giao dịch. Sự tự tin này bắt nguồn từ thực tế là chỉ những giao dịch hợp pháp mới có thể tạo ra bằng chứng không có kiến thức hợp lệ để chứng minh tính chính xác của chúng.

Làm thế nào để thực hiện các giao dịch riêng tư và cách xác minh các nguyên tắc cơ bản của chúng là một chủ đề lớn nằm ngoài phạm vi của bài viết này. Nói một cách đơn giản, những gì chúng ta cần là một “lớp bổ sung để xác minh bằng chứng không có kiến thức” để xác thực danh sách ZKP, mỗi danh sách xác thực một giao dịch riêng tư. Đó là lý do tại sao chúng được gọi là “ZK-ZK-Rollups”.

Noir là gì?

Trong tiếng Aztec, trừu tượng hóa tài khoản gốc được sử dụng, có nghĩa là không có sự khác biệt giữa tài khoản thuộc sở hữu bên ngoài (EOA) và tài khoản hợp đồng. Tất cả các tài khoản là hợp đồng thông minh. Do đó, chúng tôi sẽ cung cấp một cái nhìn tổng quan ngắn gọn về hệ sinh thái phát triển hợp đồng của Aztec, vì điều quan trọng là phải hiểu phát triển hợp đồng. Tuy nhiên, nếu bạn không có kế hoạch tự phát triển hợp đồng tài khoản, thì việc đọc và hiểu bài viết này không yêu cầu bạn phải bật máy tính và viết hợp đồng. Bạn chỉ cần hiểu logic trong mã hợp đồng tài khoản. Bạn có thể khám phá chiều sâu của chủ đề theo ý của riêng bạn!

Noir là một ngôn ngữ để viết các chương trình SNARK, tương tự như Circcom và ZoKrates. Nó không chỉ cho phép bạn tự động tạo các hợp đồng Solidity Verifier sau khi mạch được tạo mà còn có thể được sử dụng để viết các giao thức của riêng bạn hoặc thậm chí là blockchain. Vì Noir không hoàn toàn dựa vào Aztec (nó không biên dịch thành một hệ thống chứng minh cụ thể), bạn có thể đạt được mục tiêu của mình bằng cách triển khai máy chủ phụ trợ và giao diện hợp đồng thông minh cho hệ thống bằng chứng.

Tại Aztec, Noir được sử dụng để viết các hợp đồng thông minh trong đó các biến (trạng thái) và chức năng có thể được bảo vệ bởi quyền riêng tư.

Trạng thái riêng tư và ghi chú riêng tư là gì

Theo sự hiểu biết của chúng tôi về các blockchain công khai, thông thường tất cả các tiểu bang đều công khai. Trong tiếng Aztec, điều quan trọng là phải nắm bắt khái niệm nhà nước tư nhân và cách quản lý nó (thêm, sửa đổi, xóa). Nhà nước tư nhân được mã hóa và sở hữu bởi chủ sở hữu của nó. Ví dụ: nếu tôi là chủ sở hữu của hợp đồng, một biến cụ thể trong hợp đồng đó có thể được mã hóa và ẩn trạng thái riêng tư. Chỉ có tôi, với tư cách là chủ sở hữu của nhà nước tư nhân này, mới có thể giải mã bản mã để có được bản rõ.

Trạng thái riêng được lưu trữ bằng cách chỉ đính kèm cây cơ sở dữ liệu. Điều này được thực hiện bởi vì việc thay đổi giá trị trạng thái trực tiếp có thể làm rò rỉ rất nhiều thông tin từ sơ đồ giao dịch. Tuy nhiên, cơ sở dữ liệu không trực tiếp lưu trữ giá trị của nhà nước riêng. Thay vào đó, nó ghi lại chúng dưới dạng ghi chú riêng tư ở dạng mã hóa (ví dụ: x = 0 -> x = 1) addr = 0x00 -> addr = 0x01. Vì vậy, trong thực tế, các biến riêng tư này, trong khi chúng dường như là các biến, thực sự được tạo thành từ một loạt các ghi chú riêng tư bất biến. Đây là sự trừu tượng của các biến. Nếu nó không rõ ràng, chúng ta hãy tiếp tục.

Khi bạn cần xóa một trạng thái riêng tư, bạn có thể thêm các ký tự không hợp lệ liên quan đến trạng thái riêng đó vào một cơ sở dữ liệu không hợp lệ khác để làm mất hiệu lực của nó. Khi bạn cần thay đổi trạng thái riêng tư, trước tiên hãy vô hiệu hóa trạng thái đó và sau đó thêm nhận xét riêng tư mới vào trạng thái đó.

Chúng tôi sẽ sớm đề cập đến khái niệm nullifiers. Bạn có thể coi nó là chìa khóa bạn cần để liên kết một ghi chú riêng tư với ký tự không hợp lệ của nó. Chỉ chủ sở hữu của khóa không hợp lệ mới có thể xác định và sử dụng ghi chú riêng tư được liên kết với khóa đó.

Tại thời điểm này, những độc giả hiểu biết có thể nhận thấy rằng cấu trúc này rất giống với UTXO (đầu ra giao dịch chưa sử dụng) và chúng ta có thể lặp lại trên UTXO để xác định trạng thái hiện tại của trạng thái riêng tư (mặc dù điều quan trọng cần nhớ là người dùng ký giao dịch, không phải UTXO; Chúng tôi sẽ giải thích điều đó sau).

! [TEg3TOpeZXF82AgjnmG7in3uwiZp3ZtIpGsNQvxc.png] (https://img.jinse.cn/7128680_watermarknone.png “7128680”)

Ghi chú riêng là gì? UTXO được gọi là Ghi chú và chúng tôi đi qua Cây ghi chú này để lấy thông tin về trạng thái riêng. Khi chúng ta muốn thay đổi trạng thái riêng tư, các bước như sau:

1. Người dùng truy xuất tất cả các ghi chú riêng tư liên quan đến trạng thái riêng tư đó từ cơ sở dữ liệu ghi chú.
2. Người dùng (thực sự là nút Aztec mà người dùng chạy) chứng thực cục bộ sự tồn tại của mỗi chú thích được truy xuất trong cây DB này.
3. Người dùng thêm một ký tự không hợp lệ để ngăn người khác đọc lại cùng một lá.
4. Người dùng chèn một chiếc lá mới (một nhận xét mới) để cập nhật giá trị của trạng thái riêng tư này.

Cơ chế AA của Aztec

Lớp giao thức là gì và lớp ứng dụng là gì?

Như chúng ta đã biết, EIP-4337 nhằm mục đích di chuyển toàn bộ quá trình giao dịch sang lớp ứng dụng, triển khai hệ thống chuyển tiếp mở và trừu tượng hóa chữ ký (cơ chế xác minh) và mô hình thanh toán thông qua bản chất lập trình của hợp đồng thông minh. Tuy nhiên, đối với Native Account Abstraction, cho dù trong kỷ nguyên StarkNet, zkSync hay Aztec, đó là trọng tâm của bài viết này, một số yếu tố nhất định cần được khắc vào giao thức của Lớp 2 để hoạt động đúng. Ví dụ: ở Aztec, khóa mã hóa và khóa không hợp lệ cần được triển khai ở cấp giao thức.

Hiểu được sự trừu tượng hóa tài khoản gốc đòi hỏi sự hiểu biết sâu sắc hơn về cách toàn bộ chuỗi hoạt động (giả sử nó được gọi là “gốc”, với logic thực thi của AA được liên kết tự nhiên với một giao thức Lớp 2 cụ thể). Ví dụ, trong kỷ nguyên zkSync, cần phải hiểu hợp đồng hệ thống, trong StarkNet, cần phải hiểu cách thức hoạt động của trình sắp xếp và trong tiếng Aztec, điều quan trọng là phải hiểu vai trò của các “khóa và trạng thái riêng tư cơ bản của chúng”.

Điểm nhập tài khoản và giai đoạn xác minh

Trong tiếng Aztec, không giống như các triển khai trừu tượng tài khoản khác, không có tên hàm được xác định nghiêm ngặt (chữ ký hàm) làm điểm nhập vào hợp đồng tài khoản (ví dụ: validateUserOp trong EIP-4337, validateTransactionzkSync Era và __validate__StarkNet). Người dùng có thể tự do chọn bất kỳ chức năng nào trong hợp đồng tài khoản làm điểm nhập và gửi giao dịch với các thông số liên quan.

Hàm được chọn bởi người dùng (chúng tôi gọi nó là entrypoint()) phải là private (được thực thi trong môi trường thực thi private của người dùng). Nó chỉ có thể được gọi từ khách hàng của chủ sở hữu hợp đồng tài khoản (ví của người dùng). Khi entrypoint() ví của người dùng được thực thi cục bộ, nó cũng tạo ra bằng chứng zero-knowledge. Chứng thực này thông báo cho giao thức Aztec của giai đoạn xác minh rằng việc thực thi ngoài chuỗi đã xảy ra và đã thành công.

Hạn chế của giai đoạn xác nhận

Điều này cũng mở rộng đến câu hỏi liệu có nên áp đặt các hạn chế đối với những gì có thể được thực hiện trong giai đoạn xác nhận hay không. Ai cũng biết rằng vì không có giới hạn chi phí để xác thực giao dịch (về cơ bản, xác thực giao dịch là chế độ xem chức năng), kẻ tấn công có thể thực hiện tấn công từ chối dịch vụ (DOS) trên mempool để thỏa hiệp gói (EIP-4337) hoặc nhà điều hành / trình sắp xếp (AA gốc). EIP-4337 xác định opcode nào bị cấm và cách hạn chế truy cập lưu trữ. zkSync Era thư giãn một số sử dụng OpCode, trong khi StarkNet hoàn toàn không cho phép các cuộc gọi hợp đồng bên ngoài.

Bởi vì giao thức Aztec liên quan đến việc máy khách xác thực bằng chứng không có kiến thức đính kèm, thay vì thực sự gọi một hàm xác thực để xác định rằng kết quả là hoặc , trueAztecfalse, không giống như các giao thức khác, không áp đặt bất kỳ hạn chế nào trong giai đoạn xác nhận. Điểm nhập hợp đồng trong tài khoản có thể tự do gọi các hợp đồng khác, truy cập bất kỳ bộ nhớ nào và thực hiện bất kỳ tính toán nào.

Luồng tương tác

Chi tiết hơn, trong zkSync Era và StarkNet, chỉ có “hợp đồng tài khoản” mới có thể bắt đầu giao dịch, bởi vì giao thức gọi một hàm được chỉ định làm điểm vào, áp đặt hạn chế này. Tuy nhiên, ở Aztec, “tất cả các hợp đồng” đều có thể bắt đầu các giao dịch, vì không có giới hạn về chức năng mà giao thức gọi là điểm vào. Điều này có nghĩa là trên Aztec, nó không còn là luồng tương tác cố định nơi người dùng gửi giao dịch đến một vai trò cụ thể (chẳng hạn như hợp đồng EntryPoint trong EIP-4337 hoặc trình sắp xếp / nhà điều hành trong AA gốc) và sau đó gọi hợp đồng đích. Người dùng có thể gửi các giao dịch thông qua ví và trực tiếp để hợp đồng mục tiêu hoàn thành các tương tác có liên quan, giúp tăng cường đáng kể tính linh hoạt.

Nếu bạn đã quen thuộc với EIP-2938, một triển khai khác của AA, bạn sẽ thấy rằng Aztec gần giống với cách tiếp cận nhiều người thuê trong đó. Tuy nhiên, đây là một chủ đề sâu hơn mà bạn có thể tự khám phá.

Khóa trong tài khoản Aztec của bạn

Trong tiếng Aztec, mỗi tài khoản thường có hai khóa chính: khóa ký và khóa chính về quyền riêng tư.

Ký khóa

Khóa ký được sử dụng để đại diện cho ủy quyền của người dùng để thực hiện một hành động cụ thể bằng khóa riêng. Một ví dụ đơn giản là khi người dùng ghi lại khóa công khai bắt nguồn từ khóa ký trong hợp đồng tài khoản. Chữ ký được tạo sau đó có thể được khôi phục trong hợp đồng bằng cách ký giao dịch hoặc tin nhắn bằng khóa ký này để kiểm tra xem nó có khớp với khóa công khai được ghi trong hợp đồng hay không (còn được gọi là khóa do chủ sở hữu kiểm soát, được lưu trữ dưới dạng khóa). địa chỉHợp đồng ví Solidity).

Việc lựa chọn thuật toán cho đường cong elip của chữ ký số là tùy thuộc vào người dùng. Ví dụ: Ethereum sử dụng secp256k1, trong khi Aztec cung cấp một schnorr ví dụ để sử dụng. Trong hợp đồng tài khoản, hàm entrypoint() hoạt động như một điểm vào (nguồn của cuộc gọi) và được sử dụng bởi logic xác thực (is_valid_impl()) để kiểm tra xem chữ ký Schnorr có khớp với khóa công khai của bản ghi std::schnorr::verify_signature(…).

! [eWwFvxmMF7pNt0axLcucSvjcig6QHMXl2HKH3luz.png] (https://img.jinse.cn/7128683_watermarknone.png “7128683”)

Khóa ký về cơ bản giống như khóa do chủ sở hữu kiểm soát trong ví hợp đồng thông minh mà chúng ta quen thuộc, vì vậy nó sẽ tương đối dễ hiểu. Trên thực tế, việc ký khóa là không hoàn toàn cần thiết. Nếu nhà phát triển tài khoản đã triển khai một cơ chế xác minh khác, tài khoản có thể không có khóa ký.

Khóa chính về quyền riêng tư

Khóa chính về quyền riêng tư trong tài khoản Aztec của bạn không thể chuyển nhượng; Mỗi tài khoản Aztec được gắn với một khóa chính riêng. Khóa chính riêng lấy khóa chính công khai, sau đó được băm bằng mã hợp đồng để tạo địa chỉ của hợp đồng tài khoản.

! [9WujRrvfd8YccfQkh9kbCtz0O1GVAKvNVJI7kXtm.png] (https://img.jinse.cn/7128684_watermarknone.png “7128684”)

Chúng tôi public_master_key account_address, partial_address và gọi chung của người dùng là địa chỉ đầy đủ của tài khoản. Khi xử lý trạng thái riêng, người dùng cần cung cấp ba thông tin này để bất kỳ ai cũng có thể xác minh rằng khóa công khai tương ứng với địa chỉ dự định.

Tuy nhiên, nếu đó là một ứng dụng public_master_key không có ý định xử lý trạng thái riêng tư và bị thiếu (ví dụ: DeFi), bạn chỉ cần điền vào trường 0 public_master_key đó để cho biết rằng nó không muốn nhận ghi chú riêng tư.

Vì vậy, trong khi Aztec cho phép chúng tôi thực hiện cơ chế xác minh và thậm chí một số cơ chế khôi phục trong hợp đồng tài khoản để tăng cường bảo mật tài khoản, cơ chế liên quan đến khóa chính bảo mật được in trong giao thức và gắn với địa chỉ. Do đó, nó không thể hoán đổi cho nhau.

Hàm ý ở đây là khóa này cũng quan trọng như khóa riêng của EOA (tài khoản thuộc sở hữu bên ngoài) trong Ethereum, khiến nó trở thành một điểm thất bại duy nhất (SPoF) cho một tài khoản. Nếu người dùng bị mất hoặc khóa chính về quyền riêng tư của tài khoản bị đánh cắp, chắc chắn rằng tài khoản sẽ không thể khôi phục được.

Khóa chính về quyền riêng tư cũng sử dụng quy trình tương tự như BIP-32 để xuất khóa mã hóa và khóa không hợp lệ. Người dùng có thể sử dụng các khóa mã hóa khác nhau và khóa không hợp lệ trong các ứng dụng hoặc hành động khác nhau để đảm bảo quyền riêng tư và bảo mật.

Khóa mã hóa

Khóa công khai của khóa mã hóa được sử dụng để mã hóa ghi chú riêng tư, trong khi khóa riêng được sử dụng để giải mã nó. Ví dụ: trong kịch bản chuyển token, nếu tôi (người gửi token) muốn chuyển token cho bạn bè (người nhận token), mình cần mã hóa private note (việc chuyển token liên quan đến việc thay đổi biến, về cơ bản balance là thay đổi biến private state UTXO bằng khóa công khai mật mã của bạn tôi) và gửi nó.

Từ quan điểm của người ngoài, nếu không biết khóa riêng mật mã của người nhận mã thông báo, họ không thể giải mã ghi chú riêng tư này hoặc biết người nhận mã thông báo là ai.

Ký tự null

Mỗi khi một ghi chú riêng tư được sử dụng, một ký tự không hợp lệ bắt nguồn từ nhận xét riêng tư đó sẽ được tạo (được mã hóa bằng khóa không hợp lệ). Cơ chế này được sử dụng để ngăn chặn chi tiêu gấp đôi (để ngăn người khác sử dụng cùng một phương pháp để xác định vị trí của tờ tiền hoặc khấu trừ tiền hai lần) vì giao thức Aztec kiểm tra xem các ký tự không hợp lệ có phải là duy nhất hay không. Để khớp ký tự không hợp lệ đó với ghi chú riêng tư, cần có khóa riêng không hợp lệ để giải mã nó, vì vậy chỉ chủ sở hữu của nó mới có thể thiết lập mối quan hệ giữa hai người.

Giao dịch Aztec

Mô tả khái niệm giao dịch bằng tiếng Aztec có thể là một thách thức vì nó có thể dễ bị nhầm lẫn với UTXO (Ghi chú cá nhân) và chế độ thực hiện giao dịch trong EVM và Aztec là hoàn toàn khác nhau.

Ở Aztec, mọi giao dịch đều được phát sóng dưới dạng bằng chứng không có kiến thức (rõ ràng là vì lý do riêng tư). Người dùng phải thực hiện tính toán cục bộ trên các nút của họ (ứng dụng ví hoặc ứng dụng khách) để tạo bằng chứng tương ứng với giao dịch, thay vì chỉ gửi các đối tượng giao dịch đến mempool của thợ đào hoặc bất kỳ nhà khai thác Lớp 2 nào thông qua API RPC như chúng tôi đã từng làm.

Băm giao dịch và nonces

Khi người dùng tạo giao dịch cục bộ, có hai yếu tố quan trọng:

1. Địa chỉ người gửi: Địa chỉ này đại diện cho địa chỉ của hợp đồng tài khoản xử lý giao dịch. Trong hợp đồng tài khoản này, có điểm vào mà chúng tôi đã đề cập trước đó, đóng vai trò là chức năng xác minh cho các bên ngoài để xác minh xem hành động (giao dịch) có được chủ sở hữu tài khoản ủy quyền hay không.
2. Dữ liệu tải trọng: Điều này bao gồm thông tin về giao dịch, chẳng hạn như chữ ký, địa chỉ hợp đồng đích, giá trị, dữ liệu, v.v.

! [xReWU4p6VrxP45q5EYNXZGAziaZhIG1DTrjeO4yD.png] (https://img.jinse.cn/7128688_watermarknone.png “7128688”)

Ở cấp độ giao thức của Aztec, hàm băm của mỗi giao dịch hợp lệ được sử dụng như một phương tiện để ngăn chặn cùng một giao dịch được thực hiện nhiều lần. Nhà phát triển hợp đồng tài khoản có thể quyết định xem có nên có nonce trong hợp đồng tài khoản và logic liên quan hay không. Ví dụ: họ có thể đặt các yêu cầu như đảm bảo rằng trường nonce trong giao dịch được tăng lên nghiêm ngặt hoặc giao dịch có thể được xử lý theo bất kỳ thứ tự nào.

Vì không có yêu cầu nonce nghiêm ngặt ở cấp độ giao thức, Aztec không thể hủy giao dịch đang chờ xử lý bằng cách gửi một giao dịch mới với cùng một nonce và phí gas cao hơn.

Thực hiện yêu cầu

Như đã đề cập trước đó, người dùng có thể chỉ định bất kỳ chức năng nào trong hợp đồng tài khoản làm điểm vào tùy thuộc vào tình huống và hoạt động trong Aztec không được kiểm soát bởi một đối tượng giao dịch đơn giản. Trên thực tế, những gì cho tài khoản hợp đồng biết phải làm gì là một đối tượng được gọi là “yêu cầu thực hiện”. Đối tượng đại diện cho hành vi của người dùng, chẳng hạn như “Gọi hàm chuyển trên hợp đồng với 0x1234 tham số sau”.

Người dùng bắt đầu giao dịch cục bộ trong ví, trong đó sender_address là địa chỉ của hợp đồng tài khoản, chứa dữ liệu mã hóa có liên quan của hàm trong hợp đồng mục tiêu cuộc gọi tải trọng () và chữ ký có thể được xác minh bằng hợp đồng tài khoản. Ví chuyển đổi hai yếu tố này thành một yêu cầu thực thi.

Sau đó, ví sẽ nhập ghi chú riêng tư, khóa mã hóa hoặc bí mật không hợp lệ vào máy ảo cục bộ để mô phỏng yêu cầu thực thi này. Trong quá trình mô phỏng, một dấu vết thực thi sẽ được tạo ra, sẽ được bàn giao cho người chứng minh để tạo ra bằng chứng không có kiến thức. Bằng chứng này cho thấy rằng các tính toán này (việc thực hiện các chức năng riêng tư) thực sự được thực hiện cục bộ bởi người dùng.

Thông qua quá trình này, chúng tôi nhận được hai phần thông tin: bằng chứng và private_data (đầu ra của mạch hạt nhân riêng cho giao dịch này). Ví sau đó gửi đối tượng giao dịch chứa hai mẩu thông tin này đến mempool Sequencer của Aztec và hoàn tất giao dịch.

ZKP dựa trên máy khách thay vì môi trường thực thi loại EVM

Trong Aztec, chúng tôi không chỉ đơn giản là nhập tất cả thông tin vào một máy Turing như EVM để tạo trạng thái cập nhật. Thay vào đó, nó dựa vào mạch trong mỗi Dapp để xác định thông tin bảo mật sẽ hoạt động như thế nào. Điều này có nghĩa là các nhà phát triển Dapp cần phải có cách để chứng minh trạng thái của các biến hợp đồng. Ví dụ: hãy xem xét số dư của người dùng trong hợp đồng mã thông báo ERC-20. Nếu chúng ta muốn chuyển 10 token DAI, hợp đồng có thể có logic sau:

1. Kiểm tra xem số dư của người gửi có lớn hơn 10 DAI không (tức là > 10 DAI).
2. Nếu người gửi có đủ số dư, một ký tự không hợp lệ được tạo ra để chỉ ra việc hủy 10 DAI của người gửi (có thể bù đắp cho việc người gửi sở hữu ghi chú riêng 10 DAI).
3. Tạo ghi chú riêng tư mới cho người nhận.
4. Phát sóng và mã hóa tất cả các tin nhắn được truyền bằng 10 DAI.

Từ quan điểm của người ngoài, họ chỉ có thể thấy các giá trị vô hiệu và nhận xét mới xuất hiện và tất cả chúng đều được mã hóa. Vì vậy, mọi người đều biết rằng một thỏa thuận mới đã diễn ra, nhưng chính xác những gì đang diễn ra bên trong chỉ những người tham gia mới biết.

! [B2NwqMIhntBOllrlchIWeaetEbkSSdoTARJiM27A.png] (https://img.jinse.cn/7128690_watermarknone.png “7128690”)

Tìm hiểu thêm về hợp đồng tài khoản Aztec

Ví

Ví trong Aztec là một phần quan trọng trong việc quản lý tương tác của người dùng với blockchain và dữ liệu cá nhân của họ. Dưới đây là tóm tắt các tác vụ mà ví Aztec phải xử lý:

1. Tạo tài khoản: Ví sẽ cho phép người dùng tạo hợp đồng tài khoản mới, về cơ bản có nghĩa là triển khai các hợp đồng tài khoản mới trên blockchain.
2. Quản lý khóa riêng: Ví có nhiệm vụ quản lý cụm từ hạt giống và khóa riêng của người dùng, bao gồm khóa chính bảo mật và khóa ký (tùy thuộc vào thiết kế của hợp đồng tài khoản). Quản lý này cũng có thể được mở rộng để tích hợp ví phần cứng.
3. Xem tài khoản: Người dùng sẽ có thể xem tài khoản của họ và các trạng thái liên quan, bao gồm số dư và các trạng thái riêng tư khác. Điều này có nghĩa là ví cần duy trì cơ sở dữ liệu cục bộ của tất cả các ghi chú riêng tư liên quan đến người dùng.
4. Tương tác với Dapps: Ví cần tạo điều kiện tương tác giữa người dùng và Dapps. Khi người dùng tương tác với Dapp, Dapp có thể yêu cầu giao dịch được gửi từ tài khoản của người dùng.
5. Sự đồng ý của người dùng: Dapps có thể yêu cầu sự đồng ý của người dùng để hiển thị một số trạng thái hợp đồng nhất định, chẳng hạn như số dư trong hợp đồng mã thông báo. Để hiển thị các trạng thái này, ví phải có khả năng nhận yêu cầu của người dùng (vì số dư hiển thị yêu cầu sự đồng ý của khóa người dùng).
6. Tạo bằng chứng: Để gửi giao dịch thay mặt cho người dùng, ví phải có khả năng tạo bằng chứng cục bộ. Điều này liên quan đến việc tạo và xử lý bằng chứng không có kiến thức về tính hợp lệ của các giao dịch.

Một điểm quan trọng cần lưu ý là ví cần quét tất cả các khối bắt đầu bằng khối genesis, sử dụng khóa của người dùng để khám phá và giải mã các ghi chú riêng tư có liên quan, sau đó lưu trữ chúng trong cơ sở dữ liệu cục bộ để sử dụng trong tương lai. Điều này rất quan trọng để tạo điều kiện cho sự tương tác của người dùng và đảm bảo rằng dữ liệu trạng thái riêng tư có thể được quản lý hiệu quả.

Bạn đã đề cập đến một khía cạnh quan trọng khác của Aztec, đó là nhu cầu người dùng phát sóng địa chỉ đầy đủ. Khi ví tạo ghi chú tiền điện tử cho người nhận giao dịch mục tiêu, nó cũng cần có khả năng lấy địa chỉ đầy đủ của người nhận. Điều này có thể đạt được bằng cách nhập thủ công hoặc duy trì cơ sở dữ liệu cục bộ về địa chỉ của người nhận. Để biết thêm chi tiết về điều này, vui lòng tham khảo tài liệu chính thức của người Aztec.

Hợp đồng tài khoản

Ở Aztec, nhiệm vụ chính của hợp đồng tài khoản là xác minh chữ ký (xác nhận rằng các giao dịch được ủy quyền bởi chủ sở hữu tài khoản và do đó được ủy quyền rộng rãi hơn, thay vì nhất thiết phải được xác minh bằng thuật toán chữ ký số cụ thể), quản lý mức tiêu thụ gas và gọi các hợp đồng khác.

Đây là một ví dụ chính thức về hợp đồng tài khoản Aztec sử dụng thuật toán chữ ký Schnorr. Điểm vào lệnh cho tất cả các giao dịch là hàm entrypoint() (bạn có thể tự do chọn hàm hoặc tên làm điểm bắt đầu, nhưng trong trường hợp này entrypoint() được sử dụng).

! [LahY9kfNGKkYkSm5ULPlReKATiTA3K5bjFGIClh0.png] (https://img.jinse.cn/7128692_watermarknone.png “7128692”)

Khi chúng ta gọi tài khoản entrypoint() với payload đính kèm, hợp đồng tài khoản entrypoint() sẽ gọi entrypoint thư viện tài khoản AA Aztec().

! [OskBKScb0LqWpcTMIuhBMjeSB151sFvSWbwXl.png] (https://img.jinse.cn/7128697_watermarknone.png “7128697”)

Aztec không yêu cầu hợp đồng tài khoản của chúng tôi nhập vào thư viện tài khoản EntrypointPayload và Aztec AA; Bạn có thể tự do thiết kế logic hợp đồng tài khoản của riêng mình.

! [HNskT1CkOOPiZZaAVvqlJNf7L5VxU39Fz9ir2Ica.png] (https://img.jinse.cn/7128698_watermarknone.png “7128698”)

là context, một đối tượng có sẵn trong mọi chức năng trong Aztec.nr. Chứa tất cả thông tin kernel cần thiết để thực thi ứng dụng ngữ cảnh. Trích dẫn từ tài liệu chính thức của người Aztec. - Bối cảnh là gì

Trên đây là code entrypoint() của thư viện tài khoản Aztec AA. Nó chịu trách nhiệm xác định xem hoạt động có được chủ sở hữu tài khoản ủy quyền hay không dựa trên chức năng xác thực () được xác định trên tài khoản là hợp đồng \ _valid \ _impl và thực hiện các cuộc gọi cần thiết để thực hiện hoạt động _calls cần thiết cho giao dịch.

Điều này có nghĩa là nếu bạn muốn tham chiếu thư viện Aztec AA này và hợp đồng tài khoản của bạn không có triển khai là \ _valid \ _impl với cùng một chữ ký hàm, bước này sẽ không thành công.

! [QZuhkG4BTiKMQF4hFZKGw0gi9MBlU5VGcDjyQyU9.png] (https://img.jinse.cn/7128699_watermarknone.png “7128699”)

Một chi tiết triển khai quan trọng khác là sử dụng get_auth_witness() để truy xuất chữ ký. Bạn có thể tham khảo các tài liệu tham khảo bên dưới để tìm hiểu thêm về cách Nhân Chứng hoạt động. Nói một cách đơn giản, một nhân chứng là “ủy quyền cho người dùng làm những gì họ muốn làm”.

Nhân chứng xác thực là một sơ đồ để xác minh các hoạt động trên Aztec, vì vậy người dùng có thể cho phép các bên thứ ba, chẳng hạn như các giao thức hoặc người dùng khác, thực hiện các hành động thay mặt họ. Trích dẫn từ tài liệu chính thức của người Aztec. - Nhân chứng được chứng nhận

Lý do tại sao nó được gọi là “nhân chứng” thay vì chỉ đơn giản là “chữ ký” là vì cách hợp đồng tài khoản được xác minh không nhất thiết liên quan đến việc xác minh chữ ký.

Ví dụ: giả sử có một hoạt động chuyển 1000 mã thông báo từ tài khoản của Alice sang nền tảng DeFi. Trong trường hợp này, hợp đồng mã thông báo cần truy vấn hợp đồng tài khoản của Alice để xem liệu cô ấy có chấp thuận “hành động” hay không. “Hành động” này yêu cầu một nhân chứng xác thực được tạo trong ví của Alice (cục bộ), sau đó có thể được xác minh thông qua hợp đồng tài khoản của cô ấy. Nếu hợp đồng tài khoản được xác minh thành công, hợp đồng mã thông báo sẽ biết rằng “hành động” đã được ủy quyền.

! [WJkuu8NWicgcHvCyH08YpHhjYtTtYiP8GbRxwwKs.png] (https://img.jinse.cn/7128700_watermarknone.png “7128700”)

Kết luận

Cho đến nay, Aztec vẫn chưa thực hiện cơ chế phí và mục tiêu của họ cũng là trừu tượng hóa việc thanh toán phí. Điều này có nghĩa là để một giao dịch được coi là hợp lệ, nó phải chứng minh rằng nó đã khóa đủ tiền để trang trải các khoản phí của chính mình. Tuy nhiên, nó không chỉ định các khoản tiền này phải đến từ đâu, thực hiện thanh toán hoặc thanh toán bằng hiện vật dễ dàng có thể thông qua trao đổi ngay lập tức.