Re: Scaling Bitcoin с субцепей
Я отправил это к списку Bitcoin-рассылки разработчиков несколько недель назад: http://sourceforge.net/p/bitcoin/mailman/message/34127318/. Пожалуйста, прочтите этот пост. Здесь я хочу прояснить некоторые вещи, и добавить еще несколько деталей.
Это похоже на идею дерево цепи Питер Тодд, но я думаю, что это решает некоторые проблемы, которые те были. Это вроде как боковые цепи, но цепи не являются независимыми. Вы можете позвонить и назвать его формой "blockchain расширения", То, что Адам Бэк (изобретатель HashCash) любит: http://sourceforge.net/p/bitcoin/mailman/message/34157058/. Так что я просто решил назвать его «подцепочки», чтобы отличить его от других подобных концепций.
Идея заключается в том, что вы добавляете десять blockchains, каждый с 1 МБ размера блока, которые проверяются в основной цепи (тот, который мы используем в настоящее время). Основная цепь может проверить их записи хэш каждого из заголовков блоков цепей внутри своего собственного заголовка блока; так что 10 цепи синхронизируется с основной цепью. Как вы знаете, из бумаги боковых цепей (https://www.blockstream.com/sidechains.pdf) Вы можете передавать Bitcoin между цепями, и это стало проще, так как цепи синхронизированы, и ребенок цепь всегда доверяет родительскую цепь.
Так что теперь у вас есть эквивалент 11 МБ блоков, но разложенные на 11 цепей. Преимущество заключается в том, что теперь вы можете выбрать то, что цепь для сохранения / Validate. Если у вас есть только одна цепь, то вам нужно хранить все блоки (так как долгосрочный период), чтобы увидеть и подтвердить все операции, которые имели место в этой цепочке. Ключевое слово «смотри». Узел SPV может проверить, произошла ли сделка или нет, но он не уверен, является ли он смотрит на все транзакции (некоторые из них могут быть скрыты полными узлами) и, как я объяснил в почтовой рассылке, сильно обрезают узел BAD прозрачности (сохраняя мощные объекты, такие как правительства и корпорации в проверке). Вы не можете просто хранить подмножество операций из цепочки, которые важны для вас, так как срок действия каждого нового блока зависит от срока действия предыдущих блоков.
Из-за отношения между цепями и размерами блоков, вам нужно хранить только две цепочки. Вы (и все остальные) хранит основную цепь. Но вам нужно хранить только один из 10 субцепей. Просто убедитесь, чтобы сохранить все ваши транзакции по той одной цепи, которые вы выбираете. Операции, которые включают два различных подцепочек будут записаны на каждой цепи (так что есть определенное дублирование) Таким образом, вы получите силу с 1 + 10 МБ / 2 = 6 Мб размер блока, а только хранения / проверки две цепи каждый с 1 Мбайт блоков , что эквивалентно в терминах хранения размер / вычислительной мощности вы хранения / проверки достоверности blockchain с 2 Мб размер блока. Если вы хотите, чтобы следить за сделки, которые находятся в другом субцепи (например, государственные закупки, вносимый вашего правительства МП), вы можете сохранить и подтвердить, что один тоже, так что вам нужно эквивалент 3 МБ на каждый блок в этом случае. Вы также можете иметь альтернативный идентификатор, который использует другой blockchain ... В общем, сумма, которую вы храните / Validate пропорционально количеству «материала» вы хотите отслеживать. При такой схеме разбиения у вас есть свобода для точной настройки, что вы храните / Validate, вместо того, чтобы быть вынужден следовать «один размер подходит всем» политику.
Вы можете продолжать идти, как это, добавив 10 ребенок цепи для каждого из 10 субцепей, в результате чего более 100 цепей (теперь мы имеем эквивалент 1 + 10/2 + 100/2 = 56 Мб размера блока с каждым участником, необходимым для единственный магазин / проверки 3 МБ. В течение 4 уровней, вы имеете эквивалент 1 + 10/2 + 100/2 + 1000/2 = 556 Мб размера блока с каждым участником только нуждающимся в 4 МБ. В общем случае, если вы имеете п уровней из blockchains, сеть имеет O (5 ^ (N-1)) сделок, в то время как каждый участник хранит только о (п) из них. другими словами, каждый участник хранит / проверяет ~ log (N) операций, где N есть число сделок в сети. Это гораздо лучше, чем ^ 2 требование ~ N на каждого участника, если каждая сделка просто происходит на одной цепи. Обратите внимание, что даже если вы хотите сохранить / проверки операций по цепочке, вы не должны полностью магазин / проверить родитель этой цепи. Вам просто нужны блочные заголовки родительских цепей для того, чтобы подтвердить каждый блок в цепи. Кроме того, шахтер на цепи ш плохо нужно только заголовки 10 дочерних цепей с целью подтверждения сделки, происходящую в дочерних цепях. Идея заключается в том, что более высокие оцененные операции будут выполняться на цепях, которые выше в иерархии, в то время как нижние значные операции на цепях, которые ниже в иерархии.
Другие вещи: Цепи, которые слишком пусты имеют стимул пополнятся сделками, так как операционные издержки ниже там. Для моментальных сделок, контрактов, мы можем использовать Lightning каналы, подключенные к какой-либо цепи, которые вы хотите. Защита будет повышена, так как это будет трудно один узлом для хранения всех операций, когда количество сделок очень большое.
Чтобы проиллюстрировать этот момент, я сделал диаграмму:
Первоначально я хотел нарисовать классическую древовидную структуру, но это было неудобно, чтобы соответствовать всем узлам, так что я решил пойти с круговой структурой. С помощью всего лишь один blockchain, мы придерживаемся всех сделок в центре черной точки (централизация). С более blockchains, мы можем распространять вещи, пусть каждый вклад, а на самом деле масштаб для более высокой скорости транзакций, чем это возможно с централизованной модели (не больше O (N ^ 2) или даже O (N)).
Еще одна вещь: В последнее время я думал о том, чтобы добавить гибкость размер блока, так что она имеет отношение даже с более вычислительной техники. Как вы знаете, шахтеры хэширования блок заголовков. Как насчет добавления мягкого вилки правила, что блоки должны быть 1 МБ с заголовком блока хэшированием или больше, если весь блок хешируются? Он не должен быть весь блок, он также может быть хэш операций внутри блока, или что-нибудь пропорционального размера блока. Таким образом, у нас есть надежные доказательства, из-компьютеров-это-теперь быстро достаточно, чтобы иметь-это-блок-размер. Например, в будущем, компьютеры (или СИС) могут быть настолько быстро, что 10 MB блоков могут быть хэшированными с той же скоростью, как заголовки хэшируются сегодня. Тогда мягкая вилка правило позволит 10 MB блоков. Это требует дополнительных исследований.
Майк Хирн, вероятно, сказать вам, что это хитрое Rube-Голдберг, но я считаю, что это элегантное решение, и, вероятно, самый простой, я могу думать. Это скорее обобщения Bitcoin, а не изменение Bitcoin, и требует только мягкую вилки. Это как в физике, где вы имеете специальную теорию относительности, а затем изменить масштаб изображения, и понимают, что это на самом деле является частным случаем общей теории относительности.
И да, у меня есть сильное академическое образование в областях, связанных с Bitcoin, поэтому я знаком с аргументами господствующих в этих областях. У меня также есть хороший практический опыт, связанные Bitcoin проектов. Но вполне возможно, что я сделал ошибку в моей логике где-то, так что было бы хорошо, если бы некоторые люди могли бы рассмотреть это. В частности, я был бы признателен, если бы я мог услышать комментарии от следующих людей: Gavin Andreson, Питер Тодд, Адам Назад, Питер Wuille, Эндрю Poelstra.
благодаря
Редактирование 19 июня: Как я уже говорил в списке рассылки, другая основная идея заключается в том, что адреса будут ограничены на пути субцепей. Адрес может быть представлен в виде числа, и, следовательно, вы можете выполнять модульное деление на него. (Позволять "%" имею в виду "модификация") Правило может быть, как это: Для любого адреса A, если А% 1 = 0, то переходит к верхней цепи C0 (так что каждый адрес); если А% 11 = 0, чтобы субцепи С00, если А еще 10% = 0, чтобы субцепи C01, в противном случае, если А% 9 = 0, чтобы субцепи C02, ...., иначе, если А% 2 = 0, чтобы субцепи C09; если A% 111 = 0, в субцепи C000, еще если A% 100 = 0, в субцепи C001, ... и т.д .. Примечание Cij является потомком Ci и Cijk является потомком Cij и Cijkl является ребенок Cijk и т.д ... и сделать это так, чтобы и рассмотреть satsfies мод т = 0, просто умножить адрес на т. Таким образом, вы можете быть уверены, что ваш кошелек следует только один путь цепей, которые вы отслеживать, и что вы, как вы можете отслеживать в базе данных UTXO, связанных с вашего кошелька (или государственного кошелька вашего представителя правительства) в O (журнал N ) способ без использования UTXO обязательств, которые я не думаю, что это так хорошо для целей децентрализации и затрудненного доказательства.
Кроме того, я забираю схему слияния по добыче, я думаю, что это должно быть сделано без добычи объединения вообще. Родительские цепи вместо этого взимать плату от дочерних цепей поставить хеши дочерних цепей в качестве специальных операций в родительском цепных блоках. Эти сборы будут в форме UTXOs, которые являются действительными только в дочерних цепях (не родительские цепей). Это даст стимул для родительской цепи, чтобы быть осторожным с тем, что ребенок блок заголовков он обязан (таким образом проверить дочерние цепи).
Редактирование 24 июня: Забыл добавить, что в большинстве 2 одноуровневых цепь может быть использована в сделке, так что дублирование операций ограниченно. Вы всегда можете создать более сложную операцию путем объединения нескольких операций, которые включают в большинстве 2 цепей.
Кроме того, чтобы ограничить "глубоко" вилки, мы должны создать правило, которое когда-то выход переходит от ребенка цепи к его родителю (или дедушка) цепи, любое позднее обнаружение ошибки в значении выходного в дочерней цепи не может изменить свое значение, так это ограничивает эффект, ошибки в проверке глубоких дочерних цепей имеют на родительских цепях.
