MAKArti

Не юридическая консультация ... Америка: самый креативный наркоман в мире

2021-09-05T06:34:24.768Z

Соединенным Штатам нужны десятки миллиардов долларов, и государство собирается забрать их у американского криптосообществе.
Оригинал.

МНЕНИЕ

Not Legal Advice ... - ежемесячная колонка Захари Кельмана, главного юрисконсульта Cointelegraph. Он имеет лицензию в Нью-Йорке и специализируется на политических, юридических и нормативных вопросах, связанных с биткойнами, цифровыми валютами и технологией блокчейн.

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

Ответ может заключаться во все более мощной, но часто игнорируемой силе, влияющей на принятие решений в Вашингтоне, округ Колумбия: риск суверенного долга США. С 28 триллионами долларов валового национального долга, беспрецедентной денежной эмиссией и количественным смягчением, а также десятилетиями низких процентных ставок Америка потратила большую часть своих денежных боеприпасов за последнее десятилетие. Это заставило политиков разбить стекло и позволить триллионам экстренных расходов напугать американских держателей суверенного долга, у которых внезапно появилось больше оснований опасаться некогда немыслимой перспективы краха суверенного долга Америки. В эту пустоту вступают президент Джо Байден и 117-й Конгресс США.

Связанный: О количественном смягчении, криптографии и современной монетарной теории.

Можно было бы подумать, что очевидный метод смягчения опасений держателя долга заключается в балансе за счет увеличения налоговых ставок или сокращения расходов. Однако повышение налогов и сокращение бюджета равносильно закрытию открытого бара на домашней вечеринке прямо тогда, когда становится весело. Выигрышной политической формулой здесь всегда является долговая расписка: повышение налогов расстраивает избирателей и подрывает оптимизм рынка, в то время как сокращение расходов заставляет политиков не выполнять обещания и ограничивает их доступ к соусовке. Однако, подобно умному наркоману, США всегда могут найти способ убедить назойливых казначейских держателей и держателей долговых обязательств, что Америка все еще «хороша для этого».

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

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

По теме: Давайте проясним: технология Blockchain - это инфраструктура

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

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

Захари Кельман является генеральным советником Cointelegraph. Он юрист, специализирующийся на нормативно-правовой среде, окружающей цифровую валюту и финансовые технологии, будь то получение лицензий и разработка политик соответствия в соответствии с недавно разработанными законами на Филиппинах или встреча и разработка политик с регулирующими органами Карибского бассейна. До того, как стать соучредителем Kelman PLLC, он руководил программой соответствия для Coins.ph. Закари представлял и консультировал предпринимателей по передовой юридической практике их бизнеса в сфере финансовых технологий.

#qfsn

#tanz

Британский подросток зарабатывает почти 400 тысяч долларов на продажах NFT без банковского счета

2021-09-05T06:25:18.037Z

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

Оригинал статьи.

НОВОСТИ

Сообщается, что 12-летний мальчик из Лондона заработал почти 400000 долларов, продав серию нематериальных токенов (NFT) во время школьных каникул.

В интервью Geo.tv Беньямин Ахмед поделился своим волнением по поводу возможности зарабатывать деньги в Интернете, продавая произведения искусства NFT, «не имея банковского счета». Работа Ахмеда привлекла внимание в Твиттере и в конечном итоге стала вирусной.

Ахмед использовал свои школьные каникулы для создания и токенизации цифровых изображений смайликов китов под брендом «Weird Whales», которые затем продавались в форме NFT в Интернете. Раньше ребенок токенизировал набор произведений искусства в стиле Minecraft, который не продавался на рынке из-за низкой популярности.

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

«Он очень изобретателен, у него нет банковского счета и бухгалтера, поэтому он хранит свои деньги в онлайн-блокчейне».

Более того, отец пояснил, что заявленная прибыль, полученная от продаж NFT, была конвертирована в эфир ( ETH ), независимо от колебаний цен.

По теме: чеканка, распространение и продажа NFT должны включать закон об авторском праве.

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

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

Грамотность DeFi: университеты используют децентрализованное финансовое образование

2021-09-05T06:22:05.331Z

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

АНАЛИЗ

Децентрализованные финансы, или DeFi, стали одним из самых быстрорастущих секторов криптовалютной экосистемы. Данные показывают, что общая заблокированная стоимость (TVL) во всех протоколах DeFi сейчас составляет около 130 миллиардов долларов. Это важный показатель, поскольку некоторые аналитики рассматривают TVL как один из лучших способов измерения настроений в секторе DeFi .

Хотя рост очевиден, многие люди все еще могут задаться вопросом, что такое DeFi и как его можно применить сегодня. Пирс Ридьярд, генеральный директор Radix DLT - безопасной децентрализованной сети - заявил, что DeFi в настоящее время обслуживает только пользователей с достаточным знанием рынка криптографии.

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

Где можно узнать о DeFi

Калифорнийский университет в Беркли недавно добавил массово открытый онлайн-курс, или MOOC, по децентрализованным финансам в свое семестровое предложение осенью 2021 года.

Дон Сонг, профессор электротехники и информатики в Калифорнийском университете в Беркли и основательница блокчейн-платформы Oasis Network, сказала Cointelegraph, что вместе с профессорами из Стэнфорда и Имперского колледжа Лондона будет помогать вести курс DeFi. По словам Сонга, DeFi становится принципиально новым способом построения финансовой инфраструктуры, поэтому для студентов во всем мире важно узнать об этой теме:

«Около 300 студентов, изучающих информатику и финансы, записались на курс, но, учитывая огромный интерес DeFi, мы также предлагаем версию MOOC, открытую для всех во всем мире. В общей сложности более 1400 студентов записались на курс DeFi в Беркли ».

Сонг упомянул, что Калифорнийский университет в Беркли ранее предлагал более короткий и более экспериментальный курс DeFi в течение весеннего семестра 2021 года. Она объяснила, что благодаря успеху и интересу этого класса университет теперь предлагает полный семестровый курс, охватывающий наиболее важные концепции DeFi.

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

Сонг отметил, что курс DeFi будет полностью удаленным из-за ограничений COVID-19, но что учебная программа будет одинаковой как для студентов Калифорнийского университета в Беркли, так и для участников класса MOOC. Тем не менее, она упомянула, что студенты Беркли будут проводить больше курсовой работы, например, завершать открытые классные проекты и получать практический опыт разработки новых технологий в пространстве DeFi. Невозаменяемые токены или NFT будут выдаваться в качестве сертификатов тем, кто завершит курс.

Связано: для поступления в колледжи курсов по криптовалюте и блокчейну требуется специальная рабочая сила.

Хотя курс DeFi в Калифорнийском университете в Беркли может быть одним из первых в своем роде, примечательно, что MOOC открыт для всех во всем мире. «У нас есть студенты из Европы, Индии, Азии и других регионов за пределами США», - сказал Сонг. Оставаясь верной открытым, инклюзивным стандартам DeFi, она добавила, что цель курса Berekely DeFi - объединить онлайн-участников со студентами, зарегистрированными в Беркли, чтобы создать более крупное сообщество, одновременно улучшая технологии в космосе.

Вайоминг, один из ведущих штатов по инновациям в области блокчейнов, также предлагает обучение по DeFi студентам Университета Вайоминга. Али Неджадмалаери, профессор финансов в Университете Вайоминга, сказал Cointelegraph, что университет предлагает второстепенный блокчейн и что различные дисциплины в этом секторе можно изучать в виде курсов.

Например, Неджадмалайери преподает курс «Блокчейн и финансовые услуги», который представляет собой онлайн-класс на целый семестр, который содержит часть по концепциям DeFi:

«Первая часть этого курса в весеннем семестре была посвящена введению и обзору сектора блокчейнов. Второй модуль был посвящен сфере цифровых денег, которая включала ранние эксперименты с электронными деньгами и цифровыми валютами центральных банков. DeFi была последней частью, где мы обсуждали такие платформы, как Uniswap и Aave, а также различные приложения ».

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

«У вас есть люди, которые умеют программировать, но продукты DeFi должны быть ориентированы на определенную клиентуру. Внутренние знания об этих конкретных отраслях важны и поэтому будут в центре внимания многих из этих классов ».

Несмотря на то, что Соединенные Штаты занимают в качестве ведущего региона для принятия Defi по данным разведки крипто фирмы Chainalysis, европейские университеты и школа также предлагают Defi курсы для внедрения инноваций.

Например, Университет Никосии (UNIC) на Кипре предлагает бесплатный MOOC DeFi начиная с 11 октября. Джордж Джаглис, исполнительный директор Института будущего в UNIC, сказал Cointelegraph, что, хотя UNIC предлагает бесплатный вводный курс по криптовалюте и блокчейн с 2013 года, DeFi освещается лишь кратко. Тем не менее, учитывая успех курса, который привлек более 45 000 студентов из разных стран, UNIC теперь предлагает шестинедельный онлайн-курс, полностью посвященный DeFi.

Джаглис поделился, что учебная программа курса будет охватывать все основы DeFi: «Это включает в себя полный стек приложений DeFi (децентрализованные биржи, автоматизированное создание рынка, кредитование и заимствование, добыча ликвидности, выращивание урожая, децентрализованное страхование, синтетические активы, оракулы, стейблкоины), управление , токеномика, DAO ». Хотя курс полностью бесплатный, Джаглис отметил, что для выпускников, которые хотят получить выданный UNIC сертификат об окончании, который можно проверить с помощью блокчейна, взимается дополнительная плата.

В дополнение к UNIC, Европейская техническая школа, которая была запущена в июле и предлагает две программы блокчейна, также подробно обсуждает DeFi. Виктория Гаго, со-генеральный директор Европейской технической школы, сообщила Cointelegraph, что как курс Blockchain Executive Program, так и Certified Blockchain Expert Course содержат модуль DeFi, преподаваемый Моникой Сингер, руководителем ConsenSys в Южной Африке.

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

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

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

Проблемы обучения DeFi

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

Например, разработка учебной программы, посвященной наиболее актуальным темам в DeFi, может быть проблематичной. Неджадмалайери объяснил, что в весеннем семестре 2021 года ему пришлось изменить все в своем курсе по блокчейну и финансовым услугам, поскольку DeFi начал набирать обороты: «Мне пришлось отказаться от многих своих лекций и заменить их концепциями DeFi».

