Lisk 與乙太坊有何不同？
Lisk 將成為一個用於建構和分發去中心化應用程序的全棧 DApp 開發框架。它目前處於眾籌階段，但也被添加到微軟的區塊鏈即服務堆棧中。
它宣傳您可以通過簡單地編寫 Javascript 來建構去中心化的應用程序。但既然你也可以為乙太坊建構 JS-DApps，我想知道，有什麼區別？
警告，我不是 Lisk 的忠實粉絲。這顯然是故事的一方面，我確信 Lisk 的勝算比我認為的要多。但我不認識他們。
一篇博文（不是我寫的）：為什麼 Lisk 不如乙太坊
作者關於 Lisk 的主要觀點：
- Lisk“沙盒”不能用於執行不受信任的程式碼
- Lisk 框架不提供針對非確定性行為的保護
- Lisk 沒有能力防止無限循環和/或測量總計算量
- Lisk 沒有能力防止無限的記憶體增長和/或測量記憶體消耗
- 常見的 JavaScript 語言特性（例如迭代對像中的鍵）結果是隱藏的非確定性行為
作者關於 ETH 的主要觀點：
- 乙太坊保護開發人員免受困擾有經驗的區塊鏈開發人員的無數問題。
- 學習一門新的語言語法與學習如何避免數以百萬計的方法相比是微不足道的。
- 乙太坊應用程序不可能產生不確定的行為。
- 無需在乙太坊中管理“撤消”狀態，因為拋出的任何異常都會自動回滾所有更改（費用除外）。
.
1. 程式語言
Lisk：Javascript 與 Ethereum：go、C++、rust、Solidity、Serpent 等。
應用鏈
Lisk 在預售之前大力推廣的一件事是，他們的 Dapp 使用 Javascript，“世界上最流行的語言”。事實上，他們進行行銷（通過reddit 廣告）
$$ 1 $$他們自己被稱為“Javascript 開發人員的乙太坊替代方案”。 他們的整個系統是 100% javascript。後端的 Node.js。前端。他們確實有一個數據庫——最初是 SQLlite。現在是postgresql。
乙太坊
乙太坊的智能合約在 Solidity或Serpent中。Solidity與 Javascript非常相似，但它是為智能合約定制的。閱讀這些契約並理解它們在做什麼是非常容易的。當涉及移動貨幣、儲存價值和需要達成共識的合約時，還有一些重要的理由使用自定義語言而不是 Javascript（下面討論）。如果您想了解更多資訊，此頁面雖然不再維護，但對於 Solidity 是什麼有一些很好的說明。
我對 Serpent 了解不多，但它似乎與 Solidity 具有相同的目標和目的，但它與 Python 相似（因此對 Python 開發人員來說非常有用。）還展示了乙太坊必須吸引廣泛的開發人員，而不僅僅是 Javascript 開發人員。
以上僅涵蓋 Etheruem 的智能合約；那麼更全面的“Dapp”呢？嗯，乙太坊 Dapp 的 UI 幾乎是 Javascript。我建議你在這裡閱讀 ConsenSys 的文章，特別是第二部分。基本上，你有：
- 松露（JS、Sass、ES6、JSX 是內置的）
- Embark（即 JS）
- Meteor (web3.js + meteor (也是 JS))
- 還有更多。
結論
因此，對於 Lisk 來說，暗示 Javascript 開發人員不能為乙太坊創建 Dapp 有點誤導。他們絕對可以主要將 Javascript 用於 Dapp，然後將 Solidity（非常接近 Javascript）用於智能合約。上面引用的部落格文章簡潔地說：
學習一門新的語言語法與學習如何避免數以百萬計的方法相比是微不足道的。
不同的是，Lisk 完全是 Javascript（和 node.js），乙太坊有大量不同語言的客戶端
$$ 2 $$，有兩種用於智能合約的自定義編寫語言，並且仍然允許在您最需要它的地方使用 Javascript（UI）。
2.Javascript的缺點
有些人沒有意識到 Javascript 雖然非常流行，但並不會自動使其成為最佳解決方案。正如我上面所說，乙太坊和 Lisk 之間的區別在於，Lisk 是 100% Javascript，而乙太坊有大量的語言，並允許 Dapp 開發人員將 Javascript 用於 UI，將 Solidity 用於區塊鏈上的智能合約。因此，以下是區塊鏈上 Javascript 的一些潛在缺陷：
- Javascript 數字是….不是最大或最可靠的。此外，當我們處理加密貨幣時，您真的希望您的數字準確無誤。基本上 JS 使用浮點數，這意味著在某些情況下，有些東西會被逼近，而數字會失去。即使是像浮點數這樣的小事情也會破壞共識。這裡有一些進一步的閱讀：小心大數字和浮點近似。因此，Lisk 中的所有內容（包括 Lisk 本身）都在 Javascript 中，這意味著存在潛在的大數字問題（無論是大數字還是大問題。）
- Lisk 有“規則”，他們要求合約開發者必須遵守以避免破壞共識。這包括諸如“不要使用 Math.random()”之類的東西。使用乙太坊，你不必有規則。如果您嘗試做錯事，程式碼將無法編譯。（僅供參考，您不編譯 Javascript。）在 Lisk 上，如果您確實使用 Math.random()，它會中斷。
- Javascript 使用弱動態類型。如果你不小心，你可以傳遞字元串而不是數字。Solidity 和 Serpent 以及 Javascript 之間的主要區別之一是 Solidity 和 Serpent 都是強類型的。 強與弱的維基百科是這樣解釋的：
如果傳遞給函式的參數與預期類型不匹配，強類型語言更有可能產生錯誤或拒絕編譯。另一方面，非常弱類型的語言可能會產生不可預知的結果或可能執行隱式類型轉換。
由於乙太坊在區塊鏈上執行合約，而 Lisk 是在區塊鏈上執行 Dapp（側鏈？），你可以看到為什麼使用弱類型語言會導致問題，特別是在共識方面。最好在問題變成鏈上不可變的東西之前就知道問題，而不是發現所有資金都被困住了，或者你在有人第一次嘗試與它互動時分叉了區塊鏈。
Lisk 的其他缺陷包括它們的“沙箱”不能用於執行不受信任的程式碼，並且它們的框架沒有提供針對非確定性行為的保護。從上面的部落格文章：
Lisk face 可以通過高度定制的 JavaScript 環境來解決，該環境消除了浮點，實現了軟體中斷、指令計數和用於管理應用程序狀態的更清潔的 API。最終，為乙太坊 VM 創建一個 JavaScript 編譯器可能比嘗試修補 JavaScript 中的一百萬個非確定性洩漏更不容易出錯。
2b。Solidity 的缺點
正如使用者 Jehan 所指出的，Solidity 也不完美。
- 幾乎不支持任何類型的序列化和反序列化
- 它有一個極度貧乏的標準庫（最近已顯著更新）
- 無法將字元串數組傳遞給合約。
3. 在區塊鏈上
在 Lisk 中，Dapps 實際上並不儲存在區塊鏈上，就像智能合約字節碼在乙太坊中一樣。相反，你有這些 Dapp 的外部連結。他們喜歡將他們的 Dapp 與傳統的“App Store”模式（想想蘋果）進行比較。雖然這對某些使用者很有吸引力，但當您意識到他們實際上是在使用 HTTP: 連結到 .zip 文件時就不那麼吸引人了。
使用乙太坊，您將程式碼儲存在區塊鏈上，這意味著它們可以被審計並且無法更改程式碼。這是擁有去中心化應用程序 (IMO) 的全部目的。
Lisk 更喜歡使用“去中心化”的更寬鬆的定義，即字面上不儲存在中心位置，而乙太坊開發人員和使用者更喜歡去中心化意味著不能被破壞、可以審計、不能改變、可以達成共識等的東西。
$$ 3 $$
4. 誰是/曾經是 Lisk
乙太坊愛好者反對 Lisk 的最常見論點之一是 Lisk (1) 背後沒有開發團隊， (2) 起源於失敗的山寨幣，Crypti 被開發者拋棄 (3) 那些放棄 Crypti 的開發者是 Lisk 開發者，所以 (4) 這只是品牌重塑嗎？
我在這裡看到的乙太坊和 Lisk 之間的主要區別在於，Lisk 是兩個人，他們將以前的代幣重新命名，該代幣進行了預售並且沒有傳遞任何東西，而乙太坊擁有 Vitalik Buterin，這是一個由知名、社區參與、瘋狂的天才組成的大型團隊開發人員，以及致力於核心程式碼（一切都是開源的）、Dapps 和第三方錢包等的大型開發人員社區。
另一個關鍵區別是乙太坊擁有乙太坊基金會，這是一個非營利性瑞士組織，而 Lisk 擁有….一個與之相關的未知基金會/公司。
$$ 1 $$ 這也是一個螢幕截圖，因為該連結很時髦。 $$ 2 $$乙太坊的語言/客戶數量令人驚嘆。在這一點上，我們有：Geth (Go)、WebThree (C++)、PyEthereum (Python)、Parity (Rust)、EthereumJ (Java)、Ethereum-Ruby (Ruby)、NEthereum (.net)。我認為這是乙太坊的一個主要優勢，正如乙太坊團隊所指出的那樣，有這麼多語言的客戶端在測試、錯誤發現和確保共識方面非常寶貴。 $$ 3 $$ 來自憤怒執行緒的更多資訊。