Cuộc trò chuyện cùng cha đẻ của ngôn ngữ Move: Move sở hữu lợi thế về sau, blockchain về bản chất là một công nghệ loại bỏ ma sát
Tuyển chọn TechFlowTuyển chọn TechFlow
Cuộc trò chuyện cùng cha đẻ của ngôn ngữ Move: Move sở hữu lợi thế về sau, blockchain về bản chất là một công nghệ loại bỏ ma sát
Đố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 trên Move và Sui Move thực sự hiệu quả hơn và an toàn hơn.
Chuyên sâu báo cáo Web3Gần đây, chúng tôi đã có cuộc trò chuyện với Sam Blackshear, Giám đốc Công nghệ của Mysten Labs và là người sáng tạo ra ngôn ngữ lập trình Move, để thảo luận về lý do ông phát triển Sui Move – một ngôn ngữ lập trình hợp đồng thông minh mới, những khả năng mở rộng mà Sui có thể thực hiện, cũng như lợi ích của công nghệ phi tập trung đối với các nhà phát triển.
Dưới đây là nội dung buổi phỏng vấn:
01. Trước hết, anh có thể khái quát về lập trình ngôn ngữ là gì, những phẩm chất nào mà nhà phát triển thường quan tâm nhất khi lựa chọn một ngôn ngữ lập trình, và điều gì thúc đẩy anh phát triển một ngôn ngữ lập trình riêng?
Một ngôn ngữ lập trình đơn giản chỉ là một công cụ để giao tiếp với máy tính theo cách thân thiện, an toàn, hiệu quả và rõ ràng, đặc biệt quan trọng đối với máy tính. Chúng ta không thể sử dụng ngôn ngữ tự nhiên để giao tiếp với máy tính vì bản chất của ngôn ngữ tự nhiên là phong phú và mang tính biểu đạt cao. Khi bạn diễn đạt cùng một từ vựng bằng giọng điệu hơi khác hoặc lựa chọn cách nói tinh vi hơn, nghĩa của câu hoặc đoạn văn sẽ hoàn toàn thay đổi.
Trong khi đó, điều quan trọng nhất ở một ngôn ngữ lập trình chính là phải có ngữ nghĩa được định nghĩa chính xác. Khi bạn viết một chương trình, bạn biết rõ nó sẽ làm gì. Nếu bạn chỉnh sửa nhỏ, bạn hiểu rõ sự thay đổi đó sẽ dẫn đến kết quả nào. Điều này phải được duy trì trên nhiều cấp độ: bạn viết mã bằng một ngôn ngữ nguồn có một ý nghĩa nhất định, sau đó chuyển sang dạng biểu diễn khác, thì ý nghĩa đó vẫn phải giữ nguyên, cho đến tận khi chạm tới mô-đun xử lý của máy.
Theo tôi, khác với ngôn ngữ tự nhiên, bản chất của ngôn ngữ lập trình là hướng tới các lĩnh vực hoặc nhiệm vụ cụ thể. Nếu không, chúng ta chỉ cần một ngôn ngữ lập trình duy nhất để thực hiện mọi thứ. Nhưng lý do tồn tại nhiều ngôn ngữ lập trình là bởi không thể có một ngôn ngữ nào xuất sắc trong tất cả các lĩnh vực. Mỗi ngôn ngữ đều nỗ lực hướng đến những bài toán cụ thể và tập trung giải quyết chúng. Ví dụ, hãy nhìn vào ngôn ngữ Rust – ngôn ngữ mà chúng tôi dùng để xây dựng blockchain Sui và hầu hết các công việc hệ thống khác tại Mysten. Nó tập trung vào việc viết mã vừa nhanh vừa hiệu suất cao, đồng thời đảm bảo an toàn. Nó cho phép bạn truy cập các chi tiết cấp thấp như bộ nhớ, cấu trúc luồng hay tính đồng thời, nhưng lại không khiến bạn dễ mắc lỗi như các ngôn ngữ trước đó (ví dụ C hay C++).
Do đó, câu chuyện về Move cũng tương tự như vậy. Khi tôi tạo ra nó, mục tiêu không phải là tạo ra một ngôn ngữ mới. Như anh vừa đề cập, nhà phát triển tìm kiếm điều gì trong một ngôn ngữ? Họ hỏi: “Ngôn ngữ này có phù hợp với nhiệm vụ tôi muốn hoàn thành không?” Nhưng tôi cho rằng điều còn quan trọng hơn là: “Ngôn ngữ này có cộng đồng lớn mạnh không? Có nhiều thư viện sẵn sàng không? Có nhiều lập trình viên đang dùng không? Có tài nguyên giáo dục tốt không?” Tất cả những yếu tố này đều rất quan trọng. Vì vậy, ngưỡng để tạo ra một ngôn ngữ mới phải rất cao. Ngay cả khi ngôn ngữ đó tốt hơn về mặt bản thân, nếu thiếu những yếu tố này thì lợi thế của nó cũng trở nên vô nghĩa. Việc xây dựng một cộng đồng lớn mạnh và sôi động từ con số 0 là cực kỳ khó khăn.
02. Anh có thể chia sẻ thêm về quá trình phát triển Move được không?
Move 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, hãy tìm xem chúng ta nên làm gì.” Tôi đã xem xét rất nhiều lựa chọn. Chúng ta có thể dùng Solidity trên EVM không? Chúng ta có nên dùng một ngôn ngữ phổ biến thông thường như WASM hay JVM cho Libra không? Hay chúng ta nên tự tạo ra thứ gì đó riêng biệt?
Quyết định tự tạo ra một thứ riêng biệt dựa trên nghiên cứu về các hợp đồng thông minh hiện có, tìm hiểu lập trình viên muốn làm gì, và nơi nào các ngôn ngữ hiện tại hỗ trợ họ, nơi nào khiến họ thất vọng. 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 tại thực sự khiến họ thất vọng.
Điều này thể hiện rõ qua hồ sơ an toàn kém cỏi của Solidity, nhưng sâu xa hơn, các hợp đồng thông minh này không phải là loại chương trình truyền thống. Solidity không phải là ngôn ngữ được xây dựng cho những gì con người đang làm ngày nay. Tôi không chỉ trích nó, vì nó là ngôn ngữ hợp đồng thông minh đầu tiên, và lúc đó chưa biết người dùng sẽ dùng nó để làm gì. Nhưng khi bạn thấy người dùng muốn làm gì với nó, tôi nghĩ rõ ràng là bạn cần một tập hợp các trừu tượng và công cụ lập trình khác, mà ngôn ngữ Solidity không cung cấp được.
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 định nghĩa kiểu tài sản, bao gồm quy tắc về khi nào 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, ai có thể ghi lên chúng. Và kiểm tra 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 hoặc thao tác trên nó. Mọi thứ xoay quanh tài sản – bạn mong muốn các tài sản này có cùng thuộc tính như tài sản vật lý. Nếu tôi đưa đồ vật cho bạn, thì bạn phải là người sở hữu, còn tôi sẽ không còn nữa.
Trong hợp đồng thông minh, có khái niệm 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à các bit và byte, và có thể sao chép tự do. Hơn nữa, những khái niệm này vốn không tồn tại trong thế giới thực. Do đó, bạn cần một ngôn ngữ có thể cung cấp các trừu tượng tốt về sở hữu và tính không thể thay thế, giống như trong thế giới thực, nhưng không buộc lập trình viên phải phát minh lại từ đầu. Bạn muốn có các đảm bảo an toàn cơ bản.
Đây chính là vai trò của Move và lý do chúng tôi cuối cùng đã tạo ra ngôn ngữ mới này. Những nhiệm vụ này là cơ bản đối với lập trình hợp đồng thông minh. Chúng rất khó tái tạo trong các ngôn ngữ khác, kể 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ữ xung quanh việc cung cấp các chức năng cơ bản này, để lập trình viên có thể viết mã an toàn và hiệu quả mà không phải mỗi lần viết code đều phải phát minh lại bánh xe.
03. 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 đặc điểm nào của Sui Move đặc biệt phù hợp để xây dựng sản phẩm trong Web3?
Có vài yếu tố thúc đẩy những thay đổi này. Một là mục tiêu ban đầu của dự án Libra là xây dựng một mạng lưới thanh toán tuân thủ pháp luật. Vì vậy, chúng tôi cố gắng thiết kế Move (https://docs.sui.io/learn/sui-move-diffs) như một ngôn ngữ phổ quát. Nhưng chúng tôi cũng cố ý thực hiện một số hạn chế vì Libra muốn kiểm soát. Một điểm quan trọng là họ không muốn người dùng có thể gửi tài sản đến bất kỳ đâu. Họ muốn người dùng phả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, ví dụ chủ tài khoản phải trải qua xác minh KYC. Hoặc có thể phải trả phí để tạo tài khoản, hoặc chỉ một nhóm nhỏ người có quyền mới được phép tạo tài khoản. Vì mục đích chính là Libra muốn thực hiện thanh toán và hợp đồng thông minh tuân thủ pháp luật, nên có những hạn chế này. Tuy nhiên, trong lĩnh vực Web3 tổng quát hơn, tình hình lại ngược lại. Bạn không muốn việc tuân thủ nằm ở tầng cơ sở – đó chính là tư tưởng của hợp đồng thông minh. Bạn muốn mọi thứ càng tự do càng tốt, có thể gửi một vật đến bất kỳ địa chỉ nào. Bạn cũng không nên yêu cầu tạo tài khoản rõ ràng, vì điều đó sẽ chặn đứng nhiều trường hợp sử dụng. Đây là một yếu tố quan trọng.
Yếu tố khác là, mặc dù chúng tôi tập trung vào tài sản trong Move, nhưng lúc đó trong Libra, chúng tôi chưa nghĩ đến việc đưa mối quan tâm về tài sản trực tiếp vào chính giao dịch. Do đó, khi lên đến tầng giao dịch, bạn vẫn chỉ có API nhận vào các con số, giá trị boolean – những thứ không phải là tài sản – rồi trong Move, bạn dùng các con số này để rút tài sản từ tài khoản và thực hiện các thao tác khác. Thực tế cho thấy phần lớn mã bạn chạy đều là các công việc sổ sách phiền phức: lấy cái này ra, lấy cái kia ra, lấy thêm cái khác nữa, rồi OK, giờ tôi đã có tất cả tài sản cần thiết. Chúng ở đây, trong "xưởng" của tôi, bây giờ tôi mới bắt đầu làm việc thật sự. Sau đó, ở cuối quá trình, bạn có thể nói: “OK, đặt lại các tài sản này vào tài khoản kia, sắp xếp lại chúng.”
Trên 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, liệu chúng ta có thể trừu tượng hóa việc đó không? Vì vậy, logic xử lý giao dịch sẽ làm việc này thay cho lập trình viên. Từ góc nhìn của lập trình viên, họ chỉ cần chuẩn bị sẵn các tài sản cần thiết, và ngay lập tức bắt đầu làm việc thú vị. Đó chính 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 gốc, 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 rút chúng một cách rõ ràng. Trên Sui, khi bước vào phần Move của giao dịch, tài sản đã được runtime của Sui lấy sẵn. Điều này thuận tiện hơn cho lập trình viên vì họ không cần làm các công việc sổ sách trước và sau đó, và đây cũng là "vũ khí bí mật" giúp chúng tôi xác định xem liệu một giao dịch có thể chạy song song với giao dịch khác mà không cần thực thi, từ đó mở rộng ngang Sui và thực hiện hiệu quả hơn một số thao tác khác.
Chúng tôi cũng thực hiện một số công việc rất thú vị khác, ví dụ như sử dụng mô hình dữ liệu dựa trên đối tượng để tạo các khối giao dịch lập trình được. Đây là chủ đề kỹ thuật, tôi rất sẵn lòng đi sâu. Nhưng hai yếu tố trên là động lực chính dẫn đến sự khác biệt với Move gốc.
04. Anh có thể chia sẻ thêm về các khối giao dịch lập trình được và chức năng của chúng không?
Tôi thích dùng một ẩn dụ để giải thích: các blockchain khác giống như 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 ra thanh toán. Nhưng nếu bạn quyết định muốn ăn thêm hamburger, bạn lại phải đến quầy hamburger và thanh toán lần nữa. Tôi không phải người tham ăn, nhưng nếu muốn ăn tám món, bạn phải thực hiện tám giao dịch riêng biệt. Còn Sui giống như buffet hơn. Mỗi giao dịch không chỉ làm một việc. Một khi bạn đã trả phí cho buffet, bạn có thể làm nhiều việc mà không tốn thêm chi phí. Bạn có thể ăn kem, ăn hamburger, thậm chí trộn chúng lại với nhau.
Để cụ thể hóa khái niệm này, trong trường hợp đơn giản, nếu bạn gửi 100 giao dịch để đúc 100 NFT, bạn có thể gửi một giao dịch duy nhất để đúc 100 NFT. Chi phí gần như bằng chi phí đúc một NFT. Bạn cũng có thể đóng gói giao dịch dị hợp: giao dịch đầu tiên trong khối lấy một nhân vật Mario từ ví đa chữ ký của bạn, giao dịch thứ hai yêu cầu Mario để bạn chơi game. Nếu bạn thắng và nhận được huy chương, có thể giao dịch thứ ba sẽ đặt huy chương vào tủ trưng bày chung với bạn bè. Điều tuyệt vời là các khối giao dịch lập trình được cho phép lập trình viên viết mã theo cách mà trò chơi không cần biết về ví đa chữ ký hay cách lưu trữ Mario, cũng không cần biết về tủ huy chương hay cách triển khai của nó.
Các khối giao dịch lập trình được bao gồm các giao dịch 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 nó mà không cần quan tâm nó đến từ đâu, rồi truyền đầu ra cho đối tượng cần nó, cũng không cần quan tâm nó sẽ đi đâu. Trên các blockchain khác, mức độ liên kết chặt chẽ hơn, nên trò chơi phải tích hợp với ví đa chữ ký và tủ huy chương, hoặc cả hai phải triển khai một giao diện chung và có sự phụ thuộc mạnh hơn. Sui làm cho việc tổ hợp tạm thời trở nên dễ dàng hơn. Như kiểu, nếu các ống nối khớp nhau, chúng ta có thể làm trong một giao dịch.
05. Vậy các khối giao dịch lập trình được mang lại lợi ích gì cho người dùng?
Đối với người dùng, lợi ích của các khối giao dịch lập trình được bao gồm phí gas thấp hơn, vì bạn có thể đóng gói mọi thao tác vào một giao dịch thay vì thực hiện từng giao dịch riêng lẻ. Ngoài ra, số lần cần phê duyệt cũng giảm xuống. Nếu hệ thống bạn dùng yêu cầu phê duyệt giao dịch, bạn chỉ cần phê duyệt một lần, sau đó mọi việc sẽ được thực hiện một lúc. Một lợi ích khác là tính nguyên tử: nếu bạn muốn làm ba việc khác nhau và muốn việc thứ ba chỉ thành công nếu hai việc trước thành công, thì nếu các thao tác này là giao dịch độc lập, bạn không thể thực hiện được. Nhưng nếu bạn có thể đặt chúng vào một giao dịch, bạn có thể dễ dàng làm được điều đó.
06. Tôi từng nghe anh và những người khác nói rằng việc phát triển trên Sui là một trải nghiệm tuyệt vời đối với lập trình viên, và điều này rất quan trọng. Anh có thể chia sẻ một vài câu chuyện về những lập trình viên Web3 có kinh nghiệm và mới bắt đầu sử dụng Sui Move không?
Đối với các 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 trên Move và Sui Move thực sự hiệu quả hơn và an toàn hơn. Tôi vừa tham gia một podcast về Bucket Protocol, họ đang xây dựng một dự án DeFi rất thú vị trên Sui. Khi trình bày kiến trúc hệ thống, họ kể về cách các thành phần khác nhau phối hợp. Họ nói rằng nếu dùng Solidity để viết dự án này, có thể mất tám tháng, nhưng dùng Sui Move chỉ mất hai tháng, và họ rất tin tưởng vào độ an toàn của nó. Cách ngôn ngữ hoạt động rất sát với cách họ hình dung việc ghép nối các thành phần trong đầu. Còn trong thế giới Solidity, sự liên kết này không trực tiếp như vậy.
Đâ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ự: mọi người nói họ phát triển nhanh hơn trên ngôn ngữ này, và sau khi hoàn thành thì cảm thấy tự tin hơn. Nghe những điều này khiến tôi rất vui. Nhưng cũng không quá ngạc nhiên, vì chúng tôi đã nghiên cứu Solidity và hiểu rõ các vấn đề của nó. Chúng tôi đã thiết kế rõ ràng các giải pháp nhằm làm cho nó an toàn hơn, nhanh hơn. Chúng tôi xem xét những gì nhà phát triển dùng ngôn ngữ này muốn làm, và cách thiết kế ngôn ngữ phù hợp với nhu cầu của họ, thay vì chạy theo những gì đã có. Ngôn ngữ này được thiết kế để giải quyết các vấn đề mà người dùng gặp phải, vì vậy khi họ chuyển sang, họ thực sự đánh giá cao nó.
Họ nói lợi thế đi trước rất quan trọng, nhưng tôi nghĩ trong trường hợp này, lợi thế đi sau mới quan trọng hơn.
Đúng vậy, chính xác.
07. Khi anh nhắc đến đặc tính hướng đối tượng của Sui Move và toàn bộ Sui, anh đã đề cập đến điều này. Nhưng anh có thể làm rõ hơn mối liên hệ giữa thiết kế của Sui Move với khả năng Sui đạt được việc áp dụng hàng loạt trong Web3, độ trễ thấp, chi phí thấp và khả năng mở rộng không?
Một điểm mà chúng tôi rất cảnh giác khi đóng góp cho Sui, cũng là vấn đề mà các nền tảng khác đang gặp phải, là nếu dung lượng bị giới hạn, dù là Ethereum với 15 giao dịch mỗi giây (TPS), hay 100 hay 1.000 giao dịch, nếu là một con số cố định, thì khi nền tảng quá thành công, nó sẽ chạm trần dung lượng. Lúc đó, trải nghiệm của mọi người dùng nền tảng sẽ suy giảm. Nếu chỉ có 1.000 chỗ trống, bạn phải chọn 1.000 giao dịch quan trọng nhất, bằng cách đấu giá gas hoặc các phương thức khác. Giá gas tăng cho tất cả mọi người, độ trễ tăng lên, 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 chịu trả phí cao nhất mới thành công, còn những người khác phải chuyển đi nơi khác hoặc chờ lâu hơn. Đây không phải là tình huống tốt.
Mục tiêu của Sui là khả năng mở rộng ngang. Nếu phân bổ một lượng phần cứng nhất định, bạn đạt được một lượng thông lượng nhất định. Nếu cần thêm thông lượng, các nút xác thực có thể thêm nhiều phần cứng hơn, không có giới hạn. Đây là cách mọi dịch vụ Web2 hoạt động. Ý tôi là, bạn phải giải quyết một số ràng buộc kỹ thuật, điều này không chắc chắn hay đơn giản, nhưng mọi người khi thiết kế dịch vụ Web có thể mở rộng đều mong muốn đạt được khả năng mở rộng ngang.
Nếu Sui có thêm khách hàng hoặc người dùng, mục tiêu của chúng tôi là Sui có thể tiếp tục phát triển, mọi thứ vẫn hoạt động bình thường. Tất nhiên, đồng thời duy trì độ trễ rất thấp. Bạn không muốn tăng thông lượng nhưng lại đánh đổi bằng độ trễ.
Trong hệ thống Libra, những đặc tính này không được xem xét. Nó chỉ là một hệ thống thanh toán quy mô nhỏ, với vài trăm nhà vận hành thanh toán, mỗi ngày có thể vài chục triệu giao dịch, nhưng cũng không hơn thế. Vì vậy, chúng tôi dùng kiến trúc hộp đơn, đơn giản và đủ dùng. Nhưng trên Sui, chúng tôi biết hệ thống Libra không thể hoạt động, vì nó thiếu khả năng mở rộng ngang. Vì vậy, chúng tôi nghĩ: làm sao để thiết kế một hệ thống từ đầu có thể đạt được điều này? Đó là nguồn gốc của mô hình dữ liệu hướng đối tượng. Chúng tôi về cơ bản loại bỏ mô hình dữ liệu dựa trên tài khoản cũ, vì nó khiến việc đạt được khả năng mở rộng ngang trở nên cực kỳ khó khăn. Thay vào đó, nếu bạn tổ chức mọi thứ thành các đối tượng, trạng thái toàn cục chỉ là một ánh xạ lớn từ ID đối tượng đến đối tượng. Đây là một kho lưu trữ cặp khóa-giá trị, và chúng tôi biết cách mở rộng kho lưu trữ này – đó là một bài toán kỹ thuật đơn giản.
Sau đó, vấn đề là: làm sao thiết kế cấu trúc giao dịch để phù hợp với quá trình lấy và cập nhật dữ liệu từ kho lưu trữ khóa-giá trị? Làm sao phân mảnh kho lưu trữ khóa-giá trị? Quyết định giao dịch nên được xử lý ở đâu? Về cơ bản, đó là nguồn gốc của nó. Chúng tôi biết cách mở rộng những thứ này. Làm sao biến nó thành thứ có thuộc tính blockchain, đọc có thể xác minh, có thể hợp tác với Move, v.v. Rồi làm sao kết hợp chúng một cách mượt mà nhất có thể.
08. Trên tầm cao hơn, anh sẽ nói chuyện với các nhà phát triển Web2 nghi ngờ về tiềm năng của công nghệ phi tập trung như thế nào?
Theo tôi, blockchain và tiền mã hóa về bản chất là một công nghệ loại bỏ ma sát. Có những rào cản khiến việc thực hiện giao dịch tài chính, xây dựng ứng dụng hay thiết lập thông tin trở nên rất khó khăn, vì thông tin không thể vượt qua các rào cản này, hoặc nếu có, cần sự giúp đỡ của bên thứ ba, và bên thứ ba đó thu phí để cung cấp dịch vụ.
Một ví dụ kinh điển mà mọi người hay dùng là mua nhà. Có người mua và người bán, nhưng khi thực hiện thanh toán, phải có một đại lý escrow – người chỉ ngồi đó giữ tiền, vì người mua và người bán không hoàn toàn tin tưởng lẫn nhau. Đó là thực tế cuộc sống. Chúng ta phải chấp nhận điều đó. Nhưng nếu đại lý escrow có thể là một đoạn mã mà cả hai bên đều có thể kiểm tra, hoặc đã được một bên thứ ba xác minh, thì nó có thể hoàn thành công việc miễn phí hoặc với phí thấp hơn. Mục đích của blockchain không phải là loại bỏ đại lý escrow trong bất động sản. Đây chỉ là một trường hợp sử dụng, nhưng thường thì mọi thứ đều như vậy.
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à B, mà cả hai được xây dựng trên cùng một nền tảng, bạn có thể làm cho mọi thứ chảy từ ứng dụng này sang ứng dụng khác, dù là vật phẩm trong ứng dụng, dữ liệu, khuyến mãi chéo, hay sản phẩm bên thứ ba xây dựng trên cả hai. Hoặc hãy tưởng tượng Internet, các trang web chia sẻ dữ liệu qua cookie, nhưng những cookie này chỉ là siêu dữ liệu chỉ đọc. Nếu những cookie đó có thể trở thành tiền tệ thì sao? Hoặc có thể trở thành vật phẩm có thể tiêu dùng? Hoặc trở thành chương trình khách hàng thân thiết và phiếu giảm giá? Mọi thứ đều được tích hợp sẵn chức năng này. Rất trừu tượng, nhưng đó là tiềm năng. Thường thì một người đang xây dựng sẽ coi đây là những siêu năng lực mới để tạo ra thứ hấp dẫn hơn.
09. Đối với người dùng cuối, ngay cả khi họ không có kiến thức kỹ thuật, khi họ nghĩ đến việc tin tưởng vào mã nguồn, anh có cảm thấy họ do dự không, dù lựa chọn thay thế là một thực thể trung tâm lớn và mờ ám?
Tôi không nghĩ vậy. Vì chúng ta làm điều này mỗi ngày, đúng không? Khi tôi đăng nhập email, tôi không lo ngại mã sẽ xóa một bức thư nào đó của tôi, hay khi tôi gửi thư, nó thực sự không gửi đi. Nếu điều đó xảy ra, tôi có thể ngừng dùng email hoặc chuyển sang nhà cung cấp khác. Tôi nghĩ điều này rất giống nhau. Dĩ nhiên, không phải ai cũng có thể thực sự đọc và kiểm tra cách một thứ hoạt động.
Hơn nữa, nếu tôi muốn kiểm tra mã nguồn email, tôi không thể, vì mã đó không có sẵn. Vì vậy, tính minh bạch là một khía cạnh quan trọng. Mặc dù không phải ai cũng làm được, nhưng một số người có thể kiểm tra mẫu. Và, kết hợp với việc tái sử dụng liên tục, cùng với tính bất biến. Đó mới là then chốt ở đây. Khi tôi đăng nhập email, tôi không biết mã có thay đổi kể từ lần cuối tôi làm gì đó hay không. Không có minh bạch về điều này. Nhưng trong Web3, bạn có thể biết được, còn ở những nơi khác thì không.
10. Anh kỳ vọng gì về sự phát triển của Sui Move trong tương lai?
Nhiều tính năng mà chúng tôi đang tập trung hiện tại dựa trên kinh nghiệm với các nhà phát triển đã phát hành đợt đầu tiên các gói Sui Move, sau đó quan sát họ muốn phát triển các tính năng này như thế nào, tính năng nào dễ phát triển, tính năng nào khó. Sui Move là một ngôn ngữ rất phù hợp để phát hành gói lần đầu, nhưng khi tôi muốn thay đổi kiểu này, thêm một số trường, thêm một số hàm, và thực hiện điều đó theo cách mạch lạc nhưng không làm mất niềm tin của người dùng gói ban đầu, thì đây trở thành một vấn đề rất thách thức. Phần lớn công việc của chúng tôi là nghiên cứu điều này, 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, vừa mang lại sự linh hoạt mở rộng cho lập trình viên, vừa duy trì niềm tin của người dùng mã ban đầu.
Chúng tôi đang nghiên cứu nhiều tính năng liên quan, đặc biệt là kiểu liệt kê (enumeration types). 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ã phía trước (frontend). Chúng tôi thường đùa rằng một ứng dụng Sui điển hình gồm 5% mã Move và 95% mã frontend. Vì vậy, chúng tôi rất chú trọng vào 95% đó. Chúng tôi dành nhiều thời gian bàn về Move, nhưng cũng rất quan tâm đến việc làm cho phần còn lại hiệu quả hơn và kết nối dễ dàng hơn. Tổng thể, chúng tôi rất chú trọng vào việc làm sao để ứng dụng có nhiều thành phần hơn do Move đảm nhiệm, để tăng tính an toàn. Đồng thời, làm sao để 95% mã đó dễ hiểu đối với cả lập trình viên Move và không phải Move.
Chào mừng tham gia cộng đồng chính thức TechFlow
Nhóm Telegram:https://t.me/TechFlowDaily
Tài khoản Twitter chính thức:https://x.com/TechFlowPost
Tài khoản Twitter tiếng Anh:https://x.com/BlockFlow_News
Sui Network
