Основная сеть Ethereum по-прежнему обладает наибольшей ликвидностью ETH — на момент написания статьи примерно в 100 раз больше, чем OP . В то же время мы все хотим, чтобы пользователи взаимодействовали со смарт-контрактами L2, чтобы им не приходилось платить комиссию в размере 50 долларов США за каждое простое действие.

Итак, как мы можем использовать ликвидность Mainnet, используя контракты L2 для чеканки NFT?

Именно с такой дилеммой мы столкнулись с нашим проектом — Kiwi News . Это агрегатор ссылок, похожий на Hacker News, ориентированный на криптотехнологии, продукты и культурный контент.

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

Но чтобы на самом деле использовать приложение для голосования, отправки ссылок и комментариев, наши пользователи должны сначала купить наш NFT. Точно так же, как вам нужно заплатить газ для отправки транзакции Ethereum или вам нужно заплатить при создании учетной записи Farcaster на Kiwi News, вам необходимо создать OP NFT для участия.

Но на самом деле мы не начинали продажу NFT в OP Mainnet. Наш NFT сначала был доступен только на Ethereum, но, как оказалось, во время мании $PEPE, чеканка нашего NFT стоимостью 15 долларов стоила 19 долларов . Поэтому мы решили перейти на OP Mainnet.

И это действительно казалось беспроигрышным вариантом: наши пользователи платили меньше, а мы зарабатывали столько же и технически могли даже повысить цены.

Но мы быстро поняли, что у большинства людей — даже давних пользователей Ethereum — не было денег, подключенных к OP Mainnet. Конечно, они могли бы перейти на мост, но их удаление с нашего сайта означало бы общее снижение конверсии продаж. И, как гласит старая мантра распределения, вы должны «ловить рыбу там, где она есть».

Итак, мы решили решить эту проблему, сделав добычу NFT доступной как на L1, так и на L2.

Технические детали

Вот в чем проблема: наш NFT-контракт находится на уровне L2, и есть только функция Zora mintWithRewards(...), вызываемая для создания NFT. Тем не менее, новый пользователь Kiwi News может иметь средства только в основной сети Ethereum.

Если у них есть средства в основной сети OP, то это здорово; они могут просто покупать и выпускать NFT напрямую.

Однако, если у них есть средства в основной сети Ethereum, нам придется сначала заставить их соединить эти средства с основной сетью OP и, в идеале, купить NFT во время процесса соединения.

Мы ни при каких обстоятельствах не хотим, чтобы пользователь подписывал несколько транзакций, поскольку это приведет к увеличению оттока клиентов и сделает весь процесс более громоздким. Необходимость подтверждения нескольких транзакций подряд означает более высокую вероятность того, что что-то пойдет не так, поэтому мы начали искать способы объединить мост и атомарную покупку NFT.

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

Прежде всего, вы должны понимать, что система Optimism имеет API как на L1, так и на L2. Например, вы можете вызвать контракт на L2, чтобы вывести свои средства в L1. Или вы можете вызвать функцию на L1, чтобы внести средства непосредственно на L2.

Эти интерфейсы особенно полезны в нашем случае, поскольку OptimismPortal ( Etherscan , исходный код ) в основной сети Ethereum имеет функцию под названием OptimismPortal.depositTransaction(...):

/// @notice Accepts deposits of ETH and data, and emits a TransactionDeposited event for use in
///         deriving deposit transactions. Note that if a deposit is made by a contract, its
///         address will be aliased when retrieved using `tx.origin` or `msg.sender`. Consider
///         using the CrossDomainMessenger contracts for a simpler developer experience.

/// @param _to         Target address on L2.
/// @param _value      ETH value to send to the recipient.
/// @param _gasLimit   Amount of L2 gas to purchase by burning gas on L1.
/// @param _isCreation Whether or not the transaction is a contract creation.
/// @param _data       Data to trigger the recipient with.

function depositTransaction(
    address to,
    uint256 value,
    uint64 gasLimit,
    bool isCreation,
    bytes memory data
)
public
payable;

Обратите внимание, насколько depositTransaction(...)аргументы похожи на имя обычной транзакции Ethereum? Есть address to, uint256 valueи bytes memory dataкодировка деталей вызова функции. uint64 gasLimitЗдесь тоже нет ничего удивительного: определение максимального количества газа, которое может использовать транзакция, и bool isCreationнеобходимости bytes memory dataсоздания нового контракта.

depositTransaction(...)Аргументы аналогичны, поскольку внутри процесса мостового соединения узел основной сети OP отправит транзакцию в основную сеть OP с соответствующими параметрами, когда процесс мостового соединения вызывающего абонента L1 завершится успешно.

Это особенно полезно для нас, когда мы хотим создать NFT с использованием mintWithRewards(...)функции Zora в основной сети OP, а также позволить пользователям вызывать эту функцию из основной сети Ethereum без отдельных транзакций моста и чеканки.

Итак, давайте углубимся в код. Ниже приведен интерфейс нашего контракта на сбор NFT в основной сети OP, развернутого через Zora:

function mintWithRewards(
    address recipient,
    uint256 quantity,
    string calldata comment,
    address mintReferral
) external payable returns (uint256);

Для функции требуется address recipientполучатель NFT, a uint256 quantityдля определения количества NTF, a string calldata commentдля комментариев в цепочке и для address mintReferralуказания реферера за рекомендацию монетного двора.

Итак, если мы возьмем на себя работу внешнего инженера, которому поручено создать кнопку монетного двора NFT, которая работает как в основной сети OP, так и в основной сети ETH, вот пошаговый процесс того, что нам нужно будет вычислить:

1. Проверьте баланс ETH пользователя в OP Mainnet. Если пользователь может позволить себе чеканить NFT, предложите ему позвонить mintWithRewards(...)непосредственно в Optimism.

2. Если у пользователя недостаточно ETH в основной сети OP, проверьте баланс пользователя в основной сети Ethereum. Если пользователь не может позволить себе купить NFT в сети ETH, сообщите ему об этом; в противном случае перейдите к шагу 3.

import { fetchBalance, getAccount } from "@wagmi/core";
import { mainnet, optimism } from "wagmi/chains";
Import { utils } from “ethers”;

const { address } = getAccount();
if (!address) {
  throw new Error("Account not available");
}

const balance = {
  mainnet: (await fetchBalance({ address, chainId: mainnet.id })).value,
  optimism: (await fetchBalance({ address, chainId: optimism.id })).value,
};

const mintPriceETH = utils.parseEther(“0.00256”);

if (balance.optimism >= mintPriceETH) {
  // mint on OP mainnet
} else if (balance.mainnet >= mintPriceETH) {
  // mint on ETH mainnet
} else {
  throw new Error(“Insufficient balance”);
}

1. Теперь, когда мы знаем, что пользователь собирается создать NFT из сети ETH через OptimismPortal, нам нужно подготовить два вызова ETH. Один предназначен для вызова depositTransaction(...)L1, другой — для вызова mintWithRewards(...)L2. Мы передадим второй вызов, предназначенный для выполнения в основной сети OP, в depositTransaction(...)файл bytes memory data. Вот как мы это делаем:

3.1. Мы строим данные вызова функции, mintWithRewards(...)собирая входные данные для mintWithRewards(...)функции на L2. Мы используем эфиры interface.encodeFunctionData(name, [...inputs])для упаковки вызова в шестнадцатеричную строку.

import { getAccount } from "@wagmi/core";
import { Contract } from "@ethersproject/contracts";
import { mainnet, optimism } from "wagmi/chains";

import { getProvider } from “./viem-adapter.mjs”;

const nftAddress = 0xabc…;
const nftABI = [{...}];

function prepareL2Call() {
  const { address } = getAccount();
  const opProvider = getProvider({ chainId: optimism.id });
  const contract = new Contract(nftAddress, nftABI, opProvider);
  const recipient = address;
  const quantity = 1;
  const comment = “minting this from mainnet!”
  const referrer = null;
  return contract.interface.encodeFunctionData("mintWithRewards", [
    recipient,
    quantity,
    comment,
    referrer,
  ]);
}

3.2. Затем depositTransaction(...)мы выбираем цель вызова функции как address toи устанавливаем uint256 valueзначение ETH, которое хотим передать address to. Что касается uint64 gasLimit, мы должны смоделировать стоимость вызова ETH на Optimism с балансом пользователя. Однако баланс ETH пользователя недостаточен, помните? Таким образом, любой estimateGasвызов с провайдером основной сети OP и адресом пользователя будет ошибочным.

Следовательно, мы предлагаем обнаружить статическую гостевую функцию, например, вызвав mintWithRewards(...)функцию вручную и используя это значение в коде.

Что касается других аргументов, bool isCreationis falseи bytes memory dataнаконец содержит данные вызова, сгенерированные на шаге 3.1.

import { prepareWriteContract } from "@wagmi/core";
import { mainnet } from "wagmi/chains";

const optimismPortalAddress = 0x…;
const optimismPortalABI = [{...}, …];

async function writeToDeposit(nftAddress, price, data) {
  const isCreation = false;
  const gasLimit = 170000;

  return await prepareWriteContract({
    address: optimismPortalAddress,
    abi: optimismPortalABI,
    functionName: "depositTransaction",
    args: [nftAddress, price, gasLimit, isCreation, data],
    value: price,
    chainId: mainnet.id,
  });
}

3.3. Важно отметить, что нам придется внести как минимум сумму, равную uint256 valueили превышающую сумму msg.valueвызова L1. Это гарантирует, что некоторое количество эфира будет помещено в Optimism и доступно для mintWithRewards(...)вызова. Мы делаем это, установив msg.valueзначение price.

3.4. Наконец, собрав все аргументы, мы предлагаем пользователю подписать эту транзакцию для основной сети Ethereum.

import { useContractWrite } from "wagmi";
// …

function prepareL2Call(...) {...}
async function writeToDeposit(...) {...}
// …


const BuyButton = (props) => {
  // …
  const { write } = useContractWrite(config);
  // …

  return (
    <button disabled={!write} onClick={() => write?.()}>
    Buy NFT
    </button>
  );
}

Вот и все! Это то, что вам нужно сделать, если вы хотите атомарно создать NFT на Optimism, обеспечивая вызов непосредственно из основной сети Ethereum.

Хотя фрагменты кода не совсем соответствуют рабочему коду, который мы используем в Kiwi News, они очень близки к коду, исходный код которого мы открыли. Полную последовательность подготовки и многое другое вы можете найти на нашем GitHub . И вы можете попробовать это напрямую, зайдя на нашу страницу минтинга NFT .

Разумеется, использование depositTransaction(...)функции OptimismPortal — не единственный вариант перехода с уровня L1 на уровень L2. На данный момент существует множество бирж, предлагающих аналогичные услуги. Однако особенность портала OP заключается в том, что он сохраняет адрес msg.senderтого адреса, который подписал и отправил транзакцию в основной сети ETH. Это может быть особенно важно, когда ваше децентрализованное приложение полагает, что этот адрес должен быть законным.

Заключение

При переносе нашего NFT из Ethereum в OP Mainnet нам нужен был способ использовать ликвидность L1, в то же время позволяя всем нашим пользователям чеканить его из OP Mainnet.

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

Мы подробно описали наш код React.js, который проверяет балансы Ethereum и L2, чтобы обеспечить правильный вызов для каждого пользователя. Если у пользователя нет OP ETH, он подключается напрямую через портал.

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

Мы надеемся, что этот пост был полезен вам в вашей работе. В Kiwi News мы всегда работаем над тем, чтобы максимально эффективно обслуживать экосистему — будь то последние новости, сообщения в блогах или репозитории GitHub. Мы будем рады видеть вас среди читателей! Посетите нас на https://kiwinews.xyz .

Перевод оригинальной статьи от 16 апреля 2024

https://blog.oplabs.co/minting-nfts-from-mainnet-or-op/

Серия Fault Proof Deep-Dive — это результат сотрудничества команды Coinbase Blockchain Security (BlockSec) и OP Labs, целью которого является предоставление подробной информации обо всех основных компонентах Fault Proofs. Делясь этой информацией, мы надеемся побудить других узнать больше об архитектуре и технических аспектах Fault Proofs. Вместе мы можем двигаться к децентрализованному будущему блокчейнов OP Stack L2.

В этом сообщении блога мы рассмотрим реализацию автономной виртуальной машины Cannon Fault Proof Proof (FPVM). Обратите внимание, что реализации FPVM ончейн и офчейн вместе составляют Cannon. Тем не менее, мы разграничим эти два понятия, попросив Cannon в этом сообщении блога ссылаться только на реализацию оффчейн.

Что такое Cannon?

В предыдущем сообщении блога мы представили MIPS.sol, ончейн FPVM. Cannon — это офчейн-аналог MIPS.sol, написанный на Golang. Однако, в отличие от MIPS.sol, оффчейн-реализация Cannon отвечает за гораздо больше шагов в спорной игре. Кроме того, Cannon — единственная FPVM, используемая для игр по разрешению ошибок в стеке OP.

Поток управления защитой от сбоев

Еще раз давайте рассмотрим процесс проверки ошибок, чтобы понять, где находится Cannon.

На приведенной выше диаграмме, воссозданной на основе видео Fault Proof Walkthrough от Clabby, мы видим, что Cannon взаимодействует с OP-Challenger и OP-Program. OP-Challenger — это компонент, который управляет инициированием задач и взаимодействием с спорной игрой, а OP-Program обрабатывает вывод выходных данных L2 из входных данных L1. Однако диаграмма представляет собой упрощенное взаимодействие между OP-Challenger, Cannon и OP-Program.

