Sequenciadores compartilhados para cadeias de aplicativos Starknet e Madara

Introdução

Hoje, já estamos vendo projetos começando a experimentar Madara em suas cadeias de aplicativos. Pragma, Kakarot, Mangata Finance e Dojo são apenas alguns exemplos. Enquanto acreditarmos no futuro multi-chain e no poder do escalonamento zk, veremos muito mais desses projetos no futuro. No entanto, o número crescente de cadeias de aplicativos também levanta questões em torno

1. Descentralização
2. Composição
3. Experiência de desenvolvimento

Neste post tentarei explicar os problemas que surgem por ter muitas cadeias de aplicativos e também apresentar uma possível solução para o problema que considero elegante e ideal para Madara e Starknet. Se você já está familiarizado com cadeias de aplicativos e sequenciamento compartilhado, sinta-se à vontade para pular para a seção “Espere, é apenas Polkadot de novo”.

O que acontece em 100 cadeias de aplicativos?

Digamos que estamos em um futuro onde agora temos 100 cadeias de aplicativos diferentes instaladas no Ethereum. Vamos abordar todos os problemas que isso causará.

Descentralização fragmentada

Cada cadeia de aplicativos precisará resolver a descentralização por conta própria. Agora, a descentralização das cadeias de aplicativos não é tão necessária quanto a dos L1s, principalmente porque dependemos dos L1s para segurança. No entanto, ainda precisamos de descentralização para garantir a vivacidade, a resistência à censura e para evitar vantagens monopolísticas (taxas elevadas, por exemplo). No entanto, também é importante observar que se cada cadeia de aplicativos resolver a descentralização à sua maneira, isso levará muito rapidamente à fragmentação dos conjuntos de validadores. Cada cadeia de aplicações teria de desenvolver incentivos económicos para integrar novos validadores. Além disso, os validadores precisariam selecionar quais clientes eles se sentem confortáveis em executar. Sem mencionar a enorme barreira de entrada que isso cria para os desenvolvedores lançarem suas próprias cadeias de aplicativos (em vez de implantar um contrato inteligente que é apenas uma transação).

Composição

Composibilidade significa essencialmente interação entre aplicativos. No Ethereum ou Starknet, isso significa apenas chamar outro contrato e todo o resto é tratado pelo próprio protocolo. No entanto, com cadeias de aplicativos, isso se torna muito mais difícil. Diferentes cadeias de aplicativos têm seus próprios blocos e mecanismos de consenso. Cada vez que você tenta interagir com outra cadeia de aplicativos, você precisa examinar cuidadosamente o algoritmo de consenso e as garantias de finalidade e, consequentemente, configurar uma ponte entre cadeias (diretamente para a cadeia ou através do L1). Se você quiser interagir com 10 cadeias de aplicativos com designs diferentes, faça isso 10 vezes diferentes.

Experiência de desenvolvimento

Resolver a descentralização e a ponte não é fácil. Se este for um requisito para todas as cadeias de aplicativos, será muito difícil para o desenvolvedor de contrato inteligente usual construir sua própria cadeia de aplicativos. Além disso, à medida que cada cadeia de aplicações tenta resolver estes problemas à sua maneira, em breve veremos diferentes padrões a serem seguidos por diferentes cadeias, tornando ainda mais difícil a adesão ao ecossistema.

Sequenciadores compartilhados podem resolver isso

Agora, se você está acompanhando o espaço da cadeia de aplicativos, talvez já tenha ouvido falar do termo “sequenciadores compartilhados”. É a ideia de ter um conjunto comum de validadores para todas as cadeias que visam resolver os problemas mencionados acima. É assim que funciona.

Descentralização Compartilhada

A essência dos sequenciadores compartilhados é que você não precisa ter um conjunto diferente de validadores para cada cadeia de aplicativos ou L2. Em vez disso, você pode ter um conjunto de validadores realmente eficiente e descentralizado que sequencia os blocos para todas as cadeias! Imagine blocos que contenham transações de 100 cadeias de aplicativos diferentes. Você pode estar pensando que isso vai realmente sobrecarregar o sequenciador, pois você precisa ser capaz de lidar com mecanismos de execução para cada cadeia de aplicativos.

Bem, você não!

Como hoje quase todo sequenciador é centralizado, o sequenciador é pensado como uma aplicação única que coleta transações, ordena-as, executa-as e publica os resultados no L1. No entanto, estes trabalhos podem ser separados em vários componentes modulares. Para fins desta explicação, vou dividi-los em dois.

1. Motor de pedidos: É responsável por sequenciar as transações em um pedido específico. Uma vez que esta ordem tenha sido decidida pelo mecanismo de pedidos, ela DEVE ser seguida. Isso é aplicado ao confirmar esta ordem no L1 e forçar os verificadores L1 a verificar se as transações foram executadas na ordem exigida.
2. Mecanismo de rollup: O mecanismo de rollup é basicamente tudo o mais que o rollup faz – coletar transações de usuários, executá-las, criar provas e atualizar o estado no L1. Idealmente, isso pode ser dividido em mais componentes, mas evitaríamos isso neste post.

