首頁

Partnered With:

a16z對話Move語言之父：從程式語言說起，為何Move是未來智慧合約的重要方向

a16z crypto

閱讀本文需 108 分鐘

a16z Crypto團隊與MystenLabs共同創辦人兼CTO 、Move語言之父Sam Blackshear進行了深度對話，共同探討為何Move是未來智能合約的重要方向。

原文標題：《a16z 對話Move 語言之父：從程式語言說起，為何Move 是未來智能合約的重要方向》

原文作者：Sui World DAO

去年a16z 等一眾機構力捧以Sui 為代表的Move 公鏈，讓Move 語言在 Meta Diem 的廢墟上大熱歸來；與此同時，從Sui Move 出現那一刻起，不看好的聲音也一直存在：

如果僅僅是因為Move 語言有可能比Solidity 或其它開發語言更優秀，我們就一定需要一個新的智慧合約語言，並樂此不疲地從頭開始搭建一個新Layer1 嗎？

近日，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 層級的保護，以免受其他程式設計師的攻擊。

3、Sui Move 的設計想法

Move 是一種可執行的字節碼語言，用於執行用戶交易和智能合約。在 Sui Move 中，驗證者可以更有效地進行並行化，這使得儲存、執行都變得更容易，而不必將這些東西編碼到協議級別，並讓使用者和程式設計師來考慮。

4、安全性

在智慧合約世界中，我們處於一個約束狀態。我們編寫非常少量的程式碼，而且必須完美無缺，安全性必須是最首先要考慮的事情。 Move 安全性是既要防止程式設計師自我腳踏，還要盡可能為他們提供正確的原語，以便他們能夠防禦攻擊。

5、物件導向和資產

Move 被設計為一種物件導向和資產的智慧合約程式語言，之所以被設計成這樣，是因為大多數Web2 物件導向的程式語言就是這樣。在 Sui Move 中，將事物的中心點放在物件上，高度激勵能夠盡可能精確地表示細粒度存取。 Sui Move 全域儲存的結構是一個從物件 ID 到物件 ID 的對應。

6、安全性對比

Move 透過建構消除了重入和智慧合約編程中缺失的權限檢查問題。 Move 中，物件所有權資訊實際上儲存在物件元資料中，這不是程式設計師可以控制的東西。 Move Prover 是為了防止語言編寫智慧合約的錯誤而設計，可以避免開發者犯下許多基本的錯誤。

7、智能合約語言的治理

最初，Move 是在Facebook 開發的，沒有真正的治理。我們非常謹慎地擴展語言。簡潔性是最主要的東西，但我們會積極地擴展它。 Sam Blackshear 有一個非常具體的願望，例如 Move 被設計為一種跨平台語言，其中一些鏈 EDM 的基本功能仍應適用，並且覆蓋了智能合約開發能手和 Web2 新人，極具靈活性。

8、給開發者的學習建議

閱讀大量程式碼，這是了解語言的最佳方式。樂意分享並深入探討，並找到那些真正喜歡和他人分享你的程式碼，一起建立開源社群的人。任何可以讓你的工作變得更輕鬆的工具，你都應該學習它的工作原理。

以下為播客全文，全文約 25000 字，閱讀時間約 30 分鐘。

主持人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 優化。

我們也邀請到 a16z Crypto 的工程師負責人Eddy Lazzarin ，在此之前，Eddy 在Netflix 從事軟體工程，在Facebook 從事數據工程和數據科學。需要提醒的是，以下內容均不構成投資、商業、法律或稅務建議。

程式設計與智慧合約的歷史

主持人Sonal Chokshi：

我們將從傳統程式設計的歷史開始，第一個發言的是Noah，接著是Sam Blackshear 和Eddy。

a16z Crypto Noah：

我們想了解程式設計歷史如何影響智慧合約程式設計的歷史，因為我覺得有三個東西，傳統程式設計、智慧合約編程，還有Move 語言。這三件事都有它們自己的歷史，對吧？

Sui CTO Sam Blackshear：

沒錯，我喜歡這種框架。人們用語言來設計語法或讓人感到開心，這是對的，但它不僅僅是這些。所以我很喜歡這種大局觀的框架。

a16z Crypto Eddy Lazzarin：

就在這個基礎上，傳統程式設計有著過去二三十年來的各種趨勢。傳統程式語言已經發生了變化，有一些熱門話題來來去去。曾經有很長一段時間，動態程式語言和非常寬鬆的類型檢查是非常受歡迎的。通常認為，跳進去，忘記類型，忘記所有技術細節，只是編寫程式碼是更符合人體工學的方式。

Sui CTO Sam Blackshear：

但最近，人們開始更深入地思考類型系統、靜態類型和編譯時檢查等問題，以便在程式運行之前盡可能了解程式的所有細節。這些趨勢不斷變化。然而，對於智能合約程式來說，由於它是如此新穎，我們還沒有看到智能合約程式設計中這種類型的歷史，這是非常不同的。

我認為Move 語言是我們所看到的最早的關於如何設計語言以適應這一點（類型系統、靜態類型和編譯時檢查等問題）的證據。我很想了解我們期望會發生哪些變化，例如靜態和動態類型等智能合約程式設計中可能出現的話題？這些話題可能還沒出現，因為目前只有一種語言，也就是 Solidity。

主持人Sonal Chokshi：

那麼，這又與轉向智慧合約程式設計有什麼聯繫呢？再請 Sam 回答？

Sui CTO Sam Blackshear：

在這個智能合約空間中，隨著EVM 作為智能合約語言的第一批進入者，存在著不同的趨勢。人們不知道想用智能合約做什麼？我們如何編寫它們或任何這些類型的事情因此，我認為靈活性更加重要，以嘗試了解需要發現使用情況的專家的類型。我感覺現在我們已經知道了，或者至少我們對構建塊有一些了解。

智能合約的趨勢是極其領域特定的，你為資產定義模板，定義轉移資產的策略，檢查存取控制和權限。

這就是基本的，你不會用智慧合約語言寫編譯器或作業系統或任何這些類型的事情。因此，它們非常非常好，它們與通用程式語言相比的優勢。

我認為人們低估了即使ERC-20 標準發生在EVM 可以編程的很久之後，EVM 甚至被認為是編寫以太坊程序的基本構建塊之一。我只是沒有看到任何顯而易見的證據，證明最基本的東西在此之前是明確的。

所以你是對的，現在你可以把類型當作理所當然的事情。我認為類型和這些東西的繞過，是可以承受一定技術債的。如果規模很小，你只想快速移動，而且程式碼可以丟掉，那麼這種技術債是完全可以接受的。但有趣的是，你把它用公司或新創公司的規模來描述，小公司正在快速成長，每個人都能理解整個程式碼庫，這種技術債是可以容忍的。

但是，當它非常非常大時，有大量的人更改程式碼，他們不知道正在建構的新物件和系統的後果。將其放入類型系統中，使您以明確、直接的方式編寫程式碼時遇到障礙，而不是意外地創建後來有人會撞上的玻璃圍欄。

例如，就像你們談到的，能夠防止複製，能夠設定資產的最大供應量。這些約束非常重要，無論專案的規模如何，都需要維持。它們是維護專案的健全和安全非常重要的約束條件。 了解這些界限意味著您現在可以創建程式語言，以允許您強制執行它們。這就是我如何看待 Move 語言的方式。

隨著我們了解到需要做正確的事情所需的約束類型，我們現在有能力將它們包含在語言本身中。因此，我確實認為它與類型有些相似，就像你所說的那樣。

你提到類型對於程式的健全性和安全性非常重要。你們說動態類型可能適用於小型項目，但隨著項目的成長，應該使用靜態類型。我有點不同意，我認為完全靜態的類型可能更適合。這可能是個新穎的看法。它是為了程式設計師的健全性。我見過最可怕的事情是，當我按下我的快捷鍵“control k”時，它會告訴我函數簽名是什麼。當我寫 Python 時，這讓我感到恐懼。我看著函數簽名，只看到參數的名稱。我就像，你到底想要我做什麼？

