Open mr-tron opened 9 years ago
Dianna это хранилище ключ-значение. где ключ - домен, а значение - адов джейсон(условно) с кучей записей. + немного метапараметров типа хэшей, ключей, таймстэмпов и подписей. так вот чем короче ключ - тем больше сложность на создание [пустой] записи. потом значение можно изменять (например добавлять сервисы), удостоверяя приватным ключом, что ты владелец. и тут чем больше записываемое значение, чем выше сложность. при чём длина ключа здесь уже не влияет на сложность - только длина значения
Dianna это хранилище ключ-значение.
Кстати, нет - уже исправил это в ридми.
Ключ-значение, подписанные записи - это всё варианты использования общедоступного децентрализованного хранилища, из которого нельзя стереть что-либо. Но на ДНС ориентируемся как на первоочередную задачу, ради которой всё затевалось.
И поэтому я предлагаю ориентироваться просто на общий размер записи, не вникая в то, что там в ней внутри.
Потому что ты ведь хочешь привязать сложность к размеру ради экономии дискового пространства и трафика участников сети, так?
Ну тогда можно сделать просто настраиваемый параметр "формула для расчёта необходимого proof-of-woork". Тоесть например делаешь сеть для dns - учитываешь одни параметры, для распределения частот - другие параметры.
Тоесть например делаешь сеть для dns - учитываешь одни параметры, для распределения частот - другие параметры.
с какой целью?
и какая формула расчёта для ДНС предлагается?
для более "справедливого" распределения доменов (справедливость это очень важное психологическое явление. люди хотят справедливости) усложнения жизни сквотерам, без вреда для массовых пользователей и даже напользу им. При распределении msisdn между абонентам могут быть важнее другие значения - например кол-во msisdn уже привязанных к идентификатору или частота смены.
Формулы две: одна для создания новой записи - базовая_сложность_расчитанная_на_основании_нынешней_мощности_сети* (общая длина записи - служебная информация - длина домена) / ln(длина домена в символах+0.01) возможно вместо e для основания логарифма взять что-нить поменьше. или, как вариант, взять корень от длины. короче суть вроде понятная - сложность расчитанная на основании мощности системы, деленная на функцию, быстро возрастающая в начале и медленно потом от длины домена. формула вторая только для переопределения записи существующей в хранилище. - базовая_сложность_расчитанная_на_основании_нынешней_мощности_сети* (общая длина записи - служебная информация - длина домена) / ln(64) тоесть переопределить одинаково легко как самоую короткую запись так и самую длинную. может стоит внести понижающий коэфициент, чтоб каждый раз как захочешь поменять куда указывает запись не пришлось считать так же много как при создании записи.
для более "справедливого" распределения доменов (справедливость это очень важное психологическое явление. люди хотят справедливости)
не вижу в чём несправедливость решения "одинаковая сложность для любой длины домена для всех, зависящая только от наличия всплесков (см. ридми)"
Ну а я вижу, но спор на морально этические нормы - это бесперспективное занятие. Короче я бы заложил возможность настраивать необходимую сложность для разных транзакций, а там как пойдёт.
Ну а я вижу, но спор на морально этические нормы - это бесперспективное занятие.
нету тут этого, на мой взгляд
May be something like
current_base_difficulty/(ln(domain_length)+0.01)