Enterprise Ethereum Alliance Mainnet Working Group skapade en undersökning för att få input från företagsutvecklare som arbetar med Ethereum-applikationer. Undersökningen marknadsfördes via e-post till EES-postlistor och på Twitter från november 2020 till januari 2021. Här är en sammanfattning av resultaten och svaren på nyckelfrågor.

• Det var 42 svarande.
• 73 % av de tillfrågade identifierar sig som en företagsprogramvaruutvecklare eller arkitekt som arbetar med Ethereum-applikationer. Förmodligen är de andra utvecklare som inte associerar med termen "företag."
• 72 % av de tillfrågade arbetar med Ethereum Mainnet; 74 % arbetar med privata kedjor; 51 % arbetar med båda.

Anmärkningsvärda svar på "Vilka av dessa tror du är mest i behov av förbättringar och på vilka sätt?"

• Solidity bör ha färdiga exempel på försörjningskedjan och DeFi och andra applikationer
• Soliditet:ta med identitet i kedjan, ZKP och homomorfisk kryptering för att vara användbar för säkerhetstillgångar som följer reglerna
• Soliditet:Vi bör ha ett webbflöde som mjukvara
• Transaktionsspårning och Solidity-felsökning
• [Uppdatera] Web3js med soliditetsfunktioner
• Något som webbflöde
• Stabilitet [av] tryffelganache
• Tryffel, för att kompilera varje fil med olika kompilatorversioner, VSCode better debugger plugin.
• Nätverksinställningar, t.ex. starta N noder med grundläggande inställningar för integritet, tillstånd – Besu arbetar med det men behöver förbättras för att vara fantastiskt för företag
• Remix, så flitigt använt och ändå har så lite resurser dedikerade till det
• Smart avtalskodning för barn (liknande Scratch Studio)
• Web3j, inte väl underhållen
• Min nuvarande smärtpunkt är komplett abi2-stöd i Web3j
• [Stöd för] Rust
• #tx/sek
• Inga, men optimistiska sammanställningar för att verkställa kontrakt på L2 är avgörande
• Stöd för nodejs wrappers för kvorumbaserade evms
• Dokumentationsverktygen behöver förbättras. Integrering i ett av de stora verktygen för att generera dokumentation skulle vara trevligt
• IPFS webbläsarintegration
• IPFS, eller någon annan produktionsklar lagringslösning av företagsklass
• IPFS:Skyddad åtkomst; allt annat är VILA...
• Interoperabilitet mellan olika blockkedjor
• Kaleido

Anmärkningsvärda svar på "Vilka verktyg eller bibliotek eller tjänster tror du saknas och borde finnas?"

• Lätt/automatisera att bygga API utöver smarta kontrakt
• Allmän REST-API "producent" för smarta kontrakt
• [Verktyg för] regressionstestning, profilering, formell verifiering
• Bra felsökningsmöjligheter för Java-applikationer och soliditet skulle vara bra
• En bra visuell debugger
• Undertecknarbibliotek för nyckelbutiker som Key Vault, KMS och HSMs
• Webflow, andra lagerverktyg för utveckling
• web3j eller någon web3 bör ha separata API:er för att hantera a) skapa en transaktion, b) signera en transaktion av web3 eller oberoende och c) skicka transaktionen till det önskade nätverket.
• Utsättningsbibliotek och hybridutveckling (offentligt testnät/lokalt – fullmakt som överlever omkompileringar).
• MetaMask … är användbar men skulle kunna ha mer stöd för utvecklare, dvs. lokala RPC-nätverk
• JS-bibliotek för evm's på kvorum
• UI-komponenter
• Interoperabilitetsbibliotek för att utföra anslutningar till andra blockkedjenätverk
• Centralt bibliotek med öppen källkod med smarta kontrakt och deras detaljerade dokumentation.
• Hantera decentraliserade organisationer
• Rostbaserad klient
• TokenScript

Anmärkningsvärda svar på "Vilka standarder anser du saknas eller bör förbättras?"

• Skärmade/konfidentiella tokens, t.ex. Aztec och Anonymous Zether.
• Interoperabilitet mellan källor utanför kedjan
• Bästa metoder för:icke-kopplad Stablecoin och Utility-tokenekonomi, hantering av riktiga mjukvaruprodukter baserade på Ethereum (affärs- och utvecklingsaspekter)
• Sekretess
• Säkerhetsstandarder
• kryptering i kedjan
• Ipfs-alternativ, interoperabilitet
• Dokumenterade utfästelser om kontantbelöningar för säkerhetsavslöjande
• REST-API först
• Meddelanden
• KYC
• DID/SSI-stöd som baslager för applikationsintegrationer för mänskliga, företags- och maskinidentiteter
• Bättre NatSpec-standarder:https://github.com/ethereum/solidity/issues/10825

Anmärkningsvärda svar på "Vilka andra Ethereum-relaterade utmaningar möter du som utvecklare?"

• Höga bensinavgifter
• Gaspris
• Gaspris
• Förändring – hög gaskostnad på offentlig blockchain
• Ethereum 1 skalbarhet
• Skalbarhet
• Sekretess
• Säkerhetstestning
• KYC
• CI/CD-Automation – inte plattformsbunden (t.ex. Infura etc.)
• Icke-hantering för motståndskraftiga arkitekturer
• Solidity-versionsändringar
• Solidity har många förbättringar att erbjuda i framtiden för hantering av datum och struktur
• Långsam testnätdistribution/felsökningsstandard
• Dålig dokumentation, produkter som inte fungerar som förväntat
• Lärande resurser som är uppdaterade
• Det finns helt enkelt inte den mognad som det finns med Java-verktyg. det återstår fortfarande mycket kopiering och inklistring för att distribuera kontrakt när du väl gör icke-enkla saker, t.ex. distribuerar ett solidity-kontrakt I genesis-filen MED lagring
• Tillförlitlighet:RPC:er är inte så tillförlitliga ur företagssynpunkt. Behöver fler funktioner för att stärka RPC eller använda MQ:er med öppen källkod för meddelanden
• Kommunikation med andra utvecklare. Behöver ett nätverk.
• Bft, privata transaktioner
• Problem med interaktioner i öppna Ethereum
• Bygga ett ekonomiskt system kring en decentraliserad applikation som maximerar nätverkseffekterna för att förhindra att någon förkastar projektet och minskar protokollintäkter eller behöver utveckla projekt med sluten källkod

Slutsatser

Flera förslag på förbättringar av utvecklingsverktygets ekosystem lades fram. På grund av den relativt lilla urvalsstorleken finns inga större kluster eller trender identifierade (bortsett från gaspris/skalbarhet). Det kan vara användbart att upprepa undersökningen om några månader.

Höga transaktionsavgifter och skalbarhet nämndes som utmaningar av flera respondenter. Detta tyder på ett behov av att utbilda utvecklare om Layer 2-teknologier som är avsedda att lösa dessa problem.