@mrbumblebee said in Как установить делегативную ноду на VPS:

А подскажите, как прописать автоматический запуск ноды после перезагрузки сервера?

https://community.smartholdem.io/topic/21/chastye-voprosy-po-yspolzovanyiu-full-node-level-a

@patinity said in Дополнительные bash скрипты:

@stasiulman said in Дополнительные bash скрипты:

[inf] 2017-12-30 18:23:06 | New block received - {"id":"17557601612525060079","height":139486,"transactions":0,"peer":"46.101.211.116:6100"}
[inf] 2017-12-30 18:23:14 | New block received - {"id":"2447356752494765610","height":139487,"transactions":0,"peer":"85.217.171.214:6100"}
[inf] 2017-12-30 18:23:22 | New block received - {"id":"6641643334502998807","height":139488,"transactions":0,"peer":"194.87.109.198:6100"}
[inf] 2017-12-30 18:23:30 | New block received - {"id":"11139420745089260896","height":139489,"transactions":0,"peer":"194.87.146.50:6100"}
[inf] 2017-12-30 18:23:39 | New block received - {"id":"8980381093865356149","height":139490,"transactions":0,"peer":"188.120.241.109:6100"}
[inf] 2017-12-30 18:23:46 | New block received - {"id":"11853436952771474611","height":139491,"transactions":0,"peer":"107.181.174.203:6100"}
[inf] 2017-12-30 18:23:54 | New block received - {"id":"10985840749270045155","height":139492,"transactions":0,"peer":"46.101.211.116:6100"}
[inf] 2017-12-30 18:24:03 | New block received - {"id":"2273221184082392768","height":139493,"transactions":0,"peer":"185.205.210.106:6100"}
[inf] 2017-12-30 18:24:13 | New block received - {"id":"15194616238149026998","height":139494,"transactions":0,"peer":"185.205.209.96:6100"}
Сейчас пишет сл, нужно ждать или что то не так сделал? С списке делегатов не появился.

nano config.smartholdem.json секретная фраза 12 слов в кавычках стоит?

@patinity это говорит о синхронизации блокчейн
в ближайшее время создадим snapshots блокчейн для более быстрой синхронизации

@xoz9in said in SmartHoldem - первый в мире кошелёк поддерживающий русскоязычный BIP39:

@technol0g А если я создам кошелёк на англ. Переведу эти слова на русский и вставлю фразу на русском, то ничего не получиться по идеи ? Я правильно понимаю?

да это будет уже новый ключ

@anton много говорить кто работать тогда будет..

@TechnoL0g поддерживаю идею внедрения.

На данный момент идеальный кандидат реализации БЧ Node-Z-X выбран RUST

По моему я задонатил куда надо😅 Мало что понял с выше описаного, так как несильно технически подкован, но это звучит очень мощно. У меня чуйка😉

@technol0g said in Переполнение диска:

df -h

Также благодарю за информацию. Почистил логи. Их размер у меня составлял 4,4 гига. Теперь доступно 69 гигов.

20 июня в Тбилиси – Blockchain & Bitcoin Conference Georgia 2018.
Спикеры конференции – лидеры мнений в Грузии, представители государственных структур, майнеры. Кейсами поделятся грузинские и международные юристы, экономисты, ICO-консультанты и аналитики.

Партнёры и спикеры мероприятия – основатели блокчейн-индустрии в Грузии: Association Blockchain Georgia, Bitcoin Embassy Georgia и Blockchain Systems Institute.

Конференцию планируют посетить 300 участников из Грузии, Армении, Азербайджана, Казахстана, Украины, Беларуси, Германии, США.

@technol0g Что это? И зачем?

В начале разработки BlockChain для Smartholdem я придерживался модифицированной Proof-of-Stake модели, где все участники это full-nodes и получают комиссии от новых транзакций сети.
Но при таких условиях время блока от 1-6 минут, и необходимо скачивание полного BlockChain перед тем как начать операции в сети. Замедление сети обусловлено неограниченным числом пользователей подписывающих блоки, при всём этом логично, многие имеют нестабильные подключения итд. Также опасность одного пользователя теоретически выкупить более 50% токенов, что могло сказаться на работе сети в худшую сторону.

После общения с ребятами из русскоязычной ветки графен (RuDEX), решил подробнее исследовать мат часть алгоритма DPoS, за что им благодарен.

Т.к. постоянно провожу время в разработке и исследованиях новых алгоритмов, пришел к новому оптимальному консенсусу на основе DPoS

На выходе получаем следующую модель - 2х уровневый делегативный консенсус. С временем подтверждения до 5 секунд.

Суперноды (делегаты) 1го уровня избираются пользователями сети, для подписания новых блоков, число участников ограничено 64. Любой пользователь сможет стать участником при соответствующем качестве своих серверов и голосов. Получают вознаграждения за комиссии сети.

