Limitações de dimensionamento de blockchains e quais VM's são teoricamente as mais rápidas

Intermediário2/24/2025, 11:31:34 AM
Estamos a assistir a uma mudança para servidores únicos e poderosos; Solana, Megaeth e a grande variedade de sequenciadores únicos se inclinam em uma coisa: um único alto rendimento, servidor de alta memória (destes, o não L2 sempre será praticamente mais rápido).

Encaminhe o Título Original 'Limitações de escalabilidade de blockchains e quais VMs são teoricamente as mais rápidas'

TL;DR

Estamos a assistir a uma mudança em direção a servidores únicos e poderosos; Solana, Megaeth e a vasta gama de sequenciadores únicos todos convergem para uma coisa: um único servidor de alto débito e alta memória (destes, o não L2 será sempre praticamente o mais rápido).

Recentemente estive a conversar com outro fundador que eu respeito muito, ele mencionou que eu devia escrever a nossa conversa.

Começou com uma pergunta simples; "O Sonic paraleliza a execução de transações de alguma forma?". A resposta é não. E à primeira vista, isso pode parecer uma escolha estranha, uma vez que nos últimos 2 anos, se você esteve a par das tecnologias de VM, teria visto a paralelização praticamente em toda parte. Então, por que não estamos?

Para responder a isso, primeiro precisamos analisar como a engenharia da Sonic avalia em que devemos trabalhar, tínhamos uma tonelada de teorias que, no papel, parecem práticas, que queríamos implementar, mas recursos limitados da equipe física, então como escolhemos qual é o mais impactante? Assim, em vez de trabalhar em QUALQUER uma dessas ideias, a equipe decidiu passar um ano a construir Aida, Aida é uma ferramenta incrivelmente poderosa que nos permite reproduzir blockchains inteiras (qualquer) em minutos em vez de meses, com métricas de desempenho úteis incorporadas. Isso significa que poderíamos prototipar, testar em Aida e rapidamente saber quais teorias se sustentam e quais não.

Aida também nos permite algum perfilamento bastante poderoso, que leva a saídas como;

Portanto, com o acima exposto, poderíamos testar muito rapidamente e com precisão nossas suposições de throughput, então começamos a comparar puramente em VM de memória vs. disco, execução paralela, RDMS vs. KV vs. arquivo plano, subconjuntos, novos modelos de consenso e mais

A maior melhoria única foi o DB, um aumento de 800%, seguido pelos supersets, seguido pelo consenso e muito abaixo dessa lista, com uma modesta melhoria de 30%, foi a execução paralela. Isso parece contra-intuitivo, uma vez que um modelo mental para algo como execução paralela parece intuitivamente melhor do que os resultados. Então, como fizemos a paralelização? Talvez tenhamos cometido um erro, o teste foi a "Clarividência" a forma de ordenação absolutamente perfeita, um motor que conhece a ordenação e paralelização ótimas antes da execução (algo na prática que já é impossível, então mesmo os 30% são mais altos do que deveriam ser).


As VM's e blockchains são componentes muito complexos e, frequentemente, medimos pelas métricas erradas (ou nem medimos de todo).

Então ele me perguntou 'De onde vem a velocidade da Solana então? Ou, ela não é praticamente maior que a do Sonic?'. A resposta 'O Sonic é mais rápido que a Solana, mas o Sonic não é mais rápido do que o mais rápido que a Solana pode ser.'.

Estamos a assistir a uma mudança para servidores únicos poderosos; Solana, Megaeth e a vasta gama de sequenciadores únicos convergem todos para uma coisa: um único servidor de alta capacidade de processamento e memória (destes, o não L2 será sempre praticamente o mais rápido). Esta solução, se devidamente otimizada, será sempre mais rápida do que múltiplos participantes. Assim, a capacidade máxima otimizada de algo como Solana ou Megaeth seria superior à do seu concorrente mais rápido que utiliza 2+ servidores para consenso.

Então, a próxima pergunta é, provavelmente, por que Sonic não elege servidores de líder único então? E a resposta aqui, não é para isso que estamos otimizando. Um dos nossos começos nortenhos sobre o qual escrevi em 2018, foi que, à medida que vemos o advento dos programas de intercomunicação, em algum momento, o consenso é necessário. Suponha um cruzamento movimentado sem sinais de parada ou semáforos e centenas de tráfego de carros. O método mais otimizado é que os carros se "registrem" no cruzamento e, em seguida, concordem com uma ordem de classificação e o método mais otimizado em que cada carro deve se mover para maximizar o rendimento. Você não pode usar um sistema baseado em líder aqui, e você não pode assumir que uma parte não é maliciosa, neste caso, o consenso Sonic é otimizado até o ponto, onde ele já pode validar em um pi de framboesa hoje sem perder nenhuma taxa de transferência, então todos os carros podem concordar com a ordem baseada no consenso Sonic. O Sonic é otimizado para redes mesh.

De qualquer forma, divagações aleatórias, espero que tenha ajudado de alguma forma.

Aviso Legal:

  1. Este artigo foi republicado de [Gate.io]André Cronje]. Todos os direitos autorais pertencem ao autor original [Andre Cronje]. Se houver objeções a esta reimpressão, entre em contato com o Aprender sobre a Gate equipe, e eles vão lidar com isso prontamente.
  2. Isenção de Responsabilidade: Os pontos de vista e opiniões expressos neste artigo são exclusivamente do autor e não constituem qualquer conselho de investimento.
  3. A equipe do gate Learn faz traduções do artigo para outros idiomas. Copiar, distribuir ou plagiar os artigos traduzidos é proibido, a menos que mencionado.

Partilhar

Conteúdos

