轉發原文標題《Limitations of scaling blockchains and which VM’s are theoretically the fastest》

TL;DR

最近我和一位我非常尊敬的創始人聊天，他提到我應該寫下我們之間的對話。

對話從一個簡單的問題開始：“Sonic 是否以某種方式並行化交易執行？”答案是：沒有。乍一看，這似乎是一個奇怪的選擇，因為過去兩年裡，如果你有關注過虛擬機技術，你會看到“並行化”幾乎無處不在。那麼我們為什麼不做呢？

要回答這個問題，我們首先需要看看 Sonic 工程團隊是如何評估我們應該專注於什麼的。我們有很多理論，紙面上看起來都很實際，都是我們想要實施的，但團隊的資源有限，那我們該如何選擇最有影響力的方向呢？於是，團隊決定不去做那些想法中的任何一個，而是花了一年時間去構建 Aida。Aida 是一個非常強大的工具，它讓我們能夠在幾分鐘內重放整個區塊鏈（任何區塊鏈），而不是幾個月，而且還帶有有用的性能指標。這意味著我們可以在 Aida 中快速原型開發、測試，並迅速知道哪些理論是有效的，哪些是行不通的。

Aida 還為我們提供了強大的性能分析功能，能夠生成以下輸出：

有了以上這些，我們可以非常快速且準確地測試我們的吞吐量假設，因此我們開始比較純內存虛擬機與磁盤、並行執行、RDMS 與 KV 與平面文件、超集、新的共識模型等等。

最大的提升來自於數據庫，提升了 800%，接下來是超集，然後是共識，而並行執行則排在非常靠後的位置，儘管有 30% 的適度提升。這似乎有些違反直覺，因為像並行執行這樣的概念，直覺上看起來應該比結果好。那麼我們是如何實現並行化的呢？也許我們犯了個錯誤，測試名為“Clairvoyance”，它是完美的排序形式，是一種能夠提前知道最優排序和並行化方式的引擎（在實踐中這已經是不可能的，所以即使是 30% 的提升，也高於預期）。

虛擬機和區塊鏈是非常複雜的組件，而且我們常常測量錯誤的指標（或者根本沒有測量）。

然後他問我：“那麼，Solana 的速度來自哪裡？或者，它並不比 Sonic 快？”我的回答是：“Sonic 比 Solana 快，但 Sonic 並不比 Solana 的最快速度快。”

我們正在看到向單一強大服務器的轉變；Solana、Megaeth 和各種單一排序器都傾向於一個目標：單一高吞吐量、高內存服務器（其中，非 L2 將始終在實際操作中最快）。如果正確優化，這種解決方案將始終比多個參與者更快。因此，像 Solana 或 Megaeth 這樣的系統的最大優化吞吐量將比採用 2+ 服務器共識的下一個最快競爭對手更高。

那麼，下一個問題可能是，為什麼 Sonic 不使用單一領導者選舉的服務器呢？答案是，這並不是我們優化的方向。我在 2018 年寫過的一篇文章中提到過，我們的北極星之一是，隨著互通程序的出現，某個時刻就需要共識。假設一個繁忙的交叉口沒有停車標誌或紅綠燈，且有數百輛車通過。最優化的方法是讓這些車在交叉口“登記”，然後達成排序協議，並選擇最優化的方法來讓每輛車行動，以最大化吞吐量。在這種情況下，你不能使用基於領導者的系統，也不能假設某一方不會惡意行為，在這種情況下，Sonic 共識已經優化到可以在 Raspberry Pi 上驗證，而不會損失任何吞吐量，因此所有的車都可以基於 Sonic 共識達成排序。Sonic 針對的是網狀網絡的優化。

不管怎樣，這只是一些隨意的胡言亂語，希望某種程度上能有所幫助。

免責聲明：

1. 本文轉載自 [Andre Cronje]。所有版權歸原作者所有 [Andre Cronje]。若對本次轉載有異議，請聯繫 Gate Learn 團隊，他們會及時處理。
2. 免責聲明：本文所表達的觀點和意見僅代表作者個人觀點，不構成任何投資建議。
3. Gate Learn 團隊將文章翻譯成其他語言。除非另有說明，否則禁止複製、分發或抄襲翻譯文章。