—————————————————————
Las bifurcaciones tradicionales de las cadenas de bloques suelen ir acompañadas de divisiones en la comunidad. Por ejemplo, la bifurcación de Ethereum y Ethereum Classic (ETC) surgió a partir de la decisión subjetiva de "revertir o no el contrato DAO que fue hackeado".
Esta bifurcación se basa en el consenso social: quien pueda convencer a más gente, cuya cadena "sobrevivirá".
La definición de Eigenlayer intenta cambiar esta situación. Mediante las palabras clave "predefinido" y "autoverificación", cambia las condiciones de activación de la bifurcación, pasando de vagos debates morales o económicos a reglas técnicas claras.
——Definido de antemano: significa que las condiciones del fork no son el resultado de disputas posteriores, sino que están escritas de antemano en el protocolo, de manera tan clara como un término legal. Esto reduce la incertidumbre que trae la toma de decisiones improvisadas.
——Auto-verificación: enfatiza que la verificabilidad de los eventos debe ser descentralizada, cualquier nodo (incluso nodos ligeros) puede juzgar de manera independiente si se han alcanzado las condiciones del fork, evitando depender de interpretaciones “autoritarias” centralizadas.
1）Potencial y limitaciones de las reglas existentes de Ethereum 🔻
Ethereum ya tiene algunos “eventos predefinidos” que pueden servir como criterios para el fork, como el rechazo de bloques no válidos, la negación de la reorganización por límites de tiempo, etc.
Estas reglas reflejan cierta característica de “auto-verificación”, especialmente los primeros tres puntos (rechazo de bloques no válidos, rechazo de reorganización por tiempo, rechazo de bloques no disponibles), ya que pueden completarse de manera independiente a través de la verificación local de los nodos. Sin embargo, la revisión de los validadores y los errores de cliente han expuesto las limitaciones de las reglas actuales.
1、dificultades de verificación en la revisión de los validadores:
Como mencionaste, la revisión de los validadores actualmente solo puede depender de “evidencia indirecta”, como quejas en redes sociales. Este método evidentemente no es lo suficientemente “auto-verificable”, ya que es susceptible a manipulaciones (por ejemplo, alguien puede difundir rumores malintencionados) y no se puede automatizar. Para que la revisión se convierta en un criterio para el fork, deben diseñarse indicadores técnicos, como un estándar observable de “X bloques consecutivos sin incluir ciertos tipos de transacciones”. Solo así los nodos podrán juzgar de manera independiente, en lugar de depender de información externa.
2、la complejidad de los errores del cliente:
Aunque los errores del cliente se pueden verificar mediante especificaciones de pseudocódigo, en la práctica, las habilidades técnicas de los operadores de nodos son variables. Si la mayoría de los nodos no pueden identificar oportunamente los errores y llegar a un consenso, la fase de ejecución del fork puede caer en el caos. Esta es precisamente la importancia de la diversidad de clientes (client diversity): un cliente único dominante puede llevar a un escenario de “el error es destino”, mientras que la diversidad dispersa el riesgo.
2）🔻 no incluido en el fork
1、situaciones en las que el proponente del fork realiza una revisión, como cuando el proponente del bloque revisa algo.
2、hacer un fork porque Lido, Coinbase o alguien tiene un 33% de stake
3、porque se realiza un fork debido a errores en la aplicación o en el nivel de usuario.
El fork debe centrarse en los problemas centrales a nivel de protocolo, no en factores externos o errores secundarios. Esto en realidad está delimitando las fronteras del fork, evitando que se abuse como herramienta política. Por ejemplo:
——Si se hace un fork simplemente porque Lido o Coinbase tienen el 33% de las acciones, esto es esencialmente un ataque al poder económico y no a un fallo técnico, lo que evidentemente se desvía del principio de “auto-verificación”.
——Errores en la capa de aplicación (por ejemplo, si una DApp falla) tampoco deberían activar un fork, ya que esto excede el alcance de las responsabilidades de la blockchain subyacente.
Esta delimitación de fronteras es muy clave, evita que el fork se convierta en un juego de “quien grita más tiene razón”, al mismo tiempo que protege el espíritu descentralizado de Ethereum.
3）De la preparación a la ejecución: el flujo ideal del fork 🔻
Las dos fases mencionadas en el libro blanco:
——Fase de preparación: la comunidad de Ethereum necesita alcanzar un consenso, escribir las condiciones del fork en el código del protocolo y hacerlo público y transparente en la cadena. Esto no solo es una tarea técnica, sino también una tarea de gobernanza, que necesita equilibrar los intereses de todas las partes.
——Fase de ejecución: una vez que se activan las condiciones, los nodos ejecutan automáticamente el fork según la verificación local, sin necesidad de intervención humana. Esto requiere que el diseño de las condiciones sea lo suficientemente preciso, evitando ambigüedades.
Pero en la realidad, alcanzar el consenso en la fase de preparación puede ser el mayor desafío. Las actualizaciones de Ethereum (como la transición a PoS) ya han demostrado que incluso las mejoras técnicas pueden retrasarse durante años debido a diferencias de intereses. La formulación de las condiciones del fork probablemente enfrentará una mayor controversia.
📍Conclusión:
La esencia del fork de Ethereum es mantener la seguridad, la credibilidad y la descentralización de la red, y el marco de “definido de antemano y auto-verificable” intenta hacer este proceso más objetivo y automático.
Las reglas actuales son un buen punto de partida, pero para realmente alcanzar esta visión, se necesita hacer más esfuerzos en el diseño técnico (especialmente en la detección de revisiones) y en la gobernanza comunitaria. En el futuro, el fork puede dejar de ser la “guerra civil” que divide a la comunidad, y convertirse en el “bisturí” de la auto-reparación del protocolo; siempre que podamos establecer reglas lo suficientemente buenas.
🔹Enlace de traducción original: https://x.com/sreeramkannan/status/1893361540759433558?t=nQp5B8x78sBq6Wp9GAewEA&s=19