Bitcoin Forum
November 19, 2024, 12:56:33 AM *
News: Latest Bitcoin Core release: 28.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: Proof of Stake  (Read 2122 times)
Ninazu (OP)
Newbie
*
Offline Offline

Activity: 58
Merit: 0



View Profile
March 23, 2014, 06:29:00 PM
 #1

Хотелось бы обсудить реализацию POS. Общие принципы понятны. При генерации блока вероятность его сгенерировать больше у того майнера, у которого на счету больше монет. Кто-то вникал более глубоко? Интересует само техническое решение этой задачи. Или может подскажет название функции где это реализовано в сорцах
Lis
Sr. Member
****
Offline Offline

Activity: 293
Merit: 251


Spice must flow!


View Profile
March 24, 2014, 06:52:18 AM
 #2

watch

You would like to thank?
btc: 14tAPpwzrfZqBeFVvfBZHiBdByYhsoFofn
pant-79
Hero Member
*****
Offline Offline

Activity: 994
Merit: 502


View Profile
March 25, 2014, 09:38:13 AM
 #3

Выдернуто из обсуждения Novacoin:
Quote
В сети  Новакоин PoS является доминирующим методом генерации блоков. Proof-of-Work сложность в данном случае выставляется такой, чтобы сеть создавала один PoW блок за полчаса (48 PoW блоков в сутки). Вдобавок 144 блока создаются с использованием Proof-of-Stake (6 блоков в час).Итого выходит 192 блока в сутки, 8 блоков час, один блок в 7.5 минут(?)
На генерацию PoS блоков требуется время, и с ростом PoS-мощности оно будет расти. У PoS блоков тоже есть сложность и проверка по ней, сложность вычисляется независимо от PoW сложности, но по тем же правилам, что и PoW.

1. В PoS системе инструмент для генерации (аналог мощности для  PoW) - это произведение количества монет на возраст (с границей 90 дней сверху), или coin-days.
2. Сложность устанавливается аналогично тому, как это происходит в PoW-системах, и зависит от количества активных coin-days в системе в целом. Сложность 1.00 для PoS системы - это в среднем 4.295 * 10^9 coin-day-second на блок.
3. Если количество активных coin-days растет, это соответственно приводит к росту PoS сложности. Сложность мы используем в качестве параметра в отрицательной обратной связи, т.е. при росте веса активных стейков падают объемы stake генерации.
4. И наоборот, при уменьшении веса активных стейков сложность падает и объемы генерации растут.

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

POS-блок содержит CoinStake транзакцию. Которая принимает на вход зарезервированные средства, а на выходе выдает (столько же + Interest). Cм. в клиенте функции IsCoinBase, IsCoinStake и IsProofOfStake.
Монеты, использованные для создания PoS-блока, становятся частью coinstake-транзакции. А потому, будут висеть со статусом "immature", пока блок не подтвердится. Доступны они станут после 520 подтверждений блока, это ~3 дня. А вот повторно использовать для создания блока их можно будет не ранее чем через 30 дней. Если же найденный блок попадает в орфан, то после того как кошелек "поймет", что блок отвергнут сетью, у монет их "монето*день" сохранится и они опять будут пытаться сгенерировать блок.

Обработка транзакций стейкхолдерами производится так же, как и майнерами, 1 блок в 10 минут. Если есть доступные для голосования монеты, то кошелек автоматически запускает отдельным потоком CPU-майнер и генерирует PoS-блоки с использованием этих монет. Все что нужно, это чтобы кошельки стейкхолдеров были в онлайне. И за это стейкхолдерам падает годовой процент от хранимых ими в кошельке монет. Кошелек пытается создать транзакцию с "удачными" параметрами. Как и в случае с PoW майнингом, тут может быть удача и неудача. PoS майнинг не работает с зашифрованным кошельком. Не потому, что так кто-то решил, а потому что это невозможно без использования приватных ключей. Stake транзакцию после нахождения хэша нужно подписать, затем нужно подписать заголовок блока. Для этого нужны ключи, а доступа к ним в зашифрованном и заблокированном бумажнике нет. Потому что на то он и заблокирован, чтобы ключи были недоступны.

