¿Cómo funcionan realmente las criptomonedas? Claves, consenso y transacciones

¿Qué significa poseer criptomonedas?

La conocida frase «las monedas están en tu monedero» es una metáfora útil de la interfaz, pero una descripción técnica deficiente. Una cadena de bloques almacena un estado: salidas no gastadas en Bitcoin, saldos de cuentas y almacenamiento de contratos en Ethereum, o cuentas propiedad de programas en Solana. Un monedero lee ese estado, elabora instrucciones y genera cualquier autorización que la red requiera.

En el caso de una cuenta convencional de autocustodia, esa autoridad puede reducirse a una sola clave privada. Pero la regla general es más precisa: la propiedad es el control de la política de gasto válida. Una salida de Bitcoin puede requerir un script o múltiples firmas. Una cuenta de contrato de Ethereum puede requerir aprobación mediante multifirma, un módulo de clave de acceso, un bloqueo temporal o una recuperación social. Un sistema de firma por umbral puede distribuir una autoridad de firma entre varias partes de clave. Un custodio puede poseer la autoridad criptográfica, mientras que el cliente solo tiene un derecho contractual frente al custodio.

Esta distinción explica por qué «si no tienes las claves, no tienes las monedas» es una advertencia sobre la exposición frente a la contraparte, más que una estrategia de seguridad completa. Conservar las claves elimina a un intermediario y añade responsabilidad operativa directa. Ninguno de los dos modelos de custodia es automáticamente seguro por el mero hecho de estar etiquetado como «centralizado» o «autocustodio».

¿Para qué sirven realmente las claves privadas, las claves públicas y las direcciones?

La mayoría de las cadenas principales utilizan criptografía de clave pública para las firmas digitales. El monedero genera o accede a material secreto, deriva información pública y crea una firma sobre un mensaje definido con precisión. La verificación es rápida; derivar la clave privada a partir de la clave pública se considera computacionalmente inviable bajo los supuestos matemáticos del esquema y con claves generadas correctamente. «Inviable» es la afirmación correcta: la seguridad depende del algoritmo, la implementación, la generación de números aleatorios y las capacidades informáticas actuales.

Qué demuestra una firma

Una firma válida demuestra que el secreto requerido o el quórum de firma autorizó un resumen concreto según el algoritmo de firma especificado. También permite al verificador detectar cambios en la carga útil firmada. No demuestra que el firmante leyera la pantalla de la cartera, entendiera la aprobación de un token, conociera al destinatario, no fuera coaccionado o fuera el propietario de los fondos en sentido legal. Esa brecha entre la autorización criptográfica y la intención humana es donde operan muchos estafadores que vacían carteras y estafas de suplantación de identidad.

¿Qué puede socavar la seguridad de la firma?

• Una generación de claves débil o sesgada que produzca material secreto fácil de adivinar.
• La reutilización o filtración de nonces en firmas de tipo ECDSA o Schnorr, lo que puede exponer una clave privada.
• Malware, canales laterales o ataques físicos que extraen material secreto de un dispositivo.
• Un monedero que firma una carga útil diferente a la que el usuario creía que se mostraba.
• Una implementación de cuenta inteligente, multisig o de umbral que acepte una ruta de política no válida o no autorizada.
• Futuros avances criptoanalíticos o cuánticos que invaliden las hipótesis actuales sobre la resistencia.

Conclusión: La criptografía de clave pública elimina la necesidad de revelar el secreto durante la verificación. No elimina, sin embargo, la necesidad de una generación segura de claves, un software de firma fiable y una revisión precisa de las transacciones.

¿Qué firma exactamente un monedero?

La interfaz del monedero convierte la intención humana en un mensaje estructurado. Esa traducción es fundamental para la seguridad. En Bitcoin, la transacción selecciona salidas específicas no gastadas como entradas, crea nuevas salidas con condiciones de gasto, especifica importes y comisiones, y aplica un modo de hash de firma que determina a qué partes se compromete cada firma. En Ethereum, una transacción normal incluye campos como el identificador de la cadena, el nonce de la cuenta, el destino, el valor, el límite de gas, los límites de comisión y datos opcionales que pueden invocar un contrato.

