Caché à la vue de tous : une mise en œuvre sournoise de la solidité d'une vente aux enchères scellée

Note de l'éditeur : cet article fait partie de notre série en cours sur toutes les ventes aux enchères pour le Web3. Partie 1 était un aperçu des conceptions d'enchères et des défis techniques (et opportunités) spécifiques à la conception de mécanismes dans un contexte de blockchains sans autorisation. Partie 2 était un article sur la compensation du marché et la prévention des guerres du gaz. Partie 3 partage un aperçu des types d'enchères canoniques, un aperçu de la façon dont la théorie se traduit en pratique et notre première mise en œuvre d'une nouvelle enchère Vickrey à offre scellée. 

Les enchères en chaîne sont l'un des espaces de conception les plus intéressants (et omniprésents) du Web3 - des ventes NFT aux enchères de garantie - donnant lieu à un nouveau paysage d'implémentations et de recherche. Alors que la conception des mécanismes d'enchères existe depuis des siècles et a évolué au cours des dernières décennies avec l'avènement du Web et du commerce électronique, nous appliquons seulement maintenant ces approches aux contrats intelligents.

Nous commençons également à voir plus de conceptions d'enchères natives des blockchains, y compris nos open source Mise en œuvre solide d'une vente aux enchères Vickrey et plusieurs développements intéressants de la communauté (y compris suggestions pour améliorer l'efficacité, de nouveaux résultats théoriques, et deux gagnant du hackathon implémentations d'enchères scellées). Dans notre première conception, nous avons fait un compromis entre la confidentialité et l'efficacité du capital : nous avons utilisé le surnantissement (les enchérisseurs bloquaient plus de garanties que ce qui était requis par leur offre) afin d'imposer le paiement de l'enchérisseur gagnant, sans révéler les valeurs précises de l'enchère via la garantie. montant. En bloquant plus de capital, vous obtenez plus de confidentialité à un coût d'opportunité potentiellement plus élevé. Mais que se passerait-il si nous pouvions enchérir sur la confidentialité sans surdimensionnement ? 

Cet article présente une nouvelle conception d'enchères que nous appelons "SneakyAuction", qui combine le CREATE2 opcode et des preuves d'état pour garantir la confidentialité des offres sans obliger les soumissionnaires à verrouiller plus de garanties que nécessaire. Nous commençons par décomposer son fonctionnement, puis le comparons à notre implémentation précédente (OverCollateralizedAuction) en termes de coût du gaz, d'expérience utilisateur et de confidentialité. Nous avons également ajouté l'implémentation à notre Zoo d'enchères référentiel sur GitHub afin que vous puissiez le bifurquer, le développer et suivre à mesure que nous plongeons dans plus de mécanismes ; en attendant, plus d'informations sur son fonctionnement et sa comparaison avec notre conception précédente ci-dessous. 

Comment ça marche: S'engager sur des enchères à l'aide de CREATE2

Il y a deux exigences dont nous avons besoin pour créer une enchère scellée «éventuellement publique» en chaîne. Premièrement, les enchères doivent être privées pendant toute la durée de la période d'enchères, puis révélées à la fin ; les schémas de validation-révélation (où les utilisateurs publient des valeurs validées par hachage, puis révèlent leurs entrées plus tard) peuvent répliquer ce mécanisme sur la chaîne. La deuxième exigence est la garantie : les offres doivent être accompagnées de garanties pour garantir que le gagnant dispose de suffisamment de fonds pour remplir son engagement. 

Dans notre implémentation Vickrey surgarantie, les acheteurs potentiels placent des offres en appelant le commitBid fonction, fournissant un engagement de hachage et la garantie à déposer. Cette approche satisfait aux exigences, mais présente certains inconvénients. Même si l'enchère elle-même est masquée par le hachage, le commitBid transaction ouvertement et signale immédiatement l'intention de l'utilisateur : "Je voudrais enchérir sur cette enchère, et voici la garantie de mon enchère." Sans surdimensionnement, la visibilité (et la possibilité de liaison) des deux intention ainsi que le garantie révélerait les valeurs des enchères. Mais si nous pouvons obscurcir l'intention d'une transaction, nous pourrons peut-être assurer la confidentialité des offres sans compter sur le surdimensionnement. 