В ходе активной спорной игры игра пополам перейдет от поворота выходных корней L2 к констатированию хэшей-свидетелей. Кэннон отвечает за генерацию хэшей-свидетелей состояния, которые представляют собой подтверждение результатов вычислений инструкций MIPS в FPVM. Cannon будет запущен только после того, как игра-спор достигнет этой точки. Эта часть игры пополам известна как трассировка выполнения. До этого момента OP-Challenger консультировался с OP-Node относительно корней вывода состояния и не использовал OP-Program или Cannon. Однако, как только придет время запустить Cannon для игры в спор, уже скомпилированная OP-программа будет загружена в виртуальную машину Cannon, которая затем начнет выполнять инструкции MIPS.

Во время трассировки выполнения игры пополам Cannon выполнит множество инструкций MIPS и первоначально предоставит OP-Challenger хэши состояния-свидетеля. В конечном итоге одна-единственная инструкция MIPS будет идентифицирована как источник разногласий между участниками активного спора. Теперь Cannon сгенерирует доказательство свидетеля, которое содержит всю информацию, необходимую для запуска инструкции MIPS в цепочке MIPS.sol. Окончательное пост-состояние инструкции MIPS затем будет использоваться для разрешения игры со спором о неисправности.

Обзор компонентов cannon

Cannon состоит из нескольких файлов Golang, которые вместе обладают гораздо большей функциональностью, чем ончейн MIPS.sol. Это необходимо, поскольку Cannon отвечает за большее количество частей спорной игры, чем MIPS.sol. Эти файлы Golang можно сгруппировать по основным компонентам Cannon, которые они реализуют, в том числе: загрузчик исполняемого и связываемого формата (ELF), управление памятью и состоянием, MIPSEVM и генерация доказательств-свидетелей.

ELF Loader

OP-Program — это код, который будет скомпилирован в файл ELF, который, в свою очередь, содержит инструкции MIPS для запуска в Cannon. Чтобы запустить содержимое файла ELF в Cannon, его необходимо загрузить в MIPSEVM. Этот процесс включает в себя перебор заголовков ELF для определения всех программ, которые необходимо загрузить в 32-битное пространство памяти, определение начальных значений для счетчика программ (ПК) и NextPC, создание экземпляров стека, кучи и сегмента данных. указатели в памяти и исправление любых несовместимых функций. Исправление несовместимой функции просто перезаписывает первые инструкции внутри функции с возвратом к исходному указателю, а затем без операции (NOP). Исправление двоичного файла, загруженного в MIPSEVM, важно, поскольку FPVM не может выполнять многие системные вызовы и не поддерживает такие функции, как параллелизм.

Управление памятью и состоянием

Cannon хранит и обслуживает все 32-битное адресное пространство памяти, доступное MIPSEVM. Ограничений на размер памяти, хранимой вне цепочки, нет, но для MIPS.sol невозможно хранить все 32-битное адресное пространство памяти. Таким образом, память хранится в двоичной древовидной структуре данных Меркла в Cannon. Для MIPSEVM эта структура данных абстрагируется с помощью функций GetMemory(), ReadMemoryRange() и SetMemory(). Когда придет время сгенерировать доказательство-свидетель, Cannon закодирует до двух доказательств Меркла в памяти, чтобы MIPS.sol мог использовать их при выполнении инструкции MIPS.

MIPSEVM

Внутри Cannon находится MIPSEVM, который реализует 32-битную архитектуру набора команд MIPS III (ISA) с обратным порядком байтов. В отличие от MIPS.sol, MIPSEVM будет выполнять множество инструкций MIPS, а также отвечает за отслеживание доступа к памяти, которая будет использоваться для кодирования второго доказательства памяти. Однако реализации как оффчейн, так и ончейн виртуальных машин должны давать одинаковые результаты при одинаковых инструкциях, памяти и состоянии регистра. Это очень важно для обеспечения того, чтобы ожидаемое пост-состояние от MIPSEVM было таким же, как фактическое пост-состояние, сгенерированное MIPS.sol, которое будет использоваться для разрешения спорной игры.

Генерация доказательств свидетелей

Как только одна инструкция MIPS будет идентифицирована как источник разногласий между участниками игры по спору о неисправностях, Cannon сгенерирует свидетельское доказательство, чтобы ту же инструкцию можно было запустить в цепочке MIPS.sol. В доказательстве-свидетеле закодирована следующая информация: состояние выполнения виртуальной машины, подтверждение памяти для адреса выполняемой инструкции и дополнительное доказательство памяти, необходимое только для инструкций загрузки, сохранения или некоторых системных вызовов. Кроме того, если инструкции MIPS потребуется предварительный образ, Cannon также передаст ключ и смещение предварительного образа в OP-Challenger, чтобы его можно было опубликовать в цепочке PreimageOracle.sol.

Документация для Cannon

На этом мы завершаем наше глубокое погружение в Cannon. В дополнение к этому сообщению в блоге Coinbase создала подробную документацию, в которой содержится более подробная информация о каждом из компонентов, составляющих Cannon. Проверьте это на Fault Proof VM — Cannon | Optimism Docs , и если вас интересует официальная техническая спецификация Cannon от Optimism, вы можете просмотреть ее в Технической спецификации Cannon .

Перевод оригинальной статьи от 9 апреля 2024

https://blog.oplabs.co/fault-proof-deep-dive-part-2-cannon/?ref=the-optimistic-dev-blog-newsletter

Консоль разработчика Superchain делает запуск вашего приложения в Superchain максимально простым и доступным. Независимо от того, выполняете ли вы развертывание в Ethereum, Base, Fraxtel, Mode, OP Mainnet, Redstone, Lisk или Zora, у разработчиков нет недостатка в решениях для масштабирования, но выбор инструментов для использования может быть обременительным.

Консоль разработчика Superchain объединяет инструменты и специальные предложения для ускорения разработки и снижения затрат на разработчиков. Superchain питается не только от OP Stack, но и от надежной экосистемы сообщества, инструментов и инфраструктуры Collective.

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

На следующем этапе консоли разработчика Superchain вы получите доступ к предложению о скидках на развертывание. Это сделает развертывание в Superchain бесплатным!

Подпишитесь на консоль разработчиков Superchain , чтобы быть в курсе последних предложений.

При запуске мы сотрудничали с Alchemy, Gelato, QuickNode и ThirdWeb, чтобы предложить экономию и поддержку инфраструктуры. Все эти ресурсы представлены на одной удобной для просмотра платформе, что устраняет трудности и позволяет разработчикам легко находить и получать доступ к инструментам, необходимым для создания потрясающего пользовательского опыта.

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

Начните строить сегодня!

Перевод оригинальной статьи от 22 марта 2024 года

https://blog.oplabs.co/build-faster-build-together-introducing-the-superchain-developer-console/?ref=the-optimistic-dev-blog-newsletter

Полнофункциональная система защиты от сбоев OP Stack сегодня появилась на OP Sepolia, основной тестовой сети для OP Mainnet. Этот защищенный от ошибок протокол поддерживает механизм связывания, совместимый с стимулами, и проверку без разрешения, которая позволяет любому участвовать в системе без списка разрешенных.

В то время как каждый разработчик, внесший вклад в этот выпуск, гордится этой вехой, инженеры экосистемы уже рассчитывают на достижение «многофункциональной нирваны», которая позволит Optimism достичь второй стадии децентрализации. Продолжайте читать, чтобы узнать больше о том, как этот выпуск закладывает основу для суперцепи 2-го уровня.

Несанкционированные доказательства на ОП Сеполия

Сегодняшний запуск тестовой сети представляет полнофункциональный протокол защиты от сбоев, который поддерживает проверку без разрешения . Это означает, что вывод токенов ETH и ERC-20 из цепочек стека OP может быть инициирован без участия какой-либо доверенной третьей стороны. Это также означает, что недействительный вывод средств может быть оспорен и удален любым пользователем, желающим участвовать в протоколе.

Несанкционированная проверка — не единственное, что представлено в этом выпуске. Этот запуск также включает в себя структуру проверки ошибок для стека OP, что означает, что дополнительные системы проверки, такие как Asterisc , могут легко встраиваться в существующие смарт-контракты. Дополнительные доказательства могут действовать как сети безопасности, которые выявляют ошибки в других доказательствах, что в конечном итоге открывает дверь для децентрализации этапа 2 — полной зависимости от системы защиты от сбоев без какого-либо резервного совета безопасности. Если это обновление будет принято Optimism Governance для включения в стек OP, Optimism займет уникальное положение в гонке за множественными возможностями и децентрализацией этапа 2.

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

Следующая остановка: мультидоказательная нирвана.

Конечная цель системы защиты от ошибок OP Stack выходит за рамки реализации проверки ошибок в тестовой или основной сети; он нацелен на «нирвану множественных доказательств», которая может положить конец зависимости, которую сегодня L2 имеют от советов безопасности или мультиподписей. Когда появится больше систем доказательств, которые могут подкреплять друг друга, стек OP может начать полностью доверять своим доказательствам без необходимости в совете безопасности, выступающем в качестве системы безопасности.

Благодаря полнофункциональной системе защиты от сбоев, работающей на OP Sepolia, был достигнут значительный прогресс в первой схеме доказательства для OP Stack. Тем не менее, природа системы с открытым исходным кодом означает, что ряд других механизмов проверки находился в разработке в то же время, в том числе такими командами, как State Channels, RISCZero, O(1) Labs, AltLayer, Protolambda (в OP Labs), Test в Prod, а также инженеры Виллем Олдинг и Эрик Ту.

Для справки, вот некоторые из схем доказательства, которые в настоящее время находятся в разработке:

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

Критические изменения в выпуске OP Sepolia

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

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

Переходим к проверке ошибок в сетях Superchain

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

Разработчики выпустили MVP отказоустойчивой системы OP Stack в октябре 2023 года; Полнофункциональная версия системы появилась сегодня на OP Sepolia. Следующим шагом станет обеспечение защиты от сбоев в сетях Superchain. Следите за новостями о запуске.

Перевод оригинальной статьи от 19 марта 2024 г

https://blog.oplabs.co/open-source-and-feature-complete-fault-proofs-bring-permissionless-validation-to-the-op-sepolia-testnet/?ref=the-optimistic-dev-blog-newsletter

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

Краткая история шардинга Ethereum

До 2018 года члены сообщества вынашивали множество диких амбиций в отношении шардинга. К 2019 году дорожная карта для Ethereum 2.0 включала сегментирование выполнения на основе EWASM, а на Devcon Osaka произошел значительный поворот, в результате чего количество сегментов сократилось с 1024 до 64. В этом году дизайн Beacon Chain стал более компактным, а доказательство хранения стало центральным компонентом шардинга.

2020 год ознаменовался саммитом основных разработчиков Eth1x в Париже, прямо перед тем, как глобальная пандемия вызвала повсеместный хаос. Во время пандемии сообщество Ethereum сосредоточилось на разработке цепочки маяков и представило первые проекты «Слияния». Пост Виталика Бутерина о «дорожной карте, ориентированной на объединение, получил значительную поддержку для масштабирования решений, и год завершился успешным запуском PoS Beacon Chain.

В 2021 году, с запуском цепочки маяков, внимание переключилось на данксардинг и выборку доступности данных с помощью KZG, возглавляемую Proto на основе работы Данкрада Файста. Развертывания начали существенно влиять на уровень 1 Ethereum, но слияние имело приоритет над разработкой фазы 1. В этом году также были проведены хардфорки Altair (уровень консенсуса) и London (уровень выполнения), а в октябре был утвержден дизайн Merge.

2022 год стал решающим, поскольку сообщество сосредоточилось на данкшардинге. Виталик и Данкрад предложили для этого сбалансированное разделение между уровнем исполнения и уровнем консенсуса. В EthDenver Прото возглавил команду хакатона, которая разработала и реализовала предложение по EIP-4844, что привело к значительному вкладу и вехам, включая различные прототипы. Мофи Тайво из OP Labs, а также Майкл Де Хоог и Роберто Баярдо из Coinbase внесли значительный вклад в создание этих прототипов. В сентябре 2022 года сообщество Ethereum отпраздновало слияние, расчистив путь для включения EIP-4844 в основные призывы разработчиков по завершению года.

В 2023 году усилия были сосредоточены на совместимости клиентов с реализацией EIP 4844, церемонии KZG и обширном тестировании через сети разработки, нагрузочные тесты и теневые форки, а также подготовку к запланированным обновлениям тестовой сети.

К 2024 году сообщество Ethereum развернуло тестовые сети, включая Goerli, Sepolia и Holesky, что привело к обновлению основной сети до 4844 13 марта, что стало важной вехой в продолжающейся эволюции Ethereum в направлении большей масштабируемости и эффективности.

Создание обновления и решение задач

Путь по внедрению EIP-4844 в сеть Ethereum был не чем иным, как титанической задачей. Эти междисциплинарные исследования и разработки, продолжавшиеся более двух лет, были направлены на масштабирование пропускной способности Ethereum до беспрецедентного уровня, решая на этом пути многочисленные проблемы. Вот лишь некоторые из них, с которыми столкнулись основные разработчики:

• Сложность дизайна и прототипа. На начальном этапе, возглавляемом исследователями, пришлось разобраться со сложной конструкцией EIP-4844, заложив основу для того, что должно было произойти.

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

• Проектирование пула транзакций. Команда Geth взяла на себя задачу разработать пул транзакций, который мог бы противостоять DoS и проблемам с нагрузкой, что является критическим компонентом масштабируемости.

• Поддержка новой криптографии. Внедрение криптографии KZG потребовало специальной команды для проведения специальной церемонии, обеспечивающей безопасность и целостность сети.

• Обеспечение надежности сети: от стресс-тестирования пропускной способности до организации сетей разработки, тестовых сетей и теневых вилок — команда EF Devops сыграла ключевую роль в обеспечении готовности сети к EIP-4844.

Размышления и будущие амбиции в области масштабирования

Экосистема Ethereum резко изменилась за годы, прошедшие с момента появления EIP-4844. От амбициозных предложений по шардингу и перехода к дорожной карте, ориентированной на объединение, путь был отмечен важными вехами, включая запуск цепочки Beacon Chain с доказательством доли и ключевое слияние.

