Tác giả: Sui Foundation Biên dịch: Cointime.com 237

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, để thảo luận về lý do tại sao ông ấy lại phát triển ngôn ngữ lập trình hợp đồng thông minh mới, cách Sui kích hoạt khả năng mở rộng và lợi ích của việc phân cấp cho các nhà phát triển.

Đầu 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, phẩm chất nào là quan trọng nhất khi nhà phát triển 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ữ 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 và an toàn với máy tính, và điều đặc biệt quan trọng là nó phải hiệu quả và rõ rà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ộ mục đích của ngôn ngữ tự nhiên là sự phong phú và sức mạnh biểu cảm của nó. Ví dụ, một sự thay đổi nhỏ trong ngữ điệu hoặc lựa chọn từ ngữ của bạn có thể làm cho câu hoặc đoạn văn của bạn hoàn toàn khác. Trong khi với ngôn ngữ lập trình, điều quan trọng nhất là bạn 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 một sửa đổi nhỏ đối với nó, bạn cũng biết thay đổi đó là gì. Và định nghĩa chính xác này được duy trì ở nhiều cấp độ như bạn có thể viết mã bằng ngôn ngữ nguồn và nó có nghĩa và sau đó nó được chuyển đổi thành một biểu diễn trung gian có nghĩa tương tự, cho đến tận silicon của bộ phận máy .

Tôi nghĩ ngôn ngữ lập trình khác với ngôn ngữ tự nhiên ở chỗ chúng có bản chất cụ thể theo miền hoặc nhiệm vụ cụ thể. Nếu không, sẽ chỉ có một ngôn ngữ lập trình có thể làm mọi thứ. Nhưng lý do tồn tại nhiều ngôn ngữ lập trình là vì bạn không thể giỏi tất cả mọi thứ. Họ thực sự đang cố gắng nhắm mục tiêu vào một lĩnh vực có vấn đề cụ thể và rất tập trung vào đó. Vì vậy, 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à các hệ thống khác hoạt động trên Mysten, thì nó tập trung vào việc viết mã rất nhanh và hiệu quả, nhưng cũng an toàn. Nó cho phép bạn truy cập vào bộ nhớ cơ bản, cấu trúc luồng hoặc đồng thời, nhưng không để bạn tự làm rối tung bản thân như các ngôn ngữ C hoặc C++ cũ đã làm.

Câu chuyện của Move rất giống nhau. Khi tôi tạo ra nó, nó không phải để tạo ra một ngôn ngữ mới. Một câu hỏi khác mà bạn đặt ra là các nhà phát triển tìm kiếm điều gì trong một ngôn ngữ. Họ hỏi: "Liệu ngôn ngữ này có phù hợp với công việc tôi muốn làm không?" Nhưng tôi nghĩ điều quan trọng hơn là "Ngôn ngữ này có cộng đồng lớn không? Có nhiều thư viện không? Có nhiều lập trình viên sử dụng không? Có tài nguyên giáo dục tốt không? ?" Bởi vì điều này rất quan trọng nên rào cản gia nhập để tạo ra một ngôn ngữ mới phải rất cao và ngay cả khi bản thân ngôn ngữ đó tốt hơn, điểm mạnh của nó sẽ không thành vấn đề nếu không có sự hỗ trợ đó. Và đi từ con số 0 đến việc có một cộng đồng lớn và sôi động là rất khó.

Anh có thể chia sẻ một chút về quá trình phát triển của Move được không?

