Được viết bởi: Shew & Faust, web3 đam mê
Nhà tư vấn: CryptoNerdCn, nhà phát triển cốt lõi của hệ sinh thái Starknet, người sáng lập nền tảng phát triển Cairo phía trình duyệt WASM Cairo
Bản tóm tắt:
Các tính năng kỹ thuật chính của Starknet bao gồm ngôn ngữ Cairo tạo điều kiện cho việc tạo bằng chứng ZK, AA cấp độ gốc và các mô hình hợp đồng thông minh độc lập với logic kinh doanh và lưu trữ trạng thái.
Cairo là ngôn ngữ ZK phổ quát có thể được sử dụng để triển khai hợp đồng thông minh trên Starknet hoặc để phát triển các ứng dụng truyền thống hơn. Sierra được giới thiệu là ngôn ngữ trung gian trong quá trình biên dịch, cho phép Cairo lặp lại thường xuyên mà không cần phải thay đổi lớp dưới cùng. chỉ cần truyền các thay đổi sang 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 việc trừu tượng hóa tài khoản.
Hợp đồng thông minh Starknet lưu trữ dữ liệu trạng thái và logic kinh doanh riêng biệt. Khác với chuỗi EVM, việc triển khai hợp đồng Cairo bao gồm ba giai đoạn "biên soạn, khai báo và triển khai". Logic nghiệp vụ được khai báo trong lớp Hợp đồng và phiên bản Hợp đồng chứa trạng thái dữ liệu có thể được kết hợp với lớp Thiết lập một liên kết và gọi mã có trong lớp sau;
Mô hình hợp đồng thông minh nêu trên của Starknet có 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ữ và phát hiện các hợp đồng rác, đồng thời có lợi cho việc thực hiện cho thuê kho lưu trữ và song song hóa giao dịch. Mặc dù hai điều sau vẫn chưa được triển khai nhưng 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.
Chỉ có tài khoản hợp đồng thông minh trên chuỗi Starknet 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 gốc ngay từ đầu. Giải pháp AA của nó tiếp thu các ý tưởng của ERC-4337 ở một mức độ nhất định, cho phép người dùng lựa chọn các giải pháp xử lý giao dịch có tính 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 đối phó và thực hiện các cuộc thăm dò quan trọng vào hệ sinh thái AA.
Văn bản: Sau khi Starknet phát hành token, STRK đã dần trở thành một trong những yếu tố không thể thiếu trong mắt những người quan sát Ethereum. Ngôi sao Ethereum Lớp 2 này, người luôn nổi tiếng là “maverick” và “không chú ý đến trải nghiệm người dùng”, giống như một ẩn sĩ sống xa cách với thế giới, lặng lẽ tạo ra chỗ đứng riêng cho mình trong hệ sinh thái Lớp 2 nơi EVM khả năng tương thích là phổ biến.
Văn bản: Sau khi Starknet phát hành token, STRK đã dần trở thành một trong những yếu tố không thể thiếu trong mắt những người quan sát Ethereum. Ngôi sao Ethereum Lớp 2 này, người luôn nổi tiếng là “maverick” và “không chú ý đến trải nghiệm người dùng”, giống như một ẩn sĩ sống xa cách với thế giới, lặng lẽ tạo ra chỗ đứng riêng cho mình trong hệ sinh thái Lớp 2 nơi EVM khả năng tương thích là phổ biến.
Vì phớt lờ người dùng quá nhiều, thậm chí còn công khai mở kênh "ăn xin điện tử" trên Discord, Starknet từng bị Đảng Lữ Mao chỉ trích. dường như chỉ có UX và hiệu ứng tạo ra của cải là tất cả. Câu nói "Không được người khác hiểu đã trở thành niềm tự hào duy nhất của tôi" trong "Chùa Vàng" chỉ đơn giản là bức chân dung tự họa của Starknet.
Nhưng gác những vấn đề tầm thường này sang một bên, hoàn toàn dựa trên “khẩu vị kỹ thuật” của những người đam mê mã, Starknet và StarkEx, một trong những người tiên phong của ZK Rollup, gần như là báu vật trong mắt những người đam mê Cairo. các nhà phát triển, Starknet và Cairo đơn giản là tất cả mọi thứ về web3, và cả Solidity lẫn Move đều không thể so sánh được với họ. Khoảng cách thế hệ lớn nhất giữa "những người đam mê kỹ thuật" và "người dùng" ngày nay thực sự còn nhiều hơn do sự thiếu hiểu biết của mọi người về Starknet.
Với sự quan tâm và mong muốn khám phá công nghệ blockchain, cũng như 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 và AA gốc của Starknet, đồng thời sắp xếp ngắn gọn các giải pháp kỹ thuật và thiết kế cơ chế của nó, đồng thời giới thiệu nó cho nhiều người hơn Trong khi khám phá các tính năng kỹ thuật của Starknet, chúng tôi cũng hy vọng có thể để mọi người hiểu rõ hơn về "người kiểm lâm đơn độc mà người khác không hiểu" này.
Phổ biến khoa học tối giản ngôn ngữ Cairo
Sau đây, chúng tôi sẽ tập trung vào mô hình hợp đồng thông minh và tính trừu tượng hóa tài khoản gốc của Starknet, đồng thời giải thích cách Starknet triển khai AA gốc. Đọc xong bài viết này mọi người cũng có thể hiểu tại sao không thể trộn lẫn các cụm từ ghi nhớ của các ví khác nhau trong Starknet.
Nhưng trước khi giới thiệu phần tóm tắt tài khoản gốc, trước tiên chúng ta hãy hiểu ngôn ngữ Cairo gốc của Starknet. Trong quá trình phát triển Cairo, có một phiên bản đầu tiên tên là Cairo0, và sau đó 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, thực ra nó là một ngôn ngữ ZK chung, ngoài việc viết các hợp đồng thông minh trên Starknet, nó còn có thể được sử dụng để phát triển các ứng dụng chung.
Ví dụ: chúng tôi có thể sử dụng ngôn ngữ Cairo để phát triển hệ thống xác thực ZK, chương trình này có thể chạy trên máy chủ do chúng tôi xây dựng mà không cần dựa 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. Cairo có thể là ngôn ngữ lập trình thuận lợi nhất để tạo ra các bằng chứng ZK hiện nay.
Từ góc độ của quá 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ư trong hình bên dưới. Sierra trong hình là dạng trung gian (IR) trong quá trình biên dịch ngôn ngữ Cairo và Sierra sẽ được biên dịch thành dạng mã nhị phân cấp thấp hơn, có 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 là dạng trung gian giúp 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, bạn 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à nút Starknet client không cần phải cập nhật thường xuyên. Bằng cách này, có thể đạt được sự lặp lại thường xuyên của ngôn ngữ Cairo mà không làm 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 việc trừu tượng hóa tài khoản.
Những cải tiến khác của Cairo bao gồm một giải pháp lý thuyết có tên Cairo Native, có 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 phải dựa vào máy ảo CairoVM khi chạy các hợp đồng thông minh, điều này có thể cải thiện đáng kể tốc độ thực thi mã [nó vẫn đang trong giai đoạn lý thuyết và chưa được triển khai].
Mô hình hợp đồng thông minh Starknet: tách 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 mang tính đột phá trong thiết kế hệ thống hợp đồng thông minh, phần lớn được chuẩn bị cho các chức năng giao dịch song song và AA gốc sẽ ra mắt trong tương lai. Ở đây, chúng ta cần biết rằng trên các chuỗi công khai truyền thống như Ethereum, việc triển khai hợp đồng thông minh thường tuân theo phương thức “triển khai sau khi biên dịch”. Lấy hợp đồng thông minh ETH làm ví dụ:
1. Sau khi các nhà phát triển viết hợp đồng thông minh cục bộ, họ biên dịch chương trình Solidity thành mã byte EVM thông qua trình chỉnh sửa để EVM có thể hiểu và xử lý trực tiếp;
2. Nhà phát triển bắt đầu yêu cầu giao dịch để triển khai hợp đồng thông minh và triển khai mã byte EVM đã biên dịch vào chuỗi Ethereum.
(Nguồn hình ảnh: not-satoshi.com)
Mặc dù các hợp đồng thông minh của Starknet cũng đi theo ý 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 mã byte CASM được CairoVM hỗ trợ. Tuy nhiên, về phương thức gọi và chế độ lưu trữ trạng thái của thông minh hợp đồng, Starknet không tương thích với chuỗi EVM. Có một sự khác biệt rất lớn.
Nói chính xác, 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 phổ biến như Chuyển khoản và Phê duyệt mà còn lưu trữ trạng thái tài sản của tất cả những người nắm giữ USDT. Mã 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, nó không có lợi cho việc nâng cấp hợp đồng DAPP và di chuyển trạng thái, đồng thời cũng không có lợi cho việc xử lý song song các giao dịch, đó là một gánh nặng kỹ thuật nặng nề.
Nói chính xác, 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 phổ biến như Chuyển khoản và Phê duyệt mà còn lưu trữ trạng thái tài sản của tất cả những người nắm giữ USDT. Mã 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, nó không có lợi cho việc nâng cấp hợp đồng DAPP và di chuyển trạng thái, đồng thời cũng không có lợi cho việc xử lý song song các giao dịch, đó là một gánh nặng kỹ thuật nặng nề.
Về vấn đề này, Starknet đã cải tiến phương pháp lưu trữ trạng thái. Trong kế hoạch triển khai hợp đồng thông minh của mình, logic kinh doanh của DAPP hoàn toàn tách rời khỏi trạng thái tài sản và được lưu trữ ở những nơi khác nhau. Lợi ích của việc này là rõ ràng. Đầu tiên, nó có thể làm cho hệ thống hiệu quả hơn. Nhanh chóng xác định xem có triển khai mã trùng lặp hoặc dư thừa hay không. Nguyên tắc ở đây là thế này:
Hợp đồng thông minh của Ethereum = logic nghiệp vụ + dữ liệu trạng thái. Nếu có một số 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 thì hàm băm của các hợp đồng này cũng sẽ khác nhau, lúc này hệ thống rất khó phân biệt liệu các hợp đồng này có dư thừa hay không, có “hợp đồng rác” hay không.
Trong giải pháp của Starknet, phần mã và dữ liệu trạng thái được tách biệt trực tiếp, dựa trên hàm băm của phần mã, hệ thống có thể dễ dàng biết được liệu cùng một mã có được triển khai nhiều lần hay không vì hàm băm của chúng giống nhau. Điều này tạo điều kiện thuận lợi cho việc ngăn chặn hành vi triển khai mã lặp lại và tiết kiệm không gian 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 tổ chức 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 bằng văn bản cục bộ trên thiết bị của họ thành Sierra và biểu mẫu CASM mã byte cơ bản.
Sau đó, người triển khai hợp đồng đưa ra một giao dịch "khai báo" và triển khai mã byte CASM và mã trung gian Sierra của hợp đồng vào chuỗi, được đặt tên là Lớp hợp đồng.
(Nguồn hình ảnh: Trang web chính thức của Starknet)
Sau này, nếu bạn muốn sử dụng các chức năng đượ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 và triển khai một 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ẽ lưu trữ trạng thái nội dung. Sau đó, người dùng có thể gọi hàm trong Lớp hợp đồng để thay đổi trạng thái của phiên bản Hợp đồng.
Trên thực tế, bất kỳ ai hiểu lập trình hướng đối tượng đều có thể dễ dàng hiểu Lớp và Phiên bản thể hiện điều gì trong Starknet. Lớp hợp đồng do nhà phát triển khai báo chỉ chứa logic nghiệp vụ của hợp đồng thông minh. Đây là chức năng mà bất kỳ ai cũng có thể gọi. Tuy nhiên, nó không có trạng thái tài sản thực tế nên không trực tiếp thực hiện "thực thể tài sản". chỉ có “linh hồn” và không có “thể xác”.
Khi người dùng triển khai một phiên bản Hợp đồng cụ thể, nội dung sẽ được "hiện thực hóa". Nếu bạn muốn thay đổi trạng thái của "thực thể" nội dung, chẳng hạn như chuyển mã thông báo của mình cho người khác, bạn có thể gọi trực tiếp hàm được viết trong Lớp hợp đồng. Quá trình trên có phần giống với việc "khởi tạo" 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 nhau).
Sau khi hợp đồng thông minh được tách thành các lớp và phiên bản, dữ liệu trạng thái và logic nghiệp vụ sẽ được tách riêng, mang lại các tính năng sau cho Starknet:
1. Có lợi cho việc thực hiện phân tầng lưu trữ và "hệ thống cho thuê kho lưu trữ"
Cái gọi là phân tầng lưu trữ có nghĩa là 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 riêng của họ, chẳng hạn như trong 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 các lớp DA của 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 nó trên mạng chính Starknet và lưu trữ dữ liệu khác trong các lớp DA ngoài chuỗi như Celestia. Giải pháp tùy chỉnh lớp DA theo yêu cầu bảo mật này được Starknet đặt tên là "Volition".
Cái gọi là hệ thống cho thuê kho lưu trữ có nghĩa là mọi người phải tiếp tục trả tiền cho không gian lưu trữ mà họ sử dụng. Bạn chiếm bao nhiêu không gian trên chuỗi thì về mặt lý thuyết bạn nên tiếp tục trả tiền thuê nhà.
Trong mô hình hợp đồng thông minh Ethereum, quyền sở hữu hợp đồng không rõ ràng và rất khó phân biệt liệu người triển khai hay chủ sở hữu tài sản có nên trả "tiền thuê" cho hợp đồng ERC-20 hay không. thời gian dài và chỉ được thanh toán khi hợp đồng được triển khai.Người triển khai phải trả một khoản phí, đây không phải là mô hình phí lưu trữ hợp lý.
Theo các 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, giúp việc thu quỹ 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ê kho lưu trữ nhưng sẽ được triển khai trong tương lai]
2. Đạt được khả năng tái sử dụng mã 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 mã thông báo chung sẽ được lưu trữ trên chuỗi dưới dạng một lớp và sau đó mọi người có thể gọi các hàm trong lớp này để triển khai các phiên bản mã thông báo của riêng họ. Hơn nữa, hợp đồng cũng có thể gọi trực tiếp mã trong lớp, điều này đạt được hiệu quả tương tự như thư viện 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 các “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 trên chuỗi và giảm áp lực lưu trữ lên các nút nhiều nhất có thể.
3.Tái sử dụng hợp đồng thật “nhà nước”
Nâng cấp hợp đồng trên blockchain chủ yếu liên quan đến những thay đổi đối với logic kinh doanh. Trong kịch bản Starknet, logic kinh doanh của hợp đồng thông minh và trạng thái tài sản vốn đã được tách biệt. Nếu phiên bản hợp đồng thay đổi loại loại 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 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à nguyên gốc hơn so với Ethereum.
Để thay đổi logic nghiệp vụ của hợp đồng Ethereum, người ta thường phải “thuê ngoài” logic nghiệp vụ sang hợp đồng đại lý và thay đổi logic nghiệp vụ 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 đủ đơn giản và "không phải người bản địa". .
(Nguồn ảnh: Học viện wtf)
Trong một số trường hợp, nếu hợp đồng Ethereum cũ bị hủy bỏ hoàn toàn, trạng thái tài sản bên trong không thể được di chuyển trực tiếp đến vị trí mới, điều này rất rắc rối. Tuy nhiên, 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" cái cũ. trạng thái.
4. Thuận lợi cho việc xử lý song song các giao dịch
Trong một số trường hợp, nếu hợp đồng Ethereum cũ bị hủy bỏ hoàn toàn, trạng thái tài sản bên trong không thể được di chuyển trực tiếp đến vị trí mới, điều này rất rắc rối. Tuy nhiên, 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" cái cũ. trạng thái.
4. Thuận lợi cho việc xử lý song song các giao dịch
Để tối đa hóa tính 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ữ trạng thái tài sản của những 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à tách logic kinh doanh của hợp đồng thông minh khỏi dữ liệu trạng thái tài sản. Mặc dù Starknet chưa triển khai kỹ thuật chuyên sâu về song song giao dịch nhưng giao dịch song song sẽ là mục tiêu quan trọng trong tương lai.
Triển khai hợp đồng tài khoản và AA gốc của Starknet
Trên thực tế, cái gọi là trừu tượng hóa tài khoản và AA là những khái niệm độc đáo do cộng đồng Ethereum phát minh ra. Trong nhiều chuỗi công khai 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, đồng thời hệ thống tài khoản kiểu Ethereum đã bị loại bỏ khỏi bắt đầu. hố. Ví dụ: theo cài đặt của Ethereum, người kiểm soát tài khoản EOA phải có ETH trên chuỗi trước khi anh ta có thể bắt đầu giao dịch, không có cách nào để trực tiếp chọn nhiều phương thức 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 rắc rối. . Một số người thậm chí còn cho rằng thiết kế tài khoản của Ethereum đơn giản là phản con người.
Nếu chúng ta xem xét các chuỗi tập trung vào "AA gốc" như Starknet hoặc zkSyncEra, chúng ta có thể nhận thấy sự khác biệt rõ ràng: Thứ nhất, Starknet và zkSyncEra có cá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 và không có thứ đó như một tài khoản EOA ngay từ đầu (zkSync Era sẽ triển khai một bộ mã hợp đồng theo mặc định trên tài khoản mới tạo của người dùng, mô phỏng các đặc điểm của tài khoản Ethereum EOA, để tạo điều kiện tương thích với Metamask).
Starknet chưa xem xét khả năng tương thích trực tiếp với các cơ sở ngoại vi 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 chuyên dụng sẽ được tự động triển khai. Nói một cách thẳng thắn, đó là triển khai phiên bản hợp đồng được đề cập ở trên. Điều này phiên bản hợp đồng sẽ được triển khai trước cùng với dự án ví. Liên kết với lớp hợp đồng, bạn có thể gọi trực tiếp một số hàm được viết trong lớp.
Tiếp theo chúng ta sẽ nói về một chủ đề thú vị: khi nhận airdrop STRK, nhiều người phát hiện ví Argent và ví Braavos không tương thích với nhau, sau khi nhập cụm từ ghi nhớ của Argent vào Braavos thì tài khoản tương ứng không xuất được, thực chất là do Argent và Braavos Các phương pháp tính toán tạo tài khoản khác nhau được sử dụng, dẫn đến các địa chỉ tài khoản khác nhau được tạo cho cùng một cụm từ ghi nhớ.
Cụ thể, trong Starknet, địa chỉ hợp đồng mới được triển khai có thể được lấy thông qua thuật toán xác định, sử dụng công thức sau:
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à nhập một số tham số đặc biệt vào hàm pedersen để tạo ra hàm băm tương ứng. Hàm băm này được tạo ra địa chỉ tài khoản. .
Hình trên cho thấy một số tham số được Starknet sử dụng để tạo "đị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. Ngay cả khi bạn không có trước tài khoản hợp đồng Starknet, bạn vẫn có thể vẫn triển khai hợp đồng mới.
Hình trên cho thấy một số tham số được Starknet sử dụng để tạo "đị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. Ngay cả khi bạn không có trước tài khoản hợp đồng Starknet, bạn vẫn có thể vẫn triển khai hợp đồng mới.
salt được sử dụng để tính giá trị muối của địa chỉ hợp đồng. Nói một cách đơn giản, đó là một số ngẫu nhiên. Biến này thực sự được đưa vào để tránh trùng lặp địa chỉ hợp đồng. class_hash là giá trị băm của lớp tương ứng với phiên bản hợp đồng như đã giới thiệu trước đó. Và constructor_calldata_hash đại diện cho hàm băm của các 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 toán trước địa chỉ hợp đồng được tạo trước khi hợp đồng được triển khai trên chuỗi. Starknet cho phép người dùng triển khai trực tiếp các hợp đồng mà không cần có tài khoản Starknet trước, quy trình như sau:
1. Trước tiên, người dùng xác định phiên bản hợp đồng mà anh ta muốn triển khai, lớp hợp đồng mà anh ta muốn liên kết, sử dụng hàm băm của lớp làm một trong các tham số khởi tạo và tính toán muối để biết địa chỉ hợp đồng mà anh ta đã tạo;
2. Sau khi người dùng biết mình sẽ triển khai hợp đồng ở đâu, trước tiên, người dùng sẽ chuyển một lượng ETH nhất định đến địa chỉ dưới dạng 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 thông qua cầu nối chuỗi chéo;
3. Người dùng bắt đầu yêu cầu giao dịch để triển khai hợp đồng.
Trên 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í đều che chắn chi tiết và người dùng hoàn toàn không thể hiểu được quy trình, giống như thể tài khoản hợp đồng được triển khai sau khi họ chuyển ETH.
Giải pháp trên mang đến một số vấn đề về tính tương thích, vì khi các ví khác nhau tạo địa chỉ tài khoản, kết quả được tạo ra không nhất quán. Chỉ những ví đáp ứng các điều kiện sau mới có thể được trộn lẫn:
- Khóa chung lấy từ khóa riêng được ví sử dụng giống với thuật toán chữ ký;
- Quá trình tính muối của ví cũng giống nhau;
- Các lớp hợp đồng thông minh của ví về cơ bản không khác nhau về chi tiết triển khai;
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 của hai bên là khác nhau, địa chỉ tài khoản được tạo bởi cùng một cụm từ ghi nhớ trong hai ví sẽ không nhất quán.
Hãy quay lại chủ đề trừu tượng hóa tài khoản. Starknet và zkSync Era chuyển một loạt quy trình liên quan đến quy trình xử lý giao dịch, chẳng hạn như xác minh danh tính (xác minh chữ ký số), thanh toán phí gas và logic cốt lõi khác, sang được triển khai bên ngoài "lớp dưới cùng của chuỗi". Người dùng có thể tùy chỉnh chi tiết triển khai logic trên trong tài khoản của riêng họ.
Ví dụ: bạn có thể triển khai 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 Starknet của mình. Khi nút Starknet nhận được giao dịch do bạn khởi tạo, nó sẽ gọi một loạt logic xử lý giao dịch được tùy chỉnh trong tài khoản trên chuỗi của bạn. Điều này rõ ràng là linh hoạt hơn.
Trong thiết kế của Ethereum, logic như xác minh danh tính (chữ ký số) được mã hóa cứng trong mã máy khách nút và về cơ bản không thể hỗ trợ tùy chỉnh các chức năng tài khoản.
(Sơ đồ của giải pháp AA gốc do kiến trúc sư Starknet chỉ định. Xác minh giao dịch và xác minh tính đủ điều kiện của phí gas được chuyển sang hợp đồng trên chuỗi để xử lý. Máy ảo cơ bản của chuỗi có thể gọi các chức năng do người dùng xác định hoặc chỉ định này)
Theo các quan chức của zkSyncEra và Starknet, bộ ý tưởng mô-đun hóa chức năng tài khoản này dựa trên EIP-4337. Nhưng điểm khác biệt là zkSync và Starknet đã hợp nhất các loại tài khoản ngay từ đầu, các loại giao dịch thống nhất và sử dụng lối vào thống nhất để nhận và xử lý tất cả các giao dịch. Tuy nhiên, Ethereum có lịch sử và nền tảng hy vọng sẽ tránh được hard fork nhiều nhất có thể Chờ đợi một kế hoạch lặp lại thô, nó hỗ trợ kế hoạch EIP-4337 để "cứu đất nước qua đường cong", tuy nhiên, hiệu quả là tài khoản EOA và kế hoạch 4337 đều áp dụng các quy trình xử lý giao dịch độc lập, có vẻ khó xử và cồng kềnh, không giống như AA bản địa.
(Nguồn hình ảnh: ArgentWallet)
Tuy nhiên, tính năng trừu tượng hóa tài khoản gốc của Starknet vẫn chưa đạt đến độ chín hoàn toàn.Đánh giá từ tiến độ thực tế, tài khoản AA của Starknet đã triển khai tùy chỉnh thuật toán xác minh chữ ký.Tuy nhiên, để tùy chỉnh thanh toán phí, hiện tại Starknet thực tế chỉ hỗ trợ ETH và STRK trả phí gas và không chưa hỗ trợ thanh toán gas của bên thứ ba. Vì vậy, sự tiến bộ của Starknet trên AA bản địa có thể nói là "giải pháp lý thuyết về cơ bản đã trưởng thành và giải pháp thực tế vẫn đang tiến triển."
Vì chỉ có tài khoản hợp đồng thông minh trong Starknet nên tác động của hợp đồng thông minh tài khoản sẽ được xem xét trong toàn bộ quá trình giao dịch. Đầu tiên, sau khi một giao dịch được nhóm bộ nhớ của nút Starknet (Mempool) nhận được, nó phải được xác minh. Các bước xác minh bao gồm:
- Chữ ký số của giao dịch có chính xác hay không, chức năng xác minh chữ ký tùy chỉnh trong tài khoản của người khởi tạo giao dịch sẽ được gọi;
- Liệu số dư tài khoản của người khởi tạo giao dịch có đủ khả năng 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à sẽ có một kịch bản tấn công. Bởi vì nhóm 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 phí gas được tính trực tiếp sẽ dẫn đến các tình huống tấn công nghiêm trọng hơn). Người dùng độc hại trước tiên có thể tùy chỉnh 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 đó bắt đầu một số lượng lớn giao dịch, khi các giao dịch này được xác minh, họ 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 sức mạnh của nút. tài nguyên.
Để tránh tình trạng này, StarkNet áp dụng các hạn chế sau đối với các giao dịch:
- Có giới hạn trên về số lượng giao dịch mà một người dùng có thể thực hiện trong một đơn vị thời gian;
- Chức năng xác minh chữ ký tùy chỉnh trong hợp đồng tài khoản Starknet có những hạn chế về độ phức tạp và các chức năng xác minh chữ ký quá phức tạp sẽ không được thực thi. Starknet giới hạn giới hạn tiêu thụ gas của chức năng xác minh chữ ký, nếu lượng gas tiêu thụ của chức năng xác minh 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 minh 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:
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, thuật toán xác minh chữ ký của ví Braavos và Argent được triển khai trực tiếp trong ứng dụng khách nút Starknet.Khi nút phát hiện ra rằng giao dịch được tạo từ hai ví Starknet chính thống này, nó sẽ gọi thuật toán tích hợp trong máy khách Thuật toán chữ ký Braavos/Argent, thông qua ý tưởng 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 vượt qua quá trình xác minh trình sắp xếp chuỗi (các bước xác minh của trình sắp xếp chuỗi sâu hơn nhiều so với xác minh nhóm bộ nhớ), trình sắp xếp chuỗi sẽ đóng gói các giao dịch từ nhóm bộ nhớ và gửi chúng đến trình tạo chứng chỉ ZK. Ngay cả khi giao dịch vào liên kết này không thành công, gas sẽ bị tính phí.
Nhưng nếu độc giả hiểu về lịch sử của Starknet, họ sẽ thấy rằng Starknet thời kỳ đầu không tính phí xử lý đối với các giao dịch thất bại, tình huống giao dịch thất bại phổ biến nhất là người dùng chỉ có 1 ETH tiền nhưng lại chuyển 10 ETH. Loại này giao dịch rõ ràng có logic. Những sai lầm cuối cùng chắc chắn sẽ thất bại, nhưng không ai biết kết quả sẽ ra sao cho đến khi nó được thực thi.
Nhưng StarkNet trước đây chưa từng tính phí cho những giao dịch thất bại như vậy. Giao dịch sai sót không tốn kém này sẽ lãng phí tài nguyên tính toán của các nút Starknet và dẫn đến các kịch bản tấn công DDoS. Nhìn bề ngoài, việc thu phí đối với các giao dịch sai sót có vẻ dễ thực hiện nhưng thực tế lại khá phức tạp. Starknet tung ra phiên bản mới của ngôn ngữ Cairo1, phần lớn là để giải quyết vấn đề thu gom gas cho các giao dịch thất bại.
Tất cả chúng ta đều biết rằng ZK Proof là bằng chứng về tính hợp lệ và kết quả của một 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. Việc cố gắng sử dụng bằng chứng hợp lệ để chứng minh rằng một lệnh nào đó không hợp lệ và không thể tạo ra kết quả đầu ra nghe có vẻ khá lạ nhưng thực tế là không khả thi. Vì vậy, trước đây, khi Starknet tạo ra các bằng chứng, nó đã trực tiếp loại bỏ tất cả các giao dịch thất bại không thể tạo ra kết quả đầu ra.
Nhóm Starknet sau đó đã áp dụng một giải pháp thông minh hơn và xây dựng ngôn ngữ hợp đồng mới, Cairo1, để “tất cả các hướng dẫn giao dịch có thể tạo ra kết quả đầu ra và được đưa vào chuỗi”. Thoạt nhìn, tất cả các giao dịch đều có thể tạo ra đầu ra, điều đó có nghĩa là không bao giờ có lỗi logic, hầu hết các giao dịch đều thất bại do gặp phải một số lỗi làm gián đoạn việc thực hiện các lệnh.
Rất khó để đạt được một giao dịch không bao giờ bị gián đoạn và tạo đầu ra thành công, tuy nhiên, thực tế có một giải pháp thay thế rất đơn giản, đó là cho phép giao dịch tạo ra kết quả đầu ra khi gặp lỗi logic và gây gián đoạn, nhưng lúc này nó sẽ trả về giá trị A Sai cho mọi người biết rằng giao dịch không được thực hiện suôn sẻ.
Nhưng cần lưu ý rằng việc trả về giá trị Sai cũng trả về kết quả đầu ra. Nói cách khác, ở Cairo1, bất kể lệnh có gặp lỗi logic hay có gián đoạn tạm thời hay không, kết quả đầu ra đều có thể được tạo và onchain. Kết quả đầu ra này có thể đúng hoặc có thể là thông báo lỗi Sai.
Ví dụ: nếu có đoạn mã sau
_balances::read(from) - số tiền ở đây có thể báo lỗi do tràn, lúc này lệnh giao dịch tương ứng sẽ bị gián đoạn và ngừng thực thi, đồng thời kết quả giao dịch sẽ không còn trên chuỗi; và nếu đúng như vậy được viết lại Ở dạng sau, khi một giao dịch không thành công, kết quả đầu ra vẫn được trả về và vẫn còn trên chuỗi. Từ quan điểm trực quan thuần túy, dường như tất cả các giao dịch đều có thể rời khỏi đầu ra giao dịch thành công trên chuỗi và điều đó thật đặc biệt tính phí xử lý thống nhất.
Tổng quan về hợp đồng StarknetAA
Xét rằng một số độc giả của bài viết này có thể có kiến thức nền tảng về lập trình, đây là phần minh họa ngắn gọn về giao diện của hợp đồng trừu tượng tài khoản trong Starknet:
__validate_declare__ trong giao diện trên được sử dụng để xác minh giao dịch khai báo do người dùng thực hiện, trong khi __validate__ được sử dụng để xác minh giao dịch chung, chủ yếu để xác minh xem chữ ký của người dùng có đúng hay không và __execute__ được sử dụng để thực hiện giao dịch. Chúng ta có thể thấy rằng các tài khoản hợp đồng Starknet hỗ trợ đa cuộc gọi theo mặc định. Nhiều lệnh gọi có thể đạt được một số chức năng rất thú vị, chẳng hạn như đóng gói ba giao dịch sau khi thực hiện một số tương tác DeFi nhất định:
- Giao dịch đầu tiên ủy quyền mã thông báo cho hợp đồng DeFi
- Giao dịch thứ hai kích hoạt logic hợp đồng DeFi
- Giao dịch thứ ba xóa ủy quyền cho hợp đồng DeFi
Tất nhiên, vì nhiều lệnh gọi là nguyên tử nên có một số cách sử dụng phức tạp hơn, chẳng hạn như thực hiện một số giao dịch chênh lệch giá nhất định.
Tóm tắt
Các tính năng kỹ thuật chính của Starknet bao gồm ngôn ngữ Cairo tạo điều kiện cho việc tạo bằng chứng ZK, AA cấp độ gốc và các mô hình hợp đồng thông minh độc lập với logic kinh doanh và lưu trữ trạng thái.
Cairo là ngôn ngữ ZK phổ quát có thể được sử dụng để triển khai hợp đồng thông minh trên Starknet hoặc để phát triển các ứng dụng truyền thống hơn. Sierra được giới thiệu là ngôn ngữ trung gian trong quá trình biên dịch, cho phép Cairo lặp lại thường xuyên mà không cần phải thay đổi lớp dưới cùng. chỉ cần truyền các thay đổi sang 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 việc trừu tượng hóa tài khoản.
Hợp đồng thông minh Starknet lưu trữ dữ liệu trạng thái và logic kinh doanh riêng biệt. Khác với chuỗi EVM, việc triển khai hợp đồng Cairo bao gồm ba giai đoạn "biên soạn, khai báo và triển khai". Logic nghiệp vụ được khai báo trong lớp Hợp đồng và phiên bản Hợp đồng chứa trạng thái dữ liệu có thể được kết hợp với lớp Thiết lập một liên kết và gọi mã có trong lớp sau;
Mô hình hợp đồng thông minh nêu trên của Starknet có 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ữ và phát hiện các hợp đồng rác, đồng thời có lợi cho việc thực hiện cho thuê kho lưu trữ và song song hóa giao dịch. Mặc dù hai điều sau vẫn chưa được triển khai nhưng 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.
Mô hình hợp đồng thông minh nêu trên của Starknet có 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ữ và phát hiện các hợp đồng rác, đồng thời có lợi cho việc thực hiện cho thuê kho lưu trữ và song song hóa giao dịch. Mặc dù hai điều sau vẫn chưa được triển khai nhưng 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.
Chỉ có tài khoản hợp đồng thông minh trên chuỗi Starknet 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 gốc ngay từ đầu. Giải pháp AA của nó tiếp thu các ý tưởng của ERC-4337 ở một mức độ nhất định, cho phép người dùng lựa chọn các giải pháp xử lý giao dịch có tính 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 đối phó và thực hiện các cuộc thăm dò quan trọng vào hệ sinh thái AA.
Tất cả bình luận