Данное предложение предлагает новую возможность в JavaScript: использование конструкции try/catch/finally в контексте выражения, возвращающего значение. Для этого вводится новое ключевое слово raise, предназначенное для явного "выноса" значения из блока try или catch наружу. В итоге весь блок try/catch может выступать как единое выражение, результат которого определяется вызовами raise внутри него.

В классическом JavaScript конструкция try...catch является оператором и не напрямую возвращает значение. Это означает, что для использования результата выполнения try/catch в выражении приходится прибегать к дополнительным переменным или функциям. Новое же предложение делает синтаксис более выразительным и функциональным, позволяя писать код в декларативном стиле без лишних промежуточных шагов.

Ниже рассматриваются мотивация данного предложения, примеры использования, синтаксис и семантика ключевого слова raise, потенциальные сложности и влияние на существующий код, а также сравнение с похожими возможностями в других языках. Предложение оформлено в формате объяснительного документа (explainer) для нулевого этапа TC39.

Мотивация

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

let result;
try {
  result = computeValue(x);
} catch (e) {
  result = fallbackValue(e);
}

В таком коде переменная result объявляется заранее, а затем внутри try/catch ей присваиваются значения. Этот шаблон нарушает декларативность и поток чтения кода – вместо того, чтобы определить result в месте вычисления, мы вынуждены сначала объявить ее, а потом изменять. Желательно, чтобы можно было получить значение из try/catch прямо в месте вызова, как это делается с тернарными операторами или if/else (если бы if мог быть выражением).

Другой пример неудобства – использование результатов внутри других выражений. Сегодня, чтобы, например, вызвать функцию с аргументом, полученным через try/catch, приходится либо выносить вычисление вне вызова, либо использовать Immediately-Invoked Function Expression (IIFE):

// Текущий подход без try-выражения:
const finalResult = processData(
  (() => {
    try {
      return riskyOperation();
    } catch {
      return defaultValue;
    }
  })()
);

Такой код труднее читать и поддерживать. Если бы try/catch был выражением, можно было бы писать гораздо яснее:

// С предлагаемым try-выражением:
const finalResult = processData(
  try {
    raise riskyOperation();
  } catch (e) {
    raise defaultValue;
  }
);

Здесь результат try-выражения сразу передается в функцию processData, без дополнительных функций-обёрток. Код выглядит лаконичнее и очевиднее.

Помимо присваивания, выражение try вписывается в идеологию более функционального стиля: можно использовать его внутри других выражений, комбинировать с тернарными операторами, &&/|| логикой, шаблонными литералами и т.д. Это особенно ценно при сложных условиях, когда решение об значении переменной зависит как от булевых условий, так и от успешности выполнения какого-то кода.

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

Наконец, стоит отметить интерес сообщества к подобным возможностям. В других языках и предложениях уже есть схожие решения. Например, сообщество Python обсуждало возможность так называемых "exception-catching expressions" – выражений с обработкой исключений встроенной, по аналогии с тернарными операторами peps.python.org. Хотя в Python это не было принято, сам факт появления PEP 463 показывает потребность разработчиков в более кратком синтаксисе для таких случаев. Java добавила в версии 13 выражения switch с ключевым словом yield для возврата значений из блоков case, чтобы избавиться от шаблона с внешней переменной stackoverflow.com. Наше предложение в духе этой тенденции – предоставить JavaScript-разработчикам инструмент, делающий код с try/catch менее шаблонным и более выразительным.

Примеры использования до и после

Чтобы лучше понять предлагаемое изменение, рассмотрим несколько пар примеров "до и после". Они иллюстрируют, как новый синтаксис с raise сократит код и улучшит его понятность.

Присваивание с обработкой ошибок:

До:

let config;
try {
  config = loadConfig();
} catch {
  config = getDefaultConfig();
}

После:

const config = try {
  raise loadConfig();
} catch {
  raise getDefaultConfig();
};

Интеграция с условными операторами (if/тернарный):

До:

let userName;
if (user.isLoggedIn) {
  try {
    userName = fetchUserName(user.id);
  } catch {
    userName = "Гость";
  }
} else {
  userName = "Не авторизован";
}

Этот код можно переписать с использованием выражений, вложив try внутрь тернарного оператора.

После:

const userName = user.isLoggedIn 
  ? try {
      raise fetchUserName(user.id);
    } catch {
      raise "Гость";
    }
  : "Не авторизован";

Использование в async функциях с await:

Нововведение совместимо с асинхронным кодом. Ключевое слово raise поддерживает await для правильного получения промиса.

До:

async function getData() {
  try {
    const response = await fetch(url);
    return process(response);
  } catch (err) {
    return getFallbackData(err);
  }
}

После:

async function getData() {
  return try {
    raise await fetch(url);
  } catch (err) {
    raise getFallbackData(err);
  };
}

Эти примеры демонстрируют, как новая возможность устраняет шаблонное кодирование (boilerplate) и делает намерения разработчика более прозрачными. Вместо фрагментированного кода с объявлениями вне блоков и присвоениями внутри, мы получаем целостные выражения, которые проще воспринимать.

Синтаксис и семантика try-выражения с raise

Предлагаемое изменение включает два связанных элемента: разрешить конструкции try/catch/finally возвращать значение, и ввести ключевое слово raise для явного указания возвращаемого значения. Ниже описаны основные правила и поведение.

Основные правила и ограничения

Обязательность raise в ветвях:

Если хотя бы одна из ветвей (try или catch) внутри конструкции использует raise для возврата значения, то обе ветви должны содержать raise. Другими словами, в выражении вида try { ... } catch { ... } не допускается ситуация, когда try возвращает значение через raise, а в catch при этом нет raise (или наоборот). Такое требование гарантирует, что все возможные пути выполнения возвращают значение. Это схоже с тем, как в выражениях switch в Java каждой ветке должно соответствовать возвращаемое значение (через -> или yield), иначе код считается неполным docs.oracle.comdocs.oracle.com. Если ни одна из ветвей не содержит raise, конструкция try/catch работает как обычный оператор и не производит значения (то есть не может использоваться там, где ожидается значение).

Возврат значения из блока try/catch:

Ключевое слово raise действует по аналогии с return, но не на уровне функции, а на уровне самого блока try/catch. Когда выполнение кода встречает raise <выражение>, текущий блок (try или catch) немедленно завершается, и указанное значение "поднимается" наружу, становясь результатом всего выражения try/catch. Код после вызова raise в том же блоке не выполняется (как и в случае с return внутри функции). Например:

const value = try {
  if (conditionFailed) {
    raise null;  // немедленный выход из try-блока с результатом null
  }
  // ... иначе продолжаем вычисления
  let result = compute();
  raise result;  // возвращаем вычисленное значение
  console.log("Этот код уже не исполнится, т.к. выше был raise");
} catch (e) {
  raise handleError(e);
};

Здесь внутри try предусмотрен ранний выход: при нарушении условия сразу возвращается null. Если же условие в порядке, вычисляется result и он возвращается. Любой код после raise не выполнится. Блок catch также обязательно возвращает значение (обработку ошибки) через raise. Таким образом, переменная value получит либо null, либо корректно вычисленный результат, либо (если исключение не перехвачено данным catch) произойдет обычное распространение исключения вверх (см. ниже).

Поведение блока catch:

Блок catch с raise срабатывает только если в блоке try было брошено исключение (с помощью обычного throw или из-за ошибки). В этом случае выполнение переходит в catch, и там зачастую пишется raise с каким-то значением-заменой или обработкой. Если в catch есть raise, как требует правило, то при перехвате исключения именно его значение станет результатом всего try-выражения. Если же исключение не произошо в try, то блок catch пропускается (как обычно) и не влияет на результат.

Опциональный блок finally:

Конструкция может включать блок finally так же, как обычный try/catch/finally. Блок finally выполняется всегда после try/catch – вне зависимости, было исключение или нет. Однако, в контексте выражения важно, как finally влияет на возвращаемое значение: по умолчанию, если в finally ничего не предпринимать, результат, сформированный в try или catch через raise, сохраняется. Но если внутри finally будет вызван raise, он переопределит ранее подготовленный результат. То есть raise в finally имеет приоритет: он заставляет всё выражение вернуть то значение, которое указано в finally, даже если до этого в try или catch уже был выполнен raise с другим значением. Это поведение аналогично тому, как в сегодняшнем JavaScript блок finally может перезаписать результат функции, если внутри него сделать return или выбросить новое исключение (что, кстати, считается нежелательной практикой, но технически возможно).

