Chuyển tiêu đề ban đầu: Giải mã mô hình hợp đồng thông minh Starknet và ngôn ngữ lập trình AA: Những nhà phát triển công nghệ độc lập

Tác giả gốc: Shew & Faust, Cố vấn Web3: CryptoNerdCn, Nhà phát triển cốt lõi Starknet, Platform Phát triển Cairo Browser-Side WASM Cairo Founder

Tóm tắt:

Các tính năng công nghệ chính của Starknet bao gồm ngôn ngữ Cairo, giúp tạo ra chứng minh ZK, AA cấp độ nguyên thủy và một mô hình hợp đồng thông minh trong đó logic kinh doanh độc lập với lưu trữ trạng thái. Cairo là một ngôn ngữ ZK linh hoạt có thể được sử dụng để triển khai hợp đồng thông minh trên Starknet cũng như phát triển ứng dụng với truyền thống. Quá trình biên dịch của nó giới thiệu Sierra như một ngôn ngữ trung gian, cho phép lặp đi lặp lại Cairo mà không cần thay đổi bytecode cơ bản trực tiếp. Hơn nữa, thư viện tiêu chuẩn của Cairo bao gồm nhiều cấu trúc dữ liệu cơ bản cần thiết cho trừu tượng hóa tài khoản. Hợp đồng thông minh Starknet phân tách logic kinh doanh khỏi lưu trữ dữ liệu trạng thái, khác với chuỗi EVM. Triển khai các hợp đồng Cairo bao gồm ba giai đoạn: biên dịch, khai báo và triển khai, nơi logic kinh doanh được khai báo trong một lớp Hợp đồng. Các trường hợp của các hợp đồng chứa dữ liệu trạng thái có thể được liên kết với lớp và gọi mã mà nó chứa.

Mô hình hợp đồng thông minh trên Starknet như đã nói ở trên có lợi cho việc tái sử dụng mã, tái sử dụng trạng thái hợp đồng, lớp lưu trữ và phát hiện hợp đồng rác. Nó cũng có lợi cho việc thực hiện cho thuê lưu trữ và song song hóa giao dịch. Mặc dù hai điều sau chưa được thực hiện, cấu trúc của 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 lưới Starknet chỉ có các tài khoản hợp đồng thông minh và không có tài khoản EOA. Nó hỗ trợ trừu tượng hóa tài khoản AA cấp độ cơ bản từ đầu. Kế hoạch AA của nó bao gồm các ý tưởng của ERC-4337 một phần, cho phép người dùng lựa chọn các giải pháp xử lý giao dịch được 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òng ngừa và tiến hành các khám phá quan trọng vào hệ sinh thái AA.

Sau khi phát hành token trên Starknet, STRK dần trở thành một yếu tố không thể thiếu trong mắt giới quan sát Ethereum. Ngôi sao Ethereum Layer 2 này, được biết đến với thái độ "độc lập" và "coi thường trải nghiệm người dùng", lặng lẽ tạo ra lãnh thổ riêng của mình trong hệ sinh thái Lớp 2 hưng thịnh tương thích với EVM. Do bị người dùng bỏ bê quá mức, thậm chí công khai thiết lập kênh "ăn xin điện tử" trên Discord, Starknet từng bị cộng đồng chỉ trích. Giữa những cáo buộc là "vô nhân đạo", chuyên môn kỹ thuật sâu sắc của nó dường như ngay lập tức bị mất giá, như thể chỉ có UX và tạo ra sự giàu có là tất cả. Câu thoại trong "The Temple of the Golden Pavilion" - "sự thật về việc không được người khác hiểu là niềm tự hào duy nhất của tôi" - gần như là một bức chân dung tự họa của Starknet. Tuy nhiên, bỏ qua những vấn đề tầm thường này của thế giới, hoàn toàn dựa trên gu kỹ thuật của những người đam mê mã, Starknet và StarkEx, với tư cách là những người tiên phong của ZK Rollup, gần như là kho báu trong mắt những người đam mê Cairo. Trong suy nghĩ của một số nhà phát triển trò chơi blockchain, Starknet và Cairo chỉ đơn giản là mọi thứ trong Web3, vượt qua Solidity và Move. Khoảng cách lớn nhất giữa "chuyên viên kỹ thuật" và "người dùng" ngày nay thực sự phần lớn là do mọi người thiếu hiểu biết về Starknet. Được thúc đẩy bởi sự quan tâm đến công nghệ blockchain và khám phá giá trị của Starknet, tác giả của bài viết này bắt đầu từ mô hình hợp đồng thông minh của Starknet và AA gốc để phác thảo ngắn gọn các giải pháp kỹ thuật và thiết kế cơ chế của nó, nhằm giới thiệu các tính năng kỹ thuật của Starknet cho nhiều người hơn, đồng thời hy vọng sẽ giúp mọi người hiểu được "kiểm lâm đơn độc bị hiểu lầm" này. Sau phần giới thiệu ngắn gọn về ngôn ngữ Cairo trong phần tiếp theo, chúng ta sẽ tập trung thảo luận về mô hình hợp đồng thông minh của Starknet và trừu tượng hóa tài khoản gốc, giải thích cách Starknet đạt được AA gốc. Sau khi đọc bài viết này, độc giả cũng sẽ hiểu tại sao các cụm từ ghi nhớ từ các ví khác nhau không thể trộn lẫn trong Starknet. Nhưng trước khi giới thiệu trừu tượng hóa tài khoản gốc, trước tiên chúng ta hãy hiểu ngôn ngữ Cairo sáng tạo do Starknet tạo ra. Trong quá trình phát triển của Cairo, có những phiên bản đầu tiên được gọi là Cairo0, tiếp theo là phiên bản hiện đại. Cú pháp tổng thể của phiên bản hiện đại của Cairo tương tự như Rust và thực sự là một ngôn ngữ ZK linh hoạt. Bên cạnh việc được sử dụng để viết hợp đồng thông minh trên Starknet, nó cũng có thể được sử dụng để phát triển các ứng dụng chung. Ví dụ: chúng tôi có thể phát triển hệ thống xác minh danh tính ZK bằng ngôn ngữ Cairo và chương trình này có thể chạy trên máy chủ của riêng chúng tôi mà không phụ thuộc vào mạng StarkNet. Có thể nói rằng bất kỳ chương trình nào yêu cầu các thuộc tính tính toán có thể kiểm chứng đều có thể được thực hiện bằng ngôn ngữ Cairo. Và Cairo hiện có thể là ngôn ngữ lập trình có lợi nhất để tạo ra các bằng chứng ZK.

