A maioria das pessoas fala sobre a escalabilidade do Blockchain, focando apenas neste jogo numérico de throughput.

Transações comprimidas? Comprimidas. Prova de compressão? Comprimida. Caminho de dados comprimido, algoritmo de ordenação comprimido... De qualquer forma, contanto que os números de TPS fiquem bonitos, pode-se comprimir como quiser. Do ponto de vista da engenharia, isso não tem erro — manter a velocidade sob alta carga, quem não gostaria?

Mas aqui há um problema fatal: um verdadeiro sistema de liquidação nunca brinca com essa estratégia de compressão.

O que a liquidação precisa não é "poder ser comprimido", mas sim "não poder ser comprimido".

Por quê? Porque a lógica, uma vez comprimida, a responsabilidade se transforma.

Pense nisso: quando o sistema simplifica a lógica, rearranja os caminhos e muda a ordem de execução sob alta carga - em qual versão o resultado da transação deve ser calculado? Com baixa pressão, uma lógica; com alta pressão, outra lógica. Se houver problemas, quem é responsável? Legalmente, não há como atribuir responsabilidade.

A regra de ferro do sistema de liquidação é: independentemente da situação, só pode haver uma explicação.

Mas a blockchain é naturalmente propensa a "deformar-se" sob pressão:
Nós perdemos mensagens nos nós, o mempool é reordenado, a janela de execução é encurtada, o caminho de validação é encurtado, eventos de transmissão são descartados, bifurcações de consenso aparecem temporariamente, e o tempo de confirmação de finalização é prolongado...

Estas são operações rotineiras para a blockchain, mas inseridas no sistema de liquidação? Cada uma é uma bomba-relógio.

A abordagem de design do Plasma é diferente. Ele constrói uma rede de liquidação estruturada - não importa quão pesada seja a carga ou quão grande seja a escala, a lógica estrutural permanece inalterada e o caminho permanece estável.

Esta é a cadeia que realmente alcança a "incompressibilidade lógica". É rara na indústria.