Introdução

Hoje, já estamos a ver projetos a começar a experimentar o Madara para as suas cadeias de aplicações. Pragma, Kakarot, Mangata Finance e Dojo são apenas alguns exemplos. Enquanto acreditarmos no futuro das várias cadeias e no poder do zk scaling, só veremos muito mais destes projetos no futuro. No entanto, o número crescente de cadeias de aplicações também levanta questões

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

Neste post, vou tentar explicar os problemas que surgem devido a ter muitas cadeias de aplicações e também representar uma possível solução para o problema que considero elegante e ideal para Madara e Starknet. Se já é bem versado com cadeias de aplicações e sequenciamento partilhado, sinta-se à vontade para pular para a secção “Espere, é apenas Polkadot de novo”.

O que acontece em 100 cadeias de aplicações?

Digamos que estamos num futuro em que agora temos 100 cadeias de aplicações diferentes a estabelecer-se no Ethereum. Vamos resolver todos os problemas que isso irá causar.

Descentralização fragmentada

Cada cadeia de aplicações terá de resolver a descentralização por conta própria. Agora, a descentralização das cadeias de aplicações não é tão necessária como a dos L1s principalmente porque dependemos dos L1s para a segurança. No entanto, ainda precisamos de descentralização para garantir vivacidade, resistência à censura e evitar vantagens monopolistas (taxas elevadas, por exemplo). No entanto, também é importante notar que se cada cadeia de aplicações 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 gerir. Sem mencionar a enorme barreira à entrada que isto cria para os programadores lançarem as suas próprias cadeias de aplicações (em vez de implementar um contrato inteligente que é apenas uma transação).

Composição

Composabilidade 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 aplicações, isso torna-se muito mais difícil. Diferentes cadeias de aplicações têm os seus próprios blocos e mecanismos de consenso. Toda vez que tenta interagir com outra cadeia de aplicações, precisa examinar cuidadosamente o algoritmo de consenso e as garantias de finalidade e, consequentemente, configurar uma ponte de cadeia cruzada (diretamente para a cadeia ou através do L1). Se quiser interagir com 10 cadeias de aplicações com designs diferentes, faria isto 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 aplicações, será muito difícil para o habitual programador de contratos inteligentes construir a sua própria cadeia de aplicações. Além disso, à medida que cada cadeia de aplicações tenta resolver estes problemas à sua maneira, em breve veremos padrões diferentes a serem seguidos por cadeias diferentes, tornando ainda mais difícil a adesão ao ecossistema.

Os Sequenciadores Partilhados podem resolver isto

Agora, se está a seguir o espaço da cadeia de aplicações, pode ter ouvido falar do termo “sequenciadores partilhados”. É 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 Partilhada

A própria essência dos sequenciadores partilhados é que não precisa de um conjunto diferente de validadores para cada cadeia de aplicações ou L2. Em vez disso, pode ter um conjunto realmente eficiente e descentralizado de validadores que sequenciam os blocos para todas as cadeias! Imagine blocos que contêm transações de 100 cadeias de aplicações diferentes. Pode estar a pensar que isso vai realmente inchar o sequenciador, pois precisa ser capaz de lidar com os motores de execução para cada cadeia de aplicações.

Bem, não tem!

Uma vez que hoje quase todos os sequenciadores são centralizados, o sequenciador é pensado como uma única aplicação que recolhe transações, ordena-as, executa-as e posta os resultados no L1. No entanto, estes trabalhos podem ser separados em vários componentes modulares. Por causa desta explicação, vou dividi-los em dois.

1. Motor de encomendas: Este é o responsável por sequenciar as transações numa ordem específica. Uma vez que este pedido tenha sido decidido pelo motor de encomendas, DEVE ser seguido. Isto é 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. Motor de rollup: O motor de rollup é basicamente tudo o resto que o rollup faz - recolher transações dos utilizadores, executá-las, criar provas e atualizar o estado no L1. Idealmente, isso pode ser dividido em mais componentes mas evitaríamos isso para este post.

Aqui, o motor de encomendas é o sequenciador partilhado e o motor de rollup é basicamente toda a lógica de rollup. Portanto, o ciclo de vida da transação é assim