Từ quan điểm của quá trình biên soạn, Cairo sử dụng phương pháp biên soạn dựa trên ngôn ngữ trung gian, như được thể hiện trong hình dưới đây. Sierra trong hình là biểu diễn trung gian (IR) trong quá trình biên soạn ngôn ngữ Cairo, và Sierra sẽ được biên dịch thành một biểu diễn mã nhị phân cấp thấp hơn, được đặt tên là CASM, chạy trực tiếp trên thiết bị nút Starknet.

Việc giới thiệu Sierra như một biểu diễn trung gian giúp cho ngôn ngữ Cairo dễ dàng thêm các tính năng mới hơn. Trong nhiều trường hợp, chỉ cần thao tác với ngôn ngữ trung gian Sierra mà không cần thay đổi trực tiếp mã CASM cơ bản. Điều này giúp tiết kiệm rất nhiều rắc rối, và khách hàng nút của Starknet không cần phải thường xuyên được cập nhật. Điều này cho phép việc lặp đi lặp lại thường xuyên của ngôn ngữ Cairo được thực hiện mà không cần thay đổi logic cơ bản của StarkNet. Thư viện tiêu chuẩn của Cairo cũng bao gồm nhiều cấu trúc dữ liệu cơ bản cần thiết cho trừu tượng hóa tài khoản. Các đổi mới khác của Cairo bao gồm một giải pháp lý thuyết được gọi là Cairo Native, kế hoạch biên dịch Cairo thành mã máy cấp thấp có thể thích ứng với các thiết bị phần cứng khác nhau. Các nút Starknet sẽ không cần phải phụ thuộc vào máy ảo CairoVM khi chạy hợp đồng thông minh. Điều này có thể cải thiện đáng kể tốc độ thực thi mã [vẫn ở giai đoạn lý thuyết và chưa được triển khai].

Mô hình hợp đồng thông minh Starknet: loại bỏ logic mã và lưu trữ trạng thái

Không giống như các chuỗi tương thích Ethereum, Starknet đã đưa ra những đổi mới đột phá trong thiết kế hệ thống hợp đồng thông minh của mình, chủ yếu là để chuẩn bị cho AA bản địa và các tính năng sắp tới như xử lý giao dịch song song. Ở đây, quan trọng là hiểu rằng, khác với các chuỗi công cộng truyền thống như Ethereum, triển khai hợp đồng thông minh trên Starknet tuân theo một quy trình khác. Hãy xem ví dụ về việc triển khai một hợp đồng thông minh Ethereum:

1. Nhà phát triển viết mã hợp đồng thông minh tại địa phương và biên dịch chương trình Solidity thành mã bytecode EVM bằng một trình soạn thảo. Mã bytecode này sau đó có thể được hiểu và xử lý trực tiếp bởi EVM.

1. Nhà phát triển khởi tạo một giao dịch để triển khai hợp đồng thông minh, triển khai mã bytecode EVM đã biên dịch lên chuỗi Ethereum.

Nguồn: not-satoshi.com