a16z Noah：

我不敢相信人們會接受那種寫出程式碼後就永遠不會再看一眼的寫法。

a16z Eddy Lazzarin：

他們接受的是預設假設，即他們可以在心中記住系統的要求。

a16z Noah：

但是即使是100 行的程序，我也覺得無法默認這一點。

Sam Blackshear ：

它可以運行，但它並不完美。

a16z Eddy Lazzarin：

我認為你們說的對。而且我認為這種心態已經演變了。以前，類型系統是用來保護程式設計師免受同事傷害的。 當你的新創公司變得太大時，它就很有用了。但現在它更像是在保護我自己。

在智慧合約的環境下，它是在保護我免受攻擊者的攻擊。這是真正的不同之處，因為在普通程式中，你不會在攻擊者受到類型系統的約束時部署程式。攻擊者可以使用其他語言編寫機器碼。你只需要保護自己的防火牆就行了。但在這裡，我編寫這個很好的類型對象，它將流入攻擊者的程式碼並保持其完整性。類型系統必須確保我的安全。

就像你說的那樣，這是一個很棒的工具，它給你帶來了不同的需求，你需要強制執行它們，例如防止複製。這不是你在普通類型系統中需要考慮的問題，或防止刪除或確保你以某種方式使用或銷毀某個值。這些都是因為我們正在研究智能合約並試圖為這些用例提供有意義的類型系統，因此我們最終會將這些東西加入 move 中，也可能會加入未來的智慧合約語言中。

主持人Sonal Chokshi：

實際上，夥計們，讓我們更多地談談傳統程式設計和智慧合約程式設計之間的其他差異。但在我們進一步討論之前，你們能不能快速介紹一下智能合約程式設計師可以使用的語言呢？我認為我們需要了解一下大局，因為我想了解現狀，像是 Solidity、Viper 等。知道哪些內容能夠讓我們更快入門。

Sui CTO Sam Blackshear ：

是的，我想基本的情況是，如果你想編寫智能合約，你幾乎總是會使用 solidity。除非你恰好在幾個其他較小的生態系統之一。

如果你在Polkadot 生態系統中，你會使用ink!（Sui World 註：ink! 是由Parity 開發的智能合約語言，用於在Rust中編寫智能合約並編譯為Wasm 程式碼），它是一個現有的程式語言。如果你在 StarkNet 生態系統中，你使用 Cairo（Sui World 註：Cairo 是 STARK 證明系統的其中一個程式語言）。

但大部分情況下，如果我要給建議，讓你學習如何寫智慧合約，我會建議你學習一些 Solidity，然後學習 EVM。你可能還想使用 Viper，唯一的缺點是 Viper 是較新的，可能更容易出現漏洞。我記得幾年前，在驗證存款合約時，他們發現了 Viper 編譯器的一堆漏洞。發現這些漏洞的人現在在 16z 工作，他是 Day June，他是形式驗證專家。

因為 Day June 是形式驗證專家，所以現在在 a16z 工作。而現實情況是，你需要學習一些內容，你需要學習一些語言。

你甚至需要深入了解EVM，如果你想成為一個真正優秀的智能合約工程師，你需要了解EVM 到一個荒謬的程度，以至於你可以說出每個操作的gas 成本，他們能夠告訴你確切的與gas 成本有關的程式碼。這就是我們目前所處的世界。

a16z Eddy Lazzarin：

也許有一點值得一提的是，作為一名軟體工程師，你總是可以了解你正在運行程式碼的機器。有很多需要了解的關於程式設計環境的知識。但是在智能合約程式設計中，環境非常豐富、非常複雜。有很多上下文需要了解，幾乎與語言本身無關。這就是在你周圍發生的事情，周圍有哪些對象，不同的程式碼如何被呼叫。這是一件非常奇怪的事。

主持人Sonal Chokshi：

那麼，最接近學習Solidity 的人是懂JavaScript的人，這是真的嗎？

Sui CTO Sam Blackshear ：

大家都說是JavaScript，因為它使用「function」這個關鍵字，就像JavaScript 也用到了。但不幸的是，它們並不是非常相似。

a16z Eddy Lazzarin：

從語法上看，Solidity 確實繼承了許多JavaScript 的特性。如果你瞇著眼睛或情緒不好，可能會覺得相似，但實際上完全不同。虛擬機器環境差異巨大，所以共同點很少。

主持人 Sonal Chokshi：

有什麼相似的程式語言嗎？

a16z Noah：

是的，我認為沒有直接相似的程式語言。如果你熟悉Was（Sui World 註：WebAssembly Studio，一個線上工具，用於將C/C++ 和Rust 程式碼編譯為WASM 格式。），並試圖在一個需要高度隔離的環境中寫程式碼（例如Surplus），這可能是最接近的了，這些代碼要獨立執行，但又需要一定程度的通訊。但它仍然不是很相似，思考方式完全不同，表面上的相似可能會有危險。

a16z Eddy Lazzarin：

也許相關的是程式語言史上的一些重大錯誤。 我不知道在區塊鏈方面是否有一些走下了錯誤道路的惡劣歷史。我們是否走了一些可怕的路？

主持人 Sonal Chokshi：

這是個好問題。

Sui CTO Sam Blackshear ：

這是個好問題。 1977 年，C 語言發布，也是 Standard ML 發布的年份。 Standard ML 具有極大的影響力。現在，有 OCaml 語言、Rust 語言都受到其極大的影響，Move 語言也受到其影響。但這些思想已經存在很久了。我想很多人都在思考一個替代的未來，在那個未來中，C 語言沒有成為主流，而是 Standard ML 的想法被廣泛接受，例如強型別、內建安全性。

主持人 Sonal Chokshi：

那麼，這種電腦科技的發展趨勢是什麼呢？我並不是說這是一個錯誤，但我認為像 Standard ML 這樣的語言即使在今天看起來也非常現代化。想像一下那個另類的宇宙是一個有趣的事情，當我第一次發現時就被震撼了。

a16z Eddy Lazzarin：

好奇心作祟，為什麼你認為像C 語言以及類似的語言，它們如此直白、如此命令式？它們在相對較低層次上思考計算機，作為程式語言它們並沒有做很多事情，這就是我對 C 語言的看法，為什麼我們走了這條路？

Sui CTO Sam Blackshear ：

我認為當時的硬體限制迫使你使用C 語言，如果你想要編寫高效的程序，或者推動計算機的邊界，我認為如果你向前推進硬件，你會選擇另一條道路。但是我認為，函數式程式設計很難，它在很多方面都是反直覺的。我不是說 C 語言不難，但我覺得它更容易入門。然後你意識到，我已經做了非常複雜的事情，或者說很難推理，但為時已晚。這是個好點子，函數式語言確實有更陡峭的學習曲線，但是一旦你掌握了，你會意識到，我可以很好地獨立地思考我的程式碼，事情就很好地解決了。

a16z Eddy Lazzarin：

我認為如果你很多地思考電腦是如何在硬件在層面上工作的，那麼像C 語言這樣的語言就更直接了。但如果你對程式語言不是很了解，那麼 C 語言就更容易入門。但是如果你非常了解程式語言，那麼我認為 ML 和函數式程式設計這些類型的語言有更多的東西值得去探索。

Sui CTO Sam Blackshear ：

這是一個大局觀的答案。但我想說的是有關小規模的「計算機語言錯誤」的問題。

a16z Noah：

所以，我對此有些猶豫，因為我一直聽說函數式程式設計有多棒，但是我發現有點難以理解。但我一直想知道的問題是，如果函數式程式設計真的那麼好，為什麼它從來沒有能夠克服當前程式語言的網路效應？它的這種局面令我驚訝。