Доступ к поднятому значению в finally:

Возникает вопрос – как finally может узнать, какое значение было поднято из try или catch? Предлагается расширение синтаксиса: блок finally может объявить псевдопараметр, например: finally (raised) { ... }. Переменная (идентификатор) в скобках после ключевого слова finally будет доступна внутри блока и содержать значение, переданное последним вызовом raise в try или catch. Если исключение произошло, а catch поднял значение, raised будет равно этому значению; если исключения не было и try поднял значение – соответственно тому. Если ни один из блоков не вызывал raise (то есть на самом деле выражение не вернуло ничего), raised может быть undefined. Это дает возможность в finally например логгировать или модифицировать результат перед окончательным возвратом. Блок finally при этом не обязан вызывать raise – он может просто выполнить побочные действия. Но если внутри finally все же вызвать raise, то новое значение замещает собой прежнее. Пример:

const data = try {
  raise fetchData();
} catch (e) {
  raise null;
} finally (result) {
  console.log("Результат перед выходом:", result);
  if (result === null) {
    // если данные не получены, переопределим результат на заглушку
    raise { status: "empty" };
  }
  // иначе не вызываем raise, и значение из try/catch пройдет далее
};

В этом коде мы всегда логируем полученный результат (успешный или null при ошибке). Затем, если результат равен null (т.е. произошла ошибка и catch вернул null), мы решаем переопределить итоговый результат на объект { status: "empty" } посредством raise в finally. Если же результат не null, finally ничего не возвращает, и значение из try (результат fetchData()) пройдет наружу. Таким образом, data окажется либо объектом с данными (при успешном запросе), либо объектом { status: "empty" } (если произошла ошибка).

Ключевое слово raise:

Предполагается ввести новое ключевое слово raise в язык. Оно выступает как управляющая конструкция, не как функция. С точки зрения грамматики, raise будет аналогично return или throw – за ним должно следовать выражение (или семантически допустимо опустить выражение, чтобы вернуть undefined, как return;). Использование raise вне контекста блока try/catch (который предназначен для возвращения значения) будет синтаксической ошибкой. Также нельзя использовать raise внутри вложенных функций, генераторов или arrow-функций вместо return – его действие ограничено именно текущим try-выражением. Если попытаться написать:

function f() {
  try {
    raise 42;
  } catch { raise -1; }
  // ...
  return 0;
}

то поведение будет следующим: когда f() вызвана, внутри нее выполнится try-выражение. Столкнувшись с raise 42, оно завершит это try-выражение и вернет 42 наружу – в нашем случае, внутрь из функции f(), но так как результат выражения не был присвоен и использован, выполнение дойдет до return 0 и f() вернет 0. Здесь важно разграничить: return выходит из функции, throw выходит из функции (если не пойман), а raise выходит только из блока try/catch-выражения. Это подобно тому, как оператор yield в Java вызывает выход лишь из switch-выражения, а не из окружающей функции stackoverflow.com.

Допустимые возвращаемые значения:

Вызов raise может "поднять" любое значение. Это может быть примитив (число, строка, и т.д.), объект, null или undefined. Нет ограничений или специальных требований, как к throw (который зачастую используют с объектами Error, но формально тоже может бросить что угодно). raise просто берет указанное выражение и делает его результатом. Даже raise undefined; считается корректным – это явный способ вернуть "ничего". Если raise написать без выражения (как отдельную инструкцию raise;), по аналогии с return; это будет означать поднять undefined.

Асинхронность и await:

Как показано ранее, raise полноценно работает в сочетании с await внутри async-функций. При использовании await результат промиса будет получен, а затем передан наружу. Это эквивалентно тому, как return await обрабатывает значение: сначала ждет, затем возвращает его. Важно подчеркнуть: если внутри try используется await, то и сам try-блок становится асинхронным, но поскольку весь код находится внутри async функции, это естественно. Нет дополнительных ограничений – можно писать raise await somePromise;. Если обещание (промис) разрешится нормально, его значение станет результатом, если отклонится (throw внутри промиса), то будет брошено исключение и, возможно, перехвачено блоком catch данного выражения.

Правила области видимости (scoping)

Ключевое слово raise не вводит новой области видимости – оно действует внутри уже существующей области того блока, где находится. Переменные, объявленные внутри try или catch (через let/const), видимы до конца этого блока (включая до его закрывающей фигурной скобки). Вызов raise может использовать любую переменную, доступную в данной области (как локальную, так и внешнюю). Однако после выполнения raise дальнейшие инструкции блока не выполняются, что важно учитывать: например, если ниже по коду определена еще какая-то переменная, она никогда не будет инициализирована, что эквивалентно ситуации с преждевременным return. Это не создает новых проблем, аналогичная ситуация бывает с return или throw. Просто разработчику и инструментам нужно будет следить за тем, чтобы код после raise не содержал критически важных операций (lint-правила могут подсвечивать "unreachable code after raise", подобно тому, как делают для return).

Отдельно стоит сказать про Temporal Dead Zone (TDZ). Появление try-выражений не меняет существующих правил TDZ для let/const. Но могут быть тонкости, если try-выражение используется в месте объявления переменной. Рассмотрим пример:

// Неправильно:
let value = try {
  raise someVar;
} catch (e) {
  console.log(e); // ReferenceError: Cannot access 'someVar' before initialization
  raise 1;
};
let someVar = 5;

Здесь мы пытаемся использовать someVar внутри инициализации value до того, как someVar объявлена. Разработчикам нужно по-прежнему следить за порядком объявлений. В остальном try-выражение не вводит новых ограничений: оно вычисляется последовательно, и любые переменные, объявленные внутри него, живут только в нем и не "просачиваются" наружу (наружу выходит лишь значение). Переменная, объявленная во внешней функции с тем же именем, что и идентификатор в finally (ident), не находится в конфликте – идентификатор в скобках finally работает как параметр, подобно параметру функции или названному exception-параметру в catch.

Потенциальные сложности и влияние на экосистему

Внедрение нового синтаксиса – особенно с введением нового ключевого слова – требует внимательного отношения к деталям реализации и обратной

Внедрение нового синтаксиса – особенно с введением нового ключевого слова – требует внимательного отношения к деталям реализации и обратной совместимости.