Mặc dù hợp đồng thông minh của Starknet cũng tuân theo ý tưởng của việc "biên soạn trước và sau đó triển khai", Hợp đồng thông minh được triển khai trên chuỗi dưới dạng bytecode CASM được hỗ trợ bởi CairoVM. Tuy nhiên, có sự khác biệt lớn giữa Starknet và các chuỗi tương thích với EVM trong phương pháp gọi và chế độ lưu trữ trạng thái của hợp đồng thông minh. Cụ thể, hợp đồng thông minh Ethereum = logic kinh doanh + thông tin trạng thái. Ví dụ, hợp đồng USDT không chỉ thực hiện các chức năng thông thường như Chuyển khoản và Ủy quyền, mà còn lưu trữ trạng thái tài sản của tất cả người giữ USDT. Code và trạng thái được kết hợp với nhau, điều này mang lại rất nhiều rắc rối. Trước hết, điều này không tạo điều kiện cho việc nâng cấp hợp đồng DAPP và di dời trạng thái, cũng không tạo điều kiện cho xử lý song song của giao dịch. Đây là một gánh nặng kỹ thuật nặng nề.

Để đáp ứng điều này, Starknet đã cải thiện cách lưu trữ trạng thái. Trong giải pháp triển khai hợp đồng thông minh của mình, logic kinh doanh của DApps hoàn toàn tách rời khỏi trạng thái tài sản và được lưu trữ riêng biệt. Lợi ích của phương pháp này là rõ ràng: thứ nhất, nó cho phép hệ thống nhanh chóng phân biệt xem có triển khai mã trùng lặp hay dư thừa hay không. Đây là cách nó hoạt động: trong Ethereum, một hợp đồng thông minh bao gồm cả logic kinh doanh và dữ liệu trạng thái. Nếu nhiều hợp đồng có logic nghiệp vụ giống hệt nhau nhưng dữ liệu trạng thái khác nhau, hàm băm của chúng cũng sẽ khác nhau, khiến hệ thống khó xác định liệu "hợp đồng rác" có tồn tại hay không. Tuy nhiên, trong giải pháp của Starknet, dữ liệu mã và trạng thái được tách biệt, giúp hệ thống dễ dàng phát hiện xem cùng một mã đã được triển khai nhiều lần hay chưa dựa trên hàm băm của phần mã. Điều này giúp ngăn chặn việc triển khai mã trùng lặp và tiết kiệm dung lượng lưu trữ trên các nút Starknet.

Trong hệ thống hợp đồng thông minh của Starknet, việc triển khai và sử dụng hợp đồng được chia thành ba giai đoạn: "biên soạn, khai báo và triển khai." Nếu một nhà phát hành tài sản muốn triển khai một hợp đồng Cairo, họ trước tiên biên soạn mã Cairo đã viết thành các dạng bytecode Sierra và CASM cấp thấp trên thiết bị cục bộ của họ. Sau đó, người triển khai hợp đồng công bố một giao dịch "khai báo", triển khai bytecode CASM của hợp đồng và mã trung gian Sierra lên chuỗi, được đặt tên là Lớp Hợp đồng.

(Nguồn: Trang web chính thức của Starknet)

Sau đó, nếu bạn muốn sử dụng các khả năng hàm được xác định trong hợp đồng tài sản, bạn có thể bắt đầu giao dịch "triển khai" thông qua giao diện người dùng DApp để triển khai phiên bản Hợp đồng được liên kết với Lớp hợp đồng. Phiên bản này sẽ giữ trạng thái tài sản. Sau đó, người dùng có thể gọi các hàm trong Lớp hợp đồng để sửa đổi trạng thái của phiên bản Hợp đồng. Trên thực tế, bất cứ ai quen thuộc với lập trình hướng đối tượng đều dễ dàng hiểu Class và Instance đại diện cho điều gì trong Starknet. Lớp hợp đồng được các nhà phát triển tuyên bố chỉ chứa logic nghiệp vụ của hợp đồng thông minh, bao gồm các chức năng mà bất kỳ ai cũng có thể gọi, nhưng nó không có trạng thái tài sản thực tế, do đó không trực tiếp thực hiện "thực thể tài sản", chỉ có "linh hồn" mà không có "cơ thể". Tuy nhiên, khi người dùng triển khai các phiên bản Hợp đồng cụ thể, các tài sản sẽ được "cụ thể hóa". Nếu bạn cần sửa đổi trạng thái của "thực thể" tài sản, chẳng hạn như chuyển mã thông báo của bạn cho người khác, bạn có thể gọi trực tiếp các hàm được viết trong Lớp hợp đồng. Quá trình trên có phần giống với "khởi tạo" trong các ngôn ngữ lập trình hướng đối tượng truyền thống (mặc dù không hoàn toàn giống nhau).

Sau khi hợp đồng thông minh được phân tách thành các lớp và phiên bản, logic kinh doanh và dữ liệu trạng thái được tách rời, mang đến các tính năng sau cho Starknet:

1. Có lợi cho việc thực hiện phân loại lưu trữ và “hệ thống thuê lưu trữ”

Lớp lưu trữ được gọi là lớp lớp bởi các nhà phát triển có thể đặt dữ liệu vào các vị trí tùy chỉnh theo nhu cầu của họ, chẳng hạn dưới chuỗi Starknet. StarkNet đã sẵn sàng tương thích với các lớp DA như Celestia, và các nhà phát triển DAPP có thể lưu trữ dữ liệu trong những lớp DA bên thứ ba này. Ví dụ, một trò chơi có thể lưu trữ dữ liệu tài sản quan trọng nhất của mình trên mạng chính Starknet, và lưu trữ dữ liệu khác trong các lớp DA ngoại tuyến như Celestia. Giải pháp này của việc tùy chỉnh lớp DA theo yêu cầu bảo mật được đặt tên là “Volition” bởi Starknet.

