Blockchain алгоритм: что такое технология Blockchain простыми словами в 2020

Содержание

Как запустить свой блокчейн: выбираем алгоритм консенсуса


Перед разработкой собственного блокчейна ваша команда должна четко понимать, для чего необходим блокчейн и какой бюджет вы сможете выделить на его содержание.

Проектирование и запуск блокчейна имеют свои нюансы. Их можно легко упустить при планировании, если вы неверно оценили объем и сложность задачи.

Чтобы помочь проектам избежать таких ошибок, руководитель отдела исследований MixBytes Сергей Прилуцкий подготовил пошаговое руководство по запуску блокчейна.

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

***

Я буду исходить из того, что блокчейн предназначен для достаточно сложных сделок. Все рассматриваемые решения подходят для работы с кодом, размещенным в блокчейне.

Я намеренно не включил в перечень решения, которые находятся на ранних этапах развития, неизвестны широкому кругу программистов или не имеют важных механизмов, обеспечивающих безопасную работу блокчейна: неустойчивы к византийскому поведению нод (non-BFT) или могут быть успешно атакованы с единственного аккаунта. Без этих свойств блокчейн не имеет ценности и превращается в медленную, дорогую и неудобную в использовании базу данных.

Чтобы определиться, строить ли новую систему или использовать готовое решение, в первую очередь необходимо определиться с консенсусом — главным алгоритмом, обеспечивающим блокчейну BFT-свойства.

Консесусы: proof-of-work, proof-of-stake, proof-of-authority

Для начала рассмотрим разные типы консенсуса с точки зрения запуска и эксплуатации сети. Любой BFT-консенсус в блокчейнах должен удовлетворять как минимум два важных свойства распределенных систем: safety и liveness.

Safety гарантирует, что алгоритм никогда не придет к неверному консенсусу, если большинство узлов честно следуют протоколу, а liveness — что алгоритм никогда не «застрянет», не имея возможности выбора пути.

Эти свойства должны гарантированно выполняться при наличии в сети byzantine-участников, намеренно действующих наихудшим образом.

Proof-of-work (PoW)

Преимущество этого типа консенсуса — отсутствие необходимости регистрировать в сети валидаторов. Принимается любой блок, удовлетворяющий требования, без подтверждения других участников. Это позволяет оставить лишь часть логики, отвечающую за изменение сложности майнинга.

В теории этот вид консенсуса допускает любое число валидаторов — ведь соревноваться за блок может сколько угодно валидаторов. В реальных сетях, если валидаторов (майнеров) много, а сложность сети высока, то шансов получить награду за блок у отдельного майнера крайне мало. Для такого консенсуса необходимо сразу планировать работу майнинговых пулов, объединяющих майнинговые мощности, и соответствующее ПО.

При старте сети валидаторы должны сразу же установить серьезные вычислительные мощности. Это часто упускают из вида, надеясь на постепенное увеличение сложности сети и количества майнеров. Невысокий хешрейт открывает двери для недорогих атак 51%, когда атакующий на очень короткое время арендует много серверов, чтобы получить 51% хешрейта сети, и проводит атаку двойной траты.

Поэтому для PoW-сети придется планировать более сложную процедуру запуска. Сначала команда запускает сеть с собственными валидаторами, а потом постепенно «уступает» производство блоков майнерам, которые в этом случае могут плавно наращивать мощности.

Proof-of-authority (PoA)

PoA-консенсусы — это алгоритмы, использующие заранее назначенный набор аккаунтов, которые могут производить блоки и голосовать за принятие и исключение новых членов. Этот вид консенсуса — естественный выбор для корпоративных блокчейнов и тестовых сетей. Здесь может вообще не быть внутреннего токена, а при голосованиях за блоки и при выборах валидаторов 1 валидатор = 1 голос.

Это семейство алгоритмов представлено фундаментальным алгоритмом pBFT. В измененном виде он является базой для большого числа консенсусов, позволяя договориться о любых данных со всеми гарантиями безопасности.

В предыдущей статье я уже говорил о том, что не существует гарантированно безопасных консенсусов, в которых требуется менее, чем 2/3 + 1 сообщений от валидаторов. pBFT это доказывает математически. В разных консенсусах эти сообщения, подтверждающие, что валидатор принимает блок, собираются в разные моменты времени.

Процесс сбора подтверждений и в дальнейшем признание блока окончательным получил отдельное название финализации. Блоки, на которых достигнут общий консенсус называются финальными. Для уменьшения числа сообщений в части алгоритмов финальность достигается не на всех блоках, а только на некоторых, «заверяющих» сразу несколько блоков. Таким образом сильно уменьшается число сообщений между валидаторами и существенно ускоряется консенсус.

Из-за разделения процедур валидации блоков и финализации присутствует некоторая путаница, из-за которой оценивать скорость консенсуса становится непросто.

Например, алгоритм pBFT, используемый в консенсусе Tendermint (Cosmos), требует консенсуса на каждый блок, т.е. мгновенно финализирует его, а алгоритм EOS финализирует лишь один из множества блоков, финализируя сразу цепочку.

Aura — популярный алгоритм для POA-сетей на базе Ethereum — использует псевдослучайный выбор валидатора для каждого блока и параллельно договаривается о финализированных блоках с использованием алгоритма GRANDPA, ожидая > 2/3 подписей-подтверждений от других валидаторов. Такой параллельно работающий алгоритм финализации получил название finality gadget.

Похожим образом работает консенсус EOS, создающий «расписание» для валидаторов на некоторый период времени (epoch) и требуя финализации блоков в конце каждой epoch.

Proof-of-stake (PoS)

Почти все существующие реализации этих алгоритмов включают в себя алгоритмы из POA-консенсусов, что добавляет путаницы. Современные PoS-алгоритмы работают следующим образом: при помощи балансов участвующих в выборах валидаторов (стейков) формируется список валидаторов (например, голосованиями, заморозкой депозитов и т.д.). В течение некоторого времени, до момента изменения списка валидаторов, сеть работает, используя PoA-алгоритм, например pBFT.

Наиболее распространенными стали алгоритмы, названные Delegated Proof-of-Stake (DPoS), где аккаунты в сети различными способами голосуют своими балансами за валидаторов, формируя топ из N валидаторов.

Выбирая консенсус для своего блокчейна, стоит в первую очередь рассмотреть процесс финализации блоков. От нее будет зависеть время, через которое клиент получит подтверждение своих транзакций. Токеномику, процедуру «выборов» валидаторов и получение наград за блоки лучше рассматривать отдельно. В этой части может быть применено большое число разных экономических механизмов.

Отмечу, что корпоративным сетям не стоит пренебрегать экономическими механизмами и PoS-алгоритмами, даже если в сети нет никакой экономики и токена. Любые бесплатные транзакции — это почти всегда вектор атаки на систему с единственного аккаунта. Наличие баланса «технического» токена на аккаунте может служить удобным ограничителем, когда у атакующего просто не хватит средств на полномасштабную атаку, а также позволит более гибко регулировать доступ и нагрузку на сеть.

Варианты имплементации

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

Блокчейн — это мир открытого ПО. Закрытый код в нем практически невозможен — криптографические протоколы давно создаются на открытых международных конкурсах, а реализациям с закрытым кодом мало кто доверяет из-за больших рисков.

Используйте то, что создали программисты до вас. Крайне велика вероятность, что ваши задачи уже решали, обсуждали и проверяли, поэтому не стоит тратить на них лишние усилия.

Если же вы решили делать свой консенсус, связанный с сетевым взаимодействием, или вы используете новые криптографические концепции, которые архитектурно не укладываются в традиционный дизайн блокчейнов; если вы собираетесь обойти все существующие решения по производительности, экономя каждый бит; если транзакции в вашем блокчейне настолько специфические, что ничего подобного в мире не существует… Тогда ваш путь — блокчейн с нуля.

Подписывайтесь на канал Forklog в YouTube!

Нашли ошибку в тексте? Выделите ее и нажмите CTRL+ENTER

Пишем свой блокчейн

Самый быстрый способ изучить работу Блокчейнов – это создать свой блокчейн. Стоит лишь только попробовать!

Скорее всего вы здесь, также, как и я, потому что были недовольны резким подъемом Криптовалюты. И вы хотите узнать, как же работают Блокчейны – фундаментальная технология, которая стоит за всеми криптовалютами.

Но понять, как работают Блокчейны не так просто – ну или, как минимум для меня, это сложно. Я с трудом пробирался сквозь множество непонятных видеороликов, сомнительных туториалов и боролся с сильным разочарованием от очень малого количества примеров. Поэтому мы с вами напишем свой блокчейн.

Вообще, я люблю изучать что-либо практическим путём. Это заставляет меня разобраться с сутью вопроса на уровне кода, который позволяет уловить суть происходящего. Если вы делаете точно также, то к концу этого туториала, у вас будет полностью функционирующий свой Блокчейн, и твёрдое понимание того, как они работают.

Обратите внимание, что блокчейн – это неизменяемая последовательная цепочка записей, называемых Блоками. Они могут состоять из транзакций, файлов, или любой другой информации, которая вам необходима. Но самым важным здесь является то, что все они связаны вместе с помощью хэшей.

Если вы не уверены в том, что такое хэш, то вот объяснение.

У вас не должно возникать трудностей с чтением синтаксиса и написанием базовых вещей на Python. Кроме того, у вас должно быть понимание того, как работают HTTP-запросы, поскольку обращаться к нашему Блокчейну мы будем именно через них.

Убедитесь в том, что у вас установлен Python 3.6+ (также как и pip). Вам также необходимо установить библиотеку Flask и прекрасную библиотеку Request:

pip install Flask==0.12.2 requests==2.18.4

О, вам также понадобится HTTP-клиент, наподобие Postman или cURL. Но все будет дальше.

Исходный код будет доступен здесь.

Запустите ваш любимый редактор кода или IDE, лично мне нравится PyCharm. Создайте новый файл с названием blockchain.py. Мы будем использовать только один файл, но если вы вдруг запутаетесь, то всегда можете обратиться к исходному коду.

Создадим класс Blockchain, конструктор которого будет создавать изначально пустой список (для хранения нашего блокчейна), и еще один для хранения транзакций. Ниже приведен макет нашего класса:

 	
class Blockchain(object):	
    def __init__(self):
        self.chain = []
        self.current_transactions = []
 	
    def new_block(self):
        # Создает новый Блок и добавляет его к цепочке
        pass

 	
    def new_transaction(self):
        # Добавляет новую транзакцию к списку транзакций
        pass
 	
    @staticmethod	
    def hash(block):
        # Хэшируем блоки
        pass
 	

    @property
    def last_block(self):
        # Возвращает последний блок в цепочке
        pass

Наш класс blockchain отвечает за управление цепочкой. В нем будут хранится транзакции и некоторые вспомогательные методы для добавления блоков в цепочку. Давайте же начнем использовать некоторые из методов.

Каждый блок содержит в себе индекс, временную метку (timestamp, по Unix времени), список транзакций, доказательность (proof, подробнее об этом позже) и хэш предыдущего Блока.

Далее приведен пример того, как выглядит отдельный Блок:

block = {
    'index': 1,
    'timestamp': 1506057125.900785,
    'transactions': [
        {
            'sender': "8527147fe1f5426f9dd545de4b27ee00",
            'recipient': "a77f5cdfa2934df3954a5c7c7da5df1f",
            'amount': 5, 	
        }
    ],
    'proof': 324984774000,
    'previous_hash': "2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824"
}

На данном этапе идея цепочки должна быть очевидна – каждый новый блок внутри себя содержит хэш предыдущего Блока. Именно наличие предыдущего хэша является решающим фактором, который делает блокчейны неизменяемыми. Если хакер повредит один из начальных блоков (любой предыдущий блок), то вся последовательность блоков будет содержать в себе некорректный хэш.

Какой в этом смысл? Если это не так, то потребуется некоторое количество времени для того, чтобы понять, что вообще происходит – это и есть ключевая идея блокчейнов.

Итак, нам понадобится способ добавления транзакций в блок. Наш метод new_transaction() отвечает за это, и он довольно простой:

class Blockchain(object):
    ...

    def new_transaction(self, sender, recipient, amount):
        """
      Создает новую транзакцию для того чтобы перейти к следующему искомому Блоку

        :параметр sender: <str> Адрес отправителя
        :параметр recipient: <str> Адрес получателя	
        :параметр amount: <int> Количество
        :return: <int> Индекс Блока, в котором будет хранится данная транзакция
        """

        self.current_transactions.append({
            'sender': sender,
            'recipient': recipient,
            'amount': amount,
        })
 	
        return self.last_block['index'] + 1

После того, как наш метод добавил транзакцию в список, то он возвращает индекс блока, в который будет добавлена транзакция – следующий искомый блок. Позже, для пользователя, отправляющего транзакцию, это будет полезно.

После того, как мы создали экземпляр нашего Блокчейна, нам необходимо заполнить его исходным блоком – блок у которого нет предшественников. Также нам необходимо добавить «proof» в наш исходный блок, который является результатом анализа (или алгоритма «доказательство выполнения работы»). По поводу анализа мы поговорим позднее.

Кроме этого, для создания исходного блока в нашем конструкторе, нам также необходимо добавить следующие методы: new_block(), new_transaction() и hash():

import hashlib	
import json
	
from time import time


 	
class Blockchain(object):	
    def __init__(self):
        """
        Инициализируем свой блокчейн
        """
        self.current_transactions = []
        self.chain = []


        # Create the genesis block
        self.new_block(previous_hash=1, proof=100)


    def new_block(self, proof, previous_hash=None):
        """
        Создаем новый блок в нашем Блокчейне

 	 	
        :параметр proof: <int> proof полученный после использования алгоритма «Доказательство выполнения работы»
        :параметр previous_hash: (Опциональный) <str> Хэш предыдущего Блока
        :return: <dict> New Block
        """

        block = {
            'index': len(self.chain) + 1,
            'timestamp': time(),
            'transactions': self.current_transactions,
            'proof': proof,
            'previous_hash': previous_hash or self.hash(self.chain[-1]),
        }

 	
        # Сбрасываем текущий список транзакций
        self.current_transactions = []

 	
        self.chain.append(block)
        return block
 	
    def new_transaction(self, sender, recipient, amount):
        """
        Создает новую транзакцию для перехода к следующему замайненному Блоку

        :param sender: <str> Address of the Sender
        :param recipient: <str> Address of the Recipient
        :param amount: <int> Amount
        :return: <int> Индекс блока который будет хранить в себе эту транзакцию
        """

        self.current_transactions.append({
            'sender': sender,
            'recipient': recipient,
            'amount': amount,
        })
 	
        return self.last_block['index'] + 1
 	
    @property
    def last_block(self):
        return self.chain[-1]

    @staticmethod
    def hash(block):
        """
        Создает a SHA-256 хэш блока

        :параметр block: <dict> Блок
        :return: <str>
        """

        # Мы должны быть уверены что наш Словарь упорядочен, или мы можем непоследовательные хэши
        block_string = json.dumps(block, sort_keys=True).encode()	
        return hashlib.sha256(block_string).hexdigest()

Код выше должен быть всем ясен и понятен – я добавил некоторое количество комментариев и немного строк документации, чтобы все было максимально прозрачно. Мы практически закончили с представлением нашего блокчейна. Однако на данном этапе, вы должны быть удивлены тому как новые блоки создаются, формируются и майнятся.

Алгоритм «Доказательство выполнения работы» (PoW) – это то, как новые блоки создаются или майнятся в блокчейне. Целью алгоритма PoW является нахождение такого числа (метки), которое будет решать проблему. Число должно быть таким, чтобы его было сложно найти и легко проверить. Говоря в вычислительном отношении не важно кем в сети это может быть сделано. В этом и заключается основная идея данного алгоритма.

Итак, давайте взглянем на простой пример, которой поможет нам во всем разобраться.

Предположим, что хэш некоторого целочисленного числа x, умноженного на другое целочисленное число y, должен заканчиваться на 0. Следовательно, hash(x * y) = ac23dc…0. И для нашего упрощенного примера исправим x на 5. Реализуем это в Python:

from hashlib import sha256


x = 5
y = 0  # Пока мы не знаем каким должен быть y


while sha256(f'{x*y}'.encode()).hexdigest()[-1] != "0":
    y += 1


print(f'The solution is y = {y}')

 

