Artigos Artigos Figuras Glossário Gráfico Buscar

Техническая документация Optimism

Por Optimism Collective · 2021

Modo único community.optimism.io

O Optimism não possui um whitepaper tradicional. Como rollup otimista de Camada 2 do Ethereum, seu design e especificações estão documentados por meio de documentação técnica, a especificação do OP Stack e posts de pesquisa, e não em um único artigo acadêmico formal.

🇺🇸 English (Original)
🇷🇺 Русский (Tradução)

Resumo

O artigo aborda o problema de escalabilidade em blockchains descentralizados analisando a compensação entre o rendimento da transação e os requisitos de hardware para executar um nó. Rollups, ou seja, tecnologias para verificação on-chain de blocos executados fora da cadeia, são apresentados na forma de provas de falha ou de validade. Comparamos Rollups Otimistas e Rollups de Validade em relação ao tempo de retirada, custos de transação, técnicas de otimização e compatibilidade com o ecossistema Ethereum. Nossa análise revela que Optimism Bedrock atualmente tem uma taxa de compressão de gás de aproximadamente 20:1, enquanto StarkNet atinge uma taxa de compressão de custo de gravação de armazenamento de cerca de 24:1. Também discutimos técnicas para otimizar ainda mais essas taxas, como o uso de contratos de cache e filtros Bloom. Em última análise, as nossas conclusões destacam os compromissos entre complexidade e agilidade na escolha entre rollups otimistas e de validade. Palavras-chave Blockchain, Escalabilidade, Rollup 1. Introdução A tecnologia Blockchain ganhou atenção significativa devido ao seu potencial para revolucionar vários setores. No entanto, a escalabilidade continua a ser um grande desafio, já que a maioria dos blockchains enfrentam um compromisso entre escalabilidade, descentralização e segurança, comumente referido como o Trilema da Escalabilidade [1, 2]. Para aumentar o rendimento de um blockchain, uma solução trivial é aumentar o tamanho do bloco. No contexto de Ethereum, isso significa aumentar a quantidade máxima de gás que um bloco pode conter. Como cada nó completo deve validar todas as transações de cada bloco, à medida que o rendimento aumenta, os requisitos de hardware também aumentam, levando a uma maior centralização da rede. Alguns blockchains, como Bitcoin e Ethereum, otimizam seu design para maximizar sua descentralização arquitetônica, enquanto outros, como Binance Smart Chain e Solana, são projetados para serem o mais rápidos e baratos possível. As redes descentralizadas limitam artificialmente o rendimento do blockchain para reduzir os requisitos de hardware para participar da rede. Ao longo dos anos, foram feitas tentativas para encontrar uma solução para o Trilema, como os canais estaduais [3] e Plasma [4, 5]. Essas soluções têm a característica de mover algumas atividades para fora da cadeia, vincular atividades on-chain a atividades fora da cadeia usando smart contracts e verificar DLT 2023: 5th Distributed Ledger Technology Workshop, 25 a 26 de maio de 2023, Bolonha, Itália $ [email protected] (L. Donno) https://lucadonnoh.github.io/ (L. Donno) 0000-0001-9221-3529 (L. Donno) © 2023 Direitos autorais deste artigo de seus autores. Uso permitido sob Creative Commons License Attribution 4.0 International (CC BY 4.0). Procedimentos do Workshop CEUR http://ceur-ws.org ISSN 1613-0073 Procedimentos do Workshop CEUR (CEUR-WS.org) na rede o que está acontecendo fora da rede. No entanto, os canais de plasma e de estado são limitados no suporte a smart contracts gerais. Rollups são blockchains (chamados Layer 2 ou L2) que publicam seus blocos em outro blockchain (Layer 1 ou L1) e, portanto, herdam seu consenso, disponibilidade de dados e propriedades de segurança. Elas, ao contrário de outras soluções, suportam computação arbitrária. Rollups possuem três componentes principais: • Sequenciadores: nós que recebem transações Rollup de usuários e as combinam em um bloco que é enviado para Layer 1. O bloco consiste em pelo menos a raiz do estado (por exemplo, uma raiz Merkle) e os dados necessários para reconstruir e validar o estado. O Layer 1 define o...

Аннотация

В статье рассматривается проблема масштабируемости децентрализованных blockchain путем анализа компромисса между пропускной способностью транзакций и требованиями к оборудованию для запуска узла. Свертывания, то есть технологии проверки блоков, выполняемых вне сети, представлены в форме доказательств неисправности или достоверности. Мы сравниваем оптимистичные накопительные пакеты и накопительные пакеты по сроку действия с точки зрения времени вывода средств, транзакционных издержек, методов оптимизации и совместимости с экосистемой Ethereum. Наш анализ показывает, что Optimism Bedrock в настоящее время имеет степень сжатия газа примерно 20:1, а StarkNet обеспечивает степень сжатия стоимости записи в хранилище примерно 24:1. Мы также обсуждаем методы дальнейшей оптимизации этих скоростей, такие как использование контрактов кэша и фильтров Блума. В конечном счете, наши выводы подчеркивают компромисс между сложностью и гибкостью при выборе между оптимистичными и валидными накопительными пакетами. Ключевые слова Блокчейн, Масштабируемость, Объединение 1. Введение Технология Блокчейн привлекла значительное внимание благодаря своему потенциалу совершить революцию в различных отраслях. Однако масштабируемость остается серьезной проблемой, поскольку большинство blockchain сталкиваются с компромиссом между масштабируемостью, децентрализацией и безопасностью, обычно называемым «трилеммой масштабируемости» [1, 2]. Чтобы увеличить пропускную способность blockchain, тривиальным решением является увеличение размера его блока. В контексте Ethereum это означает увеличение максимального количества газа, которое может содержать блок. Поскольку каждый полный узел должен проверять каждую транзакцию каждого блока, по мере увеличения пропускной способности требования к оборудованию также возрастают, что приводит к большей централизации сети. Некоторые blockchain, такие как Bitcoin и Ethereum, оптимизируют свой дизайн, чтобы максимизировать архитектурную децентрализацию, в то время как другие, такие как Binance Smart Chain и Solana, спроектированы так, чтобы быть максимально быстрыми и дешевыми. Децентрализованные сети искусственно ограничивают пропускную способность blockchain, чтобы снизить требования к оборудованию для участия в сети. На протяжении многих лет предпринимались попытки найти решение Трилеммы, например, государственные каналы [3] и Plasma [4, 5]. Эти решения характеризуются перемещением некоторой активности за пределы цепочки, связыванием активности внутри цепочки с активностью вне цепочки с помощью smart contracts и проверкой DLT 2023: 5-й семинар по технологиям распределенного реестра, 25–26 мая 2023 г., Болонья, Италия $ [email protected] (Л. Донно) https://lucadonnoh.github.io/ (Л. Донно) 0000-0001-9221-3529 (Л. Донно) © 2023 Авторские права на эту статью принадлежат ее авторам. Использование разрешено в соответствии с лицензией Creative Commons License Attribution 4.0 International (CC BY 4.0). Материалы семинара CEUR http://ceur-ws.org ISSN 1613-0073 Материалы семинара CEUR (CEUR-WS.org) в сети, что происходит вне сети. Однако как Plasma, так и государственные каналы ограничены в поддержке общих smart contract. Накопительные пакеты — это blockchain (называемые Layer 2 или L2), которые публикуют свои блоки на другом blockchain (Layer 1 или L1) и, следовательно, наследуют его свойства консенсуса, доступности данных и безопасности. Они, в отличие от других решений, поддерживают произвольные вычисления. Rollups состоит из трех основных компонентов: • Секвенсоры: узлы, которые получают транзакции Rollup от пользователей и объединяют их в блок, который отправляется на Layer 1. Блок состоит как минимум из корня состояния (например, корня Меркла) и данных, необходимых для восстановления и проверки состояния. Layer 1 определяет...

