原標題：我如何學會停止擔心並愛上執行分片
視頻鏈接: https://www.youtube.com/watch?v=A0OXif6r-Qk
演講人: Scott Sunarto (@smsunarto) 在研究日
文章編輯整理： Justin Zhao (@hiCaptainZ)
大家好，我是 Scott (@smsunarto)，Augus Labs（@ArgusLabs_）的創始人。今天，我要討論一個我們已經有一段時間沒有觸及的話題。隨著 roll-ups 成為時代的主流，我們對執行分片的討論並不像對數據分片那樣頻繁。所以，讓我們重新審視這個有些被忽視的話題 —— 執行分片。
這將是一次輕鬆的談話。我知道大家已經聽了一整天的複雜概念，所以我會盡量讓這次討論盡可能實用。我為這次演講準備了合適的幻燈片設計。
對於不了解我的人，有趣的是，我在 Twitter 上被稱為動漫女孩。我也為了來這裡而錯過了大學畢業典禮，這讓我的父母非常不滿。目前，我是 Argus Labs 的創始人。我們認為自己是一家遊戲公司，而不是基礎設施或加密貨幣公司。我最大的煩惱之一是，所有在加密遊戲領域的人都想要構建工具，但沒有人想要創造內容或應用。我們需要更多用戶可以實際使用的應用。
之前，我和我的聰明朋友 Brian Gu (@gubsheep) 和 Alan Luo (@alanluo_0) 共同創造了 Dark Forest (@darkforest_eth)。Brian 現在正在運營 0xPARC (@0xPARC)，他比我聰明很多。
今天的討論將集中在執行分片，但在一個大多數人對執行分片的討論不熟悉的背景下。我們通常在 Layer1，如以太坊分片或 Near 分片的背景下討論執行分片。但今天，我想改變一下背景。讓我們思考一下在 roll-up 環境中分片會是什麼樣子。
這裡的基本問題是，為什麼一個遊戲公司要構建自己的 roll-up，以及我們可以從《魔獸世界》中學到什麼來設計 roll-ups。此外，我們將探討 roll-ups 的設計空間如何遠遠超越當前的現實。
為了回答這些問題，讓我們回到 2020 年，當時 Dark Forest 的想法首次被構想出來。我們問自己，如果我們創建一個每一個遊戲動作都是鏈上交易的遊戲，會怎樣？那時候這個前提是荒謬的，對今天的許多人來說仍然是如此。但這是一個有趣的假設，所以我們構建了它，Dark Forest 就這樣誕生了。
Dark Forest 是一個完全基於以太坊的全鏈空間探索 MMORTS 遊戲，由 ZK-Snarks 驅動。回到 2020 年，ZK 並不像今天這樣流行，因為幾乎沒有任何文檔。Circom 的唯一可用文檔是 Jordi Baylina's (@jbaylina) 的 Google Docs。儘管面臨挑戰，但我們從過程中學到了很多，Dark Forest 就是這些學習的體現。
Dark Forest 是一個比我們想像中更大的實驗。我們有超過 10,000 名玩家，花費了數萬億的 gas，遊戲中充滿了混亂，人們在鏈上背後捅刀。關於 Dark Forest 和鏈上遊戲最吸引人的事情是平台化的本質。通過擁有一個全鏈遊戲，你打開了為新興行為設計空間的大門，允許人們構建與遊戲交互的智能合約，以及替代客戶端和遊戲模式，例如 Dark Forest Arena 和 GPU 礦工。
然而，伴隨著巨大的力量，也有巨大的責任。當我們在現在被稱為 Gnosis Chain 的 xDai 上啟動 Dark Forest 時，我們最終填滿了鏈的整個區塊空間。這使得鏈對於其他任何事情，包括 DeFi、NFTs 或任何其他 xDAI 的事情，基本上都無法使用。
那麼，現在怎麼辦？我們是不是到了死胡同？全鏈遊戲永遠不會成為現實嗎？或者我們是否要回到製作只有 JPEG 小圖片在鏈上的遊戲，並說服人們錢是從樹上長出來的？答案是，我們讓軟件做事情。我們中的許多人對區塊鏈和 roll-ups 的看法非常僵化，好像沒有太多的改進空間。但我不同意。我們可以進行實驗，找出新的可能性。
我們問自己一個問題：如果我們要從頭開始為遊戲且只為遊戲設計一個區塊鏈，它會是什麼樣子？我們需要高吞吐量，所以需要擴展讀寫。大多數區塊鏈都設計成進行大量的寫入。每秒交易數 TPS 是人們吹噓的指標，但實際上，讀取同樣重要。如果你不能從區塊鏈節點讀取，你怎麼知道玩家的位置呢？這實際上是我們在區塊鏈構建中發現的第一個瓶頸。
Dark Forest 遇到了個問題，即全節點被大量使用，I/O 爆炸，因為我們需要從鏈上狀態讀取數據。這導致了數千美元的伺服器成本，這些成本由 xDAI 團隊慷慨地為我們承擔。然而，這對長期來說並不理想。我們需要高吞吐量，不僅對於每秒寫入的交易，也對於讀取，比如從區塊鏈本身獲取數據。
我們還需要一個水平可擴展的區塊鏈，以避免 Noisy Neighbor 問題。我們不希望一個受歡迎的遊戲突然開始在區塊鏈上出問題，停止所有的工作。我們還需要靈活性和可定制性，以便我們可以修改狀態機，使其為遊戲設計。這包括有一個遊戲循環，使其自我執行等等。
最後但並非最不重要的是，對於那些不熟悉在線遊戲架構的人來說，這可能有些模糊，我們需要高 tick rate。Ticks 是遊戲世界中的時間原子單位。在區塊鏈的背景下，我們有區塊作為時間的原子單位。在遊戲中，我們有 ticks。這在你構建一個全鏈遊戲時幾乎是類似的，其中你的區塊鏈的 tick 或區塊產生的速度等於遊戲本身的 tick。
所以，我們需要的是一個高吞吐量、水平可擴展、靈活可定制，並且具有高 tick rate 的區塊鏈。這樣的設計，才能滿足我們為遊戲從頭開始設計的區塊鏈的需求。
如果你有更高的 tick rate 或每秒更多的區塊，遊戲會感覺更加反應靈敏。相反，如果你的 tick rate 較低，遊戲會感覺更加遲鈍。需要記住的一件關鍵事情是，如果區塊產生延遲，你會在遊戲中感覺到明顯的延遲。這是一種糟糕的體驗。如果你曾經處理過因為輸掉遊戲而對著電腦大喊大叫的憤怒玩家，那是一種絕對糟糕的情況。
目前，我們的 rollups 每秒有一個區塊，相當於一次 tick。如果我們想要有更酷的遊戲，我們需要更高的 tick rate。例如，Minecraft，一個簡單的像素藝術遊戲，每秒有 26 次 tick。我們還有很長的路要走，才能建立出像 Minecraft 那樣反應靈敏的遊戲。
一個可能的解決方案是部署我們自己的 rollup。雖然表面上看起來解決了問題，但實際上並沒有解決問題的根本原因。例如，你會有更高的寫入吞吐量，但並不完全達到遊戲需要的水平。當然，如果你的遊戲有一百個玩家，這將是足夠的。但是，如果你想要構建需要更高吞吐量的遊戲，由於當前構建中的 I/O 方式，會有非常嚴格的限制。
在讀取方面，你並沒有真正得到性能的提升。你仍然需要依賴索引器。你並沒有真正的水平可擴展性。如果你試圖啟動一個新的 rollup 來水平擴展你的遊戲，你就會破壞你現有的智能合約生態系統。玩家部署的市場將無法與你為了水平擴展遊戲而啟動的其他鏈進行工作。這會引發很多問題。
最後，高 tick rate 和每秒區塊數還是有點難度的，雖然我們可以盡力推動它，我們可能會得到每秒兩個區塊，也許三個，但這真的是這些區塊鏈能走的最遠的地方，因為有一堆像 re-marshalling 這樣的事情非常依賴計算周期。
為了解決這個問題，我們回顧了 21 世紀初和 20 世紀 90 年代末，像 MMOs 這樣的在線遊戲剛剛興起的時候。他們有一個叫做分片的概念。這不是一個新的概念；它在過去已經存在。我們在數據庫架構中使用的 "分片" 這個詞實際上來自於 Ultima Online 的引用。他們最早使用 "分片" 這個詞來解釋他們的不同伺服器。
那麼，遊戲中的分片是如何工作的呢？它不是一種一刀切的解決方案。它是工具箱中的一個工具，你如何將它適應到你的遊戲中，取決於具體情況的不同。例如，第一個分片構造是我喜歡稱之為基於位置的分片。一個很好的思維模型是想像一個笛卡爾坐標系被分割成四個象限，每個象限都有自己的遊戲分片。每次你想要穿越一個分片，你都要向另一個分片發送一個通信，說 "嘿，我想要移動到那裡"，然後你被傳送到你的分片，留下你之前的玩家身體。通過這樣做，你將伺服器的工作負載分配到多個物理實例，而不是強迫一個伺服器為整個遊戲世界做所有的計算。第二種構造現在更受歡迎。它被稱為多宇宙分片，你有多個遊戲實例與彼此鏡像。你可以選擇你想要去的任何分片，它默認是負載均衡的，這樣每個伺服器都不會過於擁擠。
現在，關鍵的問題是，如何將這個概念帶入 rollup？這就是為什麼我們創建了 World Engine。World Engine 是我們的旗艦基礎設施，基本上是一個為啟動設計的有主見的分片排序器。與我們在過去幾次討論中看到的許多分片排序器設計相比，我們的設計不同，更適合我們的需求。我們優化的方向是：A，吞吐量，B，我們要確保沒有鎖阻止運行時間，以確保 tick rate 和區塊時間盡可能高效，所以它默認是同步的，我們設計排序器的方式是部分排序，而不是強制總排序（每個交易需要在另一個交易之後發生）。
這裡的關鍵組成部分是，我們有兩個主要的東西。我們有基於 EVM 的分片，它就像一個純粹的 EVM 鏈，玩家可以在上面部署智能合約，與遊戲組合，創建帶有稅收的市場等等。它就像一個正常的鏈，對吧？像每秒一個區塊或一件事，只是足夠你做所有你的典型設備和市場的東西。
這裡的秘密成分是，我們還使用一個遊戲分片，它本質上是一個設計成高性能遊戲伺服器的迷你區塊鏈。我們有一個 bring-your-own-implementation 接口，這樣你可以根據你的喜好定制這個分片。你可以構建你自己的分片，注入到基礎分片中。你只需要實現一套標準的接口，就像你熟悉的 Cosmos，Cosmos 有一個 ABC 接口。你基本上可以將這個整合成一個類似的規範，將你自己的分片帶到 World Engine 堆棧中。
這裡的關鍵是，我們有一個高 tick rate，我們目前無法用當前的分片構造實現。這就是我想要介紹 Cardinal 的地方。Cardinal 是 World Engine 的第一個遊戲分片實現。它使用實體 - 組件 - 系統（ECS），具有面向數據的架構。這允許我們並行化遊戲，並提高遊戲計算的吞吐量。它有一個可配置的 tick rate，最高可達每秒 20 次 tick。對於這裡的區塊鏈人來說，那就是每秒 20 個區塊。
我們還可以將其地理定位，以減少延遲。比如，你可能有在美國的排序器，然後亞洲人必須等待 300 毫秒的延遲，才能讓 transaction 到達排序器。這在遊戲中是一個巨大的問題，因為 300 毫秒是很長的時間。如果你試圖玩一個有 200 毫秒延遲的 FPS 遊戲，那基本上就是，你已經死了。
另一個對我們來說也很重要的關鍵點是，它是自我索引的。我們不再需要外部索引器。我們不需要這些框架來緩存遊戲狀態。這也使我們能夠構建更多的實時遊戲，不會因為索引器仍然在試圖趕上排序器區塊而有延遲問題。
我們還有一個插件系統，允許人們並行化 ZK 驗證等。最好的部分，至少對我來說，是你可以用 Go 編寫你的代碼。不再需要用 Solidity 來讓你的遊戲工作。如果你曾經試圖用 Solidity 構建一個區塊鏈遊戲，那簡直是一場噩夢。
但是，我們的分片構造的關鍵點是，你可以構建任何東西作為分片。它們就像基本上是一個無限的設計空間，像一個分片可以是什麼。
假設你並不喜歡用 Go 編寫你的遊戲代碼，那你完全可以選擇其他方式。不過，我們正在研發一種可以讓你用 Solidity 實現遊戲的 Solidity 遊戲分片，這種方式在保留 Cardinal 的許多優點的同時，也提供了代碼編寫的可能性。你還可以創建一個具有獨特內存池和排序構造的 NFT 鑄造分片，解決類似於基本鑄造的 Noisy Neighbor 問題。你甚至可以創建一個遊戲身份分片，用 NFT 表示你的遊戲身份，這樣你可以輕鬆地通過 NFT 而不是分享私鑰的方式進行遊戲身份交易。
這是一個高級架構，今天由於時間關係我不會講過多深入的細節。關鍵是，我們允許 EVM 智能合約通過使用自定義的挑選和傳遞（pick and pass）與遊戲分片進行組合。我們圍繞 Geth 創建了一個 wrapper，允許它們之間進行通信，這在雙向上打開了大量的設計空間。我們默認是同步的，並且可以在分片之間無縫可組合地進行互操作，而無需鎖定。
我們的共享排序器與眾不同，因為它不使用優先考慮全局排序的原子束的共享序列構造，這需要一個鎖定機制，並導致了像阻塞主線程這樣的問題，從而導致不穩定的 tick rate 和區塊時間，結果就是遊戲出現延遲。它還對每個分片的區塊時間進行了限制，並需要各種加密經濟學和構造來防止服務拒絕。還有一個我在許多 VCR 排序器構造中沒有看到提到的大問題：如果你有不同的分片互相依賴並造成死鎖，你應該如何解決呢？通過異步設計，這都不是問題，因為每個人都在做他們想做的事情，然後放下不管。
事實上，跨分片的原子束和 roll-ups 通常並不必要。對於我們的使用案例，我們不需要任何需要原子束的東西，我們也不認為這是我們應該圍繞使用案例純度來設計我們的 Roll-Ups 的東西。這也帶來了許多其他有趣的特性。例如，每個遊戲分片可以有一個單獨的 DA 層用於基鏈。例如，你可以使用基礎分片將數據推送到以太坊，遊戲分片可以將數據推送到的 Celestia（類似數據可用性委員會）。你還可以減少運行全節點的硬件需求，因為你可以單獨運行基礎分片 Geth 全節點，而無需運行遊戲分片節點，這使得你更容易與 Alchemy 等事物集成。
總結一下，我想在這裡坦誠地說，很多人都希望他們的構造能解決所有的問題，但我們並非如此。我們認為我們的構造對我們有用，但可能對你的使用案例並不適用。假設我們的構造可以適用於所有人是不現實的。對我們來說，它符合我們的需求，提供了高吞吐量、水平可擴展性、靈活性和高 tick rate，但它並不能治癒癌症。如果你需要一個需要同步可組合性的 DeFi 協議，那麼這種構造可能不適合你。
總的來說，我真心相信人本（human-centric）區塊鏈架構的概念。通過圍繞特定的用戶角色和使用案例進行設計，你可以更好地進行權衡，而不是試圖解決所有人的問題。文藝復興時代已經到來，每個人都可以設計自己的 Roll-Ups 來滿足自己的特定需求，而不是依賴通用的解決方案。我認為我們應該擁抱寒武紀大爆發。不要像 one-size-fits-all 的 layer one 那樣構建 roll-ups，因為它根本就沒有用來解決同樣的問題。我個人很期待看到更多的人探索更多的 Roll-Up 設計空間，這些設計空間是針對使用案例的。例如，一個專門為資產交換設計的 Roll-Up 會是什麼樣子？它會基於意圖嗎？一個專門為鏈上 CLOBs（中央限價訂單薄）設計的 Roll-Up 會是什麼樣子？在此，我將麥克風交給 MJ。感謝你的邀請。
英文版:
https://captainz.xlog.app/Why-does-Argus-Build-FOC-Gaming-INFRA-Using-Sharding