Aqui, o mecanismo de ordenação é o sequenciador compartilhado e o mecanismo de rollup é basicamente toda a lógica de rollup. Portanto, o ciclo de vida da transação é assim

Os sequenciadores compartilhados basicamente ordenam transações em rollups e as enviam para L1. Conseqüentemente, ao descentralizar o conjunto de sequenciadores compartilhados, você basicamente descentraliza todos os rollups vinculados a esse conjunto de sequenciadores! Para ter uma ideia mais detalhada do funcionamento dos sequenciadores compartilhados, você também pode consultar este incrível <a href="https://hackmd.io/@EspressoSystems/EspressoSequencer"> artigo 17 da Espresso.

Composição

Uma das principais questões da composição é entender quando a transação é finalizada na outra cadeia de aplicativos e, consequentemente, tomar ações em sua cadeia. Mas com sequenciadores compartilhados, ambos os rollups combináveis compartilham blocos entre si. Portanto, se uma transação for revertida no rollup B, todo o bloco será revertido e isso fará com que a transação no rollup A também seja revertida.

Agora, isso certamente parece mais fácil de falar do que fazer. Por esta. a comunicação entre rollups precisa ser eficiente e escalável. Os sequenciadores compartilhados precisam criar padrões adequados sobre como os rollups podem se comunicar, como devem ser as mensagens entre cadeias, como lidar com atualizações de rollup, etc. Embora sejam problemas solucionáveis, são complicados e difíceis de resolver.

Experiência do desenvolvedor

Embora os sequenciadores compartilhados abstraiam o aspecto da descentralização e facilitem as mensagens entre cadeias, ainda existem alguns padrões que cada cadeia precisa seguir para ser compatível com o sequenciador compartilhado. Por exemplo, todas as transações de rollup precisam ser transformadas em um formato geral que o sequenciador entenda. Da mesma forma, os blocos do sequenciador precisam ser filtrados para buscar as transações relevantes. Para resolver isso, eu presumiria que os sequenciadores compartilhados criariam estruturas rollup ou SDKs que abstraem o código clichê e expõem apenas a parte da lógica de negócios aos desenvolvedores da cadeia de aplicativos.

Aqui está um diagrama de como serão as cadeias de aplicativos com sequenciadores compartilhados

Espere, é apenas Polkadot de novo

Polkadot começou a trabalhar no futuro multicadeia muito antes do Ethereum. Na verdade, eles estão trabalhando nisso há mais de 5 anos e se você conhece Polkadot, deve ter notado que o design acima está basicamente reinventando muitas coisas que Polkadot já fez!

A cadeia de retransmissão (descentralização compartilhada)

A cadeia de relés é basicamente o mecanismo de pedido + L1 no diagrama de sequência acima. A cadeia de retransmissão

1. Ordena transações em todos os parachains (rollups)
2. Ele verifica as transações executadas corretamente (em vez da verificação zk, na verdade ele executa novamente o código de execução do rollup para verificar as diferenças de estado)

Você deve ter percebido que o relé é basicamente o sequenciador compartilhado que discutimos acima. Exceto pelo fato de que a cadeia de retransmissão também precisa verificar a execução (já que Polkadot é um L1), enquanto deixamos isso para Ethereum.

XCM e XCMP

Mencionamos na seção anterior que se cada cadeia construísse seus próprios métodos para interoperar com outras cadeias, em breve estaríamos sobrecarregados com diferentes padrões e formatos em todas as cadeias. Você precisará acompanhar todos esses formatos para cada rede com a qual interagir. Além disso, você também precisará responder a perguntas como o que acontece se uma rede for atualizada? No entanto, estes problemas podem ser resolvidos de forma elegante através da introdução de normas que todas as cadeias devem seguir.

Como você deve ter adivinhado, Polkadot já fez isso. XCM é o formato de mensagens e XCMP é o protocolo de mensagens que todas as cadeias de substrato podem usar para se comunicarem entre si. Não vou entrar em detalhes, mas você pode ler sobre isso aqui 5.

Substrato e Cumulus

Substrato é uma estrutura desenvolvida pela Parity que pode ser usada para construir blockchains. Embora todos os parachains no Polkadot usem substrato, o substrato é, na verdade, construído de forma independente da cadeia. A estrutura abstrai todos os aspectos comuns de um blockchain para que você possa se concentrar apenas na lógica do seu aplicativo. Como sabemos, Madara é construído em Substrate, assim como Polkadot, Polygon Avail e muitos outros projetos. Além disso, Cumulus é um middleware baseado no Substrate que permite conectar sua cadeia ao Polkadot.