但我想補充的一點，我認為函數式程式設計帶給我們的巨大貢獻是，我們使用的所有命令式語言都是藉用的。但最好的是，就像你剛才說的，Rust 受標準電子郵件的影響很大，但 Rust 基本上是一種命令式語言，對吧？但它擁有所有從凝視他們而來的奇妙的仙塵。

Sui CTO Sam Blackshear ：

總的來說，我認為真正的問題是，從1977 年開始，命令式語言的影響力太大了。然後是 PRFP，正如你所說，它不是最偉大的，它有自己的偉大想法，孤立地看，每個人都有自己的問題。我們現在只看到像 Rust 這樣的真正的混血兒漂亮地嫁給他們。它真的改變了景觀。

所我想提的一件事是，就是 Tony Hoare 稱之為節點引用的十億美元錯誤。雖然他當時可能是想誇張一下，但顯然這個錯誤帶來的代價比不犯這個錯誤更昂貴。

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 和其他一些有趣的方式來使用這些原語來設計不同的程式設計體驗，非常符合人們想做的事情。

所以，我有一種偏見的看法，認為 Viper 可以給你很多在原始碼語言層面進行實驗的空間。

a16z Eddy Lazzarin：

你對所有替代EVM 字節語言的看法如何？例如有 FE、Iron 和 Viper 等，這些有趣的努力旨在為 EVM 建立更聰明、更複雜的語言，你對此持樂觀態度嗎？

Sui CTO Sam Blackshear ：

所以這些都是編譯成EVM 字節碼的不同原始碼語言。

a16z Eddy Lazzarin：

對，編譯成 EVM 字節碼。

Sui CTO Sam Blackshear ：

我們在Facebook 開始設計Move 時，看到其他當原始碼語言建構EVM 的情況時，我們研究了Solidity 和Viper，這是在我們開始建構EVM 的時候。我們最終得出的結論是，讓人們編寫安全的智能合約最困難的問題是EVM 的底層性質，以及如何讓類型化的值在可信邊界上流動，以及動態決策等等這些問題，這些都是EVM 的特性。

如果你建立一個更好的原始碼語言，你可以讓開發者更難搞砸。也許他們可以進行更高級的驗證，但最終，Move 能夠提供的，而且我們認為很重要的是，程式碼驗證器和 VM 層級的保護，以免受其他程式設計師的攻擊。

原始碼語言不能給你這個，必須將其內建到VM 中，無論你在EVM 上迭代完美原始碼語言多少次，我認為Solidity 很棒，我們也可以做得更好，但我認為，如果你沒有這些基本的保護措施內建到VM 中，你得到的結果最終會不如一些其他路徑。我不是因為我認為 Half 很酷而感到尷尬，而是因為我認為最終狀態不如其他路徑那麼吸引人。

我認為早期智慧合約語言，特別是EVM，過度適配了平台的實作細節，這些實作細節是為以太坊設計的，內部包括了關於交易結構的指令，帳戶結構的指令，使用特定類型的密碼學等等。

我認為這使得在一個不像以太坊那樣的鏈上使用EVM 變得非常困難，你最終不得不繼承以太坊做出的許多設計決策，也許在某些情況下，還要繼承一些讓以太坊難以擴展的錯誤。

在設計Move 時，我們非常清醒地意識到不要將任何區塊鏈特有的東西加入到核心語言中，盡可能地讓它與具體的區塊鏈無關。

這樣你就可以拿著Move，在一個具有瘋狂交易結構的工作量證明鏈上使用它，這個鏈可能是在瑞典這樣做，而另一個鏈在澳洲是這樣做的。這樣，你就不必押注在某個特定的鏈上成為一個 Move 開發者。你可以將你的技能跨越各種不同的鏈使用，包括未來的鏈。我們認為這對一個智慧合約語言的生存至關重要，因為語言最大的資產就是它的社群。而透過讓你的技能跨平台，而不是過度適配於一種語言，你可以擴大社群的規模，從而更好地實現成功。然後，一個大的社區是使得在工具上投入大量資金、在公共庫上投入大量資金以及所有你真正需要一個語言成為大牌並取得成功的東西變得可能。

這是我們從一開始就嘗試做的事情，現在看到了多個真正不同的 Move 鏈，它們在如何整合語言方面非常不同。

a16z Eddy Lazzarin：

在我看來，這是node.js 底層的主題，對吧？

主持人 Sonal Chokshi：

是的。

a16z Eddy Lazzarin：

有很多人知道 JavaScript，他們想做很多事。他們想共享各種庫。現有的程式碼可以啟動伺服器端的 JavaScript 實例，這使得 node 變得有用。這意味著有各種各樣的開發者可能不做後端編程，但可以開始進入並將其作為自己的領域。

Sui CTO Sam Blackshear ：

我覺得這個對比很好。另外，我們想談談關於程式語言治理的問題，因為 Node 顯然有一些非常引人注目的治理分歧和分裂，每個程式語言社群都有許多引人注目的治理分歧和發展方向。我曾經報道 Node，它是我最喜歡的之一。但我想確保我們完成這個主題。還有別的要說的嗎？我覺得你是我們廣播節目的居民老古板，我很喜歡。

a16z Noah：

所以我有一個反面觀點，或者說我有一個很酷的想法。 我一直在想，為什麼沒有人建立一個Move 的OP Rollup，那將會非常酷，考慮到OP 的Rollup 人們是在以太坊上實現的，他們使用MetaMask 和ECDSA 簽名，但似乎沒有使用與我們相同的簽章格式，例如Move 似乎沒有使用ECDSA。

Sui CTO Sam Blackshear ：

是的，我們支援以太坊的EdDSA 和ECDSA簽名格式。

a16z Noah：

很完美，但我的觀點是，你可以建構一些非常有趣的東西。但是，當我試圖學習 Move 時，我一直在盯著甜點和演員狗。我很困惑。

Sui CTO Sam Blackshear ：

確實是個問題，對吧？當有人開始學習 Move 時，他們可能會感到困惑：我正在學習智慧合約語言，但區塊鏈在哪裡？如果你試圖為兩個平台編寫程式碼，它們之間的差異也會產生問題。所以我認為我們仍在努力解決的挑戰是，選擇一個平台，選擇一個甜點，選擇一個 Optus，深入學習它，然後你會發現你的技能和程式碼可以輕鬆轉移到另一個平台。我認為這裡存在一些固有的問題，還有一些文件問題需要解決，以使這一切更加容易。

a16z Eddy Lazzarin：

也許類比一下，取決於你是否認為SQL 是一種可移植的技能。有很多 SQL 方言。有一個反SQL，沒人真正知道它是什麼，但他們能學會SQL，如果你稍微瞇眼睛，你可以使用任何資料庫，可能會對特定的函數名稱或特定的類型有些困惑，但大致上是相同的形狀。我認為這使得 SQL 很強大和耐用。這就是為什麼它仍然是數據的共通語的一部分的原因。也許這就是 Move 的未來。我認為我們可以做得更好。

Sui CTO Sam Blackshear ：

我認為在跨平台方面，這是一個很好的目標，非常應用程式特定。這就是正確的語言來談論表格和談論資料庫。這是一個無可爭議的事實，這就是為什麼每個人都使用它。所以，如果 Move 能成為區塊鏈中的 SQL，我會很高興的。

智能合約程式設計的獨特事物

主持人Sonal Chokshi：

我們已經圍繞著傳統與智能合約程式設計、特定約束和差異以及甚至一些Tread 和智能合約程式設計之間的相似之處來回討論了。有沒有關於智能合約程式設計的獨特事物，我們沒有涵蓋？

a16z Eddy Lazzarin：

在智能合約上下文中，另一個非常重要的事情是資源使用，如Solidity 中的Gas Metering。雖然在很多情況下，計算資源是相對豐富的，計算成本也是非常重要的。但是在智能合約上下文之外或區塊鏈上下文之外，這意味著它僅被涉及和考慮更少。我認為在語言中有關你消耗的資源的概念可能是智能合約程式設計的一個有趣的資源。

Sui CTO Sam Blackshear ：

這是我們非常關注的事情，我們在EVM中建構了Gas Metering，正如你所說，這與傳統程式語言非常不同。

我認為今後的趨勢是Gas Meeting 會變得越來越粗粒度，更多地防止如資源濫用之類的嚴重問題，而不是真正地為每個指令精打細算。

我實際上認為像Gas Golfing（Sui World 註：Gas Golfing 指的是一系列智能合約的跳轉互動中，開發者編寫最節省gas 程式碼的挑戰）這樣的東西雖然非常有趣，但實際上對程式設計風格和安全性都有很大的傷害。

諷刺的是，我們之所以只知道按指令收費的模型，可能是因為如果你有一個龐大的虛擬機，運行10 萬條指令和運行50 萬條指令的差異在實際測量運行時間時微不足道。

所以，我們為什麼要依照指示收費呢？ 因此，我認為我們會看到一種趨勢，就是如何使這更加粗粒度。

每當我看到所有這些不安全的區塊和Solidity 程式碼中的大量內聯彙編時，這讓我想起我們現在處於多麼早期的階段，因為這不是智慧合約開發人員應該考慮的程式設計挑戰，這不是一個成熟的開發生態系統的標誌。但我們正在朝著這個方向發展。我同意我們要考慮極限情況。選擇正確的演算法、選擇正確的資料結構、選擇正確的一般方法，這是大多數軟體工程的情況，都是很重要的。但關於準確計算每條指令的成本的瑣碎問題可能太過繁瑣了。

主持人Sonal Chokshi：

我們談到了優化gas，類型、資產和安全性。還有哪些限制是需要考慮的？

Sui CTO Sam Blackshear ：

這是一個類似於gas 的線程，但我想到的具體子集是狀態。這對我來說是一個大問題。當我考慮 gas 操作時，我喜歡進行極端的 gas 優化。

但是，當我們處理持有真實資金的實際智能合約時，我的一般建議是，除非你可以費盡心思地使用略少於之前使用的狀態，否則你應該做出合理的組織。那是唯一一次我會使用大型彙編區塊的情況，如果你可以做出一些愚蠢的事情來使用更少的狀態，因為這就像一個永遠的資源，我們應該將它放在僅高於執行或調用數據的位置。

a16z Eddy Lazzarin：

我完全同意這個觀點，因為我認為這是根本性的昂貴的問題。如果一個平台允許每個合約都觸及任何一塊狀態，那麼它將很難實現並行化。而像 Squeeze 以及其他一些新的區塊鏈平台所採用的方法是，明確地限定交易可以存取的狀態，至少讓我知道一些。這樣在高層面上平台就能夠更容易將交易實現並行化，包括執行和共識。因此，這是一些程式設計師必須思考的問題：在存取狀態時盡可能地快，不要觸及不需要的狀態，這樣驗證者才能更有效地實現並行化，實現更多的區塊空間。

a16z Noah：

這是否會打開一種世界，即即使在非角色扮演的情況下，不是所有驗證者都需要下載全部狀態？如果你能輕易地將狀態分離開來，讓驗證者只服務它能處理的事務，這是否可以實現？

Sui CTO Sam Blackshear ：

我認為這確實有可能實現這樣的世界。這也為不同的方法開闢了一條道路。

讓我回顧一下，從程式設計師的角度來看，能夠跨越不同的交易觸及整個世界是非常有價值的。但是，我們不能過於強調這個優點，以至於必須透過 Rollup 或跨多個交易來實現，因為這會降低安全性，讓用戶注意到。

我認為區塊鏈的價值來自於這樣的抽象：有一個帳本，所有有價值的狀態都在這個帳本上，我可以一次觸及它們。從程式設計師的角度來看，這是區塊鏈的價值。問題在於：如何在幕後讓事情更有效地進行？如何讓它變得更加稀疏，使得驗證者可以更有效地進行並行化？在 Sui 中，一個驗證者可以有多個工作人員，每個工作人員負責一部分狀態。但從程式設計師的角度、甚至從其他驗證者的角度來看，它看起來像是一個邏輯實體，它可以完成一切工作。

這使得儲存、執行都變得更容易，而不必將這些東西編碼到協定級別，並讓使用者和程式設計師來考慮。

智能合約程式思維方式上的改變

主持人Sonal Chokshi：

我們剛剛討論了一些與智能合約程式相關的獨特之處。還有哪些思考方式上的改變？我們已經談到了一些，像 Eddie 提到的，一個巨大的轉變是，在程式設計的世界中，至少自從電腦的早期，我們處於豐富的世界，但在這個世界中，我們處於限制的世界。那是一個思考方式的例子。還有哪些思維方式的轉變？特別是對於你們每個人來說，作為你們接觸智能合約程式設計的程式設計師，有什麼讓你們感到驚訝，或者教會了你們，或者讓你們對某些事情有了不同的看法？

a16z Eddy Lazzarin：

也許一個有點傻的例子是，我還記得幾年前我第一次學到ERC-20 Token的餘額不是你的帳戶擁有的東西。你的地址沒有Token餘額。取代它的是，有一個Token合約，記錄著哪個地址有多少餘額。當你想要向某人轉移Token時，你不是發送給他們一些Token。相反，你需要到合約中進行所有這些低級別的操作，改變你的地址和他們的地址所持有的餘額。你有權限操作和改變那個合約。這是一種非常反直覺的方式，在 EVM 和 Slippery 中這是第一次讓我注意到的關於 Move 的一個有趣的思維方式轉變。這是有趣的思維方式轉變，因為我們常聽到的英文單字不一定與程式設計模型相對應。

Sui CTO Sam Blackshear ：

我想要補充一點，這與你在實際操作時有關。在正常的世界中，我們非常關注開發人員的生產力，因為工程師的工作是編寫大量程式碼，讓這些程式碼只有幾個錯誤，而這些錯誤不會太嚴重。而在智慧合約世界中，你的工作是寫非常少量的程式碼，而且必須完美無缺。它必須在所有可能的方面都是完美的。否則，你將失去數億其他人的錢。這是一種完全不同的思考方式的轉變。花兩個月的時間盯著 1000 行程式碼，並嘗試想出如何使其更好、更重要的是，如何使其完美，然後審核人員也要做同樣的工作，判斷它是否完美。

主持人 Sonal Chokshi：

這是一個大的思維轉變。在程式設計的世界裡，至少自從電腦的早期以來，我們一直處於豐富的世界，但在這個世界中，我們處於一個約束的世界。

a16z Eddy Lazzarin：

另一個思維轉變是，在ERC 20 Token的世界裡，你的地址沒有代Token餘額。你不能發送Token，你必須去訪問Token合約，在Token合約中查找地址對應的Token餘額，然後通過修改地址和餘額來完成Token轉移。這是一種比較反直覺的思考方式，但在 EVM 和 Move 中，這是非常重要的思考轉變。

Sui CTO Sam Blackshear ：

在智慧合約程式設計中，你的工作是寫一小段程式碼，而且必須是完美的，因為這個代碼可能涉及到數億人的資金安全。你必須仔細審查程式碼，確保程式碼的正確性。

另外，升級智慧合約的難度比升級行動應用程式或網站更高，因為在智慧合約中，程式碼是不可變的。在智慧合約程式設計中，你必須考慮如何支援安全的升級和信任，使其看起來更像傳統生態系統。

但是在智慧合約程式設計中，你需要擁有一個對抗性的思考方式，這對來自其他領域的人可能很陌生。這是因為在智慧合約中的部署模型，你不僅需要考慮你的應用程式的預期使用情況，還要考慮非預期的使用情況。因為在傳統程式設計中，有方法可以隱藏自己，限制為一個小型 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 ：

