Bitcoin Forum
May 25, 2024, 07:45:44 AM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: Почему вы никогда не запустите свой блокч  (Read 387 times)
beeqb (OP)
Full Member
***
Offline Offline

Activity: 308
Merit: 100



View Profile
September 24, 2017, 06:48:25 PM
Last edit: September 24, 2017, 07:01:16 PM by beeqb
 #1

​Разработка 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), мы выяснили, что все они имеют одну схожую особенность: один блокчейн.



Это означает, что используя такую платформу для реализации задач 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, который также как и алгоритмы должен быть мультипотоковым.

Но, используя любое из существующих решений мы получаем следующую картинку:



Но картинка должна быть такой:



То есть, у вашей компании есть корневой blockchain (Компания #1). При этом есть блокчейн “сотрудника” (Сотрудник #1 и #2) , в котором записываются его ключевые точки роста: время прихода на работу, поставленные задачи, план продаж, факт продаж, скорость сделки, выплата зарплаты и так далее (Сделка #1 и #2 ...). Некоторые блокчейны имеют двух “господ” и их исходная точка зависит от показателей двух сотрудников.

К примеру Выплата зарплаты:
Продавец получает ЗП в зависимости от цифры, заложенной в смартконтракте, и указанных KPI. Бухгалтер выплачивает зарплату, исходя из суммы, которая рассчитана смарт-контрактом и исходя из наличия средств на счету. То есть, при нулевом значении одной из сторон смарт-контракт не может быть начат, равно как и реализован. При этом результат блокчейна станет частью персонального блокчейна обоих участников и компании.


Инновация №2: Blockchain для Смарт-контрактов, а не смарт-контракт для блокчейна

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



И тут самое время рассказать о future-proofing и future-proofing events, но я оставлю это для еще одной статьи. Подписывайтесь на обновления, лайкайте и будьте в курсе последних новостией нашего блога.

Именно поэтому в BeeQB мы реализовываем три типа смарт-контрактов: товарно-сервисный, кредитный и долевой. Суть контракта исходит из его названия, но есть одно важное уточнение. Компания может использовать автоматические контракты, настроить шаблонные или создать новые. Автоматические контракты (на примере товарно-сервисного смарт-контракта):

Компания продает в розницу телевизоры. Процедура сделки, регулируется государством (количество дней для возврата покупки, срок гарантии, данные на чеке и так далее). Система распознает тип сделки и создает блокчейн сделки на основании такого смарт-контракта. Разумеется, компания может изменить контракт для такого типа сделки, но это уже другая история. Важно то, что блокчейн этой сделки будет инициирован смарт-контрактом и он будет более чем стандартизирован, а следовательно, может считать эталоном для бизнеса и государства.

Существует еще один вопрос, на который следует дать четкий ответ: что инициирует смарт-контракт?

Инновация №3: Proof of Event

Я готов вступить в дискуссию с широкой аудиторией по данному вопросу… Логически-верный вывод предыдущего рассказа заключается в том, что инициатором смарт-контракта, который инициирует блокчейн, должно послужить некое событие.

К примеру, началом корневого блокчейна компании должен послужить смарт-контракт создания этой компании через форму на сайте. При этом предшествующее событие - это клик по кнопке “Создать компанию”.

Казалось бы, “Спасибо Кэп”. Но не так все просто. Для того, чтобы пользователь кликнул на кнопку, пользователь должен быть зарегистрированным пользователем, иметь заполненный профиль и находиться на корневой странице beeqb. Также и в более серьезных задачах. Для того, чтобы клиент мог купить товар, а продавец мог продать товар, должно произойти два события: наличие денег у покупателя, наличие товара у продавца.

Давайте предположим, что вы покупаете у меня тысячу коробок спичек. Я - производственная компания. Мы с вами инициируем смарт-контракт в котором говорим:

Я: Я, поставлю тебе 1000 коробок спичек на протяжении 5 дней, при условии 50% предоплаты и 50% оплаты в момент отгрузки.
Вы: Ок, но предоплата поступит только при наличии товара на складе и готовности к отгрузке.
Я: По рукам.



BeeQB прогнозирует, что данный товарный смарт-контракт будет являться следующей последовательностью блоков:

1. Хеджирование 50% суммы;
2. Проверка наличия товара на складе;
3. Отправка 50% суммы предоплаты за товар;
4. Проверка наличия других 50%;
5. Инициация протокола отгрузки товара.
6. Хеджирование других 50% суммы;
7. Отслеживание доставки товара на ваш склад;
8. Двойной апрув сдачи и приемки товара;
9. Перевод денег поставщику.

Система создает blockchain и начинает проверку каждого звена:

1. Есть ли деньги у компании клиента? - Есть - Захеджировали (смарт-контракт “заглянул” в “финансовый” блокчейн клиента)
2. Есть товар на складе? - Нет (смарт-контракт “заглянул" в блокчейн “Склад” поставщика)



3. Есть ли товар в каталоге? - Есть (смарт-контракт “заглянул" в блокчейн “Торговый каталог” поставщика)
4. Вероятность появления необходимого количества товара на складе? - Низкая, потому что среднее время производства одной коробки спичек - 1 час (смарт-контракт “заглянул" в блокчейн “Скорость выполнения задачи” сотрудника поставщика).
5. Система дает предупреждение о том, что вероятность выполнения контракта ничтожна, потому что товара нет и произвести его в нужном количестве компания не может.
6. Деньги вернулись клиенту… Смарт-контракт расторгнут.

Все… Вот и вся суть консенсуса - наличие подтверждающего события. Есть событие - контракт запустится, блокчейн создастся, бизнес-процесс пройдет так, как запланировано.

И тут еще раз стоило бы рассказать о прогнозировании течения смарт-контракта и блокчейна. Но я все же расскажу об этом в следующей статье.



Пока все. Вот такие вот инновационные разработки мы внедряем в BeeQB. Безусловно, что разрабатывать собственное технологическое блокчейн-решение долго и дорого. Но у нас нет выбора.

Кстати, осталось 6 дней до завершения preICO. И у вас есть последняя возможность инвестировать в beeqb c крутым бонусом.

Подписывайтесь на канал, добавляйтесь в группы и, конечно же, инвестируйте в beeqb.com/ico
Interfer
Full Member
***
Offline Offline

Activity: 350
Merit: 102



View Profile
October 16, 2017, 12:49:26 PM
 #2

Я вот сколько ни читаю, пока не могу вникнуть в суть смарт-контрактов. Т.е. понятно, что мы неким программным языком пытаемся описать наступление или ненаступление некого события. Если событие наступило - контракт выполнен, нет - нет. Можно прописать несколько более сложных вариаций, к примеру исполнитель сделал 50 процентов работы и ушел в тень. Т.е. получит он там 50 процентов зарплаты (или 30, смотря что в контракте написано).

Но у меня мозгов не хватает как прописать в се разнообразие вариантов и, главное, отследить их каким-то контрактом. Ведь даже в юридической практике могут быть неоднозначные трактования одного и того же события. А тут...

beeqb (OP)
Full Member
***
Offline Offline

Activity: 308
Merit: 100



View Profile
October 17, 2017, 10:28:22 AM
 #3

Я вот сколько ни читаю, пока не могу вникнуть в суть смарт-контрактов. Т.е. понятно, что мы неким программным языком пытаемся описать наступление или ненаступление некого события. Если событие наступило - контракт выполнен, нет - нет. Можно прописать несколько более сложных вариаций, к примеру исполнитель сделал 50 процентов работы и ушел в тень. Т.е. получит он там 50 процентов зарплаты (или 30, смотря что в контракте написано).

Но у меня мозгов не хватает как прописать в се разнообразие вариантов и, главное, отследить их каким-то контрактом. Ведь даже в юридической практике могут быть неоднозначные трактования одного и того же события. А тут...

Безусловно. 100% ситуаций предвидеть невозможно. Мы разделяем контракты на кредитные, товарно-сервисные и долевые. В товарн-сервисных контрактах вы прописываете условия совершения сделки и регламенты ее исполнения. К примеру 50% предоплаты зачисляются до 1 декабря, иначе сделка недействительна. То есть, мы разрабатываем набор правил типа "IF / ELSE". И разумеется, что работа по добавлению свойств контрактам будет бесконечной. Юзкейсы - наше все.
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!