Monad para desenvolvedores
Monad é um blockchain Layer-1 compatível com Ethereum com 10.000 tps de taxa de transferência, tempos de bloco de 1 segundo e finalidade de slot único.
A implementação da Máquina Virtual Ethereum pela Monad está em conformidade com o fork de Xangai ; a simulação de transações históricas do Ethereum com o ambiente de execução Monad produz resultados idênticos. Monad também oferece compatibilidade total com Ethereum RPC para que os usuários possam interagir com Monad usando ferramentas familiares como MetaMask e Etherscan.
A Monad consegue essas melhorias de desempenho através da introdução de diversas inovações importantes:
MonadBFT (consenso HotStuff em pipeline com melhorias adicionais de pesquisa),
Execução Diferida (pipeline entre consenso e execução para aumentar significativamente o orçamento de execução)
MonadDb (back-end de estado de alto desempenho)
Embora o Monad apresente execução e pipeline paralelos, é importante observar que os blocos no Monad são lineares e as transações são ordenadas linearmente dentro de cada bloco.
Formato de transação
Espaço de endereço
corresponde a endereços Ethereum de 20 bytes usando ECDSA
Formato de transação
corresponde ao Ethereum em conformidade com EIP-2718 , codificado com RLP . Listas de acesso ( EIP-2930 ) são suportadas, mas não são obrigatórias.
Compatibilidade com carteira
Monad é compatível com carteiras Ethereum padrão, como Metamask. A única alteração necessária é alterar o URL RPC e o ChainId.
Contratos inteligentes
Monad suporta bytecode EVM e é equivalente em bytecode ao Ethereum. Todos os opcodes (a partir da bifurcação de Xangai) são suportados.
Consenso
Mecanismo de resistência Sybil
Proof de Aposta (PoS)
Delegação
Permitido (no protocolo)
Mecanismo de consenso e pipeline
MonadBFT é um algoritmo baseado em líder para chegar a um acordo sobre a ordem e inclusão da transação em condições parcialmente síncronas. Amplamente caracterizado, é um derivado do HotStuff com melhorias adicionais de pesquisa. MonadBFT é um algoritmo BFT de duas fases em pipeline com sobrecarga de comunicação linear no caso comum. Como na maioria dos algoritmos BFT, a comunicação ocorre em fases. Em cada fase, o líder envia uma mensagem assinada aos eleitores, que devolvem respostas assinadas. O pipeline permite que o certificado de quórum (QC) ou certificado de tempo limite (TC) para bloco kpegue carona na proposta de bloco. k+1.Os tempos limite incorrem em mensagens quadráticas.
Tempo de bloqueio
1 segundo
Finalidade
Slot único. Assim que 2/3 do peso da participação votar SIM em uma proposta de bloco, ela será finalizada.
Mempool
Existe um mempool . As transações são codificadas para eliminação e comunicadas usando uma árvore de transmissão para maior eficiência.
Resistência a spam
Os usuários pagam pela inclusão em blocos (“custo de transporte”) e pela execução da transação (“custo de execução”).
Participantes do consenso
Os participantes do consenso direto votam nas propostas do bloco e atuam como líderes. Para servir como participante direto, um nó deve ter pelo menos MinStakeapostado e estar entre os principais MaxConsensusNodesparticipantes por peso de aposta. Esses parâmetros são definidos em código.
Hash de transação
Para maior eficiência, as propostas de blocos referem-se apenas a transações por hash . Se um nó não tiver uma transação, ele solicitará a transação por hash de um vizinho.
Custos diferidos de execução e transporte
No Monad, o consenso e a execução ocorrem em pipeline. Os nós chegam a um consenso sobre a ordem oficial da transação antes de executar essa ordem (Execução Diferida); o resultado da execução não é um pré-requisito para o consenso.
Em blockchains onde a execução é um pré-requisito para o consenso, o orçamento de tempo para execução é uma pequena fração do tempo do bloco. O pipeline de consenso e execução permite que o Monad gaste todo o tempo do bloco tanto no consenso quanto na execução.
As propostas de bloco consistem em uma lista ordenada de hashes de transação e uma raiz merkle de estado dos Dblocos anteriores. O parâmetro de atraso Dé definido no código; espera-se que D = 10inicialmente.
O usuário deve pagar para que uma transação seja incluída em um bloco (o “custo de transporte”). Para cada endereço, os nós mantêm dois saldos:
um saldo de reserva, usado para pagar esse custo de transporte
o saldo de execução, usado para pagar pela execução da transação
O custo de transporte é debitado ao saldo de reserva quando a operação é incluída em bloco (consenso); é deduzido do saldo de execução no momento da execução (cobrança dupla) e reembolsado ao saldo de reserva após Dpassar o período de atraso dos blocos.
O saldo de reserva de uma conta é efetivamente um orçamento para pedidos “em andamento”; existe para garantir que apenas as transações pagas sejam incluídas nos blocos.
Cada conta tem um saldo de reserva alvo que pode ser alterado interagindo com um contrato inteligente consagrado, por exemplo, para EOAs que antecipam o envio de um grande número de pedidos a bordo.
Determinismo de estado
A finalidade ocorre no momento do consenso; a ordem oficial das transações está consagrada neste ponto, e o resultado é totalmente determinístico para qualquer nó completo, que geralmente executará as transações para esse novo bloco em menos de 1 segundo. O Datraso -block para raízes merkle de estado é apenas para verificação de raiz de estado, por exemplo, para permitir que um nó garanta que não cometeu um erro de cálculo.
Execução
A fase de execução de cada bloco começa após o consenso ser alcançado naquele bloco, permitindo que o nó prossiga com o consenso nos blocos subsequentes.
Execução Paralela
As transações são ordenadas linearmente; a tarefa de execução é chegar ao estado resultante da execução serial dessa lista de transações. A abordagem ingênua consiste apenas em executar as transações uma após a outra. Podemos fazer melhor? Sim, nós podemos!
Monad implementa execução paralela :
Um executor é uma máquina virtual para executar transações. Monad executa muitos executores em paralelo.
Um executor pega uma transação e produz um resultado . Um resultado é uma lista de entradas e saídas das transações, onde as entradas são tuplas (ContractAddress, Slot, Value) que foram SLOADed no decorrer da execução e as saídas são tuplas (ContractAddress, Slot, Value) que foram SSTORed como um resultado da transação.
Os resultados são inicialmente produzidos em estado pendente; eles são então confirmados na ordem original das transações. Quando um resultado é confirmado, suas saídas atualizam o estado atual. Quando é a vez de um resultado ser confirmado, o Monad verifica se suas entradas ainda correspondem ao estado atual; caso contrário, a Monad reprogramará a transação. Como resultado desse controle de simultaneidade, é garantido que a execução do Monad produzirá o mesmo resultado como se as transações fossem executadas em série.
Quando as transações são reprogramadas, muitas ou todas as entradas necessárias são armazenadas em cache, portanto a reexecução geralmente é relativamente barata. Observe que na reexecução, uma transação pode produzir um conjunto de entradas diferente do que a execução anterior produziu;
MonadDb: back-end de estado de alto desempenho
Todo o estado ativo é armazenado no MonadDb , um back-end de armazenamento para unidades de estado sólido (SSDs) otimizado para armazenar dados merkle trie. As atualizações são em lote para que a raiz merkle possa ser atualizada com eficiência.
MonadDb implementa cache na memória e usa asio para leituras e gravações assíncronas eficientes. Os nós devem ter 32 GB de RAM para desempenho ideal.
Comparação com Ethereum: Perspectiva do Usuário
Atributo
Ethereum
Monad
Transações/segundo (chamadas e transferências de contratos inteligentes)
~10
~10.000
Tempo de bloqueio
12s
1s
Criptografia
ECDSA
ECDSA
Contas
Últimos 20 bytes do keccak-256 da chave pública sob ECDSA
Últimos 20 bytes do keccak-256 da chave pública sob ECDSA
Mecanismo de consenso
Gasper (gadget de finalidade Casper-FFG + regra de escolha de fork LMD-GHOST)
MonadBFT (HotStuff em pipeline com melhorias adicionais de pesquisa)
Mempool
Sim
Sim
Pedido de transação
Discricionariedade do líder (na prática, PBS)
Discricionariedade do líder (comportamento padrão: leilão de gás prioritário)
Mecanismo de resistência a Sybil
PoS
PoS
Delegação permitida
Não; pseudo-delegação através de LSTs
Sim
Requisitos de hardware (full node)
CPU de 4 núcleos, 16 GB de RAM, SSD de 1 TB, largura de banda de 25 Mbit/s
CPU de 16 núcleos, 32 GB de RAM, SSD de 2 TB, largura de banda de 100 Mbit/s
Last updated