По теме: Идеальный шторм: взломы DeFi продвинут криптосектор вперед

Повторяя эту озабоченность, Джаглис отметил, что разработка учебной программы может быть сложной задачей, когда почти не на что полагаться и когда сектор буквально меняется день ото дня: «Достаточно сказать, что мы не считаем материал окончательным на любом этапе: мы вносят и будут продолжать вносить изменения, чтобы отразить новые события до (и после) даты каждой сессии ».

Тем не менее, участники отрасли считают, что курсы DeFi никуда не денутся и станут неотъемлемой частью дальнейшего образования. Например, Алекс Тапскотт, автор и преподаватель серии курсов Coursera по специализации Blockchain Revolution Specialization, сказал Cointelegraph, что по мере роста индустрии DeFi спрос на образовательный контент также будет расти:

«На заре Биткойн школы, такие как Корнелл и Беркли, начали предлагать курсы по этой теме. Я не удивлюсь, если DeFi станет частью учебной программы каждой программы MBA в будущем. Мы еще очень рано ».

В дополнение к этому Кимберли Грауэр, директор по исследованиям в Chainalysis, сказала Cointelegraph, что курсы DeFi будут постоянной тенденцией во многих университетах, наряду с возможным включением других курсов, связанных с криптографией: «В этом смысле DeFi действует как фундаментальный строительный блок. для более широкого круга занятий ».

Abstract Datagram Network Layer (ADNL)

2021-08-22T23:12:26.838Z

Abstract Datagram Network Layer (ADNL)

Краеугольным камнем в создании сетевых протоколов TON является ADNL. Он позволяет всем узлам принимать определенные «сетевые идентификаторы», представленные 256-битными «абстрактными сетевыми адресами», и обмениваться данными (отправлять датаграмы друг другу, в качестве первого шага), используя только эти 256-битные сетевые адреса для идентификации отправителя и получатель. В частности, не нужно беспокоиться об адресах IPv4 или IPv6, номерах портов UDP и т.д., они скрыты абстрактным сетевым уровнем.

3.1.1. Абстрактные сетевые адреса

Абстрактный сетевой адрес, или просто адрес для краткости, является 256-битным целым числом равным 256-битному публичному ключу ECC. Этот публичный ключ может быть сгенерирован произвольно, таким образом создавая столько сетевых идентификаторов, сколько нравится узлу. Однако для получения (и расшифровки) сообщений, предназначенных для такого адреса, необходимо знать соответствующий закрытый ключ. Фактически, адрес не является открытым ключом; вместо этого это 256-битный хэш (Hash = sha256) сериализованного TL-объекта, который может описывать несколько типов открытых ключей и адресов в зависимости от его конструктора (первые четыре байта). В простейшем случае этот сериализованный TL-объект состоит из 4-байтового магического числа и 256-битного открытого ключа криптографии с эллиптической кривой (ECC); в этом случае адрес будет равен хешу этой 36-байтовой структуры. Однако можно вместо этого использовать 2048-битные ключи RSA или любую другую схему криптографии с открытыми ключами. Когда узел узнает абстрактный адрес другого узла, он также должен получить свой «образ» (т.е. сериализованный TL-объект, хэш которого равен этому абстрактному адресу), иначе он не сможет шифровать и отправлять датаграммы на этот адрес.

3.1.2. Сети более низкого уровня

Реализация UDP. С точки зрения почти всех сетевых компонентов TON, единственное, что существует, - это сеть (сетевой уровень абстрактных датаграмм), способная отправлять датаграмы с одного абстрактного адреса на другой. В принципе, абстрактный сетевой уровень датаграм (ADNL) может быть реализован в различных существующих сетевых технологиях. Однако мы собираемся реализовать его по протоколу UDP в сетях IPv4 / IPv6 (таких как Интернет или интрасети), с необязательным запасным вариантом TCP, если UDP недоступен.

3.1.3. Простой вариант использования ADNL по UDP

Простейший случай отправки датаграм с абстрактного адреса отправителя на любой другой абстрактный адрес (с известным изображением) может быть реализован следующим образом. Предположим, что отправитель каким-то образом знает IP-адрес и UDP-порт получателя, которому принадлежит абстрактный адрес назначения, и что и получатель, и отправитель используют абстрактные адреса, полученные из 256-битных открытых ключей ECC. В этом случае отправитель просто добавляет датаграм для отправки своей подписью ECC (выполненной с помощью своего закрытого ключа) и адресом своего источника. Результат шифруется открытым ключом получателя, встраивается в датаграму UDP и отправляется на известный IP-адрес и порт получателя. Поскольку первые 256 бит датаграмы UDP содержат абстрактный адрес получателя, получатель может определить, какой закрытый ключ следует использовать для расшифровки оставшейся части датаграмы. Только после этого раскрывается личность отправителя.

3.1.4. Менее безопасный способ, с адресом отправителя в тексте

Иногда недостаточно безопасной схемы, когда адреса получателя и отправителя хранятся в незашифрованном виде в дейтаграмме UDP; закрытый ключ отправителя и открытый ключ получателя объединяются вместе с помощью ECDH (эллиптическая кривая Диффи-Хеллмана) для генерации 256-битного общего секрета, который используется впоследствии, наряду со случайным 256-битным одноразовым номером, также включенным в незашифрованную часть, получить ключи AES, используемые для шифрования. Целостность может быть обеспечена, например, путем объединения хеша исходных данных открытого текста в открытый текст перед шифрованием. Преимущество этого подхода состоит в том, что если ожидается обмен более чем двумя датаграмами между двумя адресами, общий секрет может быть вычислен только один раз, а затем кэширован, тогда более медленные операции эллиптической кривой больше не будут требоваться для шифрования или дешифрования следующих датаграм.

3.1.5. Каналы и идентификаторы каналов

В простейшем случае первые 256 бит датаграммы UDP, несущей встроенную дейтаграмму TON ADNL, будут равны адресу получателя. Однако в целом они составляют идентификатор канала. Существуют разные типы каналов. Некоторые из них являются двухточечными; они создаются двумя сторонами, которые желают обмениваться большим количеством данных в будущем и генерировать общий секрет путем обмена несколькими пакетами, зашифрованными, путем запуска классической или эллиптической кривой Диффи-Хеллмана (если безопасность), или просто одна сторона генерирует случайный общий секрет и отправляет его другой стороне. После этого идентификатор канала извлекается из общего секрета в сочетании с некоторыми дополнительными данными (такими как адреса отправителя и получателя), например, путем хеширования, и этот идентификатор используется в качестве первых 256 битов датаграм UDP, переносящих данные, зашифрованные с помощью помощь этого общего секрета.

3.1.6. Канал как идентификатор туннеля

В общем, «канал» или «идентификатор канала» просто выбирает способ обработки входящей датаграммы UDP, известный получателю. Если канал является абстрактным адресом получателя, обработка выполняется, если канал является установленным двухточечным каналом, обработка состоит в расшифровке датаграммы с помощью общего секрета. В частности, идентификатор канала может фактически выбрать «туннель», когда непосредственный получатель просто пересылает полученное сообщение кому-то другому - фактическому получателю или другому прокси. Некоторые этапы шифрования или дешифрования (напоминающие «луковую маршрутизацию» или даже «чесночную маршрутизацию») могут быть выполнены по пути, и другой идентификатор канала может быть использован для перешифрованных переадресованных пакетов (например, одноранговая маршрутизация). Равноправный канал может использоваться для пересылки пакета следующему получателю на пути). Таким образом, некоторая поддержка «туннелирования» и «прокси» - что-то вроде того, что обеспечивается проектами TOR или I2P - может быть добавлена на уровне сетевого уровня абстрактных дейтаграмм TON, не затрагивая функциональность всех высших сетевые протоколы уровня TON, которые были бы независимы от такого дополнения. Эта возможность используется службой TON Proxy.

3.1.7. Нулевой канал и проблема начальной загрузки

Обычно TON ADNL будет иметь некоторую «таблицу соседей», содержащую информацию о других известных узлах, таких как их абстрактные адреса и их прообразы (то есть открытые ключи), а также их IP-адреса и порты UDP. Затем он будет постепенно расширять эту таблицу, используя информацию, полученную из этих известных узлов, в качестве ответов на специальные запросы, а иногда и удалять устаревшие записи. Однако, когда узел TON ADNL только запускается, может случиться так, что он не знает ни одного другого узла и может узнать только IP-адрес и UDP-порт узла, но не его абстрактный адрес. Это происходит, например, если легкий клиент не может получить доступ ни к одному из ранее кэшированных узлов и к любым узлам, жестко закодированным в программное обеспечение, и должен попросить пользователя ввести IP-адрес или DNS-домен узла, который необходимо разрешить через DNS. В этом случае узел будет отправлять пакеты на специальный «нулевой канал» рассматриваемого узла. Это не требует знания открытого ключа получателя (но сообщение все равно должно содержать личность и подпись отправителя), поэтому сообщение передается без шифрования. Обычно его следует использовать только для получения идентификатора (возможно, единовременного идентификатора, созданного специально для этой цели) получателя и затем для начала более безопасной связи. Как только хотя бы один узел известен, можно легко заполнить «таблицу соседей» и «таблицу маршрутизации» большим количеством записей, изучая их на основе ответов на специальные запросы, отправленные на уже известные узлы. Не все узлы требуются для обработки дейтаграмм, отправленных на нулевой канал, но те, которые используются для начальной загрузки легких клиентов, должны поддерживать эту функцию.

3.1.8. TCP-подобный стриминговый протокол поверх ADNL

ADNL, являющийся малым протоколом датаграмм на основе 256-битных абстрактных адресов может использоваться в качестве основы для более сложных сетевых протоколов. Можно создать, например, TCP-подобный потоковый протокол, используя ADNL в качестве абстрактной замены IP. Однако большинству компонентов проекта TON такой потоковый протокол не нужен.

3.1.9. RLDP или надежный протокол больших датаграмм поверх ADNL

Надежный протокол датаграмм произвольного размера, построенный на ADNL, называемый RLDP, используется вместо протокола, подобного TCP. Этот надежный протокол датаграмм может использоваться, например, для отправки запросов RPC удаленным хостам и получения от них ответов.

TON: Telegram Open Networ.

2021-08-22T23:06:56.753Z

TON: Telegram Open Network. Часть 1: Вступление, сетевой уровень, ADNL, DHT, оверлейные сети

