現在是研究 ZK Rollup 開發體驗的最好時機
作者： Yiping，IOSG Ventures
原用標題： IOSG Weekly Brief | 開發者視角下的不同 ZKRollup 使用者體驗 #178
封面： Photo by Tareq Ajalyakin on Unsplash
本文為 IOSG 原創內容，僅做行業學習交流之用，不構成任何投資參考。 如需引用，請註明來源，轉載請聯繫 IOSG 團隊獲取授權及轉載須知。 特別感謝 IOSG Ventures 投研和投後團隊的辛苦協作！
TL;DR
Starknet 在 2022 年 11 月 29 日推出 Alpha Mainnet。
Scroll 在 2023 年 2 月 27 日推出其 Goerli Alpha Testnet。
zkSync 在 2023 年 3 月 24 日推出 zkSync Era Mainnet。
Polygon 在 2023 年 3 月 27 日推出其 zkEVM Mainnet Beta。
有了這些眾多的 ZK Rollup，作為一名 Solidity 開發者，你可能會好奇：
- 哪個提供了更適合你的開發者體驗？
- 哪個提供了你更需要的開發者支援？
- 如果你打算創建你的項目，哪個最適合你？
隨著 ZK Rollup 的陸續上線，現在是研究 ZK Rollup 開發體驗的最好時機。 考慮到所有 ZK Rollups 都在推廣他們的 EVM 相容性，我們對開發者體驗的探索將從 Solidity 工程師的角度出發，讓我們通過數據驅動的答案深入探討這些問題
ZK Rollup 的代碼開源比較
開源提升了開發者體驗，通過促進品質、安全性和合作。 其透明性允許全球開發者解決 Bug 和安全問題，從而持續提升軟體。 GitHub 充當學習平臺，提供對各種編碼風格、先進技術和行業標準的訪問，豐富了開發者的旅程。 開發者可以根據特定需求修改代碼。 開源通過多樣化的社區鼓勵協作和創新，推動項目的發展。
專案通常在達到關鍵里程碑後開源他們的代碼，通常是當代碼至少達到 Alpha 版本時。 仍在進行大量開發的代碼不適合開源，因為它們可能無法提供預期的好處，如品質提升、安全性提升和協作學習。 因此，開原始程式碼的數量通常與專案開發階段相關。
所有的 ZK Rollup 都在他們的 GitHub 上投入了大量的工作，儘管他們提供的內容有所不同。
項目語言選擇
Rust 在許多專案中成為構建編譯器、節點、工具鏈、CLI 工具和虛擬機的首選語言。
開發文件
開發文檔對於開發者體驗至關重要。 這些資源有效地彌合了 Layer2 解決方案的複雜性和乙太坊虛擬機（EVM）相容的開發生態系統之間的鴻溝。
不同的專案提供稍微不同的文檔結構和內容。
zkSync 為其特色功能 AA 和 Layer1 <> Layer2 通信提供了詳細文檔和參考代碼。
我們發現了以下改進的空間：
- 包含檔名和路徑：在任何代碼塊的開始部分，都要提到檔名和其路徑。 這有助於使用者知道在哪裡找到或放置代碼。
- 展示 CLI 執行結果：在提供命令行介面（CLI）指令時，包括命令的範例輸出。 這有助於使用者知道應該期待什麼，並驗證他們是否正確執行了命令。
- 限制代碼行長度：為你的代碼示例設置最大行長度。 這確保你的代碼易於閱讀，無需水平滾動。
- 使用真實的示例：而不是使用佔位元或『xxx』，提供範例合約地址或秘鑰。 這使用戶更好地瞭解他們應該使用何種數據。
- 對於複雜教程提供項目視圖：對於更複雜的教程，在教程的側邊提供項目視圖。 當使用者瀏覽教程時，突出顯示代碼的相應部分。
- 互動式範例：包含互動式範例以説明快速引導開發者。 這可以是一個播放區，用戶可以編輯和運行代碼片段，或者是雲開發環境。
- 整理文件：確保你的文件結構良好，易於導航。 使用清晰的標題，目錄。
- 保持更新：隨著專案的發展，確保你的文檔保持最新。 這可能意味著更新截圖，修訂代碼示例，或者重寫部分以反映新功能或變化。
社區和團隊貢獻
貢獻者的數量反映了開源社區的參與度。 更新的頻率和參與度對於保持最新、全面的文檔至關重要。
贡献人数越多代表其开源社区更活跃。大部分项目都在刚上线的时候达到文档更新频率的最高峰。
编码体验
编码体验取决于工具链、编辑器体验和框架。
相关工具链决定了是否容易设置本地开发环境、调试和运行代码。
编辑器体验决定了编码的速度。一个好的编辑器体验应该包括清晰的语法高亮、定义和自动补全。
框架提供了一个结构化的环境，大大加速了开发过程。它们带有预配置的功能和可重用的库，开发者可以利用这些来有效地编写智能合约，无需从头编写每一行代码。
Remix 类似软件的支持可以帮助开发者在不需要建立自己本地环境的情况下快速开始开发工作。目前，这种云原生的开发体验只适用于后端智能合约。它还需要进行改进以适应 Dapp 开发，包括智能合约和前端。
Warp 表现不佳。Kakarot 将是与 StarkNet 兼容的 EVM 的唯一解决方案。Kakarot 提供了一个非常流畅的 Solidity 开发体验。与所有现有的以太坊工具，如编译器、Remix 和 Hardhat 兼容。
Kakarot 提供了一个用 Cairo 编写的 EVM。作为一个 EVM，Kakarot 能够执行 EVM 字节码程序，使得 Ethereum 智能合约能在 StarkNet 上运行。
测试
测试是智能合约开发的重要方面，它确保了智能合约的质量、功能和可靠性。这个过程包括验证每个功能是否按照预期运行，并在部署之前找出需要修复的任何错误或问题。通过进行彻底的测试，开发者可以有信心，软件将在各种场景和条件下正确运行。这个过程不仅防止了可能影响用户体验的潜在故障，而且帮助维护智能合约的完整性和安全性。测试还使开发者了解到潜在的优化，从而有助于智能合约的持续改进。
Tenderly 是智能合约开发的最佳调试工具之一。它提供智能合约执行模拟、调试器、燃气分析器、分叉和警告功能，以帮助开发者更好地构建 Dapp。然而，Tenderly 并不支持任何 ZK Rollup。
希望在不久的将来，我们能看到更多支持 ZK Rollup 的智能合约开发和调试工具，这将有助于推动区块链技术的进一步发展和应用。
部署
部署过程在智能合约开发生命周期中至关重要。好的部署工具为从开发到链上环境部署智能合约提供自动化、一致和可靠的体验。好的部署工具可以显著减轻手动部署任务的负担，从而加快交付时间并减少人为错误。
StarkNet 的部署步骤分为 Declare 和 Deploy 两步，因此需要较长的时间。
Layer2 新特性
Layer2 解决方案在解决可扩展性、效率和用户体验的挑战方面发挥着至关重要的作用。ZK Rollup 还处在早期阶段，但已经显示出解锁开发者新可能性的巨大潜力。
通过提供如状态差异 (State-diff)、无缝的 Layer1 与 Layer2 通信，以及账户抽象化等突破性创新，ZK Rollup 使开发者能够创建创新项目，推动区块链可实现的界限。这些高级特性不仅增强了去中心化应用的能力，而且为区块链技术的主流接纳铺平了道路。
状态差异（State-diff）
StarkNet 和 zkSync Era 使用状态差异技术，理论上，可以产生更低的费用。他们只发布状态差异，而不是交易输入，这允许数据压缩和降低存储成本。这将会给游戏开发者带来好处。
Polygon zkEVM 在链上发布所有的交易输入，依赖于预期在未来几年内数据存储成本的降低。
Layer1 <> Layer2 通信
大多数 ZK Rollup 提供 Layer1 <> Layer2 通信功能。例如，zkSync Era 提供了一个利用 Layer1 <> Layer2 通信的治理例子。在 Layer1 上，合约可以启动一个 Layer2 合约执行。在 Layer2 上，Layer2 合约只能向 Layer1 合约发送信息。然后我们可以在 Layer1 上处理收到的消息。同样，Polygon 提供了一个关于 Nft-bridge 使用跨链通信在 L1 和 L2 之间共享信息的编码示例。
账户抽象化
账户抽象化是另一个令人兴奋的特性。zkSync Era 提供原生的 AA。zkSync Era 的账户可以启动交易，像 EOA 一样，但也可以在其中实现任意逻辑，像智能合约一样。由于 zkSync 原生实现了 AA，账户不需要额外的代理合约。即使是普通的 EOA 也可以有无需燃料费支付的交易，这在仅仅 EIP-4337 中是不可能的。Polygon zkEVM 和 Scroll 实现了与 EVM 兼容的 AA。StarkNet 也正在进行账户抽象化的工作。它寻求实现签名抽象化和支付抽象化。
未来对开发者体验的改进
在这次的研究中，我们深感这些 ZK Rollup 项目在不断改进产品和对开发者的支持方面付出了巨大的努力。然而，考虑到我们还处在区块链应用的初级阶段，面临的开发者群体相对较少，因此，致力于提升开发者体验无疑会帮助项目吸引未来的开发者，并最终塑造这个行业的未来。
以下是一些提高开发周期支持的常见建议：
1，文档：
- 高质量的文档：全面、清晰和及时更新的文档对于提高开发者体验至关重要。确保文档的完整性、清晰度、包含例子，并定期更新。
- 直观的 API 设计：API 应该一致、直观，并有良好的文档。根据 API 文档的清晰度和可访问性，以及完成常见任务的容易程度评估 API 设计。
- 完整的 API 引用和更改日志：提供详细的 API 引用，包括函数、参数、返回值和错误代码。维护一个更改日志，跟踪更新、新功能、bug 修复和已弃用的功能。
- 案例研究：展示产品应用的例子，以启发和教育开发者有效解决问题。
- 流畅的上手体验：通过简化环境设置，解释核心概念，和促进基本应用的创建，来缩短新开发者开始的时间。
2，可用性和效率：
- 工具的可用性：确保提供的工具用户友好且直观。通过评估开发者执行常见任务所需的时间来衡量使用的便利性。
- 错误信息和调试支持：通过有用的错误信息和强大的调试支持来提高开发者体验。你可以通过故意创建常见的错误，然后检查系统的回应有多帮忙来衡量这个。
- 集成和兼容性：评估工具或平台与生态系统中其他常用工具的集成程度如何。
3，透明度和更新：
- 产品状态：及时更新关于操作问题、维护计划和系统停机的信息，可以帮助开发者有效地规划他们的工作。
随着 Web3 领域的技术快速进步，以一种可扩展和可持续的方式维持一致的高水平开发者体验，对于 Web3 项目来说是一个显著的挑战。
為了應對這個挑戰，我們建議專案探索兩個方向：利用 AI 來增強自動化和生產力，減少對大量人力資源的需求，和利用社區的力量，激勵貢獻。
- AI 助力：生成和維護大量文件可能需要大量資源。 大型語言模型可能幫助開發者編寫和維護高品質的文檔。 此外，AI 驅動的 Q&A 機器人可以提供及時準確的回答開發者的查詢，進一步提高他們的體驗。
- 激勵社區參與：為了促進社區的參與，專案可以提供各種激勵，包括財務和非財務激勵。 例如，類似賞金的專案可以擴展到包括在代碼、代碼庫測試、文檔改進、翻譯工作和無價的第一手反饋中的貢獻，這些反饋直接來自使用者，反映出可以指導專案團隊改進產品的實際需求。 這種方法不僅有可能提高資源的品質，還可以説明減少維護成本。 通過活躍的社區管道（如 Discord、Substack 等）承認貢獻，給予貢獻者讚揚。
通過強調以開發者為中心的設計，並通過社區的共同努力，提供引人入勝的開發者體驗，我們可以在 Web3 世界中培育一個充滿活力和包容性的開發者生態系統！
免責聲明：作為區塊鏈資訊平臺，本站所發佈文章僅代表作者及嘉賓個人觀點，與 Web3Caff 立場無關。 本文內容僅用於資訊分享，均不構成任何投資建議及要約，並請您遵守所在國家或地區的相關法律法規。