Las interacciones con contratos pueden codificar mucho más que un pago. Una firma puede aprobar una asignación de tokens, realizar una operación a través de un exchange descentralizado, delegar una EOA al código según la EIP-7702, transferir un NFT, votar en un sistema de gobernanza o llamar a una función cuyo resultado dependa del estado actual de la cadena. La red ve bytes válidos; no sabe si el monedero los ha explicado correctamente.

Antes de firmar, verifica al menos estos campos

• Red y cadena: la cadena prevista, Capa 2 o cadena lateral, no solo el símbolo del activo.
• Activo y contrato: el activo nativo o el contrato del token correctos, incluyendo los decimales y el estándar del token.
• Destino: la dirección completa del destinatario, del contrato, del puente o del depósito en una plataforma de intercambio, así como cualquier nota o etiqueta requerida.
• Importe y alcance: importe exacto de la transferencia, importe mínimo recibido, límite de gasto o alcance de la autorización.
• Acción: transferencia, intercambio, aprobación, permiso, delegación, acción de staking, despliegue de contrato o firma de un mensaje arbitrario.
• Límites de comisiones: tasa de comisión de Bitcoin y comisión total, o límite de gas de Ethereum, exposición a la comisión base, comisión de prioridad y comisión máxima.
• Vencimiento y ámbito de repetición: identificador de la cadena, nonce, fecha límite y la aplicación o el contrato para los que la firma es válida.
• Ruta de la política: qué claves, cofirmantes, módulos o mecanismos de recuperación autorizan la acción.

Las carteras de hardware ayudan, pero no entienden de economía

Una cartera de hardware puede mantener una clave privada alejada de un ordenador de uso general y firmar solo tras la confirmación en una pantalla de confianza. Esto protege contra muchos ataques de extracción. No puede neutralizar una aprobación maliciosa, demostrar que la dirección de un contrato es fiable, detectar todas las sustituciones por envenenamiento de direcciones ni garantizar que una visualización abreviada contenga suficiente información. Un dispositivo seguro resulta más útil cuando el usuario puede interpretar de forma independiente lo que muestra.

¿Qué ocurre después de pulsar «Enviar»?

Paso 1: construcción y firma locales

La cartera elige las entradas o el siguiente nonce de la cuenta, calcula las comisiones, crea la carga útil y la firma. Esto puede realizarse en un teléfono, en una cartera de navegador, en un dispositivo de hardware, a través de un coordinador de multifirma o en una sesión de firma MPC. La clave secreta no debe transmitirse a la red; para la verificación solo se necesitan la transacción y la firma.

Paso 2: validación y retransmisión por parte del nodo

El primer nodo comprueba la sintaxis, las firmas, los fondos disponibles o los UTXO, el nonce, el tamaño, el gas y otras reglas. También aplica la política local: una transacción puede ser válida según el consenso, pero no cumplir los requisitos de retransmisión o del mempool de un nodo. Los nodos tienen mempools pendientes independientes y pueden discrepar sobre lo que contienen en ese momento. No existe un único mempool global que compartan todas las máquinas.

Paso 3: construcción de bloques

Los grupos de minería de Bitcoin construyen bloques candidatos a partir de las transacciones válidas de las que tienen conocimiento, teniendo en cuenta las comisiones, las dependencias y sus propias políticas. Los validadores de Ethereum pueden construir bloques localmente o utilizar generadores especializados que optimizan el orden de las transacciones y pujan por la oportunidad de la propuesta. El flujo de órdenes privado puede eludir el mempool público, y el valor máximo extraíble puede afectar al orden.

Paso 4: verificación independiente del bloque

Una vez propuesto un bloque, los demás nodos no lo aceptan simplemente porque confíen en el productor. Verifican de forma independiente el bloque y cada transición de estado relevante. Un productor que incluya un gasto no válido, supere los límites o incumpla las reglas de consenso crea un bloque que los nodos honestos rechazan, independientemente de sus ingresos por comisiones o de su peso en términos de recursos.

Paso 5: inclusión, reorganización y liquidación

La inclusión es la primera confirmación. Pueden coexistir brevemente bloques rivales en la punta de la cadena, y la regla de elección de bifurcación determina qué rama se convierte en canónica. Las transacciones de un bloque abandonado pueden volver al estado «pendiente», entrar en conflicto con otra transacción o desaparecer de la vista de un nodo. Un mayor número de confirmaciones o la finalidad explícita de los puntos de control reducen este riesgo.

¿Por qué esperan las transacciones y cómo funcionan las comisiones?

Bitcoin: pagar por el espacio virtual en los bloques

Las comisiones de las transacciones de Bitcoin son la diferencia entre el valor de entrada y el valor de salida. Las carteras y Bitcoin Core suelen expresar la oferta en satoshis por byte virtual (sat/vB), lo que permite a los mineros comparar transacciones de diferentes tamaños virtuales. Las entradas, las salidas y los datos de testigo determinan el tamaño; la cantidad de bitcoins transferida no lo hace.

Las dependencias son importantes. Una transacción «padre» con una comisión baja y una transacción «hija» con una comisión alta pueden evaluarse conjuntamente, y la lógica actual del mempool de Bitcoin Core analiza los grupos de transacciones conectadas en lugar de tratar cada transacción como totalmente independiente. Las funciones «Replace-by-fee» y «child-pays-for-parent» pueden mejorar la inclusión cuando la transacción y el monedero las admiten. Un reemplazo no garantiza la cancelación: las transacciones que compiten entre sí se disputan hasta que una de ellas se confirma.

Ethereum: gas, tarifa base y tarifa de prioridad

Ethereum cobra por el cálculo y el acceso al estado en unidades de gas. Una transacción establece un límite de gas y unos límites máximos de tarifa. El protocolo calcula una tarifa base que se quema; el remitente puede añadir una tarifa de prioridad, y la tarifa máxima limita el precio por unidad de gas. El gas no utilizado no se cobra. Una llamada a un contrato que se revierte puede seguir consumiendo gas, ya que los validadores han ejecutado el cálculo.

Las transacciones de las cuentas de Ethereum se ejecutan en orden de nonce. Un nonce anterior infravalorado o no detectado puede bloquear transacciones posteriores de la misma cuenta, incluso cuando dichas transacciones posteriores ofrezcan comisiones más altas. Una sustitución con el mismo nonce puede sustituir a una transacción pendiente si el nodo receptor o la política de la cartera acepta la puja más alta.

El orden no es solo una clasificación por comisiones

En Ethereum, los desarrolladores y los buscadores pueden ordenar paquetes para aprovechar el arbitraje, las liquidaciones u otros tipos de MEV. Los usuarios pueden enviar solicitudes a través de canales privados para reducir su exposición pública. En Bitcoin, los pools pueden aplicar políticas personalizadas o incluir transacciones recibidas fuera de banda. Las comisiones siguen siendo fundamentales, pero afirmar que «la comisión más alta siempre tiene prioridad» es una simplificación excesiva.

Conclusión: El mercado de comisiones valora los escasos recursos de inclusión. No verifica al destinatario, no garantiza la honestidad de la aplicación ni compensa una transacción firmada bajo falsos pretextos.

¿Cómo registran la propiedad Bitcoin, Ethereum y Solana?

Bitcoin: el modelo UTXO

El saldo de un monedero de Bitcoin es una suma conveniente de salidas de transacción no gastadas que puede satisfacer. Una transacción consume salidas existentes y crea otras nuevas. Las entradas apuntan a salidas anteriores; los scripts y las firmas demuestran que se cumplen las condiciones de gasto. Si el valor de la entrada supera el pago previsto y la comisión, el monedero suele crear una salida de cambio.

Ethereum: estado de cuentas y contratos

Ethereum mantiene un estado global que contiene cuentas de propiedad externa (EOA) y cuentas de contrato. Una EOA tiene un saldo, un nonce y una autoridad basada en claves; una cuenta de contrato tiene código y almacenamiento. Una transacción desde una EOA puede transferir ETH, desplegar un contrato o llamar a código que actualice muchas cuentas y libros de contabilidad de tokens en una única ejecución atómica.

Solana: cuentas propiedad de programas

Solana separa los programas ejecutables de las cuentas que contienen datos mutables. Cada cuenta tiene una dirección y un programa propietario que controla los cambios en sus datos o los cargos. Las cuentas de los usuarios firmantes utilizan direcciones de clave pública, mientras que las direcciones derivadas de programas permiten que un programa autorice cuentas determinísticas fuera de la curva sin necesidad de una clave privada.

Conclusión: «La cadena de bloques almacena saldos» es una afirmación correcta para algunos sistemas y engañosa para otros. La idea fundamental es que los nodos mantienen un estado determinista derivado de las transacciones y los bloques aceptados.

¿Qué incluye realmente el consenso de la cadena de bloques?

La validez es lo primero

Cada nodo completo evalúa los bloques según las reglas que ejecuta. Los nodos de Bitcoin verifican los scripts, la disponibilidad de UTXO, la estructura de los bloques y las restricciones monetarias. Los clientes de ejecución de Ethereum verifican las transacciones y las transiciones de estado, mientras que los clientes de consenso verifican las reglas relativas a los proponentes y a la certificación. Un bloque que no cumple los requisitos de validez no entra en absoluto en la competición por la cadena válida.

Resistencia a los ataques Sybil y selección de proponentes

Las redes abiertas necesitan una forma de evitar que un participante adquiera influencia creando millones de identidades. La prueba de trabajo vincula la influencia al trabajo computacional; la prueba de participación la vincula al capital aportado. Cada mecanismo asigna oportunidades de producción de bloques o de voto en función de un recurso escaso.

Elección de la bifurcación

Los desacuerdos temporales son normales en los sistemas distribuidos. Los nodos de Bitcoin eligen la cadena válida con la mayor prueba de trabajo acumulada. Ethereum utiliza LMD-GHOST para seguir la rama válida con el mayor peso de certificación efectivo. La elección de la bifurcación determina sobre qué rama actual se va a construir; no es lo mismo que la finalidad.

Finalidad y recuperación

Bitcoin no califica un bloque como definitivo de forma permanente; la confianza aumenta con la profundidad. Ethereum utiliza los puntos de control de Casper FFG para crear un estado finalizado explícito cuando se alcanzan los votos de mayoría cualificada necesarios. Si Ethereum llegara a generar historiales finalizados contradictorios, los mensajes del protocolo por sí solos no podrían elegir entre ellos; la recuperación requeriría una coordinación social.

¿Cómo protege Bitcoin la prueba de trabajo?

Un minero ensambla un bloque candidato, varía los campos de la cabecera y calcula los hash SHA-256. Cada hash es un boleto de lotería. El protocolo ajusta la dificultad cada 2.016 bloques para que, con el tiempo, los bloques tarden una media de unos diez minutos en generarse. El minero ganador recibe la recompensa del bloque —3,125 BTC desde la reducción a la mitad de abril de 2024— más las comisiones por transacción, siempre que el bloque sea válido y sea aceptado por la red.

El coste energético no se utiliza para calcular la validez de las transacciones ordinarias. Esto encarece la creación de una cadena alternativa y proporciona a los nodos una regla objetiva basada en el trabajo acumulado para elegir entre ramas válidas. Una vez consumida la electricidad, no se puede recuperar; el hardware especializado puede conservar su valor de reventa o de minería. Por lo tanto, la seguridad depende de la distribución del poder de hash, el acceso al hardware y a la energía, la coordinación de los grupos de minería, la conectividad de la red y el valor económico en riesgo.

Lo que la potencia de hash mayoritaria puede y no puede hacer

La expresión «ataque del 51 %» es una forma abreviada de referirse a este concepto. Por debajo del 50 %, un atacante aún puede tener una probabilidad distinta de cero de sustituir el historial reciente; por encima del 50 %, el dominio sostenido se vuelve fiable bajo supuestos simplificados. El riesgo práctico depende de la duración, las condiciones de la red y la rapidez con la que los destinatarios respondan retrasando la liquidación.

Conclusión: la prueba de trabajo regula la competencia entre historiales válidos. No otorga a los mineros la autoridad para reescribir las reglas de firma, confiscar monedas de forma arbitraria o redefinir la oferta para los nodos que rechacen dichos cambios.

¿Cómo protege Ethereum la prueba de participación?

El tiempo se divide en intervalos de 12 segundos y épocas de 32 intervalos. Se selecciona un validador para proponer un bloque en un intervalo, mientras que los comités certifican su visión de la cadena. Cada validador activo suele certificar una vez por época. Tras Pectra, 32 ETH siguen siendo el mínimo de activación; los validadores que opten por la acumulación de credenciales pueden tener un saldo efectivo de hasta 2.048 ETH.

Ethereum utiliza funciones clave independientes. Las tareas de validación utilizan claves de firma BLS para que las certificaciones puedan agregarse de manera eficiente. La autoridad de retirada puede mantenerse por separado y, tras Pectra, las credenciales de la capa de ejecución pueden activar salidas. Por lo tanto, una clave EOA normal de Ethereum no es automáticamente la misma clave que realiza las tareas de validación.

Los umbrales de ataque describen diferentes capacidades

El slashing y la inactividad son cosas diferentes

La penalización castiga firmas contradictorias específicas, como propuestas dobles, votos dobles o votos envolventes. La pérdida inmediata para un validador aislado no es necesariamente la totalidad de su saldo; una penalización masiva correlacionada puede imponer pérdidas mucho mayores. Los validadores que simplemente están desconectados suelen incurrir en sanciones menores. Si la finalidad se detiene durante más de cuatro épocas, la fuga por inactividad reduce gradualmente los saldos efectivos inactivos hasta que los validadores activos restantes puedan recuperar una mayoría cualificada de dos tercios.

Conclusión: La prueba de participación (PoS) integra el capital en el sistema de sanciones del protocolo, pero la afirmación de que «un ataque quema toda la participación» es falsa. Las capacidades, las pruebas y las sanciones varían según el tipo de ataque, y la recuperación catastrófica de la seguridad incluye una capa social.

¿Cuándo es definitiva una transacción de criptomonedas?

Bitcoin: profundidad de confirmación

El bloque que contiene una transacción es la confirmación número uno. Cada bloque posterior aumenta el trabajo acumulado que un atacante necesitaría para sustituirla. Seis confirmaciones, aproximadamente una hora de media, es una convención habitual para liquidaciones de alto valor, no una regla universal ni una garantía. Los pagos pequeños pueden aceptarse antes; las transacciones extremadamente valiosas o conflictivas pueden justificar una mayor profundidad.

Ethereum: más reciente, seguro y finalizado

Los clientes de Ethereum pueden distinguir la cabeza canónica más reciente de una vista segura y una vista finalizada. La finalidad significa que revertir el bloque requeriría un fallo crítico del consenso y haría que al menos un tercio del total de ETH apostado fuera susceptible de ser recortado de forma demostrable y quemado de los validadores responsables, con la penalización exacta escalando en función del número de validadores recortados conjuntamente. Se trata de una garantía criptoeconómica, no de una afirmación de que el software, la gobernanza o la recuperación social sean metafísicamente incapaces de cambiar la historia.

Los sistemas de Capa 2 añaden más relojes

Una transacción en un rollup u otra Capa 2 puede ser aceptada por el secuenciador antes de que sus datos o su prueba se publiquen en la capa base. Los sistemas optimistas pueden tener períodos de impugnación; los sistemas de prueba de validez esperan a que se generen y verifiquen las pruebas; los puentes y las plataformas de intercambio pueden añadir sus propios umbrales. «Confirmado en la Capa 2» y «liquidado en Ethereum» no siempre son el mismo evento.

Conclusión: la finalidad depende de la red y del destinatario. El umbral correcto depende de la cadena, el valor de la transacción, el modelo de adversario y de si interviene otra capa de liquidación.

¿Dónde falla realmente la seguridad criptográfica?

El artículo original presentaba el protocolo como esencialmente inquebrantable y la capa de claves como el origen de casi todas las pérdidas. Eso es demasiado absoluto. Los principales esquemas de firma han resistido la falsificación en la práctica bajo los supuestos para los que fueron diseñados, y Bitcoin y Ethereum cuentan con un sólido historial de funcionamiento. Sin embargo, el software de blockchain ha adolecido de graves vulnerabilidades de consenso e inflación, las aplicaciones han perdido activos debido a fallos en contratos y puentes, los custodios han fallado y los usuarios han autorizado transacciones maliciosas.

Dónde están más expuestos los usuarios comunes

En el caso de la autocustodia simple, la ruta de firma suele ser el riesgo operativo decisivo: una frase de recuperación robada o una firma maliciosa pueden autorizar una transferencia válida que la cadena de bloques ejecuta exactamente según lo previsto. Sin embargo, en el ecosistema más amplio, las pérdidas también se deben a las plataformas de intercambio, los custodios, los contratos inteligentes, los puentes, los oráculos, la gobernanza y las vulnerabilidades operativas. Las medidas de seguridad deben ajustarse al sistema real que se utiliza, no a un eslogan.

La solidez es condicional, no mágica

Una red puede ser difícil de reescribir y, aun así, albergar un token fraudulento. Una transacción puede ser definitiva y, aun así, enviarse a una dirección errónea. Una cartera de hardware puede mantener la clave en secreto y, aun así, firmar un permiso malicioso. Un protocolo descentralizado puede depender de una interfaz centralizada o de un puente. La pregunta correcta es siempre: ¿qué propiedad está protegida frente a qué adversario, bajo qué supuestos?

¿Qué es lo que no garantiza una criptomoneda?

Conclusión: las cadenas de bloques son sistemas de verificación especializados. Su fortaleza proviene de reglas estrictas y explícitas; tratarlas como máquinas de verdad universales genera precisamente los malentendidos que aprovechan los atacantes.

¿Cómo se pueden custodiar las claves y los monederos?

Frases de recuperación y carteras determinísticas

Muchas carteras de autocustodia utilizan un diseño determinista jerárquico. Una frase al estilo BIP39 codifica la entropía y, junto con una frase de acceso opcional, deriva una semilla binaria a partir de la cual una cartera puede generar muchas claves privadas y direcciones. Por lo tanto, no se trata literalmente de «una clave privada escrita en forma de palabras». Los estándares de la cartera, las rutas de derivación y el uso de la frase de acceso deben coincidir durante la restauración.

Carteras de software y hardware de clave única

Una cartera de software almacena el material de firma en un dispositivo conectado a Internet o en un enclave protegido del sistema operativo. Una cartera de hardware aísla la firma en un dispositivo dedicado y puede reducir el riesgo de extracción. Ambas pueden fallar debido a copias de seguridad defectuosas, firmware o software malicioso, una revisión deficiente de las transacciones, un compromiso físico o un error del usuario.

Multifirma en cadena y cuentas inteligentes

Los scripts de multifirma y las cuentas de contratos inteligentes pueden requerir varias aprobaciones, imponer límites de gasto, añadir bloqueos temporales o admitir roles de recuperación. Sus reglas son visibles y se aplican en la cadena, pero la seguridad depende del código, la independencia de los firmantes, la autoridad para actualizar y el proceso de recuperación. La EIP-7702 de Ethereum amplía la capacidad de las EOA para utilizar código de monedero delegado sin cambiar de dirección, lo que aumenta tanto la capacidad como la complejidad de las políticas.

Criptografía de umbral y MPC

La firma por umbral distribuye la capacidad de generar una firma entre varias partes de la clave. En un ciclo de vida de generación de claves distribuida correctamente diseñado, la clave privada completa nunca tiene por qué existir en un único lugar. Esto puede reducir el riesgo de fallo de un único dispositivo, pero añade supuestos relativos al protocolo interactivo, al coordinador, a la implementación, a la disponibilidad y a la independencia de las partes. No se trata simplemente de «multifirma sin comisiones».

Preguntas que todo diseño de custodia debería responder

• ¿Qué firma, script o acción contractual concreta puede mover los activos?
• ¿Qué personas, dispositivos, servicios o rutas de código pueden cumplir con esa autoridad?
• ¿Qué ocurre si se roba un dispositivo, una persona no está disponible o falla un proveedor?
• ¿Qué ocurre si se filtra el material de recuperación pero aún no se ha firmado ninguna transacción?
• ¿Se puede limitar una transacción maliciosa por valor, destino, retraso temporal o revisión de políticas?
• ¿Cómo se regulan las actualizaciones de software, la sustitución de firmantes, la actualización de recursos compartidos y la respuesta ante emergencias?
• ¿Cómo recuperarán el acceso los herederos o sucesores autorizados sin proporcionar a una persona una vía permanente para el robo?
• ¿Se ha probado el proceso de recuperación con pequeñas cantidades antes de que sea necesario utilizarlo en una situación de presión?

Conclusión: La clave es uno de los componentes de un sistema de autorización y recuperación. Los buenos diseños de custodia resisten pérdidas previsibles, vulneraciones de seguridad y la indisponibilidad del personal sin facilitar el robo.

Preguntas frecuentes

¿Cómo funciona la criptomoneda en términos sencillos?

Un monedero crea y firma una transacción, unos nodos independientes la verifican, un minero o validador la incluye en un bloque, y las reglas de consenso determinan qué historial de bloques válido se convierte en canónico. Cuantos más bloques o votos de puntos de control haya, menor es la probabilidad de reversión hasta que el destinatario considere la transacción como liquidada.

¿Almacena realmente una cartera de criptomonedas las monedas?

Normalmente no. La cadena de bloques registra las salidas gastables, los saldos de las cuentas o el estado de los tokens. El monedero gestiona las direcciones, la construcción de las transacciones y las claves o políticas que pueden autorizar cambios en ese estado.

¿Es lo mismo una dirección de monedero que una clave pública?

No siempre. Una dirección EOA de Ethereum se deriva de una clave pública; una dirección de firmante estándar de Solana es la propia clave pública; las direcciones de Bitcoin pueden codificar hash de claves, scripts o claves de salida de Taproot; las direcciones derivadas de contratos y programas pueden existir sin una clave privada correspondiente.

¿Puede alguien robar mis criptomonedas solo a partir de mi dirección pública?

Una dirección pública normalmente no otorga autoridad para realizar gastos. Sin embargo, puede revelar saldos e historial de transacciones, atraer ataques de phishing o de «envenenamiento de direcciones», y ayudar a un atacante a identificar un objetivo valioso. El robo sigue requiriendo una vía de autorización válida, como una clave robada, una firma maliciosa, un error en un contrato o un custodio comprometido.

¿Se puede hackear la propia cadena de bloques?

La falsificación criptográfica y los ataques de consenso profundo son solo una parte del riesgo. Las principales redes cuentan con un sólido historial de seguridad, pero el software de cliente ha contenido errores críticos, se han explotado aplicaciones y puentes, y se ha comprometido a custodios y usuarios. La afirmación «la cadena de bloques ha sido hackeada» suele ser imprecisa; hay que identificar la capa concreta en la que se ha producido el fallo.

¿Son irreversibles las transacciones con criptomonedas?

Una transacción pendiente puede sustituirse o cancelarse en determinadas condiciones, y una transacción confirmada superficialmente puede eliminarse mediante una reorganización. Una vez superado un umbral de liquidación adecuado, la reversión del protocolo se vuelve extremadamente difícil, pero la recuperación de la cuenta, la cooperación del destinatario, la intervención del custodio o el embargo judicial aún pueden alterar el resultado práctico en algunos sistemas.

¿Cuánto tarda una transacción de criptomonedas?

Depende de la red, la comisión, la congestión, el enrutamiento y el umbral de liquidación. Bitcoin tiene como objetivo bloques de unos diez minutos; Ethereum utiliza intervalos de 12 segundos y normalmente alcanza la finalidad del punto de control tras unas dos épocas. Los sistemas de capa 2 y las plataformas de intercambio añaden sus propios tiempos de procesamiento.

¿Controlan la cadena de bloques los mineros o los validadores?

Influyen en la producción y el orden de los bloques, pero no tienen autoridad unilateral sobre la validez. Los nodos completos rechazan de forma independiente los bloques que infringen las reglas que ejecutan. La gobernanza sobre los cambios en las reglas se distribuye entre los mantenedores de software, los operadores de nodos, los proveedores de recursos, las aplicaciones, las empresas y los usuarios.

¿Qué ocurre si pierdo mi clave privada?

Si ninguna copia de seguridad, cofirmante, custodio o política de recuperación puede satisfacer la autoridad de la cuenta, los activos siguen registrados pero ya no se pueden gastar. Las cuentas inteligentes, los sistemas multisig y los sistemas de custodia pueden tener diferentes vías de recuperación; una dirección convencional de clave única no dispone de un restablecimiento de contraseña en la red.

¿Por qué varían las comisiones de las criptomonedas?

La demanda de capacidad de bloque o de ejecución, que es escasa, varía. Bitcoin puja por espacio virtual en los bloques; Ethereum fija el precio del gas mediante una tarifa base del protocolo y una tarifa de prioridad. Las dependencias, el orden de los nonces, el flujo de órdenes privadas, las estrategias de los constructores y la política local también influyen en la inclusión.

¿Son anónimas las criptomonedas?

Normalmente no. Muchas cadenas públicas son seudónimas: las direcciones son públicas y el historial de transacciones es permanente, mientras que los vínculos de identidad pueden deducirse a partir de las plataformas de intercambio, los datos de la red, las contrapartes y los patrones de comportamiento.

¿Qué significa «si no tienes tus claves, no tienes tus monedas»?

Significa que, cuando un custodio controla las claves en cadena, el cliente depende de que dicho custodio atienda las retiradas y se mantenga seguro y solvente. No significa que la autocustodia sea automáticamente segura; el control directo de las claves conlleva responsabilidades adicionales de copia de seguridad, firma y recuperación.

Conclusión

Las criptomonedas funcionan porque cooperan varios mecanismos específicos. Una política de firma convierte la autoridad en evidencia criptográfica verificable. Una transacción codifica un cambio de estado propuesto exacto. Los nodos verifican esa propuesta según reglas deterministas. Los productores de bloques ordenan las propuestas válidas, y el consenso determina qué historial válido sigue la red. Las reglas de liquidación indican entonces a los destinatarios cuándo el riesgo de reorganización es lo suficientemente bajo para el valor en juego.

El modelo mental más sólido no es que «las matemáticas sustituyan a la confianza». La confianza se redistribuye y se hace más explícita. Los usuarios confían en los supuestos criptográficos, las implementaciones de software, el hardware, la participación en la red, el código de los contratos inteligentes, las interfaces de los monederos y su propio diseño de recuperación. La verificación pública reduce la dependencia de un único encargado del registro; no elimina todas las dependencias ni todas las formas de gobernanza.

Por eso también los consejos de seguridad deben especificar la capa a la que se refieren. Proteger una frase de recuperación no equivale a auditar un puente. Esperar a la finalidad no hace que un token tenga valor. Un monedero de hardware no explica un permiso malicioso. Un conjunto de validadores descentralizado no garantiza una interfaz descentralizada. Las criptomonedas son poderosas precisamente porque sus garantías son específicas. Utiliza esas garantías donde sean aplicables y no las extiendas tácitamente a problemas para los que nunca fueron diseñadas.

Fuentes y lecturas recomendadas

Referencias clave para este artículo, actualizadas a julio de 2026.

• Bitcoin: un sistema de efectivo electrónico entre pares. https://bitcoin.org/bitcoin.pdf
• Guía para desarrolladores de Bitcoin: Transacciones. https://developer.bitcoin.org/devguide/transactions.html
• Guía para desarrolladores de Bitcoin: la cadena de bloques. https://developer.bitcoin.org/devguide/block_chain.html
• Guía para desarrolladores de Bitcoin: Minería. https://developer.bitcoin.org/devguide/mining.html
• BIP 340: Firmas de Schnorr para secp256k1. https://bips.dev/340/
• BIP 341 - Taproot. https://bips.dev/341/
• Ethereum.org - Cuentas. https://ethereum.org/developers/docs/accounts/
• Ethereum.org - Transacciones. https://ethereum.org/developers/docs/transactions/
• Ethereum.org - Gas y comisiones. https://ethereum.org/developers/docs/gas/
• Ethereum.org - Mecanismos de consenso. https://ethereum.org/developers/docs/consensus-mechanisms/
• Ethereum.org - Prueba de participación. https://ethereum.org/developers/docs/consensus-mechanisms/pos/
• Ethereum.org - Gasper. https://ethereum.org/developers/docs/consensus-mechanisms/pos/gasper/