Вы с такими темами поаккуратнее, а то пойдет череда банкротств, и много проектов позакрывают, поувольняют отделы, появятся неудобные вопросы на конференциях. И вообще, правда горькая на вкус =)
Однако, вы схитрили, написав дисклеймер. Поэтому по некоторым кейса выражу свое ИХМО со своим дисклеймером: все ниже мною описанное — есть частный случай конкретного кейса и суть не распространяется на кейс в целом.
Итак, на радость тем, кто ещё внедряет блокчейн =)
1. Supply Chain Management
Решая этот кейс, рассматривал ситуацию, когда имеется множество заказчиков, поставщиков и цепочка перевозчиков. Все они не в состоянии договориться и создать единый сервис по отслеживанию посылки и ее состоянию. Но каждый на своем этапе при приеме от прошлого перевозчика может определить состояние посылки и зафиксировать его в сервисе трекинга с временной меткой. Вот как раз такой трекинг и делают на блокчейне, иначе все участники не могут доверять друг-другу и тем более ещё кому-то платить за какой-то сервис трекинга.
А вдруг санкции и угрозы отключения от такой системы? Раз так, и отключили, например, Саудовскую Аравию, и уже с трудом распространяются нефть, ее цена растет и так далее. В этом суть децентрализации.
Конечно, даже с системой трекинга на блокчейне у нее скорее всего будет оператор в виде консорциума, тем не менее, можно сделать так чтобы этот консорциум технически не мог запретить использовать сервис, а лишь поддерживал его развитие и поддержку.
2. Гарантия подлинности товара
Данный кейс на мой взгляд разобран опять таки не с той стороны.
Вот как я вижу: Проверка подлинности товара заключается в том, что к товару добавляется некий секрет, обладая которым, можно доказать что товар id123 принадлежит вам и никому другому. Допустим, дорогие часы, произведение искусства.
Злоумышленник может подменить товар и попытается его продать. Но покупатель перед покупкой с легкостью может проверить, кому в данный момент принадлежит товар, а при покупке товара приобретет и запись, подтверждающую владение им. Таким образом уникальный товар всегда имеет владельца. А злоумышленник остается с неликвидным подлинником.
В некотором похожем виде реализован EmerDPO
Получается, весь описанный вами эксплойт применим только для единичных случаев и не несет угрозы производителю. И да, этот кейс похож на цепочку поставок, но больше похож на токенизацию активов. Главное преимущество, от централизованных системе в том, что сложнее подделать информацию и в том, что информация будет там жить скорее всего дольше чем сам производитель =)
3. Подлинность диплома университета
Ну тут, тоже просто. Для подтверждения подлинности по ЦП необходимо знать ключ подписанта, а для этого нужно уже поднимать инфраструктуру открытых ключей с удостоверяющим центром. Вот как раз удостоверяющий центр заменяет блокчейн, иначе централизация по главе УЦ.
И производительности биткойна и эфира не будет достаточно, если все вузы вдруг начнут пулять хэши дипломов в блокчейн биткойна.
4. Голосование
Тут вы вероятно забыли про кольцевую криптографию. И некоторые криптовалюты уже еле как, но решают задачу сокрытия авторства транзакции (голосования).
5. Доказательство авторства
В данном кейсе важно зафиксировать время обладания произведением или первым зафиксировать произведение. И важна связь автор-время-произведение. И этот кейс применим для патентования. Представьте, что два изобретателя придумали устройство и пошли в патентное ведомство. Далее идет долгая одновременная процедура по анализу изобретения и патентному ведомству придется выдать патент тому, кто первый подал заявку на его получение. Заметим, что ни один из изобретателей не может доверять, возможно, коррумпированному ведомству, но могут доверять децентрализованной системе.
И да, блокчейна биткойна опять будет недостаточно, если каждый изобретатель будет слать туда свои хэши.
В некотором смысле IPChain создан для решения подобных ситуаций.
6. Земельный кадастр
Данный кейс самый сложный. Грубо и в первом приближении, кадастр недвижимости отражает кому какой объект недвижимости принадлежит, а регулятор определяет условия по которым это отражение может быть изменено. Суть блокчейна тут в том, что регулятора можно заменить блокченом раз и навсегда. И теперь не регулятор будет проверять условие изменение кадастра, а смарт-контракты, которые не берут взятки и не суют палки в колеса. Ноды поддерживаются соответствующими, не связанными органами власти. И здесь нет особых технических трудностей к децентрализации, сложнее изменить устоявшуюся систему политически, юридически и административно.
В остальном я с вами больше согласен, и выражаю огромную благодарность, что высказали то, что у многих на уме.
Вы правы, что имеющиеся реализации на блокчейне это чаще всего профанация, с блекджеком и пиарщиками (простите).
Блокчейн ещё не созрел и подавляющее большинство не понимают как он устроен, поэтому пытаются заменить им базы данных и ESB, с мыслями, что теперь все будет работать ещё надежнее, быстрее и все этому будут доверять, а пиар принесет нам кучу денег инвесторов.
Блокчейн способен в корне изменить принципы взаимодействия, но до этого далеко, как когда-то до настоящего коммунизма =)))
Это еще одна особенность go.
Публичные (экспортируемые) методы пишутся с большой буквы, а приватные (неэкспортируемые) с маленькой. Такая себе инкапсуляция =) golang.org/ref/spec#Exported_identifiers
Спасибо за препарацию моей самоделки и за Noise Protocol.
Я расчитывал как раз на подобный разбор.
1) Сейчас ID пира есть его публичный ключ. Первоначально не ставил задачу его скрывать, да и протокол был бы не такой лаконичный, а на будущее учту этот момент. Правда, не совсем понял как это уязвимо для MITM?
2) Эфемерные ключи передаются в подписанном конверте, поэтому можно считать что они подписаны
Другое дело, что подпись проверяется, но реакция на некорректность реализована недостаточно.
3) Да, проверка корректности отсутствует. Была идея реализовать как в телеграмме AES+IGE. Была мысль, что контент сам себя провалидирует, если будет представлять собой gzip, в который я хотел упаковывать все сообщения для экономии трафика. А там уже проверки гзиповские будут. Но соглашусь, лучше использовать проверку корректности на основе режима шифрования.
Ниже уже кинули ссылку на репозиторий с кодом, можно его еще поковырять.
Хорошее замечание, учту!
Однако, шифруется json, и он всегда заканчивается на печатные байты "}" или "]", поэтому в текущей реализации проблем быть не должно.
Где же вы в Hyperledger Fabric нашли BFT?
Дамочка указывает ссылку на свой пинтерест, а ей подборка её желаний с ценниками.
Вы с такими темами поаккуратнее, а то пойдет череда банкротств, и много проектов позакрывают, поувольняют отделы, появятся неудобные вопросы на конференциях. И вообще, правда горькая на вкус =)
Однако, вы схитрили, написав дисклеймер. Поэтому по некоторым кейса выражу свое ИХМО со своим дисклеймером: все ниже мною описанное — есть частный случай конкретного кейса и суть не распространяется на кейс в целом.
Итак, на радость тем, кто ещё внедряет блокчейн =)
1. Supply Chain Management
Решая этот кейс, рассматривал ситуацию, когда имеется множество заказчиков, поставщиков и цепочка перевозчиков. Все они не в состоянии договориться и создать единый сервис по отслеживанию посылки и ее состоянию. Но каждый на своем этапе при приеме от прошлого перевозчика может определить состояние посылки и зафиксировать его в сервисе трекинга с временной меткой. Вот как раз такой трекинг и делают на блокчейне, иначе все участники не могут доверять друг-другу и тем более ещё кому-то платить за какой-то сервис трекинга.
А вдруг санкции и угрозы отключения от такой системы? Раз так, и отключили, например, Саудовскую Аравию, и уже с трудом распространяются нефть, ее цена растет и так далее. В этом суть децентрализации.
Конечно, даже с системой трекинга на блокчейне у нее скорее всего будет оператор в виде консорциума, тем не менее, можно сделать так чтобы этот консорциум технически не мог запретить использовать сервис, а лишь поддерживал его развитие и поддержку.
2. Гарантия подлинности товара
Данный кейс на мой взгляд разобран опять таки не с той стороны.
Вот как я вижу: Проверка подлинности товара заключается в том, что к товару добавляется некий секрет, обладая которым, можно доказать что товар id123 принадлежит вам и никому другому. Допустим, дорогие часы, произведение искусства.
Злоумышленник может подменить товар и попытается его продать. Но покупатель перед покупкой с легкостью может проверить, кому в данный момент принадлежит товар, а при покупке товара приобретет и запись, подтверждающую владение им. Таким образом уникальный товар всегда имеет владельца. А злоумышленник остается с неликвидным подлинником.
В некотором похожем виде реализован EmerDPO
Получается, весь описанный вами эксплойт применим только для единичных случаев и не несет угрозы производителю. И да, этот кейс похож на цепочку поставок, но больше похож на токенизацию активов. Главное преимущество, от централизованных системе в том, что сложнее подделать информацию и в том, что информация будет там жить скорее всего дольше чем сам производитель =)
3. Подлинность диплома университета
Ну тут, тоже просто. Для подтверждения подлинности по ЦП необходимо знать ключ подписанта, а для этого нужно уже поднимать инфраструктуру открытых ключей с удостоверяющим центром. Вот как раз удостоверяющий центр заменяет блокчейн, иначе централизация по главе УЦ.
И производительности биткойна и эфира не будет достаточно, если все вузы вдруг начнут пулять хэши дипломов в блокчейн биткойна.
4. Голосование
Тут вы вероятно забыли про кольцевую криптографию. И некоторые криптовалюты уже еле как, но решают задачу сокрытия авторства транзакции (голосования).
5. Доказательство авторства
В данном кейсе важно зафиксировать время обладания произведением или первым зафиксировать произведение. И важна связь автор-время-произведение. И этот кейс применим для патентования. Представьте, что два изобретателя придумали устройство и пошли в патентное ведомство. Далее идет долгая одновременная процедура по анализу изобретения и патентному ведомству придется выдать патент тому, кто первый подал заявку на его получение. Заметим, что ни один из изобретателей не может доверять, возможно, коррумпированному ведомству, но могут доверять децентрализованной системе.
И да, блокчейна биткойна опять будет недостаточно, если каждый изобретатель будет слать туда свои хэши.
В некотором смысле IPChain создан для решения подобных ситуаций.
6. Земельный кадастр
Данный кейс самый сложный. Грубо и в первом приближении, кадастр недвижимости отражает кому какой объект недвижимости принадлежит, а регулятор определяет условия по которым это отражение может быть изменено. Суть блокчейна тут в том, что регулятора можно заменить блокченом раз и навсегда. И теперь не регулятор будет проверять условие изменение кадастра, а смарт-контракты, которые не берут взятки и не суют палки в колеса. Ноды поддерживаются соответствующими, не связанными органами власти. И здесь нет особых технических трудностей к децентрализации, сложнее изменить устоявшуюся систему политически, юридически и административно.
В остальном я с вами больше согласен, и выражаю огромную благодарность, что высказали то, что у многих на уме.
Вы правы, что имеющиеся реализации на блокчейне это чаще всего профанация, с блекджеком и пиарщиками (простите).
Блокчейн ещё не созрел и подавляющее большинство не понимают как он устроен, поэтому пытаются заменить им базы данных и ESB, с мыслями, что теперь все будет работать ещё надежнее, быстрее и все этому будут доверять, а пиар принесет нам кучу денег инвесторов.
Блокчейн способен в корне изменить принципы взаимодействия, но до этого далеко, как когда-то до настоящего коммунизма =)))
Чат — слово нерусское. Может «вещатель»?
Публичные (экспортируемые) методы пишутся с большой буквы, а приватные (неэкспортируемые) с маленькой. Такая себе инкапсуляция =)
golang.org/ref/spec#Exported_identifiers
Спасибо за препарацию моей самоделки и за Noise Protocol.
Я расчитывал как раз на подобный разбор.
1) Сейчас ID пира есть его публичный ключ. Первоначально не ставил задачу его скрывать, да и протокол был бы не такой лаконичный, а на будущее учту этот момент. Правда, не совсем понял как это уязвимо для MITM?
2) Эфемерные ключи передаются в подписанном конверте, поэтому можно считать что они подписаны
Другое дело, что подпись проверяется, но реакция на некорректность реализована недостаточно.
3) Да, проверка корректности отсутствует. Была идея реализовать как в телеграмме AES+IGE. Была мысль, что контент сам себя провалидирует, если будет представлять собой gzip, в который я хотел упаковывать все сообщения для экономии трафика. А там уже проверки гзиповские будут. Но соглашусь, лучше использовать проверку корректности на основе режима шифрования.
Ниже уже кинули ссылку на репозиторий с кодом, можно его еще поковырять.
Однако, шифруется json, и он всегда заканчивается на печатные байты "}" или "]", поэтому в текущей реализации проблем быть не должно.