Nguồn gốc của Move có thể bắt nguồn từ dự án Libra của Facebook. Nhiệm vụ của tôi vào thời điểm đó không phải là tạo ra một ngôn ngữ mới, mà là "Libra cần phải có khả năng hợp đồng thông minh, vì vậy hãy tìm ra những gì chúng ta nên làm." Tôi đã xem xét các khả năng. Chúng tôi có thể sử dụng Solidity trên Máy ảo Ethereum không? Có nên sử dụng và sử dụng một ngôn ngữ chung thông thường như WASM hoặc JVM 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 tôi dựa trên việc nghiên cứu các hợp đồng thông minh hiện có và hiểu những gì các lập trình viên đang cố gắng thực hiện, ngôn ngữ đã giúp họ ở đâu và nó đã làm họ thất bại ở đâu. Kết luận của tôi là trong nhiều trường hợp, nó làm họ thất vọng.

Điều này có thể được nhìn thấy từ hồ sơ bảo mật kém của Solidity, nhưng quan trọng hơn, các hợp đồng thông minh này là một loại chương trình rất độc đáo. Solidity không phải là một ngôn ngữ được xây dựng để đáp ứng nhu cầu của mọi người ngày nay. Tôi không có ý chỉ trích vì chúng là ngôn ngữ hợp đồng thông minh đầu tiên và chúng không 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ĩ khá rõ ràng rằng bạn cần một bộ trừu tượng và công cụ lập trình khác với ngôn ngữ mà Solidity cung cấp.

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

Trên máy tính, mọi thứ chỉ là bit và byte, có thể được sao chép tự do. Bạn biết đấy, những khái niệm này không tồn tại trong máy tính. Vì vậy, bạn muốn có một ngôn ngữ cung cấp cho bạn những khái niệm trừu tượng tốt đẹp về quyền sở hữu và tính có thể thay thế được. 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 bánh xe. Bạn muốn có những đảm bảo an ninh cơ bản này.

Đó là những gì Move làm và lý do cuối cùng chúng tôi quyết định tạo ra một ngôn ngữ mới. Những nhiệm vụ cơ bản này tồn tại trong lập trình hợp đồng thông minh, khó tái tạo 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ó. Chúng tôi muốn thiết kế toàn bộ ngôn ngữ để cung cấp các yếu tố cơ bản này, cho phép các lập trình viên viết mã một cách an toàn và hiệu quả mà không cần phải phát minh lại bánh xe mỗi khi họ muốn viết một số mã.

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? Và tính năng nào của Sui Move đặc biệt phù hợp để xây dựng sản phẩm trên Web3?

Một số yếu tố đã góp phần vào những thay đổi này. Một trong những mục tiêu của dự án Libra ban đầu là xây dựng một mạng thanh toán tuân thủ quy định. Vì vậy, chúng tôi đã cố gắng thiết kế Move như một ngôn ngữ chung. Nhưng chúng tôi cũng có ý thức làm mọi thứ để đáp ứng những ràng buộc mà Libra yêu cầu. Một trong những vấn đề lớn là họ không muốn mọi người có thể di chuyển một số tài sản nhất định. 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ạo tài khoản, chẳng hạn như chủ sở hữu tài khoản phải vượt qua xác minh KYC hoặc có tính phí khi tạo tài khoản hoặc tài khoản chỉ có thể được tạo bởi một số ít người có quyền tạo tài khoản. Những hạn chế này tồn tại vì toàn bộ mục đích của Libra là muốn thực hiện các khoản thanh toán tuân thủ và hợp đồng thông minh tuân thủ. Nhưng trong không gian Web3 tổng quát hơn, điều ngược lại là đúng. Bạn không muốn có khái niệm tuân thủ dưới mui xe, đó là khái niệm về hợp đồng thông minh. Bạn muốn mọi thứ càng miễn phí càng tốt và 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ẽ cản trở 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, dự án Libra không được xem xét tại thời điểm đó về cách đưa trọng tâm tài sản này vào chính các giao dịch. Vì vậy, viết mã trong Move cũng được, nhưng khi bạn đạt đến cấp độ giao dịch, bạn vẫn chỉ có API này, bạn cần nhập số, boolean, v.v. Nhận một tài sản và thực hiện một loạt thao tác. Hóa ra, hầu hết mã bạn đang chạy là sổ sách kế toán tồi tệ như loại bỏ thứ này, loại bỏ thứ kia, loại bỏ thứ khác, tôi đã có tất cả tài sản tôi muốn. Họ ở đó, và bây giờ tôi có thể bắt đầu làm điều gì đó có ý nghĩa. Và sau đó, bạn nói, được rồi, hãy đư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.