Заглядывая в будущее, можно сказать, что концепция полного данксардинга и не только открывает захватывающие возможности. Некоторые из них включают запланированное постепенное увеличение количества больших двоичных объектов на блок, исследование инновационных решений обеспечения доступности данных, таких как PeerDAS и Full DAS, а также параллельные усилия по исследованиям и разработкам по таким ключевым темам, как устойчивость к MEV, деревья Verkle и оптимизация сети. Все это сигнализирует о том, что впереди нас ждет яркая дорожная карта.

Реализация EIP-4844 — это праздник для сообщества Ethereum. Размышляя об этом путешествии, мы признаем коллективные усилия основных разработчиков и исследователей Ethereum. Предстоящий путь полон возможностей и проблем, но если история EIP-4844 и учит нас чему-то, так это тому, что сообщество Ethereum более чем способно воплотить дальновидные идеи в реальность.

Авторы и участники EIP-4844

Ядро обновления было тщательно разработано командой исследователей и разработчиков Ethereum Foundation. Виталик Бутерин (@vbuterin) и Данкрад Файст (@dankrad) сыграли важную роль в разработке полного дизайна данксардинга, заложив основу для обновления. Дидерик Лоераккер (@protolambda) выступал в качестве моста от исследований к проектированию, разрабатывая первоначальные спецификации и реализуя прототип исполнительного уровня. Джордж Кадианакис (@asn-d6) сыграл решающую роль в обеспечении внедрения криптографических библиотек KZG разработчиками-клиентами и поддержке интеграции установки KZG. Мэтт Гарнетт (@lightclient) и Мофи Тайво (@Inphi) внесли свой вклад в создание прототипов на уровне исполнения, проверку спецификаций и межоперационное тестирование L1. Наконец, Ансгар Дитрихс (@adietrichs) поделился ценной информацией об улучшениях рынка комиссий и отзывами о спецификациях.

Помимо основных авторов, в обновлении участвовал широкий спектр внешних участников, каждый из которых привнес уникальный взгляд и набор навыков. Команда Prysm предложила раннюю поддержку на уровне консенсуса, а EF Devops помогла с стресс-тестированием сети и разработкой тестовой сети. Карл Бихейзен и Трент Ван Эппс участвовали в церемонии KZG, а Тим Бейко и Дэнни Райан сыграли решающую роль в координации усилий по разработке и налаживании продуктивной обратной связи между разработчиками и исследователями. Вклад отдела исследований и разработок Consensys, возглавляемого Антоном Нашатыревым, обогатил сетевое моделирование и разработку BLOB-сплетен. Вклад различных разработчиков клиентов L1 очень помог при внедрении многоклиентной продукции. И последнее, но не менее важное: Роберто Баярдо (@roberto_bayardo) сыграл значительную роль в создании прототипов на уровне исполнения и предоставлении отзывов по спецификациям. Эти совместные усилия подчеркивают приверженность сообщества улучшению экосистемы Ethereum, демонстрируя силу коллективных действий.

Перевод статьи от 13 марта 2024 года

https://blog.oplabs.co/the-collective-triumph-of-4844/?ref=the-optimistic-dev-blog-newsletter

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

Ниже приводится сводка ключевых изменений конструкции RetroPGF 3 , которые были определены на основе отзывов RetroPGF 2 .

Ключевые выводы из Retro Funding 3

Вот ключевые выводы из RetroPGF 3:

1. Широкая сфера охвата ошеломила обладателей бейджей и претендентов.

2. Отсутствие стандартизированных, проверяемых и сопоставимых показателей воздействия, а также зависимость от индивидуальных критериев субъективной проверки затрудняли объективную оценку воздействия заявок.

3. Самостоятельный выбор заявок для рассмотрения обладателями бейджей не обеспечил справедливого рассмотрения каждой заявки минимальным количеством обладателей бейджей.

4. Огромный объем заявок в сочетании со слабыми критериями отбора усложнил процесс голосования для обладателей бейджей. Списки оказались неэффективными в расширении возможности обладателей бейджей точно голосовать за большее количество заявок.

Эти знания были получены на основе более чем 300 краудсорсинговых отзывов, собранных посредством опроса среди обладателей бейджей , сообщения на правительственном форуме RetroPGF 3 , а также канала Discord/Telegram для держателей бейджей, и будут использованы в следующей итерации Retro Funding.

Ниже мы подробно документируем эти знания как часть постепенного процесса создания системы управления Optimism с открытым исходным кодом. Этот пост не является исчерпывающим и призван сосредоточить внимание на основных знаниях и наиболее популярных запросах.

Анализ результатов

1. Масштаб : RetroPGF 3 создает уникальный прецедент с точки зрения масштаба. Количество подходящих кандидатов выросло на 330% за раунд, при этом число получателей увеличилось со 195 получателей в RetroPGF 2 до 501 получателя в RetroPGF 3. Количество токенов OP, выдаваемых строителям в рамках Optimism Collective, намного превышает любую сопоставимую программу грантов в крипте.

2. Низкая дисперсия : результаты RetroPGF 3 плохо отражают чрезмерное влияние. Разница в вознаграждениях между получателем из 1% лучших и средним получателем составила около 6 раз (300 тысяч против 45 тысяч).

3. Небольшие команды и отдельные заявки получили более значительное вознаграждение по сравнению с более крупными командами. Лучший проект — Protocol Guild — получил 660 тысяч OP, разделенных между более чем 100 постоянными участниками, что составляет около 6 тысяч на каждого участника. Для сравнения, 112 индивидуальных претендентов на RetroPGF получили в общей сложности 1,7 млн, или около 15 тыс. за заявку.

4. Вознаграждение за конкретный вклад оптимизма : в результатах не было расставлено приоритетов строителей, которые способствуют принятию оптимизма. Основное внимание уделялось вознаграждению общественных благ Эфириума в целом, причем 30 крупнейших получателей почти исключительно состояли из общественных благ, которые не являются специфическими для Оптимизма, но питают экосистему Эфириума в целом. Для сравнения, 20% проектов с наибольшим доходом от секвенсора получили только 5% вознаграждений. (См. выше распределение токенов OP Retro Funding 3 среди приложений основной сети OP)

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

Прикладной процесс

Для участия в RetroPGF 3 проектам и частным лицам необходимо было подать заявку . Этот процесс был упрощен на основе отзывов RetroPGF 2, где застройщикам нужно было номинироваться (в том числе самовыдвижение) и подать заявку на получение квалификации.

Процесс подачи заявок проходил с 19 сентября по 23 октября 2023 года, и в общей сложности было подано 1594 заявителя. После подачи заявки группа владельцев бейджей, выбранная самостоятельно, рассмотрела заявки , о которых сообщалось как о нарушении правил подачи заявок RetroPGF. Процесс рассмотрения проходил по принципу жюри: обладатели бейджей случайным образом распределялись по группам для голосования за исключение заявок из раунда в соответствии с правилами подачи заявок. Процесс рассмотрения заявок проходил с 24 октября по 1 ноября. Было рассмотрено 1035 зарегистрированных заявок и 967 заявителей были исключены из раунда .

Недавно введенная форма заявки привела к значительному улучшению качества заявок по сравнению с предыдущими раундами. Контент приложения был в большей степени связан с процессом голосования и содержал внешние источники данных, такие как ссылки на репозитории Github и развертывания в цепочке, которые использовались для работы инструментов аналитики, таких как OpenSource Observer. Качество обработки заявок получило положительные отзывы:

• «Это очень плавный процесс!»

• «Я имею в виду, что эта форма довольно аккуратная, лучшая форма подачи заявки, которую я когда-либо видел в любой грантовой программе» - Эдуардо

• «Я только что создал профиль Министерства обороны на веб-сайте RetroPGF-3 и не столкнулся с какими-либо техническими проблемами. Это очень плавный процесс!» - Африка

Ошибки, ошибки и сроки

Тем не менее, форму заявления можно улучшить. Пользователи столкнулись с рядом проблем, включая ввод неточных показателей воздействия и сумм грантов в нескольких заявках из-за ошибки в работе с европейскими десятичными точками. Некоторые из этих ошибок сохранились в окончательных версиях приложений , поскольку приложения можно было редактировать в течение периода подачи заявок, но нельзя было изменить после этого. Увеличение периода подачи заявок с 2 недель (в RetroPGF 2) до 4 недель в RetroPGF 3 имело минимальный эффект, поскольку подавляющее большинство пользователей подали свои заявки близко к крайнему сроку .

Нарушения правил приложения

По сравнению с RetroPGF 2, которая исключила из раунда в общей сложности 2 заявки по техническим причинам, RetroPGF 3 справился с подавляющим количеством спама и нарушений правил приложений, при этом было исключено 967 заявок. Вероятно, это было связано с процессом подачи заявок, начавшимся вскоре после Optimism Airdrop #3 , что привело к большому притоку фермеров, разбрасываемых по воздуху. Помимо исключения спама, многие обладатели бейджей высказали мнение о том, что процесс подачи заявок следует улучшить, чтобы защитить от заявок низкого качества, и что должны быть более строгие критерии отбора. Обладатели бейджей оценили общее качество подходящих проектов и их заявок в среднем на 6,9 из 10 баллов.

• «Для спамеров не существует «скина в игре». Стоимость отправки спам-приложения очень низкая, и, как мы все видели, это может потребовать от рецензентов МНОГО работы». - Майкл Вандермейден

• «Все еще кажется, что существует приличное количество кандидатов, которые не являются спамом, но не должны быть включены в список. Я придерживаюсь мнения, что если обладателю бейджа представлен кандидат, у него уже должны быть четкие аргументы в пользу предварительного воздействия» - Брайан Лерер

• «Многие проекты подали заявки на ретро-финансирование, но не оказали ощутимого влияния на коллектив Оптимизма со времен RPGF2. Можно не подавать заявку, если вы не оказали влияния. Подавать заявки и притворяться, что они оказывают влияние, НЕ нормально». - Преподобный

Сбор нужной информации

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

• «Я считаю, что информация о венчурном финансировании не запрашивается, но тогда информация о пожертвованиях и грантах запрашивается очень плохо». - Лефтерис

• «Я думаю, что в будущем проекты должны быть обязаны раскрывать свои источники финансирования». - ЗакXBT

• «Для обеспечения справедливости крайне важно раскрывать частное/венчурное финансирование в заявках RPGF». - Преподобный

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

• «Это, наверное, одна из самых больших и важных проблем, которую предстоит решить. Как можно классифицировать очень большой список проектов так, чтобы избиратель мог выбрать только те категории, в которых у него есть опыт, и не растеряться?» - Тэм

Из-за показателей воздействия, сообщаемых самими пользователями, в приложениях отсутствовали поддающиеся проверке заявления о влиянии и использовались тщеславные показатели. Метрики не были стандартизированы, что затрудняло сравнение проектов. Большинство упомянутых источников данных представляли собой ссылки на документы Etherscan, Github, Dune Analytics, Twitter и Google.

• «Мне бы хотелось, чтобы заявители лучше представляли отчеты о влиянии. Не уверен, является ли это дополнением к форме или просто руководством/шаблоном, но на меня большое влияние оказала таблица Карла с ончейн-транзакциями и метриками Github». - Крис Карелла

• «Проекты могут пропустить обладателей ведущих значков. Это было продемонстрировано, по крайней мере, одним конкретным проектом, в котором были представлены только доходы, которые уже были им переданы, но решили скрыть данные о совершенных ОП, которые они получат после годичной блокировки». - ЛауНаМу

Выводы:

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

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

3. Обладатели значка «Оптимизм» должны иметь возможность оставить отзыв о форме заявки до ее завершения. Это позволяет команде реагировать на возникающие отзывы, такие как раскрытие запроса на венчурное финансирование, возможно, замедляя цикл итерации.

4. Множественный выбор категорий воздействия отрицательно повлиял на обнаружение кандидатов и усложнил процесс голосования. Категоризацию следует улучшить, чтобы облегчить процесс обнаружения и голосования.

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

Оценка воздействия

Голосование проходило с 6 ноября по 7 декабря 2023 г., в нем приняли участие 145 обладателей бейджей и 643 претендента. Как и в предыдущих раундах RetroPGF, владельцам бейджей было предоставлено руководство для держателей бейджей , в котором изложены правила и рекомендации по процессу голосования. В руководство были включены рекомендации о том, как применять принцип «воздействие = прибыль», обзор схемы голосования и его последствий, а также соответствующие ссылки на Кодекс поведения.

В соответствии с отзывами и знаниями, полученными в ходе RetroPGF 2, обладателям бейджей было предоставлено более четкое определение ролей, в котором их просили выносить целостные суждения при применении принципа «воздействие = прибыль», а не выражать свои личные предпочтения в отношении конкретного заявителя. Этот дополнительный контекст был положительно воспринят обладателями бейджей, особенно избирателями, впервые принявшими участие в голосовании.

• «Руководство держателя бейджа было отличным справочником, но оно было слишком статичным для динамичного характера процесса голосования». - Амер

• «В целом хорошо изложено и вся очень полезная информация.» - Эми

• «Я считаю, что более четкие инструкции для владельцев бейджей могли бы упростить этот процесс. PS: Руководство для держателя бейджа очень помогло мне в этом раунде!» - Жоао Курри

• «...как новый обладатель бейджа, я чувствовал себя очень желанным гостем, процесс адаптации прошел гладко, роли и обязанности ясны, правительственная команда всегда готова ответить на любой вопрос». - Виллиан

