Abstração de contas

CriptoBrasil

👇🏻 Link do GRUPO:

Introdução

A abstração de dados na ciência da computação é a prática de ocultação de informações. Isso aumenta a capacidade de um sistema de computador ser usado em um nível mais alto com menos conhecimento dos processos que estão acontecendo por baixo.

Considere o desenvolvedor de software. Uma linguagem de programação de alto nível é usada para criar interações virtuais entre objetos. O programador não precisa saber como escrever os 1 e 0's que compõem o código da máquina que funciona fisicamente na memória e no processador. Este é um exemplo de abstração de dados.

Na rede Ethereum existem atualmente dois tipos de contas. Contas externas são carteiras das quais a criptomoeda é transacionada no envio e recebimento de funções que existem fora do EVM (Ethereum Virtual Machine). As contas contratuais são "contratos inteligentes" que existem no EVM.

O EVM é um computador virtual que existe na blockchain Ethereum. Uma série de OPCODES foram duramente programados na blockchain Ethereum para poder atuar como uma máquina virtual; memória, armazenamento e processamento na execução de contratos inteligentes.

A abstração da conta Ethereum tem o objetivo de reduzir de dois tipos de conta para um, uma conta de contrato. O único tipo de conta terá a funcionalidade de transacionar tanto a moeda quanto o contrato. O desenvolvedor e o usuário não precisarão mais fazer uma distinção entre o tipo de conta, uma vez que a transação será totalmente movida para o EVM e fora do protocolo blockchain.

A abstração da conta será uma implementação do Ethereum 2.0 e ainda há um debate feroz sobre a metodologia ao fazê-lo.

Possíveis métodos de implementação

Como descrito pelo co-fundador da Ethereum Vitalik Buterin

Abstração total preguiçosa

Como funciona: o único tipo de conta é um contrato. Há um tipo de transação, que tem os seguintes campos: [gás, addr, dados]. A execução da transação consiste em reproduzir uma mensagem, com msg.sender sendo algum endereço padrão "ENTRY_POINT" (por exemplo, 0xff... ff), msg.to sendo o aditivo, sendo o gás e os dados os valores fornecidos. Espera-se que os usuários armazenem fundos em contas contratuais, onde o código do contrato interpreta os dados fornecidos como uma codificação de ABI de [nonce, assinatura, preço gasoso, valor, dados], verifica a nonce e assinatura, paga gás ao mineiro, envia uma mensagem para o endereço desejado com o valor desejado e, em seguida, pede um reembolso para o gás restante.
Prós: torna o protocolo muito simples. apply_tx se torna um invólucro muito trivial em torno de apply_msg.
Contras: requer um código bastante complexo dentro de cada conta para verificar a nonce e assinatura e pagar gás. Em segundo lugar, requer um código bastante complexo na mineradora para determinar quais transações realmente são garantidas para pagar pela gasolina. Em terceiro lugar, requer uma lógica adicional para o remetente e o mineiro criarem novas contas. Finalmente, ele introduz a possibilidade de que, com contas construídas de forma "fora do padrão", uma transação com o mesmo hash poderia ser incluída várias vezes.

O problema do mineiro é o seguinte. A mineradora precisa verificar, em O(1) tempo, que uma determinada transação realmente é garantida para pagar o gás se a mineradora decidir processar a transação e tentar incluí-la no bloco. Em um sistema de abstração, isso poderia envolver pedir à mineradora para executar algum código, digamos, com um limite de 200000 de gás, mas a mineradora precisaria ter certeza de que, depois que isso acontece, a execução da transação é em um estado onde o gás é pago, e o pagamento não pode ser revertido. Atualmente, o protocolo lida com isso automaticamente; em abstração total, tudo isso deve ser implementado em código, e possivelmente de forma bastante complexa.

Remover a abstração de nonce

Como funciona: o mesmo que acima, exceto que uma transação também tem um campo de nonce. Uma regra é adicionada de que a nonce de uma transação deve ser igual à nonce da conta, e que a nonce é incrementada após uma transação bem-sucedida.
Prós: remove a possibilidade de uma transação aparecer em vários lugares.
Contras: aumenta ligeiramente a complexidade do protocolo base e elimina a possibilidade de esquemas alternativos (por exemplo. UTXOs, nonces paralelamente)

Padronizar esquema de assinatura

Como funciona: adicione um sig de campo byte-array à transação. Na mensagem de nível superior, adicione ao sighash de dados de retorno da transação ++ sig, onde sighash é o sha3 da transação que não inclui o sig.
Prós: torna a verificação de assinatura muito mais simples.
Contras: aumenta ligeiramente a complexidade do protocolo base.

Adicionar código opcode BREAKPOINT

Como funciona: adicione um opcode BREAKPOINT, que tem a propriedade que se uma transação joga após um breakpoint, ela só reverte até o breakpoint.
Prós: torna muito mais fácil para a mineradora detectar se uma transação paga pelo gás; o código do mineiro só precisaria ser algo como "correr para n passos ou até um ponto de ruptura, ver que o ponto de ruptura foi atingido, e que o gás foi pago".
Contras: mudança profunda e fundamental para o EVM. Historicamente não é a melhor ideia.

Adicionar código opcode PAYGAS

Como funciona: toma como entrada um argumento (gasprice), transfere imediatamente o preço gasoso * tx.gas para uma conta temporária e, em seguida, no final da execução da transação restitue qualquer gás nãousado.
Prós: torna o pagamento pelo gás mais simples, e particularmente não exige que a transação inclua filiais merkle para processar uma chamada para a base de moedas. Evita a sobrecarga de uma chamada para a base de moedas.
Contras: aumenta a complexidade do protocolo base. Também não permite a abstração do pagamento do gás, por exemplo. pagando com tokens ERC20.