Блок PoS будет собран тем клиентом, кто успел предложить монеты с наибольшим 'весом' (пропорционально: объем * время неиспользования).
После формирования блока PoS, монеты, которые использовались в нем дробятся пополам. Дробить обязательно, у coinstake-транзакции должно быть как минимум два выхода. Дробит он их, чтобы в будущем было в кошельке больше материала для генерации блоков. Дробление происходит только для входов моложе 90 дней.
Разбиение именно пополам сделано по не очевидной с первого взгляда, но очень простой причине. Сейчас дополнительные инпуты создаются постепенно, у них всех получается немного разный возраст. В результате даже при низкой сложности генерация блоков со временем станет плавной, продолжающейся в течение всего 30-дневного периода. Если же сделать сразу разбиение на N кусков, то у всех инпутов получится одинаковый возраст и при низкой сложности это приведет к очень простому результату - все рожденные в прошлом месяце инпуты "сгорят" за несколько дней, задерут сложность и на этом все закончится до следующего месяца, когда сложность снова упадет до минимума и подскочит в конце.
Сети выгоднее большое количество инпутов, а не маленькое. Один блок в месяц не приносит практически никакой пользы сети, в отличие от сорока. Таким образом, чрезмерная склейка представляет прямую угрозу безопасности сети. Когда человек скупает с рынка кучу инпутов и склеивает их, он фактически выводит их из процесса генерации блоков, облегчая потенциальному злоумышленнику задачу. Другими словами, сети нужно побольше инпутов, чтоб быть защищенной. Аналог сложности в PoW. Потому они и дробятся при PoS генерации. С другой стороны, лежать им более 90 дней нет смысла, так как это ничего не дает сети. Потому старые склеиваются.
При необходимости PoS-майнер может и будет подключать в coinstake-транзакцию дополнительные входы, в том числе и те, что получены в результате дробления в прошлом.
Количество входов ограничено сверху, не более 100 штук. кошелек выбирает все не потраченные входы, соответствующие условиям по возрасту. Возможно, стоит это пересмотреть, т.к. это открывает лазейку для DoS атаки на адреса генерирующих блоки нод. В теории, их можно зафлудить мелкими транзакциями и им станет нехорошо через 30 дней, если владелец ноды не склеит флуд. С другой стороны, такая атака требует пересылки атакуемому очень заметной суммы денег (столько монет еще не сгенерировано, и еще будет сгенерировано нескоро), т.е. является очень дорогим удовольствием.
Адреса большого значения не имеют, единственное требование - у создающего блок должен быть приватный ключ для адреса в vout[1]. Для PoW блоков есть аналогичное условие, адрес в выходной точке coinbase-транзакции обязательно должен принадлежать автору блока, в PPC это обязательно адрес в vout[0]. В NVC это условие выглядит по-другому - адрес по крайней мере одной произвольной выходной точки vout[n] в coinbase-транзакции должен принадлежать автору блока, остальные адреса могут быть любыми. На данный момент монеты отправляются на тот же адрес, с которого пришли. Но это изменится в будущем, когда клиенты начнут подключать дополнительные входы в coinstake-транзакции по мере роста PoS-сложности.

