CKB联创Jan：什么是L1饥饿问题 L2与L1该如何设计

Compilado por Wuyue&Baiding, Geek web3

Este artigo é o discurso do co-fundador da Nervos, Jan, na conferência HBS Blockchain+Crypto Club em 2019, com o tema centrado na relação entre a Layer2 e a Layer1, afirmando claramente que a blockchain modular será a direção correta, e também abordou a questão do mecanismo de armazenamento de dados da blockchain modular. Ao mesmo tempo, Jan também levantou um tópico bastante interessante: como resolver o problema se o surgimento da Layer2 levar à fome da Layer1.

Como uma das primeiras equipes a apoiar a narrativa de Layer2 e blockchain modular, a visão da Nervos era altamente visionária nos anos de 18 e 19, quando a comunidade ETH ainda tinha ilusões irrealistas sobre a Fragmentação e a narrativa de uma única cadeia de alto desempenho estava em alta, mas ainda não era amplamente confirmada.

Mas hoje, em 2024, olhando para os problemas expostos na prática pelo Layer2 da ETH e as desvantagens da ‘blockchain’ de alto desempenho representada pelo Solana em termos de Descentralização e confiança, é preciso dizer que Jan tinha uma visão muito perspicaz cinco anos atrás. Por interesse no Layer2 em si, o ‘geek web3’ compilou a palestra de Jan em forma de texto e a publicou aqui. Bem-vindos os entusiastas do Layer2 da Nervos, ETH e comunidade BTC, para estudar e discutir juntos.

A seguir está o texto original da palestra de Jan.

Definição de Layer1 e Layer2

Esta é a minha definição de L1 e L2 (rede de camada 2), conforme a ilustração.

Em primeiro lugar, é importante salientar que a Nerovs é apenas uma rede Blockchain que se esforça para atender às necessidades econômicas de Descentralização e não é responsável por resolver ‘todos os problemas’. Na nossa compreensão, a diferença entre Layer1 e Layer2 reside fundamentalmente na força do Consenso. A rede L1 deve ter o Consenso mais amplo, ou seja, ‘Consenso global’. Através de um Consenso global sem permissão, qualquer pessoa no mundo pode participar no processo de Consenso do L1, e no final o Layer1 pode servir como ‘âncora’ para a economia de Descentralização. Neste sentido, podemos chamar o L1 de ‘Camada de Consenso’.

Em comparação, o escopo de Consenso da rede L2 é um pouco menor, com seus participantes podendo ser de um único país, setor ou até mesmo de uma única empresa ou instituição, ou uma comunidade muito pequena. O sacrifício do escopo de Consenso do L2 é um custo que traz avanços em outras áreas, como maior TPS, menor latência e melhor escalabilidade. Podemos chamar o L2 de ‘camada de protocolo’, e a conexão entre L1 e L2 é frequentemente feita por meio de pontes de cadeia cruzada.

É importante enfatizar que a construção de nossa rede L2 não tem como objetivo apenas resolver o problema de escalabilidade da blockchain, mas sim porque a arquitetura em camadas é a maneira mais fácil de implementar a ideia de ‘blockchain modular’. O conceito de blockchain modular é resolver diferentes tipos de problemas em diferentes módulos.

Muitas pessoas têm discutido a questão de Conformidade e regulamentação do blockchain. Então, como podemos integrar o BTC ou o Éter Ethereum no quadro regulamentar existente? A arquitetura em camadas pode ser uma resposta para resolver esse problema. Adicionar diretamente lógica de negócios que atenda aos requisitos regulatórios na camada Layer1 pode prejudicar sua Descentralização e neutralidade, portanto, a lógica relacionada à Conformidade pode ser implementada separadamente na Layer2.

A Layer2 pode ser personalizada de acordo com regulamentos ou padrões específicos, como a criação de uma pequena blockchain com permissão ou a rede de canal estatal. Isso permite conformidade sem afetar a descentralização e neutralidade da Layer1.

Além disso, podemos resolver o conflito entre segurança e experiência do usuário por meio de uma arquitetura em camadas. Por analogia, se você quiser garantir a segurança da sua Chave privada, terá que sacrificar um pouco de conveniência, e o mesmo acontece com a blockchain. Se você quiser garantir a segurança absoluta da blockchain, terá que sacrificar algumas coisas, como o desempenho da cadeia, entre outras coisas.

No entanto, se usarmos uma arquitetura em camadas, podemos buscar total segurança na rede L1 e sacrificar um pouco da segurança na rede L2 em troca de uma melhor experiência do usuário. Por exemplo, podemos usar canais estatais na L2 para otimizar o desempenho da rede, reduzindo a latência. Portanto, o design da Camada 2 é apenas um equilíbrio entre segurança e experiência do usuário.

