Это просто "прокаченная" версия солидити для работы в асинхронной системе с акторной моделью. Зачем такая система? Тут тоже все просто, масштабируются такие системы оч легко, в отличие от синхронных
Ты либо идешь по пути эфира, на котором просто разрабатывать, т.к он синхронный и тд, но при этом super slow, а масштабирование решается тонной L2, либо идешь по пути изначально масштабируемой системы за счет асинхронности, но в ответ получаешь по лицу сложностью разработки )))
Приходить к оптимизации путем распараллеливания конечно же надо только после того, как все остальные средства исчерпаны и статья именно об этом, полностью согласен. Но методы, описываемые в статье, по большей части рассчитаны на уменьшение оверхеда некоторых функций пандас (например iterrows ) и если основная нагрузка находится в вычислениях, а не в итерации, то замена на тот же itertuples может не спасти
Да, вы правы, на 1ом графике разница кажется небольшой, хотя на самом деле порядки величин отличаются очень сильно. Я попытался как-то сгладить этот момент, добавив числа, но толку видимо немного.Для того же графика Numba без логарифмической шкалы его результат был просто полоской снизу
On Windows, Pandaral·lel will works only if the Python session (python, ipython, jupyter notebook, jupyter lab, ...) is executed from Windows Subsystem for Linux (WSL).
Ну, сетевая операция здесь просто пример, хотя да, возможно не самый лучший. Речь скорее о каких-нибудь cpu-bound операциях — можно представить что там идет подсчет факториала или что-то в этом духе. Тогда ядра действительно будут использованы
С своих примерах я ограничиваю максимальное число токенов до 2, чтобы они не скапливались именно во избежание такого кейса. Вот кусок кода из статьи:
# 1 очередь под сами таски и 1 очередь под токены для них
app.conf.task_queues = [
Queue('github'),
# я ограничил длину очереди до 2ух, чтобы токены не скапливались
# иначе это может привести к пробою нашего rate limit'a
Queue('github_tokens', max_length=2)
]
Но, как я и сказал в конце, принцип скапливаемости может наоборот стать фишкой ;)
Так что абсолютно любой программист хотя бы уровня джуниора сможет разобраться в нем. Абсолютно нет смысла платить огромные деньги разработчикам, которые знают солидити — обучить уже существующего разработчика будет на порядок дешевле.
Мало уметь писать на солидити. Надо также хорошо понимать принципы работы блокчейна и ообенности работы EVM. Если смарт-контракт представляет из себя что-то сложнее чем ERC-20 токен, то код, написанный опытным разработчиком, с высокой вероятностью будет как надежнее, так и эффективнее (не будем забывать, что хранение каждого байта стоит денег).
1. Это, конечно же, так. Канал стоит открывать только под долгосрочное пользование.
2. Не могу не согласиться, LN действительно может привести к централизации — рядовой пользователь сети не станет использовать крупные суммы в каналах.
P.s. Статья не скрывает проблемы, которые LN имеет) главной целью был разбор работы, нежели демонстрация преимуществ. Анализ плюсов/минусов использования, а также экономической стороны LN это тема для отдельной большой статьи ;)
В продолжение предыдущего ответа:
3. Witness data для траты транзакции это тот же самый scriptSig (например, signature + public key в случае P2WPKH).
4. На данный момент для каждого входа транзакции проводится следующая процедура:
4.1. Все входы удаляются, это происходит за O(n).
4.2. На место текущего проверяемого входа вставляется subScript (это locking script выхода, который мы тратим).
4.3. Берется двойной SHA-256 хеш и сравнивается с предоставленной подпиьсю при помощи публичного для проверки корректности.
Так как имеем n входов, получаем итоговую сложность в O(n^2), что может вылиться в очень долгое время валидации (транзакция, время валидации которой составляет 25 сек. из-за большого кол-ва входов). Сегвит решает эту проблему изменяя способ хеширования транзакции таким образом, что каждый байт транзакции будет хеширован не более 2ух раз.
Хорошие вопросы! Итак, по порядку:
1. Поле witness отделяется от транзакции. Вся witness-data хранится в отдельном merkle tree как и транзакции и является частью блока. Также стоит заметить, что witness merkle tree root не включается в заголовок блока — он содержится в выходе coinbase транзакции как дополнительные данные, после OP_RETURN.
2. Количество хранимых данных действительно уменьшается. Подписи нужны только для проведения полной валидации, поэтому, например, для новой ноды, которая только начинает синхронизировать блокчейн, отсутствует необходимость загружать witness данные для старых блоков, так как она не будет проверять их на валидность (проверять будут только некоторое число последних блоков).
Это просто "прокаченная" версия солидити для работы в асинхронной системе с акторной моделью. Зачем такая система? Тут тоже все просто, масштабируются такие системы оч легко, в отличие от синхронных
Ты либо идешь по пути эфира, на котором просто разрабатывать, т.к он синхронный и тд, но при этом super slow, а масштабирование решается тонной L2, либо идешь по пути изначально масштабируемой системы за счет асинхронности, но в ответ получаешь по лицу сложностью разработки )))
Но, как я и сказал в конце, принцип скапливаемости может наоборот стать фишкой ;)
Мало уметь писать на солидити. Надо также хорошо понимать принципы работы блокчейна и ообенности работы EVM. Если смарт-контракт представляет из себя что-то сложнее чем ERC-20 токен, то код, написанный опытным разработчиком, с высокой вероятностью будет как надежнее, так и эффективнее (не будем забывать, что хранение каждого байта стоит денег).
2. Не могу не согласиться, LN действительно может привести к централизации — рядовой пользователь сети не станет использовать крупные суммы в каналах.
P.s. Статья не скрывает проблемы, которые LN имеет) главной целью был разбор работы, нежели демонстрация преимуществ. Анализ плюсов/минусов использования, а также экономической стороны LN это тема для отдельной большой статьи ;)
3. Witness data для траты транзакции это тот же самый scriptSig (например, signature + public key в случае P2WPKH).
4. На данный момент для каждого входа транзакции проводится следующая процедура:
4.1. Все входы удаляются, это происходит за O(n).
4.2. На место текущего проверяемого входа вставляется subScript (это locking script выхода, который мы тратим).
4.3. Берется двойной SHA-256 хеш и сравнивается с предоставленной подпиьсю при помощи публичного для проверки корректности.
Так как имеем n входов, получаем итоговую сложность в O(n^2), что может вылиться в очень долгое время валидации (транзакция, время валидации которой составляет 25 сек. из-за большого кол-ва входов). Сегвит решает эту проблему изменяя способ хеширования транзакции таким образом, что каждый байт транзакции будет хеширован не более 2ух раз.
1. Поле witness отделяется от транзакции. Вся witness-data хранится в отдельном merkle tree как и транзакции и является частью блока. Также стоит заметить, что witness merkle tree root не включается в заголовок блока — он содержится в выходе coinbase транзакции как дополнительные данные, после OP_RETURN.
2. Количество хранимых данных действительно уменьшается. Подписи нужны только для проведения полной валидации, поэтому, например, для новой ноды, которая только начинает синхронизировать блокчейн, отсутствует необходимость загружать witness данные для старых блоков, так как она не будет проверять их на валидность (проверять будут только некоторое число последних блоков).