Phỏng vấn cha đẻ ngôn ngữ Move bởi a16z: Từ ngôn ngữ lập trình đến việc vì sao Move là hướng đi quan trọng cho hợp đồng thông minh trong tương lai?
Tuyển chọn TechFlowTuyển chọn TechFlow
Phỏng vấn cha đẻ ngôn ngữ Move bởi a16z: Từ ngôn ngữ lập trình đến việc vì sao Move là hướng đi quan trọng cho hợp đồng thông minh trong tương lai?
Năm ngoái, hàng loạt tổ chức như a16z hết lời ca ngợi các blockchain công cộng Move đại diện bởi Sui, khiến ngôn ngữ Move trở lại mạnh mẽ trên đống tro tàn của Meta Diem.
Chuyên sâu báo cáo Web3Biên dịch: Sui World
Năm ngoái, các tổ chức như a16z đã hết lời ca ngợi các blockchain công khai sử dụng ngôn ngữ Move đại diện là Sui, khiến ngôn ngữ Move trở nên nổi bật trở lại từ đống tro tàn của Meta Diem; đồng thời, kể từ thời điểm ra đời của Sui Move, luôn tồn tại những luồng ý kiến không mấy lạc quan:
Nếu chỉ vì ngôn ngữ Move có thể ưu việt hơn Solidity hoặc các ngôn ngữ phát triển khác, liệu chúng ta thực sự cần một ngôn ngữ hợp đồng thông minh mới và miệt mài xây dựng lại Layer1 từ đầu?
Gần đây, đội ngũ a16z Crypto đã có buổi trò chuyện podcast với Sam Blackshear – đồng sáng lập và CTO của MystenLabs, cha đẻ của ngôn ngữ Move, với chủ đề “Ngôn ngữ Lập trình & Tiền mã hóa”, thảo luận về lý do vì sao Move là định hướng quan trọng cho tương lai của hợp đồng thông minh.
Trong buổi podcast này, a16z Crypto cùng Sam Blackshear đã thảo luận sâu rộng về triết lý thiết kế của ngôn ngữ Move, lập trình hướng đối tượng và tài sản, tính bảo mật, cũng như chia sẻ về kiểm chứng hình thức, quản trị và công cụ cộng đồng, khả năng thích ứng đa nền tảng… từ những điểm tương đồng và khác biệt giữa lập trình truyền thống và lập trình hợp đồng thông minh, đến tranh luận về những giới hạn và cơ hội độc đáo của blockchain.
Nội dung chính gồm:
1. Lịch sử ngôn ngữ lập trình và hợp đồng thông minh
Từ lập trình truyền thống, đến lập trình hợp đồng thông minh, rồi đến lập trình Move. Move là minh chứng sớm nhất cho việc thiết kế ngôn ngữ phù hợp với hệ thống kiểu, kiểu tĩnh và kiểm tra thời gian biên dịch.
2. Đổi mới trong hợp đồng thông minh Move
EVM quá mức gắn chặt với chi tiết triển khai nền tảng, vốn được thiết kế riêng cho Ethereum. Các nhà phát triển cuối cùng phải thừa hưởng nhiều quyết định thiết kế từ Ethereum, bao gồm cả những sai lầm khiến Ethereum khó mở rộng.
Khi thiết kế Move, không có bất kỳ yếu tố đặc thù blockchain nào được đưa vào ngôn ngữ cốt lõi. Đổi mới ở cấp độ ngôn ngữ nguồn sẽ rất quan trọng, Move cuối cùng có thể cung cấp bộ xác minh mã và lớp bảo vệ ở cấp VM để ngăn chặn các cuộc tấn công từ lập trình viên khác.
3. Triết lý thiết kế Sui Move
Move là một ngôn ngữ bytecode có thể thực thi dùng để thực hiện giao dịch người dùng và hợp đồng thông minh. Trong Sui Move, các validator có thể song song hóa hiệu quả hơn, giúp việc lưu trữ và thực thi dễ dàng hơn mà không cần mã hóa những thứ này vào cấp độ giao thức và bắt người dùng, lập trình viên phải cân nhắc.
4. Bảo mật
Trong thế giới hợp đồng thông minh, chúng ta đang ở trạng thái bị ràng buộc. Chúng ta viết một lượng mã rất nhỏ nhưng phải hoàn hảo tuyệt đối, bảo mật phải là yếu tố hàng đầu cần cân nhắc. Bảo mật Move vừa nhằm ngăn lập trình viên tự gây lỗi, vừa cố gắng cung cấp nguyên thủy đúng đắn để họ có thể phòng thủ trước các cuộc tấn công.
5. Hướng đối tượng và tài sản
Move được thiết kế như một ngôn ngữ lập trình hợp đồng thông minh hướng đối tượng và tài sản, bởi vì phần lớn các ngôn ngữ lập trình Web2 hướng đối tượng đều như vậy. Trong Sui Move, việc đặt trọng tâm vào các đối tượng khuyến khích biểu diễn truy cập chi tiết một cách chính xác nhất có thể. Cấu trúc lưu trữ toàn cục của Sui Move là ánh xạ từ ID đối tượng tới đối tượng.
6. So sánh bảo mật
Move loại bỏ qua cấu trúc các vấn đề về gọi đệ quy (re-entrancy) và kiểm tra quyền trong lập trình hợp đồng thông minh. Thông tin sở hữu đối tượng thực tế được lưu trong metadata đối tượng, chứ không phải thứ mà lập trình viên có thể kiểm soát. Move Prover được thiết kế để tránh lỗi khi viết hợp đồng thông minh bằng ngôn ngữ, giúp lập trình viên tránh được nhiều lỗi cơ bản.
7. Quản trị ngôn ngữ hợp đồng thông minh
Ban đầu, Move được phát triển tại Facebook, không có quản trị thực sự. Chúng tôi thận trọng mở rộng ngôn ngữ. Tính đơn giản là yếu tố chủ đạo, nhưng chúng tôi sẽ tích cực mở rộng nó. Sam Blackshear có một mong muốn rất rõ ràng, ví dụ như Move được thiết kế như một ngôn ngữ đa nền tảng, nơi các chức năng cơ bản của EDM chuỗi vẫn áp dụng được, bao phủ cả chuyên gia phát triển hợp đồng thông minh lẫn người mới Web2, cực kỳ linh hoạt.
8. Lời khuyên học tập dành cho lập trình viên
Hãy đọc thật nhiều mã nguồn, đó là cách tốt nhất để hiểu ngôn ngữ. Hãy sẵn sàng chia sẻ, thảo luận sâu sắc, và tìm kiếm những người thực sự thích chia sẻ mã nguồn của bạn, cùng xây dựng cộng đồng mã nguồn mở. Bất kỳ công cụ nào giúp công việc của bạn nhẹ nhàng hơn, bạn đều nên học cách nó vận hành.
Dưới đây là toàn văn podcast, khoảng 25.000 chữ, thời gian đọc khoảng 30 phút.
Giới thiệu của người dẫn Sonal Chokshi
Chào mừng bạn đến với Web 3.0, chương trình do đội ngũ a16z Crypto sản xuất về việc xây dựng thế hệ internet tiếp theo. Tôi là người dẫn chương trình Sonal Chokshi.
Chương trình này nhằm hỗ trợ bất kỳ ai muốn tìm hiểu và đào sâu vào các vấn đề liên quan đến tiền mã hóa và Web 3.0, dù là nhà phát triển, người sáng tạo nội dung, kiến trúc sư, lãnh đạo doanh nghiệp hay người hoạch định chính sách. Chúng tôi bắt đầu mùa mới của chương trình. Tập hôm nay tập trung vào ngôn ngữ lập trình và tiền mã hóa, phù hợp với cả lập trình viên hợp đồng thông minh hiện tại và các nhà phát triển muốn bước chân vào lĩnh vực này. Đây cũng là lựa chọn tuyệt vời cho những ai tò mò về sự tiến hóa và xuất hiện của các ngôn ngữ lập trình.
Khách mời đặc biệt hôm nay là Sam Blackshear, đồng sáng lập và CTO của MystenLabs, công ty đang đặt nền móng cho tương lai phi tập trung Web 3.0. Sam có bề dày kinh nghiệm trong lĩnh vực ngôn ngữ lập trình, từ luận án tiến sĩ đến làm việc tại Facebook, rồi sáng tạo và trở thành tác giả của Move và một ngôn ngữ lập trình mã nguồn mở dùng để xây dựng hợp đồng thông minh. Chúng ta sẽ nói thêm về điều này.
Trong suốt chương trình, chúng tôi cũng mời Noah, kỹ sư nghiên cứu hợp đồng thông minh của a16z Crypto, gần đây anh và cộng sự đã phát triển Helios – một client nhẹ cho Ethereum và giành chiến thắng trong thách thức tối ưu gas.
Chúng tôi cũng mời Eddy Lazzarin, trưởng nhóm kỹ sư của a16z Crypto, trước đó Eddy làm kỹ sư phần mềm tại Netflix và làm kỹ sư dữ liệu và khoa học dữ liệu tại Facebook. Cần nhắc lại rằng, nội dung sau đây không cấu thành lời khuyên đầu tư, kinh doanh, pháp lý hay thuế.
1. Lịch sử lập trình và hợp đồng thông minh
Người dẫn Sonal Chokshi:
Chúng ta sẽ bắt đầu từ lịch sử lập trình truyền thống, người phát biểu đầu tiên là Noah, tiếp theo là Sam Blackshear và Eddy.
a16z Crypto Noah:
Chúng tôi muốn tìm hiểu lịch sử lập trình ảnh hưởng thế nào đến lịch sử lập trình hợp đồng thông minh, vì tôi cảm thấy có ba thứ: lập trình truyền thống, lập trình hợp đồng thông minh, và ngôn ngữ Move. Ba thứ này đều có lịch sử riêng của chúng, đúng không?
Sui CTO Sam Blackshear:
Đúng vậy, tôi thích khung nhìn này. Mọi người dùng ngôn ngữ để thiết kế cú pháp hoặc khiến người dùng cảm thấy vui vẻ, điều đó đúng, nhưng không chỉ dừng lại ở đó. Vì vậy tôi rất thích cách nhìn tổng quát này.
a16z Crypto Eddy Lazzarin:
Dựa trên điều đó, lập trình truyền thống đã trải qua nhiều xu hướng trong hai, ba thập kỷ qua. Ngôn ngữ lập trình truyền thống đã thay đổi, có những chủ đề nóng lên rồi hạ nhiệt. Từng có một thời gian dài, các ngôn ngữ lập trình động và kiểm tra kiểu rất lỏng lẻo rất được ưa chuộng. Người ta thường cho rằng, cứ nhảy vào, quên đi kiểu dữ liệu, quên mọi chi tiết kỹ thuật, chỉ cần viết mã là cách thuận tiện hơn.
Sui CTO Sam Blackshear:
Nhưng gần đây, mọi người bắt đầu suy nghĩ sâu hơn về hệ thống kiểu, kiểu tĩnh và kiểm tra thời gian biên dịch, nhằm hiểu càng nhiều chi tiết về chương trình trước khi nó chạy. Những xu hướng này liên tục thay đổi. Tuy nhiên, đối với lập trình hợp đồng thông minh, do nó quá mới mẻ, chúng ta chưa thấy lịch sử kiểu này trong lập trình hợp đồng thông minh, điều này rất khác biệt.
Tôi cho rằng Move là minh chứng sớm nhất cho việc thiết kế ngôn ngữ phù hợp với các vấn đề này (hệ thống kiểu, kiểu tĩnh, kiểm tra thời gian biên dịch). Tôi rất muốn biết chúng ta kỳ vọng điều gì sẽ thay đổi, ví dụ như tĩnh và động kiểu – những chủ đề có thể xuất hiện trong lập trình hợp đồng thông minh? Những chủ đề này có thể chưa xuất hiện vì hiện tại chỉ có một ngôn ngữ duy nhất là Solidity.
Người dẫn Sonal Chokshi: Vậy điều này liên hệ thế nào đến việc chuyển sang lập trình hợp đồng thông minh? Xin mời Sam trả lời tiếp?
Sui CTO Sam Blackshear:
Trong không gian hợp đồng thông minh, với EVM là người tiên phong đầu tiên, có những xu hướng khác nhau. Mọi người không biết nên dùng hợp đồng thông minh để làm gì? Làm sao để viết chúng hay bất kỳ điều gì liên quan đến kiểu dữ liệu. Vì vậy, tôi cho rằng tính linh hoạt quan trọng hơn, để thử nghiệm và khám phá các chuyên gia về trường hợp sử dụng. Tôi cảm giác giờ đây chúng ta đã biết, hoặc ít nhất là hiểu được các khối xây dựng.
Xu hướng hợp đồng thông minh là cực kỳ đặc thù lĩnh vực, bạn định nghĩa mẫu cho tài sản, định nghĩa chiến lược chuyển tài sản, kiểm tra quyền truy cập và phân quyền.
Đây là điều cơ bản, bạn sẽ không dùng ngôn ngữ hợp đồng thông minh để viết trình biên dịch hay hệ điều hành hay bất kỳ điều gì tương tự. Vì vậy, chúng rất tốt, lợi thế của chúng so với ngôn ngữ lập trình phổ thông là rất rõ rệt.
Tôi cho rằng mọi người đánh giá thấp việc tiêu chuẩn ERC-20 xảy ra rất lâu sau khi EVM có thể lập trình, EVM thậm chí được coi là một trong những khối xây dựng cơ bản để viết chương trình Ethereum. Tôi chỉ không thấy bằng chứng rõ ràng nào cho thấy những điều cơ bản nhất trước đó là rõ ràng.
Vì vậy bạn nói đúng, giờ bạn có thể coi kiểu dữ liệu là điều hiển nhiên. Tôi nghĩ việc bỏ qua kiểu dữ liệu và những thứ tương tự là chấp nhận được nợ kỹ thuật. Nếu quy mô nhỏ, bạn chỉ muốn di chuyển nhanh và mã có thể vứt đi, thì nợ kỹ thuật này hoàn toàn chấp nhận được. Nhưng điều thú vị là, nếu mô tả nó ở quy mô công ty hay startup, công ty nhỏ đang phát triển nhanh, mọi người đều hiểu toàn bộ mã nguồn, thì nợ kỹ thuật này có thể chịu đựng được.
Tuy nhiên, khi nó rất, rất lớn, có rất nhiều người thay đổi mã, họ không biết hậu quả của các đối tượng và hệ thống mới đang xây dựng. Việc đưa nó vào hệ thống kiểu khiến bạn gặp trở ngại khi viết mã theo cách rõ ràng, trực tiếp, thay vì vô tình tạo ra hàng rào kính mà sau này ai đó sẽ va phải.
Ví dụ, như các bạn đã nói, có thể ngăn sao chép, có thể thiết lập nguồn cung tối đa cho tài sản. Những ràng buộc này rất quan trọng, cần duy trì ở mọi quy mô dự án. Chúng là những ràng buộc rất quan trọng để duy trì tính lành mạnh và an toàn cho dự án. Hiểu được những giới hạn này có nghĩa là bạn giờ có thể tạo ra ngôn ngữ lập trình để buộc chúng thực thi. Đó là cách tôi nhìn nhận ngôn ngữ Move.
Khi chúng ta hiểu được loại ràng buộc cần thiết để làm đúng, giờ chúng ta có khả năng đưa chúng vào chính ngôn ngữ. Vì vậy, tôi thực sự nghĩ nó giống với kiểu dữ liệu như bạn đã nói.
Bạn nói kiểu dữ liệu rất quan trọng đối với tính lành mạnh và an toàn của chương trình. Các bạn nói kiểu động có thể phù hợp với dự án nhỏ, nhưng khi dự án phát triển, nên dùng kiểu tĩnh. Tôi hơi không đồng ý, tôi nghĩ kiểu tĩnh hoàn toàn có thể phù hợp hơn. Có thể đây là quan điểm mới lạ. Nó là vì sự lành mạnh của lập trình viên. Điều đáng sợ nhất tôi từng thấy là khi nhấn phím tắt "control k", nó cho tôi biết chữ ký hàm là gì. Khi viết Python, điều này khiến tôi sợ hãi. Tôi nhìn vào chữ ký hàm, chỉ thấy tên các tham số. Tôi tự hỏi, bạn thực sự muốn tôi làm gì?
a16z Noah: Tôi không thể tin được mọi người chấp nhận cách viết mã xong rồi chẳng bao giờ nhìn lại.
a16z Eddy Lazzarin: Họ chấp nhận giả định mặc định là họ có thể ghi nhớ yêu cầu của hệ thống trong đầu.
a16z Noah: Nhưng ngay cả với chương trình 100 dòng, tôi cũng cảm thấy không thể mặc định điều này.
Sam Blackshear: Nó có thể chạy, nhưng không hoàn hảo.
a16z Eddy Lazzarin:
Tôi cho rằng các bạn nói đúng. Và tôi nghĩ tâm lý này đã phát triển. Trước đây, hệ thống kiểu được dùng để bảo vệ lập trình viên khỏi đồng nghiệp. Khi startup của bạn trở nên quá lớn, nó trở nên hữu ích. Nhưng giờ nó giống như đang bảo vệ chính tôi.
Trong bối cảnh hợp đồng thông minh, nó đang bảo vệ tôi khỏi kẻ tấn công. Đây là điểm khác biệt thực sự, vì trong chương trình thông thường, bạn sẽ không triển khai chương trình khi kẻ tấn công bị ràng buộc bởi hệ thống kiểu. Kẻ tấn công có thể dùng ngôn ngữ khác để viết mã máy. Bạn chỉ cần bảo vệ bức tường lửa của mình. Nhưng ở đây, tôi viết đối tượng kiểu dữ liệu đẹp đẽ này, nó sẽ chảy vào mã của kẻ tấn công và giữ nguyên tính toàn vẹn. Hệ thống kiểu phải đảm bảo an toàn cho tôi.
Như bạn đã nói, đó là công cụ tuyệt vời, mang lại nhu cầu khác biệt, bạn cần buộc chúng thực thi, ví dụ như ngăn sao chép. Đây không phải là điều bạn cần cân nhắc trong hệ thống kiểu thông thường, hoặc ngăn xóa, đảm bảo bạn sử dụng hoặc hủy một giá trị theo cách nào đó. Tất cả những điều này là vì chúng ta đang nghiên cứu hợp đồng thông minh và cố gắng cung cấp hệ thống kiểu có ý nghĩa cho các trường hợp sử dụng này, vì vậy cuối cùng chúng ta đưa những thứ này vào move, và có thể vào các ngôn ngữ hợp đồng thông minh tương lai.
Người dẫn Sonal Chokshi:
Thực ra, các bạn, hãy nói thêm về những khác biệt khác giữa lập trình truyền thống và lập trình hợp đồng thông minh. Nhưng trước khi đi sâu hơn, các bạn có thể nhanh chóng giới thiệu các ngôn ngữ mà lập trình viên hợp đồng thông minh có thể sử dụng không? Tôi nghĩ chúng ta cần hiểu tổng quan, vì tôi muốn nắm bắt hiện trạng, ví dụ như Solidity, Viper... Biết được nội dung nào sẽ giúp chúng ta nhập môn nhanh hơn.
Sui CTO Sam Blackshear:
Vâng, tôi nghĩ tình hình cơ bản là, nếu bạn muốn viết hợp đồng thông minh, bạn hầu như luôn dùng solidity. Trừ khi bạn tình cờ nằm trong một vài hệ sinh thái nhỏ khác.
Nếu bạn ở hệ sinh thái Polkadot, bạn dùng ink! (Sui World chú thích: ink! là ngôn ngữ hợp đồng thông minh do Parity phát triển, dùng để viết hợp đồng thông minh bằng Rust và biên dịch thành mã Wasm), nó là một ngôn ngữ lập trình hiện có. Nếu bạn ở hệ sinh thái StarkNet, bạn dùng Cairo (Sui World chú thích: Cairo là một trong các ngôn ngữ lập trình của hệ thống chứng minh STARK).
Nhưng phần lớn, nếu tôi phải đưa ra lời khuyên, để học cách viết hợp đồng thông minh, tôi sẽ khuyên bạn học một chút Solidity, rồi học EVM. Bạn cũng có thể muốn dùng Viper, nhược điểm duy nhất là Viper mới hơn, có thể dễ bị lỗi hơn. Tôi nhớ vài năm trước, khi xác minh hợp đồng gửi tiền, họ phát hiện một loạt lỗi trong trình biên dịch Viper. Người phát hiện lỗi này giờ làm việc tại 16z, anh ấy là Day June, một chuyên gia kiểm chứng hình thức.
Vì Day June là chuyên gia kiểm chứng hình thức, nên giờ làm việc tại a16z. Và thực tế là, bạn cần học một cái gì đó, cần học một ngôn ngữ.
Bạn thậm chí cần hiểu sâu về EVM,nếu muốn trở thành một kỹ sư hợp đồng thông minh thực sự xuất sắc, bạn cần hiểu EVM ở mức độ hoang đường,đến mức có thể nói ra chi phí gas của từng thao tác, họ có thể nói chính xác mã liên quan đến chi phí gas. Đó là thế giới chúng ta đang sống hiện tại.
a16z Eddy Lazzarin: Có lẽ cần nói thêm một điều, với tư cách kỹ sư phần mềm, bạn luôn có thể tìm hiểu máy đang chạy mã của mình. Có rất nhiều kiến thức cần biết về môi trường lập trình. Nhưng trong lập trình hợp đồng thông minh, môi trường rất phong phú, rất phức tạp. Có rất nhiều ngữ cảnh cần hiểu, điều này gần như không liên quan đến chính ngôn ngữ. Đó là những gì đang xảy ra xung quanh bạn, xung quanh có những đối tượng nào, các mã khác được gọi thế nào. Đây là điều rất kỳ lạ.
Người dẫn Sonal Chokshi: Vậy người gần nhất với việc học Solidity là người biết JavaScript, điều này đúng không?
Sui CTO Sam Blackshear: Mọi người đều nói là JavaScript, vì nó dùng từ khóa "function", giống như JavaScript cũng dùng. Nhưng tiếc là, chúng không thực sự giống nhau.
a16z Eddy Lazzarin: Về mặt cú pháp, Solidity thực sự kế thừa nhiều đặc điểm từ JavaScript. Nếu bạn nheo mắt hoặc đang buồn bực, có thể thấy giống, nhưng thực tế hoàn toàn khác biệt. Môi trường máy ảo khác biệt lớn, nên điểm chung rất ít.
Người dẫn Sonal Chokshi: Có ngôn ngữ lập trình nào tương tự không?
a16z Noah: Vâng, tôi nghĩ không có ngôn ngữ lập trình nào tương tự trực tiếp. Nếu bạn quen với Was (Sui World chú thích: WebAssembly Studio, công cụ trực tuyến để biên dịch mã C/C++ và Rust thành định dạng WASM), và cố gắng viết mã trong môi trường đòi hỏi cách ly cao độ (ví dụ Surplus), đây có thể là điều gần nhất, mã này thực thi độc lập nhưng cần một mức độ giao tiếp nhất định. Nhưng nó vẫn không thực sự giống, cách tư duy hoàn toàn khác biệt, sự giống nhau bề ngoài có thể nguy hiểm.
a16z Eddy Lazzarin: Có lẽ liên quan đến một số sai lầm lớn trong lịch sử ngôn ngữ lập trình. Tôi không biết trong blockchain có những con đường sai lầm nghiêm trọng nào không. Chúng ta có đi những con đường tồi tệ nào không?
Người dẫn Sonal Chokshi: Đây là câu hỏi hay.
Sui CTO Sam Blackshear:
Đây là câu hỏi hay. Năm 1977, C ra đời, cũng là năm Standard ML ra đời. Standard ML có ảnh hưởng lớn. Hiện nay, các ngôn ngữ OCaml, Rust đều chịu ảnh hưởng lớn từ nó, Move cũng vậy. Nhưng những tư tưởng này đã tồn tại rất lâu. Tôi nghĩ nhiều người đang suy nghĩ về một tương lai thay thế, nơi C không trở thành chủ lưu, mà tư tưởng Standard ML được chấp nhận rộng rãi, như kiểu mạnh, an toàn nội tại.
Người dẫn Sonal Chokshi: Vậy xu hướng phát triển công nghệ máy tính là gì? Tôi không nói đây là sai lầm, nhưng tôi nghĩ ngôn ngữ như Standard ML dù ngày nay trông vẫn rất hiện đại. Hình dung về vũ trụ thay thế này là điều thú vị, tôi đã bị sốc khi lần đầu phát hiện.
a16z Eddy Lazzarin: Tò mò, tại sao bạn nghĩ các ngôn ngữ như C và tương tự, chúng quá thẳng thắn, quá mệnh lệnh? Chúng suy nghĩ về máy tính ở mức độ thấp, như ngôn ngữ lập trình chúng không làm được nhiều điều, đó là quan điểm của tôi về C, tại sao chúng ta đi con đường này?
Sui CTO Sam Blackshear:
Tôi nghĩ giới hạn phần cứng thời đó buộc bạn dùng C, nếu muốn viết chương trình hiệu quả hoặc đẩy ranh giới máy tính. Tôi nghĩ nếu bạn thúc đẩy phần cứng, bạn sẽ chọn con đường khác. Nhưng tôi nghĩ lập trình hàm rất khó, nó phản trực giác ở nhiều phương diện. Tôi không nói C không khó, nhưng tôi thấy nó dễ tiếp cận hơn. Sau đó bạn nhận ra, mình đã làm điều rất phức tạp, hoặc rất khó suy luận, nhưng đã quá muộn. Đây là điểm hay, ngôn ngữ hàm thực sự có độ dốc học tập dốc hơn, nhưng một khi nắm được, bạn nhận ra, tôi có thể suy nghĩ độc lập về mã của mình rất tốt, mọi thứ giải quyết ổn thỏa.
a16z Eddy Lazzarin: Tôi nghĩ nếu bạn suy nghĩ nhiều về cách máy tính hoạt động ở cấp độ phần cứng, thì các ngôn ngữ như C trực tiếp hơn. Nhưng nếu bạn không hiểu nhiều về ngôn ngữ lập trình, thì C dễ tiếp cận hơn. Nhưng nếu bạn hiểu rất rõ về ngôn ngữ lập trình, thì tôi nghĩ các ngôn ngữ như ML và lập trình hàm có nhiều điều thú vị để khám phá.
Sui CTO Sam Blackshear:
Đây là câu trả lời tầm nhìn rộng. Nhưng tôi muốn nói về vấn đề "sai lầm ngôn ngữ máy tính" quy mô nhỏ.
a16z Noah:
Vì vậy, tôi hơi do dự về điều này, vì tôi luôn nghe nói lập trình hàm tuyệt vời thế nào, nhưng tôi thấy hơi khó hiểu. Nhưng câu hỏi tôi luôn tự hỏi là, nếu lập trình hàm thực sự tốt như vậy, tại sao nó chưa thể vượt qua hiệu ứng mạng lưới của các ngôn ngữ lập trình hiện tại? Tình trạng này khiến tôi ngạc nhiên.
Nhưng tôi muốn bổ sung một điểm, tôi nghĩ đóng góp lớn mà lập trình hàm mang lại là, tất cả các ngôn ngữ mệnh lệnh chúng ta dùng đều mượn từ đó. Nhưng điều hay nhất là, như bạn vừa nói, Rust chịu ảnh hưởng lớn từ email chuẩn, nhưng Rust về cơ bản là ngôn ngữ mệnh lệnh, đúng không? Nhưng nó có tất cả những bùa phép tuyệt vời từ việc nhìn ngắm họ.
Sui CTO Sam Blackshear:
Tổng thể, tôi nghĩ vấn đề thực sự là, kể từ năm 1977, ảnh hưởng của ngôn ngữ mệnh lệnh quá lớn. Sau đó là PRFP, như bạn nói, nó không tuyệt vời nhất, nó có những ý tưởng vĩ đại riêng, xét riêng lẻ, mỗi người đều có vấn đề riêng. Giờ chúng ta chỉ thấy những đứa con lai thực sự như Rust kết hợp đẹp đẽ với chúng. Nó thực sự thay đổi cảnh quan.
Vì vậy tôi muốn nói một điều, đó là Tony Hoare gọi tham chiếu null là sai lầm trị giá mười tỷ đô. Dù lúc đó ông có thể đang phóng đại, rõ ràng chi phí của sai lầm này đắt hơn nhiều so với việc không mắc sai lầm.
a16z Eddy Lazzarin: Không, đây có thể chỉ là mức đáy.
2. Đổi mới trong phát triển hợp đồng thông minh
a16z Noah: Thực ra tôi rất tò mò bạn chưa nói nhiều về sự đổi mới ở cấp độ máy ảo và cấp độ ngôn ngữ lập trình, cũng như cách chúng ảnh hưởng đến sự phát triển của hợp đồng thông minh.
Sui CTO Sam Blackshear:
Đây là câu hỏi hay. Tôi nghĩ mọi người chưa cân nhắc đầy đủ sự khác biệt này, ví dụ như khác biệt giữa cấp độ máy ảo và cấp độ ngôn ngữ lập trình. Thực tế, ngoài EVM và các máy ảo mới, còn có nhiều đổi mới, ví dụ như các ngôn ngữ nguồn như Viper. Những thứ này theo nhiều phương diện tốt hơn Solidity, rất thú vị.
Tôi nghĩ, nếu Move có thể trở thành tiêu chuẩn pháp lý cho Web 3.0 như mong đợi, thì đổi mới ở cấp độ máy ảo sẽ chậm và dần dần. Bởi vì cốt lõi là cố định, chúng ta chỉ thêm mới mà không thiết kế lại hoàn toàn.
Tuy nhiên, tôi nghĩ đổi mới ở cấp độ ngôn ngữ nguồn sẽ rất quan trọng. Hiện tại, chúng ta chỉ có một ngôn ngữ nguồn, nhưng nó gắn chặt với định dạng bytecode. Nhưng khi ngày càng nhiều khách hàng dùng hợp đồng thông minh và nhấn mạnh an toàn, tôi hình dung sẽ có nhiều ngôn ngữ nguồn khác nhau để thử nghiệm, đây là lĩnh vực nghiên cứu thú vị. Có thể bạn có thể viết thực tế trước của bạn, rồi chương trình tổng hợp thông tin cho bạn, hoặc đề xuất giới hạn.
Có thể bạn bắt đầu bằng việc viết thực tế Move trước của bạn, rồi chương trình tổng hợp điền mã cho bạn, hoặc đề xuất giới hạn.
Ví dụ, bạn có thể viết Move trong bối cảnh trò chơi rất cụ thể, trông giống cấu trúc cảnh. Có thể nó được viết bằng thư viện Python, nhưng biên dịch thành bytecode Move. Có thể bạn đang cân nhắc tích hợp Move như Solana hay nền tảng khác, nhưng không muốn tích hợp máy ảo, mà bằng cách biên dịch bytecode Move thành định dạng bytecode Salina, rồi dùng ngôn ngữ nguồn Move ở cấp độ lập trình viên.
Tôi nghĩ có nhiều cách khác nhau, giống như JVM (Java Virtual Machine). JVM là máy ảo chung tuyệt vời, ban đầu chỉ hỗ trợ Java. Nhưng nó đã vượt qua thử thách thời gian, và giờ bạn có Scala, Groovy và một số cách thú vị khác để dùng các nguyên thủy này thiết kế trải nghiệm lập trình khác biệt, rất phù hợp với điều mọi người muốn làm.
Vì vậy, tôi có quan điểm thiên vị rằng Viper có thể cho bạn nhiều không gian thí nghiệm ở cấp độ ngôn ngữ nguồn.
a16z Eddy Lazzarin: Quan điểm của bạn về tất cả các ngôn ngữ bytecode EVM thay thế thế nào? Ví dụ như FE, Iron và Viper, những nỗ lực thú vị nhằm xây dựng ngôn ngữ thông minh, phức tạp hơn cho EVM, bạn có lạc quan không?
Sui CTO Sam Blackshear: Vì vậy tất cả những thứ này là các ngôn ngữ nguồn khác nhau biên dịch thành bytecode EVM.
a16z Eddy Lazzarin: Đúng, biên dịch thành bytecode EVM.
Sui CTO Sam Blackshear: Khi bắt đầu thiết kế Move tại Facebook, khi thấy các ngôn ngữ nguồn khác xây dựng trên EVM, chúng tôi đã nghiên cứu Solidity và Viper, đây là lúc chúng tôi bắt đầu xây dựng EVM. Cuối cùng chúng tôi kết luận rằng, vấn đề khó khăn nhất khiến người viết hợp đồng thông minh an toàn là bản chất底层 của EVM, và cách giá trị kiểu dữ liệu chảy qua ranh giới đáng tin cậy, và các quyết định động... Tất cả những thứ này là đặc điểm của EVM.
Nếu bạn xây dựng ngôn ngữ nguồn tốt hơn, bạn có thể khiến lập trình viên khó gây lỗi hơn. Có thể họ thực hiện kiểm chứng cao cấp hơn, nhưng cuối cùng, Move có thể cung cấp, và chúng tôi cho là quan trọng, bộ xác minh mã và lớp bảo vệ ở cấp độ VM để tránh bị lập trình viên khác tấn công.
Ngôn ngữ nguồn không thể cung cấp điều này, nó phải được tích hợp vào VM, dù bạn lặp lại ngôn ngữ nguồn hoàn hảo trên EVM bao nhiêu lần, tôi nghĩ Solidity tuyệt vời, chúng ta cũng có thể làm tốt hơn, nhưng tôi nghĩ, nếu bạn không có các biện pháp bảo vệ cơ bản này tích hợp vào VM, kết quả cuối cùng sẽ không tốt bằng các con đường khác. Tôi không xấu hổ vì nghĩ Half ngầu, mà vì nghĩ trạng thái cuối cùng kém hấp dẫn hơn các con đường khác.
Tôi nghĩ các ngôn ngữ hợp đồng thông minh đầu tiên, đặc biệt là EVM, quá mức gắn chặt với chi tiết triển khai nền tảng, được thiết kế riêng cho Ethereum, bên trong bao gồm chỉ thị về cấu trúc giao dịch, chỉ thị về cấu trúc tài khoản, dùng loại mật mã cụ thể...
Điều này khiến việc dùng EVM trên chuỗi không giống Ethereum trở nên rất khó, bạn cuối cùng phải thừa hưởng nhiều quyết định thiết kế từ Ethereum, có thể trong một số trường hợp, còn thừa hưởng cả những sai lầm khiến Ethereum khó mở rộng.
Khi thiết kế Move, chúng tôi rất tỉnh táo không đưa bất kỳ yếu tố đặc thù blockchain nào vào ngôn ngữ cốt lõi, cố gắng khiến nó càng độc lập với blockchain cụ thể càng tốt. Như vậy bạn có thể lấy Move, dùng trên chuỗi proof-of-work có cấu trúc giao dịch điên rồ
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
