Reenviar el Título Original：解读Starknet智能合约模型与原生AA：特立独行的技术巨匠

Autores originales: Shew & Faust, Asesores de Web3: CryptoNerdCn, Desarrollador principal de Starknet, Fundador de WASM Cairo, Plataforma de desarrollo de Cairo en el lado del navegador

Resumen:

Las principales características tecnológicas de Starknet incluyen el lenguaje Cairo, que es propicio para generar pruebas ZK, AA a nivel nativo, y un modelo de contrato inteligente donde la lógica empresarial es independiente del almacenamiento de estado. Cairo es un lenguaje ZK versátil que se puede utilizar para implementar contratos inteligentes en Starknet, así como desarrollar aplicaciones con inclinaciones tradicionales. Su proceso de compilación introduce a Sierra como un lenguaje intermedio, lo que permite iteraciones frecuentes de Cairo sin cambiar directamente el bytecode subyacente. Además, la biblioteca estándar de Cairo incluye muchas estructuras de datos básicas requeridas para la abstracción de cuentas. Los contratos inteligentes de Starknet separan la lógica empresarial del almacenamiento de datos de estado, a diferencia de las cadenas de EVM. La implementación de contratos Cairo implica tres etapas: compilación, declaración e implementación, donde la lógica empresarial se declara en una clase de Contrato. Las instancias de contratos que contienen datos de estado pueden asociarse con la clase y llamar al código que contiene.

El modelo de contrato inteligente mencionado anteriormente de Starknet es propicio para la reutilización de código, la reutilización de estado de contrato, la estratificación de almacenamiento y la detección de contratos basura. También es propicio para la realización de arrendamiento de almacenamiento y paralelización de transacciones. Aunque los dos últimos aún no se han implementado, la estructura de los contratos inteligentes de Cairo ha creado condiciones necesarias para ellos. · Solo hay cuentas de contrato inteligente en la cadena Starknet y no hay cuentas EOA. Admite la abstracción de cuentas AA a nivel nativo desde el principio. Su plan AA incorpora las ideas de ERC-4337 en cierta medida, lo que permite a los usuarios elegir soluciones de procesamiento de transacciones altamente personalizadas. Para evitar posibles escenarios de ataque, Starknet ha tomado muchas contramedidas y ha realizado exploraciones importantes en el ecosistema AA.

Texto: Tras la emisión de tokens en Starknet, STRK se convirtió gradualmente en un elemento indispensable a los ojos de los observadores de Ethereum. Esta estrella de la capa 2 de Ethereum, conocida por su actitud "independiente" y de "ignorar la experiencia del usuario", se labró silenciosamente su propio territorio en el floreciente ecosistema de la capa 2 compatible con EVM. Debido a su excesivo descuido de los usuarios, e incluso a la creación abierta de un canal de "mendigo electrónico" en Discord, Starknet fue criticado una vez por la comunidad. En medio de acusaciones de ser "inhumanas", su profunda experiencia técnica pareció devaluarse instantáneamente, como si solo la experiencia de usuario y la creación de riqueza lo fueran todo. La frase de "El Templo del Pabellón Dorado" -"el hecho de no ser entendido por los demás había sido mi única fuente de orgullo"- es casi un autorretrato de Starknet. Sin embargo, dejando a un lado estos asuntos triviales del mundo, puramente basados en el gusto técnico de los geeks del código, Starknet y StarkEx, como pioneros de ZK Rollup, son casi tesoros a los ojos de los entusiastas de El Cairo. En la mente de algunos desarrolladores de juegos blockchain, Starknet y Cairo son simplemente todo en Web3, superando a Solidity y Move. La mayor brecha entre los "geeks técnicos" y los "usuarios" hoy en día se atribuye en gran medida a la falta de comprensión de Starknet por parte de la gente. Impulsado por el interés en la tecnología blockchain y la exploración del valor de Starknet, el autor de este artículo parte del modelo de contrato inteligente de Starknet y AA nativo para esbozar brevemente sus soluciones técnicas y diseños de mecanismos, con el objetivo de mostrar las características técnicas de Starknet a más personas, al tiempo que espera ayudar a las personas a comprender a este "llanero solitario incomprendido". Después de una breve introducción al idioma de El Cairo en la siguiente sección, nos centraremos en discutir el modelo de contrato inteligente de Starknet y la abstracción de cuentas nativas, explicando cómo Starknet logra AA nativo. Después de leer este artículo, los lectores también entenderán por qué las frases mnemotécnicas de diferentes billeteras no se pueden mezclar en Starknet. Pero antes de introducir la abstracción de cuentas nativas, primero entendamos el innovador lenguaje Cairo creado por Starknet. En el proceso de desarrollo de El Cairo, hubo versiones tempranas llamadas Cairo0, seguidas de la versión moderna. La sintaxis general de la versión moderna de Cairo es similar a la de Rust y en realidad es un lenguaje ZK versátil. Además de utilizarse para escribir contratos inteligentes en Starknet, también se puede utilizar para el desarrollo de aplicaciones generales. Por ejemplo, podemos desarrollar un sistema de verificación de identidad ZK utilizando el idioma Cairo, y este programa puede ejecutarse en nuestro propio servidor sin depender de la red StarkNet. Se puede decir que cualquier programa que requiera propiedades computacionales verificables puede ser implementado usando el lenguaje Cairo. Y Cairo puede ser actualmente el lenguaje de programación más propicio para generar pruebas de ZK.

Desde la perspectiva del proceso de compilación, Cairo utiliza un método de compilación basado en un lenguaje intermedio, como se muestra en la figura a continuación. Sierra en la imagen es una representación intermedia (IR) en el proceso de compilación del lenguaje Cairo, y Sierra se compilará en una representación de código binario de nivel inferior, llamada CASM, que se ejecuta directamente en el dispositivo nodo de Starknet.

La introducción de Sierra como una representación intermedia facilita que el lenguaje Cairo agregue nuevas características. En muchos casos, solo es necesario manipular el lenguaje intermedio de Sierra sin cambiar directamente el código subyacente de CASM. Esto ahorra muchos problemas y el cliente de nodo de Starknet no necesita actualizarse con frecuencia. De esta manera, se pueden lograr iteraciones frecuentes del lenguaje Cairo sin cambiar la lógica subyacente de StarkNet. La biblioteca estándar de Cairo también incluye muchas estructuras de datos básicas necesarias para la abstracción de cuentas. Otras innovaciones de Cairo incluyen una solución teórica llamada Cairo Native, que planea compilar Cairo en código de máquina de bajo nivel que puede adaptarse a diferentes dispositivos de hardware. Los nodos de Starknet no tendrán que depender de la máquina virtual CairoVM al ejecutar contratos inteligentes. Esto puede mejorar considerablemente la velocidad de ejecución del código [todavía está en la etapa teórica y aún no se ha implementado].

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

A diferencia de las cadenas compatibles con Ethereum, Starknet ha realizado innovaciones revolucionarias en el diseño de su sistema de contrato inteligente, en gran medida en preparación para AA nativos y características próximas como el procesamiento de transacciones paralelas. Aquí, es importante entender que, a diferencia de las cadenas públicas tradicionales como Ethereum, la implementación de contratos inteligentes en Starknet sigue un proceso diferente. Tomemos el ejemplo de implementar un contrato inteligente de Ethereum:

1. Los desarrolladores escriben el código del contrato inteligente localmente y compilan el programa Solidity en bytecode EVM usando un editor. Este bytecode puede ser entendido y procesado directamente por el EVM.

1. El desarrollador inicia una transacción para implementar el contrato inteligente, desplegando el bytecódigo EVM compilado en la cadena de Ethereum.

Fuente: not-satoshi.com

Aunque los contratos inteligentes de Starknet también siguen la idea de "compilar primero y luego implementar", los contratos inteligentes se implementan en la cadena en forma de bytecode CASM compatible con CairoVM. Sin embargo, existen enormes diferencias entre Starknet y las cadenas compatibles con EVM en el método de llamada y el modo de almacenamiento de estado de los contratos inteligentes. Exactamente, el contrato inteligente de Ethereum = lógica empresarial + información de estado. Por ejemplo, el contrato USDT no solo implementa funciones comunes como Transferencia y Aprobación, sino que también almacena el estado de activos de todos los titulares de USDT. El código y el estado están acoplados, lo que conlleva muchos problemas. En primer lugar, no es propicio para la actualización de contratos DAPP y migración de estado, ni es propicio para el procesamiento paralelo de transacciones. Es una pesada carga técnica.

En respuesta a esto, Starknet ha mejorado la forma en que se almacena el estado. En su solución de implementación de contrato inteligente, la lógica comercial de las DApps está completamente desacoplada de los estados de los activos y se almacena por separado. Los beneficios de este enfoque son evidentes: en primer lugar, permite al sistema distinguir rápidamente si hay despliegues de código duplicado o redundante. Así es como funciona: en Ethereum, un contrato inteligente comprende tanto la lógica comercial como los datos de estado. Si varios contratos tienen la misma lógica comercial pero diferentes datos de estado, sus hashes también serán diferentes, lo que dificulta que el sistema determine si existen "contratos basura". Sin embargo, en la solución de Starknet, el código y los datos de estado están separados, lo que facilita que el sistema detecte si el mismo código ha sido desplegado varias veces basándose en el hash de la porción de código. Esto ayuda a evitar el despliegue de código duplicado y ahorra espacio de almacenamiento en los nodos de Starknet.

En el sistema de contrato inteligente de Starknet, la implementación y uso de contratos se dividen en tres etapas: "compilar, declarar e implementar". Si un emisor de activos quiere implementar un contrato de Cairo, primero compila el código escrito en Cairo en formas de bytecode Sierra y CASM de nivel inferior en su dispositivo local. Luego, el implementador del contrato publica una transacción de "declaración", implementando el bytecode CASM y el código intermedio Sierra del contrato en la cadena, nombrado como la Clase de Contrato.

(Fuente: sitio web oficial de Starknet)

Más tarde, si desea utilizar las capacidades de función definidas en el contrato de activos, puede iniciar una transacción de "implementación" a través del frontend de DApp para implementar una instancia de contrato asociada con la Clase de Contrato. Esta instancia mantendrá el estado del activo. Posteriormente, los usuarios pueden llamar a las funciones dentro de la Clase de Contrato para modificar el estado de la instancia del Contrato. De hecho, cualquier persona familiarizada con la programación orientada a objetos debería entender fácilmente lo que representan Clase e Instancia en Starknet. La Clase de Contrato declarada por los desarrolladores solo contiene la lógica empresarial del contrato inteligente, que comprende funciones que cualquiera puede llamar, pero no tiene un estado de activo real, por lo tanto, no implementa directamente "entidades de activos", teniendo solo el "alma" sin el "cuerpo". Sin embargo, cuando los usuarios implementan instancias específicas de Contrato, los activos se "materializan". Si necesita modificar el estado de la "entidad" de activo, como transferir sus tokens a otra persona, puede llamar directamente a las funciones escritas en la Clase de Contrato. El proceso anterior es algo similar a la "instanciación" en lenguajes de programación orientados a objetos tradicionales (aunque no es totalmente idéntico).

Después de que los contratos inteligentes se separan en clases e instancias, la lógica empresarial y los datos de estado se desacoplan, lo que trae las siguientes características a Starknet:

1. Propicio para la realización de la jerarquización del almacenamiento y el sistema de arrendamiento de almacenamiento

La llamada estratificación de almacenamiento significa que los desarrolladores pueden colocar los datos en ubicaciones personalizadas según sus propias necesidades, como en la cadena Starknet. StarkNet está listo para ser compatible con capas DA como Celestia, y los desarrolladores de DAPP pueden almacenar datos en estas capas DA de terceros. Por ejemplo, un juego puede almacenar sus datos de activos más importantes en la red principal de Starknet y almacenar otros datos en capas DA fuera de la cadena como Celestia.Esta solución de personalizar la capa DA de acuerdo con los requisitos de seguridad fue llamada "Volition" por Starknet.

El llamado sistema de alquiler de almacenamiento significa que todos deben seguir pagando por el espacio de almacenamiento que ocupan. Tanto espacio en la cadena como ocupes, teóricamente deberías seguir pagando el alquiler.

En el modelo de contrato inteligente de Ethereum, la propiedad del contrato no está clara, y es difícil distinguir si el desplegador o el poseedor del activo debería pagar "alquiler" por un contrato ERC-20. La función de arrendamiento de almacenamiento no se ha lanzado durante mucho tiempo, y al desplegador solo se le cobra una tarifa cuando se despliega el contrato. Este modelo de tarifa de almacenamiento es irrazonable.

Bajo los modelos de contratos inteligentes de Starknet, Sui, CKB y Solana, la propiedad de los contratos inteligentes está más claramente dividida, lo que facilita la recopilación de fondos de almacenamiento [Actualmente, Starknet no lanza directamente un sistema de arrendamiento de almacenamiento, pero se implementará en el futuro]

1. Lograr la verdadera reutilización de código y reducir la implementación de contratos basura

Podemos declarar un contrato de token general para que se almacene en la cadena como una clase, y luego todos pueden llamar a las funciones en esta clase para implementar sus instancias de token. Además, el contrato también puede llamar directamente el código en la clase, lo que logra un efecto similar a la función de biblioteca en Solidity. Al mismo tiempo, el modelo de contrato inteligente de Starknet ayuda a identificar los “contratos basura”. Esto se explicó anteriormente. Después de admitir la reutilización de código y la detección de contratos basura, Starknet puede reducir significativamente la cantidad de datos cargados en la cadena y reducir la presión de almacenamiento en los nodos tanto como sea posible.

1. Reutilización del "estado" del contrato real

Las actualizaciones de contratos en la cadena de bloques implican principalmente cambios en la lógica empresarial. En el escenario de Starknet, la lógica empresarial de los contratos inteligentes está inherentemente separada del estado de los activos. Si la instancia del contrato cambia la clase del tipo de contrato asociado, se puede completar la actualización de la lógica empresarial. No es necesario migrar el estado de los activos a un nuevo lugar. Esta forma de actualización de contratos es más exhaustiva y nativa que la de Ethereum.

Para cambiar la lógica comercial de un contrato de Ethereum, a menudo es necesario "subcontratar" la lógica comercial a un contrato de agencia y cambiar la lógica comercial del contrato principal cambiando el contrato de agencia dependiente. Sin embargo, este método no es lo suficientemente conciso y no es "nativo".

Fuente: Academia wtf

En algunos escenarios, si el antiguo contrato de Ethereum se abandona por completo, el estado del activo en su interior no se puede migrar directamente al nuevo lugar, lo cual es muy problemático; el contrato de El Cairo no necesita migrar el estado y puede "reutilizar" directamente el estado anterior.

1. Propicio para el procesamiento paralelo de transacciones

Para maximizar el paralelismo de diferentes instrucciones comerciales, un paso necesario es almacenar el estado de activos de diferentes personas en ubicaciones separadas, como se puede ver en Bitcoin, CKB y Sui. El requisito previo para el objetivo anterior es separar la lógica comercial de los contratos inteligentes de los datos de estado de activos. Aunque Starknet aún no ha llevado a cabo una implementación técnica profunda de transacciones paralelas, considerará las transacciones paralelas como un objetivo importante en el futuro.

Implementación del contrato AA nativo de Starknet y despliegue de contrato de cuenta

De hecho, el concepto de abstracción de cuentas (AA) y EOA (cuentas propiedad de terceros) fue inventado por la comunidad de Ethereum como un concepto único. En muchas nuevas cadenas públicas, no hay distinción entre las cuentas EOA y las cuentas de contratos inteligentes, evitando desde el principio los inconvenientes del sistema de cuentas estilo Ethereum. Por ejemplo, en la configuración de Ethereum, el controlador de la cuenta EOA debe tener ETH en la cadena antes de poder iniciar una transacción. No hay forma de elegir directamente una variedad de métodos de autenticación, y es extremadamente problemático agregar lógica de pago personalizada. Algunas personas incluso piensan que el diseño de cuentas de Ethereum es simplemente antihumano.

Si observamos productos emblemáticos como Starknet o la cadena "Native AA" de zkSyncEra, obviamente se pueden observar diferencias: primero, Starknet y zkSyncEra tienen tipos de cuenta unificados. Solo hay cuentas de contratos inteligentes en la cadena. No existe tal cosa como una cuenta EOA desde el principio. (zkSync Era desplegará un conjunto de códigos de contrato por defecto en la cuenta recién creada del usuario para simular las características de la cuenta EOA de Ethereum, de manera que sea compatible con Metamask).

Sin embargo, Starknet no considera directamente la compatibilidad con periféricos de Ethereum como Metamask. Cuando los usuarios utilizan la billetera de Starknet por primera vez, se despliega automáticamente una cuenta de contrato dedicada. En otras palabras, se despliega la instancia de contrato mencionada anteriormente, y esta instancia está asociada con la clase de contrato desplegada previamente por el proyecto de billetera. Los usuarios pueden llamar directamente a algunas de las funcionalidades escritas en la clase. Ahora, profundicemos en un tema interesante: al reclamar airdrops de STRK, muchas personas encontraron que las billeteras Argent y Braavos no eran compatibles entre sí. Importar la mnemotecnia de Argent a Braavos no permitía exportar la cuenta correspondiente, principalmente debido a los diferentes algoritmos de generación de cuentas utilizados por Argent y Braavos, lo que resultaba en direcciones de cuenta diferentes generadas a partir de la misma mnemotecnia. Específicamente, en Starknet, la dirección del contrato recién desplegado se puede derivar a través de un algoritmo determinista, de la siguiente manera:

La función ‘pedersen()’ mencionada anteriormente es un algoritmo hash que es fácil de usar en sistemas ZK. El proceso de generación de la cuenta implica proporcionar varios parámetros especiales a la función pedersen para generar el hash correspondiente, que es la dirección de cuenta generada. La imagen anterior muestra los parámetros utilizados por Starknet para generar la “nueva dirección del contrato”. La ‘deployer_address’ representa la dirección del “desplegador del contrato”. Este parámetro puede estar vacío, lo que significa que incluso si no tienes una cuenta de contrato Starknet con antelación, aún puedes desplegar un nuevo contrato. La ‘salt’ es el valor de sal utilizado para calcular la dirección del contrato, que es esencialmente un número aleatorio introducido para evitar direcciones de contrato duplicadas. La ‘class_hash’ corresponde al valor hash de la clase mencionada anteriormente, con la que está asociada la instancia del contrato. El ‘constructor_calldata_hash’ representa el hash de los parámetros de inicialización del contrato.

Basándose en la fórmula anterior, los usuarios pueden calcular la dirección del contrato generado antes de implementar el contrato en la cadena. Starknet permite a los usuarios implementar contratos directamente sin necesidad de tener una cuenta de Starknet de antemano, de la siguiente manera:

1. Los usuarios primero determinan la instancia del contrato que desean implementar y con qué clase de contrato asociarla, utilizando el hash de la clase como uno de los parámetros de inicialización, y calculan la sal para determinar la dirección del contrato generado.
2. Después de saber dónde desplegarán el contrato, los usuarios primero transfieren una cierta cantidad de ETH a esa dirección como tarifa de despliegue del contrato. Generalmente, este ETH necesita ser transferido de L1 a la red Starknet a través de un puente entre cadenas.
3. Los usuarios inician la solicitud de transacción para implementar el contrato.

De hecho, todas las cuentas de Starknet se despliegan a través del proceso anterior, pero la mayoría de las billeteras protegen los detalles, y los usuarios no perciben el proceso como si su cuenta de contrato se desplegara tan pronto como transfieren ETH.

La solución anterior ha traído algunos problemas de compatibilidad, porque cuando diferentes billeteras generan direcciones de cuenta, los resultados generados son inconsistentes. Solo las billeteras que cumplan con las siguientes condiciones pueden ser mezcladas:

1. La clave privada derivada de la clave pública utilizada por la billetera es la misma que el algoritmo de firma;
2. El proceso de cálculo de sal de la billetera es el mismo;
3. Las clases de contrato inteligente de la billetera no son fundamentalmente diferentes en los detalles de implementación; \

En el caso mencionado anteriormente, tanto Argent como Braavos utilizaron el algoritmo de firma ECDSA, pero los métodos de cálculo para la sal eran diferentes entre los dos, lo que resultó en direcciones de cuenta inconsistentes generadas a partir de la misma mnemotecnia.

Ahora, volvamos al tema de la abstracción de cuentas. Starknet y zkSync Era han trasladado una serie de procesos relacionados con el procesamiento de transacciones, como la verificación de identidad (verificación de firmas digitales) y el pago de tarifas de gas, fuera de la 'capa de la cadena'. Los usuarios pueden personalizar los detalles de implementación de la lógica mencionada en sus propias cuentas. Por ejemplo, puedes implementar una función dedicada de verificación de firma digital en tu cuenta de contrato inteligente Starknet. Cuando un nodo de Starknet recibe una transacción iniciada por ti, llamará a una serie de lógica de procesamiento de transacciones personalizada por ti en la cadena.

Este enfoque claramente ofrece más flexibilidad. Sin embargo, en el diseño de Ethereum, la lógica, como la verificación de identidad (firmas digitales), está codificada en el código del cliente del nodo y no puede admitir nativamente funciones de cuenta personalizables.

Diagrama esquemático de la solución AA nativa especificada por el arquitecto de Starknet. La verificación de transacciones y la verificación de la calificación de la tarifa de gas se transfieren al contrato en cadena para su procesamiento. La máquina virtual subyacente de la cadena puede llamar a estas funciones personalizadas o especificadas por el usuario.

Según los funcionarios de zkSyncEra y Starknet, este enfoque modular de la funcionalidad de la cuenta está inspirado en EIP-4337. Sin embargo, lo que los distingue es que zkSync y Starknet fusionaron tipos de cuentas desde el principio, tipos de transacciones unificados y utilizaron un único punto de entrada para recibir y procesar todas las transacciones. En contraste, Ethereum, debido a la carga histórica y al deseo de la fundación de evitar estrategias de iteración agresivas como las bifurcaciones duras tanto como sea posible, apoyó el EIP-4337, utilizando una forma diferente de resolver el problema. Sin embargo, el resultado es que las cuentas EOA y las soluciones EIP-4337 tienen flujos de procesamiento de transacciones independientes, que parecen torpes y engorrosos, a diferencia de la agilidad de las AA nativas.

Fuente: ArgentWallet

Sin embargo, la abstracción de cuenta nativa en Starknet aún no ha alcanzado su plena madurez. Desde un punto de vista práctico, si bien las cuentas AA de Starknet han implementado algoritmos personalizados de verificación de firma, actualmente solo admiten pagar tarifas de gas en ETH y STRK, y aún no admiten el pago de gas de terceros. Por lo tanto, el progreso de Starknet en las AA nativas se puede describir como "el marco teórico es en su mayoría maduro, mientras que la implementación práctica aún está en progreso". Dado que Starknet solo tiene cuentas de contratos inteligentes internamente, todo el proceso de sus transacciones tiene en cuenta la influencia de los contratos inteligentes de cuenta. Primero, después de que una transacción es recibida por el grupo de memoria (Mempool) del nodo de Starknet, se somete a verificación, que incluye:

1. Comprobando si la firma digital de la transacción es correcta, momento en el que se llama a la función de verificación personalizada de la cuenta del firmante;
2. Verificar si el saldo de la cuenta del iniciador puede cubrir la tarifa de gas. \

Cabe destacar aquí que el uso de la función de verificación de firma personalizada en el contrato inteligente de la cuenta implica un escenario de ataque. Debido a que la pool de memoria no cobra comisiones de gas al verificar la firma de nuevas transacciones. (Si se cobraran comisiones de gas directamente, ocurrirían escenarios de ataque más graves). Los usuarios malintencionados pueden personalizar primero una función de verificación de firma súper compleja en su contrato de cuenta, y luego iniciar una gran cantidad de transacciones. Cuando estas transacciones se verifiquen, llamarán a la función de verificación de firma compleja personalizada, lo que puede agotar directamente los recursos informáticos del nodo. Para evitar esta situación, StarkNet impone las siguientes restricciones a las transacciones:

1. Hay un límite superior en el número de transacciones que un solo usuario puede iniciar dentro de un tiempo unitario;
2. La función de verificación de firma personalizada en el contrato de cuenta de Starknet tiene limitaciones de complejidad, y las funciones de verificación de firma excesivamente complejas no se ejecutarán. Starknet limita el límite de consumo de gas de la función de verificación de firma. Si la cantidad de gas consumida por la función de verificación de firma es demasiado alta, la transacción será rechazada directamente. Al mismo tiempo, no se permite que la función de verificación de firma en el contrato de cuenta llame a otros contratos.

El diagrama de flujo de las transacciones de Starknet es el siguiente:

Vale la pena señalar que, para acelerar aún más el proceso de verificación de transacciones, el cliente del nodo Starknet ha implementado directamente los algoritmos de verificación de firmas de las billeteras Braavos y Argent. Cuando un nodo detecta transacciones generadas a partir de estas dos principales billeteras principales de Starknet, llamará a los algoritmos de firma Braavos/Argent incorporados en el cliente. A través de este enfoque similar al almacenamiento en caché, Starknet puede acortar el tiempo de verificación de la transacción. Después de que los datos de la transacción sean validados por el secuenciador (los pasos de verificación del secuenciador son mucho más exhaustivos que los del grupo de memoria), el secuenciador empaquetará y enviará las transacciones del grupo de memoria al generador de pruebas ZK. A las transacciones que entren en esta etapa se les cobrarán tarifas de gas incluso si fallan. Sin embargo, si los lectores están familiarizados con la historia de Starknet, notarán que las versiones anteriores de Starknet no cobraban tarifas por transacciones fallidas. El escenario más común para el fracaso de la transacción es cuando un usuario tiene solo 1 ETH pero intenta transferir 10 ETH externamente, lo que indica claramente un error lógico e inevitablemente fallará, pero nadie conoce el resultado antes de la ejecución. Sin embargo, en el pasado, StarkNet no cobraba tarifas por tales transacciones fallidas. Estas transacciones erróneas gratuitas desperdician recursos computacionales del nodo Starknet y pueden conducir a escenarios de ataque DDoS. A primera vista, cobrar comisiones por transacciones erróneas parece sencillo, pero en realidad es bastante complejo. Starknet introdujo una nueva versión del lenguaje Cairo1 en gran parte para abordar el problema de los cargos por gas para transacciones fallidas. Como todos sabemos, una prueba ZK es una prueba de validez, y el resultado de una transacción fallida no es válido y no puede dejar un resultado de salida en la cadena. Intentar utilizar una prueba de validez para demostrar que la ejecución de una determinada instrucción no es válida y no puede producir resultados de salida suena extraño y es realmente inviable. Por lo tanto, en el pasado, Starknet excluía las transacciones fallidas que no podían producir resultados de salida al generar pruebas. Más tarde, el equipo de Starknet adoptó una solución más inteligente y creó un nuevo lenguaje de contrato, Cairo1, que garantiza que "todas las instrucciones de transacción puedan producir resultados de salida y estar en la cadena". A primera vista, el hecho de que todas las transacciones puedan producir resultados de salida significa que nunca se producen errores lógicos. Sin embargo, la mayoría de las veces, las transacciones fallan porque encuentran errores que interrumpen la ejecución de instrucciones. Garantizar que las transacciones nunca se interrumpan y produzcan resultados de salida con éxito es difícil de lograr, pero en realidad existe una solución alternativa simple, que es permitir que las transacciones produzcan resultados de salida cuando se encuentran errores lógicos que conducen a interrupciones, aunque devolviendo un valor False que indica que la ejecución de la transacción no fue fluida. Es importante tener en cuenta que devolver un valor False también devuelve un resultado de salida, lo que significa que en Cairo1, independientemente de si una instrucción encuentra un error lógico o se interrumpe temporalmente, puede producir resultados de salida y estar en la cadena. Este resultado de salida puede ser correcto o un mensaje de error False. Por ejemplo, considere el siguiente fragmento de código:

En este punto, _balances::read(from) - amount puede causar un error de desbordamiento, lo que resulta en que la instrucción de transacción correspondiente se interrumpa y se detenga sin dejar un resultado de transacción en la cadena. Sin embargo, si se reescribe en la forma siguiente, aún devuelve un resultado de salida cuando la transacción falla, dejándolo en la cadena. Puramente desde un punto de vista estético, parece como si todas las transacciones pudieran dejar suavemente salidas de transacción en la cadena, lo que hace que la recolección uniforme de tarifas parezca particularmente razonable.

Visión general del contrato StarknetAA

Teniendo en cuenta que algunos lectores de este artículo pueden tener antecedentes de programación, aquí hay una breve demostración de la interfaz del contrato abstracto de cuenta en Starknet:

La validar_declararLa interfaz mencionada anteriormente se utiliza para validar transacciones de declaración iniciadas por usuarios, mientras validarse utiliza para la validación general de transacciones, principalmente verificando la corrección de la firma del usuario. Por otro lado, ejecutar se utiliza para la ejecución de transacciones. Es notable que las cuentas de contrato de Starknet admiten inherentemente multicall, lo que permite realizar múltiples llamadas. La funcionalidad de multicall puede facilitar varias características interesantes, como la agrupación de las siguientes tres transacciones al interactuar con ciertos protocolos DeFi:

1. Autorizando tokens al contrato DeFi en la primera transacción.
2. Activando la lógica del contrato DeFi en la segunda transacción.
3. Revocar la autorización al contrato DeFi en la tercera transacción.

Por supuesto, debido a la atomicidad de multicall, existen casos de uso más complejos, como la ejecución de operaciones de arbitraje.

Resumen

Las principales características tecnológicas de Starknet incluyen el lenguaje Cairo optimizado para la generación de pruebas ZK, la abstracción de cuentas a nivel nativo y el modelo de contrato inteligente que separa la lógica empresarial del almacenamiento de estado.

Cairo es un lenguaje ZK versátil que se puede utilizar para contratos inteligentes en Starknet, así como para desarrollar aplicaciones más tradicionales. Su proceso de compilación introduce Sierra como un lenguaje intermedio, lo que permite que Cairo itere con frecuencia sin cambiar el bytecode subyacente, solo propagando los cambios al lenguaje intermedio. La biblioteca estándar de Cairo también incluye muchas estructuras de datos básicas necesarias para la abstracción de cuentas.

Los contratos inteligentes de Starknet separan la lógica empresarial del almacenamiento de datos de estado, a diferencia de las cadenas EVM. La implementación de contratos de Cairo implica tres etapas: compilación, declaración e implementación. La lógica empresarial se declara en las clases de contrato, y las instancias de contrato que contienen datos de estado pueden asociarse con una clase y llamar al código que contiene.

El modelo de contrato inteligente de Starknet facilita la reutilización de código, la reutilización del estado del contrato, la superposición de almacenamiento y la detección de contratos basura. También facilita la implementación del arrendamiento de almacenamiento y la paralelización de transacciones, aunque estas características aún no se han implementado completamente. La arquitectura de los contratos inteligentes de Cairo crea las condiciones necesarias para estas características.

Starknet solo tiene cuentas de contrato inteligente, sin cuentas EOA, y admite la abstracción de cuentas AA a nivel nativo desde el principio. Su solución AA absorbe parcialmente las ideas de ERC-4337, lo que permite a los usuarios elegir soluciones de procesamiento de transacciones altamente personalizadas. Para evitar escenarios de ataque potenciales, Starknet ha implementado varias contramedidas, realizando importantes exploraciones para el ecosistema AA.

Descargo de responsabilidad：

1. Este artículo es reimpreso de [ 极客 Web3]. *Forward the Original Title‘解读Starknet智能合约模型与原生AA：特立独行的技术巨匠’.Todos los derechos de autor pertenecen al autor original [Shew & Faust]. Si hay objeciones a esta reimpresión, por favor contactar al Gate Learnequipo y lo manejarán rápidamente.
2. Descargo de responsabilidad: Las opiniones expresadas en este artículo son únicamente del autor y no constituyen ningún consejo de inversión.
3. Las traducciones del artículo a otros idiomas son realizadas por el equipo de Aprendizaje de Gate. A menos que se mencione lo contrario, copiar, distribuir o plagiar los artículos traducidos está prohibido.