Le contributeur Ethereum Marchhill a soumis une proposition préliminaire visant à permettre la vérification générique de preuves et le traitement par lots sponsorisé, permettant à plusieurs réclamations de transactions de partager une preuve tout en conservant des paiements et des signatures distincts.
Résumé
- Les sponsors pourraient payer les preuves par lots tandis que les transactions des membres paieraient leurs réclamations individuelles.
- Des sous-ensembles valides pourraient entrer dans un bloc sans exiger que les membres signent à nouveau leurs transactions.
- Les frais et limites de ressources proposés restent provisoires, l'activation dépendant de mesures de performance.
- La soumission est une demande de tirage préliminaire, sans numéro EIP attribué ni date d'activation sur le réseau principal.
La proposition de Marchhill, soumise au dépôt EIP d'Ethereum le 13 novembre, activerait le LEANSTARK_SCHEME réservé dans l'EIP-8288 et introduirait des règles pour les lots sponsorisés. La soumission est toujours en cours de développement et n'a pas été adoptée comme mise à niveau du réseau Ethereum.
Le projet rassemble la vérification générique, l'identité des preuves, les limites de ressources, les résumés de dépendances et les paiements par lots dans une seule proposition. Il remplace une soumission antérieure, la demande de tirage #12654, tandis qu'un numéro EIP et un fil de discussion dédié restent à attribuer.
Les preuves par lots d'Ethereum sépareraient les paiements des sponsors et des membres
Au cœur du projet se trouve un arrangement de paiement dans lequel un sponsor couvre chaque feuille de lot retenue, un composant de preuve individuel contenant plusieurs réclamations. Les transactions des membres paieraient selon leurs propres réclamations soumises.
Un constructeur pourrait inclure n'importe quel sous-ensemble valide sans demander aux membres de signer à nouveau. Quelqu'un dont la transaction était prête à être incluse n'aurait donc pas besoin d'une nouvelle signature uniquement parce que d'autres membres du groupe d'origine auraient été exclus, selon le mécanisme proposé.
Le projet préserverait les nonces et les reçus individuels des transactions. Un nonce identifie la place d'une transaction dans la séquence de transactions d'un compte, tandis qu'un reçu enregistre son résultat d'exécution. Le partage du travail de preuve laisserait ces enregistrements attachés aux transactions séparées.
La correspondance des paiements serait vérifiée lors de la finalisation, avec des preuves récursives authentifiant les sources utilisées dans le lot. La soumission distingue le travail consistant à établir que les réclamations sont valides du travail consistant à confirmer que les paiements nécessaires les accompagnent.
Les réclamations à tarif réduit et les paiements des sponsors iraient directement aux constructeurs de blocs. Les preuves ordinaires couvrant une seule déclaration resteraient éligibles au mempool public, où les transactions attendent d'être incluses dans les blocs.
La vérification générique s'appuie sur l'EIP-8288
L'EIP-8288 sous-jacent, rédigé par Vitalik Buterin et Thomas Coratger, propose d'agréger les signatures cryptographiques et les preuves en dehors du processus d'exécution principal d'Ethereum. Les transactions identifieraient les déclarations qu'elles doivent faire vérifier, et un STARK récursif établirait leur validité au niveau du bloc.
Les STARK sont des preuves cryptographiques qui démontrent qu'un calcul a été effectué correctement sans exiger que chaque vérificateur le répète. La récursion permet à une preuve de vérifier d'autres preuves, en combinant leurs résultats.
L'EIP-8288 réserve actuellement le schéma générique leanSTARK plutôt que de permettre son utilisation dans les cadres de dépendances. La soumission de Marchhill propose d'activer cette voie et de remplacer la déclaration de hachage de données brute du projet de base par un condensé stable représentant une liste de réclamations.
La conception suit une discussion antérieure sur la vérification cryptographique, y compris le soutien de Buterin pour le traitement de la cryptographie complexe par des preuves agrégées. Ses commentaires concernaient l'architecture sous-jacente ; le projet de Marchhill expose un arrangement spécifique de vérification et de paiement.
Les frais proposés restent soumis à calibrage
La révision fournie énumère des frais provisoires de 15 400 gaz pour la vérification native et de 572 000 gaz pour la vérification générique ordinaire. Elle attribue 5 100 gaz à la part intrinsèque de preuve, 675 000 gaz à un paiement de feuille et 4 200 gaz à une réclamation de lot.
Les paiements de feuilles portent des frais distincts parce que les paiements contraignants ajoutent un travail fixe au-delà de la vérification ordinaire, explique le projet. Les réclamations et les paiements n'entraîneraient aucune part intrinsèque de preuve supplémentaire. Les chiffres nécessitent un calibrage conjoint, de sorte qu'ils n'établissent pas de barème de frais définitif ni d'économie confirmée pour les utilisateurs.
Les contrôles de ressources incluent une limite provisoire de bloc de 16 384 dépendances distinctes, appliquée indépendamment du gaz, ainsi qu’une règle correspondante d’adéquation à la liste d’inclusion. Une feuille pourrait contenir jusqu’à 256 revendications, tandis qu’une étape de preuve pourrait avoir 16 entrées. Aucun de ces chiffres n’est une limite à l’échelle du bloc.
L’activation nécessiterait des mesures de performance sur bloc complet
Avant l’activation, la proposition exige des mesures couvrant l’intégralité du calendrier de traitement, la réparation tardive du sponsor et les frais par preuve qui respectent les limites de gaz des transactions, y compris les surcoûts requis.
Son matériel de référence distingue les résultats mesurés pour un nœud individuel et pour une machine unique des chiffres modélisés à 16 travailleurs. Le projet exige que les preuves et les écarts de performance restants soient consignés dans son matériel de référence.
Un parrainage invalidé pourrait gaspiller le travail d’un constructeur, et la soumission indique que le gaz d’inclusion ne rembourserait pas ce travail. La construction concrète des engagements et les encodages restent dans la spécification du système de preuve épinglée. La proposition n’introduit aucun nouveau message réseau.
