原文作者：Sui World DAO
原文作者：Sui World DAO
去年a16z 等一眾機構力捧以Sui 為代表的Move 公鏈，讓Move 語言在Meta Diem 的廢墟上大熱歸來；與此同時，從Sui Move 出現那一刻起，不看好的聲音也一直存在：
如果僅僅是因為Move 語言有可能比Solidity 或其它開發語言更優秀，我們就一定需要一個新的智能合約語言，並樂此不疲地從頭開始搭建一個新Layer 1 嗎？
近日，a16z Crypto 團隊與MystenLabs 的聯合創始人兼CTO、Move 語言之父Sam Blackshear 進行了一次主題為《Programming Languages Crypto》的播客對話，探討了為何Move 是未來智能合約的重要方向。
在該次播客中，a16z Crypto 與Sam Blackshear 從傳統編程語言與智能合約編程之間的差異和相似之處到辯論區塊鏈的獨特限制和機遇，展開討論了Move 語言的設計思想、面向對象和資產的編程、安全性，以及分享了形式化驗證、治理和社區工具、跨平台適應性等話題。
主要分享內容包括：
1、編程語言與智能合約歷史
從傳統編程、到智能合約編程，再到Move 編程。 Move 是最早的關於如何設計語言以適應類型系統、靜態類型和編譯時檢查等問題的語言。
2、Move 智能合約的創新
EVM 過度適配了平台的實現細節，這些實現細節是為以太坊設計的。開發者最終不得不繼承以太坊做出的許多設計決策，包括一些讓以太坊難以擴展的錯誤。 Move 在設計時，沒有將任何區塊鏈特有的東西加入到核心語言中。源代碼語言層面的創新將會相當重要，Move 最終能夠提供的是代碼驗證器和VM 級別的保護，以免受其他程序員的攻擊。
Move 是一種可執行的字節碼語言，用於執行用戶交易和智能合約。在Sui Move 中，驗證者可以更有效地進行並行化，這使得存儲、執行都變得更容易，而不必將這些東西編碼到協議級別，並讓用戶和程序員來考慮。
4、安全性
4、安全性
在智能合約世界中，我們處於一個約束狀態。我們編寫非常少量的代碼，而且必須完美無缺，安全性必須是最首先要考慮的事情。 Move 安全性是既要防止程序員自我腳踏，還要盡可能為他們提供正確的原語，以便他們能夠防禦攻擊。
5、面向對象和資產
Move 被設計為一種面向對象和資產的智能合約編程語言，之所以被設計成這樣，是因為大多數Web2 面向對象的編程語言就是這樣。在Sui Move 中，將事物的中心點放在對像上，高度激勵能夠盡可能精確地表示細粒度訪問。 Sui Move 全局存儲的結構是一個從對象ID 到對象ID 的映射。
6、安全性對比
Move 通過構造消除了重入和智能合約編程中缺失的權限檢查問題。 Move 中，對象所有權信息實際上存儲在對像元數據中，這不是程序員可以控制的東西。 Move Prover 就是為了防止語言編寫智能合約的錯誤而設計，可以避免開發者犯很多基本的錯誤。
7、智能合約語言的治理
最初，Move 是在Facebook 開發的，沒有真正的治理。我們非常謹慎地擴展語言。簡潔性是最主要的東西，但我們會積極地擴展它。 Sam Blackshear 有一個非常具體的願望，比如Move 被設計為一種跨平台語言，其中一些鏈EDM 的基本功能仍應適用，並且覆蓋了智能合約開發能手和Web2 新人，極具靈活性。
一級標題
一級標題
一級標題
主持人Sonal Chokshi 介紹
歡迎來到Web 3.0 ，這裡是a16z Crypto 團隊製作的關於建立下一代互聯網的節目。我是您的主持人Sonal Chokshi。
本節目旨在為尋求了解和深入探討加密和Web 3.0 相關事物的任何人提供幫助，無論是開發人員、創作者、建築師、企業領袖還是政策制定者。我們現在開始全新一季的節目。今天的節目主要討論編程語言和加密貨幣，既適用於現有的智能合約程序員，也適用於其他尋求進入這個領域的開發人員。對於那些對編程語言的演變和出現感到好奇的人來說，這也是一個不錯的選擇。我們今天的特別嘉賓是MystenLabs 的聯合創始人兼CTO Sam Blackshear
，該公司正在為Web 3.0 的去中心化未來打下基礎。 Sam 在編程語言方面有著資深的歷史，從他的博士學位到在Facebook 工作，再到創建並成為Move 和開源編程語言的作者，用於構建智能合約。我們將更多地談論這個話題。在整個節目中，我們還邀請到a16z Crypto 的智能合約研究工程師Noah
，他和另一位夥伴最近為以太坊開發了名為Helios 的輕量級客戶端並贏得了具有挑戰性的gas 優化。一級標題一級標題
一級標題
編程與智能合約的歷史
主持人Sonal Chokshi：
a16z Crypto Noah：
我們將從傳統編程的歷史開始，第一個發言的是Noah，接著是Sam Blackshear 和Eddy。
Sui CTO Sam Blackshear：
我們想了解編程歷史如何影響智能合約編程的歷史，因為我覺得有三個東西，傳統編程、智能合約編程，還有Move 語言。這三件事都有它們自己的歷史，對吧？
a16z Crypto Eddy Lazzarin：
沒錯，我喜歡這種框架。人們用語言來設計語法或讓人感到開心，這是對的，但它不僅僅是這些。所以我很喜歡這種大局觀的框架。
Sui CTO Sam Blackshear：
就在這個基礎上，傳統編程有著過去二三十年來的各種趨勢。傳統編程語言已經發生了變化，有一些熱門話題來來去去。曾經有很長一段時間，動態編程語言和非常寬鬆的類型檢查是非常受歡迎的。通常認為，跳進去，忘記類型，忘記所有技術細節，只是編寫代碼是更符合人體工程學的方式。
但最近，人們開始更深入地思考類型系統、靜態類型和編譯時檢查等問題，以便在程序運行之前盡可能了解程序的所有細節。這些趨勢不斷變化。然而，對於智能合約編程來說，由於它是如此新穎，我們還沒有看到智能合約編程中這種類型的歷史，這是非常不同的。
我認為Move 語言是我們所看到的最早的關於如何設計語言以適應這一點（類型系統、靜態類型和編譯時檢查等問題）的證據。我很想了解我們期望會發生哪些變化，例如靜態和動態類型等智能合約編程中可能出現的話題？這些話題可能還沒有出現，因為目前只有一種語言，即Solidity。
主持人Sonal Chokshi：
Sui CTO Sam Blackshear：
那麼，這又與轉向智能合約編程有什麼聯繫呢？再次請Sam 回答？
在這個智能合約空間中，隨著EVM 作為智能合約語言的第一批進入者，存在著不同的趨勢。人們不知道想用智能合約做什麼？我們如何編寫它們或任何這些類型的事情因此，我認為靈活性更加重要，以嘗試了解需要發現使用情況的專家的類型。我感覺現在我們已經知道了，或者至少我們對構建塊有一些了解。
智能合約的趨勢是極其領域特定的，你為資產定義模板，定義轉移資產的策略，檢查訪問控制和權限。
這就是基本的，你不會用智能合約語言編寫編譯器或操作系統或任何這些類型的事情。因此，它們非常非常好，它們與通用編程語言相比的優勢。
我認為人們低估了即使ERC-20 標準發生在EVM 可以編程的很久之後，EVM 甚至被認為是編寫以太坊程序的基本構建塊之一。我只是沒有看到任何顯而易見的證據，證明最基本的東西在此之前是明確的。
所以你是對的，現在你可以把類型當作理所當然的事情。我認為類型和這些東西的繞過，是可以承受一定技術債務的。如果規模很小，你只想快速移動，而且代碼可以扔掉，那麼這種技術債務是完全可以接受的。但有趣的是，你把它用公司或創業公司的規模來描述，小公司在快速成長，每個人都能理解整個代碼庫，這種技術債務是可以容忍的。
但是，當它非常非常大時，有大量的人更改代碼，他們不知道正在構建的新對象和系統的後果。將其放入類型系統中，使您以明確、直接的方式編寫代碼時遇到障礙，而不是意外地創建後來有人會撞上的玻璃圍欄。例如，就像你們談到的，能夠防止複制，能夠設置資產的最大供應量。這些約束非常重要，無論項目的規模如何，都需要保持。它們是維護項目的健全和安全非常重要的約束條件。
了解這些界限意味著您現在可以創建編程語言，以允許您強制執行它們。這就是我如何看待Move 語言的方式。
隨著我們了解到需要做正確的事情所需的約束類型，我們現在有能力將它們包含在語言本身中。因此，我確實認為它與類型有些相似，就像你所說的那樣。你提到類型對於程序的健全性和安全性非常重要。
a16z Noah：
你們說動態類型可能適用於小型項目，但隨著項目的增長，應該使用靜態類型。我有點不同意，我認為完全靜態的類型可能更適合。這可能是一個新穎的看法。它是為了程序員的健全性。我見過最可怕的事情是，當我按下我的快捷鍵「control k」時，它會告訴我函數簽名是什麼。當我寫Python 時，這讓我感到恐懼。我看著函數簽名，只看到參數的名稱。我就像，你到底想要我做什麼呢？
a16z Eddy Lazzarin：
我不敢相信人們會接受那種寫出代碼後就永遠不會再看一眼的寫法。
a16z Noah：
他們接受的是默認假設，即他們可以在心中記住系統的要求。
Sam Blackshear ：
但是即使是100 行的程序，我也覺得無法默認這一點。
a16z Eddy Lazzarin：
它可以運行，但它並不完美。我認為你們說的對。而且我認為這種心態已經演變了。以前，類型系統是用來保護程序員免受同事傷害的。
當你的創業公司變得太大時，它就很有用了。但現在它更像是在保護我自己。
在智能合約的環境下，它是在保護我免受攻擊者的攻擊。這是真正的不同之處，因為在普通程序中，你不會在攻擊者受到類型系統的約束時部署程序。攻擊者可以使用其他語言編寫機器代碼。你只需要保護你自己的防火牆就行了。但在這裡，我編寫這個很好的類型對象，它將流入攻擊者的代碼並保持其完整性。類型系統必須保證我的安全。
就像你說的那樣，這是一個很棒的工具，它給你帶來了不同的需求，你需要強制執行它們，比如防止複制。這不是你在普通類型系統中需要考慮的問題，或者防止刪除或確保你按某種方式使用或銷毀某個值。這些都是因為我們正在研究智能合約並試圖為這些用例提供有意義的類型系統，因此我們最終會將這些東西加入move 中，也可能會加入未來的智能合約語言中。
主持人Sonal Chokshi：
Sui CTO Sam Blackshear ：
實際上，夥計們，讓我們更多地談談傳統編程和智能合約編程之間的其他差異。但在我們進一步討論之前，你們能不能快速介紹一下智能合約程序員可以使用的語言呢？我認為我們需要了解一下大局，因為我想了解一下現狀，比如Solidity、Viper 等。知道哪些內容能夠讓我們更快地入門。
是的，我想基本的情況是，如果你想編寫智能合約，你幾乎總是會使用solidity。除非你恰好在幾個其他較小的生態系統之一。
如果你在Polkadot 生態系統中，你會使用ink!（Sui World 注：ink! 是由Parity 開發的智能合約語言，用於在Rust 中編寫智能合約並編譯為Wasm 代碼），它是一個現有的編程語言。如果你在StarkNet 生態系統中，你使用Cairo（Sui World 注：Cairo 是STARK 證明系統的其中一個編程語言）。
但是大部分情況下，如果我要給出建議，讓你學習如何編寫智能合約，我會建議你學習一些Solidity，然後學習EVM。你可能還想使用Viper，唯一的缺點是Viper 是較新的，可能更容易出現漏洞。我記得幾年前，在驗證存款合約時，他們發現了Viper 編譯器中的一堆漏洞。發現這些漏洞的人現在在16 z 工作，他是Day June，他是一個形式驗證專家。
因為Day June 是形式驗證專家，所以現在在a16z 工作。而現實情況是，你需要學習一些內容，你需要學習一些語言。你甚至需要深入了解EVM，如果你想成為一個真正優秀的智能合約工程師，你需要了解EVM 到一個荒謬的程度
a16z Eddy Lazzarin：
，以至於你可以說出每個操作的gas 成本，他們能夠告訴你確切的與gas 成本有關的代碼。這就是我們目前生活的世界。
也許有一點值得一提的是，作為一名軟件工程師，你總可以了解你正在運行代碼的機器。有很多需要了解的關於編程環境的知識。但是在智能合約編程中，環境非常豐富、非常複雜。有很多上下文需要了解，這幾乎與語言本身無關。這就是在你周圍發生的事情，周圍有哪些對象，不同的代碼如何被調用。這是一件非常奇怪的事。
主持人Sonal Chokshi：
Sui CTO Sam Blackshear ：
那麼，最接近學習Solidity 的人是懂JavaScript 的人，這是真的嗎？
a16z Eddy Lazzarin：
大家都說是JavaScript，因為它使用「function」這個關鍵詞，就像JavaScript 也用到了。但不幸的是，它們並不是非常相似。
從語法上看，Solidity 確實繼承了很多JavaScript 的特性。如果你瞇著眼睛或情緒不好，可能會覺得相似，但實際上完全不同。虛擬機環境差異巨大，所以共同點很少。
主持人Sonal Chokshi：
a16z Noah：
有什麼相似的編程語言嗎？
a16z Eddy Lazzarin：
是的，我認為沒有直接相似的編程語言。如果你熟悉Was（Sui World 注：WebAssembly Studio，一款在線工具，用於將C/C++ 和Rust 代碼編譯為WASM 格式。 ），並試圖在一個需要高度隔離的環境中寫代碼（比如Surplus），這可能是最接近的了，這些代碼要獨立執行，但又需要一定程度的通信。但它仍然不是很相似，思維方式完全不同，表面上的相似可能會有危險。也許相關的是編程語言歷史上的一些重大錯誤。
我不知道在區塊鏈方面是否有一些走下了錯誤道路的惡劣歷史。我們是否走了一些可怕的道路？
主持人Sonal Chokshi：
Sui CTO Sam Blackshear ：
這是個好問題。
這是個好問題。 1977 年，C 語言發布，也是Standard ML 發布的年份。 Standard ML 具有極大的影響力。現在，有OCaml 語言、Rust 語言都受到其極大的影響，Move 語言也受到其影響。但這些思想已經存在了很長時間。我想很多人都在思考一個替代的未來，在那個未來中，C 語言沒有成為主流，而是Standard ML 的思想被廣泛接受，如強類型、內置安全性。
主持人Sonal Chokshi：
a16z Eddy Lazzarin：
那麼，這種計算機技術的發展趨勢是什麼呢？我並不是說這是一個錯誤，但是我認為像Standard ML 這樣的語言即使在今天看起來也非常現代化。想像一下那個另類的宇宙是一個有趣的事情，當我第一次發現時就被震撼了。
Sui CTO Sam Blackshear ：
好奇心作祟，為什麼你認為像C 語言以及類似的語言，它們如此直白、如此命令式？它們在相對較低層次上思考計算機，作為編程語言它們並沒有做很多事情，這就是我對C 語言的看法，為什麼我們走了這條路？
a16z Eddy Lazzarin：
我認為當時的硬件限制迫使你使用C 語言，如果你想要編寫高效的程序，或者推動計算機的邊界，我認為如果你向前推進硬件，你會選擇另一條道路。但是我認為，函數式編程很難，它在很多方面都是反直覺的。我不是說C 語言不難，但我覺得它更容易入門。然後你意識到，我已經做了非常複雜的事情，或者說很難推理，但是為時已晚。這是個好點子，函數式語言確實有更陡峭的學習曲線，但是一旦你掌握了，你會意識到，我可以很好地獨立地思考我的代碼，事情很好地解決了。
Sui CTO Sam Blackshear ：
我認為如果你很多地思考計算機是如何在硬件層面上工作的，那麼像C 語言這樣的語言就更直接了。但如果你對編程語言不是很了解，那麼C 語言就更容易入門。但是如果你非常了解編程語言，那麼我認為ML 和函數式編程這些類型的語言有更多的東西值得去探索。
a16z Noah：
這是一個大局觀的答案。但我想說的是有關小規模的「計算機語言錯誤」的問題。
所以，我對此有些猶豫，因為我一直聽說函數式編程有多棒，但是我發現有點難以理解。但我一直想知道的問題是，如果函數式編程真的那麼好，為什麼它從未能夠克服當前編程語言的網絡效應呢？它的這種局面令我驚訝。
Sui CTO Sam Blackshear ：
但我想補充的一點，我認為函數式編程給我們帶來的巨大貢獻是，我們使用的所有命令式語言都是藉用的。但最好的是，就像你剛才說的，Rust 受標準電子郵件的影響很大，但Rust 基本上是一種命令式語言，對吧？但它擁有所有從凝視他們而來的奇妙的仙塵。
一級標題
a16z Eddy Lazzarin：
一級標題
一級標題
a16z Noah：
智能合約的創新發展
Sui CTO Sam Blackshear ：
我其實很好奇你沒怎麼談虛擬機層和編程語言層的創新，以及它們如何影響智能合約的發展。
這是個很好的問題。我認為人們沒有充分考慮這些區別，比如虛擬機層和編程語言層的區別。實際上，除了EVM 和新的虛擬機層，還有很多創新，比如Viper 等源代碼語言。這些東西在很多方面都比Solidity 更好，也很有趣。
我認為，如果Move 能夠成為我們期望的Web 3.0 的法律標準，那麼虛擬機層的創新將會是緩慢而漸進的。因為核心是固定的，我們只會添加新的東西，而不會徹底重新設計。
但是，我認為源代碼語言層面的創新將會相當重要。現在，我們只有一種源代碼語言，但它與字節碼格式緊密相連。但是，隨著越來越多的客戶使用智能合約，並強調安全性，我可以想像將會有很多不同的源代碼語言需要嘗試，這是一個有趣的研究領域。也許你可以先寫下你之前的事實，然後在程序中為你綜合他們的信息，或者對限制的建議。
也許你可以從編寫你的Move 以前的事實開始，然後通過合成程序為你填充程序，或提出限制的建議。
比如，你可能在一個非常特定的遊戲上下文中編寫Move，這個遊戲看起來像場景層次結構。也許它是用Python 庫編寫的，但是編譯成Move 的字節碼。也許你像Solana 或其他平台一樣，正在考慮整合Move，但不想整合虛擬機，而是通過將Move 的字節碼編譯為Salina 的字節碼格式，然後在開發者級別使用Move 源代碼語言。
我認為有很多不同的方法，就像JVM（Java Virtual Machine）一樣。 JVM 是一個美妙的通用虛擬機，最初只支持Java。但它經過了時間的考驗，並且現在你有Scala、Groovy 和其他一些有趣的方式來使用這些原語來設計不同的編程體驗，非常符合人們想做的事情。
a16z Eddy Lazzarin：
所以，我有一種偏見的看法，認為Viper 可以給你很多在源代碼語言層面進行實驗的空間。
Sui CTO Sam Blackshear ：
你對所有替代EVM 字節碼語言的看法如何？比如有FE、Iron 和Viper 等，這些有趣的努力旨在為EVM 構建更智能、更複雜的語言，你對此持樂觀態度嗎？
a16z Eddy Lazzarin：
所以這些都是編譯成EVM 字節碼的不同源代碼語言。
Sui CTO Sam Blackshear ：
對，編譯成EVM 字節碼。
我們在Facebook 開始設計Move 時，看到其他源代碼語言構建EVM 的情況時，我們研究了Solidity 和Viper，這是在我們開始構建EVM 的時候。我們最終得出的結論是，讓人們編寫安全的智能合約最困難的問題是EVM 的底層性質，以及如何讓類型化的值在可信邊界上流動，以及動態決策等等這些問題，這些都是EVM 的特性。如果你構建一個更好的源代碼語言，你可以讓開發者更難搞砸。也許他們可以進行更高級的驗證，
但最終，Move 能夠提供的，而且我們認為很重要的是，代碼驗證器和VM 級別的保護，以免受其他程序員的攻擊。
源代碼語言不能給你這個，必須將其內置到VM 中，無論你在EVM 上迭代完美源代碼語言多少次，我認為Solidity 很棒，我們也可以做得更好，但我認為，如果你沒有這些基本的保護措施內置到VM 中，你得到的結果最終會不如一些其他路徑。我不是因為我認為Half 很酷而感到尷尬，而是因為我認為最終狀態不如其他路徑那麼吸引人。
我認為早期智能合約語言，特別是EVM，過度適配了平台的實現細節，這些實現細節是為以太坊設計的，內部包括了關於交易結構的指令，賬戶結構的指令，使用特定類型的密碼學等等。
我認為這使得在一個不像以太坊那樣的鏈上使用EVM 變得非常困難，你最終不得不繼承以太坊做出的許多設計決策，也許在某些情況下，還要繼承一些讓以太坊難以擴展的錯誤。
在設計Move 時，我們非常清醒地意識到不要將任何區塊鏈特有的東西加入到核心語言中，盡可能地讓它與具體的區塊鏈無關。
這樣你就可以拿著Move，在一個具有瘋狂交易結構的工作量證明鏈上使用它，這個鏈可能是在瑞典這樣做，而另一個鏈在澳大利亞是這樣做的。這樣，你就不必押注在某個特定的鏈上成為一個Move 開發者。你可以將你的技能跨越各種不同的鏈使用，包括未來的鏈。我們認為這對於一個智能合約語言的生存至關重要，因為一個語言最大的資產就是它的社區。而通過使你的技能跨平台，而不是過度適配於一種語言，你可以擴大社區的規模，從而更好地實現成功。然後，一個大的社區是使得在工具上投入大量資金、在公共庫上投入大量資金以及所有你真正需要一個語言成為大牌並取得成功的東西變得可能。
a16z Eddy Lazzarin：
這是我們從一開始就嘗試做的事情，現在看到了多個真正不同的Move 鏈，它們在如何整合語言方面非常不同。
主持人Sonal Chokshi：
是的。
a16z Eddy Lazzarin：
是的。
Sui CTO Sam Blackshear ：
有很多人知道JavaScript，他們想做很多事情。他們想共享各種庫。現有的代碼可以啟動服務器端的JavaScript 實例，這使得node 變得有用。這意味著有各種各樣的開發者可能不做後端編程，但可以開始進入並將其作為自己的領域。
a16z Noah：
我認為這個對比很好。另外，我們想要談談關於編程語言治理的問題，因為Node 顯然有一些非常引人注目的治理分歧和分裂，每個編程語言社區都有許多引人注目的治理分歧和發展方向。我曾經報導過Node，它是我最喜歡的之一。但我想確保我們完成這個主題。還有別的要說的嗎？我覺得你是我們廣播節目中的居民老古板，我很喜歡。所以我有一個反面觀點，或者說我有一個很酷的想法。我一直在想，為什麼沒有人建立一個Move 的OP Rollup，那將會非常酷，
Sui CTO Sam Blackshear ：
考慮到OP 的Rollup 人們是在以太坊上實現的，他們使用MetaMask 和ECDSA 簽名，但似乎並沒有使用與我們相同的簽名格式，比如Move 似乎沒有使用ECDSA。
a16z Noah：
是的，我們支持以太坊的EdDSA 和ECDSA 簽名格式。
Sui CTO Sam Blackshear ：
很完美，但我的觀點是，你可以構建一些非常有趣的東西。但是，當我試圖學習Move 時，我一直在盯著甜點和演員狗。我很困惑。
a16z Eddy Lazzarin：
一級標題
Sui CTO Sam Blackshear ：
一級標題
一級標題
智能合約編程的獨特事物
主持人Sonal Chokshi：
a16z Eddy Lazzarin：
我們已經圍繞著傳統與智能合約編程、特定約束和差異以及甚至一些Tread 和智能合約編程之間的相似之處來回討論了。有沒有關於智能合約編程的獨特事物，我們沒有涵蓋？
Sui CTO Sam Blackshear ：
在智能合約上下文中，另一個非常重要的事情是資源使用，如Solidity 中的Gas Metering。雖然在很多情況下，計算資源是相對豐富的，計算成本也是非常重要的。但是在智能合約上下文之外或區塊鏈上下文之外，這意味著它僅被涉及和考慮得更少。我認為在語言中有關你消耗的資源的概念可能是智能合約編程的一個有趣的資源。
這是我們非常關注的事情，我們在EVM 中構建了Gas Metering，正如你所說，這與傳統編程語言非常不同。
我認為今後的趨勢是Gas Meeting 會變得越來越粗粒度，更多地防止如資源濫用之類的嚴重問題，而不是真正地為每個指令精打細算。
我實際上認為像Gas Golfing（Sui World 注：Gas Golfing 指的是在一系列智能合約的跳轉交互中，開發者編寫最節省gas 代碼的挑戰）這樣的東西雖然非常有趣，但實際上對編碼風格和安全性都有很大的傷害。
諷刺的是，我們之所以只知道按指令收費的模型，可能是因為如果你有一個龐大的虛擬機，運行10 萬條指令和運行50 萬條指令的差別在實際測量運行時間時微不足道。
所以，我們為什麼要按指令收費呢？因此，我認為我們會看到一種趨勢，就是如何使這更加粗粒度。
每當我看到所有這些不安全的塊和Solidity 代碼中的大量內聯彙編時，這讓我想起我們現在處於多麼早期的階段，因為這不是智能合約開發人員應該考慮的編程挑戰，這不是一個成熟的開發生態系統的標誌。但我們正在朝著這個方向發展。我同意我們要考慮極限情況。選擇正確的算法、選擇正確的數據結構、選擇正確的一般方法，這是大多數軟件工程的情況，都是很重要的。但關於準確計算每條指令的成本的瑣碎問題可能太過繁瑣了。
主持人Sonal Chokshi：
Sui CTO Sam Blackshear ：
我們談到了優化gas，類型、資產和安全性。還有哪些限制是需要考慮的？
這是一個類似於gas 的線程，但我想到的具體子集是狀態。這對我來說是一個大問題。當我考慮gas 操作時，我喜歡進行極端的gas 優化。
a16z Eddy Lazzarin：
但是，當我們處理持有真實資金的實際智能合約時，我的一般建議是，除非你可以費盡心思地使用略少於之前使用的狀態，否則你應該做出合理的組織。那是唯一一次我會使用大型彙編塊的情況，如果你可以做出一些愚蠢的事情來使用更少的狀態，因為這就像一個永遠的資源，我們應該將它放在僅高於執行或調用數據的位置。
a16z Noah：
我完全同意這個觀點，因為我認為這是根本性的昂貴的問題。如果一個平台允許每個合約都觸及任何一塊狀態，那麼它將很難實現並行化。而像Squeeze 以及其他一些新的區塊鏈平台所採用的方法是，顯式地限定交易可以訪問的狀態，至少讓我知道一些。這樣在高層面上平台就能夠更容易地將交易實現並行化，包括執行和共識。因此，這是一些程序員必須思考的問題：在訪問狀態時盡可能地快，不要觸及不需要的狀態，這樣驗證者才能更有效地實現並行化，實現更多的區塊空間。
Sui CTO Sam Blackshear ：
這是否會打開一種世界，即即使在非角色扮演的情況下，不是所有驗證者都需要下載全部狀態？如果你能很容易地將狀態分離開來，讓驗證者僅服務於它能處理的事務，這是否可以實現？
我認為這確實有可能實現這樣的世界。這也為不同的方法開闢了一條道路。
一級標題
一級標題
一級標題
智能合約編程思維方式上的改變
主持人Sonal Chokshi：
a16z Eddy Lazzarin：
我們剛才討論了一些與智能合約編程相關的獨特之處。還有哪些思維方式上的改變？我們已經談到了一些，像Eddie 提到的，一個巨大的轉變是，在編程的世界中，至少自從計算機的早期，我們處於豐富的世界，但在這個世界中，我們處於限制的世界。那是一個思維方式的例子。還有哪些思維方式的轉變？特別是對於你們每個人來說，作為你們接觸智能合約編程的程序員，有什麼讓你們感到驚訝，或者教會了你們，或者讓你們對某些事情有了不同的看法？
Sui CTO Sam Blackshear ：
也許一個有點傻的例子是，我還記得幾年前我第一次學到ERC-20 Token 的餘額不是你的賬戶擁有的東西。你的地址沒有Token 餘額。代替它的是，有一個Token 合約，記錄著哪個地址有多少餘額。當你想要向某人轉移Token 時，你不是發送給他們一些Token。相反，你需要到合約中進行所有這些低級別的操作，改變你的地址和他們的地址所持有的餘額。你有權限操作和改變那個合約。這是一種非常反直覺的方式，在EVM 和Slippery 中這是第一次讓我注意到的關於Move 的一個有趣的思維方式轉變。這是有趣的思維方式轉變，因為我們經常聽到的英文單詞不一定與編程模型相對應。
我想要補充一點，這與你在實際操作時有關。在正常的世界中，我們非常關注開發人員的生產力，因為工程師的工作是編寫大量代碼，讓這些代碼只有幾個錯誤，並且這些錯誤不會太嚴重。而在智能合約世界中，你的工作是編寫非常少量的代碼，而且必須完美無缺。它必須在所有可能的方面都是完美的。否則，你將失去數億其他人的錢。這是一種完全不同的思維方式的轉變。花費兩個月的時間盯著1000 行代碼，並嘗試想出如何使其更好、更重要的是，如何使其完美，然後審核人員也要做同樣的工作，判斷它是否完美。
主持人Sonal Chokshi：
a16z Eddy Lazzarin：
這是一個大的思維轉變。在編程的世界裡，至少自計算機的早期以來，我們一直處於豐富的世界，但在這個世界中，我們處於一個約束的世界。
Sui CTO Sam Blackshear ：
另一個思維轉變是，在ERC 20 Token 的世界裡，你的地址沒有代Token 餘額。你不能發送Token，你必須去訪問Token 合約，在Token 合約中查找地址對應的Token 餘額，然後通過修改地址和余額來完成Token 轉移。這是一種比較反直覺的思考方式，但在EVM 和Move 中，這是非常重要的思維轉變。
在智能合約編程中，你的工作是編寫一小段代碼，並且必須是完美的，因為這個代碼可能涉及到數億人的資金安全。你必須仔細審查代碼，確保代碼的正確性。
另外，升級智能合約的難度比升級移動應用或網站更高，因為在智能合約中，代碼是不可變的。在智能合約編程中，你必須考慮如何支持安全的升級和信任，使其看起來更像傳統生態系統。
但是智能合約編程中，你需要擁有一個對抗性的思維方式，這對於來自其他領域的人可能很陌生。這是因為在智能合約中的部署模型，你不僅需要考慮你的應用的預期使用情況，還要考慮非預期的使用情況。因為在傳統編程中，有方法可以隱藏自己，限制為一個小型API，或使用防火牆來限制攻擊者的操作等。
但智能合約的整個意義在於，你所做的可以與你從未想像過的代碼進行交互，並且可以安全地實現。因此，你需要考慮這種情況下的優點和缺點。這絕對是相對於傳統編程的一個思維方式的轉變。
主持人Sonal Chokshi：
Sui CTO Sam Blackshear ：
這是一個非常重要的問題，也是我們討論如何編寫智能合約和使用智能合約編程語言時應該優先考慮的問題嗎？
是的，絕對是。這實際上是我最喜歡談論的事情。這讓我非常害怕，智能合約語言設計者需要考慮的問題是安全性。這是主要焦點，甚至可能是唯一的焦點，直到我們解決了這個問題。
我認為，智能合約安全對於更廣泛的加密貨幣採用來說是一種存在性威脅。我這麼說的原因是，您可以看一下以太坊和solidity，以及最流行的平台EVM 和Solidity。您可以看看編寫此代碼的早期程序員，他們非常高素質，真正理解底層區塊鏈，非常注重安全。他們知道自己在做什麼。我認為，他們非常認真地編寫管理數億美元和數十億美元的代碼的責任。
但是，如果您看一下任何地方的智能合約安全記錄，都非常糟糕，這不是這些人的錯。我認為這是一個非常困難的問題。並且我認為語言使其更加困難。所以，如果您看看我最喜歡的網站rakt.news，您可以查看排行榜或查看價值數千萬或數億美元的這十個黑客，這些黑客非常慣常，每週或每月發生一次，具體取決於規模。同時，智能合約開發者社區非常小，只有約5000 名全職EVM 程序員，這與傳統開發者社區相比非常非常小。
因此，如果您相信我們擁有的人是最硬核且最注重安全的人員，但開發實踐和安全記錄是不可持續的，那麼我認為您的結論是，沒有任何方式可以使這個空間在沒有使安全問題變得更糟的情況下繼續增長，這可能意味著它根本不會增長，或者像那些想進入Web3 的大型金融機構或公司一樣，他們正在看著自己是否必須僱用智能合約開發者？我會被黑客攻擊數千萬美元並感到緊張。隨著時間的推移，這種情況只會變得更糟。他們可能會保持觀望。因此，作為試圖設計新智能合約語言的人，安全性必須是您首先要考慮的事情。
主持人Sonal Chokshi：
Sui CTO Sam Blackshear ：
你們其實已經在不失去資產的背景下暗示了這一點，但是你們更具體地是什麼意思呢，因為它非常重要？
我所說的安全性是指我們既要防止程序員自我腳踏，還要盡可能為他們提供正確的原語，以便他們能夠防禦攻擊，因為智能合約是一個設置，您的代碼部署在一個攻擊者旁邊，攻擊者可以直接調用您的代碼，可以直接與其鏈接。您的代碼是開源的，或者至少字節碼是開源的。
a16z Eddy Lazzarin：
這是目前我們所見過的最具對抗性的編程環境，出錯的代價也是最高的。因此，我認為如果你在討論智能合約編程設計，那麼安全性必須始終放在首位。一旦我們解決了安全問題，我們可以考慮其他更具表現力的因素，但這是我的有些乏味，但我認為非常重要的答案。
Sui CTO Sam Blackshear ：
哪些特性能夠影響安全性？有什麼例子能夠體現這一點呢？
我認為最重要的是封裝，具體來說，是封裝的各個子特性。當您編寫代碼時，您無法預測攻擊者會嘗試什麼，因此需要能夠在沒有預見到攻擊者會做什麼的情況下進行推理。所以，您需要一個強大的類型系統，不僅在源代碼級別，而且在字節碼級別都需要，這樣您在編寫源代碼時獲得的保證將在您將代碼發佈到區塊鏈上、其他人依賴它並與它進行交互時繼續保持。
我們觀察到，在其他領域中流行的某些特性在智能合約編程中本質上是不適合的，比如動態分派。
a16z Noah：
在傳統的編程中，像接口和動態分派這樣的東西是關鍵的抽像機制，是無處不在的。您可以定義一個接口，然後其他人使用不同的邏輯重寫該接口，然後您可以針對該接口進行編程，一切都非常好。但是我們有一個俏皮的說法：「在代碼是法律的世界裡，接口是犯罪行為。」
這是個玩笑話，讓我們停下來一分鐘。在代碼是法律的世界裡，接口是犯罪行為。
主持人Sonal Chokshi：
Sui CTO Sam Blackshear ：
在您繼續之前，您能否再解釋一下這句話？我不想太快地跳過它。
是的，完全正確。這裡的想法是，接口不定義行為，它定義了預期行為。比如，當你閱讀接口的規範、參數名稱甚至類型時，它告訴你想要完成什麼。但是並不能保證它就一定會發生。
a16z Eddy Lazzarin：
所以，如果你編寫的代碼是用來保護某些東西的，但實際上你留下了一個空白支票供攻擊者、其他人填寫。這在契約法中似乎是一種犯罪。這是一個未明確規定的合同。我非常喜歡這個特性，它在傳統的編程語言中很受歡迎。但我們認為，在智能合約中，這導致了許多不同的問題。例如，重新進入需要動態調度。例如，如果您取消了動態調度，則根本沒有重新進入。像以太坊中的毒藥Token 這樣的事情發生了，因為您重寫了轉移函數，而每個人都知道直觀地說，它只是用來轉移資金，也許不會做其他任何事情。但現在你讓它做一些超出預期的事情，比如竊取錢財。這就是一個特性的例子，如果將其刪除，那麼對代碼進行推理並進行適當的封裝就變得更加容易了，因為每次看到一個調用點時，您都知道它將確切地做什麼，您不必擔心其他人以後會做出令您驚訝的事情。
a16z Eddy Lazzarin：
確切地說，我認為這個類比就像如果你定義一個關於椅子的接口，它有四條腿和一個座位，你描述的是它的具體層面，而不是行為層面，你沒有描述可能是隱含或默認的關於椅子的其他事情，比如它具有某種結構完整性，它有特定的材料，它是以某種方式放置的。
a16z Noah：
可能被規避，這意味著接口只是一組任意的描述，不能捕捉您想要強制執行的安全約束。
a16z Eddy Lazzarin：
這正是定義。
Sui CTO Sam Blackshear ：
在錯誤的層面定義事物。我很好奇。
a16z Eddy Lazzarin：
但是，您如何在接口之外很好地進行模塊化？如果接口是一種犯罪，我可能是一個罪犯，因為我的最喜歡構建複雜的智能合約的方式之一是喜歡有不同的合約，具有不同的目的。而且，特別是在非常複雜的系統中，您有一個基於模塊的基礎，其中模塊遵守某種接口，然後主要合同可以知道如何調用不同的模塊。這些模塊通常通過治理方式獲得許可，如何獲得超級表達的即插即用的模塊性？沒有標準化接口？如何獲得繼承？
Sui CTO Sam Blackshear ：
這些與接口有關的所有事情都喜歡嗎？
這正是要問的正確問題。他們可以整天反對這一點，但是如何提供一些使您編寫有用代碼的東西？就像如果不允許您走出房子之類的事情一樣，沒有犯罪。但是我們做到這一點的方式是，接口和繼承並不是唯一的方式，我傾向於以組合為思考方式。我們提供了幾種組合原語，不需要動態調度程序接口。
其中之一是泛型。我們有運行時遺傳，看起來很像您所擁有的。 Clr（Sui World 注：common language runtime, 公共語言運行庫）讓我給出一個非常具體的例子，否則這很快就會變得抽象。
像您的ERC-20 之類的東西, 這顯然是一項根本重要的加密標準。如果您的平台，您的語言無法做到這一點，那麼它將沒有什麼用處。在像Move 這樣的語言中，您定義了一個稱為t 的類型點，其中t 是一個泛型類型參數，然後實現了coin 的函數，例如有一個函數用於將2 個點連接在一起。這適用於所有coin 類型。這不是某個人想要覆蓋的東西。您定義拆分。
a16z Eddy Lazzarin：
當你想讓某人定制Token 的行為時，使用所謂的能力模式，例如對於Token，你可能想要定制的一件事情是總供應量是多少，或者更根本的是它的政策是什麼？你可以這樣表達：好的，你有類型為「t」的點結構體，然後有不同的t 的實例化，例如美元、英鎊或其他的貨幣類型。對於你想要定制的東西，你在能力層面上提供它，創建一個Token 的函數。你說，這是我的Token 的類型參數，然後它會給你一個叫做「資金寶庫能力」的東西。然後有其他的邏輯確保只有持有t 的寶庫能力的人才能鑄造和銷毀t 類型的Token。你可以拿到這個寶庫能力，將它鎖定在一個不同的合約中，強制執行總供應量的限制。你可以將它放在某個地方，比如說只在周二評論，但不在周四評論。你倒置了控制流，這就允許你進行任意的組合。這是一個技巧的例子，但這個技巧可以在幾乎所有地方使用，如果你想要讓行為以某種方式工作，你需要硬編碼。這聽起來不好，但你實現特定的兩種方法，然後你為你想允許的東西定義這些能力。
Sui CTO Sam Blackshear ：
你認為能力是你可以添加到一個看起來像是傳統程序員的接口的約束嗎？
是的，我認為大多數這些接口模式可以非常直接地變體。這有點難以編譯，但是你可以說，這是這個接口想要做的事情的等效能力模式。
主持人Sonal Chokshi：
Sui CTO Sam Blackshear ：
一級標題
a16z Noah：
一級標題
一級標題
a16z Eddy Lazzarin：
面向對象和麵向資產的編程
a16z Noah：
所以我可能有點提前談到證明器，但是這些能力對類型系統可見嗎？在對程序進行靜態分析的時候，這些能力在程序的哪個時候是可見的？如果我寫了一些特定實例化的代碼，其中有能力，那麼在我運行它之前，能夠很早地發現我違反了能力嗎？
Sui CTO Sam Blackshear ：
是的，這些能力是對類型系統可見的，並且在程序的靜態分析階段就可見了。如果我寫了一個具有能力的特定實例化的類型的代碼，那麼非常早就可以發現我是否違反了能力，不需要在虛擬機上運行它。
讓我簡單回答一下這個問題，然後再提供一些背景信息，它們對編譯器可見，並且是類型系統的一部分。這是我們非常重要的一個利用點。但我想稍微講一下Move 可移動性系統中的結構體，以及它如何捲入到類似於審計的能力等級中。如果這不會分散注意力的話。
在Move 中，你有結構體類型和類似於其他語言的結構體，它們可以有字段，可以是基本類型的字段，也可以是其他結構體。而更加有趣，也許更加不同的是，這些結構體具有能力。如果你熟悉Rust，那麼能力有點像標記交易。它們聲明了你在結構體上允許進行的內置操作。
同樣重要的是，如果你沒有能力，你就不能做那些事情。比較簡單的一個能力是非常重要的，那就是複制的能力。如果你有一個Token 類型或者非同質化Token 之類的東西，在計算機中，它只是一些比特，但你不希望允許別人隨意複製這個東西。
在Move 中，如果你沒有聲明你的結構體具有復制的能力，那麼你就不能使用我們相當於「man copy」的操作。
所以像整數和字符串這樣的東西都有復制。但如果你不想讓你的類型具有復制的能力，那麼你就不給它。然後還有其他的能力，比如丟棄，這被稱為drop 能力。這就涉及到了有趣的線性類型的東西，如果你想要丟棄某些東西，比如把它放到作用域之外，或者覆蓋掉它，那麼你就給它drop 能力。但如果你不給drop，那麼消除它的唯一方法就是定義該類型的模塊所期望的任何策略。
a16z Noah：
公共語言運行庫(common language runtime, CLR) 舉個具體的例子，如果你想為你的Token 保持一個總供應量，你就不給你的Token drop 能力。然後除了在聲明它的模塊中定義的burn 函數，沒有其他方式可以擺脫它，這個函數可以更新總供應量。這些都是你可以使用的技巧。還有幾個與存儲有關的能力，比如它是否可以存儲在全局存儲中，我不會詳細講述，因為它們對這個問題不太相關。但基本上，能力已經融入到審計程序中，審計程序了解類型系統，知道如何利用類型系統來解決問題。如果我編寫一個說明，說只有一個這樣的東西，那麼審計程序可以利用這個來證明這個屬性。因此，能力和類型系統的保證是相輔相成的。
Sui CTO Sam Blackshear ：
當你提到drop 時，我就想談談我最喜歡的東西。你能不能談一下熱土豆模式是什麼？如果還有其他類似的酷東西，它是我最喜歡的奇怪事情之一，是從Move 中產生的。
這確實是一個奇怪的東西。這與能力非常密切相關。通常在編程語言中，你對於何時可以消除你的值沒有太多的控制，可能你有一個析構函數來說明你的值何時會消失。但是有時析構函數的保證比較弱，或者你不能簡單地說類似於「你不能刪除我的類型」。這聽起來像是一個奇怪的限制，但它實際上非常有力，特別是在沒有動態分派的情況下。
我先舉一個熱土豆的例子，然後我們可以深入了解閃電貸之類的東西。如果你在以太坊上進行閃電貸，這是一個標準，你可以重載它，基本上你公開一個回調函數，就像一個閃電貸合約，你給我錢，我的回調函數然後取回錢之類的，而在Move 中，你這樣做的方式是有人去閃電貸合約，他們說，「嘿，給我53 塊，但他們也給你所謂的熱土豆對象。
a16z Eddy Lazzarin：
熱土豆對像是一個結構體，它沒有能力。它沒有復制，所以你不能複制它。它沒有全局存儲的能力，你不能像將它放在一個合約中一樣將其藏起來。它也沒有drop 能力，所以你無法將其丟棄。因此，唯一的擺脫它的方法是將它傳回閃電貸合約。讓你傳回它的閃電貸合約的代碼，強制你還款。如果你不還，它的程序將在運行時失敗，甚至不會通過類型檢查。因此，這是利用有趣的能力控制你的值的破壞，作為一個程序員，可以在任何時候強加任意的不變量，以決定何時可以銷毀這些對象。這些看起來很像API 調用模式非常明確。另一個非常明顯的例子是，如果你想要強制某人在調用unlock 之後調用lock，但在兩者之間可以做任何想做的事情，你也可以用這種方法實現。
Sui CTO Sam Blackshear ：
當我第一次聽到「燙手山芋」模式時，我想到了像「mute texas」這樣的鎖的有趣用途，這些鎖僅出於人體工程學目的，利用了類型系統，以強制特定對象的使用方式，幾乎是商業邏輯級別的要求。我認為這是非常聰明的，感覺非常現代化，是編程語言中人體工程學的高質量使用方式，而這種方式在傳統的編程語言中甚至還不是很常見，但在智能合約環境中顯然非常有價值，因為在這裡有更多的邏輯要求，要考慮可能涉及的價值和安全性。
a16z Noah：
在我們討論任何具體的例子之前，您能否快速概述一下我們的對象系統的高級概述？對像是什麼，誰擁有它們？對像如何擁有其他對象，模塊如何與它們一起工作？
是的，完全正確。這是關於Move 語言的一個方言，特別是Sui Move。這個東西的基礎是全局存儲的不同結構，而不是我們曾經使用的原始Move 方言的全局存儲方案。原始的Move 全局存儲方案非常類似於以太坊使用的公司模型。
在Sui Move 中，我們希望將事物的中心點放在對像上，高度激勵能夠盡可能精確地表示細粒度訪問。這有助於你做很多事情，我們不會在這個播客上詳細介紹，比如更有效地處理事務，告訴錢包用戶事務將要做什麼等等。
所以在Sui Move 中，全局存儲的結構是一個從對象ID 到對象ID 的映射。然後對像只是具有一個稱為鍵（key）的能力的Move 結構。它說：「嘿，我可以作為鍵。」它可以出現在全局對像池中。然後每個對象必須具有一個全局唯一的ID。然後你可以為你的模塊編寫入口點函數，它們可以直接將對像作為輸入。如果你在寫一個事務，這個WeRunTime 就會有對象ID。如果你寫的是事務，WeRunTime 就能夠使用這些ID 來將ID 解析為對象，並將其插入函數中。
這種面向對象和麵向資產的編程體驗非常棒。它比我們在原始Move 版本中的做法直接得多。你還提到了父對象和子對像以及對象層次結構。這非常有用，但你仍然希望能夠像表示大型集合這樣的東西。
比如，我正在構建一個類似於DNS 的註冊表，我希望有數百萬個條目。我們有一個對像大小限制，一個對象可以是幾兆字節，但不能更大。但是如果你有像DNS 這樣的東西，它應該是任意大的。我們表示它的方式是使用父子對象關係，我們基本上有一種方式將一個對象視為異構映射。然後你可以添加具有動態選擇字段的鍵。這在某種程度上非常類似於JavaScript。我們可以說，這個對像有一個映射在裡面，然後我可以在這個映射裡放一些東西。或者你可以說，當我定義這個對象時，它有十個字段，但我實際上想在後來添加一個新字段，我將升級我的合同。我想在事後添加一個新字段。
a16z Noah：
一級標題
Sui CTO Sam Blackshear ：
一級標題
一級標題
Move 與Solidity 的安全性對比
主持人Sonal Chokshi：
a16z Noah：
順便說一下，在來到Wired 雜誌之前，我曾經在施樂公園呆了6 天，這讓我想起了一點關於面向對象編程的歷史。你剛才說的超級有趣，因為他們發明了Smalltalk，這是許多今天面向對象框架的早期前身。無論如何，有沒有其他的話題想討論？
Sui CTO Sam Blackshear ：
我只有一個普遍性的問題，但實際上，有沒有在EVM 世界中發生的黑客事件等等，你認為如果使用Move，由於類型系統的緣故，這些事件就不會發生在第一次。
a16z Eddy Lazzarin：
在EVM 世界中，我們已經提到了動態分配和重入，Move 通過構造消除了重入，任何與重入相關的問題都會消失，我認為人們做得很好。現在，我認為它避免了反應和查看。
Sui CTO Sam Blackshear ：
但是你能解釋一下，為什麼Move 會讓這些問題不可能發生嗎？
a16z Eddy Lazzarin：
重入，對吧？發生了什麼？你寫了一些代碼，調用了某個函數。問題在於，有人提供了一個你最初沒有預料到的函數實現。為了實現這一點，函數調用必須是動態的。它必須調用代碼，這基本上是由調用者提供的函數指針，可能是攻擊者。如果你沒有任何動態函數調用，如果你總是知道一個函數調用的目標，那麼這根本就不可能發生，就像你調用的任何東西，你可能不知道代碼做了什麼，但是你知道它是什麼，你可以測試它，你可以驗證它，所有的東西都在那裡。所以從根本上說，別人不可能提供讓你的模塊行為變得出乎你意料的代碼，因為這只是一個靜態的函數調用。太酷了。
Sui CTO Sam Blackshear ：
因此，這就消除了可重入攻擊，這在Solidity 開發中一直是一個永恆的問題。
是的，我認為Move 基本上消除了智能合約編程中缺失的權限檢查問題。有很多時候你在寫一些代碼時需要顯式地傳遞所有的賬戶，並且你必須說，我是否有權做這件事。你寫了一個簡單的代碼，但是卻忘記了檢查發送者是否是某個人，或者是否這個人可以訪問它。我認為這些問題經常發生。
所以在Move 中，對象所有權信息實際上存儲在對像元數據中。這不是程序員可以控制的東西。
當你查看這些對象時，它們會說：「我由這個地址擁有」，或者「我由這個其他對象擁有」，或者「我是共享對象」或者「我是不可變對象」。程序員不能忘記檢查它的所有者，因為運行時會在執行傳入這個Sui 對象的代碼之前進行檢查。運行時會說：「我看到了這個交易中心，我看到了他們想要使用的所有對象。我正在檢查他們是否實際擁有這些對象，或者它們擁有一個可以中轉擁有它們的對象，以便他們有權使用它們。
我們要求程序員進行的許多權限檢查最終都在We Run Time 中發生，這些檢查是不可能忘記的。我認為這非常重要，因為最難保護的是程序員沒有告訴你的規範。這些規範很容易被忘記，使用靜態分析或其他方法很難捕捉到它們，因為你總是需要一些人來確定哪些規範很重要。
主持人Sonal Chokshi：
