Compreendendo a ordem de execução e transação blockchain

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 Ideally suited 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

2 conceitos -chave

Nesta seção, introduzimos idéias, notação e terminologia usadas para descrever e delinear o espaço de design de sistemas de contrato inteligente, usando alguns sistemas conhecidos existentes como pontos de referência. A aplicação dessas idéias nos ajudará a criar um modelo matemático / psychological mais simples e mais fácil do que todos os sistemas blockchain fazem e a discutir / analisar compensações nos projetos atuais e futuros. Essas noções se aplicam tanto a blockchains padrão quanto a soluções de escala, como rollups.

2.1 Log somente de anexo

Os logs somente de anexo usados ​​em Bitcoin e Ethereum V1 são projetos baseados em prova de trabalho (POW), enquanto aqueles usados ​​no Ethereum V2, Cosmos, Polkadot, Oasis, and so on são projetos baseados em Prova de participação (POS).

No nível de abstração necessária aqui, a única coisa com que nos preocupamos é que a operação do Apêndos para um log de prisioneiros de guerra é probabilística e uma entrada não é considerada bem -sucedida até que cerca de 6 entradas adicionais tenham sido feitas (a distância até o last da corrente é um parâmetro de segurança aqui). Normalmente, a idéia de precisar de entradas adicionais em PoW é chamada de “finalidade probabilística”.

Logs POS Use eleições do comitê e assinaturas digitais em vez de resolver quebra -cabeças criptográficos e, uma vez concluída o protocolo de consenso e uma nova entrada de log é feita, ela é considerada last. Embora leve tempo para a execução do protocolo de consenso, nenhuma entrada adicional é necessária e isso é frequentemente referido como “finalidade instantânea”.

Vamos nos referir à idéia geral como “finalidade de log”, seja probabilística (com o parâmetro de segurança apropriado) ou instantâneo. A finalidade do log é o mecanismo sobre o qual outras noções de finalidade são construídas: a finalidade do log diz apenas que alguma entrada é anexada com sucesso ao log, mas não diz nada sobre o que essa entrada significa.

2.2 Estado da máquina digital

Como o “estado” pode ser codificado e representado de várias maneiras, precisamos começar com as necessidades matemáticas para descrever o que queremos dizer com “estado” de uma maneira que se divorciou de qualquer representação em specific. Por “estado”, queremos dizer uma função de um conjunto de chaves, seu domínio, para um conjunto de valores, seu intervalo, ou seja, estado: chave → valor. No Bitcoin, a chave seria essencialmente as chaves públicas, e o valor seria números representando a quantidade de tokens de bitcoin sob o controle das teclas privadas correspondentes. In Ethereum-like techniques, Key could be a union of a number of disjoint units, eg, public key hashes related to Externally Owned Accounts (EOAs), contract addresses, contract tackle and 256-bit tackle tuples for naming persistent retailer areas, and so on. Correspondingly, Worth could be public keys, EOA balances, contracts’ code and steadiness, and 256-bit values ​​from contracts’ persistent retailer, and so on.[1]

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

Os usuários de sistemas baseados em blockchain propõem transações registradas ao serem anexados ao blockchain. Normalmente, pensamos nas transações como um estado de alteração. Em uma descrição matemática, são funções que transformar Estado, ou seja, estado → Estado. Pontos de entrada de contratos inteligentes aceitam argumentos – no Ethereum, o Calldata – e não se encaixa nessa assinatura do tipo; No entanto, ao curar todos os argumentos fornecidos pelo usuário, incluindo informações de autorização (msg.sender, and so on), todas as transações podem ser modeladas dessa maneira.[2]

Essa é uma separação útil, uma vez que a maioria das máquinas virtuais contratadas implementa a semântica da transação ácida padrão, e uma transação explícita aborta a reversão do estado do contrato (falha atomicidade) está apenas devolvendo a TC de seu estado de entrada, embora as taxas de gás para a computação realizadas até o aborto ainda devam ser pagas.

2.4 Nomes naturais de estado

Como os usuários pensam em suas transações como sendo executadas em uma ordem serial estrita e enviam transações com base no modelo do que o estado atual do sistema (por exemplo, seu equilíbrio de EOA), uma maneira pure de se referir a qualquer estado acessível é a sequência de transações que produz esse estado.

2.4.1 Nomes e composição de transformações

Observe que, para Bitcoin, Ethereum e Arbitrum, o nome pure é exatamente o que é registrado na blockchain. Outros sistemas de contrato inteligentes podem apenas implicitamente Registre a ordem de execução, por exemplo, como parte de um Zksnark, provando a execução correta.

2.4.2 Nomes não são únicos

Observe que os nomes não são únicos. Muitos estados têm vários nomes. Se duas transações f e g se deslocam em um determinado estado s, ou seja, o estado resultante é (f; g) (s) = (g; f) (s), então existem (pelo menos) dois nomes para o estado resultante. Obviamente, se F e G foram propostos, o sistema acabará decidindo sobre algum pedido. Isso é análogo a como 0+ 1+ 2 e 0 + 2 + 1 são ambos os caminhos de nomear o valor 3.

Observe também que alguns estados não têm nomes nesta nomenclatura. Por exemplo, um estado em que uma EOA controla mais tokens do que o suprimento whole de token é inacessível, pois (ausente um bug catastrófico) não há sequências de transações do estado de gênese que resultaria em tal estado. Isso é bom, já que esses estados inacessíveis não têm interesse.

[1] Esta é apenas uma maneira de modelar o estado do Ethereum; Outros modelos, por exemplo, como um conjunto de mapeamentos um para cada tipo de chave, seriam mais precisos.