Il y a deux semaines, des chercheurs Ethereum se sont réunis à Berlin pour continuer à tracer la trajectoire à long terme du protocole, en suivant les discussions avec les équipes de clients à Svalbard en avril.
La carte de paille mise à jour se trouve à strawmap.org, et j'ai joint une image de celle-ci à ce post.
Mes propres conclusions de haut niveau :
"Ethereum Lean" n'est pas une mise à niveau unique et ponctuelle, c'est un ensemble d'améliorations qui entreront en ligne sur le réseau Ethereum au cours de trois ou quatre ans. Mais ne vous y trompez pas, IL S'AGIT de la troisième grande itération d'Ethereum de la même manière que la Merge était la seconde. Presque chaque grande pièce du protocole sera remplacée :
- Vérification par des STARKs récursifs, plutôt que par une ré-exécution directe. Les STARKs récursifs deviennent un composant central de premier plan inscrit dans le protocole
- Remplacement de tout ce qui est vulnérable aux ordinateurs quantiques par des alternatives résistantes aux quantiques
- Consensus : chaîne disponible et finalité découplées, finalité en un ou deux tours. Propriétés de sécurité théoriquement optimales, plus simples qu'aujourd'hui, et plus rapides qu'aujourd'hui
- Gaz multidimensionnel
- État : pas seulement la structure en arbre, mais quels *types* d'état sont disponibles
- Changements dans l'architecture des clients
...
En même temps, simplification, nettoyage et protection pour l'avenir. Et tout cela sera fait de manière à minimiser les perturbations pour les applications existantes. Nous l'avons déjà fait (la Merge), nous pouvons le refaire.
H-star (aka Hegota) est probablement la dernière fourche d'Ethereum thématiquement "pré-Lean". À partir de I-star, la plupart de tout ce que nous ferons aura une très forte saveur "Lean" d'une manière ou d'une autre.
La confidentialité n'est plus une considération secondaire, c'est un objectif de premier plan. Lors de la conception des Frames, du mempool, des ajouts à l'arbre d'état, nous posons explicitement la question "d'accord, comment des transactions de protocole de confidentialité sans intermédiaires et résistantes aux quantiques passent-elles par là, et quel est le surcoût ?"
Vérification formelle de tout pour la sécurité.
FV nous rend aussi beaucoup plus à l'aise avec la canonicalisation (avoir des pièces du protocole directement définies comme un morceau de bytecode exprimé dans un certain langage). evm-asm est écrit en partie pour devenir un système de preuve canonique pour l'EVM.
La résistance quantique a grimpé ENORMÉMENT dans les priorités. Cela ajoute beaucoup de travail (par ex., finaliser un design de blobs résistant aux quantiques est devenu urgent ; ce travail est déjà en cours depuis des mois)
Probablement la partie la plus disruptive du plan est les changements à l'état. Il y a un consensus croissant autour du fait de laisser l'"état dynamique" de style actuel largement inchangé, mais de le scaler seulement de manière modérée, et d'ajouter de nouveaux types d'état plus favorables à la scalabilité (par ex., pas besoin pour les builders de synchroniser/stocker tout), mais plus restrictifs, et qui scaleront beaucoup.
par ex. Ethereum possible en 2030 : 2 To d'état de style actuel (dynamique), et 100 To d'état de style nouveau (scalable mais restrictif)
Cet état "nouveau style" fonctionnerait très bien pour les ERC20, les NFTs, de nombreux cas d'usage DeFi, mais pas par ex. pour des objets très "centraux" comme les contrats Uniswap, ou les carnets d'ordres on-chain, ou d'autres choses complexes (qui sont cruciaux pour Ethereum mais qui n'occupent qu'un petit pourcentage de l'état)
Par conséquent, il ne sera pas nécessaire de réécrire des apps, mais ce sera *très rentable* de par ex. réécrire un token ERC20 dans un design plus récent qui utilise un nouveau type de stockage UTXO qui est actuellement exploré, afin qu'il ait des frais de tx >10x inférieurs.
La conception de ces nouveaux types d'état (idées actuelles : nonces indexés, tampons circulaires, UTXOs, état statiquement accessible, état temporaire) est un domaine où nous aurons besoin de beaucoup de retours des développeurs d'applications (y compris les développeurs d'applications favorables à la confidentialité) et probablement de plusieurs tours de repensée et d'itération.
Dans le contexte d'une taille totale d'état beaucoup plus grande, nous devons résoudre les problèmes d'incitation autour de qui stocke cet état et ce qui les motive à le faire. Même dire "chaque nœud stocke 1%" n'est pas suffisant - pourquoi stockent-ils ce 1% et pourquoi sont-ils prêts à le servir ? Cela est élevé au rang de domaine de recherche de premier plan.
Ethereum aura besoin d'avoir un "VM" autre que l'EVM d'une forme ou d'une autre - au minimum, nous avons besoin de quelque chose comme leanISA pour les STARKs récursifs - et les gains sont importants en l'exposant aux utilisateurs pour que nous supportions une confidentialité programmable et une meilleure scalabilité. Actuellement, les candidats les plus probables sont leanISA et RISC-V.
Mon idéal personnel est que dans ce monde, nous ajustions le protocole de sorte que l'EVM devienne une fonctionnalité de niveau compilateur de langage de haut niveau, et que le protocole ne "voie" directement que RISC-V / leanISA. Mais cela est encore loin.
Les augmentations de limite de gaz, les augmentations de blobs et les diminutions de temps de slot se produiront de nombreuses fois au cours des ~5 prochaines années. Nous nous attendons à une grande augmentation de limite de gaz avec Glasterdam. Chaque étape d'échelle accrue ou de temps de slot diminué est une question d'atteindre le point où c'est sûr de le faire, ce qui vient d'une combinaison d'optimisations client et de changements de protocole.
Ethereum est CROPS.
Ethereum scale.
Ethereum se réinvente.
En avant.
#Ethereum #ETH #EthereumLean #Strawmap #Blockchain #Crypto #Cryptomonnaie #Web3 #DeFi #Layer1 #Scalability #Scaling #CryptoNews #BlockchainTechnology #SmartContracts #EVM #RiscV #LeanISA #STARKs #ZK #ZeroKnowledge #ZKProofs #Privacy #Confidentiality #CryptoPrivacy #QuantumResistance #PostQuantum #CryptoSecurity #FormalVerification #Consensus #Finality #GasFees #GasLimit #Blobs #Danksharding #State #UTXO #ERC20 #NFT #DeFiApps #OnChain #CryptoDev #EthereumDev #Protocol #Innovation #FutureOfFinance #Decentralization #OpenSource #CryptoEcosystem #CryptoInvesting #CryptoTrading #DigitalAssets #FinTech #CryptoFuture #Layer2 #Rollups #CryptoResearch #Vitalik #EthereumCommunity #CryptoUpdates #TechInnovation #DistributedSystems #PeerToPeer #Trustless #Permissionless #CryptoAdoption #NextGenBlockchain #EthereumUpgrade #Merge #PostMerge #CryptoStrategy #BlockchainFuture #ScalingSolutions #CryptoVision