Руководство для владельцев бейджей включало в себя « Систему оценки воздействия» , созданную LauNaMu в сотрудничестве с Фондом Оптимизма, целью которой было предоставление ментальных моделей и определений для оценки воздействия (цель раунда 3). В нем описываются аудитории, определения и показатели воздействия для каждой из четырех категорий области применения. Эта система оказалась полезной для поддержки обладателей бейджей в построении более глубокого понимания масштаба, воздействия и полезных показателей, в то же время она функционировала скорее как инструмент, позволяющий заинтересованным обладателям бейджей разработать свою собственную структуру, а не как непосредственно применимый для проверки проектов. Вы можете найти ретроспективу системы оценки воздействия здесь .

• «Системы категорий оказались в некоторой степени полезными. Я думаю, что содержание могло бы быть более кратким. Ключевые слова и метрический сад были хорошими примерами. Я использовал их, чтобы составить список потенциальных показателей воздействия, которые мне следует искать. «Эми

• «Я знаю, что намерение состояло в том, чтобы дать каждому возможность разработать методологию. На самом деле это был отличный способ побудить множество умных людей поэкспериментировать с различными решениями. Хотя лично мне, когда я делал это впервые, потребовалось некоторое время, чтобы построить свою методологию, а затем настроить ее по мере появления новых идей». Тэм

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

• «Мне бы очень хотелось, чтобы концепция «Прибыль = Воздействие» была лучше объяснена и четко реализована», — Алекс

• «Существует большая путаница в том, что означает «воздействие», и то, как люди его интерпретируют, действительно различается. Я понимаю, почему «Оптимизм», возможно, захочет оставить этот вопрос открытым, но я чувствую, что, если не занять более самоуверенную позицию по этому вопросу, будут постоянно возникать споры о том, что на самом деле означает оказывать воздействие». - Брайан

• «Позитивное воздействие – это еще один расплывчатый термин», – Лефтерис

  Круглый прицел

RetroPGF 3 имел широкую сферу применения , состоящую из четырех категорий: стек OP, коллективное управление, экосистема разработчиков и опыт и внедрение конечных пользователей. В объемах не указывался период времени, в течение которого воздействие должно быть вознаграждено, и оставляли владельцам бейджей право вознаграждать воздействие в течение выбранного периода времени. Такой широкий охват привел к отсутствию ясности в отношении права на участие некоторых заявителей и затруднил продвижение программы среди соответствующих строителей и стимулирование создания соответствующих вкладов в Optimism.

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

• «Это кажется хаотичным, когда все эти разные типы проектов проводятся в одном раунде».

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

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

• «Объем заявок, которые должен был обработать каждый обладатель бейджа, был ошеломляющим.» - Митч

• «Меня очень обнадеживает то, что другие немного испытывают трудности с количеством проектов, и я беспокоюсь, что я где-то упускаю какую-то хитрость!» - Минимальная гравитация

• «Я начал просматривать проекты (их так много...), но я сильно отстал». - Иоав

• «В целом я чувствовал, что мое внимание было очень истощено». - Брайан

• «Меньшие периодические раунды с ограниченным лимитом имеют большой смысл, это значительно облегчит измерение относительного воздействия» - Ник

• «Согласен, я думаю, что более целенаправленные и определенные раунды с меньшим количеством ОП (и более продуманным процессом проверки) были бы отличным экспериментом для RPGF». - Мэтт

Что такое общественное благо и может ли оно финансироваться венчурным капиталом?

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

Это обсуждение показало, что намерения RetroPGF компании Optimism не были доведены до более широкого сообщества Ethereum. Часто под RetroPGF понимают благотворительную организацию, которая заботится о нуждающихся проектах. Напротив, цель RetroPGF всегда заключалась в создании новой экономической системы, в которой есть стимул оказывать влияние на Коллектив Оптимизма.

Помимо венчурного финансирования, очень популярной дискуссией является определение «общественного блага» и того, что оно должно или не должно включать.

• «Была острая дискуссия о том, что представляет собой общественное благо, и я искренне верю, что попытка сформировать определение, подходящее для всех граждан, приведет к нашему падению. Наша самая большая сила — это разнообразие нашего происхождения, личности и профессии, и я хотел бы оставить сцену открытой для того, чтобы каждый мог поделиться своим определением». - Пользователь ОП

• «Хотя идея воздействия = прибыли велика, я думаю, что оказание влияния или положительное влияние на экосистему не обязательно означает, что это общественное благо». - Уэсли

• «Ретроактивное финансирование общественных благ — это ярлык из лучших побуждений, но на практике его понимают совершенно неправильно. «Общественные блага» особенно вводят в заблуждение, поскольку заставляют людей думать только о чистых общественных благах и упускают большую часть того, что программа пытается [вознаградить]». - Спенсер

• «Обеспокоенность по поводу того, что широко используемые приложения Optimism по большей части остаются за рамками рассмотрения, кажется обоснованной при чтении реальных описаний (например, «привлечение новых пользователей»), но противоречит интуитивному пониманию людьми «общественных благ». - Тим Бейко

Эта тема горячо обсуждалась на всех трех раундах RetroPGF. Сомнительно, действительно ли дискуссия о том, что представляет собой общественное благо, способствует достижению целей RetroPGF или носит более религиозный характер. Результатом этих дебатов в RetroPGF 1 стало установление воздействия = прибыли , принципа, согласно которому ценность, которую участник создал для Коллектива Оптимизма, должна равняться ценности, которую участник извлек из Коллектива Оптимизма. В третьем раунде рекомендации еще раз подчеркнули, что цель RetroPGF — вознаградить вклад и заполнить разрыв между влиянием вкладчика и прибылью. Экономическое определение чистых общественных благ (например, неконкурентных, неисключительных) не применимо к большому набору весьма влиятельных вкладов в Optimism и экосистему Ethereum. Например: хакатоны, приложения, которые приносят доход от секвенсора Optimism, бесплатные сервисы, доступные только ограниченному кругу пользователей и разработчиков, любой хостинговый сервис и т. д. — все это может оказать положительное влияние на Коллектив, даже если они не вписываются в традиционные рамки. экономическое определение чистого общественного блага.

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

• «Если это фримиум-продукт с закрытым исходным кодом, который прекратит свое существование после смерти компании, то это не общественное благо», — Лефтерис

• «...если исходный код продукта закрыт, и я бы посоветовал обладателям бейджей проголосовать 0 за приложения, дошедшие до этапа голосования» — Виллиан

• «Я совершенно ясно дал понять, что отдаю приоритет самозагруженным командам, обеспечивающим подлинные общественные блага с открытым исходным кодом, а не ускоренным, финансируемым командам, которые могут укрепить продукт или услугу до того, как вводить плату или отказываться от нее». - Никбтс

Выводы:

• Широкий охват и большое количество претендентов оказали существенное негативное влияние на раунд.

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

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

• Коллектив не предоставил достаточной ясности относительно целей RetroPGF, что затрудняло конструктивные дискуссии в более широком сообществе Ethereum.

Схема и поведение голосования

Дизайн голосования

Схема голосования RetroPGF 3 рассчитывала вознаграждения отдельных проектов с использованием медианы с минимальным требованием кворума в 17 голосов держателей бейджей — итерация, основанная на знаниях RetroPGF 2 , в которых использовалось среднее значение голосов держателей бейджей. Несмотря на улучшение по сравнению со вторым раундом, последствия этой схемы были весьма нелогичными по сравнению с более распространенными схемами голосования. Владельцы бейджей также отметили, что есть больше возможностей для исследований и итераций этой схемы голосования .

• «Я думаю, что медиана на самом деле исправляет множество недостатков первого раунда. Медиана кажется гораздо лучшим решением для: a. предотвращение сговора (чтобы повлиять на результаты, необходимо гораздо больше избирателей) b. разрешение обладателям бейджей голосовать в зависимости от области знаний (проекты не наказываются за меньшее количество бюллетеней) как a. и б. чрезвычайно важны, поскольку мы пытаемся расширить этот процесс» - Майкл Вандермейден

• «Мне очень интересно узнать, какие математические вычисления выполняются над набором данных. Такое ощущение, что медиана не обязательно является правильным подходом. Даже если в этом раунде ничего не изменится, разнообразие результатов может помочь повлиять на будущие раунды. :)» - Ричард

• «…Я согласен, что медиана, вероятно, не лучший выбор и весьма противоречива здравому смыслу» – Кшиштоф Урбанский

Кворум

Кворум сильно повлиял на опыт как обладателя бейджа, так и заявителя. Кандидаты боялись не собрать кворум и массово обращались к обладателям бейджей, чтобы максимизировать свои шансы на успех. Небольшой нерепрезентативный опрос показал, что каждый обладатель бейджа получил от претендентов более 15 DM. Это создало динамику, которая была больше похожа на соревнование за популярность, чем на попытку объективно оценить прошлый вклад каждого заявителя:

• «Проекты, не набирающие (или вряд ли собирающие) кворум, заинтересованы в том, чтобы продвигаться к каждому обладателю бейджа, чтобы они могли получить любой RPGF. Проекты, которые, скорее всего, соберут кворум, заинтересованы в том, чтобы не продвигать их или рекламировать только тем владельцам бейджей, которые «любят» их проект, например, людям, которые уже оказали непосредственное влияние (или наблюдают влияние) от их проекта, чтобы они максимизировали RPGF». - аббатап

• «У некоторых заявителей могло даже сложиться впечатление, что для достижения кворума необходимы отчаяние и шиллинг; у меня сложилось такое впечатление, что быстрый рост количества «бюллетеней» в последние дни голосования был больше связан с тем фактом, что многие обладатели бейджей до этого были заняты работой с офлайновыми электронными таблицами и просто не использовали программное обеспечение для голосования до очень позднего времени. процесс." - Джоанбп

• «Теперь RPGF кажется искаженным и лично немного напоминает конкурс популярности». - 0xzenodotus

• «Я не думаю, что группам следует рекламировать свое «влияние», потому что в этом случае побеждают лучшие рекламодатели». - световой клиент

Поведение при голосовании

Принятие решений по голосованию на основе данных было затруднено из-за широты воздействия проектов (из-за широкого охвата), а также из-за отсутствия сопоставимых показателей и вкладов (из-за процесса подачи заявок). В сочетании с количеством заявок это привело к когнитивной перегрузке и к тому, что некоторые называют подходом к голосованию «распыли и молись». Вынесение суждения с низкой точностью по большому числу заявителей было предпочтительнее вынесения суждения с высокой точностью по небольшому числу заявителей. Создание простых схем качественной оценки было распространенным способом достижения этой цели – оценки большого количества заявок.

• «Сравнивать Арагон с департаментом децентрализации – невозможно» – Крц

• «Гражданская палата должна голосовать по конкретным, объективным квалификационным критериям. Не важно получить каждый проект — важнее захватить наиболее ценные проекты с минимизацией накладных расходов для держателей бейджей». - Полынья

• «Объем заявок, которые должен был обработать каждый обладатель бейджа, был огромным. Хотя я мог бы сосредоточиться только на своей области знаний, я считаю своей обязанностью выносить суждения по как можно большему числу проектов». - Митч

• «Прыгайте и молись — это естественная реакция на когнитивную перегрузку и ограниченную пропускную способность. Однако наше внимание не должно быть сосредоточено исключительно на создании более эффективных инструментов для распыления. Новая функция, такая как кнопка загрузки CSV, ускорит работу, но она по-прежнему побуждает нас к распылению. Что нам действительно нужно, так это более эффективные способы разработки, реализации и представления полных стратегий голосования». - Карл

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

В своей третьей итерации RetroPGF по-прежнему опирается на ручную проверку отдельных приложений человеком.

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

• «По сути, это требует перехода от вознаграждений, основанных на эмоциях, к вознаграждениям, основанным на данных. Данные имеют решающее значение для владельцев бейджей при переходе от работы в середине воронки грантов (т. е. рассмотрения отдельных проектов) к работе преимущественно в верхней и нижней части воронки (т. е. при принятии решения о том, какие формы воздействия наиболее важны, и пересмотре формулы распределения). ». - Карл

RetroPGF 3 добился значительных успехов в принятии решений, основанных на данных, в категории вкладов с открытым исходным кодом и развертываний в сети. OpenSource Observer продемонстрировал, как существующие данные можно использовать для создания « векторов воздействия » — количественной метрики воздействия, измеряемой за дискретный период времени, чтобы позволить обладателям бейджей выражать свои предпочтения в отношении типов воздействия, которые должны быть вознаграждены, а не оценивать воздействие. индивидуальных заявителей.

Выводы:

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

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

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

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

Сотрудничество с владельцами бейджей

Масштабирование оценки воздействия

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

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

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

• «Для составления списка не требуется никакого уровня знаний, поэтому мы видим большое количество списков, включающих проекты с низким уровнем воздействия, которые затем выделяются на них другим обладателям значков». - Кэти

• «Списки контрпродуктивны. Я считаю, что списки почти наверняка приводят к групповому мышлению, принципу «победитель получает все», и позволяют обладателям бейджей лениться», — Тайруш.

• «Я бы хотел, чтобы больше обладателей бейджей составили списки, отражающие их личный опыт и тщательные суждения, принимая во внимание всю сложность нашей задачи. Было несколько таких списков, и я нашел их полезными». - Джоанбп

• «Хорошо, думаю, мое главное предложение — сделать их редактируемыми, по крайней мере, на уровне UI/UX. Это также упоминалось как вызывающее предвзятость, но у меня нет твердого мнения по этому поводу; Если каждый обладатель бейджа выполняет свою работу, это не должно вызывать беспокойства». - Йоксес

• «Список: я настоятельно рекомендую сохранить их. Единственное предложение — сделать сумму $OP необязательной. Если возможно, предоставьте возможность сортировать список по приоритету. Этот отзыв не только мой; Я беседовал с другими обладателями бейджей, и они разделяют схожие мысли». - Пользователь OPU

• «Я считаю, что списки полезны для открытий, но контрпродуктивны для распределения ресурсов. В дальнейшем, если мы сохраним списки, давайте сосредоточимся на анализе воздействия и комментариях» – преп.

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

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