O conteúdo acima naturalmente levanta a questão: Qualquer blockchain pode ser usada como Layer1?

A resposta é negativa, primeiro temos de ter clareza de que a Descentralização e a segurança da rede Layer1 estão acima de tudo, pois temos de alcançar a resistência à censura. A busca pela segurança da Layer1, fundamentalmente, ocorre porque a L1 é a raiz de toda a rede de Blockchain e âncora do sistema econômico de encriptação como um todo.

Com base nesses critérios, **BTC e ETH são sem dúvidas as redes L1 mais clássicas, com um amplo alcance de Consenso. Além dessas duas, a maioria das blockchains não atende aos padrões L1, com um nível de Consenso mais baixo. Por exemplo, o Consenso do EOS não é suficiente, ele só pode atuar como uma rede L2, além disso, algumas de suas regras só se aplicam a si próprias.

Problemas atuais da rede Layer1

Depois de definir claramente a definição da Layer1, devemos apontar que existem três problemas em algumas redes L1 existentes, que existem em certa medida mesmo no BTC e no ETH:

1. O problema da tragédia dos bens comuns de armazenamento de dados

Ao usar a cadeia de blocos Bloco, é necessário pagar uma certa taxa, mas no modelo econômico do BTC, a estrutura de taxas considera apenas os custos de computação e largura de banda da rede, sem considerar adequadamente os custos de armazenamento de dados.

Por exemplo, os utilizadores só precisam de pagar uma vez para armazenar dados na cadeia, mas o prazo de armazenamento é permanente, portanto, as pessoas podem abusar dos recursos de armazenamento e colocar tudo permanentemente na cadeia, o que acabará por aumentar cada vez mais os custos de armazenamento para todos os nós na rede. Isto levanta um problema: qualquer operador de nó que queira participar nos custos da rede será elevado ao máximo.

Supondo que o estado dos dados/conta de uma determinada blockchain ultrapasse 1 TB, nem todos podem facilmente sincronizar o estado completo e o histórico de transações. Nesse caso, mesmo que você possa sincronizar o estado completo, é difícil verificar o histórico correspondente de transações, o que enfraquece a confiabilidade da blockchain, e a confiabilidade é precisamente o valor central da blockchain.

A Fundação ETH está ciente dos problemas acima e incluiu um projeto para locação de armazenamento no EIP-103, mas acreditamos que esta não é a solução ideal.

Apresentamos um novo modelo de estado no Nervos, chamado “Cell”, que pode ser considerado uma extensão do UTXO. No estado BTCUTXO, você só pode armazenar o saldo de BTC, enquanto no Cell pode armazenar qualquer tipo de dados e generalizar o “amount” e o valor inteiro do BTCUTXO como “Capacidade”, para especificar a capacidade máxima de armazenamento do Cell.

Desta forma, vinculamos a quantidade e o estado dos ativos nativos no CKB juntos. O espaço ocupado por qualquer célula não pode exceder sua capacidade, portanto, o total de dados será mantido dentro de um determinado intervalo.

E garantimos que o tamanho dos dados de estado não interferirá nos Nós em execução no Nó por meio de uma taxa de inflação de Token adequada. Qualquer pessoa pode participar da rede CKB e validar dados históricos e a validade do estado final, que é a solução proposta pelo CKB para problemas de armazenamento na cadeia de blocos.

2. Problema da fome na camada 1

Se expandirmos para Layer2 e movermos uma grande quantidade de atividade de negociação para Layer2, isso inevitavelmente levará a uma queda no número de transações em Layer1, e as recompensas econômicas para Mineiros/Nós Layer1 também diminuirão em conformidade. Isso levará a uma diminuição no entusiasmo dos Mineiros/Nós Layer1 e, finalmente, resultará em uma diminuição na segurança do Layer1. Este é o chamado problema de fome de Layer1.

Para dar um exemplo extremo, se transferirmos todas as atividades de negociação para L2, então L1, que é a base, não será sustentável. Então, como podemos resolver esse problema?

Para isso, precisamos distinguir quais tipos de usuários existem na rede blockchain, que podem ser divididos em usuários de Store of Value (usuários SoV, armazenamento de valor) e usuários de Utilidade (usuários de utilidade).

Ainda usando CKB como exemplo, os utilizadores SOV usarão o token nativo CKB como meio de armazenamento de valor, enquanto os utilizadores de Utilidade utilizarão a Cell para armazenar o estado. Os utilizadores SOV rejeitam a diluição de preços causada pela inflação do token CKB, enquanto os Utilizadores de Utilidade devem pagar uma taxa de armazenamento de estado ao Mineiro, que é proporcional à duração e ao espaço ocupado do armazenamento de dados.