是的，完全正確。這裡的想法是，介面不定義行為，它定義了預期行為。例如，當你閱讀介面的規格、參數名稱甚至類型時，它告訴你想要完成什麼。但是並不能保證它一定會發生。

所以，如果你寫的程式碼是用來保護某些東西的，但實際上你留下了一個空白支票供攻擊者、其他人填寫。這在契約法中似乎是一種犯罪。這是一個未明確規定的合約。我非常喜歡這個特性，它在傳統的程式語言中很受歡迎。但我們認為，在智能合約中，這導致了許多不同的問題。例如，重新進入需要動態調度。例如，如果您取消了動態調度，則根本沒有重新進入。像以太坊中的毒藥Token這樣的事情發生了，因為您重寫了轉移函數，而每個人都知道直觀地說，它只是用來轉移資金，也許不會做其他任何事情。但現在你讓它做一些超出預期的事情，例如竊取金錢。這就是一個特性的例子，如果將其刪除，那麼對程式碼進行推理並進行適當的封裝就變得更加容易了，因為每次看到一個呼叫點時，您都知道它將確切地做什麼，您不必擔心其他人以後會做出令您驚訝的事情。

a16z Eddy Lazzarin：

確切地說，我認為這個類比就像如果你定義一個關於椅子的接口，它有四條腿和一個座位，你描述的是它的具體層面，而不是行為層面，你沒有描述可能是隱含或默認的關於椅子的其他事情，比如它具有某種結構完整性，它有特定的材料，它是以某種方式放置的。

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 類型。這不是某個人想要覆蓋的東西。您定義拆分。

當你想讓某人自訂Token的行為時，使用所謂的能力模式，例如對於Token，你可能想要定制的一件事情是總供應量是多少，或更根本的是它的政策是什麼？你可以這樣表達：好的，你有類型為「t」的點結構體，然後有不同的 t 的實例化，例如美元、英鎊或其他的貨幣類型。對於你想要自訂的東西，你在能力層面上提供它，創建一個Token的函數。你說，這是我的Token的類型參數，然後它會給你一個叫做「資金寶庫能力」的東西。然後有其他的邏輯確保只有持有 t 的寶庫能力的人才能鑄造和銷毀 t 類型的Token。你可以拿到這個寶庫能力，將它鎖定在一個不同的合約中，強制執行總供應量的限制。你可以將它放在某個地方，比如說只在周二評論，但不在周四評論。你倒置了控制流，這就允許你進行任意的組合。這是一個技巧的例子，但這個技巧幾乎可以在所有地方使用，如果你想要讓行為以某種方式運作，你需要硬編碼。這聽起來不好，但你實作特定的兩種方法，然後你為你想允許的東西定義這些能力。

a16z Eddy Lazzarin：

你認為能力是你可以加入一個看起來像是傳統程式設計師的介面的約束嗎？

Sui CTO Sam Blackshear ：

是的，我認為大多數這些介面模式可以非常直接地變體。這有點難以編譯，但是你可以說，這是這個介面想要做的事情的等效能力模式。

主持人Sonal Chokshi：

順便問一下，Sam，你覺得這樣滿意嗎？請隨意表示異議，有點衝突感是好事。

Sui CTO Sam Blackshear ：

我覺得這樣還算滿意，因為我認為如果你可以有一個具有內在能力的模組或結構體，而這些模組可以被餵入具有非常預先定義行為的模組中，你最終可以得到完全相同的行為，就像模組可以做到的那樣。模組接受抽象的結構體，那個結構體在那個模組中被定義，然後這個結構體裡面有一個內在的能力。這實際上非常好用，因為你可以得到非常好的權限樣式註冊表，它們幾乎自然地從這裡產生，就像什麼叫做 DS-Off 註冊表就是這樣，對吧？

a16z Noah：

完全正確。這些能力是可以擴展表示你被允許做的事情。因此這有很多其他的好處。比如說，你想知道我的帳戶能做什麼，你看看我有哪些能力就行了。然後，你可以做程式分析，看看如果我有一個寶庫能力，那麼我可以呼叫哪些函數，還有其他一些類似的東西。

物件導向與以資產為導向的程式設計

a16z Eddy Lazzarin：

所以我可能有點提前談到證明器，但是這些能力對類型系統可見嗎？在對程式進行靜態分析的時候，這些能力在程式的哪個時候是可見的？如果我寫了一些特定實例化的程式碼，其中有能力，那麼在我運行它之前，能夠很早地發現我違反了能力嗎？

a16z Noah：

是的，這些能力是對類型系統可見的，並且在程式的靜態分析階段就可見了。如果我寫了一個具有能力的特定實例化的類型的程式碼，那麼非常早就可以發現我是否違反了能力，不需要在虛擬機器上運行它。

Sui CTO Sam Blackshear ：

讓我簡單回答這個問題，然後再提供一些背景信息，它們對編譯器可見，並且是類型系統的一部分。這是我們非常重要的利用點。但我想稍微講一下 Move 可移動性系統中的結構體，以及它如何捲入類似於審計的能力等級。如果這不會分散注意力的話。

在Move 中，你有結構體類型和類似其他語言的結構體，它們可以有字段，可以是基本類型的字段，也可以是其他結構體。而更加有趣，也許更加不同的是，這些結構體具有能力。如果你熟悉 Rust，那麼能力有點像是標記交易。它們聲明了你在結構體上允許進行的內建操作。

同樣重要的是，如果你沒有能力，你就不能做那些事。比較簡單的一個能力是非常重要的，那就是複製的能力。如果你有一個Token類型或非同質化Token之類的東西，在電腦中，它只是一些比特，但你不希望允許別人隨意複製這個東西。

在Move 中，如果你沒有聲明你的結構體具有複製的能力，那麼你就不能使用我們相當於“man copy”的操作。

所以像整數和字串這樣的東西都有複製。但如果你不想讓你的類型具有複製的能力，那麼你就不給它。然後還有其他的能力，例如丟棄，這被稱為 drop 能力。這就涉及到了有趣的線性類型的東西，如果你想要丟棄某些東西，例如把它放到作用域之外，或者覆蓋掉它，那麼你就給它 drop 能力。但如果你不給 drop，那麼消除它的唯一方法就是定義該類型的模組所期望的任何策略。

公共語言運行庫(common language runtime,CLR) 舉個具體的例子，如果你想為你的Token保持一個總供應量，你就不給你的Token drop 能力。然後除了在聲明它的模組中定義的 burn 函數，沒有其他方式可以擺脫它，這個函數可以更新總供應量。這些都是你可以使用的技巧。還有幾個與儲存有關的能力，例如它是否可以儲存在全域儲存中，我不會詳細講述，因為它們對這個問題不太相關。但基本上，能力已經融入審計程序中，審計程序了解類型系統，並知道如何利用類型系統來解決問題。如果我寫一個說明，說只有一個這樣的東西，那麼審計程式可以利用這個來證明這個屬性。因此，能力和類型系統的保證是相輔相成的。

a16z Noah：

當你提到drop 時，我就想談談我最喜歡的東西。能不能談一下熱土豆模式是什麼？如果還有其他類似的酷東西，它是我最喜歡的奇怪事情之一，是從 Move 產生的。

Sui CTO Sam Blackshear ：

這確實是個奇怪的東西。這與能力非常密切相關。通常在程式語言中，你對於何時可以消除你的值沒有太多的控制，可能你有一個析構函數來說明你的值何時會消失。但是有時析構函數的保證比較弱，或者你不能簡單地說類似「你不能刪除我的類型」。這聽起來像是一個奇怪的限制，但它實際上非常有力，特別是在沒有動態分派的情況下。

