Mô hình hợp đồng thông minh Starknet và AA bản địa: gã khổng lồ công nghệ độc lập

Tác giả: Shew & Faust, geek web3

Tóm tắt

• Các tính năng kỹ thuật chính của Starknet, bao gồm cả những lợi ích mà ZK chứng minh rằng ngôn ngữ Cairo được tạo, AA cấp bản địa và 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 và phát triển các ứng dụng truyền thống hơn. Việc giới thiệu Sierra như một ngôn ngữ 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 bytecode thấp nhất. Nó chỉ cần chuyển những thay đổi sang ngôn ngữ trung gian, trongthư viện chuẩn của Cairo, các tài khoản cũng được bao gồm nhiều cấu trúc dữ liệu cơ bản cần thiết cho sự trừu tượng.

• 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 "biên dịch, khai báo, triển khai" Trong Giai đoạn thứ ba, logic nghiệp vụ được khai báo trong lớp Hợp đồng. Thực thể 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ã có trong lớp sau;

< li>< p>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. Nó cũng có lợi cho việc hiện thực hóa việc 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ợ tính năng trừu tượng hóa tài khoản AA cấp gốc ngay từ đầu. Kế hoạch 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.

Sau khi Starknet phát hành token, STRK Nó 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 tách biệt 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 Khả năng tương thích EVM 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 mày điện tử" trên Discord nên Starknet từng bị Đảng Lữ Mao chỉ trích, tuy bị chê là "vô nhân đạo" nhưng lại có thành tựu kỹ thuật sâu sắc ... Trở nên “vô giá trị” trong chốc lát, dường như chỉ có UX và hiệu ứng tạo ra của cải mớ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 công ty 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. trường hợp, Trong suy nghĩ của các nhà phát triển trò chơi toàn chuỗi, Starknet và Cairo đơn giản là tất cả mọi thứ trong web3, và cả Solidity lẫn Move đều không thể so sánh được với chúng. Khoảng cách thế hệ lớn nhất giữa “những người đam mê công nghệ” và “người dùng” ngày nay thực ra là do mọi người thiếu nhận thức 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ả 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 để đơn giản hóa nó sắp xếp các giải pháp kỹ thuật và thiết kế cơ chế của nó,Trong khi hiển thị các tính năng kỹ thuật của Starknet cho nhiều người hơn, chúng tôi cũng hy vọng để mọi người hiểu được "người kiểm lâm đơn độc mà người khác không hiểu" này.

Khoa học tối giản về ngôn ngữ Cairo

Trong phần sau, chúng tôi sẽ tập trung vào mô hình hợp đồng thông minh và tính năng 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 tính năng 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 gốc của Starknet. Trong quá trình phát triển Cairo, một phiên bản đầu tiên có tên Cairo0 đã xuất hiện 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 và nó thực sự 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. VàCairo có thể là ngôn ngữ lập trình thuận lợi nhất hiện nay để tạo ra các bằng chứng ZK.

Từ quá trình biên soạn, Cairo sử dụng một ngôn ngữ trung gian dựa trên Phương pháp biên dịch được thể hiện trong hình dưới đây. 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.

Giới thiệu Sierra như một hình thức trung gian để hỗ trợ việc bổ sung các tính năng mới sang ngôn ngữ Cairo.Trong nhiều trường hợp, chúng ta 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à máy khách nút Starknet 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 và các nút Starknet đang chạy khi viết hợp đồng thông minh , không cần phải dựa vào máy ảo CairoVM, đ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 biệt logic mã và lưu trữ trạng thái< /strong>

Không giống như các chuỗi tương thích với 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. Những cải tiến này 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 nhà phát triển viết hợp đồng thông minh cục bộ, anh ta 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. yêu cầu giao dịch của hợp đồng thông minh sẽ triển khai mã byte EVM đã biên dịch vào chuỗi Ethereum.

(Nguồn ảnh: not-satoshi.com)

