En los límites de los mempools encriptados

El valor que se puede extraer al incluir, excluir o reordenar transacciones en un bloque se conoce como "valor extraíble máximo, o MEV. MEV es común en la mayoría de las blockchains y ha sido un tema de amplio interés y discusión en la comunidad.

Nota: Esta publicación de blog asume una familiaridad básica con MEV. Algunos lectores pueden desear comenzar leyendo nuestro Explicador de MEV.

Muchos investigadores, al observar la situación de MEV, han hecho una pregunta obvia: ¿Puede la criptografía resolver el problema? Un enfoque es un mempool encriptado, donde los usuarios transmiten transacciones encriptadas que solo se revelan después de ser secuenciadas. Por lo tanto, un protocolo de consenso tendría que comprometerse a un orden de transacciones a ciegas, aparentemente evitando la capacidad de aprovechar las oportunidades de MEV durante el proceso de ordenamiento.

Desafortunadamente, por razones prácticas y teóricas, no vemos que los mempools encriptados proporcionen una solución universal al MEV. Esbozamos las dificultades y exploramos cómo podrían diseñarse los mempools encriptados.

Cómo funcionan los mempools encriptados

Ha habido muchas propuestas para mempools encriptados, pero el marco general para mempools encriptados es el siguiente:

1. Los usuarios transmiten sus transacciones encriptadas.
2. Las transacciones encriptadas se comprometen en la cadena (en algunas propuestas después de ser mezclado aleatoriamente de manera demostrable)
3. Después de que se finaliza el bloque de compromiso, las transacciones se descifran.
4. Finalmente, se ejecutan las transacciones.

Ten en cuenta que el paso 3 (desencriptación de transacciones) plantea un desafío importante: ¿quién desencripta y qué pasa si no se realiza la desencriptación? Una solución ingenua sería decir que los propios usuarios desencriptan sus transacciones (en este caso, ni siquiera se necesitaría encriptación, sino que simplemente se podrían ocultar los compromisos). Sin embargo, este enfoque es vulnerable: un atacante puede realizar MEV especulativo.

Con el MEV especulativo, un atacante intenta adivinar que una cierta transacción encriptada genera algún MEV. Encriptan sus propias transacciones que, con suerte, aparecerán en un lugar oportuno (por ejemplo, justo antes o después de una transacción objetivo). Si la transacción se secuencia en el orden esperado, el atacante la descifra y su transacción extrae el MEV. Si no, deciden no descifrar y su transacción no se incluye en la cadena final.

Quizás los usuarios podrían enfrentar alguna penalización por no lograr descifrar, pero esto es complicado de implementar. La penalización tendría que ser la misma para todas las transacciones encriptadas (ya que están encriptadas y, por lo tanto, son indistinguibles), pero también lo suficientemente alta como para desincentivar el MEV especulativo incluso contra objetivos de alto valor. Esto requeriría inmovilizar mucho capital, el cual debería ser anónimo (para evitar filtrar información sobre qué transacciones son publicadas por qué usuarios). Y terminaría costando a los usuarios honestos en caso de un error o fallo de red que impida su intento legítimo de descifrar.

Por lo tanto, la mayoría de las propuestas sugieren que las transacciones se encripten de tal manera que se garantice que la desencriptación sea posible en algún momento en el futuro, incluso si el usuario que publica se desconecta o no coopera. Esto se puede lograr de varias maneras:

TEEs: Los usuarios pueden cifrar sus transacciones a una clave mantenida por un Entorno de Ejecución Confiable (TEE) enclave. En algunas versiones simples, el TEE solo se utiliza para descifrar transacciones después de un cierto plazo (lo que requiere alguna noción de tiempo dentro del TEE). En enfoques más avanzados, se utiliza el TEE para descifrar transacciones y construir el bloque, ordenándolas según algunos criterios como tiempos de llegada o tarifas. Una ventaja de los TEE en comparación con otros enfoques de mempool encriptado es su capacidad para operar en transacciones en texto plano, reduciendo así el spam onchain al filtrar transacciones que revertirían. Sin embargo, este método requiere confianza en el hardware.

Compartición de secretos y cifrado umbral: Con este enfoque, los usuarios cifran transacciones con una clave que es compartida por un comité, típicamente un subconjunto de validadores. Se requiere un umbral (por ejemplo, dos tercios del comité) para la descifrado.

El enfoque más simple utiliza una nueva clave de descifrado compartida en cada ronda (por ejemplo, cada bloque o época en Ethereum), que el comité reconstruye y publica después de que las transacciones se ordenan en un bloque finalizado. Este enfoque puede utilizar un simple reparto de secretos. La desventaja es que esto revela todas las transacciones del mempool, incluso aquellas que no se incluyeron en un bloque. Este enfoque también requiere una nueva generación de clave distribuida (DKG) en cada ronda.

Un mejor enfoque para la privacidad es descifrar solo las transacciones que fueron realmente incluidas. Esto se puede realizar utilizando el descifrado umbral. Este enfoque también permite amortizar el costo de los protocolos DKG, utilizando la misma clave para múltiples bloques con el comité descifrando umbral las transacciones después de que estén ordenadas en un bloque finalizado. Un desafío es que el comité tiene que hacer mucho más trabajo. De manera ingenua, el trabajo del comité es lineal en el número de transacciones a descifrar, aunque recientetrabajosugiere la descifrado de umbral por lotes que puede mejorar esto significativamente.

Con la descifrado de umbral, la confianza se desplaza de una pieza de hardware a un comité. La afirmación es que, dado que la mayoría de los protocolos ya hacen una suposición de mayoría honesta sobre los validadores para el protocolo de consenso, podemos hacer una suposición similar de que la mayoría de los validadores son honestos y no descifrarán transacciones antes de tiempo. Sin embargo, es necesario tener una nota de precaución: estas no son la misma suposición de confianza. Los fallos de consenso como dividir la cadena son públicamente visibles (llamados una suposición de confianza débil), mientras que un comité malicioso que descifra transacciones antes de tiempo generará ninguna evidencia pública y, por lo tanto, tal ataque no puede ser detectado o castigado (una suposición de confianza fuerte). Así, aunque, desde el exterior, las suposiciones de seguridad para el consenso y un comité de cifrado puedan parecer las mismas, consideraciones prácticas hacen que la suposición de que un comité no coludirá sea más tenue.

Cifrado con bloqueo temporal y retraso: Una alternativa al cifrado umbral se presenta en forma de cifrado por retraso. Los usuarios cifran sus transacciones con una clave pública cuya clave secreta está oculta dentro de un rompecabezas con bloqueo temporal. Un rompecabezas con bloqueo temporal es un rompecabezas criptográfico que encapsula un secreto, el cual solo puede ser revelado después de que haya transcurrido un período de tiempo predeterminado; más específicamente, el rompecabezas puede ser descifrado al realizar repetidamente algún cálculo no paralelizable. En este caso, este rompecabezas puede ser abierto por cualquier persona para recuperar la clave y descifrar transacciones, pero solo después de un cálculo lento (inherentemente secuencial) que está diseñado para tomar el tiempo suficiente para que las transacciones no puedan ser descifradas antes de que hayan sido finalizadas. La versión más fuerte de este primitivo utilizaencriptación de retraso para generar públicamente tal acertijo. También se puede aproximar utilizando un comité de confianza para calcular el acertijo a través de cifrado de bloqueo temporal, aunque en ese momento las ventajas sobre el cifrado umbral son cuestionables.

Ya sea mediante cifrado por retraso o computación por un comité de confianza, existen varios desafíos prácticos. Primero, es más difícil asegurar un momento preciso para la descifrado, ya que el retraso es de naturaleza computacional. Segundo, estos esquemas dependen de que alguna entidad ejecute hardware sofisticado para resolver los rompecabezas de manera eficiente. Si bien cualquier persona puede cumplir con este papel, no está claro cómo incentivar a esta parte. Finalmente, en estos diseños, todas las transacciones transmitidas serán descifradas, incluidas aquellas que nunca se finalizaron en un bloque. Las soluciones basadas en umbrales (o cifrado de testigos) podrían potencialmente descifrar solo las transacciones que se incluyan con éxito.

Cifrado de testigos. Finalmente, el enfoque criptográfico más avanzado utiliza una herramienta llamada cifrado de testigos. Teóricamente, la encriptación de testigos permite encriptar información a cualquier persona que conozca el testigo de una relación NP específica. Por ejemplo, se podría encriptar de tal manera que cualquier persona con la solución a un cierto rompecabezas de Sudoku, o cualquier persona con una preimagen de hash de un cierto valor, pueda desencriptar.

Los SNARKs también son posibles para cualquier relación NP. Se puede pensar en la encriptación de testigos como encriptar datos para cualquiera que pueda calcular un SNARK que demuestre una condición deseada. Para los mempools encriptados, un ejemplo de tal condición sería que las transacciones solo pueden ser desencriptadas cuando un bloque ha sido finalizado.

Este es un primitivo teórico muy poderoso. De hecho, es una generalización para la cual los enfoques basados en comités y los enfoques basados en retrasos son casos específicos. Desafortunadamente, no tenemos construcciones prácticas de cifrado basado en testigos. Además, incluso si tuviéramos, no está claro cómo sería una mejora sobre un enfoque basado en comités para cadenas de prueba de participación. Incluso si el cifrado basado en testigos se configura de tal manera que las transacciones solo puedan ser descifradas una vez que estén ordenadas en un bloque finalizado, un comité malicioso aún puede simular de manera privada el protocolo de consenso de tal manera que la transacción se finalice, y luego usar esta cadena privada como testigo para descifrar transacciones. En ese momento, usar el cifrado umbral por el mismo comité proporciona seguridad equivalente y es mucho más simple.

La encriptación de testigos ofrece una ventaja más decisiva en los protocolos de consenso de prueba de trabajo, ya que incluso un comité completamente malicioso no puede minar en privado varios nuevos bloques sobre la cabeza actual para simular la finalización.

Desafíos técnicos para mempools encriptados

Varios desafíos prácticos importantes limitan la capacidad de los mempools encriptados para prevenir el MEV. En general, mantener la información confidencial es difícil. Curiosamente, la encriptación es una herramienta rara vez utilizada en el espacio web3. Pero tenemos décadas de experiencia práctica que muestran los desafíos de implementar la encriptación en la web (TLS/HTTPS) y para la comunicación privada (desde PGP hasta plataformas modernas de mensajería encriptada como Signal o Whatsapp). Si bien la encriptación es una herramienta para preservar la confidencialidad, no la garantiza.

Primero, puede haber partes con acceso directo al texto claro de la transacción de un usuario. En casos típicos, los usuarios pueden no cifrar su propia transacción, sino externalizar esto a su proveedor de billetera. En consecuencia, el proveedor de billetera tiene acceso a la transacción en texto claro y podría usar o vender esta información para extraer MEV. El cifrado nunca es más fuerte que el conjunto de partes con acceso a la clave.

Más allá de esto, el mayor problema es la metadata, es decir, los datos que rodean la carga útil cifrada (transacción), que no están cifrados. Los buscadores pueden usar esta metadata para adivinar la intención de una transacción y luego intentar MEV especulativo. Recuerda, los buscadores no tienen que entender completamente una transacción, ni ser correctos todo el tiempo. Es suficiente si saben, por ejemplo, que con alguna probabilidad razonable una transacción representa una orden de compra de un DEX específico.

Podemos considerar varios tipos de metadatos, algunos de los cuales son desafíos clásicos con la encriptación y algunos de los cuales son únicos para los mempools encriptados.

• Tamaño de la transacción: La encriptación por sí sola no oculta el tamaño del texto plano encriptado. (Hay, notoriamente, una excepción específica hecha en las definiciones formales de seguridad semántica para excluir el ocultamiento del tamaño del texto plano que se está encriptando.) Este es un vector de ataque clásico en la comunicación encriptada. (En un ejemplo famoso, incluso con encriptación, un oyente clandestinopuede determinar qué video se está transmitiendo en tiempo real a través de Netflix desde el tamaño de cada paquete en la transmisión de video.) En el contexto del mempool encriptado, ciertos tipos de transacciones pueden tener un tamaño específico que filtra información.

• Hora de transmisión: La encriptación tampoco oculta la información de tiempo (otravector de ataque clásico). En el contexto de web3, ciertos remitentes —por ejemplo, en ventas estructuradas— podrían realizar transacciones en intervalos regulares. El tiempo de las transacciones también podría estar correlacionado con otra información, como la actividad en intercambios externos o eventos de noticias. Una forma más sutil de explotar la información de tiempo es el arbitraje CEX/DEX. Un secuenciador puede beneficiarse al insertar una transacción creada lo más tarde posible, aprovechando la información más reciente sobre los precios de CEX. El mismo secuenciador podría excluir cualquier otra transacción (incluso si está encriptada) transmitida después de cierto punto en el tiempo, asegurando que su transacción tenga la ventaja de la información de precios más actualizada.

• Dirección IP de origen: Los buscadores podrían inferir la identidad de un remitente de transacciones al monitorear la red peer-to-peer y observar la dirección IP de origen. Este problema en realidad fueidentificado hace más de diez añosen los primeros días de Bitcoin. Esto puede ser útil para los buscadores si los remitentes específicos tienen patrones específicos; por ejemplo, conocer al remitente podría permitir vincular una transacción encriptada a transacciones anteriores que ya han sido desencriptadas.

• Información del remitente de la transacción y tarifas/gas: Finalmente, las tarifas de transacción representan un tipo de metadatos específicos de los mempools encriptados. En Ethereum, las transacciones clásicamente incluyen una dirección de remitente (onchain), que se utiliza para pagar tarifas, así como un presupuesto máximo de gas y una tarifa por unidad de gas que el remitente está dispuesto a pagar. La dirección del remitente, al igual que la dirección de la red de origen, puede usarse para vincular transacciones entre sí y a entidades del mundo real. El presupuesto de gas se puede utilizar para estimar lo que la transacción pretende hacer. Por ejemplo, interactuar con un DEX específico puede requerir una cantidad específica de gas que es identificable.

Los buscadores sofisticados podrían utilizar cualquier combinación de los tipos de metadatos anteriores para predecir el contenido de una transacción.

Toda esta información podría estar potencialmente oculta, pero a un costo de rendimiento y complejidad. Por ejemplo, agregar relleno a las transacciones hasta un límite estándar oculta el tamaño de la transacción, pero desperdicia ancho de banda y espacio en la cadena. Agregar retrasos antes de enviar mensajes oculta el tiempo de la transacción, pero perjudica la latencia. Enviar transacciones a través de una red de anonimato como Tor podría ocultar la dirección IP del remitente, pero esto tiene sus propios desafíos.

Los datos de tarifas de transacción son los metadatos más difíciles de ocultar. Encriptar estos datos crea una serie de desafíos para el constructor. El primer problema es el spam. Si los datos de pago de tarifas de transacción están encriptados, cualquiera puede transmitir transacciones encriptadas malformadas que serán ordenadas pero no tendrán la capacidad de pagar tarifas. Por lo tanto, después de la desencriptación, no podrán ejecutarse, pero ninguna parte podrá ser penalizada. Esto podría abordarse posiblemente con SNARKs que prueban que una transacción está bien formada y financiada, pero esto aumentaría en gran medida la sobrecarga.

