Saltar al contenido
Financial Context Wiki

Blockchain: Estado, Consenso y Verificación

Una cadena de bloques es un protocolo versionado para ordenar y validar transiciones de estado entre réplicas. Los enlaces hash son sólo un componente; la confianza depende del consenso, los permisos, la verificación independiente, la disponibilidad de datos, la gobernanza y la recuperación.

Actualizado

Solo con fines educativos; no constituye asesoramiento de inversión. Invertir puede ocasionar pérdidas.

Respuesta directa

Una cadena de bloques es un protocolo versionado que permite que múltiples réplicas ordenen las transacciones propuestas, validen las transiciones de estado y converjan en un historial aceptado bajo consensos establecidos y supuestos de red. Un bloque es un contenedor definido por protocolo con transacciones u otros datos más compromisos con el historial anterior y el estado resultante; la cadena o historial dirigido vincula los contenedores aceptados a través de compromisos criptográficos.

Los enlaces hash hacen detectables los cambios históricos no autorizados, pero no hacen que un sistema sea descentralizado, inmutable o correcto de forma independiente. Esas propiedades dependen de quién puede proponer y validar, si los usuarios pueden verificar de forma independiente, las reglas de elección y finalidad de la bifurcación, la disponibilidad de datos, la diversidad de clientes, la gobernanza, el control de claves, los incentivos y los procedimientos de recuperación.

Las cadenas de bloques pueden utilizar UTXO, cuentas, objetos o modelos de estado específicos de aplicaciones; prueba de trabajo, prueba de participación, votación bizantina tolerante a fallas o consenso permitido; y finalidad probabilística o basada en puntos de control. Por lo tanto, la palabra “blockchain” nombra una amplia familia de arquitectura, no una garantía de seguridad o un producto de base de datos.

1
Crear

La billetera construye una transacción con destino, valor, comisiones y datos contra repetición, como entradas gastadas o un nonce.

Cómo funciona

  1. Fije la cadena, la red, la versión del protocolo, el modelo de permisos, el modelo de estado y la afirmación que se está comprobando. Registre el bloque génesis o punto de control de confianza, el identificador de cadena, la implementación del cliente y la autoridad de actualización.
  2. Construya los bytes exactos de la transacción y su autorización. Antes de difundirla, verifique la propiedad del remitente o de las entradas, el nonce o las referencias a salidas no gastadas, el importe, el destino, los límites de comisión, la ventana de validez, las firmas y las llamadas a la aplicación.
  3. Propague la transacción entre pares o pasarelas. Distinga la política local de admisión y del mempool de la validez por consenso; un nodo puede rechazar, retrasar, sustituir o no recibir nunca una transacción que sería válida en un bloque.
  4. Un proponente selecciona y ordena transacciones en un bloque candidato y se compromete con campos del protocolo como el bloque padre y las raíces de transacciones, recibos, estado o datos. El orden puede afectar los resultados de ejecución, las comisiones, las liquidaciones y el valor extraíble.
  5. Los nodos independientes deserializan el bloque, verifican la autorización de consenso y cada transición de estado requerida, vuelven a calcular los compromisos y rechazan las entradas no válidas o no disponibles de acuerdo con sus reglas. Las firmas del productor o la prueba de trabajo no anulan la validación fallida.
  6. La elección de la bifurcación selecciona entre historias válidas en competencia, mientras que las confirmaciones, los votos o los puntos de control cambian el riesgo de reorganización con el tiempo. “Incluido”, “seguro” y “finalizado” son estados diferentes y siguen siendo específicos del protocolo.
  7. Concilie el estado del protocolo con la intención de la aplicación, la custodia, la contabilidad del puente o de la plataforma y los requisitos de archivo. Conserve los bytes de la transacción, el hash del bloque, la altura o ranura, el recibo, los registros, la prueba de estado, el estado de finalidad, la versión del cliente y evidencia obtenida de un punto de acceso independiente.