Делегаты второго уровня, если говорить в привычных терминах подобны LPoS Waves, число участников неограниченно, для того чтобы стать участником 2го уровня, не менее важного чем первый, необходимо установить полную ноду и иметь генерирующий баланс от 10к STH, делегаты уровня отвечают за распределение вознаграждений и генерацию суперблоков от игровых процессов.

Здесь мы не забыли и про "малых" держателей монет, к примеру имеющих баланс 2к STH, такие пользователи тоже смогут принять участие в распределении вознаграждений, передав в аренду свой баланс делегатам 2го уровня (фактически баланс никуда не переводится), да они будут получать меньшую сумму вознаграждений, но будут.

Разрабатываемая модель идеальна для нашей децентрализованной игровой платформы, и она оптимально именно для экосистемы SmartHoldem.

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

SmartHoldem использует криптографическое хеширование для обеспечения безопасности всех аспектов системы. Система использует EdDSA, поскольку она обеспечивает гораздо более быстрый механизм хэширования и обеспечения безопасности [см. http://cr.yp.to/highspeed/coolnacl-20120725.pdf]; а не ECDSA, который встречается во многих других криптомонетах, таких как биткойн.

Закрытый и открытый ключ (Key pair)

Key pair состоит из закрытого (приватного) ключа и открытого (публичного) ключа. Приватный ключ - это информация, известная только владельцу ключа. Открытый ключ получается из закрытого ключа и может использоваться для проверки того, что закрытый ключ принадлежит владельцу, но не предоставляет доступ к закрытому ключу владельца. Криптография по элиптической кривой используется для генерации криптографически защищенных пар ключей.

Процесс, используемый для создания пары ключей, работает в следующих предположениях:

Когда пользователь создает учетную запись, для пользователя генерируется мнемоника BIP39 (кодовая фраза). Эта кодовая фраза хэшируется с использованием хэш-функции SHA-256 в 256-битной строке. Этот хеш впоследствии используется как seed в ed25519 для генерации приватного ключа ks и получает его открытый ключ kp.

Генерация key-pair

С помощью приватного ключа пользователь может подписывать транзакции в объекте-транзакции и транслирует этот объект в сеть. Открытый ключ включен как часть транзакции, а узлы, которые получают транзакцию, могут проверить достоверность подписи с использованием kp. Это обеспечивает эффективную защиту как для пользователя, так и для сети, поскольку ks известен только пользователю, а kp может подтвердить, что подпись действительна.

Вторая фраза (будет доступна в новых версиях кошелька)

SmartHoldem предлагает дополнительный уровень безопасности для пользователя. Используя специальный класс транзакций, пользователь может зарегистрировать вторую парольную фразу, связанную с kp. Эта взаимосвязь требует, чтобы все последующие транзакции подписывались с использованием второй фразы, чтобы считаться действительной. Процесс генерации второй пары ключей такой же, как и для пары основных ключей.

Мультиподписи (Multisignature) (доступно в ближайших версиях кошелька)

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

Адрес

Адрес или id кошелька формируется из открытого ключа. Открытый ключ хешируется с использованием SHA-256 и результат выполнения всегда начинается с "S"

0_1519092149189_smart-bc.png

Проблемы распространения децентрализованных сетей

Несмотря на преимущества p2p сетей, на текущий год они имеют малое распространение среди простых законопослушных пользователей интернета.

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

Варианты мотивации:

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

2. интерес к контенту
Если сайт интересен в p2p сети, его посещают тысячи пиров, распространяя контент ресурса и поднимая скорость отдачи материалов. При росте сети, контент станет избыточен, для сокращения избыточности используем формулу m < N, где m - max число пиров для одинакового контента, N - всего пиров в сети. Дополнительно сократить дедубликацию контента возможно с помощью хэширования в ipfs, к примеру библиотека jquery.js отправленая в сеть ipfs будет доступна по ранее загруженному хэшу.

3. анонимность, безопасность, отсутствие цензурирования
В обычном интернете все ваши письма, переписка и личные данные доступны провайдерам.
В p2p сетях защищенных криптографией и дополнительными протоколами (tor, vpn, tls) данная проблема отсутствует, являясь мотивацией использования.

Исходя из некоторых исследований, понимание свободного интернета для большинства пользователей сводится к тому, что участники сети ощущая полную анонимность и безопасность ведут себя недостойно и неуважительно по отношению к другим участникам. Т.е. обычное дело написать "все кАзлы..", не используя действительный потенциал сети на 0.0001% и новых возможностей, однако адекватному человеку подобный контент неинтересно воспринимать. Соответственно необходимы новые методы взаимодействия с троллинг-контентом при отсутствии злого центрального админа.

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

Приватное облачное хранилище

Всем нам известно, централизованные облачные системы dropbox, google, apple и подобные имеют доступ к всем вашим данным в облаке, не мало известны факты о взломах подобных систем со всеми вытекающими последствиями.

Приватное децентрализованное облачное хранилище исключает недостатки систем на ручном управлении.

Входные параметры хранилища:

минимальное число поддерживающих пиров (5-10-15-100-N пиров) время хранения (1-3-6-12-24-240-N месяцев) объем (1-3-5-N Tb)

соответственно в зависимости от параметров изменяется стоимость приватного хранилища. Вознаграждение - необходимая мотивация узлов.
Для предоствращения роста цен на хранилища (инфляция), предполагается допополнительная аукционная система в сочетании с фиксированными стартовыми параметрами.

Умные контракты в децентрализованных сетях

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

В простых блокчейн-системах имеются следующие недостатки: контракты навсегда записываются в базу данных, а стоимость поддержки подобных контрактов растет с каждым блоком. Каждый блок ограничен объемом принимаемого контракта.

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

К примеру контракт на проведение ICO не нуждается в вечном хранении, а лишь до его завершения и выполнения конечных автоматизированных условий - Temporary Smart Contracts.

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

Подпись сообщений может потребоваться при подтверждении владения конкретным адресом SmartHoldem без раскрытия самого приватного ключа. Результат проверки подписи имеет одно из значений: проверка пройдена, не пройдена.

К примеру при участии в ico вам может потребоваться подтверждение владения адресом, подпись контента в p2p сетях, авторство (в сочетании с хэшированием) или при авторизации на сайте поддерживающем API SmartHoldem. Либо при других операция где необходимо подтвердить владение адресом.

Подписание сообщения:

откройте SmartHoldem приложение выберите свой адрес > подпись сообщения нажмите ПОДПИСЬ укажите секретную фразу и сообщения вы получите запись с подписанным сообщением нажмите скопировать

пример результата

{"publickey":"03675c61dcc23eab75f9948c6510b54d34fced4a73d3c9f2132c76a29750e7a614","signature":"304402207d067ac09b1462289e43e701e43933580b195f40b643188e8e6330424db680de022027dff63053337a428cd8f04de675efb9aad57236c5acfad3c2b85ea7bf51efd3","message":"hello community"}

Теперь возможно проверить действительность подписавшего сообщение:

Проверка сообщения:

нажмите ПРОВЕРИТЬ укажите открытый ключ, подпись и сообщение появится сообщение о подтверждении подписи, если сообщение прошло проверку

Как вы можете видеть, с помощью открытого ключа легко возможно доказать - сообщение действительно написано тем, кто контролирует эту кодовую фразу. Это доказывает то, что я действительно написал сообщение.

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

Trusted Execution Environment SmartHoldem (TEESH) набор программных компонентов, поддерживающих на устройстве безопасную среду выполнения операций экосистемы SmartHoldem.

Состоит из:

Операционной системы (SH Trusty ОС), работающей на процессоре, поддерживающем TEE Драйверов для ядра Linux, обеспечивающих взаимодействие с приложениями, работающими под SH Trusty OS Набора библиотек для взаимодействия с доверенными приложениями, выполняемыми внутри SH Trusty OS, использующего драйверы ядра API для взаимодействия с распределенными узлами SmartHoldem из внешнего небезопасного мира

Обычно TEESH процессор — это отдельный микропроцессор в системе или виртуальный экземпляр основного процессора. TEESH процессор изолирован от остальной системы механизмами защиты памяти и операций ввода-вывода, реализованными на аппаратном уровне.

Основной процессор устройства считается «не доверенным» и не может получать доступ к определённым областям ОЗУ, аппаратным регистрам и безопасным зонам, в которых хранятся секретные данные (например — криптоключи)
Для любых операций, требующих эти секретные данные, ПО обращается к TEESH (защищенному) процессору.

Самый популярный пример всего этого в экосистеме Android — это DRM framework, используемый для защиты контента. ПО, работающее в Trusted Execution Environment процессоре, может получать доступ к специфичным для этого устройства ключам, которые нужны для расшифровки защищённого контента. При хорошо организованной защите от программных атак, основной процессор видит только зашифрованный контент.

Другие примеры использования Trusted Execution Environment: полнодисковое шифрование, многофакторная аутентификация, защита от сброса устройства, защита карт памяти, беспроводная трансляция защищённого контента, безопасная обработка PIN кодов и отпечатков пальцев.

Trusty предоставляет API для разработчиков двух классов приложений:

Доверенные приложения или сервисы, работающие на TEE процессоре Обычные/не доверенные приложения, которые работают на основном процессоре и используют сервисы, предоставляемые доверенными приложениями

ПО, работающее на основном процессоре, может использовать Trusty API для подключения к доверенным приложениям и обмениваться с ними различными сообщениями, подобно тому, как работают сетевые сервисы через IP. Используя определённый протокол, приложения определяют формат данных и семантики этих сообщений. Надёжность доставки этих сообщений гарантируется инфраструктурой, лежащей в основе Trusty (в виде драйверов, работающих на основном процессоре). Все сообщения асинхронны.

Доверенные сервисы

Доверенные приложения работают как изолированные процессы под ядром ОС Trusty. Каждый процесс работает в песочнице с собственной виртуальной памятью, которая управляется средствами MMU. Ядро распланировывает эти процессы на основе приоритетов; цикличность планирования задаётся защищённым синхронизатором тактов, все Trusty приложения имеют одинаковый приоритет.

Приложения для ОС Trusty могут быть написаны на C/C++.

Структура приложений

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

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

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

Интересно использование чипов SoC (систем на кристалле). Подробная статья тут. это и есть ASIC с спец функциями. К примеру в устройствах Android используется этот чип для обеспечения безопасной среды и хранения ключей.

Пример системы на процессоре A9

Внешние доверенные устройства

Идея вынести выполнение критических операций на отдельное специализированное устройство не нова. К критическим операциям в данном случае стоит отнести работу с ключами и контроль обрабатываемой информации, в нашем варианте это RNG. То есть в этих устройствах необходимо обеспечить генерацию ключей, выполнение криптографических операций и контроль поступаемых на обработку данных. Так же необходимо обеспечить механизм разграничения прав доступа к устройству и обеспечить неизменность исполняемого кода.
Задачу по безопасной работе с ключами достаточно давно и весьма эффективно решают смарткарты и токены с криптографией на борту. Ключи генерируются аппаратно в устройствах, криптографические операции выполняются в устройствах, ключи никогда не покидают устройств. Разграничение прав доступа наиболее часто осуществляется с помощью PIN кода. Защита исполняемой программы от модификации обеспечивается производителем чипов на аппаратном уровне. Для борьбы с атаками направленными на несанкционированное использование криптографических возможностей, развитие данных устройств идет по пути добавления функциональности контроля достоверности/целостности данных.
Реализация контроля достоверности данных, поступаемых на обработку, в доверенных устройствах может быть различной. Существует три основных механизма контроля:

Доверенный механизм ввода данных. Реализуется с помощью клавиатур ввода данных физически располагаемых на устройстве. Характерным примером являются так называемые «криптокалькуляторы», к примеру Ledger Nano S, на клавиатуре которых производится набор платежных реквизитов и затем на основе секрета устройства (или секрета платежной карты) формируется код подтверждения платежа. Основным недостатком решения является необходимость ввода данных вручную. В банковской сфере, для устранения этого неудобства, в устройство может быть добавлена функциональность хранения списка контрагентов.
Визуальный контроль данных, осуществляемый с помощью дисплея доверенного устройства. В отличии от первого способа, данные формируются в недоверенной среде, а затем отображаются на экране доверенного устройства. Корректность данных проверяет пользователь устройства. В случае подтверждения пользователем корректности данных, формируется код подтверждения.

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

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

Перспективы

Использование в генерации RNG SmartHoldem на стороне пользователя Эффективно решить поставленную задачу без некого, отдельного от основного компьютера, устройства не удается. При использовании загрузки с доверенного носителя для обеспечения безопасности ограничивается функциональность загружаемой ОС. Внешние подключаемые устройства наращивают свою функциональность.

Механизм TEE в мобильных устройствах:

0_1532266225014_Otkrytye_sistemy.SUBD_1(8049)_500.png

Источник: https://source.android.com/security/trusty/

За 3 дня до старта ICO в 2017 мной был опубликован этот твит
https://twitter.com/TechnoL0g/status/906585172203753472
это была стартовая точка в этой книге, первые участники сообщества просто поверили нам на слово, до выхода каких либо прототипов, теперь мы здесь в середине+ 2018, где каждый из вас видел как строчка за строчкой кода куётся смарт, как растёт сообщество, появляются десятки новых сервисов и обновляются созданные, многие вещи мы не успевали записывать в дорожную карту мы их просто создавали с нуля, пару недель назад мы свами запустили dex биржу, и всё это предисловие к первой главе книги SmartHoldem, которая началась с той точки в твитере 2017го...

установить $ [sudo] npm install forever -g создать файл forever.json для ваших приложений [ { "uid": "appName1", "append": true, "watch": false, "script": "index.js", "sourceDir": "/home/user/appName1/", "workingDir": "/home/user/appName1/" }, { "uid": "appName2", "append": true, "watch": false, "script": "index.js", "sourceDir": "/home/user/appName2/", "workingDir": "/home/user/appName2/" } ] Записать в cron crontab -e

добавить в файл следующую строку
@reboot /usr/local/bin/forever start /home/user/forever.json > /dev/null 2>&1