Решением здесь будет y=21. Поскольку полученный хэш заканчивается на 0:

hash(5 * 21) = 1253e9373e...5e3600155e860

В сфере Биткоинов, алгоритм «Доказательство выполнения работы» называется Hashcash. И он не сильно отличается от нашего базового примера выше. Это алгоритм, который майнеры используют в гонке по решению задачи создания новых блоков. Как правило, сложность определяется количеством символов, которые необходимо обнаружить в строке. После чего майнеры получают награду за свое решение в качестве биткойна при транзакции.

Сеть может легко проверить их решение.

Давайте реализуем простой алгоритм для того, чтобы реализовать свой блокчейн. Наше правило будет аналогично приведенному выше примеру:

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

import hashlib	
import json

 		
from time import time	
from uuid import uuid4

	
class Blockchain(object):	
    ...

    def proof_of_work(self, last_proof):
        """
        Простой алгоритм Proof of Work:
         - Ищем число p' такое, чтобы hash(pp') содержал в себе 4 лидирующих нуля, где p это предыдущий p'
         - p это предыдущий proof, а p' это новый proof

        :параметр last_proof: <int>
        :return: <int>
        """

        proof = 0
        while self.valid_proof(last_proof, proof) is False:
            proof += 1

        return proof


    @staticmethod
    def valid_proof(last_proof, proof):
        """
        Проверяем Proof: Содержит ли hash(last_proof, proof) 4 лидирующих нуля?

        :параметр last_proof: <int> предыдущий Proof
        :параметр proof: <int> Тукущий Proof
        :return: <bool> True если все верно, иначе False.
        """
	
        guess = f'{last_proof}{proof}'.encode()	
        guess_hash = hashlib.sha256(guess).hexdigest() 	
        return guess_hash[:4] == "0000"

Для регулирования сложности алгоритма, мы можем модифицировать количество лидирующих нулей. Одна четырех будет достаточно. Вы можете попробовать сами и понять, что добавление одного единственного лидирующего нуля приведет к гигантской разнице во времени поиска решения.

Наш класс практически готов, и мы готовы начать взаимодействовать с ним посредствам HTTP-запросов.

Мы будем использовать фреймворк Flask. Данный микро-фреймворк упрощает размещение конечных точек (endpoints) в Python-функциях. Это позволит нам обращаться к нашему блокчейну за счет веб-соединения с помощью HTTP-запросов.

Создадим три метода:

  • /transactions/new для создания новой транзакции в блоке;
  • /mine для передачи нашему серверу информации о том, что пора майнить новый блок;
  • /chain для возврата всего Блокчейна.

Настраиваем Flask для того, чтобы реализовать свой блокчейн

Наш «сервер» будет формировать одиночный узел в нашей блокчейн-сети. Давайте напишем некоторый шаблонный код:

import hashlib	
import json
	
from textwrap import dedent 	
from time import time	
from uuid import uuid4

	
from flask import Flask

	
class Blockchain(object):	
    ...

 	
# Создаем экземпляр нашего узла	
app = Flask(__name__)
 	
# Генерируем уникальный глобальный адрес для этого узла	
node_identifier = str(uuid4()).replace('-', '')

# Создаем экземпляр Blockchain	
blockchain = Blockchain()

 	
@app.route('/mine', methods=['GET']) 	
def mine():
    return "We'll mine a new Block"
 	
@app.route('/transactions/new', methods=['POST'])	
def new_transaction():
    return "We'll add a new transaction"

@app.route('/chain', methods=['GET'])
def full_chain():
    response = {
        'chain': blockchain.chain,
        'length': len(blockchain.chain),
    }	
    return jsonify(response), 200
 	
if __name__ == '__main__':	
    app.run(host='0.0.0.0', port=5000)

Небольшое пояснение того, что мы добавили в примере выше:

  • Строка 15: Создаем экземпляр узла. Более подробно узнать о Flask можно здесь.
  • Строка 18: Генерируем случайное имя для нашего узла;
  • Строка 21: Создаем экземпляр класса Blockchain;
  • Строки 24-26: Создаем endpoint для метода /mine, который является GET-запросом;
  • Строки 28-30: Создаем endpoint для метода /transactions/new, который является POST-запросом, поскольку мы будем отправлять сюда данные;
  • Строки 32-38: Создаем endpoint для метода /chain, который будет возвращать весь Блокчейн;
  • Строки 40-41: Запускаем наш сервер на порт 5000.

Endpoint для транзакций

Вот так будет выглядеть запрос транзакции. То есть, именно эту информацию пользователь отправляет на сервер:

{
 "sender": "my address",
 "recipient": "someone else's address",
 "amount": 5
}

В силу того, что мы уже создали методы для нашего класса, отвечающие за добавление транзакции в блок, то осталась самая простая часть. Давайте напишем функцию, которая будет добавлять наши транзакции:

import hashlib 	
import json
	
from textwrap import dedent 	
from time import time	
from uuid import uuid4

 	
from flask import Flask, jsonify, request

...
	
@app.route('/transactions/new', methods=['POST'])	
def new_transaction():
    values = request.get_json()


    # Проверяем, что обязательные поля переданы в POST-запрос
    required = ['sender', 'recipient', 'amount']
    if not all(k in values for k in required):
        return 'Missing values', 400

 	
    # Создаем новую транзакцию	
    index = blockchain.new_transaction(values['sender'], values['recipient'], values['amount'])
 	
    response = {'message': f'Transaction will be added to Block {index}'}
    return jsonify(response), 201

Endpoint для майнинга

Наш endpoint майнинга – это то, где происходит магия, и в ней нет ничего сложного. Здесь совершаются три следующих вещи:

  1. Расчет алгоритма PoW;
  2. Майнер(ы) получают награду в виде транзакции, которая гарантируем им 1 биткойн;
  3. Формирование нового блока, путем его добавления в цепочку.

 

import hashlib	
import json

 	
from time import time
from uuid import uuid4


from flask import Flask, jsonify, request
	
...
 	
@app.route('/mine', methods=['GET'])
def mine():
    # Мы запускаем алгоритм PoW для того чтобы найти следующий proof...
    last_block = blockchain.last_block	
    last_proof = last_block['proof']
    proof = blockchain.proof_of_work(last_proof)

 	
    # Мы должны получить награду за найденный proof.
    # Если sender = "0", то это означает что данный узел заработал биткойн.	
    blockchain.new_transaction(
        sender="0",	
        recipient=node_identifier,
        amount=1,
    )


    # Формируем новый блок, путем добавления его в цепочку
    block = blockchain.new_block(proof)
 	
    response = {
        'message': "New Block Forged",
        'index': block['index'],
        'transactions': block['transactions'],
        'proof': block['proof'],
        'previous_hash': block['previous_hash'],	
    }	
    return jsonify(response), 200

Обратите внимание, что получателем замайненного блока является адрес нашего узла. И большинство из того, что мы здесь сделали, просто взаимодействует с методами нашего класса Blockchain. На данном этапе мы закончили с подготовкой нашего блокчейна и теперь готовы взаимодействовать с ним.

Вы можете использовать простой, но уже устаревший cURL или Postman, для взаимодействия с нашим API через сеть.

Запускаем наш сервер:
$ python blockchain.py* Running on http://127.0.0.1:5000/ (Press CTRL+C to quit)

Давайте попробуем смайнить блок. Для этого воспользуемся GET-запросом на http://localhost:5000/mine:

Создадим новую транзакцию с помощью POST-запроса на http://localhost:5000/transactions/new с телом, содержащим структуру нашей транзакции:

Если не хотите использовать Postman, то вы можете сделать аналогичные запрос с помощью cURL:

$ curl -X POST -H "Content-Type: application/json" -d '{
 "sender": "d4ee26eee15148ee92c6cd394edd974e",
 "recipient": "someone-other-address",
 "amount": 5
}' "http://localhost:5000/transactions/new"

Я перезагрузил свой сервер, и смайнил два блока, чтобы в итоге получилось три. Давайте проверим всю цепочку, с помощью запроса на http://localhost:5000/chain:

{
  "chain": [
    {
      "index": 1,
      "previous_hash": 1,
      "proof": 100,
      "timestamp": 1506280650.770839,
      "transactions": []
    },
    {
      "index": 2,
      "previous_hash": "c099bc...bfb7",
      "proof": 35293,
      "timestamp": 1506280664.717925,
      "transactions": [
        {
          "amount": 1,
          "recipient": "8bbcb347e0634905b0cac7955bae152b",
          "sender": "0"
        }
      ]
    },
    {
      "index": 3,
      "previous_hash": "eff91a...10f2",
      "proof": 35089,
      "timestamp": 1506280666.1086972,
      "transactions": [
        {
          "amount": 1,
          "recipient": "8bbcb347e0634905b0cac7955bae152b",
          "sender": "0"
        }
      ]
    }
  ],
  "length": 3
}

Пока, все что мы делали, это круто. Мы получили базовый Блокчейн, который может принимать транзакции, тем самым позволяя нам майнить новые Блоки. Однако вся суть Блокчейнов заключается в том, что они должны быть децентрализованы. Но если блокчейны децентрализованы, то как мы можем гарантировать, что все они отражают одну и ту же цепочку? Данная проблема называется проблемой Консенсуса (конфликтов). Мы реализуем алгоритм Консенсуса, если мы конечно хотим, чтобы в нашей сети было больше одного узла.

Перед тем как мы сможем реализовать алгоритм Консенсуса, нам необходимо придумать способ, как наши узлы будут знать о своих «соседях» в сети. Каждый узел в нашей сети будет хранить в себе запись о других узлах в сети. Итак, нам необходимо еще некоторое количество endpoint-ов:

  1. /nodes/register чтобы можно было принимать список новых узлов в форме URL;
  2. /nodes/resolve для реализации нашего алгоритма Консенсуса, который разрешит любые конфликтные ситуации, чтобы каждый узел содержал корректную цепочку.

Для всего этого нам необходимо модифицировать конструктор нашего Блокчейна, и предоставить метод по регистрации узлов:

 

...	
from urllib.parse import urlparse	
...

 	
class Blockchain(object):
    def __init__(self):
        ...
        self.nodes = set()
        ...

    def register_node(self, address):
        """
        Добавляем новый узел в список узлов

        :параметр address: <str> Адрес узла, например: 'http://192.168.0.5:5000'
        :return: None
        """
 	
        parsed_url = urlparse(address)
        self.nodes.add(parsed_url.netloc)


Обратите внимание, что мы использовали set() для хранения списка узлов. Это самый дешёвый способ гарантировать, что новый узлы будут добавляться, не изменяя при этом объект, то есть не важно сколько раз мы добавляли определенный узел, он появится ровно один раз.

Как уже было сказано, конфликтная ситуация – это когда один узел содержит цепочку отличную от той, что есть в другом узле. Для решения этого, мы создадим правило, что наиболее длинная, прошедшая проверку, цепочка будет являться достоверной. Другими словами, самая длинная цепочка в сети будет фактической. При использовании данного алгоритма, мы достигаем консенсуса среди всех узлов в нашей сети.

...
import requests

 	
class Blockchain(object)	
    ...
 	
    def valid_chain(self, chain):
        """
        Определяем, что данный блокчейн прошел проверку
 
        :параметр chain: <list> Блокчейн
        :return: <bool> True если прошел проверку, иначе False
        """

        last_block = chain[0]
        current_index = 1
 	
        while current_index < len(chain):
            block = chain[current_index]
            print(f'{last_block}')	
            print(f'{block}')
            print("\n-----------\n")
            # Проверяем, что хэш этого блока корректен
            if block['previous_hash'] != self.hash(last_block):
                return False

            # Проверяем, что алгоритм PoW корректен
            if not self.valid_proof(last_block['proof'], block['proof']):
                return False

 	
            last_block = block
 	
            current_index += 1

        return True

    def resolve_conflicts(self):
        """
        Это наш алгоритм Консенсуса, он разрешает конфликт путём
        замены нашей цепочки на самую длинную в нашей сети.

        :return: <bool> True если наша цепочка была заменена, False если это не так
        """

 	
        neighbours = self.nodes
        new_chain = None

        # Мы ищем цепочки длиннее наших
        max_length = len(self.chain)

        # Берем все цепочки со всех узлов нашей сети и проверяем их
        for node in neighbours:
            response = requests.get(f'http://{node}/chain')
 	
            if response.status_code == 200:
                length = response.json()['length']
                chain = response.json()['chain']

                # Проверяем, что цепочка имеет 
                # максимальную длину и она корректна
                if length > max_length and self.valid_chain(chain):
                    max_length = length
                    new_chain = chain

        # Заменяем нашу цепочку, если нашли другую, 
        # которая имеет большую длину и является корректной
        if new_chain:
            self.chain = new_chain
            return True
 	
        return False

Первый метод valid_chain () отвечает за проверку цепочки на корректность, путем прогонки её по циклу через каждый блок, в котором сравнивается хэш и proof.

resolve_conflicts() – это метод который в цикле проходит по всем соседним узлам, скачивает их цепочки и проверяет их, используя метод выше. Если найдена необходимая цепочка, то мы заменяем текущую на эту.

Давайте зарегистрируем два endpoint-а в нашем API, один будет предназначен для добавления соседних узлов, а второй для разрешения конфликтных ситуаций.

 

@app.route('/nodes/register', methods=['POST'])
def register_nodes():
    values = request.get_json()

 	
    nodes = values.get('nodes')
    if nodes is None:
        return "Error: Please supply a valid list of nodes", 400

    for node in nodes:
        blockchain.register_node(node)

    response = {
        'message': 'New nodes have been added', 	
        'total_nodes': list(blockchain.nodes),
    }
    return jsonify(response), 201

 	
@app.route('/nodes/resolve', methods=['GET'])
def consensus():
    replaced = blockchain.resolve_conflicts()
 	
    if replaced:
        response = {
            'message': 'Our chain was replaced',
            'new_chain': blockchain.chain
        }
    else:
        response = {
            'message': 'Our chain is authoritative',
            'chain': blockchain.chain
        }

    return jsonify(response), 200

На этом этапе вы можете задействовать любое количество машин, по вашему усмотрению, и реализовать различные узлы в вашей сети. Или же реализовать все то же самое на одной машине, используя разные порты. Я это реализовал вторым способом, используя разные порты. То есть, я зарегистрировал другой узел, уже с имеющимся узлом. Итак, у меня есть два узла: http://localhost:5000 и http://localhost:5001.

После чего я замайнил новые блоки на узел 2, для того чтобы цепочка стала длиннее. Потом, я вызвал GET /nodes/resolve на узел 1, где цепочка была заменена по алгоритму Консенсуса:

И это просто обёртка… Объединитесь с друзьями для того, чтобы затестить свой Блокчейн.

Итак, мы с вами написали свой блокчейн. Я надеюсь, что данная статья способствует тому, что вы создадите что-то новое для себя.

Дополнение: Также планирую продолжить со второй частью статьи, где мы будем расширять свой блокчейн, для того чтобы у нас был свой механизм проверки транзакций. Кроме того, обсудим некоторые способы, с помощью которых вы сможете запустить свой Блокчейн в работу.

Простейший блокчейн своими руками
10 полезных ресурсов по технологии blockchain

Ссылка на оригинальную статью
Перевод: Александр Давыдов

Blockchain / Хабр

Данный текст будет являться новой главой для учебного пособия по защите информации кафедры радиотехники и систем управления МФТИ (ГУ). Полностью учебник доступен на github. На хабре я же планирую выкладывать новые «большие» куски, во-первых, чтобы собрать полезные комментарии и замечания, во-вторых, дать сообществу больше обзорного материала по полезным и интересным темам.

Когда у вас есть знания о том, что такое криптографически стойкая хеш-функция, понять, что такое blockchain («цепочка блоков») очень просто. Blockchain – это последовательный набор блоков (или же, в более общем случае, ориентированный граф), каждый следующий блок в котором включает в качестве хешируемой информации значение хеш-функции от предыдущего блока.

Технология blockchain используется для организации журналов транзакций, при этом под транзакцией может пониматься что угодно: финансовая транзакция (перевод между счетами), аудит событий аутентификации и авторизации, записи о выполненных ТО и ТУ автомобилей. При этом событие считается случившимся, если запись о нём включена в журнал.

В таких системах есть три группы действующих лиц:

  • источники событий (транзакций)
  • источники блоков (фиксаторы транзакций)
  • получатели (читатели) блоков и зафиксированных транзакций.