Hệ thống thuê lưu trữ tự giọng nói có nghĩa là mọi người nên tiếp tục thanh toán cho không gian lưu trữ mà họ sử dụng. Bất kỳ không gian nào trên chuỗi mà bạn chiếm đóng, lý thuyết bạn nên tiếp tục thanh toán tiền thuê.

Trong mô hình hợp đồng thông minh Ethereum, quyền sở hữu của hợp đồng không rõ ràng, và khó phân biệt xem người triển khai hay người giữ tài sản nên trả tiền "thuê" cho một hợp đồng ERC-20. Chức năng cho thuê lưu trữ chưa được triển khai trong một thời gian dài, và người triển khai chỉ bị tính phí khi hợp đồng được triển khai. Mô hình phí lưu trữ này là không hợp lý.

Dưới mô hình hợp đồng thông minh của Starknet, Sui, CKB và Solana, quyền sở hữu của hợp đồng thông minh được chia rõ hơn, làm cho việc thu tiền lưu trữ dễ dàng hơn [Hiện tại, Starknet không trực tiếp triển khai hệ thống cho thuê lưu trữ, nhưng sẽ được triển khai trong tương lai]

1. Đạt được việc sử dụng mã nguồn thực sự và giảm việc triển khai các hợp đồng rác

Chúng ta có thể khai báo một hợp đồng token tổng quát được lưu trữ trên chuỗi dưới dạng một lớp, sau đó mọi người có thể gọi các chức năng trong lớp này để triển khai các phiên bản token của họ. Ngoài ra, hợp đồng cũng có thể trực tiếp gọi mã trong lớp, điều này đạt được hiệu ứng tương tự như chức năng thư viện trong Solidity. Đồng thời, mô hình hợp đồng thông minh của Starknet giúp xác định “hợp đồng rác”. Điều này đã được giải thích trước đó. 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 được tải lên chuỗi và giảm áp lực lưu trữ trên các nút càng nhiều càng tốt.

1. Tái sử dụng trạng thái hợp đồng thực

Nâng cấp hợp đồng trên blockchain chủ yếu liên quan đến việc thay đổi logic kinh doanh. Trong kịch bản Starknet, logic kinh doanh của các hợp đồng thông minh được tách biệt với tình trạng tài sản. Nếu phiên bản hợp đồng thay đổi loại lớp hợp đồng liên quan, việc nâng cấp logic kinh doanh có thể được hoàn thành. Không cần phải di dời tình trạng tài sản đến một nơi mới. Hình thức nâng cấp hợp đồng này cẩn thận và gốc gác hơn so với Ethereum.

Để thay đổi logic kinh doanh của một hợp đồng Ethereum, thường cần 'ngoại giao' logic kinh doanh cho một hợp đồng đại lý, và thay đổi logic kinh doanh của hợp đồng chính bằng cách thay đổi hợp đồng đại lý phụ thuộc. Tuy nhiên, phương pháp này không đủ súc tích và không 'bản xứ' đủ.

Nguồn: Học viện wtf

Trong một số tình huống, nếu hợp đồng Ethereum cũ bị hoàn toàn bỏ rơi, trạng thái tài sản bên trong không thể được di chuyển trực tiếp sang nơi mới, điều này rất phiền toái; hợp đồng Cairo không cần di chuyển trạng thái và có thể trực tiếp “tái sử dụng” trạng thái cũ.

1. Thuận lợi cho xử lý song song các giao dịch

Để tối đa hóa sự song song của các hướng dẫn giao dịch khác nhau, một bước cần thiết là lưu trữ tình trạng tài sản của các người khác nhau ở các vị trí riêng biệt, như có thể thấy trong Bitcoin, CKB và Sui. Điều kiện tiên quyết cho mục tiêu trên là phân tách logic kinh doanh của các hợp đồng thông minh khỏi dữ liệu tình trạng tài sản. Mặc dù Starknet chưa thực hiện triển khai kỹ thuật song song sâu rộng của các giao dịch, nó sẽ coi các giao dịch song song là một mục tiêu quan trọng trong tương lai.

Triển khai hợp đồng tài khoản và hợp đồng tài khoản gốc của Starknet

Trong thực tế, khái niệm về trừu tượng hóa tài khoản (AA) và EOA (các tài khoản sở hữu bên ngoài) đã được cộng đồng Ethereum phát minh ra như một khái niệm độc đáo. Trong nhiều chuỗi công khai mới, không có sự phân biệt giữa các tài khoản EOA và tài khoản hợp đồng thông minh, tránh được những rủi ro của hệ thống tài khoản theo kiểu Ethereum từ đầu. Ví dụ, dưới cài đặt của Ethereum, người điều khiển tài khoản EOA phải có ETH trên chuỗi trước khi anh ấy có thể khởi tạo một giao dịch. Không có cách nào để trực tiếp chọn lựa giữa các phương pháp xác thực khác nhau, và việc thêm một số logic thanh toán tùy chỉnh là vô cùng phiền toái. Một số người thậm chí nghĩ rằng thiết kế tài khoản của Ethereum đơn giản là chống lại con người.

