Cha đẻ của ngôn ngữ Move: Ngôn ngữ hợp đồng thông minh Sui Move phù hợp với các sản phẩm Web3

Xuất xứ: Tùy Mạng

Gần đây, chúng tôi đã nói chuyện với Sam Blackshear, CTO của Mysten Labs và là người tạo ra ngôn ngữ lập trình Move, về lý do ông ấy phát triển Sui Move, một ngôn ngữ lập trình hợp đồng thông minh mới, các khả năng mà Sui có thể mở rộng và tác động của công nghệ phi tập trung đối với việc xây dựng lợi ích của người nhận.

Sau đây là nội dung cuộc phỏng vấn này:

**Q1. Trước tiên, bạn có thể giới thiệu tổng quan về ngôn ngữ lập trình là gì không, những phẩm chất mà các nhà phát triển tìm kiếm nhiều nhất khi chọn ngôn ngữ lập trình và điều gì thúc đẩy bạn phát triển ngôn ngữ lập trình của riêng mình? **

Ngôn ngữ lập trình chỉ là một công cụ để tương tác thân thiện, an toàn, hiệu quả và rõ ràng với máy tính và điều này đặc biệt quan trọng đối với máy tính. Chúng ta không thể giao tiếp với máy tính bằng ngôn ngữ tự nhiên, bởi vì toàn bộ ý nghĩa của ngôn ngữ tự nhiên là phong phú và biểu cảm. Khi bạn sử dụng giọng điệu hơi khác hoặc chọn cách diễn đạt từ ngữ khác một cách tinh tế, câu hoặc đoạn văn của bạn có thể mang ý nghĩa hoàn toàn khác.

**Trong các ngôn ngữ lập trình, điều quan trọng nhất là phải xác định chính xác ngữ nghĩa. **Khi bạn viết một chương trình, bạn biết nó sẽ làm gì. Nếu bạn thực hiện các chỉnh sửa nhỏ cho nó, bạn sẽ biết thay đổi đó sẽ đi đến đâu. Điều này phải được duy trì ở nhiều cấp độ, chẳng hạn như bạn có thể viết mã bằng ngôn ngữ nguồn, nó có nghĩa và sau đó nó được dịch sang các dạng biểu diễn khác, sau đó nó cũng sẽ có nghĩa tương tự, cho đến khi nó đến được máy chủ. điều tương tự cũng xảy ra với các mô-đun xử lý.

**Tôi nghĩ rằng ngôn ngữ lập trình có bản chất dành riêng cho miền hoặc dành riêng cho nhiệm vụ, không giống như ngôn ngữ tự nhiên. **Nếu không thì chỉ với một ngôn ngữ lập trình, bạn có thể làm được tất cả. Nhưng lý do có nhiều ngôn ngữ lập trình là vì bạn không thể giỏi tất cả các lĩnh vực. Họ đang cố gắng nhắm mục tiêu vào các lĩnh vực vấn đề cụ thể và tập trung vào giải quyết những vấn đề đó. Ví dụ: nếu bạn nhìn vào ngôn ngữ lập trình Rust mà chúng tôi sử dụng để viết chuỗi khối Sui và hầu hết các hệ thống khác mà chúng tôi thực hiện tại Mysten, thì nó tập trung vào việc viết mã vừa nhanh vừa hiệu quả trong khi vẫn duy trì tính bảo mật. Nó cho phép bạn truy cập vào các chi tiết cấp thấp như bộ nhớ, cấu trúc luồng hoặc đồng thời, nhưng không cho phép bạn mắc lỗi như các ngôn ngữ trước đây như C hoặc C++.

