Tác giả gốc: Tùy Thế Đạo
Năm ngoái, a16z và các tổ chức khác đã thúc đẩy mạnh mẽ chuỗi công khai Move do Sui đại diện, điều này đã khiến ngôn ngữ Move trở lại từ đống đổ nát của Meta Diem, đồng thời, từ thời điểm Sui Move xuất hiện, tiếng nói bất lợi luôn tồn tại:
Nếu chỉ vì ngôn ngữ Move có thể tốt hơn Solidity hoặc các ngôn ngữ phát triển khác, chúng ta có nhất thiết cần một ngôn ngữ hợp đồng thông minh mới không và liệu chúng ta có vui lòng xây dựng Lớp 1 mới từ đầu không?
Gần đây, nhóm a16z Crypto và Sam Blackshear, người đồng sáng lập và CTO của MystenLabs đồng thời là cha đẻ của ngôn ngữ Move, đã thực hiện một cuộc trò chuyện podcast về chủ đề Ngôn ngữ lập trình tiền điện tử, thảo luận về lý do tại sao Move lại là một 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 thảo luận về tư duy thiết kế, hướng đối tượng và lập trình Tài sản, bảo mật và xác minh chính thức được chia sẻ, các công cụ quản trị và cộng đồng, khả năng thích ứng đa nền tảng và các chủ đề khác.
Các nội dung chia sẻ chính bao gồm:
1. Ngôn ngữ lập trình và lịch sử 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à cái nhìn sớm nhất về cách thiết kế một ngôn ngữ để giải quyết các vấn đề như hệ thống kiểu, 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 phù hợp với các chi tiết triển khai của nền tảng, đượ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 một số lỗi khiến Ethereum khó mở rộng quy mô. Move được thiết kế mà không cần thêm bất kỳ thứ gì dành riêng cho blockchain vào ngôn ngữ cốt lõi. Đổi mới ở cấp độ ngôn ngữ mã nguồn sẽ khá quan trọng và những gì Move cuối cùng sẽ có thể cung cấp là trình xác thực 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.
3. Ý tưởng thiết kế của Sui Move
Move là một 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 minh có thể được song song hóa hiệu quả hơn, giúp 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 ở cấp độ giao thức và cho phép người dùng cũng như lập trình viên xem xét chúng.
4. Bảo mật
Trong thế giới của hợp đồng thông minh, chúng ta đang ở trong tình trạng bị ràng buộc. Chúng tôi viết một lượng mã rất nhỏ và nó phải hoàn hảo, đồng thời bảo mật phải là ưu tiên hàng đầu. Bảo mật di chuyển là ngăn chặn các lập trình viên tự giẫm lên chân mình, đồng thời cung cấp cho họ các nguyên mẫu chính xác nếu có thể để họ có thể chống lại các cuộc tấn công.
5. Định 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 vì hầu hết các ngôn ngữ lập trình hướng đối tượng Web2 đều như vậy. Trong Sui Move, bằng cách đặt điểm trung tâm của sự vật lên đối tượng, sẽ có động lực cao để có thể thể hiện quyền truy cập chi tiết chính xác nhất có thể. Cấu trúc lưu trữ toàn cầu của 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 truy cập lại và thiếu kiểm tra quyền trong lập trình hợp đồng thông minh bằng cách xây dựng. Trong Move, thông tin 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 các lỗi ngôn ngữ khi viết hợp đồng thông minh, điều này 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 mà 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. Đơn giản là điều chính, 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 chuỗi EDM vẫn được áp dụng và nó 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. Đề xuất học tập cho nhà phát triển
Đọc nhiều mã là cách tốt nhất để tìm hiểu về ngôn ngữ. Sẵn sàng chia sẻ và tìm hiểu sâu hơn, đồng thời tìm những người thực sự thích chia sẻ mã của bạn với những 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 có thể 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ó.
tiêu đề cấp đầu tiên
Dẫn chương trình Sonal Chokshi Giới thiệu
Chào mừng bạn đến với Web 3.0, một chương trình của nhóm tại a16z Crypto về việc xây dựng thế hệ tiếp theo của Internet. Tôi là chủ nhà của bạn, Sonal Chokshi.
Chương trình này được thiết kế để giúp bất kỳ ai, dù là nhà phát triển, người sáng tạo, kiến trúc sư, lãnh đạo doanh nghiệp hay nhà hoạch định chính sách, đang tìm cách hiểu và đào sâu hơn các vấn đề liên quan đến mã hóa và Web 3.0. Bây giờ chúng tôi đang 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 ngôn ngữ lập trình và tiền điện tử, dành cho cả những người lập trình hợp đồng thông minh hiện tại và những nhà phát triển khác đang tìm cách thâm nhập vào không gian. Đâ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.
Vị khách đặc biệt của chúng ta 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 của Web 3.0. 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, tạo và là tác giả của Move và 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.
Xuyên suốt chương trình, chúng tôi cũng mờiNoah, Kỹ sư nghiên cứu hợp đồng thông minh tại a16z Crypto, anh ấy và một đối tác khác gần đây đã phát triển một ứng dụng khách hạng nhẹ cho Ethereum có tên là Helios và đã giành chiến thắng trong thử thách tối ưu hóa gas.
Chúng tôi cũng mờiEddy Lazzarin, kỹ sư trưởng tại a16z Cryptotiêu đề cấp đầu tiên
Lịch sử lập trình và hợp đồng thông minh
Người dẫn chương trình Sonal Chokshi:
Chúng ta sẽ bắt đầu với lịch sử của chương trình truyền thống với việc Noah nói trước, 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, lập trình truyền thống, lập trình hợp đồng thông minh và ngôn ngữ Move. Cả ba điều đều có lịch sử riêng của chúng, phải không?
Sui CTO Sam Blackshear：
Vâ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ế cú pháp hoặc làm cho mọi người hài lòng, nhưng nó còn hơn thế nữa. Vì vậy, tôi rất thích khung hình lớn này.
a16z Crypto Eddy Lazzarin：
Trên cơ sở này, lập trình truyền thống có nhiều xu hướng khác nhau trong hai hoặc ba thập kỷ qua. Các ngôn ngữ lập trình truyền thống đã thay đổi, với một số chủ đề nóng đến và đi. Đã có một thời gian dài khi các ngôn ngữ lập trình động với việc kiểm tra kiểu rất lỏng lẻo rất phổ biến. Người ta thường tin rằng nhảy vào, quên các loại, quên tất cả các chi tiết kỹ thuật và chỉ 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ề những thứ như hệ thống kiểu, kiểu gõ tĩnh và kiểm tra thời gian biên dịch để biết càng nhiều chi tiết càng tốt về chương trình trước khi chương trình 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ó quá mới nên chúng ta chưa từng thấy loại lịch sử này trong lập trình hợp đồng thông minh, điều này rất khác.
Tôi nghĩ rằng ngôn ngữ Move là bằng chứng sớm nhất mà chúng tôi đã thấy về cách ngôn ngữ có thể được thiết kế để đáp ứng điều này (các vấn đề như hệ thống loại, gõ tĩnh và kiểm tra thời gian biên dịch). Tôi tò mò muốn biết những thay đổi mà chúng tôi mong đợi sẽ thấy trong lập trình hợp đồng thông minh như gõ tĩnh và động? 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ì vậy, điều này liên quan như thế nào đến việc chuyển sang lập trình hợp đồng thông minh? Sam một lần nữa xin vui lòng trả lời?
Sui CTO Sam Blackshear：
Trong không gian hợp đồng thông minh này, có nhiều xu hướng khác nhau với EVM là những người đầu tiên tham gia vào ngôn ngữ hợp đồng thông minh. Mọi người không biết họ muốn làm gì với hợp đồng thông minh? Cách chúng tôi viết chúng hoặc bất kỳ loại nào trong số này Vì vậy, tôi nghĩ rằng 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 khám phá cách sử dụng. Tôi cảm thấy như bây giờ chúng ta đã biết, hoặc ít nhất chúng ta biết điều gì đó về các khối xây dựng.
Xu hướng của hợp đồng thông minh cực kỳ cụ thể theo miền, bạn xác định mẫu cho nội dung, xác định chính sách chuyển nội dung, kiểm tra quyền và kiểm soát truy cập.
Đó là những điều cơ bản, bạn không viết trình biên dịch hoặc hệ điều hành hoặc bất kỳ loại nào trong số đó bằng ngôn ngữ hợp đồng thông minh. Vì vậy, chúng rất, rất tốt, lợi thế của chúng so với các ngôn ngữ lập trình có mục đích chung.
Tôi nghĩ mọi người đánh giá thấp rằng EVM thậm chí còn được coi là một trong những khối xây dựng cơ bản để viết chương trình Ethereum mặc dù tiêu chuẩn ERC-20 đã xuất hiện rất lâu sau khi EVM có thể lập trình được. 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ĩ rằng các loại và việc bỏ qua những thứ này có thể gây ra một khoản nợ kỹ thuật nhất định. Nếu quy mô nhỏ, bạn chỉ muốn di chuyển nhanh, và mã có thể được vứt đi, thì loại nợ kỹ thuật này là hoàn toàn có thể chấp nhận được. Nhưng thật thú vị khi 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 mới thành lập, một công ty nhỏ đang phát triển nhanh chóng, nơi mọi người đều hiểu toàn bộ cơ sở mã và loại nợ kỹ thuật này có thể chấp nhận được.
Nhưng khi nó rất, rất lớn, có rất nhiều người thay đổi mã mà không biết sự phân nhánh của các đối tượng và hệ thống mới mà họ đang xây dựng. Đưa điều này vào hệ thống loại cho phép bạn viết mã một cách rõ ràng, đơn giản và đánh vào rào cản thay vì vô tình tạo ra hàng rào kính mà ai đó sẽ đụng phải sau này.
Ví dụ, như các bạn đã nói, có thể ngăn chặn sự trùng lặp, có thể đặt mức cung tối đa cho một tài sản. 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 ràng buộc rất quan trọng để duy trì sức khỏe và tính bảo mật của dự án của bạn.Biết đượ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. Đó là cách tôi thấy ngôn ngữ Move.
Khi chúng ta tìm hiểu các loại ràng buộc cần thiết để làm điều đúng đắn, giờ đây chúng ta có khả năng đưa chúng vào chính ngôn ngữ đó. Vì vậy, tôi nghĩ rằng nó hơi giống với các loại, như bạn đã nói.
Bạn đã đề cập rằng các loại rất quan trọng đối với sự lành mạnh và an toàn của chương trình.Các bạn nói rằng kiểu gõ động có thể tốt cho các dự án nhỏ, nhưng khi các dự án phát triển, kiểu gõ tĩnh nên được sử dụng. Tôi không đồng ý, tôi nghĩ gõ hoàn toàn tĩnh có thể phù hợp hơn. Đây có thể là một cuốn tiểu thuyết. Nó dành cho sự tỉnh táo của lập trình viên. Điều đáng sợ nhất mà tôi từng thấy là khi tôi nhấn phím tắt điều khiển k, nó sẽ cho tôi biết chữ ký của chức năng là gì. Điều này làm tôi sợ khi tôi viết Python. Tôi nhìn vào chữ ký hàm và chỉ thấy tên của các tham số. Tôi giống như, bạn muốn tôi làm cái quái gì vậy?
a16z Noah：
Tôi không thể tin rằng mọi người chấp nhận ý tưởng viết mã và không bao giờ nhìn vào nó nữa.
a16z Eddy Lazzarin：
Họ chấp nhận giả định mặc định rằng họ có thể ghi nhớ các yêu cầu của hệ thống.
a16z Noah：
Nhưng ngay cả với chương trình 100 dòng, tôi không nghĩ có thể mặc định như vậy.
Sam Blackshear ：
Nó hoạt động, nhưng nó không hoàn hảo.
a16z Eddy Lazzarin：
Tôi nghĩ bạn đúng. Và tôi nghĩ rằng tâm lý đã phát triển. Trước đây, các hệ thống loại được sử dụng để bảo vệ các lập trình viên khỏi đồng nghiệp.Nó rất hữu ích khi công ty khởi nghiệp của bạn trở nê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ó 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 các chương trình bình thường, bạn không triển khai các chương trình khi kẻ tấn công bị ràng buộc 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 chính mình. Nhưng ở đây tôi viết đối tượng được đánh máy độc đáo này sẽ chuyển vào mã của kẻ tấn công và giữ cho nó nguyên vẹn. Hệ thống loại phải giữ cho tôi an toàn.
Như bạn đã nói, đó là một công cụ tuyệt vời mang đến các yêu cầu khác nhau cho bạn và bạn cần thực thi chúng, chẳng hạn như ngăn chặn việc sao chép. Đó không phải là điều bạn cần nghĩ đến trong một hệ thống loại bình thường, hoặc ngăn chặn việc xóa hoặc đảm bảo rằng bạn sử dụng hoặc hủy một giá trị theo một cách nhất định. Tất cả là do chúng tôi đang làm việc trên các hợp đồng thông minh và cố gắng đưa ra một hệ thống loại có ý nghĩa cho những trường hợp sử dụng này, vì vậy cuối cùng chúng tôi sẽ thêm những thứ này để di chuyển và có thể cả 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ực ra, các bạn hãy nói thêm một chút 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, các bạn có thể giới thiệu 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 hiện trạng, như Solidity, Viper, v.v. Biết nội dung nào có thể giúp chúng tôi bắt đầu nhanh hơn.
Sui CTO Sam Blackshear ：
Vâng, tôi đoán những điều cơ bản là nếu bạn muốn viết hợp đồng thông minh, hầu như bạn sẽ luôn sử dụng solidity. 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 đang ở trong hệ sinh thái Polkadot, bạn sẽ sử dụng mực (Lưu ý của Sui World: mực! là ngôn ngữ hợp đồng thông minh do Parity phát triển để viết hợp đồng thông minh trong Rust và biên dịch thành mã Wasm), là ngôn ngữ lập trình hiện có. Nếu bạn đang ở trong hệ sinh thái StarkNet, bạn sử dụng Cairo (Sui World Lưu ý: Cairo là một trong những ngôn ngữ lập trình cho hệ thống bằng chứng STARK).
Nhưng phần lớn, nếu tôi đưa ra lời khuyên về cách viết hợp đồng thông minh, tôi khuyên bạn nên tìm hiểu một số Solidity và sau đó tìm hiểu 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 minh hợp đồng đặt cọc, họ đã tìm thấy một loạt lỗi trong trình biên dịch Viper. Người đã tìm ra những lỗi này hiện đang làm việc ở 16z, anh ấy là Day June, anh ấy là một chuyên gia xác minh chính thức.
Vì Day June là một chuyên gia về xác minh chính thức nên anh ấy hiện đang 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 và nếu bạn muốn trở thành một kỹ sư hợp đồng thông minh thực sự giỏi, bạn cần hiểu EVM ở mức độ vô lý, để bạn có thể biết chi phí xăng của từng hoạt động, họ có thể cho bạn biết chính xác mã liên quan đến chi phí xăng. Đây là thế giới chúng ta hiện đang sống.
a16z Eddy Lazzarin：
Có lẽ đ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ể tìm hiểu về cỗ máy mà bạn đang chạy mã của mình. 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 để hiểu, gần như độc lập với chính ngôn ngữ đó. Đó là những gì đang diễn ra xung quanh bạn, những đồ vật xung quanh bạn, các mã khác nhau được gọi như thế nào. Đây là một điều rất kỳ lạ.
Người dẫn chương trình Sonal Chokshi:
Vậy có đúng là những người gần gũi nhất với việc học Solidity là những người biết JavaScript không?
Sui CTO Sam Blackshear ：
Mọi người nói đó là JavaScript vì nó sử dụng từ khóa hàm, giống như JavaScript. Nhưng thật không may, chúng không giống nhau lắm.
a16z Eddy Lazzarin：
Từ quan điểm ngữ pháp, Solidity thừa hưởng nhiều tính năng của JavaScript. Nếu bạn đang nheo mắt hoặc trong tâm trạng không vui, nó có thể có cảm giác tương tự, nhưng thực ra 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ó bất kỳ ngôn ngữ lập trình tương tự?
a16z Noah：
Vâng, tôi không nghĩ có một ngôn ngữ lập trình tương tự trực tiếp. Nếu bạn đã quen thuộc với Was (Sui World Note: WebAssugging Studio, một công cụ trực tuyến để biên dịch mã C/C++ và Rust sang định dạng WASM. ), Đây có lẽ là điều gần nhất mà các mã này thực thi độc lập, nhưng yêu cầu một số mức độ giao tiếp. Nhưng nó vẫn không giống lắm, cách suy nghĩ hoàn toàn khác nhau và những điểm tương đồng bề ngoài có thể nguy hiểm.
a16z Eddy Lazzarin：
Có lẽ có liên quan là 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ó một 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 xuống một số con đường khủng khiếp?
Người dẫn chương trình Sonal Chokshi:
Đó là một câu hỏi hay.
Sui CTO Sam Blackshear ：
Đó là một câu hỏi hay. Năm 1977, ngôn ngữ C được phát hành, cũng là năm Standard ML được phát hành. ML tiêu chuẩn có sức ảnh hưởng cực lớn. Bây giờ, 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ĩ rằng nhiều người đang nghĩ về một tương lai thay thế trong đó thay vì C là chủ đạo, các ý tưởng về ML tiêu chuẩn được chấp nhận rộng rãi, như gõ mạnh, an toàn tích hợp.
Người dẫn chương trình Sonal Chokshi:
Vì vậy, xu hướng này trong công nghệ máy tính là gì? Tôi không nói rằng đó là một sai lầm, nhưng tôi nghĩ rằng một ngôn ngữ như Standard ML trông rất hiện đại ngay cả ngày nay. Tưởng tượng ra vũ trụ thay thế đó là một điều thú vị, và tôi đã rất ngạc nhiên khi lần đầu tiên khám phá ra nó.
a16z Eddy Lazzarin：
Vì tò mò, tại sao bạn nghĩ rằng các ngôn ngữ như C và tương tự lại rất đơn giản và bắt buộc? 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, đó là cảm nhận của tôi về C, tại sao chúng ta lại đi theo con đường này?
Sui CTO Sam Blackshear ：
Tôi nghĩ rằng 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 C, và nếu bạn muốn viết những chương trình hiệu quả hoặc vượt qua ranh giới của điện toán, 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 theo tôi, lập trình chức năng rất khó, nó phản trực giác theo nhiều cách. Tôi không nói rằng ngôn ngữ C không khó, nhưng tôi nghĩ nó dễ bắt đầu hơn. Rồi bạn nhận ra, mình đã làm một việc rất phức tạp, hay đúng hơn là khó lý giải, nhưng đã quá muộn. Đó là một ý tưởng hay, các ngôn ngữ chức năng thực sự 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ể tự mình nghĩ khá tốt về mã của mình và mọi thứ diễn ra khá tốt.
a16z Eddy Lazzarin：
Tôi nghĩ một ngôn ngữ như C sẽ đơn giản hơn nếu bạn nghĩ nhiều về cách máy tính hoạt động ở cấp độ phần cứng. Nhưng nếu bạn không biết nhiều về ngôn ngữ lập trình, thì ngôn ngữ C sẽ dễ dàng hơn để bắt đầu. Nhưng nếu bạn biết rất rõ về ngôn ngữ lập trình, thì tôi nghĩ ML và các loại ngôn ngữ lập trình chức năng có nhiều điều để khám phá hơn.
Sui CTO Sam Blackshear ：
Đây là một câu trả lời hình ảnh lớn. Nhưng điều tôi muốn nói là về vấn đề 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 này bởi vì tôi vẫn nghe thấy lập trình chức năng tuyệt vời như thế nào, nhưng tôi 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 chức năng tốt như vậy, 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 tại? Đó là cách nó làm tôi ngạc nhiên.
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 hàm 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 phần hay 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 Rust về cơ bản là một ngôn ngữ mệnh lệnh, phải không? Nhưng nó có tất cả những hạt bụi cổ tích tuyệt vời đến từ việc nhìn chằm chằm vào chúng.
Sui CTO Sam Blackshear ：
Nói chung, tôi nghĩ vấn đề thực sự là các ngôn ngữ mệnh lệnh đã có quá nhiều ảnh hưởng kể từ năm 1977. Sau đó, có PRFP, như bạn đã nói, nó không phải là tuyệt vời nhất, nó có những ý tưởng tuyệt vời của riêng nó, và khi cô lập, mọi người đều có vấn đề của riêng mình. Bây giờ chúng ta chỉ thấy những người lai thực sự như Rust kết hôn với họ một cách đẹp đẽ. Nó thực sự thay đổi cảnh quan.
Vì vậy, một trong những điều tôi muốn đề cập đến là cái mà Tony Hoare gọi là lỗi tỷ đô khi tham chiếu nút. Mặc dù lúc đó anh ấy có thể đã phóng đại, nhưng rõ ràng sai lầm còn đắt hơn là không mắc phải.
a16z Eddy Lazzarin：
tiêu đề cấp đầu tiên
Phát triển sáng tạo hợp đồng thông minh
a16z Noah：
Tôi thực sự tò mò rằng bạn chưa nói nhiều về những đổi mới ở 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 ：
Đó là một câu hỏi tuyệt vời. Tôi không nghĩ mọi người đã suy nghĩ đủ về sự khác biệt, 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ế, bên cạnh EVM và lớp máy ảo mới, có nhiều đổi mới, 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 theo nhiều cách và thú vị.
Tôi nghĩ rằng nếu Move trở thành tiêu chuẩn pháp lý cho Web 3.0 mà chúng tôi mong đợi, thì sự đổi mới ở lớp máy ảo sẽ chậm và tăng dần. Vì phần lõi đã được sửa nên chúng tôi sẽ chỉ thêm nội dung mới chứ không phải thiết kế lại hoàn toàn.
Tuy nhiên, tôi nghĩ rằng 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 ngôn ngữ này gắn liền với định dạng mã byte. Tuy nhiên, khi ngày càng có nhiều khách hàng sử dụng hợp đồng thông minh, chú trọng đến bảo mật, tôi có thể tưởng tượng rằ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ể bắt đầu bằng cách viết ra các dữ kiện trước đây của mình và sau đó tổng hợp thông tin của chúng cho bạn trong chương trình hoặc một gợi ý về những hạn chế.
Có lẽ bạn có thể bắt đầu bằng cách viết các dữ kiện trước khi Di chuyển, sau đó để chương trình tổng hợp điền vào chương trình cho bạn hoặc đề xuất các ràng buộc.
Ví dụ: bạn có thể viết Di chuyển trong ngữ cảnh của một trò chơi rất cụ thể trông giống như một 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 nghĩ đến việc tích hợp Move, nhưng không muốn tích hợp 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, 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ó đã vượt qua 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 mẫu này nhằm thiết kế các 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ó thành kiến khi cho rằng Viper cho bạn nhiều cơ hội để thử nghiệm ở cấp độ ngôn ngữ nguồn.
a16z Eddy Lazzarin：
Bạn nghĩ gì về tất cả các ngôn ngữ mã byte EVM thay thế? Bạn có lạc quan rằng có những nỗ lực thú vị như FE, Iron, Viper, v.v. để xây dựng các ngôn ngữ thông minh hơn, phức tạp hơn cho EVM không?
Sui CTO Sam Blackshear ：
Vì vậy, đây là những ngôn ngữ mã nguồn khác nhau được biên dịch sang EVM bytecode.
a16z Eddy Lazzarin：
Có, được biên dịch thành mã byte EVM.
Sui CTO Sam Blackshear ：
Khi chúng tôi bắt đầu thiết kế Move tại Facebook, chúng tôi đã xem xét Solidity và Viper khi thấy các ngôn ngữ mã nguồn khác đang xây dựng EVM và đó là lúc chúng tôi bắt đầu xây dựng EVM. Điều cuối cùng chúng tôi đi đến 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 để các giá trị đã nhập chảy trên các ranh giới đáng tin cậy cũng như quá trình ra quyết định năng động, v.v. on.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 gặp khó khăn hơn. Có lẽ họ có thể thực hiện xác thực nâng cao hơn,Nhưng cuối cùng, những gì Move có thể cung cấp và những gì chúng tôi nghĩ là quan trọng, là trình xác thực mã và bảo vệ cấp VM khỏi các lập trình viên khác.
Một 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 bao nhiêu lần trên EVM để có một 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 Với các biện pháp bảo vệ cơ bản này được tích hợp trong VM, bạn sẽ nhận được kết quả không tốt bằng một số đường dẫn khác. Tôi không xấu hổ vì tôi nghĩ Half hay, mà vì tôi không nghĩ trạng thái kết thúc hấp dẫn như những con đường khác.
Tôi nghĩ rằng các ngôn ngữ hợp đồng thông minh ban đầu, đặc biệt là EVM, phù hợp với các chi tiết triển khai của nền tảng, được thiết kế cho Ethereum, bao gồm cá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 một số loại mật mã nhất định, v.v.
Tôi nghĩ rằng điều này khiến việc sử dụng EVM trên một chuỗi không giống như 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 quyết định thiết kế mà Ethereum đã đưa ra và có thể trong một số trường hợp, một số thứ đã tạo ra Ethereum khó khăn. Lỗi mở rộng.
Khi thiết kế Move, chúng tôi rất ý thức về việc không thêm bất kỳ thứ gì dành riêng cho chuỗi khối vào ngôn ngữ cốt lõi và làm cho nó độc lập nhất có thể với chuỗi khối cụ thể.
Vì vậy, bạn có thể lấy 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 đang thực hiện điều đó ở Ú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 nghĩ 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 làm cho các kỹ năng của bạn đa nền tảng, thay vì chỉ tập trung vào 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ư rất nhiều tiền vào các công cụ, rất nhiều tiền vào các thư viện công cộng và tất cả những thứ bạn thực sự cần để một ngôn ngữ trở thành một tên tuổi lớn và thành công.
Đó là những gì chúng tôi đã cố gắng thực hiện ngay từ đầu và giờ đây chúng tôi đã 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：
Đối với tôi, có vẻ như đây là chủ đề cơ bản của node.js, phải không?
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ẻ các thư viện khác nhau. Mã hiện tại có thể bắt đầu 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ó tất cả các loại nhà phát triển có thể không lập trình phụ trợ, nhưng có thể bắt đầu nhảy vào và biến nó thành lĩnh vực của họ.
Sui CTO Sam Blackshear ：
Tôi nghĩ rằng đó là một so sánh tốt. 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ố phân chia và phân chia quản trị cấu hình rất cao, và mọi cộng đồng ngôn ngữ lập trình đều có nhiều phân chia và hướng quản trị cấu hình cao. Tôi đã học qua Node và đó là một trong những mục 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 già thường trú trong chương trình radio mà tôi yêu thích.
a16z Noah：
Vì vậy, tôi có một điểm đối lập, hay đúng hơn là tôi có một ý tưởng hay.Tôi đã tự hỏi tại sao không ai xây dựng OP Rollup cho Move, điều đó sẽ thực sự tuyệt vời,Xem xét rằng những người Rollup của OP được triển khai trên Ethereum, họ sử dụng chữ ký MetaMask và ECDSA, nhưng dường như không sử dụng định dạng chữ ký giống như chúng tôi, giống như Move dường như không sử dụng ECDSA.
Sui CTO Sam Blackshear ：
Có, chúng tôi hỗ trợ các định dạng chữ ký EdDSA và ECDSA 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ứ thực sự thú vị. Tuy nhiên, khi tôi đang cố gắng học Di chuyển, tôi cứ nhìn chằm chằm vào Món tráng miệng và Con 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ĩ rằng thách thức mà chúng tôi vẫn đang cố gắng tìm ra là chọn một nền tảng, chọn một món tráng miệng, chọn một chiếc Optus, tìm hiểu sâu về nó và sau đó bạn thấy rằng các kỹ năng và mã của mình có thể dễ dàng chuyển sang một nền tảng khác. Tôi nghĩ rằng 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ó lẽ một sự tương tự phụ thuộc vào việc bạn có coi SQL là một kỹ năng di động hay không. Có nhiều phương ngữ của 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, nếu bạn tinh 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ể hơi nhầm lẫn về tên hàm cụ thể hoặc loại cụ thể, nhưng đại khái là cùng một hình dạng. Tôi nghĩ điều này làm cho SQL trở nên rất mạnh mẽ và lâu bền. Đó là lý do tại sao nó vẫn là một phần của ngôn ngữ chung về 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 ：
tiêu đề cấp đầu tiên
Những điều độc đáo về lập trình hợp đồng thông minh
Người dẫn chương trình Sonal Chokshi:
Chúng ta đã thảo luận qua lại về lập trình hợp đồng truyền thống và hợp đồng thông minh, những hạn chế và khác biệt cụ thể, và thậm chí một số điểm tương đồng giữa lập trình hợp đồng thông minh và bước đi. 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 khí trong Solidity. Mặc dù tài nguyên máy tính tương đối phong phú trong nhiều trường hợp, 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 chuỗi khối, điều đó có nghĩa là nó ít được động chạm và cân nhắc hơn. Tôi nghĩ khái niệm bằng ngôn ngữ tài nguyên mà bạn sử dụng có thể là một nguồn tài nguyên thú vị để lập trình hợp đồng thông minh.
Sui CTO Sam Blackshear ：
Đó là điều mà chúng tôi rất tập trung vào, chúng tôi đã tích hợp Đo lường khí đốt vào EVM, như bạn đã nói, rất khác so với các ngôn ngữ lập trình truyền thống.
Tôi nghĩ xu hướng trong tương lai là Gas Meeting sẽ ngày càng trở nên thô hơn, nhiều hơn để ngăn chặn các vấn đề nghiêm trọng như lạm dụng tài nguyên, hơn là thực sự chi tiết cho từng lệnh.
Tôi thực sự nghĩ rằng những thứ như Gas Golfing (Sui World Note: Gas Golfing đề cập đến thách thức đối với các nhà phát triển để viết mã tiết kiệm gas nhất trong một loạt các tương tác chuyển đổi hợp đồng thông minh) rất thú vị, nhưng chúng thực sự rất quan trọng đối với việc viết mã .Cả phong cách và an toàn đều có hại.
Trớ trêu thay, lý do chúng ta chỉ biết về mô hình tính phí cho mỗi lệnh có lẽ là vì nếu bạn có một máy ảo khổng lồ, thì sự khác biệt giữa việc chạy 100 nghìn lệnh so với chạy 500 nghìn lệnh là không đáng kể khi thực sự đo thời gian chạy.
Vì vậy, tại sao chúng tôi tính phí cho mỗi đơn đặt hàng? Vì vậy, tôi nghĩ rằng chúng ta sẽ thấy xu hướng làm thế nào để làm cho điều này 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à hàng tấn cụm lắp ráp nội tuyến trong mã Solidity, điều đó nhắc tôi nhớ rằng chúng ta còn sớm như thế nào, bởi vì đây không phải là một thách thức lập trình mà một nhà phát triển hợp đồng thông minh nên xem xét, đây không phải là dấu hiệu của sự trưởng thành. hệ sinh thái phát triển. Nhưng chúng tôi đang di chuyển theo hướng đó. Tôi đồng ý rằng chúng ta cần xem xét các trường hợp cạnh. 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, đó là trường hợp của 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ó lẽ là quá nhiều việc.
Người dẫn chương trình Sonal Chokshi:
Chúng tôi đã nói về việc tối ưu hóa gas, loại, tài sản và bảo mật. 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ậ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 tôi nghĩ về hoạt động khí đốt, tôi thích thực hiện việc tối ưu hóa khí đốt cực độ.
Tuy nhiên, khi chúng tôi đang xử lý các hợp đồng thông minh thực tế nắm giữ tiền thật, lời khuyên chung của tôi là trừ khi bạn có thể cố gắng sử dụng trạng thái ít hơn một chút so với những gì bạn đã sử dụng trước đây, bạn nên được tổ chức hợp lý. Đó là lần duy nhất tôi sẽ 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ư tài nguyên vĩnh viễn 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 điểm này, vì tôi nghĩ về cơ bản nó rất đắt. Nếu một nền tảng cho phép mọi hợp đồng chạm vào bất kỳ trạng thái nào, thì sẽ khó có thể song song hóa. Và cách tiếp cận của Squeeze và một số nền tảng blockchain mới khác là giới hạn rõ ràng trạng thái mà các giao dịch có thể truy cập, ít nhất hãy cho tôi biết một số. Bằng cách này, ở cấp độ cao, nền tảng có thể dễ dàng thực hiện song song các giao dịch 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ĩ: nhanh nhất có thể khi truy cập trạng thái và không chạm vào trạng thái không cần thiết, để trình 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：
Điều này có mở ra một thực tế là không phải tất cả các trình xác thực đều cần tải xuống trạng thái đầy đủ ngay cả trong các tình huống không nhập vai không? Có khả thi không nếu bạn có thể dễ dàng tách trạng thái để trình xác thực chỉ phục vụ các giao dịch mà nó có thể xử lý?
Sui CTO Sam Blackshear ：
Tôi nghĩ rằng nó thực sự có thể nhận ra một thế giới như vậy. Điều này cũng mở ra một con đường cho các cách tiếp cận khác nhau.
Hãy để tôi tóm tắt lại, từ quan điểm của một lập trình viên, việc có thể tiếp cận toàn thế giới qua các giao dịch khác nhau là rất có giá trị. Tuy nhiên, chúng tôi không thể nhấn mạnh lợi thế này nhiều đến mức nó phải được triển khai thông qua Tổng số 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 để người dùng nhận thấy.
Tôi nghĩ rằng giá trị của chuỗi khối đến từ sự trừu tượng này: có một sổ cái, 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ả chúng cùng một lúc. Theo quan điểm của một lập trình viên, đây chính là giá trị của chuỗi khối. 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ó trở nên thưa thớt hơn để các trình xác thực 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 worker, mỗi worker chịu trách nhiệm cho một phần của trạng thái. Nhưng từ quan điểm của lập trình viên và thậm chí từ quan điểm của những người xác thực khác, nó trông giống như một thực thể logic làm mọi thứ.
tiêu đề cấp đầu tiên
Thay đổi 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ố khía cạnh độc đáo liên quan đến lập trình hợp đồng thông minh. Những thay đổi khác trong suy nghĩ? Chúng ta đã nói một chút về, 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à từ những ngày đầu của máy tính, chúng ta đang ở trong thế giới của sự dư dả, nhưng trong thế giới này, chúng ta lại trong thế giới của giới hạn. Đó là một ví dụ về cách suy nghĩ. Những suy nghĩ khác thay đổi? Đặc biệt đối với mỗi bạn, với tư cách là những lập trình viên tiếp xúc với lập trình hợp đồng thông minh, điều gì đã làm bạn ngạc nhiên, dạy bạn hoặc khiến bạn suy nghĩ khác về một số điều nhất định?
a16z Eddy Lazzarin：
Có lẽ một ví dụ hơi ngớ ngẩn, tôi vẫn nhớ lần đầu tiên tôi biết được cách đây vài năm 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ư mã thông báo. Thay vào đó, có một hợp đồng Token ghi lại địa chỉ nào có số dư bao nhiêu. Khi bạn muốn chuyển mã thông báo cho ai đó, bạn không gửi cho họ một số mã thông báo. Thay vào đó, bạn cần phải ký kết hợp đồng và thực hiện tất cả các thao tác cấp thấp này, thay đổi số dư do địa chỉ của bạn và địa chỉ của họ nắm giữ. Bạn có quyền thao tác và thay đổi hợp đồng đó. Đó là một cách tiếp cận rất phản trực giác, một sự thay đổi thú vị trong suy nghĩ về Move mà tôi nhận thấy lần đầu tiên trong EVM và Slippery. Đó là một sự thay đổi thú vị trong suy nghĩ, bởi vì những từ tiếng Anh mà chúng ta nghe nhiều 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 đó là khi bạn thực sự làm điều đó. Trong thế giới bình thường, chúng tôi rất quan tâm đến năng suất của nhà phát triển, bởi 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 khi trong thế giới của 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 theo mọi cách có thể. Nếu không, bạn sẽ làm 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àm thế nào để làm cho nó trở nên hoàn hảo, sau đó những người đánh giá cũng làm như vậy, đánh giá 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 suy nghĩ. Trong thế giới lập trình, ít nhất là từ những ngày đầu tiên 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ế.
a16z Eddy Lazzarin：
Một thay đổi khác trong suy nghĩ là trong thế giới của mã thông báo ERC 20, địa chỉ của bạn không đại diện cho số dư mã thông báo. Bạn không thể gửi Mã thông báo, bạn phải truy cập hợp đồng Mã thông báo, tìm số dư Mã thông báo tương ứng với địa chỉ trong hợp đồng Mã thông báo, sau đó hoàn tất việc chuyển Mã thông báo bằng cách sửa đổi địa chỉ và số dư. Đây là một cách suy nghĩ khá phản trực giác, nhưng trong EVM và Move, đó là một sự thay đổi rất quan trọng trong suy nghĩ.
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 một đoạn mã nhỏ và nó phải hoàn hảo, bởi vì đoạn mã này có thể liên quan đến sự an toàn của quỹ của hàng trăm triệu người. Bạn phải xem xét kỹ lưỡng mã để đảm bảo mã đó chính xác.
Ngoài ra, nâng cấp hợp đồng thông minh khó hơn 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 suy nghĩ về cách hỗ trợ nâng cấp an toàn và tin cậy, làm cho nó 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 lập, điều này có thể không quen thuộc với những người từ 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, bạn cần xem xét không chỉ việc sử dụng ứng dụng dự kiến 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ó những cách để ẩn mình, 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ế hành động của kẻ tấn công, v.v.
Nhưng toàn bộ quan điểm của hợp đồng thông minh là những gì bạn tạo ra 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 mặt lợi và mặt hại của tình huống này. Đây chắc chắn là một sự thay đổi tư duy từ lập trình truyền thống.
Người dẫn chương trình Sonal Chokshi:
Đây có phải là một câu hỏi rất quan trọng và nên được ưu tiên khi chúng ta thảo luận về cách viết hợp đồng thông minh và sử dụng ngôn ngữ lập trình hợp đồng thông minh?
Sui CTO Sam Blackshear ：
Chắc chắn rồi. Đó thực sự là điều yêu thích của tôi để nói về. Điều này làm tôi rất sợ, vấn đề mà các nhà thiết kế ngôn ngữ hợp đồng thông minh cần xem xét là bảo mật. Đó là trọng tâm chính, thậm chí có thể là trọng tâm duy nhất cho đến khi chúng ta giải quyết vấn đề đó.
Theo tôi, bảo mật hợp đồng thông minh là một 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 điều này là bạn có thể nhìn vào Ethereum và solidity, cũng như các nền tảng phổ biến nhất, 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, họ thực sự hiểu về chuỗi khối cơ bản, họ rất có ý thức 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 tỷ đô la.
Nhưng nếu bạn xem hồ sơ bảo mật hợp đồng thông minh ở bất cứ đâu, thì nó khá tệ và đó không phải là 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ĩ rằng ngôn ngữ làm cho nó khó khăn hơn. Vì vậy, nếu bạn xem trang web yêu thích của tôi, rakt.news, bạn có thể xem bảng xếp hạng hoặc xem mười vụ hack trị giá hàng chục hoặc hàng trăm triệu đô la này rất thường xuyên và xảy ra hàng tuần hoặc hàng tháng tùy thuộc vào quy mô. Đồng thời, cộng đồng nhà phát triển hợp đồng thông minh rất nhỏ, chỉ 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 những người chúng tôi có là những người chăm chỉ nhất và có ý thức về an toàn nhất, nhưng các hoạt động phát triển và hồ sơ an toàn không bền vững, thì tôi nghĩ kết luận của bạn là không có cách nào không gian này có thể tồn tại mà không tạo ra sự an toàn Nếu vấn đề vẫn tiếp diễn phát triển tồi tệ hơn, điều đó có thể có nghĩa là nó không phát triển chút nào, hoặc giống như các tổ chức tài chính lớn hoặc các công ty muốn tham gia vào Web3, họ đang xem liệu họ có phải thuê các nhà phát triển hợp đồng thông minh hay 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ể ở bên lề. Vì vậy, với tư cách là người đang cố gắng thiết kế một ngôn ngữ hợp đồng thông minh mới, bảo mật phải là mối quan tâm đầu tiên của bạn.
Người dẫn chương trình Sonal Chokshi:
Các bạn thực sự đã ám chỉ điều đó trong bối cảnh không bị mất tài sản, nhưng bạn muốn nói cụ thể hơn là gì vì nó rất quan trọng?
Sui CTO Sam Blackshear ：
Ý tôi muốn nói về bảo mật là cả hai chúng tôi đều ngăn chặn các lập trình viên tự giẫm lên chân mình và cung cấp cho họ các nguyên mẫu chính xác nhất có thể để họ có thể chống lại các cuộc tấn công vì hợp đồng thông minh là một thiết lập nơi mã của bạn được triển khai trong một cuộc tấn công Bên cạnh kẻ tấn công, kẻ tấn công có thể gọi trực tiếp mã của bạn, 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 mã byte là mã nguồn mở.
Cho đến nay, đây là môi trường lập trình có nhiều đối thủ nhất mà chúng tôi từng thấy và là nơi mắc sai lầm đắt giá nhất. Vì vậy, tôi nghĩ rằng nếu bạn đang nói về thiết kế lập trình hợp đồng thông minh, thì bảo mật phải luôn được đặt lên hàng đầu. Khi chúng tôi giải quyết vấn đề bảo mật, chúng tôi có thể nghĩ về các yếu tố biểu cảm khác, nhưng đây là câu trả lời hơi tẻ nhạt 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? một số ví dụ về điều này là gì?
Sui CTO Sam Blackshear ：
Tôi nghĩ điều quan trọng nhất là tính đóng gói, cụ thể là các tính năng phụ riêng lẻ của tính năng đóng gói. Khi bạn viết mã, bạn không thể dự đoán kẻ tấn công sẽ làm gì, vì vậy bạn cần có khả năng suy luận mà không cần đoán trước những gì kẻ tấn công sẽ làm. 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 bạn viết mã nguồn sẽ ở đó khi bạn xuất bản mã của mình trên chuỗi khối và những người khác dựa vào bật Nó vẫn tiếp tục và tương tác với nó.
Chúng tôi quan sát thấy rằng một số tính năng phổ biến trong các miền 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 phổ biến. 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, và bạn có thể lập trình dựa trên giao diện đó, và tất cả đều ổn và tốt. Nhưng chúng tôi có một câu châm ngôn: Trong một thế giới mà mã là luật, giao diện là tội ác.
a16z Noah：
Đây là một trò đùa, chúng ta hãy dừng lại một phút. Trong một thế giới nơi mã là luật, giao diện là 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 nhảy qua nó quá nhanh.
Sui CTO Sam Blackshear ：
Đúng chính xác. Ý tưởng ở đây là giao diện không xác định hành vi, nó xác định hành vi dự kiến. Ví dụ, khi bạn đọc thông số kỹ thuật của giao diện, tên tham số hoặc thậm chí cả kiểu, nó sẽ cho bạn biết bạn muốn hoàn thành đ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 ra bạn đang để lại một ô trống cho kẻ tấn công, thì người khác sẽ đ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ó 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ụ: vào lại yêu cầu lập lịch trình động. Ví dụ: nếu bạn hủy lập lịch trình động, thì sẽ không có mục nhập lại nào cả. Những thứ như mã thông báo độc hại trong Ethereum xảy ra do bạn viết lại chức năng chuyển tiền và mọi người đều biết điều đó bằng trực giác, 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 khiến nó làm điều gì đó ngoài dự kiến, chẳng hạn như ăn cắp tiền. Đó là một ví dụ về một tính năng mà nếu bạn loại bỏ nó, việc lập luận về mã của bạn và đóng gói nó một cách thích hợp sẽ trở nên dễ dàng hơn nhiều bởi vì mỗi khi bạn nhìn thấy một trang web cuộc gọi, bạn biết chính xác nó sẽ làm gì, bạn không phải lo lắng về các tính năng khác. những người làm những điều khiến bạn ngạc nhiên sau đó.
a16z Eddy Lazzarin：
Nói một cách chính xác, tôi nghĩ phép loại suy giống như nếu bạn định nghĩa một giao diện về một chiếc ghế, có bốn chân và một chỗ ngồi, và bạn mô tả nó ở cấp độ cụ thể, không phải cấp độ hành vi, những gì bạn không mô tả có thể là ẩn ý. hoặc mặc định Những thứ khác về chiếc ghế, chẳng hạn như nó có tính toàn vẹn về cấu trúc nào đó, nó là một loại vật liệu nhất định, nó được đặt theo một cách nhất định.
a16z Eddy Lazzarin：
Có thể bị phá vỡ, nghĩa là một giao diện chỉ là một tập hợp các 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：
Đó chính xác là định nghĩa.
a16z Eddy Lazzarin：
Định nghĩa mọi thứ ở cấp độ sai. Tôi tò mò.
Sui CTO Sam Blackshear ：
Nhưng làm thế nào để bạn mô đun hóa tốt ngoài các giao diện? Nếu giao diện là một tội ác, thì tôi có lẽ là một 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à 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ó một nền tảng dựa trên mô-đun trong đó các mô-đun tuân theo 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 mô-đun plug-and-play của Super Express? Không có giao diện tiêu chuẩn hóa? Làm thế nào để nhận tài sản thừa kế?
a16z Eddy Lazzarin：
Giống như tất cả những điều này để làm với giao diện?
Sui CTO Sam Blackshear ：
Đây chính xác là câu hỏi đúng để hỏi. Họ có thể tranh luận chống lại điều này cả ngày, nhưng làm thế nào về việc cung cấp thứ gì đó khiến bạn viết mã hữu ích? Giống như nếu bạn không được phép ra khỏi nhà hay gì đó, thì không có tội. Nhưng cách chúng tôi làm là giao diện và kế thừa không phải là cách duy nhất, tôi có xu hướng nghĩ về bố cục. Chúng tôi cung cấp một số nguyên mẫu thành phần không yêu cầu giao diện bộ lập lịch động.
Một trong số đó là thuốc generic. Chúng tôi có kế thừa thời gian chạy trông rất giống với những gì bạn có. Clr (Sui World Note: 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 thì điều này sẽ trở nên trừu tượng rất nhanh.
Một cái gì đó giống như ERC-20 của bạn, rõ ràng là một tiêu chuẩn mã hóa cơ bản quan trọng. 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ó sẽ không hữu ích lắm. Trong một ngôn ngữ như Move, bạn xác định một loại điểm được gọi là t, trong đó t là tham số loại chung, sau đó triển khai các hàm cho đồng xu, ví dụ: hàm nối 2 điểm lại với nhau. Điều này áp dụng cho tất cả các loại tiền xu. Nó không phải là thứ mà ai đó muốn che đậy. Bạn xác định chia tách.
Khi bạn muốn ai đó tùy chỉnh hành vi của mã thông báo, hãy sử dụng cái được gọi là mẫu khả năng, chẳng hạn như đối với mã thông báo, một trong những điều bạn có thể muốn tùy chỉnh là tổng nguồn cung hoặc về cơ bản hơn chính sách của nó là gì? Bạn có thể diễn đạt nó như sau: OK, vì vậy bạn có các cấu trúc điểm thuộc loại t, và sau đó có các cách khởi tạo khác nhau của t, chẳng hạn như đô la, bảng Anh hoặc một số 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 của 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 của kho quỹ. Sau đó, có các logic khác để đảm bảo rằng chỉ những người nắm giữ khả năng kho bạc của t mới có thể đúc và tiêu hủy các Token loại t. Bạn có thể lấy dung lượ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 đối với tổng nguồn cung. Bạn có thể đặt nó ở đâu đó, nói rằng chỉ bình luận vào thứ ba, nhưng không phải vào thứ năm. Bạn đảo ngược luồng điều khiển, cho phép bạn thực hiện các kết hợp tùy ý. Đây là một ví dụ về thủ thuật, nhưng thủ thuật này hoạt động khá phổ biến ở mọi nơi và 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ể, 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 có nghĩ rằng khả năng là một hạn chế mà bạn có thể thêm vào một giao diện trông giống như một lập trình viên truyền thống không?
Sui CTO Sam Blackshear ：
Vâng, tôi nghĩ rằng hầu hết các mẫu giao diện này có thể được biến đổi khá dễ dàng. Nó khó biên dịch hơn một chút, nhưng bạn có thể lập luận rằng đó là mô hình khả năng tương đương với 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ó thấy điều này thỏa mãn không? Hãy thoải mái không đồng ý, một chút xung đột là một điều tốt.
Sui CTO Sam Blackshear ：
Tôi ổn với điều đó, bởi vì tôi nghĩ nếu bạn có thể có các mô-đun hoặc cấu trúc với các khả năng nội tại có thể được đưa vào các mô-đun có hành vi được xác định trước, thì bạn có thể kết thúc với chính hành vi đó, giống như các mô-đun có thể làm điều đó. 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 nội tại bên trong cấu trúc đó. Điều này thực sự hoạt động rất tốt, bởi vì bạn có thể nhận được các cơ quan đăng ký kiểu cấp phép thực sự tốt, và chúng xuất hiện gần như tự nhiên, giống như cái được gọi là cơ quan đăng ký DS-Off, phải không?
a16z Noah：
tiêu đề cấp đầu tiên
Lập trình hướng đối tượng và hướng nội dung
a16z Eddy Lazzarin：
Vì vậy, tôi có thể đi trước câu tục ngữ một chút, nhưng những khả năng này có hiển thị với hệ thống loại không? Tại thời điểm nào trong chương trình, các khả năng này có thể nhìn thấy được trong quá trình phân tích tĩnh của chương trình? Nếu tôi viết một số mã dành riêng cho quá trình khởi tạo trong đó có khả năng, liệu có thể phát hiện sớm rằng tôi đang vi phạm khả năng đó trước khi tôi chạy nó không?
a16z Noah：
Có, các khả năng này hiển thị đối với hệ thống loại và 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 khởi tạo cụ thể có khả năng, tôi có thể phát hiện ra rất sớm nếu tôi vi phạm khả năng mà không cần chạy nó trên máy ảo.
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 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 Move và cách cấu trúc đó liên quan đến thứ gì đó giống như mức độ khả năng giống như kiểm toán. Nếu đó không phải là một sự phân tâm.
Trong Move, bạn có các kiểu cấu trúc và giống như các cấu trúc trong các ngôn ngữ khác, chúng có thể có các trường, các trường thuộc kiểu nguyên thủy hoặc các cấu trúc khác. Điều thú vị hơn, và có lẽ còn 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ư đánh dấu các giao dịch. Chúng khai báo các thao tác dựng sẵn mà bạn được phép thực hiện trên cấu trúc.
Điều quan trọng là bạn không thể làm được những điều đó nếu bạn không có khả năng. Một khả năng tương đối đơn giản là rất quan trọng, đó là khả năng sao chép. Nếu bạn có một loại Token hay đại loại là Token không đồng nhất, trong máy tính chỉ là một số bit, nhưng bạn không muốn cho phép người khác tùy ý sao chép thứ này.
Trong Move, nếu bạn không khai báo cấu trúc của mình có khả năng sao chép, thì bạn không thể sử dụng man copy tương đương của chúng tôi.
Vì vậy, những thứ như số nguyên và chuỗi có bản sao. Nhưng nếu bạn không muốn loại của mình có khả năng bị sao chép, thì bạn không cho nó. Và sau đó là các khả năng khác, chẳng hạn như loại bỏ, được gọi là khả năng loại bỏ. Đó là nơi mà nội dung loại tuyến tính thú vị xuất hiện, nếu bạn muốn loại bỏ thứ gì đó, chẳng hạn như đặt nó ra khỏ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 bỏ qua, cách duy nhất để loại bỏ nó là xác định bất kỳ chính sách nào mà các mô-đun loại đó mong đợi.
Thời gian chạy ngôn ngữ chung (CLR) Như 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 không cho phép Mã thông báo của mình giảm khả năng. Sau đó, không có cách nào để loại bỏ nó ngoài chức năng ghi được xác định trong mô-đun nơi nó được khai báo, cập nhật tổng cung. Đây là tất cả các thủ 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, tôi sẽ không đi 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 toán và chương trình kiểm toán 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 tuyên bố nói rằng chỉ có một điều như vậy, thì kiểm toán viên có thể sử dụng điều này để chứng minh tài sản này. Do đó, khả năng và đảm bảo hệ thống loại đi đôi với nhau.
a16z Noah：
Khi bạn đề cập đến drop, tôi muốn nói về điều yêu thích của tôi. Bạn có thể nói một chút về chế độ khoai tây nóng là gì không? Nếu có bất kỳ nội dung thú vị nào khác như thế này, thì đó là một trong những điều kỳ lạ yêu thích của tôi từ Move.
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 năng lực. 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 có thể 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 sẽ biến mất. Nhưng đôi khi hàm hủy đảm bảo yếu hoặc bạn không thể chỉ 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ỳ lạ, nhưng nó thực sự khá mạnh mẽ, đặc biệt là khi 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, và 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 chớp nhoáng trên ethereum, đó là một tiêu chuẩn, bạn có thể ghi đè lên nó, về cơ bản, bạn hiển thị chức năng gọi lại, như hợp đồng cho vay chớp nhoáng, bạn đưa tiền cho tôi, chức năng gọi lại của tôi và sau đó lấy lại số tiền, và trong Move , cách bạn làm là ai đó đi đến hợp đồng cho vay chớp nhoáng và họ nói, “Này, đưa tôi 53 đô la, nhưng họ cũng đưa cho bạn thứ mà họ gọi là đồ vật khoai tây nóng hổi.
Một đối tượng khoai tây nóng là một cấu trúc, nó không có khả năng. Nó không được sao chép, vì vậy bạn không thể sao chép nó. Nó không có khả năng lưu trữ toàn cầu, bạn không thể cất nó đi như khi bạn đưa nó vào hợp đồng. Nó cũng không có khả năng thả, vì vậy bạn không thể thả nó. Do đó, cách duy nhất để thoát khỏi nó là chuyển nó trở lại hợp đồng cho vay chớp nhoáng. Cho bạn pass lại code hợp đồng flash loan của nó, bắt bạn trả nợ. Nếu không, các chương trình của nó sẽ bị lỗi trong thời gian chạy và thậm chí sẽ không vượt qua kiểm tra loại. Vì vậy, đây là khả năng thú vị để kiểm soát việc phá hủy các giá trị của bạn, với tư cách là một lập trình viên, có thể áp đặt các bất biến tùy ý vào bất kỳ thời điểm nào khi các đối tượng này có thể bị phá hủy. Chúng trông giống như mẫu cuộc gọi API rất cụ thể. Một ví dụ rất rõ ràng khác là nếu bạn muốn buộc ai đó gọi lock sau khi gọi unlock, nhưng họ muốn làm gì thì làm ở giữa, bạn cũng có thể làm theo cách này.
a16z Eddy Lazzarin：
Khi tôi lần đầu tiên nghe về mẫu khoai tây nóng, tôi đã nghĩ về cách sử dụng khóa thú vị như texas câm, chỉ tận dụng hệ thống loại cho mục đích công thái học, để thực thi việc sử dụng các đối tượng cụ thể. Phương pháp này gần như là một yêu cầu của mức logic nghiệp vụ. Tôi nghĩ nó rất thông minh, nó có cảm giác rất hiện đại, đó 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 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 hữu ích trong môi trường hợp đồng thông minh Giá trị, bởi vì nó là những yêu cầu hợp lý hơn ở đây, xem xét giá trị và bảo mật có thể liên quan.
Sui CTO Sam Blackshear ：
Trước khi chúng tôi nói về bất kỳ ví dụ cụ thể nào, bạn có thể cung cấp tổng quan cấp cao nhanh về hệ thống đối tượng của chúng tôi không? Đối tượng là gì và ai sở hữu chúng? Làm thế nào để các đối tượng sở hữu các đối tượng khác và làm thế nào để các mô-đun làm việc với chúng?
a16z Noah：
Đúng chính xác. Đây là một phương ngữ của ngôn ngữ Move, cụ thể là Sui Move. Cơ sở của điều 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 của phương ngữ Move ban đầu mà chúng tôi từng sử dụng. 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 điểm trung tâm của mọi thứ vào các đối tượng, được khuyến khích cao để có thể thể hiện quyền truy cập chi tiết chính xác nhất có thể. Điều này giúp bạn thực hiện nhiều việc mà chúng tôi sẽ không đi sâu vào chi tiết trong podcast này, chẳng hạn như xử lý giao dịch hiệu quả hơn, cho người dùng ví biết giao dịch nào sẽ được thực hiện, v.v.
Vì vậy, trong Sui Move, cấu trúc lưu trữ toàn cầu là ánh xạ từ ID đối tượng sang ID đối tượng. Sau đó, các đối tượng chỉ là các cấu trúc Di chuyển 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 toàn cầu. Sau đó, mỗi đối tượng 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 vào cho các mô-đun của mình để có thể 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 có thể sử dụng các ID này để phân giải ID thành các đối tượng và chèn chúng vào các 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. 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 và con và 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ể đại diện cho những thứ như bộ sưu tập lớn.
Giả sử tôi đang xây dựng 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ó một cái gì đó như DNS, thì nó phải lớn tùy ý. Cách chúng ta biểu diễn nó là sử dụng mối quan hệ đối tượng cha-con, về cơ bản chúng ta có cách xem đối tượng dưới dạng bản đồ không đồng nhất. Sau đó, bạn có thể thêm khóa với các trường 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, đối tượng này có một bản đồ trong đó, và sau đó tôi có thể đặt mộ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 một trường mới sau này 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 biểu diễn nó là với các mối quan hệ đối tượng cha và đối tượng con này và mỗi đối tượng con được liên kết với một giá trị khóa, giá trị này có thể là bất kỳ giá trị Move tùy ý nào, chẳng hạn như chuỗi hoặc u 64 hoặc bất kỳ giá trị nào khác mà bạn muốn.
a16z Noah：
Vâng, liên quan đến khái niệm về các đối tượng cha mẹ, điều mà tôi nghĩ đã khiến nó thực sự trở thành khoảnh khắc eureka của tôi thực sự 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 một chương trình chỉ có một đối tượng sang Để triển khai lại hầu hết các kết hợp thẻ kiểu Uniswap V2. Một dự án nhỏ mà tôi đã thực hiện thực sự khiến tôi nhận ra giá trị của việc sở hữu đồ vật của đồ vật. Dự án này chỉ có ba đối tượng, ổ khóa, vàng và một hàng rào trống. Có một mô-đun rất cơ bản mà bạn có thể hình dung là 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á hủy ổ khóa, đưa cho bạn vàng, sau đó phá hủy chìa khóa của bạn. Cách tiếp cận này rất thú vị, theo cách này, bạn có thể mô tả mối quan hệ giữa các đối tượng và mô tả các quyền theo cách rất chi tiết.
Sui CTO Sam Blackshear ：
tiêu đề cấp đầu tiên
So sánh bảo mật của Move và Solidity
Người dẫn chương trình Sonal Chokshi:
Nhân tiện, trước khi đến với tạp chí Wired, tôi đã dành 6 ngày ở Xerox Park, điều này gợi cho tôi một chút về lịch sử của lập trình hướng đối tượng. Điều bạn vừa nói cực kỳ thú vị, bởi vì họ đã phát minh ra Smalltalk, tiền thân ban đầu của nhiều khung hướng đối tượng ngày nay. Dù sao, có chủ đề nào khác mà bạn muốn thảo luận không?
a16z Noah：
Tôi chỉ có một câu hỏi chung, nhưng thực sự, có bất kỳ vụ hack nào và điều tương tự xảy ra trong thế giới EVM mà bạn nghĩ sẽ không xảy ra lần đầu tiên nếu bạn đang sử dụng Move vì hệ thống loại.
Sui CTO Sam Blackshear ：
Trong thế giới EVM, chúng tôi đã đề cập đến phân bổ động và đăng nhập lại, Move loại bỏ đăng nhập lại theo cấu trúc, mọi vấn đề liên quan đến đăng nhập lại sẽ biến mất và tôi nghĩ mọi người đang làm rất tốt. Bây giờ, tôi nghĩ rằng nó tránh phản ứng và xem.
a16z Eddy Lazzarin：
Nhưng bạn có thể giải thích tại sao Move khiến những vấn đề này trở nên bất khả thi không?
Sui CTO Sam Blackshear ：
nhập lại, phải không? chuyện gì đã xảy ra thế? Bạn viết một số mã và gọi một chức năng nhất định. Vấn đề là ai đó cung cấp việc triển khai một chức năng mà bạn không mong đợi ngay từ đầu. Để điều này hoạt động, các lệnh gọi hàm phải động. Nó phải gọi mã, về cơ bản là một con trỏ hàm được cung cấp bởi người gọi, có thể là kẻ tấn công. Nếu bạn không có bất kỳ lệnh gọi hàm động nào, nếu bạn luôn biết mục tiêu của lệnh gọi hàm, thì điều này hoàn toàn không thể xảy ra, giống như bất kỳ lệnh gọi nào bạn gọi, bạn có thể không biết mã làm gì, nhưng bạn biết nó là gì. là , bạn có thể kiểm tra nó, bạn có thể xác minh nó, mọi thứ đều ở đó. Vì vậy, về cơ bản, người khác không thể cung cấp mã làm cho mô-đun của bạn hoạt động khác với mong đợi của bạn, bởi vì đó chỉ là lệnh gọi hàm tĩnh. thật tuyệt.
a16z Eddy Lazzarin：
Do đó, điều này giúp loại bỏ các cuộc tấn công vào lại, vốn là một vấn đề muôn thuở trong quá trình phát triển Solidity.
Sui CTO Sam Blackshear ：
Vâng, tôi nghĩ Move về cơ bản loại bỏ vấn đề thiếu kiểm tra quyền trong lập trình hợp đồng thông minh. Đôi khi bạn viết một số mã mà bạn cần chuyển tất cả các tài khoản một cách rõ ràng và bạn phải nói, tôi có được phép làm điều này không. Bạn đã viết một mã đơn giản nhưng quên kiểm tra xem người gửi có phải là ai đó không hoặc liệu người đó có thể truy cập mã đó hay không. Tôi nghĩ rằng những vấn đề này xảy ra khá thường xuyên.
Vì vậy, trong Move, thông tin 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.
Khi bạn nhìn vào những đối tượng này, chúng nói: Tôi thuộc sở hữu của địa chỉ này hoặc Tôi thuộc sở hữu của đối tượng khác này hoặc Tôi là đối tượng được chia sẻ hoặc Tôi là đối tượng bất biến “. Lập trình viên không thể quên kiểm tra chủ sở hữu của nó, bởi vì bộ thực thi sẽ kiểm tra trước khi thực thi mã được truyền trong đối tượng Sui này. Thời gian chạy cho biết: Tôi thấy trao đổi này, tôi thấy tất cả các đối tượng họ muốn sử dụng. Tôi đang kiểm tra xem liệu họ có thực sự sở hữu những đối tượng này hay họ có một đối tượng trung gian sở hữu chúng để họ có quyền sử dụng chúng.
Nhiều kiểm tra quyền mà chúng tôi yêu cầu các lập trình viên của mình thực hiện cuối cùng lại xảy ra trong We Run Time và những kiểm tra đó là không thể quên. Tôi nghĩ điều này rất quan trọng, vì thứ khó bảo vệ nhất là đặc tả kỹ thuật mà lập trình viên đã không nói cho bạn biết. Những tiêu chuẩn này rất dễ quên và khó nắm bắt bằng cách sử dụng phân tích tĩnh hoặc các phương pháp khác, bởi vì bạn luôn cần ai đó tìm ra những tiêu chuẩn nào là quan trọng.
Người dẫn chương trình Sonal Chokshi:
Và nhân tiện, tôi nghĩ điều sẽ xảy ra ở quy mô doanh nghiệp sẽ rất thú vị khi mọi người hợp tác nhiều hơn theo cách này về mặt lập kế hoạch dài hạn hoặc ngắn hạn bởi vì nó rõ ràng là được phân phối và không chỉ một công ty, đôi khi mọi người hợp tác. Nhưng ý tôi là, bây giờ khi bạn nghĩ về những cách cũ, bạn có những nhà phát triển và tất cả những phương pháp hay nhất này
