A layer-2 das blockchains surgiu para resolver o problema da escalabilidade. Se formos observar, por exemplo, na ethereum, existe um tempo de 15 segundos para cada bloco ser adicionado na ledger. Além disso, existe uma taxa para cada transação. A ethereum cresceu muito, e cada vez que surgirem mais e mais transações, isso pode acabar sobrecarregando a rede, causando um aumento nos custos das transações, e até no aumento de delay na execução de uma transação.
Por isso, surgiu a estratégia da layer-2. Que consiste em criar uma nova camada acima da infraestrutura padrão de uma blockchain para ajudar no processo de validação das transações, mantendo assim a rede escalável e com uma boa vazão de transações.
Mas para fazer isso acontecer, surgiram várias estratégias que buscam utilizar os contratos inteligentes para ajudar na validação de transações antes de serem realmente enviadas para a blockchain. As implementações de layer-2 podem variar bastante de projeto para projeto, mas duas implementações existentes são a payment channels e rollups.
Payment Channels
Permite executar transações off-chain de tokens on-chain a provendo liquidez para um canal, e isso pode ser feito através de um contrato inteligente.
Um exemplo, bob e alice concordam em travar num contrato inteligente uma quantidade de $50, dando um total de $100. Ou seja, os dois concordam que cada um pode gastar no max $50 nas transações off-chain entre eles. Aqui os dois abriram o canal.
Depois de realizarem as transações off-chain, eles podem solicitar para o contrato inteligente fechar o canal entre eles, e ai sim executar somente o resultado final de saldos para o contrato. Ou seja, alice e bob somente realizaram duas transações on-chain. Isso reduziu bastante o request de novas transações e ainda o armazenamento on-chain dessas transações off-chain realizadas.
Rollups
Os rollups utilizam três métodos para aumentar a vazão de transações e diminuir custos.
Execuções Off-chain
Uma característica chave dos rollups são as execuções off-chain. Redes layer-2 lida com transações por trás da blockchain base, utilizando um nó validador menor e com um hardware melhor. A única coisa que a blockchain base precisa fazer é executar provas que são submetidas pelos contratos inteligentes de rollup para verificar a atividade que foi feita no layer-2.
Agrupamento de transações
Outra forma de reduzir os custos é agrupando transações. Ao invés de enviar uma transação por vez, onde cada transação tem seu custo, rollups podem agrupar várias transações de uma vez, de forma que o custo dessas transações será um custo um pouco maior, mas que pode ser dividido entre os solicitantes.
Menos validadores
A layer-2 herda as características de segurança e descentralização da blockchain em si. O que o layer-2 precisa fazer é só achar uma forma de provar para a blockchain base que as alterações de estado realizadas nela são válidas. E isso permite que rollups possam ter menos validadores. Esses validadores podem ser entidades permissionadas que geralmente tem um hardware mais sofisticado para computar as transações de forma mais rápida e com um custo baixo.
As provas mais relevantes hoje são as fault proofs e validity proofs (conhecidas como zero-knowledge proofs).
Payment Channel Signed messages
Optimistic Rollup Fault Proofs
Uma layer-2 que usa este tipo de prova, assume inicialmente que todas as transações são validas por padrão. Entretanto, existe um período de disputa onde cada participante da rede pode iniciar uma disputa e entregar uma prova para o contrato inteligente de que a proposta de alteração de estado e dados da transação estão errados. Quando uma prova de falha é publicada, a transação de rollup é parcialmente ou completamente reexecutada na base blockchain e comparada com a requisição original. Se a comparação der diferença, então o request original é considerado inválido e é revertido.
zk-rollup Validity Proofs (Zero-Knowledge)
Pode ser considerada o oposto de fault proofs, onde qualquer execução é questionada e precisa ser provada previamente. Basicamente, qualquer transação realizada na layer-2 precisa ser validada e provada que está correta antes de enviar para o contrato inteligente. Ao enviar o request para o contrato, enviando as alterações de estado e a validade da prova do agrupamento de transações.
Top comments (0)