Уважаемые пользователи Голос!
Сайт доступен в режиме «чтение» до сентября 2020 года. Операции с токенами Golos, Cyber можно проводить, используя альтернативные клиенты или через эксплорер Cyberway. Подробности здесь: https://golos.io/@goloscore/operacii-s-tokenami-golos-cyber-1594822432061
С уважением, команда “Голос”
GOLOS
RU
EN
UA
blockchained
5 лет назад

🌐 Управление EOS: всё ближе к неизменяемой архитектуре децентрализованных приложений

Технология EOSIO и сеть EOS достигли огромного успеха, несмотря на ограниченное время в продакшене. Мы опередили многих конкурентов по пропускной способности, ежедневным активным пользователям и темпам роста. Мы быстро совершенствовались с самого момента запуска. Это можно отпраздновать!

Следующее предложение подается вам в качестве пищи для размышления. Мы считаем, что должно произойти некое событие, которое приведет к пересмотру того, на чем мы сосредотачиваем свои усилия в плане управления EOS. Такое программное обеспечение предоставляет весьма широкие возможности для ликвидации устаревших систем путем перемещения фокуса на создателей ценности. Мы считаем, что для этой цели сообщество должно поместить разработчика, создателя ценности, обратно в центр внимания сообщества EOS.

Позиция

Надлежащее управление EOS подразумевает эффективную инфраструктуру принятия решений, которая уменьшает потребность в доверии между сторонами и ускоряет рост платформы.

Ниже приводится цитата члена Телеграм-сообщества EOS.

“Мы обсуждаем вопрос о том, чтобы отменить или, возможно, отложить наш план по интеграции EOS – и мы с самого первого дня очень поддерживали EOS, но если честно, мы, как разработчики децентрализованного приложения на EOS, чувствуем себя одиноко – всё, о чем мы здесь говорим, это конституции, BP, RAM и т.п., хотя мы здесь рвем наши задницы, чтобы нести EOS в массы – в одиночку.”

Обсуждение вопросов управления до сих пор практически не затрагивало разработчиков.

Давайте разберемся.

Текущее состояние

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

Изменчивость и неизменность должны рассматриваться как существующий в цикле разработки спектр. На протяжении всего этого цикла разработчик должен стремиться повысить безопасность и уменьшить потребность в доверии либо путем достижения полной неизменяемости, либо асимптотического приближения к ней.

Решение

Мы достигаем этого путем использования чрезвычайно надежной системы разрешений EOS. Вот описание «Разрешений», опубликованное Block.One на их портале для разработчиков.

Ниже приведены примеры полномочий для вымышленного аккаунта с именем @multisig. В этом случае два пользователя имеют допуск к активным разрешениям/разрешению владельца вымышленного аккаунта @multisig, где три пользователя имеют допуск к кастомному разрешению на публикацию с различным весом.

В этом случае для изменения на уровне разрешения владельца требуется пороговое значение в 2 голоса – и поскольку вес голоса каждой стороны равен 1, чтобы транзакция была полностью авторизована, ее должны подписать все пользователи.

Для отправки транзакции, что требует активных полномочий, пороговое значение устанавливается равным 1. Это означает, что требуется только одна подпись, чтобы разрешить действие от действующего управителя аккаунта.

Существует также третье кастомное разрешение с названием «публикация». В этом примере разрешение на публикацию используется для публикации постов в блоге @multisig с использованием некоего приложения для блогинга. Разрешение на публикацию имеет порог 2, @bob и @stacy обладают весом в 2, а публичный ключ имеет вес 1. Это означает, что и @bob, и @stacy могут постить без дополнительной подписи, в то время как публичный ключ требует дополнительной подписи, чтобы авторизовать действие с публичным разрешением.

Приведенная выше таблица разрешений подразумевает, что @bob и @stacy, как владельцы аккаунта, имеют повышенные привилегии, аналогичные правам модератора или редактора. Хотя этот примитивный пример довольно ограничен, в частности, в отношении масштабируемости, он в достаточной мере демонстрирует гибкий характер системы разрешений EOSIO.

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

Наблюдения

  • @bob и @stacy могут быть явно распознаны как владельцы этого аккаунта
  • Публичный ключ не может совершить действие с правом на публикацию без дополнительной подписи @bob или @stacy
  • @bob и @stacy могут совершить действие с правом на публикацию без каких-либо дополнительных подписей.

Правильно используя эту систему разрешений, разработчик может делиться полномочиями по обновлению кода своего смарт-контракта с одной или несколькими сторонами, устраняя центральную точку сбоя и снижая необходимость пользователей доверять одному разработчику или команде разработчиков.

Майкл Флетчер, ведущий разработчик EOS42 и платформы лизинга токенов Chintai, прокомментировал структуру разрешений Chintai, которая требует, чтобы 6 из 11 спонсоров - производителей блоков подписали транзакцию с мультиподписью для внесения каких-либо обновлений в код. В противном случае обновление невозможно.

