Você já quis saber mais sobre como o Rollup funciona? A teoria é boa, mas a experiência prática é sempre preferível. Infelizmente, os projetos existentes nem sempre facilitam a visualização do que está acontecendo. É por isso que criamos o BYOR (Build Your Own Rollup). É um pacote cumulativo soberano com funcionalidade mínima, com foco em tornar o código fácil de ler e entender.
Nossa motivação para este projeto é que as pessoas, tanto de fora quanto de dentro, entendam melhor o que os rollups ao nosso redor estão realmente fazendo. Você pode brincar no BYOR implantado da Holesky ou ler o código-fonte no GitHub.
O que é BYOR?
O projeto BYOR é uma versão simplificada do pacote cumulativo soberano. Em contraste com provas otimistas e de conhecimento zero de rollups, rollups soberanos não validam raízes estatais no Ethereum e dependem apenas da disponibilidade de dados e consenso no Ethereum. Isso evita pontes de minimização de confiança entre L1 e BYOR, mas simplifica muito o código e é ideal para fins educacionais.
A base de código consiste em três programas: contratos inteligentes, nós e carteiras. Quando implantados juntos, eles permitem que os usuários finais interajam com a rede. Curiosamente, o estado da rede é determinado inteiramente por dados on-chain, o que significa que vários nós podem realmente ser executados. Cada nó também pode publicar dados independentemente como um sequenciador.
Aqui está a lista completa de recursos implementados no BYOR:
Taxa de classificação
Postar status para L1 e obter status de L1
Descartar transações inválidas
Verifique o saldo da conta
Enviar transações
Verifique o status da transação
Use a carteira
Em um aplicativo de carteira, ele atua como o front-end da rede, onde os usuários podem enviar transações e verificar o status de suas contas ou o status das transações. Na página de destino, você verá uma visão geral que fornece algumas estatísticas sobre o status atual do Rollup, seguido pelo status da sua conta. Muito provavelmente, há apenas um botão para se conectar à carteira de sua escolha e há notícias sobre a torneira do token. Abaixo, há uma barra de pesquisa onde você pode colar o endereço de alguém ou hash de transação para explorar o estado atual de L2. Finalmente, existem duas listas de transações: a primeira é a lista de transações no mempool L2 e a segunda é a lista de transações publicadas em L1.
Para começar, use o botão WalletConnect para conectar sua carteira. Uma vez conectado, você pode receber uma notificação de que sua carteira está conectada à rede errada. Se a sua aplicação suportar comutação de rede, clique no botão Mudar de rede para mudar para a rede de teste Holesky. Caso contrário, mude manualmente.
Agora você pode enviar tokens para alguém fornecendo o endereço do destinatário, o número de tokens a serem enviados e as taxas necessárias. Uma vez enviado, o aplicativo de carteira solicitará que você assine a mensagem. Se assinada com êxito, a mensagem é enviada para o pool de memória do nó L2, aguardando para ser publicada em L1. O tempo necessário para que uma transação seja agrupada em uma liberação em lote pode variar. A cada 10 segundos, o nó L2 verifica o conteúdo a ser publicado. As transações com taxas mais altas são enviadas primeiro, portanto, se você especificar taxas mais baixas e tiver muito tráfego de transações, poderá enfrentar longos tempos de espera.
Como funciona
Diagrama de arquitetura de rollup ## pilha de tecnologia
Construímos cada componente utilizando as seguintes técnicas:
O código BYOR é projetado para ser facilmente compreendido olhando para a base de código. Sinta-se livre para explorar nossa base de código! Primeiro leia README.md, para entender a estrutura do projeto, leia o arquivo ARCHITECTURE.md.
Aqui estão alguns destaques interessantes do código:
Contratos inteligentes
SPDX-Licença-Identificador: MIT
Solidez do Pragma ^0.8.0;
contrato de insumos {
evento BatchAppended(remetente do endereço);
função appendBatch(bytes calldata) externo {
require(msg.sender == tx.origin);
emitir BatchAppended(msg.sender);
}
}
Este é o único contrato inteligente necessário. Seu nome deriva do fato de que as entradas são armazenadas em funções de transição de estado. O único objetivo deste contrato é armazenar convenientemente todas as transações. O lote serializado é publicado neste contrato inteligente como calldata e emite um evento BatchAppended com o endereço do editor do lote. Embora possamos projetar o sistema para que ele publique transações diretamente no EOA em vez de contratos, os dados podem ser facilmente obtidos via JSON-RPC emitindo eventos. O único requisito para este contrato inteligente é que ele não deve ser chamado de outro contrato inteligente, mas diretamente do EOA.
Esquema de banco de dados
CRIAR CONTAS DE TABELA (
texto do endereço CHAVE PRIMÁRIA NÃO NULA,
saldo inteiro DEFAULT 0 NOT NULL,
nonce inteiro DEFAULT 0 NOT NULL
);
CRIAR transações TABLE (
id inteiro,
do texto NOT NULL,
para texto NOT NULL,
valor inteiro NÃO NULO,
nonce inteiro NÃO NULO,
número inteiro da taxa NÃO NULO,
feeReceipent texto NÃO NULO,
l1SubmittedDate inteiro NÃO NULL,
texto hash NÃO NULO
CHAVE PRIMÁRIA (de, nonce)
);
-- Esta tabela tem uma única linha
CREATE TABLE fetcherStates (
Inteiro chainId CHAVE PRIMÁRIA NÃO NULA,
lastFetchedBlock inteiro DEFAULT 0 NOT NULL
);
Este é todo o esquema de banco de dados usado para armazenar informações sobre o Rollup. Você pode estar se perguntando por que precisamos de um banco de dados quando todos os dados necessários são armazenados em L1. Embora isso seja verdade, armazenar dados localmente pode economizar tempo e recursos, evitando aquisições duplicadas. Trate todos os dados armazenados nesse esquema como memorandos de status, hashes de transação e outras informações calculadas.
A tabela fetcherStates é usada para acompanhar o último bloco que buscamos ao pesquisar o evento BatchAppended. Isso é útil quando o nó é desligado e reiniciado; Ele sabe onde retomar a busca.
As funções mostradas acima estão no centro do mecanismo de transição de estado no BYOR. Pressupõe que a transação pode ser executada com segurança, com o nonce correto e saldo suficiente para fazer o pagamento definido. Devido a essa suposição, não há nenhuma manipulação de erros ou etapas de validação dentro dessa função. Em vez disso, essas etapas são executadas antes que a função seja chamada. Cada estado da conta é armazenado em um mapa. Se uma conta ainda não existir nesse mapeamento, ela será definida como o valor padrão visível na parte superior da listagem de código. Das três contas utilizadas, o nonce é atualizado e o saldo é atribuído.
Assinatura de Transação
Assinatura de transação: usamos o padrão EIP-712 para assinar dados digitados. Isso nos permite mostrar claramente aos usuários o que eles estão assinando. Como mostrado acima, ao enviar uma transação, podemos exibir o destinatário, o valor e a taxa de uma maneira amigável.
L1 evento obter
função getNewStates() {
const lastBatchBlock = getLastBatchBlock()
const eventos = getLogs(lastBatchBlock)
const calldata = getCalldata(eventos)
const timestamps = getTimestamps(eventos)
const posters = getTransactionPosters(eventos)
updateLastFetchedBlock(lastBatchBlock)
zip de retorno (cartazes, carimbos de data/hora, dados de chamada)
}
Para obter o novo evento, recuperamos todos os eventos BatchAppended do último bloco buscado do contrato de entradas. O número máximo de eventos que recuperamos é o bloco mais recente ou o último bloco buscado mais o limite de tamanho de lote. Depois de recuperar todos os eventos, extraímos os dados de chamada, o carimbo de data/hora e o endereço do editor de cada transação. Atualize o último bloco que buscamos para o último bloco que estamos buscando. Os dados de chamada extraídos, o carimbo de data/hora e o editor são então empacotados juntos e retornados da função para processamento posterior.
Pools de memória e sua classificação de custos
function popNHighestFee(txPool, n) {
txPool.sort((a, b) => b.fee - a.fee))
retornar txPool.splice(0, n)
}
Um mempool é um objeto que gerencia uma matriz de transações assinadas. O aspeto mais interessante é como ele determina a ordem em que as transações são lançadas em L1. Como mostrado no código acima, as transações são classificadas de acordo com suas taxas. Isso permite que o preço médio da taxa no sistema flutue com base na atividade on-chain.
Mesmo que você especifique taxas altas, as transações ainda precisam produzir um estado válido se precisarem ser anexadas ao estado atual. Portanto, você não pode enviar transações inválidas apenas por causa de altas taxas.
A BYOR realmente escala o Ethereum?
O otimismo e o rollup ZK construíram sistemas para provar que as raízes estatais publicadas são consistentes com as funções de transição do estado e os dados que elas comprometem, mas os rollups soberanos não. Portanto, a incapacidade desse tipo de rollup para escalar o Ethereum pode parecer contraintuitiva no início. No entanto, isso se torna razoável quando percebemos que outros tipos de rollups podem usar apenas L1 para provar que a raiz de estado publicada está correta. Para distinguir se os dados do rollup soberano estão corretos ou não, precisamos executar um nó L1 juntamente com software adicional para formalizar o nó L2 para executar funções de transição de estado, aumentando assim a carga computacional.
Perspetivas futuras
Construir este projeto foi um grande aprendizado para nós, e esperamos que você ache nossos esforços valiosos também. Esperamos voltar à BYOR no futuro e adicionar um sistema à prova de fraude. Isso fará com que seja um rollup verdadeiramente otimista e, mais uma vez, uma lição sobre o funcionamento interno dos sistemas que usamos todos os dias.
Ver original
Esta página pode conter conteúdo de terceiros, que é fornecido apenas para fins informativos (não para representações/garantias) e não deve ser considerada como um endosso de suas opiniões pela Gate nem como aconselhamento financeiro ou profissional. Consulte a Isenção de responsabilidade para obter detalhes.
Crie seu próprio Rollup – uma lista de projetos BYOR
Compilação: Plano de tradução Denlink
Você já quis saber mais sobre como o Rollup funciona? A teoria é boa, mas a experiência prática é sempre preferível. Infelizmente, os projetos existentes nem sempre facilitam a visualização do que está acontecendo. É por isso que criamos o BYOR (Build Your Own Rollup). É um pacote cumulativo soberano com funcionalidade mínima, com foco em tornar o código fácil de ler e entender.
Nossa motivação para este projeto é que as pessoas, tanto de fora quanto de dentro, entendam melhor o que os rollups ao nosso redor estão realmente fazendo. Você pode brincar no BYOR implantado da Holesky ou ler o código-fonte no GitHub.
O que é BYOR?
O projeto BYOR é uma versão simplificada do pacote cumulativo soberano. Em contraste com provas otimistas e de conhecimento zero de rollups, rollups soberanos não validam raízes estatais no Ethereum e dependem apenas da disponibilidade de dados e consenso no Ethereum. Isso evita pontes de minimização de confiança entre L1 e BYOR, mas simplifica muito o código e é ideal para fins educacionais.
A base de código consiste em três programas: contratos inteligentes, nós e carteiras. Quando implantados juntos, eles permitem que os usuários finais interajam com a rede. Curiosamente, o estado da rede é determinado inteiramente por dados on-chain, o que significa que vários nós podem realmente ser executados. Cada nó também pode publicar dados independentemente como um sequenciador.
Aqui está a lista completa de recursos implementados no BYOR:
Use a carteira
Em um aplicativo de carteira, ele atua como o front-end da rede, onde os usuários podem enviar transações e verificar o status de suas contas ou o status das transações. Na página de destino, você verá uma visão geral que fornece algumas estatísticas sobre o status atual do Rollup, seguido pelo status da sua conta. Muito provavelmente, há apenas um botão para se conectar à carteira de sua escolha e há notícias sobre a torneira do token. Abaixo, há uma barra de pesquisa onde você pode colar o endereço de alguém ou hash de transação para explorar o estado atual de L2. Finalmente, existem duas listas de transações: a primeira é a lista de transações no mempool L2 e a segunda é a lista de transações publicadas em L1.
Para começar, use o botão WalletConnect para conectar sua carteira. Uma vez conectado, você pode receber uma notificação de que sua carteira está conectada à rede errada. Se a sua aplicação suportar comutação de rede, clique no botão Mudar de rede para mudar para a rede de teste Holesky. Caso contrário, mude manualmente.
Agora você pode enviar tokens para alguém fornecendo o endereço do destinatário, o número de tokens a serem enviados e as taxas necessárias. Uma vez enviado, o aplicativo de carteira solicitará que você assine a mensagem. Se assinada com êxito, a mensagem é enviada para o pool de memória do nó L2, aguardando para ser publicada em L1. O tempo necessário para que uma transação seja agrupada em uma liberação em lote pode variar. A cada 10 segundos, o nó L2 verifica o conteúdo a ser publicado. As transações com taxas mais altas são enviadas primeiro, portanto, se você especificar taxas mais baixas e tiver muito tráfego de transações, poderá enfrentar longos tempos de espera.
Como funciona
Construímos cada componente utilizando as seguintes técnicas:
Detalhamento do código
O código BYOR é projetado para ser facilmente compreendido olhando para a base de código. Sinta-se livre para explorar nossa base de código! Primeiro leia README.md, para entender a estrutura do projeto, leia o arquivo ARCHITECTURE.md.
Aqui estão alguns destaques interessantes do código:
Contratos inteligentes
SPDX-Licença-Identificador: MIT
Solidez do Pragma ^0.8.0;
contrato de insumos {
evento BatchAppended(remetente do endereço);
função appendBatch(bytes calldata) externo {
require(msg.sender == tx.origin);
emitir BatchAppended(msg.sender);
}
}
Este é o único contrato inteligente necessário. Seu nome deriva do fato de que as entradas são armazenadas em funções de transição de estado. O único objetivo deste contrato é armazenar convenientemente todas as transações. O lote serializado é publicado neste contrato inteligente como calldata e emite um evento BatchAppended com o endereço do editor do lote. Embora possamos projetar o sistema para que ele publique transações diretamente no EOA em vez de contratos, os dados podem ser facilmente obtidos via JSON-RPC emitindo eventos. O único requisito para este contrato inteligente é que ele não deve ser chamado de outro contrato inteligente, mas diretamente do EOA.
Esquema de banco de dados
CRIAR CONTAS DE TABELA (
texto do endereço CHAVE PRIMÁRIA NÃO NULA,
saldo inteiro DEFAULT 0 NOT NULL,
nonce inteiro DEFAULT 0 NOT NULL
);
CRIAR transações TABLE (
id inteiro,
do texto NOT NULL,
para texto NOT NULL,
valor inteiro NÃO NULO,
nonce inteiro NÃO NULO,
número inteiro da taxa NÃO NULO,
feeReceipent texto NÃO NULO,
l1SubmittedDate inteiro NÃO NULL,
texto hash NÃO NULO
CHAVE PRIMÁRIA (de, nonce)
);
-- Esta tabela tem uma única linha
CREATE TABLE fetcherStates (
Inteiro chainId CHAVE PRIMÁRIA NÃO NULA,
lastFetchedBlock inteiro DEFAULT 0 NOT NULL
);
Este é todo o esquema de banco de dados usado para armazenar informações sobre o Rollup. Você pode estar se perguntando por que precisamos de um banco de dados quando todos os dados necessários são armazenados em L1. Embora isso seja verdade, armazenar dados localmente pode economizar tempo e recursos, evitando aquisições duplicadas. Trate todos os dados armazenados nesse esquema como memorandos de status, hashes de transação e outras informações calculadas.
A tabela fetcherStates é usada para acompanhar o último bloco que buscamos ao pesquisar o evento BatchAppended. Isso é útil quando o nó é desligado e reiniciado; Ele sabe onde retomar a busca.
Funções de transição de estado
const DEFAULT_ACCOUNT = { saldo: 0, nonce: 0 }
function uteTransaction(state, tx, feeRecipient) {
const fromAccount = getAccount(estado, tx.from, DEFAULT_ACCOUNT)
const toAccount = getAccount(estado, tx.to, DEFAULT_ACCOUNT)
Passo 1 Atualizar nonce
fromAccount.nonce = tx.nonce
Passo 2 Transferir valor
fromAccount.balance -= tx.value
toAccount.balance += tx.value
Passo 3 Pagar taxa
fromAccount.balance -= tx.fee
feeRecipientAccount.balance += tx.fee
}
As funções mostradas acima estão no centro do mecanismo de transição de estado no BYOR. Pressupõe que a transação pode ser executada com segurança, com o nonce correto e saldo suficiente para fazer o pagamento definido. Devido a essa suposição, não há nenhuma manipulação de erros ou etapas de validação dentro dessa função. Em vez disso, essas etapas são executadas antes que a função seja chamada. Cada estado da conta é armazenado em um mapa. Se uma conta ainda não existir nesse mapeamento, ela será definida como o valor padrão visível na parte superior da listagem de código. Das três contas utilizadas, o nonce é atualizado e o saldo é atribuído.
Assinatura de Transação
L1 evento obter
função getNewStates() {
const lastBatchBlock = getLastBatchBlock()
const eventos = getLogs(lastBatchBlock)
const calldata = getCalldata(eventos)
const timestamps = getTimestamps(eventos)
const posters = getTransactionPosters(eventos)
updateLastFetchedBlock(lastBatchBlock)
zip de retorno (cartazes, carimbos de data/hora, dados de chamada)
}
Para obter o novo evento, recuperamos todos os eventos BatchAppended do último bloco buscado do contrato de entradas. O número máximo de eventos que recuperamos é o bloco mais recente ou o último bloco buscado mais o limite de tamanho de lote. Depois de recuperar todos os eventos, extraímos os dados de chamada, o carimbo de data/hora e o endereço do editor de cada transação. Atualize o último bloco que buscamos para o último bloco que estamos buscando. Os dados de chamada extraídos, o carimbo de data/hora e o editor são então empacotados juntos e retornados da função para processamento posterior.
Pools de memória e sua classificação de custos
function popNHighestFee(txPool, n) {
txPool.sort((a, b) => b.fee - a.fee))
retornar txPool.splice(0, n)
}
Um mempool é um objeto que gerencia uma matriz de transações assinadas. O aspeto mais interessante é como ele determina a ordem em que as transações são lançadas em L1. Como mostrado no código acima, as transações são classificadas de acordo com suas taxas. Isso permite que o preço médio da taxa no sistema flutue com base na atividade on-chain.
Mesmo que você especifique taxas altas, as transações ainda precisam produzir um estado válido se precisarem ser anexadas ao estado atual. Portanto, você não pode enviar transações inválidas apenas por causa de altas taxas.
A BYOR realmente escala o Ethereum?
O otimismo e o rollup ZK construíram sistemas para provar que as raízes estatais publicadas são consistentes com as funções de transição do estado e os dados que elas comprometem, mas os rollups soberanos não. Portanto, a incapacidade desse tipo de rollup para escalar o Ethereum pode parecer contraintuitiva no início. No entanto, isso se torna razoável quando percebemos que outros tipos de rollups podem usar apenas L1 para provar que a raiz de estado publicada está correta. Para distinguir se os dados do rollup soberano estão corretos ou não, precisamos executar um nó L1 juntamente com software adicional para formalizar o nó L2 para executar funções de transição de estado, aumentando assim a carga computacional.
Perspetivas futuras
Construir este projeto foi um grande aprendizado para nós, e esperamos que você ache nossos esforços valiosos também. Esperamos voltar à BYOR no futuro e adicionar um sistema à prova de fraude. Isso fará com que seja um rollup verdadeiramente otimista e, mais uma vez, uma lição sobre o funcionamento interno dos sistemas que usamos todos os dias.