Na cadeia Plasma, a estrutura básica do bloco é semelhante à de uma cadeia normal, com transações e mudanças de estado sendo concluídas dentro da subcadeia. Mas, desde o início do seu design, o Plasma não foi pensado para que a cadeia principal tivesse controle sobre esses detalhes.
Após a geração de cada novo bloco, o que o operador faz é simples — hash de todas as transações e dados de estado dentro do bloco, gerando uma Merkle Root (algumas implementações usam a Root de transações, outras usam a Root de estado ou UTXO).
Essa Root na verdade é:
"Impressão digital completa da história até este bloco."
Esta é a primeira camada de compressão. Independentemente de quantas transações o bloco contenha, a cadeia principal só precisa verificar um valor hash de comprimento fixo.
Depois, ocorre uma segunda camada de compressão. O Plasma não quer subir na cadeia um bloco de cada vez, mas acumular informações de cabeçalho de vários blocos e agrupá-las em uma Root de nível superior. No final, o que a cadeia principal recebe geralmente não é o cabeçalho de um único bloco, mas uma promessa unificada do estado do Plasma ao longo de um período de tempo.
O que a cadeia principal vê por fim é muito resumido: • Número do bloco ou intervalo de tempo • Valor da Root correspondente • Timestamp necessário
A cadeia principal não valida transações nem armazena dados, apenas mantém essas Roots como prova imutável do tempo.
Somente quando alguém deseja fazer uma retirada ou questionar algo, é que você precisa apresentar os dados da transação e a prova de Merkle para fazer a reconciliação com esses cabeçalhos de bloco.
Normalmente, não se faz contas, só se faz quando há problemas — essa é a lógica central de por que o Plasma comprime os cabeçalhos de bloco antes de enviá-los para a cadeia principal.
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.
13 Curtidas
Recompensa
13
9
Repostar
Compartilhar
Comentário
0/400
BlockchainNewbie
· 01-21 12:37
Caramba, essa lógica de compressão é genial, é um design preguiçoso de culpar os outros hahaha
Ver originalResponder0
APY追逐者
· 01-20 19:58
Porra, isto é o núcleo do Plasma, normalmente tenho preguiça de verificar, quando acontece algo, revisito as contas antigas haha
Ver originalResponder0
fomo_fighter
· 01-18 16:56
Oh, então esta é a "técnica de preguiça" do Plasma, normalmente não se preocupa com a mainnet, só revisa as contas antigas quando acontece algum problema.
Ver originalResponder0
ApeEscapeArtist
· 01-18 13:59
Oh, não é isso que chamam de arte de preguiça? A cadeia principal diz que não olha os detalhes, só verifica a impressão digital, e só revisa o livro-razão quando dá problema?
Ver originalResponder0
IntrovertMetaverse
· 01-18 13:57
Entendi, é a arte de ser preguiçoso do Plasma, deixando todo o trabalho sujo e cansativo para as subcadeias, enquanto a cadeia principal só cuida de receber as entregas.
Ver originalResponder0
token_therapist
· 01-18 13:56
Incrível, é só que é preguiçoso em fazer a cadeia principal se preocupar, e só apresenta provas quando necessário. Essa filosofia de design ainda tem algum valor.
Ver originalResponder0
WalletDetective
· 01-18 13:55
Esta lógica de compressão é genial, é o auge da criptografia preguiçosa, geralmente fica de braços cruzados e só revisa as contas antigas quando acontece algum problema.
Ver originalResponder0
FallingLeaf
· 01-18 13:50
Ai, esta lógica de compressão é genial, normalmente só armazena a impressão digital, e só verifica o livro razão em caso de problema, é realmente uma arte de preguiça
Ver originalResponder0
SleepyArbCat
· 01-18 13:41
Ai, esta coisa... é a arte de ser preguiçoso, quanto menos trabalho na mainnet, melhor...
Na cadeia Plasma, a estrutura básica do bloco é semelhante à de uma cadeia normal, com transações e mudanças de estado sendo concluídas dentro da subcadeia. Mas, desde o início do seu design, o Plasma não foi pensado para que a cadeia principal tivesse controle sobre esses detalhes.
Após a geração de cada novo bloco, o que o operador faz é simples — hash de todas as transações e dados de estado dentro do bloco, gerando uma Merkle Root (algumas implementações usam a Root de transações, outras usam a Root de estado ou UTXO).
Essa Root na verdade é:
"Impressão digital completa da história até este bloco."
Esta é a primeira camada de compressão. Independentemente de quantas transações o bloco contenha, a cadeia principal só precisa verificar um valor hash de comprimento fixo.
Depois, ocorre uma segunda camada de compressão. O Plasma não quer subir na cadeia um bloco de cada vez, mas acumular informações de cabeçalho de vários blocos e agrupá-las em uma Root de nível superior. No final, o que a cadeia principal recebe geralmente não é o cabeçalho de um único bloco, mas uma promessa unificada do estado do Plasma ao longo de um período de tempo.
O que a cadeia principal vê por fim é muito resumido:
• Número do bloco ou intervalo de tempo
• Valor da Root correspondente
• Timestamp necessário
A cadeia principal não valida transações nem armazena dados, apenas mantém essas Roots como prova imutável do tempo.
Somente quando alguém deseja fazer uma retirada ou questionar algo, é que você precisa apresentar os dados da transação e a prova de Merkle para fazer a reconciliação com esses cabeçalhos de bloco.
Normalmente, não se faz contas, só se faz quando há problemas — essa é a lógica central de por que o Plasma comprime os cabeçalhos de bloco antes de enviá-los para a cadeia principal.