Ý kiến của Josh Primero, Kiến trúc sư giao thức trưởng tại RDX Works.  Sau khi khởi chạy Radix Engine V2 trên mạng Babylon, tôi đã xem xét kỹ hơn làn sóng máy ảo mới xuất hiện trong bối cảnh DeFi. Một trong những ứng dụng hấp dẫn nhất trong số này là MoveVM của Tùy, một cải tiến so với MoveVM ban đầu của Diễm.  Tôi đã rất hào hứng với kiến trúc của Sui từ lâu vì nó chia sẻ một số triết lý kỹ thuật quan trọng với Radix:  Sử dụng ngữ nghĩa di chuyển để cho phép lập trình hướng tài sản.  Tận dụng kiến thức về sự phụ thuộc của trạng thái để mở rộng sự đồng thuận thông qua việc sắp xếp một phần (thay vì trừu tượng hóa quá mức và chuyển khả năng mở rộng sang lớp cao hơn, mốt nhất thời)  Về mặt kỹ thuật, tôi thấy thật tuyệt vời khi họ sử dụng một ngôn ngữ và mã byte được biên dịch để nắm bắt tĩnh các phụ thuộc trạng thái tối thiểu cần thiết để thực thi một số logic.  Điều này không chỉ dẫn đến việc thực thi nhanh chóng mà còn mang lại lợi ích bảo mật vì sự phụ thuộc của trạng thái và việc ghi trạng thái của một giao dịch được giới hạn chặt chẽ.  Tuy nhiên, thành tựu này phải trả giá. Các lập trình viên DeFi phải quản lý một mô hình khó hơn và đôi khi không trực quan, thậm chí lặp lại các vấn đề nổi tiếng của EVM.  Bây giờ chúng ta hãy xem xét những vấn đề này trong bốn lỗ hổng mà tôi phát hiện được trong máy ảo của Sui.  1. Đối tượng nguyên thủy quá chung chung  Sự đổi mới lớn nhất của MoveVM của Sui (hay MoveVM nói chung) là việc sử dụng ngữ nghĩa di chuyển/mượn ở lớp mã byte. Điều này có nghĩa là máy cấp thấp của họ có thể hiểu quyền sở hữu và chuyển động của đồ vật; khá mát mẻ!  Do đó, mọi đối tượng trong VM của Sui  , một giá trị được nhập với logic liên quan có thể được sở hữu, di chuyển và chia sẻ.    hoạt động như một NFT  Thật không may, vì một đối tượng có thể thực hiện nhiều việc chung hơn trong mô hình này, nên lập trình viên DeFi phải chịu gánh nặng trong việc xác định và quản lý một máy trạng thái vòng đời của đối tượng phức tạp.   Cụ thể, trong Sui, khi xác định cấu trúc mới, lập trình viên phải chỉ định kết hợp 4 khả năng (“sao chép”, “thả”, “khóa” và “lưu trữ”), mỗi khả năng này sẽ ảnh hưởng đến máy trạng thái theo những cách khác nhau. Hơn nữa, lập trình viên phải quản lý xem khi khởi tạo một đối tượng nên được chia sẻ, chuyển giao, trả về dưới dạng giá trị hay bị đóng băng.  Việc cấu hình sai trên bất kỳ thiết bị nào trong số này có thể gây ra các lỗi nhỏ có thể dẫn đến mất tiền.  Ví dụ: trong đoạn mã sau, chúng tôi sử dụng Sui's  để thực hiện một khoản vay nhanh đơn giản. Vấn đề? Chúng tôi đã vô tình thêm khả năng thả vào Biên nhận.    Mẫu khoai tây nóng  Sai lầm nhỏ này khiến người đi vay bỏ trốn với khoản vay mà không bao giờ trả lại bằng cách tự mình đánh rơi Biên nhận. (Có một lỗi khác với mối quan hệ FlashLoan và Biên nhận, hãy xem bạn có tìm thấy nó không!)  Vì vậy, mặc dù việc tổ chức một máy ảo xung quanh một đối tượng duy nhất với một tập hợp các khả năng là thanh lịch và đơn giản về mặt khái niệm, nhưng theo quan điểm của lập trình viên, thật khó để hiểu được tác động của từng loại vì có quá nhiều trạng thái cấp thấp cần phải thực hiện. quản lý.  Điều này không quá khác biệt với các vấn đề quản lý bộ nhớ của các ngôn ngữ cũ hơn và tại sao các máy ảo thu gom rác lại đạt được nhiều thành công. Các lập trình viên ứng dụng không quan tâm đến việc quản lý các trạng thái cấp thấp như khi nào bộ nhớ được giải phóng; họ quan tâm đến các đồ vật và mối quan hệ giữa các đồ vật đó.  Theo cách tương tự, về cơ bản, các lập trình viên DeFi quan tâm đến tài sản và logic xung quanh sự chuyển động và quyền sở hữu của những tài sản này. Bản thân các tài sản không có logic cố hữu và logic quản lý những tài sản này không cần phải “di chuyển” cũng như không cần “sở hữu”.  MoveVM của Sui kết hợp hai thứ rất khác nhau này thành một sự trừu tượng hóa đối tượng chung, điều này tạo nên một mô hình tinh thần lập trình DeFi khó khăn.  2. Không có công văn động  Một tính năng nổi bật của MoveVM là việc sử dụng công văn tĩnh, nghĩa là không có lớp gián tiếp nào giữa lệnh gọi hàm và việc thực thi nó trong thời gian chạy. Các lệnh gọi hàm và logic cơ bản của nó được liên kết tĩnh tại thời điểm gói mới được xuất bản. Điều này cho phép VM hoạt động nhanh và có thể dự đoán được nhưng lại kém linh hoạt hơn và môi trường lập trình khó sử dụng hơn.  Chúng ta hãy xem xét ba hậu quả của việc thiếu sự điều phối năng động.  2a) Không có chức năng  Vì VM phải biết chính xác hàm sẽ được gọi tại thời điểm xuất bản mã nên không thể kết hợp các hàm khác nhau lại với nhau; một mẫu rất phổ biến trong lập trình thông thường (ví dụ: giao diện trong ngôn ngữ OO hoặc các đặc điểm trong Rust).  Chúng ta hãy xem một công cụ khuyến khích Nhóm thanh khoản đơn giản. Nếu tôi viết một lời động viên khuyến khích thêm 10% vào đóng góp của bạn trong Rust, nó sẽ trông giống như thế này:   Bằng cách này, LiquidityEnhancer của tôi sẽ hoạt động với bất kỳ nhóm nào triển khai đặc điểm Pool (Có, đối với những người theo dõi Rust, đặc điểm này cũng được liên kết tĩnh. Đây chỉ là một ví dụ về thành phần hàm).  Điều này là không thể trong Sui vì “đóng góp” phải là một chức năng đã được xác định sẵn. Thay vào đó, một gói mới liên kết đến việc triển khai nhóm chính xác sẽ phải được xuất bản cho bất kỳ triển khai nhóm mới nào.  2b) Không có lệnh gọi lại động hoặc con trỏ hàm  Liên quan, việc có thể chạy logic tùy ý thông qua một số giao diện chung là một cấu trúc rất hữu ích, đặc biệt là trong cài đặt DeFi.  Hãy tưởng tượng một người thực thi trong tương lai được khuyến khích khuyến khích người gọi trong tương lai gọi một số logic tùy ý (ví dụ: để sử dụng các khoản thanh toán bị trì hoãn). Trong Rust, điều này sẽ giống như:   Tuy nhiên, điều này không thể thực hiện được ở Tùy do thiếu sự điều động linh hoạt. Thay vào đó, gói IncentivizedFutureExecution mới sẽ phải được xuất bản cho từng phương thức muốn sử dụng tính năng như vậy.  2c) Khả năng nâng cấp khó khăn  Sui đã hỗ trợ cho  . Thật không may, do tính bất biến của công văn tĩnh nên việc quản lý nâng cấp gói sẽ khó khăn hơn và kém an toàn hơn những gì mong đợi.   nâng cấp gói và phiên bản  Đầu tiên, không thể cập nhật mã liền mạch và minh bạch. Nếu tôi có một gói thực hiện lệnh gọi đến gói khác và gói kia có bản cập nhật sửa lỗi bắt buộc thì tôi phải tự mình xuất bản gói mới nếu muốn sửa lỗi.   Với ngày càng nhiều gói phụ thuộc, điều này có thể dễ dàng dẫn đến sự bùng nổ nâng cấp gói chỉ từ một sửa lỗi đơn giản của gói được sử dụng nhiều.   Thứ hai, tất cả mã cũ sẽ luôn tồn tại (cần thiết vì bất kỳ mã nào khác phụ thuộc vào nó sẽ cần có khả năng gọi nó) ngay cả trong trường hợp mã này có thể có lỗi và/hoặc mã độc. Để chống lại điều này, gánh nặng được đặt lên lớp ứng dụng là duy trì lược đồ phiên bản hợp lý ở trạng thái của các đối tượng của nó.  3. Mẫu hộp thư vụng về  Sui gần đây đã phát hành một  có thể được mô tả tốt nhất như một cách để gửi một đối tượng đến một đối tượng khác mà đối tượng đó không biết (trước đây, điều này chỉ có thể thực hiện được với Địa chỉ). Để có thể truy cập vào đối tượng đó, một giao dịch riêng biệt có kiến thức về việc chuyển giao này phải được thực hiện.    Mẫu chuyển sang đối tượng  Cấu trúc như vậy rất hữu ích trong việc loại bỏ sự phụ thuộc vào trạng thái của đối tượng nhận; không khác với việc gửi UTXO đến một địa chỉ khác trong mô hình UTXO (phần nhận cũng tương tự như việc chứng minh quyền sở hữu thông qua tập lệnh chứng kiến UTXO). Sự đồng thuận của Sui sau đó có thể tận dụng sự thiếu tranh chấp này và thực hiện song song tốt hơn một giao dịch như vậy.  Tuy nhiên, việc đạt được hiệu suất như vậy không phải là không có sự đánh đổi về bảo mật. Thực tế là các đối tượng có thể được nhận mà không có thông tin về đối tượng nhận (bao gồm cả việc nó có tồn tại hay không!) dẫn đến khả năng mất quyền truy cập vào các đối tượng đã gửi đó mãi mãi.  Điều này có thể thực hiện được nếu đối tượng nhận không hỗ trợ đối tượng được gửi. Lỗ hổng như vậy tương tự như việc gửi nhầm mã thông báo ERC-20 tới một hợp đồng thông minh không hỗ trợ mã thông báo đó (một nguyên nhân   phổ biến khiến tiền bị mất). rất  Hơn nữa, thực tế là có hai loại mối quan hệ cha-con, một loại là cha mẹ biết về con cái của mình và một loại là con cái biết về cha mẹ của chúng, tạo nên một mô hình phức tạp hơn so với mô hình thông thường trong lập trình truyền thống.   Có cách tiếp cận nào duy trì được lợi ích về hiệu suất mà không cần lập trình trên cấu trúc khó xử này không? Tôi tin là có. Nó yêu cầu sử dụng các con trỏ bất biến cùng với các phương pháp CRDT khác, nhưng tôi sẽ trình bày vấn đề đó trong một bài viết sau.  4. Lập trình trạng thái chia sẻ vụng về  Máy ảo của Sui được tối ưu hóa để lập trình và thực thi ở trạng thái không gây tranh cãi. Điều này đã dẫn đến một số cơ chế lập trình khá khó xử khi thực sự cần xử lý trạng thái chia sẻ. Chúng ta hãy xem xét một số trong số này.  4a) Không có tài liệu tham khảo được lưu trữ  VM của Sui không có khái niệm về tài liệu tham khảo được lưu trữ. Nếu có, nó sẽ mất khả năng phân tích tĩnh các phụ thuộc trạng thái của một hàm và do đó mất khả năng song song hóa. Hậu quả của việc này là gánh nặng quản lý các tài liệu tham khảo được lưu trữ giờ đây được đặt lên vai người lập trình/người dùng.  Ví dụ: giả sử tôi có một đối tượng yêu cầu giá từ một Oracle cụ thể trong một trong các chức năng của nó. Trong Rust, điều này có thể trông như thế này:   Trong Sui, vì các tham chiếu không thể được lưu trữ nên mối quan hệ giữa MyDefi và Oracle phải được mô tả theo cách chức năng hơn:   Nhưng chờ đã! Bây giờ, bất kỳ lời tiên tri tùy ý nào cũng có thể được chuyển vào. Để đảm bảo rằng lời tiên tri phù hợp được sử dụng,  phải được sử dụng:    Mẫu con trỏ ID  Mẫu này, khi so sánh với các tham chiếu thông thường, dễ vỡ hơn và phải cẩn thận để triển khai mối quan hệ chính xác. Khi biểu đồ mối quan hệ giữa các đối tượng phát triển và trở nên phức tạp hơn, thật khó để tưởng tượng gánh nặng lập trình này có thể mở rộng tốt (ví dụ: điều gì sẽ xảy ra nếu lệnh gọi Oracle get_price cũng có các phần phụ thuộc riêng của nó).  Hơn nữa, sẽ luôn có gánh nặng đối với người gọi, dù là mã giao dịch hay mã gói, trong việc chuyển tham chiếu chính xác. Nếu tham chiếu này có thể thay đổi, điều này sẽ đặt thêm một gánh nặng khác lên người gọi để đảm bảo tham chiếu đã được cập nhật lên trạng thái mới nhất.  4b) An toàn loại không động cho các trường hợp liên quan  Không giống như lập trình truyền thống, trong lập trình DeFi, rất hữu ích khi có thể kiểm tra kiểu xem một phiên bản có thuộc cùng một “nhóm phiên bản” với phiên bản khác hay không.  Ví dụ: sẽ rất tốt nếu kiểm tra xem việc kết hợp hai đồng xu có cùng mã định danh đồng xu hay không:   Vấn đề khi triển khai điều này với ngữ nghĩa chung chung truyền thống là các khái quát được sử dụng để thể hiện các loại chứ không phải “một nhóm các trường hợp liên quan”.  Bằng một cách khá thông minh, Sui đã có thể giải quyết vấn đề này thông qua  . Về cơ bản, trong mẫu được hệ thống hỗ trợ này, họ đã nói rằng, nếu bạn muốn một nhóm mới gồm các phiên bản có liên quan, hãy tạo loại mới đặc biệt này sẽ đại diện cho mã định danh của nhóm này.   Mẫu nhân chứng một lần  Lợi ích to lớn của việc này là lớp ngôn ngữ hoàn toàn không cần thay đổi và người ta chỉ cần sử dụng ngữ nghĩa chung phổ biến để đạt được loại an toàn này.  Lỗ hổng lớn nhất là một loại mới (và do đó, một gói mới) phải được triển khai mỗi khi một nhóm thứ liên quan mới được tạo. Chẳng hạn, người ta không thể tự động tạo Coin<T> mới mà không triển khai gói mới.   Phần kết luận  MoveVM của Sui được xây dựng theo tiêu chuẩn của các kỹ sư hệ thống: một VM dựa trên các nguyên hàm cấp thấp đơn giản về mặt khái niệm, được thực thi tĩnh.  Thật không may, đơn giản không có nghĩa là dễ dàng và việc họ khăng khăng tránh các mẫu đối tượng dùng chung thông thường khiến lớp ứng dụng của họ khá phức tạp và không trực quan khi lập trình.  DeFi là một thế giới đối tượng được chia sẻ, lộn xộn: các nhóm có tính thanh khoản lớn mà bất kỳ ai cũng có thể truy cập, các giao thức cho vay mà bất kỳ ai cũng có thể vay và cho vay, các oracle mà bất kỳ ai cũng có thể gọi, cũng như thành phần và tương tác của tất cả các đối tượng này diễn ra cùng một lúc.  Song song hóa một hệ sinh thái như vậy là chén thánh của DLT và nỗ lực của Sui đã thành công ngoại trừ việc nó đẩy quá nhiều sự lộn xộn vào lớp ứng dụng.  Mặc dù đúng là một số vấn đề có thể được giải quyết bằng công cụ và hỗ trợ ngôn ngữ tốt hơn (   ), một số vấn đề không thể khắc phục được nếu không có những thay đổi lớn về VM (   ). 1 Đối tượng nguyên thủy quá chung chung, 4 Lập trình trạng thái chia sẻ vụng về 2 Không có công văn động, 3 Một vấn đề khó xử Mẫu hộp thư

Buy XRD with card or bank transfer via Switchere.

Nghe bài viết này bằng Tiếng Anh, đọc bởi robot thông minh của HackerNoon

MoveVM của Sui: Đánh giá toàn diện

About Author

BÌNH LUẬN

chuyên mục

BÀI VIẾT NÀY CŨNG CÓ MẶT TẠI

Related Stories

85 Stories To Learn About Travel

85 Stories To Learn About Productivity Hacks

94 Stories To Learn About John Locke

145 Stories To Learn About Book

85 Stories To Learn About Travel

85 Stories To Learn About Productivity Hacks

94 Stories To Learn About John Locke

145 Stories To Learn About Book

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps