EOS (EOS) - eos.io - Форум о заработке, инвестициях и криптовалюте
Форум о заработке, инвестициях и криптовалюте

Вернуться   Форум о заработке, инвестициях и криптовалюте > Форум о криптовалютах > Виды цифровых (крипто) валют

Важная информация

Виды цифровых (крипто) валют Представление, обсуждения, новости, мнения по конкретным криптовалютам. При поддержке:
Новости криптовалют, блокчейн, финтех

Ответ
 
Опции темы Опции просмотра
Старый 14.07.2018, 11:19   #1
Bit
www.moneycreators.ru
 
Аватар для Bit
 
Регистрация: 24.02.2018
Сообщений: 734
Вы сказали Спасибо: 0
Поблагодарили 1 раз в 1 сообщении
Автор темы По умолчанию EOS (EOS) - eos.io

  • Официальный сайт: eos.io
  • Язык сайта: English
  • Рыночная капитализация: $6 231 904 222
  • Цена за coin EOS: $6,95
  • Место в рейтинге CoinMarketCap: 5
  • Исходный код: github.com/eosio
  • Технический документ: github.com/EOSIO/Documentation/blob/master/TechnicalWhitePaper.md
  • Поддержка в социальных сетях: Youtube, Facebook, Twitter, Reddit, Medium
EOSIO - это программное обеспечение, которое вводит архитектуру blockchain, предназначенную для вертикального и горизонтального масштабирования децентрализованных приложений («Программное обеспечение EOSIO»). Это достигается с помощью конструкции, подобной операционной системе, на которой могут быть созданы приложения. Программное обеспечение предоставляет учетные записи, аутентификацию, базы данных, асинхронную связь и планирование приложений в нескольких ядрах и / или кластерах ЦП. Результирующая технология - это блок-цепь, которая может масштабироваться до миллионов транзакций в секунду, исключая плату пользователей и позволяющая быстро и просто развертывать децентрализованные приложения.



EOSIO поставляется с несколькими программами. Первичные, которые вы будете использовать, и те, которые описаны здесь, следующие:
  • nodeos(node ​​+ eos = nodeos) - основной демон узла EOSIO , который можно настроить с помощью плагинов для запуска узла. Примеры использования - это производство блоков, выделенные конечные точки API и локальная разработка.
  • cleos (cli + eos = cleos) - интерфейс командной строки для взаимодействия с блочной цепочкой и управления кошельками
  • keosd (key + eos = keosd) - компонент, который надежно хранит ключи EOSIO в кошельках.
Базовая связь между этими компонентами проиллюстрирована на следующей диаграмме. В следующих разделах вы создадите компоненты EOSIO и развернете их в конфигурации с одним узлом тестовой сети (testnet).

Bit вне форума   Ответить с цитированием
Старый 24.04.2019, 01:57   #2
BitLite
Премиум
 
Аватар для BitLite
 
Регистрация: 24.10.2012
Сообщений: 681
Вы сказали Спасибо: 0
Поблагодарили 2 раз(а) в 2 сообщениях
По умолчанию

Будущее без пароля: создание более безопасных и удобных систем аутентификации



Замена паролей закрытыми ключами в простой для понимания метафоре
С внедрением инициативы EOSIO Labs ™ мы начали открыто внедрять инновации в отношении будущего технологий цепочки блоков, построенных на EOSIO. В нашем первом выпуске в рамках этой инициативы рассматривается будущее управления закрытыми ключами и его влияние на безопасность и управление ключами - Universal Authenticator Library (UAL), В основе философии этого выпуска лежит исследование более крупной проблемы, которая сосредоточена на том, как пароли и аутентификация были реализованы через Интернет, блокчейн или иным образом. Несмотря на то, что в этой публикации нет выпуска программного обеспечения, эта статья посвящена обсуждению проблем, которые мешают существующим системам аутентификации, и современным попыткам выйти за пределы паролей, сопровождающих такие проблемы. Затем мы предложим в абстрактном виде новую модель, использующую метафору «пропуска», такую ​​как авиабилет или читательский билет, для решения этих проблем безопасным и удобным способом.

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

