Рабочая группа Enterprise Ethereum Alliance Mainnet создала опрос, чтобы узнать мнение корпоративных разработчиков, работающих над приложениями Ethereum. Опрос распространялся по электронной почте в списках рассылки ЕЭЗ и в Твиттере с ноября 2020 года по январь 2021 года. Вот сводка результатов и ответы на ключевые вопросы.

• Было 42 респондента.
• 73 % респондентов считают себя разработчиком корпоративного программного обеспечения или архитектором, работающим над приложениями Ethereum. Предположительно, остальные — разработчики, которые не ассоциируются с термином "предприятие".
• 72 % респондентов работают с Ethereum Mainnet; 74% работают с частными сетями; 51 % используют и то, и другое.

Примечательные ответы на вопрос «Что, по вашему мнению, больше всего нуждается в улучшении и каким образом?»

• У Solidity должны быть готовые примеры цепочки поставок, DeFi и других приложений.
• Надежность:используйте идентификацию в сети, ZKP и гомоморфное шифрование для активов безопасности, соответствующих нормативным требованиям.
• Solidity:у нас должен быть веб-поток, подобный программному обеспечению.
• Отслеживание транзакций и отладчик Solidity
• [Обновите] Web3js с помощью функций Solidity
• Что-то вроде веб-флоу
• Стабильность [] трюфельного ганаша
• Truffle, чтобы скомпилировать каждый файл с другой версией компилятора, лучше использовать плагин отладчика VSCode.
• Настройка сети, например, запуск N узлов с базовой настройкой конфиденциальности, разрешения — Besu работает над этим, но нуждается в доработке, чтобы стать отличным решением для предприятий.
• Ремикс, который так широко используется, но на него так мало ресурсов
• Разработка смарт-контрактов для детей (аналог Scratch Studio)
• Web3j, плохое обслуживание
• На данный момент моей проблемой является полная поддержка abi2 в Web3j.
• [Поддержка] Rust
• #транзакций в секунду
• Нет, но оптимистичные сводки для выполнения контрактов на L2 необходимы
• Поддержка оболочек nodejs для evms на основе кворума.
• Инструменты документирования нуждаются в улучшении. Было бы неплохо интегрироваться в один из основных инструментов для создания документации.
• Интеграция с браузером IPFS
• IPFS или любое другое готовое решение для хранения данных корпоративного уровня
• IPFS:защищенный доступ; все остальное - ОТДЫХ…
• Совместимость между различными блокчейнами
• Калейдо

Примечательные ответы на вопрос «Какие инструменты, библиотеки или службы, по вашему мнению, отсутствуют и должны существовать?»

• Упрощение/автоматизация создания API на основе смарт-контрактов
• Основной «производитель» REST-API для смарт-контрактов
• [Инструменты] регрессионного тестирования, профилирования, формальной проверки
• Хорошие средства отладки в Java-приложении и надежность — это было бы здорово
• Хороший визуальный отладчик
• Библиотеки подписывающих устройств для хранилищ ключей, таких как Key Vault, KMS и HSM.
• Webflow, инструменты второго уровня для разработки
• web3j или любой другой web3 должен иметь отдельные API для управления а) созданием транзакции, б) подписанием транзакции через web3 или независимо и в) отправкой транзакции в нужную сеть.
• Библиотеки развертывания и гибридная разработка (общедоступная тестовая сеть/локальная — с проксированием, которое сохраняется при перекомпиляции).
• MetaMask… полезен, но ему нужна дополнительная поддержка для разработчиков, т. е. локальные сети RPC.
• Библиотеки JS для evm on quorum
• Компоненты пользовательского интерфейса
• Библиотеки взаимодействия для подключения к другим сетям блокчейна
• Центральная библиотека смарт-контрактов с открытым исходным кодом и их подробная документация.
• Работа с децентрализованными организациями
• Клиент на основе Rust
• Токенскрипт

Примечательные ответы на вопрос «Какие стандарты, по вашему мнению, отсутствуют или должны быть улучшены?»

• Защищенные/конфиденциальные токены, например Aztec и Anonymous Zether.
• Совместимость между внешними источниками
• Передовые практики:экономика непривязанных стейблкоинов и служебных токенов, работа с реальными программными продуктами на основе Ethereum (аспекты бизнеса и разработки)
• Конфиденциальность
• Стандарты безопасности
• шифрование в сети
• Альтернативы IPFS, совместимость
• Документально подтвержденные денежные вознаграждения за раскрытие информации о безопасности.
• Сначала REST-API
• Обмен сообщениями
• Знай своего клиента
• Поддержка DID/SSI в качестве базового уровня для интеграции приложений для идентификации человека, компании и машины
• Улучшенные стандарты NatSpec:https://github.com/ethereum/solidity/issues/10825

Примечательные ответы на вопрос «С какими еще проблемами, связанными с Ethereum, вы сталкиваетесь как разработчик?»

• Высокая плата за газ
• Цена на газ
• Цена на газ
• Изменения:высокая стоимость газа в публичном блокчейне
• Масштабируемость Эфириума 1
• Масштабируемость
• Конфиденциальность
• Тестирование безопасности
• Знай своего клиента
• Автоматизация CI/CD — не привязана к платформе (например, Infura и т. д.)
• Управление одноразовыми номерами для отказоустойчивых архитектур.
• Изменения версии Solidity
• В будущем Solidity предложит множество улучшений для управления датами и структурой.
• Стандарт медленного развертывания/отладки в тестовой сети
• Плохая документация, продукты, которые не работают должным образом
• Обновленные учебные ресурсы
• Инструментам Java просто не хватает зрелости. по-прежнему приходится много копировать и вставлять для развертывания контрактов, когда вы делаете непростые вещи, например, развертывание контракта Solidity В файле генезиса С хранилищем
• Надежность. RPC не так надежны с точки зрения предприятия. Нужны дополнительные функции для усиления RPC или использования MQ с открытым исходным кодом для обмена сообщениями.
• Общение с другими разработчиками. Нужна сеть.
• BFT, частные транзакции
• Проблемы с взаимодействием в открытом Ethereum
• Создание экономической системы вокруг децентрализованного приложения, которое максимизирует сетевой эффект, чтобы предотвратить создание форка проекта и снижение дохода от протокола или необходимость разработки проектов с закрытым исходным кодом.

Выводы

Было сделано несколько предложений по улучшению экосистемы средств разработки. Из-за относительно небольшого размера выборки не выявлено крупных кластеров или тенденций (кроме цены на газ/масштабируемости). Возможно, будет полезно повторить опрос через несколько месяцев.

Несколько респондентов упомянули высокие комиссии за транзакции и масштабируемость в качестве проблем. Это говорит о необходимости информировать разработчиков о технологиях уровня 2, предназначенных для решения этих проблем.