Минимальный возраст инпута 30 дней, "полный" вес он набирает через 90 дней. DayWeight считается со смещением -30 дней. То есть, максимум PoS мощности (DayWeight * Volume) достигается на 120-й день с момента создания инпута. Лимит возраста имеет значение только при бруте хэша, на награду он не влияет. Для кошелька over 9000 дней будет все равно, что 90. В плане веса получившегося kernel hash. Но награда при этом получится соответствующая прошедшему времени. Под весом хэша имеется в виду значение, на которое умножается таргет перед сравнением с ним. Чем он больше, тем мягче получается условие проверки хэша. Это просто произведение количества на возраст. Если у тебя 1 монета с возрастом 30 дней, у тебя 30 монето-дней. Если у тебя 1 монета с возрастом 90 дней, то у тебя 90 монето-дней. В классическом представлении, если у тебя 1 монета с возрастом 1000 дней, то у тебя 1000 монето-дней, но в неравенство проверки хэша подставится лишь 90 (однако, награда посчитается как для 1000). После 120 дня шанс найти хэш инпутом перестаёт расти. Но когда этот инпут всё-же сгенерирует блок награда будет за все дни, сколько бы не пролежал инпут. (но не более 10 монет). В PPC и существующих форках NVC монето-дни в таком случае будут полностью монетизированы в соответствии с действующими условиями (где-то они статичны, где-то динамические). Сколько бы PoS блоков не нагенерил стейкхолдер, вознаграждение в итоге у него получится одинаковое, и зависящее лишь от суммы использованных монет и их возраста. Возраст монет влияет лишь на награду, которую получит за свою работу стейкхолдер. Чем старше, тем больше он получит. В NVC в таком случае произойдет упор в 10 монет. с целью предотвращения будущей возможности безнаказанного манипулирования PoS-сложностью, которое могли проводить владельцы большого количества монет, максимальная награда за PoS блок не может превышать 10 нов. Это значит, что становится невыгодно склеивать в кучу (в одну транзакцию) больше количество монет. Тем самым владелец большой суммы не сможет занизить сложность склеив всю сумму (которая создала бы всего один блок, но с большой наградой), не потеряв бы при этом прибыль. Награда для склеенных монет расчитывается как для единого целого. То есть, нет разницы в плане награды между одним входом 600 монето-дней и 6 по 100 монето-дней, в теории. На практике же coinstake транзакция размером больше 1кб облагается комиссией на трафик, 0.01 за 1кб, а потому транзакция с большим количеством входов даст меньше, чем транзакция с одним входом. Возможна даже ситуация, когда награда окажется отрицательной, но это все равно выгоднее склейки руками.
Склейка предназначена для ликвидации слишком старых/слишком мелких входов, она не влияет на вес хэша. Входы добавляются к уже готовой coinstake транзакции после нахождения хэша, соответствующего неравенству.

Первичный период созревания монет размером в 30 дней выставлен c целью ограничения роста сложности из-за крупных держателей валюты. В системе без такого ограничения по мере ее развития генерация блоков рано или поздно окажется почти полностью в руках одного или нескольких крупных инвесторов. И нет рычагов, которые позволили бы смягчить данную ситуацию. Т.е. в итоге получается централизованная система, в которой само по себе существование блокчейна не имеет смысла. Поэтому от реализации такого концепта на практике отказался даже его автор.
На самом деле подошло бы любое другое значение, которого было бы достаточно для усложнения влияния мощного майнера на пересчет модификатора coinstake транзакции. Если уменьшить окно до 2 недель, к примеру, то для достижения идентичного уровня безопасности потребуется одно из трех -
1) сократить размер выборки блоков;
2) многократно использовать одни и те же блоки (к примеру, дополнением к текущей выборке) со сдвигом и исключающим правилом наложения;
3) ускорить генерацию блоков.
Первый вариант является наихудшим т.к. портит энтропию, второй заметно усложняет систему, третий увеличивает долю орфанов.
Генерация блока сразу после созревания инпута далеко не гарантирована, и с ростом сложности этот момент будет все дальше отодвигаться от 30-дневной отметки. Причем, со временем сложность вырастет достаточно для того, чтобы 30-дневный период созревания казался несущественной мелочью.

Так как сумма и вес легко поддаются манипуляциям, а потому не могут быть использованы в качестве критериев при оценке доверия сети блоку,то оба этих параметра сами по себе не имеют никакого значения. Значение имеют только nBits (читай сложность) и соответствие proofhash неравенству.
Для новы график эмиссии PoS блоками определяется так:
Code:
nReward = nCoinAge * 33 / (365 * 33 + Cool * 5 * CENT

У чистого PoW сложность зависит от мощности сети, у чистого PoS сложность персональная для юзера и зависит от отношения его объема "голосующих" монет к общему объему "голосующих" монет. По умолчанию все доступные монеты являются "голосующими", если не задано жестко, сколько монет для этого не использовать. Зарезервированный объем "не голосующих" монет может быть просмотрен или изменен RPC-методом reservebalance. Юзер может выставить лимит в настройках и предоставить клиенту шуршать оставшимися сверх лимита мон
Ninazu (OP)
Newbie
*
Offline Offline

Activity: 58
Merit: 0



View Profile
March 25, 2014, 08:32:19 PM
 #4

Спасибо друзья! Помогло. Хотя думаю вопросы еще возникнут, когда начну копать глубже)
info_infoman
Sr. Member
****
Offline Offline

Activity: 460
Merit: 250



View Profile
March 26, 2014, 12:20:59 PM
 #5

Ну намудрили.... есть схема гораздо проще...

Народ подскажите
Можно ли технически реализовать трату с одного адреса не паралельно а последовательно?

