编辑说明：我们注意到 [1] 常用以太坊专用 IDE 和 [2] Sourcify 使用的图形表示中存在一个细微错误。本文中的结果和幻灯片中相应的图形数据已更新，以反映这一更正，准确地反映了调查数据。
我们很高兴与大家分享2023 年 Solidity 开发者调查 结果！在这篇博文中，我们将回顾调查各个部分的关键见解和详细分析。
在我们深入研究之前，我们要感谢所有提交调查回复以及帮助我们接触到合适受众的人！你们的意见对我们来说非常宝贵，对于推动重要的语言设计决策和改进 Solidity 作为开源项目至关重要。
今年，我们收到了 474 份回复。让我们从一些有用的链接开始
事不宜迟，让我们深入了解 2023 年的结果！
摘要和突出见解
该调查共分为 6 个部分，即：[1] 人口统计，[2] 开发者和用户简介，[3] Solidity 背景，[4] Solidity 开发者经验，[5] 语言设计，以及 [6] Solidity 开发者社区。
让我们从 2023 年调查的各个部分中查看一些关键见解和摘要。
- 人口统计：总共有来自 71 个不同国家的 474 名开发者参与了 2023 年的调查。回复者人数最多的国家是美国 (18.8%)，其次是印度 (10.5%) 和尼日利亚 (6.2%)。这与去年的见解保持一致，只是尼日利亚取代了法国成为回复者人数第三多的国家。今年，我们看到了新的非洲本土语言，如基尼亚卢旺达语、斯瓦希里语、鲁尼亚科列语和卢干达语。
- 开发者和用户简介：Solidity 仍然是受访者使用最多的语言，其次是 JavaScript 和 TypeScript。大多数 Solidity 专家（自评 10 分）使用该语言的时间已超过 2 年，有些人甚至超过 5 年。
- Solidity 背景：36.7% 的用户表示他们用不到 6 个月的时间就对 Solidity 感到熟练。有趣的是，在这部分用户中，大多数受访者每天或每周都会使用 Solidity，而那些对 Solidity 不熟练的用户大多数使用该语言的时间不到 3 个月。
- Solidity 开发者体验：总体而言，大多数参与者认为 Solidity 开发者体验在过去一年有所改善。33.8% 的用户表示映射是他们最喜欢的功能，其次是对象契约 (23.2%) 和修饰符 (16.1%)。
- 语言设计：泛型 (23.2%)、带自定义错误类型的 require (17.4%) 和瞬态存储 (13%) 被发现是今年最受期待的功能。28.6% 的参与者知道以太坊对象格式 (EOF)，其中 63.5% 对其会积极影响他们充满信心。
- Solidity 开发者社区：GitHub 发布在用于了解 Solidity 公告的来源列表中排名上升。
人口统计
⚠️ 请注意，该调查仅以英语进行，在解释有关居住国分布和语言偏好的结果时要谨慎。
让我们从分析调查的第一部分开始，该部分涵盖了有关受访者居住地和母语/语言偏好的信息。
总共有来自 71 个不同国家的 474 名开发者参与了 2023 年的调查。
不同地区的覆盖范围从 2021 年的 73 个国家增加到 2022 年的 100 个国家，并在 2023 年降至 71 个国家。有趣的是，2022 年的回复人数激增。
居住地
从 2023 年的调查中，18.8% 的受访者表示他们住在美国，其次是印度 (10.5%)、尼日利亚 (6.2%) 和德国 (5.3%)。
这与前一年相当一致，只是尼日利亚和德国的回复人数比法国多，排名更高。
语言
在 2023 年的调查中，受访者的母语总共提交了 60 种语言。
32.6% 的参与者母语为英语，13.1% 说印度语，7.5% 说西班牙语，6.7% 说法语，5.2% 说汉语，4.9% 说德语，4.3% 说俄语，1.3% 说非洲语言。
ℹ️ 注意：孟加拉语、古吉拉特语、印地语、马拉地语、尼泊尔语、奥里亚语、旁遮普语、泰米尔语、泰卢固语和乌尔都语被归类为“印度语言”。粤语、汉语和普通话被归类为“汉语”。伊博语、基尼亚卢旺达语、斯瓦希里语、鲁尼亚科列语、卢干达语、斯瓦希里语和约鲁巴语被归类为非洲语言。
有趣的是，今年调查结果中出现了新的非洲语言，如基尼亚卢旺达语、斯瓦希里语、鲁尼亚科列语和卢干达语。
超过一半的受访者 (54.2%) 主要在工作中说母语，而 45.8% 仍然在工作中说另一种语言。
总共有 75.4% 的受访者表示他们主要在工作中说英语，其次是汉语、印度语、西班牙语和法语，这几种语言的分布几乎相同。
总共有 84.8% 的参与者表示他们可以接受阅读英语版本的 Solidity 文档。
但是，15.2% 的参与者更喜欢阅读他们母语版本的文档。今年希望用母语阅读文档的受访者人数略高于去年 (12.9%)。
ℹ️ 注意：该调查仅以英语进行，这可能影响了这个问题的结果。我们仍然认为，国际化像 Solidity 文档这样的资源是降低进入门槛的关键因素，我们旨在通过帮助协调社区驱动的 翻译工作 来支持这一点。
开发者和用户简介
在 Solidity 开发者调查的第二部分，我们收集了有关开发者/用户职业背景的见解，并了解了他们对编码语言、开源贡献、操作系统等的偏好。
就业和工作经验
在调查时，65.2% 的受访者受雇，而 13.4% 的受访者表示他们是学生。21.4% 的受访者表示他们目前没有工作。
与之前的调查相比，学生人数和目前失业的开发者或用户的数量略有增加。
在所有参与者中，69.6% 的受雇者在“加密货币”领域工作，而 14.7% 在通用技术领域工作，4.5% 在金融服务领域工作。
这一趋势与去年的结果非常相似，只是各个百分比略有变化。
大约 36% 的受访者被认为是他们所在领域的资深人士，他们在专业领域编码的时间超过 6 年，其中 9.7% 的人编码时间甚至超过 15 年。
相反，大约 6.1% 的人从未在工作中进行过编码，9% 的人仅在工作中进行过不到一年的编码。
大多数受访者 (28.3%) 是中级程序员，拥有 3-5 年的经验。
总体而言，专业编码经验水平为中高级，大多数受访者 (64.5%) 在专业领域编码的时间超过 3 年。
开发者简介
当被问及哪个开发者简介最能描述参与者时，大多数人表示自己是智能合约开发者。
大约 5.3% 的人是工具开发者，其次是 4.4% 的审计员/安全专家，只有 1.3% 的人表示自己是学术研究人员。
大多数参与者 (48.9%) 在工作中和个人项目中都使用 Solidity。其余受访者在工作中使用 Solidity 或个人项目中使用 Solidity 的分布几乎相同。
总共有 32% 的用户定期 (每天和每周) 参与开源项目，而 27.1% 的用户仅每月参与一次。近 41% 的用户表示他们从未参与过用 Solidity 编写的开源项目。
今年，从未参与过开源项目的用户的数量有所减少，每天或每周参与开源项目的用户的数量有所增加。
编程语言偏好
今年，Solidity 再次成为参与者使用最多的编程语言 (42.9%)，其次是 TypeScript (16.7%) 和 JavaScript (15.4%)。
我们观察到，将 Solidity 作为最常用语言的调查参与者人数大幅增加，从去年的 28.9% 上升到今年的 42.9%。JavaScript 和 TypeScript 今年似乎互换了位置。
其他使用频率较低的语言包括 Python (9.5%)、Rust (3.5%)、C# (2.4%) 和 C++ (2.2%)。
当被问及最喜欢的语言时，Solidity 获得了 29.1% 的投票，排名最高，其次是 Python (15.6%)、JavaScript (12.4%)、TypeScript (12%) 和 Rust (10%)。
该列表中其他使用频率较低的语言包括 Go (4.1%)、C++ (3.4%)、Java (3%)、C# (2.8%) 和 C (1.5%)。
首选操作系统
大多数参与者使用 MacOS 作为主要操作系统 (40.5%)。Linux 和 Windows 的普及率相同，分别为 29.9% 和 29.7%。
Solidity 背景
在调查的下一部分，我们收集了有关 Solidity 特定的开发经验和参与者的使用习惯的信息。
Solidity 专业知识
近 60% 的受访者认为自己是 Solidity 专家，自评专业知识评分为 7 分或以上 (满分 10 分)，其中自评 8 分的参与者人数最多。
23.4% 的人自评为专家 (自评 10 分)，其中约 84% 的人使用 Solidity 的时间超过 2 年。
所有受访者中，大约 20% 的人是初学者，自评评分为 4 分或以下。
我们询问了参与者他们使用 Solidity 的时间。所有受访者中，近 30% 的人使用 Solidity 的时间不到一年，其中 10% 的人使用 Solidity 的时间不到三个月。
受访者人数最多的 (24.5%) 是使用 Solidity 2-3 年的用户。
大约 24% 的用户可以被认为是该生态系统的资深人士，因为他们表示他们使用 Solidity 的时间超过 3 年。
当被问及他们对 Solidity 感到熟练需要多长时间时，大多数受访者 (36.7%) 表示他们用不到 6 个月的时间就感到熟练。
17.8% 的人甚至表示他们只用不到一个月的时间就感到熟练。
12.7% 的人需要超过一年才能对该语言感到满意。这个数字略高于去年。
17.4% 的人还没有感到熟练，其中 76.7% 是初学者，使用 Solidity 的时间不超过 6 个月，其中 45% 的人使用 Solidity 的时间甚至不到三个月。
Solidity 用户简介和使用习惯
大多数用户 (46.5%) 每天都会使用 Solidity，其次是每周使用 Solidity 的用户 (33.2%)，以及每月使用 Solidity 的用户 (11.9%)。
只有 1.9% 的人表示他们从未使用过 Solidity。6.5% 的用户表示他们很少使用 Solidity。
今年，我们还想知道调查对象如何获取 Solidity 二进制文件。最常提到的来源是
- 通过框架/IDE（38.8%）
- 使用 npm（18.6%）
- GitHub Releases（9.6%）
- 从源代码构建（9.3%）
- solc-bin（6.8%）
- Homebrew（6.1%）
其他不太流行的来源包括 Ubuntu 的 Ethereum PPA、Linux 发行版的包管理器和 Dockerhub。
77.2% 的受访者在编写 Solidity 代码时使用 Visual Studio Code 作为他们的编辑器。但是，这个数字仍然低于去年。
Vim 和 IntelliJ 分别以 4.7% 和 3.7% 的使用率位居第二和第三位。主要编辑器使用率的总体趋势仍然保持一致。
根据所选择的编辑器，我们还询问了受访者是否使用任何 Solidity 相关的插件。
与去年一样，Juan Blanco 的“Solidity”扩展和 Nomic Foundation 的“HardHat VSCode”再次被发现是 Solidity 开发人员中最受欢迎的。
我们想知道我们的调查参与者使用哪些以太坊特定的开发环境。
Hardhat 以 33.3% 的比例仍然是最受欢迎的以太坊特定开发环境。
然而，这个百分比明显低于 2022 年的结果，当时大约 75% 的受访者使用 Hardhat。
Foundry 位居第二，使用率为 32%，Remix 紧随其后，使用率为 25.8%。Foundry 在 2021 年的使用率从 1.6% 上升到 2022 年的 30%，自去年以来，其使用率似乎一直保持一致。
Truffle 进一步进入“其他”列表，只有 3 名受访者表示使用它。
虽然 Dapp 的使用率略有上升，达到 3.1%，但 Brownie（1.6%）、Truffle（0.3%）、Ape（0.3%）和 Embark（0.3%）今年的使用率似乎低于往年。
今年，Wake 以 0.5% 的投票率成为图表中的一个新的 IDE 选择。
只有 2% 的受访者根本不使用任何以太坊特定的开发环境。
与去年趋势相似，0.8.x Solidity 版本仍然是最常用的版本，在 485 票总数中，有 397 票（81.8%）支持该版本。
请注意，这是一个多选问题，允许参与者选择多个版本系列。
自上次调查以来，0.7.x（4.7%）和 0.6.x（5.5%）系列的使用率持续下降。其他较旧的版本很少使用。
⚠️ 重要提醒：请确保经常将您的代码（和编译器）更新到最新版本的 Solidity。在较新版本中添加了 几个重要的错误修复和安全改进！
Solidity 使用细节
与去年一样，我们还询问了用户有关 Solidity 使用趋势的具体问题。
CLI
59.9% 的受访者不直接通过命令行使用 Solidity 编译器，而 40.1% 的受访者使用。这一趋势与去年一致。
在命令行上使用编译器时，58.9% 的用户仍然使用标准 JSON。
当被问及 CLI 选项和输出的重大更改对受访者来说有多大破坏性时，64.1% 的受访者回答“还好”，26.5% 的受访者回答“完全没有破坏性”。只有 9.4% 的人认为这些变化具有破坏性。
旧的 EVM 版本
虽然 28.8% 的受访者仍然依赖旧的 EVM 版本，但大多数（71.2%）的受访者不再需要编译器支持旧的 EVM 版本。
在依赖旧版本的人群中，11.1% 仍然依赖已弃用的 EVM 版本。
未优化的代码
20.8% 的人表示他们从不使用未优化的代码。另一方面，27.9% 的人由于其框架的默认设置而使用未优化的代码，而 48.8% 的用户是为了调试、单元测试或在链上部署而使用未优化的代码。
ABIEncoderV1
虽然 63.9% 的人没有使用 ABIEncoderV1，但只有 6.5% 的人知道它并使用它。29.6% 的人根本不知道它。
SMTChecker
74.5% 的受访者从未使用过 SMTChecker。20.1% 的人尝试过，5.4% 的人经常使用它。您可以在 这里了解更多关于 SMTChecker 的信息。今年尝试过 SMTChecker 的用户比例大幅上升。
Thevia-IR 编译管道
51.9% 的人不知道 via-IR 是什么。这个数字比去年大幅减少。25.9% 的人已经在使用 via-IR 管道。在接下来的几周内，我们打算写一篇博文介绍 via-IR 是什么，以及为什么你应该从传统的编译管道切换到 via-IR。
当被问及使用 via-IR 管道编译合约代码需要多长时间时，大多数受访者表示需要 1 到 10 分钟之间的时间。
一些用户还报告说，编译时间也可能在 15 分钟到 60 分钟之间。
一些回复中的异常值也表明编译时间长达 300 分钟和 200000 分钟。但是，我们认为这些回复并不准确，因此图表中没有包含这些回复。
当被问及用户使用 via-IR 时最担心什么时，27.4% 的人表示担心编译时间，21.4% 的人表示对 via-IR 不够了解，17.9% 的人表示担心稳定性/安全性，13.5% 的人表示担心缺乏工具。
元数据发布
55.2% 的受访者表示他们发布了其智能合约的元数据，这一比例略高于去年。
30.3% 的受访者不发布其智能合约的元数据，而 14.5% 的受访者不知道这意味着什么。这两个数字都比去年有大幅改善。
Sourcify
当被问及 Sourcify 的使用情况时，14.2% 的受访者表示使用 Sourcify 进行智能合约验证（高于去年），而 30.7% 的受访者表示不需要它。55% 的受访者不知道 Sourcify 是什么，这一比例低于去年。
大多数（37.1%）的用户通过 Hardhat 使用 Sourcify，其次是通过 Foundry（27.4%）、直接通过 Sourcify（16.1%）和通过 Remix（14.5%）使用 Sourcify。如果您想了解更多关于 Sourcify 的信息，请访问 sourcify.dev。
appendCBOR: false 或 bytecodeHash: none
55% 的用户不知道 appendCBOR: false 或 bytecodeHash: none 是什么，而 30.8% 的用户知道但不需要它。只有大约 13.7% 的用户经常或有时使用它。
扁平化合约
53.9% 的受访者没有扁平化他们的合约，而 22.5% 的受访者扁平化了他们的合约。23.6% 的受访者不知道什么是扁平化合约，也不知道如何扁平化合约。
大多数扁平化合约的用户表示他们这样做是为了验证。
其他 EVM 网络
超过一半的受访者（65.1%）在 以太坊主网 和 测试网 之外使用 Solidity。
当被问及他们在哪些其他网络上部署智能合约时，20.8% 的受访者回答是 Polygon（以前称为 Matic 网络）。
其他经常提到的区块链包括 Arbitrum（15.6%）、Optimism（13.2%）、Binance Smart Chain（10.6%）和 Avalanche（8.1%）。
其他智能合约语言
Yul 是 Solidity 的一种中间语言，它仍然是最常用的智能合约语言，除了 Solidity 之外，还有 23.9% 的受访者使用它；与去年相比略有增长。
Vyper 是一种 Python 风格的 EVM 语言，它排名第二，除了 Solidity 之外，还有 11.9% 的人使用它。
到目前为止，这一趋势与去年相似，只是百分比略有上升。
Huff（9.3%）、Cairo（5.8%）和 Sway（2.1%）连续第二年入榜。
Fe（1.8%）今年也再次入榜。但是，Rust 没有被频繁提及。
Solidity 开发人员体验
在调查的下一部分，我们将回顾用户社区的开发人员体验。
当被问及 Solidity 开发人员体验的总体改善情况时，76% 的受访者普遍认为，在过去一年中，Solidity 开发人员体验有所改善，其中 20.2% 的受访者甚至认为这是一个巨大的进步。
只有 1.6% 的受访者认为开发人员体验变得更糟。
反复出现的问题
当被问及参与者是否遇到过反复出现的问题时，53.3% 的受访者表示，他们在 Solidity 开发中没有多次遇到过相同或类似的问题。
在遇到过反复出现的问题的 46.7% 的受访者中，堆栈深度过大问题是最常遇到的，其次是字节码大小限制和调试问题。
_ℹ️ 注意：关于调试问题，我们想提醒您注意 ethdebug 标准开发工作组，这是一项旨在为基于 EVM 的语言定义通用调试数据格式的倡议：ethdebug。
我们鼓励所有从事此类工具开发的开发人员加入工作组。该工作组定期举办双周会议，并在 ethdebug Matrix 频道 上进行协调。_
开始使用编译器
当被问及开始使用 Solidity 编译器有多容易时，大多数受访者认为它非常容易（44.8%）或“还好”（50.9%）。
只有 4.3% 的受访者表示他们很难开始使用编译器。当被问及是什么让开始使用编译器变得困难时，一些人提到了缺乏好的文档和示例。
最喜欢的方面/功能和痛点
23.5% 的受访者最喜欢 Solidity 与其他编程语言的相似性。
其他人喜欢它易于学习（17.4%）、静态类型化（16.3%）、简单（15.4%）。
有些人还认为其语法（12.7%）和易读性（10.4%）是最喜欢的方面。
33.8% 的受访者认为映射是他们最喜欢的功能，其次是合约作为对象（23.2%）。
修饰符（16.1%）和内联汇编（12.6%）也经常被提及。
一些用户将用户定义类型（6%）、动态数组（3.4%）和 using for（2.5%）列为他们最喜欢的功能。
当我们询问参与者他们对 Solidity 的最大痛点时，堆栈深度过大错误排名第一，占所有投票的 42%，其次是缺少内存优化（21.6%）和编译器性能（13%）。
8.6% 的受访者表示，冗余检查（例如，在受检算术中）是他们最大的问题。
几乎 11% 的受访者选择了“其他”，并指定了一些他们最显著的痛点，即：字节码和合约大小限制以及错误。
文档
当被问及参与者是否觉得官方文档有帮助时，68% 的调查受访者表示 Solidity 文档对他们有帮助，其次是 29.1% 的受访者认为它略微有用。
只有 2.9% 的受访者投票表示他们完全没有发现文档有用。
改进建议最突出的是要求更多代码示例，以及更清晰的语法概述、更好的文档内搜索和整体更好的 UI/UX。
高影响编译器错误
我们很好奇地想了解 Solidity 开发人员是否受到任何高影响编译器错误（在 Solidity 博客上发布了 安全警报 的代码生成错误）的影响。
虽然 95.7% 的受访者表示他们没有受到影响，但 4.3% 的受访者声称他们受到了影响。
当被问及他们受到哪个错误的影响时，我们发现以下信息
（仔细核对已报告错误是否属实，并相应列出）
外部库
大多数调查受访者（47.8%）完全不使用外部库。
然而，42.7% 的受访者表示他们使用外部库，并指定了用例，例如合约拆分、代理模式和代码共享。
只有 9.5% 的用户不知道什么是外部库（或它们被用于什么）。
语言设计和即将推出的功能
在调查的下一部分，我们将带您了解我们从询问参与者他们对 Solidity 语言设计更新和努力的想法和参与程度中得出的见解。
最受期待的功能
23.2% 的受访者表示他们最期待的功能是支持泛型，其次是 17.4% 的受访者表示他们最期待 Require 具有自定义错误类型功能。
⚠️ 注意：与去年类似，我们将诸如“浮点数”、“浮点运算”、“浮点数”、“定点数”和“定点数学”之类的各种术语归类为“十进制数”。
其他最受期待的功能（按降序排列）
- 瞬时存储（13%）
- 解决堆栈过深错误（11.6%）
- 更好的燃气优化和调试工具（10.1%）
- 支持十进制数和动态内存数组（7.2%）
限制性
当我们询问调查参与者他们对语言限制性的看法时，44.7% 的受访者希望 Solidity 保持“原样”。
大约 35.6% 的受访者通常更喜欢更严格/显式的行为，而大约 19.6% 的受访者更希望 Solidity 变得不那么严格。
这个问题的整体结果在去年和今年之间是可比的。
对新功能/改进的反馈
我们询问了参与者他们对 Solidity 中的后缀类型和函数元素的看法。
以下是我们关于以下内容的发现
-
后缀类型：虽然 72.5% 的受访者（占多数）明确表示他们要么不喜欢后缀类型，要么不关心，但 27.5% 的受访者表示他们喜欢后缀类型。
-
函数元素：几乎 60% 的用户表示他们喜欢在 Solidity 中添加更多函数元素的想法，例如 Lamda 函数。15.4% 的用户表示他们不喜欢，而 24.7% 的用户对此无动于衷。
EIP 支持
我们还想知道调查受访者了解或期待使用哪些与 Solidity 相关的 EIP，以及原因。
让我们看看关于以下内容的一些有用的见解
-
EIP-1153“瞬时存储”：40.1% 的受访者了解瞬时存储 EIP，而 59.9% 的受访者不了解。40.4% 的受访者表示他们需要瞬时存储中的复杂类型，例如映射和数组，而其余的受访者对是否需要复杂类型持相同看法，或者对此无动于衷/不了解。
-
EIP-3540“EOF - EVM 对象格式”：有趣的是，只有 28.6% 的受访者了解 EOF。在 28.6% 的受访者中，63.5% 对其持积极态度，只有 4.8% 的受访者认为它会对他们作为开发人员产生负面影响。
语言设计相关努力
当被问及受访者是否参与或继续参与语言设计工作时，我们发现以下信息
- 几乎 86% 的受访者表示他们没有参与，因为他们要么太忙，要么不感兴趣/不合格，要么不知道如何参与。
- 大约 14.2% 的受访者表示他们定期参与语言设计工作，要么通过参加电话会议、论坛讨论，要么通过在 GitHub 上提出新功能或语言更改。
- 18.5% 的受访者明确表示他们不参与的原因是缺乏兴趣，或者参与这些工作需要具备的技能。
在 Solidity，我们已经并希望继续让我们的社区更容易更积极地参与这些讨论，并让他们有能力为语言设计决策做出贡献。
Solidity 开发人员社区
保持最新
与往年略有不同的是，今年大多数人表示他们喜欢通过关注 Solidity GitHub 版本页面 来了解 Solidity 版本、安全警报和公告，其次是 Solidity 的 Twitter 或 Mastodon。
另一个经常被提及的信息来源是 Solidity 博客。
有趣的是，大约 21.2% 的受访者声称他们没有做上述任何事情。
作为“其他”的一部分，受访者指定了几个基于社区的方式来保持最新
- “加密货币影响者”/热门 Solidity 开发人员
- Discord 服务器
- 加密货币 Twitter / 社区聊天 / Farcaster 频道
- 通讯
- 其他博客，例如 Moralis 和 OpenZeppelin
- Solidity 文档
- Solidity 网站
- YouTube 上的教程
- “本周以太坊新闻”通讯
与其他 Solidity 开发人员互动
超过一半的受访者（56.8%）与其他 Solidity 开发人员互动，而 25.7% 的受访者承认他们很少与其他 Solidity 开发人员互动。
该图表中较小的一部分（17.5%）完全不与其他 Solidity 开发人员互动。
与往年一样，作为调查的最后一部分，我们想听听有多少参与者同意或不同意关于 Solidity 社区和 Solidity 团队工作的某些陈述。
陈述 1：我在 Solidity 开发人员社区中感觉受到欢迎。
46.8% 的受访者在 Solidity 开发人员社区中感觉受到欢迎，26.1% 的受访者多少同意该陈述。几乎 5% 的受访者仍然感觉不受欢迎。
陈述 2：我对 Solidity 核心团队的工作充满信心。
大约 80% 的受访者表示同意或多少同意他们对 Solidity 团队的工作充满信心。调查受访者中一小部分（6.4%）不同意该陈述。
陈述 3：Solidity 团队了解我作为开发人员的需求。
大约 68% 的受访者表示同意或多少同意上述陈述。23.2% 的受访者不知道他们对此有什么感觉，而大约 8.8% 的受访者表示总体上不同意。
陈述 4：我对如何向 Solidity 贡献想法或反馈的选择很清楚。
调查受访者中 47% 的人同意他们对如何向团队贡献想法或反馈的选择很清楚。然而，几乎与之相当的 26% 的受访者仍然不清楚如何贡献想法或反馈。由此可以推断，这方面的沟通需要加强。
陈述 5：我从 Solidity 团队那里收到了关于在 GitHub 和/或论坛帖子中提出的问题的充分反馈。
50% 的受访者不知道他们对此陈述有什么感觉。
然而，大约 40% 的受访者对他们从 Solidity 团队那里收到的关于其贡献的反馈和意见总体上感到满意。而 10% 的受访者不同意或强烈不同意。
这个“社区和 Solidity 团队信心排名”的结果与去年的结果一致。
谢谢！
最后，我们要感谢您对所有调查的回复和反馈。我们旨在继续每年保持这一传统！
我们希望本次调查的见解能够像对我们一样，继续对 Solidity 生态系统和社区有所价值！
要了解所有与 Solidity 相关的公告和更新，请确保
- 在 Twitter 或 Mastodon 上关注 Solidity。
- 加入 Solidity 论坛 中的语言设计讨论，或在那里向我们提供反馈。
- 在 Solidity 博客 上关注公告和安全警报。
- 关注并 ⭐ GitHub 上的 Solidity 代码库。