我先舉一個熱馬鈴薯的例子，然後我們可以深入了解閃電貸之類的東西。如果你在以太坊上進行閃電貸，這是一個標準，你可以重載它，基本上你公開一個回調函數，就像一個閃電貸合約，你給我錢，我的回調函數然後取回錢之類的，而在Move 中，你這樣做的方式是有人去閃電貸合約，他們說，“嘿，給我53 塊，但他們也給你所謂的熱土豆對象。

熱馬鈴薯物件是一個結構體，它沒有能力。其藏起來。。變量，以決定何時可以銷毀這些物件。可以做任何想做的事情，你也可以用這種方法實現。 p>

當我第一次聽到“燙手山芋”模式時，我想到了像“mute texas”這樣的鎖的有趣用途，這些鎖僅出於人體工程學目的，利用了類型系統，以強制特定物件的使用方式，幾乎是商業邏輯層級的要求。我認為這是非常聰明的，感覺非常現代化，是程式語言中人體工學的高品質使用方式，而這種方式在傳統的程式語言中甚至還不是很常見，但在智能合約環境中顯然非常有價值，因為這裡有更多的邏輯要求，要考慮可能涉及的價值和安全性。

Sui CTO Sam Blackshear ：

在我們討論任何具體的例子之前，您能否快速概述一下我們的物件系統的高階概述？物件是什麼，誰擁有它們？對像如何擁有其他對象，模組如何與它們一起工作？

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。我們可以說，這個物件有一個映射在裡面，然後我可以在這個映射裡放一些東西。或者你可以說，當我定義這個物件時，它有十個字段，但我實際上想在後來添加一個新字段，我將升級我的合約。我想在事後新增一個欄位。

我們表示它的方式是使用這些父物件和子物件關係，每個子物件都與一個鍵值相關聯，可以是任意的Move 值，例如字串或u64 ，或任何你想要的其他值。

a16z Noah：

是的，與父親對象的概念有關，我認為讓它真正成為我的「靈光一閃」的事情實際上是幾個月前我花時間深入研究Sui Move，並從寫一個只有一個物件的程式一直到重新實現了大部分Uniswap V2 風格的卡牌組合。我做的一個小專案真正讓我意識到擁有物件的物件是如此有價值。這個項目只有三個對象，鎖、金子和一個空的障礙物。有一個很基本的模組，你可以想像它可以創造由鑰匙物件擁有的金子。然後唯一的取出金子的方法是有一個函數，它需要鎖和鑰匙，並顯然銷毀鎖，把金子給你，然後銷毀你的鑰匙。這種方式非常有趣，透過這種方式，你可以描述物件之間的關係，並以非常細粒度的方式描述權限。

Sui CTO Sam Blackshear ：

這也正是我們所考慮的。我喜歡你描述三個不同物件的嵌套方式，因為這種方式在深入到更深層次時變得更加強大。這使得身為程式設計師更容易結構化，以確保我可以到達第二層，然後可以觸及第三層，但我無法直接從第一層到達第三層。我認為這也使得對於從智能合約空間之外的程式設計師來說更容易理解，例如這些人非常熟悉編寫物件樹、DOM 物件樹，如果你是遊戲程式設計師，一切都是場景層次結構，其中有一個角色，他們有一個庫存，然後庫存裡可能有一些小東西。你可以非常直接地在 Move 中編碼這些內容，然後類型系統允許你以非常直接且安全的方式設定這種存取控制。我認為這是一種非常實際的程式設計體驗，它真正反映了關於現實世界的直覺，或者如何描述某些東西，然後直接轉化為相關的程式碼。

Move 與Solidity 的安全性比較

主持人Sonal Chokshi：

順便說一下，在來到Wired 雜誌之前，我曾經在施樂公園待了6 天，這讓我想起了一點關於物件導向程式設計的歷史。你剛才說的超級有趣，因為他們發明了 Smalltalk，這是許多今天物件導向框架的早期前身。無論如何，有沒有其他的話題想討論？

a16z Noah：

我只有一個普遍性的問題，但實際上，有沒有在EVM 世界中發生的駭客事件等等，你認為如果使用Move，由於類型系統的緣故，這些事件就不會發生在第一次。

Sui CTO Sam Blackshear ：

在EVM 世界中，我們已經提到了動態分配和重入，Move 透過構造消除了重入，任何與重入相關的問題都會消失，我認為人們做得很好。 現在，我認為它避免了反應和查看。

a16z Eddy Lazzarin：

但是你能解釋一下，為什麼Move 會讓這些問題不可能發生嗎？

Sui CTO Sam Blackshear ：

重入，對吧？發生了什麼事？你寫了一些程式碼，呼叫了某個函數。問題在於，有人提供了一個你原本沒有預料到的函數實作。為了實現這一點，函數呼叫必須是動態的。它必須呼叫程式碼，基本上是由呼叫者提供的函數指針，可能是攻擊者。如果你沒有任何動態函數調用，如果你總是知道一個函數調用的目標，那麼這根本就不可能發生，就像你調用的任何東西，你可能不知道程式碼做了什麼，但你知道它是什麼，你可以測試它，你可以驗證它，所有的東西都在那裡。所以從根本上來說，別人不可能提供讓你的模組行為變得出乎你意料的程式碼，因為這只是一個靜態的函數呼叫。太酷了。

a16z Eddy Lazzarin：

因此，這就消除了可重入攻擊，這在Solidity 開發中一直是個永恆的問題。

Sui CTO Sam Blackshear ：

是的，我認為Move 基本上消除了智能合約程式中缺少的權限檢查問題。 有很多時候你在寫一些程式碼時需要明確地傳遞所有的帳戶，而且你必須說，我是否有權做這件事。你寫了一個簡單的程式碼，但卻忘了檢查發送者是否是某個人，或者是否這個人可以存取它。我認為這些問題經常發生。

所以在 Move 中，物件所有權資訊實際上儲存在物件元資料中。這不是程式設計師可以控制的東西。

當你查看這些物件時，它們會說：「我由這個地址擁有」，或者「我由這個其他物件擁有」，或者「我是共享物件」或者「我是不可變物件」。程式設計師不能忘記檢查它的擁有者，因為執行時間會在執行傳入這個 Sui 物件的程式碼之前進行檢查。運行時會說：「我看到了這個交易中心，我看到了他們想要使用的所有對象。我正在檢查他們是否實際擁有這些對象，或者它們擁有一個可以中轉擁有它們的對象，以便他們有權使用它們。，因為最難保護的是程式設計師沒有告訴你的規範。 p>

主持人Sonal Chokshi：

順便說一句，在遠期或近期的長期規劃方面，當人們以這種方式更多地合作時，企業規模會發生什麼，我認為這將非常有趣，因為它顯然是分散式的，不僅僅是一個公司，有時人們會合作。，當你考慮現在的老舊方式，你有像開發人員和所有這些最佳實踐和所有這些方法。正式化，這還為時過早，但我非常好奇這種事情會是什麼樣子。 br>

現在EVM 的工具很好用，那麼Move 的工具呢？ Sui CTO Sam Blackshear ：

我認為我們的工具還處於很早期的階段。 io 或npm 一樣。只能透過複製貼上的方式來分享程式碼。但我認為我們還有很多事情要做，使它們更易用。 p>

Move Prover 的重要性

主持人Sonal Chokshi：

能否簡單談一下形式化驗證以及為什麼Move Prover 很重要？

Sui CTO Sam Blackshear ：

形式化驗證很具有挑戰性，通常需要專家或博士來使用。我們正在努力將它推廣到每個日常開發者，而不需要專業知識。

目前還不清楚這個目標能否實現，但我們看到了一些很有前途的項目。例如，最近有人將一個智能合約的所有規範提交到了一張文件中，之後只需要為新函數寫規範，這就使得形式化驗證變得非常容易。不過，形式化驗證還有很多需要改進的地方，包括提高易用性和功能強度。

還有像fuzzer 這樣的工具，雖然不如形式化驗證好用，但對於一些重要的正確性檢查非常有幫助，特別是當你需要寫一些非常複雜的程式碼時。我們也有一些學術界的庫在研發這些工具。除此之外，我們也正在研究如何讓編寫程式變得更容易，例如支援更多整合開發環境、程式合成和人工智慧等。

主持人 Sonal Chokshi：

如何使用 Move Prover？如果我想試試它怎麼辦？

Sui CTO Sam Blackshear ：

首先你需要拿到你已經測試過的程序。驗證不是測試的補充。然後你可以寫一些很難測試或很難檢查的內容。這可能是一些簡單的函數前後條件。比如說，如果我的函數輸入滿足這個條件，那麼輸出應該就滿足那個條件。你也可以編寫資料不變量，例如你有一個計數器，你想證明它總是在增加，你可以編寫一個規範，將其附加到計數器結構中，以檢查它是否成立。

然後它會查看所有的函數，並確保這些規範都成立。還有更進階的用法，像是全域儲存和變數。你可能會想說，這個物件總是只有一個，或是這個物件有兩個，然後有三個。以及這個物件的欄位和那個物件的欄位之間的關係。這些規範很大程度上取決於應用程式。

Move 語言可以避免很多基本的錯誤，但對於你作為程式設計師來說，總是會有一些特定於你的應用程式的正確性條件。規範語言使編寫這些條件變得容易，可以在編寫程式碼之後或某些情況下甚至在編寫程式碼之前編寫它們，並確保它們在所有可能的程式執行和所有可能的函數呼叫中都成立。

因此，現在，規範語言與編譯器集成，因此您可以在任何這些模式下提取它並嘗試使用它。它還與構建系統整合。您只需要執行 move build -prove，它就會檢查這些規格。

a16z Noah：

酷！ Prover 能理解 Sui 物件模型和 Sui 交易系統嗎？例如，我能否證明關於跨交易的一些可能修改全局狀態的內容？

Sui CTO Sam Blackshear ：

它還沒有完全理解，但它並不需要完全理解。例如，如果你想證明計數器始終在增加，這是一個 Sui 對象，但它不需要完全理解 Sui 就可以證明。 即使在核心 Move 的 prover 中，它也真正考慮物件和全域儲存的層面，而不是像交易這樣的概念。 因此，今天它確實只能考慮函數和事務的層面，這也能夠正常工作。但我想我們將來可能會在 Sui 方面做更多的事情，特別是關於父子關係和異質物件映射。

程式語言的治理

主持人Sonal Chokshi：

我們可以談談程式語言的治理嗎？程式語言的演進有著悠久的歷史，但是在區塊鏈和加密貨幣的背景下，治理話題顯然更加重要，因為有許多其他方面需要考慮，如分權、開源、分散式社群、代幣和經濟學資產等，這有時作為激勵計劃的一部分參與其中。

a16z Eddy Lazzarin：

特別是因為它們是開源的，能在許多不同的上下文中使用，它們被視為公共物品，但它們不同，需要設計和細節的關注。程式語言應該如何發展？今天有很多程式語言似乎都有不同的治理方式，如我所想到的前兩者是 C++委員會和 WG21 委員會，還有一些非常複雜的名稱。

然後像 Python，Guido 是它的生命之恩人，擁有 benevolent dictator for life。那麼，您認為什麼是現代化的程式語言治理方式呢？特別是在加密貨幣領域，這是一種獨特的情況，因為這些程式語言可能與層一相連，這是一種依賴於程式語言的不同類型的東西，它是一種公共物品，但是它有利益相關者，它有大量的資本附加價值，有許多價值正在傳遞。也許有一些程式語言的治理模式更適合區塊鏈。我對思考程式語言應該如何治理或更好地說，移動如何發展，考慮到所有巨大的利益相關者和設計語言保護其安全性質的重要性非常感興趣。

Sui CTO Sam Blackshear ：

嗯，我不會認為我的見解適用於其他程式語言。但對 Move 來說，我有一個非常具體的看法，就是這種跨平台的願望。 Move 被設計為一種跨平台語言，其中一些鏈 EDM 的基本功能仍應適用，並且涵蓋了智能合約開發能手和 Web2 新人，極具靈活性。

除了對程式設計師和平台設計者的好處外，治理是另一個原因，幾乎所有區塊鏈語言中的有爭議的決定，例如：我們應該增加這個限制嗎？或者我們應該支持這種簽名方案嗎？或者我們應該擁有這個庫？我們試圖將其設定在適配器層，也就是建立在語言形式之上的平台，而核心語言非常簡潔。簡潔性是我們語言的關鍵設計原則之一，非常不依賴區塊鏈。

因此，如果我們要與社群的利害關係人進行辯論，它不會像「我們應該增加 gas 限制」這樣的問題。而是像「我們應該擁有電子郵件」這樣的問題，這是一個更純粹的設計問題，可以受到來自一個或多個Move 平台的問題或用例的影響，但不太可能朝著對某個利益相關者有利而對其他人不利的方向發展。到目前為止，這種模式運作得很好，但我們還需要看看未來會發生什麼。

基本上，Move 語言的治理方式是，最初，Move 是在 Facebook 開發的，沒有真正的治理。它只是我們使用它的方式，雖然我們有這些設計原則。

現在，團隊分散了一些，我們有許多來自不同機構的成員。有些人在我們這裡，有些人在其它地方。有一些來自學術界、安全社群的第三方貢獻者，還有一些 Move 鏈的星際幣等其他機構。我們每個星期四都會開會。

我們會討論 Move 的設計問題，我們非常謹慎地擴展語言。簡潔性是主要的東西，但我們會積極地擴展它。

例如，加入這個東西會使在 Move 之上的這些層次的實驗更容易進行。一旦我們看到這些實驗的結果，或者每個人似乎都在做同樣的事情，那麼我們就會將其移到核心語言中。因此，我們對治理的答案是：盡可能避免治理，透過讓有爭議的事情發生在Move 之上的層次，以及將簡潔性作為核心原則之一，使我們在僅當每個程式設計師都需要某個東西時，才會增加新的內容。

主持人Sonal Chokshi：

你們作為程式設計師，對於另一面的事情，例如Noah，你們真的在乎嗎？比如說你選擇使用什麼工具，怎麼參與？你們在意社群或程式語言的治理嗎？還是只在乎你們獲取所需的工具？

a16z Noah：

我認為在某種程度上是有關係的，例如你想使用一個被很多人使用的語言，這樣你就可以得到更多的貢獻者，對吧？你也想要一個不會被拋棄的語言，對吧？那些應該是主要的考慮因素。

但是，我並不在意 Python 是由獨裁統治還是委員會治理，只要能達成目標就好。儘管我認為很多人不在意，但是有很多爭論表明由委員會治理已經破壞了很多程式語言，我想。

主持人 Sonal Chokshi：

是啊，我一直覺得很有趣。

Sui CTO Sam Blackshear ：

我認為這很重要。我有一些技術上的設想，像是跨平台的程式和資源，以及這些東西應該有的大致想法。但是這是一個社區計畫。很多貢獻者為設計的許多方面做出了貢獻，我並不是 Move 或任何其他東西的獨裁者。但是，我認為我的角色是策展人，確保每個人都在同一頁，並確保在想法湧現時，我們根據這些原則進行評估，這些想法可以來自任何人。

但最重要的是我們有共同的願景。每種語言都略有不同。我認為它們固有地反映了它們的用途、創建者和社區的個性等等因素。所以肯定不會有一種適用於所有的規則。

主持人 Sonal Chokshi：

對，完全沒問題，這很有道理。

Sam 怎麼進入Move 的

