EEA Ethereum development tool survey results


The Enterprise Ethereum Alliance Mainnet Working Group created a survey to solicit input from enterprise developers working on Ethereum applications. The survey was promoted via email on EEA mailing lists and on Twitter, from November 2020 to January 2021. Here is a summary of the findings and answers to key questions.

  • There were 42 respondents.
  • 73% of respondents identify as a developer or architect of enterprise software working on Ethereum applications. Presumably, the rest are developers who do not associate with the term “business”.
  • 72% of respondents work with Ethereum Mainnet; 74% work with private channels; 51% work with both.

Notable responses to “Which of these most in need of improvement, and how? “

  • Solidity should have ready-made examples of supply chain and DeFi and other applications
  • Robust: Bring on-chain identity, ZKP and homomorphic encryption to be useful for regulatory-compliant security assets
  • Robustness: we should have a webflow like software
  • Solidity Transaction Tracing and Debugger
  • [Bring] Up-to-date web3js with robust features
  • Something like webflow
  • Stability [of] Truffle Ganache
  • Truffle, to compile each file with a different compiler version, a better VSCode debugging plugin.
  • Network setup eg start N nodes with basic setup for privacy, permissions – Besu is working on it but needs to be improved to be great for business
  • Remix, so widely used and yet with so few resources dedicated to it
  • Smart contract coding for kids (similar to Scratch Studio)
  • Web3j, not well maintained
  • My current issue is full abi2 support in Web3j
  • [Support for] Rust
  • # tx / s
  • None, but optimistic stacks to execute contracts on L2 are essential
  • Support for nodejs wrappers for quorum based evms
  • Documentation tools need to be improved. Integration into one of the main documentation generation tools would be nice
  • IPFS browser integration
  • IPFS, or any other enterprise-grade storage solution, ready for production
  • IPFS: protected access; everything else is REST …
  • Interoperability between the different Blockchains
  • Kaleido

Notable responses to “What tools, libraries or services are missing and should exist?” “

  • Facilitate / automate API creation in addition to smart contracts
  • General REST-API “producer” for smart contracts
  • [Tools for] regression testing, profiling, formal verification
  • Good debugging facilities through Java application and solidity would be great
  • A good visual debugger
  • Signer libraries for keystores like Key Vault, KMS, and HSM
  • Webflow, 2nd layer tools for development
  • web3j or any web3 should have separate APIs to handle a) create a transaction, b) sign a transaction through web3 or independently, and c) submit the transaction to the desired network.
  • Deployment and hybrid development libraries (public / local testnet – proxy that survives recompilations).
  • MetaMask… is useful but could be better supported by developers, ie local RPC networks
  • JS libraries for quorum evm
  • User interface components
  • Interoperability libraries for making connections to other blockchain networks
  • Central open source library of smart contracts and their detailed documentation.
  • Management of decentralized organizations
  • Rust Based Client
  • Token script

Notable responses to “What standards do you think are missing or should be improved?”

  • Protected / confidential tokens, eg Aztec and Anonymous Zether.
  • Interoperability between off-chain sources
  • Best practices for: economics of stable tokens and unbound utility tokens, management of real Ethereum-based software products (business and development aspects)
  • Privacy
  • Safety standards
  • chain encryption
  • Ipfs alternatives, interoperability
  • Documented cash bonus commitments for safety disclosures
  • REST-API first
  • Messaging
  • key
  • DID / SSI support as a base layer for application integrations for human, enterprise and machine identities
  • Best NatSpec standards:

Notable Answers to “What other Ethereum-related challenges are you facing as a developer?” “

  • High gas costs
  • Gas prices
  • Gas prices
  • Change – high cost of gas on the public blockchain
  • Ethereum 1 Scalability
  • Scalability
  • Privacy
  • Security tests
  • key
  • CI / CD-Automation – unrelated to the platform (e.g. Infura, etc.)
  • Nonce management for resilient architectures
  • Solidity version changes
  • Solidity has many improvements to offer in the future for date and structure management.
  • Slow testnet deployment / debugging standard
  • Poor documentation, products that do not perform as expected
  • Up-to-date learning resources
  • There just isn’t the maturity that there is with Java tools. there is still a lot of copy and paste to deploy contracts once you do non-simple things eg deploy solidity contract IN genesis file WITH storage
  • Reliability: RPCs are not very reliable from a business perspective. Need more functionality to harden RPC or use open source MQs for messaging
  • Communications with other developers. Need a network.
  • Bft, private transactions
  • Problems with interactions in open Ethereum
  • Build an economic system around a decentralized application that maximizes network effects in order to prevent someone from forking the project and decreasing protocol revenue or having to develop closed source projects


Several suggestions for improving the development tools ecosystem were made. Due to the relatively small sample size, there are no major clusters or trends identified (other than gas price / scalability). It may be useful to repeat the survey in a few months.

High transaction costs and scalability were mentioned as challenges by several respondents. This suggests a need to educate developers on Layer 2 technologies that are intended to address these issues.


Source Link