Vì vậy, câu chuyện của Move rất giống với điều đó. Khi tôi tạo ra nó, nó không phải để tạo ra một ngôn ngữ mới. Bạn đã đề cập trước đó những gì các nhà phát triển tìm kiếm trong một ngôn ngữ. Họ hỏi, "Ngôn ngữ này có phù hợp với những gì tôi đang cố gắng hoàn thành không?" Nhưng tôi nghĩ có lẽ quan trọng hơn, "*Ngôn ngữ này có cộng đồng lớn không? Có nhiều cơ sở dữ liệu không? Có nhiều lập trình viên sử dụng không? Có có nguồn giáo dục tốt không? *" Đây là những điều rất quan trọng, vì vậy tiêu chuẩn để tạo ra một ngôn ngữ mới phải rất cao, cho dù bản thân ngôn ngữ đó có tốt hơn nhưng nếu nó không có những yếu tố này thì lợi thế của nó cũng vô nghĩa. Xây dựng một cộng đồng lớn và sôi động từ đầu là rất khó.

**Q2、****Bạn có thể chia sẻ thêm về sự phát triển của Move không? **

** Động thái bắt nguồn từ dự án Libra của Facebook. **Nhiệm vụ của tôi lúc đó không phải là tạo ra một ngôn ngữ mới, mà là "Libra cần có hợp đồng thông minh, vì vậy hãy tìm hiểu xem chúng ta nên làm gì." Tôi đã xem xét đủ thứ. Chúng tôi có thể sử dụng Solidity trong EVM không? Chúng ta có nên sử dụng một ngôn ngữ có mục đích chung thông thường, như WASM hoặc JVM và sử dụng nó cho Libra không? Hay chúng ta nên tự tạo?

Quyết định tạo ra thứ gì đó của riêng chúng tôi dựa trên việc nghiên cứu các hợp đồng thông minh hiện có, hiểu những gì các lập trình viên đang cố gắng thực hiện và những ngôn ngữ nhất định đã giúp họ ở đâu và họ làm họ thất vọng ở đâu. Kết luận của tôi là trong nhiều trường hợp, các ngôn ngữ hợp đồng thông minh hiện có đã làm họ thất vọng.

Điều này rõ ràng từ hồ sơ bảo mật kém của Solidity, nhưng về cơ bản hơn, các hợp đồng thông minh này không phải là loại chương trình rất truyền thống. Solidity không phải là một ngôn ngữ được xây dựng cho những gì mọi người làm bây giờ. Tôi không chỉ trích nó vì đây là ngôn ngữ hợp đồng thông minh đầu tiên chưa biết mọi người muốn làm gì với nó. Khi bạn thấy những gì mọi người đang cố gắng làm với nó, tôi nghĩ rõ ràng là bạn cần một tập hợp các công cụ lập trình và trừu tượng hóa khác mà ngôn ngữ Solidity không cung cấp.

Vì vậy, những hợp đồng thông minh này rất đơn giản, về cơ bản chúng làm hai việc. Chúng xác định các loại tài sản, bao gồm các quy tắc về thời điểm tài sản có thể được chuyển nhượng, bạn có thể làm gì với chúng, ai có thể đọc chúng và ai có thể viết thư cho chúng**. **** Và kiểm tra chính sách kiểm soát truy cập để xác định ai sở hữu nội dung, ai được phép sử dụng và ai được phép thao tác trên nội dung đó. **Mọi thứ đều xoay quanh tài sản và bạn muốn những tài sản đó có cùng thuộc tính như tài sản vật chất. Nếu tôi giao cái gì cho bạn, thì bạn nên có nó và tôi sẽ không có nó nữa.

**Trong hợp đồng thông minh có khái niệm về quyền sở hữu và chuyển giao quyền sở hữu, nhưng trên máy tính, mọi thứ chỉ là bit và byte và có thể được sao chép tự do. **Và, bạn biết đấy, những khái niệm này không tồn tại trong thế giới thực. Vì vậy, bạn muốn một ngôn ngữ cung cấp cho bạn những khái niệm trừu tượng tốt về quyền sở hữu và sự đồng nhất. Giống như trong thế giới thực, nhưng không buộc các lập trình viên phải phát minh lại nó. Bạn muốn đảm bảo an ninh cơ bản.