• Обратная совместимость (ключевое слово raise): На сегодняшний день слово raise не является зарезервированным в JavaScript. Это означает, что существующий код мог использовать raise как имя переменной, функции, свойства объекта и т.д. Введение его в качестве ключевого слова теоретически может сломать такой код. Например, если где-то определено var raise = 5; или функция function raise(x) { ... }, то после появления ключевого слова это станет синтаксической ошибкой или будет восприниматься иначе. Чтобы минимизировать ущерб, можно рассмотреть контекстное ключевое слово: сделать так, что raise распознается как ключевое только внутри конструкций try { ... } catch { ... } finally { ... }, где по грамматике ожидается возврат значения. Подход с контекстными (или "ограниченными") ключевыми словами уже применялся: например, yield в ES6 стал ключевым словом только внутри генераторов, await – только внутри async функций или модулей. Вероятно, raise может быть сделан зарезервированным в строгом режиме или только в специальных контекстах, чтобы не сломать существующие скрипты. Но в любом случае это обсуждаемо: возможно, придется выбрать другое слово или подход (альтернативы рассмотрим ниже).
• Поддержка инструментов (lint, форматтеры, IDE): Появление нового синтаксиса потребует обновления инструментов разработки. Правила линтеров (ESLint и др.) должны будут научиться корректно парсить try как выражение и не ругаться, например, на присваивание в const через try { ... } catch { ... }. Также могут появиться новые правила: например, предупреждение о коде после raise (как упоминалось), или требование, чтобы и в try, и в catch присутствовал raise (это, скорее, синтаксический уровень, но линтер может помогать ловить такие ошибки понятнее). Форматтеры кода (Prettier и др.) тоже должны знать про новый синтаксис, чтобы правильно расставлять отступы. В средах вроде VSCode появятся подсветка и автодополнение. Это все рабочие моменты, которые сопровождают любую новую возможность языка.
• Изменения в парсерах и AST: JavaScript-движки (V8, SpiderMonkey, JavaScriptCore) должны будут адаптировать парсер под новый конструктив. Появится необходимость распознавать конструкцию try как часть выражения. По спецификации, скорее всего, будет введено что-то вроде TryExpression. AST (Abstract Syntax Tree) форматы, такие как ESTree, тоже расширятся новым типом узла, например TryExpression с узлами block, handler (catch) и finalizer. Внутри него новые узлы RaiseExpression для точек выхода. Инструменты, работающие с AST (бабели, трансформеры, minifiers) тоже потребуют обновления. Хотя изменение не тривиальное, оно локализовано: не затрагивает тонны существующей семантики, а лишь добавляет новый вид выражения и оператор. Близкий по масштабу пример – добавление опциональной цепочки (a?.b), которое тоже потребовало внести новый тип узла. Сообщество обычно справляется с такими изменениями достаточно быстро, особенно если фича популярна.
• Влияние на читаемость и соглашения: Хотя цель предложения – улучшить читаемость, у него могут быть и критики. Некоторые разработчики могут найти непривычным видеть try/catch внутри выражения. Будут вопросы стиля: можно ли злоупотреблять и создавать слишком громоздкие выражения? Будет ли код сложнее отладки, если в одной строке много всего, включая обработку ошибок? Эти проблемы не технические, но влияют на принятие. Вероятно, появятся рекомендации (в документации или сообществе), как уместно использовать try-выражения, а когда лучше оставить явный try/catch блок. Например, правило: если логика обработки исключений сложная (больше нескольких строк), лучше не вкладывать ее в тернарный оператор, а писать отдельно. Или: избегать вложенных try-выражений ради читабельности. Эти аспекты находятся вне рамок спецификации, но важно иметь их в виду.
• Производительность: В текущем виде try/catch в JavaScript несет незначительные издержки, особенно когда исключения не происходят. Введение try-выражений с raise скорее всего аналогично по затратам: пока не брошено исключение, выполнение идет линейно, с парой дополнительных проверок на raise. Если raise вызывается, это примерно то же, что return из функции – мгновенное завершение блока. Возможно, реализация затронет механизм completion records в спецификации (уже сейчас у каждого блока есть значение завершения). Тонкая оптимизация может потребоваться, но ничего не указывает на серьезное падение производительности. Тем не менее, движкам надо будет обработать новые пути выхода (например, в JIT-компиляции), чтобы эффективно предсказывать и инлайнить такие вещи. Это работа оптимизаторов, но особых препятствий нет.

Аналоги в других языках

Идея делать конструкции вроде try/catch вычисляемыми выражениями не нова. В разных языках реализовано разными путями:

Kotlin: В Kotlin блочный оператор try/catch является выражением и может возвращать значение. Конструкция очень похожа на предлагаемую, но без специального ключевого слова – результатом считается последнее выражение, выполненное в блоке try либо в блоке catch kotlinlang.org. Например, в Kotlin:

val num = try {
    riskyOperation()
} catch (e: Exception) {
    -1
}

Здесь num получит либо результат riskyOperation(), либо -1 в случае исключения. Блок finally в Kotlin, хотя и выполняется всегда, не влияет на результат выражения (его используют только для побочных эффектов) kotlinlang.org. Наше предложение для JavaScript, по сути, стремится к аналогичному удобству, но более явным синтаксисом. Мы вводим raise чтобы явно обозначать возвращаемое значение, вместо неявного "последнего выражения". Это решение принято из соображений ясности: явный ключевой слово снижает вероятность ошибки, когда, например, кто-то забыл, что надо вернуть значение, или случайно разместил ненужный код после нужного выражения.

Scala: В языке Scala try-catch-finally также является выражением. Поскольку Scala – язык выражений, там практически все конструкции могут возвращать значение. Семантика как у Kotlin: результат – это либо значение из try, либо из catch. Отличие Scala в том, что catch там основан на сопоставлении с образцом (pattern matching), но суть та же. Кроме того, в Scala имеется класс Try (в библиотеке), представляющий результат выполнения, который может быть успешным (Success) или содержать исключение (Failure). Он позволяет писать код в функциональном стиле: вместо использования ключевых слов, оборачивает результат в объект. Например:

import scala.util.Try
val resultTry = Try(riskyOperation())  // вернет Success(значение) или Failure(ошибка)
val finalVal = resultTry.getOrElse(defaultValue)

Такой подход похож по цели – избавиться от явного try/catch при присваивании – но реализован через библиотечный класс. Наш путь – интегрировать удобство на уровне языка, без дополнительных объектов-оберток.

Rust: В Rust отсутствуют исключения, поэтому напрямую аналога try-catch нет, но есть результатный тип Result (и Option) и оператор ? для распространения ошибок. Интересно, что в версии Rust 2018+ появилось понятие try-блока (пока экспериментального, на момент появления) doc.rust-lang.org. Try-блок в Rust выглядит как:

let result: Result<T, E> = try {
    let x = doSomething()?;   // если doSomething() вернет Err, то выходим из try-блока
    let y = doOther()?;       // аналогично, ? оператор возвращает из блока при ошибке
    compute(x, y)
};

Здесь, если внутри блока встречается ?, он немедленно прерывает блок, возвращая Err(...) как значение всего блока. Если же ни один ? не сработал, результатом будет Ok(...) с последним выражением (в примере compute(x,y)). Таким образом, Rust решает сходную задачу – получить из блока либо успех, либо ошибку – но делая это через типизацию (Result) вместо исключений, а try {} + ? служат синтаксическим сахаром. Для нас Rust интересен тем, что демонстрирует: блок-выражение с ранним выходом по специальному оператору – концепция не чуждая современным языкам. По аналогии, raise в JavaScript – это "ранний выход" с готовым значением, не приводящий к выбросу исключения.

Python (PEP 463): Как упоминалось, в Python был предложен синтаксис для "exception-catching expressions". Идея заключалась в том, чтобы позволить конструкцию вида:

result = expr1 except SomeException: expr2

Это бы означало: вычислить expr1, и если возникает SomeException, вместо него взять значение expr2. Предложение (PEP 463) обосновывалось тем, что в Python не хватает выражения для EAFP-стиля (Easier to Ask Forgiveness than Permission) прямо внутри других выражений peps.python.org. Например:

process(value if key in dict else default)      # LBYL стиль (есть тернарный оператор)
process(dict[key] except KeyError: default)     # Предлагаемый EAFP стиль

Хотя PEP 463 был вежливо отклонен Guido ван Россумом (отчасти из опасений усложнения языка), он является показателем потребности. Однако предлагаемое решение в JS несколько отличается синтаксисом. Python-предложение реализовывало это более лаконично (буквально как инфиксный оператор except внутри выражения). Мы же в JavaScript стараемся сохранить привычную форму try { } catch { } даже в выражении, и вводим raise вместо перегрузки существующего слова. Это выглядит более громоздко чем PEP 463, но лучше вписывается в синтаксис JS. Стоит отметить, что Python до сих пор не имеет никаких try-выражений — то есть разработчики по-прежнему используют обычные try/except блоки.

Другие языки: В ряде функциональных и скриптовых языков есть схожие механизмы. Например, OCaml/F# (ML-семейство) – там try...with (эквивалент catch) является выражением, возвращающим значение, поскольку в этих языках вообще все конструкции возвращают значение. Haskell не имеет исключений как основного механизма, но есть монада Either/IO для обработки ошибок без выброса. Go пошел по пути вообще отказаться от исключений, возвращая ошибку как второй результат функции. В контексте JavaScript, где исключения есть и активно используются, наш подход ближе к Kotlin/Scala – сделать их использование более гибким и менее шаблонным.

Заключение

В этом документе был представлен набросок предложения для TC39, позволяющего использовать try/catch/finally как выражение с возвращаемым значением, благодаря введению нового ключевого слова raise. Мы рассмотрели мотивацию (упрощение шаблонного кода, улучшение декларативности), детально описали предполагаемый синтаксис и поведение raise, включая правила его использования и взаимодействия с finally. Также были обсуждены потенциальные подводные камни (ключевое слово, AST, линтеры, совместимость) и показано, что подобные возможности существуют или обсуждались в других языках (Kotlin, Scala, Rust, Python и др.), что подтверждает ценность идеи. Наконец, проанализированы альтернативные подходы и обосновано, почему выбран именно данный путь.