грубо говоря  есть 10 монет на адресе - заложить правило в котором за одну транзакцию можно потратить 1 монету за 1 блок
и в последующие разы (блоки) тратить неиспользованные инпуты?

никаких сдач никаких комиссий чисто трата последовательно. Huh? сколько не задаю этот вопрос все молчат как рыбы.

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

pant-79
Hero Member
*****
Offline Offline

Activity: 994
Merit: 502


View Profile
March 26, 2014, 03:50:23 PM
 #6

Ну намудрили.... есть схема гораздо проще...

Народ подскажите
Можно ли технически реализовать трату с одного адреса не паралельно а последовательно?

грубо говоря  есть 10 монет на адресе - заложить правило в котором за одну транзакцию можно потратить 1 монету за 1 блок
и в последующие разы (блоки) тратить неиспользованные инпуты?

никаких сдач никаких комиссий чисто трата последовательно. Huh? сколько не задаю этот вопрос все молчат как рыбы.

если можно то подскажите в какую функцию проверки инпутов можно эту функцию припилить чтобы майнер принимал только правильные транзакции к созданию блока.
Все молчат, как рыбы, потому что это идиотский вопрос. Криптовалюты функционируют по другому.
rPman
Legendary
*
Offline Offline

Activity: 1120
Merit: 1069


View Profile WWW
March 26, 2014, 04:01:00 PM
 #7

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

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

Здесь не может находиться ваша реклама Smiley
Protect a future of bitcoin, use p2pool
Donation in BTC: 19fv5yYtfWZ9jQNjx2ncmu1TTrvg5CczZe
salsacz
Hero Member
*****
Offline Offline

Activity: 490
Merit: 504


View Profile
March 26, 2014, 04:04:58 PM
 #8

http://aboutcoins.ru/analytics/pochemu-nxt-stoit-voprinimat-vser-ez

http://somewords.ru/next/nxt.html

http://somewords.ru/next/nxt2.html

https://cryptohabr.ru/analytics/2014/03/04/decentralizovannyy-internet-i-nxt-chast-1.html
info_infoman
Sr. Member
****
Offline Offline

Activity: 460
Merit: 250



View Profile
March 26, 2014, 04:24:50 PM
 #9

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

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

я так понимаю что чтобы сеть начала учитывать неиспользованные инпуты(последовательную трату)
достаточно в main.cpp прописать правило по которому будет вестись пересчет инпутов и аутов в предыдущих блоках и если сумма прев-инпутов больше, то можно включит транзу в блок?
я имею ввиду объем монет.

не повлияет ли такая фишка на механизм подписи права собственности на n монет? для последующей траты?

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

info_infoman
Sr. Member
****
Offline Offline

Activity: 460
Merit: 250



View Profile
March 27, 2014, 10:38:21 AM
 #10

А давайте соберем в этой теме самые непонятные моменты в pos думаю всем будет полезно.

Quote
POS-блок содержит CoinStake транзакцию. Которая принимает на вход зарезервированные средства, а на выходе выдает (столько же + Interest). Cм. в клиенте функции IsCoinBase, IsCoinStake и IsProofOfStake.

Вот main.h
bool IsCoinStake() const
    {
        // ppcoin: the coin stake transaction is marked with the first output empty
        return (vin.size() > 0 && (!vin[0].prevout.IsNull()) && vout.size() >= 2 && vout[0].IsEmpty());
    }

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

pant-79
Hero Member
*****
Offline Offline

Activity: 994
Merit: 502


View Profile
March 27, 2014, 12:40:42 PM
 #11

Зовите Бальтазара в студию. Авось объяснит...
info_infoman
Sr. Member
****
Offline Offline

Activity: 460
Merit: 250



View Profile
March 27, 2014, 01:13:38 PM
 #12

Зовите Бальтазара в студию. Авось объяснит...

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

хорошая бы была идея создать Faq по главным функциям pos
ну и общая схема работы(алгоритм) в исходниках.

pant-79
Hero Member
*****
Offline Offline

Activity: 994
Merit: 502


View Profile
March 27, 2014, 01:25:14 PM
 #13

Зовите Бальтазара в студию. Авось объяснит...

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

хорошая бы была идея создать Faq по главным функциям pos
ну и общая схема работы(алгоритм) в исходниках.
Ну на гитхабе что-то такое есть в описании исходников новы...
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!