Mặc dù các hợp đồng thông minh của Starknet cũng tuân theo ý tưởng “biên dịch trước rồi triển khai”, 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, có sự khác biệt rất lớn giữa các chuỗi tương thích với Starknet và EVM trong phương thức gọi và chế độ lưu trữ trạng thái của hợp đồng thông minh.

Nói chính xác, Hợp đồng thông minh Ethereum = logic nghiệp vụ + 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 giao và Phê duyệt, mà còn Nó cũng 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 gây ra 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 không có lợi để xử lý song song các giao dịch.

Về vấn đề này, Starknet đã cải tiến phương thức 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 và trạng thái tài sản của DAPP được tách rời hoàn toà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ó cho phép hệ thống phân biệt nhanh hơn. Có trùng lặp không? hoặc triển khai mã dư thừa? Nguyên tắc ở đây như sau:

Hợp đồng thông minh của Ethereum = logic kinh doanh + dữ liệu trạng thái. Nếu có một số hợp đồng có logic kinh doanh giống hệt nhau nhưng dữ liệu trạng thái khác nhau, thì The băm của các hợp đồng này cũng khác nhau, lúc này hệ thống rất khó phân biệt được liệu các hợp đồng này có dư thừa hay không và có "hợp đồng rác" hay không.

Và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. Bởi vì giá trị băm của chúng giống nhau. Điều này sẽ giúp ngăn việc triển khai mã lặp lại 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 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 thực hiện giao dịch "khai báo" để triển khai mã byte CASM và mã trung gian Sierra của hợp đồng vào chuỗi, có tên là Lớp hợp đồng.

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

Sau đó, nếu bạn muốn sử dụng 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, triển khai một phiên bản Hợp đồng được liên kết với Loại hợp đồng và trạng thái nội dung sẽ được lưu trữ trong phiên bản này. 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 về lập trình hướng đối tượng đều có thể dễ dàng hiểu được 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 triển khai "thực thể tài sản" ", chỉ có "linh hồn". "xác thịt".