Ở Sui, chúng tôi suy nghĩ rất nhiều về câu hỏi, nếu mọi chương trình đều bắt đầu và kết thúc theo cách này, liệu 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à từ 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à họ có thể bắt đầu thực hiện công việc thú vị ngay lập tức. Đây là cơ sở của 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ữ dưới tài khoản và lập trình viên phải lấy chúng một cách rõ ràng. Trong khi ở Sui, chúng đã được trích xuất vào phần Di chuyển của giao dịch khi chạy qua Sui. Nó thân thiện hơn nhiều với các lập trình viên vì họ không phải thực hiện tất cả công việc ghi sổ tới lui này và đó cũng là cách chúng tôi có thể biết liệu chúng tôi có thể thực hiện một giao dịch song song với một giao dịch khác hay không, mở rộng quy mô Sui theo chiều ngang mà không thực sự thực hiện giao dịch và các mẹo để thực hiện các hoạt động khác hiệu quả hơn.

Chúng tôi cũng đã thực hiện một vài điều thực sự thú vị khác như khối giao dịch có thể lập trình sử dụng mô hình dữ liệu dựa trên đối tượng. Đây là một chủ đề kỹ thuật hơn một chút và tôi rất sẵn lòng thử và giải thích nó. 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.

Nếu bạn muốn, tôi có thể chia sẻ thêm thông tin về các khối giao dịch có thể lập trình và khả năng của chúng.

Chúng tôi cũng đã thực hiện một vài điều thực sự thú vị khác như khối giao dịch có thể lập trình sử dụng mô hình dữ liệu dựa trên đối tượng. Đây là một chủ đề kỹ thuật hơn một chút và tôi rất sẵn lòng thử và giải thích nó. 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.

Nếu bạn muốn, tôi có thể chia sẻ thêm thông tin về các khối giao dịch có thể lập trình và khả năng của chúng.

Một phép loại suy mà tôi muốn sử dụng ở đây là các chuỗi khối khác giống như một khu ẩm thực trong trung tâm thương mại. 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 cũng quyết định ăn một chiếc bánh mì kẹp thịt, thì bạn đến quầy bán bánh mì kẹp thịt và trả tiền. 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. Trong khi Sui giống như một bữa tiệc buffet không giới hạn. Mỗi giao dịch không chỉ là một mặt hàng. 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ể ăn tất cả cùng nhau.

Để 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 là gửi 100 giao dịch để đúc 100 NFT, bạn có thể gửi một giao dịch đến đúc 100 NFT. Chi phí như vậy gần tương đương với chi phí đúc một NFT. Bạn cũng có thể có các giao dịch được đóng gói không đồng nhất, chẳng hạn như giao dịch đầu tiên trong một khối lấy nhân vật Mario từ ví nhiều chữ ký của bạn và giao dịch thứ hai yêu cầu Mario và cho phép bạn chơi trò chơi. Nếu bạn thắng trò chơi và nhận được một chiếc cúp, có thể lần giao dịch thứ ba sẽ đưa chiếc cúp vào tủ đựng cúp mà bạn chia sẻ với bạn bè. Một trong những điều thú vị về điều này 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 phải quan tâm đến ví nhiều chữ ký hoặc cách Mario được lưu trữ. Nó cũng không cần biết bất cứ điều gì về tủ danh hiệu của bạn hoặc cách nó được thực hiện.

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 một giao dịch cần một đối tượng đầu vào, nó có thể lấy thứ đó mà không cần quan tâm nó đến từ đâu và chuyển đầu ra của nó đến nơi cần thiết mà không cần quan tâm nó sẽ đi đâu. Trong các chuỗi khối khác, khả năng ghép nối cao 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ả năng ghép nối cao hơn. Sui làm cho những gì tôi gọi là ngẫu hứng dễ dàng hơn nhiều. Giống như, nếu các quy trình phù hợp, chúng tôi có thể thực hiện mọi thứ trong một giao dịch.