Призыв к обсуждению: На стадии 0 важно собрать мнения и выявить возможные проблемы, которые не покрыты черновиком. Открыты вопросы могут включать:

• Выбор ключевого слова: подходит ли raise по смыслу и нет ли риска путаницы с "raise exception" из других языков?
• Нужен ли параметр в finally или можно обойтись без нового синтаксиса вроде finally (raised)?
• Все ли случаи учтены (например, поведение при вложенных try-выражениях, при использовании break/return внутри блоков и т.п.)?
• Насколько часто такая конструкция пригодится на практике, есть ли реальные примеры из кода, где это существенно улучшит качество?

Обсуждение этих вопросов, а также эксперименты с прототипированием (в Babel либо в отдельных ветках V8) помогут продвинуть предложение к Stage 1 и дальше, если сообщество посчитает идею полезной. Мы надеемся, что предоставленный explainer ясно передает суть и преимущества try-выражений с raise, и с нетерпением ждем обратной связи от TC39 и сообщества JavaScript разработчиков.

Ссылка на начальный драфт пропозала:

https://github.com/dmitrytarassov/tc39-raise-proposal-draft?tab=readme-ov-file

Привет, мой дорогой читатель. В прошлый раз я рассказал тебе о том, как я считал поинты для эйрдропа от 0y. В этот раз - я расскажу тебе о том, как писал контракт. Я изначально предполагаю, что ты немного шаришь в блокчейне, и понимаешь что такое газ (о нем сегодня будет много), в частности.

Давай, сначала, попробуем определиться с той проблемой, которая есть. И так, у нас есть n токенов Eigen и надо каким-то образом из раздать. Как это можно сделать? Напрашивается несколько вариантов:

• Разослать в ручную. Просто, долго и дорого - по итогу. Запираем одного человека в комнате с компуктером, даем ему список адресов и ждем. Просто - да. Долго - о, да! А еще надо насыпать ему эфира на оплату газа. Даже если предположить, что 1 трансфер будет стоить в районе 3 USDT в газе - трансфер на все 264 аккаунта, обойдется уже под 1К. И это на низком газе, что в последнее время - редкость. Так что, это еще и дорого.
• Мультисенд. Вариант. Но тут тоже есть нюансы. Вопервых, надо запариться с контрактом. Если нет подходящего, придется писать. А если есть, то платить за газ, ведь нам все равно надо выполнить почти 300 трансферов, а это в любом случае затратно. И еще вот какой психологический момент, не то что бы так не принято делать, но пользователь не сможет почувствовать свою принадлежность сообществу, если просто получит свои токены, никуда не нажав.
• Контракт. Это самый крутой вариант. Мы можем написать контракт, и каждый пользователь, которого мы укажем - сможет в интерфейсе нажать на кнопку, отправить транзакцию и получить свои токены. Мне нравится. 0Y нравится. Пользователям тоже должно понравиться. Ну и еще момент, на себя бы берем только оплату деплоя контракта, а за дроп - платит уже пользователь. Вполне справедливо.

7 раз отмерь - 1 раз отрежь

Еще перед тем, как написать первую строчку я задумался на тему того, какие могут быть уязвимости у такого контракта. И как мне из избежать. Ну во первых у контракта должно быть какое-то управление. То есть должен быть владелец, который мог бы принимать какие-то решения. Окей, как-будто Ownable, чуть позже расскажу тебе про это. Возможно дроп надо будет поставить на паузу, звучит как Pausable. Окей, что еще...

Атака повторного входа.

Окей, как обезопаситься? Умные дядьки уже все придумали за нас. ReentrancyGuard из OpenZeppelin спешит на помощь. Забираем модификатор nonReentrant и пишем код. Код, конечно, лучше писать тоже обдумано, к этому как раз и переходим.

Time to code

Окей, открываем единственный нормальный редактор для Solidity - Remix IDE, создаем пустой шаблон и погнали писать. Первым делом забираем все необходимое из OpenZeppelin.

import "@openzeppelin/contracts/token/ERC20/IERC20.sol";
import "@openzeppelin/contracts/access/Ownable.sol";
import "@openzeppelin/contracts/security/ReentrancyGuard.sol";
import "@openzeppelin/contracts/security/Pausable.sol";

Ownable и Pausable - реализуют логику владения и управления контрактом, ReentrancyGuard - защитит от атаки повторного входа, IERC20 - интерфейс токена.

contract EigenAirdrop0y is Ownable, ReentrancyGuard, Pausable { // наследуемся
    IERC20 public immutable token; // объявляем переменную токена

    constructor(address _token) Ownable(msg.sender) { // инициализируем овнера
        require(_token != address(0), "Invalid token address");
        token = IERC20(_token); // определяем переменную токена
    }
}

Пока что изи. Давай перегрузим пару методов, отвечающих за состояние контракта, добавив к ним модификатор onlyOwner.

pragma solidity ^0.8.0;

contract Ownable {
    address public owner;

    constructor() {
        owner = msg.sender; // Устанавливаем владельцем создателя контракта
    }

    modifier onlyOwner() {
        require(msg.sender == owner, "Not the owner");
        _; // Продолжить выполнение функции
    }

    function restrictedFunction() public onlyOwner {
        // Логика функции, доступная только владельцу
    }
}

function pause() external onlyOwner {
    _pause(); // вызов родительского _pause();
}

function unpause() external onlyOwner {
    _unpause(); // вызов родительского _unpause();
}

Го некст! Надо определить кому и сколько будем дропать. Значение и состояние будем хранить в маппингах <address => uint256> и <address => bool>.

mapping(address => uint256) public airdropList;
mapping(address => bool) public done;

Пишем view функцию, которая вернет значение, может ли аккаунт получить дроп.

function canGetAirdrop(address account) public view returns(bool) {
    return airdropList[account] > 0 && done[account] == false;
}

Ну и саму функцию дропа:

// внешняя, если unpaused, если не повторный вход
function airdrop() external nonReentrant whenNotPaused {
    // проверяем, заклеймли ли уже - если да, ревертим выполнение
    require(!done[msg.sender], "Airdrop is already claimed");
    
    // забираем сколько отправлять
    uint256 amount = airdropList[msg.sender];
    // проверяем
    require(amount > 0, "No airdrop available for this address");
    // помечаем, что чел получил дроп еще до ктого, как мы отправили
    // я же говорил, что безопасность - это не только использовать
    // готовые решения, но и самому головой думать
    done[msg.sender] = true;

    // забираем баланс ДО
    uint256 balanceBefore = token.balanceOf(address(this));
    // выполняем трансфер
    // если валится - откатываемся
    require(token.transfer(msg.sender, amount), "Token transfer failed");
    // забираем баланс ПОСЛЕ
    uint256 balanceAfter = token.balanceOf(address(this));
    // если проверка не проходит - откатываемся
    require(balanceBefore - balanceAfter == amount, "Transfer amount mismatch");
}

Добавим, функцию вывода средств с контракта.

// только владелец может ее вызвать
function cancel() external onlyOwner {
    // забираем баланс
    uint256 balance = token.balanceOf(address(this));
    // выполняем трансфер
    require(token.transfer(msg.sender, balance), "cancel: Token transfer failed");
}

Ну, и напоследок - закроем получение ETH контрактом.

receive() external payable {
    revert("This contract does not accept ETH");
}

Осталось только в конструкторе инициализировать сам список airdropList.

// Test
airdropList[0x3877fbDe425d21f29F4cB3e739Cf75CDECf8EdCE] = 100000000000000000;
airdropList[0x187F087EC07511A0D77EDA2cF6f137eE49d12389] = 200000000000000000;
airdropList[0x96e4Ba33113319a67AC5eAb899579351aBf9b1c1] = 100000000000000000;

Time to test

Надо бы все это дело протестировать... Создаем свой токен, кладем рядом контракт.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;

import "@openzeppelin/contracts/token/ERC20/ERC20.sol";

contract EigenTest is ERC20 {
    constructor(uint256 initialSupply) ERC20("EigenTest", "tEigen") {
        _mint(msg.sender, initialSupply * 10**18);
    }

    function mint(uint256 supply) public {
        _mint(msg.sender, supply);
    }
}