Дилемма, которая стала очевидной в процессе создания Списка, заключается в том, что обладатели бейджей, являющиеся экспертами в определенной области, обычно также работают в этой области и связаны с одним или несколькими заявками. Если мы ожидаем, что число обладателей бейджей увеличится, а RetroPGF будет вознаграждать за большее влияние, нам следует ожидать, что больше обладателей бейджей будут работать над проектами, которые являются частью RetroPGF. Чтобы обеспечить беспристрастность процесса, решающее значение имеют дополнительные исследования в области противодействия сговору и взяточничеству .

Сотрудничество с владельцами бейджей

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

• «Каждый обладатель бейджа «сам по себе» в том смысле, что я не могу понять, о чем думают другие обладатели бейджей» — Тайруш

• «Владельцам бейджей нужен лучший способ объединить свои знания и исследования. В RPGF3 обмен знаниями происходил через разнообразные чаты, Х, блоги и т. д. Но в ходе обзора приложений не было возможности узнать, «что обладатели бейджей знают об этом приложении?» - Майкл Вандермейден

• «Стало немного сложно следить за анонсами, важными датами и связями между всей остальной болтовней в Telegram. Возможно, был бы полезен отдельный канал объявлений», - Манаси.

• «Из-за такого количества людей Telegram был слишком хаотичным». - Амер

• «Может быть, имеет смысл создать какой-то встроенный форум на каждой странице профиля? Чтобы обладатели бейджей могли высказывать опасения, а владелец проекта мог их оспаривать? С каким-то контролем, чтобы упростить разговор, если соотношение сигнал/шум станет плохим». - Рикмо

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

• «Слишком много бессмысленных встреч в масштабе. Администратору следует сосредоточиться на письменной и автономной организации в духе руководства для владельцев бейджей». (Анон)

• «Место работы офиса мне показалось очень полезным. Что касается семинаров, я не уверен, что это была просто динамика моей группы, но я покинул семинар по оценке воздействия с большим количеством вопросов, чем ответов». - Эми

Рабочая нагрузка и опыт держателя бейджа

Ответы на опрос показали, что средний обладатель бейджа провел 16 часов, участвуя в RetroPGF 3, причем некоторые тратили значительно больше времени. Эти затраты времени были в значительной степени результатом трудоемкого и ручного труда по вынесению субъективных суждений о влиянии большого количества кандидатов. .

• «Однако я могу сказать для себя, что я потратил сотни часов (да, буквально) на RPGF3 с тех пор, как получил свой значок — изучая Оптимизм и RPGF, просматривая, классифицируя и расставляя приоритеты приложений, исследуя, составляя списки, участвуя в семинарах и встречи, обсуждение и предоставление отзывов, голосование и т. д.». - Джоанбп

• «Чтобы стать «хорошим» обладателем бейджа, нужно ОЧЕНЬ много работы. Я с самого начала чувствовал себя виноватым, потому что у меня нет времени делать то, что, по моему мнению, я должен делать», — Тайруш.

• «Быть ​​обладателем бейджа в наши дни — это непростая работа 😅» — Ethernaut

• «Странно. Но быть обладателем бейджа непросто. На самом деле это очень много работы. Намного больше часов работы, чем первоначально рекламировалось. По крайней мере для меня. И я вижу, что все больше людей проводят здесь много часов». - Лефтерис

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

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

Выводы :

• Списки были полезны для курирования приложений, но не имели требований к созданию и не были эффективны для проведения специализированных оценок.

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

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

Инфраструктура и инструменты для голосования

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

Seven Teams создали инструменты или инфраструктуру для голосования в RetroPGF 3.

Инструменты RetroPGF 3, созданные сообществом, продемонстрировали, как открытая среда совместной работы может создавать продукты, которые поддерживают экспериментирование и удовлетворяют потребности пользователей. Владельцы бейджей были оснащены двумя интерфейсами, которые они могли использовать для просмотра заявок, использования списков и подачи своих голосов: voice.optimism.io, созданный Agora , и round3.opimism.io, созданный West. Эти интерфейсы были созданы в рамках миссии Foundation , в которой были изложены требования, спецификации и проекты функций голосования.

Инструменты сообщества, такие как Pairwise и Retrolist.app, позволяли владельцам бейджей создавать списки.  OpenSource Observer сделал аналитику проектов с открытым исходным кодом легко доступной. RetroPGFhub.com и GrowThePie позволили улучшить обнаружение приложений, а также предоставить дополнительные данные о проектах.

Производительность

Серверная инфраструктура для сбора голосов, а также API для запроса соответствующих данных были созданы Agora для использования двумя внешними интерфейсами. Agora поддержала разработчиков, расширив доступ к API, который использовали 8 уникальных клиентов. Хотя Agora работала в 99,65% случаев, в последний день голосования пользователи столкнулись с серьезным снижением производительности на 5-6 часов. Ретроспективу Agora по RetroPGF 3 можно найти здесь .

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

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

Популярные запросы на функции включали возможность импорта голосов через CSV, улучшенную видимость и функциональность фильтрации, а также дополнительные функции для обмена знаниями между владельцами бейджей.

• «Очень жаль, что не было возможности импортировать CSV, поэтому его пришлось добавлять обратно в интерфейс вручную. :/» — Эми

• «Я использовал платформу для голосования Уэста 4 и в целом нашел ее интуитивно понятной и простой в использовании. Для следующего раунда RPGF было бы хорошо добавить а) функциональность для редактирования, разветвления, удаления списков и б) функциональность импорта/экспорта бюллетеней для поддержки людей, работающих в автономном режиме с электронными таблицами - это также было бы полезно в периоды, когда серверы испытывают перегрузку». - Джоанбп

• «У нас должна быть возможность писать заметки по заявкам для себя (т.е. для непубличных пользователей). И, например, иметь кнопки, чтобы указать, хотим ли мы голосовать за них или нет («Да», «Нет», «Может быть» или пусто), а затем использовать их для фильтрации заявок». - ЧикиГорилла

• «было бы здорово, если бы было «спрятано от глаз» проекты, которые я рассматривала и оценивала как не кандидаты/на которые я не буду выделять средства/голосовать за них» - Дженни

• «У меня есть несколько отзывов, которыми я поделился с командой агоры перед началом голосования, которые, я думаю, могли бы сделать его лучше — иметь возможность отмечать проект как просмотренный или вариант «не вносить в голосование» — иметь возможность распределять проценты, а также сумма в долларах — избавьтесь от функции списков» — Кэти

• «Я несколько раз терял свой список (и даже при восстановлении потерял часть своих работ). Во многих случаях Агора была настолько медленной, что ее было невозможно использовать. Это был не только разочаровывающий и болезненный опыт, он истощал и отнимал время, которое я мог бы использовать, чтобы лучше проголосовать». - Амер

Pairwise, получивший грант на миссию от Token House , был создан, чтобы позволить владельцам бейджей легко создавать списки путем сравнения количества приложений в определенной категории, используя метод парного сравнения. Отзывы владельцев бейджей показали, что Pairwise полезен для обнаружения соответствующих приложений, но менее популярен, когда дело доходит до повторения голосов. 27 владельцев бейджей подключили свой кошелек к Pairwise, а 5 владельцев бейджей использовали Pairwise для создания списков. Ретроспективу Pairwise можно найти здесь .

• «В день открытия я изначально был в восторге от создателя списка Pairwise из-за его очевидной простоты использования. Однако, посвятив более 50 часов оценке различных проектов и списков, я решил пойти по более старомодному пути. Я обнаружил, что парному списку не хватает убедительной глубины…». - спящий

• «Использование Pairwise: Я думаю, что это приложение как первооткрыватель выполняет свою функцию, оно превосходно, но я бы никоим образом не ссылался на полученные суммы, только на проценты, как на отправную точку». - Йоксес

• «Наверное, я потратил около двух часов на использование приложения. Я нашел это полезным для открытия/курирования, но не для разработки стратегии голосования». - Карл

Open Source Observer, получивший грант разработчика , позволил владельцам бейджей просматривать метрики верхнего уровня кандидатов на Github, пакеты NPM и контракты onchain. Кроме того, OS Observer обеспечил экспорт соответствующих данных через CSV, чтобы владельцы бейджей могли использовать данные при голосовании. Хотя подход OS Observer является многообещающим, его использование ограничено владельцами бейджей.

• «Отлично подходит для отслеживания репозиториев, рекомендуется, и я надеюсь, что в следующем раунде так и будет продолжаться и будет лучше». - Йоксес

Работа над интерфейсом голосования Уэста (round3.optimism.io) была продолжена и открыта под названием EasyRetroPGF от Gitcoin. Разрешение другим сообществам экспериментировать с ретроактивным финансированием.

Выводы:

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

• Инфраструктура, на которую опирались многие приложения и инструменты, испытывала значительные простои и снижала производительность.

• Приложение(а) для голосования можно усовершенствовать, чтобы сделать его более удобным для рецензента.

Ключевые выводы

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

1. Широкая сфера охвата ошеломила обладателей бейджей и претендентов.

2. Отсутствие стандартизированных, проверяемых и сопоставимых показателей воздействия, а также зависимость от индивидуальных критериев субъективной проверки затрудняли объективную оценку воздействия заявок.

3. Самостоятельный выбор заявок для рассмотрения обладателями бейджей не обеспечил справедливого рассмотрения каждой заявки минимальным количеством обладателей бейджей.

4. Огромный объем заявок в сочетании со слабыми критериями отбора усложнил процесс голосования для обладателей бейджей. Списки оказались неэффективными в расширении возможности обладателей бейджей точно голосовать за большее количество заявок.

Эти знания послужат основой для следующих итераций ретроактивного финансирования общественных благ. Чтобы оставаться в курсе развития Retro Funding, вы можете следить за обновлениями и обсуждениями на форуме Optimism Governance .

Мы еще раз улучшили ретро-финансирование на основе прошлых знаний, вознаградили строителей, исследователей и преподавателей, которые лежат в основе оптимизма, и узнали много нового для улучшения следующей итерации. Вместе мы призовем Феникса Эфира 🕊️.

И, как всегда,

Оставайтесь оптимистом! 🔴✨

Перевод оригинальной статьи от 29 февраля 2024 года

https://optimism.mirror.xyz/Bbu5M1mTNV2Z637QxOiF7Qt7R9hy6nxghbZiFbtZOBA

Сегодня компания Optimism рада объявить об Optimism Drop #4 ( заявка здесь ), которая распределяет 10 343 757,81 OP на 22 998 уникальных адресов. Этот Airdrop — это «спасибо» художникам, создателям и первопроходцам, которые сыграли роль в создании культуры в суперчейне и в криптоэкосистеме в целом. Это также первая раздача Airdrop Optimism в суперчейне, посвященная растущей сети OP Chains, которые решили строиться вместе.

Снимок адресов для Optimism Airdrop #4 был сделан 10 января 2024 года. Более подробная информация о критериях отбора доступна в документации здесь .

Суперчейн стал домом для творческого самовыражения — будь то Zora, Base, Ethereum L1 или OP Mainnet. Каждому великому обществу нужны художники, и творческий вклад играет жизненно важную роль в формировании истории Optimism Collective: более 200 000 адресов создали коллекции NFT в Superchain . Создатели и художники помогают коллективу Optimism расти и процветать, привнося творческий подход в Superchain.

Кто имеет право на участие в розыгрыше Optimism Airdrop #4

Airdrop 4

https://community.optimism.io/docs/governance/airdrop-4/

Пожалуйста, будьте внимательны и доверяйте только твитам @Optimism или @OptimismGov . Дважды проверьте домен, с которым вы взаимодействуете — optimism.io или app.optimism.io.

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

Участие в управлении

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

→ Чтобы делегировать свои токены, перейдите по адресу https://vote.optimism.io/delegates .

Что дальше?

Если вы пропустили Airdrop #4, не волнуйтесь — это еще не все. Компания Optimism взяла на себя обязательство передать 19% от общего количества первоначальных токенов сообществу через Airdrops. С растущим сообществом заинтересованных пользователей в Superchain, есть еще много возможностей для предоставления по всей Superchain — примерно 560 миллионов OP остается для будущих раздач!

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

И, как всегда,

Стройте вместе и оставайтесь оптимистами! ✨🔴

Перевод оригинальной статьи от 20 февраля 2024

https://optimism.mirror.xyz/3tkU-Y5479JPw83I6jp7GTu_0_q-TWEKAXckm3XKl28

Сегодня компания Optimism рада объявить об Optimism Drop #4 ( заявка здесь ), которая распределяет 10 343 757,81 OP на 22 998 уникальных адресов. Этот Airdrop — это «спасибо» художникам, создателям и первопроходцам, которые сыграли роль в создании культуры в суперчейне и в криптоэкосистеме в целом. Это также первая раздача Airdrop Optimism в суперчейне, посвященная растущей сети OP Chains, которые решили строиться вместе.

Снимок адресов для Optimism Airdrop #4 был сделан 10 января 2024 года. Более подробная информация о критериях отбора доступна в документации здесь .

Суперчейн стал домом для творческого самовыражения — будь то Zora, Base, Ethereum L1 или OP Mainnet. Каждому великому обществу нужны художники, и творческий вклад играет жизненно важную роль в формировании истории Optimism Collective: более 200 000 адресов создали коллекции NFT в Superchain . Создатели и художники помогают коллективу Optimism расти и процветать, привнося творческий подход в Superchain.

Кто имеет право на участие в розыгрыше Optimism Airdrop #4

https://community.optimism.io/docs/governance/airdrop-4/

Пожалуйста, будьте внимательны и доверяйте только твитам @Optimism или @OptimismGov . Дважды проверьте домен, с которым вы взаимодействуете — optimism.io или app.optimism.io.

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

Участие в управлении

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

→ Чтобы делегировать свои токены, перейдите по адресу https://vote.optimism.io/delegates .

Что дальше?