Os sequenciadores partilhados ordenam basicamente transações através de rollups e as comprometem com o L1. Por isso, ao descentralizar o conjunto de sequenciadores partilhados, descentraliza basicamente todos os rollups ligados a esse conjunto de sequenciadores! Para ter uma ideia mais detalhada do funcionamento dos sequenciadores partilhados, 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 composabilidade é entender quando a transação é finalizada na outra cadeia de aplicações e, consequentemente, tomar medidas na sua cadeia. Mas com sequenciadores partilhados, ambos os rollups composáveis partilham blocos entre si. Portanto, se uma transação reverter no conjunto B, todo o bloco é revertido e isso faz com que a transação no conjunto A também seja revertida.

Agora isso parece mais fácil dizer do que fazer. Para isso. a comunicação entre rollups tem de ser eficiente e escalável. Os sequenciadores partilhados têm de apresentar padrões adequados sobre como os rollups podem comunicar, como devem ser as mensagens entre cadeias, como lidar com actualizações de rollup etc. Embora sejam problemas solucionáveis, são complicados e não são fáceis de resolver.

Experiência de programador

Embora os sequenciadores partilhados 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 partilhado. Por exemplo, todas as transações totalizadas precisam de ser transformadas num formato geral que o sequenciador compreenda. Da mesma forma, os blocos do sequenciador precisam de ser filtrados para buscar as transações relevantes. Para resolver isto, assumiria que os sequenciadores partilhados viriam com estruturas de rollup ou SDKs que abstraem o código programado e expõem apenas a parte da lógica empresarial aos programadores da cadeia de aplicações.

Aqui está um diagrama de como as cadeias de aplicações ficarão com sequenciadores partilhados

Espera, é só Polkadot de novo

Polkadot começou a trabalhar no futuro multi-cadeias muito antes do Ethereum. Na verdade, eles estão a trabalhar nisso há mais de 5 anos e se está familiarizado com o Polkadot, deve ter notado que o design acima está basicamente a reinventar muitas coisas que o Polkadot já fez!

A cadeia de relés (descentralização partilhada)

A cadeia de relés é basicamente o motor de encomenda+L1 no diagrama de sequência acima. A cadeia de relés

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

Pode ter percebido que o relé é basicamente o sequenciador partilhado que discutimos acima. Exceto pelo facto de a cadeia de relés também ter de verificar a execução (já que o Polkadot é um L1) enquanto deixamos isso para o Ethereum.

XCM e XCMP

Mencionámos na secção anterior que se cada cadeia construísse os seus próprios métodos para interoperar com outras cadeias, logo estaríamos inchados com padrões e formatos diferentes em todas as cadeias. Terá de acompanhar todos estes formatos para cada cadeia com a qual interage. Além disso, também terá de responder a perguntas como o que acontece se uma cadeia for atualizada? No entanto, estes problemas podem ser resolvidos com elegância através da introdução de padrões que todas as cadeias devem seguir.

Como deve ter adivinhado, o Polkadot já o fez. XCM é o formato de mensagens e XCMP é o protocolo de mensagens que todas as cadeias de substratos podem usar para comunicar umas com as outras. Não vou entrar em detalhes mas pode ler sobre isso aqui 5.

Substrato e Cumulus

O substrato é uma estrutura desenvolvida pela Parity que pode ser usada para construir blockchains. Embora todos os parachains no Polkadot usem substrato, o substrato é construído de uma forma independente da cadeia. A estrutura abstrai todos os aspectos comuns de uma cadeia de blocos para que possa concentrar-se apenas na lógica da sua aplicação. Como sabemos, o Madara é construído sobre o substrato e o Polkadot, o Polygon Avail e muitos outros projetos. Além disso, o Cumulus é um middleware em cima do Substrato que permite ligar a sua cadeia ao Polkadot.

Portanto, continuando a nossa analogia como antes, o Substrato e o Cumulus podem ser pensados como substitutos das estruturas de rollup que lhe permitem construir cadeias de aplicações e conectá-las aos sequenciadores partilhados.

