Алгоритмы. Рекурсия

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

Понятие рекурсии можно представить как образ из мира зеркал: когда одно зеркало отражается в другом, и это отражение, в свою очередь, находит своё отражение, создавая уходящую в бесконечность череду образов. В программировании рекурсия действует схожим образом — это техника, при которой функция для решения задачи вызывает сама себя. Хотя идея может показаться необычной, при правильном применении она становится мощным и элегантным инструментом.

Для корректной работы любой рекурсивной функции необходимы два фундаментальных компонента. Во-первых, это базовый случай — условие остановки, которое предотвращает бесконечный цикл вызовов. Его можно сравнить с последней ступенькой лестницы: достигнув её, вы прекращаете движение. Во-вторых, требуется рекурсивный шаг — вызов функцией самой себя, но с изменёнными входными данными, которые должны гарантированно приближать выполнение к базовому случаю. Это подобно каждому следующему шагу вниз по лестнице, который сокращает оставшееся до низа расстояние.

Рассмотрим простейшую иллюстрацию — функцию обратного отсчёта от заданного числа до единицы. Её логика наглядно демонстрирует оба принципа.

def count_down(n):
    # Базовый случай: когда достигли 0, останавливаемся
    if n == 0:
        print("Готово!")
        return
    
    # Выводим текущее число
    print(n)
    
    # Рекурсивный шаг: вызываем функцию с n-1
    count_down(n - 1)

count_down(5)

Вывод этой программы будет последовательным:

5
4
3
2
1
Готово!

Внутри этого процесса происходит следующее: вызов count_down(5) приводит к выводу числа 5 и новому вызову count_down(4). Этот процесс вкладывается, подобно матрёшкам, пока вызов count_down(0) не достигнет базового случая, выведет "Готово!" и не начнёт возвращать управление обратно по цепочке предыдущих вызовов.

Классическим примером, раскрывающим суть рекурсивного мышления, является вычисление факториала числа n, обозначаемого как n!. По определению, факториал — это произведение всех натуральных чисел от 1 до n, при этом 0! и 1! равны 1 (вообще не так чтобы равны, посто принято такое равенство для удобства расчетов). Ключевое наблюдение здесь — рекурсивная природа операции: факториал любого числа n можно выразить через факториал меньшего числа, а именно n! = n * (n-1)!. Это и становится основой для алгоритма.

def factorial(n):
    # Базовый случай
    if n == 0 or n == 1:
        return 1
    
    # Рекурсивный шаг
    return n * factorial(n - 1)

print(factorial(5))  # 120

# Для значения 3

factorial(3)
│
├─ factorial(2)  ← добавляется в стек
│  │
│  ├─ factorial(1)  ← добавляется в стек
│  │  └─ возвращает 1  ← снимается со стека
│  │
│  └─ возвращает 2  ← снимается со стека
│
└─ возвращает 6  ← снимается со стека

# Стек вызовов для factorial(3):

Шаг 1: [factorial(3)]
Шаг 2: [factorial(3), factorial(2)]
Шаг 3: [factorial(3), factorial(2), factorial(1)]
Шаг 4: [factorial(3), factorial(2)]  ← factorial(1) вернул результат
Шаг 5: [factorial(3)]  ← factorial(2) вернул результат
Шаг 6: []  ← factorial(3) вернул результат

Пошаговое выполнение функции для factorial(5) раскладывается в цепочку отложенных умножений: 5 * factorial(4), затем 5 * (4 * factorial(3)), и так далее, пока вычисление не дойдёт до базового случая factorial(1), который возвращает 1. После этого цепочка начинает сворачиваться, производя последовательные умножения: 2 * 1 = 2, 3 * 2 = 6, 4 * 6 = 24 и, наконец, 5 * 24 = 120.

Эта же логика применима ко множеству других задач. Например, для вычисления суммы всех чисел от 1 до n.