Vamos continuar a emitir novos tokens CKB na rede para criar uma taxa de inflação fixa e entregá-los aos mineiros. Isso é equivalente a diluir o valor dos tokens nas mãos dos Utilizadores de Utilidade (isto é uma das três formas de emissão no modelo económico do CKB, chamada ‘emissão de segundo nível’, que emite 1.344 bilhões de tokens CKB por ano. Para mais informações, consulte ‘Interpretação do Stable++: O protocolo de stablecoin RGB++ Layer inicia oficialmente’.)

Durante esse processo, os ativos dos usuários SOV também são diluídos, então podemos fornecer-lhes um subsídio para compensar as perdas de inflação (isto é o que se tornou mais tarde a divisão NervosDAO). Ou seja, os lucros que Mineiro obtém da inflação CKB são na verdade pagos apenas pelo Utility User. Em breve publicaremos o documento econômico de emissão de Token CKB, no qual essas questões serão explicadas em detalhes.

Com base nesse design de tokenomics, os Mineiros podem receber recompensas mesmo sem atividade de transação na cadeia CKB, o que nos permite ser compatíveis com qualquer ‘camada de armazenamento de valor’ ou Layer2. Em resumo, resolvemos o problema da fome da camada 1 através de uma inflação fixa intencional.

3.encriptação原语的缺乏

Os usuários precisam de diferentes idiomas de encriptação para usar diferentes métodos de encriptação ou diferentes algoritmos de assinatura, como Schnorr, BLS, etc.

**Para se tornar uma blockchain de Layer1, é necessário considerar como interagir com Layer2. Alguns na comunidade do Ethereum propuseram a utilização de ZK ou Plasma para implementar o Layer2, mas sem primitivas ZK relacionadas, como você pode realizar a verificação na Layer1?

Além disso, Layer1 também deve considerar a interoperabilidade com outras Layer1. Tomando Ethereum como exemplo, alguém pediu à equipe do Ethereum que pré-compilasse a função de hash Blake2b como uma opcode compatível com a EVM. O objetivo desta proposta é criar uma ponte entre Zcash e Ethereum, para que os usuários possam negociar entre os dois. Embora essa proposta tenha sido feita há dois anos, ainda não foi implementada devido à falta de primitivas de encriptação correspondentes, o que tem sido um obstáculo sério para o desenvolvimento da Layer1.

Para resolver esse problema, CKB construiu uma Máquina virtual altamente abstrata, chamada CKB-VM, que é completamente diferente da Máquina virtual do BTC e da EVM. Por exemplo, o BTC possui um código de operação especial, OP_CHECKSIG, usado para verificar a assinatura secp256k1 nas transações de BTC. No entanto, na CKB-VM, a assinatura secp256k1 não precisa de tratamento especial, podendo ser verificada apenas por meio de scripts personalizados do usuário ou Contratos inteligentes.

CKB também utiliza secp256k1 como seu algoritmo de assinatura padrão, mas é executado na CKB-VM em vez de ser uma primitiva de encriptação codificada em hardware.

A ideia original da CKB para construir uma Máquina virtual era melhorar o desempenho da encriptação em comparação com outras Máquinas virtuais, como a EVM, onde a execução de primitivas de encriptação é muito lenta. A verificação de uma única assinatura secp256k1 na EVM leva cerca de 9 milissegundos, enquanto a execução do mesmo Algoritmo no CKB-VM leva apenas 1 milissegundo, o que representa quase dez vezes mais eficiência.

Portanto, o valor do CKB-VM está no facto de os utilizadores poderem agora personalizar a sua própria linguagem de encriptação, e a maioria delas é compatível com o CKB-VM, uma vez que este adota o conjunto de instruções RISC-V. Qualquer linguagem compilada pelo GCC (GNU Compiler Collection, uma coleção de compiladores amplamente utilizada) pode ser executada no CKB.

Além disso, a alta compatibilidade do CKB-VM também aumenta a segurança do CKB. Como os desenvolvedores sempre dizem: “Não implemente sua própria versão de algoritmos de criptografia, você sempre irá fazer errado”, definir seu próprio Algoritmo de encriptação geralmente traz riscos de segurança imprevisíveis.

Para resumir, a rede CKB resolveu os três problemas que identifiquei para as redes L1, utilizando vários métodos. Esta é a razão pela qual a CKB pode ser considerada uma rede Layer1 qualificada.