Khingườ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. Quy trình trên có phần tương tự (nhưng không hoàn toà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.

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

1. Có lợi cho việc phân cấp lưu trữ và "lưu trữ triển khai "hệ thống cho thuê"

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 ở 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 nên trả "tiền thuê" cho hợp đồng ERC-20, Chức năng cho thuê kho đã lâu chưa ra mắt, người triển khai chỉ bị tính phí khi triển khai hợp đồng, mô hình tính phí lưu trữ này là không hợp lý.

2. Nhận ra việc 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 . Sau đó, mọi người có thể gọi hàm trong lớp này để triển khai phiên bản mã thông báo của riêng mình. Hơn nữa, hợp đồng cũng có thể gọi trực tiếp mã trong lớp, đạt được hiệu ứng 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 được tải lê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 “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 những thay đổi trong logic kinh doanh, trong kịch bản Starknet. logic kinh doanh và trạng thái tài sản của hợp đồng thông minh được tách biệt một cách tự nhiên. 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 mà không cần di chuyển trạng thái tài sản sang địa điểm mới. Hình thức nâng cấp hợp đồng này tốt hơn Ethereum. Kỹ lưỡng và nguyên bản hơn.

Để thay đổi logic nghiệp vụ của hợp đồng Ethereum, thường phải "thuê ngoài" logic nghiệp vụ cho 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 đại lý phụ thuộc Tuy nhiên, phương pháp này không đủ ngắn gọn và "không có nguồn gốc".

(Nguồn hình ảnh: wtf Academy)

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. Điều này rất rắc rối chuyển đến nơi ở mới, hợp đồng Cairo không cần di dời bang và có thể trực tiếp “tái sử dụng” bang cũ.

4. Có lợi cho việc xử lý song song các giao dịch

Để cải thiện tính song song của các hướng dẫn giao dịch khác nhau càng nhiều càng tốt, một bước cần thiết là kết hợp tài sản trạng thái của những người khác nhau Lưu trữ phi tập trung, 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 các giao dịch song song nhưng họ sẽ coi giao dịch song song là mục tiêu quan trọng trong tương lai.

Việc 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 phát minh độc đáo do Ethereum phát minh ra Khái niệm cộng đồng, 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, tránh được những cạm bẫy của hệ thống tài khoản kiểu Ethereum ngay từ đầu. 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 xem xét các chuỗi như Starknet hoặc zkSyncEra tập trung vào "native AA", 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 hợp nhất . Chỉ có tài khoản hợp đồng thông minh trên chuỗi và ngay từ đầu không có tài khoản EOA nào (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 Ethereum EOA tài khoản, vì vậy rất thuận tiện cho việc tương thích với Metamask).

Và 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,< strong> 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.Phiên bản hợp đồng này sẽ được liên kết với lớp hợp đồng được dự án ví triển khai trước và có thể được gọi trực tiếp Một số chức năng được viết trong lớp.

Chúng ta sẽ nói về một chủ đề thú vị bên dưới: Khi nhận được airdrop STRK, nhiều người nhận thấy 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 , không thể xuất tài khoản tương ứng. Điều này thực sự 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 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à để cung cấp cho hàm pedersen Enter một số tham số đặc biệt để tạo ra hàm băm tương ứng. Hàm băm này là địa chỉ tài khoản được tạo.

Hình trên hiển thị một số tham số được Starknet sử dụng để tạo "địa chỉ hợp đồng mới". người triển khai_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ó Starknet trong tài khoản hợp đồng cũng có thể triển khai hợp đồng mới.

Muối đượ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 phải có tài khoản Starknet trước. Quá trình này như sau:

1. Trước tiên, người dùng xác định phiên bản hợp đồng mình muốn triển khai, loại hợp đồng nào mình muốn liên kết nó và sử dụng hàm băm của lớp làm Khởi tạo một trong các tham số, tính toán muối và tìm hiểu địa chỉ hợp đồng mà bạn đã 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 anh ta 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 này, như thể Sau khi tự mình chuyển ETH, tài khoản hợp đồng sẽ được triển khai.

Giải pháp trên gây ra một số vấn đề về khả năng tương thích vì các ví khác nhau đang tạo ra Khi nhập đị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 kết hợp:

1. < p>Khóa công khai dẫn xuất từ ​​khóa riêng được ví sử dụng giống với thuật toán chữ ký;

2. Quy trình tính muối của ví giống nhau;

   < /li>
3. < p>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 các 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 cả hai bên là khác nhau và đị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 riêng mình, Khi nút Starknet nhận giao dịch do bạn thực hiện, nó sẽ gọi một loạt logic xử lý giao dịch do bạn tùy chỉnh trong tài khoản trên chuỗi. Đ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ợ việc 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 những người dùng này -các chức năng được xác định hoặc chỉ định. )

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, thống nhất các loại giao dịch 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. Ethereum có hành trang và nền tảng lịch sử. Chúng tôi hy vọng tránh được Các kế hoạch lặp lại thô bạo như hard fork càng nhiều càng tốt, vì vậy chúng tôi ủng hộ kế hoạch "đường cong cứu quốc gia" như EIP-4337. 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. , trông lúng túng và cồng kềnh, không linh hoạt như AA bản địa.

(Nguồn hình ảnh: ArgentWallet)

Tuy nhiên, khả 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 bộ thực tế, Starknet's Tài khoản AA đã triển khai tùy chỉnh thuật toán xác minh chữ ký, nhưng đối với việc tùy chỉnh thanh toán phí, hiện tại Starknet chỉ hỗ trợ ETH và STRK thanh toán phí gas và 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 nhóm bộ nhớ của nút Starknet (Mempool) nhận được một giao dịch, giao dịch đó phải được xác minh. Các bước xác minh bao gồm:

1. Chữ ký số của giao dịch có chính xác hay không thì 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;