В зависимости от реализации эти группы могут пересекаться. В системах типа BitCoin, например, все участники распределённой системы могут выполнять все три функции. Хотя за создание блоков (фиксацию транзакций) обычно отвечают выделенные вычислительные мощности, а управляющими их участников называют майнерами (см. раздел про децентрализованный blockchain далее).

Основное требование к таким журналам таково:

  • Невозможность модификации журнала: после добавления транзакции в журнал должно быть невозможно её оттуда удалить или изменить.

Для того чтобы понять, как можно выполнить требование на запрет модификации, стоит разобраться со следующими вопросами:

  • Каким образом гарантируется, что внутри блока нельзя поменять информацию?
  • Каким образом система гарантирует, что уже существующую цепочку блоков нельзя перегенерировать, тем самым исправив в них информацию?

Ответ на первый вопрос прост: нужно снабдить каждый блок хеш-суммой от его содержимого. И эту хеш-сумму включить в качестве дополнительной полезной информации (тоже хешируемой) в следующий блок. Тогда для того, чтобы поменять что-то в блоке без разрушения доверия клиентов к нему, нужно будет это сделать таким образом, чтобы хеш-сумма от блока не поменялась. А это как раз практически невозможно, если у нас используется криптографически стойкая хеш-функция. Либо поменять в том числе и хеш-сумму блока. Но тогда придётся менять и значение этой хеш-суммы в следующем блоке. А это потребует изменений, в свою очередь, в хеш-сумме всего второго блока, а потом и в третьем, и так далее. Получается, что для того, чтобы поменять информацию в одном из блоков, нужно будет перегенерировать всю цепочку блоков, начиная с модифицируемого. Можно ли это сделать?

Тут нужно ответить на вопрос, как в подобных системах защищаются от возможности перегенерации цепочки блоков. Мы рассмотрим три варианта систем:

  • централизованный с доверенным центром
  • централизованный с недоверенным центром
  • децентрализованный вариант с использованием доказательства работы

Централизованный blockchain с доверенным центром

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

Использование технологии blockchain в этом случае является избыточным. Если у нас есть доверенный центр, можно просто обращаться к нему с целью подписать каждую транзакцию, добавив к ней время и порядковый номер. Номер обеспечивает порядок и невозможность добавления (удаления) транзакций из цепочки, электронная подпись доверенного центра – невозможность модификации конкретных транзакций.

Централизованный blockchain с недоверенным центром

Интересен случай, когда выделенный центр не является доверенным. Точнее, не является полностью доверенным. Мы ему доверяем в плане фиксации транзакций в журнале, но хотим быть уверенными, что выделенный центр не перегенерирует всю цепочку блоков, удалив из неё ненужные ему более транзакции или добавив нужные.

Для этого можно использовать, например, следующие два метода.

  • Первый метод с использованием дополнительного доверенного хранилища. После создания очередного блока центр должен отправить в доверенное и независимое от данного центра хранилище хеш-код от нового блока. Доверенное хранилище не должно принимать никаких изменений к хеш-кодам уже созданных блоков. В качестве такого хранилища можно использовать и децентрализованную базу данных системы, если таковая присутствует. Размер хранимой информации может быть небольшим по сравнению с общим объёмом журнала.
  • Второй возможный метод состоит в дополнении каждого блока меткой времени, сгенерированной доверенным центром временных меток. Такая метка должна содержать время генерации метки и электронную подпись центра, вычисленную на основании хеш-кода блока и времени метки. В случае, если «недоверенный» центр захочет перегенерировать часть цепочки блоков, будет наблюдаться разрыв в метках времени.
    • Стоит отметить, что этот метод не гарантирует, что «недоверенный» центр не будет генерировать сразу две цепочки блоков, дополняя их корректными метками времени, а потом не подменит одну другой.

Децентрализованный blockchain

Наибольший интерес для нас (и – наименьший для компаний, продающих blockchain-решения) представляет децентрализованная система blockchain без выделенных центров генерации блоков. Каждый участник может взять набор транзакций, ожидающих включения в журнал, и сформировать новый блок. Более того, в системах типа BitCoin такой участник (будем его назвать «майнером», от англ. to mine — копать) ещё и получит премию в виде определённой суммы и/или комиссионных от принятых в блок транзакций.

Но нельзя просто так взять и сформировать блок в децентрализованных системах. Надёжность таких систем основывается именно на том, что новый блок нельзя сформировать быстрее (в среднем) чем за определённое время. Например, за 10 минут (BitCoin). Это обеспечивается механизмом, который получил название доказательство работы.

Механизм основывается на следующей идее. Пусть есть криптографически стойкая хэш-функция и задан некоторый параметр (от англ. target – цель). , где — размер выхода хэш-функции в битах. Корректным новым блоком blockchain-сеть будет признавать только такой, значение хэш-суммы которого меньше текущего заданного параметра . В этом случае алгоритм работы майнера выглядит следующий образом:

Для каждой итерации цикла вероятность получить корректный блок равна . Так как обычно мало, то майнерам нужно сделать большое количество итераций цикла, чтобы найти нужный . При этом только один (обычно — первый) из найденных блоков будет считаться корректным. Чем больше вычислительная мощность конкретного майнера, тем больше вероятность, что именно он первым сумеет найти нужный .

Зная суммарную вычислительную мощность blockchain-сети, участники могут договориться о таком механизме изменения параметра , чтобы время генерации нового корректного блока было примерно заданное время. Например, в сети Bitcoin параметр пересчитывается каждые 2016 блоков таким образом, чтобы среднее время генерации блока было 10 минут. Это позволяет адаптировать сеть к изменению количества участников, их вычислительных мощностей и к появлению новых механизмов вычисления хэш-функций.

Кроме задания параметра можно оперировать другими величинами, так или иначе относящимися к мощности вычислений.

  • Hashrate — количество хешей, которые считают за единицы времени конкретный майнер или сеть в целом. Например, в ноябре 2017 года общий hashrate для сети Bitcoin составлял примерно хэшей в секунду.
  • Difficulty — сложность поиска корректного блока, выражаемая как , где — некоторая константа сложности, а t — текущая цель (англ. target). В отличие от параметра t, который падает с ростом вычислительной мощности сети, d изменяется вместе с hashrate, что делает его более простым для восприятия и анализа человеком.

В случае примерно одновременной генерации следующего блока двумя и более майнерами (когда информация о новом блоке публикуется вторым майнером до того, как ему придёт информация о новом блоке от первого) в направленном графе блоков происходит разветвление. Далее каждый из майнеров выбирает один из новых блоков (например – какой первый увидели) и пытается сгенерировать новый блок на основе выбранного, продолжая «ответвление» в графе. В конце-концов одна из двух таких цепочек становится длиннее (та, которую выбрало большее число майнеров), и именно она признаётся основной.

В случае нормального поведения системы на включение конкретных транзакций в блоки это влияет мало, так как каждый из добросовестных майнеров следует одному и тому же алгоритму включения транзакций в блок (например, в сети BitCoin – алгоритму максимизации комиссии за блок). Однако можно предположить, что какой-нибудь злоумышленник захочет «модерировать» распределённый blockchain, включая или не включая в блоки транзакции по своему выбору. Предположим, что доля вычислительных ресурсов злоумышленника (направленных на генерацию нового блока) равна ( 0% < < 50%). В этом случае каждый следующий сгенерированный блок с вероятностью будет сгенерирована мощностями злоумышленника. Это позволит ему включать в блоки те транзакции, которые другие майнеры включать не захотели.

Но позволит ли это злоумышленнику не включать что-то в цепочку транзакций? Нет. Потому что после его блока с вероятностью будет следовать блок «обычного» майнера, который с радостью (пропорциональной комиссии-награде) включит все транзакции в свой блок.

Однако ситуация меняется, если мощности злоумышленника составляют более 50% от мощности сети. В этом случае, если после блока злоумышленника был с вероятностью сгенерирован «обычный» блок, злоумышленник его может просто проигнорировать и продолжать генерировать новые блоки, как будто он единственный майнер в сети. Тогда если среднее время генерации одного блока всеми мощностями , то за время злоумышленник сможет сгенерировать , а легальные пользователи блоков, . Даже если с некоторой вероятностью легальные пользователи сгенерируют 2 блока быстрее, чем злоумышленник один, последний всё равно «догонит и перегонит» «легальную» цепочку примерно за время . Так как в blockchain есть договоренность, что за текущее состояние сети принимается наиболее длинная цепочка, именно цепочка злоумышленника всегда будет восприниматься правильной. Получается, что злоумышленник сможет по своему желанию включать или не включать транзакции в цепочки.

Правда, пользоваться чужими деньгами злоумышленник всё равно не сможет – так как все блоки транзакций проверяются на внутреннюю непротиворечивость и корректность всех включённых в блок транзакций.

Кроме концепции «доказательство работы» используются и другие. Например, в подходе «доказательство доли владения» (англ. proof of stake), используемой в сетях Etherium и EmerCoin, вероятность генерации блока пропорциональна количеству средств на счетах потенциальных создателей нового блока. Это намного более энергоэффективно по сравнению с PoW, и, кроме того, связывает ответственность за надёжность и корректность генерации новых блоков с размером капитала (чем больше у нас средств, тем меньше мы хотим подвергать опасности систему). С другой стороны, это даёт дополнительную мотивацию концентрировать больше капитала в одних руках, что может привести к централизации системы.

Механизм внесения изменений в протокол

Любая система должна развиваться. Но у децентрализованных систем нельзя просто «включить один рубильник» и заставить участников системы работать по новому – иначе систему нельзя назвать полностью децентрализованной. Механизмы и способы внесения изменений могут выглядеть на первый взгляд нетривиально. Например:

  • апологеты системы предлагают изменения в правилах работы
  • авторы ПО вносят изменения в программный код, позволяя сделать две вещи:
    • указать участникам системы, что они поддерживают новое изменение
    • поддержать новое изменение
  • участники системы скачивают новую версию и выставляют в новых блоках транзакций (или самих транзакциях) сигнальные флаги, показывающие их намерение поддержать изменение
  • если к определённой дате определённое число блоков содержат сигнальный флаг (обратите внимание на привязку числа голосов к числу сгенерированных блоков), то изменение считается принятым, и большая (по числу новых блоков) часть участников системы в определённую дату включают эти изменения
  • те участники, которые не приняли изменения, или приняли изменения вопреки отсутствию согласия на них большей части участников, в худшем случае начнут генерировать свою цепочку блоков, только её признавая корректной. Основную цепочку блоков они будут считать неверно сгенерированной. По факту это приведёт к дублированию (разветвлению, форку) системы, когда в какую-то дату вместо одного журнала транзакций появляется два, ведущимися разными людьми. Это журналы совпадают до определённой даты, после чего в них начинаются расхождение.

Подводя итоги, Сатоши Накамото (псевдоним), автор технологий blockchain и bitcoin, сумел предложить работающий децентрализованный механизм, в котором и само поведение системы, и изменения к этой системе проходят через явный или неявный механизм поиска консенсуса участников. Для получения контроля над системой в целом злоумышленнику придётся получить контроль как минимум над 50% всех мощностей системы (в случае PoW), а без этого можно лишь попытаться ограничить возможность использования системы конкретными участниками.

Однако созданная технология не лишена недостатков. Существуют оценки, согласно которым использование метода PoW для системы bitcoin приводит к затратам энергии, сравнимой с потреблением электричества целыми городами или странами. Есть проблемы и с поиском консенсуса – сложный механизм внесения изменений, как считают некоторые эксперты, может привести к проблемам роста (например, из-за ограниченности числа транзакций в блоке), и, в будущем, к отказу использования механизма как устаревшего и не отвечающего будущим задачам.

Хотелось бы узнать у сообщества, про какие ещё технологии стоит рассказывать студентам. С одной стороны, им обязательно надо рассказать про базовые вещи — классическую криптографию и криптографию на открытых ключах. Но хочется дать понятие и про современные вещи, которые, возможно, не станут лишним грузом знаний и через пять-десять лет. С текущим содержание учебной программы можно ознакомиться здесь.

История изменений

  • 2017-11-17: Добавлено указание лицензии CC-BY
  • 2017-11-18: Уточнёна и расширена информация про механизм proof-of-work и связанные определения

Подтверждение доли и доказательство работы / Блог компании Bitfury Group / Хабр

Блокчейн — это распределенная система, в которой могут находиться тысячи участников. В отличие от обычных распределенных баз данных, в блокчейне почти всегда отсутствует центральный администратор, который конфигурирует узлы сети, поэтому получается, что архитектура блокчейна не просто распределена, но децентрализована. В связи с этим для блокчейна является актуальной задача распределенного консенсуса:

«Как узлам сети достичь одинаковой точки зрения на журнал транзакций блокчейна в распределенной сети при условии, что произвольные узлы могут «падать» или зависать, руководствуясь лишь общими правилами обработки сообщений в сети?»

О том, как достигается консенсус в блокчейнах, мы поговорим в нашем сегодняшнем материале.

/ изображение jgbarah CC

Структура и узлы блокчейн-сетей

В любой блокчейн-сети передаются два основных типа сообщений — транзакции и блоки (которые, в свою очередь, являются списками транзакций). Транзакции формируются участниками системы и их алгоритм консенсуса не касается: для того чтобы инициировать, скажем, отправку биткойнов, никакого соглашения не надо, достаточно знать правильный ключ. Блоки — совсем другое дело. Они являются основным продуктом алгоритма консенсуса и определяют, в каком порядке транзакции будут включены в журнал транзакций.

Зачем нужны эти сложности? Оказывается, без согласования между узлами сети возможна повторная трата средств (double spending). Предположим, у Евы есть 1 биткойн. Она может сформировать две транзакции, согласно которым этот биткойн переходит Алисе и Бобу. Если Алиса и Боб никак не согласовывают свою историю транзакций, они оба примут платеж Евы, поскольку транзакции будут подписаны электронной подписью Евы, а до выполнения транзакции у Евы действительно был этот биткойн! Поэтому участникам сети нужно согласовывать журналы транзакций. Тогда успешно выполнится только одна из транзакций Евы, а вторая станет некорректной — средства Евы будут уже потрачены.

Можно ли обойтись без блоков, включая транзакции в журнал по отдельности? Теоретически да, но на практике блоки экономят объем трафика и вычислительные ресурсы узлов сети. Кроме того, у них есть и другие преимущества в контексте конкретных алгоритмов консенсуса — оказывается, что со слишком частыми блоками работа блокчейна становится нестабильной.

Блоки создаются особой категорией узлов сети блокчейна — так называемыми узлами консенсуса. В случае биткойна и других криптовалют эти узлы называют майнерами, поскольку они вознаграждаются за свою работу (майнинг) генерацией новых порций криптовалюты. Майнеры активно участвуют в формировании блокчейна, постоянно группируя входящие транзакции в блоки и распространяя их по сети.

Второй тип — узлы аудита. Они не участвуют в процессе консенсуса, однако имеют у себя полную копию блокчейна. «Аудиторы» регулярно проверяют работу майнеров и занимаются распределением нагрузки по сети, выполняя функцию своеобразной сети доставки контента (CDN) для данных блокчейна.

Третий тип узлов — это легкие клиенты. Легкими они называются потому, что не имеют полной версии блокчейна и содержат лишь те данные, которые важны для узла. По этой причине они являются хорошим вариантом для организации криптовалютного кошелька — всей картины сети такой клиент не даст, но позволит эффективно отслеживать баланс пользователя. Легкие клиенты требуют меньше вычислительных ресурсов и объемов памяти, поэтому могут работать на мобильных платформах.

/ Роли узлов в блокчейн-сети. Узлы консенсуса и конечные клиенты могут быть «отгорожены» друг от друга

Биткойн-блокчейн является одним из крупнейших блокчейнов. По данным сайта bitnodes, 8 апреля 2017 года в биткойн-сети наблюдалось 7025 узлов с полной копией блокчейна. Большая часть из них — это узлы аудита; продуктивных майнеров в сети не так уж много — несколько десятков. Отметим, что количество узлов в несколько раз меньше числа участников сети биткойн (которых более 13 миллионов). Так получается потому, что пользователи не обязаны хранить локальную копию блокчейна для отправки транзакций — достаточно хранить закрытые ключи, при помощи которых транзакции подписываются.

Консенсус

Задача распределенного консенсуса не специфична для блокчейнов и имеет хорошо проверенные решения для многих других распределенных систем (например, баз данных NoSQL). Даже задача консенсуса, в котором узлы могут вести себя «по-плохому», — задача византийского консенсуса — впервые была сформулирована в 80-х годах прошлого века, а методы её решения появились в конце 90-х.

Но биткойн и другие блокчейны от предыдущих наработок отличаются условиями работы сети. В обычных алгоритмах византийского консенсуса у узлов сети есть «личности», выражаемые через цифровые подписи или сходные криптопримитивы, а сам список узлов известен заранее или меняется редко, но предсказуемо. В биткойн-блокчейне все наоборот.

Участники сети не только заранее неизвестны, но и могут свободно подключаться или отключаться от сети. При этом блокчейн, являясь децентрализованной системой, имеет определенные свойства: устойчивость к цензуре (никто не может запретить майнить криптовалюту) и объективность (для определения текущей версии журнала транзакций не нужно доверие неким авторитетным источникам — корень доверия находится в самом блокчейне).

Из-за этого обычные алгоритмы византийского консенсуса для блокчейна не подходят. Поэтому было предложено множество различных алгоритмов, среди которых выделяются две основные категории: алгоритмы на основе доказательства работы (proof-of-work) и алгоритмы на основе подтверждения доли (proof-of-stake).

Доказательство работы — PoW

Доказательство работы было «изобретено» задолго до биткойна еще в начале 90-х и применялось в ином контексте: для защиты от спама. Например, один вариант доказательства работы (Hashcash) был предложен английским криптографом Адамом Бэком (Adam Back), который сейчас является генеральным директором одного из крупнейших блокчейн-стартапов.

В случае доказательства работы хеш сообщения, объединенного со специальным полем (nonce), должен быть меньше определенного значения (или начинаться с определенного числа нулевых битов). Nonce не несет смысла для самого сообщения — это поле перебирается автором доказательства, пока не будет найдено подходящее значение. Название «доказательство работы» отражает тот факт, что для нахождения nonce надо совершить вычислительную работу, ожидаемое количество которой измеримо. Например, если нужно, чтобы первые 16 бит хеша равнялись нулю, то в среднем нужно перебрать 65536 значений nonce.

Проиллюстрировать это можно с помощью программы на Python:

import itertools
from hashlib import sha256

# Интерпретирует последовательность символов как little-endian число
to_long = lambda x: sum(ord(b) << (8*i) for i, b in enumerate(x))
# Комбинирует nonce и сообщение для вычисления хэша.
combine = lambda nonce, msg: str(nonce) + ":" + msg

# Проверяет доказательство работы    
def verify_pow(msg, nonce, difficulty):
    h = sha256(combine(nonce, msg)).digest()
    # Равны ли первые difficulty битов хеша нулю?
    return to_long(h) % (1 << difficulty) == 0

# Создает доказательство работы для сообщения
def create_pow(msg, difficulty):
    for nonce in itertools.count(0):
        if verify_pow(msg, nonce, difficulty): return nonce
	
msg = "blockchain"
nonce = create_pow(msg, 16)
combine(nonce, msg), sha256(combine(nonce, msg)).hexdigest()
#43952:blockchain 000027b5022f88d2da21bd2802268966050f5a0b031058ce4562939c13727303

Уточнение насчет ожидаемого количества работы является важным. Теоретически, при сильном везении, подходящий nonce можно найти очень быстро. Если программу выше запустить с сообщением «Bl0Ckchain», то получится, что значение nonce равняется 6571, а это в десять раз меньше ожидаемого. Поэтому, глядя на доказательство работы, можно лишь оценить затраченные на него ресурсы, однако для высокой сложности доказательства (то есть ожидаемого количества выполненной работы) эта оценка будет достаточно точна.

Доказательство работы похоже на цифровые подписи — оно обеспечивает целостность сообщения, так как вероятность того, что один и тот же nonce подойдет для различных сообщений, очень мала. Доказательства также легко проверяются — достаточно провести лишь одну операцию хеширования. В отличие от подписей, создание доказательства работы не требует знания секретов, но «потребляет» больше вычислительных ресурсов. Например, в приведенной выше программе на создание доказательства работы для сообщения «blockchain» сложностью 32 бита требуется несколько часов вычислений на обычном персональном компьютере, однако проверяется это доказательство практически мгновенно.

sha256("5263268363:blockchain") = 000000007cf39dfc8fccae534b39b5f362c16891abca02d0e7b1dbd5a129ee17

PoW и консенсус

Использование PoW для консенсуса — пожалуй, самая большая инновация оригинальной статьи о биткойне. Соответствующий алгоритм консенсуса получил вполне академическое название — консенсус Накамото. Сатоши (автор или авторы статьи) предложил «подписывать» каждый создаваемый блок доказательством работы, сложность которого зависит от общей вычислительной сложности сети биткойна. Такой подход дает несколько преимуществ:

  • Консенсус Накамото решает главный бич анонимных сетей — атаки Сибиллы, в которых злоумышленник создает кучу фейковых узлов, чтобы «задавить» получившимся большинством мнение честных пользователей. Чтобы обладать мнением в консенсусе Накамото, нужно обладать реальной вычислительной мощностью, которую нельзя подделать, и которая не требует никакой дополнительной аутентификации — она сама по себе привязывает узлы к реальному миру.
  • Доказательство нельзя подделать и «перенести» на другие блоки. Таким образом, майнеры не могут воровать доказательства друг у друга.
  • Более того, доказательства нельзя заготовить впрок — в каждый блок входит ссылка на предыдущий, поэтому начать работать над доказательством можно только после появления предыдущего блока в сети.
  • Доказательства работы обеспечивают честность — награда каждого майнера пропорциональна его вычислительной мощности (хешрейту). Если у майнера есть 10% хешрейта от всей сети, то он будет в среднем создавать 10% блоков и получать 10% награды.
  • Поскольку на создание доказательства тратятся реальные ресурсы (которые в случае биткойна измеряются тысячами долларов в минуту), у майнеров возникает совершенно новый стимул действовать в рамках протокола — нечестное поведение немедленно лишает их реальных денег.

Доказательства работы используются узлами биткойна для определения состояния системы. Актуальный журнал транзакций определяется как цепочка блоков с наибольшей суммарной сложностью доказательств работы. Майнеры, соответственно, должны искать блок поверх этой цепочки. Но, теоретически, никто не запрещает создавать новые блоки на основе какого-то старого блока (иногда случаются расщепления — форки — блокчейна, потому что два майнера находят новый блок практически одновременно). Однако намеренные форки невыгодны экономически, потому что блоки из побочных ветвей блокчейна никем не учитываются и не приносят их создателям никакой прибыли — одни затраты на нахождение доказательства работы.

Консенсус Накамото обеспечивает два ключевых требования к блокчейну, которые мы выделили ранее. Из-за того, что доказательство работы не привязывается к личностям майнеров (в отличие от цифровых подписей/сертификатов), обеспечивается устойчивость к цензуре. А за счет того, что доказательства работы быстро проверяются и не требуют для проверки ничего, кроме блокчейна, достигается объективность протокола.

Консенсус Накамото устойчив к атакам на сеть блокчейна, причем его безопасность достаточно хорошо исследована теоретически (в отличие от более новых предложений для блокчейнов). В оригинальной статье отмечено, что сеть биткойна продолжит адекватно функционировать, даже если половина майнеров начнет злонамеренную активность. Если же среди майнеров появится злонамеренное большинство (так называемая атака 51%), они смогут игнорировать блоки от всех остальных майнеров, чтобы забрать себе всю награду в сети, или, например, мошенничать, производя повторную трату средств за счет намеренных форков блокчейна. Однако при этом отметим, даже если все майнеры в сети сговорятся, они не смогут обойти базовые механизмы безопасности биткойна — например, не смогут похитить биткойны пользователей.

Биткойн — самая мощная сеть, использующая доказательство работы. За одну секунду майнеры биткойна вычисляют более трех квинтиллионов (3∙1018) хешей. 32-битное доказательство (которое вычисляется на компьютере несколько часов) — это минимальная сложность в биткойне, которую можно было наблюдать лишь в самом начале работы сети. Это связано с тем, что сложность доказательства автоматически регулируется так, чтобы биткойн-сеть находила в среднем один блок в 10 минут. При увеличении хешрейта сети растет и сложность — сейчас сложность одного доказательства составляет около 70 бит. Соответственно, hex-запись хеша блока должна начинаться с 17 нулей.

/ Мощность биткойн-сети растет по экспоненте. Это обеспечивает высокую стоимость атаки на сеть

Альтернативы для PoW

У консенсуса Накамото есть свойство, которое многими воспринимается как большой недостаток, — для обеспечения безопасности нужно «работать», то есть производить доказательства работы. Вычисления, которые выполняются в рамках PoW, не служат никакой полезной цели, и это архитектурная особенность. Оказывается, очень сложно придумать доказательство работы, которое бы выполняло общественно полезную роль. Поэтому может показаться, что ресурсы (прежде всего, электричество) на майнинг тратятся впустую (если не считать, что они тратятся на обеспечение безопасности).

Помимо этого, майнинг все же подвержен проблеме централизации. Более 70% хешрейта биткойна на данный момент находится в одной стране — Китае. Многие криптовалюты пытаются децентрализовать майнинг за счет использования доказательств работы, которые экономически невыгодно вычислять на специализированном оборудовании, однако с таким подходом возникает другая проблема — если сделать выгодным майнинг биткойнов с помощью домашних компьютеров, то арендовать оборудование для атаки (или создать для нее ботнет) станет существенно дешевле и проще.

Пытаясь решить эти проблемы, сообщество предлагает множество алгоритмов консенсуса, которые не требуют «работы». Самая популярная категория таких алгоритмов основана на доказательствах доли (proof-of-stake, PoS). Доказательство доли похоже на доказательство работы, только вместо совершения определенной работы автор показывает, что у него есть доля в системе (например, в виде ненулевого баланса криптовалюты). Получается, что для майнинга с PoS достаточно «запастись» криптовалютой, после чего просто получать с нее «проценты».

Однако у доказательства доли есть неприятный недостаток в сравнении с PoW: поскольку доказательства доли базируются не на реальном мире (вычислительная мощность), а на чём-то внутри самого блокчейна (баланс криптовалюты), задача построения надежного PoS-алгоритма оказывается нетривиальной.

В простейших вариантах PoS-консенсуса возникают проблемы с базовыми свойствами. Оказывается, что в них самым экономически выгодным поведением является размножение форков блокчейна для повторной траты средств. Были созданы более сложные варианты доказательства доли, без явных дыр в безопасности; такие алгоритмы возвращают в консенсус фактор экономической ответственности за счет обязательного залога, который конфискуется в случае некорректного поведения участника.

У криптографического сообщества все еще остаются сомнения насчет возможности надежных алгоритмов с доказательством доли. Возможно, планируемый переход на доказательство доли блокчейна Ethereum — второго по объему рынка публичного блокчейна — расставит все точки над i.

Кроме доказательства доли, блокчейн-энтузиасты экспериментируют и с другими алгоритмами «proof-of-*». Например, Брэм Коэн (Bram Cohen), создатель протокола BitTorrent, недавно предложил использовать для консенсуса в блокчейнах доказательство локального хранения файлов (proof-of-space), то есть заменить вычислительную мощность в PoW на дисковое пространство. Однако по степени зрелости подобные инициативы еще сильнее отстают от алгоритмов доказательства работы, чем proof-of-stake.


P.S. А вот еще небольшая подборка наших материалов:

Bitcoin in a nutshell — Blockchain / Хабр

Blockchain — это технология, на базе которой построен Bitcoin. И если пару лет назад вся слава доставлась криптовалюте, то сегодня все чаще можно слышать смелые фразы вроде: «Forget Bitcoin, Long Live Blockchain». Активно развиваются платформы вроде Ethereum, IPFS или Overstock, которые рассматривают блокчейн не как инструмент для создания еще одной платежной системы, а как совершенно обособленную технологию, сравнимую по своей инновационности разве что с Интернетом.

В этой главе я расскажу вам, что из себя представляет блокчейн Bitcoin. Даже по сравнению с Ethereum, это жуткий анахронизм, но понимание принципов его работы вам сильно поможет, если вы решите разобраться с более сложными проектами.

Book

Table of content

  1. Blockchain for dummies
  2. Structure
  3. Merkle tree
  4. Timestamp
  5. Raw block
  6. Links

Blockchain for dummies

Сам по себе блокчейн — это крайне простая штука. Его проще всего проиллюстрировать на примере книги бухгалтерского учета, в которую записываются все транзакции в сети Bitcoin. Более того, такая книга присутствует у каждого участника сети, а значит любой, при желании, может проверить, была та или иная транзакция в реальности или нет.

И если блокчейн целиком — это книга, то отдельные блоки можно представлять как страницы, на которых «записываются» транзакции. Кажый блок «ссылается» на предыдущий и так до самого первого блока (genesis block). Именно это и создает такую интересную особенность блокчейна, как неизменяемость. Нельзя взять и изменить блок #123 так, чтобы этого никто не заметил. Потому что блокчейн устроен таким образом, что это повлечет изменение блока #124, потом #125 и так далее, до самого верха.

Structure

Привычным движением руки открываем спецификацию протокола и смотрим на структуру блока.

  • version — версия блока
  • prev_block — хэш предыдущего блока (parent block)
  • merkle_root — если упрощенно, то это хэш всех транзакций в блоке
  • timestamp — дата и время создания блока
  • bits, nonce — про эти параметры я подробно расскажу в главе Bitcoin in a nutshell — Mining
  • txn_count, txns — число транзакций в блоке и их список

Первые шесть параметров (все кроме txn_count и txns) образуют заголовок блока (header). Именно хэш заголовка называют хэшем блока, то есть сами транзакции непосредственного участия в хэшировании не принимают.

Вместо этого они заносятся в особую структуру — дерево Меркла, про которую я расскажу ниже.

Merkle tree

Technical side

Дерево Меркла — это структура данных, также известная как бинарное дерево хэшей. В случае Bitcoin оно строится следующим образом:

  1. Сначала считаются хэши всех транзакций в блоке hash_A = SHA256(SHA256(A))

  2. Потом считаются хэши от суммы хэшей транзакций hash_AB = SHA256(SHA256(hash_A + hash_B))

  3. Точно также считаем хэши от суммы получившихся хэшей hash_ABCD = SHA256(SHA256(hash_AB + hash_CD)) и далее по рекурсии. Лирическое отступление — так как дерево бинарное, то на кажом шаге должно быть четное число элементов. Поэтому если, например, у нас только три транзакции, то последняя транзакция просто дублируется:

  4. Процесс продолжается до тех пор, пока не получится один единственный хэш — он и называется merkle_root (третье поле в header блока)

Ниже приведена реализация дерева Меркла, можете проверить ее на каком-нибудь блоке.

import hashlib

# Hash pairs of items recursively until a single value is obtained
def merkle(hashList):
    if len(hashList) == 1:
        return hashList[0]
    newHashList = []
    # Process pairs. For odd length, the last is skipped
    for i in range(0, len(hashList)-1, 2):
        newHashList.append(hash3(hashList[i], hashList[i+1]))
    if len(hashList) % 2 == 1: # odd, hash last item twice
        newHashList.append(hash3(hashList[-1], hashList[-1]))
    return merkle(newHashList)

def hash3(a, b):
    # Reverse inputs before and after hashing
    # due to big-endian / little-endian nonsense
    a1 = a.decode('hex')[::-1]
    b1 = b.decode('hex')[::-1]
    h = hashlib.sha256(hashlib.sha256(a1 + b1).digest()).digest()
    return h[::-1].encode('hex')

Immutability

Теперь о том, зачем это нужно в Bitcoin. Я думаю, вы понимаете, что если изменить хотя бы одну транзакцию, то merkle_root также изменится. Поэтому такая структура данных позволяет обеспечить «неподделываемость» транзакций в блоке. То есть не может произойти следующей ситуации:

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

Для проверки достаточно посчитать merkle_root самостоятельно и сравнить его с тем, что записан в header блока.

SPV

Но здесь можно резонно возразить, что, во-первых, такие сложности совершенно ни к чему. Достаточно просто посчитать хэш от суммы всех транзакций в блоке txns_hash = SHA256(SHA256(sum(txns))) — он точно также изменится после любых манипуляций с транзакциями. А, во-вторых, что мешает злоумышленнику подменить merkle_root в блоке? На второй вопрос отвечу сразу: на самом деле в блоке вообще нельзя ничего изменить, потому что блок тут же станет невалидным (это вы поймете после прочтения следующей главы Bitcoin in a nutshell — Mining).

А дерево Меркла нужно на самом деле для того, чтобы иметь возможность создавать SPV nodes (Simplified Payment Verification). Такие ноды синхронизируют только заголовки блоков, без самих транзакций. В результате блокчейн занимает на порядок меньше места (для красоты возьмем высоту в 500.000 блоков, размер header фиксирован — 80 байт):

500.000 * 80 / 1024 / 1024 ≈ 40 Мб

Такой блокчейн уже можно без проблем уместить на телефоне, планшете или каком-нибудь IoT. Что в перспективе должно дать большую децентрализацию, безопасность сети и так далее.

Суть упрощенной верификации платежей в следующем: пусть у вас есть SPV нода. У меня же есть весь блокчейн целиком и мне нужно вас убедить, что какая-нибудь транзакция действительно была (на картинке это транзакция K). В этом случае, мне достаточно всего лишь предоставить вам несколько хэшей: H_L, H_IJ, H_MNOP, H_ABCDEFGH, они еще называются authentication path.

После чего вы сначала считаете H_K = SHA256(SHA256(K)), потом H_KL = SHA256(SHA256(H_K + H_L)) и так до самого верха. Если в итоге вы находите у себя блок с таким же merkle_root, то факт существования транзакции считается подтвержденным.

BTW Ральф Меркл даже запатентовал свою структуру данных, о чем свидетельствует патент US4309569 A.

Timestamp

Еще один интересный вопрос. Представим, что где-то в сети появился появился новый блок и ноды начинают передавать его друг-другу. Каждая нода должна убедиться в том, что блок корректен. Для этого она:

  • проверяет синтаксис и структуру блока
  • проверяет на валидность каждую транзакцию в блоке
  • хэширует транзакции и сравнивает merkle root
  • проверяет несколько критериев, связанных с майнингом, и так далее

Но как можно проверить timestamp? Понятно, что время на разных компьютерах может различаться, так что даже если у нового блока timestamp отличается от вашего текущего времени на час вперед, это еще не значит, что блок «неправильный», может у майнера просто часы спешат.

Поэтому для проверки timestamp на валидность было придумано два критерия. Во-первых, он должен быть больше, чем среднее арифметическое timestamp-ов предыдущих 11 блоков. Это делается для того, чтобы не получилось так, что блок #123 вышел 12 марта 2011 года, а #124 — 13 февраля 1984. Но в тоже время допускается некоторая погрешность.

Во-вторых, timestamp должен быть меньше чем network adjusted time. То есть нода, при получении нового блока, интересуется текущим временем у своих «соседей» по сети, считает среднее арифметическое и если block timestamp меньше получившегося значения + 2 часа, то все в порядке.

BTW как вы видите, timestamp нового блока может оказаться даже меньше, чем timestamp более раннего блока. Это не такая уж и редкость, например #145045, #145046 и #145047.

145044: 2011-09-12 15:46:39     
145045: 2011-09-12 16:05:07 
145046: 2011-09-12 16:00:05 // ~5 minutes before prior block
145047: 2011-09-12 15:53:36 // ~7 & ~12 minutes before 2 prior blocks
145048: 2011-09-12 16:04:06 // after 2 prior blocks but still before 145045

Raw block

Если у вас до сих остались какие-то вопросы по структуре блока, то предлагаю вам посмотреть на них в «сыром» виде. Самый очевидный способ это сделать — запустить на пару часов bitcoind --daemon, а потом исследовать уже скачанные блоки. Но, во-первых, не у всех есть время / желание синхронизировать блокчейн. Во-вторых, в Bitcoin блоки хранятся в крайне специфической базе данных LevelDB, еще и довольно странным образом. А так как книга расчитана не только на опытных разработчиков, то я пойду уже проверенным путем и снова использую протокол в его первозданном виде.

Для получения блока отправим сообщение getdata, в котором укажем type : MSG_BLOCK и hash : 000000000003ba27aa200b1cecaad478d2b00432346c3f1f3986da1afd33e506 — это хэш блока #100.000. Весь код целиком можете посмотреть здесь.

def getdataMessage():
    block_hash = '000000000003ba27aa200b1cecaad478d2b00432346c3f1f3986da1afd33e506'

    count = struct.pack("<B", 1)
    inventory = struct.pack("<L", 2) # type : MSG_BLOCK
    inventory += block_hash.decode('hex')[::-1]

    return count + inventory

Links

Разогнать блокчейн до 710 000 транзакций в секунду: обзор алгоритма Proof of History 


Одна из проблем криптовалют — синхронизация узлов. Чтобы исполнить транзакции, узлы должны записать блок в блокчейн. Для этого они общаются и достигают консенсуса.

Этот процесс занимает время. Пропускная способность биткоина — 4 транзакции в секунду (TPS), блокчейна EOS — менее 50 TPS. При этом платежная система Visa обрабатывает 65 000 TPS.

Во время тестов Solana показала 60 000 TPS. По подсчетам разработчиков, теоретическая пропускная способность сети может достигать 710 000 TPS. Проект достиг таких показателей благодаря собственным решениям: Proof of History, Tower Byzantine Fault Tolerance (TBFT), Turbine, Gulfstream, Sealevel, Pipeline, Cloudbreak и Archivers.

Рассказываем, как работает Proof of History и почему большая пропускная способность блокчейна — это важно.

О проекте Solana

Solana — американский проект, разрабатывающий масштабируемый блокчейн-протокол для создания децентрализованных приложений и смарт-контрактов.

В команде Solana: бывший ведущий разработчик Qualcomm Анатолий Яковенко,  разработчик ОС BREW Грег Фицжеральд и доктор наук в области физики частиц Эрик Уильямс.

Проект основан в 2017 году. В 2018 году команда запустила альфа-версию тестовой сети, в 2019 — получила $20 млн венчурных инвестиций.

Solana использует utility-токен SOL для награждения узлов, поддерживающих работу сети.

Проект анонсировал голландский аукцион токенов SOL. Он состоится  24 марта в 08:00 (МСК) на площадке Coinlist. Начальная цена токена SOL — $4. Делать ставки можно с 17 марта.

Зарегистрироваться на торги можно на странице аукциона. Пользователи могут вернуть токены по гарантии в течение 12 месяцев. В таком случае Solana выкупит их за 90% от итоговой цены аукциона.

Что такое Proof of History

Proof of History (PoH) — это алгоритм синхронизации блокчейна. В нем есть внутренние часы, которые показывают одинаковое время на всех узлах.

Узлы сети работают по расписанию. Благодаря синхронизации они могут проверить время между операциями в блокчейне. 

Для чего нужна синхронизация узлов

Чтобы достигнуть консенсуса, узлы должны обменяться информацией — синхронизироваться. Это может занимать до 40 секунд в зависимости от скорости передачи данных между узлами.

Скорость синхронизации влияет на пропускную способность блокчейна. Чем она быстрее, тем больше транзакций в секунду обрабатывает сеть.

Представьте: вы командуете сухопутными войсками и по очереди отдаете приказ генералам, они доносят его солдатам. Если вы можете докричаться до генералов, то синхронизация происходит быстро. Но если вы отправляете приказы голубями, синхронизация будет медленной. Пока танковые войска дождутся голубя, кавалерия выполнит приказ.

Так происходит и в криптовалюте: 

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

Майнеры, которые не знают о найденном блоке, продолжают майнинг. В результате майнеры могут одновременно добыть два блока. Один из блоков станет отвергнутым (orphan-блок). 

Orphan-блоки разделяют блокчейн на две ветки. Это дает шанс провести двойное расходование и другие атаки.

В биткоине узлы ищут блок 10 минут и синхронизируются за 15 секунд. Orphan-блоки появляются редко — раз в 10 000 блоков. Если ускорить добычу блоков, не затрагивая время синхронизации, orphan-блоки будут появляться чаще. 

Разработчики Ethereum увеличили скорость добычи блока до 13 секунд, и майнеры регулярно добывают отвергнутые блоки.

Проблема синхронизации по времени

Чтобы использовать синхронизацию по времени, нужны часы. В криптовалютах есть свои часы и внутреннее время — timestamp. Оно не точное, потому что нет центральных часов, с которыми можно свериться.

Узел не может доверять timestamp, поэтому усредняет это значение: 

  1. Запрашивает локальное время у других узлов.
  2. Считает медиану выборки по времени.
  3. Подстраивает по этой медиане свое время. 

Такая синхронизация неидеальна: если ориентироваться на timestamp, новый блок может появиться раньше предыдущего.

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

Чтобы решить проблему синхронизации по времени, Solana изобрела децентрализованные часы — протокол  Proof of History. 

Как работает Proof of History

Proof of History работает как песочные часы. Песчинки в часах связаны нитью, словно бисер. Песок перетекает из верхней чаши в нижнюю.

Песчинки падают с разной скоростью, но мы можем посчитать количество песчинок в нижней чаше:

  1. Покрасим одну песчинку в зеленый цвет, другую — в красный, остальные красить не будем. 
  2. Сначала упадет зеленая песчинка, потом несколько бесцветных и красная. 
  3. Мы не знаем интервал падения песчинок в секундах, но знаем, сколько бесцветных песчинок упало между зеленой и красной. Мы можем сказать: красная песчинка упала через N песчинок после зеленой.
  4. Если по нитке отмотать цепочку песчинок до начала, то узнаем, что зеленая песчинка — X по счету. Красная песчинка — X + N. 

Proof of History — это хеш-функция с подтвержденным временем выполнения. Если циклично считать PoH и использовать результат для следующего расчета, на выходе получится цепочка связанных хешей — нить с песчинками.

Как работает Proof of History. Валидаторы считают PoH и записывают результаты: хеш PoH и порядковый номер хеширования — count. По этим результатам можно проверить, что лидер считал каждый PoH. Также можно доказать последовательность получения хешей: хеш Y был получен после хеша X и перед хешем Z.

Песчинки Proof of History можно красить — записывать в них события. Если считать хеши от первого значения PoH, можно определить относительное время события. Валидаторы проверяют порядок хешей PoH и узнают хронологический порядок транзакций.

Как PoH увеличивает пропускную способность блокчейна и решает проблему отвергнутых блоков

Solana создает расписание для узлов-валидаторов (Leader Schedule), чтобы синхронизировать их действия. Время в расписании измеряется в хешах Proof of History. Вот как это работает:

  1. Первый валидатор становится лидером на период от 0 до 1000 хешей PoH.
  2. Он считает хеш Proof of History, проверяет транзакцию и ставит на нее штамп. В него входит публичный ключ, значение и порядковый номер хеша PoH. 
  3. Лидер отправляет транзакцию двум валидаторам. Они проверяют ее и передают другим валидаторам.
  4. Период лидерства следующего валидатора — от 1001 до 2000 хешей. Валидатор считает время в Proof of History и знает, когда станет лидером. 

Алгоритм ротации лидеров снижает время добычи блока до 0.4 сек и решает проблему orphan-блоков. Валидаторы становятся лидерами по расписанию. Их рабочие смены (slot) не пересекаются: валидатор не создаст отвергнутый блок в чужую смену.

Опыт Solana: масштабирование без шардинга

Разработчики Ethereum планируют решить проблему масштабирования при помощи шардинга: сеть разбивают на несколько подсетей (шардов) с отдельным блокчейном и узлами. У этого решения есть недостатки: 

Solana масштабируется без шардинга благодаря таким разработкам:

  • протоколы передачи транзакций Turbine и Gulfstream;
  • распределенное хранение данных у архиваторов;
  • оптимизация записи транзакций Cloudbreak.

Turbine и Gulfstream разбивают транзакции на части (batch): 

  1. Лидер передает части транзакции двум случайным валидаторам. Это быстрее, чем передавать узлам полные блоки.
  2. Валидаторы обмениваются этими частями и так собирают полную транзакцию.

Обмен частями транзакций

Архиваторы — отдельные узлы, которые записывают batch от случайных валидаторов. Протокол архивации распределяет блокчейн между архиваторами. 

Cloudbreak оптимизирует многопоточную запись на диск: архиваторы быстро записывают небольшие фрагменты данных.

Если разбить блокчейн размером 1 гигабайт между сотней архиваторов, общий объем блокчейна в сети составит 1.33 ГБ: 1 гигабайт блокчейна и 0.33 гигабайта проверочных кодов. В биткоине узлы хранят по 1 гигабайту блокчейна, в сумме — 100 гигабайт.

Зачем блокчейну высокая пропускная способность

Во время тестов 50 узлов в сети Solana обработали 191 000 транзакций в секунду на пике нагрузки. Средняя пропускная способность сети — 60 000 TPS.

Высокая пропускная способность нужна ресурсоемким системам и приложениям: биржам, рекламным площадкам и файловым хранилищам.

Практический пример — работа провайдеров 5G. У вышек 5G малый радиус действия. Для вышек со скоростью 20 Мбит/с — меньше 200 метров.

Провайдерам нужно много вышек 5G. С ростом количества вышек станет сложно следить за верификацией абонентов и считать оплату за интернет. 

«Провайдерам нужно будет обрабатывать тысячи технических запросов каждой новой вышки. Блокчейн поможет автоматизировать учет трафика, посчитать оплату и верифицировать пользователей», — комментирует разработчик Solana

По подсчетам проекта Solana, владельцы смартфонов присылают вышкам 50 тысяч технических запросов в секунду. Solana сможет обработать такое количество транзакций и упростить провайдерам процессы верификации и оплаты. Благодаря этому обслуживание 5G будет дешевле, а тарифы — доступней.

Выводы

Если криптовалюты хотят конкурировать с централизованными системами, им нужно  повысить пропускную способность. А для этого — ускорить синхронизацию узлов.

Централизованные системы используют внутренние часы. Google синхронизирует базы данных по атомным часам, Яндекс — по центральному NTP-серверу. Proof of History — их децентрализованный аналог. 

Возможно, в будущем централизованные проекты будут использовать Proof of History как более простой способ синхронизации действий: переключения режимов работы, резервного копирования баз данных и распределенных расчетов.

Подписывайтесь на новости ForkLog в Telegram: ForkLog Feed — вся лента новостей, ForkLog — самые важные новости и опросы.

Нашли ошибку в тексте? Выделите ее и нажмите CTRL+ENTER

Математические основы биткойн-блокчейна / Блог компании Bitfury Group / Хабр

Сегодня биткойн продолжает набирать популярность, а индустрия разрабатывать все новые приложения для работы с криптовалютой. Одной из причин такой популярности является строгая математическая база, на которой строится биткойн.

Благодаря этому система функционирует в условиях полного отсутствия доверия между участниками сети, исключая воздействие человеческого фактора.

Поэтому в сегодняшней статье мы бы хотели поговорить о математических основах биткойн-блокчейна — эллиптических кривых, ECDSA и ключах.

/ Изображение Hernán Piñera CC BY

Фундаментальной частью биткойна являются криптографические алгоритмы. В частности, алгоритм ECDSA — Elliptic Curve Digital Signature Algorithm, который использует эллиптические кривые (elliptic curve) и конечные поля (finite field) для подписи данных, чтобы третья сторона могла подтвердить аутентичность подписи, исключив возможность её подделки. В ECDSA для подписи и верификации используются разные процедуры, состоящие из нескольких арифметических операций.

Эллиптические кривые

Эллиптическая кривая над полем K — это кубическая кривая над алгебраическим замыканием поля K, задаваемая уравнением третьей степени с коэффициентами из поля K и «точкой на бесконечности». Одной из форм эллиптических кривых являются кривые Вейерштрасса.

y² = x³ + ax + b

Для коэффициентов a = 0 и b = 7 (используемых в биткойне), график функции принимает следующий вид:


Эллиптическая кривая

Эллиптические кривые имеют несколько интересных свойств, например, невертикальная линия, пересекающая две некасательные точки на кривой, пересечет третью точку на кривой. Суммой двух точек на кривой P + Q называется точка R, которая является отражением точки -R (построенной путем продолжения прямой (P; Q) до пересечения с кривой) относительно оси X.


