Phân tích chuyên sâu về sự phát triển của hợp đồng thông minh: nghiên cứu so sánh giữa Move và Rust

Tiêu đề ban đầu: "Smart Contract Development—Move vs.Rust》

Biên dịch nguyên tác: Guo Qianwen, Chain Catcher

Biên dịch nguyên tác: Guo Qianwen, Chain Catcher

tiêu đề cấp đầu tiên

1. Giới thiệu

Gần đây, các cuộc thảo luận về Aptos và Sui đã diễn ra sôi nổi. Hai chuỗi công khai L1 hiệu suất cao đang nổi lên. Ngôn ngữ lập trình hợp đồng thông minh Move là một phần không thể thiếu của các chuỗi mới này. Một số nhà phát triển đang tích cực chuyển sang Move, tuyên bố đây là tương lai của sự phát triển hợp đồng thông minh. Những người khác thận trọng hơn, cho rằng Move không thể cung cấp nhiều thứ quá mới so với các ngôn ngữ lập trình hiện có.

Các nhà đầu tư mã hóa cũng đang tự hỏi làm thế nào tính độc đáo của các chuỗi công khai L1 này có thể cạnh tranh với Solana, công ty hiện đang là người chơi chính trong L1 hiệu suất cao và được biết đến với việc sử dụng Rust làm lập trình hợp đồng thông minh.

Nhưng các cuộc thảo luận mà chúng ta đã thấy cho đến nay vẫn chưa đạt đến độ sâu nhất định và chúng ta có thể thực sự hiểu được tác động của những công nghệ mới này đối với chúng ta. Điều này áp dụng ở cả hai cực của cuộc thảo luận - Những người hoài nghi về Move bác bỏ Move như không có gì và không đánh giá cao khía cạnh tinh tế hơn (nhưng quan trọng) của nó, nhưng những người ủng hộ Move, cường điệu hóa Move, không thấy được điều gì khiến nó trở nên tuyệt vời. Điều này tạo ra một nền tảng trung gian rộng lớn và sự mơ hồ, khiến khán giả bên ngoài, nhà phát triển mã hóa và nhà đầu tư chú ý đến chủ đề này, nhưng họ không chắc chắn về quan điểm của mình.

Trong bài đăng này, tôi sẽ tìm hiểu kỹ thuật sâu về Move, mô hình lập trình mới của nó, chuỗi khối Sui và cách nó tận dụng sức mạnh của Move cũng như cách nó so sánh với Solana và mô hình lập trình của nó. Để làm nổi bật các tính năng của Move, tôi sẽ so sánh Solana/Rust với Sui/Move. Bởi vì sự hiểu biết sẽ dễ dàng hơn khi bạn so sánh thứ này với thứ khác mà bạn đã quen thuộc.Có các biến thể khác của Move, chẳng hạn như Aptos Move, hơi khác theo một số cách. Mục đích của bài viết này không phải là thảo luận về sự khác biệt tinh tế giữa các biến thể khác nhau của Move, mà là chỉ ra những ưu điểm chung của Move và so sánh nó với mô hình lập trình Solana. Vì vậy, để đơn giản, tôi chỉ sử dụng một biến thể (Sui Move) trong bài viết này. Do đó tôiNhưng ngay cả như vậy, tất cả các lợi ích chính của Move được thảo luận trong bài viết này đều áp dụng cho tất cả các tích hợp Move (vốn hỗ trợ Move bytecode), bao gồm cả Aptos. Tôi chọn Sui chỉ vì tôi quen thuộc hơn với nó và tôi nghĩ nó trực quan hơn và dễ trình bày dưới dạng một bài báo hơn.

tiêu đề cấp đầu tiên

2. Mô hình lập trình Solana

Trên Solana, các chương trình (hợp đồng thông minh) không có trạng thái và không thể tự truy cập (đọc hoặc ghi) bất kỳ trạng thái nào tồn tại trong các giao dịch. Để truy cập hoặc duy trì trạng thái, các chương trình cần sử dụng tài khoản. Mỗi tài khoản có một địa chỉ duy nhất (là khóa công khai của cặp khóa Ed25519), có thể lưu trữ dữ liệu tùy ý.

Chúng ta có thể coi không gian tài khoản của Solana giống như một kho lưu trữ khóa-giá trị toàn cầu, trong đó khóa là địa chỉ tài khoản (pubkey) và giá trị là dữ liệu tài khoản. Các chương trình hoạt động trên kho khóa-giá trị này bằng cách đọc và sửa đổi các giá trị của nó.

Tài khoản có một khái niệm về quyền sở hữu. Mỗi tài khoản được sở hữu bởi một (và chỉ một) chương trình. Khi một tài khoản thuộc sở hữu của một chương trình, chương trình đó được phép sửa đổi dữ liệu của nó. Các chương trình không thể sửa đổi các tài khoản mà chúng không sở hữu (nhưng được phép đọc chúng). Trong quá trình hoạt động, loại kiểm tra động này có thể được thực hiện bằng cách so sánh trạng thái tài khoản trước và sau khi thực hiện chương trình, nếu có bất kỳ sửa đổi bất hợp pháp nào, giao dịch sẽ không thành công.

Mỗi tài khoản cũng có một khóa riêng được liên kết với nó (khóa chung tương ứng là địa chỉ của tài khoản) và người dùng có quyền truy cập vào khóa riêng này có thể sử dụng nó để ký các giao dịch. Sử dụng cơ chế này, chúng tôi triển khai các quyền và chức năng sở hữu trong hợp đồng thông minh Solana - ví dụ: để có được một số tiền nhất định, hợp đồng thông minh có thể yêu cầu người dùng cung cấp chữ ký cần thiết.

Khi gọi các chương trình khác, khách hàng cần chỉ định các tài khoản mà chương trình sẽ truy cập khi gọi. Bằng cách này, thời gian chạy xử lý giao dịch có thể lên lịch cho các giao dịch không chồng chéo để thực hiện song song trong khi vẫn đảm bảo tính nhất quán của dữ liệu. Đây là một trong những tính năng thiết kế của Solana giúp nó có thông lượng cao.

Các chương trình có thể gọi các chương trình khác thông qua các cuộc gọi CPI. Các cuộc gọi này về cơ bản hoạt động giống như các cuộc gọi từ máy khách - chương trình người gọi cần chỉ định tài khoản mà chương trình callee sẽ truy cập và chương trình callee sẽ thực hiện kiểm tra đầu vào, giống như cuộc gọi từ máy khách (vì nó không tin cậy chương trình người gọi).

Đây là những khối xây dựng cơ bản của lập trình hợp đồng thông minh an toàn trên Solana. Ở một mức độ nào đó, bạn có thể coi các chương trình Solana giống như các chương trình trong hệ điều hành và các tài khoản dưới dạng tệp. Bất kỳ ai cũng có thể tự do thực thi bất kỳ chương trình nào và thậm chí triển khai các chương trình của riêng mình. Khi các chương trình (hợp đồng thông minh) chạy, chúng sẽ đọc và ghi các tệp (tài khoản). Tất cả các tệp có thể được đọc bởi tất cả các chương trình, nhưng chỉ những chương trình có quyền sở hữu đối với các tệp mới có thể ghi vào chúng. Các chương trình cũng có thể thực thi các chương trình khác, nhưng chúng không có bất kỳ sự tin tưởng nào vào nhau -- bất kỳ ai thực thi một chương trình cần phải giả định rằng đầu vào có khả năng độc hại. Vì bất kỳ ai cũng có thể truy cập Hệ điều hành trên toàn cầu, hỗ trợ xác minh chữ ký gốc đã được tích hợp vào chương trình để triển khai các chức năng quyền và quyền sở hữu cho người dùng... Không phải là một phép loại suy hoàn hảo, nhưng khá thú vị.

tiêu đề cấp đầu tiên

3. Mô hình lập trình Move

Ở Solana, điều này tương đương với việc xuất bản tất cả các hợp đồng thông minh dưới dạng các mô-đun trong một chương trình. Điều này có nghĩa là tất cả các hợp đồng thông minh (mô-đun) được bao gồm trong cùng một hệ thống lớp và có thể gọi trực tiếp cho nhau mà không cần thông qua API hoặc giao diện trung gian. Điều này rất quan trọng và ý nghĩa của nó sẽ được thảo luận kỹ lưỡng trong bài viết này.

tiêu đề phụ

3.1 Đối tượng

Lưu ý rằng khái niệm đối tượng bên dưới dành riêng cho biến thể Sui của Move. Trong các tích hợp khác của Move (chẳng hạn như Aptos hoặc Diem/core Move), tình hình có thể hơi khác một chút. Tuy nhiên, có những giải pháp tương tự trong các biến thể Di chuyển khác đạt được điều tương tự (sự bền bỉ của trạng thái), không khác nhiều.

Lý do chính để giới thiệu biến thể Sui ở đây là các mẫu mã sau này trong bài viết đều dựa trên biến thể Sui của Move và các đối tượng của nó, chẳng hạn như cơ chế lưu trữ toàn cầu trong Move lõi, trực quan và dễ hiểu hơn. Điều quan trọng là tất cả các lợi ích chính của Move được thảo luận trong bài viết này áp dụng cho tất cả các tích hợp Move (hỗ trợ Move bytecode nguyên bản), bao gồm cả Aptos.

Các đối tượng là các phiên bản cấu trúc được lưu trữ bởi bộ thực thi và duy trì trạng thái qua các giao dịch.

• Có ba loại đối tượng khác nhau (trong Sui):

• đối tượng sở hữu

• đối tượng dùng chung

đối tượng bất biến

Đối tượng sở hữu là đối tượng thuộc về người dùng. Chỉ người dùng sở hữu đối tượng mới có thể sử dụng nó trong các giao dịch. Siêu dữ liệu quyền sở hữu hoàn toàn minh bạch và được xử lý bởi thời gian chạy. Nó được triển khai bằng mật mã khóa công khai - mỗi đối tượng riêng được liên kết với một khóa chung (được lưu trữ trong siêu dữ liệu đối tượng khi chạy) và bất kỳ lúc nào bạn muốn sử dụng đối tượng trong giao dịch, bạn cần cung cấp chữ ký tương ứng (hiện hỗ trợ Ed25519, sẽ sớm hỗ trợ đa chữ ký ECDSA và K-of-N).

Các đối tượng được chia sẻ tương tự như các đối tượng được sở hữu, nhưng chúng không có chủ sở hữu được liên kết với chúng. Do đó, bạn không cần sở hữu bất kỳ khóa riêng tư nào để sử dụng chúng trong các giao dịch (bất kỳ ai cũng có thể sử dụng chúng). Bất kỳ đối tượng riêng nào cũng có thể được chia sẻ (bởi chủ sở hữu của nó) và một khi đối tượng được chia sẻ, nó sẽ được chia sẻ mãi mãi - nó không bao giờ có thể được chuyển nhượng hoặc trở thành đối tượng của riêng nữa.

