Follow Us
Facebooktwitteryoutube
YouTube
Promo
banner
Promo
banner

30 технических факторов блокчейн-платформы

блог 1НовостиДля разработчиковПредприятиеБлокчейн РазъяснениеМероприятия и конференцииПрессаИнформационные бюллетени

Подписывайтесь на нашу новостную рассылку.

Адрес электронной почты

Мы уважаем вашу конфиденциальность

ГлавнаяБлогБлокчейн для предприятий

30 технических факторов блокчейн-платформы

Ключевые технические аспекты, которые следует учитывать при выборе платформы блокчейна для вашего бизнес-варианта использования. Клеменс Ван, 5 марта 2020 г.Опубликовано 5 марта 2020 г.

2

Клеменс Ван – архитектор решений в ConsenSys. Он составляет списки из 30 seelemons.com..

Если ваш выбор платформы блокчейн меньше связан с бизнес-факторами (см. 30 бизнес-факторов платформы блокчейн), то, возможно, вы изучаете некоторые технические аспекты для вашего варианта использования. Этот список из 30 включает вопросы, связанные с блокчейном, которые должны быть главными при проверке платформы..

DevOps / Сеть / Развертывание / Протокол

  1. Гибкость развертывания на уровне блокчейна – Есть ли у платформы публичный экземпляр? Разрешено? Частный? Гибридный?
  2. Оптимальное количество узлов – Сколько узлов нужно для поддержки сети? По одному на каждого участника? Могу ли я взаимодействовать с сетью без запуска узла?
  3. Контейнеризация – Можно ли докеризовать платформу и развернуть ее через Kubernetes?
  4. Уровень управления сетевой идентичностью – Как управляются разрешения для узлов и отдельных лиц? Есть ли ограничения для суперпользователей? Есть ли исходная сетевая карта всех сторон в сети (например, DNS-подобный сервис – ENS в Ethereum)?
  5. Механизм консенсуса – Основана ли система на Proof of Work? Доказательство ставки? Подтверждение полномочий? Доказательство прошедшего времени? Вероятно, это решается настройкой управления и сущностями в зависимости от того, что наиболее эффективно для вашего варианта использования..
  6. Обмен сообщениями между организациями – Есть ли отдельные уровни для личных сообщений? Это на основе AMQP? RabbitMQ? XMPP? Безопасный Скаттлбатт?
  7. Методология обработки транзакций – Какой порядок действий происходит при обработке транзакций? Когда протокол упорядочивает, проверяет и выполняет транзакции? В Ethereum TX отправляются на проверяющие узлы, которые заказывают / проверяют перед выполнением и распространением «правильного» блока. В Corda TX проверяются индивидуально из-за необходимости знать узлы через Flow Framework, пока они не будут подписаны и распространены нотариусом..
  8. Криптография – Какие библиотеки используются и поддерживаются хешами и подписями? (например, secp256k1 для Ethereum)
  9. Возможность подключения криптографии – Могут ли определенные узлы использовать другую криптографическую библиотеку в зависимости от своих региональных правил безопасности? (например, соответствие NIST)
  10. Методы обмена файлами – Каждый цифровой актив должен быть каким-то образом юридически закреплен через организацию, хранящую его, или юридический документ / прозу, на которые есть ссылка в коде. Как файлы обмениваются между организациями с помощью платформы? Сохраняются ли они на одной платформе? Они аналогичным образом поддерживаются?
  11. Юридическая привязка – Есть ли в протоколе встроенная юридическая проза или реализация юридических документов (например, OpenLaw)?
  12. Защита от несанкционированного доступа или защита от несанкционированного доступа – Может ли кто-нибудь изменить состояние вашего локального узла и его историю? Если каким-то образом транзакция или состояние будут удалены, приведет ли это к рассинхронизации всего? Могут ли указанные исторические данные быть изменены или удалены и согласованы всеми сторонами?
  13. Восстановление транзакции – Как узел восстанавливает транзакции? Если ваши транзакции не полностью распределены между всеми сторонами, то каковы механизмы загрузки последней согласованной версии??
  14. Возможности DAO – Есть ли примеры децентрализованных приложений, которые абстрагируют ответственность за управление? Это может быть полезно для повторного использования сети для поддержки голосования и управления..

Опыт разработчика / Лучшие приложения

  1. Ответственность за приложение – О чем нужно беспокоиться при создании приложения на вершине стека (dapp)? Вам нужно разместить свой собственный узел? Вы также отвечаете за развертывание соответствующих веб-серверов и интерфейсов dapp? Как ваши пользователи будут платить за ваше приложение?
  2. Развертывание слоя Dapp – На основании разрешений, как смарт-контракты развертываются в сети? Физическим лицом (например, адрес из белого списка)? Узлом (например, идентификатором LEI)? Зарегистрированным лицом (например, бизнес-сеть, добавленная в сеть)? Поставщиком инфраструктуры (например, Kaleido Marketplace)? Нужны ли вам разрешения на уровне узла для развертывания??
  3. Языки смарт-контрактов – На каком языке написан смарт-контракт? Это было проверено? Есть ли у него хорошее сообщество?
  4. Библиотеки и стандарты смарт-контрактов – Есть ли согласованные безопасные библиотеки / функции (например, OpenZeppelin), которые поддерживаются и проверяются? Существуют ли широко согласованные реализации функций, приведенных в соответствие со стандартами (например, ERC-20, ERC-721 и т. Д.)?
  5. Возможность обновления смарт-контрактов – Как обновляются приложения? Есть ли четко определенные шаблоны обновления для кода смарт-контракта??
  6. Доступ к справочным и рыночным данным – Какие доступные оракулы могут быть вызваны в сети для получения необходимой информации для выполнения инициируемого действия.?
  7. Рекомендуемое управление идентификацией физических лиц – Естественно ли, что пары открытого / закрытого ключей и адреса требуют, чтобы люди сохраняли свои собственные ключи? Или это реально при условии, что посредники будут размещать их от вашего имени и по-прежнему будут управлять учетными записями, распределенными по предпочтениям клиентов?
  8. Взаимодействие внутри приложений или сетей – Может ли децентрализованное приложение вызвать другое децентрализованное приложение? Может ли сеть / боковая цепь ссылаться на информацию из привязанной сети?

Пользовательский контроль / производительность / конфиденциальность

  1. Производительность обработки транзакций – Как быстро вы можете поставить транзакции в очередь, обработать их (партиями / блоками) и убедиться, что очередь очищена с уведомлением о «сохранении»?
  2. Масштабируемость обработки транзакций – Разработана ли система с модульным масштабированием (по горизонтали или вертикали) для поддержки более высоких скоростей обработки??
  3. Параллельные изменения – Существуют ли препятствия для обновления одного и того же контракта или баланса несколько раз, прежде чем актив будет полностью изменен??
  4. Производительность распределения транзакций – Когда ваша транзакция будет обновлена ​​для всех сторон? Это когда блок обрабатывается? После 6 глубин блока? После того, как поток завершен и подписан всеми сторонами?
  5. Многопоточность – Может ли ваша обработка транзакций и консенсус быть многопоточными или сегментированными между несколькими участниками сети и при этом согласовываться с одним и тем же золотым источником? Вы разделяете разные типы казней?
  6. Механизмы конфиденциальности для обфускации полей – Можете ли вы поделиться конкретными полями механизма хранения данных только с конкретными пользователями? Можете ли вы запустить бизнес-логику, которая сравнивает значения полей, не раскрывая информацию (например, Aztec и ZKsnarks)?
  7. Механизмы конфиденциальности для получателей (конфиденциальность) – Можно ли автоматически чередовать открытые ключи, чтобы конечный пользователь, которому вы отправляете информацию, не мог быть преобразован в известную личность?
  8. Механизмы конфиденциальности для отправителей (шаблоны транзакционного трафика) – Можете ли вы не поделиться транзакцией со всеми сторонами в тех случаях, когда вы хотите, чтобы транзакция была видна только вашим идентифицированным сторонам?
Проконсультируйтесь с нашими экспертами по блокчейну

Наша глобальная команда по решениям предлагает обучение блокчейну, стратегические консультации, услуги по внедрению и возможности партнерства. Свяжитесь с нами Информационный бюллетеньПодпишитесь на нашу рассылку, чтобы получать последние новости Ethereum, корпоративные решения, ресурсы для разработчиков и многое другое.Полное руководство по бизнес-сетям с блокчейномГид

Полное руководство по бизнес-сетям с блокчейном

Введение в токенизациюВебинар

Введение в токенизацию

Будущее финансовых цифровых активов и DeFiВебинар

Будущее финансов: цифровые активы и DeFi

Что такое Enterprise EthereumВебинар

Что такое Enterprise Ethereum?

Центральные банки и будущее денегБелая бумага

Центральные банки и будущее денег

Komgo Blockchain для финансирования торговли сырьевыми товарамиДело Шпилька

Komgo: Блокчейн для финансирования торговли сырьевыми товарами

Mike Owergreen Administrator
Sorry! The Author has not filled his profile.
follow me
Adblock
detector