Đây là những gì Move làm và lý do tại sao chúng tôi lại tạo ra ngôn ngữ mới này. Những nhiệm vụ này là cơ bản để lập trình hợp đồng thông minh. Chúng rất khó để tạo lại bằng các ngôn ngữ khác, bao gồm cả các ngôn ngữ hợp đồng thông minh hiện có và chúng tôi muốn thiết kế toàn bộ ngôn ngữ xung quanh việc cung cấp các chức năng cơ bản này để các lập trình viên có thể viết mã một cách an toàn và hiệu quả mà không cần phải viết một số mã mỗi khi họ muốn Phát minh lại bánh xe.

**Q3、****Sui sử dụng một biến thể của Move gọi là Sui Move. Điều gì đã thúc đẩy những thay đổi này? Những tính năng nào của Sui Move là lý tưởng để xây dựng sản phẩm trong Web3? **

Một số yếu tố đã thúc đẩy những thay đổi này, một trong số đó là mục tiêu của dự án Libra ban đầu nhằm xây dựng mạng thanh toán tuân thủ. Vì vậy, chúng tôi đã cố gắng thiết kế Move (như một ngôn ngữ có mục đích chung. Nhưng chúng tôi cũng đã làm một số điều một cách có ý thức, bởi vì Libra muốn có những ràng buộc. Một trong những điều quan trọng là họ không muốn mọi người có thể gửi một số tài sản nhất định đến bất kỳ nơi nào. Họ muốn mọi người tạo tài khoản một cách rõ ràng và đặt ra một số quy tắc khi tài khoản được tạo, chẳng hạn như chủ sở hữu tài khoản phải trải qua xác minh KYC. Hoặc có thể có phí để tạo tài khoản hoặc chỉ có thể là được tạo bởi một người nhỏ có quyền tạo tài khoản Một số người tạo tài khoản. Vì toàn bộ mục đích của Libra là thực hiện các khoản thanh toán tuân thủ và hợp đồng thông minh tuân thủ, nên có những hạn chế này. Nhưng trong thế giới Web3 chung hơn, điều đó ngược lại. Bạn không muốn tuân thủ ở cấp cơ sở, Đây là khái niệm về hợp đồng thông minh. Bạn muốn mọi thứ miễn phí nhất có thể, hoàn toàn có thể gửi thứ gì đó đến bất kỳ địa chỉ nào. Sau đó, bạn không nên tạo tài khoản rõ ràng vì điều đó sẽ chặn các trường hợp sử dụng khác nhau. Đây là một yếu tố quan trọng.

Một yếu tố khác là trong khi chúng tôi tập trung vào tài sản trong Move, thì tại thời điểm ở Libra, chúng tôi không nghĩ về cách đưa trọng tâm của tài sản vào chính giao dịch. Vì vậy, khi bạn đạt đến cấp độ giao dịch, bạn vẫn chỉ có API này, nơi bạn nhập số và phép toán luận cũng như những thứ không phải là tài sản, sau đó trong Move, bạn sử dụng những con số đó để rút tài sản từ tài khoản và làm những việc khác. Hóa ra phần lớn mã bạn chạy là cái sổ sách kế toán khó chịu khi lấy thứ này ra, lấy thứ kia ra, lấy ra thứ khác, và được thôi, tôi có tất cả tài sản tôi muốn. Họ đang ở đây, trong studio của tôi, và bây giờ tôi có thể bắt đầu làm điều gì đó có ý nghĩa. Và khi kết thúc quá trình, bạn có thể nói, "Được rồi, đưa những tài sản đó trở lại tài khoản này, đưa chúng trở lại tài khoản đó, sắp xếp lại chúng.

Trong Sui, chúng tôi đã suy nghĩ kỹ, nếu mọi chương trình đều bắt đầu và kết thúc theo cách này, chúng tôi có thể trừu tượng hóa nó đi không? Vì vậy, logic để xử lý giao dịch sẽ làm điều đó cho lập trình viên và theo quan điểm của lập trình viên, họ chỉ cần chuẩn bị sẵn tài sản họ cần và bắt đầu thực hiện công việc thú vị ngay lập tức. Đây là mô hình dữ liệu lấy đối tượng làm trung tâm **** tồn tại trong Sui. **Trong Move ban đầu, chúng tôi có mô hình dữ liệu dựa trên tài khoản, tài sản được lưu trữ trong tài khoản và lập trình viên phải trích xuất chúng một cách rõ ràng. Trong Sui, khi họ vào phần Di chuyển của giao dịch, tài sản đã được mua bởi thời gian chạy Sui. Điều này thuận tiện hơn cho các lập trình viên vì họ không cần phải làm tất cả những điều này trước và sau khi ghi sổ, và nó cũng cho phép chúng tôi xác định liệu chúng tôi có thể chạy một giao dịch song song với một giao dịch khác mà không thực sự thực hiện giao dịch đó hay không. một vài thứ khác hiệu quả hơn.

Chúng tôi cũng đã thực hiện một số công việc thực sự thú vị khác, chẳng hạn như tận dụng mô hình dữ liệu dựa trên đối tượng cho các khối giao dịch có thể lập trình. Đây là một chủ đề hơi kỹ thuật mà tôi rất sẵn lòng thảo luận sâu. Nhưng hai yếu tố đó là động lực chính của sự khác biệt so với Move ban đầu.

**Q4、****Bạn có thể vui lòng chia sẻ thêm thông tin về các khối giao dịch có thể lập trình và chức năng của chúng không? **

Tôi muốn sử dụng phép loại suy để giải thích rằng các chuỗi khối khác giống như khu ẩm thực trong trung tâm mua sắm. Bạn muốn ăn kem, bạn đến quầy kem, rút thẻ tín dụng và trả tiền. Nhưng nếu bạn quyết định vẫn muốn một chiếc burger, thì bạn đến quầy bán burger và trả tiền lần nữa. Tôi không phải là người háu ăn, nhưng nếu tôi muốn ăn tám thứ, tôi phải thực hiện tám giao dịch riêng biệt. **Ở đâu Sui giống như một bữa tiệc tự chọn, mỗi giao dịch không chỉ là một thứ. Khi bạn đã trả tiền cho bữa tiệc buffet, bạn có thể làm rất nhiều thứ mà không phải trả thêm phí. **Bạn có thể ăn kem, bạn có thể ăn bánh mì kẹp thịt, bạn có thể trộn tất cả chúng lên.

Để làm cho khái niệm này cụ thể hơn một chút, trong trường hợp đơn giản, nếu bạn đang gửi 100 giao dịch để đúc 100 NFT, thì bạn có thể gửi một giao dịch đúc 100 NFT. Chi phí như vậy gần giống như chi phí đúc một NFT. Bạn cũng có thể thực hiện đóng gói giao dịch không đồng nhất, chẳng hạn như giao dịch đầu tiên trong một khối lấy ký tự Mario từ ví nhiều chữ ký của bạn và giao dịch thứ hai yêu cầu Mario, sau đó cho phép bạn chơi trò chơi. Nếu bạn thắng trò chơi và nhận được cúp, có thể lần giao dịch thứ ba sẽ đặt cúp vào tủ đựng cúp mà bạn chia sẻ với bạn bè. **Điều thú vị là các khối giao dịch có thể lập trình cho phép các lập trình viên viết mã theo cách mà trò chơi không cần biết về ví nhiều chữ ký hoặc cách Mario được lưu trữ, cũng như không cần biết về tủ cúp của bạn hoặc cách nó được triển khai . **

**Các khối giao dịch có thể lập trình bao gồm các giao dịch với các đối tượng đầu vào và đầu ra. **Nếu bạn cần một đối tượng đầu vào, bạn có thể lấy đối tượng đó mà không cần quan tâm nó đến từ đâu và chuyển đầu ra của nó cho đối tượng cần nó và cũng không cần quan tâm nó được chuyển đến đâu. Trong các chuỗi khối khác, khớp nối mạnh hơn, vì vậy các trò chơi phải tích hợp với ví nhiều chữ ký và tủ khóa danh hiệu hoặc tất cả chúng phải triển khai một số giao diện chung và có khớp nối mạnh hơn. **Sui làm cho cái gọi là kết hợp đặc biệt dễ dàng hơn nhiều. **Giống như, nếu các đường ống khớp nhau, chúng ta có thể thực hiện điều đó trong một lần giao dịch.

**Q5、****Lợi ích của các khối giao dịch có thể lập trình đối với người dùng là gì? **

Đối với người dùng, lợi ích của các khối giao dịch có thể lập trình bao gồm chi phí gas thấp hơn, bởi vì bạn có thể gói tất cả các hoạt động vào một giao dịch thay vì thực hiện các giao dịch riêng biệt. Ngoài ra, yêu cầu ít phê duyệt hơn. Nếu bạn đang sử dụng một hệ thống yêu cầu phê duyệt giao dịch, bạn chỉ cần thực hiện một lần và sau đó hệ thống sẽ thực hiện tất cả trong một lần. Một lợi ích khác là atomicity, nếu bạn muốn thực hiện ba việc khác nhau và muốn thao tác thứ ba chỉ thành công nếu hai thao tác đầu tiên thành công, nếu các thao tác đó phải là các giao dịch độc lập thì bạn không thể thực hiện được. Tuy nhiên, nếu bạn có thể đưa tất cả chúng vào một giao dịch, thì bạn có thể dễ dàng đạt được điều này.

**Q6, ****Tôi đã nghe bạn và những người khác nói về việc phát triển trên Sui như một trải nghiệm tuyệt vời cho các lập trình viên và điều đó rất quan trọng. Bạn có bất kỳ giai thoại nào để chia sẻ cho các lập trình viên Web3 mới và có kinh nghiệm bắt đầu với Sui Move không? **

Đối với những nhà phát triển đến từ các ngôn ngữ lập trình Web3 khác, trải nghiệm phát triển của họ trên Move và Sui Move thực sự hiệu quả và an toàn hơn. Tôi vừa xem một podcast về Bucket Protocol và họ đang xây dựng một dự án DeFi thực sự thú vị trên Sui. Khi trình diễn kiến trúc hệ thống, họ mô tả cách các thành phần khác nhau hoạt động cùng nhau. Họ nói rằng nếu họ viết dự án này bằng Solidity thì có thể mất tám tháng, nhưng với Sui Move thì chỉ mất hai tháng và họ rất tin tưởng vào tính bảo mật của nó. Cách thức hoạt động của ngôn ngữ rất gần với ý tưởng về danh mục dự án trong đầu họ. Trong thế giới Solidity, kết nối ít trực tiếp hơn.

Đây chỉ là một ví dụ, nhưng chúng tôi đã nghe rất nhiều trường hợp tương tự khi mọi người nói rằng họ phát triển ngôn ngữ nhanh hơn và cảm thấy tự tin hơn khi học xong. Tôi rất vui khi nghe điều đó. Nhưng theo một cách nào đó, điều này không có gì đáng ngạc nhiên, chúng tôi đã xem xét Solidity và tìm hiểu về các vấn đề. Chúng tôi đã thiết kế rõ ràng các kịch bản về cách làm cho nó an toàn hơn và nhanh hơn. Chúng tôi đã xem xét những gì các nhà phát triển ngôn ngữ đang cố gắng thực hiện và cách thiết kế ngôn ngữ để đáp ứng nhu cầu của họ, thay vì phục vụ cho những gì đã tồn tại. Ngôn ngữ được thiết kế cho những vấn đề mà mọi người gặp phải, vì vậy khi họ chuyển đổi, họ thực sự đánh giá cao ngôn ngữ đó.

**Họ nói lợi thế của người đi trước là quan trọng, nhưng tôi đoán trong trường hợp này, lợi thế của người đi sau mới quan trọng hơn. **

Đúng vậy, chính là nó.

**Q7、****Bạn đã đề cập đến vấn đề này khi đề cập đến Sui Move và các tính năng hướng đối tượng tổng thể của Sui. Nhưng bạn có thể nói rõ hơn về mối liên hệ giữa thiết kế của Sui Move và khả năng của Sui để đạt được sự chấp nhận hàng loạt Web3, độ trễ thấp, chi phí thấp và khả năng mở rộng không? **

Một trong những điều chúng tôi rất cảnh giác khi đóng góp cho Sui và vấn đề mà các nền tảng khác gặp phải là nếu bạn có khả năng hạn chế, cho dù đó là 15 giao dịch mỗi giây (TPS) như Ethereum hay 100 hoặc 1.000 giao dịch, nếu là một con số cố định, sau đó khi nền tảng trở nên quá thành công, nó sẽ đạt đến giới hạn trên của dung lượng. Tại thời điểm này, trải nghiệm cho mọi người sử dụng nền tảng đã xuống cấp. Nếu chỉ có 1.000 vị trí tuyển dụng, bạn phải chọn 1.000 vị trí quan trọng nhất, có thể được chọn thông qua đấu thầu gas hoặc các phương pháp khác. Đối với tất cả, giá xăng sẽ tăng, độ trễ sẽ tăng hoặc cả hai. Nhiều trường hợp sử dụng đã bị loại trừ, vì chỉ những trường hợp có khả năng trả phí cao nhất mới thành công, trong khi những trường hợp khác sẽ phải tìm nơi khác hoặc đợi lâu hơn. Đây không phải là một tình huống tốt.

**Sui nhắm đến khả năng mở rộng theo chiều ngang. **Có thể đạt được một lượng thông lượng nhất định nếu phân bổ một lượng phần cứng nhất định. Nếu cần nhiều thông lượng hơn, trình xác thực có thể giới thiệu nhiều tiện ích phần cứng hơn mà không có giới hạn trên. Đây là cách mọi dịch vụ Web2 hoạt động. Ý tôi là, có một số hạn chế kỹ thuật mà bạn phải giải quyết, đó không phải là điều chắc chắn hoặc dễ thực hiện, nhưng mọi người đều muốn đạt được khả năng mở rộng theo chiều ngang khi thiết kế các dịch vụ web có thể mở rộng.

Nếu Sui có nhiều khách hàng hoặc người dùng hơn, mục tiêu của chúng tôi là để Sui tiếp tục phát triển và mọi thứ sẽ hoạt động. Tất nhiên, trong khi duy trì độ trễ rất thấp. Bạn không muốn hy sinh độ trễ trong khi tăng thông lượng.

Trong hệ thống Libra, những đặc điểm này không được xem xét. Nó chỉ là một hệ thống thanh toán quy mô nhỏ, với hàng trăm nhà điều hành thanh toán và có thể có hàng chục triệu lượt thanh toán mỗi ngày, nhưng không nhiều hơn. Vì vậy, chúng tôi đã áp dụng một kiến trúc hộp duy nhất, đơn giản hơn và đầy đủ hơn. Nhưng ở Sui, chúng tôi biết rằng hệ thống Libra sẽ không hoạt động vì nó không có tính năng mở rộng theo chiều ngang. Vì vậy, chúng tôi nghĩ, làm thế nào để chúng tôi thiết kế một hệ thống từ đầu có thể làm được điều đó. Đây là nơi mô hình dữ liệu hướng đối tượng xuất hiện. Về cơ bản, chúng tôi đã loại bỏ mô hình dữ liệu dựa trên tài khoản cũ vì mô hình này gây khó khăn cho việc đạt được khả năng mở rộng theo chiều ngang. Thay vào đó, nếu bạn tổ chức mọi thứ thành các đối tượng, thì trạng thái chung chỉ là một bản đồ lớn từ ID đối tượng đến các đối tượng. Đó là kho lưu trữ khóa-giá trị và chúng tôi biết cách mở rộng quy mô kho lưu trữ khóa-giá trị, đó là một vấn đề kỹ thuật đơn giản.

Sau đó, câu hỏi trở thành, làm thế nào để chúng ta thiết kế một cấu trúc giao dịch phù hợp với việc tìm nạp và cập nhật dữ liệu từ kho lưu trữ khóa-giá trị? Làm cách nào để chúng tôi phân tách kho lưu trữ khóa-giá trị? Làm cách nào để chúng tôi quyết định nơi các giao dịch sẽ được xử lý? Đó là cơ bản nơi nó đến từ. Điều đó nói rằng, chúng tôi biết làm thế nào để mở rộng quy mô những điều này. Làm cách nào để chúng tôi biến điều này thành thứ có thuộc tính chuỗi khối, số lần đọc có thể kiểm chứng, hoạt động với Move, v.v. Và sau đó làm thế nào để mang chúng lại với nhau một cách suôn sẻ nhất có thể.

Q8、** Ở cấp độ cao hơn, làm cách nào để bạn thảo luận về tiềm năng của công nghệ phi tập trung với các nhà phát triển còn hoài nghi về Web2? **

**Tôi nghĩ rằng blockchain và tiền điện tử về cơ bản là một công nghệ giúp loại bỏ ma sát. **Có những rào cản khiến chúng tôi rất khó thực hiện các giao dịch tài chính, xây dựng ứng dụng hoặc thiết lập thông tin vì thông tin không thể vượt qua những rào cản này hoặc nếu thông tin vượt qua những rào cản này thì cần có sự trợ giúp của một số bên thứ ba và những thứ này đầu tiên Bên thứ ba tính phí để có thể cung cấp hỗ trợ.

Một ví dụ cổ điển mà mọi người thích sử dụng là mua một ngôi nhà. Có người mua và người bán, nhưng khi bạn thực sự thanh toán, phải có một đại lý ký quỹ không làm gì khác ngoài việc ngồi đó và ký quỹ vì người mua và người bán không hoàn toàn tin tưởng lẫn nhau. Đây là một thực tế của cuộc sống. Chúng ta sẽ đối phó với điều này. Tuy nhiên, nếu đại lý ký quỹ có thể là mã mà cả hai bên đều có thể xem được hoặc được xác minh bởi một số bên thứ ba, thì đại lý đó có thể thực hiện công việc miễn phí hoặc ít hơn nhiều. Mục đích của blockchain không phải là loại bỏ các đại lý ký quỹ trong bất động sản. Đây chỉ là một trong những trường hợp sử dụng, nhưng nó thường xảy ra.

**Nếu không còn rào cản về khả năng tương tác giữa ứng dụng A và ứng dụng B, nhưng được xây dựng trên cùng một nền tảng cơ bản, thì bạn có thể chuyển mọi thứ từ ứng dụng này sang ứng dụng khác, có thể là mục trong ứng dụng, dữ liệu, trên các quảng cáo hoặc ứng dụng thứ ba -các sản phẩm của bên được xây dựng trên cả hai. ** Hoặc tưởng tượng về internet, nơi các trang web chia sẻ dữ liệu với nhau thông qua cookie, nhưng những cookie đó chỉ là siêu dữ liệu chỉ đọc. Điều gì sẽ xảy ra nếu những cookie này có thể trở thành tiền tệ? Hoặc nó có thể là một mặt hàng có thể tiêu hao? Hoặc nó có thể là chương trình khách hàng thân thiết và phiếu giảm giá? Mọi thứ đều có chức năng này được tích hợp sẵn. Nó rất trừu tượng, nhưng tiềm năng nằm ở đó. Thông thường, một người đang xây dựng sẽ coi đây là những siêu năng lực mới mà anh ta có thể sử dụng để xây dựng một thứ gì đó hấp dẫn hơn.

Q9、** Đối với người dùng cuối, ngay cả khi họ không có kiến thức kỹ thuật, bạn có cảm thấy do dự khi họ xem xét độ tin cậy của mã, ngay cả khi tùy chọn khác là một thực thể trung tâm lớn không rõ ràng? **

Tôi không nghĩ vậy. Bởi vì chúng ta làm những việc như thế này mỗi ngày, phải không? Khi tôi đăng nhập vào email của mình, tôi không lo lắng rằng mã sẽ xóa một trong các email của tôi hoặc khi tôi gửi email, nó sẽ không thực sự gửi. Nếu điều đó xảy ra, thì có lẽ tôi sẽ ngừng sử dụng email hoặc sử dụng nhà cung cấp khác. Tôi nghĩ nó rất giống nhau, tất nhiên không phải ai cũng có thể thực sự đọc một thứ gì đó và kiểm tra xem nó hoạt động như thế nào.

Và, bạn biết đấy, nếu tôi muốn kiểm tra mã của email, tôi không thể vì mã không có ở đó. Vì vậy, minh bạch là một khía cạnh quan trọng của điều đó. Mặc dù không phải ai cũng có thể làm điều này, nhưng một số người có thể lấy mẫu. Và, kết hợp điều đó với việc sử dụng lại bất cứ thứ gì, cộng với tính bất biến. Đó là chìa khóa ở đây. Khi tôi đăng nhập vào email của mình, tôi không biết liệu mã có thay đổi kể từ lần cuối cùng tôi làm điều gì đó hay không. Không có sự minh bạch về điều này. Ngay cả khi biết thông tin này, bạn có thể lấy thông tin đó trong Web3 và bạn không thể lấy thông tin đó ở nơi khác.

Q10、** Bạn kỳ vọng gì vào sự phát triển trong tương lai của Sui Move? **

**Nhiều tính năng mà chúng tôi hiện đang tập trung vào dựa trên kinh nghiệm của chúng tôi với các nhà phát triển đã phát hành lô gói Sui Move đầu tiên của họ, sau đó xem xét cách họ muốn phát triển các tính năng đó, tính năng nào dễ phát triển và tính năng nào những cái khó hơn. **Sui Move là một ngôn ngữ tuyệt vời cho gói phát hành đầu tiên, nhưng đối với loại tôi sẽ thay đổi, tôi sẽ thêm một số trường, tôi sẽ thêm một số chức năng, tôi sẽ làm điều đó theo cách gắn kết nhưng không đi ngược lại việc sử dụng gói ban đầu Để hoạt động theo cách mà người dùng tin tưởng, đây trở thành một vấn đề rất khó khăn. Phần lớn những gì chúng tôi làm là xem xét vấn đề này và xác định những tính năng cấp độ ngôn ngữ nào chúng tôi có thể thêm vào để mang lại cho các lập trình viên sự linh hoạt trong việc mở rộng trong khi vẫn duy trì sự tin tưởng của người dùng đối với mã gốc.

**Chúng tôi đang nghiên cứu rất nhiều tính năng liên quan đến điều này, đặc biệt là các loại enum. **Chúng tôi cũng đang nỗ lực cải thiện trải nghiệm kết nối Move với mã giao diện người dùng. Chúng tôi thường nói đùa rằng một ứng dụng Sui điển hình là 5% Move code và 95% front-end code. Vì vậy, chúng tôi rất tập trung vào 95% đó. Chúng tôi đã dành nhiều thời gian để nói về Move, nhưng chúng tôi cũng tập trung nhiều vào việc làm cho các bộ phận khác hoạt động hiệu quả hơn và kết nối dễ dàng hơn. Nói chung, chúng tôi rất tập trung vào cách làm cho ứng dụng bao gồm nhiều Move hơn để bảo mật hơn. Đồng thời, làm cách nào để chúng tôi làm cho 95% mã đó có thể hiểu được đối với cả lập trình viên Move và những người không lập trình Move.