ведь многое держится на малом и среднем бизнесе и их поддержка нужное дело, но в планах это делать во всех странах, в Европе может в США развивать такой бизнес попроще чем в странах СНГ и соответственно нужны налогово-правовые знания для поддержки бизнеса в той или иной стране.
Мы завязаны на стандарты налоги и отчеты напрямую значительно меньше, чем тот же битрикс24. Тем не менее, им это не мешает масштабироваться. Битрикс24 не единсвенный пример. Так что это технический и организационный вопрос, а не серьезная преграда.
Кстати, мы опубликовались на Хабре. Там тоже есть ответы на некоторые вопросы
https://habrahabr.ru/post/340486/очень интересный проект и что важнее полезный для общества. у вас в команде есть люди у которых был маленький бизнес в свое время? и вы писали что если сообществу будет интересно позже напишем статью с детальными подробностями технической реализации. можно поподробней?
Здравствуйте
Спасибо за впорос.
Начнем с того, что наш бизнес из 50 человек сейчас начинался с меня, как с фриласнера и перерос в малый, а потом и в средний бизнес. Никакой богатой семьи или свяей не было, поэтому все эти процессы я прошел сам.
Чем занимался бизнес и до этого я как фрилансер?
Работал в т.ч. с малым бизнесом на протяжении почти 10 лет. Мы 10 лет решали задачи для малого бизнеса, общались с его осноателями и их заместителями, если таковые были.
Решали задачи от разработки сайтов, до маркетинга и настройки процессов через CRM. Выпустили пару собственных програм для оптимизации маркетинговых кампаний и их интеграцией с CRM системами.
Для облегчения Go To Market Strategy мы вступили на уровне основателей в несколько сообществ, которые уже имет вокруг себя сообщество экспертов, что нам позволило получить первый Traction проще.
Я все это рассказываю за тем, чтобы было понятно, насколько мы знакомы с малым бизнесом и погружены в их проблемы и задачи.
На счет статьи не понял, что именно нужно сказать подробнее.
Мой комметарий выглядел вот так:
"Для разработки децентрализованного 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/534web3.js — на данный момент в бета релизе.
По части оптимизации необходимо например быть внимательными при объявлении типов переменных использовать uint8 а не uint там где это возможно. В самих структурах не стоит хранить много информации т.к. каждая запись в структуру это потребление gas. Мы стараемся использовать минимальное количество данных для хранения. Большая часть данных например документы прикрепленные к задаче храняться в базе а в блокчейне мы храним в зашифрованном виде id записи в базе.
По технической реализации:
node.js — бекенд
web3.js — чтение данных с блокчейна для реализации dapp. По сути мы на фронте его не используем. Все через бекенд в котором реализовано чтение данных с контракта, вызов функций а также чтение данных по ивентам. Очень важной особенностью является Events в контрактах они сильно облегчают разработку. Но стоит не забывать что иногда необходимо получать все события по конкретному ивенту getPastEvents.
geth — для синхронизации с блокчейном и возможностью чтения с него данных через web3.js используя IPC.
PostgreSql, Redis, mongoDB.
react.js + redux — весь фронтенд.
Если сообществу будет интересно позже напишем статью с детальными подробностями технической реализации. Это должно быть интересно."
Если подробнее, то это уже и будет статья, которую я пообещал скоро выпустить.