Introdução

  1. Introdução A tecnologia Blockchain ganhou atenção significativa devido ao seu potencial para revolucionar diversas indústrias. No entanto, a escalabilidade continua a ser um grande desafio, uma vez que a maioria dos blockchains enfrentam um compromisso entre escalabilidade, descentralização e segurança, comumente referido como o Trilema de escalabilidade [1, 2]. Para aumentar o rendimento de um blockchain, uma solução trivial é para aumentar o tamanho do bloco. No contexto de Ethereum, isso significa aumentar o máximo quantidade de gás que um bloco pode conter. Como cada nó completo deve validar todas as transações de cada bloco, à medida que a taxa de transferência aumenta, os requisitos de hardware também aumentam, levando a um maior centralização da rede. Alguns blockchains, como Bitcoin e Ethereum, otimizam seus design para maximizar sua descentralização arquitetônica, enquanto outros, como o Binance Smart Chain e Solana são projetados para serem o mais rápidos e baratos possíveis. Redes descentralizadas limitar artificialmente o rendimento do blockchain para reduzir os requisitos de hardware para participar da rede. Ao longo dos anos, foram feitas tentativas para encontrar uma solução para o Trilema, tais como medidas estatais canais [3] e Plasma [4, 5]. Estas soluções têm a característica de movimentar alguma atividade fora da cadeia, vinculando a atividade na cadeia à atividade fora da cadeia usando smart contracts e verificando DLT 2023: 5º Workshop de Tecnologia de Ledger Distribuído, 25 a 26 de maio de 2023, Bolonha, Itália $ [email protected] (L. Donno) https://lucadonnoh.github.io/ (L. Donno) 0000-0001-9221-3529 (L. Donno) © 2023 Direitos autorais deste artigo de seus autores. Uso permitido sob Creative Commons License Attribution 4.0 International (CC BY 4.0). CEUR Oficina Processos http://ceur-ws.org ISSN 1613-0073 Anais do Workshop CEUR (CEUR-WS.org)na cadeia o que está acontecendo fora da cadeia. No entanto, tanto os canais de plasma quanto os de estado são limitados em seu apoio aos smart contracts gerais. Rollups são blockchains (chamados Layer 2 ou L2) que publicam seus blocos em outro blockchain (Layer 1 ou L1) e, portanto, herda seu consenso, disponibilidade de dados e propriedades de segurança. Eles, ao contrário de outras soluções, suporta computação arbitrária. Os rollups têm três componentes principais: • Sequenciadores: nós que recebem transações Rollup dos usuários e as combinam em um bloco que é enviado para Layer 1. O bloco consiste em pelo menos a raiz do estado (por exemplo, um Merkle root) e os dados necessários para reconstruir e validar o estado. O Layer 1 define o canônico blockchain do L2 estabelecendo a ordenação dos dados publicados. • Nós completos de rollup: nós que obtêm, processam e validam blocos de rollup da camada 1 verificando se a raiz está correta. Se um bloco contém transações inválidas, então descartado, o que impede que os sequenciadores criem blocos válidos que incluam blocos inválidos transações. • Nós light de rollup: nós que obtêm blocos de rollup de Layer 1, mas não calculam o novo estado eles mesmos. Eles verificam se a nova raiz de estado é válida usando técnicas como provas de culpa ou validade. Os rollups alcançam escalabilidade diminuindo o custo amortizado das transações conforme o número de usuários aumenta. Isso ocorre porque o custo para garantir a validade de blockchain cresce sublinearmente no que diz respeito ao custo de verificação individual das transações. Os rollups diferem de acordo com o mecanismo pelo qual eles garantem a validade da execução da transação em nós leves: em Rollups Otimistas são garantidos por um modelo econômico e por provas de falhas, enquanto em Validade Rollups são garantidos criptograficamente usando provas de validade. Os nós leves podem ser implementados como smart contracts em Layer 1. Eles aceitam a raiz do novo estado e verificar a validade ou provas de falha: esses Rollup são, portanto, chamados de Contrato Inteligente Acumulações. Se os nós leves forem independentes, eles serão chamados de Rollups Soberanos [6]. A vantagem de usar um Smart Contract Rollup é ser capaz de construir uma ponte com confiança minimizada entre os dois blockchains: como a validade do estado L2 é comprovada para L1, um sistema de transações de L2 a L1 podem ser implementados, permitindo saques. A desvantagem é que o custo do transações depende do custo de verificação do estado em L1: se a camada base estiver saturada por outras atividades, o custo das transações no Rollup também aumenta. As camadas de dados e de consenso são as que determinam a segurança do sistema como eles definem a ordem das transações, evitam ataques e disponibilizam dados para comprovar o estado validade. Contribuição em papel Neste artigo, estudamos Optimistic e Validity Rollups, dois inovadores soluções para o Trilema de Escalabilidade, com foco em implementações notáveis, como Optimism Bedrock e StarkNet. Nossas contribuições incluem uma comparação abrangente desses soluções, uma análise dos tempos de retirada e uma discussão sobre um possível ataque a Optimism Base rochosa. Além disso, calculamos suas taxas de compressão de gás, fornecemos otimizações específicas da aplicação e apresentamos as vantagens e desvantagens de se afastar do Ethereum Máquina Virtual (EVM).

Estrutura do papel O artigo está organizado da seguinte forma. Na seção 2, Rollups otimistas são introduzido pela análise de Optimism Bedrock. Na seção 3, os Rollups de Validade são introduzidos por analisando StarkNet. Na seção 4 comparamos as duas soluções. Finalmente, na seção 5 desenhamos algumas conclusões.

Введение

  1. Введение Технология блокчейн привлекла значительное внимание благодаря своему потенциалу совершить революцию. различные отрасли промышленности. Однако масштабируемость остается серьезной проблемой, поскольку большинство blockchain сталкиваются с компромисс между масштабируемостью, децентрализацией и безопасностью, обычно называемый Трилемма масштабируемости [1, 2]. Чтобы увеличить пропускную способность blockchain, есть тривиальное решение: чтобы увеличить размер блока. В контексте Ethereum это означает увеличение максимального количество газа, которое может содержать блок. Поскольку каждый полный узел должен проверять каждую транзакцию каждого блок, поскольку пропускная способность увеличивается, требования к оборудованию также увеличиваются, что приводит к большему централизация сети. Некоторые blockchain, такие как Bitcoin и Ethereum, оптимизируют свои дизайн, чтобы максимизировать свою архитектурную децентрализацию, в то время как другие, такие как Binance Smart Chain и Solana созданы для того, чтобы быть максимально быстрыми и дешевыми. Децентрализованные сети искусственно ограничить пропускную способность blockchain, чтобы снизить требования к оборудованию до участвовать в сети. На протяжении многих лет предпринимались попытки найти решение трилеммы, например, каналы [3] и Плазма [4, 5]. Эти решения имеют свойство перемещать некоторую деятельность оффчейн, связывание активности внутри цепочки с активностью вне цепочки с использованием smart contracts и проверка DLT 2023: 5-й семинар по технологиям распределенного реестра, 25–26 мая 2023 г., Болонья, Италия $ [email protected] (Л. Донно) https://lucadonnoh.github.io/ (Л. Донно) 0000-0001-9221-3529 (Л. Донно) © 2023 Авторские права на данную статью принадлежат авторам. Использование разрешено в соответствии с лицензией Creative Commons License Attribution 4.0 International (CC BY 4.0). ЦЕВР Мастерская Слушания http://ceur-ws.org ISSN 1613-0073 Материалы семинара CEUR (CEUR-WS.org)в сети, что происходит вне сети. Однако как Plasma, так и государственные каналы ограничены в их поддержка генералов smart contracts. Накопительные пакеты — это blockchain (называемые Layer 2 или L2), которые публикуют свои блоки на другом blockchain. (Layer 1 или L1) и, следовательно, наследуют его свойства консенсуса, доступности данных и безопасности. Они, в отличие от других решений, поддерживают произвольные вычисления. Накопительные пакеты состоят из трех основных компонентов: • Секвенсоры: узлы, которые получают транзакции Rollup от пользователей и объединяют их в блок, который отправляется на Layer 1. Блок состоит как минимум из корня состояния (например, Меркла root) и данные, необходимые для восстановления и проверки состояния. Layer 1 определяет канонический blockchain L2 путем установления порядка опубликованных данных. • Полные узлы объединения: узлы, которые получают, обрабатывают и проверяют блоки объединения из слоя. 1, проверив правильность корня. Если блок содержит недействительные транзакции, то это так. отброшено, что не позволяет секвенаторам создавать действительные блоки, содержащие недопустимые транзакции. • Легкие узлы объединения: узлы, которые получают блоки объединения из Layer 1, но не выполняют вычисления. само новое государство. Они проверяют, что новый корень состояния действителен, используя методы такие как доказательства вины или действительности. Накопительные пакеты обеспечивают масштабируемость за счет уменьшения амортизированной стоимости транзакций по мере увеличения количества пользователей увеличивается. Это связано с тем, что стоимость обеспечения достоверности blockchain растет сублинейно. в отношении стоимости проверки транзакций в индивидуальном порядке. Свернутые пакеты различаются в зависимости от механизм, с помощью которого они обеспечивают достоверность выполнения транзакций на легких узлах: в Оптимистические накопительные пакеты обеспечиваются экономической моделью и доказательствами ошибок, пока они действительны. Rollups криптографически обеспечивается с использованием доказательств достоверности. Легкие узлы могут быть реализованы как smart contract на Layer 1. Они принимают корень новое состояние и проверка действительности или доказательств ошибок: поэтому эти накопительные пакеты называются смарт-контрактом. Ролл-апы. Если легкие узлы независимы, они называются суверенными накопительными пакетами [6]. Преимущество использование накопительного пакета смарт-контрактов позволяет построить между ними мост с минимальным доверием. blockchains: поскольку достоверность состояния L2 доказана для L1, система транзакций из Можно реализовать L2–L1, что позволит осуществлять снятие средств. Недостатком является то, что стоимость транзакций зависит от стоимости проверки состояния на L1: если базовый уровень насыщен других видов деятельности, стоимость транзакций в Rollup также увеличивается. Уровни данных и консенсуса — это те, которые определяют безопасность системы как они определяют порядок транзакций, предотвращают атаки и предоставляют данные для подтверждения состояния действительность. Бумажный вклад В этой статье мы изучаем оптимистические и валидные сводные данные, два инновационных метода. решения трилеммы масштабируемости с упором на известные реализации, такие как Optimism Bedrock и StarkNet. Наш вклад включает всестороннее сравнение этих решения, анализ времени вывода средств и обсуждение возможной атаки на Optimism. Коренная порода. Кроме того, мы рассчитываем степень сжатия газа, обеспечиваем оптимизацию для конкретных приложений и представляем преимущества и недостатки отказа от Ethereum. Виртуальная машина (EVM).

Структура бумаги Статья организована следующим образом. В разделе 2 приведены оптимистичные сводные данные. введено путем анализа Optimism коренных пород. В разделе 3 сводные данные о сроках действия представлены анализируем StarkNet. В разделе 4 мы сравниваем два решения. Наконец, в разделе 5 мы рисуем некоторые выводы.

