Olá,
A escalabilidade da transação tem sido o assunto da cidade. Temos estado a explorar como Monad ajuda a escalar TPS ao longo das últimas semanas.
A nota abaixo é um resumo de como o Monad funciona escrito por @desh_saurabh. Considere inscrever-se emDecentralised.cose gostares de ler explicadores baseados em dados sobre tudo o que é Web3. Vemo-nos do outro lado!
TPS é uma métrica sobre a qual obsessamos. Queremos que as nossas cadeias suportem um TPS mais elevado, uma vez que poderiam suportar mais utilizadores e aplicações. O gráfico abaixo mostra os números de TPS para Ethereum e L2s. Nenhuma cadeia jamais ultrapassou a marca de 100 TPS. Note que TPS é um termo geral para medir a escala. TPS é impreciso porque nem todas as transações são iguais, uma vez que diferem em complexidade. Mas usamos TPS como medida de escala por simplicidade.
O que fazemos se quisermos aumentar o TPS?
Monad, uma nova L1 compatível com a EVM que recentemente levantou $225 milhões, está a construir a EVM a partir do zero em vez de a utilizar como está. Escolheu esta terceira abordagem para aumentar a escalabilidade.
Discutimos algumas mudanças significativas que Monad traz à mesa.
A Máquina Virtual Ethereum (EVM) executa transações de forma serial. Até que uma transação seja executada, a próxima transação tem que esperar. Pense nisso desta forma. Digamos que haja uma plataforma em um armazém de montagem de motocicletas. Vários camiões deixam peças de motocicletas (de tal forma que cada camião tem todas as peças necessárias para criar 50 motocicletas). O armazém de montagem realiza quatro funções diferentes com equipas dedicadas – descarga, classificação, montagem e carregamento.
Com a configuração atual do EVM, há apenas uma plataforma e o mesmo local é usado para carregar e descarregar. Assim, quando o camião está estacionado, os componentes da motocicleta são descarregados, classificados, montados e carregados no mesmo camião. Enquanto a equipa de classificação está a trabalhar, todas as outras equipas estão apenas à espera. Portanto, se pensarmos nos seus trabalhos como slots diferentes, cada equipa trabalha apenas uma vez em quatro slots. Isso leva a ineficiências significativas, destacando a necessidade de uma abordagem mais eficiente.
Agora, imagine que existem quatro plataformas com áreas de carga e descarga diferentes. Mesmo que a equipe de descarga possa trabalhar com apenas um camião de cada vez, não precisam de esperar pelos próximos três lugares. Podem passar diretamente para o próximo camião.
O mesmo se aplica às equipas de classificação, montagem e carregamento. Uma vez que a carga do camião é descarregada, o camião desloca-se para a área de carregamento e aguarda que a equipa de carregamento carregue as motas montadas. Assim, o armazém com apenas uma plataforma e área de carregamento/descarregamento executa tudo sequencialmente, e o que tem 4 plataformas e diferentes áreas de carregamento/descarregamento está a paralelizar.
Considere o Monad como uma infraestrutura equivalente ao armazém com várias plataformas de camiões - mas não tão simples. A complexidade aumenta quando os camiões são dependentes. Por exemplo, e se um camião não tiver todas as peças para fazer 50 motociclos? As transações podem nem sempre ser independentes. Assim, quando o Monad as executa em paralelo, tem de lidar com transações dependentes umas das outras.
Como? Ele realiza algo chamado de execução paralela otimista. O protocolo só pode executar transações independentes em paralelo. Por exemplo, considere 4 transações com o saldo de Joel como 1 ETH -
Todas essas transações são executadas em paralelo com resultados pendentes que são comprometidos um por um. As transações são reexecutadas se os resultados pendentes entrarem em conflito com as entradas originais de qualquer transação. As transações 2 e 4 não têm resultados pendentes conflitantes com as entradas de outras transações, pois são independentes entre si. Mas 1 e 3 não são independentes.
Note que, uma vez que todas as 4 transações partem do mesmo estado, a que está em causa aqui é o saldo de Joel de 1 ETH. O resultado de Joel enviar 0,2 ETH resulta em 0,8 ETH. Depois de Joel enviar 0,1 ETH para Sid, o seu saldo é de 0,9 ETH. Os resultados são comprometidos um por um, garantindo que os resultados não entrem em conflito com qualquer um dos inputs. Após o resultado pendente de 1 ser comprometido, o novo saldo de Joel é de 0,8 ETH.
Esta saída entra em conflito com a entrada de 3. Assim, agora 3 é reexecutado com uma entrada de 0.8 ETH. Após a execução do 3, o saldo de Joel é de 0.7 ETH.
Neste ponto, uma questão óbvia é como sabemos que não teremos que reexecutar a maioria das transações. A resposta está no fato de que a reexecução não é o gargalo. O gargalo é o acesso à memória do Ethereum. Acontece que a forma como o Ethereum armazena seu estado no banco de dados torna difícil (demorado e, portanto, caro) acessar o estado. É aqui que entra a outra melhoria da Monad - MonadDb. A Monad construiu seu banco de dados de maneira a reduzir a sobrecarga associada às operações de leitura.
Quando uma transação tem que ser reexecutada, todos os inputs já estão na memória cache, o que é significativamente mais fácil de acessar em comparação com o estado geral.
Solana tem 50k TPS na sua rede de testes, mas faz cerca de 1k na mainnet agora. A Monad afirma ter alcançado 10k TPS reais na sua rede de testes interna. Embora nem sempre seja indicativo do desempenho no mundo real, estamos ansiosos por ver como a Monad funciona na natureza.
Este artigo originalmente intitulado "Understanding Monad" é reproduzido a partir de [chaincatcher]. Todos os direitos autorais pertencem ao autor original [Decentralised.Co]. Se tiver alguma objeção à reimpressão, entre em contacto com o Equipe Gate Learn, a equipa tratará disso o mais rapidamente possível.
Isenção de responsabilidade: As opiniões expressas neste artigo representam apenas as opiniões pessoais do autor e não constituem qualquer conselho de investimento.
As traduções do artigo para outros idiomas são feitas pela equipe da Gate Learn. Salvo indicação em contrário, é proibido copiar, distribuir ou plagiar os artigos traduzidos.
Olá,
A escalabilidade da transação tem sido o assunto da cidade. Temos estado a explorar como Monad ajuda a escalar TPS ao longo das últimas semanas.
A nota abaixo é um resumo de como o Monad funciona escrito por @desh_saurabh. Considere inscrever-se emDecentralised.cose gostares de ler explicadores baseados em dados sobre tudo o que é Web3. Vemo-nos do outro lado!
TPS é uma métrica sobre a qual obsessamos. Queremos que as nossas cadeias suportem um TPS mais elevado, uma vez que poderiam suportar mais utilizadores e aplicações. O gráfico abaixo mostra os números de TPS para Ethereum e L2s. Nenhuma cadeia jamais ultrapassou a marca de 100 TPS. Note que TPS é um termo geral para medir a escala. TPS é impreciso porque nem todas as transações são iguais, uma vez que diferem em complexidade. Mas usamos TPS como medida de escala por simplicidade.
O que fazemos se quisermos aumentar o TPS?
Monad, uma nova L1 compatível com a EVM que recentemente levantou $225 milhões, está a construir a EVM a partir do zero em vez de a utilizar como está. Escolheu esta terceira abordagem para aumentar a escalabilidade.
Discutimos algumas mudanças significativas que Monad traz à mesa.
A Máquina Virtual Ethereum (EVM) executa transações de forma serial. Até que uma transação seja executada, a próxima transação tem que esperar. Pense nisso desta forma. Digamos que haja uma plataforma em um armazém de montagem de motocicletas. Vários camiões deixam peças de motocicletas (de tal forma que cada camião tem todas as peças necessárias para criar 50 motocicletas). O armazém de montagem realiza quatro funções diferentes com equipas dedicadas – descarga, classificação, montagem e carregamento.
Com a configuração atual do EVM, há apenas uma plataforma e o mesmo local é usado para carregar e descarregar. Assim, quando o camião está estacionado, os componentes da motocicleta são descarregados, classificados, montados e carregados no mesmo camião. Enquanto a equipa de classificação está a trabalhar, todas as outras equipas estão apenas à espera. Portanto, se pensarmos nos seus trabalhos como slots diferentes, cada equipa trabalha apenas uma vez em quatro slots. Isso leva a ineficiências significativas, destacando a necessidade de uma abordagem mais eficiente.
Agora, imagine que existem quatro plataformas com áreas de carga e descarga diferentes. Mesmo que a equipe de descarga possa trabalhar com apenas um camião de cada vez, não precisam de esperar pelos próximos três lugares. Podem passar diretamente para o próximo camião.
O mesmo se aplica às equipas de classificação, montagem e carregamento. Uma vez que a carga do camião é descarregada, o camião desloca-se para a área de carregamento e aguarda que a equipa de carregamento carregue as motas montadas. Assim, o armazém com apenas uma plataforma e área de carregamento/descarregamento executa tudo sequencialmente, e o que tem 4 plataformas e diferentes áreas de carregamento/descarregamento está a paralelizar.
Considere o Monad como uma infraestrutura equivalente ao armazém com várias plataformas de camiões - mas não tão simples. A complexidade aumenta quando os camiões são dependentes. Por exemplo, e se um camião não tiver todas as peças para fazer 50 motociclos? As transações podem nem sempre ser independentes. Assim, quando o Monad as executa em paralelo, tem de lidar com transações dependentes umas das outras.
Como? Ele realiza algo chamado de execução paralela otimista. O protocolo só pode executar transações independentes em paralelo. Por exemplo, considere 4 transações com o saldo de Joel como 1 ETH -
Todas essas transações são executadas em paralelo com resultados pendentes que são comprometidos um por um. As transações são reexecutadas se os resultados pendentes entrarem em conflito com as entradas originais de qualquer transação. As transações 2 e 4 não têm resultados pendentes conflitantes com as entradas de outras transações, pois são independentes entre si. Mas 1 e 3 não são independentes.
Note que, uma vez que todas as 4 transações partem do mesmo estado, a que está em causa aqui é o saldo de Joel de 1 ETH. O resultado de Joel enviar 0,2 ETH resulta em 0,8 ETH. Depois de Joel enviar 0,1 ETH para Sid, o seu saldo é de 0,9 ETH. Os resultados são comprometidos um por um, garantindo que os resultados não entrem em conflito com qualquer um dos inputs. Após o resultado pendente de 1 ser comprometido, o novo saldo de Joel é de 0,8 ETH.
Esta saída entra em conflito com a entrada de 3. Assim, agora 3 é reexecutado com uma entrada de 0.8 ETH. Após a execução do 3, o saldo de Joel é de 0.7 ETH.
Neste ponto, uma questão óbvia é como sabemos que não teremos que reexecutar a maioria das transações. A resposta está no fato de que a reexecução não é o gargalo. O gargalo é o acesso à memória do Ethereum. Acontece que a forma como o Ethereum armazena seu estado no banco de dados torna difícil (demorado e, portanto, caro) acessar o estado. É aqui que entra a outra melhoria da Monad - MonadDb. A Monad construiu seu banco de dados de maneira a reduzir a sobrecarga associada às operações de leitura.
Quando uma transação tem que ser reexecutada, todos os inputs já estão na memória cache, o que é significativamente mais fácil de acessar em comparação com o estado geral.
Solana tem 50k TPS na sua rede de testes, mas faz cerca de 1k na mainnet agora. A Monad afirma ter alcançado 10k TPS reais na sua rede de testes interna. Embora nem sempre seja indicativo do desempenho no mundo real, estamos ansiosos por ver como a Monad funciona na natureza.
Este artigo originalmente intitulado "Understanding Monad" é reproduzido a partir de [chaincatcher]. Todos os direitos autorais pertencem ao autor original [Decentralised.Co]. Se tiver alguma objeção à reimpressão, entre em contacto com o Equipe Gate Learn, a equipa tratará disso o mais rapidamente possível.
Isenção de responsabilidade: As opiniões expressas neste artigo representam apenas as opiniões pessoais do autor e não constituem qualquer conselho de investimento.
As traduções do artigo para outros idiomas são feitas pela equipe da Gate Learn. Salvo indicação em contrário, é proibido copiar, distribuir ou plagiar os artigos traduzidos.