Ejemplos resueltos

  • Conciliación del estado de una cuenta. Una cuenta comienza con 10 ETH y nonce 41. Una transacción válida con nonce 41 transfiere 2 ETH y consume 0.00042 ETH en comisiones, por lo que el estado posterior simplificado es 10 - 2 - 0.00042 = 7.99958 ETH, el destinatario recibe 2 ETH y el nonce del remitente pasa a 42. Una firma válida por sí sola no demostraría el saldo anterior ni la ejecución correcta.
  • Conservación UTXO. Una transacción gasta entradas de 0.80 BTC y 0.35 BTC, por un total de 1.15 BTC. Las salidas de 1.00 BTC y 0.1496 BTC totalizan 1.1496 BTC; la diferencia es 1.15 - 1.1496 = 0.0004 BTC en comisiones. Los nodos también deben verificar que cada salida referenciada exista, siga sin gastarse y satisfaga sus condiciones de gasto.
  • Tamaño de prueba de compromiso. En un árbol Merkle binario equilibrado ilustrativo con 8 leaves, una ruta de inclusión necesita log2(8) = 3 sibling hashes. Con hashes 256-bit = 32-byte, esos hermanos ocupan 3 * 32 = 96 bytes antes de los índices y la codificación. La prueba vincula una hoja a una raíz reivindicada; no prueba que los datos fuente sean veraces o estén actualmente disponibles.
  • El peso no es el recuento de nodos. En un protocolo de votación ilustrativo cuya regla de finalidad establecida es >= 2/3 de peso, los validadores mantienen 30%, 25%, 20%, 15%, 10%. Los primeros tres suman 30 + 25 + 20 = 75% y cruzan la regla, mientras que los dos primeros suman 55% y no lo hacen. Los umbrales reales, las reglas de correlación, equívoco y recuperación deben provenir del protocolo nombrado.

Riesgos

  • Usar la cadena, red, bifurcación, punto de control o identificador de cadena incorrectos.
  • Tratar una marca como un protocolo completo o una especificación de modelo de confianza.
  • Asumir únicamente el enlace hash evita las reescrituras autorizadas o aprobadas por consenso.
  • Confundir la propuesta de bloque de un productor con la validación de un nodo independiente.
  • Tratar la aceptación, difusión, inclusión, éxito de ejecución y finalidad de Mempool como un solo estado.
  • Firma de bytes, dominios o destinos diferentes a lo que muestra la interfaz.
  • Reutilizar nonces, gastar UTXO obsoletos o calcular mal tarifas y cambios.
  • Confiar en símbolos de token, etiquetas, eventos o interpretaciones del explorador en lugar de identificadores de protocolo y estado.
  • Tratar las entradas de documentos, puentes o oráculos firmados como prueba de que las afirmaciones fuera de la cadena son ciertas.
  • Ignorar el ordenamiento de transacciones, la censura, el front-running y la concentración de proponentes o constructores.
  • Contar nodos o validadores sin resolver operadores, pesos e infraestructura comunes.
  • Ignorar la concentración de clientes, nube, geografía, gobernanza, claves y cadena de suministro de software.
  • Suponer que todos los modelos de consenso tienen los mismos umbrales de falla o semántica de finalidad.
  • Ignorar particiones, demoras en la firmeza, reorganizaciones, equívocos y procedimientos de recuperación.
  • Aceptar encabezados de bloque o pruebas sin los supuestos requeridos de disponibilidad de datos.
  • Dependiendo de un RPC, explorador, billetera, indexador o plataforma de custodia como fuente de verdad.
  • Confundir posesión o control protocolario con título, recurso o recuperabilidad legal.
  • Subestimar el crecimiento del estado, la pérdida de archivos, el costo de sincronización y las barreras de hardware.
  • Ignorar claves de actualización, pausas de emergencia, recuperación social y bifurcaciones polémicas.
  • Inferir privacidad, escalabilidad, valor de inversión o seguridad de aplicaciones a partir de la etiqueta blockchain.

Errores comunes

  • Cada blockchain es descentralizada e inmutable. El permiso, la independencia del operador, la elección de la bifurcación, la gobernanza y la recuperación determinan quién puede cambiar o rechazar la historia.
  • Los datos registrados en la cadena deben ser verdaderos. El consenso puede acordar registrar fielmente un precio falso, un documento falsificado o una entrada de aplicación maliciosa.
  • Una transacción válida demuestra el resultado deseado. Puede apuntar a la dirección incorrecta, revertir después de consumir tarifas, emitir eventos engañosos o depender de pasos posteriores de puente y custodia.
  • Más réplicas siempre mejoran la seguridad. Las réplicas bajo un mismo operador, cliente, nube o clave pueden fallar juntas y es posible que no proporcionen una verificación independiente.
  • Una cadena de bloques siempre es mejor que una base de datos convencional. Un operador confiable, una eliminación requerida, un alto rendimiento o una simple resolución de disputas pueden hacer que un sistema convencional sea más apropiado.

Temas relacionados

Fuentes autorizadas

Navegación

Buscar en la wiki...