Rollups otimistas

  1. Rollups otimistas A ideia de aceitar de forma otimista a saída dos blocos sem verificar sua execução é já presente no white paper Bitcoin [7], discutindo nós de luz. Esses nós seguem apenas a cadeia de cabeçalho, verificando a regra de consenso, tornando-os vulneráveis à aceitação de blocos contendo transações inválidas no caso de um ataque de 51%. Nakamoto propõe resolver isso problema usando um sistema de “alerta” para avisar os nós leves de que um bloco contém transações inválidas. Este mecanismo foi implementado pela primeira vez por Al-Bassam, Sonnino e Buterin [8] em que uma falha sistema de prova baseado em códigos de correção de erros [9] é usado. Para permitir a criação de provas de falhas, é necessário que os dados de todos os blocos, inclusive os blocos inválidos, estejam disponíveis para a rede: este é o Problema de Disponibilidade de Dados, que é resolvido usando uma análise probabilística de dados mecanismo de amostragem. O primeiro design Optimistic Rollup foi apresentado por John Adler e Mikerah Quintyne-Collins em 2019 [10], em que os blocos são publicados em outro blockchain que define seu consenso sobre o pedido. 2.1. Optimism Base rochosa Bedrock [11] é a versão mais recente de Optimism, um Smart Contract Rollup. A versão anterior, a Optimistic Virtual Machine (OVM) exigia um compilador ad hoc para compilar o Solidity em seu próprio bytecode: em contraste, Bedrock é totalmente equivalente ao EVM em que o mecanismo de execução segue a especificação do papel amarelo Ethereum [12]. 2.1.1. Depósitos Os usuários podem depositar transações por meio de um contrato no Ethereum, o Portal Optimism, chamando a função depositTransaction. Quando uma transação é executada, um O evento TransactionDeposited é emitido, e cada nó no Rollup escuta para processar depósitos. Uma transação depositada é uma transação L2 derivada de L1. Se o chamador do função é um contrato, o endereço é transformado adicionando-lhe um valor constante: isso evita ataques em que um contrato em L1 tem o mesmo endereço que um contrato em L2, mas um código diferente. A inclusão em L2 de uma transação depositada é garantida pela especificação dentro de um sequenciamento janela. As transações depositadas são um novo tipo de transação compatível com EIP-2718 [13] com prefixo 0x7E, onde os campos codificados em rlp são: • bytes32 sourceHash: hash que identifica exclusivamente a origem da transação. • endereço de: o endereço do remetente. • endereço para: o endereço do destinatário, ou o endereço zero se a transação depositada for uma criação de contrato.• uint256 mint: o valor a ser criado em L2. • valor uint256: valor a ser enviado ao destinatário. • dados de bytes: os dados de entrada. • bytes gasLimit: o limite gas da transação. O sourceHash é calculado como o keccak256 hash do bloco L1 hash e o log L1 índice, identificando exclusivamente um evento em um bloco. Como as transações depositadas são iniciadas em L1, mas executadas em L2, o sistema precisa de um mecanismo para pagar em L1 pelo gás gasto em L2. Uma solução é enviar ETH pelo Portal, mas isso implica que cada chamador (mesmo os chamadores indiretos) deve ser marcado como pagável, e isso é não é possível para muitos projetos existentes. A alternativa é queimar o gás correspondente em L1. O gás 𝑔alocado para a transação depositada é chamado de gás garantido. O preço do gás L2 em L1 não é sincronizado automaticamente, mas é estimado usando um mecanismo semelhante ao EIP-1559 [14]. A quantidade máxima de gás garantida por bloco Ethereum é de 8 milhões, com meta de 2 milhões. A quantidade 𝑐de ETH necessária para pagar o gás em L2 é 𝑐= 𝑔𝑏L2 onde 𝑏L2 é o taxa base em L2. O contrato em L1 queima uma quantidade de gás igual a 𝑐/𝑏L2. O gás gasto para ligar depositTransaction é reembolsado em L2: se este valor for maior que o gás garantido, nenhum gás é queimado. A primeira transação de um bloco rollup é uma transação depositada com atributos L1, usada para registrar em um L2 pré-implante os atributos dos blocos Ethereum. Os atributos que a pré-implantação fornece acesso são o número do bloco, o carimbo de data / hora, a taxa base, o bloco hash e a sequência número, que é o número do bloco L2 relativo ao bloco L1 associado (também chamado de época); este número é redefinido quando uma nova época começa. 2.1.2. Sequenciamento Os nós Rollup derivam a cadeia Optimism inteiramente de Ethereum. Esta cadeia é estendida cada vez que novas transações são publicadas em L1, e seus blocos são reorganizados cada vez Ethereum blocos são reorganizados. O Rollup blockchain é dividido em épocas. Para cada 𝑛 número do bloco de Ethereum, há uma época 𝑛 correspondente. Cada época contém pelo menos um bloco, e cada bloco em uma época contém uma transação depositada com atributos L1. O primeiro bloco em uma época contém todas as transações depositadas através do Portal. Layer 2 blocos também podem continha transações sequenciadas, ou seja, transações enviadas diretamente ao sequenciador. O sequenciador aceita transações de usuários e constrói blocos. Para cada bloco, ele constrói um lote a ser publicado em Ethereum. Vários lotes podem ser publicados de forma compactada, tomando o nome do canal. Um canal pode ser dividido em vários frames, caso seja muito grande para uma única transação. Um canal é definido como a compactação com ZLIB [15] de canais codificados em rlp lotes. Os campos de um lote são o número da época, a época hash, o pai hash, o carimbo de data/hora e a lista de transações. Uma janela de sequenciação, identificada por uma época, contém um número fixo 𝑤de L1 consecutivos blocos que uma etapa de derivação toma como entrada para construir um número variável de blocos L2. Para época 𝑛, a janela de sequenciamento 𝑛 inclui os blocos [𝑛, 𝑛+𝑤). Isto implica que a ordenação O número de transações e blocos L2 dentro de uma janela de sequenciamento não é corrigido até que a janela termine. Uma transação rollup é chamada de segura se o lote que a contém foi confirmado em L1. Moldurassão lidos de blocos L1 para reconstruir lotes. A implementação atual não permite a descompressão de um canal comece até que todos os quadros correspondentes tenham sido recebidos. Inválido lotes são ignorados. As transações em bloco individuais são obtidas dos lotes, que são usado pelo mecanismo de execução para aplicar transições de estado e obter o estado Rollup. 2.1.3. Retiradas Para processar saques, é implementado um sistema de mensagens L2 para L1. Ethereum precisa saber o estado do L2 para aceitar saques, e isso é feito publicando no Oracle de saída L2 smart contract em L1 a raiz de estado de cada bloco L2. Essas raízes são otimistamente aceitos como válidos (ou finalizados) se nenhuma prova de falha for realizada durante o período de disputa. Somente endereços designados como Proponentes podem publicar raízes de saída. A validade das raízes da produção é incentivada fazendo com que os proponentes depositem uma participação que será reduzida se eles forem mostrado ter proposto uma raiz inválida. As transações são iniciadas chamando a função inicieWithdrawal em uma pré-implantação em L2 e, em seguida, finalize em L1 chamando a função finalizeWithdrawalTransaction no Portal Optimism mencionado anteriormente. A raiz de saída correspondente ao bloco L2 é obtida do L2 Output Oracle; é verificou que está finalizado, ou seja, que o período de disputa já passou; verifica-se que a Saída A Prova Raiz corresponde à Prova Oracle; verifica-se que o hash do saque está incluído nele utilizando um Comprovante de Saque; que a retirada ainda não foi finalizada; e então o a chamada para o endereço de destino é executada, com o limite de gás especificado, quantidade de Ether e dados. 2.1.4. Cannon: o sistema à prova de falhas Se um Rollup Full Node, ao executar localmente lotes e transações depositadas, descobrir que o estado Layer 2 não corresponde à raiz do estado publicada na cadeia por um proponente, ele pode ser executado uma prova de falha em L1 para provar que o resultado da transição do bloco está incorreto. Por causa do sobrecarga, processar um bloco Rollup inteiro em L1 é muito caro. A solução implementada por Bedrock é executar on-chain apenas a primeira instrução de desacordo de minigeth, compilando-o em uma arquitetura MIPS que é executada em um intérprete on-chain e publicada em L1. minigeth é uma versão simplificada do geth 1 em que o consenso, RPC e banco de dados foram removidos. Para encontrar a primeira instrução de desacordo, uma busca binária interativa é conduzida entre aquele que iniciou a prova de falhas e aquele que publicou a raiz de saída. Quando a prova começa, ambas as partes publicam a raiz do estado de memória MIPS no meio da execução de o bloqueio no contrato do Desafio: se hash corresponder, significa que ambas as partes concordam com o primeira metade da execução publicando assim a raiz da metade da segunda metade, caso contrário a metade do primeiro semestre é publicado e assim por diante. Fazer isso alcança a primeira instrução de desacordo em um número logarítmico de etapas em comparação com a execução original. Se um dos dois parar interagindo, ao final do período de disputa o outro participante ganha automaticamente. Para processar a instrução, o interpretador MIPS precisa de acesso à sua memória: já que a raiz é disponíveis, as células de memória necessárias podem ser publicadas comprovando sua inclusão. Para acessar o estado do EVM, é feito uso do Preimage Oracle: dado o hash de um bloco ele retorna 1https://geth.ethereum.org/docs

o cabeçalho do bloco, a partir do qual se pode obter o hash do bloco anterior e voltar no cadeia ou obtenha o hash do estado e dos logs dos quais é possível obter a pré-imagem. O oracle é implementado pelo minigeth e substitui o banco de dados. Consultas são feitas a outros nós para obter as pré-imagens.