Limitações de dimensionamento de blockchains e quais VM's são teoricamente as mais rápidas

Intermediário2/24/2025, 11:31:34 AM
Estamos a assistir a uma mudança para servidores únicos e poderosos; Solana, Megaeth e a grande variedade de sequenciadores únicos se inclinam em uma coisa: um único alto rendimento, servidor de alta memória (destes, o não L2 sempre será praticamente mais rápido).

Encaminhe o Título Original 'Limitações de escalabilidade de blockchains e quais VMs são teoricamente as mais rápidas'

TL;DR

Estamos a assistir a uma mudança em direção a servidores únicos e poderosos; Solana, Megaeth e a vasta gama de sequenciadores únicos todos convergem para uma coisa: um único servidor de alto débito e alta memória (destes, o não L2 será sempre praticamente o mais rápido).

Recentemente estive a conversar com outro fundador que eu respeito muito, ele mencionou que eu devia escrever a nossa conversa.

Começou com uma pergunta simples; "O Sonic paraleliza a execução de transações de alguma forma?". A resposta é não. E à primeira vista, isso pode parecer uma escolha estranha, uma vez que nos últimos 2 anos, se você esteve a par das tecnologias de VM, teria visto a paralelização praticamente em toda parte. Então, por que não estamos?

Para responder a isso, primeiro precisamos analisar como a engenharia da Sonic avalia em que devemos trabalhar, tínhamos uma tonelada de teorias que, no papel, parecem práticas, que queríamos implementar, mas recursos limitados da equipe física, então como escolhemos qual é o mais impactante? Assim, em vez de trabalhar em QUALQUER uma dessas ideias, a equipe decidiu passar um ano a construir Aida, Aida é uma ferramenta incrivelmente poderosa que nos permite reproduzir blockchains inteiras (qualquer) em minutos em vez de meses, com métricas de desempenho úteis incorporadas. Isso significa que poderíamos prototipar, testar em Aida e rapidamente saber quais teorias se sustentam e quais não.

Aida também nos permite algum perfilamento bastante poderoso, que leva a saídas como;

Portanto, com o acima exposto, poderíamos testar muito rapidamente e com precisão nossas suposições de throughput, então começamos a comparar puramente em VM de memória vs. disco, execução paralela, RDMS vs. KV vs. arquivo plano, subconjuntos, novos modelos de consenso e mais

A maior melhoria única foi o DB, um aumento de 800%, seguido pelos supersets, seguido pelo consenso e muito abaixo dessa lista, com uma modesta melhoria de 30%, foi a execução paralela. Isso parece contra-intuitivo, uma vez que um modelo mental para algo como execução paralela parece intuitivamente melhor do que os resultados. Então, como fizemos a paralelização? Talvez tenhamos cometido um erro, o teste foi a "Clarividência" a forma de ordenação absolutamente perfeita, um motor que conhece a ordenação e paralelização ótimas antes da execução (algo na prática que já é impossível, então mesmo os 30% são mais altos do que deveriam ser).


As VM's e blockchains são componentes muito complexos e, frequentemente, medimos pelas métricas erradas (ou nem medimos de todo).

Então ele me perguntou 'De onde vem a velocidade da Solana então? Ou, ela não é praticamente maior que a do Sonic?'. A resposta 'O Sonic é mais rápido que a Solana, mas o Sonic não é mais rápido do que o mais rápido que a Solana pode ser.'.

Estamos a assistir a uma mudança para servidores únicos poderosos; Solana, Megaeth e a vasta gama de sequenciadores únicos convergem todos para uma coisa: um único servidor de alta capacidade de processamento e memória (destes, o não L2 será sempre praticamente o mais rápido). Esta solução, se devidamente otimizada, será sempre mais rápida do que múltiplos participantes. Assim, a capacidade máxima otimizada de algo como Solana ou Megaeth seria superior à do seu concorrente mais rápido que utiliza 2+ servidores para consenso.

Então, a próxima pergunta é, provavelmente, por que Sonic não elege servidores de líder único então? E a resposta aqui, não é para isso que estamos otimizando. Um dos nossos começos nortenhos sobre o qual escrevi em 2018, foi que, à medida que vemos o advento dos programas de intercomunicação, em algum momento, o consenso é necessário. Suponha um cruzamento movimentado sem sinais de parada ou semáforos e centenas de tráfego de carros. O método mais otimizado é que os carros se "registrem" no cruzamento e, em seguida, concordem com uma ordem de classificação e o método mais otimizado em que cada carro deve se mover para maximizar o rendimento. Você não pode usar um sistema baseado em líder aqui, e você não pode assumir que uma parte não é maliciosa, neste caso, o consenso Sonic é otimizado até o ponto, onde ele já pode validar em um pi de framboesa hoje sem perder nenhuma taxa de transferência, então todos os carros podem concordar com a ordem baseada no consenso Sonic. O Sonic é otimizado para redes mesh.

De qualquer forma, divagações aleatórias, espero que tenha ajudado de alguma forma.

Aviso Legal:

  1. Este artigo foi republicado de [Gate.io]André Cronje]. Todos os direitos autorais pertencem ao autor original [Andre Cronje]. Se houver objeções a esta reimpressão, entre em contato com o Aprender sobre a Gate equipe, e eles vão lidar com isso prontamente.
  2. Isenção de Responsabilidade: Os pontos de vista e opiniões expressos neste artigo são exclusivamente do autor e não constituem qualquer conselho de investimento.
  3. A equipe do gate Learn faz traduções do artigo para outros idiomas. Copiar, distribuir ou plagiar os artigos traduzidos é proibido, a menos que mencionado.
Comece agora
Registe-se e ganhe um cupão de
100 USD
!