2023年Solidity开发者调查结果

编辑说明：我们注意到 [1] 流行的以太坊特定 IDE 和 [2] Sourcify 使用情况的图形表示中存在一个小的错误。此博文和幻灯片组中相应的图形数据已更新，以准确反映代表调查数据的更正。

我们很高兴与你分享 Solidity 开发者调查 2023 的结果！在这篇博文中，我们将介绍调查各个部分的关键见解和详细分析。

在我们深入研究之前，我们要感谢所有提交调查回复以及帮助我们将调查发送给合适受众的人！你的投入对我们来说非常宝贵，并且对于推动重要的语言设计决策和改进作为开源项目的 Solidity 至关重要。

今年，我们收到了总共 474 份回复。让我们从一些有用的链接开始：

• 本着开源的精神，你可以在此处找到调查结果的所有原始数据，并在此处找到所有图表。
• 这是我们的第四次年度调查。你可以通过查看以下博文将 2023 年的结果与往年进行比较：
  • 2022
  • 2021
  • 2020

事不宜迟，让我们深入研究 2023 年的结果！

摘要 & 值得注意的见解

该调查包含 6 个部分，即：[1] 人口统计信息、[2] 开发者 & 用户画像、[3] Solidity 背景、[4] Solidity 开发者体验、[5] 语言设计和 [6] Solidity 开发者社区。

让我们看一下 2023 年调查中这些不同部分的一些关键见解和摘要。

• 人口统计信息：总共有来自 71 个不同国家的 474 位开发者参与了 2023 年的调查。回复者人数最多的是美国 (18.8%)，其次是印度 (10.5%) 和尼日利亚 (6.2%)。这与去年的见解保持一致，除了尼日利亚取代法国成为回复者人数第三多的国家。 今年，我们看到了新的非洲原生语言，如卢旺达语、斯瓦希里语、Runyankole 语和卢干达语。
• 开发者 & 用户画像：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 开发者社区：在用于及时了解 Solidity 公告的来源列表中，GitHub 版本排名上升。

人口统计信息

⚠️ 请注意，在解释有关居住国家/地区和语言偏好的分布结果时，此调查仅以英语共享。

让我们首先分析调查的第一部分，该部分涵盖有关回复者的居住地和母语/语言偏好的信息。

总共有来自 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% 的人说非洲语言。

ℹ️ 注意：孟加拉语、古吉拉特语、印地语、马拉地语、尼泊尔语、奥迪亚语、旁遮普语、泰米尔语、泰卢固语和乌尔都语被归类为“印度语言”。粤语、中文和普通话被归类为“中文”。伊博语、卢旺达语、斯瓦希里语、Runyankole 语、卢干达语、斯瓦希里语和约鲁巴语被归类为非洲语言。

有趣的是，今年卢旺达语、斯瓦希里语、Runyankole 语和卢干达语等新的非洲语言已进入调查结果。

