Topic: DIANNA: IANA Decentralized концепт дизайн (Read 31411 times)

Лично я в IRC не разбираюсь да и не люблю его
ты можешь поднять рядом с вики проекта какой-нибудь простенький форум
по-моему это будет удобней, нет ?

Я надеюсь что когда будет прототип системы
появиться много сильно умных желающих "атаковать" диану
на бумаге -- тогда станет ясно -- есть ли у нее слабые места

@rPman
смотрите пост № 417
речь шла о том что средний комп не способен сейчас одновременно работать со многими
неймспейсами -- значит можно создавая "мусорные" спейсы вредить системе

но вред тут ограниченный как я теперь понимаю

@pent
атака "1002 неймспейса" на самом деле не опасна
в реале будет всего спейсов макс. 100 -- считая с клонами

просто 4 миллиарда неймспейсов существуют только в теории
а на практике их сейчас сделать нельзя

Это весьма интересная идея, только реализовать ее трудно.

@pent
Возможно я в чем-то не прав  
Главное чтобы формулы (будь это PDiff или что другое) обеспечивали
БЕЗУБЫТОЧНОСТЬ работы майнеров при любых раскладах
может какая-то атака и возможна -- просто пока не ясно какая  
меня больше интересуют возможные атаки на уничтожение/дискредитацию сети
чтобы их не было или они были экономически очень дороги

Есть специальный софт для симуляций
http://en.wikipedia.org/wiki/List_of_computer_simulation_software
Есть еще других до черта -- но мне кажется это не будет проще
чем написать на обычном языке -- во всех этих системах все не просто
Вот и атака : плохиши открывают 1002 неймспейса и слегка заполняют их
своими доменами => система в шоке 

Посчитаем систему по-другому :
 
Пусть себестоимость обслуживания домена = 0.2 BTC ( вероятно меньше
-- позже будет ясно сколько )
Это минимальная цена которую формулы должны держать
максимальная цена НЕ ограничена формулами а только спросом-предложением

пусть число транз/блок мин = 1 и макс = 6000
это тоже жесткие ограничения

пусть максим частота блоков в сети дианы ~ равна частоте блоков в сети биткойн
а миним. частота у дианы -- 1 блок за 12 часов
и это тоже жестко выдерживается формулами ( есессно при наличии
новых транзакций в сети )

Если соотн. новых регов к апдейтам старых доменов принять 50/50
то при максимальной нагрузке в сети ( стабильно высокий спрос )
число доменов в ICANN может быть достигнуто за 2-3 года  
-----------------------------------------------------------------------
Я пока вижу в такой сети только атаку путем скупки всех доменов на корню
это конечно плохо , но имеет побочный эффект --
атакующим придется закачать в биткойн прорву денег  
при цене домена в 0.2 -- стоимость атаки в год превосходит
ВСЕ уже намайненные BTC  
Что экономически невозможно для атакующего  

здесь есть только один вопрос -- какова будет себестоимость обслуживания домена за время TTL ?

UPD : остается не решенным еще вопрос вероятного будущего роста
 курса BTC к фиату, но это отдельная проблема
ее можно выставить на мозговой штурм в обе треды (rus & engish) -- это ведь
экономика и желающих пообсуждать найдется много

Самое простое что мне приходит в голову :

1) написать упрощенный эмулятор биткойна в отдельном файле
2) вывести все формулы для дианы
3) четко определить допустимые пределы всех параметров дианы
4) написать в ДРУГОМ файле эмулятор дианы согласно 2) и 3)
5) гонять оба эмулятора как два отдельных процесса
    общими данными они будут обмениваться через файл или разделяемую память
 или message passing или как удобно будет
------------------------------------------------------
Это решит проблемы с синхронизацией 2-х цепочек с разной скоростью
 и даже будет круче прогона на реальном биткойне -- быстрее и все параметры
биткойна можно менять

Велосипед симуляции уже изобретали до нас много раз  
http://en.wikipedia.org/wiki/Model_checking
поброди там может чего полезного  найдешь
как это делать правильно

UPD : Вывод:  эмулировать надо ПОЛНУЮ систему со всеми возможными
обратными связями и выраженными в формулах соотношениями

Надумал 2 вещи.

1) Эмулятор у нас не полный -- не все обратные связи реализованы
значит и стабилизировать его правильно в таком виде невозможно

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

Если буфера в настоящей реализации не будет, то и здесь он не нужен
но какой-то объект содержащей текущие транзакции может в эмуляторе и нужен

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

или альтернативно можно завязать с эмуляцией -- написать протоклиент
и договориться о тестировании его на живом биткойне

А биржа - зло, особенно краткосрочная торговля, я когда-то оставил там скромное состояние
с тех пор спекулирую только долгосрочно 

По-моему  лучше сначала встроить туда автоматическое изменение баунти
как оно должно идти 50 25 12.5 и т.д.
адаптировать формулы чтобы система справлялась с изменением баунти достойно
а потом уже добавлять устойчивость ко всяким тяжелым ситуациям
так оно будет проще и быстрей

эмуляция не совершенна 

я попробовал ограничивать koef после его вычисления : 0.6 <= koef<=0.97

1 ) в некоторых экстримальных случаях расчет нереален
напр. выдает плоскую цену = 0.3

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

3) ценовой уровень на котором стабилизируется система зависит
сильно зависит от нач. цены -- что тоже не очень хорошо

А есть ли вообще способ удерживать в рамках одновременно и цену и частоту блоков ?
По-моему это сильно сложно будет
---------------------------------------------------------------------------------
Попробуй усредниться как-то : Fprev/function(Fpprev, Fbitcoin),
где function(Fpprev, Fbitcoin) <-- некая функция балансирующая влияние скорости обоих цепочек

-----------------------------------------------------------
Еще у нас идет расчет типа для сети набирающей популярность

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

Это естественно что шатает -- но это редкое событие раз в 210000 блоков
Но да можно формулы подкрутить чтобы переход был плавнее
-----------------------------------------------------------------------------------------
Есть дурацкая идея : если считать PDiff НЕ опираясь на величину bounty
то никакого фазового перехода не будет

Просьба ногами не бить 

Я и не цепляюсь к точной стартовой цене -- так погонял  из интереса
чтоб знать что к чему -- можно например сделать изменение баунти по биткойновым
блокам -- уполовиневание каждые 210000 блоков как и должно быть

тут важны два момента :

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

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

 а так ему все равно -- домен то на год -- день ожидания здесь ничто

формула спроса здесь просто демонстрирует что система довольно успешно справляется
( не падает , хоть и замедляется)
с ПОСТОЯННЫМ и значительным ростом числа доменов в обороте -- и больше ничего
настоящий спрос надо моделировать как-то по-другому , еще и учитывая
влияние на курс BTC/$ -- настоящий спрос будет переменным
макс. число одновременных доменов не превысит 100  миллионов.

но пока в целом результаты тестов очень хорошие ИМХО

просто у меня было сразу поставлено 25.0 
это ж уже скоро 

last = 900000  start_price =0.05  0<=bitcoms<=25.0
выдает :

Погонял еще немного -- результаты такие :

при баунти == 25 лучше начинать с цены домена в 0.1
тогда цена домена не падает ниже начальной

функцию спроса вида 1.0001**(step/5000) не выдерживает

что ты имеешь ввиду говоря "ожидание блока на час поменять"
Cделать так ?
или что-то другое ?

Можно и так -- тебе видней

А DHT какую возмешь ?

cjd использовал у себя Kademlia -- только он наверно все там поменял 
на Яве есть несколько реализаций Kademlia (>5)

Или будешь свою собств. делать