Mô hình lập trình Move rất trực quan và đơn giản. Mỗi hợp đồng thông minh là một mô-đun bao gồm các định nghĩa về chức năng và cấu trúc. Các cấu trúc được khởi tạo trong các hàm và có thể được chuyển đến các mô-đun khác thông qua các lệnh gọi hàm. Để làm cho một cấu trúc bền vững trong các giao dịch, chúng tôi biến nó thành một đối tượng có thể được sở hữu, chia sẻ hoặc không thể thay đổi (chỉ dành cho Sui, hơi khác một chút trong các biến thể Move khác).

tiêu đề cấp đầu tiên

4. Bảo mật Di chuyển

• Chúng tôi đã thấy điều đó trong Move:

• Bạn có thể chuyển bất kỳ đối tượng nào bạn sở hữu (hoặc chia sẻ) cho bất kỳ chức năng nào trong bất kỳ mô-đun nào

• Bất cứ ai cũng có thể xuất bản một mô-đun (có thể là thù địch)

Không có khái niệm về cấu trúc sở hữu mô-đun, điều này sẽ cung cấp cho mô-đun sở hữu quyền duy nhất để thay đổi cấu trúc, như trường hợp của tài khoản Solana - cấu trúc có thể chảy vào các mô-đun khác hoặc được nhúng vào cấu trúc khác.

Câu hỏi là, tại sao thực hành này là an toàn? Điều gì ngăn mọi người đăng một mô-đun độc hại, lấy một đối tượng được chia sẻ (chẳng hạn như nhóm AMM), gửi nó vào một mô-đun độc hại và tiếp tục rút tiền của họ?

Đó là điểm mới của Move...hãy nói về tài nguyên.

tiêu đề phụ

4.1 Cấu trúc

Xác định một loại cấu trúc là khá nhiều những gì bạn mong đợi:

• Cho đến nay rất tốt - đó cũng là cách bạn xác định cấu trúc trong Rust. Nhưng trong Move, struct là duy nhất, so với các ngôn ngữ lập trình truyền thống, Move module có nhiều không gian hơn trong cách sử dụng các kiểu. Cấu trúc được xác định trong đoạn mã ở trên sẽ tuân theo các hạn chế sau:

• Nó chỉ có thể được khởi tạo ("đóng gói") và hủy ("giải nén") trong mô-đun xác định cấu trúc -- nghĩa là bạn không thể khởi tạo hoặc hủy một thể hiện cấu trúc từ bất kỳ chức năng nào trong bất kỳ mô-đun nào khác.

• Các trường của một thể hiện cấu trúc chỉ có thể được truy cập (và do đó có thể được thay đổi) trong mô-đun của nó.

• Một thể hiện cấu trúc không thể được sao chép hoặc sao chép bên ngoài mô-đun của nó

không thể lưu trữ một thể hiện cấu trúc trong một trường của một thể hiện cấu trúc khác

Điều này có nghĩa là nếu chúng ta xử lý một thể hiện của cấu trúc này trong một hàm của mô-đun khác, thì chúng ta không thể thay đổi các trường của nó, sao chép nó, lưu trữ nó trong trường của cấu trúc khác hoặc loại bỏ nó (nó phải được chuyển qua một lệnh gọi hàm khác địa điểm). Đây là vấn đề: các mô-đun của cấu trúc triển khai các chức năng có thể được gọi từ các mô-đun của chúng tôi để thực hiện những việc này. Nhưng ngoài ra, chúng ta không thể làm những việc này trực tiếp cho các kiểu bên ngoài. Điều này cho phép mô-đun kiểm soát hoàn toàn cách các loại của nó được sử dụng và không được sử dụng.

Chúng tôi dường như mất rất nhiều tính linh hoạt do những ràng buộc này. Điều này cũng đúng - trong lập trình truyền thống, xử lý các cấu trúc như vậy sẽ rất cồng kềnh, nhưng trên thực tế, đây chính xác là điều chúng tôi muốn trong hợp đồng thông minh. Xét cho cùng, phát triển hợp đồng thông minh là lập trình các tài sản (tài nguyên) kỹ thuật số. Nếu bạn nhìn vào cấu trúc được mô tả ở trên, thì đó chính xác là nó - đó là một tài nguyên. Nó không thể được tạo ra từ không khí mỏng theo ý muốn, nó không thể được sao chép và nó không thể bị phá hủy một cách tình cờ. Vì vậy, chúng tôi mất một số tính linh hoạt ở đây, nhưng tính linh hoạt mà chúng tôi mất chính xác là những gì chúng tôi muốn, vì điều này làm cho việc thao tác tài nguyên trở nên trực quan và an toàn.

Hơn nữa, Move cho phép chúng tôi nới lỏng một số hạn chế này bằng cách thêm các khả năng vào cấu trúc. Có bốn khả năng: khóa, lưu trữ, sao chép và xóa. Bạn có thể thêm bất kỳ sự kết hợp nào của những khả năng này vào một cấu trúc.

• Đây là những gì họ làm:

• Phím - Cho phép một cấu trúc trở thành một đối tượng (dành riêng cho Sui, trường hợp Move cốt lõi hơi khác một chút). Như đã đề cập trước đó, các đối tượng tồn tại lâu dài và nếu chúng là đối tượng tự sở hữu, chúng cần được người dùng ký trước khi chúng có thể được sử dụng trong các cuộc gọi hợp đồng thông minh. Khi sử dụng khả năng khóa, trường đầu tiên của cấu trúc phải là ID đối tượng có loại UID. Điều này sẽ cung cấp cho nó một ID duy nhất trên toàn cầu có thể được tham chiếu bởi.

• lưu trữ - cho phép nhúng cấu trúc dưới dạng trường trong cấu trúc khác

• sao chép - cho phép sao chép/nhân bản cấu trúc tùy ý từ mọi nơi

Về cơ bản, mọi cấu trúc trong Move đều là tài nguyên mặc định. Khả năng cung cấp cho chúng tôi sức mạnh để nới lỏng một cách tinh vi những ràng buộc này để hoạt động giống các cấu trúc truyền thống hơn.

tiêu đề phụ

4.2 Tiền xu

