@Plasma inicialmente no estaba destinado a ser el camino fácil para salir de las restricciones de rendimiento de Ethereum. Desde el principio de sus formulaciones, Plasma convirtió el problema de escalar en un problema de restricciones, en lugar de un problema de capacidad bruta. En segundo lugar, en lugar de poner más computación en un bloque base, en realidad limitó lo que se podía realizar fuera de la cadena, para mantener una promesa delgada y crítica: uno siempre debería poder, en cualquier caso, regresar de manera segura a Ethereum. Es esa elección de diseño la que hace que Plasma sea fundamentalmente diferente de muchos métodos de escalado posteriores--y también la confusión detrás de la disponibilidad de Plasma.
En su esencia más básica, @Plasma ve a Ethereum como un último recurso de arbitraje en lugar de una capa de ejecución. Las transiciones de estado, la computación y el orden de la transacción se descargan en cadenas hijas. Ethernet simplemente tiene compromisos ocasionales, raíces de Merkle que capturan el estado de tales cadenas. Esta separación minimiza significativamente la carga en cadena, a costa de que Ethereum ya no garantice la corrección de cada transición. Sin embargo, Plasma hace la suposición de que el comportamiento incorrecto será confrontado y no prevenido. La escalabilidad es el reconocimiento de tal restricción.
Aquí el enfoque de @Plasma sobre los mecanismos de salida entra en juego. Dado que Ethereum no autentica todas las transacciones, Plasma tiene que emitir a los usuarios medios criptográficos y procedimentales para redimir su dinero de manera unilateral. Las características periféricas de los juegos de salida, los períodos de desafío y las pruebas de fraude son la columna vertebral del sistema. Cada elección de diseño en Plasma: la presencia de utxo-basados, las diversas formas de modelos, cualquier restricción sobre la expresividad del contrato inteligente, comprar en un tiempo de retiro más largo está dictada por la propiedad de que la salida es predeciblemente verificable y ejecutable en Ethereum en circunstancias adversas.
A la luz de esto, @Plasma no es óptimo en rendimiento en el significado tradicional del término. No se esfuerza por maximizar el número de transacciones por segundo y aún ser completamente general. Más bien, limita la funcionalidad hasta el punto en que incluso el peor de los casos puede sobrevivir. Cuando un operador retiene datos, prohíbe a los usuarios (o entrega raíces de estado incorrectas), el sistema no se bloquea por completo, sino que entra en el proceso de salida. Esta filosofía de escalabilidad es muy diferente a los rollups en los que Ethereum reejecuta o vuelve a verificar la computación fuera de la cadena para garantizar garantías más fuertes.
Estas limitaciones son la causa de muchas de las verdaderas limitaciones de @Plasma . Los contratos inteligentes de propósito general son difíciles de soportar, ya que las salidas deben ser expresables y cuestionables en Ethereum. La disponibilidad de datos es la suposición de que es externa y implica que los usuarios o vigilantes deben rastrear activamente la cadena. El concepto de salidas masivas, aunque hipotéticamente seguro, crea la amenaza de congestión en Ethereum. Todas estas no son algunas deficiencias accidentales; son resultados directos de considerar la seguridad de la salida sobre la flexibilidad de la ejecución.
También es una consecuencia de ver @Plasma como un sistema de restricciones que no ha sido la solución de escalado elegida aunque es algo hermoso de hacer. Con el desarrollo de Ethereum, más modelos que reemplazan los altos costos de verificación en cadena por garantías de usuario más fáciles se han aceptado en el ecosistema. Los rollups transfieren más computación al modelo de seguridad de Ethereum, por lo que los usuarios no necesitan actuar en defensa de sus fondos. Plasma, por otro lado, requiere vigilancia y está dispuesto a tolerar la complejidad para poder tener una pequeña huella en cadena.
Pero las ideas de @Plasma aún tienen su efecto. La aislación de la implementación y el asentamiento, la modelación específica de los modos de falla, el énfasis en una recuperación que reduzca el fallo adversarial en lugar de un rendimiento optimista influyeron en los diseños posteriores. Más al punto, Plasma se utiliza para mostrar que la escalabilidad no es un problema de optimización de un solo eje. El proceso de aumentar el rendimiento sin especificar cómo fallan los sistemas y cómo los usuarios podrían escapar de las fallas no es escalabilidad, sino aplazamiento.
En ese sentido, @Plasma tiene éxito porque no resulta ser un atajo de rendimiento. Hace que los diseñadores de protocolos se enfrenten a cuestiones incómodas de confianza del operador, responsabilidad del usuario y comportamiento en el peor de los casos. Ethernet se puede escalar de numerosas maneras diferentes, pero Plasma nos recuerda el hecho de que antes de avanzar con cualquier otro enfoque creíble, necesitamos responder a una pregunta más básica: en caso de que todo salga mal, ¿quién podrá salir de las trincheras y cómo?
