Os componentes de um design de rollup da camada excellent Very best

Tabela de hyperlinks

Resumo e 1. Introdução

2. Conceitos -chave

   2.1 log somente de anexo e 2.2 estado de máquina digital

   2.3 Transações como funções ao curry

   2.4 Nomes naturais de estado

   2.5 Verdade do solo

   2.6 Representações eficientes de estado

   2.7 pontos de verificação

   2.8 Parâmetros de execução: calldata

   2.9 Pedido de execução

   2.10 decidindo sobre o estado correto

3. Design Very best da Camada 2

   3.1 VM Fila de empregos e finalidade de pedidos de transação

   3.2 Disponibilidade de dados e coleta de lixo

   3.3 Finalidade do Estado

   3.4 Finalidade do ponto de verificação

4. Conclusão e referências

A. Parâmetros de segurança de detecção de discrepância

3 design excellent da camada 2

O design excellent de rollup permite a computação verificável eficiente (fora da cadeia) com finaalidade rápida. Aqui, a eficiência significa:

• Computação replicada reduzida. Não queremos usar recursos, por exemplo, usar uma enorme quantidade de eletricidade, quando é desnecessário para o nível de segurança exigido. A replicação reduzida também deve reduzir o custo por transação, tornando o sistema mais escalável de uma perspectiva econômica.

• alta confiança nos resultados. Este é o inverso para a replicação: os usuários devem confiar nos resultados do cálculo verificado, mesmo que o fator de replicação possa ser menor.

• Taxa de transferência alta. A taxa de transferência geral do sistema deve ser alta, para que o sistema tenha um bom desempenho com uma alta carga de trabalho.

• baixa latência. As transações propostas não devem ter que esperar muito tempo nas filas. Os usuários devem ter confiança razoável de que, uma vez aceita uma transação, ela terá o efeito desejado/esperado.

A aparência de um design “excellent” depende de outros fatores, como a carga de trabalho esperada. Por exemplo, à medida que os sistemas se tornam mais capazes, as aplicações precisarão executar transações maiores que tenham um alto limite de gás? Qual é a distribuição dos tempos de execução? Com um design que separa a finalidade da ordem da transação e a finalidade do estado, desde que a taxa média de processamento de transações seja suficiente, o sistema deve ser capaz de tolerar transações ocasionais de tempo de execução, pois os usuários se preocupam principalmente com a finalidade da ordem de transação, assumindo que a transação cara não interfira ou interaja com a maioria dos contratos do estado dos usuários.

Esta ainda é uma área de pesquisa e algumas restrições de design são desconhecidas. Apresentamos um esboço de um design “excellent” abaixo.

3.1 VM Fila de empregos e finalidade de pedidos de transação

O design excellent do Rollup usa a finalidade “instantânea” de um blockchain de POS (por exemplo, Tenermint, eth2) para obter a finalidade da ordem de transação. Ou seja, as propostas de transações são essencialmente empregos inseridos na fila de empregos de máquinas virtuais; Uma vez inserido na fila, sua ordem é last.

Isso implica que a transação CallData não pode ser validada com a semântica da máquina digital completa, pois isso requer um acoplamento próximo entre o log e a máquina digital. Uma opção de design extrema é permitir que mensagens arbitrárias sejam registradas para segmentar a fila de empregos da VM e confiar no custo do registro para impedir ataques de negação de serviço. Isso significa, no entanto, que o custo da execução da VM para verificar e descartar a mensagem mal formada (por exemplo, pontos de entrada não assinados, incomparáveis ​​e inexistentes, and many others.) devem ser incluídos como parte do custo do manuseio de mensagens.

A publicação de mensagens deve custar algo para evitar ataques de negação de serviço. Isso significa que alguns cheques já devem ser feitos na blockchain subjacente: a própria mensagem deve ser assinada e deve autorizar o pagamento da EOA para pagar minimamente pela postagem de mensagens, bem como uma autorização de pagamento (limitada) para a execução da VM (limite de gás).

Como a verificação de assinatura é efetivamente um custo afundado, uma alternativa é realizar uma verificação muito simples das transações propostas:

• Autorização da transação: assinatura válida na proposta.

• A conta EOA tem tokens suficientes para pagar pela publicação de mensagens.

• (Opcional) a conta EOA tem tokens suficientes para pagar pelo pagamento máximo de gás, usando uma estimativa de limite inferior da fila de transações para as quais a finalização do estado não foi atingida.

Os parâmetros de chamada do contrato (CallData) são apenas bytes opacos neste momento.

Todas as propostas de transações assinadas com essas verificações básicas são consideradas “transações bem formadas” (WFTs). Observe que não realizamos verificações de tipo específico para entrada de contrato ou outras verificações pré-condicionas por contrato na ponte. A bem-formada não implica que a mensagem faça sentido. As WFTs que não passam no formato de mensagem verificações serão simplesmente abortadas com o remetente cobrado uma pequena taxa de gás: em nosso formalismo, isso significa que a interpretação é que a TC retorna com seu estado de entrada. O mesmo se aplica a outras pré-condições: elas seriam verificadas pelo código do contrato (por exemplo, o equivalente a requer cheques na solidez) e, da mesma forma, causará a transação. Isso está em conformidade com a natureza dissociada do design do sistema: o contrato de ponte não sabe quais contratos (possivelmente novos) foram instanciados no rollup, e fazer uma escala de digitação seria impraticável.

As invocações de contrato em blockchains do tipo Ethereum são estruturadas internamente como chamadas essencialmente de procedimentos remotos, com uma mensagem que deve ser (parcialmente) analisada para identificar o ponto de entrada pretendido e descobrir a assinatura do tipo e depois analisar ainda mais e digitar o restante da mensagem. Embora possa ser razoável dizer que a codificação da mensagem é arquitetonicamente fixa e realizada pela Rollup VM, ela é viável – como é feito por solidez para o EVM – para executar isso no próprio código do contrato (no caso do Solidity, no tempo de execução do idioma que executa o envio do RPC). Como os diferentes tempos de execução do idioma do contrato poderiam, em princípio, exigir formatos de serialização de dados completamente diferentes, a execução da verificação do formato de mensagem na ponte é inviável sem saber detalhes sobre como o receptor/demultiplexor de RPC de cada contrato é implementado.

O design mais simples é ver o contrato da ponte como aceitar as WFTs e exigir verificação de tempo de execução para pré-condições específicas de rollup, específicos de idiomas ou contratos específicos.

A ordem de chegada na fila de emprego mantida pelo contrato da ponte não especifica necessariamente a ordem de execução. Claramente, desde que um rollup permitir que os proponentes de transações ofereçam taxas de gás variáveis ​​(em oposição a uma taxa de mercado fixa como limite de bloqueio), os trabalhos precisarão ser classificados pelo preço do gás. E, ao usar o preço do gás como chave primária e ordem de chegada, pois a chave secundária pode aproximar uma ordem “justa”, ela permite que um pioneiro criava trivialmente transações pseudoconjugadas, propondo um par de transações a uma taxa de gás um pouco mais alta e um pouco mais baixa. Mais pesquisas são necessárias aqui, especialmente porque a implementação de um agendador justo aproximado introduzirá latência adicional ao processamento de transações.