O principal benefício é reduzir a quantidade de dados armazenados no Ethereum, reduzindo assim o custo para os usuários realizarem transações no L2.
**Escrito por: **OneTrueKirk
** Compilado por: Yvonne, MarsBit **
Postagem original de OneTrueKirk em ethresear.ch
Esta é minha primeira vez postando sobre um tópico aqui, então peço desculpas se eu te ofendi de alguma forma. Tenho pensado nessa ideia (Stateless Rollups) principalmente para rollups dedicados para nosso protocolo de empréstimo, mas espero que possa ser aplicável em geral, qualquer feedback é apreciado.
TLDR:
Somente a raiz do status é publicada, não o calldata.
(Nota MarsBit: Calldata é o valor da parte de dados na transação do contrato e não pode ser modificado.)
detalhe
E se, em vez de usar o Ethereum como uma camada de disponibilidade de dados, publicasse o estado completo como calldata e publicasse apenas a raiz do estado na rede principal? O principal benefício é reduzir a quantidade de dados armazenados no Ethereum, reduzindo assim o custo para os usuários realizarem transações no L2. Mesmo com EIP-4844, o blobace não é gratuito.
O principal risco é um ataque de retenção de dados, em que um proponente publica uma raiz de estado válida, mas retém dados completos de outros nós de rollup para monopolizar a futura produção de blocos ou manter os fundos como reféns. Para evitar isso, os nós honestos devem questionar qualquer atualização de estado para a qual nenhum par pode fornecer dados. As provas de fraude interativas no estilo arbitram podem ser usadas para forçar os proponentes a divulgar o estado completo na rede principal, mas ainda causar a falha do desafio se a raiz for válida; portanto, mesmo no caso de falha, o custo do desafio é baixo.
(Nota da MarsBit: Ataque de Retenção de Dados refere-se a um invasor que deliberadamente não retorna todos os dados ou retorna dados errados ao acessar dados protegidos, a fim de atingir o objetivo de enganar ou destruir.
Se o custo de uma falha de desafio for baixo, os proponentes honestos podem ficar infelizes ao forçá-los a pagar pela postagem de todos os seus dados de estado na rede principal em defesa do desafio, mesmo que tenham propagado os dados de estado ponto a ponto corretamente. O custo de iniciar uma contestação deve ser proporcional ao custo da defesa para garantir que proponentes honestos não sejam atacados dessa forma.
No pior caso, se um invasor puder gastar US$ 1 para custar US$ 1 a um proponente honesto, ele poderá forçar o proponente a desistir e recuperar o bloqueio. Um novo proponente honesto pode então licitar e, a menos que o invasor possa repetir o ataque a todos os possíveis proponentes honestos, o que inclui todos com fundos, eles não podem causar um tempo de inatividade permanente. É possível adicionar outra cláusula, onde o custo do desafio aumenta quando muito tempo se passou desde que um bloco válido foi finalizado. Dessa forma, é fácil desafiar um proponente desonesto, mas impossível interromper as transições de estado por muito tempo.
De forma mais otimista, se os nós espalharem dados entre pares, eles podem decidir suas próprias soluções de backup e acessibilidade de dados, e os usuários ficam melhor armazenando localmente os dados de que precisam para suas próprias transições de estado. No contexto de um aplicativo específico, pensei em codificar o estado de rollup de uma maneira completamente diferente do EVM para otimizar isso. Todos os estados associados a uma conta de usuário específica podem ser codificados no mesmo hash, para que os usuários possam verificar mais facilmente as alterações em suas contas sem conhecer o estado global (ou seja, confirmar que você recebeu o número de tokens sem se preocupar com a origem deles).
Resumir
Eu adoraria ouvir seus pensamentos e gostaria de receber links para trabalhos relacionados. Ao contrário do rollup otimista comum, no rollup otimista é fácil determinar se os dados de chamada enviados correspondem à raiz do estado da rede principal e se ambos são válidos, mas é impossível saber se uma atualização é válida apenas a partir da raiz do estado, então é necessário considerar cuidadosamente a economia dos períodos de desafio e luto (ou seja, comportamento malicioso).
Ver original
O conteúdo é apenas para referência, não uma solicitação ou oferta. Nenhum aconselhamento fiscal, de investimento ou jurídico é fornecido. Consulte a isenção de responsabilidade para obter mais informações sobre riscos.
Uma rápida olhada nas vantagens e problemas potenciais do acúmulo sem estado
**Escrito por: **OneTrueKirk
** Compilado por: Yvonne, MarsBit **
Postagem original de OneTrueKirk em ethresear.ch
Esta é minha primeira vez postando sobre um tópico aqui, então peço desculpas se eu te ofendi de alguma forma. Tenho pensado nessa ideia (Stateless Rollups) principalmente para rollups dedicados para nosso protocolo de empréstimo, mas espero que possa ser aplicável em geral, qualquer feedback é apreciado.
TLDR:
Somente a raiz do status é publicada, não o calldata.
(Nota MarsBit: Calldata é o valor da parte de dados na transação do contrato e não pode ser modificado.)
detalhe
E se, em vez de usar o Ethereum como uma camada de disponibilidade de dados, publicasse o estado completo como calldata e publicasse apenas a raiz do estado na rede principal? O principal benefício é reduzir a quantidade de dados armazenados no Ethereum, reduzindo assim o custo para os usuários realizarem transações no L2. Mesmo com EIP-4844, o blobace não é gratuito.
O principal risco é um ataque de retenção de dados, em que um proponente publica uma raiz de estado válida, mas retém dados completos de outros nós de rollup para monopolizar a futura produção de blocos ou manter os fundos como reféns. Para evitar isso, os nós honestos devem questionar qualquer atualização de estado para a qual nenhum par pode fornecer dados. As provas de fraude interativas no estilo arbitram podem ser usadas para forçar os proponentes a divulgar o estado completo na rede principal, mas ainda causar a falha do desafio se a raiz for válida; portanto, mesmo no caso de falha, o custo do desafio é baixo.
(Nota da MarsBit: Ataque de Retenção de Dados refere-se a um invasor que deliberadamente não retorna todos os dados ou retorna dados errados ao acessar dados protegidos, a fim de atingir o objetivo de enganar ou destruir.
Se o custo de uma falha de desafio for baixo, os proponentes honestos podem ficar infelizes ao forçá-los a pagar pela postagem de todos os seus dados de estado na rede principal em defesa do desafio, mesmo que tenham propagado os dados de estado ponto a ponto corretamente. O custo de iniciar uma contestação deve ser proporcional ao custo da defesa para garantir que proponentes honestos não sejam atacados dessa forma.
No pior caso, se um invasor puder gastar US$ 1 para custar US$ 1 a um proponente honesto, ele poderá forçar o proponente a desistir e recuperar o bloqueio. Um novo proponente honesto pode então licitar e, a menos que o invasor possa repetir o ataque a todos os possíveis proponentes honestos, o que inclui todos com fundos, eles não podem causar um tempo de inatividade permanente. É possível adicionar outra cláusula, onde o custo do desafio aumenta quando muito tempo se passou desde que um bloco válido foi finalizado. Dessa forma, é fácil desafiar um proponente desonesto, mas impossível interromper as transições de estado por muito tempo.
De forma mais otimista, se os nós espalharem dados entre pares, eles podem decidir suas próprias soluções de backup e acessibilidade de dados, e os usuários ficam melhor armazenando localmente os dados de que precisam para suas próprias transições de estado. No contexto de um aplicativo específico, pensei em codificar o estado de rollup de uma maneira completamente diferente do EVM para otimizar isso. Todos os estados associados a uma conta de usuário específica podem ser codificados no mesmo hash, para que os usuários possam verificar mais facilmente as alterações em suas contas sem conhecer o estado global (ou seja, confirmar que você recebeu o número de tokens sem se preocupar com a origem deles).
Resumir
Eu adoraria ouvir seus pensamentos e gostaria de receber links para trabalhos relacionados. Ao contrário do rollup otimista comum, no rollup otimista é fácil determinar se os dados de chamada enviados correspondem à raiz do estado da rede principal e se ambos são válidos, mas é impossível saber se uma atualização é válida apenas a partir da raiz do estado, então é necessário considerar cuidadosamente a economia dos períodos de desafio e luto (ou seja, comportamento malicioso).