超过一半的回复者 (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 用户画像 & 使用习惯

大多数用户 (46.5%) 每天都使用 Solidity，其次是每周使用 Solidity 的用户 (33.2%) 和每月使用 Solidity 的用户 (11.9%)。

只有 1.9% 的人表示他们从不使用 Solidity。6.5% 的用户报告说他们很少使用它。

今年，我们还想了解调查对象如何获得 Solidity 二进制文件。最常提及的来源是：

• 通过框架/IDE (38.8%)
• 使用 npm (18.6%)
• GitHub 版本 (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%。在从 2021 年的 1.6% 上升到 2022 年的 30% 之后，Foundry 的使用率似乎与去年持平。

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 的更多信息。尝试过它的用户百分比今年显着增加。

via-IR Compilation Pipeline

51.9% 的人不知道 via-IR 是什么。这个数字比去年显着减少。25.9% 的人已经在使用 via-IR Pipeline。在接下来的几周内，我们打算撰写一篇博文，介绍什么是 via-IR 以及为什么你应该从传统的 Compilation Pipeline 切换到 via-IR。

当被问及使用 via-IR Pipeline 编译合约代码所需的时间时，大多数回复者表示这需要 1 到 10 分钟。

一些用户还报告说，这也可能需要 15 分钟到 60 分钟不等。

回复中的一些异常值也表明长达 300 分钟和 200000 分钟。但是，我们认为这些回复是不准确的，因此，图表没有考虑这些回复。

当被问及用户最担心使用 via-IR 的是什么时，27.4% 的人表示是编译时间，21.4% 的人表示知识不足，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.dev。

appendCBOR: false 或 bytecodeHash: none

55% 的用户不知道 appendCBOR: false 或 bytecodeHash: none 是什么，而 30.8% 的人知道但不需要它。只有大约 13.7% 的人经常或有时使用它。

扁平化合约

53.9% 的回复者不扁平化他们的合约，而 22.5% 的人这样做。23.6% 的人不知道那是什么或如何做。

大多数扁平化合约的用户提到他们这样做是为了验证。

其他 EVM 网络

超过一半的回复者 (65.1%) 在 以太坊主网 和 Testnet 之外使用 Solidity。

当被问及他们在哪些其他网络上部署智能合约时，20.8% 的人回答为 Polygon（以前称为 Matic Network）。

其他经常被提及的区块链包括 Arbitrum (15.6%)、Optimism (13.2%)、Binance Smart Chain (10.6%) 和 Avalanche (8.1%)。

其他智能合约语言

Yul，Solidity 的一种中间语言，仍然是除 Solidity 之外使用最多的智能合约语言，有 23.9% 的回复者使用；与去年相比略有增加。

Vyper，一种 Pythonic EVM 语言，是除 Solidity 之外使用第二多的语言，占 11.9%。

到目前为止，这种趋势与去年相似，只是百分比略有增加。

Huff (9.3%)、Cairo (5.8%) 和 Sway (2.1%) 连续第二年进入列表。

Fe (1.8%) 今年也再次进入图表。但是，Rust 没有经常被提及。

Solidity 开发者体验

在调查的下一部分中，我们将介绍我们用户社区的开发者体验。

当被问及 Solidity 开发者体验的总体改进情况时，76% 的回复者普遍认为它在过去一年有所改进，其中 20.2% 的人甚至认为这是一个很大的改进。

只有 1.6% 的回复者认为开发者体验变得更糟。

经常出现的问题

当被问及参与者是否遇到经常出现的问题时，53.3% 的回复者表示，他们在 Solidity 开发过程中不会多次遇到相同或类似的问题。

在遇到经常出现的问题的 46.7% 的人中，Stack Too Deep 问题是最常遇到的问题，其次是 Bytecode Size Limit 和 Debugging 问题。

_ℹ️ 注意：关于调试问题，我们想提醒你注意 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%) 和使用 for (2.5%) 是他们最喜欢的特性。

当我们询问参与者 Solidity 最大的痛点是什么时，Stack Too Deep 错误以 42% 的选票排名最高，其次是缺少内存优化 (21.6%) 和编译器性能 (13%)。

8.6% 的回复者表示冗余检查（例如，在 checked 算术中）是他们最大的问题。

几乎 11% 的人选择了“其他”并指出了他们最重要的一些痛点，即：字节码和合约大小限制以及错误。

文档

当被问及参与者是否发现官方文档有用时，68% 的调查回复者报告说 Solidity 文档有用，其次是 29.1% 的人认为它在某种程度上有用。

只有 2.9% 的人投票表示他们根本没有发现文档有用。

改进的想法最突出地要求更多的代码示例，但也要求更好地概述语法、更好的文档内搜索以及总体上更好的 UI/UX。

高影响编译器错误

我们很好奇 Solidity 开发者是否受到了任何高影响的编译器漏洞的影响（codegen 漏洞会在 Solidity 博客上通过安全警报宣布）。

虽然 95.7% 的人表示他们没有受到影响，但 4.3% 的人声称他们受到了影响。

当被问及他们受到哪个漏洞的影响时，以下是我们发现的：

（仔细检查报告的漏洞是否真实，并据此列出）

外部库

大多数调查受访者 (47.8%) 根本不使用外部库。

然而，42.7% 的人报告说他们使用它，并指定了诸如合约拆分、代理模式和共享代码等用例。

只有 9.5% 的用户不知道外部库是什么（或它们用于什么）。

语言设计 & 即将到来的特性

在调查的以下部分，我们将带你了解我们从询问参与者关于他们对 Solidity 语言设计更新和工作的想法和参与中所获得的见解。

最受期待的特性

23.2% 的受访者表示他们最期待的特性是支持泛型，其次是 17.4% 的人表示他们最期待的是带有自定义错误类型的 Require 特性。

⚠️ 注意： 与往年类似，我们将 "floats"、"floating point arithmetic"、"floating point number"、"fixed point numbers" 和 "fixed point math" 等术语的使用归类为 "decimal numbers"。

其他最受期待的特性按降序排列：

• 瞬态存储 (13%)
• 解决 stack-too-deep 错误 (11.6%)
• 更好的 gas 优化和调试工具 (10.1%)
• 支持十进制数和动态内存数组 (7.2%)

限制性

当我们询问调查参与者对语言限制性的看法时，44.7% 的受访者希望 Solidity 保持“原样”。

大约 35.6% 的人通常更喜欢更严格/更明确的行为，而大约 19.6% 的人希望 Solidity 不那么严格。

这个问题的总体结果与去年和今年的结果相当。

关于新特性/改进的反馈

我们询问了参与者对 Solidity 中的后缀类型和函数式元素的看法。

以下是我们发现的关于：

1. 后缀类型： 虽然 72.5% 的受访者明确表示他们要么不喜欢后缀类型，要么不在乎，但 27.5% 的人表示他们喜欢。

2. 函数式元素： 近 60% 的用户表示他们喜欢在 Solidity 中使用更多函数式元素（如 Lamda 函数）的想法。15.4% 的人表示他们不喜欢，24.7% 的人对此漠不关心。

EIP 支持

我们还想知道调查受访者了解或期待使用哪些与 Solidity 相关的 EIP 以及原因。

让我们看看关于以下内容的一些有用的见解：

1. EIP-1153 “瞬态存储”： 40.1% 的受访者知道瞬态存储 EIP，而 59.9% 的人不知道。40.4% 的人表示他们需要在瞬态存储中使用复杂类型，例如映射和数组，其余的受众在不需要复杂类型和对此漠不关心/不知道之间平分秋色。

2. EIP-3540 “EOF - EVM 对象格式”： 很有趣的是，只有 28.6% 的受访者知道 EOF。在 28.6% 中，63.5% 的人对此持积极态度，只有 4.8% 的人认为它会对他们作为开发者产生负面影响。

与语言设计相关的工作

当被问及受访者是否参与或继续参与语言设计工作时，以下是我们发现的：

• 几乎 86% 的受访者表示他们不参与，因为他们要么太忙，要么不感兴趣/不合格，要么不知道如何参与。
• 大约 14.2% 的受访者表示，他们通过参加电话会议、论坛讨论或在 GitHub 上提出新特性或语言更改来定期参与语言设计工作。
• 18.5% 的人特别提到，他们缺乏参与的原因是缺乏参与这些工作所需的兴趣或技能。

在 Solidity，我们已经并将继续努力使我们的社区更容易更积极地参与这些讨论，并感到有足够的能力为语言设计决策做出贡献。

Solidity 开发者社区

保持最新

与往年略有不同的趋势是，今年大多数人表示，他们喜欢通过关注 Solidity GitHub Releases page 来了解 Solidity 版本、安全警报和公告，其次是 Solidity Twitter 或 Mastodon。

另一个经常提到的信息来源是 Solidity 博客。

有趣的是，大约 21.2% 的人声称没有做以上任何事情。

作为“其他”的一部分，受访者指定了几个基于社区的保持最新状态的方式：

• "加密货币影响者" / 受欢迎的 Solidity 开发者
• Discord 服务器
• Google
• 加密货币 Twitter / 社区聊天 / Farcaster 频道
• 新闻通讯
• 其他博客，如 Moralis 和 OpenZeppelin
• Solidity 文档
• Solidity 网站
• YouTube 上的教程
• Reddit
• "以太坊新闻周报" 新闻通讯

与其他 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 repo。

• • *

所有图表都可以在这里找到。原始和分析的数据可以在这里找到。

• 原文链接： soliditylang.org/blog/20...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～