Sequenciadores partilhados →
Composição de cadeias de relés → Frameworks/pilhas de rollup XCM e XCMP → Substrato e Cumulus

Então sim, é praticamente Polkadot de novo! Além disso, a Polkadot e a Parity têm algumas das equipas mais experientes e financiadas que continuam a construir o Substrato e o Polkadot para adicionar mais funcionalidades e torná-lo mais escalável. A tecnologia já é testada em batalha há anos e tem uma tonelada de ferramentas de desenvolvimento fora da caixa.

Liquidar Polkadot no Ethereum?

Embora seja verdade que o Polkadot começou a construir o futuro multi-cadeias muito antes do Ethereum, não há como negar que, a partir de hoje, o Ethereum é a blockchain mais descentralizada e o lugar onde repousa a maioria das aplicações e a liquidez. No entanto, e se houvesse uma maneira de trazer toda a tecnologia Polkadot para o ecossistema Ethereum?

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

1. Remova a parte de verificação como isso acontece no L1 via zk proofs
2. Cometer a ordem das transações para o L1
3. Otimize os nós e algoritmos de consenso para suportar o TenderMint/HotStuff

Podemos ter sequenciadores partilhados como mencionado anteriormente. Obviamente, é mais fácil dizer do que fazer. No entanto, acredito que este caminho é mais pragmático do que reconstruir os sequenciadores, padrões e frameworks a partir do zero. Polkadot já resolveu muitos problemas de uma forma independente de cadeia que podemos pedir emprestado para o Ethereum. Como um produto secundário, temos

1. Um conjunto ativo de programadores que continuam a construir e educar o mundo sobre o Substrato
2. Um conjunto de ferramentas de desenvolvimento ativo e uma comunidade forte
3. Muitos parachains ativos também podem optar por se estabelecer no Ethereum se quiserem fazê-lo (vimos a Astar fazer o mesmo recentemente com o Polygon CDK)

Conclusão

A minha ideia principal por trás de escrever este post é abrir a discussão entre o ecossistema mais amplo da Starknet e Ethereum. Acho que o modelo de sequenciamento partilhado terá um papel importante na descentralização não só da Starknet mas também de todas as cadeias de aplicações que consideram construir sobre ela. Enquanto estivermos confiantes sobre a tese da cadeia de aplicações e o escalonamento zk, uma análise minuciosa do modelo de sequenciamento partilhado é inevitável. Além disso, à medida que o Madara caminha para a produção e a Starknet começou o seu trabalho de descentralização, acho que este tópico é agora importante abordar. Por isso, peço a todos os que leem isto que deixem qualquer feedback/sugestão que tenha sobre o assunto. Ansioso para ler os seus pensamentos!

Apêndice

Polkadot vs Cosmos

O Cosmos, semelhante ao Polkadot, tem vindo a resolver um futuro multi-cadeias há muitos anos. Como resultado, fez muitos desenvolvimentos com o Cosmos SDK e IBC e também vemos muitas cadeias de aplicações a construir sobre o ecossistema Cosmos. Portanto, é justo considerar o Cosmos também para esta abordagem. A minha opinião pessoal sobre este tópico é que o Polkadot é mais relevante à medida que resolve o problema dos sequenciadores partilhados, enquanto o Cosmos requer que cada cadeia de aplicações construa o seu próprio conjunto de validadores. Além disso, o Substrato sempre foi construído de uma forma independente da cadeia para permitir que os programadores construam blockchains sem suposições sobre algoritmos de consenso ou o ecossistema Polkadot. Esta é também a razão pela qual escolhemos o Substrato para Madara. No entanto, com isso dito, a minha experiência no Cosmos é limitada e adoraria ouvir mais sobre isso das pessoas mais experientes! 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, contacte a equipa do Gate Learn, e eles tratarão disso imediatamente.
2. Isenção de responsabilidade: As opiniões e opiniões expressas neste artigo são exclusivamente do autor e não constituem nenhum conselho de investimento.
3. As traduções do artigo para outras línguas são feitas pela equipa do Gate Learn. A menos que mencionado, é proibido copiar, distribuir ou plagiar os artigos traduzidos.