Agradecimentos especiais a Dankrad Feist e Aditya Asgaonkar pela revisão Sharding é o futuro da escalabilidade do Ethereum e será fundamental para ajudar o ecossistema a suportar muitos milhares de transações por segundo e permitir que grandes partes do mundo usem regularmente a plataforma a um custo acessível. No entanto, também é um dos conceitos mais incompreendidos no ecossistema Ethereum e nos ecossistemas blockchain de forma mais ampla. Refere-se a um conjunto muito específico de ideias com propriedades muito específicas, mas muitas vezes é confundido com técnicas que têm propriedades de segurança muito diferentes e muitas vezes muito mais fracas. O objetivo desta postagem será explicar exatamente quais propriedades específicas o sharding fornece, como ele difere de outras tecnologias que são sharding e quais sacrifícios um sistema sharded precisa fazer para alcançar essas propriedades. não O Trilema da Escalabilidade A melhor maneira de descrever o sharding começa com a declaração do problema que moldou e inspirou a solução: . o Trilema da Escalabilidade O trilema da escalabilidade diz que existem três propriedades que um blockchain tenta ter e que, . As três propriedades são: se você se ater a técnicas "simples", poderá obter apenas duas dessas três : a cadeia pode processar mais transações do que um único nó regular (pense: um laptop de consumidor) pode verificar. Escalabilidade : a cadeia pode ser executada sem nenhuma dependência de confiança em um pequeno grupo de grandes atores centralizados. Isso normalmente é interpretado como significando que não deve haver nenhuma confiança (ou mesmo suposição de maioria honesta) de um conjunto de nós que você não pode unir apenas com um laptop de consumidor. Descentralização : a cadeia pode resistir a uma grande porcentagem de nós participantes tentando atacá-la (idealmente 50%; qualquer coisa acima de 25% está bem, 5% definitivamente está bem). Segurança não Agora podemos olhar para as três classes de "soluções fáceis" que obtêm apenas duas das três: - incluindo Bitcoin, pré-PoS/sharding Ethereum, Litecoin e outras cadeias semelhantes. Eles dependem de cada participante executando um nó completo que verifica todas as transações e, portanto, têm descentralização e segurança, mas não escalabilidade. Blockchains tradicionais - incluindo a família DPoS, mas também muitas outras. Estes contam com um pequeno número de nós (geralmente 10-100) mantendo o consenso entre si, com os usuários tendo que confiar na maioria desses nós. Isso é escalável e seguro (usando as definições acima), mas não é descentralizado. Cadeias de alto TPS - refere-se ao conceito geral de "dimensionamento" por ter diferentes aplicativos ativos em diferentes cadeias e usar protocolos de comunicação entre cadeias para conversar entre eles. Isso é descentralizado e escalável, mas não é seguro, porque um invasor precisa apenas obter uma maioria de nós de consenso em uma das muitas cadeias (frequentemente <1% de todo o ecossistema) para quebrar essa cadeia e possivelmente causar efeitos de ondulação que causam grandes prejuízos para aplicações em outras cadeias. Ecossistemas de várias cadeias Uma blockchain fragmentada é: Sharding é uma técnica que permite obter todos os três. : pode processar muito mais transações do que um único nó Escalável : pode sobreviver inteiramente em laptops de consumo, sem qualquer dependência de "supernós" Descentralizado : um invasor não pode atingir uma pequena parte do sistema com um pequeno número de recursos; eles só podem tentar dominar e atacar a coisa toda Seguro O restante da postagem descreverá como os blockchains fragmentados conseguem fazer isso. Fragmentação por meio de amostragem aleatória A versão de fragmentação mais fácil de entender é a fragmentação por meio de amostragem aleatória. A fragmentação por meio de amostragem aleatória tem propriedades de confiança mais fracas do que as formas de fragmentação que estamos construindo no ecossistema Ethereum, mas usa uma tecnologia mais simples. A ideia central é a seguinte. Suponha que você tenha uma proof of stake chain com um grande número (por exemplo, 10.000) validadores e um grande número (por exemplo, 100) blocos que precisam ser verificados. Nenhum computador é poderoso o suficiente para validar esses blocos antes que o próximo conjunto de blocos chegue. todos Portanto, o que fazemos é . Embaralhamos aleatoriamente a lista de validadores e atribuímos os primeiros 100 validadores na lista embaralhada para verificar o primeiro bloco, os segundos 100 validadores na lista embaralhada para verificar o segundo bloco etc. verificar um bloco (ou executar alguma outra tarefa) é chamado de . dividir aleatoriamente o trabalho de fazer a verificação comitê Quando um validador verifica um bloco, ele publica uma assinatura atestando o fato de que o fez. Todos os outros, em vez de verificar 100 blocos inteiros, agora verificam apenas 10.000 assinaturas - uma quantidade muito menor de trabalho, especialmente com . Em vez de todos os blocos serem transmitidos pela mesma rede P2P, cada bloco é transmitido em uma sub-rede diferente, e os nós precisam apenas ingressar nas sub-redes correspondentes aos blocos pelos quais são responsáveis (ou têm interesse por outros motivos). agregação de assinatura BLS Considere o que acontece se o poder de computação de cada nó aumentar em 2x. Como cada nó agora pode validar com segurança 2x mais assinaturas, você pode reduzir o tamanho mínimo do depósito para suportar 2x mais validadores e, portanto, pode fazer 200 comitês em vez de 100. Portanto, você pode verificar 200 blocos por slot em vez de 100. Além disso, pode ser 2x maior. Assim, você tem 2x mais blocos de 2x o tamanho, ou 4x mais capacidade de corrente. cada bloco individual Podemos introduzir alguma linguagem matemática para falar sobre o que está acontecendo. Usando a , usamos " " para nos referirmos à capacidade computacional de um único nó. Uma blockchain tradicional pode processar blocos de tamanho . Uma cadeia fragmentada conforme descrita acima pode processar blocos em paralelo (lembre-se, o custo para cada nó para verificar cada bloco indiretamente é porque cada nó só precisa verificar um número fixo de assinaturas) e cada bloco tem capacidade e, portanto, a capacidade total da cadeia fragmentada é . É por isso que chamamos esse tipo de sharding , e esse efeito é uma das principais razões pelas quais pensamos que, a longo prazo, o sharding é a melhor maneira de dimensionar um blockchain. notação Big O O(C) O(C) O(C) O(1) O(C) O(C2) quadrático sharding Pergunta frequente: Qual a diferença entre a divisão em 100 comitês e a divisão em 100 cadeias separadas? Existem duas diferenças fundamentais: . Em um ecossistema multichain de 100 cadeias, o invasor precisa apenas de aproximadamente 0,5% da participação total para causar estragos: eles podem se concentrar em 51% atacando uma única cadeia. Em uma blockchain fragmentada, o invasor deve ter cerca de ~30-40% de a participação para fazer o mesmo (em outras palavras, a cadeia tem ). Certamente, eles podem esperar até ter sorte e obter 51% em um único fragmento por acaso, apesar de terem menos de 50% da aposta total, mas isso fica exponencialmente mais difícil para os invasores que têm muito menos que 51%. Se um invasor tiver menos de ~30%, é praticamente impossível. A amostragem aleatória impede que o invasor concentre seu poder em um fragmento toda segurança compartilhada Existe um contrato social (e em seções posteriores deste documento descrevemos algumas maneiras de impor isso tecnologicamente) que uma cadeia com até mesmo um bloco defeituoso em até mesmo um shard não é aceitável e deve ser descartada assim que for descoberta. Isso garante que, do ponto de vista de uma aplicação da cadeia, haja uma segurança perfeita: o contrato A pode contar com o contrato B, porque se o contrato B se comportar mal devido a um ataque à cadeia, todo esse histórico é revertido, incluindo as transações em contrato A que se comportou mal como resultado do mau funcionamento do contrato B. Acoplamento estreito: se até mesmo um fragmento obtiver um bloco defeituoso, toda a cadeia se reorganizará para evitá-lo. dentro Essas duas diferenças garantem que o sharding crie um ambiente para aplicativos que preserva as principais propriedades de segurança de um ambiente de cadeia única, de uma forma que os ecossistemas de várias cadeias fundamentalmente não fazem. Melhorando o sharding com melhores modelos de segurança Um refrão comum nos círculos de Bitcoin, e com o qual concordo totalmente, é que . Se houver um ataque de 51% em tal blockchain, o invasor pode fazer coisas desagradáveis, como reverter ou censurar transações, mas não pode inserir transações inválidas. E mesmo que revertam ou censurem transações, os usuários que executam nós regulares podem facilmente detectar esse comportamento, portanto, se a comunidade deseja se coordenar para resolver o ataque com uma bifurcação que tira o poder do invasor, eles podem fazer isso rapidamente. blockchains como Bitcoin (ou Ethereum) NÃO dependem completamente de uma suposição de maioria honesta algumas . Essas cadeias não têm e não podem ter uma cultura de usuários regulares executando nós e, portanto, os principais nós e participantes do ecossistema podem se reunir com muito mais facilidade e impor uma mudança de protocolo que a comunidade não gosta. Pior ainda, os nós dos usuários aceitariam por padrão. Depois de algum tempo, os usuários notariam, mas a essa altura a mudança forçada de protocolo seria um fato consumado: para rejeitar a mudança e eles teriam que tomar a dolorosa decisão de reverter o valor de um dia ou mais de atividade que todos pensavam que já estava finalizada. A falta dessa segurança extra é um ponto fraco das cadeias de alto TPS mais centralizadas o ônus da coordenação recairia sobre os usuários Idealmente, queremos ter uma forma de sharding que evite suposições de confiança de 51% para validade e preserve o poderoso baluarte de segurança que os blockchains tradicionais obtêm da verificação completa. E é exatamente disso que trata grande parte de nossa pesquisa nos últimos anos. Verificação Escalável de Computação Podemos dividir o problema de validação escalável à prova de ataque de 51% em dois casos: : verifica se alguma computação foi feita corretamente, assumindo que você possui todas as entradas para a computação. Computação de validação : verificando se as entradas para o próprio cálculo estão armazenadas de alguma forma onde você possa baixá-las se realmente precisar; essa verificação deve ser realizada realmente baixar as próprias entradas inteiras (porque os dados podem ser muito grandes para serem baixados para cada bloco). Validando a disponibilidade de dados sem Validar um bloco em um blockchain envolve computação e verificação de disponibilidade de dados: você precisa estar convencido de que as transações no bloco são válidas e que o novo hash raiz de estado reivindicado no bloco é o resultado correto da execução dessas transações, mas você também precisam ser convencidos de que dados suficientes do bloco foram realmente publicados para que os usuários que baixam esses dados possam calcular o estado e continuar processando o blockchain. Esta segunda parte é um conceito muito sutil, mas importante, chamado ; mais sobre isso mais tarde. de problema de disponibilidade de dados A validação escalável da computação é relativamente fácil; existem duas famílias de técnicas: e . provas de fraude ZK-SNARKs As duas tecnologias podem ser descritas simplesmente da seguinte forma: As são um sistema onde, para aceitar o resultado de um cálculo, você exige que alguém com um apostado assine uma mensagem do formulário "Certifico que se você fizer o cálculo com a entrada , obterá a saída ". Você confia nessas mensagens por padrão, mas deixa em aberto a oportunidade para outra pessoa com um depósito apostado fazer um (uma mensagem assinada dizendo "Discordo, a saída é Z"). Somente quando há um desafio, todos os nós executam a computação. Qualquer uma das duas partes que estiver errada perde seu depósito e todos os cálculos que dependem do resultado desse cálculo são recalculados. provas de fraude depósito C X Y desafio são uma forma de prova que prova diretamente a afirmação "realizar computação na entrada dá saída ". A prova é criptograficamente "sólida": se não igual a , é computacionalmente inviável fazer uma prova válida. A prova também é rápida de verificar, mesmo que a própria execução do leve muito tempo. Veja para mais detalhes matemáticos sobre ZK-SNARKs. ZK-SNARKs criptográfica C X Y C(x) for Y C este post A computação baseada em provas de fraude é escalável porque "no caso normal" você substitui a execução de uma computação complexa pela verificação de uma única assinatura. Existe o caso excepcional, em que você precisa verificar o cálculo na cadeia porque há um desafio, mas o caso excepcional é muito raro porque acioná-lo é muito caro (o reclamante original ou o desafiante perde um grande depósito). Os ZK-SNARKs são conceitualmente mais simples - eles apenas substituem um cálculo por uma verificação de prova muito mais barata - mas a matemática por trás de como eles funcionam é consideravelmente mais complexa. Existe uma classe de sistema semi-escalável que verifica a computação de forma escalável, embora ainda exija que cada nó verifique todos os dados. Isso pode ser bastante eficaz usando um conjunto de truques de compactação para substituir a maioria dos dados por computação. Este é o reino dos . apenas rollups A verificação escalável da disponibilidade de dados é mais difícil Uma prova de fraude não pode ser usada para verificar a disponibilidade de dados. As provas de fraude para dependem do fato de que as entradas para a computação são publicadas na cadeia no momento em que a reivindicação original é enviada e, portanto, se alguém desafiar, a execução do desafio está acontecendo exatamente no mesmo "ambiente" em que a execução original foi acontecendo. No caso de verificar a disponibilidade de dados, você não pode fazer isso, porque o problema é justamente o fato de haver muitos dados para verificar para publicar na cadeia. Portanto, um esquema à prova de fraude para disponibilidade de dados enfrenta um problema-chave: alguém pode alegar que "os dados X estão disponíveis" sem publicá-los, esperar para ser questionado e só publicar os dados X e fazer o desafiante aparecer para o resto do mundo. rede está incorreta. computação então Isso é expandido no : dilema do pescador A ideia central é que os dois "mundos", um em que V1 é um editor malvado e V2 é um desafiante honesto e o outro onde V1 é um editor honesto e V2 é um desafiante malvado, são indistinguíveis para qualquer um que não esteja tentando baixar aquele dado específico no momento. E, claro, em um blockchain descentralizado escalável, cada nodo individual só pode esperar baixar uma pequena parte dos dados, então apenas uma pequena parte dos nodos veria algo sobre o que aconteceu, exceto pelo mero fato de que houve um desacordo. O fato de ser impossível distinguir quem estava certo e quem estava errado torna impossível ter um esquema à prova de fraude para disponibilidade de dados. Pergunta frequente: e se alguns dados estiverem indisponíveis? Com um ZK-SNARK você pode ter certeza de que tudo é , e isso não é suficiente? válido Infelizmente, a mera validade não é suficiente para garantir uma blockchain funcionando corretamente. Isso ocorre porque, se o blockchain for , mas todos os dados não , os usuários não terão como atualizar os dados necessários para gerar provas de que qualquer bloco é válido. Um invasor que gera um bloco válido, mas indisponível, mas depois desaparece, pode efetivamente interromper a cadeia. Alguém também pode reter os dados da conta de um usuário específico até que o usuário pague um resgate, portanto, o problema não é apenas uma questão de vivacidade. válido estiverem disponíveis futuro Existem alguns fortes argumentos teóricos da informação de que esse problema é fundamental, e não há nenhum truque inteligente (por exemplo, envolvendo ) que possa contorná-lo. Consulte para obter detalhes. acumuladores criptográficos este documento Então, como você verifica se 1 MB de dados está disponível sem realmente tentar baixá-lo? Isso parece impossível! A chave é uma tecnologia chamada . A amostragem de disponibilidade de dados funciona da seguinte maneira: amostragem de disponibilidade de dados Use uma ferramenta chamada para expandir um pedaço de dados com N pedaços em um pedaço de dados com 2N pedaços de forma que desses pedaços possa recuperar os dados inteiros. codificação de eliminação qualquer N Para verificar a disponibilidade, em vez de tentar baixar os dados, os usuários simplesmente (por exemplo, 30 posições) e aceitam o bloco somente quando encontram com sucesso os pedaços no bloco de suas posições selecionadas. todos selecionam aleatoriamente um número constante de posições no bloco . Os códigos de eliminação transformam um problema de "verificação de 100% de disponibilidade" (todos os dados estão disponíveis) em um problema de "verificação de 50% de disponibilidade" (pelo menos metade dos dados estão disponíveis). A amostragem aleatória resolve o problema de disponibilidade de 50%. Se menos de 50% dos dados estiverem disponíveis, pelo menos uma das verificações quase certamente falhará e, se pelo menos 50% dos dados estiverem disponíveis, embora alguns nós possam não reconhecer um bloco como disponível, é necessário apenas um nó honesto para executar o procedimento de reconstrução do código de eliminação para trazer de volta os 50% restantes do bloco. E assim, ao invés de precisar baixar 1 MB para verificar a disponibilidade de um bloco de 1 MB, basta baixar alguns kilobytes. Isso torna possível executar a verificação de disponibilidade de dados em bloco. Veja para saber como essa verificação pode ser implementada com eficiência com sub-redes ponto a ponto. cada esta postagem Um ZK-SNARK pode ser usado para verificar se a codificação de apagamento em uma parte dos dados foi feita e, em seguida, as ramificações do Merkle podem ser usadas para verificar partes individuais. Como alternativa, você pode usar (por exemplo, compromissos ), que essencialmente fazem codificação de apagamento comprovam elementos individuais verificação de correção em um componente simples - e é isso que o sharding Ethereum está usando. corretamente compromissos polinomiais Kate (também conhecido como KZG) e e Recapitulação: Como estamos garantindo que tudo esteja correto novamente? Suponha que você tenha 100 blocos e queira verificar com eficiência a exatidão de todos eles sem depender de comitês. Precisamos fazer o seguinte: Cada cliente executa em cada bloco, verificando se os dados em cada bloco estão disponíveis, enquanto baixa apenas alguns kilobytes por bloco, mesmo que o bloco como um todo tenha um megabyte ou mais. Um cliente só aceita um bloqueio quando todos os dados de seus desafios de disponibilidade foram respondidos corretamente. amostragem de disponibilidade de dados Agora que verificamos a disponibilidade dos dados, fica mais fácil verificar a exatidão. Existem duas técnicas: Podemos usar : alguns participantes com depósitos apostados podem assinar a correção de cada bloco. Outros nós, chamados (ou ) verificam aleatoriamente e tentam processar completamente os blocos. Como já verificamos a disponibilidade de dados, sempre será possível baixar os dados e processar totalmente qualquer bloco específico. Se encontrarem um bloco inválido, eles postam um que todos verificam. Se o bloco for ruim, então esse bloco e todos os blocos futuros que dependem dele precisam ser recalculados. provas de fraude desafiantes pescadores desafio Podemos usar . Cada bloco viria com um ZK-SNARK comprovando a exatidão. ZK-SNARKs Em qualquer um dos casos acima, cada cliente só precisa fazer uma pequena quantidade de trabalho de verificação por bloco, independentemente do tamanho do bloco. No caso de provas de fraude, ocasionalmente os blocos precisarão ser totalmente verificados na cadeia, mas isso deve ser extremamente raro porque acionar até mesmo um desafio é muito caro. E isso é tudo! No caso de fragmentação do Ethereum, o plano de curto prazo é tornar os blocos fragmentados ; ou seja, os fragmentos são um "mecanismo de disponibilidade de dados" e é o trabalho dos usar esse espaço de dados seguro, além de provas de fraude ou ZK-SNARKs, para implementar recursos de processamento de transações seguras de alto rendimento. No entanto, é totalmente possível criar um sistema integrado para adicionar execução "nativa" de alto rendimento. apenas para dados puramente rollups de camada 2 Quais são as principais propriedades dos sistemas fragmentados e quais são as vantagens e desvantagens? O principal objetivo do sharding é chegar o mais próximo possível da replicação das propriedades de segurança mais importantes dos blockchains tradicionais (não sharded), mas sem a necessidade de cada nó verificar pessoalmente cada transação. A fragmentação chega bem perto. Em um blockchain tradicional: porque os nós de validação notam que são inválidos e os ignoram. Os blocos inválidos não podem passar porque os nós de validação falham ao baixá-los e os ignoram. Os blocos indisponíveis não podem passar Em um blockchain fragmentado com recursos avançados de segurança: porque: Blocos inválidos não podem passar Uma prova de fraude rapidamente os pega e informa toda a rede sobre a incorreção do bloqueio, e penaliza fortemente o criador, ou Um ZK-SNARK prova a correção e você não pode criar um ZK-SNARK válido para um bloco inválido. porque: Blocos indisponíveis não podem passar Se menos de 50% dos dados de um bloco estiverem disponíveis, pelo menos uma verificação de amostra de disponibilidade de dados quase certamente falhará para cada cliente, fazendo com que o cliente rejeite o bloco, Se pelo menos 50% dos dados de um bloco estiverem disponíveis, na verdade o bloco inteiro estará disponível, porque é necessário apenas um único nó honesto para reconstruir o restante do bloco. As correntes tradicionais de alto TPS sem sharding não têm como fornecer essas garantias. Os ecossistemas multichain não têm como evitar o problema de um invasor selecionar uma cadeia para ataque e facilmente assumi-la (as cadeias compartilhar a segurança, mas se isso for mal feito, ela se transformará em uma cadeia tradicional de alto TPS com todas as suas desvantagens, e se fosse bem feito, seria apenas uma implementação mais complicada das técnicas de sharding acima). podem As são altamente dependentes de implementação, mas são tipicamente vulneráveis às fraquezas das cadeias tradicionais de alto TPS (isto é, se elas compartilham mineradores/validadores) ou às fraquezas dos ecossistemas multicadeias (isto é, se elas não compartilham mineradores/validadores ). Cadeias fragmentadas evitam esses problemas. sidechains . Notavelmente: No entanto, existem algumas brechas na armadura do sistema fragmentado . Ou seja, se o adversário tiver a capacidade de invadir (ou apenas desligar) qualquer conjunto de nós de sua escolha em tempo real, ele precisará atacar apenas um pequeno número de nós para quebrar um único comitê. Além disso, se um adversário (seja um adversário adaptativo ou apenas um atacante com 50% da aposta total) quebrar um único comitê, apenas alguns de seus nós (os que estão naquele comitê) podem ser confirmados publicamente como participantes desse comitê. ataque, e assim apenas uma pequena quantidade de aposta pode ser penalizada. Esta é outra razão chave pela qual a amostragem de disponibilidade de dados junto com provas de fraude ou ZK-SNARKs são um complemento importante para as técnicas de amostragem aleatória. Cadeias fragmentadas que dependem de comitês são vulneráveis a adversários adaptativos e têm responsabilidade mais fraca apenas que, coletivamente, façam solicitações de amostragem de disponibilidade de dados suficientes para que as respostas quase sempre se sobreponham para abranger pelo menos 50% do bloco. Na prática, isso significa que (e esse número aumenta quanto maior for a relação entre a capacidade do sistema e a capacidade de um único nó). Este é um - geralmente bastante confiável, mas certamente não tão robusto quanto a confiança de 0 de N que os nós em cadeias não fragmentadas têm para disponibilidade. A amostragem de disponibilidade de dados só é segura se houver um número suficiente de clientes on-line deve haver algumas centenas de clientes online modelo de confiança de alguns de N ; se a rede for muito lenta, os nós podem aceitar um bloco como finalizado antes que a prova de fraude apareça, mostrando que está errado. Felizmente, se você seguir uma regra estrita de reverter todos os bloqueios inválidos assim que a invalidez for descoberta, esse limite é um parâmetro definido pelo usuário: cada usuário individual escolhe quanto tempo espera até a finalização e, se não quiser, sofre, mas usuários mais cuidadosos estão seguros. Mesmo assim, isso é um enfraquecimento da experiência do usuário. Se a cadeia fragmentada depende de provas de fraude, ela depende de suposições de tempo Usar ZK-SNARKs para verificar a validade resolve isso. , aumentando o risco de falhas em condições extremas de rede. Pequenas quantidades de dados são mais fáceis de enviar (e mais fáceis de , se um governo poderoso tentar censurar a cadeia) do que grandes quantidades de dados. Os exploradores de blocos precisam armazenar mais dados se quiserem manter toda a cadeia. Há uma quantidade muito maior de dados brutos que precisam ser repassados esconder com segurança Blockchains fragmentados dependem de redes ponto a ponto fragmentadas, e . O atenua isso porque há alguma redundância entre as sub-redes, mas mesmo assim há um risco. cada "sub-rede" p2p individual é mais fácil de atacar porque possui menos nós modelo de sub-rede usado para amostragem de disponibilidade de dados Essas são preocupações válidas, embora, em nossa opinião, sejam superadas em muito pela permitindo que mais aplicativos sejam executados na cadeia em vez de por meio de serviços centralizados da camada 2. Dito isso, essas preocupações, especialmente as duas últimas, são, na prática, a verdadeira restrição ao aumento do throughput de uma cadeia fragmentada além de um certo ponto. Há um limite para a quadraticidade da fragmentação quadrática. redução na centralização no nível do usuário, A propósito, os crescentes riscos de segurança de blockchains fragmentados se sua taxa de transferência se tornar muito alta também são a principal razão pela qual o esforço para estender a foi amplamente abandonado; parece que manter a fragmentação quadrática quadrática é realmente o meio termo. fragmentação superquadrática apenas Por que não produção centralizada e verificação fragmentada? Uma alternativa à fragmentação frequentemente proposta é ter uma cadeia estruturada como uma cadeia de alto TPS centralizada, exceto que usa amostragem de disponibilidade de dados e fragmentação na parte superior para permitir a verificação da validade e disponibilidade. Isso melhora as cadeias de alto TPS centralizadas como existem hoje, mas ainda é consideravelmente mais fraca do que um sistema fragmentado. Isso ocorre por alguns motivos: . A detecção de censura requer (i) ser capaz de ver transações e verificar se não há transações que claramente mereçam entrar e que inexplicavelmente não consigam entrar, ou (ii) ter um modelo de confiança 1 de N em e verificar se nenhum bloco falha ao entrar. Em uma cadeia centralizada de alto TPS, (i) é impossível e (ii) é mais difícil porque a pequena contagem de nós torna até mesmo um modelo de confiança de 1 de N mais propenso a quebrar e se a cadeia tiver um tempo de bloqueio muito rápido para DAS (como a maioria das cadeias de alto TPS centralizadas), é muito difícil provar que os blocos de um nó não estão sendo rejeitados simplesmente porque estão sendo publicados muito lentamente. É muito mais difícil detectar a censura dos produtores de blocos em uma cadeia de alto TPS todas as produtores de bloco Se a maioria dos produtores de blocos e membros do ecossistema tentar forçar uma mudança de protocolo impopular, os clientes dos usuários certamente a , mas porque eles precisariam criar um novo conjunto de nós caros de alto rendimento para manter uma cadeia que mantém as regras antigas. detectarão é muito mais difícil para a comunidade se rebelar e se separar . O alto rendimento dos nós produtores de blocos os torna muito detectáveis e fáceis de desligar. Também é politicamente e logisticamente mais fácil censurar a computação dedicada de alto desempenho do que perseguir os laptops de usuários individuais. A infra-estrutura centralizada é mais vulnerável à censura imposta por atores externos , aumentando o risco de que toda a cadeia seja executada nos serviços de nuvem de 1 a 3 empresas e, portanto, o risco de a cadeia cair devido à falha simultânea de muitos produtores de bloco . Uma cadeia fragmentada com uma cultura de execução de validadores no próprio hardware é novamente muito menos vulnerável a isso. Há uma pressão mais forte para que a computação de alto desempenho mude para serviços de nuvem centralizados Sistemas devidamente fragmentados são melhores como uma camada de base. Dada uma camada base fragmentada, você sempre pode criar um sistema de produção centralizado (por exemplo, porque você deseja um domínio de alto rendimento com capacidade de ) em camadas no topo, construindo-o como um rollup. Mas se você tiver uma camada base com dependência da produção de blocos centralizados, não poderá criar uma camada 2 mais descentralizada no topo. composição síncrona para defi Também publicado . aqui
