-
Notifications
You must be signed in to change notification settings - Fork 0
Rationales
Questions and conserns
Основополагающее
- сейчас основная проблема криптовалют замешанных на сложности вычислений - экспоненциальный рост вычмощностей майнеров. При этом у биткоина основные игроки - это пулы пользователей, то есть в основе все также люди на компах считают распаралелено хэши. Биткоин явно не расчитывал на рост сложности (сейчас nonce даже не дает достаточного разнообразия для подбора).
- Для стабильного блокчейна нужен "давящий" фактор. Сложность расчетов отпадает, остается время+объем средств под контролем пользователя
- "давящий" фактор: есть аналогичные попытки решить вопрос через proof-of-stake. Попытки пока не очень успешны - встает проблема равномерного распределения гигантских сумм, которые просто никому не нужны в таких количествах, плюс proof-of-stake убивают эмиссию как класс
- цель блокчейна - стабильно разносить транзакции между клиентами. причем приоритетно - "дорогие", "толстые" или "широкие" (много wId)
- считаем что любой майнер может подобрать любую комбинацию (кроме взлома хэшей). Это не так уж умозрительно - пока kri в зачаточном состоянии (мало майнеров) - любой ASIC будет супер-королем вычислений
- запретить перебор майнерам невозможно, поэтому нужно чтобы он "стоил денег".
- транзакции привязываются к руту клиентом. таким образом аттакер не сможет использовать чужие транзакции чтобы обогнать блокчейн, ему будет необходимо вести свой пул непустых wId (рост линейно от числа блоков, которые нужно "подменить")
- строгая сортировка по kriTotal + возможности по gc + способ сравнения blockProposals гарантируют, что в блоках будут чаще дорогие транзакции неподконтрольные аттакеру.
- таким образом аттакер для полного успеха должен владеть (по разным кошелькам) суммами не меньшими чем kriTotals всех транзакций в блоке. с учетом регулярных gc - это будут не 0-и. аттакер должен быть "богаче" всех остальных пользователей
- используя при сравнении блоков меру разнообразия, стоимость владения для проведения успешных атак можно "умножать". то есть для атаки на блокчейн длиной в 1 час нужно в 5 раз больше контролируемых средств, чем для атаки на одиночный блок
- немного похоже на proof-of-stake. только без лимита на эмиссию и с бОльшими трудностями для аттакера
Генераторы для timeHash - Tech: TimeHash
Стимулы держать ноду
-
Генерация блоков - допзаработок на комиссиях. Не требует вычислительных ресурсов
-
Активная нода может "перерассылать" свои транзакции, если никто не включил их в блок. с опциональным ростом комиссии
Почему равномерная эмиссия+сбор комиссии
-
Майнинг (причем СПРАВЕДЛИВЫЙ майнинг) - основной драйвер интереса для мелких пользователей. привязка к timeHash-у дает гарантии равномерной эмиссии и равномерного распределения miningLoot, даже когда майнер "не в сети"
-
Зависимость от одних лишь комиссий рано или поздно заставит майнеров изобретать способы по "искривлению" блокчейна в свою пользу, замедляя его работу (даже без miner51 - проблемы)
-
кроме эмиссии, сумма комиссии уходит blockSpawner-у, так что несмотря на равномерное распределение, у майнеров есть стимул включать как можно больше "выгодных" транзакций в блок и участвовать в блокостроении
-
гарантия равномерности эмиссии следует из привязки 1 блок = 1 timeHash + лимит эмиссии на блок.
-
равномерность финансово - то же самое что и ограниченность эмиссии, главное что к этому можно подстроиться. кстати ethereum тоже построен на бесконечной эмиссии: https://forum.ethereum.org/discussion/1321/why-infinite-number-of-ethers
Почему один блок на timeHash
- больше одного блока на timeHash продумывать смысла нет, так как любому полному клиенту все равно придется качать ВСЕ последние блоки (либо хэши транзакций) для нормальной работы. Т.е. деление транзакций на блоки не несет дополнительной эффективности, а для безопасности не принципиально
Защита от спама блокчейна, пересчетов, предсказуемость в динамике
-
Нет транзакций с 0-ой суммой, нельзя потратить меньше 1 kc, Оплата "лишнего веса" транзакции
-
Лимит на число транзакций в блоке -> предсказуемость роста блокчейна, необходимого канала/ресурсов по обработке и тп
-
Дефолтное поведение клиентов (gc) работает на устойчивость блокчейна - перемешивание "больших" транзакций в каждом блоке
Деанонимизация майнеров (не всех клиентов, а только майнеров) при использовании factChecking
-
Список сайтов будет ограничен (clientWhitelistedSites). Сама штука нужна чтобы иметь возможность "аппрувить" транзакции через реальный мир.
-
Создатель factCheck-запроса сам выбирает степень проверки числом подписей майнеров (не меньше 3х)
"Вирусные" транзакции, которые могут блочиться на уровне сети (маркеры вирусов и тп)
-
решается хранением всех user-defined значений (скрипты, блобы, и тп) в b64
-
все Javascript-ы должны проходить нормализацию
Скалабилити, почему фиксировано количество транзакций в блоке
-
Лучше иметь понятные ограничения, чем полагаться на рост возможностей участников сети. Самое узкое место сейчас - это bandwidth, клиенты (особенно слабые) не могут прокачивать мегабайты в реальном времени. Фиксированное количество транзакций дает гарантии ограничения канала "сверху" и скорости прироста блокчейна
-
фиксированное количество транзакций используется в обосновании концепции безопасности блокчейна
-
При увеличении числа транзакций выше предела будет предложен scaling путем введения "параллельных", сильно независимых блокчейнов (с непересекающимся набором транзакций и таким же лимитом), паралельность можно расширять и дальше, увеличивая пропускную способность и сохраняя контроль над каналами для "слабых" клиентов. Естественно будет возможность обмена между паралельными блокчейнами
-
виза дает 2000 transactions per second (https://en.bitcoin.it/wiki/Scalability) -> 600000 per 5 min. На такой объем можно выйти путем увеличения лимита на число транзакций в блоке (с введением градации на операции разного сорта под разные каналы) и ведением паралельных блокчейнов (сотни)