Сумма двух точек на кривой (источник)

Если же провести прямую через две точки, имеющие координаты вида P (a, b) и Q (a, -b), то она будет параллельна оси ординат. В этом случае не будет третьей точки пересечения. Чтобы решить эту проблему, вводится так называемая точка на бесконечности (point of infinity), обозначаемая как O. Поэтому, если пересечение отсутствует, уравнение принимает следующий вид P + Q = O.

Если мы хотим сложить точку саму с собой (удвоить её), то в этом случае просто проводится касательная к точке Q. Полученная точка пересечения отражается симметрично относительно оси X.


Удвоение точки (источник)

Эти операции позволяют провести скалярное умножение точки R = k*P, складывая точку P саму с собой k раз. Однако отметим, что для работы с большими числами используются более быстрые методы.

Эллиптическая кривая над конечным полем

В эллиптической криптографии (ECC) используется такая же кривая, только рассматриваемая над некоторым конечным полем. Конечное поле в контексте ECC можно представить как предопределенный набор положительных чисел, в котором должен оказываться результат каждого вычисления.

y² = x³ + ax + b (mod p)

Например, 9 mod 7 = 2. Здесь мы имеем конечное поле от 0 до 6, и все операции по модулю 7, над каким бы числом они ни осуществлялись, дадут результат, попадающий в этот диапазон.

Все названные выше свойства (сложение, умножение, точка в бесконечности) для такой функции остаются в силе, хотя график этой кривой не будет походить на эллиптическую кривую. Эллиптическая кривая биткойна, y² = x³ + 7, определенная на конечном поле по модулю 67, выглядит следующим образом:


Эллиптическая кривая биткойна, определенная на конечном поле по модулю 67 (источник)

Это множество точек, в которых все значения х и у представляют собой целые числа между 0 и 66. Прямые линии, нарисованные на этом графике, теперь будут как бы «оборачиваться» вокруг поля, как только достигнут барьера 67, и продолжатся с другого его конца, сохраняя прежний наклон, но со сдвигом. Например, сложение точек (2, 22) и (6, 25) в этом конкретном случае выглядит так:


Сложение точек (2, 22) и (6, 25) (источник)

Если хотите посмотреть, как выглядят другие эллиптические кривые, то поэкспериментировать можно на этом сайте.

ECDSA в биткойне

В протоколе биткойна зафиксирован набор параметров для эллиптической кривой и её конечного поля, чтобы каждый пользователь использовал строго определенный набор уравнений. Среди зафиксированных параметров выделяют уравнение кривой (equation), значение модуля поля (prime modulo), базовую точку на кривой (base point) и порядок базовой точки (order). О вычислении порядка базовой точки вы можете почитать здесь. Этот параметр подбирается специально и является очень большим простым числом.

В случае биткойна используются следующие значения:

Уравнение эллиптической кривой: y² = x³ + 7

Простой модуль: 2256— 232 — 29 — 28 — 27 — 26 — 24 — 1 = FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFE FFFFFC2F

Базовая точка:

04 79BE667E F9DCBBAC 55A06295 CE870B07 029BFCDB 2DCE28D9 59F2815B 16F81798 483ADA77 26A3C465 5DA4FBFC 0E1108A8 FD17B448 A6855419 9C47D08F FB10D4B8

Жирным шрифтом выделена координата X в шестнадцатеричной записи. За ней сразу следует координата Y.

Порядок: FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFE BAAEDCE6 AF48A03B BFD25E8C D0364141

Этот набор параметров для эллиптической кривой известен как secp256k1 и является частью семейства стандартов SEC (Standards for Efficient Cryptography), предлагаемых для использования в криптографии. В биткойне кривая secp256k1 используется совместно с алгоритмом цифровой подписи ECDSA (elliptic curve digital signature algorithm). В ECDSA секретный ключ — это случайное число между единицей и значением порядка. Открытый ключ формируется на основании секретного: последний умножается на значение базовой точки. Уравнение имеет следующий вид:

Открытый ключ = секретный ключ * G

Это показывает, что максимальное количество секретных ключей (следовательно, биткойн-адресов) — конечно, и равняется порядку. Однако порядок является невероятно большим числом, так что случайно или намеренно подобрать секретный ключ другого пользователя нереально.

Вычисление открытого ключа выполняется с помощью тех же операций удвоения и сложения точек. Это тривиальная задача, которую обычный персональный компьютер или смартфон решает за миллисекунды. А вот обратная задача (получение секретного ключа по публичному) — является проблемой дискретного логарифмирования, которая считается вычислительно сложной (хотя строгого доказательства этому факту нет). Лучшие известные алгоритмы ее решения, вроде ро Полларда, имеют экспоненциальную сложность. Для secp256k1, чтобы решить задачу, нужно порядка 2128 операций, что потребует времени вычисления на обычном компьютере, сопоставимого со временем существования Вселенной.

Когда пара секретный/публичный ключ получена, её можно использовать для подписи данных. Эти данные могут быть любой длины. Обычно первым шагом выполняется хеширование данных с целью получения уникального значения с числом битов, равным битности порядка кривой (256). После хеширования, алгоритм подписи данных z выглядит следующим образом. Здесь, G — базовая точка, n — порядок, а d — секретный ключ.

  • Выбирается некоторое целое k в пределах от 1 до n-1
  • Рассчитывается точка (х, у) = k * G с использованием скалярного умножения
  • Находится r = х mod n. Если r = 0, то возврат к шагу 1
  • Находится s = (z + r * d) / k mod n. Если s = 0, то возврат к шагу 1
  • Полученная пара (r, s) является нашей подписью

После получения данных и подписи к ним, третья сторона, зная публичный ключ, может их верифицировать. Шаги для проверки подписи такие (Q — открытый ключ):

  • Проверка, что и r, и s находятся в диапазоне от 1 до n-1
  • Рассчитывается w = s-1 mod n
  • Рассчитывается u = z * w mod n
  • Рассчитывается v = r * w mod n
  • Рассчитывается точка (x, y) = uG + vQ
  • Если r = x mod n, то подпись верна, иначе — недействительна

В самом деле,

uG + vQ = u + vdG = (u + vd)G = (zs-1 + rds-1)G = (z + rd) s-1G = kG

Последнее равенство использует определение s на этапе создания подписи.

Безопасность ECDSA связана со сложностью задачи поиска секретного ключа, описанной выше. Помимо этого, безопасность исходной схемы зависит от «случайности» выбора k при создании подписи. Если одно и то же значение k использовать более одного раза, то из подписей можно извлечь секретный ключ, что и произошло с PlayStation 3. Поэтому современные реализации ECDSA, в том числе используемые в большинстве биткойн-кошельков, генерируют k детерминировано на основе секретного ключа и подписываемого сообщения.

P.S. Bitfury Group Russia в Vk и Fb.

Простое введение в алгоритмы цепочки блоков | Зинат Али

Zeenat Ali

Блокчейн — это открытый, децентрализованный, распределенный , публичный цифровой реестр и , в котором транзакции записываются между людьми на многих компьютерах, так что запись не может быть изменена задним числом без изменения всех последующих блоков и Консенсус сети. Блокчейн считается растущей цепочкой записей, связанных силой криптографии .

Криптография включает письменный код, требующий авторизованного декодирования и шифрования. Блокчейн управляется сетью, которая придерживается протоколов для узловой связи и проверки новых блоков. Майнеры проверяют транзакции, которые будут записаны в блокчейн. Для майнинга требуется применение алгоритма для проверки и извлечения данных. Криптовалюта — это цифровая валюта, в которой шифрование используется для регулирования и генерации денежных единиц.Криптовалюта использует криптографию для обеспечения безопасности и технологию блокчейн для записи транзакций. Этот механизм от добавления в цепочку записей до проверки транзакций в целом упоминается как алгоритм блокчейна .

В блокчейне каждый узел в сети приводит к одному и тому же выводу, каждый обновляет запись независимо, причем наиболее популярной записью является де-факто официальная запись вместо основной копии. Транзакции транслируются, и каждый узел создает свою собственную обновленную версию событий.Это делает технологию блокчейн уникальной — она ​​представляет собой инновации в записи и распространении информации, которые устраняют необходимость в третьей стороне для облегчения цифровых отношений.

Технология блокчейн — это комбинация технологий, применяемых различными новыми способами. Он построен на платформе с использованием протоколов, он находится в одноранговой сети, которая представляет собой систему записи и использует криптографию с закрытым ключом для идентификации. Алгоритм — это часть протокола.

В результате получается система транзакционных взаимодействий, для которых не требуется доверенная третья сторона.Работа по защите цифровых отношений является неотъемлемой частью — обеспечивается надежной, простой, но сложной сетевой архитектурой самой технологии блокчейн.

Среди наиболее популярных и успешных вариантов использования Биткойн — это криптовалюта, которая использует алгоритм Consensus network , называемый Proof-of-Work . Биткойн был первым выпуском новой системы электронных денег, которая использует одноранговую сеть для предотвращения двойных расходов и проверки транзакций. Он полностью децентрализован, без какой-либо центральной власти.Сатоши Накамото, создатель цепочки блоков биткойнов, объявил о выпуске биткойнов 9 января 2009 года.

Алгоритмы могут направлять действия человека и влиять на информацию, которая считается правдивой. В отличие от других работ по алгоритмам в социотехнических системах, мы исследуем более точное использование алгоритмов блокчейна, а также важность изучения алгоритмических систем, которые обеспечивают работу всей технологии.

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

Исследования показывают, что члены общества предпочитают авторитет алгоритмов авторитету традиционных институтов, которые они считали ненадежными. Однако исследования также признали необходимость согласования алгоритмического авторитета с человеческим суждением.

По сути, тот, кто контролирует алгоритмы, контролирует судьбу.

Разработчики блокчейнов работают над тем, чтобы каждый человек контролировал свои собственные алгоритмы и личные данные, связанные с идентификацией. Алгоритмы, изучающие наше поведение, знают нас намного лучше, чем мы сами.

Алгоритмы , которые понимают, что каждый из нас действует, покупает, общается и т. Д. сегодня контролируются сторонними компаниями , такими как поисковые системы или компании социальных сетей, такие как Google и Facebook.

  1. Наша идентификационная информация , связанная с этими алгоритмами , не находится под нашим индивидуальным контролем , а скорее копируется и передается крупным и мелким поставщикам услуг, компаниям и государственным учреждениям, которые часто не защищают данные должным образом.
  2. Миллиарды записей личной информации скомпрометированы из-за утечки данных в таких учреждениях, как Equifax, Facebook, Yahoo !, банки, телефонные компании, правительственные учреждения США, такие как IRS, государственные избирательные агентства и многие другие.
  3. Как известно, наши личные данные продавались и перепродавались бесчисленное количество раз различным компаниям и поставщикам. Они варьируются от национального населения до обычных преступников.
  4. Правительства больше не могут угнаться за с потоком информации, поступающей к ним вместе с быстрыми темпами технологических изменений. Лучшее, что они могут сделать, — это служить хранителем статус-кво, но у многих правительств это не получается.
  5. Крупные технологические компании начали управлять большей частью технологической эволюции в наших обществах.
  6. Тот, кто контролирует алгоритмы, будет обладать большой властью.

На данный момент обещание революции блокчейнов и его демократизированный, децентрализованный контроль являются приемлемым вариантом, однако для его экономического внедрения потребуется время. Будущее на основе блокчейнов, в котором мы владеем собственными идентификационными данными, дает нам возможность контролировать наши собственные алгоритмы и уменьшать контроль над данными в существующих экономических институтах.

Алгоритм — это набор инструкций, которые производят вывод или результат.Это может быть простой сценарий или сложная программа. Порядок инструкций важен, и алгоритм определяет порядок. Он сообщает системе, что делать, чтобы достичь желаемого результата. Он может не знать заранее, каков результат, но он знает, что он должен иметь результаты.

В блокчейне алгоритм:

  • Проверяет подписи
  • Подтверждает балансы
  • Определяет, действителен ли блок
  • Определяет, как майнеры проверяют блок
  • Устанавливает процедуру для сообщения блоку о перемещении
  • Устанавливает процедура для создания новых монет
  • Сообщает системе, как определять консенсус

Алгоритмы сообщают майнерам, как проводить проверку блока.Они устанавливают условия, как это делают протоколы, но инструкции являются фундаментальными, и есть желаемый результат: обрабатывать транзакции, определять, какие блоки входят в цепочку, и обеспечивать консенсус относительно того, какая цепочка является правильной. Для достижения этих целей алгоритмы используют базовый протокол.

Биткойн и Ethereum считаются протоколами. Они устанавливают основные правила, настраивают «двигатели» и определяют, кто что и как делает. Затем мы, пользователи, реализуем алгоритмы для транзакций с монетами, выполнения смарт-контрактов и создания новых бизнес-моделей.Алгоритмы — вот что делает протоколы полезными.

Есть различие между состоянием и действием. Мы не можем изменить правила, но мы можем создать серию действий, инструкций и процессов, специфичных для наших бизнес-моделей.

С момента внедрения блокчейна и криптовалюты Биткойн в 2009 году Сатоши Накамото, было создано множество алгоритмов. Постоянно разрабатываются дополнительные алгоритмы, которые также нацелены на устранение ошибок существующих алгоритмов, таких как система алгоритмов Proof-of-Work (PoW).Proof-of-Work и Proof-of-Stake — это существующие алгоритмы Consensus . Они позволяют всем узлам блокчейна соглашаться, а также предотвращают двойное расходование — атаку, которая пытается потратить одни и те же монеты более одного раза. Вот несколько алгоритмов.

АЛГОРИТМЫ КОНСЕНСУСА

Алгоритмы консенсуса сложны, но помогают при покупке монет или запуске узла. Алгоритмы консенсуса обеспечивают надежность в сетях, включающих несколько узлов, гарантируя, что все узлы соответствуют указанному правилу или действию.Узлы определяют консенсус в биткойнах, а не майнеры. Консенсус определяется цепочкой с наибольшим количеством работы. Если вы форкнете и измените POW, у вас не будет мощности для майнинга, чтобы защитить его. Узлы принимают транзакции, проверяют транзакции, реплицируют транзакции, проверяют блоки, реплицируют блоки, обслуживают цепочку блоков и сохраняют цепочку блоков. Узлы даже определяют алгоритм Proof-of-Work, который должны использовать майнеры.

Протокол обслуживают узлы, а не майнеры.

Внедрение блокчейна привело к эволюции алгоритмов консенсуса, и было создано множество других алгоритмов, направленных на устранение ошибок первой в истории системы алгоритмов Proof-of-Work (PoW).

АЛГОРИТМЫ МАЙНИНГА

Интеллектуальный анализ данных состоит из трех основных компонентов: Кластеризация или классификация, правила ассоциации и анализ последовательности .

Кластеризация / классификация — это анализ набора данных и создание набора правил группирования, которые можно использовать для классификации будущих данных. Правило ассоциации — это правило, которое подразумевает определенные отношения ассоциации между набором объектов в базе данных. Анализ последовательности — это анализ последовательностей последовательностей.Предлагается множество алгоритмов для реализации таких аспектов интеллектуального анализа данных.

В блокчейне майнеры используют компьютеры, чтобы многократно и очень быстро угадывать ответы на головоломки, пока один из них не выиграет. В частности, майнеры будут запускать уникальные метаданные заголовка блока (включая временную метку и версию программного обеспечения) с помощью хеш-функции, которая возвращает случайную строку чисел фиксированной длины, изменяя при этом значение nonce для воздействия на хеш-значение.

Если майнер находит хэш, который соответствует цели, майнер будет награжден в криптовалюте, и блок будет транслироваться по сети для каждого узла для проверки и добавления в свою собственную копию реестра.Если майнер B найдет хэш, майнер A остановит работу над текущим блоком и повторит процесс для следующего блока.

Примерно каждые 12–15 секунд майнер находит блок. Если майнер начинает решать головоломку быстрее или медленнее, алгоритм автоматически настраивается так, чтобы майнеры могли оставаться в 12–15-секундном времени решения.

АЛГОРИТМЫ ЦЕПИ ОТСЛЕЖИВАНИЯ