Nếu chúng ta nhìn vào các sản phẩm cờ vững như Starknet hoặc chuỗi zkSyncEra "Native AA", rõ ràng sẽ có sự khác biệt: đầu tiên, Starknet và zkSyncEra có loại tài khoản thống nhất. Chỉ có tài khoản hợp đồng thông minh trên chuỗi. Không có khái niệm về tài khoản EOA từ đầu. (Thời kỳ zkSync sẽ triển khai một bộ mã hợp đồng mặc định trên tài khoản mới được tạo bởi người dùng để mô phỏng các đặc điểm của tài khoản EOA Ethereum, để nó tương thích với Metamask).

Tuy nhiên, Starknet không xem xét trực tiếp tính tương thích với các phụ kiện Ethereum như Metamask. Khi người dùng sử dụng ví Starknet lần đầu tiên, một tài khoản hợp đồng được triển khai tự động. Nói cách khác, trường hợp hợp đồng đã được đề cập trước đó được triển khai, và trường hợp này liên kết với lớp hợp đồng được triển khai trước bởi dự án ví. Người dùng có thể trực tiếp gọi một số chức năng được viết trong lớp này. Bây giờ, hãy khám phá một chủ đề thú vị: khi yêu cầu nhận STRK airdrops, nhiều người phát hiện rằng các ví Argent và Braavos không tương thích với nhau. Nhập mnemonic từ Argent sang Braavos không cho phép xuất tài khoản tương ứng, chủ yếu do các thuật toán tạo tài khoản khác nhau được sử dụng bởi Argent và Braavos, dẫn đến việc tạo ra các địa chỉ tài khoản khác nhau từ cùng một mnemonic. Cụ thể, trong Starknet, địa chỉ hợp đồng mới triển khai có thể được suy ra thông qua một thuật toán xác định, như sau:

Các function ‘pedersen()’ được đề cập ở trên là một thuật toán băm dễ sử dụng trong các hệ thống ZK. Quá trình tạo tài khoản liên quan đến việc cung cấp một số tham số đặc biệt cho hàm pedersen để tạo ra băm tương ứng, đó chính là địa chỉ tài khoản được tạo ra. Hình ảnh ở trên cho thấy các tham số được sử dụng bởi Starknet để tạo ra “địa chỉ hợp đồng mới”. ‘deployer_address’ đại diện cho địa chỉ của 'người triển khai hợp đồng'. Tham số này có thể trống, có nghĩa là ngay cả khi bạn không có tài khoản hợp đồng Starknet từ trước, bạn vẫn có thể triển khai một hợp đồng mới. ‘salt’ là giá trị muối được sử dụng để tính địa chỉ hợp đồng, đó chính là một số ngẫu nhiên được giới thiệu để tránh trùng lặp địa chỉ hợp đồng. ‘class_hash’ tương ứng với giá trị băm của lớp được đề cập trước đó, mà thể hiện liên kết với phiên bản hợp đồng. ‘constructor_calldata_hash’ đại diện cho băm của các tham số khởi tạo của hợp đồng.

Dựa trên công thức trên, người dùng có thể tính địa chỉ hợp đồng được tạo ra 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 tài khoản Starknet trước đó, như sau:

1. Người dùng đầu tiên xác định phiên bản hợp đồng mà họ muốn triển khai và lớp hợp đồng nào để liên kết với nó, sử dụng băm của lớp như một trong các tham số khởi tạo, và tính muối để xác định địa chỉ hợp đồng được tạo.
2. Sau khi biết nơi họ sẽ triển khai hợp đồng, người dùng trước tiên chuyển một số lượng ETH nhất định đến địa chỉ đó như là phí triển khai hợp đồng. Thông thường, ETH này cần được chuyển từ L1 sang mạng Starknet qua cầu liên chuỗi.
3. Người dùng khởi tạo yêu cầu giao dịch để triển khai hợp đồng.

Trong thực tế, tất cả các tài khoản Starknet đều được triển khai thông qua quy trình trên, nhưng hầu hết các ví tiền điện tử che giấu chi tiết, và người dùng không nhận ra quá trình triển khai tài khoản hợp đồng của họ ngay sau khi họ chuyển ETH.

Giải pháp trên đã gây ra một số vấn đề về sự tương thích, bởi vì khi các ví khác nhau tạo địa chỉ tài khoản, kết quả tạo ra là không nhất quán. Chỉ các ví đáp ứng các điều kiện sau mới có thể được kết hợp:

1. Khóa riêng tư được tạo ra từ khóa công khai được sử dụng bởi ví là giống như thuật toán chữ ký;
2. Quá trình tính toán muối của ví tiền là như vậy;
3. Các lớp hợp đồng thông minh của ví không khác biệt về chi tiết triển khai cơ bản; \

