Encaminhe o título original'Limitações de escalar blockchains e quais VMs são teoricamente as mais rápidas'
Estamos presenciando uma mudança em direção a servidores poderosos únicos; Solana, Megaeth e a ampla gama de sequenciadores únicos todos se inclinam para uma coisa: servidor único de alta capacidade de processamento e alta memória (desses, o não L2 sempre será praticamente o mais rápido).
Recentemente estive conversando com outro fundador que eu respeito muito, ele mencionou que eu deveria escrever nossa conversa.
Tudo começou com uma pergunta simples; "O Sonic paraleliza a execução de transações de alguma forma?". A resposta é não. E isso, a princípio, pode parecer uma escolha estranha, já que nos últimos 2 anos, se você esteve lendo sobre tecnologia VM, teria visto a paralelização praticamente em todos os lugares. Então, por que não estamos?
Para responder a isso, primeiro precisamos olhar como a engenharia do Sonic avalia o que devemos trabalhar, tínhamos uma tonelada de teorias, que no papel parecem práticas, que queríamos implementar, mas recursos físicos limitados da equipe, então como escolher qual é a mais impactante? Então, em vez de trabalhar em QUALQUER uma dessas ideias, a equipe decidiu passar um ano para construir Aida, Aida é uma ferramenta incrivelmente poderosa que nos permite reproduzir blockchains inteiros (qualquer) em minutos, em vez de meses, com métricas de desempenho úteis. Isso significa que poderíamos prototipar, testar em Aida e saber muito rapidamente quais teorias se sustentam e quais não.
Aida também nos permite fazer alguns perfis bastante poderosos, o que leva a saídas como;
Portanto, com o que foi dito acima, poderíamos testar muito rapidamente e com precisão nossas suposições de throughput, então partimos para comparar puramente na memória VM vs disco, execução paralela, RDMS vs KV vs arquivo plano, conjuntos, novos modelos de consenso e mais
A maior melhoria única foi o DB, um aumento de 800%, em seguida, supersets, seguido de consenso, e muito baixo nessa lista, com uma modesta melhoria de 30%, foi a execução paralela. Isso parece contraditório, já que um modelo mental para algo como a execução paralela parece intuitivamente melhor do que os resultados. Então, como fizemos para paralelizar? Talvez tenhamos cometido um erro, o teste foi 'Clarividência', a forma absolutamente perfeita de ordenação, um mecanismo que conhece a classificação e paralelização ideal antes da execução (algo na prática que já é impossível, então até os 30% são maiores do que deveriam ser).
Os VMs e blockchains são componentes muito complexos e, frequentemente, medimos pelos métricas erradas (ou nem medimos de jeito nenhum).
Então ele me perguntou: "De onde vem a velocidade da Solana então? Ou, na prática, ela não é mais rápida do que o Sonic?". A resposta é: "O Sonic é mais rápido do que a Solana, mas o Sonic não é mais rápido do que a Solana mais rápida pode ser.".
Estamos vendo uma mudança para servidores únicos poderosos; Solana, Megaeth e a grande variedade de sequenciadores individuais se inclinam em uma coisa: servidor único de alta taxa de transferência e alta memória (destes, o não L2 sempre será praticamente o mais rápido). Esta solução, se devidamente otimizada, será sempre mais rápida do que vários participantes. Assim, a taxa de transferência máxima otimizada de algo como Solana ou Megaeth seria maior do que seu próximo concorrente mais rápido que faz consenso de 2+ servidores.
Então, a próxima pergunta é, provavelmente, por que o Sonic não faz servidores eleitos por um único líder então? E a resposta aqui, não é para isso que estamos otimizando. Um dos nossos pontos de partida sobre os quais escrevi em 2018, foi que, à medida que vemos o advento de 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 do Sonic é otimizado ao ponto, onde ele já pode validar em um pi de framboesa hoje sem perder nenhum rendimento, então todos os carros podem concordar com a ordem baseada em consenso do Sonic. O Sonic é otimizado para redes mesh.
De qualquer forma, divagações aleatórias, espero que tenha ajudado de alguma forma.
Compartilhar
Conteúdo
Encaminhe o título original'Limitações de escalar blockchains e quais VMs são teoricamente as mais rápidas'
Estamos presenciando uma mudança em direção a servidores poderosos únicos; Solana, Megaeth e a ampla gama de sequenciadores únicos todos se inclinam para uma coisa: servidor único de alta capacidade de processamento e alta memória (desses, o não L2 sempre será praticamente o mais rápido).
Recentemente estive conversando com outro fundador que eu respeito muito, ele mencionou que eu deveria escrever nossa conversa.
Tudo começou com uma pergunta simples; "O Sonic paraleliza a execução de transações de alguma forma?". A resposta é não. E isso, a princípio, pode parecer uma escolha estranha, já que nos últimos 2 anos, se você esteve lendo sobre tecnologia VM, teria visto a paralelização praticamente em todos os lugares. Então, por que não estamos?
Para responder a isso, primeiro precisamos olhar como a engenharia do Sonic avalia o que devemos trabalhar, tínhamos uma tonelada de teorias, que no papel parecem práticas, que queríamos implementar, mas recursos físicos limitados da equipe, então como escolher qual é a mais impactante? Então, em vez de trabalhar em QUALQUER uma dessas ideias, a equipe decidiu passar um ano para construir Aida, Aida é uma ferramenta incrivelmente poderosa que nos permite reproduzir blockchains inteiros (qualquer) em minutos, em vez de meses, com métricas de desempenho úteis. Isso significa que poderíamos prototipar, testar em Aida e saber muito rapidamente quais teorias se sustentam e quais não.
Aida também nos permite fazer alguns perfis bastante poderosos, o que leva a saídas como;
Portanto, com o que foi dito acima, poderíamos testar muito rapidamente e com precisão nossas suposições de throughput, então partimos para comparar puramente na memória VM vs disco, execução paralela, RDMS vs KV vs arquivo plano, conjuntos, novos modelos de consenso e mais
A maior melhoria única foi o DB, um aumento de 800%, em seguida, supersets, seguido de consenso, e muito baixo nessa lista, com uma modesta melhoria de 30%, foi a execução paralela. Isso parece contraditório, já que um modelo mental para algo como a execução paralela parece intuitivamente melhor do que os resultados. Então, como fizemos para paralelizar? Talvez tenhamos cometido um erro, o teste foi 'Clarividência', a forma absolutamente perfeita de ordenação, um mecanismo que conhece a classificação e paralelização ideal antes da execução (algo na prática que já é impossível, então até os 30% são maiores do que deveriam ser).
Os VMs e blockchains são componentes muito complexos e, frequentemente, medimos pelos métricas erradas (ou nem medimos de jeito nenhum).
Então ele me perguntou: "De onde vem a velocidade da Solana então? Ou, na prática, ela não é mais rápida do que o Sonic?". A resposta é: "O Sonic é mais rápido do que a Solana, mas o Sonic não é mais rápido do que a Solana mais rápida pode ser.".
Estamos vendo uma mudança para servidores únicos poderosos; Solana, Megaeth e a grande variedade de sequenciadores individuais se inclinam em uma coisa: servidor único de alta taxa de transferência e alta memória (destes, o não L2 sempre será praticamente o mais rápido). Esta solução, se devidamente otimizada, será sempre mais rápida do que vários participantes. Assim, a taxa de transferência máxima otimizada de algo como Solana ou Megaeth seria maior do que seu próximo concorrente mais rápido que faz consenso de 2+ servidores.
Então, a próxima pergunta é, provavelmente, por que o Sonic não faz servidores eleitos por um único líder então? E a resposta aqui, não é para isso que estamos otimizando. Um dos nossos pontos de partida sobre os quais escrevi em 2018, foi que, à medida que vemos o advento de 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 do Sonic é otimizado ao ponto, onde ele já pode validar em um pi de framboesa hoje sem perder nenhum rendimento, então todos os carros podem concordar com a ordem baseada em consenso do Sonic. O Sonic é otimizado para redes mesh.
De qualquer forma, divagações aleatórias, espero que tenha ajudado de alguma forma.