Если вы пропустили Airdrop #4, не волнуйтесь — это еще не все. Компания Optimism взяла на себя обязательство передать 19% от общего количества первоначальных токенов сообществу через Airdrops. С растущим сообществом заинтересованных пользователей в Superchain, есть еще много возможностей для предоставления по всей Superchain — примерно 560 миллионов OP остается для будущих раздач!

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

И, как всегда,

Стройте вместе и оставайтесь оптимистами! ✨🔴

Перевод оригинальной статьи от 20 февраля 2024

https://optimism.mirror.xyz/3tkU-Y5479JPw83I6jp7GTu_0_q-TWEKAXckm3XKl28

Серия Fault Proof Deep-Dive — это результат сотрудничества команды Coinbase Blockchain Security (BlockSec) и OP Labs, целью которого является предоставление подробной информации обо всех основных компонентах Fault Proofs. Делясь этой информацией, мы надеемся побудить других узнать больше об архитектуре и технических аспектах Fault Proofs. Вместе мы можем двигаться к децентрализованному будущему блокчейнов OP Stack L2.

В этом сообщении блога мы рассмотрим смарт-контракт MIPS.sol для отказоустойчивой виртуальной машины (FPVM).

Что такое MIPS.sol?

Смарт-контракт MIPS.sol — это ончейн-реализация виртуальной машины (ВМ), которая включает в себя 32-битную архитектуру набора инструкций MIPS III (ISA) с прямым порядком байтов. Этот смарт-контракт является аналогом реализации MIPSEVM golang вне цепочки той же ISA. Вместе реализации ончейн и офчейн виртуальных машин составляют Cannon, первую FPVM OP.

Cannon — это экземпляр FPVM, который используется как часть игры по устранению неисправностей для оптимистичных объединенных блокчейнов L2, использующих стек OP. Сама игра по спорам является модульной, что позволяет использовать любую FPVM; однако Cannon в настоящее время является единственной реализованной FPVM и, следовательно, будет использоваться во всех спорах.

Поток управления защитой от сбоев

Сделав шаг назад, давайте кратко сосредоточимся на том, где находится контракт MIPS.sol в процессе Fault Proof.

На приведенной выше диаграмме, воссозданной на основе видео Fault Proof Walkthrough от Clabby, мы видим, что контракт MIPS.sol взаимодействует с двумя другими контрактами: FaultDisputeGame.sol и PreimageOracle.sol.  FaultDisputeGame.sol — это развернутый экземпляр игры Fault Dispute Game для активного спора. PreimageOracle.sol — это развернутый экземпляр Oracle предварительного образа, который будет хранить предварительные изображения для всех игр-диспутов, использующих одну и ту же FPVM. Итак, в нашем случае существует один контракт PreimageOracle.sol для всех игр, использующих MIPS.sol в качестве FPVM.

Контракт MIPS.sol вызывается запущенным экземпляром спорной игры и вызывается только тогда, когда спорная игра достигает конечного узла в дереве перехода состояний, который в данный момент оспаривается. Листовой узел представляет собой одну инструкцию MIPS (в случае, если мы используем Cannon в качестве FPVM), которую затем можно запустить в цепочке. Учитывая предварительное состояние, которое является ранее согласованным состоянием L2 до этой инструкции, и состояние инструкции для выполнения в контракте MIPS.sol, игра по разрешению ошибок может определить истинное состояние после. Это истинное состояние публикации затем будет использоваться для разрешения игры со спором о неисправности путем сравнения состояния оспариваемой публикации на листовом узле с состоянием публикации, предложенным оппонентом в экземпляре игры со спором.

Поток управления смарт-контрактом

В смарт-контракте MIPS.sol есть единственная точка входа: функция Step(). Это функция, вызываемая запущенной игрой в споре, которая выполняет одну инструкцию MIPS в цепочке. На высоком уровне будут выполнены следующие операции:

1. Входные данные о состоянии выполнения виртуальной машины анализируются и загружаются в память. Эти данные генерируются аналогом Cannon golang, который участники игры запускают вне цепочки через OP-Challenger.

2. Ввод проверки памяти считывается и проверяется. Это доказательство использования памяти указывает на место в памяти, откуда должна быть загружена и запущена следующая инструкция MIPS.

3. Выполняется следующая инструкция MIPS. Большая часть логики контракта MIPS.sol отвечает за выполнение инструкции MIPS в соответствии со спецификацией MIPS III. При обработке инструкций MIPS единственной инструкцией, которая не соответствует строгой спецификации, является инструкция SYSCALL (системный вызов). Поведение системных вызовов уникально для операционной системы, и в случае MIPS.sol системные вызовы, которые можно выполнить, составляют лишь часть от общего числа системных вызовов. Основная цель системных вызовов — обработка чтения из контракта PreimageOracle.sol и имитация записи в контракт.

4. Результаты команды могут быть записаны обратно в регистр или в память. В случае записи в память второе доказательство памяти будет предоставлено в качестве входных данных игры-спора. Второе доказательство памяти должно совпадать с местом в памяти, в которое ожидается запись, и смарт-контракт MIPS.sol будет использовать новое значение и доказательство памяти для вычисления нового корня Меркла в памяти.

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

Состояние контракта MIPS.sol

Как упоминалось ранее, контракт MIPS.sol взаимодействует с двумя другими смарт-контрактами: FaultDisputeGame.sol и PreimageOracle.sol. Контракт FaultDisputeGame.sol предоставляет текущее состояние выполнения виртуальной машины и до двух доказательств памяти. Контракт PreimageOracle.sol предоставляет предварительные изображения, которые MIPS.sol может использовать для определения истинного состояния L2. Содержимое, полученное в предварительном изображении, может включать в себя данные как из L1, так и из L2, которые могут быть заголовками блоков, транзакциями, квитанциями, состоянием контракта и т. д.

Вместе эти два контракта предоставляют всю необходимую информацию, необходимую для выполнения одной инструкции MIPS. Контракт MIPS.sol не хранит в памяти никакой информации о выполнении инструкции. Таким образом, контракт может использоваться в любой игре по разрешению споров без необходимости сброса каких-либо значений. Следовательно, контракт MIPS.sol гарантирует, что вычисленный корень Меркла на основе предоставленных доказательств памяти равен корню Меркла в состоянии выполнения виртуальной машины. В противном случае контракт FaultDisputeGame.sol должен обеспечить корректность предоставленной информации и действий участника спорной игры.

Документация для MIPS.sol

На этом мы завершаем подробное изучение смарт-контракта MIPS.sol. В дополнение к этому сообщению в блоге Coinbase создали подробную документацию, в которой подробно описана каждая функция смарт-контракта, перечислены инструкции MIPS, поддерживаемые FPVM, и многое другое. Проверьте это на сайте Fault Proofs - MIPS.sol | Документы по оптимизму .

Перевод оригинальной статьи от 15 февраля 2024 года

https://blog.oplabs.co/mips-sol/

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

Коллектив Optimism стремится продвигать децентрализацию одновременно по нескольким направлениям: техническая, социальная и управленческая децентрализация. В декабре OP Labs изложила свои стремления к Optimism достичь 1-го этапа децентрализации и перейти ко 2-му этапу (согласно дорожной карте, изложенной Виталиком Бутериным в 2022 году). В Фонде Оптимизма мы можем поддержать эту цель, поддерживая усилия по передаче управления обновлениями протоколов Совету Безопасности.

Чтобы достичь децентрализации этапа 1 и перейти к этапу 2, сетям необходимо что-то вроде Совета Безопасности — мультиподписи, с помощью которого можно управлять обновлениями протоколов — чтобы обеспечить постепенную децентрализацию параллельно с усилиями по достижению других важных этапов этапа 1, таких как создание сети с множественной проверкой. . Эту мультиподпись должны поддерживать как минимум 8 независимых лиц с порогом подписи 75% или выше.

Ценности, лежащие в основе создания Совета Безопасности

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

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

Безопасность важнее жизнеспособности — это то, что определяет безопасность всей экосистемы Optimism. Это означает, что для оптимизма для системы более важно избегать ошибок и недопустимых состояний, особенно тех, которые могут привести к потере активов, даже если это приведет к временной остановке операций. См. недавнюю публикацию в блоге OP Labs об улучшенных возможностях реагирования на инциденты суперцепи , которые были представлены в предложении по управлению, чтобы увидеть пример того, как это значение выглядит на практике. Новый уполномоченный Совет Безопасности будет нести совместную ответственность за обновление протокола, реализующее это предложение, если оно будет принято.

Дизайн, основанный на информации сообщества

Подотчетность Совета Безопасности перед Управлением Оптимизма имеет основополагающее значение, и обсуждение в сообществе поощряется, чтобы постоянно помогать информировать его операции.

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

Коллектив опирался на членов сообщества на протяжении всего процесса создания первой версии Совета Безопасности. Участие сообщества имело жизненно важное значение во время трех репетиций , которые проводились для отработки выполнения ончейн-транзакций, которые переводят Совет Безопасности в онлайн-режим. Эти волонтеры были вознаграждены более чем 11 тысячами OP во время 3-го раунда RetroPGF за поддержку Фонда в этой работе. Сообщество также предоставило отзывы о предложениях по управлению, связанных с созданием Совета Безопасности, а его члены сыграли важную роль в разработке и совершенствовании процесса репетиций и учебных пособий для Совета Безопасности.

Что дальше?

Фаза 0, завершенная сегодня, устанавливает первую общую мультиподпись между Фондом и Советом Безопасности для OP Mainnet. Это знаменует собой начало процесса, направленного на расширение суперчейна и переход к этапу 1. На этапе 1 Совет Безопасности станет единственным действующим лицом, ответственным за подписание обновлений протокола.

Следите за дискуссией по вопросам управления в Совете Безопасности на форуме управления Optimism или следите за прогрессом в репозитории superchain-ops на GitHub . Помните: конечным этапом децентрализации в экосистеме Optimism является децентрализация этапа 2, согласно концепции Виталика Бутерина для масштабирования объединений L2 . Для Совета Безопасности, как и в случае с доказательствами ошибок, Коллектив Оптимизма приближается к Стадии 2 .

Перевод статьи от 12 февраля 2024 года

https://optimism.mirror.xyz/f20gj4Mv3DWdqQEduk5J85VVN254SaQtP0zV_v-8IYs

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

Интересным аспектом этого обновления является введение нового контракта. В настоящее время этот контракт минималистичный, но со временем он может расширяться по мере добавления новых возможностей в Superchain.[SuperchainConfig]

Примечательно, что эти расширенные функции были активны на OP Sepolia с 11 декабря 2023 года без каких-либо проблем.

Почему это важно?

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

Текущий механизм реагирования на инциденты, который включает в себя функцию паузы в цепочке для вывода ETH, решает, возможно, наиболее важные проблемы безопасности в протоколе Optimism. Предлагаемое обновление идет еще дальше. Внедрив механизм паузы в масштабе всей суперцепи, мы можем усилить защиту по нескольким направлениям, включая L1CrossDomainMessenger и вывод средств для токенов ERC-20 и ERC-721, которые являются дополнительными критичными для безопасности путями кода, защищающими пользовательские активы.

Это обновление касается не только усиления отдельных цепочек; речь идет об использовании интеллекта коллективной безопасности всей Суперцепи.

Объем обновления

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

Основываясь на существующей функции паузы сети в OP Mainnet, улучшенное реагирование на инциденты Superchain представляет единый контракт SuperchainConfig для всей сети, содержащий переменную «paused». Это обеспечит более надежную функцию паузы, которая обеспечивает более надежные гарантии безопасности для защиты всех токенов ETH, ERC-20 и ERC-721, хранящихся в стандартных мостах.

Мультиподпись Фонда Оптимизма будет иметь право приостанавливать и возобновлять вывод средств в любых цепочках OP, которые согласятся на это . Приостановка будет осуществляться по принципу «все или ничего» — она будет применяться ко всем транзакциям вывода средств в любых цепочках OP, которые заранее решили приостановить вывод средств в случае, если это сделает OP Mainnet. Поскольку все OP-цепочки будут выполнять один и тот же код, возможность делать паузу в унисон имеет решающее значение. Недавно обнаруженные уязвимости в одной цепочке, скорее всего, будут дублироваться в других цепочках. Важно добавить, что у Фонда не будет возможности приостанавливать определенные транзакции вывода средств или токены. Вот ссылка на результаты аудита безопасности предлагаемого обновления протокола компанией Trust Security .

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

1. Введение нового SuperchainConfigконтракта для улучшения существующего механизма паузы, тем самым обеспечивая более надежную защиту активов в мосту. Более подробную информацию можно найти в спецификации SuperchainConfig .

2. Обновления OptimismPortalи L1CrossDomainMessengerдля устранения проблемы, из-за которой некоторые значения сбрасывались до значений по умолчанию после обновления. Подробности об этом можно узнать в соответствующем PR . Мы работаем над отражением этого изменения в наших спецификациях.

3. L1 OptimismMintableERC20TokenFactoryпретерпевает обновления для:

   • Разрешение развертывания токенов с настраиваемым десятичным числом (детали PR будут добавлены).

   • Обеспечение отдельных адресов для токенов с разными свойствами в различных цепочках OP с использованием CREATE2(детали PR будут добавлены).

Работаем вместе, чтобы защитить Superchain

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

Мы поощряем открытое обсуждение этого обновления протокола всеми членами Коллектива на форуме управления . Ваш вклад поможет сохранить Superchain в безопасности!

Перевод оригинальной статьи от 25 января 2024 года

https://blog.oplabs.co/improved-superchain-incident-response/

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

Что такое репозиторий экосистемы?

Если репозиторий Optimism — это место, где создаются протокол и его инфраструктура, то репозиторий экосистемы — это место, где создаются утилиты, приложения и примеры для взаимодействия с этими протоколами и их инфраструктурой.

Начните с построения моста к суперчейну

