Был один спор, который я вел и сам с собой и с коллегами, с которыми мы строим свою блокчейновую платформу, относительно того что такое, зачем нужен и как работает в общем механизм достижения консенсуса в блокчейновых сетях. И в процессе этих споров родилась схема механизма консенсуса, которая несколько отличается от существующих решений и способна подойти для обеспечения устойчивой работы с высоким показателем пропускной способности для сети, где размер каждой транзакции радикально отличается от обычных нескольких сотен байт, например для конфиденциальных транзакций, чей размер раз в 20 больше, чем обычной. На ваш суд я и предоставляю краткое её описание и хотел бы выслушать все возможные аргументы “за и против” подобной схемы.
Все существующие на сегодняшний день типы консенсуса достигают соглашения по всем параметрам транзакции в один этап — и сам факт того, что транзакция состоялась и корректно ли ее внутреннее содержимое. С одной стороны это приводит к тому, что в любой момент времени состояние сети находится в конечном, “правильном”, состоянии, но, с другой, мешает пропускной способности, поскольку для проведения работы верификации тратятся и ресурсы и проверяющего и сети да и время, конечно же.
Мы решили разбить достижение консенсуса на два этапа, а сеть на три слоя, где один слой, это шардированное “хранилище”, а два других — это слои “консенсуса”. На первом этапе транзакция, которая “весит”, как минимум, несколько килобайт, не рассылается по всей сети целиком для верификации всеми участниками “ответственными за консенсус”, но составляются два пакета. Первый пакет — это “заголовок” транзакции, состоящий из публичного ключа, хеша самой транзакции и подписи. Второй пакет — собственно сама транзакция целиком как она есть со всеми деталями. Первый пакет посылается в слой, который отвечает только за то, чтобы задокументировать факт того, что транзакция посылалась с такого-то аккаунта и ее хеш такой-то. Сама же транзакция посылается в “хранилище” без какой-либо верификации ее содержимого.
схематичное представление описанных слоёв
На этом этапе получающая сторона уже может увидеть, что транзакция пришла в “хранилище” и что она таки зарегистрирована в первом слое консенсуса. Поскольку “заголовок” транзакции имеет очень маленький размер (меньше 200 байт), даже самые большие транзакции не снижают пропускную способность сети целиком на этом этапе.
Далее, законы о том, когда считать содержимое транзакции верным, а когда нет абсолютно детерменистичны и одинаковы для всех и в любой момент времени. Поэтому все участники смогут самостоятельно проверять содержимое транзакций и приходить всегда к одинаковым выводам относительно их верности.
Но тут есть проблема, что если оставить “достижение консенсуса”, что называется, только “на местах”, то каждый участник сети будет обязан всегда сгружать и проверять содержимое всех транзакций предшествующих полученной. И не только тех, что были разосланы текущим контрагентом, но и всеми контрагентами, с кем он имел дело до настоящего момента времени и их контрагентами и так далее. В теории это конечно хорошо, поскольку такая сеть действительно будет независимо проверяться всеми участниками, но хотелось бы снизить нагрузку на конечного потребителя, чтобы ему не приходилось скачивать информацию “с начала времен”.
Для этих целей реализован третий слой, который призван проходить по уже зарегистрированным транзакциям и выносить решение — каждая конкретная транзакция она правильна или нет. Поскольку этот слой будет работать с уже установленным блокчейном заголовков транзакций, то никаких разветвлений тут уже не может быть. В условиях менее сильной нагрузки сети этот слой будет идти практически “нога в ногу” со слоем регистрации транзакций, а в условиях увеличенной нагрузки будет немного отставать и тогда каждый конечный получатель транзакции сможет самостоятельно прийти к выводу о верности транзакции по правилам, универсальными для всей сети в кратчайший промежуток времени.
Таким образом мы сможем достигать и высокой пропускной способности сети и наискорейшей финализации транзакции и позволить работать с сетью тем участникам, которые не хотят иметь у себя полную копию всех исторических данных сети.
Для полноты картины отмечу, что слой, ответственный за регистрацию транзакций будет работать на основании pBFT, где набор группы верификации будет осуществляться случайным образом с использованием проверяемой случайной функции (VRF), а слой, ответственный за консенсус по содержимому будет работать на основании механизма Proof of Stake.
Автор: Лунтик