Оптимистичные сводки

  1. Оптимистичные сводки Идея оптимистичного принятия вывода блоков без проверки их выполнения уже присутствует в официальном документе Bitcoin [7], где обсуждаются легкие узлы. Эти узлы следуют только цепочку заголовков, проверяя правило консенсуса, что делает их уязвимыми для приема блоков содержащие недействительные транзакции в случае атаки 51%. Накамото предлагает решить эту проблему проблема с использованием системы «оповещения», предупреждающей легкие узлы о том, что блок содержит недопустимые транзакции. Этот механизм впервые был реализован Аль-Бассамом, Соннино и Бутерином [8], в котором возникла ошибка используется система подтверждения, основанная на кодах исправления ошибок [9]. Для того, чтобы обеспечить возможность создания Для проверки ошибок необходимо, чтобы данные всех блоков, включая недействительные, были доступны сеть: это проблема доступности данных, которая решается с использованием вероятностных данных механизм выборки. Первый дизайн Optimistic Rollup был представлен Джоном Адлером и Микера Квинтайн-Коллинз в 2019 году [10], в котором блоки опубликованы на другом blockchain. это определяет их консенсус относительно порядка. 2.1. Optimism Коренная порода Bedrock [11] — это последняя версия Optimism, накопительного пакета смарт-контрактов. Предыдущая версия, Оптимистической виртуальной машине (OVM) требовался специальный компилятор для компиляции Solidity в свою программу. собственный байт-код: напротив, Bedrock полностью эквивалентен EVM в том смысле, что механизм выполнения соответствует спецификации Ethereum Yellow Paper [12]. 2.1.1. Депозиты Пользователи могут вносить транзакции через контракт на Ethereum, портале Optimism, вызывая функцию депозитаTransaction. Когда транзакция выполняется, Выдается событие TransactionDeposited, которое прослушивает каждый узел в накопительном пакете для обработки. депозиты. Депонированная транзакция — это транзакция L2, производная от L1. Если вызывающий абонент функция является контрактом, адрес преобразуется путем добавления к нему постоянного значения: это предотвращает атаки, при которых контракт на L1 имеет тот же адрес, что и контракт на L2, но другой код. Включение в L2 депонированной транзакции обеспечивается спецификацией в рамках секвенирования. окно. Депонированные транзакции — это новый тип транзакции [13], совместимый с EIP-2718, с префиксом 0x7E, где поля в кодировке rlp: • bytes32 sourceHash: hash, который однозначно идентифицирует источник транзакции. • Адрес от: адрес отправителя. • адрес: адрес получателя или нулевой адрес, если депонированная транзакция является создание договора.• uint256 mint: значение, которое будет создано на уровне L2. • Значение uint256: значение, которое будет отправлено получателю. • байтовые данные: входные данные. • байты gasLimit: лимит газа транзакции. SourceHash вычисляется как keccak256 hash блока L1 hash и журнала L1. индекс, однозначно идентифицирующий событие в блоке. Поскольку депонированные транзакции инициируются на L1, но выполняются на L2, системе требуется механизм оплаты на L1 газа, потраченного на L2. Одним из решений является отправка ETH через Портал. но это подразумевает, что каждый вызывающий абонент (даже косвенный вызывающий абонент) должен быть помечен как подлежащий оплате, и это невозможно для многих существующих проектов. Альтернативой является сжигание соответствующего газа на L1. Газ 𝑔, выделяемый для депозитной транзакции, называется гарантированным газом. Цена на газ L2 на L1 не синхронизируется автоматически, но оценивается с использованием механизма, аналогичного EIP-1559. [14]. Максимальное гарантированное количество газа на блок Ethereum составляет 8 миллионов, с целью из 2 миллионов. Количество 𝑐ETH, необходимое для оплаты газа на L2, равно 𝑐= 𝑔𝑏L2, где 𝑏L2 — это базовая плата за L2. Контракт на L1 сжигает количество газа, равное 𝑐/𝑏L2. Газ, потраченный на звонок депозитная транзакция возмещается на L2: если эта сумма превышает гарантированный газ, газ не горит. Первая транзакция блока rollup — это транзакция с депонированием атрибутов L1, используемая для регистрации на L2 предварительно разверните атрибуты блоков Ethereum. Атрибуты, которые дает предварительное развертывание доступом являются номер блока, временная метка, базовая плата, блок hash и последовательность номер, который является номером блока L2 относительно связанного блока L1 (также называемого эпохой); это число сбрасывается при начале новой эпохи. 2.1.2. Секвенирование Узлы объединения полностью наследуют цепочку Optimism от Ethereum. Эта цепочка расширена каждый раз новые транзакции публикуются на L1, и его блоки каждый раз реорганизуются Блоки Ethereum реорганизованы. Накопительный пакет blockchain разделен на эпохи. Для каждого 𝑛 номер блока Ethereum, существует соответствующая 𝑛эпоха. Каждая эпоха содержит по крайней мере один блок, и каждый блок в эпоху содержит транзакцию депонирования атрибутов L1. Первый блок в эпоху содержит все транзакции, проведенные через Портал. Блоки Layer 2 также могут содержали секвенированные транзакции, т.е. транзакции, отправленные непосредственно в секвенсор. Sequencer принимает транзакции от пользователей и строит блоки. Для каждого блока строится пакет будет опубликован Ethereum. Несколько пакетов могут быть опубликованы в сжатом виде, взяв название канала. Канал можно разделить на несколько кадров, если он слишком велик для одна транзакция. Канал определяется как сжатие с помощью ZLIB [15] файлов, закодированных в rlp. партии. Полями пакета являются номер эпохи, эпоха hash, родительская hash, временная метка и список транзакций. Окно секвенирования, идентифицируемое эпохой, содержит фиксированное количество 𝑤 последовательных L1. блоки, которые на этапе деривации используются в качестве входных данных для создания переменного числа блоков L2. Для эпоха 𝑛, окно последовательности 𝑛 включает блоки [𝑛, 𝑛+𝑤). Это означает, что упорядочение Количество транзакций и блоков L2 в окне последовательности не фиксируется до тех пор, пока окно не завершится. Транзакция rollup называется безопасной, если содержащий ее пакет был подтвержден на L1. Рамкисчитываются из блоков L1 для восстановления пакетов. Текущая реализация не позволяет распаковка канала начнется до тех пор, пока не будут получены все соответствующие кадры. Недействительный пакеты игнорируются. Отдельные блочные транзакции получаются из пакетов, которые используется механизмом выполнения для применения переходов между состояниями и получения состояния Rollup. 2.1.3. Вывод средств Для обработки вывода средств реализована система обмена сообщениями L2-L1. Ethereum необходимо знать состояние L2, чтобы принять вывод средств, и это делается путем публикации на выходе L2 Oracle smart contract на L1 - корень состояния каждого блока L2. Эти корни оптимистично принимаются как действительные (или завершенные), если в течение период спора. Только адреса, обозначенные как Предлагающие, могут публиковать выходные корни. Срок действия выходных корней стимулируется тем, что предлагающие вносят ставку, которая сокращается, если они показано, что он предложил неверный корень. Транзакции инициируются вызовом функции инициироватьВывод средств при предварительном развертывании на уровне L2, а затем завершать на уровне L1, вызывая функцию FinalizeWithdrawalTransaction на ранее упомянутом портале Optimism. Выходной корень, соответствующий блоку L2, получается из выходного оракула L2; это проверил, что он завершен, т. е. период диспута прошел; проверено, что Выход Root Proof соответствует Oracle Proof; подтверждено, что hash вывода включен в нем с использованием Доказательства вывода средств; что вывод еще не завершен; а затем выполняется вызов на целевой адрес с указанным лимитом газа, количеством эфира и данными. 2.1.4. Cannon: надежная система Если объединенный полный узел, локально выполняя пакеты и депонированные транзакции, обнаруживает, что состояние Layer 2 не соответствует корню состояния, опубликованному в цепочке Предлагающим, оно может быть выполнено доказательство неисправности на L1, чтобы доказать, что результат перехода к кадру неверен. Из-за накладные расходы, обработка всего блока Rollup на L1 слишком дорога. Решение реализовано от Bedrock — выполнить по цепочке только первую инструкцию несогласия минигетов, компиляция его в архитектуру MIPS, которая выполняется на интерпретаторе цепочки и публикуется на Л1. minigeth — это упрощенная версия geth 1, в которой консенсус, RPC и база данных были удалены. Для нахождения первой инструкции несогласия проводится интерактивный бинарный поиск между тот, кто инициировал проверку неисправности, и тот, кто опубликовал корень вывода. Когда доказательство начинается, обе стороны публикуют корень состояния памяти MIPS в середине выполнения блок в контракте Challenge: если hash совпадает, это означает, что обе стороны согласны на первая половина выполнения, таким образом публикуя корень половины второй половины, в противном случае половина первой половины публикуется и так далее. Таким образом достигается первая инструкция несогласия. за логарифмическое количество шагов по сравнению с исходным выполнением. Если один из двух останавливается взаимодействуя, по окончании периода спора автоматически побеждает другой участник. Для обработки инструкции интерпретатору MIPS необходим доступ к ее памяти: поскольку корень доступны, необходимые ячейки памяти можно опубликовать, доказав их включение. Чтобы получить доступ состояние EVM, используется Oracle Preimage: учитывая hash блока, который он возвращает 1https://geth.ethereum.org/docs

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