Vì vậy, lợi ích của các khối giao dịch có thể lập trình cho người dùng là gì?

Từ góc độ người dùng, tôi nghĩ những lợi ích như sau: Phí gas thấp hơn vì bạn có thể gói tất cả các hoạt động vào một giao dịch thay vì nhiều giao dịch riêng lẻ. Ngoài ra, số lượng phê duyệt đã giảm. Nếu bạn 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 đó thực hiện tất cả trong một lần. Ngoài ra, tôi nghĩ rằng có một điểm khác về tính nguyên tử. Nếu bạn muốn thực hiện ba việc khác nhau và muốn việc thứ ba chỉ thành công nếu hai việc đầu tiên thành công, thì điều đó sẽ không hiệu quả nếu những việc đó phải là các giao dịch riêng biệt. Nhưng nếu bạn có thể đưa tất cả chúng vào một giao dịch thì không có vấn đề gì.

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

Đối với những nhà phát triển sử dụng các ngôn ngữ lập trình Web3 khác, họ cảm thấy hiệu quả hơn trong Move và Sui Move. Đồng thời, phương pháp này cũng an toàn hơn. Tôi đã 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ọ minh họa cách các thành phần khác nhau hoạt động cùng nhau. Họ nói rằng nếu viết dự án này trên Solidity thì có thể mất 8 tháng, nhưng với Sui Move, họ chỉ mất 2 tháng và rất tin tưởng vào tính bảo mật của nó. Mô hình lập trình của Sui Move rất gần với ý tưởng của họ về cách các mục nên được sáng tác. Trong thế giới Solidity, kết nối này gián tiếp hơn nhiều.

Đây chỉ là một ví dụ và 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ọ tiến bộ nhanh hơn trong ngôn ngữ và cảm thấy tự tin hơn về kết quả khi họ hoàn thành. Điều này làm cho tôi rất hạnh phúc. Nhưng theo một cách nào đó, điều đó không đáng ngạc nhiên. Chúng tôi đã xem xét Solidity và thấy có vấn đề với nó. Thiết kế của chúng tôi rõ ràng xoay quanh cách làm cho nó an toàn hơn và nhanh hơn. Chúng tôi nghĩ về những vấn đề mà những người sử dụng ngôn ngữ đang cố gắng giải quyết và cách thiết kế một ngôn ngữ đáp ứng nhu cầu của họ, chứ không chỉ những gì đang 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 sang ngôn ngữ này, họ thực sự có thể cảm nhận được lợi ích của nó.

Họ nói "người đi trước thắng", nhưng tôi đoán trong trường hợp này có thể nói "người đi sau thắng".

Vâng, đúng vậy.

Bạn đã nói về điều này khi đề cập đến Sui Move và bản chất hướng đối tượng chung của Sui. Nhưng bạn có thể trình bày rõ ràng 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 việc áp dụng rộng rãi Web3, đặc biệt là về độ trễ thấp, chi phí thấp và khả năng mở rộng không?

Bạn đã nói về điều này khi đề cập đến Sui Move và bản chất hướng đối tượng chung của Sui. Nhưng bạn có thể trình bày rõ ràng 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 việc áp dụng rộng rãi Web3, đặc biệt là về độ trễ thấp, chi phí thấp và khả năng mở rộng không?

