Действительно, FabEx дублирует данные из леджера, и размер дублированных данных зависит только от базы данных и её настроек. Если это критично, можете поднять сервис на отдельной ноде, FabEx'у не обязательно работать на одной машине с пиром.
Вы не привели примеров. Ни оракулы, ни atomic swap никак не решают проблему консистентности двух чейнов (тем более в том ключе, в котором мы о них говорим — с целью увеличения производительности и при оперирования сущностями, отличными от валют).
Что если в одной сети мы ликвидировали колесную пару, а в другом купили? Если между чейнами есть какая-то шина, пересылающая транзакции, как мы поймем в каждый конкретный момент, что сеть консистентна? Если транзакции все равно пересылаются между сетями, в чем отличие от одной единой сети? Кто поддерживает эту шину, не является ли это уязвимостью всей системы?
Приведите, пожалуйста, пример таких сообщающихся блокчейнов на Eth или Fabric, обслуживающих общий бизнесс-процесс крупной компании, чтобы все понимали, что вы предлагаете.
Как я понимаю, колесные пары особо не взаимодействуют (хотя, может быть, и взаимодействуют — вы бизнес-операции так и не указали), их можно и не вместе держать. В принципе и перекидывать между блокчейнами можно.
Я вот с этого момента совсем перестал понимать, что вы доказываете. Делить сеть на множество частей и потом «перекидываться», чтобы заюзать нечто иное кроме Fabric — мы так делать, конечно, не будем.
Представил, как подключается участник с 2 миллионами исторических транзакций, забивает всю сеть на сутки, никто не может нормально работать и он сам на день заблокирован. Можно, конечно, так жить, но зачем?
Про «сорок восемь блокчейнов». Вы предлагаете создать 48 изолированных анклавов участников? Чтобы эфир использовать? Поскольку нам нужно будет решать проблему поддержания консистентности во всех чейнах, нам придется либо идти на компромиссы с логикой и безопасностью, либо изобретать полноценное решение для интероперабельности в эфирных сетях, что в наши планы не входит.
Я разделяю ваш скептицизм. Например, Quorum — вполне достойная замена. Но так уж вышло, что команда предпочла Fabric, гораздо более удобный в разработке. Это trade-off — мы принимаем как данность операционную сложность, чтобы взамен получить полноценный язык смарт-контрактов, огромное количество фич, скорость, хороший и поддающийся изменению код в основе платформы.
В любой момент мы можем переехать на другую платформу, если поймем, что это действительно стоит сделать. Можете посоветовать что-то более подходящее на ваш взгляд?
Стремление обходиться необходимым и достаточным, конечно, верное, но мы так (используя только БД) не могли делать, потому что компании нужна необратимая и поддающаяся аудиту история операций с КП. Слишком большая цена у злонамеренных манипуляций с колесными парами, нужно свести возможность таковых к минимуму.
Не очень удобный дизайн ещё не отменяет Тьюринг-полноту языка, было бы желание. Зато есть много проблем с HLF, вытекающих из архитектуры с доступом по сертификатам и многоступенчатым процессом подтверждения транзакции (нода, исполняющая контракт, и нода, собирающая блоки — разные сущности), которая приводит к MVCC конфликтам… Кстати, не так много разработчиков на HLF, вы не заметили? Это что-то говорит о «применимости» технологии, мне кажется.
Конечно, на Go писать удобно. Тем более, что при кажущейся простоте, на практике Solidity оказывается довольно бедным языком. Но, может, оно и к лучшему? Может, не стоит нагромождать монструозную логику в контрактах?
Вы говорите об Ethereum как о чем-то плохом, создавая искусственное противоречие «открытость/нужды бизнеса». Ethereum — это не только публичная PoW цепочка, но и такие же консорциумы на PoA Clique или Aura.
Хотите каналы? Может, вам подойдут приватные транзакции Quorum (приватный Ethereum, сделанный корпорацией для корпораций) на бешенных скоростях при raft-консенсусе? Кстати, ваше решение и HL Fabric обсеспечивают byzantine fault tolerance? Нет, только crash fault tolerance на недавно подвезенных ордерерах на raft-движке. Эфирный Quorum давно решил эту проблему.
То есть все ваши аргументы против Eth-решений, включая плату за tx, разделение цепочки, скорость, приватность и не совсем понятную сентенцию про ноды в Китае можно поставить под сомнение.
HLF — хорошая технология, но не замена eth и не панацея для корпоратов.
Приведите, пожалуйста, пример таких сообщающихся блокчейнов на Eth или Fabric, обслуживающих общий бизнесс-процесс крупной компании, чтобы все понимали, что вы предлагаете.
Я вот с этого момента совсем перестал понимать, что вы доказываете. Делить сеть на множество частей и потом «перекидываться», чтобы заюзать нечто иное кроме Fabric — мы так делать, конечно, не будем.
Про «сорок восемь блокчейнов». Вы предлагаете создать 48 изолированных анклавов участников? Чтобы эфир использовать? Поскольку нам нужно будет решать проблему поддержания консистентности во всех чейнах, нам придется либо идти на компромиссы с логикой и безопасностью, либо изобретать полноценное решение для интероперабельности в эфирных сетях, что в наши планы не входит.
Я разделяю ваш скептицизм. Например, Quorum — вполне достойная замена. Но так уж вышло, что команда предпочла Fabric, гораздо более удобный в разработке. Это trade-off — мы принимаем как данность операционную сложность, чтобы взамен получить полноценный язык смарт-контрактов, огромное количество фич, скорость, хороший и поддающийся изменению код в основе платформы.
В любой момент мы можем переехать на другую платформу, если поймем, что это действительно стоит сделать. Можете посоветовать что-то более подходящее на ваш взгляд?
Хотите каналы? Может, вам подойдут приватные транзакции Quorum (приватный Ethereum, сделанный корпорацией для корпораций) на бешенных скоростях при raft-консенсусе? Кстати, ваше решение и HL Fabric обсеспечивают byzantine fault tolerance? Нет, только crash fault tolerance на недавно подвезенных ордерерах на raft-движке. Эфирный Quorum давно решил эту проблему.
То есть все ваши аргументы против Eth-решений, включая плату за tx, разделение цепочки, скорость, приватность и не совсем понятную сентенцию про ноды в Китае можно поставить под сомнение.
HLF — хорошая технология, но не замена eth и не панацея для корпоратов.