Pull to refresh
65
0
Sergii Grybniak @greebn9k

DLT Research and Implementation

Send message
К сожалению, не могу оправдать Ваши надежды. Если мы говорим о, например, разработке ERP, то данное утверждение является правильным. Конечно, если мы говорим о разработке небольшого программного продукта, типа системы бухгалтерского учета или учета рабочего времени программистов, то тогда предметной областью этого продукта является то, что Вы назвали.
Я с Вами согласен, что текст в этом месте стоит уточнить. Благодарю за комментарий.
-30! За вполне сильные контраргументы в 2011! Как там в 2011?
Не один, но мы про json-rpc over whatever
Прекрасная статья, смысла в REST нету, если нету масштабирования
Ну основной чейн — это эфириум обычно — это и есть рутчейн. Вы или я что-то не поняли?
Сформировать пруф на вывод тоже нельзя будет если нет наличия подписанной транзакцииб вернее нужно 2 транзакции послать для вывода.
Не могут они делать фейковые опровержения, не получится сформировать пруф, это все проверяется же на уровне смарт контракта. Вывод уже попадает в рутчейн чтобы его оспорить.

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

Про рутчейн и основной блокчейн мы поправим в статье.
Да, спасибо, именно эта информация устарела уже.
Вывел с root chain'a — получил себе на кошелек/контракт перевод со смарт-контракта плазмы. Сделал вывод с плазмы.
Никто не сможет cформировать fraud proof на честную транзакцию, то есть если токен пользователя не был потрачен ранее, и не было невалидных блоков в истории, или скрытых (block withholding).
Проверить всю цепочку очень легко, она передается вместе с токеном, когда тратятся токены.
Пользователь А передает историю пользователю Б вместе с токеном. Проверить историю можно проверив хеши в плазма контракте без траты fee. Пользователь Б проверяет историю токена и представляет cвой товар/услугу.
Текущий или следующий ничего не получит, если он уже вывел с корневого чейна и никто не оспорил, тогда он может отправить куда угодно, на биржу или куда захочет.
А что будет с токеном если транзакция невалидная и ее оспорили? Ее сможет предыдущий owner вывести.
Fraud proof'ы — это основа на чем держится плазма. Период можно изменить на меньший. Если есть внешние сторонние валидаторы, они могут быть поощрены валидировать цепочку и тогда этот период можно сделать равным одному дню. После оспаривания, если транзакция невалидная, но уже в чейне, она просто реджектится, какая-то сумма должна вычитаться с fee и идти на поощрение валидаторов.
Невозможно представить, как это более просто описать. Единственная проблема то здесь описано далеко не все, что необходимо.
Благодарю за вопрос.
Вставил как отдельный комментарий, а не ответ. см. ниже.
Для разработки децентрализованного ESCROW мы использовали язык программирования solidity, как самый распространенный высокоуровневый язык программирования для смарт контрактов
Несмотря на его большие возможности мы столкнулись например с такими усложнениями:

Отсутствием номеров с фикс точкой — можно объявлять fixed но не присваивать значение
solidity.readthedocs.io/en/develop/types.html#fixed-point-numbers
Отсутствием итераторов для mapping типов, то есть невозможно перебрать к примеру все списки судей в контракте, необходимо использовать ухищрения — несколько переменных и структуру
solidity.readthedocs.io/en/develop/types.html?highlight=mapping#arrays
Отсутствие безопасных даже базовых математических операций. Был использован SafeMath от Zeppelin
github.com/OpenZeppelin/zeppelin-solidity/blob/master/contracts/math/SafeMath.sol
Несмотря на наличие операций revert транзакции потребляют газ. В форке Byzantium пофикшено
github.com/ethereum/EIPs/pull/206
Невозможно проверить наличие того факта что превышен лимит газа. Что приводит к ошибкам при выполнении длинных циклов.
solidity.readthedocs.io/en/develop/security-considerations.html#gas-limit-and-loops
Структуры нельзя возвращать с функций. Это возможно лишь для internal (внутренних функций)
solidity.readthedocs.io/en/develop/frequently-asked-questions.html#can-a-contract-function-return-a-struct
В Ethereum Wallet и в truffle версия компилятора устаревшая.
Отсутствие полноценной IDE для разработки. Выручает remix.ethereum.org
Буквально пару дней назад столкнулись с проблемой. В момент деплоя была создана копия контракта. При загрузке в один из контрактов source они были так же продублированы в копии контракта. Учитывая что деплой контракта требует ввода пароля. Это можно отнести к уязвимости. Была создана issue github.com/ethereum/mist/issues/3181 но пока без ответа.
В лайт режиме есть баг. После выполнения транзакции не возвращался address контракта. Этот баг справедлив как для кошельков так и для выполнения миграции через truffle
github.com/trufflesuite/truffle/issues/534
web3.js — на данный момент в бета релизе.