Чтобы проиллюстрировать это, представьте себе плохо принятый пост в социальной сети, предположительно созданный известным политиком, который угрожает разрушить карьеру указанного политика. Откуда мы можем точно знать, что политик, фактически, создал этот пост? Хотя автор действительно мог быть политиком, о котором идет речь, это может быть любой человек, имеющий доступ к учетной записи политика в социальных сетях. Чтобы расширить эти рассуждения, пул возможных «авторов» может включать любое количество людей, близких к политическому деятелю, или соперничающих хакеров в целенаправленной атаке. Тем не менее, никто, включая политика и поставщика услуг социальных сетей, не сможет представить убедительные, косвенные доказательства того, что политик был или не был окончательно автором данного поста.
Чтобы использовать юридическую и техническую терминологию, эта характеристика упоминается как отказоустойчивость, и это не желательная черта. Два главных фактора приводят к этой характеристике достоверности в нашем примере в социальных сетях; Первый фактор - это схема аутентификации, которая требует раскрытия секрета для подтверждения владения этим секретом. В схемах безопасности (таких как пароли), которые подвержены этому фактору, невозможно создавать журналы активности пользователей, которые могут быть проверены кем-либо, кроме стороны и контрагента. Вторым фактором является отсутствие средств для доказательства того, что данные в системе, которые на самом деле представляют собой намерения пользователя, приводят нас к другой проблеме, которую мы называем «Пустой чек».

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

«Двое становятся одним»
Проницательный наблюдатель мог бы заметить, что эти проблемы на самом деле являются двумя результатами одной и той же основной проблемы: отсутствие доказуемых журналов аудита. Хотя существуют технологии, которые устраняют этот фундаментальный недостаток в наших нынешних системах, например системы на основе сертификатов, основанные на асимметричной криптографии, они еще не достигли уровня удобства для пользователя, который делает их доступными для широкой публики. Решая эту проблему с помощью простых в понимании метафор для теоретического решения, которое мы представим ниже, у нас есть возможность повысить безопасность и удобство использования всех наших систем для каждого типа пользователей и улучшить взаимодействие пользователей в процессе.

Пароли
При обсуждении кибербезопасности должны быть определены два основных термина: «аутентификация», то есть процесс, с помощью которого пользователь доказывает, что он является тем, кем, по его словам, он владеет определенными учетными данными, обычно с именем пользователя и паролем; и «авторизация», которая представляет собой процесс, посредством которого действия пользователя в программной платформе разрешаются или ограничиваются в соответствии с их личностью.
С 1960-х годов пароли были де-факто методом, который позволяет пользователю аутентифицировать себя на устройстве или услуге. Аутентификация по паролю на сегодняшний день является хорошо понятной технологией для инженеров. Для пользователей пароли стали простым понятием; они удобны и знакомы даже для нетехнических пользователей. Но хотя их простота и удобство являются сильной стороной, пароли также страдают от многих недостатков.
Такие слабости носят как технологический, так и человеческий характер. Некоторые из них широко обсуждались, в том числе подробно в Руководстве по цифровой идентификации NIST.поэтому мы не будем их здесь повторять. Однако важно помнить, что пароли не позволяют вести достоверные проверяемые журналы действий, разрешенных пользователем. Для аутентификации с помощью пароля он должен быть раскрыт, а для проверки действительности пароля пользователя поставщики услуг должны хранить их в какой-либо форме централизованной инфраструктуры. Это означает, что никто, кроме поставщика услуг, не может быть уверен, что любые журналы аудита, которые они ведут, являются точным представлением действий пользователя. По этой причине системы, использующие пароли для проверки подлинности, подвержены как проблеме слуховых сообщений, так и проблеме незаполненной проверки, как описано выше.

Современные попытки улучшить или заменить пароли
За последние годы было несколько попыток постепенно улучшить или заменить пароли. Ниже мы рассмотрим несколько наиболее успешных случаев, а также их сильные и слабые стороны.

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

Двухфакторная аутентификация
Признавая слабость паролей, были предприняты попытки наложить дополнительную безопасность, чтобы гарантировать, что сам пароль не является единственной точкой отказа. Этот подход обычно называют вторым фактором или двухфакторной аутентификацией (2FA). Существует множество реализаций 2FA, и хотя все они добавляют разную степень дополнительной безопасности к системам аутентификации на основе паролей, они компенсируют это дополнительными сложностями с точки зрения настройки и работы конечного пользователя. Обычное решение 2FA использует SMS-сообщения для предоставления одноразовых паролей, основанных на времени (OTP). Как и сами пароли, двухфакторные решения страдают от проблемы, заключающейся в том, что они не подлежат аудиту и уязвимы для практики безопасности телефонных операторов, которые доставляют SMS-сообщения на ваше устройство.
Отсутствие доказуемой проверяемости означает, что 2FA по-прежнему не решает проблему слухов или проблему незаполненной проверки.