Bạn có thể tìm thấy việc triển khai mô-đun hoàn chỉnh trong kho lưu trữ mã Sui (liên kết）。

liên kết

Các loại tiền xu có chức năng khóa và lưu trữ. key có nghĩa là nó có sẵn như một đối tượng. Điều này cho phép người dùng sở hữu tiền trực tiếp (dưới dạng đối tượng cấp cao nhất). Khi bạn sở hữu một đồng xu, thậm chí không ai khác có thể tham chiếu nó trong các giao dịch (chứ đừng nói chi tiêu nó) ngoại trừ bạn. Lưu trữ có nghĩa là một đồng xu có thể được nhúng dưới dạng một trường trong một cấu trúc khác, điều này rất hữu ích cho khả năng kết hợp.

Vì không có chức năng loại bỏ, tiền xu không thể vô tình bị loại bỏ (hủy) trong chức năng. Đây là một tính năng rất hay - nó có nghĩa là bạn không thể vô tình làm mất một đồng xu. Nếu bạn đang triển khai một hàm lấy đồng xu làm tham số, thì ở cuối hàm, bạn cần thực hiện điều gì đó với nó một cách rõ ràng - chuyển nó cho người dùng, nhúng nó vào một đối tượng khác hoặc gửi nó vào một đối tượng khác bằng cách gọi chức năng (mà một lần nữa cần phải làm điều gì đó với nó). Tất nhiên, có thể đốt một đồng xu bằng cách gọi hàm coin::burn trong mô-đun đồng xu, nhưng bạn cần thực hiện việc đó một cách có mục đích (bạn không thể vô tình làm được).

Không có khả năng nhân bản có nghĩa là không ai có thể sao chép tiền xu, tạo ra nguồn cung mới ngoài không khí mỏng. Tạo nguồn cung cấp mới có thể được thực hiện với chức năng coin::mint và chỉ có thể được gọi bởi chủ sở hữu đối tượng khả năng ngân quỹ của đồng xu.

Trong Move, tính bảo mật của tài nguyên được xác định theo loại của nó. Cho rằng Move có một hệ thống loại toàn cầu, điều này tạo ra một mô hình lập trình tự nhiên hơn và an toàn hơn, nơi các tài nguyên có thể được chuyển trực tiếp vào và ra khỏi mã không đáng tin cậy.

tiêu đề phụ

4.3 Xác minh mã byte

Như đã đề cập trước đó, hợp đồng thông minh di động được phát hành dưới dạng mô-đun. Bất kỳ ai cũng được phép tạo và tải bất kỳ mô-đun tùy ý nào lên chuỗi khối để thực thi bởi bất kỳ ai. Chúng ta cũng đã thấy rằng Move có các quy tắc về cách sử dụng các cấu trúc.

Vì vậy, điều gì đảm bảo rằng các quy tắc này được tuân theo bởi bất kỳ mô-đun nào? Điều gì ngăn mọi người tải lên các mô-đun có mã byte được chế tạo đặc biệt, chẳng hạn như chấp nhận một đối tượng tiền xu, rồi trực tiếp thay đổi các trường bên trong của nó để bỏ qua các quy tắc này? Bằng cách này, số lượng của tất cả các đồng xu có thể được tăng lên một cách bất hợp pháp. Chỉ riêng cú pháp của mã byte chắc chắn cho phép điều này.

Xác minh mã byte có thể giúp ngăn chặn kiểu lạm dụng này. Trình xác minh Move là một công cụ phân tích tĩnh phân tích mã byte Move và xác định xem nó có tuân theo các quy tắc an toàn về loại, bộ nhớ và tài nguyên được yêu cầu hay không. Tất cả mã được tải lên chuỗi cần phải vượt qua trình xác thực. Khi bạn cố gắng tải mô-đun Move lên chuỗi, các nút và trình xác thực trước tiên sẽ chạy qua trình xác thực trước khi cho phép gửi. Nếu bất kỳ mô-đun nào cố gắng bỏ qua các quy tắc bảo mật của Move, thì mô-đun đó sẽ bị trình xác thực từ chối và sẽ không được xuất bản.

Move bytecode và trình xác thực là những đổi mới cốt lõi của Move. Nó thực hiện một mô hình lập trình tập trung vào tài nguyên trực quan không thể có ở nơi nào khác. Quan trọng nhất, nó cho phép các loại có cấu trúc vượt qua các ranh giới tin cậy mà không làm mất đi tính toàn vẹn của chúng.

Trong Move, các loại tồn tại trên các mô-đun - hệ thống loại là toàn cầu. Điều này có nghĩa là không yêu cầu lệnh gọi CPI, mã hóa/giải mã tài khoản, kiểm tra quyền sở hữu tài khoản, v.v. - bạn chỉ cần gọi các hàm và đối số trực tiếp từ một mô-đun khác. Loại và sự an toàn tài nguyên của toàn bộ hợp đồng thông minh được đảm bảo bằng xác minh mã byte tại thời điểm biên dịch/phát hành và không cần triển khai ở cấp độ hợp đồng thông minh như Solana, sau đó được kiểm tra trong thời gian chạy.

tiêu đề cấp đầu tiên

Bây giờ chúng ta đã thấy cách lập trình Move hoạt động và tại sao về cơ bản nó lại an toàn. Vì vậy, chúng ta hãy xem xét sâu hơn về cách điều này tác động đến việc lập trình hợp đồng thông minh từ quan điểm về khả năng kết hợp, công thái học và bảo mật. Ở đây, tôi sẽ so sánh sự phát triển của Move/Sui với EVM và Rust/Solana/Anchor để giúp hiểu được những lợi ích mà mô hình lập trình của Move mang lại.

tiêu đề phụ

5.1 Cho vay chớp nhoáng

Khoản vay nhanh là một loại khoản vay trong DeFi trong đó số tiền cho vay phải được hoàn trả trong cùng một giao dịch với khoản vay. Lợi ích chính của việc này là các khoản vay có thể hoàn toàn không được thế chấp vì các giao dịch là nguyên tử. Điều này có thể được sử dụng để phân xử giữa các tài sản mà không cần phải có tiền gốc.

Khó khăn chính để đạt được điều này là - làm thế nào để bạn đảm bảo từ hợp đồng thông minh cho vay chớp nhoáng rằng số tiền cho vay sẽ được hoàn trả trong cùng một giao dịch? Để khoản vay không được thế chấp, giao dịch cần phải nguyên tử - nghĩa là nếu số tiền cho vay không được hoàn trả trong cùng một giao dịch, thì toàn bộ giao dịch cần phải thất bại.

• EVM có lập lịch động, vì vậy có thể sử dụng khả năng vào lại để đạt được điều này, như sau:

• Người dùng Lightning Loan tạo và tải lên các hợp đồng thông minh tùy chỉnh và khi hợp đồng được gọi, quyền kiểm soát sẽ được chuyển cho hợp đồng thông minh Lightning Loan bằng cách gọi

• Sau đó, hợp đồng thông minh cho vay chớp nhoáng sẽ gửi số tiền cho vay được yêu cầu đến hợp đồng thông minh tùy chỉnh và gọi hàm gọi lại execOperation() trong hợp đồng thông minh tùy chỉnh.

• Hợp đồng thông minh tùy chỉnh sau đó sẽ sử dụng số tiền cho vay nhận được để thực hiện các hoạt động cần thiết (chẳng hạn như chênh lệch giá).

• Sau khi hợp đồng thông minh tùy chỉnh hoàn thành hoạt động, nó cần trả lại số tiền đã vay cho hợp đồng thông minh cho vay nhanh.

• Bằng cách này, quá trình thực thiOperation() của hợp đồng thông minh tùy chỉnh đã hoàn tất và quyền kiểm soát sẽ được trả lại cho hợp đồng thông minh cho vay nhanh, hợp đồng này sẽ kiểm tra xem số tiền cho vay đã được trả lại chính xác hay chưa.

Nếu hợp đồng thông minh tùy chỉnh không trả lại số tiền cho vay một cách chính xác, toàn bộ giao dịch sẽ không thành công.

Điều này đạt được chức năng mong muốn một cách độc đáo, nhưng vấn đề là nó phụ thuộc vào khả năng truy cập lại, điều mà chúng tôi rất muốn không có trong lập trình hợp đồng thông minh. Bởi vì reentrancy vốn đã nguy hiểm và là nguyên nhân gốc rễ của nhiều lỗ hổng, bao gồm cả vụ hack DAO khét tiếng.

• Solana làm điều này tốt hơn vì nó không cho phép vào lại. Nhưng nếu không đăng ký lại, làm thế nào các khoản vay nhanh có thể được thực hiện trên Solana nếu hợp đồng thông minh cho vay nhanh không thể gọi lại hợp đồng thông minh tùy chỉnh? Nhờ hướng dẫn nội tâm. Trên Solana, mỗi giao dịch bao gồm nhiều hướng dẫn (gọi hợp đồng thông minh) và từ bất kỳ hướng dẫn nào, bạn có thể kiểm tra các hướng dẫn khác (ID chương trình, dữ liệu hướng dẫn và tài khoản) tồn tại trong cùng một giao dịch. Điều này giúp bạn có thể triển khai các khoản vay nhanh như sau:

• Hợp đồng thông minh cho vay chớp nhoáng thực hiện các hướng dẫn vay và trả nợ

• Người dùng tạo một giao dịch cho vay chớp nhoáng bằng cách sắp xếp các cuộc gọi để vay và trả các hướng dẫn trong cùng một giao dịch. Khi lệnh vay được thực hiện, nó sẽ sử dụng nội quan lệnh để kiểm tra xem lệnh trả nợ có được lên lịch ở giai đoạn sau của cùng một giao dịch hay không. Nếu việc gọi lệnh mua lại không tồn tại hoặc không hợp lệ, giao dịch sẽ thất bại ở giai đoạn này.

• Giữa các cuộc gọi để vay và trả nợ, số tiền đã vay được tự do sử dụng theo bất kỳ hướng dẫn nào khác ở giữa.

Khi kết thúc giao dịch, lệnh gọi hoàn trả sẽ trả lại tiền cho hợp đồng thông minh Lightning Lender (sự tồn tại của lệnh này sẽ được kiểm tra khi phản ánh lệnh vay)

Giải pháp này là đủ tốt, nhưng vẫn không lý tưởng. Nội quan của hướng dẫn là một trường hợp đặc biệt, không được sử dụng phổ biến trong Solana và việc sử dụng nó yêu cầu các nhà phát triển phải nắm vững một số lượng lớn các khái niệm và bản thân việc triển khai nó cũng rất kỹ thuật, vì có một số sắc thái cần được xem xét đúng cách. Ngoài ra còn có một giới hạn kỹ thuật - hướng dẫn hoàn trả cần tồn tại tĩnh trong giao dịch, do đó không thể gọi hoàn trả động thông qua lệnh gọi CPI trong khi thực hiện giao dịch. Đây không phải là một vấn đề lớn, nhưng nó phần nào hạn chế tính linh hoạt của mã khi tích hợp với các hợp đồng thông minh khác, đồng thời đẩy sự phức tạp hơn cho khách hàng.

Move cũng cấm lập lịch trình động và đăng nhập lại, nhưng không giống như Solana, nó có một giải pháp cho vay nhanh rất đơn giản và tự nhiên. Hệ thống kiểu tuyến tính của Move cho phép tạo ra các cấu trúc được đảm bảo tiêu thụ chính xác một lần trong quá trình thực hiện giao dịch. Đây được gọi là mẫu "Hot Potato" - một cấu trúc không có chức năng khóa, lưu trữ, xóa hoặc sao chép. Một mô-đun thực hiện mẫu này thường sẽ có một chức năng khởi tạo cấu trúc và một chức năng phá hủy cấu trúc. Vì cấu trúc "khoai tây nóng" không có chức năng loại bỏ, khóa hoặc lưu trữ, chức năng hủy của nó được đảm bảo được gọi để tiêu thụ nó. Mặc dù chúng ta có thể chuyển nó tới bất kỳ chức năng nào khác trong bất kỳ mô-đun nào, nhưng cuối cùng thì nó cần kết thúc trong chức năng hủy. Bởi vì không có cách nào khác để loại bỏ nó và trình xác thực yêu cầu nó phải được loại bỏ khi kết thúc giao dịch (không thể loại bỏ tùy ý vì không có chức năng loại bỏ).

• Hãy xem cách chúng ta có thể sử dụng điều này để triển khai các khoản vay nhanh.

• Hợp đồng thông minh Lightning Loan triển khai cấu trúc biên nhận (Receipt) "khoai tây nóng"

• Khi một khoản vay được thực hiện bằng cách gọi chức năng cho vay, nó sẽ gửi cho người gọi hai đối tượng - số tiền được yêu cầu (một đồng xu) và biên lai, là bản ghi số tiền cho vay cần được hoàn trả.

• Sau đó, người vay có thể sử dụng số tiền nhận được cho các hoạt động mà họ cần (chẳng hạn như kinh doanh chênh lệch giá).

• Sau khi người vay hoàn thành hoạt động dự định của mình, nó cần gọi chức năng trả nợ, chức năng này sẽ nhận số tiền đã vay và biên nhận dưới dạng tham số. Chức năng này được đảm bảo để được gọi trong cùng một giao dịch, vì người gọi không có cách nào khác để loại bỏ phiên bản nhận (không được phép loại bỏ hoặc nhúng vào đối tượng khác, điều này được yêu cầu bởi trình xác thực).

Chức năng hoàn trả kiểm tra xem số tiền chính xác đã được trả lại bằng cách đọc thông tin khoản vay được nhúng trong biên lai.

Các tính năng an toàn tài nguyên của Move cho phép các khoản vay nhanh trong Move mà không cần sử dụng tính năng truy cập lại hoặc xem xét nội tâm. Họ đảm bảo rằng biên lai không thể bị sửa đổi bởi mã không đáng tin cậy và nó cần được trả lại cho chức năng hoàn trả khi kết thúc giao dịch. Bằng cách này, chúng tôi có thể đảm bảo rằng số tiền chính xác được trả lại trong cùng một giao dịch.

Flash Loan là một ví dụ tuyệt vời về cách hệ thống loại tuyến tính và đảm bảo an toàn tài nguyên của Move cho phép chúng tôi thể hiện chức năng theo cách mà các ngôn ngữ lập trình khác không thể.

tiêu đề phụ

5.2 Khóa Cơ quan Mint

• Hợp đồng thông minh "khóa ủy quyền đúc" mở rộng chức năng đúc mã thông báo, cho phép nhiều bên trong danh sách trắng (chính quyền) đúc mã thông báo. Chức năng mong muốn của hợp đồng thông minh này như sau (đối với cả triển khai Solana và Sui):

• Cơ quan đúc mã thông báo ban đầu tạo ra một "khóa đúc" cho phép hợp đồng thông minh của chúng tôi giám sát việc đúc. Người gọi trở thành quản trị viên của mintlock.

• Quản trị viên có thể tạo các ủy quyền đúc bổ sung cho khóa này, ủy quyền này có thể được ủy quyền cho các bên khác và cho phép anh ta sử dụng khóa này để đúc mã thông báo bất kỳ lúc nào.

• Mỗi ủy quyền đúc có giới hạn hàng ngày về số lượng mã thông báo có thể được đúc.

• Quản trị viên có thể cấm (và bỏ chặn) bất kỳ cơ quan đúc tiền nào vào bất kỳ lúc nào.

Khả năng của quản trị viên có thể được chuyển giao cho bên khác.

Ví dụ: hợp đồng thông minh này có thể được sử dụng để chuyển quyền khai thác mã thông báo cho người dùng khác hoặc hợp đồng thông minh, trong khi cơ quan khai thác ban đầu (quản trị viên) vẫn giữ quyền kiểm soát việc khai thác. Nếu không, chúng tôi sẽ phải trao toàn quyền kiểm soát việc đúc tiền cho một bên khác, điều này không lý tưởng vì chúng tôi chỉ cần tin tưởng rằng họ sẽ không lạm dụng quyền lực đó. Và không thể cấp quyền cho nhiều bên.

Bạn có thể tìm thấy việc triển khai đầy đủ các hợp đồng thông minh này tại đây (Solana) và tại đây (Sui).

LƯU Ý: Vui lòng không sử dụng mã này trong sản xuất! Đây là mã mẫu chỉ dành cho mục đích giáo dục. Trong khi tôi đã kiểm tra chức năng của nó, tôi chưa thực hiện kiểm tra kỹ lưỡng hoặc kiểm tra bảo mật.

Bây giờ chúng ta hãy xem mã và xem cách triển khai khác nhau như thế nào. Dưới đây là ảnh chụp màn hình mã song song về việc Solana và Sui triển khai đầy đủ hợp đồng thông minh này.

Có thể nhận thấy rằng đối với cùng một chức năng, quy mô triển khai của Solana lớn hơn gấp đôi so với Sui (230 LỘC so với 104). Đây là một vấn đề lớn vì ít mã hơn thường có nghĩa là ít lỗi hơn và ít thời gian phát triển hơn.

Vì vậy, Solana đã lấy những hàng bổ sung này ở đâu? Nếu chúng ta xem kỹ mã của Solana, chúng ta có thể chia nó thành hai phần - thực hiện hướng dẫn (logic hợp đồng thông minh) và kiểm tra tài khoản. Việc triển khai hướng dẫn tương đối gần với những gì chúng tôi có trên Sui --- Solana có 136 dòng và Sui có 104 dòng. Số lượng dòng bổ sung là do tham chiếu của hai lệnh gọi CPI (mỗi cuộc gọi khoảng 10 LOC). Sự khác biệt quan trọng nhất là trong kiểm tra tài khoản (được đánh dấu màu đỏ trong ảnh chụp màn hình ở trên), điều này là bắt buộc (thực tế là quan trọng) trên Solana, nhưng không phải trên Move. Kiểm tra tài khoản chiếm khoảng 40% (91 LỘC) của hợp đồng thông minh này.

Di chuyển không yêu cầu kiểm tra tài khoản. Việc giảm LỘC có thể mang lại lợi ích, nhưng cũng cần loại bỏ việc kiểm tra tài khoản. Bởi vì hóa ra việc thực hiện các kiểm tra này một cách chính xác là rất phức tạp và nếu bạn mắc lỗi dù chỉ một lần, điều đó thường có thể dẫn đến vi phạm nghiêm trọng và mất tiền của người dùng. Trên thực tế, một số lỗ hổng hợp đồng thông minh Solana lớn nhất (về mặt mất tiền của người dùng) là các cuộc tấn công thay thế tài khoản do kiểm tra tài khoản không đúng cách.
-Wormhole ($336 triệu) - https://rekt.news/wormhole-rekt/
-Cashio ($48 triệu) - https://rekt.news/cashio-rekt/

- Crema Finance (8,8 triệu USD) - https://rekt.news/crema-finance-rekt/

Vậy làm thế nào để Move có thể an toàn nếu không có những kiểm tra này? Chúng ta hãy xem xét kỹ hơn những kiểm tra này thực sự làm gì. Đây là kiểm tra tài khoản theo yêu cầu của lệnh mint_to (người giữ quyền đúc mã thông báo bằng cách gọi lệnh này):

Có 6 kiểm tra (được đánh dấu màu đỏ):

1. Kiểm tra xem tài khoản khóa được cung cấp có thuộc sở hữu của hợp đồng thông minh hay không và có thuộc loại MintLock hay không. Khóa đến là bắt buộc vì nó được sử dụng cho lệnh gọi CPI đến chương trình mã thông báo để đúc (lưu trữ quyền).

2. Kiểm tra xem tài khoản cho phép đúc được cung cấp có thuộc khóa được cung cấp hay không. Tài khoản cơ quan đúc tiền nắm giữ trạng thái thẩm quyền (khóa công khai của nó, liệu nó có bị cấm hay không, v.v.).

3. Kiểm tra xem người gọi lệnh có khóa cần thiết để cấp phép không (cơ quan được yêu cầu ký giao dịch).

4. Tài khoản mục tiêu mã thông báo cần được chuyển vào, vì chương trình mã thông báo sẽ thay đổi nó (tăng số dư) trong lệnh gọi CPI. Kiểm tra đúc tiền không thực sự cần thiết ở đây, vì lệnh gọi CPI sẽ không thành công nếu tài khoản sai được chuyển vào, nhưng đây vẫn là một phương pháp hay.

5. Tương tự như 4.

• 6. Kiểm tra xem tài khoản chương trình mã thông báo có được chuyển chính xác hay không.

• Chúng ta có thể thấy rằng séc tài khoản (trong ví dụ này) thuộc năm loại sau:

• Kiểm tra quyền sở hữu tài khoản (1, 2, 4, 5)

• Kiểm tra loại tài khoản (1, 2, 4, 5)

• Kiểm tra phiên bản tài khoản (có chuyển đúng phiên bản của loại tài khoản hay không) (2, 5)

• Kiểm tra chữ ký tài khoản(3)

Kiểm tra địa chỉ tài khoản chương trình(6)

Nhưng trong Move, không có kiểm tra tài khoản hay bất cứ thứ gì tương tự, chỉ có chức năng chữ ký:

Hàm mint_balance chỉ yêu cầu bốn tham số. Trong số bốn tham số này, chỉ có lock và cap đại diện cho các đối tượng (hơi giống với tài khoản).

Trong Solana, chúng ta cần khai báo 6 tài khoản và thực hiện các kiểm tra khác nhau theo cách thủ công trên chúng, trong khi ở Move, chúng ta chỉ cần chuyển vào 2 đối tượng và không yêu cầu kiểm tra rõ ràng.

Trong Move, một số kiểm tra này được thực hiện minh bạch theo thời gian chạy, một số kiểm tra được thực hiện tĩnh bởi trình xác thực tại thời điểm biên dịch và một số kiểm tra hoàn toàn không cần thiết trong quá trình xây dựng.

Kiểm tra quyền sở hữu tài khoản - Di chuyển có một hệ thống loại, vì vậy thiết kế này là không cần thiết. Cấu trúc Move chỉ có thể được thay đổi bởi các chức năng được xác định trong mô-đun của nó, không phải trực tiếp. Xác minh mã byte đảm bảo rằng các phiên bản cấu trúc có thể tự do chuyển sang mã không đáng tin cậy (các mô-đun khác) mà không bị thay đổi bất hợp pháp.

Kiểm tra loại tài khoản - không cần thiết vì loại Di chuyển tồn tại trong suốt hợp đồng thông minh. Các định nghĩa loại được nhúng vào nhị phân mô-đun (được xuất bản trên chuỗi khối và được thực thi bởi máy ảo). Trình xác thực sẽ kiểm tra xem, trong quá trình biên dịch/xuất bản, khi hàm của chúng ta được gọi, loại chính xác có được chuyển hay không.

Kiểm tra phiên bản tài khoản - trong Move (và đôi khi trên Solana nữa), bạn thực hiện việc này trong thân hàm. Trong trường hợp cụ thể này, điều này là không cần thiết vì tham số loại chung T của các loại tham số khóa và giới hạn thực thi rằng đối tượng giới hạn đến (khả năng đúc/quyền hạn) khớp chính xác với khóa của nó (mỗi loại tiền xu T chỉ có thể có một khóa).

Kiểm tra chữ ký tài khoản - Chúng tôi không xử lý việc ký trực tiếp trong Sui. Đối tượng có thể được sở hữu bởi người dùng. Quyền khai thác được cấp theo quyền sở hữu của đối tượng khả năng Cơ quan khai thác (do quản trị viên tạo). Truyền một tham chiếu đến đối tượng này trong hàm mint_balance sẽ cho phép chúng ta đúc. Đối tượng sở hữu chỉ có thể được sử dụng trong các giao dịch bởi chủ sở hữu của họ. Nói cách khác, việc kiểm tra chữ ký của các đối tượng được thực hiện trong suốt bởi bộ thực thi.

Về cơ bản, Move tận dụng xác minh mã byte để làm cho mô hình lập trình cho các tài sản kỹ thuật số trở nên tự nhiên hơn. Mô hình của Solana xoay quanh quyền sở hữu tài khoản, chữ ký, cuộc gọi CPI, PDA, v.v. Nhưng khi lùi lại và suy nghĩ về nó, chúng tôi nhận ra rằng mình không muốn giải quyết những vấn đề này. Bản thân chúng không có bất kỳ mối liên hệ nào với tài sản kỹ thuật số - thay vào đó, chúng tôi phải sử dụng chúng vì điều này cho phép chúng tôi triển khai chức năng mong muốn trong mô hình lập trình của Solana.

Trên Solana, không có xác minh mã byte để đảm bảo an toàn cho tài nguyên hoặc loại chi tiết hơn và bạn không thể cho phép bất kỳ chương trình nào thay đổi bất kỳ tài khoản nào, vì vậy cần đưa ra khái niệm về quyền sở hữu tài khoản. Vì những lý do tương tự (không có loại/an toàn tài nguyên trong các cuộc gọi chương trình), không có khái niệm về các đối tượng do người dùng sở hữu có thể vào và thoát khỏi chương trình, thay vào đó chúng tôi sử dụng chữ ký tài khoản để chứng minh quyền. Vì đôi khi các chương trình cũng cần có khả năng cung cấp chữ ký tài khoản, chúng tôi có PDA...

Sự trừu tượng hóa tài nguyên gốc của Move cho phép chúng tôi thao tác trực tiếp với tài nguyên mà không cần giới thiệu bất kỳ khối xây dựng cấp thấp nào, chẳng hạn như PDA. Đảm bảo an toàn về loại và tài nguyên trên các ranh giới hợp đồng thông minh được đảm bảo bởi trình xác thực và không cần phải thực hiện thủ công.

tiêu đề phụ

5.3 Hạn chế của khả năng kết hợp Solana

Tôi muốn đưa ra một ví dụ nữa để làm nổi bật một số điểm yếu của khả năng kết hợp hợp đồng thông minh trên Solana.

Chúng ta đã thấy trong ví dụ về khóa quyền của mint rằng chúng ta cần khai báo nhiều đầu vào hơn trên Solana so với Sui (mint_to gọi 6 tài khoản trên Solana so với 2 đối tượng trên Sui). Rõ ràng, xử lý 6 tài khoản rắc rối hơn xử lý 2 đối tượng, đặc biệt nếu xét thấy bạn cũng cần thực hiện kiểm tra tài khoản đối với các tài khoản. Về lý thuyết, phần này có thể quản lý được, nhưng điều gì xảy ra khi chúng ta bắt đầu soạn thảo nhiều hợp đồng thông minh khác nhau trong một cuộc gọi?

Giả sử chúng ta muốn tạo một hợp đồng thông minh có thể thực hiện những việc sau:

Nó có quyền đúc một mã thông báo nhất định từ chương trình khóa cơ quan đúc tiền và có thể đúc

Khi nó được gọi, nó sẽ sử dụng quyền hạn của mình để đúc một lượng mã thông báo do người dùng chỉ định, hoán đổi nó lấy một mã thông báo khác bằng AMM và gửi cho người dùng trong cùng một lệnh

Trọng tâm của ví dụ này là để minh họa cách hợp đồng thông minh khóa cơ quan đúc tiền và hợp đồng thông minh AMM sẽ được kết hợp. Kiểm tra tài khoản được gọi bởi một lệnh có thể giống như sau:

17 tài khoản. 5-6 chương trình trên mỗi cuộc gọi CPI (đúc và hoán đổi), cộng với các tài khoản chương trình.

Trên Sui, chữ ký của một chức năng tương đương trông như thế này:

Chỉ có 3 đối tượng.

Tại sao chúng ta chuyển ít đồ vật hơn trên Sui so với các tài khoản trên Solana (3 so với 17)? Về cơ bản, bởi vì trong Move, chúng ta có thể nhúng (bọc) chúng. Các đảm bảo an toàn của hệ thống loại cho phép chúng tôi làm điều này.

Dưới đây là so sánh giữa tài khoản Solana và các đối tượng Sui, giữ trạng thái của nhóm AMM.

Chúng ta có thể thấy rằng trên Solana, chúng ta lưu trữ địa chỉ (Pubkey) của các tài khoản khác, giống như con trỏ và không lưu trữ dữ liệu thực tế. Để truy cập các tài khoản này, chúng cần được chuyển vào riêng lẻ và chúng tôi cũng cần kiểm tra thủ công xem có đúng tài khoản được chuyển vào hay không. Trong Move, chúng tôi có thể nhúng các cấu trúc vào nhau và truy cập trực tiếp các giá trị của chúng. Chúng tôi có thể kết hợp và kết hợp các loại từ bất kỳ mô-đun nào trong khi chúng vẫn giữ nguyên các đảm bảo an toàn về loại và tài nguyên, cả hai đều nhờ vào hệ thống loại toàn cầu và an toàn tài nguyên của Move, cả hai đều được thúc đẩy bởi xác minh mã byte.

Tuy nhiên, khi soạn thảo nhiều hợp đồng thông minh, nhiều tài khoản phải được thông qua (và do đó được kiểm tra), điều này tạo ra sự phức tạp đáng kể khi triển khai và có ý nghĩa bảo mật. Mối quan hệ giữa các tài khoản này có thể khá phức tạp, đến mức khó theo dõi tất cả các kiểm tra tài khoản cần thiết và liệu chúng có được triển khai chính xác hay không.

Trên thực tế, đó là những gì tôi nghĩ đã xảy ra trong vụ vi phạm Cashio ($48 triệu). Dưới đây là bảng phân tích kiểm tra tài khoản (không đầy đủ) dẫn đến lỗ hổng bảo mật. Như bạn có thể thấy, việc kiểm tra tài khoản này phức tạp hơn một chút. Các nhà phát triển có mục đích tốt là kiểm tra chính xác, nhưng đến một lúc nào đó, áp lực tinh thần trở nên quá lớn và nó trở nên rất dễ xảy ra lỗi. Bạn càng có nhiều tài khoản, bạn càng dễ bị lỗi.

Hệ thống loại toàn cầu và mô hình lập trình tự nhiên hơn của Move có nghĩa là chúng ta có thể thúc đẩy thành phần hợp đồng thông minh với độ an toàn cao hơn trước khi đạt đến giới hạn căng thẳng tâm lý.

Move được thiết kế với mục tiêu giảm TCB - Move đã đưa ra một số quyết định để giảm thiểu TCB càng nhiều càng tốt. Trình xác minh mã byte loại bỏ nhiều kiểm tra được thực hiện bởi trình biên dịch Move khỏi TCB, trong khi ở Rust/Anchor có nhiều thành phần khác cần được tin cậy, vì vậy diện tích bề mặt cho các lỗi bảo mật nghiêm trọng lớn hơn.

tiêu đề cấp đầu tiên

Chúng ta có thể di chuyển trên Solana không, và bằng cách nào?

tiêu đề phụ

6.1 Có Anchor kiểu an toàn toàn cầu không?

Trước khi bắt đầu, chúng ta hãy xem qua Anchor và thực hiện một thử nghiệm tưởng tượng nhỏ. Có lẽ bằng cách nào đó chúng ta có thể nâng cấp Mỏ neo để cung cấp một số lợi ích mà chúng ta nhận được từ Move? Có lẽ chúng ta có thể nhận được hỗ trợ gốc an toàn cho các cuộc gọi theo thủ tục? Xét cho cùng, lệnh Anchor đã tương tự như chức năng nhập của Move:

Có lẽ chúng ta có thể mở rộng Anchor để tài khoản có thể được chuyển trực tiếp đến tham số lệnh.

Chúng tôi có thể tránh bị kiểm tra tài khoản không?

Trong trường hợp này, chúng tôi muốn việc kiểm tra loại được thực hiện bởi lần chạy chứ không phải chương trình - lần chạy sẽ đọc bộ phân biệt đối xử tài khoản Anchor (hoặc tương đương) và có thể kiểm tra xem tài khoản được chuyển vào có tuân theo bộ phân biệt bắt buộc không (Anchor 8 byte đầu tiên của tài khoản).

Solana không phân biệt giữa các lệnh gọi khác nhau của cùng một chương trình, điều này được thực hiện thủ công bởi chương trình (trong trường hợp này, việc nâng vật nặng được thực hiện bởi Anchor). Vì vậy, để làm được điều này, bộ thực thi bằng cách nào đó phải biết về các hướng dẫn khác nhau, chữ ký của chúng, thông tin loại.
Các chương trình Solana được biên dịch thành SBF (Định dạng mã byte Solana, một biến thể của eBPF) và được tải lên chuỗi (và được thực thi) theo cách này. Bản thân SBF không nhúng bất kỳ thông tin loại hoặc chức năng nào có thể giúp ích cho chúng tôi. Nhưng có lẽ chúng ta có thể sửa đổi SBF để cho phép các hướng dẫn và loại thông tin được nhúng trong tệp nhị phân? Bằng cách này, bộ thực thi có thể đọc các hướng dẫn cần thiết và thông tin chữ ký từ tệp nhị phân.

Chúng tôi thực sự có thể làm điều này. Điều này sẽ đòi hỏi một lượng kỹ thuật đáng kể, đặc biệt là khi chúng tôi cần duy trì khả năng tương thích ngược với các chương trình cũ hơn, nhưng đây là những gì chúng tôi nhận được:

- quyền sở hữu tài khoản và kiểm tra loại được thực hiện bằng cách chạy thay vì chương trình

- Đối với các tài khoản có địa chỉ được biết tại thời điểm biên dịch (chẳng hạn như tài khoản chương trình), chúng tôi có thể tránh chuyển chúng từ ứng dụng khách, giờ đây chúng có thể được chuyển vào bằng cách chạy.

- Nếu chúng tôi quản lý để nhúng các ràng buộc tài khoản vào tệp nhị phân, chúng tôi có thể giảm thêm số lượng tài khoản mà máy khách phải chuyển vào, tải lại chúng một cách linh hoạt với thời gian chạy (dựa trên thông tin ràng buộc được nhúng).

Chúng tôi vẫn không nhận được:

- Tài khoản nhúng. Chúng tôi vẫn phải sử dụng Pubkey để tham khảo các tài khoản khác và không thể nhúng chúng trực tiếp. Điều này có nghĩa là chúng tôi không thoát khỏi vấn đề đầy tài khoản được mô tả trong Phần 5.3.

-Khi thực hiện các cuộc gọi liên chương trình, việc kiểm tra loại tài khoản vẫn cần được thực hiện động trong thời gian chạy, thay vì tĩnh tại thời điểm biên dịch như trong Move.

LƯU Ý: Đây chỉ là một thử nghiệm suy nghĩ. Nó không có nghĩa là nó có thể được hoàn thành một cách an toàn, cũng không có nghĩa là nó khó đạt được, cũng không có nghĩa là nó quảng cáo rằng những lợi ích này xứng đáng với nỗ lực của kỹ thuật.

Những lợi ích này chắc chắn là tốt, nhưng về cơ bản chúng không thay đổi bất cứ điều gì từ góc độ phát triển hợp đồng thông minh. Thực hiện kiểm tra kiểu trong thời gian chạy thay vì trong chương trình có thể mang lại một số lợi ích về hiệu suất và không cần thiết phải chuyển tài khoản địa chỉ từ máy khách theo cách thủ công vào thời điểm biên dịch, cải thiện công thái học ở một mức độ nhất định (điều này cũng có thể được giảm bớt bằng công cụ). Nhưng cuối cùng chúng tôi vẫn đang xử lý mô hình lập trình của Solana, mô hình này tự nó cung cấp nhiều trợ giúp hơn trong việc xử lý tài sản kỹ thuật số - chúng tôi vẫn không có bảo mật tài nguyên gốc, chúng tôi không thể nhúng tài khoản, vì vậy tài khoản vẫn phình to, chúng tôi vẫn đang xử lý với việc ký tài khoản và PDA...

Chúng tôi muốn có một mô hình lập trình tự nhiên, nhưng đồng thời chúng tôi cũng đang xử lý mã không đáng tin cậy. Mặc dù chúng tôi có thể xử lý mã không đáng tin cậy một cách an toàn trên Solana, nhưng có một sự thỏa hiệp trong mô hình lập trình. Xác minh mã byte giúp chúng tôi có thể có cả hai. Không có nó, chúng tôi thực sự dường như không thể cải thiện mô hình lập trình.

tiêu đề phụ

6.2 Định dạng mã byte Solana

Như đã đề cập trước đó, SBF (Định dạng mã byte Solana), định dạng biên dịch và lưu trữ trên chuỗi của các hợp đồng thông minh Solana, dựa trên eBPF. Sử dụng eBPF trên Solana thay vì bất kỳ định dạng mã byte nào khác (chẳng hạn như WASM) chủ yếu là do các yêu cầu của Solana về thực thi hợp đồng thông minh an toàn và hiệu suất cao phù hợp với yêu cầu thực thi chương trình hộp cát nhân của thiết kế eBPF (nó cũng cần bảo mật và hiệu suất cao)

Về mặt này, eBPF thực sự là một lựa chọn chắc chắn. Hiệu suất cao, được thiết kế xoay quanh vấn đề bảo mật, kích thước chương trình và số lượng lệnh bị hạn chế, có trình xác minh mã byte... trông rất tuyệt.

Nhưng hãy xem điều này có ý nghĩa gì trong thực tế. Có lẽ bằng cách nào đó chúng ta có thể tận dụng các trình xác nhận eBPF để cải thiện tính bảo mật của các hợp đồng thông minh của mình? Dưới đây là một số điều mà trình xác thực eBPF thực hiện:

- không cho phép vòng lặp vô hạn

- Kiểm tra xem chương trình có phải là DAG (Directed Acyclic Graph)

-Không cho phép nhảy ngoài giới hạn

- Kiểm tra các loại tham số khi thực hiện các lệnh gọi hàm trợ giúp khác nhau (các hàm trợ giúp được xác định trong kernel, ví dụ: để sửa đổi các gói mạng).

Chà, việc không cho phép nhảy ngoài giới hạn có vẻ hữu ích, nhưng mặt khác lại bị hạn chế. Trên thực tế, việc bắt buộc một chương trình phải là DAG và không có vòng lặp vô hạn là một vấn đề, vì nó hạn chế rất nhiều khả năng hoạt động của chương trình (chúng tôi không có tính đầy đủ của Turing). Lý do điều này cần thiết trong các chương trình eBPF là người xác minh cần chắc chắn rằng chương trình kết thúc trong một số hướng dẫn nhất định (để chương trình không khiến hạt nhân chấm dứt; đây là Sự cố tạm dừng nổi tiếng) và gas đo sáng không phải là một lựa chọn vì nó sẽ ảnh hưởng đến hiệu suất quá nhiều.

Mặc dù sự đánh đổi này là tuyệt vời để triển khai tường lửa hiệu suất cao, nhưng nó không quá tuyệt vời để phát triển hợp đồng thông minh. Phần lớn các trình xác nhận eBPF không thể được sử dụng lại trên các chương trình Solana. Trên thực tế, Solana hoàn toàn không sử dụng trình xác thực eBPF ban đầu, nó sử dụng trình xác thực tùy chỉnh (cơ bản hơn) để kiểm tra cơ bản các hướng dẫn chính xác và các bước nhảy vượt quá giới hạn.

Đồng thời, eBPF được thiết kế để cho phép truyền tối đa 5 tham số cho một chức năng để gọi. Điều này có nghĩa là thư viện chuẩn Rust không thể được biên dịch trực tiếp sang eBPF. Hoặc kích thước ngăn xếp được giới hạn ở 512 byte, giúp giảm kích thước của các đối số mà chúng ta có thể chuyển đến một hàm mà không cần cấp phát heap.

Vì vậy, ngay cả khi Rust biên dịch thành LLVM, có chương trình phụ trợ eBPF cho LLVM và thậm chí hỗ trợ trình biên dịch Rust cho eBPF, thì bạn vẫn không thể có hợp đồng thông minh Solana để biên dịch thành eBPF như bình thường. Đây là lý do tại sao nhóm Solana phải thực hiện một số sửa đổi đối với cơ sở mã Rust và phụ trợ eBPF LLVM (ví dụ: chuyển đối số qua ngăn xếp).

Vì một số thay đổi này là hỗ trợ gốc ngược dòng (Rust hoặc LLVM), nên nhóm Solana hiện đang duy trì các nhánh của cả Rust và LLVM. Khi bạn thực thi cargo build-bpf (lệnh điển hình để xây dựng hợp đồng thông minh Solana), Cargo sẽ kéo phiên bản Rustc dành riêng cho Solana này (trình biên dịch cho ngôn ngữ lập trình Rust) để biên dịch hợp đồng thông minh (rustc ban đầu sẽ không hoạt động ) .

Đây là cách SBF ra đời - Solana yêu cầu một số yêu cầu không tương thích với eBPF. Nhóm Solana hiện đang làm việc để ngược dòng SBF dưới dạng phụ trợ LLVM riêng biệt và thêm nó làm mục tiêu Rust để tránh duy trì một nhánh rẽ riêng biệt.

Do đó, mặc dù eBPF có thể phục vụ như một định dạng cho các hợp đồng thông minh, nhưng nó không lý tưởng như bề ngoài. Nó yêu cầu một số sửa đổi và trình xác thực ban đầu không hữu ích lắm.

Trong cuộc thảo luận về Move và Solana/SBF, một quan niệm sai lầm là một số người cho rằng các ý tưởng chính của Move nên được áp dụng cho SBF, vì nó dựa trên eBPF và có lẽ có thể sử dụng trình xác thực của nó để thực hiện kiểm tra thay đổi tài khoản tĩnh thay vì trong Thực hiện kiểm tra động khi chạy.

Theo tôi, đây là một tuyên bố đáng ngờ. Ngay cả khi có thể chứng minh rằng các chương trình không thay đổi tài khoản trong eBPF mà chúng không sở hữu, đó chính xác là những gì Move đang làm, thì đó chắc chắn không phải là ý tưởng chính của Move.

Ý tưởng chính của Move là tạo ra một mô hình lập trình lấy tài nguyên làm trung tâm, có thể tương tác tự nhiên với mã không đáng tin cậy.

• Trong thực tế, điều này có nghĩa là:

• loại an toàn toàn cầu

• Bảo mật tài nguyên (khóa, sao chép, lưu trữ, loại bỏ)

• tài nguyên có thể nhúng

• ...

Tài nguyên chảy an toàn đến và từ mã không đáng tin cậy

Rất khó để đưa các ý tưởng chính của Move vào eBPF/SBF. Không thể thực thi các thuộc tính như "mã không đáng tin cậy này không thể bỏ chữ T" nếu không có những thay đổi lớn đối với eBPF. Điều này đòi hỏi phải sửa đổi nhiều đến mức bạn sẽ có một mã byte mới trông giống Move hơn là eBPF.

Trên thực tế, một dòng suy nghĩ tương tự đã dẫn đến sự ra đời của Move ngay từ đầu. Nhóm Move (lúc đó ở Diem) ban đầu cân nhắc bắt đầu với các định dạng khác như WASM, JVM hoặc CLR, nhưng việc thêm định dạng này sau đó thực tế là quá khó - tuyến tính/dung lượng là khác thường. Vì vậy, Move được thiết kế từ đầu với ý tưởng thực hiện các kiểm tra này một cách hiệu quả thông qua các kênh trình xác thực hạng nhẹ.

Nếu bạn nghĩ về nó, điều này thực sự không đáng ngạc nhiên. Xét cho cùng, lập trình hợp đồng thông minh không phải là lập trình hệ thống, lập trình phụ trợ hay bất kỳ chương trình truyền thống nào khác, nó là một loại lập trình hoàn toàn khác. Vì vậy, không có gì ngạc nhiên khi không thể khai thác khả năng của mã bytecode và định dạng lệnh hiện có, vì chúng được thiết kế với các trường hợp sử dụng hoàn toàn khác nhau.

Tôi không chỉ trích Solana vì đã sử dụng eBPF. Trên thực tế, tôi nghĩ đó là một lựa chọn khá chắc chắn và một quyết định phán đoán tốt của nhóm dựa trên bối cảnh. Nhìn nhận lại, nhóm có thể đã chọn WASM thay vì eBPF, điều này sẽ tránh được các vấn đề đã nói ở trên khi biên dịch hợp đồng thông minh thành eBPF, vì WASM có hỗ trợ hạng nhất trong Rust (mặc dù WASM có thể có các vấn đề khác), nhưng có thể thấy rằng nhóm có thể cảm thấy rằng eBPF là lựa chọn an toàn hơn do chú trọng vào hiệu suất. Ngoài ra, vào thời điểm các lựa chọn thiết kế này được đưa ra, Move thậm chí còn chưa được công bố và việc tạo một ngôn ngữ mới từ đầu chắc chắn không phải là một lựa chọn hợp lý cho một công ty khởi nghiệp. Cuối cùng, Solana quản lý để cung cấp L1 hiệu suất cao thành công và đó mới là điều quan trọng.

• Có ba cách để có được Di chuyển trên Solana:

• Thêm Move vm làm trình tải cục bộ (cùng với SBF vm)

• Chạy máy ảo Move như một chương trình (chẳng hạn như Neon)

Biên dịch Chuyển sang SBF (như Solang)

Hãy thảo luận về (3) trước. Ý tưởng ở đây là có giao diện người dùng LLVM cho Move để nó biên dịch thành SBF. Hợp đồng thông minh Move được biên dịch sang SBF được thực thi một cách minh bạch, giống như hợp đồng thông minh được xây dựng bằng Rust (hoặc bất kỳ ngôn ngữ nào khác có thể được biên dịch sang SBF) và không yêu cầu bất kỳ sự phân biệt hoặc kiến ​​thức nào về Move trong thời gian chạy. Từ góc độ hoạt động, đây sẽ là một giải pháp rất tao nhã, vì nó sẽ không yêu cầu thay đổi đối với nó hoặc các giả định bảo mật của nó.

Nhưng tôi nghĩ việc phát triển hợp đồng thông minh theo cách này sẽ tệ hơn so với việc sử dụng Anchor trực tiếp. Những gì bạn nhận được với (3) là cú pháp Di chuyển trong mô hình lập trình Solana. Điều này có nghĩa là tất cả những ưu điểm quan trọng của Move đã thảo luận trong Chương 5 (an toàn kiểu toàn cầu, an toàn tài nguyên toàn cầu, các đối tượng có thể nhúng...) sẽ không còn tồn tại. Thay vào đó, chúng ta sẽ vẫn phải đối phó với việc kiểm tra tài khoản, cuộc gọi CPI, PDA, v.v., giống như trong Rust. Và, vì Move không hỗ trợ macro, nên không thể triển khai một khung như Anchor bằng cách sử dụng eDSL để đơn giản hóa một số công việc này, vì vậy mã sẽ tương tự (nhưng có thể tệ hơn) với vanilla Rust. Hệ sinh thái và thư viện tiêu chuẩn Rust cũng không khả dụng, vì vậy những thứ như tuần tự hóa và giải tuần tự hóa tài khoản phải được triển khai lại trong Move.

Move không phù hợp để sử dụng với các mô hình lập trình khác. Điều này là do nó được thiết kế đặc biệt để biên dịch thành Di chuyển mã byte và chuyển trình xác thực. Điều này là cần thiết với các quy tắc tùy chỉnh xung quanh khả năng và người kiểm tra mượn. Xác minh mã byte của nó cụ thể đến mức các ngôn ngữ khác có ít cơ hội biên dịch thành Di chuyển mã byte và vượt qua trình xác minh. Vì Move được xây dựng xung quanh loại xác minh mã byte rất cụ thể này nên nó không linh hoạt bằng các ngôn ngữ như Rust.

Việc tước mã byte sẽ loại bỏ tất cả các lợi thế chính của Move. Mặc dù các tính năng an toàn về loại, tài nguyên và bộ nhớ của Move được bảo toàn ở cấp độ chương trình nhưng chúng không được bảo toàn trên toàn cầu. Và mức độ an toàn của chương trình không mang lại nhiều kết quả mới -- chúng tôi đã đạt được chúng với Rust.

Hệ sinh thái hợp đồng thông minh của Move cũng không hoạt động trên Solana - mô hình lập trình quá khác biệt nên các phần quan trọng của hợp đồng thông minh phải được viết lại. Xem xét tất cả những điều này, tôi dự đoán rằng việc triển khai Di chuyển với (3) sẽ không được chấp nhận.

Đối với (1), ý tưởng ở đây là (cùng với trình tải SBF) để thêm hỗ trợ cho trình tải Move khi chạy. Move hợp đồng thông minh sẽ được lưu trữ dưới dạng Move bytecode on-chain và được thực thi bởi Move VM (giống như trong Sui). Điều này có nghĩa là chúng ta sẽ có một hệ sinh thái hợp đồng thông minh SBF và hệ sinh thái hợp đồng thông minh Move, cái trước chạy trên mô hình lập trình Solana hiện tại và cái sau chạy trên mô hình Move (được cho là tiên tiến hơn).

Với cách tiếp cận này, có thể giữ tất cả các lợi ích của sự tương tác giữa các hợp đồng thông minh Move, nhưng một thách thức ở đây là cho phép các hợp đồng thông minh Move tương tác với các hợp đồng thông minh SBF và ngược lại - bạn cần một cặp Move và For những người có hiểu biết sâu sắc về Solana, các trình xác thực cũng phải được điều chỉnh.

Ngoài ra còn có nhược điểm là cần duy trì hai bộ tải khác nhau trong thời gian chạy. Điều này có ý nghĩa bảo mật vì nó có nghĩa là bề mặt tấn công được nhân đôi - một lỗi trình tải duy nhất có thể có nghĩa là toàn bộ chuỗi bị khai thác. Hỗ trợ ban đầu cho MoveVM đã thực sự được thêm vào Solana vào năm 2019 (#5150), nhưng sau đó đã bị xóa do lo ngại về bảo mật (#11184).

Đối với (2), ý tưởng là chạy toàn bộ Move VM dưới dạng một chương trình Solana (hợp đồng thông minh). Move VM được triển khai trong Rust, do đó, nó có thể sẽ biên dịch thành SBF (trừ khi nó sử dụng các luồng hoặc API không được hỗ trợ khác). Mặc dù điều này nghe có vẻ điên rồ nhưng Neon đã thực hiện một cách tiếp cận tương tự, chạy EVM dưới dạng chương trình Solana. Lợi ích của phương pháp này là không cần sửa đổi quá trình chạy và có thể duy trì các giả định bảo mật tương tự.

Không có cách nào trực tiếp để đưa chức năng chính của Move lên Solana. Mặc dù có thể xây dựng giao diện người dùng LLVM và biên dịch Chuyển sang SBF, nhưng điều này sẽ không làm được gì nhiều vì mô hình lập trình sẽ không thay đổi. Như thí nghiệm suy nghĩ trong Phần 6.1 minh họa, mô hình lập trình không thể được cải thiện nếu không có một số loại xác minh mã byte. Việc thay đổi eBPF/SBF để hỗ trợ xác minh mã byte sẽ rất khó khăn. Có vẻ như tùy chọn hợp lý duy nhất là bằng cách nào đó chạy MoveVM. Nhưng điều này có nghĩa là sẽ có hai hệ sinh thái hoạt động trên các mô hình lập trình khác nhau và việc khiến chúng tương tác với nhau đúng cách là vô cùng khó khăn.

tiêu đề phụ

6.4. Thực hiện Di chuyển

Mã byte của Move không phải là ngôn ngữ mã byte có mục đích chung. Nó có một hệ thống loại rất "quyết đoán", khá tiên tiến để cho phép tất cả các xác thực cần thiết. Điều này có nghĩa là hiệu suất thấp hơn so với các định dạng mã byte khác như eBPF/SBF, gần với mã gốc hơn, mà người ta có thể coi là một vấn đề khi sử dụng nó trong L1 hiệu suất cao.

Tuy nhiên, cho đến nay, việc thực thi hợp đồng thông minh không phải là nút cổ chai đối với Solana (3k TPS trung bình tại thời điểm viết) hoặc Sui (dựa trên điểm chuẩn e2e ban đầu mà nhóm đã thực hiện). Cách chính để cải thiện hiệu suất xử lý giao dịch là thông qua thực thi song song. Cả Solana và Sui đều thực hiện điều này bằng cách yêu cầu khai báo trước các yếu tố phụ thuộc và lập lịch trình thực hiện song song các giao dịch phụ thuộc vào các nhóm đối tượng/tài khoản khác nhau.

Với tất cả những điều này, tôi hy vọng hiệu suất của Move sẽ không phải là trở ngại đáng kể trong tương lai gần.

7. Các chức năng khác của Move

tiêu đề phụ

7.1 Trình xác thực

Move có một công cụ xác minh chính thức cho các hợp đồng thông minh được gọi là Move Prover. Với công cụ này, bạn có thể đánh giá liệu các bất biến khác nhau có phù hợp với hợp đồng thông minh của bạn hay không. Đằng sau hậu trường, các điều kiện xác minh được dịch thành các công thức SMT, sau đó được kiểm tra bằng bộ giải SMT. Điều này rất khác so với làm mờ, chẳng hạn như thử và sai bằng cách đi bộ trong không gian đầu vào. Ví dụ, kiểm thử làm mờ và kiểm thử đơn vị/tích hợp vẫn có thể đưa ra kết quả dương tính giả nếu chúng không kiểm tra được một đầu vào hoặc tổ hợp đầu vào cụ thể, điều này cho thấy có lỗi trong chương trình. Mặt khác, người xác minh về cơ bản cung cấp bằng chứng chính thức rằng các bất biến được chỉ định phù hợp với chương trình được cung cấp. Nó giống như việc kiểm tra chương trình dựa trên tất cả các đầu vào có thể, nhưng nó không cần thiết.

Dưới đây là một ví dụ về trình xác thực (được lấy từ Sách trắng "Xác minh chính thức nhanh chóng và đáng tin cậy của hợp đồng thông minh với Move Prover").

tiêu đề phụ

7.2. Bảo mật ví

Vì Sui yêu cầu tất cả các đối tượng mà giao dịch sẽ truy cập phải được truyền trong các đối số chức năng (không được tải động từ trạng thái toàn cầu) và chữ ký chức năng di chuyển được lưu trữ trong chính mã byte cùng với thông tin loại, chúng tôi có thể gửi ví Người dùng cung cấp thông tin có ý nghĩa hơn, giải thích nội dung của giao dịch.

Ví dụ: nếu chúng ta có một hàm có chữ ký sau:

Chúng ta có thể thấy từ chữ ký của chức năng rằng giao dịch này sẽ truy cập 3 tài sản (loại tài sản) của người dùng. Không chỉ vậy, theo từ khóa & và &mut (hoặc không có từ khóa) ta còn có thể biết nội dung 1 đọc được, nội dung 2 thay đổi được (nhưng không chuyển, hủy), nội dung 3 có thể thay đổi, chuyển, hủy .tiêu diệt.

Ví có thể hiển thị thông tin này cho người dùng, người sau đó có thể nhận thức rõ hơn về những hành động mà một giao dịch có thể có đối với tài sản. Ví dụ: nếu có điều gì đó bất thường, một cuộc gọi giao dịch từ ứng dụng Web3 đang chạm vào một số tài sản hoặc đồng tiền không nên, người dùng có thể quan sát điều này và quyết định không tiếp tục giao dịch.

Điều này là không thể trên Solana vì các tài khoản chứa dữ liệu tùy ý từ quan điểm hoạt động. Bạn cần một mô tả bên ngoài về tài khoản (dành riêng cho ứng dụng) để giải thích nó, điều này không nhất thiết phải được cung cấp bởi nhà phát hành hợp đồng thông minh. Ngoài ra, khái niệm quyền sở hữu tài sản không tồn tại trong thời gian chạy Solana và mỗi hợp đồng thông minh cần triển khai ngữ nghĩa này theo cách thủ công (thường sử dụng chữ ký tài khoản và PDA), có nghĩa là không có cách chung để theo dõi điều này.

tiêu đề phụ

7.3 Giao dịch đơn giản và phức tạp

Cụ thể đối với Sui, có một tối ưu hóa thú vị ở cấp độ đồng thuận cho phép một số loại giao dịch nhất định từ bỏ sự đồng thuận hoàn toàn để chuyển sang thuật toán đơn giản hơn dựa trên Phát sóng nhất quán Byzantine. Ưu điểm của điều này là các giao dịch này có thể được thực hiện song song ở cấp độ đồng thuận, loại bỏ việc chặn đầu dòng và đạt được kết quả cuối cùng gần như ngay lập tức—về cơ bản nhận ra khả năng mở rộng của web2.

Điều này là do sự phân biệt của Sui giữa các đối tượng được sở hữu và chia sẻ (xem Phần 3.1). Các giao dịch chỉ liên quan đến các đối tượng riêng (được gọi là giao dịch đơn giản) không yêu cầu sự đồng thuận hoàn toàn về Sui. Vì các đối tượng riêng không thể được sử dụng trong các giao dịch khác ngoài người gửi và người gửi chỉ có thể gửi một giao dịch tại một thời điểm, điều này tự nó có nghĩa là các giao dịch này không cần phải được sắp xếp theo thứ tự tham chiếu đến các giao dịch khác (thứ tự tổng thể và thứ tự nhân quả) - chúng tôi biết rằng các giao dịch Các đối tượng được tham chiếu không thể bị ảnh hưởng bởi các giao dịch khác và giao dịch không thể ảnh hưởng đến các đối tượng khác. Do đó, chúng tôi không quan tâm đến thứ tự của giao dịch đó so với các giao dịch khác diễn ra song song trên chuỗi - điều đó thực sự không liên quan. Sui có thể khai thác thực tế này để tối ưu hóa đáng kể việc xử lý các giao dịch đơn giản, đạt được kết quả cuối cùng trong vài trăm mili giây. Nhưng nhược điểm là người gửi chỉ có thể gửi một giao dịch tại một thời điểm. Mặt khác, các giao dịch liên quan đến bất kỳ số lượng đối tượng được chia sẻ nào, được gọi là giao dịch phức tạp, luôn yêu cầu sự đồng thuận hoàn toàn.

Một số loại ứng dụng có thể tận dụng tốt các giao dịch đơn giản, với điều kiện là việc tạo, truyền và sửa đổi các đối tượng riêng có thể được thực hiện hoàn toàn thông qua các giao dịch đơn giản. Các ví dụ điển hình là NFT (bao gồm tiền đúc hàng loạt) và trò chơi web3. Các trường hợp sử dụng này được hưởng lợi rất nhiều từ tính hữu hạn của độ trễ thấp và loại bỏ chặn ngang hàng, cho phép trải nghiệm người dùng và khả năng mở rộng tốt hơn.

Nhưng các loại ứng dụng khác phải dựa vào các giao dịch phức tạp. Điều này bao gồm hầu hết các ứng dụng DeFi. Ví dụ: nhóm thanh khoản AMM cần phải là một đối tượng được chia sẻ, vì bất kỳ loại thực thi lệnh trao đổi nào cũng yêu cầu sự đồng thuận hoàn toàn và toàn bộ lệnh. Vì về cơ bản, nếu nhiều lệnh đến từ những người dùng khác nhau cùng một lúc, chúng ta cần thống nhất xem lệnh của ai sẽ được thực hiện trước, điều này sẽ xác định giá thực hiện mà mỗi người dùng sẽ nhận được.

Tài liệu Sui có nhiều chi tiết hơn về các giao dịch đơn giản và phức tạp.

https://docs.sui.io/devnet/learn/sui-compared

https://docs.sui.io/devnet/learn/how-sui-works#system-overview

tiêu đề cấp đầu tiên

8. Kết luận

Bài viết này tìm hiểu sâu và so sánh các mô hình lập trình của Solana và Sui, đồng thời thảo luận về ngôn ngữ lập trình Move.

Chương thứ hai là phần tóm tắt về mô hình lập trình Solana, trong khi chương thứ ba giới thiệu về Sui Move và mô hình lập trình của nó. Chương 4 tiếp tục giải thích cách an toàn tài nguyên và loại trong Move hoạt động. Ý nghĩa của chức năng Move đối với việc phát triển hợp đồng thông minh không rõ ràng ngay lập tức, vì vậy trong Chương 5, tôi sẽ cung cấp một so sánh kỹ lưỡng hơn về Solana và SuiMove bằng các ví dụ thực tế. Chương 6 thảo luận về eBPF/SBF, cho thấy rằng không dễ để chức năng Di chuyển hoặc chính Di chuyển hoạt động trên Solana. Chương 7 thảo luận về một số tính năng liên quan đến Di chuyển của Sui.

Lập trình hợp đồng thông minh là về lập trình tài sản kỹ thuật số. Có thể nói đây là một kiểu lập trình mới, khác rất nhiều so với các kiểu lập trình khác (như hệ thống, backend...) mà chúng ta đã thấy từ trước đến nay. Do đó, các ngôn ngữ lập trình và mô hình lập trình hiện tại đương nhiên không phù hợp lắm với trường hợp sử dụng này.

Mấu chốt của vấn đề là chúng tôi muốn một mô hình lập trình hoạt động tự nhiên với tài nguyên nhưng đồng thời tương tác với mã không đáng tin cậy. Solana đưa ra một thỏa hiệp ở đây, nó cho phép các hợp đồng thông minh có khả năng lập trình cần thiết trong một môi trường không tin cậy, nhưng mô hình lập trình của nó không tự nhiên đối với việc lập trình bằng tài nguyên. Xác minh mã byte giúp có thể có cả hai thuộc tính. Theo một cách nào đó, nó biến mã không đáng tin cậy thành mã đáng tin cậy.

Move là một ngôn ngữ lập trình mới để phát triển hợp đồng thông minh. Cải tiến cốt lõi của nó là mã byte, được thiết kế có chủ đích để có thể kiểm chứng được. Mặc dù bản thân việc xác minh mã byte không phải là một khái niệm mới, nhưng việc xác minh mà Move thực hiện thực sự là một sự đổi mới. Thông qua mã byte và xác minh, Move triển khai mô hình lập trình hợp đồng thông minh với sự hỗ trợ hạng nhất cho tài nguyên và đảm bảo lập trình an toàn trong môi trường không đáng tin cậy.

Tôi nghĩ Move là để phát triển hợp đồng thông minh giống như React là phát triển front-end. Nói rằng "những gì có thể được thực hiện trong Move có thể được thực hiện trong Rust" giống như nói "những gì có thể được thực hiện trong React có thể được thực hiện trong jQuery". Tất nhiên, có thể triển khai một ứng dụng dựa trên jQuery có thể so sánh với ứng dụng React, nhưng điều đó là không thực tế. React giới thiệu khái niệm về DOM ảo, điều này hoàn toàn dễ hiểu đối với các nhà phát triển, nhưng giúp cho việc phát triển giao diện người dùng nhanh hơn, có thể mở rộng và đơn giản hơn. Tương tự như vậy, xác minh mã byte của Move là một công nghệ cấp thấp cũng dễ hiểu đối với các nhà phát triển, nhưng nó cung cấp một sự phát triển hợp đồng thông minh tiện dụng hơn, có thể kết hợp và an toàn hơn. Move cũng làm giảm đáng kể rào cản gia nhập đối với các nhà phát triển hợp đồng thông minh nhờ tính bảo mật và mô hình lập trình trực quan hơn.

Nếu Move quản lý để đạt được lực kéo (và có những dấu hiệu sớm cho thấy điều đó sẽ xảy ra), nó có thể gây ra mối đe dọa nghiêm trọng cho Solana. Có hai lý do.

Trước hết, thời gian phát triển của hợp đồng thông minh Move nhanh hơn nhiều. Phát triển hợp đồng thông minh từ đầu trong Move có thể nhanh hơn 2-5 lần so với Rust. Do đó, sự phát triển của hệ sinh thái Move có thể vượt qua Solana. Do tính chất mở và không được phép của chuỗi khối, không có hiệu ứng khóa nghiêm trọng và tính thanh khoản có thể di chuyển dễ dàng. Các nhà phát triển Solana có thể buộc phải áp dụng Move hoàn toàn do các cân nhắc về kinh tế - chuyển sang Move hoặc bị các nhà phát triển Move vượt qua vì họ có thể phát triển các hợp đồng thông minh an toàn hơn nhanh hơn. Nếu bạn muốn thuê một nhà phát triển hợp đồng thông minh, bạn có thể thuê một nhà phát triển Rust có thể xây dựng một hợp đồng thông minh hoặc thuê một nhà phát triển Move có thể xây dựng hai hợp đồng thông minh an toàn hơn trong cùng một khoảng thời gian. Điều này tương tự như những gì React đã làm với quá trình phát triển front-end.

Thứ hai, Move có rào cản gia nhập thấp hơn nhiều so với Rust hoặc Solidity. Vì cú pháp Move đơn giản hơn và mô hình lập trình trực quan hơn. Một số nhà phát triển không thể phát triển hợp đồng thông minh trong Rust hoặc Solidity, nhưng có thể trong Move. Vì có ít khái niệm hơn để tìm hiểu nên các nhà phát triển hợp đồng không thông minh có thể vào Move nhiều hơn là vào Rust (Bản thân Rust là một ngôn ngữ phức tạp, cùng với các khái niệm Solana, chẳng hạn như PDA, sẽ gây ra nhiều nhầm lẫn cho người mới bắt đầu) hoặc Solidity (bạn cần phải làm quen với các chi tiết rất nhỏ của ngôn ngữ như khả năng truy cập lại để có thể phát triển các hợp đồng thông minh an toàn) sẽ dễ dàng hơn nhiều. Ngay cả khi các nhà phát triển Solana và Solidity hiện tại không chuyển sang Move, thì thị trường của các nhà phát triển chưa tham gia vào lĩnh vực này có số lượng đơn đặt hàng lớn hơn số lượng nhà phát triển hiện có trong lĩnh vực này. Do các rào cản gia nhập thấp hơn và tốc độ phát triển nhanh hơn của Move, nó có sản phẩm phù hợp với thị trường hơn Rust hoặc Solidity và có thể chiếm một miếng bánh lớn hơn. Nếu các nhà phát triển mới bắt đầu tham gia, tôi muốn họ bắt đầu với Move chứ không phải Rust hay Solidity. Điều này cũng tương tự như cách React hoạt động trong ngành công nghiệp web.

Vì điều này, tôi hoàn toàn mong đợi Solana sẽ bổ sung hỗ trợ hạng nhất cho Move trong trung và dài hạn. Nhưng nó không dễ dàng. Để có được những lợi ích chính của Move, Move bytecode cần phải được hỗ trợ nguyên bản, điều đó có nghĩa là không thể biên dịch Move thành eBPF/SBF đơn giản (xem Phần 6.3). Để duy trì hệ sinh thái hiện có, cả hai hoạt động cần được hỗ trợ. Thách thức kỹ thuật chính là làm thế nào để đạt được khả năng tương tác thích hợp giữa các hoạt động. Điều này đòi hỏi sự hiểu biết sâu sắc về Move và Solana, vì vậy tôi hy vọng nhóm Solana sẽ thúc đẩy trực tiếp việc này với sự hỗ trợ từ nhóm Move.

Move bắt nguồn từ dự án Diễm của Meta (nhũ danh Facebook). Nhóm Move, do Sam Blackshear lãnh đạo, được giao nhiệm vụ tìm ra cách xử lý các hợp đồng thông minh. Sau khi đào sâu vào vấn đề, họ nhận thấy rằng lập trình hợp đồng thông minh là tất cả về tài sản kỹ thuật số (tài nguyên), nhưng không có ngôn ngữ hiện có nào hỗ trợ trường hợp sử dụng này và quyết định xây dựng một ngôn ngữ lập trình mới từ đầu.