Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 7
Opporty не только создает условия для того, чтобы небольшие компании существенно снизили затраты на поиск и конверсию новых клиентов, но и делает судебные разбирательства нецелесообразными.
А каким образом можно сделать судебные разбирательства нецелесообразными? Вот исполнитель взял предоплату, потратил её, а услугу или товар не предоставил. Каким образом платформа может заставить его вернуть деньги или товар без судебных разбирательств? Как я вижу, только одним способом — обходиться вообще без предоплат. Т.е. смарт-контракт может заблокировать оплату у заказчика, и потом по принятию работ передать её исполнителю. Но это же подходит далеко не всем, большинству нужна реальная предоплата для того, чтобы приобрести материалы или там оплатить свои расходы на начало проекта, да просто банально покрыть риски со своей стороны.
Здравствуйте.
Спасибо за вопрос. Есть категория судебных дел, которые являются на практике неразрешимыми через традиционные суды. Например, нанял юриста, он работу не сделал, но аванс взял. Можно его привлекать к отвественности через суд, но это «бой на его територии». Этот бой можно выиграть, но ценой достаточно больших дополнительных затрат. За счет этого к таким кейсам относятся с позиции «проще забыть, чем доказывать свою правоту». Таких сутуаицй очень много.
Это создает плодотворную почву для функционирования нашей платформы.
В сегментах рынка, выбранных для первоначальной интеграции такая модель применима.
В других отраслях есть своя специфика. Мы это понимаем и осознаем, что впереди нас ждет большой объем работы. Это не делает задачу нерешаемой. Где-то интеграция будет идти быстрее, где-то медленнее.
Спасибо за вопрос. Есть категория судебных дел, которые являются на практике неразрешимыми через традиционные суды. Например, нанял юриста, он работу не сделал, но аванс взял. Можно его привлекать к отвественности через суд, но это «бой на его територии». Этот бой можно выиграть, но ценой достаточно больших дополнительных затрат. За счет этого к таким кейсам относятся с позиции «проще забыть, чем доказывать свою правоту». Таких сутуаицй очень много.
Это создает плодотворную почву для функционирования нашей платформы.
В сегментах рынка, выбранных для первоначальной интеграции такая модель применима.
В других отраслях есть своя специфика. Мы это понимаем и осознаем, что впереди нас ждет большой объем работы. Это не делает задачу нерешаемой. Где-то интеграция будет идти быстрее, где-то медленнее.
Мне кажется (поправьте меня, если я ошибаюсь), что подобные вещи и в смарт-контракте прописать не менее сложно. Всё-таки смарт-контракт подразумевает какие-то строгие условия сделки, без субъективной части, которые можно «алгоритмизовать». Либо, как вариант, с субъективной частью и наличием третьей стороны-арбитра. Которой, по сути, мы делегируем полномочия суда.
Не могу Вас поправить. Вы очень точно все сказали.
Я в этой статье описал именно эту процедуру. (пока есть только на английском)
blog.opporty.com/what-is-decentralized-escrow-and-why-do-we-need-that-cb2136c71f15
Я в этой статье описал именно эту процедуру. (пока есть только на английском)
blog.opporty.com/what-is-decentralized-escrow-and-why-do-we-need-that-cb2136c71f15
Расскажите пожалуйста подробней о технологической стороне. Какие технологии использовали для blockchain, с какими трудностями столкнулись?
Для разработки децентрализованного 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 — весь фронтенд.
Если сообществу будет интересно позже напишем статью с детальными подробностями технической реализации. Это должно быть интересно.
Несмотря на его большие возможности мы столкнулись например с такими усложнениями:
Отсутствием номеров с фикс точкой — можно объявлять 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 — весь фронтенд.
Если сообществу будет интересно позже напишем статью с детальными подробностями технической реализации. Это должно быть интересно.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Opporty — новый маркетплейс для малого бизнеса на блокчейне