Base: ждем дроп в этом году?
Пока рынок штормит вкину немного позитива и напомнить о том, что на медвежкках были одни из самых легендарных дропов (Uniswap, Celestia, Optimism, Arbitrum, BONK, DYDX).
Думаю, что у Base будет та же участь выйти на падающем рынке, но раздадут они хорошую котлетку.
Сейчас Coindesk закладывает TGE Base на Q2-Q4 с минимальным FDV в 10В$+, что звучит очень bullish.
Я начинал отрабатывать Base еще со времен LZ, ZK, STRK и вот на что сейчас я делаю упор, дабы попасть под дроп.
> Нативный контент в Х о проекте
> Активность в BaseApp
> Взаимодействие с их обширной экосистемой
> Квесты в Guild
> Для кодеров, запилить свою апку
Думаю, всего вышеперечисленного будет достаточно, чтобы хоть как-то выделиться среди миллионов сибиллов.
Кстати, недавно Base добавили в черекер на Layerhub, по ссылке можно чекнуть свой топ и помечтать о дропе.
Чат | Support | Market
Pelican | HiddenCode [EN]
📟 Прилетело из @hidden_coding
Пока рынок штормит вкину немного позитива и напомнить о том, что на медвежкках были одни из самых легендарных дропов (Uniswap, Celestia, Optimism, Arbitrum, BONK, DYDX).
Думаю, что у Base будет та же участь выйти на падающем рынке, но раздадут они хорошую котлетку.
Сейчас Coindesk закладывает TGE Base на Q2-Q4 с минимальным FDV в 10В$+, что звучит очень bullish.
Я начинал отрабатывать Base еще со времен LZ, ZK, STRK и вот на что сейчас я делаю упор, дабы попасть под дроп.
> Нативный контент в Х о проекте
> Активность в BaseApp
> Взаимодействие с их обширной экосистемой
> Квесты в Guild
> Для кодеров, запилить свою апку
Думаю, всего вышеперечисленного будет достаточно, чтобы хоть как-то выделиться среди миллионов сибиллов.
Кстати, недавно Base добавили в черекер на Layerhub, по ссылке можно чекнуть свой топ и помечтать о дропе.
Чат | Support | Market
Pelican | HiddenCode [EN]
📟 Прилетело из @hidden_coding
Алгоритмы. Быстрая сортировка
Быстрая сортировка представляет собой эффективный алгоритм, основанный на стратегии «разделяй и властвуй». Представьте себе задачу упорядочить книги на полке по высоте. Вместо того чтобы последовательно сравнивать каждую книгу с каждой, что потребовало бы значительного времени, можно выбрать одну книгу среднего размера в качестве условного эталона. Все книги меньше этого эталона помещаются слева, а все больше — справа. Затем эта же процедура рекурсивно применяется к каждой из образовавшихся групп. Именно эта идея лежит в основе быстрой сортировки.
Алгоритм работает, разделяя исходный массив данных на части относительно специально выбранного элемента, который называется опорным или пивотом. Стратегия «разделяй и властвуй» подразумевает три этапа: сначала большую задачу разбивают на меньшие независимые подзадачи, затем каждую из них решают, и наконец, полученные решения объединяют в окончательный результат. Этот процесс можно представить как преобразование большого беспорядка в несколько маленьких, которые затем приводятся в порядок.
Рассмотрим работу алгоритма пошагово на примере массива
Второй шаг — разделение массива. Все элементы, меньшие опорного, помещаются в одну группу, равные ему — в другую, а большие — в третью.
Наглядно это можно изобразить так:
Третий шаг — рекурсивное применение того же алгоритма к левой и правой частям, так как группа равных опорному элементу уже считается отсортированной. Для левой части
Четвертый шаг — объединение результатов. После того как все рекурсивные вызовы завершены, отсортированные части собираются вместе. Сборка происходит снизу вверх: отсортированные подмассивы меньших размеров объединяются с опорными элементами.
Полное дерево рекурсии для данного примера выглядит следующим образом:
Сборка снизу вверх:
Реализация этого алгоритма на Python демонстрирует его лаконичность. Ключевая часть — рекурсивное разделение и объединение массивов.
📟 Прилетело из @solidityset
Быстрая сортировка представляет собой эффективный алгоритм, основанный на стратегии «разделяй и властвуй». Представьте себе задачу упорядочить книги на полке по высоте. Вместо того чтобы последовательно сравнивать каждую книгу с каждой, что потребовало бы значительного времени, можно выбрать одну книгу среднего размера в качестве условного эталона. Все книги меньше этого эталона помещаются слева, а все больше — справа. Затем эта же процедура рекурсивно применяется к каждой из образовавшихся групп. Именно эта идея лежит в основе быстрой сортировки.
Алгоритм работает, разделяя исходный массив данных на части относительно специально выбранного элемента, который называется опорным или пивотом. Стратегия «разделяй и властвуй» подразумевает три этапа: сначала большую задачу разбивают на меньшие независимые подзадачи, затем каждую из них решают, и наконец, полученные решения объединяют в окончательный результат. Этот процесс можно представить как преобразование большого беспорядка в несколько маленьких, которые затем приводятся в порядок.
Рассмотрим работу алгоритма пошагово на примере массива
[64, 34, 25, 12, 22, 11, 90]. Первым шагом является выбор опорного элемента. Это может быть первый, последний, средний или случайный элемент массива. В нашем примере выберем средний элемент по индексу: arr[3] = 12.Второй шаг — разделение массива. Все элементы, меньшие опорного, помещаются в одну группу, равные ему — в другую, а большие — в третью.
Меньше 12: [11]
Равно 12: [12]
Больше 12: [64, 34, 25, 22, 90]
Наглядно это можно изобразить так:
[64, 34, 25, 12, 22, 11, 90]
↓
выбираем pivot = 12
↓
┌─────────────────┼─────────────────┐
↓ ↓ ↓
[11] [12] [64, 34, 25, 22, 90]
(меньше) (равно) (больше)
Третий шаг — рекурсивное применение того же алгоритма к левой и правой частям, так как группа равных опорному элементу уже считается отсортированной. Для левой части
[11], состоящей из одного элемента, рекурсия завершается. Для правой части [64, 34, 25, 22, 90] снова выбирается опорный элемент, например, средний — 25, и процесс разделения повторяется.Четвертый шаг — объединение результатов. После того как все рекурсивные вызовы завершены, отсортированные части собираются вместе. Сборка происходит снизу вверх: отсортированные подмассивы меньших размеров объединяются с опорными элементами.
Уровень 4: [] + [64] + [90] = [64, 90]
Уровень 3: [] + [34] + [64, 90] = [34, 64, 90]
Уровень 2: [22] + [25] + [34, 64, 90] = [22, 25, 34, 64, 90]
Уровень 1: [11] + [12] + [22, 25, 34, 64, 90] = [11, 12, 22, 25, 34, 64, 90]
Полное дерево рекурсии для данного примера выглядит следующим образом:
[64, 34, 25, 12, 22, 11, 90]
pivot=12
/ | \
[11] [12] [64, 34, 25, 22, 90]
↓ pivot=25
[11] / | \
[22] [25] [64, 34, 90]
↓ pivot=34
[22] / | \
[] [34] [64, 90]
pivot=64
/ | \
[] [64] [90]
↓
[90]
Сборка снизу вверх:
[11] + [12] + ([22] + [25] + ([] + [34] + ([] + [64] + [90])))
= [11, 12, 22, 25, 34, 64, 90]
Реализация этого алгоритма на Python демонстрирует его лаконичность. Ключевая часть — рекурсивное разделение и объединение массивов.
📟 Прилетело из @solidityset
def quick_sort(arr):
"""Быстрая сортировка списка."""
# Базовый случай: массив из 0 или 1 элемента уже отсортирован
if len(arr) <= 1:
return arr
else:
# Выбираем опорный элемент (средний по индексу)
pivot = arr[len(arr) // 2]
# Создаём три подмассива:
# left - все элементы меньше опорного
left = [x for x in arr if x < pivot]
# middle - все элементы равные опорному
middle = [x for x in arr if x == pivot]
# right - все элементы больше опорного
right = [x for x in arr if x > pivot]
# Рекурсивно сортируем левую и правую части,
# объединяем результаты
return quick_sort(left) + middle + quick_sort(right)
Наличие группы
middle в реализации принципиально важно для корректной обработки массивов с повторяющимися элементами. Без неё алгоритм может попасть в бесконечную рекурсию, пытаясь сортировать одинаковые значения.Производительность быстрой сортировки в первую очередь зависит от выбора опорного элемента. Хороший выбор, когда пивот делит массив примерно пополам, приводит к временной сложности O(n log n) в лучшем и среднем случаях. Это происходит потому, что глубина рекурсии составляет log n уровней, и на каждом уровне выполняется порядка n операций. Однако если опорный элемент постоянно оказывается минимальным или максимальным, дерево рекурсии становится несбалансированным, что приводит к худшему случаю со сложностью O(n²). Для улучшения выбора пивота применяют такие методы, как случайный выбор или выбор медианы из трех элементов — первого, среднего и последнего. Например:
import random
pivot = arr[random.randint(0, len(arr)-1)]
Пространственная сложность представленной реализации составляет O(n), так как на каждом уровне рекурсии создаются новые списки. Однако существует оптимизированная версия алгоритма, выполняющая сортировку на месте, которая требует O(log n) дополнительной памяти для стека рекурсии.
Сравнение быстрой сортировки с сортировкой слиянием выявляет их ключевые различия. Оба алгоритма имеют среднюю сложность O(n log n), но сортировка слиянием гарантирует эту сложность даже в худшем случае, тогда как быстрая сортировка может деградировать до O(n²). С другой стороны, быстрая сортировка часто оказывается быстрее на практике из-за меньших константных множителей и может быть реализована с меньшим потреблением памяти. Сортировка слиянием является стабильной — она сохраняет относительный порядок равных элементов, что не всегда верно для классической in-place реализации быстрой сортировки.
Встроенная функция
sort() в Python использует более сложный гибридный алгоритм — Timsort. Он сочетает в себе идеи сортировки слиянием и сортировки вставками. Timsort эффективно использует уже существующие упорядоченные подпоследовательности в данных, что делает его особенно быстрым для частично отсортированных массивов, где он может достигать сложности O(n). Этот алгоритм является стабильным и гарантирует производительность O(n log n) в худшем случае, что делает его отличным выбором для стандартной библиотеки Python. Пример его использования:data = [64, 34, 25, 12, 22, 11, 90]
data.sort()
sorted_data = sorted(data, reverse=True)
Таким образом, быстрая сортировка остается важным и фундаментальным алгоритмом, наглядно демонстрирующим принцип «разделяй и властвуй». Она эффективна на практике, хотя и требует внимательного подхода к выбору опорного элемента. Для большинства повседневных задач предпочтительнее использовать оптимизированные встроенные средства языка, такие как Timsort в Python, но глубокое понимание работы быстрой сортировки необходимо для анализа алгоритмов и решения специализированных задач.
#algorithm
📟 Прилетело из @solidityset
Show Me Your AI Setup
Сегодня в 19:00 по Москве (через ~1.5 часа) будет стрим с @og_mishgun
Я буду задавать вопросы: что пробовал, что реально работает, что дальше.
Будем импровизировать, будет лампово.
Накидывайте вопросы в комменты
📟 Прилетело из @danokhlopkov
Please open Telegram to view this post
VIEW IN TELEGRAM
Radiant: взлом, после которого я перестал верить в "проверенные" протоколы
Я уже писал про взлом Radiant сразу после события. Сейчас — о том, какие выводы пришлось сделать спустя время.
Часть дропа $ARB я оставил и, когда цена просела, решил положить их в Radiant. Это оказалось серьёзной ошибкой.
Если бы я просто ничего не делал.
Они были бы у меня до сих пор.
Это ещё раз подтвердило моё мнение: самой надёжной стратегией часто оказывается лень ☺️.
Теперь остаётся ждать компенсации, если она вообще будет.
Про Radiant я отдельно не писал и не разбирал его - он упоминался у меня только в контексте LayerZero (в начале поддерживали кроссчейн кредитование).
Не проанализировать - это оказался ещё один промах. На тот момент это была ощутимая для моего портфеля сумма, и именно поэтому сейчас этот опыт так отрезвляет.
Тогда меня удивило, что взлом произошёл спустя два года после запуска.
А когда позже начали взламываться "старики" вроде Balancer, стало ясно: возраст в DeFi больше не аргумент.
Что я усвоил после этого события:
1. Всегда стоит изучать проект хотя бы по формализованному подходу. Например, который я описывал ранее.
Благо сейчас есть ИИ-модели. Можно делегировать первичный сбор информации им, а затем проверять источники вручную.
2. Для себя я создал правило: не вкладывать больше 1-2% портфеля в один протокол. Больше - существенный риск потерять. Если бы нашёл 5-10 проектов, не произошло бы этого или потери были бы меньше.
3. Потом уже прочитал, и с этим согласен:
Для диверсификации важно выбирать не просто «хорошие» проекты, а проекты с уникальной основой.
Иначе можно распределить капитал по форкам (клонам) - и потерять всё из-за одной и той же уязвимости.
Представьте, что я бы выбрал 10 проектов на основе Radiant (таки не существует, но это гипотетическая ситуация). Их бы все взломали из-за того, что они - форки (если не исправили уязвимость, но это редко). И я бы все равно потерял средства.
А вы теряли деньги из-за взломов?
Были ли случаи, когда диверсификация по форкам не спасла, а наоборот - усилила потери?
😎 Незрячий web3 программист (подписаться)
Чат | бот
📟 Прилетело из @blind_dev
Я уже писал про взлом Radiant сразу после события. Сейчас — о том, какие выводы пришлось сделать спустя время.
Часть дропа $ARB я оставил и, когда цена просела, решил положить их в Radiant. Это оказалось серьёзной ошибкой.
Если бы я просто ничего не делал.
Они были бы у меня до сих пор.
Это ещё раз подтвердило моё мнение: самой надёжной стратегией часто оказывается лень ☺️.
Теперь остаётся ждать компенсации, если она вообще будет.
Про Radiant я отдельно не писал и не разбирал его - он упоминался у меня только в контексте LayerZero (в начале поддерживали кроссчейн кредитование).
Не проанализировать - это оказался ещё один промах. На тот момент это была ощутимая для моего портфеля сумма, и именно поэтому сейчас этот опыт так отрезвляет.
Тогда меня удивило, что взлом произошёл спустя два года после запуска.
А когда позже начали взламываться "старики" вроде Balancer, стало ясно: возраст в DeFi больше не аргумент.
Что я усвоил после этого события:
1. Всегда стоит изучать проект хотя бы по формализованному подходу. Например, который я описывал ранее.
Благо сейчас есть ИИ-модели. Можно делегировать первичный сбор информации им, а затем проверять источники вручную.
2. Для себя я создал правило: не вкладывать больше 1-2% портфеля в один протокол. Больше - существенный риск потерять. Если бы нашёл 5-10 проектов, не произошло бы этого или потери были бы меньше.
3. Потом уже прочитал, и с этим согласен:
Для диверсификации важно выбирать не просто «хорошие» проекты, а проекты с уникальной основой.
Иначе можно распределить капитал по форкам (клонам) - и потерять всё из-за одной и той же уязвимости.
Представьте, что я бы выбрал 10 проектов на основе Radiant (таки не существует, но это гипотетическая ситуация). Их бы все взломали из-за того, что они - форки (если не исправили уязвимость, но это редко). И я бы все равно потерял средства.
А вы теряли деньги из-за взломов?
Были ли случаи, когда диверсификация по форкам не спасла, а наоборот - усилила потери?
😎 Незрячий web3 программист (подписаться)
Чат | бот
📟 Прилетело из @blind_dev
Всем спасибо 🙂
Ставьте реакцию, если хотите еще
и предлагайте, с кем провести следующий стрим
подписывайтесь на Мишу @og_mishgun и добавляйтесь к нам в чат
Запись есть!
📟 Прилетело из @danokhlopkov
Ставьте реакцию, если хотите еще
и предлагайте, с кем провести следующий стрим
подписывайтесь на Мишу @og_mishgun и добавляйтесь к нам в чат
Запись есть!
📟 Прилетело из @danokhlopkov
Пара слов о моем проекте
Нельзя недооценивать силу ранних запусков, бета тестирования и обратной связи. В наши дни достаточно легко создать быстро проект, купить домен и выпустить его в мир, однако все нужно тратить время на его "обкатку". И я тому достаточно показательный пример.
Когда ты создаешь сайт / приложение / контракт, то явно понимаешь, как его нужно использовать, что вводить и куда нажимать (особенно, если важен порядок действий). Но все меняется когда ты даешь доступ пользователям.
Я тоже явно представлял, что нужно вводить и как делать запросы, чтобы получать результаты. Но то, что у меня в голове было логически обоснованным, оказалось совершенно не понятно с внешнего взгляда.
Прежде всего, была не достаточно ясно подчеркнута идея самого проекта. Хоть и были несколько надписей и на главной странице, и внутри сайта, что это не анализатор, а поиск по базе данных, многие упорно пытались получить результаты анализа своего проекта или контракта.
Функция чата определенно сбивала с толку. Мы все привыкли, что можно ввести какое-нибудь сообщение, chatGPT поймет намеренье и выдаст нужную (или около-нужную информацию). Тут было также. Не смотря на то, что это MCP/API сервер предназначенный для использования вместе с нейронками (чтобы они сами формировали запроси и делали анализ), многие также не доходили до установки этого сервера, заканчивая свой путь на первом запросе чата.
Кроме того, оказалось, что многие также не понимают работу семантического поиска.
В итоге оказалось, что UI/UX не приспособлен для передачи идеи проекта и его нужно менять, чем я потихоньку и занимаюсь.
Прежде всего, была обновлена главная страница, которая теперь четко говорит назначение проекта. Опять же на мой взгляд. Буду тестировать сообщение. Если будут сомнения - буду снова экспериментировать.
Также обновлена форма для чата. Вместо одного поля, теперь два: одно для запроса, другое для функций. Оба поля получили более описательные placeholder.
В планах, сделать более просто навигацию (хотя думал, что разбитие по вкладкам будет удачным решением...), а также добавить пару других режимов в чате, чтобы модель llm могла корректировать запросы пользователей, делая их более подходящими для релевантного поиска.
В общем, всем большое спасибо за обратную связь!
#hornetmcp
📟 Прилетело из @solidityset
Нельзя недооценивать силу ранних запусков, бета тестирования и обратной связи. В наши дни достаточно легко создать быстро проект, купить домен и выпустить его в мир, однако все нужно тратить время на его "обкатку". И я тому достаточно показательный пример.
Когда ты создаешь сайт / приложение / контракт, то явно понимаешь, как его нужно использовать, что вводить и куда нажимать (особенно, если важен порядок действий). Но все меняется когда ты даешь доступ пользователям.
Я тоже явно представлял, что нужно вводить и как делать запросы, чтобы получать результаты. Но то, что у меня в голове было логически обоснованным, оказалось совершенно не понятно с внешнего взгляда.
Прежде всего, была не достаточно ясно подчеркнута идея самого проекта. Хоть и были несколько надписей и на главной странице, и внутри сайта, что это не анализатор, а поиск по базе данных, многие упорно пытались получить результаты анализа своего проекта или контракта.
Функция чата определенно сбивала с толку. Мы все привыкли, что можно ввести какое-нибудь сообщение, chatGPT поймет намеренье и выдаст нужную (или около-нужную информацию). Тут было также. Не смотря на то, что это MCP/API сервер предназначенный для использования вместе с нейронками (чтобы они сами формировали запроси и делали анализ), многие также не доходили до установки этого сервера, заканчивая свой путь на первом запросе чата.
Кроме того, оказалось, что многие также не понимают работу семантического поиска.
В итоге оказалось, что UI/UX не приспособлен для передачи идеи проекта и его нужно менять, чем я потихоньку и занимаюсь.
Прежде всего, была обновлена главная страница, которая теперь четко говорит назначение проекта. Опять же на мой взгляд. Буду тестировать сообщение. Если будут сомнения - буду снова экспериментировать.
Также обновлена форма для чата. Вместо одного поля, теперь два: одно для запроса, другое для функций. Оба поля получили более описательные placeholder.
В планах, сделать более просто навигацию (хотя думал, что разбитие по вкладкам будет удачным решением...), а также добавить пару других режимов в чате, чтобы модель llm могла корректировать запросы пользователей, делая их более подходящими для релевантного поиска.
В общем, всем большое спасибо за обратную связь!
#hornetmcp
📟 Прилетело из @solidityset
Opinion airdrop, кто следующий?
Вот уже и первый аирдроп в мете предиктов дождались. Вчера Opinion открыл возможность добавить кошельки для распределения дропа.
> https://app.opinion.trade/points
Polymarket и Kalshi будут долго тянуть с выходом, в то время, как проекты по типу Opinion будут выходить и передтягивать одеяло на себя.
Лично я Opinion не фармил, но для тех, кто отрабатывал это отличные новости. А для тех, кто только хочет войти в эту мету я выделяю два проекта.
PredictFun
> Идем на сайт и коннектимся кошельком
> Делаем депозит в предложенных сетях и ставим на события
> Стараемся фармить лимитками и вилковать с другими предикшенами
> Приглашаем друзей
Probable
> Идем по ссылке и подключаем свой кошелек
> Делаем депозит в любой из предложенных сетей и ставим на события
> Приглашаем друзей и фармим роли в ДС
Сейчас делаю большую ставку на PredictFun и по возможности цепляю Probable (пока мало ликвидный).
Уверен, что если Opinion покажет хороший результат, конкуренция резко возрастет, поэтому включаемся уже сейчас.
Чат | Support | Market
Pelican | HiddenCode [EN]
📟 Прилетело из @hidden_coding
Вот уже и первый аирдроп в мете предиктов дождались. Вчера Opinion открыл возможность добавить кошельки для распределения дропа.
> https://app.opinion.trade/points
Polymarket и Kalshi будут долго тянуть с выходом, в то время, как проекты по типу Opinion будут выходить и передтягивать одеяло на себя.
Лично я Opinion не фармил, но для тех, кто отрабатывал это отличные новости. А для тех, кто только хочет войти в эту мету я выделяю два проекта.
PredictFun
> Идем на сайт и коннектимся кошельком
> Делаем депозит в предложенных сетях и ставим на события
> Стараемся фармить лимитками и вилковать с другими предикшенами
> Приглашаем друзей
Probable
> Идем по ссылке и подключаем свой кошелек
> Делаем депозит в любой из предложенных сетей и ставим на события
> Приглашаем друзей и фармим роли в ДС
Сейчас делаю большую ставку на PredictFun и по возможности цепляю Probable (пока мало ликвидный).
Уверен, что если Opinion покажет хороший результат, конкуренция резко возрастет, поэтому включаемся уже сейчас.
Чат | Support | Market
Pelican | HiddenCode [EN]
📟 Прилетело из @hidden_coding
#OxygenDelta #predictions #обновления
Мы обновили Oxygen Delta. Это тот случай, когда апдейт реально меняет ежедневное использование.
💪 Улучшенный метчинг событий (+70%)
Самое важное: мы прокачали систему сопоставления одинаковых событий между площадками.
Теперь метчи стали точнее, в среднем +70% совпадений.
Мы добавили анализ правил маркетов через Grok AI. Он сравнивает формулировки, условия расчёта и нюансы исходов.
🔜 Фильтр по дате исхода
Добавили фильтр по сроку завершения события:
теперь ты можешь показывать только те маркеты, которые заканчиваются не позже N дней.
Это удобно, если ты:
— не хочешь держать позиции месяцами
— работаешь под быстрый оборот
— выбираешь события с понятным дедлайном
📊 Фильтр по объёму
Ещё один фильтр, который экономит время:
можно скрыть маркеты, где объём меньше заданного.
Для больших ордеров это must-have: меньше пустых стаканов, меньше слиппеджа.
🙃 Полностью новый дизайн
Мы изменили интерфейс и логику отображения:
— быстрее читается
— проще фильтровать
— удобнее сравнивать площадки и спреды
В скором времени так же обновим страницу Tools.
https://oxygendelta.com
https://oxygendelta.com
https://oxygendelta.com
Пишите, какие фильтры добавить следующими.
📟 Прилетело из @oxygen_tools
Please open Telegram to view this post
VIEW IN TELEGRAM
И СНОВА НА РАБОТУ | WEB3 EDITION
pt.2
продолжаем наш последний пост
1. ФРЕЙМВОРКИ И ИНСТРУМЕНТЫ
ETHEREUM
Библиотеки:
PYTHON
web3py.readthedocs.io/en/stable - Python-библиотека для взаимодействия с Ethereum: чтение блоков, контракты, события, отправка транзакций и так далее
SOLIDITY
docs.openzeppelin.com/contracts - библиотека проверенных реализаций стандартных контрактов: токены, доступы, прокси, утилиты и так далее
ЭТО ДЕ-ФАКТО СТАНДАРТ ИНДУСТРИИ В WEB3
Фреймворки:
hardhat.org - среда для сборки, тестирования и деплоя контрактов.
SOLANA
Библиотеки:
PYTHON
github.com/michaelhly/solana-py - Python SDK для JSON-RPC, сборка/отправка транзакций, SPL Token операции на уровне Python.
github.com/kevinheavey/solders - обычно используют: solana-py для сети/async + solders для типов/подписей. В официальных community-заметках прямо так и рекомендуют: solders (core), solana-py (networking/async).
Фреймворки:
anchor-lang.com/docs - главный фреймворк для Solana-программ.
Сильно упрощает написание, тестирование и деплой Solana-программ + даёт готовый клиент для работы с ними.
КУРСЫ
ETHEREUM
ethereum.org/learn
speedrunethereum.com
SOLANA
solana.com/developers
ПРОДОЛЖАЕМ?
АКТВИРУЕМ НОВЫЕ РЕАКЦИИ, ЧТОБЫ ПРОДОЛЖИТЬ
📟 Прилетело из @code_vartcall
pt.2
продолжаем наш последний пост
1. ФРЕЙМВОРКИ И ИНСТРУМЕНТЫ
ETHEREUM
Библиотеки:
JAVASCRIPT / TYPESCRIPT
viem.sh - TypeScript-first библиотека для работы с Ethereum. Создана как быстрая, строготипизированная и безопасная замена ethers.js для фронтенда.
Используется внутри wagmi, RainbowKit и Reown AppKit (новая замена Web3Modal)
docs.ethers.org/v5 - самая популярная JS-библиотека для работы с Ethereum контрактами, транзакциями, подписями, событиями и кошельками
GITHUB БАЗА ПО ETHERS.JS
wagmi.sh - TypeScript-first React-библиотека с хуками для взаимодействия с Ethereum. Обеспечивает основу для выполнения задач Web3: от подключения кошелька до чтения/записи данных в смарт-контракты.
rainbowkit.com - UI-библиотека на React для подключения кошельков, построенная поверх wagmi.
reown.com/reown-sdk - Интегрирует множество функций Web3 UX помимо подключения кошельков:
1. Email и social логин (Google, GitHub, X и др.)
2. Поддержка 600+ кошельков и нескольких сетей (EVM, Solana, Bitcoin)
3. Он-рампы, свапы, транзакции, истории операций
Фреймворк-независим: React, Vue, Svelte, Next.js, React Native, Flutter, iOS, Android, Unity и др.
PYTHON
web3py.readthedocs.io/en/stable - Python-библиотека для взаимодействия с Ethereum: чтение блоков, контракты, события, отправка транзакций и так далее
SOLIDITY
docs.openzeppelin.com/contracts - библиотека проверенных реализаций стандартных контрактов: токены, доступы, прокси, утилиты и так далее
ЭТО ДЕ-ФАКТО СТАНДАРТ ИНДУСТРИИ В WEB3
Фреймворки:
hardhat.org - среда для сборки, тестирования и деплоя контрактов.
SOLANA
Библиотеки:
JAVASCRIPT / TYPESCRIPT
npmjs.com/package/@solana/web3.js - базовый RPC-клиент, транзакции, аккаунты, подписи, инструкции, подписки.
solanakit.com/docs - современный JS SDK, на который сместилась “новая разработка
github.com/anza-xyz/wallet-adapter - набор TypeScript/React-пакетов: провайдеры, хуки, UI-компоненты и адаптеры под разные Solana-кошельки.
По сути, стандартный способ сделать кнопку Connect wallet и дальше подписывать транзакции.
PYTHON
github.com/michaelhly/solana-py - Python SDK для JSON-RPC, сборка/отправка транзакций, SPL Token операции на уровне Python.
github.com/kevinheavey/solders - обычно используют: solana-py для сети/async + solders для типов/подписей. В официальных community-заметках прямо так и рекомендуют: solders (core), solana-py (networking/async).
RUST
docs.rs/solana-client/latest/solana_client
1. Отправка и получение транзакций с узла Solana через JSON-RPC.
2. Запросы баланса, получения аккаунтов, блоков, подписей и пр.
3. Интерактивная работа с сетью Solana из офф-чейн кода (то есть не внутри on-chain программы).
docs.rs/solana-sdk/latest/solana_sdk
1. Базовые примитивы Solana
2. Сборка транзакций и инструкций
3. Типы для on-chain программ
Фреймворки:
anchor-lang.com/docs - главный фреймворк для Solana-программ.
Сильно упрощает написание, тестирование и деплой Solana-программ + даёт готовый клиент для работы с ними.
КУРСЫ
ETHEREUM
ethereum.org/learn
speedrunethereum.com
SOLANA
solana.com/developers
ПРОДОЛЖАЕМ?
АКТВИРУЕМ НОВЫЕ РЕАКЦИИ, ЧТОБЫ ПРОДОЛЖИТЬ
📟 Прилетело из @code_vartcall
Позвал @og_mishgan показать его AI-сетап.
Что узнал:
🟥 Ghostty — терминал для тех, кому лень настраивать iTerm. Установил и забыл.
↳ ghostty.org
🟥 ownyourchat — Мишин проект. Синхронизирует все чаты с ChatGPT, Claude, Perplexity в локальную SQLite базу. Грепай свои разговоры с AI.
↳ github.com/mlshv/ownyourchat
🟥 Descript — монтаж видео через редактирование текста. Удаляешь слова — удаляется видео.
↳ descript.cello.so/RyHJMBOkveq
Запись стрима скоро на YouTube. Подпишись заранее:
↳ youtube.com/@danokhlopkov
📟 Прилетело из @danokhlopkov
Что узнал:
🟥 Ghostty — терминал для тех, кому лень настраивать iTerm. Установил и забыл.
↳ ghostty.org
🟥 ownyourchat — Мишин проект. Синхронизирует все чаты с ChatGPT, Claude, Perplexity в локальную SQLite базу. Грепай свои разговоры с AI.
↳ github.com/mlshv/ownyourchat
🟥 Descript — монтаж видео через редактирование текста. Удаляешь слова — удаляется видео.
↳ descript.cello.so/RyHJMBOkveq
Запись стрима скоро на YouTube. Подпишись заранее:
↳ youtube.com/@danokhlopkov
📟 Прилетело из @danokhlopkov
ЧТО ЖЕ ДЕЛАЕМ С 1INCH??
продолжаем наш разговор
ЧТО ПРОИСХОДИТ?
У КОМАНДЫ СТРИМ ЧЕРЕЗ 10 МИНУТ!
x.com/1inchdevs/status/2014745240234528995
Q/A СЕССИЯ С DEVREL x.com/Tanz0rz
DevRel (Developer Relations) - человек, который строит мост между проектом и разработчиками.
Он делает так, чтобы РАЗРАБОТЧИКАМ было понятно, удобно и выгодно пользоваться продуктом
КАЖДЫЙ СМОЖЕТ ЗАДАТЬ СВОЙ ВОПРОС
ПРИСОЕДИНЯЙТЕСЬ! НАЧИНАЕМ ЧЕРЕЗ 10 МИНУТ
📟 Прилетело из @code_vartcall
продолжаем наш разговор
ЧТО ПРОИСХОДИТ?
У КОМАНДЫ СТРИМ ЧЕРЕЗ 10 МИНУТ!
x.com/1inchdevs/status/2014745240234528995
Q/A СЕССИЯ С DEVREL x.com/Tanz0rz
DevRel (Developer Relations) - человек, который строит мост между проектом и разработчиками.
Он делает так, чтобы РАЗРАБОТЧИКАМ было понятно, удобно и выгодно пользоваться продуктом
ПРИСОЕДИНЯЙТЕСЬ! НАЧИНАЕМ ЧЕРЕЗ 10 МИНУТ
📟 Прилетело из @code_vartcall
Если не умеешь зарабатывать на фьючерсах, то эта группа каждый день поднимает
со 100$ = 500$ 🔥
Королев ведет свой канал с 23 года и я лично уважаю его как трейдера.
✅ Это не реклама, делюсь с вами тем, в ком уверен - https://t.iss.one/+KOPP5yR8fjdjZDAy
#реклама
📟 Прилетело из @hidden_coding
со 100$ = 500$ 🔥
Королев ведет свой канал с 23 года и я лично уважаю его как трейдера.
✅ Это не реклама, делюсь с вами тем, в ком уверен - https://t.iss.one/+KOPP5yR8fjdjZDAy
#реклама
📟 Прилетело из @hidden_coding
In my restless dreams I see that code... You promised you'd refactored it but you never did... А иногда прямо хочется вернуться в те славные дни в стиле "гусарский кодинг", когда всё было легко и просто.
Захотел - да и объявил константу класса на лету при включении модуля, а то и метод класса заодно, который на лету что-то читает. А чего - один раз ведь живём!
Сейчас, конечно, тоже не сильно сложно, но не так весело. Метапрограммирование всегда добавляло перчинку в скучную жизнь. Как говорил Джек Воробей - мир остался прежним, стало меньше содержимого (да, я уже помню, что *капитан* Джек Воробей, можно не поправлять 👍) https://github.com/bodrovis/ChgkRating/blob/master/lib/chgk_rating/concerns/searching.rb
📟 Прилетело из @dev_in_ruby_colors
module Searching
# Some black magic indeed...
# Creates a Search child class of a given class that changes the URI where the
# GET request should be sent
def self.included(klass)
klass.const_set(:Search,
Class.new(klass) do |*_args|
def api_path
"#{super}/search"
end
end)
# The actual method to perform searching
# Instantiates a Search class with the given search params
# and send a GET request to the proper URI (defined above)
klass.define_singleton_method :search do |params|
klass.const_get(:Search).new(params)
end
end
end
Захотел - да и объявил константу класса на лету при включении модуля, а то и метод класса заодно, который на лету что-то читает. А чего - один раз ведь живём!
Сейчас, конечно, тоже не сильно сложно, но не так весело. Метапрограммирование всегда добавляло перчинку в скучную жизнь. Как говорил Джек Воробей - мир остался прежним, стало меньше содержимого (да, я уже помню, что *капитан* Джек Воробей, можно не поправлять 👍) https://github.com/bodrovis/ChgkRating/blob/master/lib/chgk_rating/concerns/searching.rb
📟 Прилетело из @dev_in_ruby_colors
Алгоритм. Бинарный поиск
Идем дальше в нашем цикле постов про алгоритмы.
Рассмотрим эффективный алгоритм поиска, основанный на простой и элегантной идее — бинарный поиск. Чтобы понять его суть, представьте себе классическую игру, где требуется угадать число в диапазоне от 1 до 100. Неэффективный подход — перебирать числа по порядку: 1, 2, 3 и так далее. В худшем случае это потребует ста попыток. Гораздо более разумная стратегия заключается в том, чтобы каждый раз делить оставшийся диапазон пополам. Например, сначала спросить: «Число больше 50?». Получив ответ, вы сразу исключаете половину всех возможных чисел, затем повторяете эту процедуру с оставшимся интервалом. Именно этот принцип — последовательное деление области поиска пополам — и лежит в основе алгоритма бинарного поиска.
Крайне важным условием для его применения является предварительная сортировка данных. Алгоритм опирается на упорядоченность массива, чтобы делать корректные выводы о местоположении искомого элемента. Рассмотрим пошаговый процесс на примере отсортированного массива
На первом шаге определяются границы поиска: нижняя
Теперь область поиска сузилась до элементов с индексами от 0 до 2. Снова вычисляется середина:
На третьем шаге границы
Этот процесс можно представить в виде наглядной визуализации:
Реализация данного алгоритма на языке Python выглядит следующим образом:
На каждой итерации цикла вычисляется индекс середины текущего интервала. Затем значение этого элемента сравнивается с целевым. Если они равны, поиск завершается. Если средний элемент меньше искомого, нижняя граница смещается за середину, сужая поиск до правой половины. В противном случае, если средний элемент больше, поиск продолжается в левой половине. Цикл выполняется до тех пор, пока границы не пересекутся, что будет означать отсутствие элемента в массиве.
📟 Прилетело из @solidityset
Идем дальше в нашем цикле постов про алгоритмы.
Рассмотрим эффективный алгоритм поиска, основанный на простой и элегантной идее — бинарный поиск. Чтобы понять его суть, представьте себе классическую игру, где требуется угадать число в диапазоне от 1 до 100. Неэффективный подход — перебирать числа по порядку: 1, 2, 3 и так далее. В худшем случае это потребует ста попыток. Гораздо более разумная стратегия заключается в том, чтобы каждый раз делить оставшийся диапазон пополам. Например, сначала спросить: «Число больше 50?». Получив ответ, вы сразу исключаете половину всех возможных чисел, затем повторяете эту процедуру с оставшимся интервалом. Именно этот принцип — последовательное деление области поиска пополам — и лежит в основе алгоритма бинарного поиска.
Крайне важным условием для его применения является предварительная сортировка данных. Алгоритм опирается на упорядоченность массива, чтобы делать корректные выводы о местоположении искомого элемента. Рассмотрим пошаговый процесс на примере отсортированного массива
[11, 12, 22, 25, 34, 64, 90]. Предположим, нам нужно найти число 22.На первом шаге определяются границы поиска: нижняя
low (индекс 0), верхняя high (индекс 6). Вычисляется средний индекс: mid = (0 + 6) // 2 = 3. Элемент с индексом 3 равен 25. Поскольку 25 больше искомого значения 22, делается вывод, что элемент находится в левой половине массива. Таким образом, верхняя граница high смещается на позицию mid - 1, то есть на индекс 2.Теперь область поиска сузилась до элементов с индексами от 0 до 2. Снова вычисляется середина:
mid = (0 + 2) // 2 = 1. Элемент arr[1] равен 12. Так как 12 меньше 22, становится ясно, что цель находится в правой части текущего интервала. Нижняя граница low сдвигается: low = mid + 1 = 2.На третьем шаге границы
low и high совпадают (индекс 2). Средний элемент, arr[2], равен 22, что полностью соответствует искомому значению. Алгоритм завершается успешно, возвращая индекс 2.Этот процесс можно представить в виде наглядной визуализации:
Исходный массив (7 элементов):
┌────┬────┬────┬────┬────┬────┬────┐
│ 11 │ 12 │ 22 │ 25 │ 34 │ 64 │ 90 │
└────┴────┴────┴────┴────┴────┴────┘
0 1 2 3 4 5 6
Ищем: 22
Итерация 1: Проверяем середину (индекс 3 = значение 25)
┌────┬────┬────┬────┬────┬────┬────┐
│ 11 │ 12 │ 22 │[25]│ 34 │ 64 │ 90 │
└────┴────┴────┴────┴────┴────┴────┘
✗ 25 > 22, ищем левее
Итерация 2: Область поиска сузилась до [11, 12, 22]
Проверяем индекс 1 = значение 12
┌────┬────┬────┐
│ 11 │[12]│ 22 │
└────┴────┴────┘
✗ 12 < 22, ищем правее
Итерация 3: Область поиска = [22]
Проверяем индекс 2 = значение 22
┌────┐
│[22]│
└────┘
✓ Найдено!
Реализация данного алгоритма на языке Python выглядит следующим образом:
def binary_search(arr, target):
"""Бинарный поиск элемента в отсортированном списке."""
low = 0 # Левая граница области поиска
high = len(arr) - 1 # Правая граница области поиска
while low <= high: # Пока область поиска не пуста
mid = (low + high) // 2 # Находим средний индекс
# // - целочисленное деление
if arr[mid] == target: # Если нашли - возвращаем индекс
return mid
elif arr[mid] < target: # Если середина меньше искомого
low = mid + 1 # Ищем в правой половине
else: # Если середина больше искомого
high = mid - 1 # Ищем в левой половине
return -1 # Если элемент не найден, возвращаем -1
На каждой итерации цикла вычисляется индекс середины текущего интервала. Затем значение этого элемента сравнивается с целевым. Если они равны, поиск завершается. Если средний элемент меньше искомого, нижняя граница смещается за середину, сужая поиск до правой половины. В противном случае, если средний элемент больше, поиск продолжается в левой половине. Цикл выполняется до тех пор, пока границы не пересекутся, что будет означать отсутствие элемента в массиве.
📟 Прилетело из @solidityset
Для закрепления рассмотрим несколько примеров. В первом случае элемент отсутствует в массиве:
Алгоритм выполнит следующие шаги: сначала проверит середину (25), затем, так как 25 меньше 50, перейдет к правой половине [34, 64, 90]. Проверив элемент 64, который больше 50, он перейдет к левой части этого подмассива, [34]. После сравнения 34 с 50 границы low и high пересекутся, и будет возвращено значение -1.
Поиск первого и последнего элементов также работает корректно:
Главное преимущество бинарного поиска — его исключительная эффективность. Сложность алгоритма оценивается как O(log n), что означает логарифмическую зависимость количества операций от размера данных. Это становится возможным благодаря тому, что на каждом шаге область поиска сокращается вдвое. Например, для массива из 100 элементов в худшем случае потребуется не более 7 проверок, для миллиона элементов — около 20. В сравнении с линейным поиском, который в худшем случае проверяет все элементы, выигрыш становится колоссальным, особенно на больших объемах данных.
Теперь обратимся к ключевому вопросу: почему бинарный поиск неприменим к неотсортированным данным? Вся логика алгоритма строится на предположении, что если элемент в середине меньше искомого, то все элементы слева от него тоже заведомо меньше. Это свойство гарантировано только в отсортированном массиве. В противном случае, отбросив какую-либо половину, мы можем случайно потерять искомый элемент. Проиллюстрируем это на примере массива
Алгоритм можно реализовать не только итеративно, но и с помощью рекурсии, когда функция вызывает саму себя для суженной области поиска.
Рекурсивная версия часто выглядит более лаконичной, но она использует память для стека вызовов, что может стать ограничением для очень больших массивов. Итеративный подход с циклом обычно более эффективен с точки зрения потребления памяти.
Интересно, что принцип бинарного поиска интуитивно используется людьми в повседневных задачах. Самый яркий пример — поиск слова в бумажном словаре. Мы открываем книгу примерно посередине, смотрим на букву, определяем, нужная ли она нам, и отбрасываем одну из половин. Этот процесс повторяется до нахождения нужной страницы. Точно так же мы действуем, ища дату в календаре или настраивая громкость. Все эти ситуации объединяет наличие упорядоченных данных и стратегия последовательного деления области поиска.
📟 Прилетело из @solidityset
sorted_data = [11, 12, 22, 25, 34, 64, 90]
target = 50
print(binary_search(sorted_data, target)) # Вывод: -1
Алгоритм выполнит следующие шаги: сначала проверит середину (25), затем, так как 25 меньше 50, перейдет к правой половине [34, 64, 90]. Проверив элемент 64, который больше 50, он перейдет к левой части этого подмассива, [34]. После сравнения 34 с 50 границы low и high пересекутся, и будет возвращено значение -1.
Поиск первого и последнего элементов также работает корректно:
sorted_data = [11, 12, 22, 25, 34, 64, 90]
target = 11
print(binary_search(sorted_data, target)) # Вывод: 0
target = 90
print(binary_search(sorted_data, target)) # Вывод: 6
Главное преимущество бинарного поиска — его исключительная эффективность. Сложность алгоритма оценивается как O(log n), что означает логарифмическую зависимость количества операций от размера данных. Это становится возможным благодаря тому, что на каждом шаге область поиска сокращается вдвое. Например, для массива из 100 элементов в худшем случае потребуется не более 7 проверок, для миллиона элементов — около 20. В сравнении с линейным поиском, который в худшем случае проверяет все элементы, выигрыш становится колоссальным, особенно на больших объемах данных.
Теперь обратимся к ключевому вопросу: почему бинарный поиск неприменим к неотсортированным данным? Вся логика алгоритма строится на предположении, что если элемент в середине меньше искомого, то все элементы слева от него тоже заведомо меньше. Это свойство гарантировано только в отсортированном массиве. В противном случае, отбросив какую-либо половину, мы можем случайно потерять искомый элемент. Проиллюстрируем это на примере массива
[64, 11, 90, 22, 25, 12, 34]. При поиске числа 90 алгоритм, проверив середину (22), решит, что нужно искать справа, так как 22 меньше 90. Однако правая часть [25, 12, 34] не содержит 90, хотя само число 90 присутствует в исходном массиве слева от проверяемой середины. Таким образом, на несортированных данных бинарный поиск дает ненадежный результат.Алгоритм можно реализовать не только итеративно, но и с помощью рекурсии, когда функция вызывает саму себя для суженной области поиска.
def binary_search_recursive(arr, target, low, high):
"""Рекурсивная версия бинарного поиска."""
# Базовый случай: область поиска пуста
if low > high:
return -1
# Находим середину
mid = (low + high) // 2
# Проверяем средний элемент
if arr[mid] == target:
return mid # Нашли!
elif arr[mid] < target:
# Рекурсивно ищем в правой половине
return binary_search_recursive(arr, target, mid + 1, high)
else:
# Рекурсивно ищем в левой половине
return binary_search_recursive(arr, target, low, mid - 1)
# Использование:
sorted_data = [11, 12, 22, 25, 34, 64, 90]
target = 22
result = binary_search_recursive(sorted_data, target, 0, len(sorted_data) - 1)
print(result) # Вывод: 2
Рекурсивная версия часто выглядит более лаконичной, но она использует память для стека вызовов, что может стать ограничением для очень больших массивов. Итеративный подход с циклом обычно более эффективен с точки зрения потребления памяти.
Интересно, что принцип бинарного поиска интуитивно используется людьми в повседневных задачах. Самый яркий пример — поиск слова в бумажном словаре. Мы открываем книгу примерно посередине, смотрим на букву, определяем, нужная ли она нам, и отбрасываем одну из половин. Этот процесс повторяется до нахождения нужной страницы. Точно так же мы действуем, ища дату в календаре или настраивая громкость. Все эти ситуации объединяет наличие упорядоченных данных и стратегия последовательного деления области поиска.
📟 Прилетело из @solidityset
Подводя итог, можно выделить ключевые характеристики бинарного поиска. Во-первых, он применим исключительно к отсортированным массивам. Во-вторых, его временная сложность O(log n) делает его чрезвычайно быстрым для больших наборов данных. В-третьих, принцип работы основан на постоянном уменьшении области поиска вдвое. Наконец, алгоритм возвращает индекс найденного элемента или специальное значение (например, -1), если элемент отсутствует. По сравнению с линейным поиском бинарный поиск демонстрирует подавляющее преимущество в скорости на крупных массивах, что делает его одним из фундаментальных алгоритмов в информатике.
#algorithm
📟 Прилетело из @solidityset
#algorithm
📟 Прилетело из @solidityset