En la cadena Plasma, la estructura básica de los bloques es similar a la de una cadena normal, y las transacciones y cambios de estado se realizan dentro de la subcadena. Pero desde el diseño inicial, Plasma no pretendía que la cadena principal manejara estos detalles.

Cada vez que se genera un nuevo bloque, lo que hace el operador es muy simple: hash de todas las transacciones y datos de estado dentro del bloque, y generar un Merkle Root (algunas implementaciones usan el Root de transacciones, otras usan el Root de estado o UTXO).

Este Root en realidad es:

"la huella completa de la historia hasta este bloque."

Esta es la primera capa de compresión. Sin importar cuántas transacciones contenga el bloque, al final la cadena principal solo necesita ver un valor hash de longitud fija.

Luego ocurre una segunda capa de compresión. Plasma no se apresura a subir cada bloque individualmente a la cadena, sino que acumula la información de cabecera de varios bloques y la empaqueta en un Root de nivel superior. Finalmente, lo que recibe la cadena principal no suele ser la cabecera de un solo bloque, sino una declaración unificada del estado de Plasma en un período de tiempo.

Lo que la cadena principal ve al final es muy simplificado:
• Número de bloque o intervalo de tiempo
• El valor Root correspondiente
• La marca de tiempo necesaria

La cadena principal no verifica las transacciones ni almacena datos, solo mantiene estos Roots como prueba inalterable del tiempo.

Hasta que alguien quiera retirar fondos o presentar una disputa, solo necesita tener los datos de la transacción y la prueba Merkle para cotejar con estas cabeceras de bloques y hacer la conciliación.

No se hace cuentas normalmente, solo se hace cuando hay un problema — esa es la lógica central de por qué Plasma comprime las cabeceras de los bloques antes de enviarlas a la cadena principal.