Lightning пригоден по сути для микротранзакций и для платежей с известными контрагентами. Получение суммы от неизвестного, либо суммы большей чем открытый канал и все. Идем в основную сеть и снова грузим ее.
К тому же каналы это значит заморозить деньги.
Сотни и тысячи транзакций внутри канала возможны лишь при активном взаимообмене. Односторонние платежи быстро вычерпают канал.
По сути канал это аналог депозитной карточки с банком, причем ущербной ибо на нее банк не может закинуть денег больше чем хозяин сложил изначально.
С шардами интересно, но мастерноды это уход децентрализации.
Есть еще перспективные варианты вместо chain использовать направленный граф типа tangle, но там тоже проблема с объемами хранения не решена.
На начальных этапах было бы хорошо (да и выгодно) ввести поддержку. Простой сервис (можно сказать централизованный) слушающий blockchain и дергающий Joule. Это для первых пользователей. Мол не волнуйтесь даже если никто из chain не дернется ваш сервис все равно вызовут вот с такой ноды.
А если таки никто из майнеров не вызвал? Машина хорошоа когда уже раскочегарилось с сотнями контрактов и желающими их вызвать. Для приложения которому критичен момент вызова и нужны гарантии этого вызова использовать трудновато.
Нет. После указания способа было добавлено в описание алгоритма — возможность каждого покупателя билета заложить key number. Это не даст организатору читить т.к. он не знает этого числа.
Вот тут предлагал вариант для розыгрыша в лотерею. Относительно безопасного.
Комбинация использования blockhash с идеями commit-reveal.
1. На старте организатор задает некое число — ключ которое будет использоваться при розыгрыше. И выдает его хэш (само число до розагрыша закрыто).
2. Для всех покупателей билетов берется blockhash и сохраняется
3. При розыгрыше число выдается организатором и складывается с числами покупателей билетов.
4. результат используется при определении blockhash по которому вычисляется победитель.
Чтобы убрать сомнения в честности организатора каждый может за увеличенную плату тоже забросить свое число (хэш при покупке билета, само число при розыгрыше).
Либо просто купить билет.
Те кто закидывал свое число выдают депозит. При открытии числа депозит возвращается. Билет для них стоит чуть дешевле, чтобы стимулировать выдачу. Если проверяльщик не открывает свое число депозит присоединятеся к розыгрышу из оставшихся. Если организатор не открывает число всем возвращаются деньги.
Мы все строим языки для людей. Основанные в первую очередь на нашем восприятии — звук/вид.
Представим язык для собак или медведей у которых сильно выражено обоняние. Как опИсать столбик чтоб «читающий» носом понял?
Или представьте цивилизацию глубинных осьминогов общающихся электроимпульсами. Что они смогут разглядеть или услышать? Попробуйте выразить слово «завтра».
Запишите феромонами для муравьев понятие «скоро».
И это только для наших близких видов. Можем ли мы реально что-то придумать понятное пришельцам? Сомневаюсь…
Например он прекрасный админ и все работает как надо, но на серверах компании майнит себе в личный кошелек?
В Беларуси был случай, один деятель на сайте завода развесил личные баннеры, но ведь все же работало.
Грань довольно тонкая. Под расписку взял обязательства и будь добр исполнять. Не нравится поищи другое место.
Есть еще вероятность, что более умные не создают профили в соцсетях. Выпускники вузов покруче чаще уезжают за границу, чаще знают языки и регистрируются в facebook/linkedin а не в vk/одноклассники.
Вот с этим есть сомнения. Например переворматирование прекрасно рушит annotate и потом не найдешь (по крайней мере без больших усилий) кто и зачем написал эту строку. Таск другой и как узнать бизнес логику оригинального таска? А уж смена названий переменных это потенциалльно конфликт у разработчиков (было пару раз на моей памяти).
Опять же QA могут быть сильно против ибо регресс. При 100% покрытии тестами еще так сяк, но зазеленить упавшее может потребовать долгого времени.
Не реализация алгоритма, а идея алгоритма. Java для реализации не нужна. По памяти будет оптимальнее C. Выразить идею с алгоритмической сложностью и сложностью по использованию памяти вполне. У Кнута например все на паскале и это не значит, что алгоритмы надо на нем писать.
Есть пачка бонусов которые перевешивают:
1. огромное количество библиотек и реализаций.
Попробуйте навелосипедить свой spring-security c каким-нибудь oauth собственнм сервером и клиентом. Куча багов и без гарантий что дырок нет. Альтернативу @Transactional с нетривиальнм двухфазным коммитом (например БД + Очередь в единой транзакции). Возможно вы напишете свое, но сколько это займет времени. Возможно вы найдете для всего альтернативы, но опять же время на изучение и не меньшее время чтобы все это подружить между собой.
2. сообщество.
Легко найти того, кто знает, делал и есть доки, SO и т.д. Представьте, что у вас ушел 1-2 ключевых разработчика, кто делал ваши велосипеды и потом найдите и пофиксите сложный баг.
3. оттестированно.
Куча проблем за вас решена, причем проблемы в основном транспортного уровня, безопасность и т.п. Туча народу пробежала по граблям и убрала большинство.
4. относительно быстрый старт.
Сделать достаточно сложный проект на spring-boot для быстрого старта как прототип относительно несложно по количеству кода и времени. Самостоятельные попытки найти нужные библиотеки и связать их вместе только для того чтобы быстро показать и выбросить/поменять намного труднее.
Я тут, к моему сожалению, не совсем понял. Хоть и прикладной математик по образованию, но уж больно давно учился.
Если подкините ссылок почитать могу присоединиться к группе «подумать над».
Спасибо.
К тому же каналы это значит заморозить деньги.
Сотни и тысячи транзакций внутри канала возможны лишь при активном взаимообмене. Односторонние платежи быстро вычерпают канал.
По сути канал это аналог депозитной карточки с банком, причем ущербной ибо на нее банк не может закинуть денег больше чем хозяин сложил изначально.
С шардами интересно, но мастерноды это уход децентрализации.
Есть еще перспективные варианты вместо chain использовать направленный граф типа tangle, но там тоже проблема с объемами хранения не решена.
Вот тут предлагал вариант для розыгрыша в лотерею. Относительно безопасного.
Комбинация использования blockhash с идеями commit-reveal.
1. На старте организатор задает некое число — ключ которое будет использоваться при розыгрыше. И выдает его хэш (само число до розагрыша закрыто).
2. Для всех покупателей билетов берется blockhash и сохраняется
3. При розыгрыше число выдается организатором и складывается с числами покупателей билетов.
4. результат используется при определении blockhash по которому вычисляется победитель.
Чтобы убрать сомнения в честности организатора каждый может за увеличенную плату тоже забросить свое число (хэш при покупке билета, само число при розыгрыше).
Либо просто купить билет.
Те кто закидывал свое число выдают депозит. При открытии числа депозит возвращается. Билет для них стоит чуть дешевле, чтобы стимулировать выдачу. Если проверяльщик не открывает свое число депозит присоединятеся к розыгрышу из оставшихся. Если организатор не открывает число всем возвращаются деньги.
Представим язык для собак или медведей у которых сильно выражено обоняние. Как опИсать столбик чтоб «читающий» носом понял?
Или представьте цивилизацию глубинных осьминогов общающихся электроимпульсами. Что они смогут разглядеть или услышать? Попробуйте выразить слово «завтра».
Запишите феромонами для муравьев понятие «скоро».
И это только для наших близких видов. Можем ли мы реально что-то придумать понятное пришельцам? Сомневаюсь…
В Беларуси был случай, один деятель на сайте завода развесил личные баннеры, но ведь все же работало.
Грань довольно тонкая. Под расписку взял обязательства и будь добр исполнять. Не нравится поищи другое место.
Вот с этим есть сомнения. Например переворматирование прекрасно рушит annotate и потом не найдешь (по крайней мере без больших усилий) кто и зачем написал эту строку. Таск другой и как узнать бизнес логику оригинального таска? А уж смена названий переменных это потенциалльно конфликт у разработчиков (было пару раз на моей памяти).
Опять же QA могут быть сильно против ибо регресс. При 100% покрытии тестами еще так сяк, но зазеленить упавшее может потребовать долгого времени.
Может если учить чайников, так хорошему?
1. огромное количество библиотек и реализаций.
Попробуйте навелосипедить свой spring-security c каким-нибудь oauth собственнм сервером и клиентом. Куча багов и без гарантий что дырок нет. Альтернативу @Transactional с нетривиальнм двухфазным коммитом (например БД + Очередь в единой транзакции). Возможно вы напишете свое, но сколько это займет времени. Возможно вы найдете для всего альтернативы, но опять же время на изучение и не меньшее время чтобы все это подружить между собой.
2. сообщество.
Легко найти того, кто знает, делал и есть доки, SO и т.д. Представьте, что у вас ушел 1-2 ключевых разработчика, кто делал ваши велосипеды и потом найдите и пофиксите сложный баг.
3. оттестированно.
Куча проблем за вас решена, причем проблемы в основном транспортного уровня, безопасность и т.п. Туча народу пробежала по граблям и убрала большинство.
4. относительно быстрый старт.
Сделать достаточно сложный проект на spring-boot для быстрого старта как прототип относительно несложно по количеству кода и времени. Самостоятельные попытки найти нужные библиотеки и связать их вместе только для того чтобы быстро показать и выбросить/поменять намного труднее.
Закономерности некоторые наблюдаются… но чего-то не хватает. И как доказывать я увы…
Если подкините ссылок почитать могу присоединиться к группе «подумать над».
Спасибо.