? Editing: Post:21.body Save Delete Cancel
Content changed Sign & Publish new content

MUON

Blog about muon messenger

Follow in NewsfeedFollowing

Latest comments:

Magistral (концепция). Взаимодействие между узлами в виде шин (bus)

on Mar 29, 2016 ·
1 comments

О сложности выбора блокчейна

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

Сочетание характеристик блокчейна для отдельного приложения

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

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

Дальняя связь между блоками - это выбор требований к блоку и транзакции. Сложно описать эту характеристику, так как технология блокчейн ещё находится на раннем этапе освоения. Но сюда следует отнести как выбор PoW/PoS алгоритма для блока, так и монетарной системы (в случае криптовалют). Так, в некоторых системах (Twister, Bitmessage) на транзакцию накладываются только PoW-требования, в криптовалютах часто наоборот только требования типа PoS (владения и подтверждение передачи монет). В более сложном случае мы имеем дело со смарт-контрактами.

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

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

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

Стоимость записи в блок

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

Несколько приложений (DAPPs) на базе одного блокчейна

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

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

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

Проблема частных блокчейнов

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

Первой проблемой является уязвимость к атакам подмены цепочки. Это работает в случае чистого PoW-алгоритма совместимого с высокопроизводительным оборудованием, но и в случае PoS даже ещё проще. Проблема не решена полностью даже в самом биткоине и разрешается чекпоинтами в ручном режиме. Для частных блокчейнов неплохим способом хранения чекпоинтов могут быть существующие популярные цепочки блоков (Proof-Of-Existence).

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

Как упростить работу с частными блокчейнами

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

В создании такого узла и состоит идея.

Как это должно работать

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

Узлы при этом не работают со всей сетью, а только с нужными цепочкам. Это похоже на сайдчены, только без главной цепочки биткоина и в виде единого ПО. Так же это более похоже гибрид Ethereum и IPFS.

Read more

О разрешении имен

on Mar 14, 2016

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

  1. Предоставление человекочитаемого имени
  2. Предоставление постоянного псевдонима вместо меняющихся имен
  3. Предоставление одного имени вместо нескольких
  4. Подтверждение имени(???) (В DNS осуществляется в dns почти никак).

При таком рассмотрении видно, что задачи друг от друга независимые, хоть и часто воспринимаются как одна. При этом (1) DNS выполняет плохо, (2) и (3) удовлетворительно, а четвертую не выполняет вообще, и для этого используется внешний костыль в виде сертификатов.

А с Namecoin дело обстоит так. (1) осуществляется удовлетворительно, (2) и (4) хорошо, (3) ближе к удовлетворительною. Но за счет самой тяжеловесности минус каждому пункту. В Emercoin ситуация почти такая-же (1) удовлетворительно, (2) и (4) хорошо и (3) ближе к хорошо.

При реализации всех альтернатив DNS стремятся выполнить именно первый пункт. Но он же и является самым слабым звеном, и подводит всю систему. Так почему бы от него не отказаться. Может то что останется в итоге (пункты 2, 3 и 4) вполне оправданно предпочесть перовому.

Разрешение по открытому ключу

Вместо того чтобы представлять, как может выглядеть такой сервис, представим что namecoin изначально пошел по такому пути. То есть вместо Namecoin имен, он позволяет получить значение по адресу непосредственно. В итоге получим что, для примера, по адресу:

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

Возможные применения такого:

  1. Биткоин, альткоины и системы с аналогичными адресами. NCmgn5ckCa8Meyq4Tn5MdnGG3VGJGcYkPR -> Bitcoin Address (если он содержится в значении).
  2. Доступ к сайту по NCmgn5ckCa8Meyq4Tn5MdnGG3VGJGcYkPR -> ip адрес, onion адрес или всё что угодно, пользователь сам может выстави
  3. И многое другое. Например, можно записать в значение список магнит-ссылок на один фильм с разным качеством и реализовать добавление в торрент клиент по namecoin адресу.
Read more

Ориентировочные характеристики v1

on Mar 14, 2016

Пока набросок выглядит примерно так:

  1. Размер сообщения: до 10К. (не привязано к блокчейну, просто ориентир на ближайщее время). Это ориентир.
  2. 1 минута блок.
  3. размер блока до 500КБ. ~1500 сообщений
  4. Хеш-алгоритм BLAKE2s (Не PoW, только хеш-поинтеры)
  5. Длина блокчейна 50000 блоков, что чуть больше месяца.
  6. Вес блокчейна до 25 ГБ. Вес заголовков < 50 МБ. Вес полной базы сообщений до ~650 ГБ.
Read more

Блог о muon

on May 31, 2015

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

Muon планируется как продолжение идей Bitmessege. В то же время многое будет совершенно иначе.

В основе полноценная криптовалюта (MUONC), она должна служить следующим целям.

  1. Спамо и DDoS-устойчивость через транзакционные комиссии.
  2. Распределение участия. Возможность легких клинетов, которым не нужно загружать блоки (они оплачивают работу полных узлов через комиссии).
  3. Позволять PoS-минтинг или гибриный PoW/PoS.

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

  1. Высокий демёриджный налог. Токены живут в течении ограниченного количества блоков (буквально таят каждый блок).
  2. Адаптивный алгоритм. Так как есть как механизм накачки валюты, так и её сокращения. Есть большое желание использовать адаптивный алгоритм. Таким образом объем валюты будет зависеть от используемости (загруженности блокчейна). У этого тоже свои цели - форкоустойчивость и гибкость в случае возрастания пользователей.

Так же и сам блокчейн будет отличаться. Ключевое отличие: рабочий участок в n-блоков хвоста блокчейна. Нет необходимости хранить все блоки с начала времён, только заголовки. Ориентировочная длина 1 месяц. Это становится возможным из-за высокодемёриджной природы валюты. В старых блоках уже просто не может быть инпутов.

Read more
Add new post

Title

21 hours ago · 2 min read ·
3 comments
Body
Read more

Title

21 hours ago · 2 min read

0 Comments:

user_name1 day ago
Reply
Body
This page is a snapshot of ZeroNet. Start your own ZeroNet for complete experience. Learn More