Я даже на перле его переписал, все не то.
оффтоп
Настроение херня, на бирже сегодня не повезло.
Topic: DIANNA: IANA Decentralized концепт дизайн - page 4. (Read 31411 times)
Да полностью левый эмулятор. Я его гоняю, поражаюсь.
То что цену шатало, это я пофиксил. Там формула Fprev/Fpprev, Только Fpprev это частота двух последних чепоинтов, а Fprev - частота только последнего. Тогда нормально затухает.
При чем функция затухания зависит от k_max (макс изменения цены). Сейчас 1/k_max < k < k_max, k_max=4. Это значение должно быть больше двух (Fprev/Fpprev), чтобы затухание шло и цена стабилизировалась.
Так же k_max/2 определяет, насколько резкий скачок параметров за чекпоинт система способна адекватно пережевать. Если параметры скачут быстрее чем k_max/2 каждый чекпоинт, то начинаются чудеса. Если же параметры скакнули хоть в 10 раз, но однажды, то жрет нормально.
Соответственно, чем больше k_max, тем лучше система справляется с резкими переходами. Однако изменение цены в 10 раз, например, это вам не здрасте.
Где золотая середина?
Эмулятор очень кривой.
1. Не умеет работать с ситуациями, когда спроса вообще нет
2. Находит блоки с 0 транзакциями
3. Вот эта гребенка на предыдущем графике - создается им же, т.к. бешеное количество транзакций обрушивается на блок внезапно раз в 600 секунд
То что цену шатало, это я пофиксил. Там формула Fprev/Fpprev, Только Fpprev это частота двух последних чепоинтов, а Fprev - частота только последнего. Тогда нормально затухает.
При чем функция затухания зависит от k_max (макс изменения цены). Сейчас 1/k_max < k < k_max, k_max=4. Это значение должно быть больше двух (Fprev/Fpprev), чтобы затухание шло и цена стабилизировалась.
Так же k_max/2 определяет, насколько резкий скачок параметров за чекпоинт система способна адекватно пережевать. Если параметры скачут быстрее чем k_max/2 каждый чекпоинт, то начинаются чудеса. Если же параметры скакнули хоть в 10 раз, но однажды, то жрет нормально.
Соответственно, чем больше k_max, тем лучше система справляется с резкими переходами. Однако изменение цены в 10 раз, например, это вам не здрасте.
Где золотая середина?
Эмулятор очень кривой.
1. Не умеет работать с ситуациями, когда спроса вообще нет
2. Находит блоки с 0 транзакциями
3. Вот эта гребенка на предыдущем графике - создается им же, т.к. бешеное количество транзакций обрушивается на блок внезапно раз в 600 секунд
Когда происходит резкий скачек значения Fprev/Fpprev, то оно дальше не затухает. Идет "гармошкой": медленный-быстрый-медленный-быстрый и т.д.
Надо ввести затухающий фактор в это выражение.
Надо ввести затухающий фактор в это выражение.
Это естественно что шатает -- но это редкое событие раз в 210000 блоков
Но да можно формулы подкрутить чтобы переход был плавнее
Дело не в том что редкое. А в том, что его шатнуло раз и дальше пошел раскач. Незатухающий.Но да можно формулы подкрутить чтобы переход был плавнее
Сейчас формула пересчета цены Fprev/Fpprev
То есть, диана вычисляет ее из своего "виртуального времени" без привязки к реальности.
Если мы будем считать Fprev/Fbitcoin, привязываясь, то это форсанет систему держать выход блоков в строгих рамках. Но активность в немспейсах может быть разная. А оно будет форсировать определенную активность. Таким образом, шатать в таком случае будет цену.
Как быть?
Я вообще сразу не заметил но вот это вот плохо
Шатает очень нехило. В правильном направлении, но нехило.
Думаю дело не в pdiff, просто надо к какому то реальному показателю времени репрайсинг привязать. К степу например.
Шатает очень нехило. В правильном направлении, но нехило.
Думаю дело не в pdiff, просто надо к какому то реальному показателю времени репрайсинг привязать. К степу например.
Все таки, если в процессе происходит какой то фазовый сдвиг (Bounty 50 -> 25) например, система очень плохо стабилизируется, по графикам видно. С ценой то более-менее, а вот с остальным плохо - шатает во все стороны. В правильном направлении, но уж очень шатает.
И вообще, чет надоело мне в питоне это все считать и в маткад перекидывать. Счас буду в маткаде считать непосредственно.
И вообще, чет надоело мне в питоне это все считать и в маткад перекидывать. Счас буду в маткаде считать непосредственно.
Какая разница, какой bounty, какой trfee, какая стартовая цена?
Да любой может быть. Стартовую цену можно только прикинуть, даже с большой погрешностью. Как видно из графика, она стремится к ожиданиям общественности.
Я вот думаю, удовлетворенность клиентов временем выхода блока нужно считать не по этой формуле
43200/blktime
А по чето вроде
То есть, если блоки выходят с временем < ожидаемого, то все впорядке. А если больше, начинается экспоненциальное падение спроса.
Прально я говорю? А то предыдущая формула спрос взвинтила только потому что блоки выходят чаще чем требуется.
Да любой может быть. Стартовую цену можно только прикинуть, даже с большой погрешностью. Как видно из графика, она стремится к ожиданиям общественности.
Я вот думаю, удовлетворенность клиентов временем выхода блока нужно считать не по этой формуле
43200/blktime
А по чето вроде
Code:
1 if blktime < expected_blocktime
2**(1 - blktime/expected_blocktime) else
То есть, если блоки выходят с временем < ожидаемого, то все впорядке. А если больше, начинается экспоненциальное падение спроса.
Прально я говорю? А то предыдущая формула спрос взвинтила только потому что блоки выходят чаще чем требуется.
Code:
def num_domain_trans(step, prc, blktime):
k1=1.0*(start_price/prc)
k2=1.0
if (blktime > 43200):
k2=2**(1 - blktime/43200);
return sqrt(5*step)*k1*k2
Не вижу проблем с переходом на Bounty=25 BTC
В районе шага 30к переходим на 25 BTC
Что с ценой?
В районе шага 30к переходим на 25 BTC
Code:
bounty=50.0
for z1 in range(1, last):
if z1 == 30000:
bounty=25
#bla-bla
pdiff = domfee/(bounty + bitcom)
Что с ценой?
Надо будет взять какой то подходящий и перепилить.
Вообще дхт можно пилить параллельно. Сначала то, что будет находиться в дхт, складывать в виде заглушки в локальную отдельную базу.
А когда появится дхт, просто эту базу каждый клиент туда сольет, освободив место.
Вообще дхт можно пилить параллельно. Сначала то, что будет находиться в дхт, складывать в виде заглушки в локальную отдельную базу.
А когда появится дхт, просто эту базу каждый клиент туда сольет, освободив место.
Можно на экспоненте, только реальной какой то. Или просто наполнять буфер реальными данными неймкоин.
Ну и ожидание блока на час поменять.
Кодить думаю на яве. Там есть гугловский BitcoinJ и protobuf.
Ну и ожидание блока на час поменять.
Кодить думаю на яве. Там есть гугловский BitcoinJ и protobuf.
Ну можно еще погонять на другом спросе, на других ожиданиях кастомеров.
Ну а вообще по моему можно уже кодить. Мне надо только с текущей работой разгрестись.
Ну а вообще по моему можно уже кодить. Мне надо только с текущей работой разгрестись.
Ты шагал блоками дианы, а я шагаю блоками биткоин - почти реальным временем.
TTL я думаю будет измеряться в блоках биткоин. У нас же есть соответствие.
TTL я думаю будет измеряться в блоках биткоин. У нас же есть соответствие.
@pent
Ок. будет формула цены по-новому -- переделаю скрипт -- это быстро
я хочу погонять его блок за блоком -- как виртуальную сеть -- на случайных
( но правдоподобных ) данных -- тогда будет видно держит ли формула
равновесие системы скажем на 300000 блоков -- тест на пригодность
По-моему хорошо чтобы цена была 2-3 $ за доменную операцию -- в будущем
это еще зависит от того какой ты выберешь TTL домена
Сначала и для слабых сетей можно делать цену меньше
Но не думаю что этот подход будет проще -- посмотрим
---------------------------------------------------------------------------------------------------
А насчет контрактов - а юзает ли их кто-нибудь на практике ?
Если да -- то тебе было бы полезно с ними пообщаться -- мож чего подскажут
Ок. будет формула цены по-новому -- переделаю скрипт -- это быстро
я хочу погонять его блок за блоком -- как виртуальную сеть -- на случайных
( но правдоподобных ) данных -- тогда будет видно держит ли формула
равновесие системы скажем на 300000 блоков -- тест на пригодность
По-моему хорошо чтобы цена была 2-3 $ за доменную операцию -- в будущем
это еще зависит от того какой ты выберешь TTL домена
Сначала и для слабых сетей можно делать цену меньше
Но не думаю что этот подход будет проще -- посмотрим
---------------------------------------------------------------------------------------------------
А насчет контрактов - а юзает ли их кто-нибудь на практике ?
Если да -- то тебе было бы полезно с ними пообщаться -- мож чего подскажут
Оформил в вику http://dianna-project.org/wiki/Calc_1
Получается такое
Шаг на графике - 10 минут. Т.е. если step=100, то это 1000 минут. step типа время.
Время нахождения блока
Транзакций на блок
Цена транзакции
Доход майнеров на блок
Шаг на графике - 10 минут. Т.е. если step=100, то это 1000 минут. step типа время.
Время нахождения блока
Транзакций на блок
Цена транзакции
Доход майнеров на блок
Так, корректировка.
Значит спрос у нас будет такой:
sqrt(5*x)
Где x = шаг в 10 минут
Довольство клиентов будет измеряться более простой функцией
good_price/price
При good_price=1 вот такое довольство будет
Еще довольство будет зависеть от скорости выхода блоков. Ведь если блок выходит раз в неделю, то кому это надо, правильно?
Допустим, 5 часов - терпимый промежуток выхода блоков
43200/blktime
Тогда функция спроса будет такая
Я чесно не подгоняю ничего, я просто ввожу какие то адекватные обратные связи вида 1/x
Погоняем на другом спросе потом
Значит эмулятор будет такой
http://pastebin.com/HeP3kQKV
Получается вот что
http://dianna-project.org/c/diaemu.log
Значит спрос у нас будет такой:
sqrt(5*x)
Где x = шаг в 10 минут
Довольство клиентов будет измеряться более простой функцией
good_price/price
При good_price=1 вот такое довольство будет
Еще довольство будет зависеть от скорости выхода блоков. Ведь если блок выходит раз в неделю, то кому это надо, правильно?
Допустим, 5 часов - терпимый промежуток выхода блоков
43200/blktime
Тогда функция спроса будет такая
Code:
def num_domain_trans(step, prc, blktime):
return sqrt(5*step)*(start_price/prc)*(43200/blktime) ## changed coeff. 10 --> 2 !!!
return sqrt(5*step)*(start_price/prc)*(43200/blktime) ## changed coeff. 10 --> 2 !!!
Я чесно не подгоняю ничего, я просто ввожу какие то адекватные обратные связи вида 1/x
Погоняем на другом спросе потом
Значит эмулятор будет такой
http://pastebin.com/HeP3kQKV
Получается вот что
http://dianna-project.org/c/diaemu.log
ну вроде да
Хотя нет, в сад жаность майнера. Пусть делает что делает.
Сколько набрал из буфера - по такому PDiff и посчитал блок и выпустил его через соотв. количество секунд time = BitcoinDiff*(1+PDiff) * 2**32 / hashrate
Следующий блок можно считать только если выпущен предыдущий. То есть если на момент следующего "шага" системы предыдущий еще не выпустился, то следующий не считается.
Посмотрим как система сожрет такой SQRT спрос =)
Сколько набрал из буфера - по такому PDiff и посчитал блок и выпустил его через соотв. количество секунд time = BitcoinDiff*(1+PDiff) * 2**32 / hashrate
Следующий блок можно считать только если выпущен предыдущий. То есть если на момент следующего "шага" системы предыдущий еще не выпустился, то следующий не считается.
Посмотрим как система сожрет такой SQRT спрос =)
Но вообще это выглядеть будет так.
Существует буфер, куда добавляются "заказы" каждый раз в 600 секунд по функции NumTrans(N,price)=num_transactions(N)*dov(price/0.02), где N - номер "раза".
Из этого буфера майнер забирает транзакции в блоки.
Он должен набрать транзакций на PDiff~=10%. Тогда он выпускает блок. Если он не может выпустить блок по причине недостатка транзакций, он пытается его выпустить с вероятностью
p(PDiff)=100 - 4*(PDiff*100-10)^2
Если же он "перебрал" транзакций из буфера, то он тоже пытается выпустить блок с этой вероятностью.
То есть система "шагает" шагом в 600 секунд. Каждый шаг наполняет буфер транзакций по функции. И каждые 600 сек принимается решение о выпуске блока дианы
(если предыдущий успел рассчитаться).
Существует буфер, куда добавляются "заказы" каждый раз в 600 секунд по функции NumTrans(N,price)=num_transactions(N)*dov(price/0.02), где N - номер "раза".
Из этого буфера майнер забирает транзакции в блоки.
Он должен набрать транзакций на PDiff~=10%. Тогда он выпускает блок. Если он не может выпустить блок по причине недостатка транзакций, он пытается его выпустить с вероятностью
p(PDiff)=100 - 4*(PDiff*100-10)^2
Если же он "перебрал" транзакций из буфера, то он тоже пытается выпустить блок с этой вероятностью.
То есть система "шагает" шагом в 600 секунд. Каждый шаг наполняет буфер транзакций по функции. И каждые 600 сек принимается решение о выпуске блока дианы
(если предыдущий успел рассчитаться).
Смотри. Пусть транзакции у нас по 0.1 BTC.
Тогда если майнер возьмет 50 транзакций, то его PDiff=50*0.1/50=0.1 (или 10%)
Теперь смотри на обратную параболу. 10% соответствует вероятность 100%:
p(0.1)=100 - 4*(0.1*100-10)^2=100%
Значит этот блок выйдет через (BitcoinDiff*1.1 * 2**32 / hashrate) секунд.
Если майнер взял 60 транзакций, то Pdiff уже 60*0.1/50=0.12 (12%)
p(0.12)=100 - 4*(0.12*100-10)^2=84%
Значит, запускаем rand(0,100). Если 0 <= rand(0,100) <= 84, то блок выйдет через (BitcoinDiff*1.1 * 2**32 / hashrate) секунд. Если нет, то повторяем процедуру через 600 секунд.
Тогда если майнер возьмет 50 транзакций, то его PDiff=50*0.1/50=0.1 (или 10%)
Теперь смотри на обратную параболу. 10% соответствует вероятность 100%:
p(0.1)=100 - 4*(0.1*100-10)^2=100%
Значит этот блок выйдет через (BitcoinDiff*1.1 * 2**32 / hashrate) секунд.
Если майнер взял 60 транзакций, то Pdiff уже 60*0.1/50=0.12 (12%)
p(0.12)=100 - 4*(0.12*100-10)^2=84%
Значит, запускаем rand(0,100). Если 0 <= rand(0,100) <= 84, то блок выйдет через (BitcoinDiff*1.1 * 2**32 / hashrate) секунд. Если нет, то повторяем процедуру через 600 секунд.
Jump to: