{"id":176251,"date":"2026-10-09T00:19:41","date_gmt":"2026-10-09T00:19:41","guid":{"rendered":"https:\/\/crypto-economy.com\/es\/?p=176251"},"modified":"2026-10-09T00:19:42","modified_gmt":"2026-10-09T00:19:42","slug":"slashing-en-proof-of-stake","status":"publish","type":"post","link":"https:\/\/crypto-economy.com\/es\/slashing-en-proof-of-stake\/","title":{"rendered":"Slashing en proof-of-stake: La penalizaci\u00f3n por correlaci\u00f3n y el riesgo sist\u00e9mico que el sector evita discutir"},"content":{"rendered":"

La discusi\u00f3n p\u00fablica sobre <\/span>slashing<\/span><\/strong><\/a> en redes <\/span>proof-of-stake<\/span><\/strong><\/a> se ha estabilizado en una narrativa c\u00f3moda: se trata de un mecanismo punitivo para validadores deshonestos, la mayor\u00eda de los incidentes ocurre por <\/span>error operativo<\/span><\/strong>, y la soluci\u00f3n consiste en no duplicar claves.<\/span><\/p>\n

<\/p>\n

La narrativa es parcialmente correcta y, al mismo tiempo, insuficiente. El problema no radica en la existencia del slashing ni en su severidad inicial. El problema radica en la <\/span>penalizaci\u00f3n por correlaci\u00f3n<\/span><\/strong> y en la forma en que la industria eval\u00faa el <\/span>riesgo operativo<\/span><\/strong>.<\/span><\/p>\n

La posici\u00f3n que sostengo es directa: el slashing est\u00e1 bien dise\u00f1ado como <\/span>disuasivo econ\u00f3mico<\/span><\/strong>, pero la <\/span>penalizaci\u00f3n por correlaci\u00f3n<\/span><\/strong> introduce un <\/span>riesgo sist\u00e9mico<\/span><\/strong> que el sector subestima, y la <\/span>concentraci\u00f3n de operadores<\/span><\/strong> agrava la exposici\u00f3n.<\/span><\/p>\n

Fundamentos t\u00e9cnicos del slashing<\/span><\/h2>\n

El <\/span>slashing<\/span><\/strong> es un mecanismo de penalizaci\u00f3n en cadenas <\/span>proof-of-stake<\/span><\/strong><\/a>. Su funci\u00f3n es castigar la <\/span>equivocaci\u00f3n<\/span><\/strong>, entendida como la firma de mensajes contradictorios que podr\u00edan facilitar un ataque de <\/span>doble gasto<\/span><\/strong> o una <\/span>reorganizaci\u00f3n<\/span><\/strong> no autorizada. <\/span><\/p>\n

En Ethereum, las faltas slasheables se agrupan en dos categor\u00edas: <\/span>Casper FFG<\/span><\/strong><\/a> y <\/span>LMD GHOST<\/span><\/strong><\/a>. Incluyen la emisi\u00f3n de dos atestaciones con el mismo checkpoint objetivo, la emisi\u00f3n de atestaciones con votos que se rodean mutuamente, la propuesta de m\u00e1s de un bloque en la misma altura, y la atestaci\u00f3n a cabezas distintas con id\u00e9ntico origen y destino.<\/span><\/p>\n

La l\u00f3gica subyacente es correcta. Un validador con <\/span>stake<\/span><\/strong> en riesgo tiene incentivos para actuar de forma consistente. La <\/span>irracionalidad econ\u00f3mica<\/span><\/strong> de atacar la red se sostiene en la magnitud de la p\u00e9rdida potencial. Sin slashing, el costo de un ataque se reduce al valor del hardware y a la p\u00e9rdida de recompensas futuras, un costo insuficiente para disuadir a un actor con recursos.<\/span><\/p>\n

La distinci\u00f3n entre <\/span>slashing<\/span><\/strong> y <\/span>penalizaci\u00f3n por inactividad<\/span><\/strong> es relevante. La penalizaci\u00f3n por inactividad es menor, no expulsa al validador del conjunto activo y permite reanudar funciones. El slashing es severo, implica <\/span>expulsi\u00f3n forzosa<\/span><\/strong> y activa un proceso de salida de <\/span>36 d\u00edas<\/span><\/strong>. La diferencia de dise\u00f1o refleja una diferencia de prop\u00f3sito: la inactividad se incentiva, la equivocaci\u00f3n se castiga.<\/span><\/p>\n

Hasta aqu\u00ed, el consenso t\u00e9cnico es amplio. El desacuerdo comienza en el dise\u00f1o de las penalizaciones.<\/span><\/p>\n

Las tres penalizaciones y el problema de la correlaci\u00f3n<\/span><\/h2>\n

Un validador slasheado en Ethereum enfrenta <\/span>tres penalizaciones<\/span><\/strong>. La primera es una <\/span>multa inicial<\/span><\/strong> equivalente a aproximadamente <\/span>1\/32 del balance efectivo<\/span><\/strong>, con un m\u00e1ximo cercano a <\/span>1 ETH<\/span><\/strong>. La segunda es la p\u00e9rdida continua por <\/span>atestaciones omitidas<\/span><\/strong> durante el periodo de salida, que se extiende por <\/span>36 d\u00edas<\/span><\/strong>. La tercera es la <\/span>penalizaci\u00f3n por correlaci\u00f3n<\/span><\/strong>, aplicada alrededor del <\/span>d\u00eda 18<\/span><\/strong>.<\/span><\/p>\n

La penalizaci\u00f3n por correlaci\u00f3n es el componente que merece escrutinio. Su f\u00f3rmula escala con el <\/span>porcentaje del stake total<\/span><\/strong> involucrado en faltas slasheables dentro de una ventana de <\/span>36 d\u00edas<\/span><\/strong>. La penalizaci\u00f3n adicional equivale a aproximadamente <\/span>tres veces<\/span><\/strong> ese porcentaje. Si el <\/span>5% del ETH en stake<\/span><\/strong> comete una falta slasheable en la ventana, cada validador afectado pierde un <\/span>15% adicional<\/span><\/strong> de su balance.<\/span><\/p>\n

El dise\u00f1o tiene una virtud te\u00f3rica: <\/span>penaliza la coordinaci\u00f3n<\/span><\/strong>. Un ataque coordinado requiere que m\u00faltiples validadores act\u00faen de forma sincronizada. La penalizaci\u00f3n por correlaci\u00f3n encarece esa coordinaci\u00f3n de forma <\/span>superlineal<\/span><\/strong>. Un atacante que controle el <\/span>33% del stake<\/span><\/strong> enfrenta una p\u00e9rdida que escala con el tama\u00f1o de la coalici\u00f3n.<\/span><\/p>\n

La virtud te\u00f3rica se convierte en <\/span>vulnerabilidad pr\u00e1ctica<\/span><\/strong> cuando la independencia de los validadores no se cumple.<\/span><\/p>\n

La falacia de la independencia<\/span><\/h2>\n

La penalizaci\u00f3n por correlaci\u00f3n asume que las faltas slasheables son <\/span>independientes<\/span><\/strong> entre validadores. La suposici\u00f3n es razonable para un conjunto distribuido de operadores con infraestructura heterog\u00e9nea. No es razonable para un conjunto dominado por <\/span>operadores institucionales<\/span><\/strong> que comparten <\/span>proveedores de infraestructura<\/span><\/strong>, <\/span>clientes de consenso<\/span><\/strong>, <\/span>clientes de ejecuci\u00f3n<\/span><\/strong>, <\/span>servicios de custodia<\/span><\/strong> y <\/span>pr\u00e1cticas operativas<\/span><\/strong>.<\/span><\/p>\n

La evidencia emp\u00edrica respalda la preocupaci\u00f3n. La mayor\u00eda de los eventos de slashing registrados en Ethereum se originaron en <\/span>error operativo<\/span><\/strong>, no en <\/span>malicia<\/span><\/strong>. El caso recurrente es la ejecuci\u00f3n de <\/span>claves de validador duplicadas<\/span><\/strong> en dos nodos simult\u00e1neos, con frecuencia durante una <\/span>migraci\u00f3n<\/span><\/strong> o una <\/span>conmutaci\u00f3n por error<\/span><\/strong>. La causa es humana. La consecuencia es econ\u00f3mica.<\/span><\/p>\n

El punto que la industria evita discutir es el siguiente: si un <\/span>proveedor de servicios de staking<\/span><\/strong><\/a> con <\/span>decenas de miles de validadores<\/span><\/strong> comete un error de configuraci\u00f3n que afecta a una fracci\u00f3n de sus nodos, la penalizaci\u00f3n por correlaci\u00f3n se activa como si se tratara de un ataque coordinado. La <\/span>penalizaci\u00f3n superlineal<\/span><\/strong> castiga al operador por una <\/span>falla de infraestructura<\/span><\/strong>, no por una <\/span>conducta maliciosa<\/span><\/strong>.<\/span><\/p>\n

La distinci\u00f3n importa. El slashing est\u00e1 dise\u00f1ado para disuadir <\/span>ataques<\/span><\/strong>. La penalizaci\u00f3n por correlaci\u00f3n est\u00e1 dise\u00f1ada para disuadir <\/span>ataques coordinados<\/span><\/strong>. Aplicar ambas a <\/span>fallas operativas correlacionadas<\/span><\/strong> introduce una <\/span>externalidad negativa<\/span><\/strong> que el dise\u00f1o original no contempl\u00f3.<\/span><\/p>\n

Existe un agravante. La penalizaci\u00f3n por correlaci\u00f3n no distingue entre <\/span>intenci\u00f3n<\/span><\/strong> y <\/span>negligencia<\/span><\/strong>. Un operador que ejecuta claves duplicadas por un error de configuraci\u00f3n recibe el mismo tratamiento que un atacante que coordina validadores para revertir checkpoints. La equivalencia es problem\u00e1tica desde una perspectiva de <\/span>incentivos<\/span><\/strong>. El operador negligente no busca atacar la red. El atacante s\u00ed. La penalizaci\u00f3n no diferencia.<\/span><\/p>\n

Concentraci\u00f3n de operadores<\/span><\/h2>\n

El argumento anterior depende de la <\/span>concentraci\u00f3n<\/span><\/strong>. En un conjunto de validadores con <\/span>diversidad operativa<\/span><\/strong>, la correlaci\u00f3n es baja y la penalizaci\u00f3n por correlaci\u00f3n permanece cerca del m\u00ednimo. En un conjunto con <\/span>concentraci\u00f3n<\/span><\/strong>, la correlaci\u00f3n es alta y la penalizaci\u00f3n por correlaci\u00f3n se convierte en un <\/span>riesgo sist\u00e9mico<\/span><\/strong>.<\/span><\/p>\n

La evidencia disponible apunta a <\/span>concentraci\u00f3n creciente<\/span><\/strong>. Los <\/span>proveedores de staking l\u00edquido<\/span><\/strong> y los <\/span>operadores institucionales<\/span><\/strong> controlan porciones significativas del <\/span>stake<\/span><\/strong><\/a> en Ethereum. La tendencia no es exclusiva de Ethereum. Otras redes proof-of-stake con <\/span>mecanismos de slashing<\/span><\/strong> muestran patrones similares.<\/span><\/p>\n

\"bullish<\/p>\n

La concentraci\u00f3n tiene dos efectos. Primero, <\/span>reduce la diversidad de infraestructura<\/span><\/strong>. Segundo, <\/span>aumenta la probabilidad de fallas correlacionadas<\/span><\/strong>. La combinaci\u00f3n eleva la <\/span>exposici\u00f3n<\/span><\/strong> de cada validador individual a la <\/span>penalizaci\u00f3n por correlaci\u00f3n<\/span><\/strong>.<\/span><\/p>\n

La industria reconoce la concentraci\u00f3n como un problema de <\/span>descentralizaci\u00f3n<\/span><\/strong>. La discusi\u00f3n se centra en la <\/span>censura<\/span><\/strong> y en la <\/span>captura de gobernanza<\/span><\/strong>. La discusi\u00f3n sobre <\/span>slashing<\/span><\/strong> y <\/span>riesgo operativo correlacionado<\/span><\/strong> recibe menos atenci\u00f3n. La asimetr\u00eda es reveladora. La censura es visible. La penalizaci\u00f3n por correlaci\u00f3n es un riesgo latente que se materializa en eventos discretos y se olvida entre incidentes.<\/span><\/p>\n

Qu\u00e9 deber\u00eda cambiar<\/span><\/h2>\n

La posici\u00f3n que sostengo no es la eliminaci\u00f3n de la penalizaci\u00f3n por correlaci\u00f3n. El mecanismo cumple una funci\u00f3n. La posici\u00f3n es que el sector debe <\/span>reconocer el riesgo<\/span><\/strong> y <\/span>ajustar pr\u00e1cticas<\/span><\/strong>.<\/span><\/p>\n

Tres cambios son necesarios.<\/span><\/p>\n

Primero<\/span><\/strong>, los operadores deben tratar la <\/span>gesti\u00f3n de claves<\/span><\/strong> como un problema de <\/span>seguridad de grado institucional<\/span><\/strong>, no como una <\/span>tarea de configuraci\u00f3n<\/span><\/strong>. La <\/span>duplicaci\u00f3n de claves<\/span><\/strong> no es un accidente inevitable. Es un <\/span>fallo de control<\/span><\/strong>. Los procedimientos de <\/span>rotaci\u00f3n de claves<\/span><\/strong>, <\/span>verificaci\u00f3n de estado<\/span><\/strong> y <\/span>auditor\u00eda de firmas<\/span><\/strong> deber\u00edan ser est\u00e1ndar, no opcionales.<\/span><\/p>\n

Segundo<\/span><\/strong>, los <\/span>proveedores de infraestructura<\/span><\/strong> deben ofrecer <\/span>aislamiento<\/span><\/strong> entre <\/span>entornos de validaci\u00f3n<\/span><\/strong>. La <\/span>conmutaci\u00f3n por error<\/span><\/strong> no deber\u00eda permitir que dos nodos firmen simult\u00e1neamente. Los <\/span>sistemas de firma remota<\/span><\/strong> y los <\/span>guardianes de slashing<\/span><\/strong> existen. Su adopci\u00f3n es desigual. La adopci\u00f3n desigual no es un problema de disponibilidad tecnol\u00f3gica. Es un problema de <\/span>prioridades operativas<\/span><\/strong>.<\/span><\/p>\n

Tercero<\/span><\/strong>, la <\/span>investigaci\u00f3n de mecanismos<\/span><\/strong> deber\u00eda evaluar si la <\/span>penalizaci\u00f3n por correlaci\u00f3n<\/span><\/strong> requiere <\/span>par\u00e1metros diferenciados<\/span><\/strong> para <\/span>faltas maliciosas<\/span><\/strong> y <\/span>faltas operativas<\/span><\/strong>. La <\/span>diferenciaci\u00f3n<\/span><\/strong> es t\u00e9cnicamente compleja. Requiere <\/span>pruebas criptogr\u00e1ficas<\/span><\/strong> de intenci\u00f3n que no existen de forma generalizada. La <\/span>complejidad<\/span><\/strong> no es una raz\u00f3n para ignorar el problema. Es una raz\u00f3n para <\/span>investigar<\/span><\/strong>.<\/span><\/p>\n

El <\/span>slashing<\/span><\/strong> es un componente necesario de la <\/span>seguridad econ\u00f3mica<\/span><\/strong> en <\/span>proof-of-stake<\/span><\/strong><\/a>. La <\/span>penalizaci\u00f3n inicial<\/span><\/strong> y las <\/span>p\u00e9rdidas por atestaci\u00f3n<\/span><\/strong> cumplen una funci\u00f3n disuasiva. La <\/span>penalizaci\u00f3n por correlaci\u00f3n<\/span><\/strong> cumple una funci\u00f3n adicional: encarecer la <\/span>coordinaci\u00f3n maliciosa<\/span><\/strong>.<\/span><\/p>\n","protected":false},"excerpt":{"rendered":"

La discusi\u00f3n p\u00fablica sobre slashing en redes proof-of-stake se ha estabilizado en una narrativa c\u00f3moda: se trata de un mecanismo punitivo para validadores deshonestos, la mayor\u00eda de los incidentes ocurre por error operativo, y la soluci\u00f3n consiste en no duplicar claves.<\/p>\n","protected":false},"author":53,"featured_media":176254,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"rank_math_title":"","rank_math_description":"","footnotes":""},"categories":[925],"tags":[10124,10125],"class_list":["post-176251","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-opinion","tag-proof-of-stake-2","tag-slashing"],"_links":{"self":[{"href":"https:\/\/crypto-economy.com\/es\/wp-json\/wp\/v2\/posts\/176251","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/crypto-economy.com\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/crypto-economy.com\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/crypto-economy.com\/es\/wp-json\/wp\/v2\/users\/53"}],"replies":[{"embeddable":true,"href":"https:\/\/crypto-economy.com\/es\/wp-json\/wp\/v2\/comments?post=176251"}],"version-history":[{"count":2,"href":"https:\/\/crypto-economy.com\/es\/wp-json\/wp\/v2\/posts\/176251\/revisions"}],"predecessor-version":[{"id":176253,"href":"https:\/\/crypto-economy.com\/es\/wp-json\/wp\/v2\/posts\/176251\/revisions\/176253"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/crypto-economy.com\/es\/wp-json\/wp\/v2\/media\/176254"}],"wp:attachment":[{"href":"https:\/\/crypto-economy.com\/es\/wp-json\/wp\/v2\/media?parent=176251"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/crypto-economy.com\/es\/wp-json\/wp\/v2\/categories?post=176251"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/crypto-economy.com\/es\/wp-json\/wp\/v2\/tags?post=176251"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}