a16z trò chuyện với cha đẻ ngôn ngữ Move: Bắt đầu từ ngôn ngữ lập trình, tại sao Move là hướng đi quan trọng cho hợp đồng thông minh trong tương lai

Tiêu đề gốc: "a16z Đối thoại với cha đẻ của ngôn ngữ di chuyển: Bắt đầu từ ngôn ngữ lập trình, tại sao di chuyển là hướng quan trọng cho các hợp đồng thông minh trong tương lai"

Tác giả gốc: Sui World DAO

Năm ngoái, a16z và các tổ chức khác đã hỗ trợ mạnh mẽ cho chuỗi công khai Move do Sui đại diện, khiến ngôn ngữ Move trở lại vô cùng nhiệt tình từ đống đổ nát của Meta Diem, đồng thời kể từ thời điểm này; Sui Move xuất hiện, những tiếng nói không hài lòng luôn tồn tại:

Nếu chỉ vì ngôn ngữ Move có thể tốt hơn Solidity hay các ngôn ngữ phát triển khác, chúng ta phải cần một một ngôn ngữ hợp đồng thông minh mới và bạn có sẵn sàng xây dựng Layer1 mới từ đầu không?

Mới đây, nhóm a16z Crypto đã tiến hành buổi hội thảo với Sam Blackshear, đồng sáng lập và CTO của MystenLabs và cha đẻ của ngôn ngữ Move, với chủ đề "Lập trình Ngôn ngữ và tiền điện tử" Cuộc trò chuyện trên podcast, Thảo luận tại sao Move là hướng đi quan trọng cho các hợp đồng thông minh trong tương lai.

Trong podcast này, a16z Crypto và Sam Blackshear đi từ sự khác biệt và tương đồng giữa các ngôn ngữ lập trình truyền thống và lập trình hợp đồng thông minh đến tranh luận về lợi ích độc đáo của blockchain. những hạn chế và cơ hội đã được thảo luận. Các ý tưởng thiết kế của ngôn ngữ Move, lập trình hướng đối tượng và hướng tài sản, bảo mật và các chủ đề như xác minh chính thức, các công cụ quản trị và cộng đồng, khả năng thích ứng đa nền tảng, v.v. đã được chia sẻ.

Nội dung chia sẻ chính bao 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, đến lập trình Move. Move là một trong những nghiên cứu sớm nhất về cách thiết kế ngôn ngữ để giải quyết các vấn đề như hệ thống kiểu, gõ tĩnh và kiểm tra thời gian biên dịch.

2. Đổi mới hợp đồng thông minh Move

EVM thích ứng quá mức với các chi tiết triển khai của nền tảng, những chi tiết triển khai này được thiết kế cho Ethereum. Các nhà phát triển cuối cùng đã phải kế thừa nhiều quyết định thiết kế do Ethereum đưa ra, bao gồm cả một số quyết định gây khó khăn cho việc mở rộng quy mô. Move được thiết kế mà không thêm bất kỳ thứ gì dành riêng cho blockchain vào ngôn ngữ cốt lõi. Sự đổi mới ở cấp độ ngôn ngữ mã nguồn sẽ rất quan trọng và những gì Move cuối cùng có thể cung cấp là trình xác thực mã và khả năng bảo vệ ở cấp độ VM khỏi các cuộc tấn công của các lập trình viên khác.

3. Triết lý thiết kế của Sui Move 

Move là ngôn ngữ mã byte thực thi được sử dụng để thực hiện các giao dịch của người dùng. và hợp đồng thông minh. Trong Sui Move, các trình xác thực có thể được song song hóa hiệu quả hơn, giúp việc lưu trữ, thực thi dễ dàng hơn mà không cần phải mã hóa những thứ này ở cấp độ giao thức và để người dùng cũng như lập trình viên suy nghĩ về nó.

4. Bảo mật

Trong thế giới hợp đồng thông minh, chúng ta đang ở trong tình trạng bị hạn chế. Chúng tôi viết một lượng mã rất nhỏ và nó phải hoàn hảo và bảo mật phải là điều đầu tiên được xem xét. Bảo mật di chuyển vừa là việc ngăn chặn các lập trình viên tự đá vào mông mình vừa cung cấp cho họ những nguyên tắc phù hợp bất cứ khi nào có thể để họ có thể tự vệ trước các cuộc tấn công.

5. Hướng đối tượng và hướng tài sản

Move được thiết kế để hướng tới đối tượng- định hướng và hướng đến tài sản Ngôn ngữ lập trình hợp đồng thông minh được thiết kế như thế này bởi vì hầu hết các ngôn ngữ lập trình hướng đối tượng Web2 đều giống như thế này. Trong Sui Move, việc đặt điểm trung tâm của mọi thứ lên một đối tượng được khuyến khích cao để thể hiện quyền truy cập chi tiết một cách chính xác nhất có thể. Cấu trúc của bộ lưu trữ toàn cầu Sui Move là ánh xạ từ ID đối tượng sang ID đối tượng.

6. So sánh bảo mật

Di chuyển loại bỏ khả năng đăng ký lại và lập trình hợp đồng thông minh thông qua việc xây dựng Thiếu kiểm tra quyền vấn đề trong . Trong Move, thông tin về quyền sở hữu đối tượng thực sự được lưu trữ trong siêu dữ liệu đối tượng, đây không phải là thứ mà lập trình viên có thể kiểm soát. Move Prover được thiết kế để ngăn ngừa lỗi khi viết hợp đồng thông minh bằng ngôn ngữ và có thể ngăn các nhà phát triển mắ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 There. không có sự quản lý thực sự. Chúng tôi mở rộng ngôn ngữ rất cẩn thận. Sự đơn giản là điều quan trọng nhất, 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 cụ thể, chẳng hạn như Move được thiết kế như một ngôn ngữ đa nền tảng, trong đó một số chức năng cơ bản của EDM chuỗi vẫn nên được áp dụng và bao gồm cả các chuyên gia phát triển hợp đồng thông minh và những người mới sử dụng Web2, với tính linh hoạt cao.

8. Gợi ý học tập cho nhà phát triển

Đọc nhiều code, cái này mới hiểu ngôn ngữ một cách tốt nhất. Sẵn sàng chia sẻ và tìm hiểu sâu, đồng thời tìm những người thực sự thích chia sẻ mã của bạn với người khác và cùng nhau xây dựng một cộng đồng nguồn mở. Bất kỳ công cụ nào giúp công việc của bạn dễ dàng hơn, bạn nên tìm hiểu cách thức hoạt động của nó.

Sau đây là toàn văn podcast, khoảng 25.000 từ và mất khoảng 30 phút để đọc.

Lời giới thiệu của người dẫn chương trình Sonal Chokshi

Chào mừng bạn đến với Web 3.0, đây là nhóm a16z Crypto Một chương trình về xây dựng Internet thế hệ tiếp theo. Tôi là chủ nhà Sonal Chokshi.

Chương trình này được thiết kế để hữu ích cho bất kỳ ai muốn tìm hiểu và nghiên cứu sâu hơn về tiền điện tử và những thứ liên quan đến Web 3.0, cho dù họ là nhà phát triển, người sáng tạo, kiến trúc sư, Doanh nghiệp lãnh đạo cũng là người hoạch định chính sách. Bây giờ chúng ta bắt đầu một mùa hoàn toàn mới của chương trình. Tập hôm nay tập trung vào các ngôn ngữ lập trình và tiền điện tử, dành cho cả cá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 khác đang muốn tham gia vào lĩnh vực này. Đây cũng là một lựa chọn tốt cho những ai tò mò về sự phát triển và xuất hiện của các ngôn ngữ lập trình.

Khách mời đặc biệt của chúng ta hôm nay là Sam Blackshear, người đồng sáng lập và CTO của MystenLabs , một công ty đang phát triển các giải pháp cho Web 3.0 Đặt nền móng cho một tương lai phi tập trung. Sam có kinh nghiệm lâu năm về ngôn ngữ lập trình, từ bằng tiến sĩ đến làm việc tại Facebook cho đến việc sáng tạo và là tác giả của Move cũng như ngôn ngữ lập trình nguồn mở để xây dựng hợp đồng thông minh. Chúng ta sẽ nói nhiều hơn về chủ đề này.

Trong suốt chương trình, chúng tôi cũng mời a16z Kỹ sư nghiên cứu hợp đồng thông minh của Crypto, Noah, người và một đối tác khác gần đây đã phát triển một ứng dụng khách nhẹ tên là Helios cho Ethereum và giành được giải pháp tối ưu hóa gas đầy thách thức.

Chúng tôi cũng đã mời Eddy Lazzarin, trưởng bộ phận kỹ thuật tại a16z Crypto . Trước đó, Eddy đã làm việc trong lĩnh vực kỹ thuật phần mềm tại Netflix, tham gia vào lĩnh vực kỹ thuật dữ liệu và khoa học dữ liệu tại Facebook. Xin nhắc lại, không có nội dung nào sau đây cấu thành tư vấn về đầu tư, kinh doanh, pháp lý hoặc thuế.

Lịch sử lập trình và hợp đồng thông minh

Người điều hành Sonal Chokshi:

Chúng ta sẽ bắt đầu với lịch sử lập trình truyền thống, với Noah phát biểu đầu tiên, tiếp theo là Sam Blackshear và Eddy.

a16z Crypto Noah:

Chúng tôi muốn hiểu lịch sử lập trình ảnh hưởng như thế nào đến lịch sử lập trình hợp đồng thông minh, bởi vì tôi nghĩ có ba điều, truyền thống lập trình và lập trình hợp đồng thông minh cũng như ngôn ngữ Move. Cả ba thứ đó đều có lịch sử riêng của nó phải không?

Sui CTO Sam Blackshear:

Đúng, tôi thích khuôn khổ này. Đúng là mọi người sử dụng ngôn ngữ để thiết kế ngữ pháp hoặc để làm mọi người vui vẻ, nhưng nó còn hơn thế nữa. Vì vậy, tôi thực sự thích khung hình lớn này.

a16z Crypto Eddy Lazzarin:

Trên cơ sở đó, lập trình truyền thống có hai Xu hướng vừa qua hơn ba mươi năm. Các ngôn ngữ lập trình truyền thống đã thay đổi và một số chủ đề nóng hổi đã đến rồi đi. Đã có một thời gian dài các ngôn ngữ lập trình động và việc kiểm tra kiểu rất lỏng lẻo rất phổ biến. Người ta thường nghĩ rằng sẽ thuận tiện hơn nếu chỉ cần nhảy vào, quên đi các loại, quên đi tất cả các chi tiết kỹ thuật và chỉ viết mã.

Sui CTO Sam Blackshear:

Nhưng gần đây, mọi người bắt đầu suy nghĩ sâu sắc hơn về gõ hệ thống, gõ tĩnh và kiểm tra thời gian biên dịch, v.v., để hiểu tất cả các chi tiết của chương trình càng nhiều càng tốt trước khi nó được 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, vì nó còn quá mới nên chúng tôi chưa thấy lịch sử loại hình này trong lập trình hợp đồng thông minh, điều này rất khác.

Tôi nghĩ ngôn ngữ Move là một trong những ví dụ sớm nhất mà chúng ta thấy về cách ngôn ngữ nên được thiết kế để đáp ứng điều này (hệ thống kiểu, kiểu gõ tĩnh, kiểm tra thời gian biên dịch, v.v.) bằng chứng về. Tôi muốn biết những thay đổi nào chúng tôi có thể mong đợi, chẳng hạn như các chủ đề như nhập liệu tĩnh và động 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ữ là Solidity.

Người dẫn chương trình Sonal Chokshi:

Vậy, điều này có liên quan gì đến việc chuyển sang thông minh lập trình hợp đồng thì sao? Sam lại trả lời nhé?

Sui CTO Sam Blackshear:

Trong không gian hợp đồng thông minh này, với EVM là The Lô người tham gia đầu tiên vào ngôn ngữ hợp đồng thông minh có xu hướng khác nhau. Mọi người không biết họ muốn làm gì với hợp đồng thông minh? Làm cách nào để chúng tôi viết chúng hoặc bất kỳ loại nội dung nào trong số này vì vậy tôi nghĩ tính linh hoạt là quan trọng hơn để cố gắng hiểu các loại chuyên gia cần thiết để khám phá cách sử dụng. Tôi cảm thấy như bây giờ chúng ta đã biết điều đó, hoặc ít nhất là chúng ta đã hiểu được phần nào về các yếu tố cơ bản.

Xu hướng hợp đồng thông minh là có miền cực kỳ cụ thể, bạn xác định mẫu cho nội dung, xác định chiến lược chuyển giao nội dung, kiểm tra quyền và kiểm soát quyền truy cập.

Đó là điều cơ bản, bạn sẽ không viết trình biên dịch, hệ điều hành hay bất kỳ thứ gì trong số đó bằng ngôn ngữ hợp đồng thông minh. Vì vậy, chúng có những ưu điểm rất rất tốt so với các ngôn ngữ lập trình đa năng.

Tôi nghĩ mọi người đánh giá thấp rằng mặc dù tiêu chuẩn ERC-20 đã ra đời rất lâu sau khi EVM có thể được lập trình, nhưng EVM thậm chí còn được coi là một trong những nền tảng cơ bản cho viết các chương trình Ethereum. Tôi chỉ không thấy bất kỳ bằng chứng rõ ràng nào cho thấy những điều cơ bản nhất đã rõ ràng trước đó.

Vì vậy, bạn đã đúng, bây giờ bạn có thể coi các loại là điều hiển nhiên. Tôi nghĩ các loại và việc bỏ qua những thứ này có thể duy trì một lượng nợ kỹ thuật nhất định. Nếu quy mô nhỏ, chỉ muốn di chuyển nhanh, mã có thể vứt đi thì loại nợ kỹ thuật này hoàn toàn có thể chấp nhận được. Nhưng điều thú vị là, bạn mô tả nó dưới dạng quy mô của một công ty hoặc một công ty khởi nghiệp, nơi các công ty nhỏ đang phát triển nhanh chóng và mọi người đều hiểu toàn bộ cơ sở mã, loại nợ kỹ thuật này được chấp nhận.

Nhưng khi nó thực sự rất lớn, có rất nhiều người thay đổi mã mà không biết hậu quả của các đối tượng và hệ thống mới mà họ đang xây dựng . Đưa nó vào một hệ thống kiểu cho phép bạn viết mã một cách rõ ràng, trực tiếp thay vì vô tình tạo ra một hàng rào kính mà sau này ai đó sẽ đụng phải.

Ví dụ, như bạn đã đề cập, có thể ngăn chặn việc sao chép, có thể đặt nguồn cung cấp nội dung tối đa. Những ràng buộc này rất quan trọng và cần được duy trì bất kể quy mô của dự án. Chúng là những hạn chế rất quan trọng để duy trì sự lành mạnh và an toàn của dự án. Hiểu được những ranh giới này có nghĩa là giờ đây bạn có thể tạo các ngôn ngữ lập trình cho phép bạn thực thi chúng. Đây là cách tôi xem ngôn ngữ Move.

Khi tìm hiểu về các loại ràng buộc cần thiết để thực hiện đúng, giờ đây chúng tôi có khả năng đưa chúng vào chính ngôn ngữ đó. Vì vậy, tôi nghĩ nó có phần giống với thể loại, như bạn đã nói.

Bạn đã đề cập rằng loại rất quan trọng đối với sự ổn định và an toàn của một chương trình. Các bạn nói rằng gõ động có thể phù hợp với các dự án nhỏ, nhưng khi dự án phát triển, nên sử dụng kiểu gõ tĩnh. Tôi không đồng ý, tôi nghĩ loại hoàn toàn tĩnh có thể phù hợp hơn. Đây có thể là một quan điểm mới lạ. Đó là sự tỉnh táo của lập trình viên. Điều đáng sợ nhất tôi từng thấy là khi tôi nhấn phím tắt "control k", nó sẽ cho tôi biết chữ ký hàm là gì. Điều này làm tôi kinh hãi khi viết Python. Tôi nhìn vào chữ ký hàm và chỉ thấy tên các tham số. Tôi giống như, bạn muốn cái quái gì ở tôi?

a16z Noah:

Tôi không thể tin được rằng mọi người chấp nhận rằng nếu họ viết mã thì họ sẽ không bao giờ lấy cái khác nhìn vào chữ viết.

a16z Eddy Lazzarin:

Họ chấp nhận giả định ngầm rằng họ có thể Tuân thủ các yêu cầu của hệ thống trong tâm trí.

a16z Noah:

Nhưng ngay cả đối với một chương trình 100 dòng, tôi cũng không nghĩ rằng nó có thể mặc định vào thời điểm này.

Sam Blackshear:

Nó hoạt động được nhưng không hoàn hảo.

a16z Eddy Lazzarin:

Tôi nghĩ bạn đúng. Và tôi nghĩ tâm lý đó đã phát triển. Trước đây, hệ thống kiểu được sử dụng để bảo vệ các lập trình viên khỏi đồng nghiệp của họ. Nó rất hữu ích khi công ty khởi nghiệp của bạn quá lớn. Nhưng bây giờ nó giống như bảo vệ bản thân mình hơn.

Trong bối cảnh hợp đồng thông minh, nó đang bảo vệ tôi khỏi những kẻ tấn công. Đây là sự khác biệt thực sự, bởi vì trong một chương trình bình thường, bạn không triển khai chương trình trong khi kẻ tấn công bị hạn chế bởi hệ thống loại. Kẻ tấn công có thể viết mã máy bằng các ngôn ngữ khác. Bạn chỉ cần bảo vệ tường lửa của riêng bạn. Nhưng ở đây tôi viết đối tượng kiểu Nice này sẽ đi vào mã của kẻ tấn công và giữ tính toàn vẹn của nó. Hệ thống loại phải giữ cho tôi an toàn.

Như bạn đã nói, đây là một công cụ tuyệt vời cung cấp cho bạn các yêu cầu khác nhau và bạn cần phải thực thi chúng, chẳng hạn như ngăn chặn việc sao chép. Đây không phải là điều bạn phải nghĩ tới trong một hệ thống kiểu thông thường, ngăn chặn việc xóa hoặc đảm bảo bạn sử dụng hoặc hủy một giá trị nhất định theo một cách nhất định. Tất cả là do chúng tôi đang xem xét các hợp đồng thông minh và cố gắng cung cấp một hệ thống loại có ý nghĩa cho các trường hợp sử dụng này, vì vậy đây là những thứ mà cuối cùng chúng tôi sẽ thêm vào để di chuyển và có thể là các ngôn ngữ hợp đồng thông minh trong tương lai.

Người dẫn chương trình Sonal Chokshi:

Thật ra thì các bạn, hãy làm nhiều hơn nữa Hãy nói 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 chúng ta tiến xa hơn, bạn có thể cung cấp cho chúng tôi tổng quan nhanh về các ngôn ngữ có sẵn cho các lập trình viên hợp đồng thông minh không? Tôi nghĩ chúng ta cần nhìn vào bức tranh toàn cảnh vì tôi muốn nhìn vào trạng thái hiện tại của những thứ như Solidity, Viper, v.v. Biết điều gì khiến chúng ta bắt đầu nhanh hơn.

Sui CTO Sam Blackshear:

Vâng, tôi đoán kịch bản cơ bản là nếu bạn muốn viết hợp đồng thông minh, bạn hầu như sẽ luôn sử dụng sự vững chắc. Trừ khi bạn tình cờ ở một trong những hệ sinh thái nhỏ hơn khác.

Nếu bạn ở trong hệ sinh thái Polkadot, bạn sẽ sử dụng mực! (Sui World Note: ink! là ngôn ngữ hợp đồng thông minh được phát triển bởi Parity và được sử dụng trong Rust Smart hợp đồng được viết bằng mã Wasm và được biên dịch thành mã Wasm), đây là ngôn ngữ lập trình hiện có. Nếu bạn ở trong hệ sinh thái StarkNet thì bạn sử dụng Cairo (Sui World Lưu ý: Cairo là một trong những ngôn ngữ lập trình của hệ thống STARK proof).

Nhưng phần lớn, nếu tôi đưa ra lời khuyên về cách học cách viết hợp đồng thông minh, tôi khuyên bạn nên học một số Solidity và sau đó học EVM. Bạn cũng có thể muốn sử dụng Viper, nhược điểm duy nhất là Viper mới hơn và có thể dễ bị lỗi hơn. Tôi nhớ cách đây vài năm, khi xác thực hợp đồng tiền gửi, họ đã phát hiện ra một loạt lỗi trong trình biên dịch Viper. Người phát hiện ra những lỗ hổng này hiện làm việc tại 16z, Day June, là chuyên gia xác minh chính thức.

Vì Day June là chuyên gia xác minh chính thức nên hiện cô ấy làm việc tại a16z. Và thực tế là, bạn cần học một số nội dung, bạn cần học một số 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ự giỏi, bạn cần phải hiểu EVM ở mức độ cao nhất. , <Để bạn có thể biết chi phí gas của từng thao tác, họ có thể cho bạn biết chính xác mã liên quan đến chi phí gas. Đây là thế giới chúng ta hiện đang sống.

a16z Eddy Lazzarin:

Có lẽ một điều đáng nói là với tư cách là một kỹ sư phần mềm, bạn luôn có thể hiểu được máy mà mã của bạn đang chạy. Có rất nhiều điều 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ú và phức tạp. Có rất nhiều ngữ cảnh cần hiểu và hầu như không liên quan gì đến bản thân ngôn ngữ. Đây là những gì đang xảy ra xung quanh bạn, những vật thể nào ở xung quanh và cách gọi các đoạn mã khác nhau. Đây là một điều rất kỳ lạ.

Người dẫn chương trình Sonal Chokshi:

Vì vậy, người gần nhất học được Solidity là người biết Người đàn ông JavaScript, điều này có đúng không?

Sui CTO Sam Blackshear:

Mọi người đều nói đó là JavaScript vì nó sử dụng từ khóa "function", chỉ là như JavaScript cũng được sử dụng. Nhưng thật không may, chúng không giống nhau lắm.

a16z Eddy Lazzarin:

Về mặt cú pháp, Solidity thừa hưởng rất nhiều đặc điểm của JavaScript. Nếu bạn nheo mắt hoặc đang có tâm trạng không tốt, nó có thể trông giống nhau nhưng thực tế lại hoàn toàn khác. Môi trường máy ảo rất khác nhau nên có rất ít điểm chung.

Người dẫn chương trình Sonal Chokshi:

Có ngôn ngữ lập trình nào tương tự không?

a16z Noah:

Đúng, tôi nghĩ không có ngôn ngữ lập trình nào tương tự nhau. Nếu bạn quen thuộc với Was (Sui World Lưu ý: WebAssembly Studio, một công cụ trực tuyến để biên dịch mã C/C++ và Rust sang định dạng WASM. ) và thử viết mã trong môi trường yêu cầu mức độ tách biệt cao (chẳng hạn như là Thặng dư), có lẽ là gần nhất, vì các mã này thực thi độc lập nhưng yêu cầu một mức độ giao tiếp nào đó. Nhưng nó vẫn không giống lắm, cách suy nghĩ hoàn toàn khác và những điểm tương đồng bề ngoài có thể gây nguy hiểm.

a16z Eddy Lazzarin:

Có lẽ có 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 liệu có lịch sử tồi tệ nào về việc đi sai đường khi nói đến blockchain hay không. Chúng ta đã đi những con đường khủng khiếp chưa?

Người điều hành Sonal Chokshi:

Đây là một câu hỏi hay.

Sui CTO Sam Blackshear:

Đó là một câu hỏi hay. Năm 1977, năm ngôn ngữ C ra đời cũng là năm Standard ML ra đời. ML tiêu chuẩn đã có ảnh hưởng cực kỳ lớn. Giờ đây, ngôn ngữ OCaml và ngôn ngữ Rust bị ảnh hưởng rất nhiều bởi nó và ngôn ngữ Move cũng bị ảnh hưởng bởi nó. Nhưng những ý tưởng này đã có từ lâu. Tôi nghĩ nhiều người đang nghĩ về một tương lai thay thế, trong đó thay vì C trở thành xu hướng chủ đạo, các ý tưởng ML tiêu chuẩn như gõ mạnh, an toàn tích hợp lại được chấp nhận rộng rãi.

Người dẫn chương trình Sonal Chokshi:

Vậy xu hướng phát triển của công nghệ máy tính này là gì? Tôi không nói đây là một sai lầm, nhưng tôi nghĩ các ngôn ngữ như Standard ML trông rất hiện đại ngay cả ngày nay. Thật thú vị khi tưởng tượng ra vũ trụ thay thế đó và tôi đã rất ngạc nhiên khi lần đầu tiên khám phá ra nó.

a16z Eddy Lazzarin:

Tò mò, tại sao bạn nghĩ những ngôn ngữ như C và Những ngôn ngữ tương tự rất đơn giản, rất cấp bách? Họ nghĩ về máy tính ở mức độ tương đối thấp và là ngôn ngữ lập trình, họ không làm được gì nhiều, và đó là quan điểm của tôi về C, tại sao chúng tôi lại đi theo con đường này?

Sui CTO Sam Blackshear:

Tôi nghĩ những hạn chế về phần cứng vào thời điểm đó đã buộc bạn phải sử dụng ngôn ngữ C, nếu bạn muốn viết chương trình hiệu quả hoặc vượt qua ranh giới của máy tính, tôi nghĩ nếu bạn đẩy phần cứng về phía trước, bạn sẽ chọn một con đường khác. Nhưng tôi nghĩ lập trình chức năng rất khó, nó phản trực giác về nhiều mặt. Tôi không nói C không khó, nhưng tôi nghĩ nó dễ vào hơn. Rồi bạn nhận ra, mình đã làm một việc rất phức tạp, khó lý giải, nhưng đã quá muộn. Đó là một ý tưởng hay, các ngôn ngữ chức năng có đường cong học tập dốc hơn, nhưng khi bạn đã hiểu rõ về nó, bạn sẽ nhận ra rằng tôi có thể suy nghĩ độc lập về mã của mình khá tốt và mọi thứ diễn ra khá tốt.

a16z Eddy Lazzarin:

Tôi nghĩ nếu bạn nghĩ nhiều về cách máy tính hoạt động trong phần cứng Nếu nó hoạt động ở cùng cấp độ thì ngôn ngữ như C sẽ đơn giản hơn. Nhưng nếu bạn không biết nhiều về ngôn ngữ lập trình thì C sẽ dễ bắt đầu hơn. Nhưng nếu bạn biết rõ về ngôn ngữ lập trình thì tôi nghĩ còn rất nhiều điều để khám phá về các loại ngôn ngữ, ML và lập trình chức năng này.

Sui CTO Sam Blackshear:

Đây là một câu trả lời có tầm nhìn tổng thể. Nhưng điều tôi muốn nói là về những “lỗi ngôn ngữ máy tính” ở quy mô nhỏ.

a16z Noah:

Vì vậy, tôi hơi do dự về điều đó bởi vì tôi Mình luôn nghe nói lập trình hàm rất hay nhưng mình thấy nó hơi khó hiểu. Nhưng câu hỏi mà tôi luôn thắc mắc là, nếu lập trình hàm tốt như vậy thì tại sao nó chưa bao giờ vượt qua được hiệu ứng mạng của các ngôn ngữ lập trình hiện nay? Nó làm tôi ngạc nhiên về cách nó hoạt động.

Nhưng tôi muốn nói thêm rằng tôi nghĩ đóng góp to lớn mà lập trình chức năng đã mang lại cho chúng ta là tất cả các ngôn ngữ mệnh lệnh mà chúng ta sử dụng đều được vay mượn. Nhưng điều tuyệt vời nhất là, như bạn vừa nói, Rust bị ảnh hưởng nặng nề bởi email tiêu chuẩn, nhưng về cơ bản, Rust là một ngôn ngữ mệnh lệnh, phải không? Nhưng nó có tất cả bụi thần tiên tuyệt vời đến từ việc nhìn chằm chằm vào chúng.

Sui CTO Sam Blackshear:

Nhìn chung, tôi nghĩ câu hỏi thực sự là, bắt đầu từ Năm 1977, ảnh hưởng của ngôn ngữ mệnh lệnh quá lớn. Sau đó, có PRFP, như bạn đã nói, nó không phải là lớn nhất, nó có những ý tưởng tuyệt vời của riêng mình, và khi đứng riêng lẻ, mỗi ý tưởng đều có những vấn đề riêng. Bây giờ chúng ta chỉ thấy những anh chàng thuộc chủng tộc hỗn hợp thực sự như Rust kết hôn với họ một cách xinh đẹp. Nó thực sự thay đổi cảnh quan.

Một điều tôi muốn đề cập là điều mà Tony Hoare gọi là sai lầm tỷ đô khi tham chiếu nút. Mặc dù anh ta có thể đang cố gắng phóng đại nhưng sai lầm rõ ràng còn phải trả giá đắt hơn việc không mắc phải.

a16z Eddy Lazzarin:

Không, đây có lẽ chỉ là giới hạn thấp hơn.

Sự phát triển sáng tạo của hợp đồng thông minh

 a16z Noah:

Tôi thực sự tò mò rằng bạn không nói nhiều về những đổi mới trong lớp máy ảo và lớ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à một câu hỏi hay. Tôi nghĩ mọi người chưa nghĩ đủ về những khác biệt này, chẳng hạn như sự khác biệt giữa lớp máy ảo và lớp ngôn ngữ lập trình. Trên thực tế, ngoài EVM và các lớp máy ảo mới, còn có nhiều cải tiến, chẳng hạn như các ngôn ngữ mã nguồn như Viper. Những thứ này tốt hơn Solidity về nhiều mặt và rất thú vị.

Tôi nghĩ rằng nếu Move trở thành tiêu chuẩn pháp lý mà chúng tôi mong muốn cho Web 3.0 thì sự đổi mới ở lớp máy ảo sẽ chậm lại và tăng dần. Vì cốt lõi đã cố định nên chúng tôi sẽ chỉ thêm nội dung mới chứ không thiết kế lại hoàn toàn.

Tuy nhiên, tôi nghĩ sự đổi mới ở cấp độ ngôn ngữ mã nguồn sẽ khá quan trọng. Hiện tại, chúng tôi chỉ có một ngôn ngữ mã nguồn nhưng nó gắn chặt với định dạng mã byte. Tuy nhiên, khi ngày càng nhiều khách hàng sử dụng hợp đồng thông minh, chú trọng đến tính bảo mật, tôi có thể tưởng tượng sẽ có rất nhiều ngôn ngữ mã nguồn khác nhau để thử và đây là một lĩnh vực nghiên cứu thú vị. Có lẽ bạn có thể viết ra những dữ kiện trước đây của mình và sau đó tổng hợp thông tin của chúng vào chương trình hoặc đề xuất những hạn chế.

Có lẽ bạn có thể bắt đầu bằng cách viết các thông tin thực tế trước đó về Move của mình và sau đó điền vào chương trình cho bạn thông qua quá trình tổng hợp hoặc đề xuất các hạn chế.

Ví dụ: bạn có thể viết một Nước đi trong bối cảnh của một trò chơi rất cụ thể trông giống như hệ thống phân cấp cảnh. Có thể nó được viết trong thư viện Python nhưng được biên dịch thành mã byte của Move. Có thể bạn, giống như Solana hoặc các nền tảng khác, đang xem xét việc tích hợp Move, nhưng không phải với máy ảo mà bằng cách biên dịch mã byte của Move sang định dạng mã byte của Salina và sau đó sử dụng ngôn ngữ mã nguồn Move ở cấp độ nhà phát triển.

Tôi nghĩ có nhiều cách tiếp cận khác nhau, giống như JVM (Máy ảo Java). JVM là một máy ảo đa năng tuyệt vời ban đầu chỉ hỗ trợ Java. Nhưng nó đã đứng vững trước thử thách của thời gian và giờ đây bạn có Scala, Groovy và một số cách thú vị khác để sử dụng những nguyên tắc cơ bản này nhằm thiết kế những trải nghiệm lập trình khác nhau rất phù hợp với những gì mọi người muốn làm.

Vì vậy, tôi có quan điểm thiên vị rằng Viper cho bạn rất nhiều không gian để thử nghiệm ở cấp độ ngôn ngữ mã nguồn.

a16z Eddy Lazzarin:

Bạn nghĩ gì về tất cả các ngôn ngữ mã byte EVM thay thế? ? Có những nỗ lực thú vị như FE, Iron và Viper nhằm xây dựng các ngôn ngữ thông minh hơn, phức tạp hơn cho EVM. Bạn có lạc quan về điều này không?

