來源： Sui Network
近日，我們與Mysten Labs的首席技術官、Move編程語言創作者Sam Blackshear進行了交談，討論了他為什麼開發Sui Move這種新的智能合約編程語言、Sui能夠擴展的功能以及去中心化技術對構建者的好處。
以下為本次採訪內容：
Q1、首先，您能概述一下編程語言是什麼，開發者在選擇編程語言時最關注的品質是什麼，以及是什麼推動您開發自己的編程語言嗎？
編程語言只是一種與計算機進行友好、安全、高效和明確的交互工具，對於計算機來說，這一點尤為重要。我們不能用自然語言與計算機交流，因為自然語言的整個意義是具有豐富性和表達能力的。當你用稍微不同的語氣或選擇細微不同的方式來表達詞彙時，你的句子或段落意思就會完全不同。
而在編程語言中，最重要的就是具備精確定義的語義。當你編寫一個程序時，你清楚它將要做什麼。如果你對它進行微小的調整，你知道這個變化會產生什麼結果。這一點在多個層面上都得要保持，比如你可以用一種源語言編寫代碼，它有一種含義，然後被轉換為其他形式表示，那它也應該具有相同的含義，直到觸達機器的處理模塊也是這樣。
我認為，與自然語言不同，編程語言的本質是針對特定領域或特定任務的。否則只用一種編程語言，就可以完成所有任務。但之所以存在多種編程語言，是因為你不可能在所有領域都表現得很好。它們正在努力針對特定的問題領域進行目標定位，並且專注於解決這些問題。舉個例子，如果你看看我們用來編寫Sui區塊鍊和在Mysten進行的大部分其他系統工作的Rust編程語言，它專注於編寫既快速又高性能的代碼，同時保證安全性。它讓你能夠接觸到內存、線程結構或併發等底層細節，但不會像之前的語言（如C或C++）那樣讓你在其中犯錯。
因此，Move的故事與此非常類似。當我創造它時，並不是為了創造一種新的語言。你之前提到開發者在一種語言中尋找什麼。他們會問，“這個語言對我想要完成的任務是否適用？”但我認為可能更重要的是，“這種語言是否有一個龐大的社區？是否有很多可用的數據庫？是否有很多程序員在使用？是否有良好的教育資源？”這些都非常重要，因此創造一種新語言的門檻必須非常高，即使這種語言本身更好，但是如果它沒有這些因素，那麼它的優勢就沒有意義。從零開始建立一個龐大而充滿活力的社區是非常困難的。
Q2、您能分享更多關於Move的開發情況嗎？
Move起源於Facebook的Libra項目。我當時的任務不是創建一種新的語言，而是“Libra需要有智能合約，所以找出我們應該做什麼。”我看了各種各樣的東西。我們能在EVM中使用Solidity嗎？我們是否應該使用常規的通用語言，比如WASM或JVM，並將其用於Libra？還是應該創建我們自己的東西？
決定創建我們自己的東西是基於對現有智能合約的研究，了解程序員試圖做什麼，以及某些語言在幫助他們的地方和讓他們失望的地方。我的結論是，在很多情況下，現有的智能合約語言確實讓他們失望。
這一點可以從Solidity糟糕的安全記錄中清楚地看出，但更基本的是，這些智能合約不是非常傳統的程序類型。 Solidity並不是為現在人們所做的事情而構建的語言。我不是要批評它，因為它是第一種智能合約語言，它還不知道人們想用它做什麼。一旦你看到人們試圖用它做什麼，我認為很明顯，你需要一組不同的抽象和編程工具，而Solidity語言提供不了。
所以這些智能合約非常簡單，它們基本上做兩件事情。它們定義了資產的類型，包括何時可以轉移資產、你可以用它們做什麼、誰可以讀取它們、誰可以寫入它們的規則。並且檢查訪問控制策略，確定誰擁有該資產，誰被允許使用它，誰被允許對其進行操作。一切都圍繞著資產，你希望這些資產具有與物理資產相同的屬性。如果我把東西交給你，那麼你應該擁有它，我就不再擁有它了。
智能合約中有所有權和所有權轉讓的概念，但在計算機上，一切都只是數位和字節，並且可以自由複制。而且，你知道，這些概念在現實世界並不存在。因此，你希望有一種語言能夠為你提供有關所有權和同質化的良好抽象。就像在現實世界中一樣，但無需強迫程序員重新發明它。你希望獲得基本的安全保證。
這就是Move的作用以及為什麼我們最終創建了這種新的語言。這些任務對於智能合約編程來說是基本的。它們很難在其他語言中重新創建，包括現有的智能合約語言，我們希望圍繞提供這些基本功能的整個語言進行設計，以便程序員可以安全高效地編寫代碼，而不必每次想編寫一些代碼時都重新發明輪子。
Q3、Sui使用了Move的一種變體，稱為Sui Move。是什麼促使了這些變化？ Sui Move的哪些特點非常適合在Web3中構建產品？
以下幾個因素促使了這些變化，其中一個是最初的Libra項目的目標是構建一個合規的支付網絡。因此，我們試圖設計Move（https://docs.sui.io/learn/sui-move-diffs）作為一種通用的語言。但我們還有意識地做了一些事情，因為Libra希望具備限制條件。其中一個重要的事情是，他們不希望人們能夠將某些資產發送到任何地方。他們希望人們明確地創建一個賬戶，並在賬戶創建時設置一些規則，比如賬戶的所有者必須進行KYC認證。或者可能需要支付費用來創建賬戶，或者只能由擁有創建賬戶權限的一小部分人來創建賬戶。由於整個目的是Libra希望進行合規支付和合規智能合約，所以存在這些限制。但在更通用的Web3領域，情況恰恰相反。你不希望在基礎層面上進行合規，這是智能合約的概念。你希望事物盡可能自由，完全可以將某物發送到任何地址。然後你不應該進行顯式的賬戶創建，因為這將阻塞各種用例。這是一個重要的因素。
另一個因素是，儘管我們在Move中專注於資產，但當時在Libra中我們並沒有考慮如何將資產的關注點引入交易本身。因此，當你到達交易層級時，你仍然只有這個API，其中你輸入數字和布爾值等不是資產的東西，然後在Move中，你使用這些數字來從賬戶中提取資產並進行其他操作。事實證明，你運行的大部分代碼都是這種令人討厭的記簿工作，其中包括取出這個東西，取出那個東西，取出其他東西，好的，我擁有了所有我想要的資產。它們在這裡，在我的工作室裡，現在我可以開始做一些有意義的事情了。然後在此過程的末尾，你可能會說：“好的，將這些資產放回這個賬戶，將它們放回那個賬戶，重新組織它們。
在Sui中，我們經過深思熟慮，如果每個程序都以這種方式開始和結束，我們是否可以將其抽像出來？因此，用於處理交易的邏輯將為程序員完成此操作，從程序員的角度來看，他們只需準備好所需的資產，立即開始進行有趣的工作。這就是存在於Sui中的以對象為中心的數據模型。在原始的Move中，我們擁有基於賬戶的數據模型，資產存儲在賬戶下，並且程序員必須明確地提取它們。而在Sui中，它們在進入交易的Move部分時，已經被Sui運行時獲取到資產。這對程序員來說更方便，因為他們不需要進行所有這些之前和之後的記簿工作，而且這也是允許我們在不實際執行的情況下確定是否可以將一個交易與另一個交易並行運行、將Sui進行水平擴展以及更高效地進行其他一些操作的秘密武器。
我們還進行了其他一些非常有趣的工作，比如利用基於對象的數據模型進行可編程的交易塊。這是一個偏技術性的話題，我很樂意深入討論。但這兩個因素是導致與原始Move的分歧的主要動力。
Q4、能請您能分享更多關於可編程交易區塊及其功能的信息嗎？
我喜歡使用一個類比來解釋，其他區塊鏈就像一個購物中心的美食廣場。你想吃一份冰淇淋，你去冰淇淋攤位，拿出你的信用卡付款。但是如果你決定還想吃一個漢堡，然後你去漢堡攤位，再次付款。我不是個貪吃的人，但是如果我想吃八樣東西，我就必須進行八次單獨的交易。而Sui更像是一個自助餐，每個交易不只是一件事。一旦你支付了自助餐的費用，你可以做很多事情而無需額外花費。你可以吃冰淇淋，你可以吃漢堡，你可以將它們混在一起。
為了讓這個概念更具體一點，在簡單的情況下，如果你要發送100個交易來鑄造100個NFT，你可以發送一個鑄造100個NFT的交易。這樣的成本與鑄造一個NFT的成本幾乎相同。你還可以進行異構交易打包，比如區塊中的第一個交易從你的多簽錢包中取出一個馬里奧角色，而第二個交易則請求一個馬里奧，然後允許你玩遊戲。如果你贏得遊戲並獲得獎杯，也許第三個交易會將獎杯放入一個與朋友共享的獎杯櫃中。很酷的是，可編程交易區塊允許程序員以這樣的方式編寫代碼，遊戲不必知道多簽錢包或馬里奧的存儲方式，它也不必知道你的獎杯櫃或其實現方式。
可編程交易區塊由具有輸入和輸出對象的交易組成。如果你需要一個輸入對象，可以獲得該對象，而無需關心它來自哪裡，然後將其輸出傳遞給需要它的對象，同樣也無需關心它將傳遞給哪裡。在其他區塊鏈中，耦合性更強，因此遊戲必須與多簽錢包和獎杯櫃進行集成，或者它們都必須實現一些共同的接口並具有更強的耦合性。 Sui使得所謂的臨時組合變得更加容易。就像，如果管道匹配，我們可以在一個交易中完成。
Q5、那可編程交易區塊對於用戶來說有什麼好處呢？
對於用戶來說，可編程交易區塊的好處包括更低的gas費用，因為你可以將所有操作打包到一個交易中，而不是進行單獨的交易。此外，需要批准的次數也會減少。如果你使用的系統需要交易批准，你只需要進行一次批准，然後它就會一次性完成所有操作。另外一個好處是原子性，如果你想做三件不同的事情，並且希望只有在前兩個操作成功後第三個操作才能成功，如果這些操作必須是獨立的交易，那麼你無法實現這一點。但是，如果你可以將它們都放在一個交易中，那麼你就可以輕鬆實現這一點。
Q6、我聽過您和其他人談論，在Sui上進行開發對於程序員來說是一次很棒的體驗，而且這很重要。對於有經驗的和新的Web3程序員開始使用Sui Move時，您有什麼軼事可以分享嗎？
對於那些來自其他Web3編程語言的開發者來說，他們在Move和Sui Move上的開發體驗確實更加高效，而且更安全。我剛剛參加了一個關於Bucket Protocol的播客節目，他們正在Sui上構建一個非常酷的DeFi項目。他們在展示系統架構時，講述了不同組件如何協同工作。他們說，如果他們用Solidity來編寫這個項目，可能需要八個月的時間，但是用Sui Move只用了兩個月，而且他們對其安全性非常有信心。這門語言的工作方式非常貼近他們頭腦中項目組合的想法。而在Solidity領域，這種聯繫就沒那麼直接。
這只是一個例子，但我們聽到了很多類似的情況，人們說他們在這門語言上的開發速度更快，完成後更有信心。聽到這些讓我感到高興。但在某種程度上，這並不令人意外，我們研究了Solidity並了解了其中的問題。我們明確地設計了圍繞如何使其更安全、更快速的方案。我們審視了使用這門語言的開發者們試圖做什麼，以及如何設計符合他們需求的語言，而不是迎合已有的情況。這門語言就是為人們遇到的問題而設計的，所以當他們進行切換時，他們真的會非常欣賞這門語言。
他們說先發優勢很重要，但我想在這種情況下，是後發優勢更重要。
沒錯，就是這樣。
Q7、在您提到Sui Move和Sui整體的面向對象的特性時，您已經談到了這一點。但您能更明確地闡述Sui Move的設計與Sui能夠實現Web3的大規模採用、低延遲、低成本和可擴展性之間的聯繫嗎？
我們在為Sui做出貢獻時非常警惕的一點，也是其他平台所面臨的問題，就是如果你的容量有限，無論是像以太坊的每秒15個交易（TPS）還是100或1,000個交易，如果是一個固定的數字，那麼當平台過於成功時，它將達到容量的上限。此時，每個使用平台的人的體驗都會下降。如果只有1,000個空位，你必須選擇最重要的1,000個，可以通過gas競價或其他方式進行選擇。對於所有人來說，gas價格都會上漲，延遲會增加，或者兩者兼有。許多使用案例被排除在外，因為只有能夠支付最高費用的使用案例才會成功，而其他人不得不轉向其他地方或等待更長時間。這不是一個好的情況。
Sui的目標是水平可擴展性。如果分配了一定數量的硬件，就可以實現一定數量的吞吐量。如果需要更多的吞吐量，驗證節點可以引入更多的硬件設施，沒有上限。這就是每個Web2服務的工作方式。我的意思是，你必須解決一些工程上的約束，這並不是一件確定或簡單的事情，但是每個人在設計可擴展的Web服務時都希望實現水平可擴展性。
如果Sui有更多的客戶或用戶，我們的目標就是使Sui能夠繼續增長，一切都應該正常運行。當然，同時保持非常低的延遲。你不希望在增加吞吐量的同時犧牲延遲性。
在Libra系統中，沒有考慮到這些特性。它只是一個小規模的支付系統，有幾百個支付運營商，每天可能有數千萬筆支付，但也不會更多。所以我們採用了單一盒子架構，這樣更簡單也足夠用。但在Sui中，我們知道Libra系統行不通，因為它沒有水平可擴展性的特性。所以我們想，如何從零開始設計一個能夠實現這一點的系統。這就是面向對象的數據模型的來源。我們基本上拋棄了舊的基於賬戶的數據模型，因為它使實現水平可擴展性變得非常困難。相反，如果你將所有內容都組織成對象，全局狀態就只是一個從對象ID到對象的大型映射。這是一個鍵值對存儲，我們知道如何擴展鍵值對存儲，這是一個簡單的工程問題。
然後問題就是，我們如何設計一個事務結構，使其適應從鍵值存儲中獲取數據和更新數據的過程？我們如何分片鍵值對存儲？我們如何決定事務應該在哪裡被處理？這基本上就是它的來源。也就是說，我們知道如何擴展這些東西。我們如何將它變成具有區塊鏈屬性、可驗證讀取、可與Move合作等功能的東西。然後如何盡可能平穩地將它們結合在一起。
Q8、從更高的層面上講，您如何與Web2中質疑的開發者討論去中心化技術的潛力？
我認為區塊鍊和加密貨幣在根本上是一種去除摩擦的技術。存在一些障礙，使得我們在進行金融交易、構建應用程序或設置信息時變得非常困難，因為信息無法跨越這些障礙，或者如果跨越這些障礙，就需要某些第三方的幫助，而這些第三方為能夠提供幫助而收取一定的費用。
人們喜歡用的一個經典例子是購買房屋。有一個購房者和一個賣房者，但當你實際進行支付時，必須有一個託管代理人，他除了坐在那里托管資金以外什麼都不做，因為買方和賣方彼此並不完全信任。這是生活的現實。我們要處理這個問題。但是，如果託管代理人可以是雙方都可以查看的代碼，或者經過某個第三方的驗證，那麼它就可以免費或者以更少的費用來完成這個工作。區塊鏈的目的不是消除房地產中的託管代理人。這只是其中的一個用例，但通常都是這樣。
如果不再有應用A和應用B之間的互操作性障礙，而是建立在相同的基礎平台上，這樣你就可以使事物從一個應用流向另一個應用，無論是應用內物品、數據、跨促銷活動，還是構建在兩者之上的第三方產品。或者想像一下互聯網，網站通過cookie與彼此共享數據，但這些cookie只是只讀元數據。如果這些cookie可以成為貨幣呢？或者可以成為可花費的物品呢？或者可以成為忠誠計劃和優惠券呢？一切都內置了這個功能。這是非常抽象的，但這是潛力所在。通常，一個正在構建的人會認為這些是他可以用來構建更有吸引力的東西的新超能力。
Q9、對於終端用戶來說，即使他們不具備技術知識，當他們考慮代碼信任時，你是否感覺到他們有所猶豫，即使另一種選擇是一個不透明的大型中心實體？
我不這麼認為。因為我們每天都在做這樣的事情，對吧？當我登錄我的電子郵件時，我並不擔心代碼會刪除我的某封郵件，或者當我發送郵件時，它實際上不會發送。如果發生這種情況，那麼我可能會停止使用電子郵件，或者使用其他提供者。我認為這是非常相似的，當然，並不是每個人都能夠真正閱讀某些內容並檢查其工作方式。
而且，你知道，如果我想檢查電子郵件的代碼，我不能，因為代碼不在那裡。所以透明度是其中一個重要方面。雖然不是每個人都能夠做到這一點，但有些人可以進行抽樣檢查。而且，與任何事物的重複使用相結合，再加上不可變性。這就是這裡的關鍵。當我登錄電子郵件時，我不知道自從上次我做某事以來代碼是否發生了變化。對此沒有透明度。即使了解到這個信息，在Web3中你可以得到，而在其他地方你得不到。
Q10、您對Sui Move在未來的發展有什麼期望？
我們目前關注的許多功能都是基於我們與發布其初始批次的Sui Move包的開發者的經驗，然後觀察他們希望如何發展這些功能，哪些功能易於發展，哪些功能較難。 Sui Move是一個非常適合第一次發布包的語言，但是對於我要改變這種類型，我要添加一些字段，我要添加一些函數，我要以一種有凝聚力但不違背使用初始包的用戶的信任的方式進行操作，這變成了一個非常具有挑戰性的問題。我們所做的很多工作是研究這一點，並確定我們可以添加哪些語言級別的功能，既能給程序員提供擴展的靈活性，同時又能保持原始代碼用戶的信任。
我們正在研究許多與此相關的功能，尤其是枚舉類型。我們還在改善將Move與前端代碼連接的體驗方面做了很多工作。我們常常開玩笑說，一個典型的Sui應用程序是5%的Move代碼和95%的前端代碼。因此，我們非常關注這95%。我們花費了很多時間討論Move，但我們也非常關注如何使其他部分更加高效，並使連接更加容易。總的來說，我們非常關注如何使應用程序更多地由Move組成，以獲得更多的安全性。同時，我們如何使這95%的代碼對Move程序員和非Move程序員都易於理解。