-----НАЧАТЬ PGP MESSAGE ----- ПОДПИСАЛИ
Hash: SHA256
Blockchain система на основе жесткой вилки голосования без порогов
Управляемый жесткие вилы событие требует синхронного сотрудничества между различными участниками (основными разработчиками, разработчиками бумажника, биржами, шахтерами). Это требует человеческого внимания и люди, как известно, ограничены их концентрации внимания. Слишком много возможностей (часто подобных) приводит к отвлечению и бесконечным дискуссиям.
Заданными удались жестко вилки также требует определенного порога, который инициирует жесткие вилки развертывания (например, 75% от мощности хэширования должно сигнализировать соглашение с предлагаемой жесткой вилкой). Этот порог является проблематичным, поскольку там должен быть * кто-то * кто устанавливает его в камне. Этот пороговый уровень ажурных воздействий на результате, и это приводит к политике.
Позвольте мне предложить blockchain на основе жесткой вилки голосования и планирование системы без жестких вилков порогов. Во-первых, я собираюсь описать суть его в менее техническом плане. В следующих разделах будут включать возможные подробности технической реализации и краткое обсуждение.
- ---
Каждые 6 месяцев Bitcoin сеть выполняет управляемую жесткую вилку. Это делит график на равные 6 месяцев, где каждый период имеет две фазы:
1. Первые 5 месяцев является фаза голосования
2. последнего 1 месяц фаза сигнализации / фаза предложения
На этапе предложения, каждый может представить специально сконструированную сделку, которая предлагает libconsensus ревизию. Сделка будет содержать только идентификацию (а ревизию свидетеля). Все подробности будут публично опубликованы за пределами сети. Давайте назовем данную транзакцию «предложение».
На этапе голосования, каждый может представить специально сконструированные сделки (например, проводя биткойны себе или как часть их нормальных расходов) упоминая предложение. Это будет отбрасывать взвешенное голосование по указанному предложению (Bitcoin дней уничтоженного).
В конце периода голосования. Победившая предложение (общее количество дней Bitcoin разрушен) пропагандируется как нового кандидата libconsensus. В прошлом месяце это время для шахтеров, чтобы сигнализировать о своих намерениях на вилке точки. Шахтеры выразить (Y), чтобы сигнал поддержки коммутатора к кандидату, (N), чтобы сигнал поддержки, чтобы остаться на текущем libconsensus. Или они ничего не делают (0), чтобы сигнализировать нейтральное мнение (или они просто не волнует).
В конце периода сигнализации. Жестко вилка бывает так или иначе. Пожалуйста, обратите внимание, что технически libconsesus то же самое в N, как старый libconsensus, но их версии будут отличаться. Таким образом, с точки системы N является жестко развилка текущего состояния.
Сигнальный периода время также используется для сбора новых предложений последующего периода. Участники должны представить предложения (необязательно анонимно, не раскрывая вне цепи содержания до тех пор, пока предложение получает добытое или начинает голосование).
- ---
Все голосования / сигнальная информация должна быть передана через blockchain. Любой имеющий копию blockchain должен быть в состоянии восстановить и оценить "вся картина" (Для ревизий, которая не является актуальной для наблюдения системы за исключение).
Мы должны определить сроки периода / фазы с точкой зрения блока подсчета:
1. голосования фаза: VP = 5 * 30 * 24 * 6 блоков
Фаза 2. сигнализации: SP = 1 * 30 * 24 * 6 блоков
Это потребует первоначальный "самонастройки" трудно вилкой, чтобы определить начальный блок в течение первого периода. Это трудно вилка также добавляет новый "супер-консенсус" правило: "должны перейти на новую версию libconsensus с каждым новым периодом",
Транзакция предложение может использовать OP_RETURN. Например. объединить предложение габаритного (38b), предложение типа (2b) и предложение содержания свидетеля (40b). Изначально мы могли бы поддержать GIT на основе предложение типа, где свидетель определяется как SHA предлагаемого libconsensus наконечника ветви. Система будет открыта для будущих предложения-типов, определив новое предложение типа.
Сделка голосования может использовать OP_RETURN упомянуть идентификатор транзакции конкретной сделки заявки.
Сигнализация может использовать существующий механизм версию бит. Для этого потребуется 2 бита для кодирования три случая (Y, N, 0).
В точке жесткой вилки. Шахтеры следуя "супер-консенсус" Правило будет либо перейти на Y или N. Там не разрешено остаться на старом libconsensus. Y определяются как кандидат libconsensus от победы предложения. N строится как текущий libconsensus с задеть номером версии. В теоретическом вырожденном случае, когда не было никаких предложений. Y определяется как N.
- ---
Я считаю, что эта система будет иметь благотворное влияние сообщества. Управляемые жесткие вилки не может происходить чаще, чем через каждые X месяцев, и они происходят в хорошо определенный график. Mainstream обсуждение, скорее всего, вращается вокруг нескольких главных предложений выигрышных поддержанных с сильным сигналом их поддержки. Голосование осуществляется экономическое сообщество людей и машин, которые на самом деле использовать Bitcoin (они либо Transact или удерживать значительные суммы). Голосование может быть анонимным, полностью раскрывается общественности и доказуемо через blockchain. Право голос является ограниченным ресурсом, а также время (там корректно определена запирающей дата для каждого периода голосования). Это не изменит фундаментальное правило в Bitcoin, что большинство хэширования власти устанавливает консенсус. Но сообщество раскрученной кандидат предложение заставит шахтер сообщество четко ответить. Y / N / 0 голосования четко отделяет "Определенно да", "Определенно нет" а также "в различных" рудничные лагеря. В точке жесткой вилки, 0-лагерь, вероятно, прыгать на стороне с более сильной сигнализацией (потому что в соответствии с правилом суперов-консенсусными они должны изменить libconsensus в любом случае), вскоре после того, что проигравшая сторона присоединится к сильной стороне. Конечно, шахтеры могут в конечном счете, ведут себя иначе, чем сигнал, но в этом случае они повреждают их общественную репутацию. Кроме того, они могут внезапно удалить правило супер-консенсус и остаться на старом libconsensus без жесткого разветвления. Это будет фактически означать отказ от этой системы голосования и отмены "самонастройки" трудно вилка. Это игра-теория вопрос, который я надеюсь, что кто-то более способный сможет моделировать более формально. Главный вопрос, чтобы ответить, если небольшая группа шахтеров еще может эффективно подавлять любой процесс принятия решения в рамках такой системы, как это.
Кроме того, я считаю, что обязательное разветвление (даже тем же правил консенсус только с врезался номером версии) будет иметь положительное воздействие (как выполнение огня дрели). Все участники смогут узнать, как бороться с ним в упорядоченным образом. Кроме того, эта система не препятствует незапланированные (аварийные) жесткие вилки, если это необходимо (сегодняшняя модель).
Эта система также может устранить необходимость для установки произвольного порога для жестких вилков запуска. Но это вводит произвольные постоянные временные (VP, ИП). Я считаю, что эти временные константы менее склонны к политике, потому что они должны быть смоделированы способностью внимания естественного человека / сообщества / разработчика. Кроме того, они будут установлены один раз в самонастройках жесткой вилке, а затем должны быть изменены только с помощью самого механизма голосования.
-----НАЧАТЬ PGP SIGNATURE -----
wsFcBAEBCAAQBQJW3H0QCRAyqJqp3djIfwAAGggQABVgB0YNWVBVlhgt3QQQklDb
д / l2kJ1kz0tSaGPPdvmL0XDEP1GuBTBep26Fj2123uyjCnOALgMWzLN + rBJ8NyRP
IshhVMNql67LmvQ8RqPWhJ4bolY4Zja9L932mpDhIaJSr + 9DSS5YrM86B33g23HH
sPmcILyb3hEqTtmctgg1Gc5tE1CtyDyxkYEnYABLZ7BP2eFFEFVOsCFPCNROqvV5
Q + ATuMnLDLy8Zqzsqj01VBaJOPRSktfkP8VN4tGpiuS / NF7U / gUkvNDvjIlr3vWg
GqNagi86icyXHQRL1cVYfwrPZwPDDxQxVMCDyG2lpE6AJoYuQq0DAEHVoQEfMPkS
lCizMMnoBkXXG4uZdjy1kosjg2DEtML / DI9IHnCMLffcxK9IS8B + K08h1BVZqWnW
/ QMoYJu1P0IXO3HktLiDuxPqH8fkh39wx + XrnjRzleYBLxoqCiJkEsCKcS9rQeJa
B5qdpWXYEFgE8aSSHlwkHwUhNI20cAuxPddNX6yeOiQe7xYreUq43FGopFiPePmc
0Hg0fmiNMRHV4u2u1PD1g + k5hD / MmHDukpH9aZUG45Fu6Pguxv + okXlhwt2cgURO
PLpxtBgt829AOfKF4Iuj5bcaePBRv4HEsqaIiN7JXHfi9Iq0ZZArf8F7jGAYc9rE
aXm96IPwihq0SSZb7M7J
= + W90
-----END PGP SIGNATURE -----