Chúng tôi rất thận trọng khi đóng góp cho Sui và tôi nghĩ đây là vấn đề mà các nền tảng khác cũng gặp phải. Nếu bạn có dung lượng hạn chế, cho dù đó là 15 TPS (giao dịch mỗi giây) trên Ethereum hay 100 hay 1.000, nếu đó là một con số cố định, thì khi nền tảng trở nên quá thành công, nó sẽ đạt đến giới hạn 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í, bạn phải chọn 1.000 vị trí quan trọng nhất, có thể thông qua đấu giá xăng hoặc một cái gì đó. Giá tăng đối với mọi người hoặc độ trễ tăng đối với mọi người hoặc cả hai. Rất nhiều trường hợp sử dụng bị loại trừ vì chỉ người trả phí cao nhất mới thắng và những người khác phải đi nơi khác hoặc đợi lâu hơn. Điều này không lý tưởng.

Mục tiêu của Sui là khả năng mở rộng theo chiều ngang. Nếu bạn phân bổ một lượng phần cứng nhất định, bạn có thể đạt được một lượng thông lượ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 thêm phần cứng. Không có giới hạn trên cho điều này. Đây là cách mọi dịch vụ Web2 hoạt động. Tất nhiên, bạn phải giải quyết một số hạn chế và vấn đề kỹ thuật, và đó không phải là điều chắc chắn hoặc dễ thực hiện, nhưng khi thiết kế các dịch vụ web có thể mở rộng, mọi người đều muốn đạt được khả năng mở rộng theo chiều ngang.

Nếu Sui có thêm nhiều khách hàng hoặc người dùng, mục tiêu là để Sui tiếp tục phát triển và mọi thứ sẽ hoạt động. Và tất nhiên, giữ độ trễ rất thấp. Bạn không muốn phải hy sinh độ trễ để đạt được thông lượng cao hơn.

Trong hệ thống Libra, chúng tôi không tính đến các thuộc tính này. Đó là một hệ thống thanh toán quy mô nhỏ, có thể vài trăm nhà điều hành thanh toán mỗi ngày, có thể hàng nghìn hoặc hàng triệu khoản thanh toán, nhưng không nhiều hơn thế. Do đó, chúng tôi đã áp dụng kiến ​​trúc một khung vì nó đơn giản hơn và đủ để sử dụng. Nhưng đối với Sui, chúng tôi biết hệ thống Libra sẽ không hoạt động vì nó thiếu cá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ể đạt được điều này. Đâ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ì đó là điều khiến khả năng mở rộng theo chiều ngang trở nên khó đạt được. Trong khi nếu bạn tổ chức mọi thứ thành các đối tượng, thì trạng thái chung của bạn 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ị. Đây là một câu hỏi kỹ thuật đơn giản.

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

Ở cấp độ cao, làm thế nào để bạn nói lời hứa về công nghệ phi tập trung với những người hoài nghi về các nhà phát triển Web2?

Tôi nghĩ rằng blockchain và tiền điện tử về cơ bản là một công nghệ loại bỏ ma sát. Có một số 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 các rào cản này hoặc nếu vượt qua các rào cản này thì sẽ cần có sự trợ giúp của một số bên thứ ba và họ sẽ tính phí cho nó Một số khoản phí.

Một ví dụ kinh điển là nếu bạn mua một căn nhà, có người mua và người bán, nhưng khi thanh toán thực sự được thực hiện, phải có một bên thứ ba là đại lý bảo lãnh, người không làm gì ngoài việc ngồi đó và giữ tiền vì người mua và người bán. Không hoàn toàn tin tưởng 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ý xác nhận có thể là mã mà cả hai bên đều có thể xem được hoặc đã được bên thứ ba nào đó kiểm tra, 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 đảm bảo về bất động sản. Đó chỉ là một trường hợp ứng dụng. Nhưng đây là một nguyên tắc chung.

Nếu thay vì làm cho Ứng dụng A và Ứng dụng B không thể tương tác với nhau, thì chúng được xây dựng trên cùng một nền tảng cơ bản, vì vậy bạn có thể chuyển mọi thứ từ ứng dụng này sang ứng dụng khác, cho dù đó là mục trong ứng dụng, dữ liệu, quảng cáo chéo hoặc một số chức năng của bên thứ ba được xây dựng trên cả hai. Hoặc nghĩ về internet, nơi các trang web chia sẻ dữ liệu 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 họ có thể là đối tượng chi tiêu? Điều gì sẽ xảy ra nếu đây có thể là một 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, những người đang xây dựng nghĩ rằng đây là những siêu năng lực mới mà tôi có thể sử dụng để xây dựng thứ gì đó hấp dẫn hơn.

Đối với người dùng cuối, ngay cả khi họ không phải là chuyên gia kỹ thuật, bạn có cảm thấy do dự khi họ nghĩ về việc tin tưởng mã, ngay cả khi tùy chọn khác là một thực thể trung tâm lớn mờ đục?

Đối với người dùng cuối, ngay cả khi họ không phải là chuyên gia kỹ thuật, bạn có cảm thấy do dự khi họ nghĩ về việc tin tưởng mã, ngay cả khi tùy chọn khác là một thực thể trung tâm lớn mờ đục?

Tôi không nghĩ vậy. Bởi vì chúng ta làm điều 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ẽ làm mất thư của tôi hoặc khi tôi gửi 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 một nhà cung cấp khác. Tôi nghĩ nó cũng rất giống ở đây, tất nhiên chỉ có nhiều người thực sự có thể đọc một cái 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 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 đó. Trên thực tế, không phải ai cũng làm được, nhưng một số có thể kiểm tra tại chỗ. Ngoài ra, có tái sử dụng và 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ả trong Web3, bạn có thể lấy phần thông tin này, bạn không thể lấy nó ở bất kỳ nơi nào khác.

Bạn có kỳ vọng gì cho sự phát triển của Sui Move trong tương lai?

Rất nhiều tính năng mà chúng tôi đang tập trung vào ngay bây giờ dựa trên kinh nghiệm của chúng tôi với những người phát hành lô gói Sui Move ban đầu của họ, sau đó xem cách họ muốn phát triển các gói đó và điều gì dễ phát triển và điều gì khó. Sui Move là ngôn ngữ tuyệt vời cho các lần phát hành gói lần đầu, nhưng nếu tôi muốn thay đổi loại, thêm một số trường, thêm một số chức năng và thực hiện theo cách phối hợp mà không vi phạm nguyên tắc sử dụng gói ban đầu Người dùng tin tưởng, sau đó trở thành một vấn đề rất thách thức. Phần lớn công việc chúng tôi làm là xem xét vấn đề này và tìm ra những tính năng ở cấp độ ngôn ngữ nào mà 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 mã trong khi vẫn duy trì niềm tin ở những người sử dụng mã gốc.

Chúng tôi đang nghiên cứu rất nhiều chức năng liên quan đến vấn đề này, đặc biệt là enums. Chúng tôi cũng đang nghiên cứu những thứ khác liên quan đến trải nghiệm kết nối Di chuyển với mã giao diện người dùng. Chúng tôi muốn nói đùa rằng 5% của một ứng dụng Sui điển hình là mã Move và 95% là mã giao diện người dùng. Vì vậy, chúng tôi quan tâm rất nhiều về 95% đó. Chúng tôi dành nhiều thời gian để nói về Move, nhưng chúng tôi cũng quan tâm nhiều đến việc làm cho phần khác hiệu quả hơn và giúp kết nối dễ dàng hơn. Nói chung, làm thế nào chúng ta có thể làm cho ứng dụng bao gồm nhiều Moves hơn để cải thiện tính bảo mật? Đồng thời, làm cách nào để chúng tôi làm cho 95% mã đó dễ tiếp cận hơn đối với cả lập trình viên Move và những người không lập trình Move.