Sui CTO Sam Blackshear:

Vậy những thứ này được tổng hợp thành các từ EVM Khác nhau ngôn ngữ mã nguồn cho mã phần.

a16z Eddy Lazzarin:

Có, được biên dịch thành mã byte EVM.

Sui CTO Sam Blackshear:

Khi bắt đầu thiết kế Move tại Facebook, chúng tôi đã thấy những Trong trường hợp ngôn ngữ mã nguồn để xây dựng EVM, chúng tôi đã xem xét Solidity và Viper khi bắt đầu xây dựng EVM. Điều cuối cùng chúng tôi kết luận là vấn đề khó khăn nhất đối với mọi người khi viết hợp đồng thông minh an toàn là bản chất cơ bản của EVM và cách cho phép các giá trị đã nhập chảy qua ranh giới tin cậy, ra quyết định linh hoạt, v.v., đây đều là các Tính năng của EVM.

Nếu bạn xây dựng một ngôn ngữ mã nguồn tốt hơn, bạn có thể khiến các nhà phát triển khó gặp rắc rối hơn. Có thể họ có thể thực hiện xác minh nâng cao hơn,nhưng cuối cùng, những gì Move có thể cung cấp và chúng tôi cho là quan trọng là trình xác minh mã và bảo vệ cấp độ VM khỏi các cuộc tấn công của các lập trình viên khác.

Ngôn ngữ mã nguồn không thể cung cấp cho bạn điều này, nó phải được tích hợp vào VM, bất kể bạn lặp lại trên EVM bao nhiêu lần cho ngôn ngữ mã nguồn hoàn hảo, tôi nghĩ Solidity rất tuyệt và chúng tôi có thể làm tốt hơn, nhưng tôi nghĩ nếu bạn không tích hợp các biện pháp bảo vệ cơ bản này vào VM, bạn sẽ nhận được kết quả kém hơn so với một số đường dẫn khác. Tôi không xấu hổ vì nghĩ Half hay mà vì tôi không nghĩ trạng thái cuối hấp dẫn như những con đường khác.

Tôi nghĩ các ngôn ngữ hợp đồng thông minh đời đầu, đặc biệt là EVM, đã điều chỉnh quá mức các chi tiết triển khai của nền tảng được thiết kế cho Ethereum, bao gồm cả hướng dẫn nội bộ về cấu trúc giao dịch, cấu trúc tài khoản, sử dụng các loại mật mã cụ thể, v.v.

Tôi nghĩ điều này khiến việc sử dụng EVM trên một chuỗi không giống Ethereum trở nên rất khó khăn và cuối cùng bạn phải kế thừa rất nhiều thiết kế được tạo ra bởi Các quyết định của Ethereum và có lẽ trong một số trường hợp, kế thừa một số lỗi khiến Ethereum khó mở rộng quy mô.

Khi thiết kế Move, chúng tôi rất ý thức không thêm bất kỳ thứ gì dành riêng cho blockchain vào ngôn ngữ cốt lõi và làm cho nó không có gì cụ thể nhất có thể. để làm gì với nó.

Vì vậy, bạn có thể sử dụng Move và sử dụng nó trên chuỗi bằng chứng công việc với cấu trúc giao dịch điên rồ có thể đang thực hiện điều này ở Thụy Điển và một chuỗi khác cũng làm như vậy điều này ở Úc. Bằng cách này, bạn không cần phải đặt cược vào một chuỗi cụ thể để trở thành nhà phát triển Move. Bạn có thể sử dụng các kỹ năng của mình trên nhiều chuỗi khác nhau, bao gồm cả các chuỗi trong tương lai. Chúng tôi tin rằng điều này rất quan trọng đối với sự tồn tại của ngôn ngữ hợp đồng thông minh, bởi vì tài sản lớn nhất của ngôn ngữ là cộng đồng của nó. Và bằng cách biến các kỹ năng của bạn trở nên đa nền tảng, thay vì điều chỉnh chúng quá mức theo một ngôn ngữ, bạn có thể mở rộng quy mô cộng đồng của mình và có vị trí tốt hơn để thành công. Và sau đó, một cộng đồng lớn là điều giúp bạn có thể đầu tư nhiều tiền vào công cụ, đầu tư nhiều tiền vào các thư viện công cộng và tất cả những điều bạn thực sự cần để một ngôn ngữ trở thành tên tuổi lớn và thành công.

Đây là điều chúng tôi đã cố gắng thực hiện ngay từ đầu và hiện thấy nhiều chuỗi Move thực sự khác nhau, rất khác nhau về cách chúng tích hợp ngôn ngữ.

a16z Eddy Lazzarin:

Theo tôi, đây là Chủ đề cơ bản của node.js , Phải?

Người dẫn chương trình Sonal Chokshi:

Đúng.

a16z Eddy Lazzarin:

Có rất nhiều người biết JavaScript và họ muốn để làm rất nhiều thứ. Họ muốn chia sẻ nhiều thư viện khác nhau. Mã hiện tại có thể khởi chạy các phiên bản JavaScript phía máy chủ, điều này làm cho nút trở nên hữu ích. Điều này có nghĩa là có nhiều nhà phát triển có thể không lập trình phụ trợ nhưng có thể bắt đầu tham gia và biến nó thành của riêng họ.

Sui CTO Sam Blackshear:

Tôi nghĩ sự so sánh này là đúng. Ngoài ra, chúng tôi muốn nói một chút về quản trị ngôn ngữ lập trình, bởi vì Node rõ ràng có một số bất đồng và chia rẽ về quản trị rất nổi bật, đồng thời mọi cộng đồng ngôn ngữ lập trình đều có rất nhiều bất đồng và chỉ đạo về quản trị nổi bật. Tôi đã từng đề cập đến Node trước đây và đó là một trong những ứng dụng yêu thích của tôi. Nhưng tôi muốn chắc chắn rằng chúng ta đã hoàn thành chủ đề này. Còn gì để nói nữa không? Tôi nghĩ bạn là người thường xuyên tham gia chương trình radio của chúng tôi và tôi thích điều đó.

a16z Noah:

Vậy là tôi có quan điểm ngược lại, hoặc tôi có quan điểm rất Ý tưởng tuyệt vời. Tôi đã tự hỏi tại sao không ai xây dựng OP Rollup of Move, điều đó thực sự rất tuyệt, vì những người OP Rollup đã triển khai trên Ethereum, họ đã sử dụng chữ ký MetaMask và ECDSA, nhưng nó không' t dường như sử dụng định dạng chữ ký giống như của chúng tôi, ví dụ Move dường như không sử dụng ECDSA.

Sui CTO Sam Blackshear:

Có, chúng tôi hỗ trợ định dạng EdDSA và ECDSA Signature của Ethereum.

a16z Noah:

Hoàn hảo, nhưng quan điểm của tôi là, bạn có thể xây dựng một số thứ Rất thú vị chất liệu. Nhưng khi tôi cố gắng học Move, tôi cứ để mắt tới những món tráng miệng và những chú chó diễn viên. Tôi bối rối.

Sui CTO Sam Blackshear:

Đó thực sự là một vấn đề, phải không? Khi ai đó bắt đầu học Move, họ có thể bối rối: Tôi đang học ngôn ngữ hợp đồng thông minh, nhưng blockchain ở đâu? Sự khác biệt giữa chúng cũng có thể tạo ra vấn đề nếu bạn cố gắng viết mã cho cả hai nền tảng. Vì vậy, tôi nghĩ thách thức mà chúng tôi vẫn đang cố gắng giải quyết là chọn một nền tảng, chọn một điểm phù hợp, chọn một chiếc Optus, tìm hiểu sâu về nó và sau đó bạn sẽ thấy rằng các kỹ năng và mã của mình có thể dễ dàng được chuyển sang nền tảng khác . Tôi nghĩ có một số vấn đề cố hữu ở đây và một số vấn đề về tài liệu cần được giải quyết để làm cho việc này trở nên dễ dàng hơn.

a16z Eddy Lazzarin:

Có thể là một sự tương tự, tùy thuộc vào việc bạn có nghĩ SQL là Kỹ năng di động hay không. Có nhiều phương ngữ SQL. Có một anti-SQL, không ai thực sự biết nó là gì, nhưng họ có thể học SQL và nếu bạn nheo mắt một chút, bạn có thể sử dụng bất kỳ cơ sở dữ liệu nào, có thể có một số nhầm lẫn về tên hàm cụ thể hoặc các loại cụ thể, nhưng về cơ bản là giống nhau hình dạng sự vật. Tôi nghĩ điều này làm cho SQL trở nên rất mạnh mẽ và bền bỉ. Đó là lý do tại sao nó vẫn là một phần của ngôn ngữ chung của dữ liệu. Có lẽ đây là tương lai của Move. Tôi nghĩ chúng ta có thể làm tốt hơn.

Sui CTO Sam Blackshear:

Tôi nghĩ đây là một vấn đề rất lớn xét về mặt đa nền tảng Mục tiêu tốt, ứng dụng rất cụ thể. Đó là ngôn ngữ phù hợp để nói về bảng và cơ sở dữ liệu. Đây là một thực tế không thể chối cãi và đó là lý do tại sao mọi người đều sử dụng nó. Vì vậy, tôi sẽ rất vui nếu Move có thể trở thành SQL của blockchain.

Những điều độc đáo về lập trình hợp đồng thông minh

Người điều hành Sonal Chokshi:

Chúng tôi đã xem xét lại những điểm tương đồng giữa lập trình hợp đồng thông minh và truyền thống, những hạn chế và khác biệt cụ thể cũng như một số điểm tương đồng giữa lập trình Tread và hợp đồng thông minh. Có điều gì độc đáo về lập trình hợp đồng thông minh mà chúng tôi chưa đề cập đến không?

a16z Eddy Lazzarin:

Một điều rất quan trọng khác trong bối cảnh hợp đồng thông minh Đó là việc sử dụng tài nguyên, chẳng hạn như Đo lượng khí trong Solidity. Mặc dù trong nhiều trường hợp tài nguyên máy tính tương đối dồi dào nhưng chi phí tính toán cũng rất quan trọng. Nhưng bên ngoài bối cảnh hợp đồng thông minh hoặc bên ngoài bối cảnh blockchain, điều đó có nghĩa là nó chỉ được đề cập đến và ít được xem xét hơn. Tôi nghĩ khái niệm về tài nguyên bạn sử dụng bằng ngôn ngữ có thể là một tài nguyên thú vị để lập trình hợp đồng thông minh.

Sui CTO Sam Blackshear:

Đây là điều chúng tôi rất quan tâm, chúng tôi EVM Gas Metering được tích hợp sẵn, như bạn đã nói, rất khác với các ngôn ngữ lập trình truyền thống.

Tôi nghĩ xu hướng tương lai là Gas Meet sẽ ngày càng trở nên thô thiển hơn để ngăn chặn các vấn đề nghiêm trọng như lạm dụng tài nguyên thay vì thực sự lập ngân sách. cho mỗi hướng dẫn.

