Title: Почему вы никогда не запустите свой блокч Post by: beeqb on September 24, 2017, 06:48:25 PM Разработка BeeQB, как и многих других продуктов, началось без использования blockchain, хоть и с перспективой интеграции, как-никак расчеты в криптовалюте иначе и не реализуешь. Существовало, впрочем, сейчас ничего не изменилось, много аргументов, из-за которых я считаю, что классический blockchain не подходит для бизнеса. Вот они:
Аргумент №1: Скорость blockchain Максимальная теоретическая производительность транзакции нода Ethereum составляет чуть более 1000 транзакций в секунду. К сожалению, это не фактическая пропускная способность из-за «gas limit», который в настоящее время составляет около 6,7 миллионов газа в среднем для каждого блока. C текущим 6,7 миллионами gas limit и текущим, средним показателем газа, используемым для стандартной транзакции приблизительно 21K, мы получаем приблизительно 300 стандартных транзакций в каждом блоке. Текущее среднее время блока составляет 20 секунд, что в лучшем случае составляет примерно 15 транзакций в секунду (300/20 = 15). Количество транзакций становится намного ниже при более сложных транзакциях (например, median gas, используемый смарт-контрактами, составляет 50 тыс., что означает примерно 7 транзакций в секунду). Именно поэтому, выбирая платформу для токенов, я остановился на Waves, у которых производительность несравнимо выше. Хотя, рядовому ICO инвестору, который свято верит в смарт-контракт и erc20 сложно объяснить, тот факт, что мы обязаны использовать самый надежные, а не самые хайповые технологии. Используя любую SQL базу, можно добиться в 5000-15000 раз большей производительности. Аргумент №2: Один blockchain - только один blockchain Исследовав все известные blockchain сети (Apla, Ethereum, Hyperledger, Tezos, EOS), мы выяснили, что все они имеют одну схожую особенность: один блокчейн. https://spark.ru/upload/other/b_59c7e94c9faed.jpg Это означает, что используя такую платформу для реализации задач beeqb, мы будем вынуждены либо добавлять множество join запросов и бессмысленно детализировать каждый блок blockchainа, увеличивая до 20-50Mb каждый блок. Либо для каждого бизнес-процесса каждой компании, каждого сотрудника компании будем вынуждены создавать собственный классический blockchain, а эта бессмысленная идея слишком дорога и слишком нелогична. С одной стороны, если вы создаете или используете монопродукт - сервис хранения данных, сервис распределенного реестра, сервис приема платежей или выдачи кредитов, то указанное ограничение не является проблемой. По сути, вам больше и не нужно. Но для BeeQB такое ограничение - проблема, причем нерешаемая проблема, которая, снова же, заставляет разрабатывать костыли или совершенно новое технологическое решение. Аргумент №3: Смарт-контракт - это код Самая большая глупость, которую я встречал в мире - это попытка создать свой собственный язык программирования для реализации программного решения, которое ограничено платформой, которая написана на другом языке программирования. Cмарт-контракты Ethereum пишутся на Solidity (этот тот же Java, только Solidity), APLA предлагает изучить Simvolio А я считаю, что смарт-контракт - это замечательная штука, создание которого можно и нужно автоматизировать до заполнения форму на сайте или коммуникации с чат-ботом (Порекламирую http://thetokenfactory.com/#/ ) И снова же, blockchain не подходит для бизнеса, потому что слишком много процессов, которые необходимо прописывают проводить нюансировку, дописать и так далее. В итоге работа со смартконтрактами создает корпоративных звезд, которых нельзя уволить, потому что только они понимают что там и где. А следовательно, компания работает на благо программистов, что ставит под сомнение необходимость существования самой компании. Анализируя все это, разрабатывая возможные теории, я пришел к неутешительному для себя выводу: BeeQB невозможно реализовать без blockchain, но как blockchain реализовать в BeeQB я не знаю. Хотя И вот об этом ХОТЯ я и хочу вам рассказать. Проведя глобальную исследовательскую работу, прочитав сотни статей на многих языках, которые иногда приходилось переводить google translator. Проведя сотни часов в общении с экспертами и гуру рынка, задавая им глупые и неуместные вопросы, обсуждая с ними свой проект я разработал очень смелый и амбициозный, я бы даже сказал ИННОВАЦИОННЫЙ вариант реализации blockchain, абсолютно новый консенсус и, окончательно утвердился в мысле, что BeeQB невозможен без использования blockchain. Инновация №1: Мультитред Любой бизнес работает по двум классическим технологиям: 1. BPM (Business Process Management); 2. PM (Project Management). Без одной технологии нет другой. Но везде одна из технологий менеджмента является главенствующей. Toyota, Bloomberg, Tesla, Valve, IBM используется BPM метод. Apple, VW Group, CAT, Oracle, Amazon - главенствующим сделали PM метод. В принципе, абсолютно не важно, какую из технологий вы выберите, важно, чтобы вы ее выбрали. И вот, выбрав свою технологию менеджмента, вы столкнетесь с тем, что управляемые процессы алгоритмичны, но при этом они мультипотоковые. Следовательно, чтобы использовать blockchain в вашем бизнесе, вам необходимо использовать такой blockchain, который также как и алгоритмы должен быть мультипотоковым. Но, используя любое из существующих решений мы получаем следующую картинку: https://spark.ru/upload/other/b_59c7eb4ddec54.jpg Но картинка должна быть такой: https://spark.ru/upload/other/b_59c7ec16e84c9.jpg То есть, у вашей компании есть корневой blockchain (Компания #1). При этом есть блокчейн сотрудника (Сотрудник #1 и #2) , в котором записываются его ключевые точки роста: время прихода на работу, поставленные задачи, план продаж, факт продаж, скорость сделки, выплата зарплаты и так далее (Сделка #1 и #2 ...). Некоторые блокчейны имеют двух господ и их исходная точка зависит от показателей двух сотрудников. К примеру Выплата зарплаты: Продавец получает ЗП в зависимости от цифры, заложенной в смартконтракте, и указанных KPI. Бухгалтер выплачивает зарплату, исходя из суммы, которая рассчитана смарт-контрактом и исходя из наличия средств на счету. То есть, при нулевом значении одной из сторон смарт-контракт не может быть начат, равно как и реализован. При этом результат блокчейна станет частью персонального блокчейна обоих участников и компании. Инновация №2: Blockchain для Смарт-контрактов, а не смарт-контракт для блокчейна Очевидность необходимости разработки совершенно новой типологии blockchain привела к другому выводу - необходимости генерации новых цепей на основании смарт-контрактов. То есть, именно смарт-контракт должен стать инициатором создания блокчейна, именно смарт-контракт должен стать законодателем правил блокчейна. https://spark.ru/upload/other/b_59c7f0813ab05.jpg И тут самое время рассказать о future-proofing и future-proofing events, но я оставлю это для еще одной статьи. Подписывайтесь на обновления, лайкайте и будьте в курсе последних новостией нашего блога. Именно поэтому в BeeQB мы реализовываем три типа смарт-контрактов: товарно-сервисный, кредитный и долевой. Суть контракта исходит из его названия, но есть одно важное уточнение. Компания может использовать автоматические контракты, настроить шаблонные или создать новые. Автоматические контракты (на примере товарно-сервисного смарт-контракта): Компания продает в розницу телевизоры. Процедура сделки, регулируется государством (количество дней для возврата покупки, срок гарантии, данные на чеке и так далее). Система распознает тип сделки и создает блокчейн сделки на основании такого смарт-контракта. Разумеется, компания может изменить контракт для такого типа сделки, но это уже другая история. Важно то, что блокчейн этой сделки будет инициирован смарт-контрактом и он будет более чем стандартизирован, а следовательно, может считать эталоном для бизнеса и государства. Существует еще один вопрос, на который следует дать четкий ответ: что инициирует смарт-контракт? Инновация №3: Proof of Event Я готов вступить в дискуссию с широкой аудиторией по данному вопросу Логически-верный вывод предыдущего рассказа заключается в том, что инициатором смарт-контракта, который инициирует блокчейн, должно послужить некое событие. К примеру, началом корневого блокчейна компании должен послужить смарт-контракт создания этой компании через форму на сайте. При этом предшествующее событие - это клик по кнопке Создать компанию. Казалось бы, Спасибо Кэп. Но не так все просто. Для того, чтобы пользователь кликнул на кнопку, пользователь должен быть зарегистрированным пользователем, иметь заполненный профиль и находиться на корневой странице beeqb. Также и в более серьезных задачах. Для того, чтобы клиент мог купить товар, а продавец мог продать товар, должно произойти два события: наличие денег у покупателя, наличие товара у продавца. Давайте предположим, что вы покупаете у меня тысячу коробок спичек. Я - производственная компания. Мы с вами инициируем смарт-контракт в котором говорим: Я: Я, поставлю тебе 1000 коробок спичек на протяжении 5 дней, при условии 50% предоплаты и 50% оплаты в момент отгрузки. Вы: Ок, но предоплата поступит только при наличии товара на складе и готовности к отгрузке. Я: По рукам. https://spark.ru/upload/other/b_59c7f1b181cf3.jpg BeeQB прогнозирует, что данный товарный смарт-контракт будет являться следующей последовательностью блоков: 1. Хеджирование 50% суммы; 2. Проверка наличия товара на складе; 3. Отправка 50% суммы предоплаты за товар; 4. Проверка наличия других 50%; 5. Инициация протокола отгрузки товара. 6. Хеджирование других 50% суммы; 7. Отслеживание доставки товара на ваш склад; 8. Двойной апрув сдачи и приемки товара; 9. Перевод денег поставщику. Система создает blockchain и начинает проверку каждого звена: 1. Есть ли деньги у компании клиента? - Есть - Захеджировали (смарт-контракт заглянул в финансовый блокчейн клиента) 2. Есть товар на складе? - Нет (смарт-контракт заглянул" в блокчейн Склад поставщика) https://spark.ru/upload/other/b_59c7f229d50c1.jpg 3. Есть ли товар в каталоге? - Есть (смарт-контракт заглянул" в блокчейн Торговый каталог поставщика) 4. Вероятность появления необходимого количества товара на складе? - Низкая, потому что среднее время производства одной коробки спичек - 1 час (смарт-контракт заглянул" в блокчейн Скорость выполнения задачи сотрудника поставщика). 5. Система дает предупреждение о том, что вероятность выполнения контракта ничтожна, потому что товара нет и произвести его в нужном количестве компания не может. 6. Деньги вернулись клиенту Смарт-контракт расторгнут. Все Вот и вся суть консенсуса - наличие подтверждающего события. Есть событие - контракт запустится, блокчейн создастся, бизнес-процесс пройдет так, как запланировано. И тут еще раз стоило бы рассказать о прогнозировании течения смарт-контракта и блокчейна. Но я все же расскажу об этом в следующей статье. https://spark.ru/upload/other/b_59c7f2c667498.jpg Пока все. Вот такие вот инновационные разработки мы внедряем в BeeQB. Безусловно, что разрабатывать собственное технологическое блокчейн-решение долго и дорого. Но у нас нет выбора. Кстати, осталось 6 дней до завершения preICO. И у вас есть последняя возможность инвестировать в beeqb c крутым бонусом. Подписывайтесь на канал, добавляйтесь в группы и, конечно же, инвестируйте в beeqb.com/ico (http://beeqb.com/ico) Title: Re: Почему вы никогда не запустите свой блокч Post by: Interfer on October 16, 2017, 12:49:26 PM Я вот сколько ни читаю, пока не могу вникнуть в суть смарт-контрактов. Т.е. понятно, что мы неким программным языком пытаемся описать наступление или ненаступление некого события. Если событие наступило - контракт выполнен, нет - нет. Можно прописать несколько более сложных вариаций, к примеру исполнитель сделал 50 процентов работы и ушел в тень. Т.е. получит он там 50 процентов зарплаты (или 30, смотря что в контракте написано).
Но у меня мозгов не хватает как прописать в се разнообразие вариантов и, главное, отследить их каким-то контрактом. Ведь даже в юридической практике могут быть неоднозначные трактования одного и того же события. А тут... Title: Re: Почему вы никогда не запустите свой блокч Post by: beeqb on October 17, 2017, 10:28:22 AM Я вот сколько ни читаю, пока не могу вникнуть в суть смарт-контрактов. Т.е. понятно, что мы неким программным языком пытаемся описать наступление или ненаступление некого события. Если событие наступило - контракт выполнен, нет - нет. Можно прописать несколько более сложных вариаций, к примеру исполнитель сделал 50 процентов работы и ушел в тень. Т.е. получит он там 50 процентов зарплаты (или 30, смотря что в контракте написано). Но у меня мозгов не хватает как прописать в се разнообразие вариантов и, главное, отследить их каким-то контрактом. Ведь даже в юридической практике могут быть неоднозначные трактования одного и того же события. А тут... Безусловно. 100% ситуаций предвидеть невозможно. Мы разделяем контракты на кредитные, товарно-сервисные и долевые. В товарн-сервисных контрактах вы прописываете условия совершения сделки и регламенты ее исполнения. К примеру 50% предоплаты зачисляются до 1 декабря, иначе сделка недействительна. То есть, мы разрабатываем набор правил типа "IF / ELSE". И разумеется, что работа по добавлению свойств контрактам будет бесконечной. Юзкейсы - наше все. |