Идем в кран, получаем токены в Sepolia. Деплоим токен, получаем адрес, деплоим контракт, перебрасываем на контракт токены. Все, можно тыкать...

Глазами и руками - это конечно хорошо, но надо бы все это дело автоматизировать... Давай попробуем написать тест для среды hardhat. Только сначала надо обновить контракт, добавить функцию добавления адреса в airdropList.

function addToAirdropList(address account, uint256 amount) external onlyOwner {
    require(account != address(0), "Invalid address");
    require(amount > 0, "Amount must be greater than 0");
    airdropList[account] = amount;
}

Все, погнали писать тест:

const { expect } = require("chai");

describe("EigenAirdrop0y Contract", function () {
    let EigenAirdrop0y, airdrop, token, owner, addr1, addr2, addr3;

    beforeEach(async function () {
        // Загружаем контракт токена ERC20 и создаем экземпляр
        const ERC20 = await ethers.getContractFactory("MockERC20"); // создайте тестовый ERC20 контракт
        token = await ERC20.deploy("TestToken", "TT", 18);
        await token.deployed();

        // Загружаем и развертываем контракт airdrop
        EigenAirdrop0y = await ethers.getContractFactory("EigenAirdrop0y");
        [owner, addr1, addr2, addr3] = await ethers.getSigners();
        airdrop = await EigenAirdrop0y.deploy(token.address);
        await airdrop.deployed();

        // Переводим токены на контракт airdrop для распределения
        await token.transfer(airdrop.address, ethers.utils.parseEther("1.0"));
    });

    it("Should add address to airdrop list", async function () {
        await airdrop.addToAirdropList(addr1.address, ethers.utils.parseEther("0.1"));
        expect(await airdrop.airdropList(addr1.address)).to.equal(ethers.utils.parseEther("0.1"));
    });

    it("Should check if an address can get airdrop", async function () {
        await airdrop.addToAirdropList(addr1.address, ethers.utils.parseEther("0.1"));
        expect(await airdrop.canGetAirdrop(addr1.address)).to.be.true;
    });

    it("Should not allow claiming airdrop twice", async function () {
        await airdrop.addToAirdropList(addr1.address, ethers.utils.parseEther("0.1"));
        await airdrop.connect(addr1).airdrop();
        expect(await airdrop.done(addr1.address)).to.be.true;
        await expect(airdrop.connect(addr1).airdrop()).to.be.revertedWith("Airdrop is already claimed");
    });

    it("Should distribute tokens correctly", async function () {
        await airdrop.addToAirdropList(addr1.address, ethers.utils.parseEther("0.1"));
        const balanceBefore = await token.balanceOf(addr1.address);
        await airdrop.connect(addr1).airdrop();
        const balanceAfter = await token.balanceOf(addr1.address);
        expect(balanceAfter.sub(balanceBefore)).to.equal(ethers.utils.parseEther("0.1"));
    });

    it("Should allow the owner to cancel and withdraw remaining tokens", async function () {
        const contractBalance = await token.balanceOf(airdrop.address);
        await airdrop.cancel();
        expect(await token.balanceOf(owner.address)).to.equal(contractBalance);
        expect(await token.balanceOf(airdrop.address)).to.equal(0);
    });

    it("Should revert if address tries to get airdrop without being on the list", async function () {
        await expect(airdrop.connect(addr2).airdrop()).to.be.revertedWith("No airdrop available for this address");
    });
});

Шикарно. Давай убедимся, что мы защищены от "повторного входа". Для этого напишем атакующий контракт:

// SPDX-License-Identifier: GPL-3.0
pragma solidity ^0.8.0;

import "./EigenAirdrop0y.sol";

contract ReentrancyAttack {
    EigenAirdrop0y public airdrop;
    bool public attacked = false;

    constructor(EigenAirdrop0y _airdrop) {
        airdrop = _airdrop;
    }

    // Функция для начала атаки
    function attack() external {
        // Начало первой попытки вызова
        airdrop.airdrop();
    }

    // Функция обратного вызова для повторного входа
    fallback() external {
        if (!attacked) {
            attacked = true;
            // Повторная попытка вызова `airdrop` в ходе первой попытки
            airdrop.airdrop();
        }
    }
}

И сам тест:

const { expect } = require("chai");

describe("Reentrancy Protection in EigenAirdrop0y Contract", function () {
    let EigenAirdrop0y, airdrop, token, owner, attacker, addr1;

    beforeEach(async function () {
        // Загружаем контракт токена ERC20 и создаем экземпляр
        const ERC20 = await ethers.getContractFactory("MockERC20"); // создайте тестовый ERC20 контракт
        token = await ERC20.deploy("TestToken", "TT", 18);
        await token.deployed();

        // Загружаем и развертываем контракт airdrop
        EigenAirdrop0y = await ethers.getContractFactory("EigenAirdrop0y");
        [owner, attacker, addr1] = await ethers.getSigners();
        airdrop = await EigenAirdrop0y.deploy(token.address);
        await airdrop.deployed();

        // Переводим токены на контракт airdrop для распределения
        await token.transfer(airdrop.address, ethers.utils.parseEther("1.0"));

        // Добавляем адрес атакующего в список для airdrop
        await airdrop.addToAirdropList(attacker.address, ethers.utils.parseEther("0.1"));
    });

    it("Should prevent reentrancy attack", async function () {
        // Разворачиваем атакующий контракт
        const ReentrancyAttack = await ethers.getContractFactory("ReentrancyAttack");
        const reentrancyAttack = await ReentrancyAttack.deploy(airdrop.address);
        await reentrancyAttack.deployed();

        // Переводим часть токенов атакующему контракту
        await airdrop.addToAirdropList(reentrancyAttack.address, ethers.utils.parseEther("0.1"));

        // Проверяем, что повторный вход не удается
        await expect(reentrancyAttack.attack()).to.be.revertedWith("ReentrancyGuard: reentrant call");
    });
});

Супер! Все работает!

Что можно улучшить?

• Хранение массива получивших дроп. Если бы не газ - я бы складывал всех, кто получил дроп в отдельный массив. В эфире нельзя вытащить весь маппинг из контракта, только по ключу. Это неудобно. В дальнейшем придется писать больше кода. Но опять же - я старался сэкономить на газе при потенциальном вызове эйрдропа.
• События. Можно было бы эмитить событие при каждом успешном дропе, чтоб потом вытаскивать их из ноды. Но, так как тут нет особо сложной логики, я буду вытаскивать потом эвент трансфера, который эмитится из контракта токена. Тоже пойдет.

Эти 2 пункта еще создадут мне головную боль, но это будет потом. В следующей статье я расскажу тебе о том, как все это дело мы в фронт завернули, и как я выводил аналитику по всей этой истории. Но это потом, а пока - пока.

PS: Нормальный газ пришлось подождать. Все было не так плохо, как на момент написания статьи, но все же...

Часть первая: как мы токены считали.

Еще на том этапе, когда не было понятно, сколько токенов насыплют - было понимание, что это произойдет. А значит надо готовиться. Мы выбрали вот такую формулу: points = nETH * 10000 * days. Иными словами 10,000 поинтов за 1 делегированный эфир в день.

Какие вводные еще есть? Адрес контракта EigenLayer, адрес оператора 0y, адрес пользователя, текущая дата и какая-то начальная дата (не надо же нам искать с генезис блока эфира). Да начнется ресерч!

Сначала идем в эзерскан и смотрим, что там с контрактом, находим в нем транзу, которой мы знаем, что кто-то делегировал оператору (я просто сам заделегировал 0.02 эфира (через лайдо)). Идем в логи и смотрим: опа, тут есть событие OperatorSharesIncreased. Что-то мне подсказывает, что в транзакции на отмену делегации будет что-то подобное. И да, вот и OperatorSharesDecreased. Кстати, там же в логах видим адрес нашего оператора 0y, это плюс.

Окей, забираем hex этих 2х событий и получаем 2 константы, которые будем искать (ну и еще 2 объявим с именами экшенов):

export const OperatorSharesDecreased =  "0x6909600037b75d7b4733aedd815442b5ec018a827751c832aaff64eba5d6d2dd";
export const OperatorSharesDecreasedAction = "OperatorSharesDecreased";
export const OperatorSharesIncreased =  "0x1ec042c965e2edd7107b51188ee0f383e22e76179041ab3a9d18ff151405166c";
export const OperatorSharesIncreasedAction = "OperatorSharesIncreased";