Tôi thực sự nghĩ rằng một cái gì đó giống như Gas Golfing (Sui World Lưu ý: Gas Golfing đề cập đến thách thức đối với các nhà phát triển trong việc viết mã tiết kiệm gas nhất trong một loạt các tương tác nhảy hợp đồng thông minh . ), mặc dù rất thú vị nhưng thực sự gây ra nhiều thiệt hại cho phong cách mã hóa và tính bảo mật.

Trớ trêu thay, lý do chúng ta chỉ biết về mô hình mỗi lệnh có lẽ là vì nếu bạn có một máy ảo khổng lồ chạy 100.000 lệnh và Sự khác biệt khi chạy 500.000 lệnh là không đáng kể khi thực sự đo thời gian chạy.

Vậy tại sao chúng tôi lại tính phí theo hướng dẫn? Vì vậy, tôi nghĩ chúng ta sẽ thấy xu hướng làm cho nó trở nên thô hơn.

Bất cứ khi nào tôi nhìn thấy tất cả các khối không an toàn này và rất nhiều tập hợp nội tuyến trong mã Solidity, điều đó nhắc nhở tôi rằng chúng ta đang ở giai đoạn đầu, bởi vì đây không phải là một thách thức lập trình mà các nhà phát triển hợp đồng thông minh nên xem xét và nó không phải là dấu hiệu của một hệ sinh thái phát triển trưởng thành. Nhưng chúng tôi đang đi theo hướng đó. Tôi đồng ý rằng chúng ta cần xem xét những trường hợp cực đoan. Chọn thuật toán phù hợp, chọn cấu trúc dữ liệu phù hợp, chọn cách tiếp cận chung phù hợp, điều này xảy ra với hầu hết công nghệ phần mềm, đều quan trọng. Nhưng câu hỏi tầm thường về việc tính toán chính xác chi phí của mỗi lệnh có thể quá tẻ nhạt.

Người điều hành Sonal Chokshi:

Chúng tôi đã nói về việc tối ưu hóa khí đốt, loại hình, tài sản và tình dục an toàn . Những hạn chế nào khác cần được xem xét?

Sui CTO Sam Blackshear:

Đây là một chủ đề tương tự như gas, nhưng tôi tập hợp con cụ thể mà tôi nghĩ đến là trạng thái. Đây là một vấn đề lớn đối với tôi. Khi nghĩ về hoạt động sử dụng khí đốt, tôi thích thực hiện việc tối ưu hóa khí đốt một cách triệt để.

Tuy nhiên, khi chúng ta xử lý các hợp đồng thông minh thực tế chứa tiền thật, lời khuyên chung của tôi là trừ khi bạn có thể gặp mọi rắc rối khi sử dụng ít hơn một chút so với trước đây Sử dụng trạng thái, nếu không bạn nên tổ chức hợp lý. Đó là lần duy nhất tôi sử dụng một khối lắp ráp lớn nếu bạn có thể làm điều gì đó ngu ngốc để sử dụng ít trạng thái hơn vì đây giống như một tài nguyên mãi mãi và chúng ta nên đặt nó ngay phía trên thực thi hoặc gọi Vị trí của dữ liệu.

a16z Eddy Lazzarin:

Tôi hoàn toàn đồng ý với quan điểm này vì tôi nghĩ nó là vấn đề cơ bản của tình dục. Nếu một nền tảng cho phép mọi hợp đồng chạm vào bất kỳ phần trạng thái nào thì sẽ khó có thể song song hóa được. Cách tiếp cận được thực hiện bởi các nền tảng blockchain mới như Squeeze và các nền tảng khác là giới hạn rõ ràng trạng thái mà giao dịch có thể truy cập, ít nhất là để cho tôi biết điều gì đó. Điều này giúp nền tảng dễ dàng song song hóa các giao dịch ở mức cao hơn, bao gồm cả việc thực thi và đồng thuận. Vì vậy, đây là điều mà một số lập trình viên phải suy nghĩ: truy cập trạng thái càng nhanh càng tốt và không chạm vào trạng thái không cần thiết, để người xác thực có thể song song hóa hiệu quả hơn và đạt được nhiều không gian khối hơn.

a16z Noah:

Liệu điều này có mở ra một thế giới mà ngay cả trong những tình huống không phải nhập vai, đừng tất cả người xác thực cần tải xuống toàn bộ trạng thái? Điều này có thể thực hiện được nếu bạn có thể dễ dàng tách trạng thái và yêu cầu trình xác nhận chỉ phân phát các giao dịch mà nó có thể xử lý?

Sui CTO Sam Blackshear:

Tôi nghĩ thực sự có thể đạt được một thế giới như vậy . Điều này cũng mở đường cho những cách tiếp cận khác nhau.

Hãy để tôi tóm tắt lại, từ góc độ của một lập trình viên, việc có thể tiếp cận toàn bộ thế giới qua các giao dịch khác nhau là vô cùng quý giá. Tuy nhiên, chúng tôi không thể nhấn mạnh ưu điểm này đến mức nó phải được triển khai thông qua Rollup hoặc trên nhiều giao dịch, vì điều này sẽ làm giảm tính bảo mật mà người dùng chú ý.

Tôi nghĩ giá trị của blockchain đến từ sự trừu tượng này: có một sổ cái và tất cả các trạng thái có giá trị đều nằm trên sổ cái này và tôi có thể chạm vào tất cả cùng một lúc họ. Từ quan điểm của một lập trình viên, đây chính là giá trị của blockchain. Câu hỏi đặt ra là: Làm thế nào để bạn khiến mọi thứ hoạt động hiệu quả hơn ở hậu trường? Làm cách nào để làm cho nó thưa thớt hơn để trình xác minh có thể được song song hóa hiệu quả hơn? Trong Sui, một trình xác thực có thể có nhiều công nhân, mỗi công nhân chịu trách nhiệm về một phần trạng thái. Nhưng từ góc độ của một lập trình viên, và thậm chí từ góc độ của những người xác nhận khác, nó trông giống như một thực thể logic có thể thực hiện mọi thứ.

Điều này giúp việc lưu trữ và thực thi dễ dàng hơn mà không cần phải mã hóa những thứ này sang cấp độ giao thức và để người dùng cũng như lập trình viên suy nghĩ về điều đó.

Những thay đổi trong cách nghĩ về lập trình hợp đồng thông minh

Người dẫn chương trình Sonal Chokshi:

Chúng ta vừa thảo luận về một số tính năng độc đáo liên quan đến lập trình hợp đồng thông minh. Những thay đổi nào khác đã xảy ra trong cách suy nghĩ? Chúng tôi đã nói về vấn đề này một chút, và như Eddie đã đề cập, một sự thay đổi lớn là trong thế giới lập trình, ít nhất là kể từ những ngày đầu của máy tính, chúng ta đã ở trong một thế giới của sự phong phú, nhưng trong thế giới này, chúng ta' đang ở trong một thế giới của những hạn chế. Đó là một ví dụ về tư duy. Có những thay đổi nào khác trong tư duy? Đối với mỗi người trong số các bạn nói riêng, với tư cách là những lập trình viên sắp bước vào lĩnh vực lập trình hợp đồng thông minh, điều gì khiến bạn ngạc nhiên, dạy bạn hoặc khiến bạn nhìn nhận điều gì đó khác biệt?

a16z Eddy Lazzarin:

Có lẽ một ví dụ hơi ngớ ngẩn là, tôi vẫn còn nhớ một vài Cách đây nhiều năm, lần đầu tiên tôi biết rằng số dư của Mã thông báo ERC-20 không phải là thứ mà tài khoản của bạn sở hữu. Địa chỉ của bạn không có số dư token. Thay vào đó là hợp đồng Token ghi lại địa chỉ nào có số dư bao nhiêu. Khi bạn muốn chuyển token cho ai đó, bạn không gửi cho họ một số token. Thay vào đó, bạn cần phải ký hợp đồng và thực hiện tất cả các hoạt động cấp thấp này, thay đổi địa chỉ của bạn và số dư do địa chỉ của họ nắm giữ. Bạn có quyền vận hành và thay đổi hợp đồng đó. Đây là một cách tiếp cận rất phản trực giác và đó là một sự thay đổi thú vị trong suy nghĩ về Move mà lần đầu tiên tôi chú ý đến EVM và Slippery. Đây là một sự thay đổi tư duy thú vị vì những từ chúng ta thường nghe trong tiếng Anh không nhất thiết phải tương ứng với các mô hình lập trình.

Sui CTO Sam Blackshear:

Tôi muốn nói thêm rằng điều này có liên quan khi bạn thực sự làm việc đó . Trong thế giới bình thường, chúng ta tập trung rất nhiều vào năng suất của nhà phát triển vì công việc của kỹ sư là viết rất nhiều mã chỉ có một vài lỗi và những lỗi đó không quá nghiêm trọng. Trong thế giới hợp đồng thông minh, công việc của bạn là viết một lượng mã rất nhỏ và nó phải hoàn hảo. Nó phải hoàn hảo về mọi mặt có thể. Nếu không bạn sẽ mất hàng trăm triệu tiền của người khác. Đó là một sự thay đổi trong một cách suy nghĩ hoàn toàn khác. Dành hai tháng nhìn chằm chằm vào 1.000 dòng mã và cố gắng tìm ra cách làm cho nó tốt hơn và quan trọng hơn là làm thế nào để nó trở nên hoàn hảo, sau đó người đánh giá phải làm công việc tương tự và quyết định xem nó có hoàn hảo hay không.

Người dẫn chương trình Sonal Chokshi:

Đây là một sự thay đổi lớn trong tư duy. Trong thế giới lập trình, ít nhất là kể từ những ngày đầu của máy tính, chúng ta đã ở trong một thế giới dồi dào, nhưng trong thế giới này, chúng ta đang ở trong một thế giới đầy những ràng buộc.

a16z Eddy Lazzarin:

Một sự thay đổi khác trong suy nghĩ là trong thế giới của ERC 20 Mã thông báo Tại đây, địa chỉ của bạn không có số dư mã thông báo. Bạn không thể gửi Token, bạn phải truy cập vào hợp đồng Token, tìm số dư Token tương ứng với địa chỉ trong hợp đồng Token, sau đó hoàn tất việc chuyển Token bằng cách sửa đổi địa chỉ và số dư. Đây là một lối suy nghĩ khá phản trực giác nhưng trong EVM và Move thì đây lại là một sự chuyển đổi rất quan trọng trong tư duy.

Sui CTO Sam Blackshear:

Trong lập trình hợp đồng thông minh, công việc của bạn là viết A một đoạn mã nhỏ và nó phải hoàn hảo, vì mã này có thể liên quan đến sự an toàn của hàng trăm triệu quỹ của mọi người. Bạn phải xem xét cẩn thận mã để đảm bảo tính chính xác của nó.