所以在我們結束前的最後幾個問題裡，我突然意識到我們從來沒有聽過Sam 怎麼來到Move 的。我主要感興趣的不僅僅是因為我想聽你的故事，我相信它很棒，但我更感興趣的是你是如何透過思考來解決問題的。所以可以快速分享一下這個過程嗎？當然可以。

Sui CTO Sam Blackshear ：

我開始作為程式語言研究員進行職業生涯。我從事靜態分析和程序驗證的工作，這意味著我花了很多時間看真實的程序，尋找漏洞，並嘗試弄清楚程式設計師經常犯的錯誤類型是什麼，以及導致這些錯誤的原因是什麼。是語言的基本問題使得某些類型的錯誤變得太容易？是他們所使用的框架的問題？還是只是有關人類心理學，使得某些類型的錯誤比其他錯誤更容易被發現？

基本上，在我的博士期間，我花了很多時間研究真實的程序，尋找漏洞，然後建立這些工具，試圖在不運行程式碼的情況下查看程式碼並嘗試在之前捕捉這些錯誤。而這種事情在一般情況下是無法解決的。當你進行靜態分析時，總是在與停機問題作鬥爭，但在實踐中，你可以無限地接近完美的結果，而不是在理論中得出平均結果。所以我花了很多時間做這件事，看了所有經典類型的漏洞，如空引用、緩衝區溢位、安全性問題等等。我真的很享受這個工作，但是很難找到這些例子和很多人真正關心的數據集。

但在我博士的最後階段，我在 Facebook 實習。這是在2013 年到2014 年左右，他們正在從Web 世界向行動世界過渡，並且發現當我將漏洞發佈到行動應用程式時，它會在那裡存在兩週，而在Web 中，我可以立即修復它。當我加入後，Android 上的分裂問題是造成問題最嚴重的問題，因為這會導致無法修復的漏洞。他們在靜態分析技術上進行了大量投資。他們從我的領域收購了一個研究小組，我有機會與他們一起工作，並繼續我真正喜歡的工作。但是，與其結束於單一程式的漏洞修復，我開始思考如何設計一種語言來使這種漏洞更難以產生。我對語言設計和程式安全的興趣越來越大，開始產生一些關於如何建立更安全的語言的想法。後來，我在 2018 年加入了 Libra 項目，這是一個建立基於區塊鏈的全球支付網路的項目，我被徵用為程式語言的專家。這個專案需要一個新的程式語言，因此我開始著手建立 Move 語言，並運用我先前的經驗來解決一些語言設計上的挑戰，例如如何確保 Move 智慧合約的安全性和正確性。

主持人Sonal Chokshi：

所以Libra 也被重新命名為diem，這是今天很多人可能知道的。還有一個快速的提醒，你的博士論文的實際主題是什麼？

Sui CTO Sam Blackshear ：

我的博士論文主要研究目標導向的靜態分析。通常，在進行靜態分析時，你會查看整個程式並建立有關程式的事實資料庫，然後透過取得該事實資料庫來尋找漏洞。這種方法很有效，但對於非常大的程式而言，不太容易擴展，因為你必須查看整個程式並做所有事情。而你可能有一個非常具體的問題，只專注於程式中的一個特定部分。例如，如果你正在運行分析器，並且在 CI 中報告漏洞，你真的想要報告在該 pull request 中發生的漏洞。對程序中的其餘部分不是很關心。

在我的博士論文中，我研究了目標導向的靜態分析。這意味著我希望靜態分析的效率可以隨著我關心的特定屬性的複雜性而擴展，而不是隨著輸入程式的大小而擴展。如果這個屬性非常簡單，只需要進行簡單的推理就可以確定其安全性或漏洞性，我希望它非常快。或者如果這需要查看整個程式進行推理，則相應地會更慢。這是一件有用的事情，因為靜態分析的一個主要問題是非常慢，特別是當你在運行像巨大的幾百萬行程式時。我在這個靜態分析子領域中研究了一個新的理論，稱為抽象解釋，旨在使抽象解釋更具目標導向性和屬性導向性，從而提高效率和精確度。

主持人 Sonal Chokshi：

非常有趣。你提到你在背景中也對心理學很感興趣，當你設計你的博士研究以及現在的工作時，你可以快速介紹程式設計師的心理學嗎？因為你沒有滿足我的好奇心。

Sui CTO Sam Blackshear ：

當我在2018 年來到Libra 時，我們基本上上需要在Libra 建立智能合約，你需要想出這意味著什麼。你不能在真空中進行推理，就像語言基本上就是問題解決工具一樣。所以我看了很多 Solidity 和智能合約程式碼。我想知道程式設計師用這些東西做什麼？語言在哪裡幫助了他們？在哪裡妨礙了他們？這個問題的主要結論是基本上所有這些程序都在試圖做同一件事。

他們試圖談論資產，試圖轉移它們，試圖定義它們。但是程式碼編寫的方式總是如此間接。這就像一種粗暴的設計練習，你試著談論這件事，但沒有詞彙來表達它。這就是心理學的元素，我可以閱讀程式並思考，這個人在想什麼？在他們的頭腦中，相對於他們實際編寫的程式碼？這個翻譯層中的障礙是什麼？語言如何透過提供正確的抽象來幫助他們？這些問題沒有客觀的答案。這就像我也是程式設計師，我會怎麼寫這段程式碼？或者我會發現什麼直覺又什麼困惑？

所以基本上，決定創建Move 而不是在EVM 上構建或使用現有語言是因為，正如我們之前所說，這種智能合約需求與其他任何東西都非常不同，使用現有語言沒有所需的抽像或特徵是沒有意義的。

如果你在 EVM 中使用 Solidity 之類的東西，這是這個領域的第一次嘗試。因此，它沒有合理地預測人們將要嘗試做什麼。所以我認為我們有所有這些第二移動者的優勢。我們了解人們想做什麼，什麼效果好，什麼效果不好。我們應該利用這一點來打造一個新的語言。說服人們需要建立一個新的程式語言是一個有趣的旅程，我們可以在另一個時間討論，但是有人告訴你你應該說不。很多人對 Facebook 是否有這種嘗試的願景持有合理的懷疑態度。

主持人Sonal Chokshi：

有趣的是，感覺這幾乎是你能夠回應唯一的地方，甚至更好的是，你們現在可以將其帶離Facebook 並繼續前進。實際上，對於它的誕生和發展來說，這幾乎是理想的條件。事實上，這對它們兩者都是一個很好的機會。

Sui CTO Sam Blackshear ：

完全是意外之喜。

主持人 Sonal Chokshi：

那就很好了解了。

給智慧合約程式語言開發者的建議

最後一個小問題，如果你們有一個建議想要給那些想要了解智慧合約程式語言或已經在這個領域的人，如果你們可以用兩秒鐘的時間給一個建議，你們會說什麼？

Sui CTO Sam Blackshear ：

閱讀大量程式碼，了解程式碼的目的以及底層程式碼實際上是如何做到這一點，它做得好和不好在哪裡。

主持人 Sonal Chokshi：

為什麼？簡單地說？

Sui CTO Sam Blackshear ：

我認為這是了解語言的最佳方式，它是一個很抽象的東西。但是，如果你從某個東西開始，只是試著弄清楚如何做到這一點，我認為這是一條更具體的路線，也很容易從中進行概括。好的。

主持人 Sonal Chokshi：

艾迪，你有什麼建議嗎？

a16z Eddy Lazzarin：

這是個好問題。我完全同意 Sam 說的話。我還想補充一點，因為我們還在早期階段，人們都喜歡分享一些有趣的東西，例如在區塊鏈上編程有多瘋狂。有很多人非常樂意分享，樂意深入探討。每次我在任何一個大型的社交群組或任何一個論壇上有問題的時候，人們總是樂於和我分享。所以我會建議大家去找那些你真正喜歡和他人分享你的程式碼，一起建立開源社群的人。