Gasprice + PANIC

Como funciona: uma transação adiciona um preço de gasce de parâmetro. No início da execução, o preço gasoso * startgas é subtraído. Um opcode PANIC é adicionado, que só pode ser chamado em um contexto de execução de nível superior (ou seja, se msg.sender == ENTRY_POINT) e onde (tx.gas - msg.gas) <= PANICLIMIT (por exemplo. PANICLIMIT = 200000). Se este opcode for acionado, então toda a transação será inválida. Uma conta de usuário faria questão de verificar a assinatura e a nonce dentro do limite, impedindo que transações inválidas consumam gás. Os mineiros fariam transações com um preço suficiente e rejeitariam aqueles que entram em pânico.
Prós: código de conta é simples, e código miner é simples, enquanto ainda adiciona assinatura completa e abstração nonce
Contras: aumenta ligeiramente a complexidade do protocolo base. Também não permite a abstração do pagamento do gás, por exemplo. pagando com tokens ERC20. Em terceiro lugar, não fornece flexibilidade no tempo que a verificação de assinatura pode levar (embora casper já imponha um limite, de modo que o limite pode ser definido como o mesmo valor). Uma possível variante é simplesmente fazer com que o comportamento de invalidez da transação faça parte do comportamento da THROW se for chamado em um contexto de alto nível com a quantidade de gás restante.

Combine PÂNICO e PAYGAS

Como funciona: remova o PÂNICO. Em vez disso, todas as exceções têm comportamento equivalente ao PANIC se o PAYGAS ainda não foi chamado.
Prós: permite que as contas estabeleçam seu próprio limite de gás de verificação base. Um mineiro pode executar o algoritmo de executar o código para até n gás, onde N é escolhido pelo mineiro, até paygas foi chamado. Além disso, elimina a necessidade de o preço do gás fazer parte do órgão de transação.
Contras: torna o estado de saída de uma mensagem um pouco mais complicado, pois também precisa levar as informações se um opcode paygas foi acionado ou não e se sim com o preço do gás.

Sal + código em transação

Como funciona: uma transação tem dois novos campos: sal e código. Se a conta-alvo de uma transação for nenhuma, então esses dois campos devem estar vazios [variante: são ignorados]. Se a conta de destino estiver vazia, então os últimos 20 bytes de sha3 (salt + code) devem ser iguais à conta, e se esse for o caso, então o código é colocado nessa posição no código da conta [variante: é usado como código de imite].
Prós: cria uma maneira padrão e limpa de criar novas contas.
Contras: adiciona complexidade de protocolo.

Conta recém-criada paga

Como funciona: uma transação pode ser uma transação de criação de contrato especificando um sal e um código. Se o endereço alvo estiver vazio, então é preciso fundos desse endereço para pagar a gasolina e, em seguida, cria o contrato.
Prós: semelhante à criação de contratos existentes.
Contras: enviar a primeira transação de uma conta dá um passo adicional.

Abstração de conta minimamente simples sem reembolsos de gás

Como descrito pelo co-fundador da Ethereum Vitalk Buterin:

Trata-se de uma proposta de abstração de contas que alcança uma simplicidade significativamente maior, e maior generalidade, do que qualquer coisa proposta até agora, mas a um preço: transações cujos custos de gás não são completamente estáticos podem acabar sobrecarregando o gás.

A proposta é simples. Adicione um BREAKPOINT de código opcode, com a propriedade que uma chamada de função que falha após um BREAKPOINT reverte apenas até o BREAKPOINT. O código da conta do usuário seria, em geral, estruturado da seguinte forma:

verify_nonce() verify_signature() enviar (coinbase, x) breakpoint() do_stuff() do_more_stuff()

Depois que a execução atingir o código de controle BREAKPOINT, o proponente do bloco está certo de que eles serão compensados por incluir a transação. Observe que neste modelo, não são possíveis reembolsos para gás não uso.

Para adicionar mais flexibilidade, adicione outro opcode, DECREASE_LIMIT, que diminui o limite de gás restante sem consumir gás. Isso permitiria o código da conta onde o limite de gás de uma transação pode ser determinado no "cabeçalho" (ou seja, antes do envio e BREAKPOINT).

Consequências

apply_msg e apply_tx se tornam idênticos (a reforma do mercado de taxas 7 pode ser feita no nível por bloco), reduzindo consideravelmente a complexidade
A ABI precisaria especificar o consumo máximo de gás de cada chamada de função, para que os máximos apertados possam ser computados mais facilmente
Não requer análise estática do código
Levaria a alguma ineficiência nos casos em que os custos de gás realmente são variáveis (o caso de uso mais comum é o CREATE2'ing um contrato se e somente se ele não existir ainda), pois o usuário precisaria pagar pelo maior nível de consumo, mesmo que o menor nível de consumo seja mais frequente
Implementa a abstração total, para que percamos a garantia de exclusividade de hash tx

Considerações de segurança

Para pagar os recursos de computação de nodes e mineradores e incentivar o uso de código eficiente, há um custo de Gás associado às interações de contratos inteligentes.

Um dos vetores de ataque para a blockchain Ethereum é o DoS (negação de serviço) criando transações que são computacionalmente intensivas. Os esforços vistos acima destinam-se a ser capazes de carregar a quantidade correta de Gás sem permitir um vetor de ataque para DoS.

✅ Para mais informações entre no nosso Grupo do Telegram sobre Bitcoin e Criptomoedas:

🔵 https://t.me/BitcoinBrasilGrupo