Область применения технология широка: от создания своей криптовалюты до реализации аналога СВИФТа
Это у Вас все о финансах. На самом деле все еще куда шире. Мы в Jincor пытаемся упростить использование смарт-контрактов для бизнеса, предоставляя возможность заключать трудовые смарт-контракты с сотрудниками, смарт-контракты на оказание услуг, обмен цифровыми товарами и много чего еще, включая децентрализованные арбитражные суды, страхование сделок, ну и, конечно же, денежные переводы. Подробнее с тем, как смарт-контракты используем именно мы можно почитать в нашем whitepaper. Но я замечу, что даже мы не раскрываем и малой доли потенциала смарт-контрактов)
Спросите администрацию Гиктаймс, которая удалила целых 3 моих статьи об этом и скажите им спасибо.
А если коротко, то сфера примененения очень широка: от распредленных реестров до собственных криптовалют, цифрового правительства, выпуска акции, денежных транзакций и даже порнография и Virtual Reality. Рекомендую погугулить, что такое блокчейн, с чем его едят и почему за ним будущее.
Причина, по которой судьи хорошо работают — это открытость судов.
Вы так это утверждаете, как будто у вас есть какие-то доказательства. А они есть, или это ваше собственное умозаключение?)
Криптостартапы предоставляют детальную документацию, как и что должно работать, с точностью до алгоритмов, чтобы сообщество всё проверило и выявило недостатки. Тут же одни мечтания…
А с чего Вы решили, что все, что у нас есть — эта статья?) С удовольствием приглашаю Вас на наш лендинг, ссылки на который есть в статье и прочитать наш whitepaper)
Хотите — на русском, а не хотите, так и на английском ест)
Сначала речь о главенстве кода и смарт-контрактах, затем — о живых судьях. Это же разные подходы к образованию консенсуса, либо то, либо другое.
В статье речь о подходе: «Если не сработал подход к образованию консенсуса А, применить консенсус Б». Не вижу какой-то проблемы в применении разных подходов в исключительных ситуациях. Если у меня под рукой нет компьютера, я пишу на бумаге. Вот здесь примерно то же самое.
Сначала речь о главенстве кода и смарт-контрактах, затем — о живых судьях. Это же разные подходы к образованию консенсуса, либо то, либо другое.
Видимо не смог донести мысль. Главенство кода это прекрасно, но существование ситуаций, неразрешимых только кодом отрицать нельзя. И чем больше наши ситуации привязаны к реальному, а не исключительно цифровому миру, тем больше разрешение спорных вопросов лежит не в плоскости кода.
Далее, привязка к реальной личности. В рамках децентрализованной сети, ага. Есть какие-нибудь соображения, как верифицироваться?
Не понимаю, как вы тут увязали вообще децентрализацию. Децентрализация не имеет никакого отношения к анонимности) То что данные не хранятся в одном месте, а хранятся сразу везде, вовсе не означает, что они обезличены.
Внимательно прочитал статью «от» и «до» и так и не понял, почему же многие кейсы не осуществимы) Мы(и далеко не одни только мы) в Jincor занимаемся в том числе упрощением работы с умными контрактами для бизнеса. Большая часть из озвученных Вами проблем более чем решаема. Часть проблем решается банальными оракулами, часть приватными блокчейнами, часть децентрализованным арбитражным судом, часть привязкой умных контрактов к реальным и так далее. Так или иначе, абсолютно все проблемы, озвученные Вами в статье имеют решение и, как правило, далеко не одно)
Узнать подробней о природе умных контрактов и сферах применения можно в тут
Конечно, объемы пока маленькие. Конечно, применяется пока не повсеместно. Хочу напомнить, что это НОВАЯ технология. Или Вы думаете, что сразу после изобретения радио оно появилось в каждом доме? Что насчет телефонов и мобильных телефонов? А вот то, что объем использования криптовалют и блокчейна в целом растет с моменета основания и растет невероятными темпами — факт. Вот только сегодня наткнулся на новость:
Авиакомпания S7 продала более сотни билетов через блокчейн Ethereum
Российская авиакомпания S7 Airlines в партнерстве с “Альфа-банком” запустила автоматизированную продажу билетов, в основе которой лежит платформа, построенная на блокчейне Ethereum.
И подобные штуки появляются регулярно. Сам факт встречи президента с одним из основателей Ethereum Виталиком Бутереным, выступления глав банков и ЦБ, выступления авторитетнейших людей из мира IT вроде того же Билла Гейца, вот это все. А вы говорите — бесперспективно и не популярно, рынок не растет и т.п. Хотя вооружившись гуглом любой может доказать обратное буквально за 10 минут.
Решать, кто ворюга, а кто нет давайте оставим суду. Лично мне этот человек тоже неприятен, например, но отрицать то, что в данный момент от его решений во многом зависит судьба блокчейна в РФ вряд ли стоит. В этом и был посыл картинки.
А мы и не говорим только о криптовалютах. Смарт-контракты как пример того, что в Jincor работает на блокчейн, но имеет очень посредственное отношение к криптовалютам(и это не единственный пример). Для нас криптовалюта — топливо, благодаря которому мы можем обеспечить работу других частей системы.
Должны иметь доступ или нет — это вопрос совершенно другой. Вполне есть способы сделать так, что у каждого члена команды будет доступ к production, но это требует куда больших усилий, чем разграничение прав.
Но с тем, что джуна похвалить, а CTO на ковер — согласен)
ORM же это когда у нас есть реляции (таблички) и мы их мэпим на объекты
Я думаю, что про реляции тоже не совсем правда. Буква R в аббревиатуре скорее характеризует тип СУБД нежели обязательное требование к наличию реляций. Иначе как же быть с ODM, который по сути является тем же паттерном. А ведь в документо-ориентированных БД реляции не такое уж и частое явление.
Ну лично мне удобно было вбросить doctrine для:
а) DataMapping
b) Абстракции от СУБД(ибо было большое желание поиграть с разными)
Но никакого мэппинга не происходит
Мне кажется вы заблуждаетесь. Далеко не всегда нам нужны конечные состояния объектов. Часто бывают ситуации, когда я хочу анализировать массивы эвентов. И часто бывает ситуация, когда хочется анализировать их в PHP/Python-коде, работая как с объектами. Они иммутабельны, но это вовсе не означает, что я после сохранения не захочу мапить их на объекты.
Ну и плюс построение read-model из событий все же является частью подхода под названием event-sourcing, а там ORM — очень удобно.
В книжках по DDD очень много внимания этому уделено) Разговаривайте со своими заказчиками больше. То что они сами, как правило, не знают свою предметную область — факт. И есть методы, благодаря которым и Вы и заказчик сформируете ее понимание. При том общее. И придете к единому языку и будет вам счастье
Это у Вас все о финансах. На самом деле все еще куда шире. Мы в Jincor пытаемся упростить использование смарт-контрактов для бизнеса, предоставляя возможность заключать трудовые смарт-контракты с сотрудниками, смарт-контракты на оказание услуг, обмен цифровыми товарами и много чего еще, включая децентрализованные арбитражные суды, страхование сделок, ну и, конечно же, денежные переводы. Подробнее с тем, как смарт-контракты используем именно мы можно почитать в нашем whitepaper. Но я замечу, что даже мы не раскрываем и малой доли потенциала смарт-контрактов)
Из статьи переделывали или с github брали? Допускаю в статье наличие опечаток
А если коротко, то сфера примененения очень широка: от распредленных реестров до собственных криптовалют, цифрового правительства, выпуска акции, денежных транзакций и даже порнография и Virtual Reality. Рекомендую погугулить, что такое блокчейн, с чем его едят и почему за ним будущее.
Вы так это утверждаете, как будто у вас есть какие-то доказательства. А они есть, или это ваше собственное умозаключение?)
А с чего Вы решили, что все, что у нас есть — эта статья?) С удовольствием приглашаю Вас на наш лендинг, ссылки на который есть в статье и прочитать наш whitepaper)
Хотите — на русском, а не хотите, так и на английском ест)
В статье речь о подходе: «Если не сработал подход к образованию консенсуса А, применить консенсус Б». Не вижу какой-то проблемы в применении разных подходов в исключительных ситуациях. Если у меня под рукой нет компьютера, я пишу на бумаге. Вот здесь примерно то же самое.
Видимо не смог донести мысль. Главенство кода это прекрасно, но существование ситуаций, неразрешимых только кодом отрицать нельзя. И чем больше наши ситуации привязаны к реальному, а не исключительно цифровому миру, тем больше разрешение спорных вопросов лежит не в плоскости кода.
Не понимаю, как вы тут увязали вообще децентрализацию. Децентрализация не имеет никакого отношения к анонимности) То что данные не хранятся в одном месте, а хранятся сразу везде, вовсе не означает, что они обезличены.
Узнать подробней о природе умных контрактов и сферах применения можно в тут
И подобные штуки появляются регулярно. Сам факт встречи президента с одним из основателей Ethereum Виталиком Бутереным, выступления глав банков и ЦБ, выступления авторитетнейших людей из мира IT вроде того же Билла Гейца, вот это все. А вы говорите — бесперспективно и не популярно, рынок не растет и т.п. Хотя вооружившись гуглом любой может доказать обратное буквально за 10 минут.
Подразумевается, что этим дело не ограничивается. И это даже не основная «фича», которую мы предлагаем.
Я думаю, что основная претензия и была в попытке выдать частное за общее ;)
Но с тем, что джуна похвалить, а CTO на ковер — согласен)
Я думаю, что про реляции тоже не совсем правда. Буква R в аббревиатуре скорее характеризует тип СУБД нежели обязательное требование к наличию реляций. Иначе как же быть с ODM, который по сути является тем же паттерном. А ведь в документо-ориентированных БД реляции не такое уж и частое явление.
а) DataMapping
b) Абстракции от СУБД(ибо было большое желание поиграть с разными)
Мне кажется вы заблуждаетесь. Далеко не всегда нам нужны конечные состояния объектов. Часто бывают ситуации, когда я хочу анализировать массивы эвентов. И часто бывает ситуация, когда хочется анализировать их в PHP/Python-коде, работая как с объектами. Они иммутабельны, но это вовсе не означает, что я после сохранения не захочу мапить их на объекты.
Ну и плюс построение read-model из событий все же является частью подхода под названием event-sourcing, а там ORM — очень удобно.