Стандарт WebAuthn
WebAuthn - это новый стандарт аутентификации, предложенный Консорциумом всемирной паутины (W3C), международным сообществом организаций-членов, штатным сотрудником и общественностью, совместно работающей над разработкой веб-стандартов. WebAuthn очень близко подходит к решению всех этих проблем для веб-транзакций, используя асимметричную криптографию вместо паролей, предоставляя один из необходимых компонентов для преодоления описанных проблем. Однако для того, чтобы пользователи, которые теряют свои устройства, не были заблокированы во всех сервисах, WebAuthn предназначен для использования в сочетании с паролями, а не в качестве замены.
Еще одно важное ограничение WebAuthn заключается в том, что он был разработан как подтверждение присутствия, а не как подтверждение согласия. Он не предназначен для разрешения запросов авторизации для каждой транзакции, которые могут быть проверены партнерами. Итак, еще раз, системы, которые полагаются на WebAuthn, не имеют проверяемых журналов аудита и подвержены как проблеме «Слуха», так и проблеме «Незаполненной проверки».

Блокчейн как потенциальное решение
Блокчейны популяризировали идею аутентификации пользователя для каждого санкционированного им действия, используя криптографическое подписывание транзакций с открытым ключом для достижения этой цели. Это значительное улучшение паролей и шаг за пределы того, что может предоставить WebAuthn. Это также удовлетворяет первому фактору, необходимому для решения проблемы слухов: доказуемая аудиторская способность.
К сожалению, современные пользовательские интерфейсы блокчейна также не определяют стандарт для описания запросов на авторизацию удобным для пользователей способом, чтобы их можно было отображать в надежном контексте для одобрения пользователя. Без этого удобного для пользователя стандарта обработки запросов пользователи не могут знать, на что они соглашаются. Это означает, что хотя блокчейны создают проверяемый журнал, который можно проверить, им не хватает средств, чтобы доказать, что данные в системе действительно представляют намерение пользователя. Таким образом, они все еще подвержены проблемам Слуха и Бланка.
Вернемся к нашему примеру с социальными сетями: если бы платформа социальных сетей была построена на блокчейне, они смогли бы доказать, что политик, о котором идет речь, фактически подписал действие, приведшее к посту, но они не смогли бы доказать что они (или другая сторона) не обманули политика, чтобы он подписал действие, искажая его.

Теоретическое решение: «проходит» вместо ключей или паролей
Для повышения безопасности наших систем нам необходимо подтверждение согласия пользователя в сочетании с уровнем простоты и удобства использования, который превышает даже пароли. Это означает, что мы должны передавать сложные технологии, такие как асимметричная криптография, через метафору, которая сразу понятна для любого пользователя, а не только для технолога. Одной из концепций, которая соответствует этим критериям, является концепция «прохода». При описании концепции прохода мы покажем, как это теоретическое решение прохода, используемое в приложении Pass Manager, может удовлетворить как проблему Hearsay, так и проблему незаполненной проверки, которую мы обрисовали в общих чертах.
Для пользователей пропуск представляет собой знакомое и осязаемое средство подтверждения наличия учетных данных. Каждый день мы взаимодействуем с физическими пропусками как часть нашей повседневной жизни. Как пользователь библиотеки, вы просто показываете свою библиотечную карточку. Как пассажир авиакомпании, вы просто появляетесь и предъявляете свой билет. Это примеры одноразовых пропусков. Для услуг, которые не предоставляют одноразового пропуска, вы можете предоставить свои водительские права, чтобы подтвердить свою личность.
Для поддержки случаев использования аутентификации и авторизации мы вводим концепцию цифрового «Pass Manager». Pass Manager - это парадигма без пароля для случаев использования при регистрации, аутентификации и авторизации.

Что вы могли бы сделать с Pass Manager?

Выдача и отзыв
Поставщики услуг могут запросить Pass Manager для выдачи нового пропуска для пользователя.
Пользователи могут организовывать свои пропуска в группы. (например, моя работа проходит, и мои личные проходы)
Пользователи могут авторизовать и деавторизовать проходы между несколькими устройствами.
Аутентификация
Поставщики услуг могут запросить подтверждение наличия у пользователя пропуска.
Пользователи могут предоставить доказательство своего владения пропуском.
Авторизация
Поставщики услуг могут запросить подтверждение разрешения пользователя на выполнение определенного действия в зависимости от разрешения, которым обладает пользователь.
Пользователи могли видеть запросы на авторизацию, четко представленные в удобной для человека форме, и выбирать, разрешать ли действие, на основании разрешения, которое они имеют.