Les CREATE2 opcode, introduit dans EIP-1014 et inclus dans le hard fork de Constantinople, nous donne un moyen de le faire. La CREATE ainsi que le CREATE2 Les opcodes sont tous deux utilisés pour déployer des contrats intelligents, mais ils diffèrent dans la façon dont les adresses de déploiement sont calculées. La CREATE l'adresse de déploiement est calculée comme un hachage de l'adresse et du nonce du déployeur ; la CREATE2 l'adresse de déploiement, d'autre part, est calculée comme un hachage du bytecode du contrat et des paramètres du constructeur, un sel arbitraire et l'adresse du déployeur (détails).

CREATE2 est souvent utilisé dans le modèle d'usine pour déployer des contrats à des adresses prévisibles - par exemple, le UniswapV3PoolDeployer contrat utilise CREATE2 pour déployer chaque contrat de pool à une adresse qui est fonction de la paire de jetons et du niveau de frais. CREATE2 peut également être utilisé pour (re)déployer des contrats intelligents évolutifs, notamment dans le métamorphique modèle de contrat.

Plus important pour nous, le CREATE2 L'adresse de déploiement peut fonctionner comme un engagement de hachage pour tout comportement défini par le bytecode et les paramètres d'entrée. Si les paramètres du constructeur encodent une enchère, le CREATE2 l'adresse peut servir d'engagement d'offre.

De plus, le contrat lui-même peut servir de coffre-fort – un soumissionnaire peut envoyer des ETH au CREATE2 adresse du coffre-fort avant le déploiement du contrat pour garantir et s'engager dans leur offre en un seul transfert ! Étant donné que l'enchérisseur ne dispose pas de la clé privée de l'adresse du coffre-fort, la garantie est verrouillée jusqu'à ce que l'offre soit révélée, moment auquel le contrat SneakyAuction se déploie et déverrouille le coffre-fort. 

Cette approche rend la transaction indiscernable d'un transfert vers une adresse externe (EOA). La transaction d'offre est cachée à la vue, parmi d'autres transferts sur la blockchain. Une mise en garde importante, cependant : cette solution apparemment ordonnée rend également difficile la détermination quand la garantie était verrouillée. Il est essentiel pour la sécurité des enchères que le coffre-fort ait été financé avant que les offres ne soient révélées. Sinon, un acheteur opportuniste pourrait attendre la toute fin de la période de révélation, moment auquel la plupart des offres ont déjà été révélées, pour décider de garantir ou non son coffre-fort. Nous devons nous assurer que les coffres-forts sont garantis pendant la période d'appel d'offres, pas pendant la période de révélation, en utilisant un autre outil : les preuves d'état.

Vérification rétroactive des garanties à l'aide de preuves d'état

Une façon de s'assurer qu'un coffre-fort a été garanti pendant la période d'enchères consiste à vérifier son solde lors d'un bloc passé. Il est relativement facile de le faire hors chaîne en interrogeant un nœud d'archive ; mais beaucoup plus difficile à accomplir (sans confiance) en chaîne. Les EVM BALANCE opcode lit le solde actuel d'une adresse, mais aucun opcode n'existe pour récupérer un passé solde. En fait, le seul opcode EVM qui fournit une sorte d'accès à l'état historique est BLOCKHASH, qui renvoie le hachage de l'un des 256 derniers blocs. Heureusement - avec une aide hors chaîne - le blockhash fonctionne juste assez bien pour notre cas d'utilisation.

Le blockhash est le hachage de l'en-tête du bloc, qui inclut (entre autres métadonnées) le racine d'état de ce bloc. La racine d'état est le nœud racine d'un Essai Merkle-Patricia, où chaque nœud feuille correspond à une adresse particulière et inclut l'adresse' équilibre à ce bloc. Nous ne pouvons pas accéder directement à ces nœuds feuilles sur la chaîne, mais nous pouvons vérifier que le contenu d'un nœud feuille est correct. En fait, le eth_getProof Méthode RPC prise en charge par Alchimie (entre autres fournisseurs) renvoie les preuves Merkle nécessaires pour effectuer cette vérification (Leo Zhang fournit un explication approfondie de la façon dont cela fonctionne dans le contexte des clients légers Ethereum). Cela signifie qu'avec un peu d'aide hors chaîne (un seul appel RPC), les enchérisseurs peuvent prouver au contrat SneakyAuction que leur coffre-fort a été garanti pendant la période d'enchères. 

Dans notre implémentation, le première enchère révélé pour une vente aux enchères stocke le blockhash du bloc précédent. Cette transaction fait passer efficacement l'enchère de la phase d'enchère à la phase de révélation - tout offres ultérieures révélé doit fournir une preuve Merkle que son coffre-fort était suffisamment garanti avant ce bloc (c'est-à-dire avant que la première enchère ne soit révélée). Notez que le premier revealBid la transaction serait idéalement soumise via un pool de transactions privé (par exemple Flashbots); sinon, un enchérisseur regardant le mempool (voyant la valeur de l'enchère révélée) pourrait lancer la transaction et placer une enchère de dernière seconde. 

LibBalanceProof

Afin de minimiser les coûts pour les soumissionnaires, nous avons rédigé un bibliothèque pour vérifier les preuves d'équilibre sur la chaîne qui s'appuie sur contrats écrit par l'équipe d'Aragon (qui a été le pionnier des preuves de stockage en chaîne en 2018), et les contrats de Hamdi Allam pour les preuves en chaîne Décodage RLP. Notre bibliothèque utilise un certain nombre d'astuces et d'optimisations de bas niveau qui reposent sur la structure particulière du trie d'état, de sorte qu'elle ne peut pas être utilisée pour les preuves de trie Merkle-Patricia génériques. En contrepartie, il permet au contrat SneakyAuction de vérifier le solde passé d'un coffre-fort en moins de 30,000 XNUMX gaz.

Nous avons également écrit un léger Enveloppe JavaScript pour le eth_getProof Méthode RPC. Étant donné une adresse et un numéro de bloc, il renvoie la preuve de solde et l'en-tête de bloc sérialisé RLP, qui peuvent être utilisés pour révéler une offre. 

Comment ça se compare 

Comparons notre nouvelle approche SneakyAuction à la conception OverCollateralizedAuction que nous avons publiée pour la dernière fois, selon plusieurs dimensions clés dont les concepteurs techniques ou les utilisateurs se soucient : les coûts de gaz, l'expérience utilisateur et la confidentialité. 

Coûts du gaz

SneakyAuction's revealBid, endAuctionet la withdrawCollateral fonctions nécessitent le déploiement d'un SneakyVault, ils sont donc plus chers que leurs homologues OverCollateralizedAuction. revealBid est particulièrement onéreux car il vérifie également une épreuve d'équilibre, qui coûte environ 25,000 XNUMX gaz.

Coûts approximatifs du gaz de différentes opérations, basés sur des tests unitaires de fonderie

Expérience de l'utilisateur

Bien que les deux implémentations suivent un flux global similaire (phase d'enchères, phase de révélation, fins d'enchères), il existe quelques différences dans l'expérience utilisateur. SneakyAuction a quelques inconvénients mineurs :

