denizzzka / dianna2

DIANNA - IANA Decentralized
MIT License
3 stars 0 forks source link

Difficulty depending on domain length #3

Open mr-tron opened 9 years ago

mr-tron commented 9 years ago

May be something like current_base_difficulty/(ln(domain_length)+0.01)

mr-tron commented 9 years ago

Dianna это хранилище ключ-значение. где ключ - домен, а значение - адов джейсон(условно) с кучей записей. + немного метапараметров типа хэшей, ключей, таймстэмпов и подписей. так вот чем короче ключ - тем больше сложность на создание [пустой] записи. потом значение можно изменять (например добавлять сервисы), удостоверяя приватным ключом, что ты владелец. и тут чем больше записываемое значение, чем выше сложность. при чём длина ключа здесь уже не влияет на сложность - только длина значения

denizzzka commented 9 years ago

Dianna это хранилище ключ-значение.

Кстати, нет - уже исправил это в ридми.

Ключ-значение, подписанные записи - это всё варианты использования общедоступного децентрализованного хранилища, из которого нельзя стереть что-либо. Но на ДНС ориентируемся как на первоочередную задачу, ради которой всё затевалось.

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

Потому что ты ведь хочешь привязать сложность к размеру ради экономии дискового пространства и трафика участников сети, так?

mr-tron commented 9 years ago

Ну тогда можно сделать просто настраиваемый параметр "формула для расчёта необходимого proof-of-woork". Тоесть например делаешь сеть для dns - учитываешь одни параметры, для распределения частот - другие параметры.

denizzzka commented 9 years ago

Тоесть например делаешь сеть для dns - учитываешь одни параметры, для распределения частот - другие параметры.

с какой целью?

и какая формула расчёта для ДНС предлагается?

mr-tron commented 9 years ago

для более "справедливого" распределения доменов (справедливость это очень важное психологическое явление. люди хотят справедливости) усложнения жизни сквотерам, без вреда для массовых пользователей и даже напользу им. При распределении msisdn между абонентам могут быть важнее другие значения - например кол-во msisdn уже привязанных к идентификатору или частота смены.

Формулы две: одна для создания новой записи - базовая_сложность_расчитанная_на_основании_нынешней_мощности_сети* (общая длина записи - служебная информация - длина домена) / ln(длина домена в символах+0.01) возможно вместо e для основания логарифма взять что-нить поменьше. или, как вариант, взять корень от длины. короче суть вроде понятная - сложность расчитанная на основании мощности системы, деленная на функцию, быстро возрастающая в начале и медленно потом от длины домена. формула вторая только для переопределения записи существующей в хранилище. - базовая_сложность_расчитанная_на_основании_нынешней_мощности_сети* (общая длина записи - служебная информация - длина домена) / ln(64) тоесть переопределить одинаково легко как самоую короткую запись так и самую длинную. может стоит внести понижающий коэфициент, чтоб каждый раз как захочешь поменять куда указывает запись не пришлось считать так же много как при создании записи.

denizzzka commented 9 years ago

для более "справедливого" распределения доменов (справедливость это очень важное психологическое явление. люди хотят справедливости)

не вижу в чём несправедливость решения "одинаковая сложность для любой длины домена для всех, зависящая только от наличия всплесков (см. ридми)"

mr-tron commented 9 years ago

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

denizzzka commented 9 years ago

Ну а я вижу, но спор на морально этические нормы - это бесперспективное занятие.

нету тут этого, на мой взгляд