Starknet Smart Contract Model y Native AA: Maverick Technical Master

Autor: Shew & amp;

resumen

• Las características técnicas más importantes de Starknet, incluido el lenguaje de El Cairo que conduce a la prueba de ZK,Nivel nativo AA, Modelo de contrato inteligente de lógica comercial y almacenamiento de estado.

• El Cairo es un lenguaje ZK común que puede implementar contratos inteligentes en Starknet, o puede usarse para desarrollar aplicaciones tradicionales.La introducción de Sierra como un lenguaje intermedio en su proceso de compilación permite a El Cairo iterar con frecuencia, pero no es necesario cambiar la capa inferior de Bytecode.En la Biblioteca Estándar de El Cairo, se necesitan muchas estructuras de datos básicas para la abstracción de la cuentaEsencia

• Starknet Smart contratos separados de la lógica comercial y el estado.«Compilación, declaración, despliegue»En la tercera etapa, la lógica comercial se declara en la clase de contrato.

• El modelo de contrato inteligente mencionado por encima de Starknet es propicio para la reutilización del código, la reutilización del estado del contrato, las capas de almacenamiento y la detección de contratos de basura.También es propicio para la realización del sistema de arrendamiento de almacenamiento y la paralelización de la transacción.Aunque los dos últimos aún no han aterrizado, la arquitectura del contrato inteligente de El Cairo ha creado «condiciones necesarias» para ello.

• Solo hay una cuenta de contrato inteligente en la cadena Starknet, y no hay una cuenta EOA.Desde el principio, admite la abstracción de la cuenta AA nativa.Su solución AA absorbe la idea de ERC-4337 hasta cierto punto, lo que permite a los usuarios elegir un esquema de procesamiento de transacciones altamente personalizado.Para prevenir posibles escenas de ataque, Starknet ha hecho muchas contramedidas y ha realizado exploraciones importantes para el ecosistema AA.

Después de los tokens emisores de Starknet, STRK se ha convertido gradualmente en uno de los elementos indispensables a los ojos de los observadores de Ethereum.La estrella de Ethereum Layer2 conocida por la «singularidad» y «no prestar atención a la experiencia del usuario» es como un ermitaño con el mundo.

Debido a que los usuarios lo ignoraron demasiado, e incluso abrió públicamente el canal de «mendigo electrónico» en Discord, Starknet fue atacado una vez por el Partido Mao. «Parece que solo los efectos de fabricación de UX y riqueza lo son todo.La frase «no entendida como mi único orgullo» en el «Templo del Pabellón Golden» es simplemente un autorretrato de Starknet.

Pero aparte de estos asuntos triviales, simplemente comienza desde el «gusto técnico» de los geeks del código. Las mentes de algunos desarrolladores de juegos de todas las cadenas, Starknet y El Cairo lo son todo en Web3, ni la solidez ni el movimiento es comparable.Hoy en día, la brecha de generación más grande entre los «geeks técnicos» y el «usuario» se debe más a la falta de cognición de las personas de Starknet.

Con el interés y la exploración de la tecnología blockchain y el valor del valor de Starknet,El autor comienza desde el modelo de contrato inteligente de Starknet y AA nativo para simplemente resolver su solución técnica y diseño de mecanismo para todos.Al mostrar las características técnicas de Starknet a más personas, también espero permitir que la gente entienda este «hombre solitario no comprensible».

Lenguaje de Cairro Ciencia minimalista

A continuación, nos centraremos en discutir el modelo de contrato inteligente de Starknet y la abstracción de las cuentas nativas, explicando cómo Starknet logra AA nativo.Después de leer este artículo, todos también pueden entender por qué la ayuda de diferentes billeteras en Starknet no se puede mezclar.

Pero antes de introducir abstracción de cuenta nativa,Primero entendamos el idioma original de El Cairo de Starknet.Durante el desarrollo de El Cairo, apareció una versión temprana llamada El Cairo0, así como la versión moderna posterior.La gramática general de la versión moderna de El Cairo es similar a la óxido, que en realidad es un lenguaje ZK común.Además de escribir contratos inteligentes en Starknet, también se puede utilizar para el desarrollo de aplicaciones generales.

Por ejemplo, podemos desarrollar el sistema de verificación de identidad ZK en el lenguaje de El Cairo.Se puede decir que cualquier programa que deba verificarse se puede implementar en el idioma de El Cairo.yEl Cairo es probablemente el lenguaje de programación que es más propicio para generar ZK.

A juzgar por el proceso de compilación, El Cairo utiliza el método de compilación basado en el lenguaje intermedio, como se muestra en la figura a continuación.La Sierra en la figura es una forma intermedia (IR) en el proceso de compilación de idiomas de El Cairo, y Sierra se compilará en una forma de código binario más subyacente, llamada CASM, que se opera directamente en el equipo de nodo Starknet.

Introducir a Sierra como la forma intermedia, que es conveniente para el lenguaje de El Cairo para aumentar las nuevas características.Esto ahorra muchos problemas, y el cliente de nodo de Starknet no tiene que actualizarse con frecuencia.De esta manera, puede lograr iteraciones frecuentes del lenguaje de El Cairo sin cambiar la lógica subyacente de Starknet.yEn la Biblioteca estándar de El Cairo, se necesitan muchas estructuras de datos básicas para la abstracción de la cuenta.

La innovación de otro Cairo, incluida una solución teórica llamada Cairo Native. Mejore enormemente la velocidad de ejecución del código [todavía está en la etapa teórica y no se ha designado].

Modelo de contrato inteligente de Starknet: lógica de código y eliminación de almacenamiento estatal

A diferencia de la cadena EVM y Capable, Starknet tiene innovación innovadora en el diseño de sistemas de contratos inteligentes.Aquí, necesitamos saber que en la cadena pública tradicional como Ethereum,La implementación de contratos SMART a menudo sigue el método de «despliegue posterior a la compilación» y utiliza contratos SMART ETH, por ejemplo:

1. Después de que el desarrollador escribió el contrato inteligente localmente, el desarrollador compila el programa de solidez en el código de byte de EVM a través del editor, para que el EVM pueda entenderse y procesarse directamente;

2. Los desarrolladores inician una solicitud de transacción para implementar contratos inteligentes para implementar el código de byterio EVM compilado en la cadena Ethereum.

(Fuente de la imagen: no-Satoshi.com)

Aunque el contrato inteligente de Starknet también sigue la idea de «compilar y luego implementación»,Los contratos inteligentes se implementan en la cadena en forma de Bytecode CASM compatible con Cairovm.Sin embargo, en términos de llamadas y modo de almacenamiento de estado de contratos inteligentes, las cadenas compatibles con Starknet y EVM son enormes.

Ser preciso,Ethereum Smart Contract = Business Logic+Status Information,Por ejemplo, el contrato del USDT no solo implementa funciones de función comúnmente utilizadas como transferencia, aprobación, etc., sino que también almacena el estado de activos de todos los titulares del USDT.El código y el estado se acoplan juntos, lo que trae muchos problemas. carga.

En este sentido, Starknet ha mejorado el método de almacenamiento del estado.En su plan de implementación de contratos inteligentes, la lógica comercial y el estado de activos de DAPP están completamente desacoplados y se almacenan en diferentes lugares.Los beneficios de hacerlo son obvios.El principio aquí es:

Ethereum’s Smart Contract = Business Logic+Status Data,Si la lógica comercial de varios contratos es completamente consistente, pero los datos de estado son diferentes, el hash de estos contratos también es diferente. contratos «.

yEn el esquema de Starknet, la parte del código y los datos de estado están directamente separados.Porque su hash es el mismo.Esto es conveniente para detener la implementación de código duplicada y guardar el espacio de almacenamiento de los nodos Starknet.

En el sistema de contrato inteligente de Starknet, la implementación y el uso del contrato se dividen en«Compilación, declaración, despliegue»Tres etapas.Si el emisor de activos quiere implementar el contrato de El Cairo, el primer paso es compilar el código de El Cairo escrito a Sierra y el formulario de Casma Bytecode subyacente.

Luego, el despliegue del contrato emitirá una declaración de la transacción «declarar», implementará el código de bytecodo CASM del contrato y el código intermedio Sierra a la cadena, nombradoClase de contratoEsencia

(Fuente de la imagen: sitio web oficial de Starknet)

Después de eso, si desea utilizar la función de función definida en el contrato de activos, puede iniciar una transacción de «implementar» a través del extremo frontal del DAPP e implementar unInstancia de contratoEsta instancia almacenará el estado de activos.Después de eso, el usuario puede llamar a la función de función en la clase de contrato para cambiar el estado de la instancia del contrato.

De hecho, cualquier persona que entienda la programación orientada a los objetos debe comprender fácilmente lo que representa la clase y la instancia de Starknet.La clase de contrato declarada por el desarrollador solo contiene la lógica comercial de los contratos inteligentes.

DeberíaDespués de que el usuario implementa una instancia de contrato específica, los activos completan la «fisicalización».Si desea cambiar el estado de la «entidad» de activos, como transferir su token a otros, puede llamar directamente a la función de función escrita en la clase de contrato.El proceso anterior es algo similar (pero no completamente consistente) en el lenguaje de programación tradicional.

Después de que el contrato inteligente se separa como clase e instancias, la lógica comercial y las decepciones de datos de estado trae las siguientes características:

1. No almacenar capas y la realización del «sistema de arrendamiento de almacenamiento»

La estratificación de almacenamiento de SO significa que los desarrolladores pueden colocar datos en una posición personalizada de acuerdo con sus propias necesidades, como debajo de la cadena Starknet.Starknet es compatible con la capa DA, como Celestia, y los desarrolladores de DAPP pueden almacenar datos en estas capas DA de tercera parte.Por ejemplo, un juego puede almacenar los datos de activos más importantes en la red principal de Starknet y almacenar otros datos en la capa DA bajo el enlace de Celestia.Starknet se llama «Volition» esta solución a la capa DA según la personalización de las necesidades de seguridad «Volition».

El sistema de arrendamiento de almacenamiento que se le llama SO significa que todos deberían continuar pagando por el espacio de almacenamiento que ocupan.¿Cuánto espacio lleva para usted, teóricamente, debe continuar pagando el alquiler?

En el modelo de contrato inteligente de Ethereum, la propiedad del contrato no es clara, y es difícil distinguir el contrato ERC-20 debe ser pagado por el despliegue o el titular de los activos para pagar «alquiler».No ha estado lanzando la función de arrendamiento de almacenamiento, y solo cobra una tarifa al despliegue durante el despliegue del contrato.

Según los modelos de contrato inteligente de Starknet y Sui y CKB y Solana, la propiedad del contrato inteligente es más claro, lo que es conveniente para la recolección de fondos de almacenamiento [Starknet actualmente no se realiza directamente en línea. el futuro]

2. Date cuenta de la reutilización del código real y reduce la implementación de contratos de basura

Podemos declarar un contrato de token universal como la clase almacenada en la cadena, y luego todos pueden llamar a la función en esta clase para implementar su propia instancia de token.Y el contrato también puede llamar directamente al código en la clase, que logra el efecto de la biblioteca de funciones de la biblioteca similar a la biblioteca de funciones de la biblioteca en solidez.

Al mismo tiempo, este modelo de contrato inteligente de Starknet,Ayuda a distinguir el «contrato de basura».Anteriormente explicó esto.Después de soportar la reutilización del código y la detección de contratos de basura, Starknet puede reducir en gran medida la cantidad de datos en la cadena y minimizar la presión de almacenamiento de los nodos tanto como sea posible.

3. «Estado» real del contrato real

La actualización del contrato en Blockchain implica principalmente cambios en la lógica de negocios. La actualización de la lógica comercial no es necesario migrar el estado de activo a un nuevo lugar.

Para cambiar la lógica comercial del contrato de Ethereum, a menudo es necesario «externalizar» la lógica comercial al contrato de la agencia.

(Fuente de la imagen: Academia WTF)

En algunos escenarios, si el antiguo contrato de Ethereum se abandona en todo momento, el estado del activo en el interior no se puede migrar directamente a un nuevo lugar, lo cual es muy problemático; «El viejo. Estado.

4. Falta de paralelización de transacciones

Para aumentar el grado paralelo de diferentes instrucciones de transacción tanto como sea posible, la necesidad de dispersar y almacenar el estado del activo de diferentes personas, que se pueden ver en Bitcoin, CKB y Sui.El requisito previo para los objetivos anteriores es despegar la lógica comercial y los datos de estado de activos de contratos inteligentes.Aunque Starknet aún no se ha llevado a cabo en la implementación tecnológica profundamente tecnológica de transacciones paralelas, tomará las transacciones paralelas como un objetivo importante en el futuro.

La implementación nativa de AA y el contrato de cuenta de Starknet

De hecho, la abstracción de la cuenta llamada y AA son los conceptos únicos inventados por la comunidad de Ethereum. evitado desde el principio.Por ejemplo, bajo la configuración de Ethereum, el controlador de cuenta EOA debe tener ETH en la cadena para iniciar las transacciones.Algunas personas incluso piensan que el diseño de esta cuenta en Ethereum es simplemente antihumano.

Si vamos a observar a Starknet o Zksyncera, etc.«AA nativo»La cadena puede observar la diferencia obvia: primero,Starknet y Zksyncera unifican el tipo de cuenta.(La era de ZKSYNC implementará un conjunto de código de contrato de forma predeterminada en la cuenta recién creada del usuario para simular las características de la cuenta EOA Ethereum, que es conveniente para la compatibilidad con Metamask).

Starknet no considera directamente compatible con Metamask y otras instalaciones alrededor de Ethereum.Cuando los usuarios usan la billetera Starknet por primera vez, implementarán automáticamente una cuenta de contrato dedicada.Esta instancia de contrato se asociará con la clase de contrato desplegada por la fiesta del proyecto de billetera por adelantado, lo que puede llamar directamente a algunas de las funciones escritas en clase.

A continuación hablaremos sobre un tema interesante:Al recibir el Airdrop STRK, muchas personas encuentran que Argent y la billetera Braavos son incompatibles entre sí.Después de importar las notas de Argent en Braavos, la cuenta correspondiente no se puede exportar.Esto se debe a que Argent y Bravos usan diferentes métodos de cálculo de generación de cuentas.La dirección de la cuenta generada por el mismo SIDA es diferente.

Específicamente, en Starknet, la dirección del contrato recién implementada se puede obtener a través de un algoritmo de certeza.

PEDERSEN () En la fórmula anterior es un proceso que es fácil de usar en el sistema ZK para generar una cuenta. esencia de la dirección de la cuenta

La imagen de arriba muestra algunos parámetros utilizados cuando Starknet genera «nueva dirección de contrato».

La sal es el valor de sal de la dirección del contrato.Esta variable es para evitar la dirección del contrato introducida repetidamente.Class_hash se introduce anteriormente, y los valores hash de clase correspondientes a la instancia del contrato.Constructor_calldata_hash representa el hash en nombre del contrato para la inicialización del contrato.

Según las fórmulas anteriores, los usuarios pueden calcular previamente la dirección del contrato generada antes de la implementación del contrato en la cadena.Starknet permite a los usuarios implementar directamente los contratos sin la cuenta de Starknet por adelantado.

1. El usuario primero determina la instancia del contrato que quiere implementar, qué clase de contrato debe estar asociada, y usa el hash de la clase como uno de los parámetros de inicialización, y calcule la sal para aprender sobre la dirección del contrato del contrato;

2. Después de que el usuario sabe dónde implementará el contrato, primero transfiera a la dirección a una cierta cantidad de ETH como una tarifa de implementación del contrato.En términos generales, esta parte de ETH a través del puente de la cadena desde L1 hasta la red Starknet;

3. El usuario inicia una solicitud de transacción para la implementación del contrato.

de hecho,Todas las cuentas de Starknet se implementan a través del proceso anterior, pero la mayoría de las billeteras protegen los detalles en el interior.Es como si la cuenta del contrato se implementara después de transferir a ETH.

La solución anterior trae algunos problemas de compatibilidad, porque cuando diferentes billeteras generan direcciones de cuentas, los resultados resultantes no son consistentes.Solo se pueden mezclar billeteras que cumplan con las siguientes condiciones:

1. La clave pública derivada de la clave privada utilizada por las billeteras es la misma que el algoritmo de firma;

2. El proceso de cálculo de sal de la billetera es el mismo;

3. La clase de contrato inteligente de la billetera no es fundamentalmente diferente en los detalles de implementación;

En los casos anteriores, Argent y Braavos usan el algoritmo de firma ECDSA, pero el método de cálculo de sal de ambos lados es diferente.

Regresamos al tema de la abstracción de la cuenta.Starknet y Zksync Era hacen una serie de procesos involucrados en el proceso de procesamiento de transacciones, como la autenticación (firma digital de verificación) y el pago de la tarifa de gas, todos los cuales se mueven fuera de la «parte inferior de la cadena».Los usuarios pueden personalizar los detalles de la lógica anterior en su cuenta.

Por ejemplo, puede implementar una función de verificación de firma digital dedicada en su cuenta de contrato inteligente de Starknet,Cuando el nodo Starknet recibe la transacción que inició, llamará a una serie de lógica de procesamiento de transacciones que personalizó en la cuenta en la cadena.Obviamente, esto es más flexible.

En el diseño de Ethereum, la lógica como la autenticación (firma digital) se escribe en el código del cliente de nodo, y no puede admitir de forma nativa la personalización de las funciones de la cuenta.



(El diagrama esquemático AA original establecido por el arquitecto de Starknet, la verificación de la transacción y la verificación de Gas presentada se han transferido al contrato para manejarlo. La máquina virtual subyacente de la cadena puede llamar a la función personalizada o especificada del usuario)

Según el personal oficial de Zksyncera y Starknet, este conjunto de función de cuenta se ha modularizado y se aprende el EIP-4337.Pero la diferencia es que Zksync y Starknet fusionaron el tipo de cuenta desde el principio, unificaron el tipo de negociación y recibieron todas las transacciones con una entrada unificada.Debido a que Ethereum tiene cargas históricas y la Fundación espera evitar esquemas iterativos ásperos, como las horquillas duras tanto como sea posible, apoya el esquema de «curva para salvar el país» EIP-4337.Pero este efecto es que la cuenta EOA y la solución 4337 adoptan un proceso de procesamiento de transacciones independiente, que se ve incómodo e inflable, a diferencia del espíritu AA nativo.



(Fuente de la imagen: ArgentWallet)

Pero la abstracción de la cuenta nativa de Starknet aún no ha alcanzado una madurez completa.Desde la perspectiva del progreso práctico, la cuenta AA de Starknet se ha dado cuenta de la personalización de los algoritmos de verificación de la firma, pero para la personalización de las tarifas de manejo, Starknet en realidad solo admite las tarifas de gas de pago ETH y STRK, y no ha admitido el gas de pago de terceros.Por lo que se puede decir que el progreso de Starknet en AA nativo es«La solución teórica es básicamente madura, y la solución práctica sigue avanzando».

Debido a que solo hay una cuenta de contrato inteligente en Starknet, todo el proceso de sus transacciones considera la influencia de los contratos inteligentes de la cuenta.En primer lugar, el grupo de memoria del nodo Starknet (MEMPOOL) acepta una transacción, y los pasos de verificación incluyen:

1. Si la firma digital de la transacción es correcta.

2. ¿Se puede pagar el saldo del iniciador de transacción?

Cabe señalar aquí que usar la función de verificación de firma personalizada en el contrato inteligente de la cuenta significa que hay un escenario de ataque.Porque el grupo de memoria no cobra la tarifa de gas al firmar la nueva verificación de la transacción(Si cobra la tarifa de gas directamente, traerá escenarios de ataque más serios).Los usuarios maliciosos pueden personalizar las funciones de firma súper complicadas en su contrato de cuenta, y luego iniciar una gran cantidad de transacciones, de modo que cuando se verifiquen estas transacciones, llamen a la función de firma compleja personalizada.

Para evitar esta situación, Starknet tiene los siguientes límites en las transacciones:

1. Durante el tiempo de la unidad, el número de bolígrafos de transacción se puede iniciar en el tiempo de la unidad es limitado;

2. La función de verificación de firma personalizada en el contrato de cuenta de Starknet tiene límites en la complejidad, y no se ejecutará una función de firma excesiva.Starknet limita el límite superior del consumo de gas de la función de firma.Al mismo tiempo, otros contratos en el contrato de cuenta no pueden llamar a otros contratos en el contrato de cuenta.

El diagrama de flujo de la transacción Starknet es el siguiente:



Vale la pena señalarPara acelerar aún más el proceso de verificación de transacciones, el cliente del nodo StarkNet implementa directamente el algoritmo de verificación de firma de bravos y billeteras argent.Cuando el nodo encuentra que la transacción genera las dos billeteras de Starknet convencionales, llamará al algoritmo de firma Bravos/Argent que viene con el cliente.

Después de que el clasificador verifica los datos de la transacción (los pasos de verificación del clasificador serán mucho más profundos que la verificación del grupo de memoria), el clasificador empacará la transacción del grupo de memoria y lo enviará al ZK para probar el generador.La transacción que ingresa a este enlace se cargará con gas incluso si falla.

Pero si el lector entiende la historia de Starknet,Encontrará que el Starknet temprano no cobra una tarifa de manejo por la transacción que no se ejecuta,La falla de la transacción más común es que los usuarios tienen solo 1 fondos ETH, pero 10 ETH se transfieren fuera del exterior.

Pero Starknet no cobrará tarifas por tales transacciones de falla en el pasado.Este comercio sin costo desperdiciará los recursos informáticos del nodo Starknet, que derivará la escena del ataque DDoS.En la superficie, parece que la tarifa de manejo para transacciones incorrectas parece ser muy fácil de lograr, pero en realidad es bastante complicada.Starknet lanzó la nueva versión del lenguaje El Cairo1, que es en gran medida para resolver el problema de recolectar el gas de las transacciones de falla.

Todos sabemos que la prueba de ZK es una prueba efectiva, y el resultado que no se ejecuta no es válido y no puede dejar los resultados de salida en la cadena.Intente probarlo con efectividad para demostrar que la ejecución de una determinada instrucción no es válida, y el resultado de la salida no puede generarse.Por lo tanto, en el pasado, cuando se generó el Starknet, las transacciones de falla que no pudieron producir los resultados de la salida se planificaron directamente.

El equipo de Starknet luego adoptó una solución más inteligente,Se construye un nuevo lenguaje de contrato Cairo1, para que «todas las instrucciones de transacción puedan generar resultados de salida y en la cadena».A primera vista, todas las transacciones pueden producir salida, lo que significa que no hay un error lógico, y la mayoría de las veces la transacción falla porque encontrar algunos errores, lo que hace que la ejecución de la instrucción se interrumpa.

Es difícil lograr la salida de ininterrupción y nunca más exitosa de la transacción, pero de hecho, existe una alternativa muy simple de que cuando la transacción encuentra errores lógicos, también le permite producir el resultado de la salida. Una devolución devolverá uno a un valor falso.

Pero preste atención, devuelva el valor falso y devuelva el resultado de la salida, es decir,En El Cairo1, no importa si la instrucción ha encontrado errores lógicos o si hay una interrupción temporal, el resultado de la salida se puede producir y una cadena.Este resultado de salida puede ser información de error correcta o falsa.

Para Exmple, si hay el siguiente segmento de código:



El _balances :: lea (desde) -Ansum puede informar un error debido al desbordamiento. lo reescribe para la siguiente forma, un resultado de salida aún se devuelve cuando la transacción falla, dejando la cadena,Desde la perspectiva de la percepción, esto es como si todas las transacciones pudieran dejar sin problemas la producción comercial en la cadena, y parece razonable recolectar las tarifas de manejo.



Descripción general del contrato de Starknetaa

Teniendo en cuenta que algunos lectores pueden tener un fondo de programación en este artículo, existe una breve visualización de la interfaz del contrato de abstracción de la cuenta en Starknet:



El __Validate_Declare__ en la interfaz anterior se usa para verificar la transacción declarada iniciada por el usuario, mientras que __Validate__ se usa para la verificación de las transacciones generales, verifica principalmente si la firma del usuario es correcta, y __execute__ se usa para la ejecución de la transacción.Podemos ver que la cuenta de contrato de Starknet admite múltiples, que son múltiples llamadas por defecto.La llamada múltiple puede lograr algunas características muy interesantes, como empacar las siguientes tres transacciones al realizar alguna interacción Defi:

1. La primera transacción autoriza el token al contrato Defi

2. La segunda transacción desencadena la lógica del contrato de defi

3. La tercera transacción está autorizada para autorizar el contrato Defi

Por supuesto, debido a que múltiples llamadas son atómicas, hay un uso más complicado, como realizar ciertas transacciones de arbitraje.

Resumir

• Las características técnicas más importantes de Starknet, incluidos los modelos de contratos inteligentes independientes de lógica y lógica comercial y lógica de negocios, que conducen a ZK.

• El Cairo es un lenguaje ZK común que no solo puede implementar contratos inteligentes en Starknet, o para desarrollar aplicaciones tradicionales. Capa El Bytecode debe transmitirse al lenguaje medio;

• Starknet Smart contratos separados de la lógica comercial y el estado.

• El modelo de contrato inteligente mencionado por encima de Starknet es propicio para la reutilización del código, la reutilización del estado del contrato, el almacenamiento de almacenamiento, la detección de contratos de basura y también conduce a la realización de la paralelización de arrendamiento y transacción.Aunque los dos últimos aún no han aterrizado, la arquitectura del contrato inteligente de El Cairo ha creado «condiciones necesarias» para ello.

• Solo hay una cuenta de contrato inteligente en la cadena de Starknet y sin cuenta EOA.Su solución AA absorbe la idea de ERC-4337 hasta cierto punto, lo que permite a los usuarios elegir un esquema de procesamiento de transacciones altamente personalizado.Para prevenir posibles escenas de ataque, Starknet ha hecho muchas contramedidas y ha realizado exploraciones importantes para el ecosistema AA.