По части оптимизации необходимо например быть внимательными при объявлении типов переменных использовать uint8 а не uint там где это возможно. В самих структурах не стоит хранить много информации т.к. каждая запись в структуру это потребление gas. Мы стараемся использовать минимальное количество данных для хранения. Большая часть данных например документы прикрепленные к задаче храняться в базе а в блокчейне мы храним в зашифрованном виде id записи в базе.

По технической реализации:
node.js — бекенд
web3.js — чтение данных с блокчейна для реализации dapp. По сути мы на фронте его не используем. Все через бекенд в котором реализовано чтение данных с контракта, вызов функций а также чтение данных по ивентам. Очень важной особенностью является Events в контрактах они сильно облегчают разработку. Но стоит не забывать что иногда необходимо получать все события по конкретному ивенту getPastEvents.
geth — для синхронизации с блокчейном и возможностью чтения с него данных через web3.js используя IPC.
PostgreSql, Redis, mongoDB.
react.js + redux — весь фронтенд.
Если сообществу будет интересно позже напишем статью с детальными подробностями технической реализации. Это должно быть интересно.
Не могу Вас поправить. Вы очень точно все сказали.
Я в этой статье описал именно эту процедуру. (пока есть только на английском)
blog.opporty.com/what-is-decentralized-escrow-and-why-do-we-need-that-cb2136c71f15
Здравствуйте.
Спасибо за вопрос. Есть категория судебных дел, которые являются на практике неразрешимыми через традиционные суды. Например, нанял юриста, он работу не сделал, но аванс взял. Можно его привлекать к отвественности через суд, но это «бой на его територии». Этот бой можно выиграть, но ценой достаточно больших дополнительных затрат. За счет этого к таким кейсам относятся с позиции «проще забыть, чем доказывать свою правоту». Таких сутуаицй очень много.
Это создает плодотворную почву для функционирования нашей платформы.
В сегментах рынка, выбранных для первоначальной интеграции такая модель применима.
В других отраслях есть своя специфика. Мы это понимаем и осознаем, что впереди нас ждет большой объем работы. Это не делает задачу нерешаемой. Где-то интеграция будет идти быстрее, где-то медленнее.
Не то что в ходит в CORE DOMAIN.
Ксения, спасибо за комментарий. Увы, но ваши предположения ошибочны. Статья писалась без упора на какой-то конкретный источник. Я, честно говоря, вижу некоторые совпадения с вашей статьей, но это, уж извините за тавтологию, совпадение. Ваша статья тоже очень хорошая. Спасибо за источник.
Если найти специализированные форумы (или ветки по вашей теме), где находятся люди, которым могут быть интересны товары, которые вы перечислили, то почему бы и нет… Эти товары имеют не очень большой чек и не привязаны к конкретному городу.

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

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

Касательно самого метода, то да использовали (и используем). Кейс сейчас в процессе, так сказать. Так что, к сожалению, ничего конкретного не скину.

Information

Rating
Does not participate
Date of birth
Registered
Activity