Transaction
Un type de transaction introduit dans l'EIP-4844 d'Ethereum, conçu pour réduire les frais de transaction en stockant les blobs de données séparément des données de transaction principales.
Les transactions blob, introduites via la proposition d'amélioration d'Ethereum (EIP) 4844 (également connue sous le nom de Proto-Danksharding), représentent un changement architectural significatif visant à réduire les frais de transaction, en particulier pour les solutions de mise à l'échelle de couche 2. Contrairement aux transactions Ethereum traditionnelles qui intègrent les données directement dans les calldata de la transaction principale, les transactions blob utilisent une structure de données distincte, bien que toujours sur la chaîne, appelée 'blobs'. Ces blobs sont conçus pour être moins chers à publier et sont soumis à des limites de gaz et à des mécanismes de tarification différents de ceux des données de transaction régulières. La motivation principale est de réduire le coût de la disponibilité des données pour les rollups. Les rollups regroupent les transactions hors chaîne et publient un résumé compressé ou une preuve sur la chaîne principale d'Ethereum (couche 1). Le coût de publication de ces données sur la couche 1 est un goulot d'étranglement majeur. L'EIP-4844 introduit un nouveau type de transaction qui permet aux rollups de publier de plus grandes quantités de données plus économiquement en les séparant dans ces blobs. Ces blobs ne sont pas directement traités par la machine virtuelle Ethereum (EVM) mais sont plutôt engagés via un schéma d'engagement polynomial KZG (Kalai-Shen-Goldwasser). Cet engagement est inclus dans l'en-tête du bloc, garantissant la disponibilité des données sans obliger chaque nœud à télécharger et à stocker indéfiniment les données complètes du blob. Cette séparation et ce traitement spécialisé réduisent considérablement le coût du gaz associé à la disponibilité des données, rendant les rollups plus viables économiquement et améliorant ainsi la scalabilité globale d'Ethereum.
graph LR
Center["Transaction"]:::main
Pre_digital_signature["digital-signature"]:::pre --> Center
click Pre_digital_signature "/terms/digital-signature"
Pre_private_key["private-key"]:::pre --> Center
click Pre_private_key "/terms/private-key"
Rel_block["block"]:::related -.-> Center
click Rel_block "/terms/block"
Rel_smart_contract["smart-contract"]:::related -.-> Center
click Rel_smart_contract "/terms/smart-contract"
Rel_data_availability["data-availability"]:::related -.-> Center
click Rel_data_availability "/terms/data-availability"
classDef main fill:#7c3aed,stroke:#8b5cf6,stroke-width:2px,color:white,font-weight:bold,rx:5,ry:5;
classDef pre fill:#0f172a,stroke:#3b82f6,color:#94a3b8,rx:5,ry:5;
classDef child fill:#0f172a,stroke:#10b981,color:#94a3b8,rx:5,ry:5;
classDef related fill:#0f172a,stroke:#8b5cf6,stroke-dasharray: 5 5,color:#94a3b8,rx:5,ry:5;
linkStyle default stroke:#4b5563,stroke-width:2px;
🧒 Explique-moi comme si j'avais 5 ans
Imaginez que vous envoyez un gros colis (votre transaction) où vous payiez cher pour inclure tout le papier d'emballage à l'intérieur. Les transactions blob vous permettent d'envoyer le papier d'emballage séparément et beaucoup moins cher, ce qui réduit considérablement le coût total de votre livraison.
🤓 Expert Deep Dive
L'EIP-4844 modifie fondamentalement la stratégie de disponibilité des données d'Ethereum en introduisant des 'blobs' et des engagements KZG. Les blobs sont des morceaux de données contigus attachés à un bloc, avec une taille maximale et une limite de gaz distincte de celle des calldata. Crucialement, les blobs ne sont pas directement accessibles par la logique des contrats EVM ; leur objectif principal est la vérification de la disponibilité des données. L'engagement des données de blob est réalisé à l'aide d'engagements polynomiaux KZG, où les données du blob représentent les coefficients d'un polynôme, et l'engagement est un point sur une courbe elliptique. Cela permet une génération et une vérification efficaces des preuves. Les nœuds sont tenus de télécharger les données des blobs pendant une période limitée (par exemple, environ 4096 blocs ou environ 27 heures) à des fins de vérification, après quoi ils peuvent les supprimer, réduisant ainsi l'encombrement de l'état. Le coût du gaz pour la publication des blobs est considérablement inférieur à celui des calldata, calculé en fonction de la taille du blob et d'un 'prix du gaz blob' distinct. Ce mécanisme est un précurseur du Danksharding complet, où l'espace des blobs sera étendu et distribué sur plusieurs shards. Les compromis incluent la complexité du schéma d'engagement KZG et l'exigence de stockage temporaire pour les nœuds, mais le principal avantage est une réduction substantielle des coûts de publication des données pour les rollups.