Ок, го некст. Идем на алхимию, создаем ключ, подключаем в код провайдера.

const provider = new ethers.providers.JsonRpcProvider(
  `https://eth-mainnet.g.alchemy.com/v2/${process.env.ALCHEMY_PRIVATE_KEY}`
);

Как же хорошо, что это эфир и нет проблем с архивными нодами, поэтому прямо из алкхимии можно вытащить всю историю и все логи. 5 минут гугла и находим, как получить исторические логи, еще 10 минут и код готов:

async function getLogs(
  provider: ethers.providers.JsonRpcProvider, // провайдер
  delegationContract: string, // контракт управляющий делегациями EigenLayer
  operator: string, // оператор, в нашей ситуации 0y
  operation: string, // действие, которые мы ищем в логе
  fromBlock?: number, // с какого блока ищем
  toBlock?: number // до какого блока ищем
) {
  return await provider.getLogs({
    fromBlock: fromBlock ? toBigNumber(fromBlock).toHexString() : undefined,
    toBlock: toBlock ? toBigNumber(toBlock).toHexString() : undefined,
    address: delegationContract || EigenLayerDelegationContract,
    topics: [operation, operator],
  });
}

Что тут происходит? Если непонятно по комментам, то у меня есть: что искать (оператор и действие), где искать (в контракте EigenLayer) и когда искать (между fromBlock и toBlock).

Ну и сам вызов:

const increasingLogs = await getLogs(
  provider,
  contract,
  _operator,
  OperatorSharesIncreased,
  fromBlock,
  toBlock
);

И что же нам вернется? ethers.provider.Log[] - говорит мне IDE. Массив какого-то говна лога, ок. Идем в код, идем в доку, и видим:

export interface Log {
  blockNumber: number;
  blockHash: string;
  transactionIndex: number;
  removed: boolean;
  address: string;
  data: string;
  topics: Array<string>;
  transactionHash: string;
  logIndex: number;
}

Оооок... Что-то мне подсказывает, что меня интересует data и topics. Смотрим глазами в консоль:

Смотрим в output, смотрим еще раз в etherscan, смотрим output, смотрим etherscan, смотрим output, смотрим etherscan... Ну вы поняли. Пишем парсер лога.

Сначала мы распарсим дату, получим набор строк. Смотрим еще раз в эзерскан и понимаем, что нулевой элемент - это наш стейкер. Записали. Оператора забираем из топиков. То, что здесь называется стратегией - тоже берем из даты, нам это еще понадобится, но скажу честно, на начальном этапе я не понимал зачем и что это вообще такое. Amount - тоже берем из даты.

function parseLogs(
  logs: ethers.providers.Log[],
  action: OperatorReStakerAction["action"]
): Map<string, OperatorReStakerAction[]> {
  const stakers: Map<string, OperatorReStakerAction[]> = new Map();

  for (const log of logs) {
    const data = parseData(log.data); // будет ниже, там особенно интересно

    const staker = parseAddress(data[0]).toLowerCase();

    const stakerData = stakers.get(staker) || [];
    const awsOperator = parseAddress(log.topics[1]);
    const strategy = parseAddress(data[1]);

    stakers.set(staker, [
      ...stakerData,
      {
        amount: toBigNumber(`0x${data[2]}`),
        block: toBigNumber(log.blockNumber),
        action,
        strategy,
        awsOperator,
      },
    ]);
  }

  return stakers;
}

Если интересует, что за parseAddress - то все просто.

Длинна адреса - 20 байт. А значит нам надо убрать 24 лидирующих нуля и добавить 0x в начало, чтобы получить адрес.

function parseAddress(data: string) {
  const [, addr] = data.split("0".repeat(24));
  return `0x${addr}`;
}

Так, давай разберемся с парсингом даты. Что мы видим?

0x000000000000000000000000269df236ae8bd066e9de7670a7cbfd8cbafd11c200000000000000000000000013760f50a9d7377e4f20cb8cf9e4c26586c658ff0000000000000000000000000000000000000000000000002470a7f61539b90a

Длинная, как Мисисипи строка, с лидирующим 0x. Если интересно - вот ссылка на спеку, но что важно знать - там может быть все, что угодно, что начинается с 0x. В нашей ситуации - несколько групп по 32 байта (64 символа) в каждой. Погнали писать парсер:

function parseData(d: string): string[] {
  let str = d; // убираем лидирующий 0x он нам тут наш не нужон
  if (d.startsWith("0x")) {
    str = removeLeading0x(d);
  }
  
  const arr = [...str];
  const result: string[] = [];
  
  if (arr.length === 0) {
    return [];
  } else if (arr.length === 1) { // вспомнить бы зачем, хотя припоминаю когда в data встречал 0x0, но тут явно не то случай. Но пусть будет.
    return [str];
  }
  
  let line = "";
  
  arr.forEach((l) => {
    line += l;
    // каждые 32 байта - новая строка
    // 2 символа - 1 байт
    // нужно 64 символа
    if (line.length === 64) {
      result.push(line);
      word = "";
    }
  });

  if (line.length > 0) {
    result.push(line);
  }
  
  return result;
}

Все, что надо мы написали, осталось все это вызвать:

export async function getOperatorDelegatorsHistory(
  provider: ethers.providers.JsonRpcProvider,
  {
    fromBlock,
    toBlock,
    operator,
    delegationContract,
  }: {
    fromBlock?: number;
    toBlock?: number;
    operator: string;
    delegationContract?: string;
  }
): Promise<Map<string, OperatorReStakerAction[]>> {
  const _operator = `0x${"0".repeat(24)}${removeLeading0x(operator)}`;

  const stakers: Map<string, OperatorReStakerAction[]> = new Map();

  const contract = delegationContract || EigenLayerDelegationContract;
  const increasingLogs = await getLogs(
    provider,
    contract,
    _operator,
    OperatorSharesIncreased,
    fromBlock,
    toBlock
  );

  const decreasingLogs = await getLogs(
    provider,
    contract,
    _operator,
    OperatorSharesDecreased,
    fromBlock,
    toBlock
  );

  const increasingActions = parseLogs(
    increasingLogs,
    OperatorSharesIncreasedAction
  );

  const decreasingActions = parseLogs(
    decreasingLogs,
    OperatorSharesDecreasedAction
  );

  const stakersArray = [
    ...new Set([...increasingActions.keys(), ...decreasingActions.keys()]),
  ];

  stakersArray.forEach((staker) => {
    const inc = increasingActions.get(staker) || [];
    const dec = decreasingActions.get(staker) || [];

    stakers.set(
      staker,
      [...inc, ...dec].sort((a, b) => (a.block > b.block ? 1 : -1))
    );
  });

  return stakers;
}

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

describe("getOperatorDelegatorsHistory", () => {
  it("check", async () => {
    const provider = new ethers.providers.JsonRpcProvider(
      `https://eth-mainnet.g.alchemy.com/v2/${process.env.ALCHEMY_PRIVATE_KEY}`
    );

    const data = await getOperatorDelegatorsHistory(provider, {
      fromBlock: 19576120,
      operator: "0xd172a86a0f250aec23ee19c759a8e73621fe3c10",
    });

    const realDelegator = "0x3877fbDe425d21f29F4cB3e739Cf75CDECf8EdCE";
    
    // строки сравнивать проще, так что конвертим реальные данные
    const realDelegations: string[] = [
      ["19388606404441598", 19676121, OperatorSharesIncreasedAction],
      ["4847151601110399", 19677373, OperatorSharesIncreasedAction],
      ["969344385657699", 19689181, OperatorSharesDecreasedAction],
    ].map(([amount, block, action]) => `${amount}_${block}_${action}`);

    expect(data.has(realDelegator));
    
    const delegations: string[] = (
      data.get(realDelegator.toLocaleLowerCase()) || []
    ).map(
      (delegation) =>
        // конвертим данные из бч в строку
        `${delegation.amount.toString()}_${delegation.block.toNumber()}_${
          delegation.action
        }`
    );

    for (const realDelegation of realDelegations) {
      expect(delegations.includes(realDelegation)).toBeTruthy();
    }
  });
});

Либа