Rollups de validade

  1. Rollups de validade O objetivo de um Validity Rollup é provar criptograficamente a validade da transição de estado dada a sequência de transações com uma prova curta que pode ser verificada sub-linearmente comparada ao tempo dos cálculos originais. Esses tipos de certificados são chamados de provas de integridade computacional e são praticamente implementados com SNARKs (Succint Non-interactive ARgument of Knowledge), que utilizam aritmética circuitos como seu modelo computacional. Diferentes implementações do SNARK diferem no tempo de prova, tempo de verificação, a necessidade de uma configuração confiável e resistência quântica [16, 17]. STARKs (escalável ARgumento Transparente de Conhecimento) [18] são um tipo de SNARKs que não requer um confiável configurados e são resistentes a quantum, ao mesmo tempo que abrem mão de alguma eficiência na prova e verificação em comparação com outras soluções. 3.1. StarkNet StarkNet é um Smart Contract Validity Rollup desenvolvido pela StarkWare que usa o STARK sistema de prova para validar seu estado para Ethereum. Para facilitar a construção de provas de validade, um É utilizada uma máquina virtual diferente da EVM, cuja linguagem de alto nível é Cairo. 3.1.1. Depósitos Os usuários podem depositar transações por meio de um contrato em Ethereum chamando sendMessageToL2 função. A mensagem é registrada calculando seu hash e aumentando um contador. Sequenciadores ouça o evento LogMessageToL2 e codifique as informações em uma transação StarkNet que chama uma função de um contrato que possui o decorador l1_handler. No final da execução, quando a prova de transição de estado é produzida, o consumo da mensagem é anexado a ela e é excluído diminuindo seu contador. A inclusão de transações depositadas não é exigida pela especificação StarkNet, portanto, um gás mercado é necessário para incentivar os sequenciadores a publicá-los em L2. Na versão atual, porque o Sequenciador é centralizado e gerenciado pela StarkWare, o custo das transações depositadas é determinado apenas pelo custo de execução do depósito. Este custo é pago enviando ETH para enviarMessageToL2. Esses Éteres permanecem bloqueados em L1 e são transferidos para o Sequenciador em L1, quando a transação depositada está incluída em uma transição de estado. A quantidade de ETH enviada, se a transação depositada está incluída, é totalmente gasta, independentemente da quantidade de gás consumida em L2. StarkNet não possui um sistema que disponibilize atributos do bloco L1 automaticamente. Alternativamente, Fossil é um protocolo desenvolvido pela Oiler Network 2 que permite, dado um hash de um bloco, qualquer informação a ser obtida de Ethereum através da publicação de pré-imagens. 2https://www.oiler.network/3.1.2. Sequenciamento O estado atual de StarkNet pode ser derivado inteiramente de Ethereum. Qualquer diferença de estado entre transições é publicado em L1 como calldata. As diferenças são publicadas para cada contrato e são salvos como uint256[] com a seguinte codificação: • Número de campos relativos a implantações contratuais. • Para cada contrato publicado: – O endereço do contrato publicado. – O hash do contrato publicado. – O número de argumentos do construtor do contrato. – A lista de argumentos do construtor • Número de contrato cuja armazenagem foi modificada. • Para cada contrato que foi modificado: – O endereço do contrato modificado. – O número de atualizações de armazenamento. – Os pares de valores-chave dos endereços de armazenamento com os novos valores. As diferenças de estado são publicadas em ordem, portanto é suficiente lê-las sequencialmente para reconstruir o estado. 3.1.3. Retiradas Para enviar uma mensagem de L2 para L1, é usado o syscall send_message_to_L1. A mensagem é publicado em L1 aumentando seu contador hash junto com a prova e finalizado chamando o função consomeMessageFromL2 no StarkGate smart contract em L1, que diminui o contador. Qualquer pessoa pode finalizar qualquer saque. 3.1.4. Provas de validade A Máquina Virtual Cairo [19] foi projetada para facilitar a construção de provas STARK. A linguagem Cairo permite que o cálculo seja descrito com uma programação de alto nível linguagem, e não diretamente como um circuito. Isso é conseguido por um sistema de equações polinomiais 3 representando um único cálculo: o ciclo FDE de uma arquitetura von Neumann. O número de restrições é, portanto, fixo e independente do tipo de computação, permitindo apenas um Programa verificador para cada programa cujo cálculo precisa ser provado. StarkNet agrega múltiplas transações em uma única prova STARK usando um provador compartilhado chamado SHARP. As provas são enviadas para smart contract em Ethereum, que verifica sua validade e atualiza a raiz Merkle correspondente ao novo estado. O custo sublinear de verificar um a prova de validade permite que seu custo seja amortizado em múltiplas transações. 3chamada Representação Algébrica Intermediária (AIR)

Сводные данные о сроке действия

  1. Сводные данные о сроках действия Целью валидного накопительного пакета является криптографическое доказательство достоверности перехода состояний. учитывая последовательность транзакций с коротким доказательством, которое можно проверить сублинейным сравнением ко времени первоначальных вычислений. Сертификаты такого типа называются доказательствами вычислительной целостности и практически реализуются с помощью SNARK (краткий неинтерактивный аргумент знаний), в которых используются арифметические действия. схемы в качестве их вычислительной модели. Различные реализации SNARK отличаются временем проверки, время проверки, необходимость доверенной установки и квантовое сопротивление [16, 17]. STARK (Масштабируемые Прозрачный аргумент знаний) [18] — это тип SNARK, не требующий доверенного настройки и являются квантово-устойчивыми, но при этом теряют некоторую эффективность при доказательстве и проверке. по сравнению с другими решениями. 3.1. StarkNet StarkNet — это накопительный пакет действительности смарт-контракта, разработанный StarkWare, который использует STARK система доказательства для подтверждения своего состояния до Ethereum. Чтобы облегчить построение доказательств достоверности, используется виртуальная машина, отличная от EVM, языком высокого уровня которой является Cairo. 3.1.1. Депозиты Пользователи могут вносить транзакции через контракт на Ethereum, вызвав sendMessageToL2. функция. Сообщение записывается путем вычисления его hash и увеличения счетчика. Секвенсоры прослушивайте событие LogMessageToL2 и кодируйте информацию в транзакции StarkNet который вызывает функцию контракта, имеющую декоратор l1_handler. В конце исполнения, когда создается доказательство перехода состояния, к нему прилагается потребление сообщения и он удаляется путем уменьшения его счетчика. Спецификация StarkNet не требует включения депонированных транзакций, поэтому газ рынок необходим, чтобы стимулировать секвенаторов публиковать их на L2. В текущей версии, поскольку Секвенсер централизован и управляется StarkWare, стоимость депонируемых транзакций определяется только стоимостью исполнения депозита. Эта стоимость оплачивается путем отправки ETH на sendMessageToL2. Эти эфиры остаются заблокированными на L1 и передаются в секвенсор L1, когда депонированная транзакция включена в переход состояния. Сумма отправленных ETH, если внесенная транзакция включена, расходуется полностью, независимо от количества потребленного газа на Л2. StarkNet не имеет системы, которая автоматически делает атрибуты блока L1 доступными. Альтернативно, Fossil — это протокол, разработанный Oiler Network 2, который позволяет при наличии hash блок, любая информация, которую можно получить от Ethereum путем публикации прообразов. 2https://www.oiler.network/3.1.2. Секвенирование Текущее состояние StarkNet может быть полностью получено из Ethereum. Любая государственная разница между переходами публикуется на L1 как данные вызова. Различия публикуются для каждого контракта и сохраняются как uint256[] со следующей кодировкой: • Количество полей, касающихся развертывания контрактов. • Для каждого опубликованного контракта: – Адрес опубликованного контракта. – hash опубликованного контракта. – Количество аргументов конструктора контракта. – Список аргументов конструктора • Номер контракта, хранилище которого было изменено. • Для каждого измененного контракта: – Адрес измененного контракта. – Количество обновлений хранилища. – Пары ключ-значение адресов хранения с новыми значениями. Государственные различия публикуются по порядку, поэтому достаточно прочитать их последовательно, чтобы реконструировать государство. 3.1.3. Вывод средств Чтобы отправить сообщение с L2 на L1, используется системный вызов send_message_to_L1. Сообщение опубликовано в L1 путем увеличения счетчика hash вместе с доказательством и завершено путем вызова метода функция ConsumerMessageFromL2 на StarkGate smart contract на L1, которая уменьшает счетчик. Любой может завершить вывод средств. 3.1.4. Доказательства действительности Виртуальная машина Cairo [19] предназначена для облегчения построения доказательств STARK. Язык Cairo позволяет описывать вычисления с помощью высокоуровневого программирования. языке, а не непосредственно как цепь. Это осуществляется с помощью системы полиномиальных уравнений 3 представляет одно вычисление: цикл FDE архитектуры фон Неймана. Число Таким образом, количество ограничений фиксировано и независимо от типа вычислений, что позволяет использовать только одно Программа-верификатор для каждой программы, вычисления которой необходимо доказать. StarkNet объединяет несколько транзакций в одно доказательство STARK с использованием общего доказательства. по имени ШАРП. Доказательства отправляются на smart contract Ethereum, который подтверждает их достоверность. и обновляет корень Меркла, соответствующий новому состоянию. Сублинейная стоимость проверки Доказательство действительности позволяет амортизировать его стоимость в рамках нескольких транзакций.
  2. называется алгебраическим промежуточным представлением (AIR).