def sum_numbers(n):
    # Базовый случай
    if n == 0:
        return 0
    
    # Рекурсивный шаг
    return n + sum_numbers(n - 1)

print(sum_numbers(5))  # 15 (5+4+3+2+1)

Аналогично работает возведение числа в натуральную степень.

📟 Прилетело из @solidityset

def power(base, exponent):
    # Базовый случай
    if exponent == 0:
        return 1
    
    # Рекурсивный шаг
    return base * power(base, exponent - 1)

print(power(2, 3))  # 8 (2 * 2 * 2)

Или определение длины строки без использования встроенных функций.

def string_length(s):
    # Базовый случай: пустая строка
    if s == "":
        return 0
    
    # Рекурсивный шаг: убираем первый символ и считаем остаток
    return 1 + string_length(s[1:])

print(string_length("hello"))  # 5

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

Механизм, обеспечивающий возможность таких вложенных вызовов, называется стеком вызовов. Это специальная область памяти, организованная по принципу LIFO ("последним пришёл — первым ушёл"), подобно стопке тарелок. Каждый новый вызов функции помещает в стек свой контекст (аргументы, локальные переменные, место возврата). Когда функция завершает работу, её контекст извлекается из вершины стека, и выполнение продолжается с предыдущего вызова. При глубокой рекурсии стек может исчерпать свой лимит, что приводит к ошибке переполнения стека. Каждый рекурсивный вызов занимает память, поэтому важно, чтобы алгоритм гарантированно сходился к базовому случаю.

Рассмотрим практический вопрос: как написать рекурсивную функцию для вычисления n-го числа Фибоначчи? Последовательность Фибоначчи задаётся правилами: F(0) = 0, F(1) = 1, а для n > 1 каждое число равно сумме двух предыдущих: F(n) = F(n-1) + F(n-2). Это определение напрямую ложится на рекурсивный алгоритм.

def fibonacci(n):
    # Базовые случаи
    if n == 0:
        return 0
    if n == 1:
        return 1
    
    # Рекурсивный шаг
    return fibonacci(n - 1) + fibonacci(n - 2)

# Примеры
print(fibonacci(0))   # 0
print(fibonacci(1))   # 1
print(fibonacci(5))   # 5
print(fibonacci(10))  # 55

**Почему так медленно?**

Посмотрим на дерево вызовов для fibonacci(5):

fib(5)
/ \
fib(4) fib(3)
/ \ / \
fib(3) fib(2) fib(2) fib(1)
/ \ / \ / \
fib(2) fib(1) fib(1) fib(0) fib(1) fib(0)
/ \
fib(1) fib(0)

Однако у этой наивной реализации есть серьёзный недостаток — экспоненциальная временная сложность O(2^n). Это происходит из-за колоссального количества повторных вычислений одних и тех же значений, что хорошо видно на дереве вызовов для `fibonacci(5)`, где, например, `fibonacci(3)` вычисляется несколько раз. Для оптимизации применяют технику мемоизации — сохранения результатов предыдущих вычислений в кеше (словаре), чтобы не считать их заново.

```python
def fibonacci_memo(n, memo={}):
    # Если уже вычисляли, берем из кеша
    if n in memo:
        return memo[n]
    
    # Базовые случаи
    if n == 0:
        return 0
    if n == 1:
        return 1
    
    # Вычисляем и сохраняем результат
    memo[n] = fibonacci_memo(n - 1, memo) + fibonacci_memo(n - 2, memo)
    return memo[n]

print(fibonacci_memo(50))  # Работает быстро!

С мемоизацией сложность снижается до линейной O(n), поскольку каждое значение вычисляется только один раз.

Это подводит к обсуждению недостатков рекурсивного подхода в сравнении с итеративным (циклы). Главные минусы рекурсии — повышенный расход памяти из-за использования стека вызовов, риск его переполнения при большой глубине, более низкая скорость из-за накладных расходов на вызов функции, а также потенциальная сложность отладки. Итеративные решения обычно более эффективны по памяти и быстродействию для задач, которые можно просто выразить через циклы. Например, вычисление факториала с помощью цикла не требует хранения цепочки вызовов в стеке.

📟 Прилетело из @solidityset

Тем не менее, рекурсия остаётся незаменимым инструментом для задач, имеющих естественную рекурсивную структуру данных или логики. Она идеально подходит для обхода древовидных структур (каталогов файловой системы), реализации алгоритмов "разделяй и властвуй" (быстрая сортировка, бинарный поиск) и решения таких задач, как Ханойские башни. Выбор между рекурсией и итерацией часто является компромиссом между читаемостью, простотой выражения идеи алгоритма и требованиями к производительности и ресурсам.

#algorithm

📟 Прилетело из @solidityset

Алгоритмы. Рекурсия

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

Понятие рекурсии можно представить как образ из мира зеркал: когда одно зеркало отражается в другом, и это отражение, в свою очередь, находит своё отражение, создавая уходящую в бесконечность череду образов. В программировании рекурсия действует схожим образом — это техника, при которой функция для решения задачи вызывает сама себя. Хотя идея может показаться необычной, при правильном применении она становится мощным и элегантным инструментом.

Для корректной работы любой рекурсивной функции необходимы два фундаментальных компонента. Во-первых, это базовый случай — условие остановки, которое предотвращает бесконечный цикл вызовов. Его можно сравнить с последней ступенькой лестницы: достигнув её, вы прекращаете движение. Во-вторых, требуется рекурсивный шаг — вызов функцией самой себя, но с изменёнными входными данными, которые должны гарантированно приближать выполнение к базовому случаю. Это подобно каждому следующему шагу вниз по лестнице, который сокращает оставшееся до низа расстояние.

Рассмотрим простейшую иллюстрацию — функцию обратного отсчёта от заданного числа до единицы. Её логика наглядно демонстрирует оба принципа.

def count_down(n):
    # Базовый случай: когда достигли 0, останавливаемся
    if n == 0:
        print("Готово!")
        return
    
    # Выводим текущее число
    print(n)
    
    # Рекурсивный шаг: вызываем функцию с n-1
    count_down(n - 1)

count_down(5)

Вывод этой программы будет последовательным:

5
4
3
2
1
Готово!

Внутри этого процесса происходит следующее: вызов count_down(5) приводит к выводу числа 5 и новому вызову count_down(4). Этот процесс вкладывается, подобно матрёшкам, пока вызов count_down(0) не достигнет базового случая, выведет "Готово!" и не начнёт возвращать управление обратно по цепочке предыдущих вызовов.

Классическим примером, раскрывающим суть рекурсивного мышления, является вычисление факториала числа n, обозначаемого как n!. По определению, факториал — это произведение всех натуральных чисел от 1 до n, при этом 0! и 1! равны 1 (вообще не так чтобы равны, просто принято такое равенство для удобства расчетов). Ключевое наблюдение здесь — рекурсивная природа операции: факториал любого числа n можно выразить через факториал меньшего числа, а именно n! = n * (n-1)!. Это и становится основой для алгоритма.

def factorial(n):
    # Базовый случай
    if n == 0 or n == 1:
        return 1
    
    # Рекурсивный шаг
    return n * factorial(n - 1)

print(factorial(5))  # 120

# Для значения 3

factorial(3)
│
├─ factorial(2)  ← добавляется в стек
│  │
│  ├─ factorial(1)  ← добавляется в стек
│  │  └─ возвращает 1  ← снимается со стека
│  │
│  └─ возвращает 2  ← снимается со стека
│
└─ возвращает 6  ← снимается со стека

# Стек вызовов для factorial(3):

Шаг 1: [factorial(3)]
Шаг 2: [factorial(3), factorial(2)]
Шаг 3: [factorial(3), factorial(2), factorial(1)]
Шаг 4: [factorial(3), factorial(2)]  ← factorial(1) вернул результат
Шаг 5: [factorial(3)]  ← factorial(2) вернул результат
Шаг 6: []  ← factorial(3) вернул результат

Пошаговое выполнение функции для factorial(5) раскладывается в цепочку отложенных умножений: 5 * factorial(4), затем 5 * (4 * factorial(3)), и так далее, пока вычисление не дойдёт до базового случая factorial(1), который возвращает 1. После этого цепочка начинает сворачиваться, производя последовательные умножения: 2 * 1 = 2, 3 * 2 = 6, 4 * 6 = 24 и, наконец, 5 * 24 = 120.

Эта же логика применима ко множеству других задач. Например, для вычисления суммы всех чисел от 1 до n.

def sum_numbers(n):
    # Базовый случай
    if n == 0:
        return 0
    
    # Рекурсивный шаг
    return n + sum_numbers(n - 1)

print(sum_numbers(5))  # 15 (5+4+3+2+1)

Аналогично работает возведение числа в натуральную степень.

📟 Прилетело из @solidityset

def power(base, exponent):
    # Базовый случай
    if exponent == 0:
        return 1
    
    # Рекурсивный шаг
    return base * power(base, exponent - 1)

print(power(2, 3))  # 8 (2 * 2 * 2)

Или определение длины строки без использования встроенных функций.

def string_length(s):
    # Базовый случай: пустая строка
    if s == "":
        return 0
    
    # Рекурсивный шаг: убираем первый символ и считаем остаток
    return 1 + string_length(s[1:])

print(string_length("hello"))  # 5

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

Механизм, обеспечивающий возможность таких вложенных вызовов, называется стеком вызовов. Это специальная область памяти, организованная по принципу LIFO ("последним пришёл — первым ушёл"), подобно стопке тарелок. Каждый новый вызов функции помещает в стек свой контекст (аргументы, локальные переменные, место возврата). Когда функция завершает работу, её контекст извлекается из вершины стека, и выполнение продолжается с предыдущего вызова. При глубокой рекурсии стек может исчерпать свой лимит, что приводит к ошибке переполнения стека. Каждый рекурсивный вызов занимает память, поэтому важно, чтобы алгоритм гарантированно сходился к базовому случаю.

Рассмотрим практический вопрос: как написать рекурсивную функцию для вычисления n-го числа Фибоначчи? Последовательность Фибоначчи задаётся правилами: F(0) = 0, F(1) = 1, а для n > 1 каждое число равно сумме двух предыдущих: F(n) = F(n-1) + F(n-2). Это определение напрямую ложится на рекурсивный алгоритм.

def fibonacci(n):
    # Базовые случаи
    if n == 0:
        return 0
    if n == 1:
        return 1
    
    # Рекурсивный шаг
    return fibonacci(n - 1) + fibonacci(n - 2)

# Примеры
print(fibonacci(0))   # 0
print(fibonacci(1))   # 1
print(fibonacci(5))   # 5
print(fibonacci(10))  # 55

# Почему так медленно?

Посмотрим на дерево вызовов для fibonacci(5):

                    fib(5)
                   /      \
              fib(4)      fib(3)
              /    \      /    \
          fib(3) fib(2) fib(2) fib(1)
          /   \   /  \   /  \
      fib(2) fib(1) fib(1) fib(0) fib(1) fib(0)
      /   \
  fib(1) fib(0)

Однако у этой наивной реализации есть серьёзный недостаток — экспоненциальная временная сложность O(2^n). Это происходит из-за колоссального количества повторных вычислений одних и тех же значений, что хорошо видно на дереве вызовов для fibonacci(5), где, например, fibonacci(3) вычисляется несколько раз. Для оптимизации применяют технику мемоизации — сохранения результатов предыдущих вычислений в кеше (словаре), чтобы не считать их заново.

def fibonacci_memo(n, memo={}):
    # Если уже вычисляли, берем из кеша
    if n in memo:
        return memo[n]
    
    # Базовые случаи
    if n == 0:
        return 0
    if n == 1:
        return 1
    
    # Вычисляем и сохраняем результат
    memo[n] = fibonacci_memo(n - 1, memo) + fibonacci_memo(n - 2, memo)
    return memo[n]

print(fibonacci_memo(50))  # Работает быстро!

С мемоизацией сложность снижается до линейной O(n), поскольку каждое значение вычисляется только один раз.

Это подводит к обсуждению недостатков рекурсивного подхода в сравнении с итеративным (циклы). Главные минусы рекурсии — повышенный расход памяти из-за использования стека вызовов, риск его переполнения при большой глубине, более низкая скорость из-за накладных расходов на вызов функции, а также потенциальная сложность отладки. Итеративные решения обычно более эффективны по памяти и быстродействию для задач, которые можно просто выразить через циклы. Например, вычисление факториала с помощью цикла не требует хранения цепочки вызовов в стеке.

📟 Прилетело из @solidityset

Тем не менее, рекурсия остаётся незаменимым инструментом для задач, имеющих естественную рекурсивную структуру данных или логики. Она идеально подходит для обхода древовидных структур (каталогов файловой системы), реализации алгоритмов "разделяй и властвуй" (быстрая сортировка, бинарный поиск) и решения таких задач, как Ханойские башни. Выбор между рекурсией и итерацией часто является компромиссом между читаемостью, простотой выражения идеи алгоритма и требованиями к производительности и ресурсам.

#algorithm

📟 Прилетело из @solidityset

FUN: первый лайфчендж 2026?

Думаю, вы уже видели скрины с сумасшедшими профитами $FUN на ASTER DEX.

Если кратко, то маркетмейкер $FUN на ASTER парсил цену с другого токена, который на 99,9% торговался ниже, чем $FUN на других биржах.

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

Людям удалось забрать 20-50х на сайз, что очень вкусно и я рад за тех, кому это удалось.

Для остальных рекомендую держать деньги на: всех СЕХ, а так же Lighter, HL, Aster. И ждать свой лайфчендж.

📟 Прилетело из @hidden_coding

Провели вертикальный тг стрим с вайбкодингом игрульки @blockwallbot

добавили:
• красивые темы
• рефералку
• фикс багов
• онбординг

Кто был — расскажите, как вам формат? Что запрогать дальше? Темы для будущих стримов?

Запись стрима грузится в комменты

📟 Прилетело из @danokhlopkov

Vercel Labs выкатили json-render – библиотеку для генерации UI через промпты.

Проблема: когда AI генерит интерфейс — это рулетка. Может выдать несуществующий компонент, кривой JSON, XSS в придачу. json-render ставит модель в рамки: вот каталог компонентов, вот схема – генерируй только из этого. Нет в каталоге – не рендерим. Tool calling, только для UI.

У ребят из Onchain Divers индексеры по Solana, Hyperliquid, Polymarket — данных море. Сейчас чтобы сделать к этому интерфейс — либо пилишь фронт руками, либо агент отвечает текстом. С json-render агент рисует готовый UI: "покажи все свопы больше 10 SOL на Raydium для токена за неделю" → таблица с интерактивными фильтрами, не простыня текста. "Топ кошельков по объёму на Hyperliquid" → график. Всё с валидацией по схеме.

Генеративный UI близок. Первые шаги, но направление понятно.

github.com/vercel-labs/json-render

📟 Прилетело из @insuline_eth

🧠 SOLANA LUV: ВОЗВРАЩЕНИЕ

14 января 2026 года мы начали наш марафон: SOLANA С НУЛЯ ЗА 30 ДНЕЙ

150 Участников принимают участие и уже получают первые результаты!

но...

Уже несколько дней мне пишут, что не успели зайти на марафон

ПОЭТОМУ

❤️‍🔥 ДОБАВЛЯЮ 50 МЕСТ

и снова но...

НЕ ВСЕ ТАК ПРОСТО

Теперь вам необходимо заполнить простую форму

5 ВОПРОСОВ

После заполнения вы сразу вступаете на наш марафон!

GOOGLE-ФОРМА
GOOGLE-ФОРМА
GOOGLE-ФОРМА

СОЗИДАЕМ ❤️‍🔥

📟 Прилетело из @code_vartcall

Мне довольно часто приходится работать со сторонними API, в том числе в мире JS/TS (так уж складывается). Долгое время в качестве go-to решения у меня был Got (который теперь переродился, об этом чуть ниже).

Однако я предпочитаю подход "чем меньше сторонних зависимостей", тем лучше, поэтому последние пару лет очень активно использую встроенный Fetch, который доступен с версии node 18. Решение несложное, без наворотов, но надёжное - плюс, можно легко тестировать (нужно подключить undici, из которого это всё и появилось изначально).

Да, там нет каких-то продвинутых штук, но таймауты настраиваются, ошибки ловятся, все необходимые параметры конфигурируются, прокси добавляются (хотя это чуточку сложнее)... Честно говоря, во многих случаях этого достаточно. А для чего-то несколько более сложного можно попробовать Ky - от создателей Got.

Если нужно изучить это дело с нуля, у меня вышла новая статья https://www.scrapingbee.com/blog/nodejs-fetch-api-http-requests/

📟 Прилетело из @dev_in_ruby_colors

gm!

Команда $TROVE не особо скрываясь решила депнуть в казик средства полученные в ангельском раунде.

Можно долго рассуждать про "utility токены" и "революционные протоколы". А можно просто посмотреть куда идут деньги с раундов. Иногда честность системы восхищает.

https://x.com/zachxbt/status/2012545418350207378

📟 Прилетело из @insuline_eth

Новый способ паразитировать на чужой репутации в крипте — запустить токен с именем известного разработчика, даже не спрашивая его.

Схема работает так: платформа Bags позволяет создать Solana-токен и указать Twitter-аккаунт как получателя части комиссий. Согласие владельца аккаунта не требуется.

Дальше – классика. Создатели раскачивают капу своими деньгами, потом стучатся в личку: «Смотри, твоё комьюнити тебя поддерживает! У тебя $279,000 накопилось, забирай!»

Жертва радуется халявным деньгам, начинает постить про токен, народ налетает покупать – а инсайдеры сливают в этот поток ликвидности.

Steve Yegge уже написал восторженный пост про $GAS и «creator economy». Geoff Huntley пошёл по тому же пути с $RALPH. Оба – уважаемые разработчики с многолетней репутацией. Теперь рекламируют мемкоины.

Почему именно разрабы? Goedecke объясняет:
— $200k впечатляет разраба, но не MrBeast
— Их подписчики задроты — разберутся как купить
— AI хайп добавляет топлива

Разрабы получают крохи от комиссий. Основной профит — у инсайдеров, которые накачали токен до прихода «комьюнити» и сливают на пике.

crypto-airdrop-pump-and-dumps-as-a-service

Ну и бонусом — агрессивный спам по всем разрабам в Twitter DMs. Отличная работа по репутации индустрии.

📟 Прилетело из @insuline_eth

Стоит ли держать токен Cypher? Разбор токеномики

Многие на этот проект смотрят: это и декс, и лончпад, а в будущем и другое. Есть интересные функции токеномики. Решил изучить и написать аналитику.

Интересно, что проект создала команда основателей dex Camelot (не проверял). Видимо старый проект не удался - решили попробовать ещё раз 😁.
Также увидел на странице распределения дохода выделение Algebra. Как понимаю, это ПО для дексов.

Источники токеномик для обзора: документация.


Помимо основного токена есть застейканная версия - xCYPH (за блокировку $CYPH). Он выдаётся при блокировке CYPH. В замен холдеры xCYPH получают доходы протокола. Вывод в CYPH 6 месяцев.
Поддерживает плагины, расширяющие функционал. Например, плагин для стейкинга с реальной доходностью (официальный). Но поддерживаются и сторонние.
Интересная модель, имхо.

И oCYPH - распространяется для нужд фарминга и создает стимулы для снижения давления прямых продаж на CYPH. Является, по сути, опционом к $CYPH. Можно обменять на $xCYPH 1 к 1 или в $CYPH с оплатой в ETH (30-60% от суммы).
Эти ETH используются для выкупа CYPH на открытом рынке.

Как работает поток ценности
1. Протокол генерирует доходы от своей деятельности.

2. Эти доходы поступают к холдерам $xCYPH (доходы, байбеки, другое.).

3. Вознаграждения усиливают мотивацию блокировать $CYPH, что уменьшает ликвидный запас токена и перераспределяет ценность держателям $xCYPH.

4. oCYPH выступает как опционный токен — он используется для стимулов и фарминга, чтобы снизить давление продажи на $CYPH и поддерживать устойчивость токеномики.

5. xCYPH и oCYPH связаны с $CYPH: стейкинг ($xCYPH) и спрос через $oCYPH приводят к снижению циркулирующего предложения $CYPH и росту совокупного спроса со временем.

Продуманная структура с защитой от сливов по рынку. Но многое зависит от спроса и доходов протокола.


И основное - $CYPH. Всего - 1 МЛРД.
Ликвидный токен, доступный для торговли пользователям. Нет утилит (разве что перевод в $xCYPH).

Начальное распределение:

1. Community Rewards - 65%.
Распространяется в течение 4 лет, все в oCYPH.
Если линейно - это эмиссия 1.354%. Но учитывайте, что при конвертации в $CYPH будет на 30% ниже - это 0.9478% (если все будут это делать). Если же все награды переведут в $xCYPH, будет то же значение, но через 6 месяцев.
И стоит понимать, что это награды пользователям = вряд ли все будут действовать одновременно.

2. Core Contributors - 15%.
По сути, команде. Больше 10%, что плохо.
6 месяцев клифф (ожидание) и 3 года вестинг (распределение).
Это 0.417% в месяц через 6 месяцев от TGE (от момента запуска токена).

3. Fair-launch sale - 10%.
Если больше не будет аллокаций инвесторам, норм.
2/3 суммы разблокировано на TGE, 1/3 - в xCYPH.
То есть, как я понимаю, через полгода после запуска токена смогут одномоментно продать где-то 3.3% от всех токенов - многовато, но некритично.

4. Ecosystem Fund - 7%.
Что выделяют на развитие экосистемы средства - хорошо. Но кто ими будет распоряжаться и качественно ли, непонятно.
Благо они тоже 6 месяцев клифф и 3 месяца вестинг.
0.194% - норм.

5. PoL - 3%.
Используется для обеспечения начальной ликвидности.
Возможно стоило бы выделить 5-10%, но и так норм.


И того:
Первые 6 месяцев только Community Rewards с почти 1.35% в месяц.
А далее почти 1.97% в месяц.
Это многовато: норма - до 0.9% в месяц.
Но стоит понимать, что награды идут в $oCYPH, что создаёт барьер к сливу.

После четырёх лет разблокировки завершаются.

Пока же надо смотреть на байбеки и прибыль: если небольшая - считаю, что рисковано холдить.


Рыночная ситуация:
Падение на 57.82%. От минимума больше на 122.97% (рост за 14 дней на 64.839%).
Не разблокировано (по данным Coingecko) 91% - много.

Как считаете, достаточно ли будет такой токеномики для успеха? Я считаю, что нет, но интересно ваше мнение.
P. S. Мне проект и их актив не особо интересен.

P. P. S. Написал в пятницу и забыл поставить на отложенную публикацию...

😎 Незрячий web3 программист (подписаться)
Чат | бот

📟 Прилетело из @blind_dev

Алгоритмы. Стек и Очередь

Продолжаем разбираться с базовыми алгоритмами и сегодня поговорим про Стек и Очередь. Как вы можете знать стек используется даже в Solidity, поэтому важно понимать как он работает, и что можно от него ожидать.

Примеры кода на Python получились достаточно объемными, поэтому пришлось поместить их в отдельный ресурс Telegraph.

P.S. Весь код вы можете протестировать в Google Colab или Jupyter Notebook.

В программировании для организации хранение данных с определенными правилами доступа существуют две базовые структуры — стек и очередь. Они определяют четкий порядок, в котором элементы добавляются и извлекаются, что делает их незаменимыми инструментами для решения широкого спектра задач.

Стек, или Stack, работает по принципу LIFO — Last-In, First-Out, что переводится как «последним пришел — первым ушел». Это легко представить на примере стопки книг: новую книгу всегда кладут сверху, и чтобы взять нужную, также снимают сначала верхнюю. Самую нижнюю книгу можно получить, только убрав все лежащие выше. Основные операции со стеком включают push для добавления элемента на вершину, pop для его удаления, peek или top для просмотра вершины без удаления и isEmpty для проверки на пустоту. Визуально стек можно изобразить следующим образом:

┌─────────┐
│    C    │ ← Вершина (Top) - здесь происходят операции
├─────────┤
│    B    │
├─────────┤
│    A    │
└─────────┘

После операции pop() будет удален элемент C, а после push(D) на вершине окажется D. На практике это выглядит так, как показано в примере реализации стека на Python с использованием списка.

Пример 1

Вывод программы наглядно демонстрирует порядок операций:

Пример 2

Стек находит применение во множестве реальных задач. Например, история браузера использует стек для реализации кнопки «Назад»: каждый новый URL помещается в стек, а нажатие кнопки извлекает последний. Текстовые редакторы хранят историю изменений в стеке для функции отмены действий (Ctrl+Z). Компиляторы и интерпретаторы проверяют сбалансированность скобок в коде, используя стек для отслеживания открывающих символов. Наконец, сам механизм вызова функций в программах управляется стеком вызовов, где сохраняются контексты выполнения. Практическим примером может служить функция проверки корректности расстановки скобок.

Пример 3

В отличие от стека, очередь, или Queue, работает по принципу FIFO — First-In, First-Out, то есть «первым пришел — первым ушел». Это аналогично очереди в магазине: первый вставший в очередь покупатель первым же и обслуживается, а новые люди присоединяются к концу. Основные операции — enqueue для добавления элемента в конец, dequeue для удаления из начала, front для просмотра первого элемента и isEmpty для проверки. Визуализация очереди выглядит так:

Пример 4

При dequeue() будет удален элемент A, а после enqueue(E) в конец добавится E. В Python для эффективной реализации очереди используется структура deque из модуля collections.

Пример 5

Вывод этой программы отражает принцип FIFO:

Пример 6

Очереди применяются там, где важен порядок поступления. Например, принтер обрабатывает документы в порядке отправки, сервера обрабатывают запросы в очереди, алгоритм поиска в ширину (BFS) использует очередь для обхода графа, а операционные системы планируют процессы. Практическую модель можно увидеть в симуляции работы кассы.

Пример 7

Сравнивая стек и очередь, можно выделить их ключевые различия. Стек следует принципу LIFO, подобно стопке книг, где добавление и удаление происходят с одного конца (вершины). Очередь же работает по принципу FIFO, как очередь в магазине, где добавление идет в конец, а удаление — из начала. В Python стек эффективно реализуется через список (list), а для очереди предпочтительнее использовать deque из модуля collections.

📟 Прилетело из @solidityset