Так как кода много, надо бы сделать его переиспользуемым. В итоге получилась либа, которую я просто подгрузил в нужный момент в проект. Да, 0 скачиваний в неделю - это успех, но пофиг, это для себя в первую очередь. Исходники тут.

Поинты

Ок! Мы получили мапу стейкеров с их действиями в протоколе, все, что осталось - это посчитать, сколько поинтов получил каждый. Для начала, нужно вычислить дату блока, тут все просто provider.getBlock(block) вернет нам инфу по блоку, в том числе и timestamp. Вполне логично, что грузить каждый раз это нам не нужно, так что можно сохранить полученные данные в базу (я просто писал в файл).

function getBlockTimeStampBase(provider: ethers.providers.JsonRpcProvider, base: Map<number, number>) {
  const stack: Map<number, number> = new Map(base);

  return async (block) => {
    if (stack.has(block)) {
      return stack.get(block);
    }

    const timestamp = (await provider.getBlock(block)).timestamp;
    stack.set(block, timestamp);

    return timestamp;
  };
}

const getBlockTimeStamp = getBlockTimeStampBase(provider, timestamps);

const timestamp = await getBlockTimeStamp(stake.block.toNumber());

Далее идем по массиву действий и проводим вычисления: определяем дату, определяем дату следующего события, потому что считать нам надо только в рамках одного события, ведь дальше стейк изменится. Если нет следующей даты - берем дату окончания кампании (мы зафинализировали на 20871841 блоке). Изи катка.

_accountStakes.forEach((stake, index) => {
      if (!strategies.includes(stake.strategy.toLowerCase())) {
        return;
      }

      // https://etherscan.io/block/20871841
      const finalBlockTimestamp = 1727800151000;
      const nextDate = _accountStakes[index + 1] ? +`${_accountStakes[index + 1].timestamp}000` : finalBlockTimestamp;
      const distance = nextDate - +`${stake.timestamp}000`;

      const days = distance / 1000 / 60 / 60 / 24;

      if (stake.action === OperatorSharesDecreased) {
        stakeValue -= BigInt(stake.amount.toString())
      } else {
        stakeValue += BigInt(stake.amount.toString())
      }

      const value = BigInt(days.toFixed(0)) * stakeValue;
      
      rewards.push(value * BigInt(10_000))
});

return ethers.utils.formatEther(rewards.reduce((acc, value) => acc += value, BigInt(0)))

А, ну да, так как мы работаем с эфиром, то у нас тут числа без плавающей точки, но с 18 нулями, а мне бы в простом виде, так что дергаем ethers.utils.formatEther. И еще важный момент: формат таймстемпа, чтоб в js работать с ним - добавляем 3 нуля в конец.

Что-то пошло не так

Помнишь, я писал про то что выцепляю какую-то "стратегию" из лога. Дак вот, когда EigenLayer выдали первый дроп, его можно (и нужно) было запихнуть в стейкинг, чтоб еще немного подзаработать. Блок был примерно на 3 месяца, я запихнул свои 100 EIGEN, получил примерно 4.5. APR 18% - найс. Дак вот, стратегия - это как раз то, какой рестейкнутый токен ты запихиваешь в оператора: stETH, wBETH, ankrETH... или Eigen. И вот тут то и случилась жопа, потому что под каждый токен деплоился отдельный управляющий контракт, и их пришлось глазами выискивать. Заняло час рутинной работы, но все получилось.

const __data = `1. ETH
0x0000000000000000000000000000000000000000-0xbeac0eeeeeeeeeeeeeeeeeeeeeeeeeeeeeebeac0

2. WETH
0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2

3. rETH
0xae78736cd615f374d3085123a210448e74fc6393-0x1bee69b7dfffa4e2d53c2a2df135c388ad25dcd2

4. stETH
0xae7ab96520de3a18e5e111b5eaab095312d7fe84-0x93c4b944d05dfe6df7645a86cd2206016c51564d

5. cbETH
0xbe9895146f7af43049ca1c1ae358b0541ea49704-0x54945180db7943c0ed0fee7edab2bd24620256bc

6. osETH
0xf1c9acdc66974dfb6decb12aa385b9cd01190e38-0x57ba429517c3473b6d34ca9acd56c0e735b94c02

7. swETH
0xf951e335afb289353dc249e82926178eac7ded78-0x0fe4f44bee93503346a3ac9ee5a26b130a5796d6

8. oETH
0x856c4efb76c1d1ae02e20ceb03a2a6a08b0b8dc3

9. wBETH
0xa2e3356610840701bdf5611a53974510ae27e2e1-0x7ca911e83dabf90c90dd3de5411a10f1a6112184

10. ankrETH
0xe95a203b1a91a908f9b9ce46459d101078c2c3cb-0x13760f50a9d7377e4f20cb8cf9e4c26586c658ff

11. ETHx
0xa35b1b31ce002fbf2058d22f30f95d405200a15b-0x9d7ed45ee2e8fc5482fa2428f15c971e6369011d

12. sfrxETH
0xac3e018457b222d93114458476f3e3416abbe38f

13. lsETH
0x8c1bed5b9a0928467c9b1341da1d7bd5e10b6549-0xae60d8180437b5c34bb956822ac2710972584473

14. mETH
0xd5f7838f5c461feff7fe49ea5ebaf7728bb0adfa-0x298afb19a105d59e74658c4c334ff360bade6dd2`;

const strategies = __data
  .split("\n")
  .filter(l => l.startsWith("0x"))
  .map(s => s.toLowerCase().split("-")[1])
  .filter(Boolean);

Поиск облегчило то, что люди заносили в 0y, так что список не полный. Ребята сказали игнорить "не эфир", так что не пришлось возиться с определением курса Eigen на момент занесения. По этому фильтруем по стратегии (исключаем Eigen) и двигаемся дальше.

Тут, как бы, все. Человек заходил в интерфейс, подключал кошель, а мы ему показывали сколько поинтов у него есть на текущий день.

Это поинты, а сколько токенов?

Когда эйген отсыпали операторам, 0y решили распределить половину наград стейкерам, у которых баланс поинтов был больше 1М, и между ними - пропорционально, относительно размера стейка (я пролетел, у меня 38к было). Тут даже писать нечего, простейшая математика в гугл таблицах.

Что дальше?

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

??= — Нулевое присваивание

Начнём с того, что этот оператор работает (если честно так и подмывало тут и закончить предложение) только, если переменная null или undefined. Это как сказать: «Если ничего не задано, тогда бери вот это». Пример:

let foo;
foo ??= 42;
console.log(foo); // 42 — подхватил значение, потому что foo был undefined

foo ??= 100;
console.log(foo); // 42 — остался, ведь foo уже не null и не undefined

В ECMAScript под капотом называет это Nullish Coalescing Assignment — логика такая: проверяет, пусто ли (null/undefined), если да, — присваивает, если нет, — пропускает. Эдакий мини-страж от ошибок, когда значение по умолчанию нужно только при «пустоте».

||= Логическое присваивание через OR

А вот этот оператор нужен, когда надо присвоить значение, если переменная — falsy (то есть false, 0, '', null, undefined или NaN). Представь: проверка на пустые строки или ноль и дефолтное значение при этом. Кайф:

let y = '';
y ||= 'Привет';
console.log(y); // "Привет", потому что y был пустой строкой

let z = 'Я тут';
z ||= 'Пока';
console.log(z); // "Я тут", потому что z уже правдиво

Это называется Logical OR Assignment. Логика простая — если переменная «ложна», то она обновляется. Если правдива — то остаётся как есть. Меньше `if`, меньше кода, больше читаемости.

&&= — Логическое присваивание через AND

А вот тут всё наоборот: присваивание происходит только если переменная truthy. Представь: «если правда, то продолжай». Чёткий инструмент для ситуации, когда обновляем только работающие переменные.

let alpha = 5;
alpha &&= 10;
console.log(alpha); // 10 — обновил, потому что alpha был 5

let beta = 0;
beta &&= 10;
console.log(beta); // 0 — остался как был, ведь beta был falsy

По спецификации это Logical AND Assignment. Если переменная правдива, оператор присвоит новое значение, иначе — нет.

На самом деле тут применений я вижу меньше, чем у первых 2х, их то я точно буду использовать, а этот.. хзхз!