Отслеживаемость доказывает происхождение и методы, лежащие в основе транзакции, при сборе дополнительных данных для улучшения показателей внутренних процессов и планирования деятельности каждого узла в цепочке поставок.Блокчейн воздействует на аналитику больших данных, поскольку данные транзакций — это потоковые данные и многомерные данные из распределенных вычислительных сетей. Основная цель алгоритмов цепочки отслеживания — быстрое принятие решений по отслеживаемости. Соответственно, такая операция порождает неактуальные проблемы с данными и плохо оптимизирует отслеживаемость в блокчейне. Следовательно, искусственный интеллект алгоритма добычи блокчейна, как и алгоритм цепочки прослеживаемости, работает быстрее, чем алгоритм консенсуса, из-за механизма вывода.

Сегодня компании не могут постоянно отслеживать элементы, потому что у них хранится информация в хранилищах, соответствующих повторяющимся точкам. С помощью блокчейна можно постоянно отслеживать путь транзакции. Новый подход под названием Нечеткие когнитивные карты Такаги – Сугено применяет алгоритм цепочки прослеживаемости. Оценивается численный пример предложенного алгоритма в майнинге блокчейнов. Целевые функции для оптимизированных вычислений решений описываются как метод ограничения узлов-участников.Таким образом, вклад позволяет сократить затраты на добычу полезных ископаемых, пока обрабатывается цепочка отслеживания.

Отслеживаемость цепочки блоков способствует и улучшает координацию цепочки поставок, предоставляя более подробную информацию о положении и состоянии транзакций, чтобы узел мог использовать эту информацию в качестве входных данных для своей деятельности по планированию. Отслеживаемость обеспечивает строгий контроль жизненного цикла транзакции, имея возможность отслеживать каждый цифровой актив, перемещаемый по отношению к цепочке блоков.

Чтобы разработать полную систему прослеживаемости, транзакция должна перемещаться в цепочке блоков, что дает каждому элементу, который связан с транзакцией, виртуальную идентификацию.Следовательно, объекты должны быть связаны с датчиками или тегом, который может хранить информацию об элементах и ​​передавать их на платформу. Например, QR-коды, RFID или беспроводные сенсорные сети.

Алгоритмы прослеживаемости состоят из трех ключевых подпроцессов:

  1. Идентификация и маркировка продуктов для облегчения идентификации продукта.
  2. Сбор и запись данных: возможности сканирования с электронным информационным потоком для оптимизации поиска данных.
  3. Связи и коммуникация для оптимизации обмена данными между партнерами по цепочке поставок и протоколами.

Функция отметки времени обеспечивает точность информации, хранящейся в реестре. Сотрудничество между традиционными инструментами отслеживания и блокчейном гарантирует непрерывный мониторинг транзакций по всей цепочке поставок, выступая в качестве важного барьера на пути к плохо работающим рынкам.

BYZANTINE FAULT TOLERANCE (BFT)

Byzantine Fault Tolerance (BFT) определяет надежность распределенных вычислительных систем, в которых компоненты могут выходить из строя и приводить к неточной информации.Достижение BFT — одна из самых сложных задач, которую решает технология блокчейн. BFT означает, что два узла могут безопасно обмениваться данными по сети, зная, что они отображают одни и те же данные.

В «Византийский сбой» такой компонент, как сервер, может непоследовательно выходить из строя, каждый раз проявляя разные симптомы. В этом случае активные пользователи должны согласовать стратегию, чтобы избежать полного отказа системы. BFT также упоминается как совпадение источников, лавина ошибок, проблема византийских генералов и проблема византийского соглашения.

По сути, без BFT узел может передавать ложную информацию в сеть, что делает информацию в цепочке блоков ненадежной. Внедрение BFT гарантирует, что все возможные случаи будут предотвращены с помощью Practical Byzantine Fault Tolerance (PBFT) и Федеративного византийского соглашения (FBA) среди некоторых других.

Проекты, в которых успешно реализован алгоритм BFT, включают Hyperledger, Stellar, Dispatch и Ripple.

Распределенные реестры, а именно технология блокчейн, в корне изменили парадигмы вычислений.Существует множество типов алгоритмов на выбор в зависимости от приложения, которое вы хотите развернуть. Публичный блокчейн требует устойчивого консенсуса среди множества неизвестных и ненадежных участников. Для начала задайте себе следующие вопросы:

  1. Каков масштаб проекта?
  2. Является ли ваш блокчейн общедоступным или разрешенным? (Для разрешенных или консорциумных блокчейн-проектов могут потребоваться более быстрые транзакции)
  3. Каковы ваши требования к производительности?
  4. Монетная или не монетная?

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

Блокчейны, ориентированные на монеты , позволяют быстро осуществлять денежные переводы в любую точку мира в децентрализованной системе. Примеры включают Bitcoin, Bitcoin Cash, Litecoin, Monero и Ripple. Платформы смарт-контрактов позволяют создавать смарт-контракты.Контракт — это скрипт, который выполняется и может взаимодействовать с цепочкой блоков, на которой он размещен, для хранения данных в цепочке блоков. Эти платформы позволяют создавать децентрализованные приложения (DApps), которые могут взаимодействовать с этими контрактами, чтобы предлагать пользователям функции или услуги. Например, Ethereum, NEO, Hyperledger, Lisk и Ark. Токены, основанные на платформах смарт-контрактов, используются DApps для предоставления пользователю функции или услуги.

Некоторые проекты также включают использование одного или нескольких токенов для конкретного приложения.Это отдельные проекты, которые направлены на решение существующей проблемы с помощью технологии блокчейн или технологии, производной от нее. Примеры включают IOTA.

Вы также должны определить, будет ли ваше приложение находиться в публичной или частной сети . Это решение зависит от проверки, необходимой вам при создании транзакций, контрактов или активов. Определяющий фактор обычно сводится к безопасности. Поврежденная цепочка может потребовать использования вилки для обнаружения ошибок. Технология блокчейн устраняет целые категории атак на безопасность.

  1. Злоумышленники не могут легко изменить содержимое распределенного реестра (неизменяемость) .
  2. Нарушение (отказ в обслуживании) — злоумышленники не могут легко нарушить поток транзакций.
  3. Влияние на порядок транзакции (Справедливость порядка транзакции) — Злоумышленники не могут несправедливо влиять на согласованное сообществом порядок транзакций.

Справедливый порядок транзакций позволяет разрабатывать распределенные приложения, в которых участники соревнуются за то, чтобы их транзакции были записаны первыми.Сегодня программное обеспечение обычно размещается на серверах, а серверы централизованно управляются отдельными лицами или организациями. Мы доверяем этим организациям предотвратить перечисленные выше атаки. Технология распределенного реестра (DLT), а именно технология блокчейн, делает сетевые приложения более безопасными, предотвращая успешное проведение этих атак отдельными лицами (или даже небольшими группами лиц).

Технология Blockchain может быть реализована с использованием алгоритма одной из нескольких категорий различных алгоритмов консенсуса.Однако не все алгоритмы одинаково защищают от перечисленных выше атак. Кроме того, некоторые алгоритмы менее рентабельны, в то время как другие имеют ограничения по полосе пропускания и задержке.

БЛОКЧЕЙН (НЕ ДОКАЗАТЕЛЬСТВО РАБОТЫ)

При использовании в разрешенных сетях (сетях, где все одноранговые узлы известны и доверяют) части алгоритма блокчейна, требующие дорогостоящих математических операций, заменяются более простыми, но менее безопасными альтернативами. Алгоритмы блокчейна без PoW часто имеют лидера.В результате блокчейн без PoW подвержен DoS-атакам, но может представлять лучшую альтернативу демократизированным транзакциям.

БЛОКЧЕЙН (ДОКАЗАТЕЛЬСТВО РАБОТЫ)

В открытых сетях (сетях, в которых любой может участвовать в качестве однорангового узла без ограничений; одноранговые узлы являются ненадежными и потенциально неизвестными), блокчейн использует Proof-of-Work, что снижает уязвимость к DoS-атакам. , но приводит к высокой стоимости транзакции.

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

.

Что такое алгоритм консенсуса блокчейн?

Содержание

Введение

Согласованный алгоритм — это механизм, который позволяет пользователям или машинам координировать свои действия в распределенной среде. Он должен гарантировать, что все агенты в системе могут прийти к соглашению о едином источнике истины, даже если некоторые агенты терпят неудачу. Другими словами, система должна быть отказоустойчивой (см. Также: Visantine Fault Tolerance Explained ).

При централизованной настройке одна сущность имеет власть над системой.В большинстве случаев они могут вносить изменения по своему усмотрению — не существует сложной системы управления для достижения консенсуса между многими администраторами.

Но в децентрализованной системе — совсем другое дело. Предположим, мы работаем с распределенной базой данных — как достичь соглашения о том, какие записи будут добавлены?

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

Алгоритмы консенсуса и криптовалюта

В криптовалютах балансы пользователей записываются в базу данных — блокчейн. Важно, чтобы каждый (или, точнее, каждый узел) поддерживал идентичную копию базы данных. В противном случае вы скоро получите противоречивую информацию, что подорвет всю цель криптовалютной сети.

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

Сатоши Накамото, создатель Биткойна, предложил систему Proof of Work для координации участников. Вскоре мы рассмотрим, как работает PoW, а пока определим некоторые общие черты многих существующих алгоритмов консенсуса.

Во-первых, мы требуем, чтобы пользователи, которые хотят добавлять блоки (назовем их валидаторами ), предоставляли ставки . Ставка — это некая ценность, которую должен выдвинуть валидатор, чтобы удерживать его от нечестных действий.Если они обманывают, они теряют свою ставку. Примеры включают вычислительную мощность, криптовалюту или даже репутацию.

Зачем им рисковать собственными ресурсами? Ну, есть также награда . Обычно он состоит из собственной криптовалюты протокола и сборов, уплачиваемых другими пользователями, недавно созданных единиц криптовалюты или того и другого.

Последнее, что нам нужно, это прозрачность . Нам нужно уметь определять, когда кто-то обманывает.В идеале для них должно быть дорого производить блоки, но дешево для всех проверять их. Это гарантирует, что валидаторы будут проверяться обычными пользователями.

Типы алгоритмов консенсуса

Proof of Work (PoW)

Proof of Work (PoW) является крестным отцом консенсусных алгоритмов блокчейна. Впервые он был реализован в Биткойне, но реальная концепция существует уже некоторое время. В Proof of Work валидаторы (называемые майнерами ) хешируют данные, которые они хотят добавить, пока не получат конкретное решение.

Хеш — это кажущаяся случайной строка букв и цифр, которая создается, когда вы обрабатываете данные с помощью хеш-функции. Но если вы снова пропустите через него те же данные, вы всегда получите тот же результат. Но измените хотя бы одну деталь, и ваш хеш будет совершенно другим.

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

В Proof of Work протокол устанавливает условия того, что делает блок действительным. Например, можно сказать, что только блок, хэш которого начинается с 00, будет действительным . Единственный способ для майнера создать тот, который соответствует этой комбинации, — это ввести грубую силу. Они могут настроить параметр в своих данных, чтобы получать разные результаты для каждого предположения, пока не получат правильный хэш.

Для основных блокчейнов планка установлена ​​невероятно высоко. Чтобы конкурировать с другими майнерами, вам понадобится склад, полный специального оборудования для хеширования (ASIC), чтобы иметь возможность произвести действительный блок.

Ваша ставка при майнинге — это стоимость этих машин и электричество, необходимое для их работы. ASIC созданы для одной цели, поэтому они не используются в приложениях, кроме майнинга криптовалюты. Ваш единственный способ окупить свои первоначальные инвестиции — это майнить, что дает значительную награду, если вы успешно добавите новый блок в цепочку блоков.

Для сети просто проверить, действительно ли вы создали правильный блок. Даже если вы испробовали триллионы комбинаций, чтобы получить правильный хеш, им просто нужно один раз пропустить ваши данные через функцию.Если из ваших данных будет получен действительный хеш, он будет принят, и вы получите вознаграждение. Иначе сеть отклонит его, и вы зря потратите время и электричество.

Proof of Stake (PoS)

Proof of Stake (PoS) был предложен на заре Биткойн в качестве альтернативы Proof of Work. В системе PoS нет концепции майнеров, специализированного оборудования или огромного потребления энергии. Все, что вам нужно, это обычный компьютер.

Ну не все. Вам все еще нужно добавить скин в игру.В PoS вы предлагаете не внешний ресурс (например, электричество или оборудование), а внутренний — криптовалюту. Правила различаются для каждого протокола, но обычно существует минимальная сумма средств, которую вы должны держать, чтобы иметь право на участие в стейкинге.

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

Если выбран ваш блок, вы получите часть комиссии за транзакцию в зависимости от вашей ставки. Чем больше средств вы заблокируете, тем больше вы выиграете. Но если вы попытаетесь обмануть, предложив недействительные транзакции, вы потеряете часть (или всю) своей ставки. Следовательно, у нас есть механизм, аналогичный PoW — действовать честно выгоднее, чем действовать нечестно .

Как правило, в качестве вознаграждения для валидаторов не используются недавно созданные монеты.Таким образом, собственная валюта блокчейна должна быть выпущена другим способом. Это можно сделать либо через начальное распространение (например, ICO или IEO), либо запустив протокол с помощью PoW перед последующим переходом на PoS.

На сегодняшний день чистое доказательство доли действительно используется только в небольших криптовалютах. Поэтому неясно, может ли он служить жизнеспособной альтернативой PoW. Хотя теоретически это кажется разумным, на практике все будет по-другому.

Когда PoS внедряется в сети с большой стоимостью, система становится игровым полем теории игр и финансовых стимулов.Любой, у кого есть ноу-хау для «взлома» системы PoS, скорее всего, сделает это только в том случае, если он сможет извлечь из этого выгоду — поэтому единственный способ узнать, возможно ли это, — это действующая сеть.

Вскоре мы увидим масштабное тестирование PoS — Casper будет реализован в рамках серии обновлений сети Ethereum (вместе известной как Ethereum 2.0).

Другие консенсусные алгоритмы

Proof of Work и Proof of Stake — наиболее обсуждаемые консенсусные алгоритмы. Но есть множество других, каждый со своими достоинствами и недостатками.Ознакомьтесь со следующими статьями:

Заключительные мысли

Механизмы достижения консенсуса жизненно важны для функционирования распределенных систем. Многие считают, что величайшим нововведением в биткойнах стало использование Proof of Work, позволяющее пользователям согласовывать общий набор фактов.

Сегодня алгоритмы консенсуса лежат в основе не только систем цифровых денег, но и блокчейнов, позволяющих разработчикам запускать код в распределенной сети. Теперь они являются краеугольным камнем технологии блокчейн и имеют решающее значение для долгосрочной жизнеспособности различных существующих сетей.

Из всех алгоритмов консенсуса Proof of Work остается доминирующим предложением. Альтернативы, более надежной и безопасной, пока не предложено. Тем не менее, существует огромное количество исследований и разработок по замене PoW, и мы, вероятно, увидим их больше в ближайшие годы.

.

Что мне нужно знать об алгоритмах консенсуса блокчейна?

Blockchain — это децентрализованная распределенная сеть, которая предлагает более высокую прозрачность, безопасность и неизменность.

Мы все это знаем.

Но вы когда-нибудь задумывались, как он может достичь всего этого?

Кто управляет этой сетью и проверяет каждую транзакцию при отсутствии централизованного управления?

Ну, это консенсусные алгоритмы Blockchain — основная часть мира разработки Blockchain, о которой мы будем говорить в этом всеобъемлющем руководстве.

СОДЕРЖАНИЕ:

  1. Определение алгоритма консенсуса цепочки блоков
  2. Цели механизма консенсуса
  3. Свойства хорошего механизма консенсуса цепочки блоков
  4. Последствия использования протокола плохого консенсуса
  5. алгоритмов консенсуса блокчейна, популярных на рынке
    1. Подтверждение работы (PoW)
    2. Proof of Stake (PoS) и его варианты
    3. Византийская отказоустойчивость (BFT) и ее производные
    4. Прямой ациклический граф (DAG)
    5. Подтверждение емкости (PoC)
    6. Доказательство ожога (PoB)
    7. Подтверждение личности (PoI)
    8. Подтверждение активности (PoA)
    9. Подтверждение истекшего времени (PoET)
    10. Подтверждение важности (PoI)
  6. Быстрое сравнение основных консенсусных алгоритмов блокчейна
  7. Часто задаваемые вопросы

