La Capa 2 ya no es solo la Capa 2 de Ethereum.
Escrito por: Haotian
Ha surgido en el mercado una nueva narrativa de “EVM paralelo”, que es muy interesante en la capa 2. Puede realizar un nuevo paradigma Rollup “refinado”. Si se exagera, puede lograr el efecto mágico de que Solana se convierta en la nueva capa 2 de Etereum.
En mi opinión, EVM paralelo es solo una manifestación altamente “modular” de Rollup. Después de que DA fue invadido por un tercero, la capa de ejecución de VM cayó nuevamente y la capa 2 se redefinirá en el futuro. ¿Por qué? A continuación, analicémoslo desde una perspectiva de divulgación científica:
Para comprender este tema, primero debe aclarar el modelo de ejecución de un solo subproceso de “EVM”.
Este modelo estipula que las transacciones deben procesarse y confirmarse una tras otra en orden, lo que afecta directamente la velocidad de procesamiento de las transacciones, el tiempo de generación de bloques y el rendimiento de las transacciones, etc., y es la razón principal del alto nivel de gas y congestión del principal Ethereum. red. Además, la razón por la que está diseñado para ser de un solo subproceso tiene ciertas limitaciones históricas.
Dado que las transacciones en Ethereum son verificadas y ejecutadas por nodos independientes distribuidos, es necesario garantizar que los datos de todas las direcciones, como saldos, códigos de contratos inteligentes, etc., permanezcan consistentes entre diferentes nodos. necesario garantizar que no haya activos idénticos, surgiendo la posibilidad de un doble gasto.
Esto hace que las transacciones se pongan en cola en orden. Si se producen transacciones paralelas, puede provocar errores en la sincronización de datos entre nodos y la clave es que pueden producirse transacciones graves de doble gasto.
Explicación popular: El banco tiene solo una ventana de servicio y los clientes deben hacer cola para retirar dinero. Ya sean depósitos, retiros, préstamos y otros servicios, un cliente solo puede iniciar el siguiente después de completar el negocio. La ventaja es que cada operación del sistema de cuentas del banco se registre con precisión, aunque el tiempo de espera para los clientes será mayor;
Si un banco abre varias ventanas de servicio y los clientes pueden elegir una ventana para manejar diferentes negocios, habrá dos ventanas tratando de deducir dinero de una cuenta al mismo tiempo. Si la conciliación del sistema de cuentas entre ventanas no es oportuna, dará lugar a duplicar el gasto Obviamente, esto obviamente mejorará la eficiencia, pero la lógica contable compleja ejercerá presión sobre el sistema contable.
En el escenario de cadena independiente de capa 1, si la capa inferior de la cadena admite el procesamiento paralelo, el problema se resolverá fácilmente. Dado que los estados de computación y almacenamiento de Solana están separados, después de que su VM reciba múltiples transacciones de los usuarios, el nodo ordenará estas transacciones y luego llame a la cadena independiente. Los datos de estado del sistema de almacenamiento detectan si hay un conflicto de estado en estas transacciones. Si no hay conflicto, la transacción se empaquetará en un bloque. Si hay un conflicto, la transacción en conflicto se excluirá de este bloque.
En comparación, el estado de almacenamiento de Ethereum se calcula en tiempo real. Cada transacción debe esperar a que se complete la transacción anterior antes de actualizar el estado. Por lo tanto, es imposible filtrar las transacciones antes de esperar el empaquetado, lo que limita su procesamiento paralelo. .
En el escenario de la cadena acumulativa de capa 2, la distancia es similar para lograr el procesamiento paralelo. Puede pensar en el cálculo de transacciones de Solana y la detección del estado de almacenamiento en espera de la marca de tiempo POH como el proceso de la cadena acumulada que procesa transacciones en Sequener y luego las envía por lotes a la red principal.
Ahora, antes de procesar las transacciones por lotes de capa 2, Sequener primero organizará los nonces de las transacciones en orden cronológico y luego las agrupará en la red principal en orden. ¿Cómo podemos lograr subprocesos múltiples?
-
Según el modelo abstracto de cuenta AA, es posible iniciar múltiples transacciones al mismo tiempo desde el estado de la cuenta. Por ejemplo, si se ejecutan dos transferencias al mismo tiempo, el contrato inteligente AA les dará un nonce, que debe ejecutarse en orden. Si se trata de una transferencia, si se aprueba una transacción, se puede procesar de manera más flexible en paralelo sin estar restringida por el nonce. En el modelo de cuenta AA, cada cuenta puede personalizar la lógica de procesamiento de transacciones y luego cooperar con nonce para lograr una alta concurrencia.
-
Se puede realizar un procesamiento “refinado” de transacciones en Sequencer. Por ejemplo, cuando las transacciones de capa 2 se envían a Sequencer, Sequencer puede detectar rápidamente estas lógicas de transacciones y realizar una clasificación y selección refinadas. Por ejemplo, si lo mismo Si una cuenta inicia dos Transferencias, esta última debe ser excluida y esperar el siguiente Lote. Si la misma cuenta inicia dos operaciones de diferente naturaleza, se pueden Batchar en un bloque al mismo tiempo.
¿Suena simple? Pero esto no es en absoluto el caso: tomando como ejemplo el escenario DeFi, Sequencer se enfrenta a dos grandes retos para lograr una gestión refinada de las transacciones:
-
Es necesario analizar los datos de las transacciones en tiempo real y comprender los métodos de llamada de contratos inteligentes y los parámetros de los datos entrantes. Tomemos como ejemplo el Stake común en DeFi. Una operación de Stake implica la transferencia de tokens, la actualización del estado, el período de compromiso y cálculo de recompensa potencial, etc. Si una gran cantidad de usuarios envían algunas transacciones de compromiso al mismo tiempo, si también hay transacciones que involucran compromiso y luego transferencia, junto con factores de precios complejos de Oralce, etc., si Sequener no puede analizarlo y procesarlo correctamente, se producirá un error en uno paso puede provocar accidentes graves.
-
El secuenciador debe garantizar la descentralización. Actualmente, el secuenciador de capa 2 solo tiene transacciones por lotes y sus derechos son demasiado grandes. Si el problema de descentralización del secuenciador no se puede resolver, se le otorgará un paquete acumulativo “refinado”. Si Sequencer realiza transacciones falsas, se involucra descaradamente en trampas MEV o incluso manipula maliciosamente la liquidación de Oracle, etc., se reproducirá.
Recientemente, Metis se ha vuelto popular. En la superficie, solo logra la descentralización de Sequencer. En un nivel más profundo, construye una premisa de consenso básica para que Sequencer en el futuro realice un resumen refinado.
Por supuesto, confiar en Sequencer para lograr una agregación y procesamiento de transacciones Rollup altamente refinadas sigue siendo solo una idea. Afortunadamente, la abstracción de cuentas AA y la idea abierta de combinación modular de toda la cadena de bloques proporcionan los requisitos previos para la implementación de esta idea. .
eso es todo.
Además, como se mencionó anteriormente, la capa 2 en su conjunto se está volviendo cada vez más modular. La tecnología ZK está integrada en el marco OP Stack para lograr la expansión de la privacidad; el Ethereum DA original se convierte en un DA de terceros como Celestia para reducir costos; ETH es utilizado gradualmente como Gas La tradición de las tarifas también ha cambiado, lo que le da a los tokens de capa 2 una mayor practicidad; incluso la capa 2 puede procesar por lotes transacciones por lotes y enviarlas a diferentes entornos de ejecución de VM, y las transacciones se dividen en Solana y Ethereum para su procesamiento, etc.
Para entonces, surgirá un nuevo paradigma. La capa 2 actual ya no es solo la capa 2 de Ethereum. Solana también puede ser la capa 2 de Ethereum, e incluso la definición de capa 2 cambiará mágicamente.
Como idea audaz, la capa 2 ahora se ha convertido en una “capa 1” de nivel básico que integra capacidades de procesamiento de transacciones de alta concurrencia, y la antigua capa 1, como Ethereum y Solana, se ha convertido en una nueva “capa 2” que maneja la liquidación de activos y garantía de seguridad.
La capa 2 nunca ha sido un concepto rígido. Las plataformas de capa 2 siempre han tenido la misión de resolver el procesamiento concurrente de transacciones a gran escala y atraer grupos de mercado de usuarios incrementales.
Si se logra la misión, bajo la idea modular, no solo se romperá la legitimidad de la capa 1 de Ethereum, sino que la disponibilidad de datos DA, la capa de ejecución de VM e incluso la interacción de comunicación de interoperabilidad de toda la cadena se convertirán en la infraestructura para que la capa 2 lo realice. Adopción masiva.
Para entonces, la capa 2 ya no será solo un complemento de la capa 1, sino que se convertirá en una poderosa plataforma integral de procesamiento de distribución y agregación de transacciones.Permítanme preguntar, ¿quién es de quién es la capa 2?
