Fases de desenvolvimento e eras no Cardano

Esta visão geral é baseada em CIP-59.

O desenvolvimento do Cardano segue uma roadmap bem definida e claramente comunicada. Firmemente baseado em pesquisa acadêmica e testes rigorosos, esse processo resultou em uma cadeia sem interrupções.

O Cardano passou por múltiplas fases de desenvolvimento e eras habilitadas por eventos de combinador de bifurcação rígida. Os seguintes conceitos são explicados abaixo:

• Fase de desenvolvimento – uma coleção de recursos descritos no roadmap do Cardano.
• Era do Ledger – uma coleção de recursos do ledger introduzidos com uma bifurcação rígida. Começando com Alonzo, as eras são planejadas para serem nomeadas após matemáticos e cientistas da computação em ordem a, b, c.
• Bifurcação rígida intra-era – uma mudança semântica pequena e focada no ledger que requer uma bifurcação rígida.
• Mecanismo de consenso – uma coleção de recursos de consenso introduzidos com uma bifurcação rígida. Historicamente, estes têm o nome de 'Ouroboros'.
• Protocolo do Ledger – uma coleção de recursos do ledger entre a camada de consenso e a camada do ledger, caracterizada aproximadamente pela validação do cabeçalho do bloco.

Fases de desenvolvimento

As fases de desenvolvimento do Cardano incluem Byron, Shelley, Goguen, Basho e Voltaire – todas nomeadas após poetas exceto Goguen, um cientista da computação.

Byron focou no estabelecimento da fundação, Shelley na descentralização. Goguen introduziu contratos inteligentes e suporte a ativos nativos, Basho - aprimoramentos de escalabilidade, e, finalmente, Voltaire trata de governança descentralizada e tomada de decisão.

Veja aqui uma visão geral das fases de desenvolvimento do Cardano.

Eras do Ledger

Existem várias eras dentro da evolução do Cardano. Cada era refere-se às regras do ledger. Por exemplo, que tipos de transações e quais dados são armazenados no ledger, ou a validade e o significado das transações.

Eras Byron e Shelley

A evolução da mainnet do Cardano começou com as regras do ledger de Byron. A mainnet passou por uma bifurcação rígida no final de julho de 2020 para mudar das regras de Byron para as regras do ledger de Shelley. Foi uma reimplementação completa do Cardano, que permitiu duas mudanças fundamentais: o suporte para múltiplos conjuntos de regras do ledger e o gerenciamento do processo de bifurcação rígida de mudança de um conjunto de regras para o próximo. Em outras palavras, a nova implementação poderia suportar tanto as regras de Byron quanto as regras de Shelley, o que significava que, quando implantada na mainnet no início de 2020, a implementação era totalmente compatível com as regras de Byron. Isso permitiu uma transição suave da implementação antiga para a nova. Uma vez que todos os usuários do Cardano atualizaram seus nós para a nova implementação, tornou-se possível invocar o evento de combinador de bifurcação rígida e mudar para as regras de Shelley.

Eras Allegra, Mary e Alonzo

Allegra, Mary e Alonzo são todas parte da fase de desenvolvimento Goguen.

Começando com Goguen, a equipe do ledger introduziu a noção de era no código do ledger. As regras do ledger de Shelley então se tornaram ‘a era Shelley’.

Porque os recursos de Goguen foram implementados em etapas, cada conjunto de funcionalidades foi introduzido com uma bifurcação rígida diferente, portanto, houve várias eras do ledger:

• Allegra: introduziu suporte a bloqueio de tokens
• Mary: trouxe tokens nativos e funcionalidade multi-ativos para o Cardano
• Alonzo: introduziu suporte a contratos inteligentes

Os nomes Allegra e Mary foram escolhidos por sua conexão com o poeta Percy Shelley e só foram destinados a serem usados como nomes de variáveis para uma abstração muito específica usada no código do ledger.

Goguen, a fase de desenvolvimento de contratos inteligentes, foi a única fase nomeada não após um poeta. Portanto, o nome da era do ledger que introduziu contratos inteligentes foi nomeado após Alonzo Church - a pessoa que inventou o cálculo lambda (Plutus Core usa uma variante de sistema F).

No futuro, as equipes decidiram usar nomes em ordem a, b, c, após indivíduos que contribuíram para a matemática e ciência da computação. Uma falta de consistência a ser observada é que as eras podem usar tanto nomes próprios quanto sobrenomes. Isso é motivado pela concisão.

Era Babbage

A era do ledger de Babbage introduziu recursos como dados inline, scripts de referência e inputs de referência. No entanto, o lançamento também é conhecido como Vasil, nomeado em homenagem ao falecido matemático búlgaro e embaixador do Cardano Vasil Dabov.

Bifurcações rígidas intra-era

Uma nova era deve ser introduzida com uma bifurcação rígida, mas o ledger também pode mudar a semântica durante uma bifurcação rígida controlada com outro mecanismo - uma bifurcação rígida intra-era. Este é um detalhe de implementação que envolve aumentar a versão do protocolo principal, mas não criar uma nova era do ledger. A era de Alonzo, por exemplo, experimentou uma bifurcação rígida intra-era ao passar da versão principal do protocolo 5 para 6.

Você pode ver uma tabela com as fases, eras e bifurcações rígidas intra-era do Cardano visualizadas abaixo:

Fonte da imagem: Anexo de recursos do CIP-59 do Cardano

Conclusão

É importante entender que nem todas as mudanças semânticas na rede Cardano envolvem o ledger. Mudanças no protocolo de consenso ou na camada de rede também podem exigir uma bifurcação rígida. Também há uma abstração entre as camadas de consenso e ledger, chamada protocolo. A distinção entre os protocolos do ledger e as eras do ledger corresponde aproximadamente a como os cabeçalhos dos blocos são validados (protocolo) versus como os corpos dos blocos são validados (era). A era de Shelley usou o protocolo 'Praos transitório' (TPraos), que consistia em Praos combinado com um sistema de transição para se afastar de Ouroboros BFT. A era de Babbage substituiu TPraos por Praos.

Observe que a versão do protocolo não está relacionada às versões do protocolo de nó para nó e de nó para cliente. A camada de consenso mantém um esquema de versionamento para as consultas do nó que não necessariamente se alinha com a versão do protocolo descrita nesta visão geral.

A versão do protocolo também está incluída em cada cabeçalho de bloco, indicando a versão máxima do protocolo que o produtor de bloco é capaz de suportar.