Comparação

  1. Comparação 4.1. Tempo de retirada O aspecto mais importante que distingue os Rollups Otimistas dos Rollups de Validade é o tempo que decorre entre a inicialização de um levantamento e a sua finalização. Em ambos os casos, as retiradas são inicializadas em L2 e finalizadas em L1. Em StarkNet, a finalização é possível como assim que a prova de validade da nova raiz de estado for aceita em Ethereum: teoricamente, é possível retirar fundos no primeiro bloco de L1 após a inicialização. Na prática, o frequência de envio de provas de validade em Ethereum é uma compensação entre a velocidade do bloco finalização e agregação de provas. Atualmente StarkNet fornece provas de validade para verificação a cada 10 horas 4, mas pretende-se que diminua à medida que a atividade de transação aumenta. Em Optimism Bedrock é possível finalizar um saque somente no final da disputa período (atualmente 7 dias), após o qual uma raiz é automaticamente considerada válida. O comprimento de este período é determinado principalmente pelo fato de que as provas de falha podem ser censuradas em Ethereum até seu fim. A probabilidade de sucesso deste tipo de ataque diminui exponencialmente à medida que o tempo aumenta: E[valor subtraído] = 𝑉𝑝𝑛 onde 𝑛 é o número de blocos em um intervalo, 𝑉 é a quantidade de fundos que pode ser subtraída publicando uma raiz inválida, e 𝑝é a probabilidade de realizar uma censura com sucesso ataque em um único bloco. Suponha que esta probabilidade seja de 99%, que o valor bloqueado no Rollup é um milhão de Ether, e que os blocos em um intervalo são 1800 (6 horas de blocos com 12 intervalo de segundos): o valor esperado é cerca de 0,01391 Ether. O sistema é tornado seguro por pedindo aos proponentes que apostem uma quantidade muito maior de Ether do que o valor esperado. Winzer et al. mostrou como realizar um ataque de censura usando um simples smart contract isso garante que certas áreas da memória no estado não mudem [20]. Modelando o ataque como um jogo de Markov, o artigo mostra que a censura é a estratégia dominante para uma bloquear o produtor se receberem mais compensação do que incluindo a transação que muda a memória. O valor de 𝑝 discutido acima pode ser visto como a percentagem do bloco racional produtores da rede, onde “racional” não leva em conta possivelmente penalizar externalidades, como menos confiança no blockchain que diminui seu valor de criptomoeda. O código a seguir apresenta um smart contract que pode ser usado para realizar um ataque de censura em Bedrock. O ataque explora os incentivos dos produtores de blocos, oferecendo-lhes suborno censurar as transações que modificariam partes específicas do estado. O principal do contrato função, ClaimBribe, permite que os produtores de blocos reivindiquem o suborno se conseguirem censurar a transação alvo, verificando se a raiz de saída inválida não foi tocada. função reivindicaçãoSuborno(bytes memória storageProof) externo { require(!claimed[block.number], "suborno já reivindicado"); Memória OutputProposal atual = storageOracle.getStorage(L2_ORACLE, block.number, SLOT, prova de armazenamento); require(invalidOutputRoot == current.outputRoot, "ataque falhou"); reivindicado[bloco.número] = verdadeiro; (bool enviado,) = block.coinbase.call{valor: bribeAmount}(""); 4https://etherscan.io/address/0xc662c410c0ecf747543f5ba90660f6abebd9c8c4require(enviado, "falha ao enviar ether"); } Listagem 1: Exemplo de contrato que incentiva um ataque de censura a Bedrock. A duração do período de litígio também deve ter em conta o facto de a prova da culpa ser uma prova interativa e, portanto, deve ser fornecido tempo suficiente para os participantes interagirem e que qualquer interação poderia ser censurada. Se o último movimento ocorrer num momento muito próximo do final do período de disputa, o custo da censura é significativamente menor. Embora a censura seja o estratégia dominante, a probabilidade de sucesso é menor porque os nós de censura são vulneráveis a Ataques de negação de serviço: um invasor pode gerar transações muito complexas que terminam com o publicação de uma prova de culpa sem nenhum custo, uma vez que nenhuma taxa seria paga. Em casos extremos, um longo período de litígio permite a coordenação no caso de uma decisão bem-sucedida. ataque de censura para organizar um fork e excluir os produtores de blocos atacantes. Outro possível ataque consiste em publicar mais propostas de raiz estatal do que os disputantes podem verificar, que pode ser evitado usando um limite de frequência. 4.1.1. Retiradas rápidas e otimistas Como a validade de um Optimistic Rollup pode ser verificada a qualquer momento por qualquer Full Node, um confiável oracle pode ser usado para saber em L1 se a retirada pode ser finalizada com segurança. Isto mecanismo foi proposto pela primeira vez pelo Maker [21]: um oracle verifica a retirada, publica o resultado em L1 em que um empréstimo remunerado é atribuído ao usuário, que é automaticamente fechado ao final de 7 dias, ou seja, quando o saque pode realmente ser finalizado. Esta solução introduz uma suposição de confiança, mas no caso do Maker ela é minimizada, pois o operador oracle é gerido pela mesma organização que assume o risco ao conceder o empréstimo. 4.2. Custos de transação O custo das transações L2 é determinado principalmente pela interação com a L1. Em ambas as soluções o custo computacional das transações é muito barato, pois é executado inteiramente fora da cadeia. Optimism publica calldata de transações L2 como calldata e raramente (ou nunca) executa falha provas, portanto calldata é o recurso mais caro. Em 12 de janeiro de 2022, uma rede Bedrock foi lançado na testnet Goerli de Ethereum. Uma taxa de compressão de gás pode ser calculada rastreando a quantidade de gás usada em Bedrock em um determinado período e comparando-a com o quantidade de gás gasta em L1 para os blocos correspondentes. Usando este método, uma compressão de gás taxa de ∼20: 1 é encontrada, mas este número pode diferir com a atividade real na rede principal. StarkNet publica em Ethereum todas as alterações no estado L2 como dados de chamada, portanto, o armazenamento é o recurso mais caro. Como a rede não utiliza EVM, o custo da transação a compressão não pode ser estimada trivialmente. Ao assumir o custo de execução e calldata para ser insignificante, é possível calcular a taxa de compactação de gravações de armazenamento em comparação com L1. Supondo que nenhum contrato seja implantado e 10 células não acessadas anteriormente em StarkNet sejam modificado, uma taxa de compactação de custo de gravação de armazenamento de ∼24: 1 é encontrada. Se uma célula for sobrescrita 𝑛vezes entre publicações de dados, o custo de cada gravação será 1/𝑛comparado ao custo de uma única escrita, já que apenas a última é publicada. O custo pode ser ainda mais minimizado porcompactando valores usados ​​com frequência. O custo da verificação da prova de validade é dividido entre as transações às quais se refere: por exemplo, o bloco StarkNet 4779 contém 200 transações e seu o comprovante de validade consome 267.830 unidades de gás, ou 1.339,15 gás para cada transação. 4.2.1. Otimizando calldata: contrato de cache Apresentado abaixo está um smart contract que implementa um cache de endereço para uso frequente endereços aproveitando o fato de que o armazenamento e a execução são muito mais baratos recursos, juntamente com um contrato de Amigos que demonstra seu uso. Este último acompanha o “amigos” de um endereço que pode ser registrado chamando a função addFriend. Se um endereço já foi usado pelo menos uma vez, ele pode ser adicionado chamando addFriendWithCache função: os índices de cache são inteiros de 4 bytes enquanto os endereços são representados por 20 bytes, portanto, há uma economia de 5:1 no argumento da função. A mesma lógica pode ser usada para outros dados tipos como inteiros ou, mais geralmente, bytes. contrato AddressCache { mapeamento (endereço => uint32) public address2key; endereço[] endereço-chave2 público; função cacheWrite(address _address) retornos internos (uint32) { require(key2address.length <type(uint32).max, "AddressCache: cache está cheio"); require(address2key[_address] == 0, "AddressCache: endereço já armazenado em cache"); // as chaves devem começar em 1 porque 0 significa "não encontrado" chave uint32 = uint32(key2address.length + 1); endereço2key[_endereço] = chave; key2address.push(_address); chave de retorno; } função cacheRead (uint32 _key) visualização pública retorna (endereço) { require(_key <= key2address.length && _key > 0, "AddressCache: chave não encontrada"); retornar key2address[_key - 1]; } } Listagem 2: Contrato de cache de endereço. contrato Amigos é AddressCache { mapeamento(endereço => endereço[]) amigos públicos; function addAmigo(endereço_amigo) public { amigos[msg.remetente].push(_amigo); cacheWrite(_amigo); } função addFriendWithCache(uint32 _friendKey) public { amigos[msg.sender].push(cacheRead(_friendKey)); } função getFriends() visualização pública retorna (endereço[] memória) { retornar amigos[msg.sender];} } Listagem 3: Exemplo de contrato que herda o cache de endereços. O contrato suporta em cache cerca de 4 bilhões (232) endereços, e adicionar um byte dá cerca de 1 trilhão (240). 4.2.2. Otimizando o armazenamento: filtros Bloom Em StarkNet existem diversas técnicas para minimizar o uso de armazenamento. Se não for necessário garantir a disponibilidade dos dados originais, então é suficiente salvar on-chain seu hash: este é o mecanismo usado para salvar dados para um ERC-721 (NFT) [22], ou seja, um link IPFS que resolve o hash dos dados, se disponíveis. Para dados armazenados diversas vezes, é possível usar uma pesquisa tabela semelhante ao sistema de cache introduzido para Optimism, exigindo que todos os valores sejam salvos em pelo menos uma vez. Para algumas aplicações, salvar todos os valores pode ser evitado usando um filtro Bloom [23, 24, 25], ou seja, uma estrutura de dados probabilística que permite saber com certeza se um elemento não pertence a um conjunto, mas admite uma probabilidade pequena, mas não desprezível, de falso positivos. Um filtro Bloom é inicializado como uma matriz de 𝑚bits em zero. Para adicionar um elemento, 𝑘hash funções com uma distribuição aleatória uniforme são usados, cada um mapeando para um bit da matriz que está definida para 1. Para verificar se um elemento pertence ao conjunto, executamos as funções 𝑘hash e verificamos que os 𝑘bits estão definidos como 1. Num filtro de Bloom simples, não há como distinguir se um elemento realmente pertence ao conjunto ou é um falso positivo, uma probabilidade que aumenta à medida que o número de entradas aumenta. Depois de inserir 𝑛elementos: P[falso positivo] = (︃ 1 - [︂ 1 −1 𝑚 ]︂𝑘𝑛)︃𝑘 ≈ (︁ 1 −𝑒−𝑘𝑛/𝑚)︁𝑘 assumindo a independência da probabilidade de cada conjunto de bits. Se 𝑛elementos (de tamanho arbitrário!) são espera-se que seja incluído e a probabilidade de um falso positivo tolerado é 𝑝, o tamanho da matriz pode ser calculado como: 𝑚= −𝑛ln 𝑝 (Em 2)2 Embora o número ideal de funções hash seja: 𝑘= 𝑚 𝑛ln 2 Se assumirmos a inserção de 1.000 elementos com tolerância de 1%, o tamanho do array será de 9.585 bits com 𝑘= 6, enquanto para uma tolerância de 0,1% torna-se 14377 bits com 𝑘= 9. Se um milhão de elementos espera-se que sejam inseridos, o tamanho da matriz torna-se cerca de 1170 kB para 1% e 1775 kB para 0,1%, com os mesmos valores de 𝑘, pois depende apenas de 𝑝[26]. Num jogo em que os jogadores não devem ser atribuídos a um adversário que já tenham desafiado, em vez de salvar no armazenamento para cada jogador a lista de oponentes anteriores, pode-se usar um Bloom filtro. O risco de não desafiar alguns jogadores é muitas vezes aceitável, e o filtro pode ser reiniciado periodicamente.4.3. Ethereum compatibilidade A principal vantagem de ser compatível com EVM e Ethereum é o reaproveitamento de todos os disponíveis ferramentas. Ethereum smart contracts podem ser publicados em Optimism sem qualquer modificação nem novas auditorias. As carteiras permanecem compatíveis, ferramentas de desenvolvimento e análise estática, análise geral ferramentas, ferramentas de indexação e oracles. Ethereum e Solidity têm uma longa história de estudos bem estudados vulnerabilidades, como ataques de reentrada, overflows e underflows, empréstimos instantâneos e oracle manipulações. Por causa disso, Optimism foi capaz de capturar uma grande quantidade de valor em um curto espaço de tempo tempo. Optar por adotar uma máquina virtual diferente implica reconstruir todo um ecossistema, com a vantagem de uma maior liberdade de implementação. StarkNet implementa conta nativamente abstração, que é um mecanismo pelo qual cada conta é um smart contract que pode implementar lógica arbitrária, desde que esteja em conformidade com uma interface (daí o termo abstração): isso permite o uso de diferentes esquemas de assinatura digital, a capacidade de alterar a chave privada usando o mesmo endereço ou use um multisig. A comunidade Ethereum propôs a introdução deste mecanismo com EIP-2938 em 2020, mas a proposta permaneceu obsoleta por mais de um ano como outras atualizações receberam mais prioridade [27]. Outro benefício importante obtido com a compatibilidade é a reutilização de clientes existentes: Optimism usa uma versão de geth para seu próprio nó com apenas 800 linhas de diferença, que foi desenvolvido, testado e mantido desde 2014. Ter um cliente robusto é crucial, pois define o que é aceito como válido ou não na rede. Um bug na implementação da prova de falhas sistema pode fazer com que uma prova incorreta seja aceita como correta ou uma prova correta para uma prova inválida. bloco seja aceito como incorreto, comprometendo o sistema. A probabilidade deste tipo de o ataque pode ser limitado com uma diversidade maior de clientes: Optimism pode reutilizar além de obter o outros clientes Ethereum já mantidos, e o desenvolvimento de outro cliente baseado em Erigon está já em andamento. Em 2016 um problema no gerenciamento de memória do geth foi explorado por um ataque DoS e a primeira linha de defesa foi recomendar o uso de Paridade, o segundo mais cliente usado na época 5. StarkNet enfrenta o mesmo problema com provas de validade, mas os clientes tem que ser escrito do zero e o sistema de provas é muito mais complexo e, conseqüentemente, também é muito mais complexo garantir a correção.

Сравнение

  1. Сравнение 4.1. Время вывода Наиболее важным аспектом, который отличает оптимистические сводные данные от сводных данных по достоверности, является время, которое проходит между инициализацией вывода средств и его завершением. В обоих случаях Вывод средств инициализируется на L2 и завершается на L1. На StarkNet финализация возможна как как только подтверждение достоверности нового корня состояния будет принято Ethereum: теоретически это возможен вывод средств в первом блоке L1 после инициализации. На практике частота отправки доказательств достоверности на Ethereum — это компромисс между скоростью блока доработка и агрегирование доказательств. В настоящее время StarkNet предоставляет доказательства действительности для проверки. каждые 10 часов 4, но предполагается, что оно будет уменьшаться по мере увеличения активности транзакций. На Optimism Bedrock завершить вывод можно только по окончании диспута. период (на данный момент 7 дней), по истечении которого рут автоматически считается действительным. Длина этот период главным образом определяется тем фактом, что доказательства ошибок могут подвергаться цензуре Ethereum до тех пор, пока его конец. Вероятность успеха этого типа атаки уменьшается экспоненциально с увеличением времени: E[вычтенное значение] = 𝑉𝑝𝑛 где 𝑛 — количество блоков в интервале, 𝑉 — сумма средств, которую можно вычесть опубликовав недействительный корень, и 𝑝это вероятность успешного выполнения цензуры атаковать одним блоком. Предположим, что эта вероятность составляет 99%, что значение, зафиксированное в сводном списке, составляет один миллион эфиров, а блоков в интервале — 1800 (6 часов блоков по 12 интервал секунд): ожидаемое значение составляет около 0,01391 эфира. Система защищена благодаря просить предлагающих поставить на ставку гораздо большее количество эфира, чем ожидаемое значение. Винзер и др. показал, как осуществить цензурную атаку с помощью простого smart contract это гарантирует, что определенные области памяти в состоянии не изменятся [20]. Моделирование атаки как марковская игра, в статье показано, что цензура является доминирующей стратегией рационального производитель блока, если он получит больше компенсации, чем включая транзакцию, которая меняет память. Обсуждаемое выше значение 𝑝 можно рассматривать как процент рационального блока. производителей в сети, где «рационально» не учитывается возможное наказание внешние эффекты, такие как меньшее доверие к blockchain, что снижает его ценность в криптовалюте. Следующий код представляет smart contract, который можно использовать для проведения цензурной атаки. на Бедроке. Атака использует стимулы производителей блоков, предлагая им взятку. подвергать цензуре транзакции, которые изменят определенные части государства. Основной контракт Функция ClaimBribe позволяет производителям блоков требовать взятку, если они успешно подвергают цензуре целевую транзакцию, проверив, что недействительный выходной корень не затронут. функция претензииBribe (байты памяти StorageProof) внешний { require(!claimed[block.number], "взятка уже заявлена"); Текущий объем памяти OutputProposal = StorageOracle.getStorage(L2_ORACLE, block.number, SLOT, хранилищеДоказательство); require(invalidOutputRoot == current.outputRoot, «атака не удалась»); заявлено [блок.номер] = правда; (bool отправлено, ) =block.coinbase.call{значение: bribeAmount}(""); 4https://etherscan.io/address/0xc662c410c0ecf747543f5ba90660f6abebd9c8c4require(sent, «не удалось отправить эфир»); } Листинг 1: Пример контракта, стимулирующего цензурную атаку на Bedrock. Продолжительность периода спора также должна учитывать тот факт, что доказательство вины интерактивное доказательство, поэтому участникам необходимо предоставить достаточно времени для взаимодействия и что любое взаимодействие может подвергаться цензуре. Если последний ход происходит в момент, очень близкий к В конце периода спора стоимость цензуры значительно меньше. Хотя цензура – это доминирующей стратегии, вероятность успеха ниже, поскольку узлы цензуры уязвимы для Атаки типа «отказ в обслуживании»: злоумышленник может генерировать очень сложные транзакции, которые заканчиваются публикация доказательства неисправности осуществляется бесплатно, поскольку никакие сборы не взимаются. В крайних случаях длительный период спора позволяет скоординировать действия в случае успешного решения спора. цензурная атака для организации форка и исключения атакующих производителей блоков. Другой Возможная атака состоит в публикации большего количества предложений по созданию корней штата, чем могут проверить участники спора, чего можно избежать, используя ограничение частоты. 4.1.1. Быстрый оптимистичный вывод средств Поскольку достоверность оптимистического накопительного пакета может быть проверена в любое время любым полным узлом, доверенный oracle можно использовать, чтобы узнать на L1, можно ли безопасно завершить вывод средств. Это Механизм был впервые предложен Создателем [21]: oracle проверяет вывод средств, публикует результат на L1, по которому пользователю назначается процентный кредит, который автоматически закрывается по истечении 7 дней, т. е. когда вывод действительно может быть завершен. Это решение вводит предположение о доверии, но в случае Maker оно сведено к минимуму, поскольку оператор oracle управляется той же организацией, которая принимает на себя риск, предоставляя кредит. 4.2. Транзакционные издержки Стоимость транзакций L2 в основном определяется взаимодействием с L1. В обоих решениях Вычислительная стоимость транзакций очень низкая, поскольку они выполняются полностью вне сети. Optimism публикует данные вызовов транзакций L2 как данные вызовов и редко (или никогда) выполняет ошибку доказательства, поэтому данные вызова — самый дорогой ресурс. 12 января 2022 года сеть Bedrock был запущен в тестовой сети Goerli Ethereum. Можно рассчитать степень сжатия газа отслеживая количество газа, использованного на Bedrock за определенный период, и сравнивая его с количество газа, потраченного на L1 для соответствующих блоков. С помощью этого метода происходит сжатие газа. Обнаружена скорость ~20:1, но эта цифра может отличаться в зависимости от реальной активности в основной сети. StarkNet публикует на Ethereum каждое изменение состояния L2 в виде данных вызова, поэтому хранилище самый дорогой ресурс. Поскольку сеть не использует EVM, стоимость транзакции сжатие не может быть тривиально оценено. Предполагая, что стоимость выполнения и данные вызова равны быть незначительным, можно вычислить степень сжатия записи в хранилище по сравнению с Л1. Предполагая, что контракт не развернут и 10 ячеек, к которым ранее не осуществлялся доступ на StarkNet, после модификации получена степень сжатия стоимости записи в хранилище ~24:1. Если ячейка перезаписана 𝑛раз между публикациями данных стоимость каждой записи будет равна 1/𝑛по сравнению со стоимостью одной записи, поскольку публикуется только последняя запись. Затраты можно дополнительно минимизировать за счетсжатие часто используемых значений. Стоимость проверки подтверждения действительности делится между транзакции, к которым он относится: например, блок StarkNet 4779 содержит 200 транзакций и его Доказательство действительности потребляет 267830 единиц газа или 1339,15 газа на каждую транзакцию. 4.2.1. Оптимизация данных вызова: контракт кэша Ниже представлен smart contract, который реализует кэш адресов для часто используемых адреса, воспользовавшись тем фактом, что хранение и выполнение обходятся гораздо дешевле. ресурсы вместе с контрактом друзей, который демонстрирует их использование. Последний отслеживает «друзья» адреса, которые можно зарегистрировать, вызвав функцию addFriend. Если адрес уже использовался хотя бы один раз, его можно добавить, вызвав метод addFriendWithCache. функция: индексы кэша представляют собой 4-байтовые целые числа, а адреса представлены 20 байтами, поэтому экономия аргумента функции составляет 5:1. Ту же логику можно использовать и для других данных. такие типы, как целые числа или, в более общем случае, байты. контракт AddressCache { отображение (адрес => uint32) общедоступный адрес2ключ; адрес[] открытый ключ2адрес; функция cacheWrite(address _address) внутренний возврат (uint32) { require(key2address.length < type(uint32).max, "AddressCache: кеш заполнен"); require(address2key[_address] == 0, «AddressCache: адрес уже кэширован»); // ключи должны начинаться с 1, потому что 0 означает «не найдено» ключ uint32 = uint32(key2address.length + 1); адрес2ключ[_адрес] = ключ; key2address.push(_адрес); возвратный ключ; } function cacheRead(uint32 _key) возвращает публичное представление (адрес) { require(_key <= key2address.length && _key > 0, «AddressCache: ключ не найден»); вернуть адрес key2[_key - 1]; } } Листинг 2. Контракт кэша адресов. контракт Друзья — это AddressCache { сопоставление (адрес => адрес []) общедоступных друзей; функция addFriend(адрес _friend) public { друзья[msg.sender].push(_friend); кэшWrite (_друг); } функция addFriendWithCache(uint32 _friendKey) public { друзья[msg.sender].push(cacheRead(_friendKey)); } функция getFriends() возвращает публичное представление (адрес [] памяти) { вернуть друзей[msg.sender];} } Листинг 3. Пример контракта, который наследует кэш адресов. Контракт поддерживает в кеше около 4 миллиардов (232) адресов, а добавление одного байта дает около 1 триллиона (240). 4.2.2. Оптимизация хранения: фильтры Блума На StarkNet есть несколько способов минимизировать использование памяти. Если нет необходимости гарантировать доступность исходных данных, тогда достаточно сохранить в цепочке их hash: это это механизм, используемый для сохранения данных для ERC-721 (NFT) [22], т. е. канала IPFS, который разрешает hash данных, если они доступны. Для данных, которые сохраняются несколько раз, можно использовать поиск. таблица, аналогичная системе кэширования, представленной для Optimism, требующая сохранения всех значений по адресу хотя бы один раз. В некоторых приложениях сохранения всех значений можно избежать, используя фильтр Блума. [23, 24, 25], т.е. вероятностная структура данных, позволяющая с уверенностью знать, элемент не принадлежит множеству, но допускает небольшую, но не пренебрегаемую вероятность ложного результата. позитивы. Фильтр Блума инициализируется как массив 𝑚битов с нулевым значением. Чтобы добавить элемент, используйте функцию 𝑘hash. с равномерным случайным распределением, каждый из которых соответствует биту установленного массива до 1. Чтобы проверить, принадлежит ли элемент множеству, мы запускаем функции 𝑘hash и проверяем что биты 𝑘 установлены в 1. В простом фильтре Блума нет способа отличить элемент на самом деле принадлежит множеству или является ложноположительным, вероятность, которая растет с увеличением числа записей увеличивается. После вставки 𝑛elements: P[ложное срабатывание] = (︃ 1 — [︂ 1-1 𝑚 ]︂𝑘𝑛)︃𝑘 ≈ (︁ 1 −𝑒−𝑘𝑛/𝑚)︁𝑘 предполагая независимость вероятности каждого набора битов. Если 𝑛элементы (произвольного размера!) ожидается, что он будет включен, и вероятность ложного положительного результата равна 𝑝, размер массива можно рассчитать как: 𝑚= −𝑛ln 𝑝 (пер. 2)2 А оптимальное количество функций hash составляет: 𝑘= 𝑚 𝑛ln 2 Если предположить вставку 1000 элементов с допуском 1%, размер массива составит 9585 бит. с 𝑘= 6, а при допуске 0,1% оно становится 14377 бит с 𝑘= 9. Если миллион элементов будут вставлены, размер массива составит около 1170 КБ для 1% и 1775 КБ для 0,1%, с теми же значениями 𝑘, поскольку это зависит только от 𝑝[26]. В игре, где игроки не должны быть назначены противнику, которому они уже бросили вызов, вместо сохранения в хранилище для каждого игрока списка прошлых противников можно использовать Bloom фильтр. Риск не бросить вызов некоторым игрокам часто приемлем, и фильтр можно сбросить. периодически.4.3. Ethereum совместимость Основным преимуществом совместимости с EVM и Ethereum является повторное использование всех доступных инструменты. Ethereum smart contract могут быть опубликованы на Optimism без каких-либо изменений или новые проверки. Кошельки остаются совместимыми, инструменты разработки и статического анализа, общий анализ инструменты, инструменты индексирования и oracles. Ethereum и Solidity имеют долгую историю хорошо изученных уязвимости, такие как повторные атаки, переполнение и недостаточное переполнение, быстрые кредиты и oracle манипуляции. Благодаря этому Optimism смог за короткое время получить большую сумму денег. время. Выбор использования другой виртуальной машины подразумевает необходимость перестройки всей экосистемы. с преимуществом большей свободы реализации. StarkNet изначально реализует учетную запись абстракция, представляющая собой механизм, посредством которого каждая учетная запись представляет собой smart contract, который может реализовать произвольная логика, если она соответствует интерфейсу (отсюда и термин абстракция): это позволяет использование различных схем ЭЦП, возможность изменения закрытого ключа с помощью тот же адрес или используйте мультиподпись. Сообщество Ethereum предложило ввести это механизм с EIP-2938 в 2020 году, но предложение оставалось неактуальным уже более года, поскольку другим обновлениям присвоен больший приоритет [27]. Еще одним важным преимуществом совместимости является повторное использование существующих клиентов: Optimism. использует версию geth для своего собственного узла с разницей всего в ~800 строк, что было разрабатывается, тестируется и поддерживается с 2014 года. Наличие надежного клиента имеет решающее значение, поскольку оно определяет что считается действительным или нет в сети. Ошибка в реализации доказательства неисправности система может привести к тому, что неправильное доказательство будет принято за правильное, а правильное доказательство будет принято за недействительное. блок будет принят как неправильный, ставящий под угрозу систему. Вероятность такого типа Атака может быть ограничена за счет более широкого разнообразия клиентов: Optimism можно повторно использовать в дополнение к получению другие клиенты Ethereum уже поддерживаются, а разработка еще одного клиента на базе Erigon уже идет. В 2016 году проблема с управлением памятью geth была использована для DoS-атака и первая линия защиты заключались в том, чтобы рекомендовать использование четности, второй по значимости используемый клиент на тот момент 5. StarkNet сталкивается с той же проблемой с доказательствами достоверности, но клиенты приходится писать с нуля, а система доказательства гораздо сложнее, и, следовательно, также гораздо сложнее обеспечить правильность.

Conclusão

  1. Conclusão Rollups são a solução mais promissora disponível atualmente para resolver o problema de escalabilidade em blockchains descentralizados, abrindo caminho para a era dos blockchains modulares em oposição a blockchains monolíticos. A escolha de desenvolver um Rollup Otimista ou um Rollup de Validade é mostrada principalmente como uma compensação entre complexidade e agilidade. StarkNet tem inúmeras vantagens, como rapidez retiradas, incapacidade estrutural de ter transições de estado inválidas, menor custo de transação no despesa de um período de desenvolvimento mais longo e incompatibilidade com EVM, enquanto Optimism tem alavancou a economia de rede para ganhar rapidamente uma grande fatia do mercado. Optimism Bedrock, entretanto, possui um design modular que permite que ele se torne um Validity 5https://blog.ethereum.org/2016/09/22/ethereum-network-currently-undergoing-dos-attack

Rollup no futuro: Cannon atualmente usa minigeth compilado em MIPS para sua prova de falhas sistema, mas a mesma arquitetura pode ser usada para obter um circuito e produzir provas de validade. Compilar uma máquina complexa como EVM para uma microarquitetura resulta em uma solução mais simples circuito que não precisa ser modificado e verificado novamente em caso de atualizações. RISC Zero é um microarquitetura verificável com provas STARK já em desenvolvimento com base em RISC-V que pode ser usado para esta finalidade como uma alternativa a MIPS [28]. Um aspecto que não deve ser subestimado é a complexidade em compreender como o a tecnologia funciona. Um ponto forte dos blockchains tradicionais é ser capaz de verificar o estado de o blockchain sem confiar em nenhuma entidade terceirizada. No entanto, no caso de StarkNet, é necessário confiar na implementação quando não é possível verificar os vários componentes baseado em criptografia e matemática avançada. Isto pode inicialmente criar atrito para o adoção da tecnologia, mas à medida que as ferramentas e o uso de provas de integridade avançam ainda mais fora do campo blockchain este problema será resolvido.

Заключение

  1. Заключение Накопительные пакеты — наиболее многообещающее решение, доступное сегодня для решения проблемы масштабируемости в децентрализованные blockchain, прокладывающие путь к эпохе модульных blockchain в отличие от монолитный blockchainс. В основном показан выбор между разработкой оптимистического сводного отчета или сводного отчета по достоверности. как компромисс между сложностью и гибкостью. StarkNet имеет множество преимуществ, таких как быстрая вывод средств, структурная неспособность иметь недействительные переходы между состояниями, более низкие транзакционные издержки на за счет более длительного периода разработки и несовместимости с EVM, тогда как Optimism имеет использовали сетевую экономику, чтобы быстро завоевать значительную долю рынка. Однако Optimism Bedrock имеет модульную конструкцию, которая позволяет ему стать действительным. 5https://blog.ethereum.org/2016/09/22/ethereum-network-currently-undergoing-dos-attack

Обновление в будущем: Cannon в настоящее время использует minigeth, скомпилированный в MIPS, для защиты от ошибок. система, но ту же самую архитектуру можно использовать для получения схемы и доказательства достоверности. Компиляция сложной машины, такой как EVM, для микроархитектуры приводит к более простому результату. схема, которую не нужно дорабатывать и перепроверять в случае модернизации. RISC Zero — это проверяемая микроархитектура с уже разрабатываемыми доказательствами STARK на основе RISC-V, которая может использоваться для этой цели как альтернатива MIPS [28]. Одним из аспектов, который не следует недооценивать, является сложность понимания того, как технология работает. Сильная сторона традиционных blockchain заключается в возможности проверять состояние blockchain, не доверяя какой-либо третьей стороне. Однако в случае StarkNet это необходимо доверять реализации, когда нет возможности проверить различные компоненты основанный на криптографии и высшей математике. Первоначально это может создать трения для внедрение технологии, но по мере развития инструментов и использования доказательств целостности даже за пределами поля blockchain эта проблема, надеюсь, будет решена.