Что такое алгоритм консенсуса блокчейн?

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

Механизм консенсуса позволяет сети блокчейн достичь надежности и выстроить уровень доверия между различными узлами, обеспечивая при этом безопасность в среде. Это причина, по которой это одна из жизненно важных частей каждого руководства по разработке приложений Blockchain и каждого проекта dApp в среде распределенного реестра.

Эти алгоритмы работают для достижения различных целей, некоторые из которых мы рассмотрим в следующем разделе этой статьи.

Цели механизма консенсуса блокчейн

Objectives of Blockchain Consensus Mechanism

1.Единое соглашение

Одна из основных целей механизмов консенсуса — достижение единого соглашения.

В отличие от централизованных систем, в которых необходимо доверие к органам власти, пользователи могут работать, даже не доверяя друг другу, децентрализованно. Протоколы, встроенные в распределенную сеть блокчейнов, гарантируют, что данные, участвующие в процессе, являются правдивыми и точными, а статус публичного реестра актуален.

2. Согласование экономических стимулов

Когда дело доходит до построения ненадежной системы, которая регулирует сама по себе, согласование интересов участников сети является обязательным.

Протокол консенсуса блокчейна в этой ситуации предлагает вознаграждение за хорошее поведение и наказывает плохих участников. Таким образом, он также обеспечивает регулирование экономических стимулов.

3. Справедливый и равноправный

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

4. Предотвращение двойных расходов

Механизмы консенсуса

работают на основе определенных алгоритмов, которые гарантируют, что в публичный прозрачный реестр включаются только те транзакции, которые проверены и действительны.Это решает традиционную проблему двойного расходования средств, то есть проблему двукратного расходования цифровой валюты.

5. Отказоустойчивый

Другой характеристикой метода консенсуса является то, что он гарантирует отказоустойчивость, согласованность и надежность цепочки блоков. Это означает, что управляемая система будет работать неопределенное время даже в случае сбоев и угроз.

В настоящее время в экосистеме существует множество консенсусных алгоритмов Blockchain, и многие другие собираются выйти на рынок.Это заставляет каждую компанию, занимающуюся разработкой блокчейнов, и энтузиастов-предпринимателей знать факторы, которые определяют хороший консенсусный протокол, и возможные последствия использования плохого протокола.

Итак, давайте начнем с определения того, что делает консенсус блокчейна хорошим.

Свойства хорошего механизма консенсуса цепочки блоков

1. Безопасность

В хорошем механизме консенсуса все узлы способны генерировать результаты, которые действительны в соответствии с правилами протокола.

2. Включительно

Хороший механизм консенсуса гарантирует, что каждый конкретный узел сети участвует в процессе голосования.

3. Участие

Механизм консенсуса, в котором все узлы активно участвуют и вносят свой вклад в обновление базы данных в блокчейне, называется моделью хорошего консенсуса.

4. Эгалитарный

Еще одна черта хорошего механизма состоит в том, что он придает одинаковую ценность и вес каждому голосу, полученному от узла.

С учетом этого давайте выясним, что происходит, если вы не учитываете эти факторы и внедряете модель плохого консенсуса в свой процесс разработки.

Последствия выбора протокола плохого консенсуса

1. Форки блокчейна

Выбор плохого метода консенсуса блокчейна увеличивает уязвимость цепочки. Одна из таких уязвимостей, с которой сталкиваются энтузиасты и разработчики блокчейнов, — это форки блокчейна.

Форки блокчейна

, говоря языком непрофессионала, — это ситуация или обстоятельства, при которых одна цепочка расходится на две или более.Подробное объяснение форка Blockchain и его типов доступно в видео, встроенном ниже.

Когда происходит форк блокчейна, приложение начинает работать непредсказуемым образом, создавая впереди два или более разнесенных узла.

2. Плохая работа

Когда рассматривается плохой механизм консенсуса, либо узел выходит из строя, либо страдает разделением сети. Это задерживает процесс обмена сообщениями между узлами и увеличивает задержку приложения, что в конечном итоге снижает уровень производительности.

3. Ошибка консенсуса

Еще один эффект от внедрения механизма плохого консенсуса в вашу бизнес-модель — это отказ от консенсуса. В этой ситуации часть узлов не может участвовать в каком-либо процессе, и, таким образом, из-за отсутствия их голосов консенсус не может обеспечить точные и желаемые результаты.

Теперь, когда мы рассмотрели основы методов консенсуса блокчейна, давайте углубимся в тему и рассмотрим популярные типы механизмов консенсуса.

Консенсусные алгоритмы блокчейна, популярные на рынке

Blockchain Consensus Algorithms that are Popular in the Market

1.Доказательство работы (PoW)

Разработанный Сатоши Накамото, Proof of Work является старейшим механизмом консенсуса, используемым в области цепочки блоков. Это также известно как майнинг, где участвующие узлы называются майнерами.

В этом механизме майнеры должны решать сложные математические головоломки, используя обширную вычислительную мощность. Они используют различные формы методов майнинга, такие как майнинг GPU, майнинг CPU, майнинг ASIC и майнинг FPGA. А тот, кто решит проблему раньше, получает в награду блок.

Однако это не так просто. Головоломку можно решить только методом проб и ошибок. Кроме того, уровень сложности головоломки увеличивается с увеличением скорости добычи блоков. Таким образом, становится обязательным создание нового блока в течение определенного периода времени, чтобы справиться с уровнем сложности.

Механизм Proof of Work используется несколькими криптовалютами, такими как Bitcoin, Litecoin, ZCash, Primecoin, Monero и Vertcoin, и это лишь некоторые из них.

Что касается внедрения, Proof of Work (PoW) повлиял не только на финансовую отрасль, но и на здравоохранение, корпоративное управление, менеджмент и многое другое. Фактически, он предлагал возможность многоканальных платежей и транзакций с несколькими подписями по адресу для повышения безопасности.

2. Подтверждение ставки (PoS)

Proof of Stake — это самая простая и экологически безопасная альтернатива протоколу консенсуса PoW.

В этом методе блокчейна производители блоков не являются майнерами, но действуют как валидаторы.У них есть возможность создать блок для всех, что экономит энергию и сокращает время. Однако для того, чтобы стать валидатором, они должны вложить некоторую сумму денег или долю.

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

Это в целом побудило такие бренды, как Ethereum, обновить свою модель с PoW до PoS в Ethereum 2.0 обновление. Кроме того, это помогло различным экосистемам Blockchain, таким как Dash, Peercoin, Decred, Reddcoin и PivX, функционировать должным образом.

Теперь, хотя PoS решает различные проблемы, ранее связанные с PoW, на рынке все еще оставалось множество проблем. Чтобы смягчить эти проблемы и предоставить улучшенную среду блокчейна, появилось несколько вариантов PoS.

Две популярные разновидности Proof of Stake (PoS) — это DPoS и LPoS.

  • Делегированное подтверждение доли (DPoS)

В случае делегированного подтверждения ставки (DPoS) участники ставят свою монету и голосуют за определенное количество делегатов, так что чем больше они вкладывают, тем больший вес они получают.Например: если пользователь A тратит 10 монет на делегата, а пользователь B вкладывает 5 монет, голос A получает больший вес, чем голос B.

Делегаты также получают вознаграждение в виде комиссии за транзакцию или определенного количества монет.

Из-за этого механизма голосования с взвешиванием по ставкам DPoS является одной из самых быстрых моделей консенсуса в цепочке блоков и весьма предпочтителен в качестве цифровой демократии. Некоторые из реальных вариантов использования этого механизма консенсуса блокчейна — это Steem, EOS и BitShares.

  • Арендованное доказательство доли (LPoS)

LPoS — это усовершенствованная версия механизма консенсуса PoS, работающая на платформе Waves.

В отличие от обычного метода Proof-of-Stake, где каждый узел с некоторым количеством криптовалюты имеет право добавить следующий блокчейн, пользователи могут сдавать свой баланс в аренду полным узлам в этом алгоритме консенсуса. А тот, который сдает большую сумму в аренду полному узлу, имеет более высокую вероятность генерации следующего блока. Кроме того, арендатор затем получает вознаграждение в виде процента от комиссии за транзакцию, которая была собрана всем узлом.

Этот вариант PoS — эффективный и безопасный вариант для разработки публичных криптовалют.

3. Византийская отказоустойчивость (BFT)

Byzantine Fault Tolerance, как следует из названия, используется для устранения византийской неисправности (также называемой проблемой византийских генералов) — ситуации, когда участники системы должны согласовать эффективную стратегию, чтобы избежать катастрофического отказа системы, но некоторые из них сомнительны.

Узнайте больше о проблеме византийских генералов из этого видео: —

Двумя вариациями модели консенсуса BFT, которые являются основными на арене блокчейнов, являются PBFT и DBFT.

  • Практическая византийская отказоустойчивость (PBFT)

PBFT — это упрощенный алгоритм, который решает проблемы византийского генерала, позволяя пользователям подтверждать доставленные им сообщения путем выполнения вычислений для оценки решения о достоверности сообщения.

Затем сторона объявляет о своем решении другим узлам, которые в конечном итоге обрабатывают решение по нему. Таким образом, окончательное решение зависит от решений, полученных от других узлов.

Stellar, Ripple и Hyperledger Fabric являются одними из примеров использования этого механизма консенсуса блокчейна.

  • Делегированная византийская отказоустойчивость (DBFT)

Представленный NEO, механизм делегированной византийской отказоустойчивости аналогичен модели консенсуса DPoS. Здесь также держатели токенов NEO получают возможность проголосовать за делегатов.

Однако это не зависит от суммы инвестируемой валюты. Любой, кто выполняет основные требования, т.е.е, подтвержденная личность, нужное оборудование и 1000 ГАЗ, могут стать делегатом. Затем один из этих делегатов выбирается в качестве докладчика случайным образом.

Спикер создает новый блок из транзакции, ожидающей подтверждения. Кроме того, он отправляет предложение проголосовавшим делегатам, которые обязаны контролировать все транзакции и записывать их в сети. Эти делегаты имеют право обмениваться предложениями и анализировать их, чтобы проверить точность данных и честность докладчика.Если тогда 2/3 делегатов подтвердят его, блок добавляется в цепочку блоков.

Этот тип консенсусного протокола Blockchain также называется «Ethereum of China» и может быть полезным ресурсом в построении «умной экономики» путем оцифровки активов и предложения смарт-контрактов на блокчейне.

4. Прямой ациклический граф (DAG)

Еще одна базовая, но основная консенсусная модель блокчейна, с которой должна быть знакома каждая компания по разработке мобильных приложений, работающая с блокчейном, — это DAG.

В этом типе протокола консенсуса Blockchain каждый узел сам готовится стать «майнерами». Теперь, когда майнеры искоренены, а транзакции подтверждаются самими пользователями, соответствующая комиссия снижается до нуля. Становится проще проверять транзакции между любыми двумя ближайшими узлами, что делает весь процесс легким, быстрым и безопасным.

Два лучших примера алгоритма DAG — это IOTA и Hedera Hashgraph.

Хотя это основные модели консенсуса в среде разработки, многие различные механизмы консенсуса блокчейнов медленно и постепенно начинают набирать обороты, например: —

5.Подтверждение емкости (PoC)

В механизме Proof of Capacity (PoC) решения для каждой сложной математической задачи накапливаются в цифровых хранилищах, таких как жесткие диски. Пользователи могут использовать эти жесткие диски для создания блоков, так что те, кто быстрее всех оценивает решения, получают больше шансов на создание блоков.

Последующий процесс называется Построением. Две криптовалюты, которые полагаются на протокол консенсуса PoC blockchain, — это Burstcoin и SpaceMint.

6.Доказательство ожога (PoB)

Считающаяся альтернативным решением для PoW и PoS с точки зрения энергопотребления, модель консенсуса Proof of Burn (PoB) работает по принципу, позволяя майнерам « сжигать » или « разрушать » токены виртуальной криптовалюты, что дополнительно предоставляет им привилегию писать блоки пропорционально монетам. Чем больше монет они сжигают, тем больше шансов выбрать новый блок для каждой полученной монеты.

Но, чтобы сжечь монеты, они должны отправить их на адрес, где они не могли быть потрачены на проверку блока.

Это широко используется в случае распределенного консенсуса. И лучший пример этого механизма консенсуса — монета Slim.

7. Подтверждение личности (PoI)

Концепция PoI (Proof of Identity) аналогична концепции авторизованной идентичности. Это часть криптографического подтверждения личного ключа пользователя, прикрепляемого к каждой конкретной транзакции. Каждый идентифицированный пользователь может создавать и управлять блоком данных, который может быть представлен другим в сети.

Эта консенсусная модель блокчейна обеспечивает аутентичность и целостность созданных данных. Таким образом, это хороший выбор для внедрения в умные города.

8. Подтверждение активности (PoA)

PoA — это, по сути, гибридный подход, разработанный путем конвергенции моделей консенсуса PoW и PoS блокчейнов.

В случае механизма PoA, майнеры соревнуются, чтобы решить криптографическую головоломку как можно раньше, используя специальное оборудование и электроэнергию, как и в PoW. Однако блоки, с которыми они сталкиваются, содержат только информацию о личности победителя блока и транзакции вознаграждения.Здесь механизм переключается на PoS.

Валидаторы (акционеры, назначенные для проверки транзакций) проверяют и проверяют правильность блока. Если блок проверялся много раз, валидаторы активируются до полной блокировки. Это подтверждает, что открытые транзакции являются процессами и, наконец, интегрированы в найденные блок-контейнеры.

Кроме того, вознаграждение за блок делится таким образом, чтобы валидаторы получали его доли.

Две реальные реализации этого механизма — монеты Espers и Decred.

9. Доказательство истекшего времени (PoET)

PoET был представлен Intel с намерением решить криптографические головоломки, связанные с механизмом PoW, с учетом того факта, что архитектура процессора и количество оборудования для майнинга знают, когда и на какой частоте майнер выигрывает блок.

Он основан на идее справедливого распределения и увеличения шансов для большей части участников. Итак, каждому участвующему узлу предлагается подождать определенное время, чтобы участвовать в следующем процессе майнинга.Участника с самым коротким временем задержки просят предложить блокировку.

В то же время каждый узел также предлагает свое время ожидания, по истечении которого они переходят в спящий режим.

Итак, как только узел становится активным и становится доступным блок, этот узел считается «счастливым победителем». Затем этот узел может распространять информацию по сети, сохраняя при этом свойство децентрализации и получая вознаграждение.

10. Подтверждение важности (PoI)

Представленный NEM, PoI представляет собой разновидность протокола PoS, который учитывает роль акционеров и валидаторов в его работе.Однако это зависит не только от размера и вероятности их акций; различные другие факторы, такие как репутация, общий баланс и т.д. транзакций, совершаемых через какой-либо конкретный адрес, также играет в этом роль.

Сети, основанные на модели консенсуса POI, обходятся дорого в атаке и вознаграждают пользователей за вклад в безопасность сети.

Информация, предоставленная до сих пор, помогла бы вам дифференцировать различные протоколы консенсуса Blockchain.

Однако, чтобы упростить вам задачу, вот таблица сравнения консенсусных алгоритмов блокчейна.

Быстрое сравнение основных согласованных алгоритмов блокчейна

[идентификатор таблицы = 43 /]

Но, в случае, если вы хотите получить больше информации об алгоритмах консенсуса блокчейна и посмотреть, как внедрить их в свои проекты приложений, проконсультируйтесь с нашими консультантами по блокчейну сегодня.

Часто задаваемые вопросы об алгоритмах консенсуса блокчейна

Q.Что такое протокол консенсуса в блокчейне?

Протокол консенсуса — это набор правил или процедур, которые регулируют взаимодействие двух или более узлов, обмен информацией и выполнение связанных процессов в экосистеме блокчейн.

В. Какую модель консенсуса использует Ethereum?

Ранее Ethereum работал с моделью консенсуса PoW (Proof of Work). Но теперь он перешел на консенсусный алгоритм блокчейна PoS (Proof of Stake).

Chirag Bhardwaj

Чираг Бхардвадж

Евангелист блокчейн

В поисках стратегических сессий ?.

Позвольте нам досконально разобраться в вашем бизнесе и помочь вам
стратегии вашего цифрового продукта.

Статьи по теме:

.

Leave a Comment

Ваш адрес email не будет опубликован. Обязательные поля помечены *