El segundo problema es la construcción eficiente de bloques y las subastas de tarifas. Los constructores utilizan tarifas para construir el bloque más rentable y establecer el precio de mercado actual para los recursos en cadena. Cifrar estos datos interrumpe este proceso. Esto podría abordarse estableciendo una tarifa fija en cada bloque, pero esto es económicamente ineficiente y podría fomentar mercados secundarios para la inclusión de transacciones que socavarían el propósito de tener un mempool cifrado. Realizar una subasta de tarifas utilizando computación segura multipartita o hardware de confianza es posible, pero ambos son pasos costosos.

Finalmente, los mempools seguros y cifrados imponen sobrecarga en el sistema de varias maneras. El cifrado añade latencia, sobrecarga computacional y de ancho de banda a la cadena. Cómo combinarlo con el soporte para sharding o ejecución paralela —que son objetivos futuros importantes— está lejos de ser obvio. Podría añadir puntos adicionales de fallo para la vitalidad (por ejemplo, el comité de descifrado para soluciones de umbral o el solucionador de funciones de retraso). Y ciertamente añade complejidad al diseño y la implementación.

Muchos de los problemas de los mempools encriptados son compartidos por blockchains que buscan garantizar la privacidad de las transacciones (por ejemplo, Zcash, Monero). Si hay un lado positivo, es que resolver todos los desafíos de la encriptación para la reducción de MEV tendría como efecto colateral allanar el camino para la privacidad de las transacciones.

Desafíos económicos para los mempools encriptados

Finalmente, los mempools encriptados enfrentan desafíos económicos. A diferencia de los desafíos técnicos, que podrían mitigarse con suficiente esfuerzo de ingeniería, estas son limitaciones fundamentales que parecen difíciles de resolver.

El problema básico del MEV resulta de la asimetría de información entre los usuarios que crean transacciones y los buscadores y constructores que encuentran oportunidades de MEV. Los usuarios típicamente no saben cuánto MEV se puede extraer de sus transacciones. Como resultado, incluso con un mempool encriptado perfecto, los usuarios podrían ser inducidos a renunciar a sus claves de descifrado a cambio de un pago de los constructores que es menor que el valor extraído. Podemos llamar a esto descifrado incentivado.

No es difícil imaginar cómo se vería esto porque una versión de él, llamada MEV Share, existe hoy en día. MEV Share es una subasta de flujo de órdenes que permite a los usuarios enviar selectivamente información sobre sus transacciones a un pool donde los buscadores compiten por la oportunidad de explotar la oportunidad de MEV presentada por la transacción. El buscador con la oferta ganadora extrae el MEV y reembolsa parte de su ganancia (es decir, la oferta o una fracción de la oferta) al usuario.

Este modelo podría adaptarse inmediatamente dentro de un espacio de mempool encriptado, requiriendo que los usuarios revelen sus claves de decripción (o posiblemente solo alguna información parcial) para participar. Pero la mayoría de los usuarios no entenderán el costo de oportunidad de participar en un esquema así, solo viendo las recompensas que les llegan y estando felices de renunciar a su información. También hay ejemplos de finanzas tradicionales (por ejemplo, servicios de trading sin comisiones como Robinhood) que obtienen beneficios al vender el flujo de órdenes de sus usuarios a terceros en un llamado ".pago-por-flujo-de-ordenes” modelo de negocio.

Otros escenarios posibles incluyen a grandes constructores obligando a los usuarios a revelar sus transacciones (o alguna información sobre ellas) por razones de censura. La resiliencia a la censura es un tema importante y controvertido dentro de web3, pero si grandes proponentes y/o constructores están legalmente obligados a hacer cumplir una lista de censura (por ejemplo, por OFAC), pueden negarse a secuenciar cualquier transacción encriptada. Podría ser posible resolver este problema técnicamente, si los usuarios pueden producir una prueba de conocimiento cero que demuestre que su transacción encriptada cumple con la lista de censura, pero esto también añadirá costos y complejidad. Incluso si la cadena tiene una fuerte resistencia a la censura, donde se garantiza que las transacciones encriptadas serán incluidas, los constructores de bloques podrían aún priorizar poner transacciones que conocen en texto claro en la parte superior del bloque y relegar cualquier transacción encriptada a la parte inferior del bloque. Por lo tanto, las transacciones que desean ciertas garantías de ejecución podrían verse obligadas a revelar su contenido a los constructores de todos modos.

Otros desafíos de eficiencia

Los mempools encriptados añaden sobrecarga al sistema de varias maneras obvias. Los usuarios deben encriptar las transacciones y el sistema debe de alguna manera desencriptarlas. Esto añade costo computacional y posiblemente incrementa el tamaño de la transacción. Como se discutió anteriormente, lidiar con los metadatos puede empeorar estas sobrecargas. Sin embargo, algunos otros costos de eficiencia son menos obvios. En finanzas, un mercado se considera eficiente si el precio refleja toda la información disponible, y las ineficiencias surgen de retrasos y asimetrías de información: consecuencias naturales de los mempools encriptados.

Una de las consecuencias de estas ineficiencias es la mayor incertidumbre de precios, el resultado de la demora adicional que introducen los mempools encriptados. Así, es probable que aumente el número de fallos en las operaciones debido a que se supera la tolerancia a la desviación de precios y se desperdicia espacio en la cadena.

De manera similar, esta incertidumbre en los precios también podría llevar a transacciones MEV especulativas que intentan beneficiarse del arbitraje en cadena. Es importante destacar que estas oportunidades podrían ser más comunes con mempools encriptados porque la mayor incertidumbre sobre el estado actual de los DEX, a la luz de la ejecución retrasada, probablemente producirá mercados menos eficientes con discrepancias de precios entre las plataformas. Este tipo de transacciones MEV especulativas también desperdiciarían espacio en el bloque porque a menudo se abortarán si no se encuentran tales oportunidades.

Si bien nuestro objetivo aquí era describir los desafíos en los mempools encriptados, para que las personas puedan centrarse en construir y resolver cosas de otras maneras, pueden ser parte de la solución al MEV.

Una posible solución son los diseños híbridos, donde algunas transacciones se ordenan de manera ciega a través de un mempool encriptado y otras se ordenan a través de otra solución. Para ciertos tipos de transacciones —por ejemplo, órdenes de compra/venta de grandes participantes del mercado que pueden encriptarlas/padearlas cuidadosamente y están dispuestos a pagar más para evitar MEV— los diseños híbridos pueden ser la solución adecuada. Estos diseños también pueden tener sentido para transacciones altamente sensibles, como correcciones de errores en un contrato de seguridad con una vulnerabilidad.

Sin embargo, debido a sus limitaciones tecnológicas, así como a la significativa complejidad de ingeniería y los costos de rendimiento, es poco probable que los mempools encriptados sean la solución mágica al MEV que a veces se dice que son. La comunidad necesitará desarrollar otras soluciones, incluyendo subastas de MEV, defensas a nivel de aplicación y minimización del tiempo de finalización. MEV será un desafío por algún tiempo, y se necesita una cuidadosa investigación para encontrar el equilibrio adecuado de soluciones para gestionar sus desventajas.

Pranav Garimidi es un Asociado de Investigación en a16z Crypto. Realiza investigaciones sobre problemas en el diseño de mecanismos y la teoría de juegos algorítmica en relación con los sistemas de blockchain. Se centra especialmente en cómo los incentivos interactúan a lo largo de la pila de blockchain. Antes de a16z, Pranav fue estudiante en la Universidad de Columbia, donde se graduó con un título en Ciencias de la Computación.

Joseph Bonneaues Profesor Asociado en el Departamento de Ciencias de la Computación del Instituto Courant de la Universidad de Nueva York, y asesor técnico de a16z crypto. Su investigación se centra en la criptografía aplicada y la seguridad en blockchain. Ha enseñado cursos de criptomonedas en la Universidad de Melbourne, NYU, Stanford y Princeton, y obtuvo un doctorado en ciencias de la computación de la Universidad de Cambridge y títulos de BS/MS de Stanford.

Lioba Heimbaches un estudiante de doctorado de cuarto año asesorado por el Prof. Dr. Roger Wattenhofer en el Computación Distribuida (Disco) grupo en ETH Zurich. Su investigación se centra en protocolos de blockchain con un enfoque en finanzas descentralizadas (DeFi). En particular, se enfoca en permitir un ecosistema de blockchain y DeFi accesible, descentralizado, justo y eficiente. Fue pasante de investigación en a16z crypto durante el verano de 2024.

Las opiniones expresadas aquí son las de los individuos citados de AH Capital Management, L.L.C. (“a16z”) y no son las opiniones de a16z ni de sus afiliados. Cierta información contenida aquí ha sido obtenida de fuentes de terceros, incluidas las empresas de cartera de fondos gestionados por a16z. Si bien se ha tomado de fuentes que se creen confiables, a16z no ha verificado de forma independiente dicha información y no hace representaciones sobre la precisión actual o duradera de la información o su idoneidad para una situación dada. Además, este contenido puede incluir anuncios de terceros; a16z no ha revisado dichos anuncios y no respalda ningún contenido publicitario contenido en ellos.

Este contenido se proporciona únicamente con fines informativos y no debe ser considerado como asesoramiento legal, empresarial, de inversión o fiscal. Debe consultar a sus propios asesores en esos asuntos. Las referencias a cualquier valor o activo digital son únicamente para fines ilustrativos y no constituyen una recomendación de inversión ni una oferta para proporcionar servicios de asesoría de inversión. Además, este contenido no está dirigido ni destinado a ser utilizado por ningún inversor o inversor potencial, y no puede ser considerado bajo ninguna circunstancia al tomar una decisión de invertir en cualquier fondo gestionado por a16z. (Una oferta para invertir en un fondo de a16z se realizará únicamente mediante el memorando de colocación privada, el acuerdo de suscripción y otra documentación relevante de cualquier fondo de este tipo y debe leerse en su totalidad.) Cualquier inversión o empresa de cartera mencionada, referida o descrita no es representativa de todas las inversiones en vehículos gestionados por a16z, y no se puede asegurar 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 gestionados por Andreessen Horowitz (excluyendo inversiones para las cuales el emisor no ha proporcionado permiso para que a16z las divulgue públicamente, así como inversiones no anunciadas en activos digitales cotizados públicamente) está disponible en https://a16z.com/investments/.

El contenido habla solo a partir de la fecha indicada. Cualquier proyección, estimación, pronóstico, objetivo, perspectiva y/o opinión expresada en estos materiales está sujeta a cambios sin previo aviso y puede diferir o ser contraria a las opiniones expresadas por otros. Por favor, consulte https://a16z.com/disclosures para información adicional importante.

Aviso legal:

1. Este artículo es reproducido de [a16zcrypto]. Todos los derechos de autor pertenecen al autor original [Pranav GarimidiJoseph Bonneau andy Lioba Heimbach]. Si hay objeciones a esta reimpresión, por favor contacte al Gate Learn equipo, y lo manejarán de manera oportuna.
2. Descargo de responsabilidad: Las opiniones y puntos de vista expresados 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 Gate Learn. A menos que se mencione lo contrario, está prohibido copiar, distribuir o plagiar los artículos traducidos.