Уже две недели Рунет шумит про Telegram и ситуацию с его бессмысленной и беспощадной блокировкой Роскомнадзором. Рикошетом задело многих, но всё это — темы для постов на Geektimes. Меня же удивило другое — я до сих пор не видел на Хабре ни одного разбора запланированной к выходу на базе Telegram сети TON — Telegram Open Network. Мне захотелось восполнить этот недостаток, ибо поизучать там есть что — даже несмотря на отсутствие официальных заявлений о нём.

Напомню — ходят слухи о том, что Telegram запустил очень масштабное закрытое ICO, уже собрав в нём невероятные суммы. Предполагается, что уже в этом году будет запущена собственная криптовалюта Gram — и у каждого пользователя Телеграма автоматически появится кошелёк, что само по себе создает немалое преимущество перед остальными криптовалютами.

К сожалению, так как официальных заявлений нет, дальше я могу отталкиваться только от документа неизвестного происхождения, о чём я сразу вас предупреждаю. Конечно, он может оказаться очень искусной подделкой, но не исключено и то, что это — реальный whitepaper будущей системы, написанный Николаем Дуровым (и слитый, вероятно, кем-то из инвесторов). Но даже если это фейк, никто нам не запретит его поизучать и обсудить, верно?

Что же говорится в этом документе? Я попробую пересказать его своими словами, близко к тексту, но по-русски и чуть более человечно (да простит меня Николай со своей склонностью уходить в формальную математику). Имейте в виду, что даже в случае его подлинности, это черновое описание системы и оно, весьма вероятно, изменится к моменту публичного запуска.

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

TON Blockchain. Это основа всей системы. Если вы совсем не знаете, что такое блокчейн — рекомендую узнать, потому что тут блокчейнов будет много. Вложенные друг в друга, виртуально раздроблённые и даже «вертикальные» блокчейны внутри блоков других блокчейнов. А ещё тут будет несколько круто звучащих терминов типа Instant Hypercube Routing и Infinite Sharding Paradigm, но об этом позже. И, конечно, proof-of-stake и смарт-контракты.
TON P2P Network. Пиринговая сеть, на основе которой будет построена работа системы. О ней в первую очередь пойдёт речь в этой части повествования.
TON Storage. Файловое хранилище, которое независимо от блокчейна будет построено на вышеупомянутой пиринговой сети. Можно сравнить с торрентами.
TON Proxy. Это сервис, цель которого — повысить анонимность участников сети. Любой пакет можно отправить не напрямую, а через туннели-посредники с дополнительным шифрованием — подобно I2P или TOR.
TON DHT. Распределенная хэш-таблица для хранения произвольных значений. Она тоже построена поверх TON Network (но при этом используется им же) и помогает TON Storage находить «раздающие» узлы, а TON Proxy — промежуточные ретрансляторы. Но нужно отметить, что, в отличие от блокчейна, эта хэш-таблица не является защищённым хранилищем — хранить важную информацию в ней нельзя.
TON Services. Платформа для произвольных сервисов. По сути — это новый интернет поверх всего вышеописанного. Обмен данными — через TON Network/TON Proxy, а логика — в смарт-контрактах самого TON Blockchain. И интерфейс с довольно привычными URL.
TON DNS. Раз уж зашла речь про привычные URL, нужен и преобразователь из них в 256-битные адреса — аккаунтов, контрактов, сервисов и узлов.
TON Payments. И вот только тут затрагивается денежный вопрос. И это будет не только gram — как с эфиром, будут возможны любые «токены»; грамы тут будут всего лишь валютой «по умолчанию».

Это первая часть, описывающая «приземлённый» уровень TON — его сетевую часть, строящуюся поверх традиционных протоколов. В следующей части речь пойдёт про «мякотку» — блокчейн, который будет поддерживаться описанной далее системой. Таким образом, мой порядок пересказа несколько отличается от использованного в вышеупомянутом документе (который начинается сразу с абстрактного уровня).

Базовые понятия

TL (Type Language). Это абстрактный бинарный формат для произвольных структур данных. Он используется в протоколе Телеграма и будет активно использоваться в TON. Если хотите подробно ознакомиться с ним — вот его описание.

Хэш (hash). Функция, производящая необратимое преобразование произвольной структуры данных в единственное число фиксированной длины. В рамках документации повсеместно идёт речь о функции SHA-256.

Узел сети (node). Узел — это ПО, которое будет обеспечивать работу системы. В частности, предполагается, что каждое клиентское приложение Телеграма будет включать в себя узел TON'а. На низком уровне узлы имеют IPv4/IPv6-адреса и общаются по протоколу UDP, на более высоком — обладают абстрактными адресами и реализуют протокол ADNL (об абстрактных адресах и ADNL — см. ниже). Когда речь идёт о том, что какие-то части системы что-то делают или хранят какие-то данные — подразумевается, что это делают узлы сети.

Абстрактный адрес (или просто адрес, address). Адрес узла определяется его публичным ключом. Более строго — это 256-битный хэш (SHA256) от структуры данных, содержащей публичный ключ (конкретный криптографический алгоритм при этом не уточняется — в качестве примера приводятся эллиптические кривые и RSA-2048). Чтобы один узел мог взаимодействовать с другим, ему нужно знать не только адрес того, но и эту структуру данных. Теоретически один физический узел может создать любое количество адресов (соответствующих разных ключам).

Далее часто используется именно такая связка: «прообраз» в виде TL-структуры (содержащей практически любые данные), и 256-битный хэш от неё, используемый для адресации.

Блокчейн (blockchain). Блокчейн — это структура данных, элементы (блоки) которой упорядочены в «цепь», и каждый следующий блок цепи содержит в себе хэш предыдущего. Таким образом достигается целостность — изменения могут вноситься только добавлением новых блоков.

Сервис (service). Сервисы в рамках TON могут быть различных типов — в зависимости от того, используют они блокчейн или нет. Например, один (или множество) из узлов сети может обрабатывать некие RPC-запросы по описанному далее протоколу ADNL, не создавая никаких записей в блокчейне — наподобие традиционных веб-серверов. В том числе рассматривается возможность реализации HTTP поверх ADNL, а также переход самого мессенджера на этот протокол. По аналогии с TOR или I2P, это сделает его более устойчивым к различным блокировкам.

В то же время, ряд сервисов подразумевает и взаимодействие с блокчейном, и обработку запросов вне его. Например, для TON Storage — файлового хранилища — не очень разумно хранить сами файлы в блокчейне. В нём будут содержаться только хэши файлов (вместе с какой-то метаинформацией о них), а в качестве «файловых серверов» будут выступать специализированные узлы сети, готовые отдавать их другим узлам по ADNL.

Туманный сервис (fog service). Речь идёт о некоторых сервисах, которые подразумевают децентрализацию и открытое участие в них. Например, TON Proxy — это сервис, который может поддерживать любой участник, желающий предоставить свой узел в качестве посредника (прокси), пересылающего пакеты между другими узлами. При желании он может взымать за это установленную им плату — используя систему TON Payments для микроплатежей (которая, в свою очередь, тоже является туманным сервисом).

ADNL: Abstract Datagram Network Layer

На самом низком уровне взаимодействие между узлами будет производиться по протоколу UDP (хотя допустимы и другие варианты).

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

Кроме того, вместо адреса получателя в начале пакета данных может находиться т.н. идентификатор канала. В таком случае обработка пакета уже зависит от конкретных договорённостей между узлами — например, отправленные в некий канал данные могут предназначаться другому узлу и должны быть ему переадресованы (это и есть сервис TON Proxy). Другим частным случаем может быть взаимодействие напрямую между узлами, но с шифрованием по индивидуальной паре ключей для этого канала (предварительно сформированных по протоколу Диффи-Хеллмана).

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

Вышеописанный протокол (256 бит идентификатора канала + содержимое пакета) называется ADNL. Документация упоминает возможность реализации аналога TCP поверх него или собственной надстройки — RLDP (Reliable Large Datagram Protocol), но не вдается в подробности об их реализации.

TON DHT: Распределённая хэш-таблица

Как в случае с другими распределёнными системами, TON предполагает реализацию DHT — распределённой хэш-таблицы. Более конкретно — таблица является Kademlia-подобной. Если вы не знакомы с такой разновидностью хэш-таблиц — не беспокойтесь, далее я примерно опишу, как они устроены.

В абстрактном смысле, DHT ставит в соответствие 256-битным ключам некие бинарные значения произвольной длины. При этом ключи в таблице — это хэши от определённой TL-структуры (сами структуры тоже хранятся вместе с DHT). Это очень похоже на формирование адресов узлов — и они действительно могут присутствовать в DHT (например, по такому ключу может находиться IP-адрес узла соответствующего заданному абстрактному адресу, если он не скрывает его). Но в общем случае, «прообразы ключей» (их описания, key descriptions) — это метаданные, которые указывают на «владельца» записи в хэш-таблице (то есть публичный ключ какого-то узла), тип хранимого значения и правила, по которым эта запись может впоследствии изменяться. Например, правило может разрешать изменять значение только владельцу — или запрещать изменение значения в меньшую сторону (чтобы защититься от replay-атак).

Кроме 256-битных ключей вводится понятие DHT-адресов. Разница с обычными адресами узлов в том, что DHT-адрес обязательно привязан к IP-адресу. Если узел не скрывает своего IP, он может использовать обычный адрес для DHT. Но чаще для нужд DHT будет заводиться отдельный, «полу-постоянный» адрес.

Над ключами и DHT-адресами вводится понятие расстояния — в этом всё совпадает с таблицами Kademlia — расстояние между ключами равно XOR (побитовому исключающему ИЛИ) от них. Как и в таблицах Kademlia, значение, соответствующее некоему ключу, должно храниться на s узлах, имеющих наименьшее расстояние до этого ключа (s тут — относительно небольшое число).

Для того, чтобы узел DHT мог взаимодействовать с другими такими узлами, он держит в памяти таблицу маршрутизации DHT — DHT- и IP-адреса узлов, с которыми он взаимодействовал до этого, сгруппированные по расстоянию до них. Таких групп 256 (они соответствуют старшему выставленному биту в значении расстояния — то есть узлы на расстоянии от 0 до 255 попадут в одну группу, от 256 до 65535 — в следующую, и т.д.). Внутри каждой группы хранится ограниченное число «лучших» узлов (в плане пинга до них).

Каждый узел должен поддерживать несколько операций: сохранение значения для ключа, поиск узлов и поиск значений. Поиск узлов подразумевает выдачу по заданному ключу ближайших к нему узлов из таблицы маршрутизации; поиск значений — то же самое, за исключением ситуации, когда узлу известно значение для ключа (тогда он просто возвращает его). Соответственно, если узел хочет найти в DHT значение по ключу, он посылает запросы небольшому числу ближайших к этому ключу узлов из своей таблицы маршрутизации. Если среди их ответов нет искомого значения, но есть другие адреса узлов, то запрос повторяется уже к ним.

TON DHT может использоваться для различных целей, например — для реализации торрент-подобного хранилища файлов (см. TON Storage); для определения адресов узлов, реализующих определённые сервисы; для хранения информации о владельцах аккаунтов в блокчейне. Но самое важное применение — обнаружение узлов по их абстрактным адресам. Для этого адрес используется в качестве ключа, значение которого нужно найти. В результате запроса либо найдётся сам узел (если искомый адрес был его полу-постоянным DHT-адресом), либо значением окажется IP-адрес и порт для подключения — или же другой адрес, который следует использовать в качестве тоннеля-посредника.

Оверлейные сети в TON

Описанный выше протокол ADNL подразумевает возможность любым узлам обмениваться информацией друг с другом — правда, не обязательно оптимальными путями. Можно сказать, что благодаря ADNL все узлы образуют глобальный граф TON (в идеале — связный). Но дополнительно предусмотрена возможность создавать оверлейные сети — подграфы внутри этого графа.

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

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

Оверлейные сети могут быть публичными и приватными. Стать участником публичной сети несложно — нужно найти TL-структуру, описывающую её (она может быть публичной — или доступна по определённому ключу в DHT). В случае с приватной сетью эта структура должна быть известна узлу заранее.

Продолжение следует

DeBot Specifications

2021-03-03T06:43:38.494Z

Objective

Provide a secure and convenient environment to work with smart-contracts

emulate calling smart-contract functions locally on the client
debug blockchain transactions
interact with smart-contracts deployed in the blockchain

Basic terms

DeBot — a smart contract facilitating conversation-like flow communication with a target smart contract.
Target smart contract - a smart contract for which DeBot is created. DeBot is an interface to this smart contract.
DeBot browser - a program that executes DeBot and parses its answer using DeBot protocol.
DeBot protocol — a set of rules describing the communication between browser and DeBot: how to call DeBot functions and how to interpret its answers.

Architecture

DeBot platform consists of the following elements:

DeBot smart contract;
DeBot browser;
Target smart contract(s)

One target smart contract can have several DeBots and vise versa. DeBot is deployed to the blockchain. DeBot browser runs on client. It downloads DeBot code and runs it inside the engine.

Proof of State

Transactions can be verified by running DeBot locally and comparing the result of execution to the account state in the blockchain.

DeBot Interfaces

Motivation

DeBot is a smart contract and smart contracts are isolated from each other and from the blockchain, their capabilities are limited by the commands of the virtual machine on which they are executed. But DeBots must have more possibilities. DeBots need to:

receive input from users;
query info about other smart contracts;
query transactions and messages;
receive data from external subsystems (like file system) and external devices (like NFC, camera and so on);
call external function libraries that allow to do operations that are not supported by VM. For example, work with json, convert numbers to string and vice versa, encrypt/decrypt/sign data.

To cover all these needs we should design different DeBot Interfaces (DInterfaces) which can be used in DeBots and which must be supported in DeBots Browsers. These interfaces should match the requirements:

comprehensive - interfaces should describe all types of communication accessible on modern devices;
universal - interfaces should be abstract from certain OS and hardware;
atomic - every communication channel should be separately described in the interface for further flexible resource access management
convenient - even low-skilled developers should be able to use this interface in their DeBots

In this model DeBot Engine should act like a proxy between DeBot Browser and DeBot. But it can have builtin implementation of very basic DInterfaces (e.g. working with json).

Also, we need to describe the manifest for DeBots. DeBot developer will describe all needed interfaces in this manifest and the DeBot Browser will check it before running DeBot. We need this manifest to keep users secure and private when using DeBots.

Description

Every DeBot must declare which DInterfaces it will use. For this purpose it must have getRequiredInterfaces() function which returns array of required interfaces.

Every interface must have an id which is an unsigned 256-bit integer and an address which is used in DeBots as a destination address of internal messages. Address must be a standard TON address consisting of DEBOT_WC (equal to 0xDB) as a workchain_id part and interface id as address part (see "Telegram Open Network Blockchain" specification, section 3.1.2 for details about TL-B scheme for address).

For example, in solidity getRequiredInterfaces can be implemented like this:

// Base contract for all debots
abstract contract Debot {

	i32 constant DEBOT_WC = -31;

	function getRequiredInterfaces() virtual returns (uint256[] interfaces); 

}

contract DebotA is Debot {

	function getRequiredInterfaces() override returns (uint256[] interfaces) {
    return [ID_TERMINAL, ID_MENU, ...];
	}

}

How to use DInterface in DeBot

To use an interface DeBot should import source file with DInterface declaration and call its methods as any other smart contract methods in TON - by sending internal messages to interface address.

Before running the DeBot, DeBot Browser should provide callbacks for DEngine to receive all requests to DInterfaces. Requests are packed into internal messages. When Browser receives a message from DEngine it should unpack the message, decode its body, call DInterface function, pack results to internal message and return it to DEngine using Dengine.send(msg).

interface BrowserCallbacks {
  // Message from Debot to Browser with encoded DInterface call
	send(message: string) -> Promise<void>
	// Request from Dengine to approve some action (for example, send mesage to blockchain)
	approve(action: {}) -> bool
	// Request from Debot to call another debot
	invoke(debotAddress: string, message: string) -> Promise<void>
}

DeBot Start

Before starting the DeBot, DeBot Browser creates new instance of DEngine with address of DeBot.
DEngine downloads DeBot state, queries list of DInterfaces required by DeBot and returns the list to Browser.
Browser must check that it supports all required DInterfaces. If one of interfaces is not supported, Browser must report error to the user (application) and not start the DeBot otherwise Browser must list requested interfaces to user (application).
All required interfaces should be approved by user (application).
After the list of interfaces is approved, the DeBot Browser starts DeBot using Dengine.start(callback).

On every interface call Browser should check permission for DeBot and on success execute it according to isolation requirement if needed.

Below you can see DeBot start sequence:

DInterface specification

Every DInterface must be discussed and accepted by DeBot Interface Specifications (DIS) Consortium before it can be used in DeBots. All accepted interfaces are published in repo:

https://github.com/tonlabs/DeBot-IS-consortium

Everybody can suggest new DInterface. Go to repo and follow the instructions.

DInterfaces support in DeBot Browser

DeBot Browser can support and implement any or all DInterfaces published in DIS repo depending on browser's capabilities. For example, console browser cannot support external devices like camera, NFC, microphone and so on.

DEngine versioning

DEngine as a SDK module should have a version of SDK itself.

DIS statuses: Proposed, Accepted, Published.

Example of DInterface

Name:

RawInput

ID:

8796536366ee21852db56dccb60bc564598b618c865fc50c8b1ab740bba128e3

Description

Allows to get string from user

Functions

Function input

arguments:

answerId: uint32 - function id of result callback

prompt: bytes - string printed to the user and describing what to enter

returns:

text: bytes - string entered by user

Declaration in Solidity

interface IRawInput {
	function input(uint32 answerId, string prompt) external returns (string value);
}

Library RawInput {
	uint256 constant ID_RAWINPUT = 0x8796536366ee21852db56dccb60bc564598b618c865fc50c8b1ab740bba128e3
	// Callback Function Prototype
	function inputResult(uint32 answerId, string prompt) public {
		address addr = address.makeAddrStd(DEBOT_WC, ID_RAWINPUT);
		IRawInput(addr).input(answerId, prompt);
	}
}

Declaration in C++

namespace tvm { namespace schema {

__interface IRawInput {
  [[internal, answer_id]]
  string input(string prompt);
};

Code Example

Solidity

pragma solidity >=0.6.0;
import "Debot.sol";
import "RawInput.sol";

contract ExampleDebot is Debot, RawInput {
	function start() public {
		RawInput.input(tvm.functionId(inputResult), "enter your name:");
		RawInput.input(tvm.functionId(inputResult), "enter your wallet address:");
	}

	function inputResult(string text) public override {
			require(text == "Debot");
	}

}

DeBot Special Features

DeBots have 3 special features:

calling get-methods of target smart contracts;
calling external functions of target smart contracts onchain;
invoking other DeBots in a local environment.

Ordinary TON smart contracts cannot use 1st and 2nd features because they cannot produce external inbound messages. But DeBots can, due to the fact that they are executed in DEngine, that allows DeBots to generate these kinds of messages, can send them to blockchain and return results to DeBots.

In terms of DeBots, all these features are implemented without DInterfaces but in a native way, like two smart contracts communicating with each other - by sending messages directly to target address.

But with only one difference - to call a get-method or call a function onchain DeBot must generate external inbound message.

Get-methods

Developer Example

// Solidity

function foo() public {
	IWallet(addr).getOwner{external: true, funcid: tvm.functionId(setOwner)}();
}

function setOwner(address owner) public {
	// Types and names of parameters should be equal 
	// to those returned by get-method `getOwner`
}
// C++

void foo() {
	address owner = co_await IWallet(*wallet_addr_).run().getOwner();
}

Support in DEngine

DEngine executes DeBot and checks if it produces external inbound messages. If yes then DEngine analyzes each message by scanning signature and public key bits in message body to understand if message is for get-method call. If bits are zero DEngine downloads target contract and runs its get-method, then returns results to DeBot by calling its function with id placed in expire header of message body.

Onchain function call

Developer example

Remark for Solidity : for now developers should use combination of two functions:

TvmCell msg = tvm.createExtMsg({
	dest: <addr>,
	time: now(),
	expire: 123,
	pubkey: <pubkey>,
	call: {IWallet.transfer, dest, amount}
});
tvm.sendrawmsg(msg);

Support in DEngine

DEngine executes DeBot and checks if it produces external inbound messages. If there is one DEngine analyzes if it is onchain call by scanning signature and public key bits in message body. If signature bit is 1 then DEngine does the following things.

Downloads target smart contract and emulates its transaction locally.
Checks if transaction produces outbound internal messages with funds.
Requests permission from DeBot Browser to send this message onchain. Request contains information about funds that will be spent if message will be executed onchain and message itself.
If DeBot Browser allows to send message then it must sign it and return signed message to DEngine.
DEngine sends message to blockchain.

Invoking DeBots

DeBot can call another DeBot by simply sending internal message to it.

After DeBot execution DEngine filters all internal messages produced by DeBot with destination addresses with workchain 0. This filter allows to separate DInterface calls (which have 0xDB workchain id) from DeBot invokes. If there are invoke messages, DEngine packs them into Invoker Interface request and sends request to Browser which must download target DeBot, call its function and return results back to DEngine.

Security notes

At start DeBot returns list of required DInterfaces to Browser through DEngine.

When DeBot is running, DEngine proxies all DInterface calls (except calls to builtin interfaces supported by engine itself like SDK calls) directly to Browser which must decide to execute or reject them.

Get-method calls are always allowed. Executed by DEngine.

External function calls must be approved by Browser. Executed by DEngine.

Other DeBots calls are always allowed. But executed by Browser which can block invoke if needed.

DECENTRALIZEDePool Specifications

2021-03-03T06:08:48.405Z

DECENTRALIZEDePool Технические характеристики

2020 (c) TON Venture Studio Ltd

Background

It is quite evident that to achieve high-performance properties, a network needs powerful, reliable servers with fast connectivity. At the same time, to achieve sufficient decentralization, these servers have to belong to as many owners as possible. There seems to be a contradiction between these goals.

In Proof-of-Work networks, performance is often sacrificed for decentralization. Yet, claims arise that the centralization of Bitcoin, Ethereum etc. mining power is not entirely prevented. Mining Pools centralization remains an issue, as these pools are controlled by particular entities distributing rewards. For example, almost 60% of Bitcoin mining power is concentrated in just 4 pools and around 80% of all mining power originates in China. Just 2 mining pools control 52% of Ethereum hashrate, more than 50% of which originates in China.

In Proof-of-Stake, the correlation between network performance and concentration of power (money in this case) is even more apparent, as one does not need to buy, set up, and manage complicated mining farms. It can ultimately be claimed that POS is trading performance for decentralization (look no further than EOS centralization, Steemit network overtaking etc.).

It seems that enabling small token holders to participate in network governance is a very important decentralization property.

Motivation

TON blockchain needs all newly created blocks to be validated in order to run correctly. For this it relies on special designated nodes called "Validators", and offers substantial reward for their work. However, becoming a validator requires a substantial cryptocurrency deposit. The required amount might far exceed an individual validator budget. On the other hand, blockchain users with no validating system might be interested in investing in validation duty. This is where the Decentralized Pool (DePool) smart contract comes in.

There are two main use cases of DePool:

User has no Validator capabilities but some free funds. User can support a third-party Validator and receive rewards.
User has Validator capabilities and but doesn't have necessary amount of funds to participate in validator elections and subsequent rewards.

Basic terms

DePool - a smart contract that allows other smart contracts to invest stakes into a common pool of funds and after some period of time to receive it back with interest.
Elector - a system level smart contract, deployed to masterchain from zero state. Runs validator elections periodically.
DePool Proxy (proxy) - a smart contract that delivers messages between DePool and Elector.
Participant - a smart contract that invests funds into DePool.
Validator - software running blockchain node. Each DePool works with one node only. This node must be a DePool participant.
Validator wallet - a smart contract that is used by Validator to send election requests to DePool and receive the Validator reward. Validator wallet should be a Multisig contract with 3 custodians.
DePool Helper - a smart contract that stores the address of the actual DePool and works with the Timer contract.
Global Validators Set (GVS) - current set of validators chosen in the latest elections.
Validation period - period of time for which GVS is elected.
Investment round - period of time between Participant investing a stake in DePool and receiving it back (with or without interest).
Timer - a smart contract that can call other smart contracts periodically.

Architecture

DePool is designed to receive investment stakes from Participants, allocate the pool funds to a validator in order to participate in elections of the GVS and, after the end of the validation cycle, distribute stakes with certain rewards back to the Participants.
DePool is deployed to basechain. But it cannot communicate with Elector directly, because Elector rejects messages from non-masterchain contracts. Thus there are DePool proxies that are deployed to masterchain and deliver messages from DePool to Elector and back. This is done, because DePool is a large and complex contract, and gas and storage fees are 10 times lower in basechain compared to masterchain. Keeping DePool on masterchain would be unreasonably expensive.
DePool is open for Participants’ stakes at all times, however, there is a deadline for participation in the upcoming elections. The deadline depends on the timer of the Elector. After the deadline, the incoming stakes will be accumulated for participation in the next elections.
DePool distinguishes stakes received before the deadline and after the deadline, therefore it stores information on Participant stakes in separate investment rounds (or rounds), one for every elections, to facilitate subsequent distribution of stakes and rewards. To separate Elector communication, DePool uses 2 proxies: one for even rounds, one for odd.
In order to be time-aware, the DePool should be called from time to time. For this purpose the Timer contract is used. DePool Helper asks Timer to call it periodically and transmits every call from Timer to DePool. Interval between calls is chosen according to the elections interval.
DePool must be linked to a validator wallet to participate in elections on behalf of the latter. This validator wallet address is specified during DePool deployment and cannot be changed afterwards. When elections start, DePool waits for signed election requests from linked wallet, then attaches round stake to request and transmits it to Elector.
Validator can validate many DePools with 1 Validator wallet. Reputation of Validator wallet therefore is available and can be analyzed over time.
To ensure that the validator will perform its functions correctly (be always online and not "lie" to other validators), the validator wallet must itself become a Participant and invest in every investment round at least m_validatorAssurance, which is initialized in DePool constructor. This can be achieved with any of the three available types of stakes.
When Elector unfreezes validator stakes, DePool returns its stake back with round rewards. Part of the total reward is used to top up the DePool's own balance to a certain value. The rest is distributed as follows: m_validatorRewardFraction% goes to Validator wallet balance. m_participantRewardFraction% is distributed among all Participants in investment round (validator is also participant). m_associationRewardFraction% (can be equal to zero) goes to m_association address.
DePool keeps a balance for each Participant and can automatically reinvest Participant's stake into the next investment round if appropriate flag is enabled.
Participant can transfer part of its total stake to another Participant's stake inside DePool storage. This function allows for collateralization of the stake to provide liquidity to stake holders.

Special kinds of stakes

Along with the basic ordinary stake, that functions according to the rules detailed above, there are 2 types of special stakes: vesting and lock stake.

While the entire ordinary stake is invested into the current pooling round (and will thus be reinvested every second round), lock and vesting stakes are split into two equal parts upon reception, which are invested into the current pooling round, and the next round. This way they can be continuously reinvested into both odd and even rounds.

Vesting Stake

Any address can make a vesting stake and define a target participant address (beneficiary) who will own this stake. But not the whole stake is available to the beneficiary at once. Instead it is split into logical parts and the next part of stake becomes available to the participant only when next vesting period is ended. At completion step of every round DePool decides how many vesting parts should be unlocked and subtracted from vesting stake and become available to owner since last unlocking. These funds are added to beneficiary's ordinary stake.

Example: address A makes a vesting stake of 120 tons for 1 year with vesting period of 1 month and defines address B as the stake beneficiary. It means that after 1 month 10 tons become available to address B and 110 tons are still locked in the pool. After 1 year vesting stake will be equal to 0 and last 10 tons will become available to owner.

Vesting for validator beneficiaries is subject to additional rules: At the end of every withdrawal period, the part of the vesting stake to be released is divided proportionally into 2 parts - for rounds in this period when DePool successfully completed validation and received a reward (without slashing) and for rounds when DePool missed elections or was slashed. The portion of the stake corresponding to the successful rounds is sent to the validator, while the portion corresponding to the failed rounds is returned to the vesting stake owner. For example, if there were 100 rounds within the withdrawal period, and DePool successfully completed 80 of them, missed elections in 5 more and was slashed in the remaining 15, the validator will receive 80% of the unlocked part of the vesting stake, and the stake owner will get back 20% of it.

LockStake

Any address can make a lock stake, in which it locks its funds in DePool for a defined period, but rewards from this stake will be payed to another target participant (beneficiary). At the end of a period the Lock Stake should be returned to the address which locked it.

Example: address A makes a lock stake of 120 tons for 1 year with vesting period of 1 month and defines address B as the stake beneficiary. It means that after 1 month 10 tons become available to address A (as opposed to vesting, where these 10 tons would become available to address B, the beneficiary) and 110 tons are still locked in round. DePool will reinvest the gradually diminishing lock stake for a 1 year and pay rewards to B address. After 1 year DePool will return the remainder of the lock stake to address A.

One Participant can be a beneficiary only of one lock and one vesting stake. Once current lock or vesting stake of the participant expires, it can be repeated. When a stake of either of these types is created, it is split equally into two last rounds, which means that the minimal value for such stake is 2 * minStake + fee.

Specification

Data Structures

DePool contract uses library and inheritance from several simple base contacts to separate functionality and facilitate development and debugging of the contract. The core data set stored by DePool is the following:

DePoolLib.sol

// Describes contract who deposit stakes in DePool pool
struct Participant {
    // Count of rounds in which participant takes a part
    uint8 roundQty;
    // Sum of all rewards from completed rounds (for logging)
    uint64 reward;
    // count of parts of vesting stakes in the rounds
    uint8 vestingParts;
    // count of parts of lock stakes in the rounds
    uint8 lockParts;
    // Flag whether to reinvest ordinary stakes and rewards
    bool reinvest;
    // Target tons that will be transferred to participant after rounds are completed
    // After each round this value is decreased
    uint64 withdrawValue;
}

// Request for elections from validator wallet.
struct Request {
    // Random query id.
    uint64 queryId;
    // Validator's public key that will be used as validator key if validator will win elections.
    uint256 validatorKey;
    // current election id.
    uint32 stakeAt;
    // Validator's stake factor.
    uint32 maxFactor;
    // Validator's address in adnl overlay network.
    uint256 adnlAddr;
    // Ed25519 signature of above values.
    bytes signature;
}

DePoolRounds.sol

// roundPre0 = m_rounds[m_roundQty - 1] - pre-pooling. Helper round for adding vesting and lock stakes. When vesting/lock stake
//                                        is added than stake is split into two part. And first part invested into pooling round
//                                        and second part - pre-pooling.
// round0    = m_rounds[m_roundQty - 2] - pooling
// round1    = m_rounds[m_roundQty - 3] - election or validation
// round2    = m_rounds[m_roundQty - 4] - validation or investigation
// Algo of round rotation:
//     delete round2
//     round1         -> round2
//     round0         -> round1
//     roundPre0      -> round0
//     createNewRound -> roundPre0
mapping(uint64 => Round) m_rounds;

// count of created rounds
uint64 m_roundQty = 0;

DePoolBase.sol

// Dictionary of participants for rounds
mapping (address => Participant) m_participants;

// Address of the validator wallet
address m_validatorWallet;

// Array of proxies addresses.
address[] m_proxies;

DePool.sol

// Indicates that pool is closed. Closed pool doesn't accept stakes from other contracts.
bool m_poolClosed;
// Min stake accepted to the pool in nTon (for gas efficiency reasons): 10 tons is recommended.
uint64 m_minStake;
// Minimum validator stake in each round
uint64 m_validatorAssurance;
// % of participant rewards
uint8 m_participantRewardFraction;
// % of validator rewards
uint8 m_validatorRewardFraction;
// % of dePool association rewards
uint8 m_associationRewardFraction;
// Association address
address m_association;
// Minimum balance
uint64 m_minimumBalance;

DePool Initialization

When deployed, the DePool constructor is called with the following parameters:

/// @dev DePool's constructor.
/// @param minStake Min stake that participant may have in one round.
/// @param validatorAssurance Min validator stake.
/// @param proxyCode Code of proxy contract.
/// @param validatorWallet Address of validator wallet.
/// @param participantRewardFraction % of reward that distributed among participants.
constructor(
    uint64 minStake,
    uint64 validatorAssurance,
    TvmCell proxyCode,
    address validatorWallet,
    uint8 participantRewardFraction,
)

At initialization the variable m_balanceThreshold is set as current DePool account balance - 5 tokens. DePool will replenish its balance from validation rewards to this value every round it receives rewards.

Participant functions

DePool stores some participant information in a dictionary (m_participants) where key - Participant's address and value - Participant structure.

Functions used by participants perform checks and send receiveAnswer message back to the caller with an error code and a comment in case of failure. If all conditions are met, DePool sends a confirmation message (receiveAnswer with status 0) back to the caller.

All functions can be called by internal messages only.

1. addOrdinaryStake(uint64 stake) - allows to make an ordinary stake in the current pooling round. The source address of the message is taken as Participant's address. The Participant's total stake is increased by stake amount.

Parameters:

stake - value of participant's stake in nanotons.

Function checks that:

inbound message value is at least (stake + ADD_STAKE_FEE);
stake is at least min stake;
pool is not closed.

Function returns change (part of unused ADD_STAKE_FEE).

2. addVestingStake(uint64 stake, address beneficiary, uint32 withdrawalPeriod, uint32 totalPeriod) - allows to add a vesting stake for another participant (beneficiary). The source address of the message is saved as the vesting stake owner.

Parameters:

stake - value of participant's stake in nanotons (Note: this value is divided into 2 parts and is added to 2 rounds).
beneficiary - address of target participant (beneficiary);
withdrawalPeriod - the period in seconds after which the part of the vesting becomes available for beneficiary;
totalPeriod - total period of vesting in seconds after which beneficiary becomes owner of the whole stake.

Function checks that:

DePool is not closed (m_poolClosed ≠ true);
beneficiary is an addr_std. It's not zero address. It's not the message sender (not self vesting);
inbound msg.value≥ (m_minStake+ ADD_STAKE_FEE);
Message value is at least stake + STAKE_FEE;
stake/2 is at least min stake;
withdrawalPeriod ≤ totalPeriod;
totalPeriod < 18 years;
withdrawalPeriod ≠ 0;
totalPeriod % withdrawalPeriod = 0;
beneficiary doesn't have a vesting stake.

3. addLockStake(uint64 stake, address beneficiary, uint32 withdrawalPeriod, uint32 totalPeriod) - allows to add a stake that will bring rewards to another participant (beneficiary). The source address of the message is saved as the lock stake owner.

It has the same parameters and checks as addVestingStake, but it checks that participant doesn't have a lock stake instead of a vesting stake.

4. withdrawFromPoolingRound(uint64 withdrawValue) - allows to remove Participant's stake from the current pooling round.

Parameters:

withdrawValue- desired amount of stake to be removed.

Function checks that:

inbound msg.sender address is address of an existing participant.

If real ordinary stake is less than withdrawValue, then DePool returns the whole stake from pooling round.

If the remaining stake in the pooling round is less than m_minStake, then the whole stake is transferred to Participant.

If the remaining total stake of Participant is 0, then it is removed from the m_stakeholders dictionary.

5. withdrawPart(uint64 withdrawValue) - Allows a participant to withdraw some value from DePool. This function withdraws withdrawValue nanotons when rounds are completed. If participant stake becomes less than minStake, then the whole stake is sent to participant.

Parameters:

withdrawValue- desired amount of stake to be removed.

Function checks that:

pool is not closed (m_poolClosed ≠ true)
inbound msg.sender address is address of an existing participant.

If the remaining stake in the round is less than m_minStake, then the whole stake will be transferred to Participant (after completing round).

If the remaining total stake of Participant is 0, then it is removed from the m_stakeholders dictionary.

6. withdrawAll() - Set global flag for the participant that indicates to return participant's ordinary stake after completing rounds.

Function checks that:

pool is not closed (m_poolClosed ≠ true);
inbound msg.sender address is address of an existing participant.

After transferring all Participant's stake, the Participant will be removed from the m_stakeholders dictionary.

7. cancelWithdrawal() - Cancel effect of calls of functions withdrawAll and withdrawPart.

8. transferStake(address dest, uint64 amount) - allows to move amount of stake from msg.sender Participant to dest Participant inside DePool storage.

Parameters:

dest - stake beneficiary;
amount - stake value transferred to dest in nanotons.

Function checks that:

pool is not closed (m_poolClosed≠ true);
destination is a non-zero addr_std;
msg.sender ≠ dest;
neither destination nor msg.sender is the validator wallet;
inbound msg.sender address is address of an existing participant;
desired amount can be transferred and transfer doesn't leave stake less than m_minStake in any round.

In case of success DePool sends back a notification via onTransfer function calling to beneficiary.

Functions of interface DePoolInfoGetter:

function getLastRoundInfo() public

If there is no completed round yet, call callback function receiveDePoolInfo with struct containing default values, else send call with struct containing info about last completed round.

// Represent info about last completed round
struct LastRoundInfo {
    uint32 supposedElectedAt;
    uint8 participantRewardFraction;
    uint8 validatorRewardFraction;
    uint32 participantQty;
    uint64 roundStake;
    address validatorWallet;
    uint256 validatorPubkey;
    uint64 validatorAssurance;
}

Participant callback functions:

These functions are called by DePool to send notifications to Participant.

1. receiveAnswer(uint32 errcode, uint64 comment) - function, which is called as an answer from DePool to Participant.

Arguments:

errcode - error code. List of codes:

uint8 constant STATUS_SUCCESS                                        =  0;
uint8 constant STATUS_STAKE_TOO_SMALL                                =  1;
uint8 constant STATUS_DEPOOL_CLOSED                                  =  3;
uint8 constant STATUS_NO_PARTICIPANT                                 =  6;
uint8 constant STATUS_PARTICIPANT_HAVE_ALREADY_VESTING               =  9;
uint8 constant STATUS_WITHDRAWAL_PERIOD_GREATER_TOTAL_PERIOD         = 10;
uint8 constant STATUS_TOTAL_PERIOD_MORE_18YEARS                      = 11;
uint8 constant STATUS_WITHDRAWAL_PERIOD_IS_ZERO                      = 12;
uint8 constant STATUS_TOTAL_PERIOD_IS_NOT_DIVED_BY_WITHDRAWAL_PERIOD = 13;
uint8 constant STATUS_PERIOD_PAYMENT_IS_ZERO                         = 14;
uint8 constant STATUS_REMAINING_STAKE_LESS_THAN_MINIMAL              = 16;
uint8 constant STATUS_PARTICIPANT_HAVE_ALREADY_LOCK                  = 17;
uint8 constant STATUS_TRANSFER_AMOUNT_IS_TOO_BIG                     = 18;
uint8 constant STATUS_TRANSFER_SELF                                  = 19;
uint8 constant STATUS_TRANSFER_TO_OR_FROM_VALIDATOR                  = 20;
uint8 constant STATUS_FEE_TOO_SMALL                                  = 21;
uint8 constant STATUS_INVALID_ADDRESS                                = 22;
uint8 constant STATUS_INVALID_BENEFICIARY                            = 23;
uint8 constant STATUS_NO_ELECTION_ROUND                              = 24;
uint8 constant STATUS_INVALID_ELECTION_ID                            = 25;

comment - some value attached to error code.

2. onTransfer(address source, uint128 amount) - function, which is called after successful transferStake to inform beneficiary.

Arguments:

source - address of Participant who made transfer;
amount - funds that were transferred.

3. onRoundComplete(uint64 roundId, uint64 reward, uint64 ordinaryStake, uint64 vestingStake, bool reinvest, uint8 reason) - send a notification from DePool to Participant when round is completed:

roundId - Id of completed round;
reward - Participant's reward in completed round in nanotons;
ordinaryStake- ordinary stake in completed round;
vestingStake - vesting stake in completed round;
lockStake - lock stake in completed round;
reinvest - are ordinary stakes automatically reinvested (prolonged)?
reason - reason why round is completed (See enum CompletionReason).

DePool owner functions:

These functions can be called only by the DePool owner, as they have to be signed with the deploy keypair.

1. terminator() [external msg only] - a method to close DePool. All stakes from all rounds are returned in several phases:

first of all, stakes from pooling round are returned immediately.
m_poolClosed = true;
All other rounds will return stakes after their "completed" step.

Important: remaining parts of vesting/lock stakes will be sent to owners of those stakes (not to beneficiaries)

2. setValidatorRewardFraction(uint8 fraction) [external msg only]

Sets new validator's reward fraction and calculates new participants' reward fraction. New validator's reward fraction must be less than current one and be not zero.

fraction - new validator's reward fraction.

Events

DePoolClosed() - event emitted when pool is closed by terminator() function.
RoundStakeIsAccepted(uint64 queryId, uint32 comment) - event is emitted on accepting stake by elector.
RoundStakeIsRejected(uint64 queryId, uint32 comment) - event is emitted on rejecting stake by elector.
ProxyHasRejectedTheStake(uint64 queryId) - event is emitted if stake is returned by proxy (IProxy.process_new_stake) because too low balance of proxy contract.
ProxyHasRejectedRecoverRequest(uint64 roundId) - event is emitted if stake cannot be returned from elector (IProxy.recover_stake) because too low balance of proxy contract.
RoundCompleted(TruncatedRound round) - event is emitted on completing round.
StakeSigningRequested(uint32 electionId, address proxy) - Event emitted when round is switched from pooling to election. DePool is waiting for signed election request from validator wallet.
TooLowDePoolBalance(uint replenishment) - event emitted when pure DePool's balance becomes too low. replenishment minimal value that must be sent to DePool via receiveFunds function.
RewardFractionsChanged(uint8 validator, uint8 participants) - event emitted when contract owner changes reward fractions. validator - validator's reward fraction. participants - participants' reward fraction.

Get-methods

These get-methods are used for local run.

getParticipantInfo(address addr) - returns participant's information about stakes in every rounds;
getDePoolInfo() - returns DePool configuration parameters and constants;
getParticipants() - return list of all participants;
getRounds() - returns information about all rounds.
getDePoolBalance() - returns DePool's own balance in nanotokens.

The DePool does not store validator public keys or ADNL address, because, according to the official TON guide, the Validator generates a new keypair and ADNL for every elections. The contract stores only Validator wallet address.

State update function

ticktock() - this function is the "engine" of DePool. This function rotates rounds: creates a new round if necessary and removes an old one. Switches steps of rounds and calls various internal functions if certain conditions are satisfied and so on.

ticktock() does not accept external inbound messages and can be called only from other contracts. ticktock returns unspent message value (change) back to caller.

Multi-Round elections

Every round goes through several steps:

1. "PrePooling" step (RoundStep.PrePooling) - it's an imaginary round introduced to store half of vesting/lock stake from participants. See addVestingStake/addLockStake functions.

2. "Pooling" step (RoundStep.Pooling) - round is ready to accept stakes from Participants. This round receives ordinary, vesting and lock stakes.

3. "waiting for election requests" step (RoundStep.WaitingValidatorRequest) - round is switched to this step when validator elections begin. DePool is waiting for signed election request from validator wallet. See process_new_stake function of Elector to properly generate election request.

Important: Validator wallet must also be a Participant and invest at least m_validatorAssurance stake in the round. If it doesn't, round is completed and stakes are reinvested in another round or are returned to participants.

4. "Waiting if stake is accepted by elector" (RoundStep.WaitingIfStakeAccepted) - DePool has received the validator signed election request. DePool has sent the whole round stake to elector through one of its proxies. Now DePool is waiting for elector answer. Note: elector will call DePool's onStakeAccept function if election request is accepted successfully or onStakeReject in case of an error.

5. "waiting for validation start" (RoundStep.WaitingValidationStart) - round stake was accepted by elector. Validator is a candidate. DePool now is waiting for the start of the validation to find out if validator won the elections.

6. "waiting for election result" (RoundStep.WaitingIfValidatorWinElections) - DePool has tried to recover stake in validation period to find out if validator won elections. Waiting for elector answer. Note: If validator won the elections, elector returns no stake. If Validator lost the elections, elector returns the whole stake.

7. "waiting stake unfreeze" (RoundStep.WaitingUnfreeze) - If CompletionReason!=Undefined, the round is waiting round rotation to return/reinvest funds because elections were lost. Else validator won elections. DePool is waiting for ending of unfreeze period to recover funds from elector.

8. "waiting for a reward" (RoundStep.WaitingReward) - Unfreeze period has been ended. Request to recover stake has been sent to elector. DePool is waiting for answer from elector.

9. "completing" step (RoundStep.Completing) - DePool receives reward and replenishes its balance from it. Then it returns or reinvests participant's stakes. Also on this step DePool recounts vesting and lock stakes and modifies them if necessary.

10. "completed" (RoundStep.Completed) - round switches to this step after processing all the Participants in the round. In next ticktock this round will be deleted.

Round completion

When a round switches to "completing" step (completeRound function), the DePool replenishes its balance from received rewards and then starts to cycle through all stakes in the round. If Participant's reinvestment flag is false, DePool sends it back to the Participant, otherwise - adds it to the pooling round. Also DePool sends notification message (onRoundComplete) to Participant.

DePool goes through all vesting and lock stakes of the completing round and checks whether a withdrawal period has finished for the current stake. If it has, DePool modifies the stake via transferring part of it to Participants ordinary stake (in case of Vesting) and/or transferring part of the stake back to the owner (in case of Lock or in case of Vesting for validator which was slashed or lost elections over the course of the completed withdrawal period).

Remark: if there are 15000 stakes in round, then the contract should split completion to 375 transactions sending 375 completePendingRound messages to itself. All these transactions can fit in 1-2 blocks and the whole operation will take about 5-20 seconds.

DePool decentralization

No inherent way to replace the contract code (no SETCODE);
No inherent way to transfer an arbitrary amount of currency from the DePool;
Any contract can call the ticktock() function to update the state of the DePool;
No one has special privileges, except for deployer of DePool who can only close DePool and start a procedure of returning all stakes back to Participants;
Fees cannot be changed after the contract is deployed;
Validator wallet must be a Participant as well to share risks with other Participants.

DePool contract fee

Caller of DePool's ticktock function must pay for consumed gas. Unused message value is returned back when ticktock is finished.
At the beginning of completing step DePool first takes from the total reward an amount of tokens to replenish it's balance to m_balanceThreshold, and then additionally RET_OR_REINV_FEE*(N+1), where N is the number of participants, to cover the costs of stake processing.

Что такое TON OS

2021-02-26T10:13:51.421Z

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

Почему мы называем это TON OS?
Современный блокчейн, такой как Free TON, - это не просто неизменный реестр. Биткойн и другие ранние блокчейны были в основном реестрами, но даже Биткойн поддерживает не полный сценарий Тьюринга, который предоставляет некоторые инструкции выполнения транзакции. Фактически, сценарий Биткойн представляет собой набор инструкций, подобный Форт, что делает его несколько похожим по происхождению на язык ассемблера виртуальной машины TON, но об этом позже.

Большинство блокчейнов после Ethereum по большей части представляют собой распределенные вычислительные машины, которые выполняют и проверяют программы, завершенные по Тьюрингу, называемые смарт-контрактами. Проще говоря, они представляют собой особую разновидность сетевых процессоров, работающих в оркестровке (так называемый «консенсус») для выполнения общих операций и, таким образом, проверки правильности их выполнения.

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

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

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

Вот как GNU определяет операционную систему:

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

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

И, как и в случае с любым компьютером, блокчейну нужен промежуточный уровень (или уровни), который управляет его ресурсами и предоставляет услуги программам, которые пользователь запускает или с которыми взаимодействует. Конечно, с точки зрения архитектуры, блокчейн нельзя напрямую сравнивать 1: 1 с обычным ПК. Но с логической точки зрения, всякий раз, когда мы думаем о программном стеке, необходимом для взаимодействия с пользователем, называть его операционной системой весьма убедительно.

Приведем несколько аргументов. Из соображений практичности мы не будем говорить только о блокчейне Free TON, но большинство аргументов можно применить и к некоторым другим современным блокчейнам.

Ожидается, что классическая операционная система обеспечит:

Управление памятью
Управление процессором
Управление устройством
Обработка файлов
Обеспечение безопасности
Контроль производительности системы
Учет и обработка работ
Обнаружение и обработка ошибок
Синхронизация с другим ПО и пользователями
Сравним с TON OS и предоставляемыми ею услугами:

Управление памятью

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

Управление процессором

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

Управление устройством

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

Файл handliнг

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

Обеспечение безопасности

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

Контроль производительности системы

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

Учет и обработка работ

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

Обнаружение и обработка ошибок

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

Синхронизация с другим ПО и пользователями

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

Самоорганизующаяся демократия

2021-02-18T23:26:31.024Z

Самоорганизующаяся демократия

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

Я считаю, это далеко не самый перспективный путь развития общества, так как существуют более прогрессивные модели управления. Современные исследования и разработки в области IT наглядно показывают колоссальный потенциал децентрализованных (aka, peer2peer) и/или самоорганизующихся систем: от нейронных сетей SOINN до всем известной нашумевшей p2p криптовалюты bitcoin.

Централизованные и децентрализованные (Twister и т.п.) социальные сети демонстрируют самоорганизованное формирирование топологии, которая способствует быстрому распространению информации.

От прямой/представительной демократии к самоорганизующемуся государству

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

Прямая демократия:

Преимущества

Недостатки

1. Каждый может принимать участие в принятии политических решений.

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

2. Каждый имеет право влиять на принятие решений, но не каждый сможет/захочет им воспользоваться (нехватка времени, отсутствие мотивации).

Представительная демократия:

Преимущества

Недостатки

1. Каждый гражданин не обязан тратить время на управление государством.

1. Народ не принимает непосредственного участия в процессе принятия решений.

2. Механизм коммуникации между представителями упрощен.

2. Система уязвима для недобросовестных представителей из-за длительности сроков их полномочий.

3. Риск узурпации власти господствующим политическим кланом.

4. Большинство граждан не имеют возможности принимать участие в политической борьбе.

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

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

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

Самоорганизация в делегируемой демократии

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

Один общепризнанный делегат становится лидером и берет на себя ответственность за принятие жизненно важных для общества решений. Когда государство возвращается к стабильному состоянию, топология системы вновь смещается в сторону прямой демократии (коллективного принятия решений):

На практике делегируемую демократию сегодня используют Пиратские партии нескольких стран Европы. В частности, Пиратская партия Германии пользуется специально разработанной платформой LiquidFeedback для реализации механизма самоорганизации.

Заключение

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

Ресурсы:

Лучшие техники и методологии мозгового штурма.

2021-02-17T21:24:38.905Z

10 МИН ЧИТАТЬ

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

Шесть Шляп Мышления
Креативная Стратегия Уолта Диснея
SCAMPER

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

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

Чем больше тем лучше или количество важнее качества Чем больше идей выдвинет ваша команда, тем шире пространство вариантов. Совершенно нормально, если двое или трое участников повторят одно и то же. И это нормально, если некоторые идеи кажутся нелепыми или смешными. Задача фасилитатора – помочь участникам высказать оригинальные, но скрытые глубоко в мозгу идеи.
Никакой критики. Mозговой Штурм призван создать пул идей. Должны приветствоваться любые высказывания, вне зависимости от субординации и экспертных мнений. Босс не может заставить замолчать подчиненного, аналитик не может смеяться над нереалистичным видением своего товарища по команде, а дизайнер не должен подвергать соображения своего коллеги тесту на юзабилити.
Следуйте плану. Брейншторм будет продуктивным, только если он нацелен на результат, и имеет жесткие временные рамки. Неконтролируемые вспышки креативности, как правило, проваливаются. Чтобы чудо произошло, необходимо организовать для него хорошие условия

Вот Вам слайды, в качестве инструкции:

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

Метод 1 – Шесть Шляп Мышления

Метод был создан в 1985 году мальтийским психологом Эдвардом де Бонo.

Уровень сложности – нормальный

Предмет обсуждения – процесс, услуга, продукт, новая функция, – что угодно.

Длительность 1 – 1,5 часа

Организация – 1 фасилитатор на группу из 5-8 человек. Если присутствует большее количество людей, то будет лучше разделить их на небольшие группы и привлечь ассистентов. Например, нашу команду из 20 дизайнеров мы обычно делим на 3 группы, которые одновременно работают над проблемой.

Материалы

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

Процесс

Сессия начинается с 5-минутного вступления, которое должно дать участникам предварительное представление о том, что они будут делать, к какому результату они должны прийти, и почему этот процесс так важен. Перед тем, как перейти к следующему шагу, необходимо убедиться, что участники полностью понимают концепцию Шести Шляп Мышления. Она построена на том, что люди привыкают воспринимать реальность с одной и той же точки зрения, другими словами – “носят одну и ту же шляпу”. А это блокирует креативность и порождает стереотипы. Для того, чтобы люди начали мыслить по другому, достаточно просто “примерить другую шляпу”.

Ниже вы найдете пояснения что значит каждая из шляп.

Белая Шляпа: факты, непредвзятость, объективность

Желтая Шляпа: оптимизм, преимущества, возможности реализации

Черная Шляпа: критика, осторожность, оценка рисков

Красная Шляпа: интуиция, чувства, эмоции

Зеленая Шляпа: инновация, креативность, новые идеи

Синяя Шляпа: контроль, общая схема, организация.

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

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

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

Синяя – подготовка
Белая – обзор доступной и недостающей информации
Красная – выслушивание эмоциональных суждений и непроверенных предположений
Желтая – выявление уже имеющихся положительных моментов
Зеленая – обдумывание возможных улучшений и инноваций
Черная – анализ рисков и ресурсов
Синяя – подведение итогов

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

Этот заключительный этап брейншторма мы дополняем еще и сортировкой идей по тематическому сходству/близости. Хотя она и не предусмотрена оригинальной методикой, но позволяет суммировать идеи, и приблизить момент их воплощения. Команда должна найти на вайтборде записи о сходных вещах, объединить их в группы, и присвоить каждой группе название. Например, во время обсуждения темы ”Улучшение инфраструктуры дизайнерского отдела”, мои коллеги создали такие группы как “Эргономика стульев”, “Полы и стены”, “Обновление программного обеспечения”.

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

Метод 2 – Креативная Стратегия Уолта Диснея

Креативный метод Уолта Диснея был разработан Робертом Дилтсом, экспертом по нейро-лингвистическому программированию, в 1994 году.

Уровень сложности – легкий

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

Длительность – 1 час

Организация – 1 фасилитатор на группу из 5-8 человек. Когда мы устраиваем практические семинары по брейнстормингу, я и мои коллеги работаем с 4 группами по 6 человек.

Материалы

Слайды с пошаговыми инструкциями
Таймер (или ноутбук с таймером, развернутым во весь экран)
Желтые стикеры для заметок стандартного размера (1-2 пачки на группу из 5-8 человек)
Красные стикеры маленького размера (1-2 пачки на команду)
Флажки для голосования
Вайтборд или большой лист бумаги на стене или на столе
Черные маркеры для каждого участника

Эта техника была названа в Честь Уолта Диснея – знаменитого мультипликатора и продюсера. Сам Дисней не использовал никакой методологии, его креативный процесс был интуитивным, но тем не менее продуктивным.

Роберт Дилтс, эксперт по НЛП, создал свое ноу-хау гораздо позже, базируясь на воспоминаниях коллег Уолта Диснея. Стратегия Диснея основана на строгом разделении трех ролей – Мечтатель, Реалист, и Критик. Когда люди думают о будущем, они часто смешивают эти три роли. Именно поэтому они терпят поражение. Ведь как мечтают обычные люди? “Давайте сделаем это. Но это так дорого. И рискованно… Возможно, позже”. В результате, прекрасная идея гибнет под гнетом страхов и сомнений.

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

Мечтатель:

Генерирует множество идей;
Свободен в своем воображении и может высказывать что угодно;
Не думает о препятствиях.

Реалист:

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

Критик:

Анализирует возможные риски;
Находит слабые места;
Хочет предотвратить поражение.

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

Перед тем как участники перейдут к следующей роли, следует объяснить им, что она означает. “Реалист – лучший друг Мечтателя. Реалист это менеджер, который способен превратить неопределенную идею в пошаговый план действий, и найти для этого определенные ресурсы. Реалист понятия не имеет, что такое критика. Он пытается найти любые возможности для осуществления идей Мечтателя, определяя кто, когда, и как сделает эту идею реальностью.

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

Слайды:

Мечтатель

Генерирует и записывает идеи
Подхватывает идеи своих коллег
Создает облако идей

Реалист

Как мы можем сделать эту мечту реальностью?
Кто может тебе помочь?
Как другие люди воплощают подобные идеи?

Критик

В чем слабые места этого решения?
Кто или что может помешать?

Роль Критика наиболее трудная для понимания, так как многие думают, что Критик это тот парень, который втаптывает в грязь работу Мечтателя и Реалиста. К счастью, это не так. “Критик это лучший друг Мечтателя и Реалиста. Этот человек анализирует риски и заботится о безопасности предложенного решения. Критик не трогает изначальную идею, а работает только с решениями. Задача Критика помочь и заранее предвидеть вероятные сложности”.

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

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

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

Слайды:

Голосование

Подумайте о лучшей идее и решении
Выберите самую многообещающую идею
Проголосуйте за лучшую идею

Поделитесь ключевыми выводами

Какая идея самая многообещающая?

С чего вы начнете?

Финальный этап процесса это роудмэппинг. Команда берет идеи, которая собрали наибольшее количество голосов (обычно, 6-10), и распределяют их на временной шкале в зависимости от сложности воплощения. Если идею можно легко реализовать, она ставится в колонке “Сейчас”. Если идея требует серьезной подготовки и благоприятных условий, на шкале она отодвигается дальше.

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

Метод 3 – SCAMPER

Этот метод был предложен в 1953 году Алексом Осборном, основателем и руководителем международной сети рекламных агенств BBDO.

Уровень сложности – от нормального до трудного

Предмет обсуждения – в идеале, технические вопросы или материальные предметы, хотя автор и евангелист этого метода уверяет, что он может быть применим и к любым другим областям. По моему мнению, SCAMPER менее эффективен, когда он касается абстрактных понятий. Например, работая по этому методу, команда с трудом справилась с темой “Улучшение взаимодействия между дизайнером и клиентом”, зато он блестяще сработал в случае с темой “Изобретение лучшего приложения для прототайпинга”.

Длительность – не более 2 часов.

Организация – 1 фасилитатор на группу из 5-8 человек.

Материалы

Слайды с пошаговыми инструкциями
Таймер (или ноутбук с таймером, развернутым во весь экран)
Стандартные стикеры для заметок (7 упаковок на группу из 5-8 человек)
Вайтборд или большой лист бумаги на стене или на столе
Черные маркеры для каждого участника
Дополнительно, Thinkpack – специальные карточки, разработанные Майклом Михалко (1 комплект на команду)

Процесс

Техника SCAMPER задействует различные варианты модификации объекта. Метод призван произвести инвентаризацию идей и помочь оптимизировать существующий продукт, или создать принципиально новый.

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

S – Substitute (заменить)

C – Combine (комбинировать)

A – Adopt (адаптировать)

M – Modify (модифицировать)

P – Put to other uses (предложить другое применение)

E – Eliminate (устранить)

R – Rearrange or reverse (реорганизовать)

В данном случае обязательно нужно проиллюстрировать каждую позицию примерами, и предложить участникам для начала потренироваться. Мы объясняем этот метод на простых объектах, таких как ординарная шариковая ручка. Как можно её усовершенствовать?

S – Заменить чернила на что нибудь, что можно стереть.

C – Скомбинировать корпус ручки и стержень в единое целое.

A – Адаптировать, например, нож, чтобы писать по дереву.

M – Модифицировать корпус, сделав его гибким, чтобы носить как браслет.

P – Использовать ручку, как дротик для дартса.

E – Устранить зажим и сделать вместо этого магнит.

R – Поменять расположение зажима. В результате, стержень будет ориентирован вверх и чернила не прольются в карман.

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

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

Thinkpak cards – это комплект карт для брейнсторминга, разработанный Mайклом Михалко. Эти карточки оживляют процесс мозгового штурма, и привносят в него элемент игры. Каждая карточка символизирует одну из букв аббревиатуры

SCAMPER. Каждый участник по очереди вытягивает карту из колоды, и делает свой ход, выступая с корреспондирующей идеей. Будет довольно весело посоревноваться в количестве идей, выданных каждым участником за короткий промежуток времени, обычно 3-5 минут. Если ваша команда никогда ранее не участвовала в мозговом штурме, Thinkpak cards это прекрасный способ сначала поиграть и потренироваться, а потом перейти к серьезным делам.

Какие уроки можно извлечь

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

Адекватность темы и аудитории

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

Документируйте

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