Как будет работать Pass Manager?
Менеджер проходов реализует (пока еще не определенный) стандартизированный протокол для выдачи и отзыва пропусков, аутентификации и авторизации с пропусками. Pass - это концептуальная абстракция, которая инкапсулирует информацию о полномочиях (ключи).
Опыт использования цифрового Pass Manager должен быть очень похож на физический аналог Pass Card. Пользователь просто приходит к услуге (будь то веб-приложение, нативное приложение, система торговой точки или киоск) и представляет пропуск для входа или авторизации действия. Это похоже на то, как студент колледжа использует свой идентификатор колледжа, чтобы получить допуск к спортивному мероприятию в колледже, а затем, находясь внутри, использует его для покупки еды на стенде с обеденным балансом в своем кампусе, когда перед совершением транзакций ему выдается подтверждение заказа.
Под капотом может сочетаться сочетание технологий для обеспечения превосходной безопасности и удобства использования для пользователей, включая криптографическую подпись, аппаратные ключи и биометрические данные для защиты учетных данных, а также независимый от транспорта протокол для переносимости.
В любое время, когда Pass Manager запрашивает согласие пользователя, пользователю должно показываться понятное описание действия , и это описание (или его криптографически проверяемое производное) должно включаться в подписанный ответ от Pass Manager. Использование ключей означает, что журналы не подлежат исправлению и могут быть проверены третьими лицами, а включение понятного для человека описания в подписанный ответ может служить доказательством намерения пользователя. Эти характеристики решают проблемы, связанные с проверкой на наличие ошибок и проверкой.
Эта модель может поддерживать как существующие веб-технологии, так и будущие сценарии использования технологии блокчейн. Он также способен обеспечить понятный пользовательский интерфейс для случаев использования входа и авторизации.

Что необходимо для успеха Pass Managers?

Interoperability
Прежде всего, должен быть создан протокол Pass Manager, чтобы пользователи могли свободно выбирать Pass Manager, который наилучшим образом соответствует их потребностям. Это важно, потому что это предотвращает привязку к поставщику, создавая свободный рынок, необходимый для стимулирования инноваций в области безопасности и взаимодействия с пользователем. Таким образом, лучший пользовательский опыт с приемлемой безопасностью выиграет.
Чтобы обеспечить эту свободу выбора, должны быть стандартные протоколы для регистрации, входа в систему и авторизации. Авторизация, в частности, представляет собой интересную задачу, поскольку требует определения стандарта для описания запросов на авторизацию для пользователей понятным, проверяемым, доказуемым и переносимым способом.
Портативность
Во-вторых, протокол Pass Manager должен быть построен для переносимости; Это означает: 1) поддержку всех видов приложений или услуг, работающих на любой платформе, 2) поддержку ограниченного сетевого подключения или его отсутствие, 3) поддержку нескольких устройств и 4) поддержку связи между устройствами.
У пользователей есть настольные компьютеры, ноутбуки, телефоны, планшеты, умные часы и USB-ключи. Таким образом, простой и беспроблемный опыт выдачи и отмены пропуска на нескольких устройствах имеет решающее значение. Пользователи также взаимодействуют с системами торговых точек, ненадежными публичными компьютерами, торговыми автоматами и киосками. Поэтому необходима способность взаимодействовать с одного устройства на другое с сетевым подключением или без него, не требуя, чтобы устройства доверяли друг другу.
Этим требованиям можно удовлетворить, определив протокол Pass Manager как независимый от транспорта. Это означает, что протокол должен фокусироваться на определении существительных и глаголов, которые реализующие системы должны иметь возможность свободно говорить, и позволять транспортам, через которые они говорят, изменяться. Примерами транспортов могут быть URL-адреса пользовательских протоколов, универсальные ссылки Apple, содержимое Android, запросы к серверу, QR-коды, API-интерфейсы Bluetooth, NFC и JavaScript. Благодаря такой гибкости Pass Managers могут быть действительно портативными.
Юзабилити
Пользователям не нужно учитывать последствия того, используют ли они веб-сервис с базой данных базы данных или систему блокчейнов. В случае блокчейна им не нужно знать, на какой платформе или сети блокчейна создано приложение, которое они используют. Им нужно только рассмотреть их вариант использования. Вещи как…
«Я снимаю средства в банкомате».
«Я вхожу в свою электронную почту.»
«Мне нравится пост в социальных сетях».
«Я покупаю чипсы в торговом автомате».
«Я перевожу 100 жетонов от Дэна к Брайану».
Никогда такие вещи, как ...
«Я подписываю транзакцию с ключом R1, авторизованным для моей учетной записи blockchain11, на dapp example.com, который построен на блокчейне Telos, который построен на платформе EOSIO».
Безопасности
Текущие реализации паролей и систем с открытым ключом небезопасны по ряду причин. Проходные менеджеры должны работать лучше.
Чтобы защитить пользователей от атак на централизованные приманки учетных данных, секретные данные учетных данных никогда не должны храниться в централизованной инфраструктуре в какой-либо форме (хеширование и засоление недостаточно). Чтобы защитить пользователей от кражи их учетных данных в результате фишинга, вредоносных программ и атак типа «злоумышленник в середине», пользователи никогда не должны знать свои учетные данные и никогда не должны вводиться вручную или автоматически в какую-либо службу. Чтобы защитить пользователей от обмана при добавлении вредоносных проходов, пользователи не должны иметь возможность добавлять или удалять проходы самостоятельно. Вместо этого доверенный Pass Manager должен обрабатывать это автоматически от имени пользователя в ответ на посещение пользователем новых служб или получение новых устройств.
BitLite вне форума   Ответить с цитированием
Старый 22.04.2020, 02:04   #3
BitLite
Премиум
 