Итого, у нас есть три инструмента, которые решают частую головную боль по работе с дефолтами и проверками. Да, не без подводных камней, но эти операторы чистят код, делая его понятнее.

PS: там есть всякое, типа >>= и <<<= но камон, когда ты последний раз использовал сдвиг влево? Ай не п**ди, не использовал ты его.

PPS: Если твой лид говорит тебе, что такое нельзя использовать в проде потому "ну там же эдж, там же сафары" - тыкни носом его в зеленые циферки

Ну и еще, вот ссылка на tc39 - ты знаешь что делать (забить болт).

Что такое dePIN?

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

Ключевая идея dePIN заключается в децентрализации не только цифровых активов и данных, но и физической инфраструктуры, предоставляя пользователям возможность напрямую участвовать в построении и управлении этими системами через токены и смарт-контракты.

Как работает dePIN?

Ключевые элементы:

1. Инфраструктурные провайдеры: Физические лица или компании, которые предоставляют реальную инфраструктуру для сети (оборудование, пропускная способность, энергия и т.д.).
2. Токенизация: Участники сети вознаграждаются токенами за поддержку сети (например, предоставление серверных мощностей, данных или доступа к сети).
3. Смарт-контракты: Они обеспечивают автоматическое выполнение соглашений между участниками сети, что минимизирует необходимость в посредниках и гарантирует прозрачность транзакций.

Примеры dePIN-проектов

1. Helium — децентрализованная сеть, предоставляющая доступ к беспроводной связи через физические узлы. Пользователи устанавливают "хоты" — физические устройства, которые обеспечивают локальное покрытие и зарабатывают токены за работу.
   https://depinhub.io/projects/helium
   https://docs.helium.com/
2. HiveMapper — краудсорсинговая платформа для создания децентрализованных карт. Водители устанавливают специальные камеры в свои машины и зарабатывают токены, предоставляя обновленные географические данные.
   https://depinhub.io/projects/hivemapper
   https://docs.hivemapper.com/
3. Filecoin — платформа для децентрализованного хранения данных, где пользователи предоставляют свободное место на своих серверах и получают вознаграждение за это.
   https://depinhub.io/projects/filecoin
   https://filecoin.io/

Преимущества и вызовы dePIN

Преимущества:

• Прозрачность: Благодаря блокчейн-технологиям, все транзакции в сети остаются прозрачными, что позволяет избегать манипуляций и повысить доверие между участниками.
• Стимулы для участников: Токенизация позволяет участникам напрямую получать вознаграждение за участие в физической инфраструктуре, что открывает новые модели бизнеса.
• Снижение централизации: dePIN снижает зависимость от централизованных поставщиков услуг и инфраструктуры, делая экосистему более устойчивой и независимой от корпоративных интересов.

Вызовы:

• Юридические и регуляторные барьеры: Взаимодействие с физическими активами в разных юрисдикциях вызывает сложности с регулированием, лицензированием и налогообложением.
• Надежность инфраструктуры: Поддержание высокой надежности физической инфраструктуры требует значительных ресурсов, что может усложнить масштабирование таких проектов.
• Мотивированность участников: Экономическая модель вознаграждений должна быть тщательно продумана, чтобы долгосрочно стимулировать участников к поддержке сети.

Влияние на реальный мир

Заключение

dePIN представляет собой шаг в сторону реальной интеграции блокчейна с физической инфраструктурой. Это не только расширяет возможности использования технологии, но и открывает путь к построению более децентрализованных, устойчивых и эффективных систем в реальном мире. Однако перед проектами dePIN стоят серьёзные вызовы, которые необходимо решать на пути к массовому внедрению.

Контекст

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

mapping(uint256 => mapping(address => uint256)) private _accesses;

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

struct AccessType {
  address client;
  uint256 level;
}

function getRequests(address account)
external view returns(AccessType[] memory) {
// code
}

И вот тут-то я и столкнулся с проблемой.

Проблема

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

function getAccessLevel_WRONG(address user)
public view returns(AccessLevel[] memory) {
  AccessLevel[] memory result;
  uint256 j = 0;
  
  for(uint256 i = 0; i < programs.length; i++) {
    address program = programs[i];
    uint8 accessLevel = accessLevels[user][program];
    
    if (accessLevel > 0) {
      result[j] = AccessLevel(
        program,
        accessLevel
      );
      j++;
    }
  }
  
  return result;
}

И ведь самое интересное, что код компилируется, линтер не выдает ошибку! Вроде все чисто!

А вот при исполнении вылетает Panic Exception!

Решение

Несколько раз проверив весь код, а так же логом пройдясь почти по каждой строчке, я смирился с тем, что мое первое подозрение верно - что-то не то с массивом. Если бы у меня был простой, не memory, массив, я бы просто добавлял в него элементы через .push, но тут так не прокатит. Так же я мог бы из функции вернуть 2 значения, в первом указывать адреса, а во втором - уровни, но это тоже как-то не тру.

Минимальные знания низкоуровневых языков говорят мне, что массивы без указанной длинны - не бро, а с указанной - бро. Ок, давайте проверим. Предположим, что у нас добавлена только одна программа и мы заменим:

-- 
function getAccessLevel_WRONG(address user)
public view returns(AccessLevel[] memory) {
  AccessLevel[] memory result;

++
function getAccessLevel_WRONG(address user)
public view returns(AccessLevel[1] memory) {
  AccessLevel[] memory result = new AccessLevel[](1);

Вуаля! Все заработало... Штош, похоже, мне таки придется посчитать сначала длину всего массива. Meh... Мне кажется, что я пишу дополнительный код, который будет тратить процессорное время выполнения view функции, но на самом деле это просто необходимость, с которой мне надо смириться.

function getAccessLevel_CORRECT(address user)
public view returns(AccessLevel[] memory) {
    uint256 length = 0;

    for(uint256 i = 0; i < programs.length; i++) {
        address program = programs[i];
        uint8 accessLevel = accessLevels[user][program];

        if (accessLevel > 0) {
            length++;
        }
    }

    AccessLevel[] memory result = new AccessLevel[](length);

    uint256 j = 0;

    for(uint256 i = 0; i < programs.length; i++) {
        address program = programs[i];
        uint8 accessLevel = accessLevels[user][program];

        if (accessLevel > 0) {
            result[j] = AccessLevel(
                program,
                accessLevel
            );
            j++;
        }
    }

    return result;
}

Мне еще предстоит разобраться, с глубинным поведением этого кода, но смело можно сказать три вещи:

• Solidity плохо умеет в динамические массивы, с этим надо смириться, но это не проблема;
• Линтер не отработал, а компилятор схавал - это уже плохо. Я привык доверять Remix IDE и её(его? IDE - это он или она?) инструментам. Вот по компилятору - да, тут еще есть вопросы, думаю что Remix IDE сможет мне помочь в этом своим дебаггером. Ну или придется погонять код в Ganache, посмотрим.
• TDD рулит. Ясен красен тесты я пошел писать не сразу! Да, сначала этот код оказался в сети, а уже потом я увидел ошибку, и если честно - пару недель игнорил ее, потому что у меня были еще и другие методы для получения чуть более конкретных данных. Но вот именно написание теста, параллельно с переписыванием кода помогло мне разобраться, что именно идет не так.

Код с контрактом и тестами я залил на github, так что велкам посмотреть.

Послесловие

Мне еще предстоит разобраться, что именно идет не так в этом коде, вероятно кто-то из вас, читателей (ну я надеюсь кто-то это читает), знает в чем причина! дайте мне знать, я с радостью приму ваше решение. Не скажу, что потратил на решение проблемы много времени, наверное, потому что изначально предполагал проблему с длинной массива. Но вот сейчас я дописываю этот текст, и уже чувствую, что время не потрачено впустую, а значит все не напрасно.

После-послесловие

Есть идея: создать сообщество блокчейн разработчиков, где каждый сможет делиться своим опытом, в виде статей или в виде диалога. Чтобы каждый участник сообщества был значим, чтобы были общие проекты, чтобы совместно поднимать ноды. А поверх всего этого DAO, ну и шаттл на луну. Ну это все идеи, которые на данном этапе находятся на стадии зарождения. Нас пока 4 человека, и если честно - последнее сообщение в чате было неделю назад. Посмотрим, что из этого выйдет, но если я случайно заинтересовал тебя мой читатель - напиши мне!