JAM es 2.0 después, es decir, se está acelerando el desarrollo, con más de 30 equipos, diferentes lenguajes de programación y diferentes equipos de desarrollo para implementar un cliente JAM descentralizado (basado en el protocolo del libro gris de JAM). El ETH más antiguo requería que todas las transacciones fueran verificadas por todos los validadores (esta parte se puede consultar en el libro amarillo de Ethereum, y hay una versión de interpretación mejor). L2 permite que un subconjunto más pequeño fuera de la cadena realice cálculos, a través de dos métodos: uno es L2 con prueba de fraude (después de descubrir un fraude, se vuelve a ejecutar el código de la transacción para verificar), y el otro es L2 con prueba zk, que no requiere cálculos repetidos, pero necesita usar GPU más caras para generar pruebas, en la cadena solo se verifica la prueba, sin necesidad de volver a ejecutar el código de la función de transformación de la transacción anterior. El antiguo @Polkadot 1.0 utilizaba un algoritmo llamado ELVES, que no es como el algoritmo de fraude de ETH, que verifica de manera pasiva, sino que utiliza un algoritmo de tipo probabilístico para verificar de manera activa. En @polkadot 2.0, el conjunto de validadores ya se ha empaquetado en un concepto llamado Core, que esencialmente es un subconjunto del conjunto de validadores. 2.0 soporta Agile Coretime, es decir, el uso dinámico de core, en 1.0 una cadena solo puede usar un Core, después de que 2.0 se lance, soportará Agile Coretime, lo que significa que una cadena puede usar dinámicamente coretime (número de subconjuntos de validación) según la demanda, mejorando así la carga de servicio del sistema. Entonces, JAM se ha evolucionado sobre estas ideas, surgiendo tantos zk, op, contratos inteligentes, e incluso aplicaciones sin estado de tipo web2, ¿pueden abstraer mejor los servicios para adaptarse a estos diferentes modelos de aplicación? Y permitir que interactúen y se combinen entre sí. Así que JAM ha hecho una abstracción adicional sobre esta base. - Diferentes cosas de L2/cadenas paralelas ahora se llaman servicios - Las cosas de bloques/transacciones ahora se llaman ítems de trabajo o paquetes de trabajo - Los ítems de trabajo pertenecen a servicios, mientras que un paquete de trabajo es un conjunto de ítems de trabajo - Los servicios se describen mediante tres puntos de entrada, de los cuales dos son fn refine() y fn accumulated - Los nombres de estos dos puntos de entrada son precisamente la razón por la que este protocolo se llama JAM: Máquina de Acumulación Conjunta (Join Accumulate Machine). Conectar (Join) se refiere a fn refine(), todos los núcleos de Polkadot ejecutarán en paralelo una gran cantidad de trabajo para diferentes servicios. Conectar se refiere a refinar los datos en un subconjunto más pequeño y luego pasarlo a la siguiente etapa. - Acumular se refiere a acumular los resultados de todas las operaciones anteriores en el estado principal de JAM - Se apoyan diferentes formas de servicios (op rollups, zkrollups, cadenas paralelas, aplicaciones sin estado, contratos inteligentes) La era ETH es una máquina de estado de columna única de estado compartido, La era @polkadot 1.0 es una máquina de fragmentación probabilística interoperable. La era @polkadot 2.0 es una máquina Agile Coretime. La era JAM es la Máquina de Acumulación Conjunta (JAM). Hay muchos más detalles y características, aquí solo he hecho una sincronización de la información que entendí, ¿por qué JAM puede ejecutar programas de manera continua sin necesidad de invocar programas a través de transacciones? ¿Qué nuevos productos de modelos surgirán en el futuro al combinar estas características con DEFI? ¿Por qué JAM puede ejecutar aplicaciones no estatales, como JAM DOOM? Para más detalles, consulta el video: Material de estudio: