Oculto a simple vista: una implementación furtiva de solidez de una subasta de oferta sellada

Nota del editor: este artículo es parte de nuestra serie en curso sobre todo lo relacionado con las subastas para web3. Parte 1 fue una descripción general de los diseños de subastas y los desafíos técnicos (y oportunidades) específicos del diseño de mecanismos en un contexto de cadenas de bloques sin permiso. Parte 2 era un artículo sobre cómo limpiar el mercado y evitar las guerras del gas. Parte 3 comparte una descripción general de los tipos de subastas canónicas, una mirada a cómo la teoría se traduce en la práctica y nuestra primera implementación de una novedosa subasta de Vickrey con oferta sellada. 

Las subastas en cadena son uno de los espacios de diseño más interesantes (y ubicuos) en web3, desde ventas de NFT hasta subastas colaterales, lo que da lugar a un nuevo panorama de implementaciones e investigación. Si bien el diseño del mecanismo de subasta ha existido durante siglos y ha evolucionado en las últimas décadas con la llegada de la web y el comercio electrónico, solo ahora estamos aplicando estos enfoques a los contratos inteligentes.

También estamos empezando a ver más diseños de subastas que son nativos de las cadenas de bloques, incluidos nuestros de código abierto Solidez implementación de una subasta de Vickrey, y varios desarrollos interesantes de la comunidad (incluyendo sugerencias para mejoras de eficiencia, nuevos resultados teóricos, y dos ganador del hackathon implementaciones de subastas en sobre cerrado). En nuestro primer diseño, hicimos una compensación entre la privacidad y la eficiencia del capital: utilizamos la sobregarantía (los postores aseguran más garantías de las requeridas por su oferta) para hacer cumplir el pago del postor ganador, sin revelar los valores precisos de la oferta a través de la garantía. Monto. Al bloquear más capital, obtiene más privacidad a un costo de oportunidad potencialmente mayor. Pero, ¿y si pudiéramos ofrecer privacidad? sin ¿sobrecolateralización? 

Esta publicación presenta un nuevo diseño de subasta que llamamos "SneakyAuction", que combina la CREATE2 código de operación y pruebas estatales para garantizar la privacidad de la oferta sin exigir a los licitadores que guarden más garantías de las requeridas. Comenzamos desglosando cómo funciona y luego lo comparamos con nuestra implementación anterior (OverCollateralizedAuction) en términos de costo de gasolina, experiencia del usuario y privacidad. También hemos agregado la implementación a nuestro Zoológico de subastas repositorio en GitHub para que pueda bifurcarlo, desarrollarlo y seguirlo mientras nos sumergimos en más mecánicas; mientras tanto, más información sobre cómo funciona y se compara con nuestro diseño anterior a continuación. 

Como Funciona: Comprometerse con las ofertas usando CREATE2

Hay dos requisitos que necesitamos para crear una subasta de oferta sellada "eventualmente pública" en cadena. Primero, las ofertas deben ser privadas durante el período de licitación y luego revelarse cuando finaliza; Los esquemas de compromiso-revelación (donde los usuarios publican valores comprometidos con hash y luego revelan sus entradas más tarde) pueden replicar este mecanismo en la cadena. El segundo requisito es la garantía: las ofertas deben estar respaldadas por garantías para garantizar que el ganador tenga suficientes fondos para cumplir con su compromiso. 

En nuestra implementación de Vickrey sobrecolateralizada, los posibles compradores hacen ofertas llamando al commitBid función, proporcionando un compromiso de hash y la garantía que se depositará. Este enfoque satisface los requisitos, pero tiene algunos inconvenientes. Aunque la oferta en sí está oculta por el hash, el commitBid La transacción señala abierta e inmediatamente la intención del usuario: "Me gustaría ofertar en esta subasta, y aquí está la garantía de mi oferta". Sin sobrecolateralización, la visibilidad (y vinculabilidad) de ambos intención y colateral revelaría los valores de oferta. Pero si podemos ofuscar la intención de una transacción, podríamos lograr la privacidad de la oferta sin depender de la garantía excesiva. 