Continuando nossa analogia como antes, Substrate e Cumulus podem ser considerados substitutos das estruturas rollup que permitem construir cadeias de aplicativos e conectá-las aos sequenciadores compartilhados.

Sequenciadores Compartilhados → Cadeias de Retransmissão
Composição → XCM e XCMP
Estruturas/pilhas de rollup → Substrato e Cumulus

Então sim, é praticamente Polkadot de novo! Além disso, Polkadot e Parity têm algumas das equipes mais experientes e financiadas que continuam a construir o Substrate e o Polkadot para adicionar mais recursos e torná-los mais escalonáveis. A tecnologia já foi testada em batalha há anos e possui uma tonelada de ferramentas de desenvolvimento prontas para uso.

Resolver Polkadot em Ethereum?

Embora seja verdade que Polkadot começou a construir o futuro multi-chain muito antes do Ethereum, não há como negar que, a partir de hoje, o Ethereum é o blockchain mais descentralizado e o lugar onde reside a maioria dos aplicativos e da liquidez. No entanto, e se houvesse uma maneira de trazer toda a tecnologia Polkadot para o ecossistema Ethereum?

Há! Na verdade, já começamos isso com Madara. Madara usa a estrutura Substrate para permitir que qualquer pessoa construa sua própria solução L2/L3 com zk em cima do Ethereum. O que precisamos a seguir é a cadeia de retransmissão Polkadot na forma de um sequenciador compartilhado. Então, basicamente, se pudermos reutilizar a cadeia de retransmissão Polkadot, mas

1. Remova a parte de verificação como acontece no L1 por meio de provas zk
2. Confirme a ordem das transações para o L1
3. Otimize os nós e algoritmos de consenso para suportar Tendermint/HotStuff

Podemos obter sequenciadores compartilhados conforme mencionado anteriormente. Obviamente, é mais fácil falar do que fazer. Porém, acredito que esse caminho é mais pragmático do que reconstruir os sequenciadores, padrões e frameworks do zero. Polkadot já resolveu muitos problemas de uma forma agnóstica em cadeia que podemos emprestar para Ethereum. Como produto secundário, obtemos

1. Um conjunto ativo de desenvolvedores que continuam a construir e educar o mundo sobre o Substrate
2. Um conjunto ativo de ferramentas para desenvolvedores e uma comunidade forte
3. Muitos parachains ativos também podem optar por se estabelecer no Ethereum se assim o desejarem (vimos Astar fazer o mesmo recentemente com o Polygon CDK)

Conclusão

Minha ideia principal por trás de escrever este post é abrir a discussão entre o ecossistema mais amplo de Starknet e Ethereum. Sinto que o modelo de sequenciamento compartilhado desempenhará um papel importante na descentralização não apenas da Starknet, mas também de todas as cadeias de aplicativos que consideram construir sobre ele. Enquanto estivermos confiantes na tese da cadeia de aplicativos e no escalonamento zk, uma análise completa do modelo de sequenciamento compartilhado será inevitável. Além disso, à medida que Madara está a avançar para a produção e a Starknet iniciou o seu trabalho na descentralização, sinto que este tópico é agora importante de abordar. Portanto, peço a todos que estão lendo isto que deixem comentários/sugestões sobre o assunto. Estou ansioso para ler seus pensamentos!

Apêndice

Polkadot vs Cosmos

O Cosmos, semelhante ao Polkadot, vem solucionando um futuro multicadeia há muitos anos. Como resultado, ele fez muitos desenvolvimentos com o Cosmos SDK e IBC e também vemos muitas cadeias de aplicativos sendo construídas no ecossistema Cosmos. Portanto, é justo considerar também o Cosmos para esta abordagem. Minha opinião pessoal sobre este tópico é que Polkadot é mais relevante porque resolve o problema dos sequenciadores compartilhados, enquanto o Cosmos exige que cada cadeia de aplicativos construa seu próprio conjunto de validadores. Além disso, o Substrate sempre foi construído de forma agnóstica em cadeia para permitir que os desenvolvedores construíssem blockchains sem suposições sobre algoritmos de consenso ou o ecossistema Polkadot. Esta também é a razão pela qual escolhemos Substrato para Madara. No entanto, dito isso, minha experiência no Cosmos é limitada e adoraria ouvir mais sobre isso das pessoas mais experientes! Você também pode encontrar mais sobre a comparação das duas redes aqui

Isenção de responsabilidade:

1. Este artigo foi reimpresso de [starknet]. Todos os direitos autorais pertencem ao autor original [apoorvsadana]. Se houver objeções a esta reimpressão, entre em contato com a equipe do Gate Learn e eles cuidarão disso imediatamente.
2. Isenção de responsabilidade: As opiniões e pontos de vista expressos neste artigo são exclusivamente do autor e não constituem qualquer conselho de investimento.
3. As traduções do artigo para outros idiomas são feitas pela equipe do Gate Learn. A menos que mencionado, é proibido copiar, distribuir ou plagiar os artigos traduzidos.