Первоначальный запуск представляет собой пример приложения-моста , демонстрирующий, как соединить токены ETH и ERC-20, перечисленные в списке токенов Superchain . Это приложение предоставляет шаблон для тех, кто строит свои собственные мосты, предлагая понимание того, как вы можете взаимодействовать с протоколом. Кроме того, выпущенный пакет включает в себя общие утилиты, необходимые для взаимодействия разработчиков с уровнями L1 и L2. В частности, он включает в себя инструменты для отслеживания сетевых пар и адресов развертывания смарт-контрактов.

Этот запуск — всего лишь начало. Мы планируем постоянно пополнять ресурсы для разработчиков приложений в экосистеме Superchain.

Одно маленькое обязательство для разработчиков, один гигантский скачок для экосистемы

Мы приглашаем вас клонировать репозиторий экосистемы , независимо от того, являетесь ли вы строителем, желающим внести свой вклад, или просто интересуетесь последними разработками в экосистеме оптимизма. Ваше участие – это то, что определит будущее Коллектива.

Если вас вдохновил этот выпуск и у вас есть какие-либо идеи, связанные со стеком OP, которые вы хотели бы видеть в открытом доступе в репозитории, не стесняйтесь оставлять вопрос на GitHub. Приятного строительства!

Перевод оригинальной статьи от 24 января 2024 года

https://blog.oplabs.co/open-sourcing-utilities-for-dapp-developers/

На этом присутствие Коллектива на Devconnect не закончилось. Представители Фонда и OP Labs выступали с докладами и участвовали в дискуссиях на других интересных мероприятиях Devconnect, включая Pragma от ETHGlobal, Rollup Frontier Day от AltLayer, Schelling Point от Gitcoin и других.

Одним из ярких событий недели стал анонс Redstone , плазменного L2 от Lattice для ончейн-игр и амбициозных приложений, созданного с использованием OP Stack. Коллектив также приветствует команду Lattice в качестве основных разработчиков OP Stack!

Представление о суперчейне на саммите Onchain

Программа Onchain Summit включала три увлекательных беседы у камина, три содержательных доклада, три информационных панели и пять практических семинаров.

В начале утра соучредитель Optimism и главный научный сотрудник Фонда Бен Джонс выступил на сессии под названием «Коллектив становится самосознательным». Здесь он поделился подробностями о RetroPGF, Законе цепочек и о том, как они связаны друг с другом для создания «экономически самосознательного» Коллектива.

Далее нам очень повезло принять специального гостя Виталика Бутерина на беседе у камина обо всем, что касается Superchain и масштабирования Ethereum. Генеральный директор OP Labs и соучредитель Optimism Карл Флёрш задал основателю Ethereum вопросы по широкому кругу тем: от футуристических решений масштабирования, таких как плазма, до того, как создать и поддерживать сильную базовую культуру разработчиков. Это насыщенное информацией занятие, которое вы не захотите пропустить.

Виталик Бутерин был не единственным уважаемым основателем протокола, который поделился своими мыслями на саммите Onchain. Глава отдела по связям с разработчиками OP Labs Мэтти Фэйрчайлд побеседовал с основателем Lens Protocol и Aave Стани Кулеховым о том, как Superchain может обеспечить социальный уровень Web3.

Суперспособности стека OP

Был проведен ряд сессий, на которых были рассмотрены многие инновации, реализованные благодаря модульному стеку OP. Основатель Celo Марек Ольшевски провел семинар о том, как его команда в cLabs переводит Celo с уровня L1 на уровень L2 с использованием стека OP; Инженер по тестированию в Prod Тэм Парк продемонстрировал, как синхронизировать OP Mainnet с альтернативным клиентским op-erigon; и представители Risc Zero и O(1) Labs проводят семинар , на котором освещаются их уникальные подходы к запросу предложений ZKP Фонда.

Кроме того, компания Protolambda, принадлежащая OP Labs, провела семинар о том, как разобрать отказоустойчивую систему OP Stack и собрать ее обратно, чтобы доказать что-то новое.

Посмотрите сессию Прото здесь:

Растущая экосистема суперчейнов

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

Бодган Хабич, основатель Tenderly, и Игорь Баринов, основатель Blockscout, представили презентацию о том, как поставщики инфраструктуры и инструменты разработчиков могут адаптироваться к потребностям экосистемы, состоящей из растущего числа разнообразных цепочек. Инженер Base Лукас Росарио провел семинар , который продемонстрировал, как два новых инструмента, созданных Base, op-viem и op-wagmi, могут помочь разработчикам создавать кросс-чейн-приложения в любой OP Chain.

Также была организована панельная дискуссия, в которой приняли участие представители проектов, получивших ретроактивное финансирование общественных благ (RetroPGF) от Коллектива Оптимизма, и рассказали, как это финансирование способствовало их важной работе; строители из Mode, Base и Manta Network рассказали на панели о своем опыте запуска и эксплуатации OP Chains , а докладчики из Ankr, Caldera, Gelato и Altlayer рассказали, как появились поставщики накопительных пакетов как услуги (RaaS) для решения этой проблемы. растущий спрос на сети, изготовленные по индивидуальному заказу.

Наконец, Ремко Блумен из Worldcoin Foundation рассказал об уроках, извлеченных из миграции Worldcoin на OP Mainnet. Вот полное видео:

Финал!

Мы благодарны всем, кто посетил Onchain Summit. Это было удивительное событие, которое на короткое время запечатлело огромную энергию и импульс экосистемы Superchain в бутылке (конференц-центре!) Нет лучшей ноты для завершения, чем выступление, завершившее Onchain Summit, музыкальное попурри Бена Джонса и музыканта Web 3 Шаки.

До следующего года! Оставайтесь оптимистом.

Перевод оригинальной статьи от 29 ноября 2023 года

nft://10/0xfFfc37fce9e0587fC7b2406A97D66e698a00e6aa/?showBuying=true&showMeta=true

Optimism находится в процессе миграции тестовых сетей с OP Goerli на OP Sepolia. Тестовая сеть Goerli объявлена ​​устаревшей сообществом Ethereum с января 2023 года и будет поддерживаться только до конца 2023 года.

OP Sepolia — это устойчивый путь вперед, и мы призываем все приложения и разработчиков перейти на OP Sepolia для любых нужд тестирования и разработки.

Как эта миграция повлияет на партнеров и пользователей?

Ethereum Goerli и OP Goerli вместе с ним будут полностью выведены из эксплуатации в январе 2024 года. Когда тестовая сеть устарела (как это было в прошлом с Ropsten, Rinkeby и Kovan), она теряет паритет с виртуальной машиной Ethereum (EVM), что делает ее устаревшей. небезопасно и неточно для тестирования приложений и других проектов web3.

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

Это сетевая информация, которая должна включать:

Название сети - OP Sepolia

URL RPC - https://sepolia.optimism.io/

Идентификатор цепи - 11155420

Символ валюты - SepoliaETH

URL-адрес обозревателя блоков - https://optimism-sepolia.blockscout.com/

Адреса контрактов: https://github.com/ethereum-optimism/optimism/tree/develop/packages/contracts-bedrock/deployments/sepolia

Конечные пользователи, которые хотят экспериментировать в среде тестовой сети, должны начать делать это на OP Sepolia, а не на OP Goerli. Средства Testnet можно получить через кран Superchain, до 1 тестового ETH в день. Мост также поддерживает тестовые сети Sepolia. Metamask уже поддерживает OP Sepolia, поэтому ее можно найти в выпадающем меню. Если вам нужно добавить его в качестве пользовательской сети в другом месте, пожалуйста, используйте информацию о сети, указанную выше.

Вам нужна поддержка при миграции в OP Sepolia?

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

Перевод оригинальной статьи от 27 ноября 2023 года

https://blog.oplabs.co/op-sepolia/

Что такое Мы ❤️ Искусство?

Думайте об этом как об American Idol для ончейн-арта. Мы ❤️ The Art — это конкурс авторов с призовым фондом в 1 000 000 OP, который оценивают ряд уважаемых деятелей в творческом пространстве onchain. Это праздник творческой свободы и открытое приглашение творцам со всего мира проявить себя на передовых технологиях блокчейнов.

Подобно тому, как достижение видения Superchain будет достигаться посредством сотрудничества и координации между многими различными заинтересованными сторонами, W❤️TA также является примером того, что возможно, когда творческие сообщества объединяются. Это похоже на то, почему Оптимизм был создан с самого начала : чтобы построить более справедливую, более ориентированную на человека платформу для координации и вернуть общественные блага , которые позволяют это сделать.

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

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

Что это значит для создателей?

Знакомство, сообщество и награды в виде части призового фонда в 1 000 000 OP. Призы будут разделены между четырьмя отдельными местами и категориями, всего будет выбрано до 184 потенциальных победителей конкурса.

Это ВОЗМОЖНОСТЬ получить признание вашей работы от судейской коллегии с глубокими знаниями в этой области, привлечь внимание к своим работам в сети и потенциально быть вознагражденным токеном управления Optimism.

Призовые уровни

Призовой фонд в 1 000 000 OP равномерно разделен между четырьмя отдельными категориями, каждая из которых имеет одинаковые четыре призовых уровня.

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

• 1-й уровень: приз 50 тыс. OP (1 победитель в каждой категории)

• 2-й уровень: приз 20 тыс. OP (по 5 победителей в каждой категории)

• 3-й уровень: приз 7K OP (10 победителей в каждой категории)

• 4-й уровень: приз 1K OP (30 победителей в каждой категории)

Категории конкурса

• Искусство искусственного интеллекта — искусство, созданное с помощью генеративных инструментов искусственного интеллекта, таких как Stable Diffusion.

• Генеративное искусство — искусство, созданное с помощью кода.

• Музыка - Музыкальные произведения любого жанра.

• 1of1s – открытая категория авторов, включающая все, что не включено в другие три категории выше.

Как принять участие

Создайте коллекцию ончейн-иллюстраций и разверните ее в OP Mainnet, используя один из инструментов NFT и/или торговых площадок, с которыми мы сотрудничаем в рамках конкурса.🎨

Посетите сайт конкурса и отправьте свое творение в любую из четырех категорий конкурса. 🖼️

Крайний срок подачи заявок: 13 декабря, 23:00 UTC.

Срок рассмотрения: с 14 по 20 декабря.

Представленные материалы будут рассмотрены судейской коллегией NFT. 📋

Победители будут объявлены вскоре после окончания судейства. 🏆

Давайте сделаем немного искусства (с сердцем)

Мы ❤️ Искусство — это возможность собраться вместе, чтобы отметить разнообразные таланты и воображение цифровых художников, внедряющих инновации в сети. Являетесь ли вы опытным творцом или человеком, ожидающим искры вдохновения, мы приглашаем всех стать частью этого опыта.

Удачи! Нам не терпится увидеть, что вы создадите в сети!

Перевод оригинальной статьи от 8 ноября 2023 года

https://optimism.mirror.xyz/K6b7_LpAK88jWo0FJLRGflxxpIzbgVJdYfGZ3pFcfUM

Optimism рад объявить о своем первом обновлении сети после Bedrock под названием Canyon. Canyon активируется в тестовых сетях (OP Goerli, OP Sepolia, Base Goerli, Base Sepolia, PGN Sepolia, Zora Sepolia) во вторник 14 ноября в 17:00 UTC. Это обновление сети было создано и реализовано в сотрудничестве с Base.

Canyon уже успешно активирован в сети разработчиков при координации с Conduit и Base, и мы рады представить его в тестовой сети на следующей неделе.

Чтобы быть активированным в основной сети OP, Base и других сетях Superchain, хардфорк Canyon должен успешно пройти процесс управления Optimism . Следите за будущими объявлениями, чтобы узнать, когда будет принято предложение управления по обновлению Superchain Mainnet до Canyon.

Объем обновления

Обновление Canyon включает поддержку хардфорка Shanghai и Capella и несколько мелких исправлений ошибок. Шанхай содержит следующие EIPS ( EIP-3651: Warm COINBASE , EIP-3855: инструкция PUSH0 , EIP-3860: инициализирующий код ограничения и счетчика , EIP-4895: вывод push-уведомлений по цепочке маяков как операции , EIP-6049: устарело SELFDESTRUCT ). Canyon также вносит некоторые изменения, специфичные для OP Stack.

Обновление увеличит знаменатель EIP-1559 с 50 до 250, чтобы уменьшить скорость роста базовой платы, когда количество блоков превышает целевой показатель газа. При использовании EIP-1559 базовая плата меняется пропорционально тому, насколько далеко используемый газ находится от целевого значения газа. Если используется больше газа, чем целевое значение, базовая плата увеличивается, если используется меньше газа, чем целевое значение, базовая плата уменьшается. Это обновление снижает скорость изменения базовой платы.

Кроме того, Canyon модифицирует протокол для обработки незакрытых каналов. Раньше одновременно мог быть активен только один канал, и если канал не был закрыт, для возобновления прогресса требовалось время ожидания. После обновления оп-узел прочитает первый готовый канал.

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

Наконец, Canyon устанавливает байт-код create2Deployer (хэш кода есть 0xb0550b5b431e30d38000efb7107aaa0ade03d48a7198a140edda9d27134468b2во 0x13b0D85CcB8bf860b6b79AF3029fCA081AE9beF2всех сетях OP). Это позволяет разработчикам иметь доступ к этому часто используемому контракту во всех сетях OP, а не только в основной сети OP.

Операторы узлов: обновите свои узлы!

Это обновление тестовой сети не должно повлиять на пользователей, за исключением доступа к новейшим функциям основной сети Ethereum во всех тестовых сетях OP.

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

Следите за обновлениями OP Governance в ближайшие недели, чтобы узнать о предложении обновить сети Superchain до Canyon.

Перевод оригинальной статьи от 7 ноября 2023 г

https://blog.oplabs.co/canyon-hardfork/