Ngoài ra, việc nâng cấp hợp đồng thông minh còn khó khăn hơn việc nâng cấp ứng dụng di động hoặc trang web vì trong hợp đồng thông minh, mã là bất biến. Trong lập trình hợp đồng thông minh, bạn phải xem xét cách hỗ trợ nâng cấp an toàn và tin cậy để làm cho nó trông giống một hệ sinh thái truyền thống hơn.

Nhưng trong lập trình hợp đồng thông minh, bạn cần có lối suy nghĩ đối đầu, điều này có thể xa lạ với những người ở các lĩnh vực khác. Điều này là do mô hình triển khai trong hợp đồng thông minh, trong đó bạn cần xem xét không chỉ mục đích sử dụng ứng dụng của mình mà còn cả việc sử dụng ngoài ý muốn. Bởi vì trong lập trình truyền thống, có nhiều cách để ẩn giấu bản thân, giới hạn bản thân trong một API nhỏ hoặc sử dụng tường lửa để hạn chế những gì kẻ tấn công có thể làm, v.v.

Nhưng điểm chung của hợp đồng thông minh là những gì bạn làm có thể tương tác với mã mà bạn chưa từng tưởng tượng và thực hiện điều đó một cách an toàn. Vì vậy, bạn cần cân nhắc những ưu và nhược điểm của tình huống này. Đây chắc chắn là một sự thay đổi trong tư duy so với lập trình truyền thống.

Người điều hành Sonal Chokshi:

Đây là một vấn đề rất quan trọng và là vấn đề mà chúng ta sẽ thảo luận. để viết hợp đồng thông minh và bạn nên ưu tiên điều gì khi sử dụng ngôn ngữ lập trình hợp đồng thông minh?

Sui CTO Sam Blackshear:

Có Chắc chắn rồi. Đây thực sự là điều tôi thích nói nhất. Điều này làm tôi rất lo lắng,Vấn đề mà các nhà thiết kế ngôn ngữ hợp đồng thông minh cần cân nhắc là tính bảo mật. Đây là trọng tâm chính, thậm chí có thể là trọng tâm duy nhấtcho đến khi chúng ta tìm ra điều này.

Tôi tin rằng bảo mật hợp đồng thông minh là mối đe dọa hiện hữu đối với việc áp dụng tiền điện tử rộng rãi hơn. Lý do tôi nói như vậy là bạn có thể xem xét Ethereum và Solidity cũng như các nền tảng phổ biến nhất là EVM và Solidity. Bạn có thể nhìn vào những lập trình viên đầu tiên đã viết mã này, họ có trình độ rất cao, thực sự hiểu về blockchain cơ bản và rất chú trọng đến bảo mật. Họ biết những gì họ đang làm. Tôi nghĩ họ rất coi trọng trách nhiệm viết mã quản lý hàng trăm triệu và hàng tỷ đô la.

Nhưng nếu bạn nhìn vào hồ sơ bảo mật hợp đồng thông minh ở bất cứ đâu, bạn sẽ thấy nó thật tồi tệ và đó không phải lỗi của những người này. Tôi nghĩ đây là một câu hỏi rất khó. Và tôi nghĩ ngôn ngữ khiến việc đó trở nên khó khăn hơn. Vì vậy, nếu bạn nhìn vào trang web yêu thích của tôi, rakt.news, bạn có thể nhìn vào bảng xếp hạng hoặc nhìn vào mười vụ hack trị giá hàng chục triệu hoặc hàng trăm triệu đô la này rất quen thuộc, xảy ra hàng tuần hoặc hàng tháng, cụ thể là Phụ thuộc về kích thước. Đồng thời, cộng đồng nhà phát triển hợp đồng thông minh rất nhỏ, chỉ có khoảng 5.000 lập trình viên EVM toàn thời gian, rất nhỏ so với cộng đồng nhà phát triển truyền thống.

Vì vậy, nếu bạn tin rằng chúng tôi có một số người tập trung vào bảo mật và khắt khe nhất hiện nay, nhưng thực tiễn phát triển và hồ sơ bảo mật là không bền vững, thì tôi tôi nghĩ rằng kết luận của bạn là không có cách nào để không gian này tiếp tục phát triển mà không làm cho vấn đề bảo mật trở nên tồi tệ hơn, điều đó có thể có nghĩa là nó sẽ không phát triển chút nào, hoặc giống như các tổ chức hoặc công ty tài chính lớn muốn truy cập vào Web3. , họ đang xem xét liệu họ có phải thuê nhà phát triển hợp đồng thông minh không? Tôi sẽ bị hack hàng chục triệu đô la và cảm thấy lo lắng. Tình trạng này sẽ chỉ trở nên tồi tệ hơn khi thời gian trôi qua. Họ có thể vẫn đứng bên lề. Vì vậy, khi ai đó đang cố gắng thiết kế ngôn ngữ hợp đồng thông minh mới, bảo mật phải là điều đầu tiên bạn nghĩ đến.

Người dẫn chương trình Sonal Chokshi:

Thật ra bạn đã ám chỉ điều này mà không bị mất tài sản, nhưng ý bạn là gì hơn cụ thể là vì nó rất quan trọng?

Sui CTO Sam Blackshear:

Theo ý tôi là bảo mật Chúng tôi muốn cả hai ngăn chặn các lập trình viên tự đá vào mông mình mà còn cung cấp cho họ những nguyên thủy phù hợp nhiều nhất có thể để họ có thể chống lại các cuộc tấn côngvì hợp đồng thông minh là một thiết lập trong đó mã của bạn được triển khai bên cạnh kẻ tấn công Người đọc có thể gọi trực tiếp mã của bạn và có thể liên kết trực tiếp với nó. Mã của bạn là mã nguồn mở hoặc ít nhất là mã byte.

Đây là môi trường lập trình khắc nghiệt nhất mà chúng tôi từng thấy và cái giá phải trả cho những sai lầm cũng cao nhất. Vì vậy, tôi nghĩ nếu bạn đang thảo luận về thiết kế lập trình hợp đồng thông minh thì tính bảo mật luôn phải được đặt lên hàng đầu. Sau khi giải quyết vấn đề bảo mật, chúng ta có thể xem xét các yếu tố khác, mang tính biểu cảm hơn, nhưng đây là câu trả lời hơi nhàm chán nhưng tôi nghĩ rất quan trọng của tôi.

a16z Eddy Lazzarin:

Những tính năng nào có thể ảnh hưởng đến bảo mật? Những ví dụ nào có thể minh họa điều này?

Sui CTO Sam Blackshear:

Tôi nghĩ điều quan trọng nhất là bao bì , Cụ thể là các tính năng phụ khác nhau của gói. Khi viết mã, bạn không thể đoán trước kẻ tấn công sẽ thử điều gì, vì vậy bạn cần có khả năng suy luận mà không đoán trước được kẻ tấn công sẽ làm gì. Vì vậy, bạn cần một hệ thống loại mạnh, không chỉ ở cấp mã nguồn mà còn ở cấp mã byte, để đảm bảo bạn nhận được khi viết mã nguồn sẽ có khi bạn xuất bản mã trên blockchain và những người khác dựa vào. trên đó và tiếp tục giữ trong khi tương tác với nó.

Chúng tôi nhận thấy rằng một số tính năng phổ biến trong các lĩnh vực khác vốn không phù hợp trong lập trình hợp đồng thông minh, chẳng hạn như công văn động.

Trong lập trình truyền thống, những thứ như giao diện và điều phối động là các cơ chế trừu tượng quan trọng và có mặt khắp nơi. Bạn có thể xác định một giao diện, sau đó người khác viết lại giao diện đó với logic khác, sau đó bạn lập trình dựa trên giao diện đó và tất cả đều tuyệt vời. Nhưng chúng tôi có một câu nói dí dỏm: "Trong một thế giới mà mã là luật, giao diện là một tội ác."

a16z Noah:

Đây là một trò đùa, chúng ta hãy dừng lại một chút. Trong một thế giới mà mã là luật, giao diện là một tội ác.

Người dẫn chương trình Sonal Chokshi:

Trước khi tiếp tục, bạn có thể giải thích câu này thêm một chút được không? Tôi không muốn vượt qua nó quá nhanh.

Sui CTO Sam Blackshear:

Đúng vậy. Ý tưởng ở đây là một giao diện không xác định hành vi, nó xác định hành vi được mong đợi. Ví dụ: khi bạn đọc thông số kỹ thuật của một giao diện, tên tham số và thậm chí cả loại, nó sẽ cho bạn biết bạn muốn thực hiện điều gì. Nhưng không có gì đảm bảo nó sẽ xảy ra.

Vì vậy, nếu bạn viết mã để bảo vệ thứ gì đó, nhưng thực tế bạn lại để trống một dấu kiểm cho kẻ tấn công, những người khác điền vào. Điều này dường như là một tội ác trong luật hợp đồng. Đây là một hợp đồng không xác định. Tôi thực sự thích tính năng này, nó rất phổ biến trong các ngôn ngữ lập trình truyền thống. Nhưng chúng tôi nghĩ rằng trong hợp đồng thông minh, điều này dẫn đến rất nhiều vấn đề khác nhau. Ví dụ, việc quay lại yêu cầu lập kế hoạch động. Ví dụ: nếu bạn hủy công văn động thì sẽ không có mục nhập lại nào cả. Những điều như Poison Token trong Ethereum xảy ra do bạn ghi đè chức năng chuyển khoản và mọi người đều biết bằng trực giác rằng nó chỉ được sử dụng để chuyển tiền và có thể không làm gì khác. Nhưng bây giờ bạn bắt nó làm điều gì đó ngoài mục đích đã định, chẳng hạn như ăn trộm tiền. Đây là một ví dụ về một tính năng mà nếu bạn loại bỏ nó, việc suy luận về mã và gói gọn nó một cách thích hợp sẽ trở nên dễ dàng hơn vì mỗi khi bạn nhìn thấy một trang web cuộc gọi, bạn sẽ biết chính xác nó sẽ làm gì và bạn không phải lo lắng về việc người khác sẽ làm gì điều gì đó sẽ làm bạn ngạc nhiên sau này.

a16z Eddy Lazzarin:

Chính xác, tôi nghĩ sự tương tự giống như nếu bạn Định nghĩa một giao diện về một chiếc ghế, nó có bốn chân và một chiếc ghế, bạn đang mô tả nó ở mức độ cụ thể, không phải ở mức độ hành vi, bạn không mô tả những điều khác về chiếc ghế có thể là ẩn ý hoặc mặc định, chẳng hạn như nó có một số Cấu trúc tính toàn vẹn, nó có những vật liệu cụ thể, nó được đặt theo một cách nhất định.

a16z Eddy Lazzarin:

có thể bị phá vỡ, điều đó có nghĩa là giao diện chỉ là một tập hợp mô tả tùy ý, không nắm bắt được các ràng buộc bảo mật mà bạn muốn thực thi.

a16z Noah:

Đó là định nghĩa.

a16z Eddy Lazzarin:

Định nghĩa mọi thứ ở mức độ sai lầm. Tôi tò mò.

Sui CTO Sam Blackshear:

