该2022 年 Solidity 开发者调查 结果已出炉！在这篇文章中，我们将对其进行总结和分析。
首先，非常感谢所有抽出时间参与调查的人，以及帮助我们宣传调查的人！今年，我们收到了 1401 份答卷，这比之前调查的答卷数量增加了 3 倍以上，我们对如此高的参与度感到非常高兴。你们的反馈对我们来说非常宝贵，并且在帮助持续改进整体 Solidity 开发者体验方面发挥着至关重要的作用。
在开始之前，这里有一些有用的链接
- 本着开源的精神，您可以找到调查结果的所有原始数据此处以及所有图表 此处。
- 由于这是我们第三次进行年度调查，因此比较结果与之前调查的结果可能很有趣。2021 年开发者调查的结果可 在此 查看，2020 年的结果可 在此 查看。
事不宜迟，让我们深入了解 2022 年的结果吧！
摘要和值得注意的见解
- 调查受众：2022 年调查共吸引了来自 100 个不同国家的 1401 名开发者参与。与之前的调查相比，答卷数量增加了 222% 以上！不同地区的覆盖范围也持续扩大，从 2020 年的 48 个国家增加到 2021 年的 73 个国家，再到 2022 年的 100 个国家。大约 18% 的受访者表示居住在美国，其次是印度（10%）和法国（5%）。
- 开发者画像：编码经验水平仍然处于中等至高级水平，大多数受访者拥有 3 年或以上专业编码经验，其中 12.5% 甚至超过 15 年。
- Solidity 使用经验：超过一半的受访者使用 Solidity 的时间不到一年，而 13.8% 的受访者使用 Solidity 的时间超过 3 年。41% 的人每天使用 Solidity，37.3% 的人每周使用。
- Solidity 专业知识：许多人认为自己是 Solidity 专家，其自我评估的专业知识评分为 7 或更高（满分 10 分）。4.6% 的人将自己的专业知识评为 10 分（满分 10 分）。其中 70% 的人使用 Solidity 的时间为 2-3 年或更长。
- 开发者体验：大多数（+75%）人认为 Solidity 开发者体验在过去一年有所改善。0.9% 的人认为它变得更糟了。调试问题经常遇到，其次是栈溢出错误和字节码大小限制。
- 未来特性：十进制数和泛型的支持被最常提及为“最期待的 Solidity 特性”。
- 喜欢的和讨厌的特性：受访者最喜欢 Solidity 的语法、易于学习、阅读、编码和编译，以及静态类型。最大的痛点是“栈溢出”，占所有投票的 33.6%，其次是缺少内存优化（浪费内存）（24.4%）和冗余检查（例如在受检算术中）（11.8%）。9.9% 的人表示编译器性能是他们最大的问题。
调查受众的人口统计
⚠️在解释有关居住国和语言偏好的结果分布时，请注意此调查仅以英文发布。
像往常一样，我们首先关注参与此次调查的开发者：在本章中，我们将介绍有关调查受众的一般信息，包括居住地和使用语言。
2022 年调查共吸引了来自 100 个不同国家的 1401 名开发者参与。与之前的调查相比，这代表着答卷数量增加了 222%。
不同地区的覆盖范围从 2021 年的 73 个国家增加到 2022 年的 100 个国家。
居住地
大约 18% 的受访者表示居住在美国，其次是印度（10%）、法国（5%）和尼日利亚（4.5%）。
语言
受访者的多样性不仅体现在居住国方面，也体现在母语方面。总共有 70 种不同的语言被提及为他们的母语。与去年相比，增加了 40%。
31.5% 的人将英语作为母语，其次是印度语（12.4%）、西班牙语（8.4%）、法语（6.9%）、俄语（6.4%）和德语（4.7%）。
ℹ️印地语、乌尔都语、泰卢固语、孟加拉语、泰米尔语、马拉雅拉姆语、古吉拉特语、马拉地语、卡纳达语和奥里亚语被归类为“印度语”。汉语、粤语和普通话被归类为“汉语”。波斯语、普什图语和奥塞梯语被归类为“伊朗语”。
大多数受访者（近 80%）主要在工作中使用英语。工作中使用的其他语言包括：法语（3.2%）、俄语（3.1%）和汉语（2.3%）。
在那些没有将英语作为母语的受访者中，87% 的人可以接受阅读英文版的 Solidity 文档。
12.9% 的人更希望阅读他们母语版本的文档，其中提及最多的语言包括西班牙语、印度语和俄语。
ℹ️注意：此次调查仅以英文进行，这可能会影响此问题的结果。我们仍然认为国际化资源（如 Solidity 文档）是降低入门门槛的关键因素，我们旨在通过帮助协调社区驱动的 翻译工作 来提供支持。
开发者画像
在 Solidity 开发者调查的第二部分，我们深入了解了调查受众的专业经验和编码偏好。
工作经验和就业情况
大约 71% 的受访者在调查期间有工作，大约 12% 的受访者表示是学生，17% 的受访者表示目前没有从事专业工作。
与之前的调查相比，学生和目前失业的开发者的数量略有增加。
受雇的受访者主要在“加密货币”（58.2%）、技术（21.6%）和金融服务（5.4%）行业工作。
所有受访者中，37.1% 为高级开发者，拥有 6 年或以上的专业编码经验，其中 12.5% 甚至拥有 15 年以上的经验。
另一方面，大约 12% 的人是编码新手，只有不到一年的专业编码经验。
占比约 22% 的最大群体处于分布的中间位置，拥有 3-5 年的专业编码经验。
总体而言，编码经验水平处于中等至高级水平，大多数受访者（59.2%）拥有 3 年或以上的专业编码经验。7.7% 的人从未将编码作为工作的一部分，其中 37% 为学生。
与 Solidity 的接触点
与之前的调查一样，大多数受访者（75.7%）仍然将 Solidity 用于个人项目。
大约 64% 的受访者在工作中使用 Solidity。
超过 20% 的人表示他们领导着一个编程团队。
只有 23.4% 的受访者每天或每周都会为用 Solidity 编写的开源项目做贡献。其余的人表示每月（27.4%）或从不（47.1%）贡献。
编程语言偏好
Solidity 是调查受众使用最多的编程语言（28.6%），其次是 JavaScript（25.6%）和 TypeScript（20.5%）。
其他不太常用的语言包括 Python（8.7%）、Rust（2.7%）和 Go（2.5%）。
与去年类似，受访者最喜欢的编程语言在各种语言之间分布得更加均匀。
Solidity 最受欢迎，占所有条目数的 18.8%，其次是 JavaScript（17.3%）、Python（15.2%）、TypeScript（15.0%）和 Rust（8.6%）。
操作系统
大多数受访者使用 macOS 作为其主要操作系统（41.8%）。Windows 和 Linux 也比较受欢迎，分别为 30.5% 和 27.7%。
Solidity 用户画像
在本部分调查中，我们询问了受访者关于他们与 Solidity 相关的开发经验和使用习惯。
Solidity 使用经验
几乎 50% 的受访者认为自己是 Solidity 专家，其自我评估的专业知识评分为 7 或更高（满分 10 分）。
4.6% 的人将自己的专业知识评为 10 分（满分 10 分），其中 70% 的人使用 Solidity 的时间为 2-3 年或更长。
大约 23% 的人可以被认为是初学者或低频用户，其自我评估的专业知识水平为 4 或更低。
即使调查受众规模扩大到了原来的三倍，自我评分的分布也与之前的调查相似。
大约 50% 的受访者使用 Solidity 的时间不到一年，其中 13% 的人刚刚开始他们的 Solidity 之旅（使用经验少于三个月）。
13.83% 的人使用 Solidity 的时间超过 3 年，因此可以被认为是“Solidity 老手”。为了更好地理解年限：“版本 0.1.1”，Solidity 在solc-bin 上的最旧版本，来自 2015 年 8 月，因此大约有 7.5 年的历史。该语言仍然相对年轻，并且仍在不断发展。我们可能会在下次调查中添加更多粒度的“超过 3 年”的 Solidity 使用经验选项，以便更好地区分这一点。
与往年一样，Solidity 似乎很容易学习，21.2% 的受访者表示在不到一个月的时间内就能够高效使用，39.3% 的受访者表示在不到半年内就能够高效使用。
8.1% 的人需要一年以上才能对这门语言感到舒适。
17.8% 的人还没有感到高效，其中 74.2% 以上是初学者，使用 Solidity 的时间为 6 个月或更短，47% 的人甚至不到三个月。
Solidity 用户画像和使用习惯
关于使用频率，超过 40% 的受访者每天使用 Solidity！
37.3% 的人每周使用，13.9% 的人每月使用。
大约 8% 的人表示“很少”或“从不”使用 Solidity。
他们大多数之前都表示将 Solidity 用于个人项目，并在工作中使用其他编程语言进行编码。
惊人的 81.8% 的受访者在编写 Solidity 代码时使用 Visual Studio Code 作为编辑器。Vim 和 IntelliJ 分别以 3.7% 和 3.4% 的使用率位居第二和第三位。
与 2021 年的之前调查相比，Visual Studio Code 的普及率显著提高（从大约 50% 上升到 81.8%）。
根据所选 IDE，我们还询问了受访者是否使用了任何与 Solidity 相关的插件。
Nomic Foundation 的“HardHat VSCode”和 Juan Blanco 的“Solidity”扩展（均适用于 Visual Studio Code）是最受欢迎的。
Hardhat 仍然是最受欢迎的以太坊专用开发环境，大约 75% 的受访者使用 Hardhat。
Remix 排名第二，占比 42%。Foundry 的份额大幅增加，从 2021 年的 1.6% 增长到 2022 年的 30%。
Truffle 继续淡出，17% 的受访者表示他们使用它。
其他较为“小众”的以太坊专用开发环境包括 Brownie (6.7%)、Ape (3.3%)、Dapptools (2.3%) 和 Embark (0.8%)。
4.4% 的受访者没有使用任何以太坊专用开发环境。
值得注意的是，这个问题是一个复选框问题，允许受访者选择多个答案。
⚠️比较 2020 年、2021 年和 2022 年的结果可能会提供一些见解，例如 Truffle 份额大幅下降 (2020 年：59.3% -> 2021 年：26.2% -> 2022 年：17%)，而 Hardhat 和 Foundry 等新兴工具的用户份额有所增加。但是，务必注意，之前的调查响应人数明显较少 (2020 年：194 人，2021 年：435 人，2022 年：1401 人)。年度比较只能被解读为一种松散的趋势，本研究的目的并非详细分析 IDE 之间用户分布。
大约 90% 的用户仍然使用 0.8.x 版本的 Solidity，它是迄今为止使用最广泛的版本。0.7.x (10.2%) 和 0.6.x (7.7%) 系列的使用份额自上次调查以来持续下降。更旧的版本几乎不再使用。
⚠️提醒：请确保经常将您的代码（和编译器）更新到最新的 Solidity 版本。新版本中添加了许多重要的错误修复和安全改进！
Solidity 使用详情
今年，我们还针对 Solidity 使用习惯提出了具体问题。
有关这些问题的图表和数据，请参阅包含所有图表的内容介绍和原始数据文件。
总结
- 命令行：大约三分之二的受访者不直接通过命令行使用 Solidity 编译器。37.5% 的受访者使用。
- 命令行：在命令行使用编译器时，61.3% 的受访者仍然使用标准 JSON。
- 优化器：93.6% 的受访者不会禁用优化器。6.4% 启用优化器的受访者表示，他们这么做是为了解决合约大小限制、编译速度慢、通过 Etherscan 验证、进行燃气测试或出于安全考虑。
- 燃气估算器：23.4% 的受访者使用编译器内置的燃气估算器。25% 的受访者尝试过，但没有定期使用，而 41.5% 的受访者从未使用过。
- SMTChecker：81% 的受访者从未使用过 SMTChecker。13.7% 的受访者尝试过，5.4% 的受访者经常使用。您可以在此处了解有关 SMTChecker 的更多信息。
- via-IR 编译管道：70.8% 的受访者不知道什么是via-IR。18.6% 的受访者已经在使用via-IR管道。在接下来的几周内，我们将分享更多关于为什么您应该从传统编译管道切换到via-IR以及这意味着什么的背景信息。
- 元数据发布：53.5% 的受访者发布了其智能合约的元数据。27.8% 的受访者不发布，而 18.7% 的受访者不知道这意味着什么。
- Sourcify：11% 的受访者使用 Sourcify 进行智能合约验证，而 21.2% 的受访者声称不需要它。67.8% 的受访者不知道什么是 Sourcify。如果您想了解有关 Sourcify 的更多信息，请访问sourcify.dev。
定点类型
大约 91% 的调查受访者不使用定点类型。
9% (100 人) 使用的用户主要使用PRB Math、solmate 的 FixedPointMathLib 和自定义实现。
其他 EVM 网络
超过一半的受访者在以太坊主网和测试网之外使用 Solidity。当被问及他们在哪些其他网络上部署智能合约时，最受欢迎的链条是 Polygon (以前称为 Matic Network)。其他经常被提及的区块链包括 Binance 智能链、Arbitrum、Avalanche 和 Optimism。
其他智能合约语言
一半的受访者与 Solidity 一起使用其他智能合约语言。使用最多的其他智能合约语言是Yul，一种 Solidity 的中间语言，占比 17.2%，其次是Vyper，一种 Python 风格的 EVM 语言，占比 10.5%。Cairo (7.1%)，一种针对 StarkNet 的基于 STARK 的语言，以及Huff (6.2%)，一种 EVM 的低级汇编语言，也多次被提及。其他“新兴语言”如Sway (2.4%) 和Fe (1.5%) 也出现在图表中。
Solidity 开发者体验
76.5% 的受访者认为 Solidity 的开发者体验在过去一年中总体有所改善。25.1% 的受访者认为与前一年相比，他们注意到了很大的改进。
7.8% 的受访者表示他们的体验没有变化，而 0.9% 的受访者认为体验变差了。
与去年的结果相比，“变差了”和“不知道”的比例有所下降，“没有变化”的比例略有上升。总体而言，情况非常相似。
遇到 Solidity 问题时，大多数受访者会访问 Ethereum StackExchange/StackOverflow 寻求帮助或在互联网上搜索解决方案。许多人也会向同事寻求帮助或观看教程视频。
反复出现的问题
60% 的受访者在使用 Solidity 开发时没有多次遇到相同或类似的问题。
在遇到相同或类似问题的 40% 的受访者中，最常遇到的问题是调试问题，其次是堆栈过深错误和字节码大小限制。
ℹ️关于调试问题，我们想借此机会重点介绍一项新的举措，旨在为构建在 EVM 之上的语言定义通用的调试数据格式：ethdebug。最终结果将是一个规范，允许调试器、分析器和其他工具在编译器生成的 EVM 字节码和高级语言特性之间可靠地映射。多年来，这在整个生态系统中一直是一个常见难题，并且随着 Solidity 中引入新的基于 IR 的代码生成器（即via-IR管道），这个问题变得更加紧迫，因为新的代码生成器经常会破坏工具基于传统管道工作方式所做的隐式假设。我们鼓励所有从事此类工具开发的开发人员加入工作组。该组定期举行双周会议，并通过 Matrix 上的ethdebug 频道进行协调。
入门和文档
大多数受访者认为使用 Solidity 编译器入门很容易或“还可以”。4.2% (55 人) 表示他们觉得很难入门。当被问及是什么让他们难以入门时，一些人提到了之前缺乏技术背景或开发经验，另一些人则指出了缺乏良好的学习资源或学习资源过时。
近 64% 的调查受访者认为 Solidity 文档很有帮助，其次是 33% 的受访者认为文档“有点”有用。只有 3.3% 的受访者认为文档完全没有用。
改进建议主要包括提供更多代码示例，以及改进语法的高级概述、文档内搜索、搜索引擎优化和措辞。
最大的痛点
与往年不同，今年我们尝试更好地构建围绕“最大痛点”的问题，并将第一步划分为几个突出的类别：堆栈过深、燃气相关问题、编译器性能和“其他”。
最大的痛点是“堆栈过深”，占比 33.6%，其次是内存优化不足（浪费内存）（24.4%）和冗余检查（例如在检查算术中）（11.8%）。9.9% 的受访者表示编译器性能是他们最大的问题。
15.8% 的受访者选择了“其他”，并能够在自由文本字段中指定他们最重要的痛点。最常被提及的是：合约大小限制、错误消息和调试问题。
高影响编译器错误
作为今年研究的一部分，我们也很想知道 Solidity 开发人员是否受到任何高影响编译器错误（在 Solidity 博客上以安全警报形式宣布的代码生成错误）的影响。
最初，4.7% 的受访者表示是。但是，当被问及他们受到哪种错误的影响时，在后续问题中只有 63 人中的两人能够指出实际的 Solidity 漏洞。这表明，从本次调查中受影响的开发人员的实际人数可能远低于 4.7%，一些受访者可能只是误解了问题。我们将在下一次调查中尝试更准确地措辞这个问题。
语言设计和即将推出的功能
最喜欢的功能/Solidity 方面
受访者最喜欢 Solidity 的语法、学习、阅读、编码和编译方面的简单性以及静态类型。
最常被提及的喜欢的功能（按降序排列）：
- 语法
- 易于……阅读/编码/编译/学习
- 简单性
- 静态/强/严格类型
- 与其他语言的相似性（最常提及 JS/TS 和面向对象，也提及：Rust、C++、Python）
- 修饰符
- 内联汇编
- 映射
- 继承
- (用户定义) 类型
- SafeMath/检查和未检查
- Yul
最令人畏惧的方面
今年，我们向调查受众提出了一个略有不同的问题：“如果您可以更改 Solidity 的一项内容，您会更改什么？”
最常被提及的“更改请求”（按降序排列）：
- 修复堆栈过深
- 改进数组处理
- 燃气优化
- 添加分数（定点类型/浮点类型）
- 改进错误处理和描述
- 改进调试
- 提高合约字节码大小限制
未来功能
最期待的功能
对分数和泛型的支持被最常提及为“最期待的 Solidity 功能”。
⚠️与去年类似，我们注意到受访者使用了各种不同的术语，如“浮点数”、“浮点运算”、“浮点数”、“定点数”和“定点数学”。我们将这些都归类为“分数”。
最常被提及的期待功能（按降序排列）：
- 对分数的支持（定点类型/浮点数）
- 泛型
- 更好的优化
- 不再出现堆栈过深
- 改进调试
- 瞬态存储
- 标准库
- 更好的错误信息
EIP 支持
我们还想了解调查受访者认为编译器需要支持哪些与 Solidity 相关的 EIP。
EIP-2535“‘钻石，多面代理”被提及最多，其次是 EIP-1153“瞬态存储”和 EIP-3540“EOF - EVM 对象格式”。
限制性
关于语言限制性，大约 43% 的受访者希望 Solidity 保持“现状”。41% 倾向于更严格/明确，进行更多检查，而大约 16% 希望 Solidity 变得不那么严格。
Solidity 开发者社区
语言设计社区参与
不到 10% 的所有受访者曾参与过与 Solidity 语言设计相关的活动。
参与论坛讨论和作为 Github 问题提出功能或语言更改的分布相当相似，而语言设计讨论和反馈电话的参与度略低（所有参与人数在 80-108 人之间，可以选择多个选项）。
在近 90% 未参与语言设计的人中，大多数表示不知道如何参与，其次是“工作或其他事情太忙”。大约 30% 的人表示他们对讨论不感兴趣或不具备资格。
保持知情
与往年类似，大多数人喜欢通过关注 Solidity 的 Twitter 或 Mastodon 来了解 Solidity 版本、安全警报和公告的最新信息。
其他常用的信息来源包括 Solidity 博客 和 Solidity GitHub 发布页面。
有趣的是，近 30% 的人声称没有做上述任何一项。
作为“其他”的一部分，受访者指定了几种基于社区的方式来保持最新状态
- YouTube
- 加密 Twitter/社区聊天
- Solidity 文档
- "以太坊新闻周刊"通讯
- "加密货币影响者"/流行的 Solidity 开发人员
- 更新 RemixIDE/Hardhat/VS Code
- 同事
- 谷歌
- 通讯
- 会议/聚会
- OpenZeppelin 论坛
- Solidity 网站
与其他 Solidity 开发人员的互动
超过一半的受访者与其他 Solidity 开发人员互动。
16.7% 的人根本不与其他 Solidity 开发人员互动。
与往年一样，作为调查的最后一部分，我们想听听有多少参与者同意或不同意关于 Solidity 社区和 Solidity 团队工作的几项陈述。
- 66% 的受访者感到（有点）受到 Solidity 开发者社区的欢迎。
- 大约 77% 的人同意或有点同意他们对 Solidity 团队的工作充满信心。
- 超过一半的人感到欢迎为 Solidity 做出贡献，但是，只有不到 40% 的人表示他们知道如何向 Solidity 贡献想法或反馈。
- 大约 25% 的人相信 Solidity 团队了解他们作为开发人员的需求。另有 35% 的人有点同意，而大约 9% 的人不同意或强烈不同意。
此次“社区和 Solidity 团队信心排名”的结果与去年非常相似。
可以看出，虽然社区似乎对 Solidity 团队的能力/资格充满信心，但围绕贡献方式以及对社区需求的理解的沟通可以改进。这些是我们过去几年一直在努力改进的事情，并将继续这样做。
感谢您并期待明年再见！
最后，我们要借此机会感谢您所有可爱和鼓舞人心的信息以及收到的反馈。我们对调查回复的数量感到震惊，并希望在未来几年继续保持这种趋势！我们希望本次调查的见解对您有用，就像对我们一样！我们将继续定期收集反馈。
为避免错过任何内容，请确保
- 关注 Solidity 的 Twitter 或 Mastodon。
- 加入 Solidity 论坛 中的语言设计讨论或在那里向我们提供反馈。
- 关注 Solidity 博客 上的公告和安全警报。
- 关注并 ⭐ Github 上的 Solidity 代码库。