Производители блоков <> Разработчики децентрализованных приложений

Производители блоков могут обновлять различные части блокчейна EOS, когда каждый из 15/21 или ?+1 производителей блоков подпишет транзакцию, чтобы получить доступ к активному разрешению аккаунта eosio.prods. Как только 15/21 подписались, eosio.prods может авторизовать действия, которые обычные аккаунты не могут. В аккаунте eosio.prods существуют три разрешения, которые жизненно важны для этого предложения.

  • active
  • prods.major
  • prods.minor

Каждое разрешение в eosio.prodsactive, prods.major и prods.minor – требует соответственно 15, 11 и 8 производителей блоков для доступа. Это также можно представить как ?+1, ?+1 и ?+1.

У нас получается изящная пошаговая система, которая при эффективном подходе может использоваться для децентрализации полномочий по обновлению конфиденциальных смарт-контрактов децентрализованных приложений с участием производителей блоков, которые являются доверенными и подотчетными объектами в системе EOS. По сути, используя доступные функции EOSIO, мы можем создать структуру управления, которая уменьшает потребность в доверии и повышает безопасность dApp, основанных на EOS. Эта взаимосвязь распределенных полномочий не ограничивается только разрешениями eosio.prods, но также может существовать между любым разработчиком и третьей стороной. Это отличительная конкурентная особенность EOS.

Как это может выглядеть?

На сегодняшний день существует множество стандартов сертификации в различных отраслях. Например, сертификаты SSL подтверждают, кто вы, соответствие SOC и PCI гарантирует безопасность процессов, а ISO – стандарты качества в разных отраслях. Большинство из них затем разбиваются на уровни в зависимости от строгости применяемой сертификации. В то время как EOS предлагает своим разработчикам неограниченную гибкость, средний пользователь не обладает необходимыми инструментами для оценки безопасности или определения личности разработчика любого децентрализованного приложения, с которым он взаимодействует.

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

Предстоящие задачи

В середине декабря 2018 была обнаружена уязвимость в системе безопасности, и нами был разработан патч, исправляющий проблему в сети EOS, который приняли все производители блоков. И хотя этот патч, безусловно, был необходим, он вызвал проблемы у многих разработчиков децентрализованных приложений и их смарт-контрактов. Что если бы эти децентрализованные приложения делились разрешениями на обновление своего кода с производителями блоков? Теперь перед нами стоит ряд логистических задач.

  • Каким образом могут быть уведомлены децентрализованные приложения, а каким – производители блоков этими же децентрализованными приложениями?
  • Как децентрализованные приложения будут отправлять информацию об обновлении производителям блоков для подтверждения?
  • Придется ли за это платить?
  • Есть ли надежный портал для общения или других процессов?
  • Должно ли существовать соглашение об обслуживании между производителями блоков и децентрализованными приложениями, которые совместно используют структуры разрешений?

Это важные вопросы, ответы на которые представляют, как должны были бы выглядеть основы управления EOS с самого начала.

Заключение

Отношения на уровне обслуживания между производителями блоков и разработчиками децентрализованных приложений имеют ключевое значение для базовой структуры управления блокчейном EOS и основной сетью. Переход к неизменяемой архитектуре для конфиденциальных смарт-контрактов поможет создать условия для роста за счет повышения безопасности и уменьшения потребности в доверии между сторонами. Разработчики децентрализованных приложений должны подумать о том, как приблизиться к неизменности своих контрактов, особенно тех, которые управляют токенами, и таким образом дифференцировать себя от менее защищенных конкурентов. Производители блоков должны начать разработку процесса, с помощью которого они смогут адекватно поддерживать разработчиков согласно этому подходу. Создание этой структуры является обязанностью всего сообщества EOS. Проработка рабочих процессов и правил взаимодействия, связанных с нашим движением вперед, имеют ключевое значение. У EOS New York пока нет четкого сценария развития этого процесса. Мы, однако, призываем сообщество признать важность этой инициативы и
переключить на нее свою энергию с отвлекающих факторов, которые изрядно нас измотали. Давайте поместим разработчика обратно в центр внимания. То, как мы – сообщество – решим эту задачу, напрямую повлияет на рост и управление сетью EOS и EOSIO.


Переведено @blockchained

Оригинал поста: ЗДЕСЬ


Если вам нравится то, что мы делаем - поддержите блокпродюсера blockchained в сети EOS


Телеграм чат: https://t.me/EOS_RU


Загрузите десктопное приложение с открытым исходным кодом RuDex


Вы можете торговать токенами EOS на RuDEX

0
151.245 GOLOS
На Golos с January 2017
Комментарии (2)
Сортировать по:
Сначала старые