Desde la llegada de BTC en 2009, Bitcoin ha pasado por tres iteraciones técnicas y ha evolucionado de un simple concepto de activos nativos digitales a un sistema financiero descentralizado con funciones y aplicaciones complejas.
Este artículo está escrito por el fundador de BEVM,** quien comparte sus ideas sobre la evolución de la tecnología BTC y también responde en detalle cómo BEVM, que es un hito clave en el desarrollo de la tecnología BTC Layer 2, puede lograr la prosperidad futura del ecosistema descentralizado de BTC a nivel técnico. **
En este artículo, aprenderá más sobre:
La necesidad de la capa 2 de BTC
¿Cómo lograr la capa 2 de BTC?
Solución BEVM totalmente descentralizada
Homenaje a las 3 grandes iteraciones tecnológicas revolucionarias de BTC desde su nacimiento:
2009: Nació BTC, la primera vez que se utiliza la estructura de la cadena de bloques para abrir aplicaciones monetarias descentralizadas.
2017: BTC Segregated Witness se actualizó para admitir almacenamiento de hasta 4 MB, resolviendo el problema de almacenamiento en cadena de BTC. Esto también proporciona la base para el ahora explosivo protocolo Ordinals (emisión de activos).
2021: BTC Taproot se actualizó para admitir el algoritmo de firma de umbral de BTC, que proporciona soporte subyacente para la tecnología BTC Layer2 totalmente descentralizada.
Primero, ¿por qué quieres hacer BTC Layer2?**
1. Hay demanda: La red Bitcoin satisface las necesidades de registro de activos, pero todavía hay una gran cantidad de activos que deben liquidarse en la cadena (Capa 2)
En la actualidad, la capa 2 de ETH es solo una copia de la capa 1 de ETH, y no hay nada que la capa 1 no pueda resolver, sino los problemas comerciales reales que la capa 2 tiene que resolver.
Hay que decir que la capa 2 de ETH resuelve el problema de la capa 1 de ETH: la capa 2 resuelve el problema del costoso gas de capa 1. Es precisamente por esta demanda que se ha logrado la primera aplicación de derivados de ETH en Layer2 Arbitrum, como GMX.
Y la capa 2 de BTC no es tan irrelevante como la capa 2 de ETH.
Debido a que la máquina virtual en cadena de BTC que no es Turing completa solo puede registrar activos, pero no puede realizar la liquidación, la capa 1 de BTC debe necesitar la capa 2 de BTC completa de Turing para liquidar los activos emitidos por la capa 1 de BTC.
2.Capacidad: BTC se puede convertir en una capa 2 totalmente descentralizada
Antes de la actualización de BTC Taproot en 2021, era imposible lograr una capa 2 de BTC totalmente descentralizada. Sin embargo, después de esta actualización, el algoritmo de firma del umbral de BTC permite que BTC admita una capa informática de capa 2 totalmente descentralizada.
II.¿Cómo lograr BTC L2 descentralizado?
Las Propuestas de Mejora de Bitcoin (BIPs) son documentos de diseño que introducen nuevas características e información a Bitcoin, mientras que las actualizaciones de taproot son una compilación de tres BIPs, a saber, Schnorr Signature (BIP 340), Taproot (BIP 341) y Tap (BIP 342), conocidos colectivamente como BIP Taproot.
Brindará una forma más eficiente, flexible y privada de transferir Bitcoin mediante el uso de firmas Schnorr y árboles de sintaxis abstracta de Merkel.
Las firmas Schnorr son un esquema de firma digital conocido por su simplicidad y seguridad. Las firmas Schnoor ofrecen varias ventajas en términos de eficiencia computacional, almacenamiento y privacidad.
! [Fundador de BEVM: ¿Por qué y cómo hacer BTC Layer2?] (https://cdn-img.panewslab.com//panews/2022/11/11/images/f2c90430573edf17b34bc2b81d6fba2e.)
El usuario confirma la identidad del firmante a través de la clave pública y el contenido del contrato a través de los datos, con el fin de autenticar la validez del contrato digital.
Schnorr Aggregate Signatures puede comprimir y fusionar varios datos de firma en una sola firma agregada.
El verificador verifica una única firma agregada con una lista de todos los datos asociados a las firmas y las claves públicas, lo que equivale a verificar de forma independiente todas las firmas relevantes.
! [Fundador de BEVM: ¿Por qué y cómo hacer BTC Layer2?] (https://cdn-img.panewslab.com//panews/2022/11/11/images/c7ed182df952263f95cd6b5da86e5aa3.)
En la actualidad, la mayoría de las cadenas de bloques utilizan el algoritmo multifirma ECDSA, en el que cada nodo genera una firma digital independiente con su propia clave privada para los datos del bloque y la transmite a otros nodos. El otro nodo verifica la firma y la escribe en el siguiente fragmento de datos.
De esta forma, cuando el número de nodos de consenso es grande, los datos de firma almacenados en cada ronda de bloques de consenso seguirán aumentando, ocupando espacio de almacenamiento.
Cada vez que un nuevo nodo se une a la red y necesita sincronizar bloques históricos, una gran cantidad de datos de firma supondrá un gran reto para el ancho de banda de la red.
Después de usar la tecnología de firma agregada, cada nodo recopilará las tarjetas de presentación de firma agregada difundidas por otros nodos y, a continuación, guardará el agregado de particiones de firma, como se muestra en la Figura 2.**
De esta manera, cuando se une un nuevo nodo, el bloque de historial de sincronización solo necesita descargar los datos de firma agregados, lo que reduce en gran medida la ocupación del ancho de banda de la red y reduce el gasto de tarifas de transacción.
Además, la agregación de claves hace que todas las salidas de Taproot tengan un aspecto similar. Ya sea que se trate de una salida de firma múltiple, una salida de firma única u otros contratos inteligentes complejos, todos se ven iguales en la cadena de bloques, por lo que muchos análisis de la cadena de bloques no estarán disponibles, preservando la privacidad para todos los usuarios de Taproot. **
! [Fundador de BEVM: ¿Por qué y cómo hacer BTC Layer2?] (https://cdn-img.panewslab.com//panews/2022/11/11/images/187dbc4fe20ec85e558eb12132a2a850.)
El MAST (Merkle Abstract Syntax Tree) es una serie de scripts no superpuestos (por ejemplo, multisig o timelock) que utilizan un árbol de Merkle para cifrar scripts de bloqueo complejos.
Al gastar, solo es necesario revelar el script en cuestión y la ruta desde ese script hasta la raíz del árbol de Merck. Como se muestra en la figura 3, para usar 1, solo necesita revelar 1, 2 y hash3.
Los principales beneficios de MAST incluyen:
1) Soporte para condiciones de gasto complejas
2) No es necesario revelar scripts no ejecutados o condiciones de gasto no activadas, lo que proporciona una mejor protección de la privacidad
**3) Comprimir el tamaño de la transacción: A medida que aumenta el número de scripts, el tamaño de la transacción que no es MAST aumenta linealmente, mientras que el tamaño de la transacción MAST aumenta logarítmicamente. **
Sin embargo, hay un problema en la actualización de Taproot, es decir, P2SH no es lo mismo que el común Pay-to-Public-Key-Hash (P2PKH), y todavía hay problemas de protección de la privacidad.
¿Es posible hacer que P2SH y P2PKH se vean iguales en la cadena?
Para ello, Taproot propone una solución que se puede dividir en dos partes para un script con un número limitado de firmantes:
La primera parte es multisig, en la que todos los signatarios acuerdan un determinado resultado de gasto, conocido como "gasto colaborativo".
La segunda parte se denomina "gasto no colaborativo" y puede tener estructuras de guión muy complejas.
Estas dos partes son la relación de "o".
Como se muestra en las Figuras 3 y 3, una multifirma 2 de 2 requiere que tanto Alice como Bob sean válidos, que es "gasto colaborativo" y 1 y 2 son "gastos no colaborativos".
Tanto el "gasto colaborativo" como el "gasto no colaborativo" pueden gastar este resultado, donde:
Para el script de "gasto no colaborativo", adopte el enfoque MAST descrito anteriormente y utilice MerkleRoot para representar la raíz del árbol de Merck.
Para el script de "gasto colaborativo", se adopta un algoritmo multifirma basado en las firmas de Schnoor. Pa y Pb se utilizan para representar las claves públicas de Alice y Bob, respectivamente, y Da y Db se utilizan para representar las claves privadas de Alice y Bob, respectivamente.
Por lo tanto, la clave pública agregada es P=Pa+Pb, y la clave privada correspondiente es Da+Db.
Combine "gasto colaborativo" y "gasto no colaborativo" en forma de P2PKH, y su clave pública es: PP+H(P||MerkleRoot)G; la clave privada correspondiente es Da+Db+H(P||MerkleRoot)。
Cuando Alice y Bob están de acuerdo con el "gasto colaborativo", usan Da+Db+H(P||MerkleRoot) requiere que solo uno de ellos agregue H(P||) a su clave privadaMerkleRoot).
En la cadena, esto se comporta como una transacción P2PKH, con una clave pública y una clave privada correspondiente, sin necesidad de revelar el MAST subyacente.
III. Nuestra solución de capa 2 de BTC totalmente descentralizada:
3.1 Nodo ligero BTC + contrato de firma de umbral distribuido
! [Fundador de BEVM: ¿Por qué y cómo hacer BTC Layer2?] (https://cdn-img.panewslab.com//panews/2022/11/11/images/d6ddaf08422a0b02bc25e45cd2f5d947.)
En este esquema, se seleccionan n (n pueden ser todos los validadores en BEVM) validadores fijos para completar el contrato de custodia agregada en cadena de BTC con firma de umbral distribuido.
La clave privada de cada validador en la capa 2 de BEVM también se deriva de una parte de la clave privada agregada de la firma de umbral de BTC, y la clave privada de umbral de n validadores se combina en la dirección de foto de firma agregada de BTC. **n puede ser de hasta 1000 o más. **
Cuando el usuario A quiere hacer cross-chain de BTC a BEVM, sólo tiene que enviar BTC al contrato de custodia de agregación de Bitcoin, y el usuario puede recibir BTC en la capa BEVM2.
En consecuencia, cuando el usuario A realiza una operación de retiro, solo necesita interoperar con m contratos de firma de umbral distribuido de autocompletar en la firma agregada entre n validadores, y la transferencia del contrato de depósito en garantía al usuario A se puede completar en Bitcoin, y el BTC se quemará en el BEVM al mismo tiempo que se complete la transferencia.
3.2 Implementar BTC como una tarifa de gas nativa y una capa 2 compatible con EVM
1) Principio EVM
La máquina virtual de Ethereum es el entorno de ejecución de los contratos inteligentes de Ethereum. No solo está aislado, sino que está completamente aislado.
Esto significa que el código que se ejecuta en la EVM no puede acceder a la red, al sistema de archivos ni a otros procesos. Incluso el acceso entre contratos inteligentes está restringido.
La capa subyacente de Ethereum admite la ejecución e invocación del contrato a través del módulo EVM, y el código del contrato se obtiene de acuerdo con la dirección del contrato cuando se llama, y se carga en la EVM para su funcionamiento. Normalmente, el proceso de desarrollo de contratos inteligentes consiste en escribir código lógico en solidlity, compilarlo en código de bytes a través de un compilador y, finalmente, publicarlo en Ethereum.
! [Fundador de BEVM: ¿Por qué y cómo hacer BTC Layer2?] (https://cdn-img.panewslab.com//panews/2022/11/11/images/2d2d923b8ae9ff718bac8dedbf6a9314.)
2) Partes principales de EVM
! [Fundador de BEVM: ¿Por qué y cómo hacer BTC Layer2?] (https://cdn-img.panewslab.com//panews/2022/11/11/images/67f265774f666ae9ab031a29230b5b8d.)
3)Código EVM
El código EVM es el código de la máquina virtual de Ethereum, que se refiere al código del lenguaje de programación que Ethereum puede contener. El código EVM asociado a una cuenta se ejecuta cada vez que se envía un mensaje a la cuenta y tiene la capacidad de leer/escribir almacenamiento y enviar mensajes por sí mismo.
4)Estado de Mchine
El estado Mchine es donde se ejecuta el código EVM, que contiene contadores de programa, pilas y memoria.
5)Almacenamiento
El almacenamiento es un espacio de almacenamiento persistente que se puede leer, escribir y modificar, y también es el lugar donde cada contrato almacena datos de forma persistente. El almacenamiento es un mapa enorme, con un total de 2256 ranuras, cada una con 32 bytes cada una.
6) BTC como tarifa de gas
Permita que el BTC transferido desde la red Bitcoin se utilice como moneda de cálculo de la tarifa de gas para la ejecución de transacciones en la EVM.
Esta página puede contener contenido de terceros, que se proporciona únicamente con fines informativos (sin garantías ni declaraciones) y no debe considerarse como un respaldo por parte de Gate a las opiniones expresadas ni como asesoramiento financiero o profesional. Consulte el Descargo de responsabilidad para obtener más detalles.
Fundador de BEVM: ¿Por qué y cómo hacer la capa 2 de BTC?
Autor: Peter
Preámbulo
Desde la llegada de BTC en 2009, Bitcoin ha pasado por tres iteraciones técnicas y ha evolucionado de un simple concepto de activos nativos digitales a un sistema financiero descentralizado con funciones y aplicaciones complejas.
Este artículo está escrito por el fundador de BEVM,** quien comparte sus ideas sobre la evolución de la tecnología BTC y también responde en detalle cómo BEVM, que es un hito clave en el desarrollo de la tecnología BTC Layer 2, puede lograr la prosperidad futura del ecosistema descentralizado de BTC a nivel técnico. **
En este artículo, aprenderá más sobre:
La necesidad de la capa 2 de BTC
¿Cómo lograr la capa 2 de BTC?
Solución BEVM totalmente descentralizada
Homenaje a las 3 grandes iteraciones tecnológicas revolucionarias de BTC desde su nacimiento:
2009: Nació BTC, la primera vez que se utiliza la estructura de la cadena de bloques para abrir aplicaciones monetarias descentralizadas.
2017: BTC Segregated Witness se actualizó para admitir almacenamiento de hasta 4 MB, resolviendo el problema de almacenamiento en cadena de BTC. Esto también proporciona la base para el ahora explosivo protocolo Ordinals (emisión de activos).
2021: BTC Taproot se actualizó para admitir el algoritmo de firma de umbral de BTC, que proporciona soporte subyacente para la tecnología BTC Layer2 totalmente descentralizada.
Primero, ¿por qué quieres hacer BTC Layer2?**
1. Hay demanda: La red Bitcoin satisface las necesidades de registro de activos, pero todavía hay una gran cantidad de activos que deben liquidarse en la cadena (Capa 2)
En la actualidad, la capa 2 de ETH es solo una copia de la capa 1 de ETH, y no hay nada que la capa 1 no pueda resolver, sino los problemas comerciales reales que la capa 2 tiene que resolver.
Hay que decir que la capa 2 de ETH resuelve el problema de la capa 1 de ETH: la capa 2 resuelve el problema del costoso gas de capa 1. Es precisamente por esta demanda que se ha logrado la primera aplicación de derivados de ETH en Layer2 Arbitrum, como GMX.
Y la capa 2 de BTC no es tan irrelevante como la capa 2 de ETH.
Debido a que la máquina virtual en cadena de BTC que no es Turing completa solo puede registrar activos, pero no puede realizar la liquidación, la capa 1 de BTC debe necesitar la capa 2 de BTC completa de Turing para liquidar los activos emitidos por la capa 1 de BTC.
2.Capacidad: BTC se puede convertir en una capa 2 totalmente descentralizada
Antes de la actualización de BTC Taproot en 2021, era imposible lograr una capa 2 de BTC totalmente descentralizada. Sin embargo, después de esta actualización, el algoritmo de firma del umbral de BTC permite que BTC admita una capa informática de capa 2 totalmente descentralizada.
II.¿Cómo lograr BTC L2 descentralizado?
Las Propuestas de Mejora de Bitcoin (BIPs) son documentos de diseño que introducen nuevas características e información a Bitcoin, mientras que las actualizaciones de taproot son una compilación de tres BIPs, a saber, Schnorr Signature (BIP 340), Taproot (BIP 341) y Tap (BIP 342), conocidos colectivamente como BIP Taproot.
Brindará una forma más eficiente, flexible y privada de transferir Bitcoin mediante el uso de firmas Schnorr y árboles de sintaxis abstracta de Merkel.
Las firmas Schnorr son un esquema de firma digital conocido por su simplicidad y seguridad. Las firmas Schnoor ofrecen varias ventajas en términos de eficiencia computacional, almacenamiento y privacidad.
! [Fundador de BEVM: ¿Por qué y cómo hacer BTC Layer2?] (https://cdn-img.panewslab.com//panews/2022/11/11/images/f2c90430573edf17b34bc2b81d6fba2e.)
El usuario confirma la identidad del firmante a través de la clave pública y el contenido del contrato a través de los datos, con el fin de autenticar la validez del contrato digital.
Schnorr Aggregate Signatures puede comprimir y fusionar varios datos de firma en una sola firma agregada.
El verificador verifica una única firma agregada con una lista de todos los datos asociados a las firmas y las claves públicas, lo que equivale a verificar de forma independiente todas las firmas relevantes.
! [Fundador de BEVM: ¿Por qué y cómo hacer BTC Layer2?] (https://cdn-img.panewslab.com//panews/2022/11/11/images/c7ed182df952263f95cd6b5da86e5aa3.)
En la actualidad, la mayoría de las cadenas de bloques utilizan el algoritmo multifirma ECDSA, en el que cada nodo genera una firma digital independiente con su propia clave privada para los datos del bloque y la transmite a otros nodos. El otro nodo verifica la firma y la escribe en el siguiente fragmento de datos.
De esta forma, cuando el número de nodos de consenso es grande, los datos de firma almacenados en cada ronda de bloques de consenso seguirán aumentando, ocupando espacio de almacenamiento.
Cada vez que un nuevo nodo se une a la red y necesita sincronizar bloques históricos, una gran cantidad de datos de firma supondrá un gran reto para el ancho de banda de la red.
Después de usar la tecnología de firma agregada, cada nodo recopilará las tarjetas de presentación de firma agregada difundidas por otros nodos y, a continuación, guardará el agregado de particiones de firma, como se muestra en la Figura 2.**
De esta manera, cuando se une un nuevo nodo, el bloque de historial de sincronización solo necesita descargar los datos de firma agregados, lo que reduce en gran medida la ocupación del ancho de banda de la red y reduce el gasto de tarifas de transacción.
Además, la agregación de claves hace que todas las salidas de Taproot tengan un aspecto similar. Ya sea que se trate de una salida de firma múltiple, una salida de firma única u otros contratos inteligentes complejos, todos se ven iguales en la cadena de bloques, por lo que muchos análisis de la cadena de bloques no estarán disponibles, preservando la privacidad para todos los usuarios de Taproot. **
! [Fundador de BEVM: ¿Por qué y cómo hacer BTC Layer2?] (https://cdn-img.panewslab.com//panews/2022/11/11/images/187dbc4fe20ec85e558eb12132a2a850.)
El MAST (Merkle Abstract Syntax Tree) es una serie de scripts no superpuestos (por ejemplo, multisig o timelock) que utilizan un árbol de Merkle para cifrar scripts de bloqueo complejos.
Al gastar, solo es necesario revelar el script en cuestión y la ruta desde ese script hasta la raíz del árbol de Merck. Como se muestra en la figura 3, para usar 1, solo necesita revelar 1, 2 y hash3.
Los principales beneficios de MAST incluyen:
1) Soporte para condiciones de gasto complejas
2) No es necesario revelar scripts no ejecutados o condiciones de gasto no activadas, lo que proporciona una mejor protección de la privacidad
**3) Comprimir el tamaño de la transacción: A medida que aumenta el número de scripts, el tamaño de la transacción que no es MAST aumenta linealmente, mientras que el tamaño de la transacción MAST aumenta logarítmicamente. **
Sin embargo, hay un problema en la actualización de Taproot, es decir, P2SH no es lo mismo que el común Pay-to-Public-Key-Hash (P2PKH), y todavía hay problemas de protección de la privacidad.
¿Es posible hacer que P2SH y P2PKH se vean iguales en la cadena?
Para ello, Taproot propone una solución que se puede dividir en dos partes para un script con un número limitado de firmantes:
La primera parte es multisig, en la que todos los signatarios acuerdan un determinado resultado de gasto, conocido como "gasto colaborativo".
La segunda parte se denomina "gasto no colaborativo" y puede tener estructuras de guión muy complejas.
Estas dos partes son la relación de "o".
Como se muestra en las Figuras 3 y 3, una multifirma 2 de 2 requiere que tanto Alice como Bob sean válidos, que es "gasto colaborativo" y 1 y 2 son "gastos no colaborativos".
Tanto el "gasto colaborativo" como el "gasto no colaborativo" pueden gastar este resultado, donde:
Para el script de "gasto no colaborativo", adopte el enfoque MAST descrito anteriormente y utilice MerkleRoot para representar la raíz del árbol de Merck.
Para el script de "gasto colaborativo", se adopta un algoritmo multifirma basado en las firmas de Schnoor. Pa y Pb se utilizan para representar las claves públicas de Alice y Bob, respectivamente, y Da y Db se utilizan para representar las claves privadas de Alice y Bob, respectivamente.
Por lo tanto, la clave pública agregada es P=Pa+Pb, y la clave privada correspondiente es Da+Db.
Combine "gasto colaborativo" y "gasto no colaborativo" en forma de P2PKH, y su clave pública es: PP+H(P||MerkleRoot)G; la clave privada correspondiente es Da+Db+H(P||MerkleRoot)。
Cuando Alice y Bob están de acuerdo con el "gasto colaborativo", usan Da+Db+H(P||MerkleRoot) requiere que solo uno de ellos agregue H(P||) a su clave privadaMerkleRoot).
En la cadena, esto se comporta como una transacción P2PKH, con una clave pública y una clave privada correspondiente, sin necesidad de revelar el MAST subyacente.
III. Nuestra solución de capa 2 de BTC totalmente descentralizada:
3.1 Nodo ligero BTC + contrato de firma de umbral distribuido
! [Fundador de BEVM: ¿Por qué y cómo hacer BTC Layer2?] (https://cdn-img.panewslab.com//panews/2022/11/11/images/d6ddaf08422a0b02bc25e45cd2f5d947.)
En este esquema, se seleccionan n (n pueden ser todos los validadores en BEVM) validadores fijos para completar el contrato de custodia agregada en cadena de BTC con firma de umbral distribuido.
La clave privada de cada validador en la capa 2 de BEVM también se deriva de una parte de la clave privada agregada de la firma de umbral de BTC, y la clave privada de umbral de n validadores se combina en la dirección de foto de firma agregada de BTC. **n puede ser de hasta 1000 o más. **
Cuando el usuario A quiere hacer cross-chain de BTC a BEVM, sólo tiene que enviar BTC al contrato de custodia de agregación de Bitcoin, y el usuario puede recibir BTC en la capa BEVM2.
En consecuencia, cuando el usuario A realiza una operación de retiro, solo necesita interoperar con m contratos de firma de umbral distribuido de autocompletar en la firma agregada entre n validadores, y la transferencia del contrato de depósito en garantía al usuario A se puede completar en Bitcoin, y el BTC se quemará en el BEVM al mismo tiempo que se complete la transferencia.
3.2 Implementar BTC como una tarifa de gas nativa y una capa 2 compatible con EVM
1) Principio EVM
La máquina virtual de Ethereum es el entorno de ejecución de los contratos inteligentes de Ethereum. No solo está aislado, sino que está completamente aislado.
Esto significa que el código que se ejecuta en la EVM no puede acceder a la red, al sistema de archivos ni a otros procesos. Incluso el acceso entre contratos inteligentes está restringido.
La capa subyacente de Ethereum admite la ejecución e invocación del contrato a través del módulo EVM, y el código del contrato se obtiene de acuerdo con la dirección del contrato cuando se llama, y se carga en la EVM para su funcionamiento. Normalmente, el proceso de desarrollo de contratos inteligentes consiste en escribir código lógico en solidlity, compilarlo en código de bytes a través de un compilador y, finalmente, publicarlo en Ethereum.
! [Fundador de BEVM: ¿Por qué y cómo hacer BTC Layer2?] (https://cdn-img.panewslab.com//panews/2022/11/11/images/2d2d923b8ae9ff718bac8dedbf6a9314.)
2) Partes principales de EVM
! [Fundador de BEVM: ¿Por qué y cómo hacer BTC Layer2?] (https://cdn-img.panewslab.com//panews/2022/11/11/images/67f265774f666ae9ab031a29230b5b8d.)
3)Código EVM
El código EVM es el código de la máquina virtual de Ethereum, que se refiere al código del lenguaje de programación que Ethereum puede contener. El código EVM asociado a una cuenta se ejecuta cada vez que se envía un mensaje a la cuenta y tiene la capacidad de leer/escribir almacenamiento y enviar mensajes por sí mismo.
4)Estado de Mchine
El estado Mchine es donde se ejecuta el código EVM, que contiene contadores de programa, pilas y memoria.
5)Almacenamiento
El almacenamiento es un espacio de almacenamiento persistente que se puede leer, escribir y modificar, y también es el lugar donde cada contrato almacena datos de forma persistente. El almacenamiento es un mapa enorme, con un total de 2256 ranuras, cada una con 32 bytes cada una.
6) BTC como tarifa de gas
Permita que el BTC transferido desde la red Bitcoin se utilice como moneda de cálculo de la tarifa de gas para la ejecución de transacciones en la EVM.