————————————————————
Les forks de blockchain traditionnels s'accompagnent souvent de fractures au sein de la communauté, par exemple, le fork entre Ethereum et Ethereum Classic (ETC) est né d'un jugement subjectif sur la question de savoir s'il fallait annuler le contrat DAO attaqué par un hacker.
Ce fork dépend du consensus social — qui peut convaincre le plus de personnes, la chaîne de qui 'survivra'.
La définition d'Eigenlayer tente de changer cette situation, en déplaçant les conditions de déclenchement du fork d'un débat moral ou économique flou vers des règles techniques claires à travers les mots-clés 'pré-défini' et 'auto-vérifié'.
—— Pré-défini : cela signifie que les conditions du fork ne sont pas le résultat de disputes ultérieures, mais sont écrites à l'avance dans le protocole, aussi clairement que des clauses légales. Cela réduit l'incertitude causée par des décisions ad-hoc.
—— auto-vérification : soulignant que la vérifiabilité des événements doit être décentralisée, tout nœud (y compris les nœuds légers) doit pouvoir juger indépendamment si les conditions de fork ont été atteintes, évitant ainsi de dépendre d'une 'autorité' centralisée.
1）Le potentiel et les insuffisances des règles existantes d'Ethereum 🔻
Ethereum a déjà certains 'événements pré-définis' qui peuvent servir de base pour un fork, comme le rejet des blocs invalides, le refus de réorganisation après expiration des délais, etc.
Ces règles incarnent effectivement certaines caractéristiques d'auto-vérification, en particulier les trois premiers points (rejet des blocs invalides, rejet de la réorganisation après expiration, rejet des blocs non disponibles), car ils peuvent être réalisés indépendamment par une vérification locale des nœuds. Cependant, l'examen par le validateur et les bugs des clients exposent les limites des règles actuelles.
1、problème de vérification examiné par le validateur :
Comme vous l'avez dit, l'examen par le validateur ne peut actuellement dépendre que de 'preuves indirectes', comme les plaintes sur les réseaux sociaux. Cette méthode est manifestement insuffisante en termes d'auto-vérification, car elle est facile à manipuler (par exemple, quelqu'un qui propage des rumeurs malveillantes) et ne peut pas être algorithmisée. Pour que l'examen devienne un fondement de fork, des indicateurs techniques doivent être conçus, comme un critère observable de 'X blocs consécutifs n'incluant pas un certain type de transaction'. Cela permettra aux nœuds de juger indépendamment, plutôt que de dépendre d'informations externes.
2、la complexité des bugs des clients :
Bien que les bugs des clients puissent être vérifiés par des spécifications de pseudo-code, en pratique, les capacités techniques des opérateurs de nœuds varient considérablement. Si la plupart des nœuds ne peuvent pas identifier rapidement les bugs et parvenir à un consensus, la phase d'exécution du fork pourrait sombrer dans le chaos. C'est là que l'importance de la diversité des clients (client diversity) entre en jeu — un client unique dominant peut facilement mener à une situation où 'le bug est le destin', tandis que la diversité répartit le risque.
2）Les forks n'incluent pas 🔻
1、exemples de situations où le proposeur de fork effectue une révision, comme un proposeur de bloc examinant certains éléments.
2、fork simplement parce que Lido, Coinbase ou quelqu'un a 33 % de stake
3、en raison d'erreurs du niveau application ou utilisateur entraînant un fork.
Le fork doit se concentrer sur les problèmes centraux au niveau du protocole, et non sur des facteurs externes ou des erreurs secondaires. C'est en fait une délimitation des frontières du fork, empêchant son utilisation abusive en tant qu'outil politique. Par exemple :
—— Si un fork a lieu simplement parce que Lido ou Coinbase détient 33 % des actions, cela s'attaque essentiellement au pouvoir économique plutôt qu'à une défaillance technique, ce qui s'écarte clairement du principe d'auto-vérification.
—— Les erreurs de couche d'application (comme un DApp qui plante) ne devraient pas déclencher de fork, car cela dépasse le périmètre de responsabilité de la blockchain sous-jacente.
Cette définition des frontières est cruciale, elle évite que le fork ne devienne un jeu de 'celui qui crie le plus fort a raison', tout en protégeant l'esprit de décentralisation d'Ethereum.
3）De la préparation à l'exécution : le processus idéal de fork 🔻
Les deux phases mentionnées dans le livre blanc :
—— Phase de préparation : la communauté Ethereum doit parvenir à un consensus pour écrire les conditions de fork dans le code du protocole et les rendre publiquement transparentes sur la chaîne. Cela nécessite non seulement un travail technique, mais aussi une tâche de gouvernance, nécessitant un équilibre des intérêts de toutes les parties.
—— Phase d'exécution : une fois les conditions déclenchées, les nœuds exécutent automatiquement le fork en fonction de la vérification locale, sans intervention humaine. Cela nécessite que la conception des conditions soit suffisamment précise, évitant toute ambiguïté.
Mais dans la réalité, atteindre le consensus en phase de préparation peut être le plus grand défi. Les mises à niveau d'Ethereum (comme la transition vers PoS) ont déjà montré qu'il peut y avoir des retards de plusieurs années même pour des améliorations techniques en raison de divergences d'intérêts. La définition des conditions de fork pourrait faire face à des controverses encore plus grandes.
📍Conclusion :
L'essence du fork d'Ethereum est de maintenir la sécurité, la crédibilité et la décentralisation du réseau, tandis que le cadre 'pré-défini et auto-vérifié' tente de rendre ce processus plus objectif et automatisé.
Les règles existantes sont un bon point de départ, mais pour réaliser cette vision, il faut encore faire plus d'efforts en matière de conception technique (en particulier pour la détection des examens) et de gouvernance communautaire. À l'avenir, le fork pourrait ne plus être une 'guerre civile' déchirant la communauté, mais un 'scalpel' d'auto-réparation du protocole — à condition que nous puissions définir les règles suffisamment bien.
🔹Lien vers la traduction originale : https://x.com/sreeramkannan/status/1893361540759433558?t=nQp5B8x78sBq6Wp9GAewEA&s=19