El CREATE2 código de operación, introducido en EIP-1014 e incluido en la bifurcación dura de Constantinopla, nos da una manera de hacer precisamente eso. los CREATE y CREATE2 ambos códigos de operación se usan para implementar contratos inteligentes, pero difieren en cómo se calculan las direcciones de implementación. los CREATE la dirección de implementación se calcula como un hash de la dirección del implementador y nonce; la CREATE2 la dirección de implementación, por otro lado, se calcula como un hash del código de bytes del contrato y los parámetros del constructor, una sal arbitraria y la dirección del implementador (detalles).

CREATE2 se usa a menudo en el patrón de fábrica para implementar contratos en direcciones predecibles, por ejemplo, el UniswapV3PoolDeployer usos del contrato CREATE2 para implementar cada contrato de grupo en una dirección que es una función del par de tokens y el nivel de tarifa. CREATE2 también se puede utilizar para (re)implementar contratos inteligentes actualizables, sobre todo en el metamórfico patrón de contrato.

Más importante para nosotros, el CREATE2 La dirección de implementación puede funcionar como un compromiso de hash para cualquier comportamiento definido por el código de bytes y los parámetros de entrada. Si los parámetros del constructor codifican una oferta, el CREATE2 dirección puede servir como un compromiso de oferta.

Además, el contrato en sí puede servir como una bóveda: un postor puede enviar ETH al CREATE2 dirección de la bóveda antes de que se implemente el contrato para garantizar y comprometerse con su oferta en una simple transferencia! Dado que el postor no tiene la clave privada para la dirección de la bóveda, la garantía está bloqueada hasta que se revela la oferta, momento en el que se implementa el contrato SneakyAuction y desbloquea la bóveda. 

Este enfoque hace que la transacción no se distinga de una transferencia a una dirección de propiedad externa (EOA). La transacción de oferta está oculta a simple vista, entre otras transferencias en la cadena de bloques. Sin embargo, una advertencia importante: esta solución aparentemente ordenada también hace que sea difícil determinar cuando la garantía estaba bloqueada. Es esencial para la seguridad de la subasta que la bóveda haya sido financiada antes de que se revelen las ofertas. De lo contrario, un comprador oportunista podría esperar hasta el final del período de revelación, momento en el que ya se han revelado la mayoría de las ofertas, para decidir si garantizar o no su bóveda. Necesitamos asegurarnos de que las bóvedas estén garantizadas durante el período de licitación, no durante el período de revelación, usando otra herramienta: pruebas de estado.

Verificación retroactiva de garantías utilizando pruebas estatales

Una forma de asegurarse de que una bóveda esté garantizada durante el período de licitación es verificar su saldo en un bloque anterior. Es relativamente fácil hacer esto fuera de la cadena consultando un nodo de archivo; pero mucho más difícil de lograr (sin confianza) en cadena. Los EVM BALANCE El código de operación lee el saldo actual de una dirección, pero no existe tal código de operación para recuperar un pasado balance. De hecho, el único código de operación EVM que proporciona algún tipo de acceso al estado histórico es BLOCKHASH, que devuelve el hash de uno de los últimos 256 bloques. Afortunadamente, con algo de ayuda fuera de la cadena, blockhash funciona lo suficientemente bien para nuestro caso de uso.

El blockhash es el hash del encabezado del bloque, que incluye (entre otros metadatos) el raíz del estado de ese bloque. La raíz del estado es el nodo raíz de un Merkle-Patricia trie, donde cada nodo hoja corresponde a una dirección particular e incluye la dirección' equilibrar en ese bloque. No podemos acceder directamente a estos nodos hoja en cadena, pero podemos verificar que el contenido de un nodo hoja sea correcto. De hecho, el eth_getProof Método RPC compatible con Alquimia (entre otros proveedores) devuelve las pruebas de Merkle necesarias para realizar esta verificación (Leo Zhang proporciona una explicación en profundidad de cómo funciona esto en el contexto de los clientes ligeros de Ethereum). Esto significa que con un poco de ayuda fuera de la cadena (una sola llamada de RPC), los postores pueden demostrar al contrato de SneakyAuction que su bóveda fue garantizada durante el período de licitación. 

