Medición del rendimiento de SNARK: Frontends, backends y el futuro

Un SNARK (argumentos de conocimiento sucintos no interactivos) es una primitiva criptográfica importante que encuentra aplicaciones para la escalabilidad de blockchain (por ejemplo, acumulaciones L2) y privacidad. Los SNARK permiten que alguien le demuestre a un verificador desconfiado V (p. ej., la cadena de bloques de Ethereum) que conocen algunos datos (p. ej., un lote de transacciones válidas). Una forma ingenua de probar esto sería enviar los datos a V, quien podrá entonces comprobar directamente su validez. Un SNARK logra lo mismo, pero con mejores costos para V. En particular, una prueba de SNARK debe ser más corta que la ingenua que comprende los datos en sí. (Para más detalles, vea el borrador de mi libro de texto, Pruebas, argumentos y conocimiento cero. Para obtener una introducción a los SNARK, consulte Sarah Meicklejohn's presentation en la criptografía a16z Serie de investigación de verano.)

Los costos de verificación de SNARK pueden variar, pero se entienden bien y, a menudo, son bastante buenos. Por ejemplo, Morapio las pruebas cuestan alrededor Gas 290,000 para verificar en Ethereum, mientras que las pruebas de StarkWare cuestan alrededor de 5 millones de gas. Los SNARK son potencialmente aplicables en diversos entornos, incluso fuera de las cadenas de bloques; por ejemplo, permiten el uso de sistemas rápidos pero no confiables. servidores y hardware. 

Pero debido a que la verificación SNARK suele ser económica, los principales determinantes de la aplicabilidad son los costos del probador SNARK. P. En esta publicación, explico cómo estimar estos costos para determinar cuándo es razonable usar SNARK y cómo SNARK podría mejorar en el futuro. Vale la pena señalar que este es un espacio de rápido movimiento, y varios de los proyectos discutidos en esta publicación están mejorando activamente su desempeño.

Pero primero: cómo se implementan los SNARK

En la implementación de SNARK, un desarrollador generalmente escribe un programa de computadora ψ que toma como entrada los datos w que el probador afirma saber (w representa Testigo), y comprueba que w es válida. Por ejemplo, en rollups, el programa verificará que todas las transacciones en w están firmados digitalmente, no provocan que los saldos de las cuentas caigan por debajo de cero, etc. El programa ψ luego se alimenta a través de un Interfaz de SNARK que lo compila en un formato que es más adecuado para la aplicación de la tecnología SNARK. Este formato compatible con SNARK se denomina representación intermedia (IR). 

Por lo general, el IR es una especie de instancia de satisfacibilidad del circuito que es equivalente a ψ. Esto significa que el circuito C toma como entrada los datos w, así como algunas entradas adicionales normalmente denominadas "consejos no deterministas", y se ejecuta ψ on w. Las entradas de consejos se utilizan para ayudar C corrida ψ, mientras se mantiene C pequeña. Por ejemplo, cada vez ψ divide dos números x y y, el cociente q y resto r puede proporcionarse como consejo para Cy C simplemente puede comprobar que x = qy + r. Este cheque es menos costoso que hacer C ejecutar un algoritmo de división para calcular q y r desde cero.

Finalmente, se aplica un SNARK para la satisfacibilidad del circuito a C. Esto se llama el back-end SNARK. Para un puñado de problemas altamente estructurados como multiplicación de matrices, circunvolucionesy varios problemas de grafico, existen SNARK conocidos que evitan este paradigma frontend/backend y, por lo tanto, logran un probador mucho más rápido. Pero el enfoque de esta publicación está en los SNARK de propósito general.

Como veremos, los costos de prueba del backend de SNARK crecen con Ces Talla. Acuerdo C pequeño puede ser un desafío, porque los circuitos son un formato extremadamente limitado en el que expresar un cálculo. consisten en puertas conectado por alambres. cada puerta g recibe algunos valores y aplica un muy función simple a esos valores. El resultado luego se alimenta a las puertas "aguas abajo" a través de los cables que emanan de g.

Escalabilidad de SNARK: ¿Cuánto tiempo lleva realmente?

La pregunta clave es, ¿cuánto tiempo más toma el probador SNARK, en relación con simplemente volver a ejecutar ψ en los datos? la respuesta es la probador por encima del SNARK, relativo a comprobación directa de testigos. Esta última expresión se refiere al hecho de que, en la prueba ingenua en la que P envía w a V, V cheques wla validez ejecutando ψ en ella. 

Es útil dividir los gastos generales del comprobador en "gastos generales de interfaz" y "gastos generales de back-end". Si se evalúa el circuito C puerta por puerta es F veces más caro que correr ψ, entonces decimos que la sobrecarga de frontend es F. Si se aplica el probador backend a C is B veces más caro que evaluar C puerta por puerta, entonces decimos que la sobrecarga de backend es B. La sobrecarga total del probador es el producto, F·B. Esta sobrecarga multiplicativa puede ser sustancial incluso si F y B son individualmente modestos. 

En la práctica, F y B ambos pueden ser aproximadamente 1000 o más grandes. Esto significa que los gastos generales totales del probador en relación con la verificación directa de testigos pueden ser de 1 millón a 10 millones o más. Un programa que se ejecuta durante solo un segundo en una computadora portátil puede conducir fácilmente a un probador SNARK que requiere decenas o cientos de días de tiempo de cómputo (un solo subproceso). Afortunadamente, este trabajo es típicamente paralelizable en diversos grados (dependiendo del SNARK). 

En resumen, si desea usar un SNARK en una aplicación hoy, entonces una de estas tres cosas debe ser cierta:

1. La verificación directa de testigos toma mucho menos de un segundo en una computadora portátil.
2. La verificación directa de testigos es particularmente adecuada para la representación en un circuito, por lo que la sobrecarga de interfaz es pequeña.
3. Está dispuesto a esperar días hasta que finalice el probador SNARK y/o pagar enormes recursos informáticos paralelos.

TEl resto de esta publicación explica de dónde provienen los gastos generales de frontend y backend, y cómo los estimo para diferentes SNARK. A continuación, pasaremos a las perspectivas de mejora. 

Separando frontends y backends

Separar completamente los frontends de los backends puede ser un desafío porque diferentes backends admiten diferentes tipos de circuitos. Por lo tanto, las interfaces pueden diferir según el backend con el que esperan interactuar.

Los backends de SNARK generalmente admiten los llamados circuitos aritméticos, lo que significa que las entradas a los circuitos son elementos de algún campo finito, y que las puertas del circuito realizan sumas y multiplicaciones de dos elementos de campo. Estos circuitos corresponden aproximadamente a programas de computadora de línea recta (sin ramas, declaraciones condicionales, etc.) que son de naturaleza algebraica, es decir, su tipo de datos primitivo son elementos de campo. 

La mayoría de los backends en realidad admiten una generalización de circuitos aritméticos a menudo llamados instancias de satisfacción de restricciones de rango 1 (R1CS). Con la notable excepción de Groth16 y sus predecesores, estos SNARK también se pueden hacer para admitir otros IR. Por ejemplo, StarkWare usa algo llamado Representación intermedia algebraica (AIR), que también es similar a una noción llamada Aritmetización PlonKish que puede ser compatible con PlonK y otros backends. La capacidad de algunos backends para admitir IR más generales puede reducir la sobrecarga de los frontends que producen esos IR. 

Los backends también varían en términos de los campos finitos que admiten de forma nativa. Hablaré más sobre esto en la siguiente sección.

Varios enfoques para frontends

Algunos programas de computadora (muy especiales) corresponden naturalmente a circuitos aritméticos. Un ejemplo es el programa de computadora que realiza la multiplicación ingenua de matrices sobre algún campo. Pero la mayoría de los programas de computadora no son lineales ni algebraicos. A menudo implican declaraciones condicionales, operaciones como la división de enteros o la aritmética de coma flotante que no se corresponden naturalmente con la aritmética de campos finitos, y más. En estos casos, la sobrecarga de frontend será sustancial. 

Un enfoque de front-end popular es producir circuitos que esencialmente ejecutan paso a paso una CPU simple, también llamada máquina virtual (VM). Los diseñadores de frontend especifican un conjunto de "operaciones primitivas" análogas a las instrucciones de ensamblaje para procesadores de computadora reales. Los desarrolladores que quieran usar la interfaz escribirán "programas de verificación de testigos" directamente en lenguaje ensamblador o en algún lenguaje de nivel superior como Solidity, y sus programas se compilarán automáticamente en código ensamblador. 

Por ejemplo, StarkWare El Cairo es un lenguaje ensamblador muy limitado en el que las instrucciones ensambladoras permiten sumas y multiplicaciones en un campo finito, llamadas a funciones y lecturas y escrituras en una memoria inmutable (es decir, de una sola escritura). El Cairo VM es una arquitectura de von Neumann, lo que significa que los circuitos producidos por la interfaz esencialmente toman un programa de Cairo como entrada pública y "ejecutan" el programa en el testigo. El lenguaje de Cairo es Turing Complete: a pesar de su conjunto de instrucciones limitado, puede simular arquitecturas más estándar, aunque hacerlo puede ser costoso. La interfaz de El Cairo hace que los programas de El Cairo se ejecuten T instrucciones primitivas en lo que se llama un "grado-2 AIRE con T filas y sobre 50 columnas.” Qué exactamente esto significa no es importante para este post, pero en lo que respecta a los probadores de SNARK, esto corresponde a circuitos con entre 50 y 100 puertas para cada uno de los T pasos de la CPU de Cairo. 

RISC cero adopta un enfoque similar a El Cairo, pero con la máquina virtual siendo el llamado Arquitectura RISC-V, una arquitectura de código abierto con un rico ecosistema de software que está creciendo en popularidad. Como un conjunto de instrucciones muy simple, el diseño de una interfaz SNARK eficiente que lo admita puede ser relativamente manejable (al menos en relación con arquitecturas complicadas como x86 o ARM). A partir de mayo, RISC cero está convirtiendo programas ejecución T instrucciones RISC-V primitivas en AIR de grado 5 con 3T filas y 160 columnas Esto corresponde a circuitos con al menos 500 puertas por paso de la CPU RISC-V. Se prevén mejoras adicionales en un futuro próximo.

Los diversos proyectos zkEVM (por ejemplo, zkSync 2.0, Scroll, Polygon's zkEVM) toman la máquina virtual como (duh) la máquina virtual Ethereum. El proceso de convertir cada instrucción EVM en un "dispositivo" equivalente (es decir, un circuito optimizado que implementa la instrucción) es sustancialmente más complicado que para las arquitecturas Cairo y RISC-V más simples. Por esta y otras razones, algunos de los proyectos zkEVM no están implementando directamente el conjunto de instrucciones EVM, sino compilando programas Solidity de alto nivel en otros lenguajes ensambladores antes de convertirlos en circuitos. Los resultados de desempeño de estos proyectos están pendientes.

Los proyectos de "emulador de CPU" como RISC-V y Cairo producen un solo circuito que puede manejar todos los programas en el lenguaje ensamblador asociado. Los enfoques alternativos son "similares a ASIC", que producen diferentes circuitos para diferentes programas. Este enfoque similar a ASIC puede generar circuitos más pequeños para algunos programas, especialmente cuando la instrucción de ensamblaje que ejecuta el programa en cada paso de tiempo no depende de la entrada del programa. Por ejemplo, potencialmente puede evitar la sobrecarga de frontend por completo para programas de línea recta como la multiplicación de matriz ingenua. Pero el enfoque ASIC también parece muy limitado; que yo sepa, no se sabe cómo usarlo para admitir bucles sin límites de iteración predeterminados. 

El componente final de la sobrecarga de interfaz proviene del hecho de que todos los SNARK utilizan circuitos que operan sobre campos finitos. La CPU de su computadora portátil puede multiplicar o sumar dos números enteros con una sola instrucción de máquina. Si una interfaz genera un circuito sobre un campo de características lo suficientemente grandes, esencialmente puede simular esa multiplicación o suma a través de la operación de campo correspondiente. Sin embargo, implementar la operación de campo en una CPU real generalmente requerirá muchas instrucciones de máquina (aunque algunos procesadores modernos tienen soporte nativo para ciertos campos). 

Algunos backends de SNARK permiten opciones de campo más flexibles que otros. Por ejemplo, si el backend hace uso de un grupo criptográfico G, el campo del circuito tiene que coincidir con el número de elementos en G, que puede ser limitante. Además, no todos los campos admiten algoritmos FFT prácticos. 

Solo hay un SNARK implementado, Destruir, que admite de forma nativa cálculos en campos arbitrarios (lo suficientemente grandes). junto con su descendientes, tiene el rendimiento de probador concreto más rápido conocido, incluso en campos compatibles con otros SNARK, pero sus pruebas son actualmente demasiado grandes para muchas aplicaciones de blockchain. Trabajo reciente busca mejorar el tamaño de la prueba, pero el probador es asintóticamente más lento y hay parece ser las barreras a la practicidad.

Algunos proyectos han optado por trabajar sobre campos con aritmética particularmente rápida. Por ejemplo, plonky2 y otros usan un campo de característica 2⁶⁴ 2 Mayo³² + 1 porque la aritmética en este campo se puede implementar varias veces más rápido que en campos menos estructurados. Sin embargo, el uso de una característica tan pequeña puede generar desafíos en la representación eficiente de la aritmética de enteros a través de operaciones de campo (p. ej., multiplicar dos enteros de 32 bits sin signo puede generar un resultado mayor que la característica de campo). 

 Pero pase lo que pase, para que todos los SNARK populares hoy en día logren 128 bits de seguridad (sin un aumento significativo en los costos de verificación), tienen que trabajar en un campo de tamaño superior a 2¹²⁸. Por lo que puedo decir, esto significa que cada operación de campo requerirá al menos unas diez multiplicaciones de máquina de 64 bits y considerablemente más adiciones y operaciones bit a bit. Por lo tanto, se debe tener en cuenta al menos un orden de magnitud de sobrecarga de frontend debido a la necesidad de circuitos que operen sobre campos finitos. 

Para resumir, las interfaces existentes que usan una abstracción de máquina virtual producen circuitos con puertas de 100x a 1000x por paso de la máquina virtual, y posiblemente más para máquinas virtuales más complicadas. Además de eso, la aritmética de campos finitos es al menos 10 veces más lenta que las instrucciones análogas en los procesadores modernos (con posibles excepciones si el procesador tiene soporte incorporado para ciertos campos). Un "enfoque de interfaz ASIC" podría reducir algunos de estos gastos generales, pero actualmente está limitado en cuanto a los tipos de programas que puede admitir.

¿Cuáles son los cuellos de botella del back-end?

Los SNARK para la satisfacción del circuito se diseñan típicamente combinando un protocolo teóricamente seguro de la información llamado "PIO polinomial” con un protocolo criptográfico llamado “esquema de compromiso polinomial.” En la mayoría de los casos, el cuello de botella concreto para el probador es el esquema de compromiso polinomial. En particular, estos SNARK tienen el probador comprometido criptográficamente con uno o más polinomios cuyo grado es (al menos) |C|, el número de puertas en el circuito C. 

A su vez, el cuello de botella concreto dentro del esquema de compromiso polinómico dependerá del esquema utilizado y del tamaño del circuito. Pero siempre será una de las siguientes tres operaciones: cálculo de FFT, exponenciaciones en un grupo criptográfico o Merkle-hashing. Merkle-hashing suele ser un cuello de botella solo si el circuito es pequeño, por lo que no lo discutiremos más. 

Compromisos polinómicos basados ​​en logaritmos discretos

En compromisos polinómicos basados ​​en la dureza del problema del logaritmo discreto en un grupo criptográfico G (KZG, A prueba de balas, Galloy Confirmación de Hyrax), el probador tiene que calcular un Compromiso de vector de Pedersen a los coeficientes del polinomio. Esto implica una multiexponenciación, de tamaño igual al grado del polinomio. En SNARK, este grado suele ser el tamaño |C| del circuito C.

Hecho ingenuamente, una exponenciación múltiple del tamaño |C| requiere alrededor de 1.5·|C|·log |G| ≈ 400·|C| operaciones de grupo, donde |G| denota el número de elementos en el grupo G. Sin embargo, existe un enfoque, llamado algoritmo de Pippenger, que puede reducir esto por un factor de aproximadamente log |C|. Para circuitos grandes (digamos, |C| ≥ 225), este registro |C| el factor puede ser concretamente 25 o más, es decir, para circuitos grandes, esperamos que el compromiso del vector de Pedersen pueda ser computable con un poco más de 10·|C| operaciones de grupo. Cada operación de grupo, a su vez, tiende a ser (como un estadio de béisbol muy aproximado) unas 10 veces más lenta que una operación de campo finito. Los SNARK que utilizan estos compromisos polinómicos son tan caros para P como alrededor de 100·|C| operaciones de campo. 

Desafortunadamente, los SNARK existentes tienen gastos generales adicionales además del factor 100x anterior. Por ejemplo:

• espartanoEl probador de , que utiliza el compromiso polinomial de Hyrax, tiene que ver |C|^½ muchas exponenciaciones múltiples cada una de tamaño |C|^½, debilitando la aceleración del algoritmo de Pippenger por un factor de aproximadamente dos. 
• In Groth16, P debe trabajar en un grupo compatible con el emparejamiento, cuyas operaciones suelen ser al menos 2 veces más lentas que los grupos que no son compatibles con el emparejamiento. P también debe realizar 3 exponenciaciones múltiples en lugar de 1. Combinado, esto da como resultado al menos una desaceleración adicional de factor 6 en relación con el 100·|C| estimación anterior. 
• Marlin y Morapio también requieren emparejamientos y sus probadores para comprometerse con mucho más de 3 polinomios. 
• Para cualquier SNARK que utilice A prueba de balas (p.ej, Halo2, que es más o menos PlonK pero con Bulletproofs en lugar de compromisos polinómicos KZG), el probador tiene que calcular logarítmicamente muchas exponenciaciones múltiples durante la fase de "apertura" del esquema de compromiso, y esto borra en gran medida cualquier aceleración de Pippenger. 

En resumen, los SNARK conocidos que utilizan compromisos de vector de Pedersen parecen tener una sobrecarga de back-end de al menos 200x y hasta 1000x o más. 

Otros compromisos polinómicos

Para SNARK que utilizan otros compromisos polinómicos (como Viernes y Ligero-compromiso), el cuello de botella es que el probador necesita realizar grandes FFT. Por ejemplo, en los AIR de grado 2 producidos por Cairo (con 51 columnas y T filas, una por paso de la CPU de Cairo), el demostrador implementado de StarkWare hace al menos 2 FFT por columna, de longitud entre 16 ·T y 32 ·T. Las constantes 16 y 32 dependen de los parámetros internos de FRI establecidos por StarkWare y se pueden reducir, pero a costa de mayores costos de verificación. 

Con optimismo, una FFT de longitud 32·T toma alrededor de 64·T·registro (32T) multiplicaciones de campo. Esto significa que incluso para valores relativamente pequeños de T (p.ej, T ≥ 2²⁰), el número de operaciones de campo por columna es de al menos 64·25·T= 1600·T. Entonces, la sobrecarga de back-end parece ser al menos de miles. Además, es posible que las FFT grandes se vean aún más obstaculizadas por el ancho de banda de la memoria que por las operaciones de campo. 

En algunos contextos, la sobrecarga de back-end de SNARK que realizan FFT grandes se puede mitigar con una técnica llamada agregación de prueba. Para acumulaciones, esto significaría que P (el servicio de resumen) divide un gran lote de transacciones en, digamos, 10 lotes más pequeños. Para cada pequeño lote i, P produce una prueba de SNARK πi de la validez del lote. Pero P no publica estas pruebas en Ethereum, ya que esto conduciría a un aumento de casi 10 veces en los costos de la gasolina. En cambio, el SNARK se aplica una vez más, esta vez para producir una prueba π estableciendo que P sabe π₁ ...,π₁₀. Es decir, el testigo que P afirma saber son las diez pruebas π₁,…,π₁₀, y la verificación presencial directa aplica el procedimiento de verificación SNARK a cada una de las pruebas. Esta sola prueba π se publica en Ethereum. 

En compromisos polinómicos como FRI y Ligero-commit, existe una fuerte tensión entre P tiempo y V costos, con parámetros internos que actúan como una perilla que puede intercambiar uno por el otro. Ya que π₁ ,…,π₁₀ no se publican en Ethereum, la perilla se puede ajustar para que estas pruebas son grandes, y producirlos es más rápido. Solo en la aplicación final del SNARK, para agregar π₁ ,…,π₁₀ en una sola prueba π, ¿Es necesario configurar el esquema de compromiso para garantizar una pequeña prueba? 

StarkWare planea implementar la agregación de pruebas inminentemente. Este es también el foco de proyectos como plonky2.

¿Cuáles son los otros cuellos de botella para la escalabilidad de SNARK?

Esta publicación se ha centrado en probar equipo, pero otros costos de prueba también pueden ser cuellos de botella de escalabilidad. Por ejemplo, para muchos backends de SNARK, el probador necesita almacenar varios elementos de campo para cada puerta en C, y este costo de espacio puede ser enorme. Por ejemplo, un programa ψ ejecutarse en un segundo en una computadora portátil puede realizar quizás mil millones de operaciones primitivas en un procesador moderno. Como hemos visto, en general uno debe esperar C requerir más de 100 puertas por tal operación. Esto significa 100 mil millones de puertas, lo que, según el SNARK, podría significar decenas o cientos de terabytes de espacio para P. 

Otro ejemplo: muchos SNARK populares (p. ej., Morapio, Marlin, Groth16) requieren una "ceremonia de configuración confiable" complicada para generar una "clave de prueba" estructurada. que debe ser almacenado por el probador. Hasta donde yo sé, el mayor ceremonia de este tipo generó una clave de prueba capaz de admitir circuitos con aproximadamente 2²⁸≈250 millones de puertas. La clave de prueba tiene un tamaño de varias docenas de gigabytes. 

En contextos donde es posible la agregación de pruebas, estos cuellos de botella se pueden mitigar sustancialmente. 

De cara al futuro: perspectivas de SNARK más escalables

Tanto los gastos generales de frontend como los de backend pueden ser de tres órdenes de magnitud o más. ¿Podemos esperar que estos disminuyan sustancialmente en un futuro cercano? 

Creo que lo haremos, hasta cierto punto. En primer lugar, los backends más rápidos de la actualidad (p. ej., espartano y Destruir, y otros SNARK que combinan la protocolo de verificación de suma con compromisos polinómicos) tienen pruebas grandes, generalmente raíz cuadrada en el tamaño del circuito, por lo que la gente realmente no las está usando. Espero que el tamaño de la prueba y el tiempo del verificador se reduzcan significativamente en un futuro cercano a través de una composición de profundidad uno con SNARK de prueba pequeña. Similar a la agregación de pruebas, esto significa que un probador primero generaría una prueba SNARK π con el SNARK de "probador rápido, prueba grande", pero no enviar π a V. Más bien, P usaría un SNARK de prueba pequeña para producir una prueba π' que sabe π, y enviar π" a V. Esto podría reducir en un orden de magnitud los gastos generales de back-end de SNARK que son populares hoy en día. 

En segundo lugar, la aceleración de hardware puede ayudar. Una regla general muy aproximada es que las GPU pueden comprar una aceleración de 10x sobre las CPU, y los ASIC una aceleración de 10x sobre las GPU. Sin embargo, tengo tres preocupaciones en este frente. En primer lugar, las FFT grandes pueden verse obstaculizadas por el ancho de banda de la memoria en lugar de las operaciones de campo, por lo que los SNARK que realizan tales FFT pueden ver aceleraciones limitadas de hardware especializado. En segundo lugar, si bien esta publicación se centró en el cuello de botella del compromiso polinomial, muchos SNARK requieren que el probador realice otras operaciones que son solo un poco menos costosas. Entonces, romper el cuello de botella del compromiso polinomial (por ejemplo, acelerando multi-exponenciaciones en SNARK basados ​​en registros discretos) puede dejar una nueva operación de cuello de botella que no es mucho mejor que la anterior. (Por ejemplo, los SNARK, incluidos Groth16, Marlin y PlonK, también tienen el probador de FFT, además de exponenciaciones múltiples.) Finalmente, los campos y las curvas elípticas que conducen a los SNARK más eficientes pueden continuar evolucionando durante algún tiempo, y eso puede crear desafíos para la aceleración del probador basado en ASIC.

En el lado de la interfaz, es posible que encontremos cada vez más que el enfoque de "emulador de CPU" de proyectos como Cairo, RISC Zero, zkEVM y otros en realidad escalan bastante bien (en términos de rendimiento) con la complejidad de los conjuntos de instrucciones de la CPU. De hecho, esta es precisamente la esperanza de varios proyectos zkEVM. Esto puede significar que, si bien la sobrecarga del frontend sigue siendo de tres órdenes de magnitud o más, los frontends logran admitir máquinas virtuales que se adaptan cada vez más a las arquitecturas de CPU reales. Una preocupación compensatoria es que las interfaces pueden volverse complicadas y difíciles de auditar, a medida que proliferan los dispositivos codificados a mano que implementan instrucciones cada vez más complicadas. Es probable que los métodos formales de verificación desempeñen un papel importante para abordar esta preocupación. 

Finalmente, al menos en las aplicaciones de blockchain, podemos encontrar que la mayoría de los contratos inteligentes que aparecen en la naturaleza utilizan principalmente instrucciones simples y compatibles con SNARK. Esto puede permitir gastos generales bajos en la práctica, al tiempo que conserva la generalidad y la experiencia mejorada del desarrollador que viene con el soporte de lenguajes de programación de alto nivel como Solidity y conjuntos de instrucciones enriquecidos, incluidos los de EVM. 

***

justin thaler is Profesor Asociado en la Universidad de Georgetown. Antes de unirse a Georgetown, pasó dos años como científico investigador en Yahoo Labs en Nueva York, antes de lo cual fue investigador asociado en el Instituto Simons para la Teoría de la Computación en la Universidad de Berkeley. 

***

Agradecimientos: Agradezco a Hamburguesa Elena por proponer el tema de este post, y a Arasu Arun, José Bonneauy Sam Ragsdale para comentarios perspicaces. Un agradecimiento especial también a mi editor, Tim Sullivan.

***

Las opiniones expresadas aquí son las del personal individual de AH Capital Management, LLC ("a16z") citado y no son las opiniones de a16z o sus afiliados. Cierta información contenida aquí se ha obtenido de fuentes de terceros, incluso de compañías de cartera de fondos administrados por a16z. Si bien se tomó de fuentes que se consideran confiables, a16z no ha verificado de forma independiente dicha información y no hace declaraciones sobre la precisión duradera de la información o su idoneidad para una situación determinada. Además, este contenido puede incluir anuncios de terceros; a16z no ha revisado dichos anuncios y no respalda ningún contenido publicitario incluido en ellos.

Este contenido se proporciona solo con fines informativos y no debe considerarse como asesoramiento legal, comercial, de inversión o fiscal. Debe consultar a sus propios asesores sobre estos asuntos. Las referencias a cualquier valor o activo digital son solo para fines ilustrativos y no constituyen una recomendación de inversión ni una oferta para proporcionar servicios de asesoramiento de inversión. Además, este contenido no está dirigido ni destinado a ser utilizado por ningún inversionista o posible inversionista, y bajo ninguna circunstancia se puede confiar en él al tomar una decisión de invertir en cualquier fondo administrado por a16z. (Una oferta para invertir en un fondo a16z se realizará solo mediante el memorando de colocación privada, el acuerdo de suscripción y otra documentación relevante de dicho fondo y debe leerse en su totalidad). Cualquier inversión o compañía de cartera mencionada, referida o descritos no son representativos de todas las inversiones en vehículos administrados por a16z, y no puede garantizarse que las inversiones serán rentables o que otras inversiones realizadas en el futuro tendrán características o resultados similares. Una lista de inversiones realizadas por fondos administrados por Andreessen Horowitz (excluyendo inversiones para las cuales el emisor no ha otorgado permiso para que a16z divulgue públicamente, así como inversiones no anunciadas en activos digitales que cotizan en bolsa) está disponible en https://a16z.com/investments /.

Los cuadros y gráficos proporcionados en el interior tienen únicamente fines informativos y no se debe confiar en ellos al tomar cualquier decisión de inversión. El rendimiento pasado no es indicativo de resultados futuros. El contenido habla sólo a partir de la fecha indicada. Todas las proyecciones, estimaciones, pronósticos, objetivos, perspectivas y/u opiniones expresadas en estos materiales están sujetas a cambios sin previo aviso y pueden diferir o ser contrarias a las opiniones expresadas por otros. Consulte https://a16z.com/disclosures para obtener información adicional importante.