Trong trường hợp được đề cập trước đó, cả Argent và Braavos đều sử dụng thuật toán chữ ký ECDSA, nhưng phương pháp tính muối khác nhau giữa hai bên, dẫn đến việc tạo địa chỉ tài khoản không nhất quán từ cùng một mnemonic.

Bây giờ, hãy xem xét lại vấn đề trừu tượng hóa tài khoản. Starknet và zkSync Era đã di chuyển một loạt quy trình liên quan đến xử lý giao dịch, chẳng hạn như xác minh danh tính (xác minh chữ ký số) và thanh toán phí gas, ra khỏi “lớp chuỗi.” Người dùng có thể tùy chỉnh chi tiết triển khai của logic trên trong tài khoản của họ. Ví dụ, bạn có thể triển khai một chức năng xác minh chữ ký số chuyên dụng trong tài khoản hợp đồng thông minh của Starknet của bạn. Khi một nút Starknet nhận được một giao dịch được khởi tạo bởi bạn, nó sẽ gọi một loạt logic xử lý giao dịch do bạn tùy chỉnh trên chuỗi.

Phương pháp này rõ ràng cung cấp linh hoạt hơn. Tuy nhiên, trong thiết kế của Ethereum, logic như xác minh danh tính (chữ ký số) được cứng đặt vào mã nguồn khách hàng node và không thể hỗ trợ các tính năng tài khoản tùy chỉnh một cách tự nhiên.

Sơ đồ mô phỏng của giải pháp AA bản địa được chỉ định bởi kiến trúc sư Starknet. Xác minh giao dịch và xác minh phí gas được chuyển đến hợp đồng on-chain để xử lý. Máy ảo ảo hóa cơ bản của chuỗi có thể gọi các chức năng này được tùy chỉnh hoặc được chỉ định bởi người dùng.

Theo các quan chức của zkSyncEra và Starknet, cách tiếp cận modul này đối với chức năng tài khoản được lấy cảm hứng từ EIP-4337. Tuy nhiên, điều làm cho họ khác biệt là zkSync và Starknet đã hợp nhất loại tài khoản từ đầu, thống nhất loại giao dịch và sử dụng một điểm nhập duy nhất để nhận và xử lý tất cả các giao dịch. Ngược lại, Ethereum, do gánh nặng lịch sử và mong muốn của quỹ để tránh các chiến lược cải tiến quyết đoán như hard forks càng nhiều càng tốt, đã hỗ trợ EIP-4337, sử dụng một cách khác để giải quyết vấn đề. Tuy nhiên, kết quả là tài khoản EOA và các giải pháp EIP-4337 mỗi loại đều có quy trình xử lý giao dịch độc lập, dường như vụng về và cồng kềnh, không giống như tính linh hoạt của AAs bản địa.

Nguồn: ArgentWallet

Tuy nhiên, sự trừu tượng hóa tài khoản gốc trong Starknet vẫn chưa đạt đến độ chín hoàn toàn. Từ quan điểm thực tế, trong khi các tài khoản AA của Starknet đã triển khai các thuật toán xác minh chữ ký tùy chỉnh, họ hiện chỉ hỗ trợ thanh toán phí gas bằng ETH và STRK và chưa hỗ trợ thanh toán gas của bên thứ ba. Do đó, sự tiến bộ của Starknet trong các AA bản địa có thể được mô tả là "khung lý thuyết hầu hết đã trưởng thành, trong khi việc triển khai thực tế vẫn đang được tiến hành". Vì Starknet chỉ có tài khoản hợp đồng thông minh trong nội bộ, toàn bộ quá trình giao dịch của nó có tính đến ảnh hưởng của các hợp đồng thông minh tài khoản. Đầu tiên, sau khi nhận được giao dịch bởi nhóm bộ nhớ của nút Starknet (Mempool), nó sẽ trải qua quá trình xác minh, bao gồm:

1. Kiểm tra xem chữ ký số của giao dịch có đúng không, ở đó chức năng xác minh tùy chỉnh của tài khoản người ký được gọi;
2. Xác minh xem số dư tài khoản của người khởi xướng có thể chi trả phí gas hay không. \

Cần lưu ý ở đây rằng việc sử dụng chức năng xác minh chữ ký tùy chỉnh trong hợp đồng thông minh tài khoản có nghĩa là có một kịch bản tấn công. Bởi vì bộ nhớ không tính phí gas khi xác minh chữ ký của các giao dịch mới. (Nếu tính phí gas trực tiếp, sẽ xảy ra các kịch bản tấn công nghiêm trọng hơn). Người dùng độc hại có thể tùy chỉnh trước một chức năng xác minh chữ ký siêu phức tạp trong hợp đồng tài khoản của họ, sau đó khởi động một lượng lớn giao dịch. Khi những giao dịch này được xác minh, chúng sẽ gọi chức năng xác minh chữ ký phức tạp tùy chỉnh, có thể 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 đặt các hạn chế sau đối với giao dịch:

1. Có một giới hạn trên số giao dịch mà một người dùng có thể khởi tạo trong một đơn vị thời gian;
2. Chức năng xác thực chữ ký tùy chỉnh trong hợp đồng tài khoản Starknet có các hạn chế về độ phức tạp, và các chức năng xác thực chữ ký quá phức tạp sẽ không được thực thi. Starknet giới hạn mức tiêu thụ gas của chức năng xác thực chữ ký. Nếu lượng gas tiêu thụ bởi chức năng xác thực chữ ký quá cao, giao dịch sẽ bị từ chối trực tiếp. Đồng thời, chức năng xác thực chữ ký trong hợp đồng tài khoản không được phép gọi các hợp đồng khác.

Biểu đồ luồng giao dịch của Starknet như sau:

Điều đáng chú ý là, để đẩy nhanh hơn nữa quá trình xác minh giao dịch, ứng dụng khách nút Starknet đã trực tiếp triển khai các thuật toán xác minh chữ ký của ví Braavos và Argent. Khi một nút phát hiện các giao dịch được tạo ra từ hai ví Starknet chính thống này, nó sẽ gọi các thuật toán chữ ký Braavos / Argent tích hợp trong máy khách. Thông qua cách tiếp cận giống như bộ nhớ đệm 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 thực bởi bộ sắp xếp (các bước xác minh của bộ sắp xếp kỹ lưỡng hơn nhiều so với các bước của nhóm bộ nhớ), bộ sắp xếp sẽ đóng gói và gửi các giao dịch từ nhóm bộ nhớ đến trình tạo bằng chứng ZK. Các giao dịch bước vào giai đoạn này sẽ bị tính phí gas ngay cả khi chúng không thành công. Tuy nhiên, nếu độc giả quen thuộc với lịch sử của Starknet, họ sẽ nhận thấy rằng các phiên bản trước của Starknet không tính phí cho các giao dịch thất bại. Trường hợp phổ biến nhất cho lỗi giao dịch là khi người dùng chỉ có 1 ETH nhưng cố gắng chuyển 10 ETH ra bên ngoài, điều này cho thấy rõ lỗi logic và chắc chắn sẽ thất bại, nhưng không ai biết kết quả trước khi thực hiện. Tuy nhiên, trước đây, StarkNet không tính phí cho các giao dịch thất bại như vậy. Những giao dịch sai lầm miễn phí này làm lãng phí tài nguyên tính toán nút Starknet và có thể dẫn đến các kịch bản tấn công DDoS. Nhìn bề ngoài, việc tính phí cho các giao dịch sai có vẻ đơn giản, nhưng trên thực tế, nó khá phức tạp. Starknet đã giới thiệu một phiên bản mới của ngôn ngữ Cairo1 chủ yếu để giải quyết vấn đề phí gas cho các giao dịch thất bại. Như chúng ta đã biết, bằng chứng ZK là bằng chứng về tính hợp lệ và kết quả của giao dịch thất bại là không hợp lệ và không thể để lại kết quả đầu ra trên chuỗi. Cố gắng sử dụng bằng chứng hợp lệ để chứng minh rằng một lệnh thực thi nhất định là không hợp lệ và không thể tạo ra kết quả đầu ra nghe có vẻ lạ và thực sự không thể thực hiện được. Do đó, trong quá khứ, Starknet đã loại trừ các giao dịch thất bại không thể tạo ra kết quả đầu ra khi tạo bằng chứng. Nhóm Starknet sau đó đã áp dụng một giải pháp thông minh hơn và xây dựng một ngôn ngữ hợp đồng mới, Cairo1, đảm bảo rằng "tất cả các hướng dẫn giao dịch có thể tạo ra kết quả đầu ra và nằm trên chuỗi". Thoạt nhìn, thực tế là tất cả các giao dịch có thể tạo ra kết quả đầu ra có nghĩa là lỗi logic không bao giờ xảy ra. Tuy nhiên, hầu hết thời gian, các giao dịch không thành công vì chúng gặp phải các lỗi làm gián đoạn việc thực hiện lệnh. Đảm bảo rằng các giao dịch không bao giờ bị gián đoạn và tạo ra thành công kết quả đầu ra là khó đạt được, nhưng thực sự có một giải pháp thay thế đơn giản, đó là cho phép các giao dịch tạo ra kết quả đầu ra khi gặp lỗi logic dẫn đến gián đoạn, mặc dù trả về giá trị False cho thấy việc thực hiện giao dịch không trơn tru. Điều quan trọng cần lưu ý là trả về giá trị False cũng trả về kết quả đầu ra, có nghĩa là trong Cairo1, bất kể lệnh gặp lỗi logic hay tạm thời bị gián đoạn, nó có thể tạo ra kết quả đầu ra và nằm trên chuỗi. Kết quả đầu ra này có thể đúng hoặc thông báo lỗi Sai. Ví dụ: hãy xem xét đoạn mã sau:

Tại thời điểm này, _balances::read(from) - amount có thể gây ra lỗi tràn số, dẫn đến việc chỉ thị giao dịch tương ứng bị gián đoạn và dừng lại mà không để lại kết quả giao dịch nào trên chuỗi. Tuy nhiên, nếu nó được viết lại dưới dạng sau đây, nó vẫn trả về một kết quả đầu ra khi giao dịch thất bại, để lại nó trên chuỗi. Chỉ từ quan điểm thẩm mỹ, dường như tất cả các giao dịch có thể mượt mà để lại đầu ra giao dịch trên chuỗi, khiến việc thu phí đồng đều trở nên hợp lý đặc biệt.

Tổng quan về Hợp đồng StarknetAA

Xét đến việc một số độc giả của bài viết này có lịch sử lập trình, dưới đây là một biểu diễn ngắn gọn về giao diện của hợp đồng trừu tượng tài khoản trong Starknet:

The validate_declaregiao diện được đề cập ở trên được sử dụng để xác minh giao dịch tuyên bố được khởi xướng bởi người dùng, trong khi xác thựcđược sử dụng để xác nhận giao dịch chung, chủ yếu là xác minh tính chính xác của chữ ký người dùng. Trong khi đó, thực thi được sử dụng để thực thi giao dịch. Đáng chú ý, các tài khoản hợp đồng Starknet hỗ trợ đa gọi mặc định, cho phép thực hiện nhiều cuộc gọi. Chức năng đa gọi có thể hỗ trợ nhiều tính năng thú vị, chẳng hạn như gói ghém ba giao dịch sau khi tương tác với một số giao thức DeFi cụ thể:

1. Ủy quyền token cho hợp đồng DeFi trong giao dịch đầu tiên.
2. Kích hoạt logic của hợp đồng DeFi trong giao dịch thứ hai.
3. Thu hồi quyền cho hợp đồng DeFi trong giao dịch thứ ba.

Tất nhiên, do tính nguyên tử của multicall, có nhiều trường hợp sử dụng phức tạp hơn, như thực hiện giao dịch cơ hội.

Tóm tắt

Các tính năng công nghệ chính của Starknet bao gồm ngôn ngữ Cairo được tối ưu hóa cho việc tạo chứng minh ZK, trừu tượng hóa tài khoản cấp độ native, và mô hình hợp đồng thông minh tách biệt logic kinh doanh khỏi lưu trữ trạng thái.

Cairo là một ngôn ngữ ZK linh hoạt có thể được sử dụng cho 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. Quá trình biên dịch của nó giới thiệu Sierra là một ngôn ngữ trung gian, cho phép Cairo lặp đi lặp lại một cách thường xuyên mà không thay đổi bytecode cơ bản, chỉ lan truyền các thay đổi đến ngôn ngữ trung gian. Thư viện tiêu chuẩn của Cairo cũng bao gồm nhiều cấu trúc dữ liệu cơ bản cần thiết cho trừu tượng hóa tài khoản.

Hợp đồng thông minh của Starknet phân tách logic kinh doanh khỏi lưu trữ dữ liệu trạng thái, không giống như 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 và triển khai. Logic kinh doanh được khai báo trong các lớp Hợp đồng, và các trường hợp Hợp đồng chứa dữ liệu trạng thái có thể được liên kết với một lớp và gọi mã mà nó chứa.

Mô hình hợp đồng thông minh của Starknet tạo điều kiện 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, lớp lưu trữ và phát hiện hợp đồng rác. Nó cũng tạo điều kiện cho việc triển khai cho việc cho thuê lưu trữ và song song hóa giao dịch, mặc dù những tính năng này chưa được triển khai hoàn toàn. Kiến trúc của hợp đồng thông minh Cairo tạo điều kiện cần thiết cho những tính năng này.

Starknet chỉ có tài khoản hợp đồng thông minh, không có tài khoản EOA, và hỗ trợ trừu tượng hóa tài khoản AA cấp độ bản địa từ đầu. Giải pháp AA của nó một phần hấp thụ các ý tưởng của ERC-4337, cho phép người dùng lựa chọn các giải pháp xử lý giao dịch được tùy chỉnh cao. Để ngăn chặn các kịch bản tấn công tiềm năng, Starknet đã triển khai các biện pháp ngăn chặn khác nhau, đồng thời thực hiện những khám phá quan trọng cho hệ sinh thái AA.

Tuyên bố từ chối trách nhiệm：

1. Bài này được sao chép từ [ 极客 Web3]. *Chuyển tiếp Tiêu đề Gốc ‘解读Starknet智能合约模型与原生AA：特立独行的技术巨匠’. Tất cả bản quyền thuộc về tác giả gốc [Shew & Faust]. Nếu có ý kiến phản đối về việc sao chép này, vui lòng liên hệ Học viện Gateđội ngũ, và họ sẽ xử lý nhanh chóng.
2. Miễn trách nhiệm về trách nhiệm: Các quan điểm và ý kiến được thể hiện trong bài viết này chỉ thuộc về tác giả và không cấu thành bất kỳ lời khuyên đầu tư nào.
3. Các bản dịch của bài viết sang các ngôn ngữ khác được thực hiện bởi nhóm Gate Learn. Trừ khi được đề cập, việc sao chép, phân phối hoặc đạo văn các bài viết dịch là không được phép.