WebAssembly的前世今生

買賣虛擬貨幣


首先WebAssembly不是區塊鏈範疇的技術,屬於瀏覽器前端技術,估計是那個寫白皮書的把以太坊EVM裡面EVM2.0提到的效能提升WebAssembly實現展望學了進去。



誠然,目前區塊鏈很多技術發展非常快,基本上用到了目前業界正在測試和評估的很多前沿技術,WebAssembly就是其中之一,WebAssembly其實是多家主流瀏覽器廠商競爭後的妥協,從字面理解可以看做是“Web的組合語言”,要了解組合語言需要你有計算機專業的學習背景,簡單來說組合語言可以理解為機器可以直接執行的程式碼,或者叫做位元組碼,或者“機器語言”等等,其優點是執行效率非常快,基本上屬於指令集範疇,當然其缺點是可讀性和程式碼編寫非常困難,所以人們發明“高階程式語言”讓程式碼編寫和閱讀更符合人類的邏輯習慣,C/C++/JAVA等你能熟知的都是屬於高階語言範疇,當然機器是無法識別高階程式語言的,所以人們發明了“編譯器”,透過編譯器把高階程式語言轉化為組合語言,讓機器可以執行,現在你知道所謂程式語言的來龍去脈了吧。


在計算機語言的發展過程中,有兩大發展方向,一個是解釋型語言,一個是編譯型語言。最早的Basic語言是解釋型語言的代表,因為解釋型語言可以逐條執行,不要編譯過程,所以設計簡單,非常適合簡單的程式邏輯環境,所以後期一般把解釋語言成為“指令碼語言”,現在流行的javascript語言從字面就可以知道這是一種指令碼語言,但是,由於當時的CPU運算能力限制,解釋型語言的效率不是那麼好,應用面比較小,其優點是可以很容易修改和執行。


而編譯型語言可以透過編譯器直接將大量高階語言程式碼一次性編譯成機器碼,所以最終的執行效率非常高,在Web應用沒有大發展時,基本上主流語言是編譯型語言的天下。


但是就像衣服和鞋帽的流行時尚一樣,過了那麼幾年,總要轉回去一樣,隨著網際網路的發展,大量的Web應用湧現,CPU效率的提升,解釋語言的效率弱點被硬體的發展掩蓋,於是乎PHP/ruby/javascript等解釋語言重新崛起,其易於編寫和實時修改不需要編譯就可以執行的特點被放大,所以大量應用開始使用解釋語言進行編寫,包括一些非常複雜的邏輯應用。


其中以javascript為最(以下簡稱js),其實從語言本身上來說js是非常垃圾的語言,沒有強型別,約束也不嚴謹,效率也不好,最初就是為瀏覽器設計的簡單指令碼語言,但就是這個原因,由於web應用的發展,js一躍成為事實的標準,各種js框架的發展在一定程度上彌補了js語言本身的不足,比較著名的有node.js,使用這個框架居然可以編寫本地和服務端應用,這本來都是傳統編譯型語言的陣地,可見為了照顧大量js程式設計師,框架的力量有多厲害,可謂得程式設計師者得天下。



山不轉水轉,js因為是瀏覽器預設的語言(最早微軟的IE可以執行Basic語言),所以js得到了很大的發展,但是因為其出身問題,效率低下其實是所有瀏覽器廠商知道的,比如進行MD5等加密運算,大量的圖形處理等,只能勉強應付。最早發現並嘗試解決這個問題的是adobe公司,他們開發了flash外掛(微軟搞過Silverlight),擴充套件了瀏覽器功能,所以你能見到很多用flash開發的網頁遊戲應用,由於adobe不是瀏覽器廠商,同時flash被設計成為外掛機制,安全性存在很多問題,更為主要的是flash是商業產品,當時喬布斯大神都很抵制,主流瀏覽器廠商迫切需要一個開放的標準,於是乎HTML5誕生了,HTML5解決了很多瀏覽器的功能和效能標準問題,但是HTML5仍然沿用了js作為主要語言,這樣問題就出來了。


效能問題仍然沒有得到很好的解決,比如你無法在HTML5應用中看到主流的3D遊戲等等,所以各大瀏覽器廠商開始亂搞,紛紛開始嘗試在瀏覽器中實現編譯型語言的機制,以此提升效率,期間Mozilla在推asm.js,谷歌支援PNaCI,蘋果在開發FLTJIT,而微軟好像在發呆沒有推出任何東西。而後來,所有四個主要的瀏覽器供應商一致同意建立一種面向Web的二進位制格式WebAssembly或WASM。可以簡單將其稱為位元組碼,由於執行於瀏覽器容器中,它並不是傳統意義上的機器位元組碼,實際上是一個經過壓縮的AST編碼(AST是語法抽象樹的意思)。


就這樣WebAssembly誕生了,它就是為解決效能瓶頸而設計的東西,如果用在區塊鏈上可以提升基於Web的Dapp效能,但是如果不用在Web應用上,我不知道為什麼要用它,不如直接使用C語言原生代碼來的快,特別是在專業環境中的EVM虛擬機器中,所以以太坊在EVM2.0中要使用WebAssembly這點上是值得商榷的,更別提那些只知道堆砌名詞的ICO白皮書中去學以太坊中利用的技術,更值得深入探討了。



WebAssembly (簡稱 wasm ) 是一種適合於編譯到 Web 的, 新的可移植的, 大小和載入時間高效的格式. 這是一個新的平臺無關的二進位制程式碼格式,  目標是解決 JavaScript 效能的問題. 這個新的二進位制格式遠小於 JavaScript, 可由瀏覽器 的 JavaScript 引擎直接載入和執行, 這樣可節省從 JavaScript 到位元組碼, 從位元組碼到執行前的機器碼所花費的及時編譯 JIT (Just-In-Time) 時間. 作為一種低階語言, 它定義了一個抽象語法樹 (Abstract Syntax Tree, AST) , 開發人員可以以文字格式進行除錯.


WebAssembly 描述了一個記憶體安全的沙箱執行環境, 可以在現有的 JavaScript 虛擬機器中實現. 當嵌入到 Web 中時, WebAssembly 將強制執行瀏覽器的同源和許可權安全策略. 因此, 和經常出現安全漏洞的 Flash 外掛相比, WebAssembly 是一個更加安全的解決方案.


WebAssembly 可由 C/C++ 等語言編譯而來. 此外, WebAssembly 由 Google, Mozilla, Microsoft 以及 Apple 牽頭的 W3C 社羣組共同努力, 基本覆蓋主流的瀏覽器廠商, 因此其可移植性相較 Silverlight 等有極大提升, 平臺相容問題將不復出現.


在 Web 平臺的很多專案中, 對於原生新功能的支援需要 Web 瀏覽器或者 Runtime 提供複雜的標準化的 API 來實現, 但是 JavaScript API 往往較慢. 使用 WebAssembly, 這些標準 API 可以更簡單, 並且操作在更低的水平. 例如, 對於一個面部識別的 Web 專案, 對於訪問資料流我們可以由簡單的 JavaScript API 實現, 而把面部識別原生 SDK 做的事情交由 WebAssembly 實現.


需要了解的是, WebAssembly 不是將 C/C++ 等其他語言編譯到 JavaScript, 更不是一種新的程式語言


下圖比較好的描述了WebAssembly的結構

由於WebAssembly是目前正在發展的技術,不是專業人員可以不用仔細瞭解其中的主要原理,本文旨在科普一下,今後您在遇到白皮書中提到這個名詞有個感性的認識,如果對這方面感興趣,推薦閱讀更為專業的資料,或者直接看W3C相關標準定義。

免責聲明:

  1. 本文版權歸原作者所有,僅代表作者本人觀點,不代表鏈報觀點或立場。
  2. 如發現文章、圖片等侵權行爲,侵權責任將由作者本人承擔。
  3. 鏈報僅提供相關項目信息,不構成任何投資建議

推荐阅读

;