En nuestra implementación, el primera oferta revelado para una subasta almacena el blockhash del bloque anterior. Esta transacción hace que la subasta pase de la fase de licitación a la fase de revelación, todo ofertas posteriores revelado debe proporcionar una prueba de Merkle de que su bóveda estaba suficientemente garantizada antes de ese bloque (es decir, antes de que se revelara la primera oferta). Tenga en cuenta que el la primera revealBid idealmente, la transacción se enviaría a través de un grupo privado de transacciones (por ejemplo, Flashbots); de lo contrario, un postor que observa el mempool (viendo el valor de la oferta revelada) podría adelantar la transacción y realizar una oferta de último segundo. 

LibBalancePrueba

Para minimizar los costos para los postores, escribimos un programa optimizado para gas bibliotecas para verificar las pruebas de equilibrio en la cadena que se basa en contratos escrito por el equipo de Aragón (que fue pionero en las pruebas de almacenamiento en cadena en 2018), y los contratos de Hamdi Allam para pruebas en cadena decodificación RLP. Nuestra biblioteca utiliza una serie de trucos y optimizaciones de bajo nivel que se basan en la estructura particular del trie de estado, por lo que no se puede usar para pruebas genéricas de trie de Merkle-Patricia. A cambio, permite que el contrato SneakyAuction verifique el saldo anterior de una bóveda en menos de 30,000 de gas.

También escribimos un ligero Contenedor de JavaScript para eth_getProof método RPC. Dada una dirección y un número de bloque, devuelve la prueba de saldo y el encabezado del bloque serializado por RLP, que se puede usar para revelar una oferta. 

como se compara 

Comparemos nuestro nuevo enfoque SneakyAuction con el diseño OverCollateralizedAuction que lanzamos por última vez, junto con varias dimensiones clave que preocupan a los diseñadores técnicos o usuarios: costos de gasolina, experiencia del usuario y privacidad. 

Costos de gas

SneakyAuctions revealBid, endAuctiony withdrawCollateral funciones requieren implementar un SneakyVault, por lo que son más caros que sus homólogos de OverCollateralizedAuction. revealBid es especialmente caro porque también verifica una prueba de equilibrio, que cuesta alrededor de 25,000 de gas.

Costos aproximados de gas de diferentes operaciones, con base en pruebas unitarias de fundición

La experiencia del usuario

Aunque las dos implementaciones siguen un flujo general similar (fase de licitación, fase de revelación, finalización de la subasta), existen algunas diferencias en la experiencia del usuario. SneakyAuction tiene algunas desventajas menores:

• La experiencia de enviar ETH a una bóveda no implementada, aunque podría ser abstraída por el front-end, es potencialmente confusa para los usuarios que examinan su transacción de oferta en un explorador de bloques.
• Con OverCollateralizedAuction, es posible finalizar la subasta antes de tiempo si se revelaron todas las ofertas. Esto no es posible en SneakyAuction porque el contrato no tiene forma de saber cuántas ofertas se han comprometido.
• Los postores pueden actualizar su oferta y recargar su garantía con OverCollateralizedAuction llamando commitBid otra vez. En SneakyAuction, los postores no pueden hacer actualizaciones una vez que la bóveda de la oferta ha sido garantizada.

Privacidad

La privacidad de la oferta de OverCollateralizedAuction se basa en que los postores eligen bloquear garantías adicionales (para que los espectadores conozcan el límite superior de una oferta pero no la cantidad exacta). SneakyAuction, por otro lado, obtiene privacidad de la actividad en cadena que no tiene nada que ver con la subasta en sí: transferencias de ETH que ocurren durante el período de licitación de la subasta. 

Para simplificar, supongamos que cada oferta está garantizada mediante una única transferencia ETH. Observamos que: 

1. La transacción de garantía debe ser la primera vez que alguien interactúa con la dirección de la bóveda en la cadena. 
2. No esperamos que ninguna otra transacción toque la dirección de la bóveda durante el resto del período de licitación. 
3. Ninguna transacción puede originarse desde la dirección de la bóveda (porque nadie tiene la clave privada). 

Las transferencias de ETH durante el período de licitación a direcciones que de otro modo "no se tocarían" son licitaciones plausibles; en otras palabras, son el "ruido" que oculta las transacciones de licitación. Para ayudar a cuantificar la privacidad de SneakyAuction, podemos observar la forma de esta distribución de ruido.

Este histograma muestra la distribución del año hasta la fecha de las transferencias diarias de ETH (en la red principal de Ethereum) a direcciones intactas, lo que ilustra la distribución de ruido para un período de oferta de 24 horas. Podemos ver que la mayoría de las transacciones caen en el rango [0.001, 1] ETH, lo que implica que las subastas con un valor de oferta esperado en ese rango tendrían la mayor privacidad. Por otro lado, es posible que el ruido típico no brinde suficiente privacidad para las subastas en las que la oferta esperada es superior a 10 ETH; rara vez hay más de 100 transferencias en ese rango, por lo que una subasta que atraiga muchas ofertas crearía un pico notable en la distribución. . 

Para tener otra perspectiva de estos datos, estos diagramas de dispersión representan las transferencias el 15 de octubre de 2022, superpuestas con ofertas de dos subastas hipotéticas: 

Intuitivamente, sería mucho más fácil para un observador identificar las ofertas de la segunda subasta. En la práctica, podría usar un algoritmo de agrupamiento como el maximización de expectativas (EM) algoritmo para predecir qué transacciones son ofertas. 

Sin embargo, hay algunos otros factores que pueden hacer que SneakyAuction sea más privado (y, por lo tanto, más atractivo) en la práctica:

1. Períodos de oferta más largos: la privacidad escala con la duración del período de oferta: cuanto más largo sea el período de oferta, más transferencias hay para ocultar ofertas. 
2. Subastas simultáneas: la privacidad aumenta con el número de subastas simultáneas: si dos subastas están en sus fases de oferta al mismo tiempo, las ofertas de una subasta sirven como ruido para la otra.

SneakyAuction también puede beneficiarse de la sobregarantía: dado que SneakyVault devuelve cualquier exceso de ETH al postor, los postores pueden optar por la sobregarantía para una mayor privacidad. Entonces, en cierto sentido, SneakyAuction proporciona una privacidad estrictamente más fuerte que nuestra implementación anterior.

Un simple corolario del mecanismo de privacidad de SneakyAuction es que oculta la número de ofertas durante el período de licitación. Esta es una ventaja sobre OverCollateralizedAuction, que solo oculta los valores de la oferta: la cantidad de compromisos de oferta que se han realizado para una subasta determinada es completamente pública (y puede revelar cuán competitiva es la subasta).

***

Si bien nuestra primera implementación de una subasta de oferta cerrada tradujo características del mundo real en decisiones de diseño en cadena, nuestro segundo diseño se basa en un mecanismo novedoso y práctico para aprovechar la naturaleza pública de las cadenas de bloques: las ofertas selladas se "ocultan" entre los usuarios no relacionados. actividad de la cadena de bloques.

Si bien este nuevo enfoque es una forma conveniente de lograr la privacidad de las ofertas sin sobrecolateralización, no es necesariamente adecuado para todas las subastas (por ejemplo, subastas con muchas ofertas de alto valor). La privacidad mejora para las subastas que esperan ofertas más pequeñas (y especialmente durante un período de tiempo más largo).

***
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 actual o 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