• L'expérience d'envoi d'ETH vers un coffre-fort non déployé, bien qu'elle puisse être abstraite par le frontal, est potentiellement déroutante pour les utilisateurs qui examinent leur transaction d'offre sur un explorateur de blocs.
• Avec OverCollateralizedAuction, il est possible de mettre fin à l'enchère plus tôt si toutes les offres ont été révélées. Ce n'est pas possible dans SneakyAuction car le contrat n'a aucun moyen de savoir combien d'offres ont été engagées.
• Les enchérisseurs peuvent mettre à jour leur enchère et compléter leur garantie avec OverCollateralizedAuction en appelant commitBid encore. Dans SneakyAuction, les enchérisseurs ne peuvent pas effectuer de mises à jour une fois que le coffre-fort de l'offre a été garanti.

Confidentialité

La confidentialité des enchères d'OverCollateralizedAuction repose sur le fait que les enchérisseurs choisissent de verrouiller des garanties supplémentaires (ainsi, les spectateurs connaissent la limite supérieure d'une enchère, mais pas le montant exact). SneakyAuction, d'autre part, dérive la confidentialité de l'activité en chaîne qui n'a aucun rapport avec l'enchère elle-même: Transferts ETH qui se produisent pendant la période d'enchère de l'enchère. 

Pour plus de simplicité, supposons que chaque offre est garantie à l'aide d'un seul transfert ETH. Nous observons que : 

1. La transaction de collatéralisation devrait être la première fois que quelqu'un interagit avec l'adresse du coffre-fort en chaîne. 
2. Nous ne nous attendons pas à ce qu'aucune autre transaction ne touche l'adresse du coffre-fort pendant le reste de la période d'enchères. 
3. Aucune transaction ne peut provenir de l'adresse du coffre (car personne ne possède la clé privée). 

Les transferts d'ETH pendant la période d'enchères vers des adresses autrement «intouchées» sont vraisemblablement des offres - en d'autres termes, ils sont le «bruit» qui cache les transactions d'enchères. Pour aider à quantifier la confidentialité de SneakyAuction, nous pouvons examiner la forme de cette distribution de bruit.

Cet histogramme montre la distribution depuis le début de l'année des transferts ETH quotidiens (sur le réseau principal Ethereum) vers des adresses intactes, illustrant la distribution du bruit pour une période d'enchères de 24 heures. Nous pouvons voir que la plupart des transactions se situent dans la plage [0.001, 1] ETH, ce qui implique que les enchères avec une valeur d'enchère attendue dans cette plage auraient la plus grande confidentialité. D'autre part, le bruit typique peut ne pas fournir une confidentialité suffisante pour les enchères où l'offre attendue est supérieure à 10 ETH - il y a rarement plus de 100 transferts dans cette plage, donc une enchère attirant de nombreuses offres créerait un pic visible dans la distribution. . 

Pour une autre perspective sur ces données, ces diagrammes de dispersion représentent les transferts du 15 octobre 2022, superposés aux offres de deux enchères hypothétiques : 

Intuitivement, il serait beaucoup plus facile pour un observateur d'identifier les offres de la deuxième enchère. En pratique, vous pouvez utiliser un algorithme de clustering tel que le maximisation des attentes (EM) pour prédire quelles transactions sont des enchères. 

Cependant, il existe quelques autres facteurs qui peuvent rendre SneakyAuction plus privé (et donc plus convaincant) dans la pratique :

1. Périodes d'enchères plus longues : la confidentialité s'adapte à la durée de la période d'enchères -– plus la période d'enchères est longue, plus il y a de transferts pour masquer les enchères. 
2. Enchères simultanées : la confidentialité dépend du nombre d'enchères simultanées –– si deux enchères sont dans leurs phases d'enchères en même temps, les offres d'une enchère servent de bruit pour l'autre.

SneakyAuction peut également bénéficier d'un surdimensionnement - puisque SneakyVault renvoie tout ETH excédentaire à l'enchérisseur, les enchérisseurs peuvent choisir de surdimensionner pour plus de confidentialité. Donc, dans un sens, SneakyAuction offre une confidentialité strictement plus forte que notre implémentation précédente.

Un corollaire simple du mécanisme de confidentialité de SneakyAuction est qu'il cache le nombre des offres pendant la période d'appel d'offres. C'est un avantage par rapport à OverCollateralizedAuction, qui ne fait que masquer les valeurs d'enchère - le nombre d'engagements d'enchère qui ont été pris pour une enchère donnée est entièrement public (et peut révéler à quel point l'enchère est compétitive).

***

Alors que notre première mise en œuvre d'une enchère à offre scellée a traduit des fonctionnalités du monde réel en décisions de conception en chaîne, notre deuxième conception repose sur un mécanisme novateur et pratique pour utiliser la nature publique des chaînes de blocs à son avantage : les offres scellées se "cachent" parmi des activité de la chaîne de blocs.

Bien que cette nouvelle approche soit un moyen pratique d'assurer la confidentialité des offres sans surdimensionnement, elle n'est pas nécessairement adaptée à toutes les enchères (par exemple les enchères avec de nombreuses offres de grande valeur). La confidentialité s'améliore pour les enchères qui s'attendent à des offres plus petites (et surtout sur une plus longue période).

***
Les opinions exprimées ici sont celles du personnel individuel d'AH Capital Management, LLC (« a16z ») cité et ne sont pas les opinions d'a16z ou de ses sociétés affiliées. Certaines informations contenues ici ont été obtenues de sources tierces, y compris de sociétés de portefeuille de fonds gérés par a16z. Bien qu'elles proviennent de sources considérées comme fiables, a16z n'a pas vérifié ces informations de manière indépendante et ne fait aucune déclaration quant à l'exactitude actuelle ou durable des informations ou à leur pertinence dans une situation donnée. De plus, ce contenu peut inclure des publicités de tiers ; a16z n'a pas examiné ces publicités et n'approuve aucun contenu publicitaire qu'elles contiennent.

Ce contenu est fourni à titre informatif uniquement et ne doit pas être considéré comme un conseil juridique, commercial, d'investissement ou fiscal. Vous devriez consulter vos propres conseillers sur ces questions. Les références à des titres ou à des actifs numériques sont uniquement à des fins d'illustration et ne constituent pas une recommandation d'investissement ou une offre de fournir des services de conseil en investissement. En outre, ce contenu n'est ni destiné ni destiné à être utilisé par des investisseurs ou des investisseurs potentiels, et ne peut en aucun cas être invoqué pour prendre une décision d'investir dans un fonds géré par a16z. (Une offre d'investissement dans un fonds a16z ne sera faite que par le mémorandum de placement privé, le contrat de souscription et toute autre documentation pertinente de ce fonds et doit être lu dans son intégralité.) Tous les investissements ou sociétés de portefeuille mentionnés, référencés ou décrits ne sont pas représentatifs de tous les investissements dans des véhicules gérés par a16z, et rien ne garantit que les investissements seront rentables ou que d'autres investissements réalisés à l'avenir auront des caractéristiques ou des résultats similaires. Une liste des investissements effectués par des fonds gérés par Andreessen Horowitz (à l'exclusion des investissements pour lesquels l'émetteur n'a pas autorisé a16z à divulguer publiquement ainsi que des investissements non annoncés dans des actifs numériques cotés en bourse) est disponible sur https://a16z.com/investments /.

Les tableaux et graphiques fournis ici sont uniquement à des fins d'information et ne doivent pas être utilisés pour prendre une décision d'investissement. Les performances passées ne représentent pas les résultats futurs. Le contenu ne parle qu'à la date indiquée. Toutes les projections, estimations, prévisions, objectifs, perspectives et/ou opinions exprimées dans ces documents sont susceptibles d'être modifiées sans préavis et peuvent différer ou être contraires aux opinions exprimées par d'autres. Veuillez consulter https://a16z.com/disclosures pour des informations importantes supplémentaires