Не случайно одним из самых интересных компонентов системы защиты от сбоев (FPS) OP Stack являются игры-споры. В предыдущих публикациях о FPS было описано, как модульность стека OP позволила отделить программу Fault Proof Program (FPP) от Fault Proof Virtual Machine (FPVM), чтобы обеспечить возможность компоновки следующего уровня и эффективные параллельные обновления обоих компонентов. То же самое, почти в геометрической прогрессии, справедливо и для игр в спорах.

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

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

Что такое игра-спор?

Игра по спорам — это основной примитив протокола споров. Он моделирует простой конечный автомат и инициализируется с использованием 32-байтовой фиксации любой части информации, достоверность которой может быть оспорена. Они содержат функцию, позволяющую определить истинность или ложность этого обязательства, которую остается определить разработчику примитива. Первая реализация спорной игры в стеке OP, FaultDisputeGame, не требует разрешений, поскольку ее функция разрешения определяется результатом выполнения отказоустойчивой программы поверх эмулируемой виртуальной машины.

Сами игры-споры основаны на двух фундаментальных свойствах:

1. Совместимость стимулов : система наказывает ложные заявления и вознаграждает правдивые, чтобы обеспечить справедливое участие.

2. Решение : в каждой игре есть механизм окончательной проверки или аннулирования корневого утверждения.

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

Игра пополам

Это особый тип игры для споров и первая игра, созданная на основе протокола споров OP Stack. В этой игре игроки ходят взад и вперед, разделяя след выполнения до тех пор, пока не достигнут отдельных шагов. После того, как bisection достиг фиксации состояния в отдельных инструкциях трассировки, он FaultDisputeGameвыполняет один шаг инструкции в цепочке с использованием общей виртуальной машины. Функция перехода состояния виртуальной машины, которую мы назовем T , может быть чем угодно, если она соответствует форме T(s, i) -> s' , где s = согласованное предварительное состояние, i = входные данные перехода состояния. , и s' = состояние публикации.

Для нашей первой полной реализации универсального VM в игре пополам мы реализовали один контекст потока MIPS поверх EVM для выполнения отдельных инструкций в пределах трассировки выполнения, сгенерированной Cannonи op-program.

Претензии

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

Позиции

Утверждения существуют в позициях в двоичном дереве. Позиция показывает, к какой инструкции относится утверждение. Позиции представляют собой обобщенные индексы, которые можно определить как2^{depth} + index_at_depth.

Шахматные часы

У игроков есть ограничение по времени на ходы. Игра не требует разрешений, поэтому к ней может присоединиться любой желающий. Каждая сторона начинает с 3,5 днями на часах, что в сумме составляет 7 дней игрового времени. В случае создания нового пути или заявки в позиции, которая уже получила заявку, наследуются часы дедушки и бабушки.

Ходы

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

Шаг инструкции

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

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

Разрешение

Игра может быть решена после того, как закончатся шахматные часы для всех претензий, минимальный срок - 3,5 дня. Каждая заявка в игре является корнем отдельной дополнительной игры . Подигры представляют собой группы DAG с глубиной 1. Все дочерние элементы (которые сами являются корнями подигр), указывающие на корень, являются его противоположностями, и подигра может быть решена только в том случае, если все ее дочерние подигры также были решены. Корень подигры можно считать противодействующим только в том случае, если один или несколько его дочерних элементов разрешены и не противодействуются, и это свойство распространяется вверх вплоть до корневого утверждения игры.

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

Поиграйте в игру «Алфавит пополам».

Для тех, кому интересно, существует также инструмент визуализации трассировки FaultDisputeGameимитации выполнения длиной всего 16 инструкций. В этом моделировании используется отдельная виртуальная машина, отличная от контекста потока MIPS, AlphabetVM, которая просто возвращает следующую букву алфавита, когда буква задана в качестве входных данных.

Если вы заинтересованы в изучении правил игры с более простым интерфейсом, вот как играть:

Клонируйте монорепозиторий Optimism, установите зависимости и создайте двоичные файлы devnetlocations/cannon/op-program.

Необходимые зависимости:

1. foundry

2. Инструментарий Голанга

3. Докер

git clone git@github.com:ethereum-optimism/optimism.git && \\
    cd optimism && \\
  pnpm i && \\
  (cd packages/contracts-bedrock && forge install) && \\
  make cannon-prestate && \\
  make devnet-allocs

Запустите игру «Алфавит»:

cd op-challenger && make alphabet

1. Перейдите по адресу https://disputify.optimism.io/ или запустите интерфейс визуализации локально, клонировав https://github.com/clabby/dispute-viz , и введите адрес прокси- FaultDisputeGameсервера, развернутого в вашей локальной сети разработчиков, указанной выше.

Помогите защитить протокол споров OP Stack.

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

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

Перевод оригинальной статьи от 28 сентября 2023 г.

https://blog.oplabs.co/dispute-games/

Подать заявку можно здесь до 23 октября.

Если у вас есть вопросы, обращайтесь на #retropgf-discussionканал Optimism Discord .

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

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

RetroPGF Funds Строители, создатели, писатели, преподаватели и многие другие

Каждый тип участников экосистемы Optimism имеет право на RetroPGF.

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

Посмотрите на получателей RetroPGF 2 , чтобы понять, за что они были вознаграждены в прошлом.

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

Создайте изменения, которые вы хотите увидеть

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

RetroPGF уже оказывает огромное влияние на экосистему и меняет представление людей об общественных благах. Вот несколько отзывов от получателей RetroPGF Round 2:

«Благодаря RetroPGF мы теперь знаем, что наша работа важна и имеет влияние». - Нико Продукто

«Влияние этого раунда RetroPGF в Cryptoversidad было огромным. Если бы не это, мы бы не смогли продолжать создавать бесплатный образовательный контент. Мы смогли продолжить строительство». - Диего Марес, Cryptoversidad

«RetroPGF предоставляет недостающую часть программного обеспечения с открытым исходным кодом. Хотя специалисты по сопровождению занимаются этим не ради славы или богатства, ретроактивное финансирование укрепляет уверенность и предотвращает выгорание». - Дэвис Шейвер

Покажите свое влияние

Хотя любые проекты, которые поддерживали разработку и внедрение Optimism, поощряются к подаче заявок, нет никакой гарантии, что какой-либо конкретный человек или проект будет выбран в качестве получателя RetroPGF 3. В конечном итоге это решение остается за обладателями значков RetroPGF 3.

Есть несколько вещей, которые вы можете сделать, чтобы сделать ваше приложение RetroPGF 3 максимально надежным:

• Будьте четкими и исчерпывающими, описывая свой вклад.

• Будьте конкретны, описывая влияние, которое оказали вы или ваш проект.

• Предоставьте показатели (как качественные, так и количественные), демонстрирующие ваше влияние (например, пользователи, транзакции, загрузки и т. д.).

Здесь вы найдете инструкции о том, как заполнить заявку.

Подать заявку на RetroPGF 3

Подайте заявку сейчас , чтобы считаться имеющими право на получение части 30 миллионов OP, которые будут выделены для RetroPGF 3!

Окно подачи заявок закроется 23 октября.

Если у вас есть какие-либо вопросы, зайдите на #retropgf-discussionканал Optimism Discord и подпишитесь на информационный бюллетень RetroPGF , чтобы оставаться в курсе событий.

Чтобы отпраздновать открытие приложений для RetroPGF 3, наслаждайтесь этим памятным NFT, который можно отчеканить подписчикам информационного бюллетеня Optimism Mirror.

Перевод оригинальной статьи от 19 сентября 2023

https://optimism.mirror.xyz/wiHMKqsbAQnK51Se3MraSnvf0blwRzS9jguojEmKKVc

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

Модульность и развязка системы отказоустойчивости

Модульность стека OP позволила разработать изолированную систему защиты от сбоев, повысив ее гибкость и адаптируемость. Отделив программу отказоустойчивости (FPP) от отказоустойчивой виртуальной машины (FPVM), каждый компонент может развиваться и оптимизироваться независимо, без ограничений, налагаемых другим. Такое разделение не только упрощает процессы разработки и отладки, но также повышает надежность и надежность как FPP, так и FPVM.

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

Функциональный обзор прообраза оракула

Чтобы понять оракул прообраза, рассмотрите задачу простой FP-VM: как вы можете последовательно доказать вычисление различных данных? Доказательство вычислений становится простым, если свести их к одной инструкции с помощью интерактивной игры: обработать одну инструкцию VM из предварительного состояния в пост-состояние.

Однако загрузить обширные входы L1 и предварительное состояние L2 в эту виртуальную машину непросто. Здесь необходимо использовать прообраз оракула. Он предоставляет значения по запросам программы с использованием ключей. Но это больше, чем просто хранилище значений ключей: оно гарантирует, что используются только законные входные данные, проверяя переход состояния L2 на основе данных L1.

Этот оракул делает получение входных данных доказуемым в цепочке, что похоже на чтение файла или доступ к API.

Оракул-прообраз воплощает в себе «безгражданство»: проверку вычислений путем своевременного предоставления важных данных. В отличие от выполнения без сохранения состояния на уровне L1, этому методу не мешает пропускная способность сети. Интерактивный оптимистический подход меняет правила игры; все эффективно управляется в EVM.

Что особенного в предварительном образе оракула OP Stack?

• Крошечные шаги ввода-вывода: оракул предварительного образа упрощает доказательство, сокращая количество взаимодействий с состоянием виртуальной машины. Он эффективно загружает данные порциями размером в байт, обеспечивая одно аккуратное изменение памяти для каждой инструкции.

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

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

• Проверка претензии: оракул также может загрузить оспариваемую претензию в виртуальную машину, позволяя программе сравнивать ее с результатами вычислений, а не извлекать результат.

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

Компонуемый прообраз оракула

Модульный стек OP может вмещать различные типы FPVM или программ изменения состояния. Красота прообраза-оракула OP Stack заключается в его адаптивности: его можно использовать с разными наборами команд и разными программами. Будь то стек Go с op-node и op-geth или стек Rust с Magi и Reth, один и тот же прообраз-оракул подойдет всем.

Более того, такое разделение между виртуальной машиной и программой позволяет использовать альтернативные виртуальные машины, такие как версия Cannon RISC-V или даже ZK-доказательство MIPS. (!) Будущие проверки предварительного изображения могут быть легко добавлены без внесения радикальных изменений в FPVM.

Как это повлияет на систему защиты от сбоев?

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

Заинтересованы в доказательствах неисправностей? Прочтите эту статью , в которой рассказывается более подробная информация о конструкции полной системы защиты от сбоев стека OP, а также эту статью , в которой рассказывается, как работает многофункциональная конструкция стека OP.

Перевод оригинальной статьи от 23 августа 2023 г.

https://blog.oplabs.co/composable-pre-image-oracle/?ref=the-optimistic-dev-blog-newsletter

Сборщики тестовой сети — это способ для разработчиков получить бесплатный ETH, который можно использовать для взаимодействия со смарт-контрактами в тестовой сети, такой как OP Goerli, но часто они не предоставляют разработчикам достаточное количество ETH для тестирования и итерации проекта от начала до конца. В результате разработчики тратят дополнительное время, пытаясь найти средства или ежедневно посещая краны, чтобы получить достаточное количество токенов тестовой сети для создания своего продукта.

К счастью для создателей экосистемы Optimism, у нас есть творческое решение, которое стало возможным благодаря растущему количеству репутации, доступной благодаря аттестациям в OP Mainnet, WorldID и в Optimism Collective.

Мы рады объявить о запуске сборщика Superchain, который позволит разработчикам в экосистеме Optimism запрашивать до 1 ETH тестовой сети в день в цепочках OP тестовой сети, чтобы помочь создавать продукты и инструменты в Superchain.

Что такое сборщик Superchain?

Традиционно большинство сборщиков требуют социальной аутентификации и значительно ограничивают количество средств тестовой сети, которые можно получить в день, для предотвращения сибил-атак. Сборщик Superchain позволяет разработчикам проходить аутентификацию через свою учетную запись в сети в дополнение к социальной аутентификации через GitHub. Разработчики, выбравшие аутентификацию через свою учетную запись в сети, могут требовать в 20 раз больше ETH в тестовой сети по сравнению с традиционными сборщиками.

При запуске Faucet поддерживает OP Goerli, но он предназначен для расширения на другие цепочки OP в суперчейне, включая Base, ZORA NETWORK, PGN и будущих партнеров Superchain.

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

Использование сетевой идентификации для улучшения распределения токенов тестовой сети

Используя идентификационные данные в сети, связанные со сборщиком, сборщик Superchain может сбрасывать в 20 раз больше токенов тестовой сети по сравнению с традиционными сборщиками — до 1 ETH за раз.

Чтобы воспользоваться этим новым процессом, разработчики могут посетить app.optimism.io/faucet или получить доступ к сборщику через раскрывающееся меню учетной записи после подключения кошелька на app.optimism.io .

В настоящее время сборщик поддерживает аутентификацию с помощью Optimist NFT, и вскоре будет добавлена ​​поддержка WorldID. По мере увеличения количества данных об идентичности в сети в суперчейне должно появиться больше возможностей для проверки личности в сети.

Если у вас еще нет Optimist NFT, но вы хотите попробовать сборщик Superchain, вы можете получить его, выполнив соответствующий квест Coinbase Wallet или будучи активным строителем.

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

Начните вносить свой вклад в стек OP

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

Если вы новичок в ончейн-разработке и готовы внести свой вклад, ознакомьтесь с новым учебником CryptoZombies Optimism Unleashed . Если вы уже знакомы с ончейн-разработкой, ознакомьтесь с панелью инструментов Optimism Ecosystem Contributions Dashboard, чтобы узнать о проектных идеях, которые ищет Optimism Collective. Удачного строительства!

Перевод оригинальной статьи от 1.08.2023

https://blog.oplabs.co/superchain-faucet/?ref=the-optimistic-dev-blog-newsletter