Giải mã mô hình hợp đồng thông minh và AA gốc của Starknet: bậc thầy công nghệ đi lối riêng
Tuyển chọn TechFlowTuyển chọn TechFlow
Giải mã mô hình hợp đồng thông minh và AA gốc của Starknet: bậc thầy công nghệ đi lối riêng
Bài viết này sẽ điểm qua sơ lược về phương án kỹ thuật và thiết kế cơ chế của Starknet, bắt đầu từ mô hình hợp đồng thông minh và AA bản địa của nó.
Chuyên sâu báo cáo Web3Tác giả: Shew & Faust, Geeks web3
Cố vấn: CryptoNerdCn, nhà phát triển cốt lõi hệ sinh thái Starknet, người sáng lập nền tảng phát triển Cairo trên trình duyệt WASM Cairo
Tóm tắt
Một vài đặc điểm kỹ thuật chính của Starknet bao gồm ngôn ngữ Cairo hỗ trợ việc tạo bằng chứng ZK, trừu tượng hóa tài khoản (AA) ở cấp độ gốc, và mô hình hợp đồng thông minh tách biệt logic nghiệp vụ với lưu trữ trạng thái.
Cairo là một ngôn ngữ ZK phổ quát, có thể dùng để triển khai hợp đồng thông minh trên Starknet cũng như phát triển các ứng dụng truyền thống hơn, quy trình biên dịch của nó đưa vào Sierra như một ngôn ngữ trung gian, giúp Cairo có thể cập nhật thường xuyên mà không cần thay đổi bytecode底层, chỉ cần truyền sự thay đổi tới ngôn ngữ trung gian; thư viện chuẩn của Cairo còn tích hợp nhiều cấu trúc dữ liệu cơ bản cần thiết cho việc trừu tượng hóa tài khoản.
Hợp đồng thông minh Starknet tách riêng logic nghiệp vụ và dữ liệu trạng thái, khác với các chuỗi EVM. Việc triển khai hợp đồng Cairo bao gồm ba giai đoạn: "biên dịch, khai báo, triển khai", logic nghiệp vụ được khai báo trong Contract class, các instance Contract chứa dữ liệu trạng thái có thể liên kết với class và gọi mã từ class đó;
Mô hình hợp đồng thông minh nói trên của Starknet thuận lợi cho việc tái sử dụng mã, tái sử dụng trạng thái hợp đồng, phân tầng lưu trữ, phát hiện hợp đồng rác, đồng thời cũng hỗ trợ thực hiện thuê lưu trữ và xử lý giao dịch song song. Dù hai tính năng sau vẫn chưa được triển khai, kiến trúc hợp đồng thông minh Cairo đã tạo ra "điều kiện cần thiết" cho chúng.
Trên mạng Starknet chỉ tồn tại tài khoản hợp đồng thông minh, không có tài khoản EOA, từ đầu đã hỗ trợ AA mức nguyên bản. Giải pháp AA của nó phần nào tiếp thu tư tưởng từ ERC-4337, cho phép người dùng lựa chọn các phương án xử lý giao dịch tùy chỉnh cao độ. Để ngăn chặn các kịch bản tấn công tiềm ẩn, Starknet đã thực hiện nhiều biện pháp phản công, đóng góp khám phá quan trọng cho hệ sinh thái AA.
Nội dung chính
Sau khi Starknet phát hành token, STRK dần trở thành một yếu tố không thể thiếu trong mắt những người theo dõi Ethereum. Dự án nổi bật Layer2 này vốn nổi tiếng với cái tôi độc lập, "không coi trọng trải nghiệm người dùng", giống như một ẩn sĩ vô danh lặng lẽ mở rộng mảnh đất riêng giữa thế giới Layer2 tràn ngập xu hướng tương thích EVM.
Vì quá xem nhẹ người dùng đến mức công khai tạo kênh "hành khất điện tử" trên Discord, Starknet từng bị cộng đồng airdrop chỉ trích gay gắt. Bị chê trách là "vô tình", nền tảng kỹ thuật vững chắc nhất thời trở nên "vô giá trị", dường như chỉ có UX và hiệu ứng làm giàu mới là tất cả. Câu nói trong "Kim Các Tự": "Không được ai hiểu biết hóa thành niềm tự hào duy nhất của tôi", đúng là chân dung tự họa của Starknet.
Nhưng bỏ qua những chuyện thị phi này, nếu xét riêng về "gu công nghệ" của các lập trình viên yêu thích mã nguồn, Starknet và StarkEx - một trong những tiên phong của ZK Rollup - gần như là kho báu trong mắt những người yêu thích Cairo. Trong lòng một số nhà phát triển game toàn chuỗi, Starknet và Cairo đơn giản là toàn bộ web3, Solidity hay Move đều không thể so sánh. Khoảng cách lớn nhất hiện nay giữa "kỹ sư công nghệ" và "người dùng" chủ yếu bắt nguồn từ sự thiếu hiểu biết về Starknet.
Với lòng ham muốn tìm hiểu công nghệ blockchain và mong muốn khám phá giá trị của Starknet, bài viết này sẽ sơ lược cơ chế và giải pháp kỹ thuật của Starknet bắt đầu từ mô hình hợp đồng thông minh và AA gốc của nó, nhằm giới thiệu đặc điểm kỹ thuật của Starknet, đồng thời giúp mọi người hiểu rõ hơn về "kẻ lang thang đơn độc không ai thấu hiểu" này.
Giới thiệu ngắn gọn về ngôn ngữ Cairo
Trong phần sau, chúng ta sẽ tập trung thảo luận về mô hình hợp đồng thông minh và AA gốc của Starknet, giải thích cách Starknet đạt được AA gốc. Sau khi đọc xong bài viết này, bạn cũng sẽ hiểu tại sao các ví khác nhau trên Starknet không thể dùng chung cụm khôi phục.
Tuy nhiên, trước khi giới thiệu về AA gốc, chúng ta hãy tìm hiểu ngôn ngữ Cairo do Starknet sáng tạo. Trong quá trình phát triển Cairo, xuất hiện phiên bản ban đầu gọi là Cairo0 và phiên bản hiện đại sau này. Ngữ pháp tổng thể của Cairo hiện đại tương tự Rust, thực tế là một ngôn ngữ ZK phổ quát, không chỉ dùng để viết hợp đồng thông minh trên Starknet mà còn có thể dùng để phát triển ứng dụng tổng quát.
Ví dụ, chúng ta có thể dùng ngôn ngữ Cairo để phát triển hệ thống xác thực danh tính ZK, chương trình này có thể chạy trên máy chủ do mình xây dựng, không cần phụ thuộc vào mạng StarkNet. Có thể nói, bất kỳ chương trình nào cần thuộc tính tính toán có thể kiểm chứng đều có thể thực hiện bằng ngôn ngữ Cairo. Và Cairo có lẽ là ngôn ngữ lập trình thuận lợi nhất hiện nay để tạo bằng chứng ZK.
Xét về quy trình biên dịch, Cairo sử dụng phương pháp biên dịch dựa trên ngôn ngữ trung gian, như hình dưới đây. Sierra trong hình là một dạng trung gian (IR) trong quá trình biên dịch ngôn ngữ Cairo, sau đó Sierra sẽ được biên dịch thành dạng mã nhị phân thấp hơn gọi là CASM, chạy trực tiếp trên thiết bị nút Starknet.
Việc đưa Sierra làm dạng trung gian giúp dễ dàng thêm các tính năng mới cho ngôn ngữ Cairo, nhiều lúc chỉ cần thay đổi trên ngôn ngữ trung gian Sierra mà không cần thay đổi trực tiếp mã CASM底层, điều này tiết kiệm rất nhiều rắc rối, khách hàng nút Starknet không cần cập nhật thường xuyên. Như vậy có thể thực hiện cập nhật thường xuyên cho ngôn ngữ Cairo mà không thay đổi logic底层 của StarkNet. Thư viện chuẩn của Cairo còn tích hợp nhiều cấu trúc dữ liệu cơ bản cần thiết cho việc trừu tượng hóa tài khoản.
Những đổi mới khác của Cairo bao gồm một phương án lý thuyết mang tên Cairo Native, dự định biên dịch Cairo thành mã máy phù hợp với các thiết bị phần cứng khác nhau, các nút Starknet khi chạy hợp đồng thông minh sẽ không cần phụ thuộc vào máy ảo CairoVM, từ đó tăng tốc độ thực thi mã đáng kể [hiện vẫn ở giai đoạn lý thuyết, chưa triển khai].
Mô hình hợp đồng thông minh Starknet: Tách rời logic mã và lưu trữ trạng thái
Khác với các chuỗi tương thích EVM, Starknet có những đổi mới đột phá trong thiết kế hệ thống hợp đồng thông minh, phần lớn đổi mới này nhằm phục vụ AA gốc và chức năng giao dịch song song trong tương lai. Ở đây, cần biết rằng trên các chuỗi công cộng truyền thống như Ethereum, việc triển khai hợp đồng thông minh thường tuân theo cách thức "biên dịch rồi triển khai", lấy ví dụ hợp đồng ETH:
1. Sau khi lập trình viên viết xong hợp đồng thông minh tại máy cục bộ, dùng trình biên dịch chuyển chương trình Solidity thành bytecode EVM, để EVM có thể trực tiếp hiểu và xử lý;
2. Lập trình viên gửi yêu cầu giao dịch triển khai hợp đồng thông minh, triển khai bytecode EVM đã biên dịch lên chuỗi Ethereum.
(Nguồn ảnh: not-satoshi.com)
Mặc dù Starknet cũng tuân theo tư tưởng "biên dịch trước rồi triển khai sau", hợp đồng thông minh được triển khai trên chuỗi dưới dạng bytecode CASM được CairoVM hỗ trợ, nhưng về cách gọi hợp đồng và mô hình lưu trữ trạng thái, Starknet có sự khác biệt lớn so với các chuỗi tương thích EVM.
Chính xác hơn, hợp đồng thông minh Ethereum = logic nghiệp vụ + thông tin trạng thái, ví dụ như trong hợp đồng USDT không chỉ hiện thực các hàm chức năng phổ biến như Transfer, Approval, mà còn lưu trữ trạng thái tài sản của tất cả người nắm giữ USDT, mã và trạng thái bị ràng buộc chặt chẽ với nhau, gây ra nhiều rắc rối, trước hết không thuận lợi cho nâng cấp hợp đồng DAPP và di chuyển trạng thái, cũng không thuận lợi cho xử lý giao dịch song song, là gánh nặng kỹ thuật.
Đối với điều này, Starknet đã cải tiến cách lưu trữ trạng thái, trong giải pháp hiện thực hợp đồng thông minh của nó, logic nghiệp vụ và trạng thái tài sản của DAPP hoàn toàn tách rời, lưu trữ ở nơi khác nhau, lợi ích rõ ràng là hệ thống có thể nhanh chóng phân biệt được liệu có tồn tại việc triển khai mã trùng lặp hay dư thừa hay không. Nguyên lý ở đây như sau:
Hợp đồng thông minh Ethereum = logic nghiệp vụ + dữ liệu trạng thái, giả sử có vài hợp đồng có phần logic nghiệp vụ hoàn toàn giống nhau nhưng dữ liệu trạng thái khác nhau, thì hash của các hợp đồng này cũng khác nhau, hệ thống khó phân biệt được những hợp đồng này có dư thừa hay không, có tồn tại "hợp đồng rác" hay không.
Trong khi đó, trong giải pháp Starknet, phần mã và dữ liệu trạng thái được tách rời trực tiếp, hệ thống dựa trên hash của phần mã để dễ dàng phân biệt liệu có cùng mã bị triển khai nhiều lần hay không, vì hash của chúng giống nhau. Điều này thuận tiện để ngăn chặn hành vi triển khai mã trùng lặp, tiết kiệm không gian lưu trữ cho nút Starknet.
Trong hệ thống hợp đồng thông minh Starknet, việc triển khai và sử dụng hợp đồng được chia thành ba giai đoạn: "biên dịch, khai báo, triển khai". Nếu người phát hành tài sản muốn triển khai hợp đồng Cairo, bước đầu tiên là biên dịch mã Cairo đã viết sẵn trên thiết bị cục bộ thành dạng Sierra và bytecode底层 CASM.
Sau đó, người triển khai hợp đồng phải đăng ký giao dịch "declare", triển khai bytecode CASM và mã trung gian Sierra của hợp đồng lên chuỗi, được gọi là Contract Class.
(Nguồn ảnh: trang web chính thức Starknet)
Sau đó, nếu bạn muốn sử dụng các chức năng hàm được định nghĩa trong hợp đồng tài sản này, có thể thông qua giao diện DAPP gửi giao dịch "deploy", triển khai một instance Contract liên kết với Contract Class, instance này sẽ lưu trữ trạng thái tài sản. Sau đó, người dùng có thể gọi các chức năng hàm trong Contract Class để thay đổi trạng thái của instance Contract.
Thực tế, bất kỳ ai hiểu về lập trình hướng đối tượng đều có thể dễ dàng hiểu được Class và Instance trong Starknet đại diện cho cái gì. Contract Class do nhà phát triển khai báo chỉ chứa logic nghiệp vụ của hợp đồng thông minh, là một đoạn chức năng hàm mà ai cũng có thể gọi, nhưng không có trạng thái tài sản thực tế, tức là chưa hiện thực "thực thể tài sản", chỉ có "linh hồn" chứ không có "thân xác".
Khi người dùng triển khai instance Contract cụ thể, tài sản mới hoàn thành "thể hiện hóa". Nếu bạn muốn thay đổi trạng thái của "thực thể" tài sản, ví dụ như chuyển token của mình cho người khác, bạn có thể trực tiếp gọi các chức năng hàm đã viết sẵn trong Contract Class. Quá trình trên tương tự như "khởi tạo instance" trong các ngôn ngữ lập trình hướng đối tượng truyền thống (nhưng không hoàn toàn giống).
Sau khi hợp đồng thông minh được tách thành Class và instance, logic nghiệp vụ và dữ liệu trạng thái được tách rời, mang lại các đặc điểm sau cho Starknet:
1. Thuận lợi cho việc phân tầng lưu trữ và hiện thực "chế độ thuê lưu trữ"
Phân tầng lưu trữ nghĩa là nhà phát triển có thể đặt dữ liệu tại vị trí tùy chỉnh theo nhu cầu, ví dụ như ngoài chuỗi Starknet. StarkNet dự định tương thích với các lớp DA như Celestia, nhà phát triển DAPP có thể lưu dữ liệu trên các lớp DA bên thứ ba này. Ví dụ, một trò chơi có thể lưu dữ liệu tài sản quan trọng nhất trên mạng chính Starknet, còn dữ liệu khác lưu trên các lớp DA ngoài chuỗi như Celestia. Giải pháp lựa chọn lớp DA theo nhu cầu bảo mật được Starknet đặt tên là "Volition".
Còn "thuê lưu trữ" nghĩa là mỗi người nên liên tục trả phí cho không gian lưu trữ mà họ chiếm dụng. Bạn chiếm bao nhiêu không gian trên chuỗi, về lý thuyết nên liên tục trả tiền thuê.
Trong mô hình hợp đồng thông minh Ethereum, quyền sở hữu hợp đồng không rõ ràng, khó phân biệt một hợp đồng ERC-20 nên do người triển khai hay người nắm giữ tài sản trả "tiền thuê", khiến chức năng thuê lưu trữ chưa được triển khai, chỉ thu một khoản phí từ người triển khai khi triển khai hợp đồng, mô hình phí lưu trữ này không hợp lý.
Trong khi đó, trong mô hình hợp đồng thông minh của Starknet, Sui, CKB và Solana, quyền sở hữu hợp đồng thông minh được phân chia rõ ràng hơn, thuận tiện cho việc thu phí lưu trữ [hiện tại Starknet chưa triển khai trực tiếp chế độ thuê lưu trữ, nhưng trong tương lai sẽ hiện thực]
2. Hiện thực tái sử dụng mã thực sự, giảm việc triển khai hợp đồng rác
Chúng ta có thể khai báo một hợp đồng token phổ quát làm class lưu trữ trên chuỗi, sau đó mọi người đều có thể gọi các hàm trong class này để triển khai instance token của riêng mình. Hơn nữa, hợp đồng cũng có thể trực tiếp gọi mã trong class, hiện thực hiệu quả tương tự thư viện hàm Library trong Solidity.
Đồng thời, mô hình hợp đồng thông minh của Starknet, giúp phân biệt "hợp đồng rác". Phần trước đã giải thích điều này. Sau khi hỗ trợ tái sử dụng mã và phát hiện hợp đồng rác, Starknet có thể giảm đáng kể lượng dữ liệu lên chuỗi, giảm tải tối đa cho bộ nhớ nút.
3. Tái sử dụng "trạng thái" hợp đồng thực sự
Việc nâng cấp hợp đồng trên blockchain chủ yếu liên quan đến việc thay đổi logic nghiệp vụ. Trong trường hợp Starknet, logic nghiệp vụ và trạng thái tài sản của hợp đồng thông minh vốn đã tách rời, instance hợp đồng thay đổi class hợp đồng liên kết có thể hoàn thành việc nâng cấp logic nghiệp vụ, không cần di chuyển trạng thái tài sản sang nơi mới, hình thức nâng cấp hợp đồng này triệt để và gốc hơn so với Ethereum.
Trong khi đó, để thay đổi logic nghiệp vụ, hợp đồng Ethereum thường phải "giao khoán" logic cho hợp đồng đại lý, thông qua việc thay đổi hợp đồng đại lý phụ thuộc để thay đổi logic nghiệp vụ của hợp đồng chính, nhưng cách này không gọn gàng và "không gốc".
(Nguồn ảnh: wtf Academy)
Trong một số trường hợp, nếu hợp đồng Ethereum cũ bị loại bỏ hoàn toàn, trạng thái tài sản bên trong không thể di chuyển trực tiếp sang nơi mới, rất phiền phức; trong khi hợp đồng Cairo không cần di chuyển trạng thái, có thể trực tiếp "tái sử dụng" trạng thái cũ.
4. Thuận lợi cho xử lý giao dịch song song
Để nâng cao mức độ song song của các lệnh giao dịch khác nhau, một bước cần thiết là tách riêng trạng thái tài sản của những người khác nhau, điều này thấy rõ ở Bitcoin, CKB và Sui. Điều kiện tiên quyết cho mục tiêu trên là tách rời logic nghiệp vụ và dữ liệu trạng thái của hợp đồng thông minh. Mặc dù Starknet chưa thực hiện sâu về mặt kỹ thuật cho giao dịch song song, nhưng trong tương lai sẽ lấy giao dịch song song làm mục tiêu quan trọng.
AA gốc và triển khai hợp đồng tài khoản của Starknet
Thực tế, khái niệm tài khoản trừu tượng và AA là một khái niệm độc đáo do cộng đồng Ethereum tạo ra, trong nhiều chuỗi công cộng mới, không có sự phân biệt giữa tài khoản EOA và tài khoản hợp đồng thông minh, từ đầu đã tránh được cái hố của hệ thống tài khoản kiểu Ethereum. Ví dụ, theo thiết lập Ethereum, người kiểm soát tài khoản EOA phải có ETH trên chuỗi mới có thể khởi tạo giao dịch, không thể trực tiếp chọn các phương thức xác thực danh tính đa dạng, việc thêm các logic thanh toán tùy chỉnh cũng cực kỳ khó khăn. Thậm chí có người cho rằng thiết kế tài khoản của Ethereum đơn giản là phản nhân loại.
Nếu quan sát Starknet hoặc zkSyncEra - những chuỗi nổi bật với "AA gốc", có thể thấy sự khác biệt rõ rệt: trước hết, Starknet và zkSyncEra hợp nhất loại tài khoản, trên chuỗi chỉ có tài khoản hợp đồng thông minh, từ đầu đã không có thứ gọi là tài khoản EOA (zkSync Era sẽ triển khai một bộ mã hợp đồng mặc định trên tài khoản mới tạo của người dùng, mô phỏng đặc điểm tài khoản EOA Ethereum, thuận tiện cho việc tương thích Metamask).
Trong khi đó, Starknet không cân nhắc tương thích trực tiếp với các tiện ích xung quanh Ethereum như Metamask, khi người dùng lần đầu sử dụng ví Starknet, sẽ tự động triển khai tài khoản hợp đồng chuyên dụng, nói trắng ra là triển khai instance hợp đồng đã đề cập ở trên, instance hợp đồng này sẽ liên kết với class hợp đồng do bên phát triển ví triển khai trước, có thể trực tiếp gọi một số chức năng đã viết sẵn trong class.
Dưới đây chúng ta sẽ bàn đến một chủ đề thú vị: khi nhận airdrop STRK, nhiều người phát hiện Argent và Braavos không tương thích với nhau, khi nhập cụm khôi phục Argent vào Braavos, không thể xuất được tài khoản tương ứng, điều này thực chất là do Argent và Braavos sử dụng các phương pháp tính toán tạo tài khoản khác nhau, dẫn đến địa chỉ tài khoản được tạo từ cùng cụm khôi phục là khác nhau.
Cụ thể, trong Starknet, địa chỉ hợp đồng mới có thể được suy ra bằng thuật toán xác định, sử dụng công thức sau:
Hàm pedersen() trong công thức trên là một thuật toán băm dễ sử dụng trong hệ thống ZK, quá trình tạo tài khoản thực chất là đưa một vài tham số đặc biệt vào hàm pedersen, tạo ra hash tương ứng, hash này chính là địa chỉ tài khoản được tạo.
Hình ảnh trên hiển thị một vài tham số được dùng khi Starknet tạo "địa chỉ hợp đồng mới", deployer_address đại diện cho địa chỉ "người triển khai hợp đồng", tham số này có thể để trống, ngay cả khi bạn chưa có tài khoản hợp đồng Starknet, vẫn có thể triển khai hợp đồng mới.
salt là giá trị muối để tính toán địa chỉ hợp đồng, đơn giản là một số ngẫu nhiên, biến này thực tế được đưa vào để tránh trùng lặp địa chỉ hợp đồng. class_hash là hash của class hợp đồng tương ứng với instance hợp đồng, như đã giới thiệu ở trên. constructor_calldata_hash đại diện cho hash của tham số khởi tạo hợp đồng.
Dựa trên công thức trên, người dùng có thể tính trước địa chỉ hợp đồng được tạo trước khi triển khai hợp đồng lên chuỗi. Starknet cho phép người dùng triển khai hợp đồng trực tiếp mà không cần có tài khoản Starknet trước, quy trình như sau:
1. Người dùng trước tiên xác định instance hợp đồng mình muốn triển khai sẽ liên kết với class hợp đồng nào, lấy hash của class đó làm một trong các tham số khởi tạo, và tính salt, biết được địa chỉ hợp đồng sẽ tạo ra;
2. Sau khi người dùng biết sẽ triển khai hợp đồng tại đâu, trước tiên chuyển một lượng ETH nhất định đến địa chỉ đó, làm phí triển khai hợp đồng. Nói chung, phần ETH này cần được chuyển từ L1 sang mạng Starknet qua cầu nối;
3. Người dùng gửi yêu cầu giao dịch triển khai hợp đồng.
Thực tế, tất cả tài khoản Starknet đều được triển khai theo quy trình trên, nhưng hầu hết ví che giấu các chi tiết này, người dùng hoàn toàn không cảm nhận được quá trình bên trong, cứ như sau khi chuyển ETH vào thì tài khoản hợp đồng đã được triển khai xong.
Giải pháp trên gây ra một số vấn đề tương thích, vì các ví khác nhau tạo địa chỉ tài khoản với kết quả không nhất quán, chỉ những ví thỏa mãn các điều kiện sau mới có thể dùng chung:
-
Ví sử dụng cùng thuật toán suy diễn khóa công khai và chữ ký từ khóa riêng;
-
Quy trình tính toán salt của ví giống nhau;
-
Chi tiết hiện thực class hợp đồng thông minh của ví không có sự khác biệt căn bản;
Trong ví dụ đã đề cập, Argent và Braavos đều dùng thuật toán chữ ký ECDSA, nhưng phương pháp tính toán salt khác nhau, dẫn đến địa chỉ tài khoản tạo ra từ cùng cụm khôi phục trong hai ví là khác nhau.
Bây giờ chúng ta quay lại chủ đề trừu tượng hóa tài khoản. Starknet và zkSync Era chuyển toàn bộ các quy trình liên quan trong quá trình xử lý giao dịch, như xác thực danh tính (xác minh chữ ký số), thanh toán phí Gas, v.v., ra khỏi "lớp底层" của chuỗi để hiện thực. Người dùng có thể tự định nghĩa chi tiết hiện thực các logic trên trong tài khoản của mình.
Ví dụ, bạn có thể triển khai hàm xác minh chữ ký số chuyên dụng trong tài khoản hợp đồng thông minh Starknet của mình, khi nút Starknet nhận được giao dịch bạn khởi tạo, sẽ gọi các logic xử lý giao dịch tùy chỉnh mà bạn đã định nghĩa trên tài khoản chuỗi. Điều này rõ ràng linh hoạt hơn nhiều.
Trong thiết kế Ethereum, các logic như xác thực danh tính (chữ ký số) được viết chết trong mã khách hàng nút, không hỗ trợ tùy chỉnh chức năng tài khoản ở cấp độ gốc.
(Sơ đồ minh họa giải pháp AA gốc do kiến trúc sư Starknet chỉ ra, xác minh giao dịch và xác minh tư cách phí gas đều được chuyển sang xử lý bởi hợp đồng trên chuỗi, máy ảo底层 có thể gọi các hàm tùy chỉnh hoặc chỉ định bởi người dùng)
Theo lời nhân viên chính thức của zkSyncEra và Starknet, tư tưởng mô-đun hóa chức năng tài khoản này tham khảo EIP-4337. Nhưng khác biệt là, zkSync và Starknet từ đầu đã hợp nhất loại tài khoản, hợp nhất loại giao dịch, và dùng cổng vào thống nhất để nhận và xử lý tất cả giao dịch, trong khi Ethereum do gánh nặng lịch sử, và quỹ hy vọng tránh các phương án cập nhật thô bạo như hard fork càng nhiều càng tốt, nên hỗ trợ EIP-4337 - một giải pháp "đi vòng", nhưng hiệu quả là, tài khoản EOA và giải pháp 4337 dùng quy trình xử lý giao dịch độc lập, trông gượng gạo và cồng kềnh, không linh hoạt như AA gốc.
(Nguồn ảnh: ArgentWallet)
Nhưng hiện tại AA gốc của Starknet chưa đạt đến mức trưởng thành hoàn toàn, xét về tiến độ thực tiễn, AA tài khoản Starknet đã hiện thực tùy chỉnh thuật toán xác minh chữ ký, nhưng đối với tùy chỉnh thanh toán phí, hiện tại Starknet thực tế chỉ hỗ trợ nộp phí gas bằng ETH và STRK, và chưa hỗ trợ bên thứ ba nộp phí gas. Vì vậy tiến độ của Starknet trong AA gốc có thể nói là "giải pháp lý thuyết cơ bản trưởng thành, giải pháp thực tiễn đang được thúc đẩy".
Do trong Starknet chỉ có tài khoản hợp đồng thông minh, nên toàn bộ quy trình giao dịch đều tính đến ảnh hưởng của hợp đồng thông minh tài khoản. Trước hết, một giao dịch được nút Starknet nhận vào bộ nhớ tạm (Mempool), cần xác minh, các bước xác minh bao gồm:
-
Chữ ký số của giao dịch có đúng không, lúc này sẽ gọi hàm xác minh chữ ký tùy chỉnh trong tài khoản người khởi tạo giao dịch;
-
Số dư tài khoản người khởi tạo giao dịch có đủ để trả phí gas không;
Lưu ý rằng, việc sử dụng hàm xác minh chữ ký tùy chỉnh trong hợp đồng thông minh tài khoản có nghĩa là tồn tại kịch bản tấn công. Vì bộ nhớ tạm khi xác minh chữ ký cho giao dịch mới đến không thu phí gas (nếu thu phí gas trực tiếp sẽ gây ra kịch bản tấn công nghiêm trọng hơn). Người dùng ác ý có thể trước tiên tự định nghĩa hàm xác minh chữ ký siêu phức tạp trong hợp đồng tài khoản của mình, sau đó khởi tạo大量 giao dịch, khiến việc xác minh các giao dịch này đều gọi hàm xác minh chữ ký tùy chỉnh phức tạp, trực tiếp làm cạn kiệt tài nguyên tính toán của nút.
Để tránh tình huống này, StarkNet áp dụng các hạn chế sau đối với giao dịch:
-
Người dùng đơn lẻ trong khoảng thời gian nhất định có giới hạn số lượng giao dịch có thể khởi tạo;
-
Hàm xác minh chữ ký tùy chỉnh trong hợp đồng tài khoản Starknet có giới hạn về độ phức tạp, các hàm xác minh quá phức tạp sẽ không được thực thi. Starknet giới hạn mức tiêu thụ gas tối đa của hàm xác minh chữ ký, nếu lượng gas tiêu thụ vượt quá mức, sẽ trực tiếp từ chối giao dịch. Đồng thời, không cho phép hàm xác minh chữ ký trong hợp đồng tài khoản gọi các hợp đồng khác.
Sơ đồ quy trình giao dịch Starknet như sau:
Đáng chú ý, để tiếp tục tăng tốc quy trình xác minh giao dịch, khách hàng nút Starknet trực tiếp hiện thực các thuật toán xác minh chữ ký của ví Braavos và Argent, khi nút phát hiện giao dịch được tạo từ hai ví Starknet phổ biến này, sẽ gọi thuật toán xác minh chữ ký Braavos/Argent tích hợp sẵn trong khách hàng, thông qua tư tưởng tương tự cache này, Starknet có thể rút ngắn thời gian xác minh giao dịch.
Sau khi dữ liệu giao dịch được xác minh bởi bộ sắp xếp (bộ xác minh của bộ sắp xếp sâu hơn nhiều so với xác minh bộ nhớ tạm), bộ sắp xếp sẽ đóng gói và xử lý các giao dịch từ bộ nhớ tạm, sau đó chuyển cho người tạo bằng chứng ZK. Các giao dịch vào giai đoạn này ngay cả khi thất bại cũng sẽ bị thu phí gas.
Tuy nhiên, nếu bạn đọc hiểu lịch sử Starknet, sẽ phát hiện Starknet giai đoạn đầu không thu phí xử lý cho giao dịch thất bại, tình huống thất bại giao dịch phổ biến nhất là người dùng chỉ có 1ETH, nhưng chuyển ra ngoài 10ETH, giao dịch này rõ ràng có lỗi logic, cuối cùng chắc chắn thất bại, nhưng trước khi thực thi cụ thể thì không ai biết kết quả là gì.
Nhưng StarkNet trong quá khứ không thu phí xử lý cho các giao dịch thất bại này. Những giao dịch lỗi không mất phí này sẽ lãng phí tài nguyên tính toán của nút Starknet, dẫn đến kịch bản tấn công DDoS. Bề ngoài, thu phí xử lý cho giao dịch lỗi dường như rất dễ thực hiện, thực tế lại khá phức tạp. Starknet ra mắt ngôn ngữ Cairo1 mới, phần lớn là để giải quyết vấn đề thu phí gas cho giao dịch thất bại.
Chúng ta đều biết rằng, Bằng chứng ZK là một bằng chứng hiệu lực, trong khi giao dịch thất bại có kết quả vô hiệu, không thể để lại kết quả đầu ra trên chuỗi. Cố gắng dùng bằng chứng hiệu lực để chứng minh một lệnh nào đó thực thi vô hiệu, không tạo ra kết quả đầu ra, nghe đã thấy kỳ lạ, thực tế cũng không khả thi. Do đó, Starknet trong quá khứ khi tạo bằng chứng, trực tiếp loại bỏ các giao dịch thất bại không thể tạo ra kết quả đầu ra.
Sau này đội ngũ Starknet đã áp dụng giải pháp thông minh hơn, xây dựng một ngôn ngữ hợp đồng mới Cairo1, khiến "mọi lệnh giao dịch đều có thể tạo ra kết quả đầu ra và onchain". Nhìn thoáng qua, mọi giao dịch đều tạo ra đầu ra, có nghĩa là không bao giờ xảy ra lỗi logic, trong khi phần lớn giao dịch thất bại là do gặp một số lỗi, khiến lệnh thực thi bị gián đoạn.
Việc khiến giao dịch không bao giờ bị gián đoạn và luôn tạo ra đầu ra là khó thực hiện, nhưng thực tế có một giải pháp thay thế đơn giản, đó là khi giao dịch gặp lỗi logic dẫn đến gián đoạn, vẫn để nó tạo ra kết quả đầu ra, chỉ là lúc này trả về giá trị False, để mọi người biết giao dịch thực thi không thuận lợi.
Tuy nhiên cần lưu ý, trả về giá trị False cũng là trả về kết quả đầu ra, nghĩa là, trong Cairo1, dù lệnh có gặp lỗi logic hay bị gián đoạn tạm thời, đều có thể tạo ra kết quả đầu ra và onchain. Kết quả đầu ra này có thể là chính xác, hoặc là thông tin báo lỗi False.
Ví dụ, giả sử tồn tại đoạn mã sau
Ở đây _balances::read(from) - amount có thể báo lỗi do tràn âm, lúc này sẽ khiến lệnh giao dịch tương ứng bị gián đoạn và dừng thực thi, không để lại kết quả giao dịch trên chuỗi; nếu sửa thành dạng sau, khi giao dịch thất bại vẫn trả về kết quả đầu ra, lưu trên chuỗi, chỉ xét về cảm giác, điều này giống như mọi giao dịch đều thuận lợi để lại kết quả giao dịch trên chuỗi, việc thu phí xử lý thống nhất trở nên đặc biệt hợp lý.
Tổng quan về hợp đồng AA Starknet
Xét đến một phần độc giả bài viết này có thể có nền tảng lập trình, nên ở đây đơn giản trình bày giao diện hợp đồng trừu tượng tài khoản trong Starknet:
Trong giao diện trên, __validate_declare__ dùng để xác minh giao dịch declare do người dùng khởi tạo, trong khi __validate__ dùng để xác minh giao dịch thông thường, chủ yếu xác minh chữ ký người dùng có đúng không, còn __execute__ dùng để thực thi giao dịch. Chúng ta thấy tài khoản hợp đồng Starknet mặc định hỗ trợ multicall tức gọi nhiều lần. Gọi nhiều lần có thể hiện thực một số chức năng thú vị, ví dụ khi tương tác DeFi có thể đóng gói ba giao dịch sau:
-
Giao dịch đầu tiên ủy quyền token cho hợp đồng DeFi
-
Giao dịch thứ hai kích hoạt logic hợp đồng DeFi
-
Giao dịch thứ ba hủy ủy quyền cho hợp đồng DeFi
Tất nhiên, do gọi nhiều lần có tính nguyên tử, nên tồn tại một số cách dùng phức tạp hơn, ví dụ thực thi một số giao dịch arbitrage.
Kết luận
Một vài đặc điểm kỹ thuật chính nhất của Starknet bao gồm ngôn ngữ Cairo thuận lợi cho việc tạo bằng chứng ZK, AA ở cấp độ gốc, mô hình hợp đồng thông minh tách rời logic nghiệp vụ với lưu trữ trạng thái.
Cairo là một ngôn ngữ ZK phổ quát, có thể dùng để hiện thực hợp đồng thông minh trên Starknet cũng như phát triển các ứng dụng truyền thống hơn, quy trình biên dịch đưa vào Sierra làm ngôn ngữ trung gian, giúp Cairo có thể cập nhật thường xuyên mà không cần thay đổi bytecode底层, chỉ cần truyền sự thay đổi tới ngôn ngữ trung gian; thư viện chuẩn của Cairo còn tích hợp nhiều cấu trúc dữ liệu cơ bản cần thiết cho việc trừu tượng hóa tài khoản.
Hợp đồng thông minh Starknet tách riêng việc lưu trữ logic nghiệp vụ và dữ liệu trạng thái, khác với các chuỗi EVM, việc triển khai hợp đồng Cairo bao gồm ba giai đoạn: "biên dịch, khai báo, triển khai", logic nghiệp vụ được khai báo trong Contract class, instance Contract chứa dữ liệu trạng thái có thể liên kết với class và gọi mã từ class đó;
Mô hình hợp đồng thông minh nói trên của Starknet thuận lợi cho việc tái sử dụng mã, tái sử dụng trạng thái hợp đồng, phân tầng lưu trữ, phát hiện hợp đồng rác, cũng thuận lợi cho việc hiện thực thuê lưu trữ và xử lý giao dịch song song. Dù hai tính năng sau vẫn chưa được triển khai, kiến trúc hợp đồng thông minh Cairo vẫn tạo ra "điều kiện cần thiết" cho chúng.
Trên mạng Starknet chỉ tồn tại tài khoản hợp đồng thông minh, không có tài khoản EOA, từ đầu đã hỗ trợ AA mức nguyên bản. Giải pháp AA của nó phần nào tiếp thu tư tưởng từ ERC-4337, cho phép người dùng lựa chọn các phương án xử lý giao dịch tùy chỉnh cao độ. Để ngăn chặn các kịch bản tấn công tiềm ẩn, Starknet đã thực hiện nhiều biện pháp phản công, đóng góp khám phá quan trọng cho hệ sinh thái AA.
Chào mừng tham gia cộng đồng chính thức TechFlow
Nhóm Telegram:https://t.me/TechFlowDaily
Tài khoản Twitter chính thức:https://x.com/TechFlowPost
Tài khoản Twitter tiếng Anh:https://x.com/BlockFlow_News
@godrealmx