Nhưng làm cách nào để mô-đun hóa tốt bên ngoài giao diện? Nếu giao diện là một tội ác thì có lẽ tôi sẽ là tội phạm, bởi vì một trong những cách yêu thích của tôi để xây dựng các hợp đồng thông minh phức tạp là thích có các hợp đồng khác nhau, với các mục đích khác nhau. Và đặc biệt là trong các hệ thống rất phức tạp, bạn có nền tảng dựa trên mô-đun trong đó các mô-đun tuân thủ một số loại giao diện và sau đó hợp đồng chính có thể biết cách gọi các mô-đun khác nhau. Các mô-đun này thường được cấp phép thông qua quản trị, làm cách nào để bạn có được tính mô-đun plug-and-play của Super Express? Không có giao diện chuẩn hóa? Làm thế nào để có được quyền thừa kế?

a16z Eddy Lazzarin:

Bạn thích tất cả những thứ về giao diện này?

Sui CTO Sam Blackshear:

Đây là câu hỏi phù hợp để hỏi. Họ có thể tranh luận chống lại điều này cả ngày, nhưng còn việc cung cấp thứ gì đó cho phép bạn viết mã hữu ích thì sao? Giống như nếu bạn không được phép ra khỏi nhà hoặc bất cứ điều gì tương tự thì không có tội. Nhưng cách chúng tôi làm, giao diện và tính kế thừa không phải là cách duy nhất, tôi có xu hướng nghĩ về mặt bố cục. Chúng tôi cung cấp một số thành phần nguyên thủy không yêu cầu giao diện lập lịch động.

Một trong số đó là thuốc generic. Chúng tôi có tính kế thừa thời gian chạy trông rất giống những gì bạn có. Clr (Sui World Lưu ý: thời gian chạy ngôn ngữ chung, thời gian chạy ngôn ngữ chung) Hãy để tôi đưa ra một ví dụ rất cụ thể, nếu không điều này sẽ nhanh chóng trở nên trừu tượng.

Những thứ như ERC-20 của bạn, rõ ràng là một tiêu chuẩn mật mã quan trọng về cơ bản. Nếu nền tảng của bạn, ngôn ngữ của bạn không thể làm được điều đó thì nó chẳng có tác dụng gì. Trong ngôn ngữ như Move, bạn xác định một điểm thuộc loại được gọi là t , trong đó t là tham số loại chung, sau đó triển khai các hàm cho coin , ví dụ: có một hàm để nối 2 điểm lại với nhau. Điều này hoạt động cho tất cả các loại tiền xu. Đây không phải là điều mà ai đó muốn che đậy. Bạn xác định sự phân chia.

Sử dụng cái gọi là mẫu khả năng khi bạn muốn ai đó tùy chỉnh hành vi của Mã thông báo, ví dụ: đối với Mã thông báo, bạn có thể muốn tùy chỉnh một thứ. luôn luôn là Nguồn cung là gì, hay cơ bản hơn là chính sách của nó là gì? Bạn có thể diễn đạt nó như thế này: OK, bạn có cấu trúc điểm thuộc loại "t", và sau đó bạn có các cách thể hiện khác nhau của t, chẳng hạn như đô la, bảng Anh hoặc các loại tiền tệ khác. Đối với thứ bạn muốn tùy chỉnh, bạn cung cấp nó ở cấp khả năng, tạo chức năng Mã thông báo. Bạn nói, đây là tham số loại Mã thông báo của tôi, và sau đó nó sẽ cung cấp cho bạn một thứ gọi là "Khả năng kho bạc quỹ". Sau đó, có logic khác để đảm bảo rằng chỉ những người nắm giữ khả năng kho bạc mới có thể đúc và phá hủy các mã thông báo loại t. Bạn có thể sử dụng khả năng kho bạc này, khóa nó trong một hợp đồng khác và thực thi giới hạn về tổng nguồn cung. Bạn có thể đặt nó ở đâu đó và nói chỉ bình luận vào Thứ Ba chứ không phải Thứ Năm. Bạn đảo ngược luồng điều khiển, cho phép bạn thực hiện bất kỳ sự kết hợp nào. Đây là một ví dụ về một thủ thuật, nhưng thủ thuật này có thể được sử dụng ở hầu hết mọi nơi, nếu bạn muốn hành vi hoạt động theo một cách nhất định, bạn cần phải mã hóa cứng nó. Điều này nghe có vẻ tệ, nhưng bạn triển khai hai phương pháp cụ thể và sau đó bạn xác định những khả năng đó cho những gì bạn muốn cho phép.

a16z Eddy Lazzarin:

Bạn nghĩ gì về những khả năng mà bạn có thể thêm vào những gì trông giống như một lập trình viên truyền thống Có bất kỳ hạn chế nào về giao diện không?

Sui CTO Sam Blackshear:

Đúng vậy, tôi nghĩ hầu hết các mẫu giao diện này có thể Rất biến thể đơn giản. Điều này hơi khó biên dịch, nhưng bạn có thể nói rằng đây là mẫu khả năng tương đương với những gì giao diện này đang cố gắng thực hiện.

Người dẫn chương trình Sonal Chokshi:

Nhân tiện, Sam, bạn có hài lòng với điều này không? ? Hãy thoải mái không đồng ý, xung đột một chút cũng là điều tốt.

Sui CTO Sam Blackshear:

Tôi nghĩ điều này khá thỏa đáng, bởi vì tôi nghĩ nếu Bạn có thể có các mô-đun hoặc cấu trúc có các khả năng tích hợp có thể được đưa vào các mô-đun có hành vi được xác định trước và bạn có thể kết thúc với hành vi giống hệt như mô-đun có thể thực hiện. Một mô-đun chấp nhận một cấu trúc trừu tượng, cấu trúc đó được xác định trong mô-đun đó và sau đó có một khả năng vốn có trong cấu trúc đó. Điều này thực sự hoạt động rất tốt vì bạn có thể nhận được các sổ đăng ký kiểu quyền thực sự tốt đẹp gần như tự nhiên xuất phát từ đây, giống như cái được gọi là sổ đăng ký DS-Off, phải không?

a16z Nô-ê:

Chính xác. Những khả năng này là sự thể hiện có thể mở rộng về những gì bạn được phép làm. Vì vậy, điều này có rất nhiều lợi ích khác. Ví dụ: nếu bạn muốn biết tài khoản của tôi có thể làm gì, chỉ cần xem tôi có những khả năng gì. Sau đó, bạn có thể phân tích chương trình và xem liệu tôi có khả năng tìm kiếm kho báu hay không, tôi có thể gọi những chức năng nào và một số thứ tương tự khác.

Lập trình hướng đối tượng và hướng tài sản 

a16z Eddy Lazzarin:

Vì vậy, có thể tôi còn hơi sớm khi nói về người chứng minh, nhưng hệ thống loại có thể nhìn thấy những khả năng này không? Khi phân tích tĩnh một chương trình, những khả năng này có thể nhìn thấy được ở điểm nào trong chương trình? Nếu tôi viết một số mã khởi tạo một khả năng cụ thể, liệu tôi có thể phát hiện sớm hành vi vi phạm khả năng của mình trước khi chạy nó không?

a16z Noah:

Có, những khả năng này được hiển thị đối với hệ thống loại và nó được hiển thị trong giai đoạn phân tích tĩnh của chương trình. Nếu tôi viết mã cho một loại có phiên bản cụ thể của một khả năng, thì có thể phát hiện từ rất sớm liệu tôi có vi phạm khả năng đó khi không chạy nó trên máy ảo hay không.

Sui CTO Sam Blackshear:

Hãy để tôi trả lời ngắn gọn câu hỏi và sau đó cung cấp một số thông tin cơ bản, Chúng là hiển thị với trình biên dịch và là một phần của hệ thống kiểu. Đây là một điểm sử dụng rất quan trọng đối với chúng tôi. Nhưng tôi muốn nói một chút về cấu trúc trong hệ thống di động của Move và cách nó liên quan đến hệ thống phân cấp các khả năng tương tự như kiểm tra. Nếu điều đó không gây mất tập trung.

Trong Move, bạn có các kiểu cấu trúc và cấu trúc tương tự như các ngôn ngữ khác, chúng có thể có các trường, có thể là các trường thuộc loại cơ bản hoặc có thể là các cấu trúc khác . Điều thú vị hơn và có lẽ khác biệt hơn là những cấu trúc này có khả năng. Nếu bạn quen thuộc với Rust, các khả năng giống như các giao dịch được gắn thẻ. Chúng khai báo các thao tác có sẵn mà bạn được phép thực hiện trên cấu trúc.

Quan trọng không kém, bạn không thể làm được những việc đó nếu không có năng lực. Một khả năng tương đối đơn giản nhưng lại rất quan trọng, đó là khả năng sao chép. Nếu bạn có một loại mã thông báo hoặc thứ gì đó giống như mã thông báo không thể thay thế, trong máy tính, nó chỉ là một số bit, nhưng bạn không muốn cho phép người khác sao chép thứ này theo ý muốn.

Trong Move, nếu bạn không khai báo rằng cấu trúc của bạn có khả năng sao chép thì bạn không thể sử dụng thao tác tương đương với "man copy" của chúng tôi.

Vì vậy, những thứ như số nguyên và chuỗi đều được sao chép. Nhưng nếu bạn không muốn kiểu của mình có khả năng sao chép thì bạn không cho. Và sau đó còn có những khả năng khác như thả rơi, được gọi là khả năng thả rơi. Điều này trở thành nội dung kiểu tuyến tính thú vị, trong đó nếu bạn muốn loại bỏ thứ gì đó, chẳng hạn như đặt nó ngoài phạm vi hoặc ghi đè lên nó, thì bạn cung cấp cho nó khả năng loại bỏ. Nhưng nếu bạn không thả, thì cách duy nhất để loại bỏ nó là xác định bất kỳ chiến lược nào mà các mô-đun thuộc loại đó mong đợi.

Thời gian chạy ngôn ngữ chung (CLR) Đối với một ví dụ cụ thể, nếu bạn muốn duy trì tổng nguồn cung cấp cho Mã thông báo của mình, bạn Nó sẽ không cung cấp cho bạn Mã thông báo khả năng đánh rơi. Sau đó, không có cách nào khác để loại bỏ nó ngoại trừ hàm ghi được xác định trong mô-đun nơi nó được khai báo, chức năng này sẽ cập nhật tổng nguồn cung. Đây là tất cả các kỹ thuật bạn có thể sử dụng. Ngoài ra còn có một số khả năng liên quan đến lưu trữ, chẳng hạn như liệu nó có thể được lưu trữ trong bộ lưu trữ toàn cầu hay không, mà tôi sẽ không đi sâu vào chi tiết vì chúng không liên quan lắm đến câu hỏi này. Nhưng về cơ bản, các khả năng đã được đưa vào chương trình kiểm tra và chương trình kiểm tra hiểu hệ thống loại và biết cách sử dụng hệ thống loại để giải quyết vấn đề. Nếu tôi viết mô tả cho biết chỉ có một thứ như vậy thì chương trình kiểm toán có thể sử dụng điều này để chứng minh đặc tính này. Do đó, khả năng và đảm bảo hệ thống loại bổ sung cho nhau.