Аватар для BitLite
 
Регистрация: 24.10.2012
Сообщений: 681
Вы сказали Спасибо: 0
Поблагодарили 2 раз(а) в 2 сообщениях
По умолчанию

EOS Ecosystem, приложение-кошелек, обещавшее высокую отдачу от депозитов пользователей в EOS, закрыло платформу, и ее создатели, похоже, сбежали с примерно 52 миллионами долларов пользовательских средств, согласно отчету.

Ранее ChainNews сообщал, что EOS Ecosystem не имеет узла EOS, как он утверждает и использует схему пирамиды. В 2019 году проект был подан в суд на местный суд в Тэнчжоу, Китай, за то, что он предположительно выполнил схему пирамиды, включающую более 33 миллионов токенов EOS (около 81 миллиона долларов на момент печати)...


Подробнее в теме: Приложение для кошельков закрывается, прикарманив $52 млн.
BitLite вне форума   Ответить с цитированием
Старый 02.05.2020, 01:49   #4
Holder
Новичок
 
Аватар для Holder
 
Регистрация: 17.09.2013
Сообщений: 148
Вы сказали Спасибо: 0
Поблагодарили 0 раз(а) в 0 сообщениях
По умолчанию

Многоуровневая инфраструктура DeFi Equilibrium, повысила пропускную способность EOSDT с 70 до 170 миллионов долларов благодаря интеграции pBTC.

По мере того, как децентрализованные финансы, или DeFi , промышленность продолжают расти, потребность в ликвидности в криптовалютах неуклонно растет.

Старт DeFi Equilibrium сегодня расширил предложение своей децентрализованной EOS- стабильной монеты EOSDT в результате интеграции ликвидности , управляемой биткоинами ( BTC ).

Equilibrium, крупная многоуровневая инфраструктура DeFi, подняла лимит тиража EOSDT с 70 до 170 миллионов долларов, объявила фирма 1 мая...

Подробнее в теме: Объем поставок EOSDT увеличился на $100 млн.
Holder вне форума   Ответить с цитированием
Старый 25.05.2020, 00:38   #5
BigLion
Новичок
 
Аватар для BigLion
 
Регистрация: 13.04.2011
Сообщений: 237
Вы сказали Спасибо: 0
Поблагодарили 0 раз(а) в 0 сообщениях
По умолчанию

Игра Upland, управляемая блок-цепью EOS - основанная на местоположении концепция Monopoly, в которой игроки собирают и торгуют цифровыми версиями реальных объектов, вскоре позволит пользователям продавать их за указанную валюту благодаря партнерству с Linden Lab, создателем Second Life.

Upland позволяет игрокам приобретать и собирать виртуальные версии реальных локаций в виде негибаемых токенов (NFT), а затем получать прибыль от них. Игроки могут зарабатывать жетоны UPX, когда другие игроки посещают их объекты, а также бонусы за сбор тематических наборов свойств...

Подробнее в теме: Upland использует технологию Second Life для продажи недвижимости за наличные
BigLion вне форума   Ответить с цитированием
Ответ

Опции темы
Опции просмотра

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.

Быстрый переход


Загрузка...


Powered by vBulletin® Version 3.8.9
Copyright ©2000 - 2024, vBulletin Solutions, Inc.
vB.Sponsors

© 2009-2020 «ACRYPTOINVEST.COM»
сообщество трейдеров, инвесторов и игроков