Enterprise Ethereum Alliance Mainnet Working Group oprettede en undersøgelse for at indhente input fra virksomhedsudviklere, der arbejder med Ethereum-applikationer. Undersøgelsen blev promoveret via e-mail til EØS-mailinglister og på Twitter fra november 2020 til januar 2021. Her er en oversigt over resultaterne og svar på nøglespørgsmål.

• Der var 42 respondenter.
• 73 % af respondenterne identificerer sig som en virksomhedssoftwareudvikler eller arkitekt, der arbejder på Ethereum-applikationer. Formentlig er de andre udviklere, der ikke forbinder med udtrykket "virksomhed."
• 72 % af respondenterne arbejder med Ethereum Mainnet; 74 % arbejder med private kæder; 51 % arbejder med begge dele.

Bemærkelsesværdige svar på "Hvilke af disse mener du har størst behov for forbedringer, og på hvilke måder?"

• Soliditet bør have færdige eksempler på forsyningskæde og DeFi og andre applikationer
• Soliditet:Bring on-chain identitet, ZKP og Homomorphic Encryption for at være nyttigt for lovoverensstemmende sikkerhedsaktiver
• Soliditet:Vi bør have et webflow som software
• Transaktionssporing og Solidity debugger
• [Bring] Web3js opdateret med solide funktioner
• Noget som webflow
• Stabilitet [af] Trøffelganache
• Truffle, for at kompilere hver fil med forskellige kompileringsversioner, VSCode better debugger plugin.
• Netværksopsætning, f.eks. start N noder med grundlæggende opsætning til privatliv, tilladelser – Besu arbejder på det, men skal forbedres for at være fantastisk for virksomheder
• Remix, så udbredt og alligevel har så få ressourcer dedikeret til det
• Smart kontraktkodning for børn (svarende til Scratch Studio)
• Web3j, ikke godt vedligeholdt
• Mit nuværende smertepunkt er komplet abi2-support i Web3j
• [Støtte til] Rust
• #tx/sek
• Ingen, men optimistiske rollups for at udføre kontrakter på L2 er afgørende
• Understøttelse af nodejs-indpakninger til kvorumbaserede evms
• Dokumentationsværktøjerne skal forbedres. Integration i et af de store dokumentationsgenererende værktøjer ville være rart
• IPFS-browserintegration
• IPFS eller enhver anden produktionsklar lagerløsning i virksomhedskvalitet
• IPFS:Beskyttet adgang; alt det andet er HVILE...
• Interoperabilitet mellem forskellige Blockchains
• Kaleido

Bemærkelsesværdige svar på "Hvilke værktøjer eller biblioteker eller tjenester mener du mangler og burde eksistere?"

• Let/automatiser opbygning af API oven på smarte kontrakter
• Generel REST-API "producent" for Smart-kontrakter
• [Værktøjer til] regressionstestning, profilering, formel verifikation
• Gode fejlfindingsfaciliteter på tværs af java-applikationer og soliditet ville være fantastisk
• En god visuel debugger
• Underskriverbiblioteker for nøglebutikker som Key Vault, KMS og HSM'er
• Webflow, 2. lags værktøjer til udvikling
• web3j eller en hvilken som helst web3 skal have separate API'er til at administrere a) oprette en transaktion, b) underskrive en transaktion via web3 eller uafhængigt og c) sende transaktionen til det ønskede netværk.
• Implementeringsbiblioteker og hybridudvikling (offentligt testnet/lokalt – proxy, som overlever genkompilering).
• MetaMask … er nyttig, men kunne klare sig med mere støtte til udviklere, dvs. lokale RPC-netværk
• JS-biblioteker for evm'er på quorum
• UI-komponenter
• Interoperabilitetsbiblioteker til at udføre forbindelser til andre blockchain-netværk
• Centralt open source-bibliotek med smarte kontrakter og deres detaljerede dokumentation.
• Håndtering af decentrale organisationer
• Rustbaseret klient
• TokenScript

Bemærkelsesværdige svar på "Hvilke standarder mener du mangler eller bør forbedres?"

• Beskyttede/fortrolige tokens, f.eks. Aztec og Anonymous Zether.
• Interoperabilitet mellem kilder uden for kæden
• Bedste praksis for:ikke-tilknyttede Stablecoin og Utility token-økonomi, håndtering af rigtige softwareprodukter baseret på Ethereum (forretnings- og udviklingsaspekter)
• Privatliv
• Sikkerhedsstandarder
• kryptering i kæden
• Ipfs-alternativer, interoperabilitet
• Dokumenterede tilsagn om kontante dusører for sikkerhedsoplysninger
• REST-API først
• Beskeder
• KYC
• DID/SSI-understøttelse som basislag for applikationsintegrationer til menneske-, virksomheds- og maskinidentiteter
• Bedre NatSpec-standarder:https://github.com/ethereum/solidity/issues/10825

Bemærkelsesværdige svar på "Hvilke andre Ethereum-relaterede udfordringer står du over for som udvikler?"

• Høje gasgebyrer
• Gaspris
• Gaspris
• Forandring – høje gasomkostninger på offentlig blockchain
• Ethereum 1-skalerbarhed
• Skalerbarhed
• Privatliv
• Sikkerhedstest
• KYC
• CI/CD-Automation – ikke platformbundet (f.eks. Infura osv.)
• Ikke-administration for modstandsdygtige arkitekturer
• Solidity-versionændringer
• Solidity har mange forbedringer at tilbyde i fremtiden til dato- og strukturstyring
• Langsom testnetimplementering/debug-standard
• Dårlig dokumentation, produkter, der ikke fungerer som forventet
• Læringsressourcer, der er opdaterede
• Der er bare ikke den modenhed, der er med Java-værktøjer. der er stadig en masse kopiering og indsættelse for at implementere kontrakter, når du først laver ikke-simple ting, f.eks. implementerer en solidity-kontrakt I genesis-filen MED lager
• Plidelighed:RPC'er er ikke så pålidelige fra et virksomhedssynspunkt. Brug for flere funktioner til at styrke RPC eller bruge open source MQ'er til meddelelser
• Kommunikation med andre udviklere. Har brug for et netværk.
• Bft, private transaktioner
• Problemer med interaktioner i åben Ethereum
• Opbygning af et økonomisk system omkring en decentral applikation, der maksimerer netværkseffekterne for at forhindre, at nogen forkaster projektet og reducerer protokolindtægter eller har behov for at udvikle lukkede kildeprojekter

Konklusioner

Der blev fremsat flere forslag til forbedringer af udviklingsværktøjets økosystem. På grund af den relativt lille stikprøvestørrelse er der ingen større klynger eller tendenser identificeret (bortset fra gaspris/skalerbarhed). Det kan være nyttigt at gentage undersøgelsen om et par måneder.

Høje transaktionsgebyrer og skalerbarhed blev nævnt som udfordringer af flere respondenter. Dette tyder på et behov for at uddanne udviklere om Layer 2-teknologier, som er beregnet til at løse disse problemer.