a16z Noah:

Khi bạn nhắc đến giọt nước, tôi muốn nói về thứ tôi yêu thích nhất. Bạn có thể nói một chút về chế độ khoai nóng là gì được không? Đó là một trong những điều kỳ lạ yêu thích của tôi đến từ Move, nếu có những thứ thú vị khác tương tự.

Sui CTO Sam Blackshear:

Đây quả thực là một điều kỳ lạ. Điều này liên quan rất chặt chẽ đến khả năng. Thông thường trong các ngôn ngữ lập trình, bạn không có nhiều quyền kiểm soát khi giá trị của bạn bị hủy, có thể bạn có một hàm hủy cho biết khi nào giá trị của bạn bị hủy. Nhưng đôi khi sự đảm bảo của hàm hủy yếu hoặc bạn không thể đơn giản nói điều gì đó như "bạn không thể xóa loại của tôi". Điều này nghe có vẻ như là một hạn chế kỳ quặc, nhưng nó thực sự rất mạnh mẽ, đặc biệt là không có công văn động.

Tôi sẽ bắt đầu với một ví dụ về khoai tây nóng, sau đó chúng ta có thể đi sâu vào những thứ như khoản vay nhanh. Nếu bạn thực hiện các khoản vay nhanh trên Ethereum, thì đó là một tiêu chuẩn, bạn có thể ghi đè nó, về cơ bản, bạn hiển thị chức năng gọi lại, chẳng hạn như hợp đồng cho vay nhanh, bạn đưa tiền cho tôi, chức năng gọi lại của tôi sau đó sẽ lấy lại tiền, và cách bạn làm điều đó trong Move là có người ký hợp đồng cho vay nhanh và họ nói: "Này, cho tôi 53 đô la, nhưng họ cũng đưa cho bạn thứ mà họ gọi là đồ khoai tây nóng.

Đối tượng Hot Potato là một cấu trúc, nó không có khả năng sao chép nên bạn không thể sao chép nó, bạn không thể đặt nó vào hợp đồng như bạn có thể. Nó cũng không có. bỏ khả năng nên bạn không thể vứt nó đi nên cách duy nhất để loại bỏ nó là chuyển nó trở lại hợp đồng flash loan, buộc bạn phải trả lại. Nếu không, chương trình sẽ thất bại. trong thời gian chạy và thậm chí sẽ không vượt qua được quá trình kiểm tra loại. Vì vậy, thật thú vị khi tận dụng khả năng kiểm soát việc phá hủy các giá trị của bạn và với tư cách là một lập trình viên, bạn có thể áp đặt các giá trị tùy ý vào bất kỳ lúc nào. xác định thời điểm các đối tượng này có thể bị hủy. Chúng trông rất giống mẫu lệnh gọi API. Một ví dụ rất rõ ràng khác là nếu bạn muốn buộc ai đó gọi khóa sau khi gọi mở khóa, nhưng ở giữa bất kỳ điều gì bạn muốn làm, bạn đều có thể thực hiện. cách này cũng vậy

a16z Eddy Lazzarin:

Lần đầu tiên tôi nghe đến "khoai tây nóng" ", tôi đã nghĩ đến những cách sử dụng thú vị cho các khóa như "tắt tiếng texas" khai thác hệ thống loại chỉ nhằm mục đích công thái học. Việc thực thi cách sử dụng một đối tượng cụ thể gần như là một yêu cầu ở mức logic nghiệp vụ. Tôi nghĩ điều này rất thông minh, mang lại cảm giác rất hiện đại và là cách sử dụng công thái học chất lượng cao trong ngôn ngữ lập trình theo cách thậm chí còn chưa phổ biến trong các ngôn ngữ lập trình truyền thống nhưng rõ ràng là rất phổ biến trong ngôn ngữ lập trình thông minh. môi trường hợp đồng Giá trị, vì ở đây có nhiều yêu cầu hợp lý hơn để xem xét giá trị và bảo mật có thể liên quan.

Sui CTO Sam Blackshear:

Trước khi chúng ta thảo luận về bất kỳ ví dụ cụ thể nào, bạn có thể đưa ra một cái nhìn tổng quan nhanh chóng không? tổng quan cấp cao về hệ thống đối tượng của chúng tôi? Các đồ vật là gì và ai sở hữu chúng? Các đối tượng sở hữu các đối tượng khác như thế nào và các mô-đun hoạt động với chúng như thế nào?

a16z Noah:

Đúng vậy. Đây là một phương ngữ của ngôn ngữ Move, cụ thể là Sui Move. Cơ sở của vấn đề này là một cấu trúc lưu trữ toàn cầu khác với sơ đồ lưu trữ toàn cầu mà chúng tôi thường sử dụng trong phương ngữ Move ban đầu. Sơ đồ lưu trữ toàn cầu Move ban đầu rất giống với mô hình công ty được Ethereum sử dụng.

Trong Sui Move, chúng tôi muốn đặt trọng tâm của mọi thứ lên đối tượng, với động lực cao là thể hiện quyền truy cập chi tiết một cách chính xác nhất có thể. Điều này giúp bạn làm được nhiều việc mà chúng tôi sẽ không trình bày chi tiết trên podcast này, như xử lý các giao dịch hiệu quả hơn, cho người dùng ví biết những giao dịch sẽ thực hiện, v.v.

Vì vậy, trong Sui Move, cấu trúc lưu trữ toàn cầu là sự ánh xạ từ ID đối tượng sang ID đối tượng. Đối tượng khi đó chỉ là một cấu trúc Move với khả năng được gọi là khóa. Nó nói: "Này, tôi có thể là chìa khóa." Nó có thể xuất hiện trong nhóm đối tượng chung. Mỗi đối tượng sau đó phải có một ID duy nhất trên toàn cầu. Sau đó, bạn có thể viết các hàm điểm đầu vào cho mô-đun của mình để lấy trực tiếp các đối tượng làm đầu vào. Nếu bạn đang viết một giao dịch, WeRunTime này sẽ có ID đối tượng. Nếu bạn đang viết một giao dịch, WeRunTime sẽ có thể sử dụng các ID này để phân tích các ID thành đối tượng và chèn chúng vào hàm.

Trải nghiệm lập trình hướng đối tượng và hướng tài sản này thật tuyệt vời. Nó đơn giản hơn nhiều so với những gì chúng tôi đã làm trong phiên bản Move gốc. Bạn cũng đã đề cập đến các đối tượng cha, con và hệ thống phân cấp đối tượng. Điều này rất hữu ích nhưng bạn vẫn muốn có thể làm những việc như đại diện cho các bộ sưu tập lớn.

Ví dụ: tôi đang xây dựng một sổ đăng ký giống như DNS và tôi muốn có hàng triệu mục nhập. Chúng tôi có giới hạn kích thước đối tượng, một đối tượng có thể là vài megabyte nhưng không lớn hơn. Nhưng nếu bạn có thứ gì đó như DNS, thì nó sẽ có kích thước lớn tùy ý. Cách chúng tôi thể hiện nó là sử dụng mối quan hệ đối tượng cha-con, trong đó về cơ bản chúng tôi có cách xử lý một đối tượng như một bản đồ không đồng nhất. Sau đó, bạn có thể thêm khóa với các trường được chọn động. Điều này rất giống với JavaScript theo một cách nào đó. Chúng ta có thể nói, vật thể này có một bản đồ trong đó, và sau đó tôi có thể đặt thứ gì đó vào bản đồ này. Hoặc bạn có thể nói, khi tôi xác định đối tượng này, nó có mười trường, nhưng tôi thực sự muốn thêm trường mới sau và tôi sẽ nâng cấp hợp đồng của mình. Tôi muốn thêm một lĩnh vực mới sau khi thực tế.

Cách chúng tôi thể hiện nó là sử dụng các mối quan hệ đối tượng cha và đối tượng con này, mỗi đối tượng con được liên kết với một giá trị khóa, có thể là bất kỳ giá trị Move nào, chẳng hạn như chuỗi hoặc u64 , hoặc bất kỳ giá trị nào khác mà bạn muốn.

a16z Noah:

Đúng vậy, liên quan đến khái niệm đối tượng cha mẹ, tôi nghĩ hãy Điều thực sự trở thành "khoảnh khắc eureka" của tôi thực ra là cách đây vài tháng, khi tôi dành thời gian tìm hiểu về Sui Move và chuyển từ viết chương trình chỉ với một đối tượng sang triển khai lại hầu hết bộ bài kiểu Uniswap V2 kết hợp . Một dự án nhỏ mà tôi thực hiện đã thực sự khiến tôi nhận ra việc sở hữu đồ vật có giá trị như thế nào. Dự án này chỉ có ba đối tượng, một chiếc khóa, vàng và một rào chắn trống. Có một mô-đun rất cơ bản mà bạn có thể tưởng tượng việc tạo vàng thuộc sở hữu của một đối tượng chính. Sau đó, cách duy nhất để lấy vàng ra là có một chức năng lấy ổ khóa và chìa khóa và rõ ràng là phá ổ khóa, đưa cho bạn vàng và sau đó phá hủy chìa khóa của bạn. Đây là một cách tiếp cận rất thú vị, trong đó bạn có thể mô tả mối quan hệ giữa các đối tượng và mô tả các quyền một cách rất chi tiết.

Sui CTO Sam Blackshear:

Đây chính xác là những gì chúng tôi đang xem xét. Tôi thích cách bạn mô tả việc lồng ba đối tượng khác nhau, vì điều này trở nên mạnh mẽ hơn khi bạn đi sâu hơn. Điều này giúp lập trình viên dễ dàng được cấu trúc hơn để đảm bảo rằng tôi có thể đạt đến cấp độ thứ hai và sau đó là cấp độ thứ ba, nhưng tôi không thể đi thẳng từ cấp độ đầu tiên lên cấp độ thứ ba. Tôi nghĩ điều này cũng giúp các lập trình viên ở bên ngoài không gian hợp đồng thông minh dễ hiểu hơn, những người rất quen thuộc với việc viết cây đối tượng, cây đối tượng DOM và nếu bạn là lập trình viên trò chơi, mọi thứ đều là hệ thống phân cấp cảnh trong đó có ký tự A, họ có hàng tồn kho và sau đó có thể có một số thứ nhỏ nhặt trong kho. Bạn có thể mã hóa những thứ này trong Move rất trực tiếp và sau đó hệ thống loại cho phép bạn thiết lập kiểm soát truy cập này một cách rất trực tiếp và an toàn. Tôi nghĩ đó là trải nghiệm lập trình thực tế, thực sự phản ánh trực giác về thế giới thực hoặc cách mô tả điều gì đó, sau đó chuyển trực tiếp sang mã có liên quan.

So sánh bảo mật giữa Move và Solidity

Người điều hành Sonal Chokshi: