Уважаемый ТС, как обстоят дела по прогрессу на данный момент времени??
Пишу потихоньку в одно лицо очень крыша едет просто. Сейчас по сути осталось написать примитивный блокчейн, для хранения данных. Приходится изучать этот вопрос, как хранить, как лучше описывать итд. Есть готовые решения, но копаться и разбираться в них, это тратить много времени. Процесс идет. Интересно, буду следить.
Кроме POW будет ли какой нить способ получить токены до запуска?
POW будет участвовать только в процессе подключения ноды, в процессе майнинга нет, будет другой алгоритм. токены до запуска возможно будут раздаваться, об этом еще не думал, хочу написать простой прототип, который можно будет запустить, потестить и там уже думать. возможно обосрусь если не секрет конечно то в чем конечная замка проекта? допустим все пошло идеально и как вы хотели то как вы видите свой проект? и на какое количество пользователей вы планируете?
весь проект крутиться вокруг нового алгоритма POH, который доказывает выполненную работу определенной нодой, но не требует много ресурсов. блокчейн + POH. те же яйца, только в профиль + не надо майнинговое оборудование и не надо POS блокировки средств. кто первый подключился к системе того и тапки. Делай сразу как монету мраи))) кран и все разгадывают капчу)) к вечеру распределение монет))
Я что-то видать давно не в теме На сколько выгодно майнить вашу монету на обычном ноутбуке.
Так как количество нод в вашей сети растёт интересно, на сколько выгодно зайти в вашу монету без специального оборудования ферм, асиков.
А на каком алгоритме происходить Pow: Scrypt?
Количество нод сейчас ноль. pow алгоритм другой. используется только в подключении новых нод, где сложность увеличивается от количества нод в системе. требования это 24/7 быть в сети, статический ip, чем больше памяти тем быстрее будет проходит обработка данных. если не секрет конечно сколько активно сейчас работают над проектом?
именно 24/7 а не те кто просто проходили мимо. такой проект нельзя просто на выходных делать.
проект делается просто на выходных и свободное время. |
|
|
|
|
18. Входы-выходы или красота в простоте
При проведении транзакции например от Пети к Ане:
1) У пети 10 атомов и он переводит Ане 2 атома.
2) Ищем в блокчейн последнюю запись, где написано сколько у Пети денег.
3) В новом блоке в заголовке пишем, что у пети 8 атомов, у ани 2 атома
То есть в каждом новом блоке с текущими транзакцией будет последнее значение полного кошелька со всеми переводами.
Последний встречающийся адрес в блокчейн будет содержать текущее состояние кошелька.
- Если надо проверить валидность денег в последнем блоке, надо проверить предыдущие блоки, на наличие входов (переводов)
|
|
|
|
|
а как нода проверяет транзакцию, которая упала в мемпул? она проверяет весь блокчейн от начала времен, чтобы найти все возможные выходы по этому адресу?
|
|
|
|
Блок состоит из
1. заголовка
2. транзакций
3. сегвит данных
Хэш Меркла находится в заголовке блока.
Допустим к вам пришла транзакция, как узнать: есть ли эта транзакция в блоке? Варианта два
1. если у вас есть все блоки целиком, то надо просто посмотреть транзакцию в нужном блоке.
2. если у вас легкий клиент и/или блоки хранятся не целиком, то вы можете проверить наличие транзакции в блоке с помощью хэша Меркла.
Алгоритм проверки я точно не знаю, но примерно он должен выглядеть так:
1. Берем из транзакции номер блока
2. Достаем из своей базы заголовок блока с нужным номером
3. Достаем из заголовка хэш Меркла - корень дерева (К)
4. Посылаем в сеть сообщение: "пришлите мне ветки и листья дерева Меркла для транзакции"
5. Когда ветки и листья присылают, можно их прохэшировать. Если хэш даст корень К, значит все хорошо.
Самое прикольное в этом то, что для проверки не нужны все транзакции блока, а нужны только те ветки и листья в которых есть хэш нужной транзакции.
На примере будет понятней.
Пусть в блоке шесть транзакций A, B, C, D, E, F
Тогда хэш Меркла формируется следующим образом
Ветка01 = хэш(A+B)
Ветка02 = хэш(C+D)
Ветка03 = хэш(E+F)
Ветка11 = хэш(Ветка01 + Ветка02)
Ветка12 = хэш(Ветка03 + Ветка03)
Корень = хэш(Ветка11 + Ветка12)
Теперь допустим надо проверить: существует ли транзакция D в блоке? У нас есть только Корень, что мы делаем?
Мы ищем в сети соседей у которых есть блоки целиком и просим: "подайте пожалуйста бедному SPV клиенту несколько веточек Меркла для транзакции D"
Добрые соседи хоть и добрые, но все таки скупые и все ветки вам не дадут ибо для проверки достаточно знать: С, Ветка01, Ветка12.
То есть в примере вместо 5 хэшей (A,B,C,E,F) вы получаете только три (С, Ветка01, Ветка12), но при этом все равно можете точно проверить наличие транзакции в блоке.
Корень = хэш(хэш(Ветка01 + хэш(C+D)) + Ветка12)
объяснение топ, спасибо  - получается в самом процессе создания блоков во время майнинга, меркель не используется? - меркель учитывается для быстрого поиска нужных транзакций в блоках и быстром обмене данных? |
|
|
|
|
Подскажите, зачем надо делать для каждого блока merkel tree, вместо обычного хеша?
|
|
|
|
Ну вроде во втором классе средней школы проходят.
1 = 01 = 001 = 0001 = 00000...000001
2 = 02 = 002 = 0002 = 00000...000002
0000000000000000002a3efa7588628ea72576cd1fc7384c2ed4ca9e26d77040 = 2a3efa7588628ea72576cd1fc7384c2ed4ca9e26d77040
00000000000000000016ea0bd16532a3d726a01b60dcf34d0756c5140c76a007 = 16ea0bd16532a3d726a01b60dcf34d0756c5140c76a007
ВНЕЗАПНО:
1 < 2
0001 < 0002
допер 
00000000ffff0000000000000000000000000000000000000000000000000000 - это константа, это - максимально возможный target, его нельзя превысить, то есть, хеш блока всегда будет меньше либо равен этому числу.
target - 256-битное число. Числа фиксированной длины принято отображать с нулями перед значащими цифрами. Так принято для наглядности. То есть, у хеша любого блока будет минимум 8 нулей спереди (при отображении в шестнадцатеричном виде!).
При пересчёте сложности target может уменьшаться. Понятно, что при его уменьшении, нулей спереди станет больше. Значит, и у хеша блока число нулей спереди увеличится, он ведь должен быть меньше или равен target.
получается, что нули спереди, это не результат перебора nonce, а просто потому что мы 16-ю систему перевели в 256 и в начале автоматом выставились нули? то есть смысл nonce, просто перебирать числа, чтобы наше число оказалось меньше числа таргет и чем меньше таргет, тем соответственно больше в начале нулей, так как отображение 256 бит! бомба, когда понимаешь, так просто кажется, в начале дебри были какие-то |
|
|
|
просто в коде не нашел сравнение по количеству нулей в начале, вижу только if (thash <= hashTarget)
Ну, всё правильно. Выполняется сравнение двух чисел, и по результату сравнения принимается решение: итерировать ли дальше nonce или мы таки нашли хеш заголовка блока, подходящий под текущий target. И чего вы к этим нулям прицепились? С чего вы, вообще, взяли что происходит сравнение по количеству нулей? почему каждый хеш блока, который нашел нужный nonce, выглдят так: 0000000000000000002a3efa7588628ea72576cd1fc7384c2ed4ca9e26d77040 или 00000000000000000016ea0bd16532a3d726a01b60dcf34d0756c5140c76a007 то есть всегда в начале нули? получается ближайшее значение к таргет, это значение с нулями? |
|
|
|
Так "находим" или "первое попавшееся"? Это разные вещи.
Слово "находим" предполагает некоторую последовательность действий.
https://github.com/neiros/---TTC--TDC---/blob/TDC/src/miner.cpp#L779просто в коде не нашел сравнение по количеству нулей в начале, вижу только if (thash <= hashTarget) Вам, может, лучше сначала книжку про Bitcoin прочитать. На русском языке. Там есть разные разделы: Ключи, Транзакции, Блокчейн - выбирайте любой. спасибо, почитаю, что-то новое обязательно найду. принцип работы nonce я понимаю, хочется понять под капотом |
|
|
|
Утверждение "мы ищем хеш с нулями в начале" не противоречит утверждению "любой хеш ниже таргета", а является следствием из него. Если a< b, то количество значащих цифр числа a меньше либо равно количеству значащих цифр числа b.
Впрочем, если вас сбивают с толку эти нули - не обращайте на них внимания.
приведу пример в двоичной системе, как я это вижу: есть число таргет (a) = 99 мы находим число 1 (b) и удовлетворяем формулу a<b тогда первое попавшееся число удовлетворяет, формулу. мне кажется я просто не до дупляю что-то с 256 битной системе  |
|
|
|
получается мы ищем хеш с нулями в начале, потом переводим хеш в 265-бит, и проверяем, чтобы он был меньше таргет, тогда хеш валиден?  Хэш это 256 битное число Таргет это 256 битное число Если найденный хэш меньше или равен таргету, значит зашибись! значит нули вообще не причем? то есть любой хешь, ниже таргета? |
|
|
|
получается мы ищем хеш с нулями в начале, потом переводим хеш в 265-бит, и проверяем, чтобы он был меньше таргет, тогда хеш валиден? |
|
|
|
Чем больше нулей в начале, тем меньше 265-битное число.
ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff - максимальное
00000000000000000000000000000000ffffffffffffffffffffffffffffffff - среднее
0000000000000000000000000000000000000000000000000000000000000000 - минимальное
Все те 265-битные числа меньше этого таргета - 0000002cd2130000000000000000000000000000000000000000000000000000
Любой хеш меньше таргета будет валидным.
я не понял а как он определяет, что меньше этого таргета? он переводит его в десятичные и сравнивает? или как происходит сравнение? |
|
|
|
толковая статья, но не могу принципа работы уловить, там написано: Хеш блока может быть каким угодно, но не меньше 265-битного числа значения таргета, например, такого:
0000002cd2130000000000000000000000000000000000000000000000000000
Валидный хеш блока биткоина или подобных криптовалют при таком таргете может бить таким
0000002cd2107f99fb83761bdb34a4a86ca1acb711a3c6082acb7af567960ef3
или таким
00000000b7082acb7af5672cd21b7f98a1916c3c61a60ef3a9fb83761bdb344a
или таким и т.п.
000000000000000000000a4ac3761bdb321b7f98b7af5672c1a3c6f8b6ca196f почему таргете в начале 6 нулей, а в внизу написано, что валидны хеши с большим количеством нулей? |
|
|
|
https://en.bitcoin.it/wiki/Difficultybits это компактное представление target. Можно так написать target = target_from_bits(bits); target (цель) это 256 битное число. Чем меньше это число, тем больше сложность. Формула перевода невероятно сложная, но я ее тут приведу. Приготовьтесь: difficulty = target_from_bits(0x1d00ffff) / target  сложность определяется количеством нулей в хеше, не могу понять, число difficulty на выходе будет равно количеству нулей? |
|
|
|
https://bitcoin.org/en/developer-reference#block-headersвот еще хороший материал, если кому интересно не могу понять только, какой смысл поля nBit, для высчитывая сложности nonce?описание выглядит так An encoded version of the target threshold this block’s header hash must be less than or equal to. See the nBits format described below.https://bitcoin.org/en/developer-reference#target-nbitsесть еще на русском, но ничего не понятно Как я уже написал выше, весь майнинг сводится к тому, чтобы найти хэш блока меньше числа, называемого target. В структуре блока это число записывается в поле bits, например для блока #277,316, target равнялся 1903a30c.
$ bitcoin-cli getblock 0000000000000001b6b9a13b095e96db41c4a928b97ef2d944a9b31b2cc7bdc4
{
"hash" : "0000000000000001b6b9a13b095e96db41c4a928b97ef2d944a9b31b2cc7bdc4",
"confirmations" : 35561,
"size" : 218629,
"height" : 277316,
"version" : 2,
"merkleroot" : "c91c008c26e50763e9f548bb8b2fc323735f73577effbc55502c51eb4cc7cf2e",
"tx" : ["d5ada064c6417ca25c4308bd158c34b77e1c0eca2a73cda16c737e7424afba2f", 418 more transactions],
"time" : 1388185914,
"nonce" : 924591752,
"bits" : "1903a30c", // Here it's
"difficulty" : 1180923195.25802612,
"chainwork" : "000000000000000000000000000000000000000000000934695e92aaf53afa1a",
"previousblockhash" : "0000000000000002a7bbd25a417c0374cc55261021e8a9ca74442b01284f0569",
"nextblockhash" : "000000000000000010236c269dd6ed714dd5db39d36b33959079d78dfd431ba7"
}
|
|
|
|
Спасибо, буду изучать upd: для питона 14 проектов, но это скелеты работы блокчейна, причем очень утрированные. что давно уже реализовано у меня. нет работы конкретно по самому принципу входов выходов. буду значит курить сам биток, либо книгу |
|
|
|
У тебя какие-то нубские вопросы для писателя своей крипты с блекджеком. Скорость работы базы зависит от используемого движка и пользовательского устройства. Чаще всего для крипты используют BerkeleyDB и LevelDB. Это nosql БД, то есть key-value хранилище в котором значение (value) присваивается ключу (хешу) и ищется исключительно по нему. С HDD, а тем более SSD эти БД практически на любом конфиге легко справляются с сотнями тысяч, а то и миллионом PUT/GET операций в секунду (при value = 100 байт). http://www.lmdb.tech/bench/microbench/benchmark.htmlСпасибо Я не про базы спрашивал, а про принцип хранения в базе, в первую очередь сам принцип работы входов-выходов. Я использую как раз redis и знаю, что это такое. Перефразирую вопрос, где можно почитать о самом принципе работы входов-выходов. А есть смысл этого блокчеина ? Можно использовать же готовые решение по типу еоса. Кстате попробуйте форкнуть биток или еще любую монету может будет легче разбиратся в работе бч.
Я пишу на питоне, поэтому будет тяжело разгребать С код. проще написать базовый функционал самому. А так смысл есть писать свой блокчейн, та как есть идеи по новому алгоритму консенсуса. Если определился со стэком, найди "лучшие практики" крипты на нем, затем изучай его код на гитхаб. Все есть в открытом доступе.
Мы таким образом и двигались при разработке своей платформы.
P.s. в скором времени будем публиковать по нашей платформе(скорее не платформа а framework*) материалы и туториалы. Хотим сделать её проще чем эфир (в плане разработки СК), но существенно функциональнее и гибче - вероятно может заинтересовать, как пример для разбора.
*
Фреймворк для блокчена это очень хорошая идея |
|
|
|
|
17. База данных на Redis
Сам блокчейн будет храниться в redis. В памяти будет висеть база с указателями на последние выходы, в формате address:blockchain_number (адрес кошелька:номер блока). Можно сказать, что это будет просто кеш последних значений, где находятся данные для проверки по конкретным владельцам кошельков. Если сервер выключится или будет сбой, то база в памяти исчезнет, но это не повлияет на работу Атома. Входы и выходы будут проверяться соответственно быстрее чем, в обычной базе данных, так как указатели будут находится в памяти и скорость обработки информации будет максимальной.
Итог:
- храним классический блокчейн в redis и сохраняем эти блоки на диск
- держим в памяти указатели на нужные блоки
- проверяем быстро транзакцию на валидность и проводим ее
- добавляем новый блок
Инфа из википедии:
Redis (от англ. remote dictionary server) — резидентная система управления базами данных класса NoSQL с открытым исходным кодом, работающая со структурами данных типа «ключ — значение». Используется как для баз данных, так и для реализации кэшей, брокеров сообщений.
Ориентирована на достижение максимальной производительности на атомарных операциях (заявляется о приблизительно 100 тыс. SET- и GET-запросов на Linux-сервере начального уровня). Написана на Си, интерфейсы доступа созданы для большинства основных языков программирования.
|
|
|
|
|
очевидно что вам надо threading
я бы в памяти держал 1млн ключей или распихал бы в 100 файлов по 10т ключей, и создал вы потоки, который каждый отдельно работал со свободным файлом.
|
|
|
|
|
Всем привет, пишу свою крипту, дошел до фазы создания блоков. хочу изобрести велосипед и местами со своим блэкджеком.
Подскажите толковый материал, а именно по принципу работы входов-выходов, как именно хранятся данные в блоках, скорость работы базы и какой принцип работы поиска в базе (на физическом носители или в памяти)? Буду признателен, если кто сталкивался с технической частью
|
|
|
|
|
Show Posts
