Bitcoin Forum
May 11, 2024, 01:02:02 PM *
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
The network tries to produce one block per 10 minutes. It does this by automatically adjusting how difficult it is to produce blocks.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
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!