2. Số dư tài khoản của người khởi tạo giao dịch có thể được thanh toán không ? Đủ khả năng trả phí gas;

Ở đây cần lưu ý 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. 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 đặt các hạn chế sau đối với các giao dịch:

1. 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;

2. Chức năng xác minh chữ ký tùy chỉnh trong Hợp đồng tài khoản Starknet rất phức tạp, do những hạn chế trên nên 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 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 Starknet node client, Khi một node phát hiện ra rằng một giao dịch được tạo từ hai ví Starknet chính thống này, nó sẽ gọi thuật toán chữ ký Braavos/Argent đi kèm với ứng dụng khách. Thông qua ý tưởng giống như bộ nhớ đệm này, Starknet có thể rút ngắn giao dịch thời gian xác minh.

Sau khi dữ liệu giao dịch vượt qua quá trình xác minh của bộ sắp xếp (các bước xác minh của bộ sắp xếp sâu hơn nhiều so với xác minh nhóm bộ nhớ), bộ sắp xếp sẽ đóng gói các giao dịch từ nhóm bộ nhớ và gửi chúng đến ZK trình tạo chứng chỉ. 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ả tìm hiểu 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à chỉ có người dùng có 1ETH tiền, nhưng chuyển 10 ETH ra ngoài. Giao dịch này rõ ràng có lỗi logic và cuối cùng sẽ thất bại, nhưng không ai biết kết quả sẽ như thế nào trước khi nó được thực hiện.

Nhưng trước đây, StarkNet không tính phí đối với 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 đã ra mắt 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 nhất định không hợp lệ và không thể tạo ra kết quả đầu ra nghe có vẻ khá lạ và 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 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ả 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 hướng dẫn.

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 ra Tuy nhiên, lúc này giá trị False sẽ được trả về để 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, trong Cairo1, đầu ra có thể được tạo bất kể lệnh có gặp lỗi logic hay không sự gián đoạn tạm thời. Kết quả không phải là trên chuỗi. 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 đoạn mã sau tồn tại:

Số tiền _balances::read(from)-amount ở đây có thể báo lỗi do tràn, lúc này, hướng dẫn giao dịch tương ứng sẽ bị gián đoạn và dừng lại, kết quả giao dịch sẽ không còn trên chuỗi; và Nếu nó được viết lại thành dạng sau, kết quả đầu ra sẽ vẫn được trả về khi giao dịch thất bại và vẫn còn trên chuỗi.Từ quan điểm trực quan thuần túy, có vẻ như tất cả các giao dịch đều có thể để lại đầu ra giao dịch thành công chuỗi. Việc tính phí xử lý thống nhất là đặc biệt hợp lý.

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 các 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 các giao dịch chung, chủ yếu là xác minh Liệu chữ ký của người dùng là chính xác 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:

1. Giao dịch đầu tiên ủy quyền mã thông báo cho hợp đồng DeFi

2. Giao dịch thứ hai kích hoạt logic hợp đồng DeFi

< li>< p>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

• Starknet Các tính năng kỹ thuật quan trọng nhất 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 tổng quát, không chỉ có thể thực hiện các hợp đồng thông minh trên Starknet mà còn được sử dụng để phát triển các ứng dụng truyền thống hơn. Sierra được giới thiệu là trung gian trong quá trình biên dịch của nó Ngôn ngữ cho phép Cairo lặp lại thường xuyên mà không thay đổi mã byte cơ bản và 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 dịch, khai báo và triển khai" và giai đoạn kinh doanh logic được khai báo Trong lớp Hợp đồng, phiên bản 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ã có trong lớp sau;

• Mô hình hợp đồng thông minh 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 hợp đồng rác cũng có lợi cho việc thực hiện việc 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.

• Chuỗi Starknet chỉ có tài khoản hợp đồng thông minh và không có tài khoản EOA. Nó hỗ trợ tính năng trừu tượng hóa tài khoản AA cấp gốc ngay từ đầu. Kế hoạch 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.