Saltar al contenido
Financial Context Wiki

Blockchain sin permisos

Una blockchain sin permisos elimina la aprobación previa de identidad para acciones concretas del protocolo, pero la elegibilidad, el acceso práctico, la influencia, la privacidad y la gobernanza de las aplicaciones deben evaluarse por separado.

Actualizado

Solo con fines educativos; no constituye asesoramiento ni recomendación de inversión. Las inversiones pueden ocasionar pérdidas.

Respuesta directa

Una blockchain sin permisos permite que un actor realice acciones concretas del protocolo sin aprobación previa de identidad por un administrador o consorcio. La etiqueta debe indicar la acción: leer el estado público, enviar una transacción, ejecutar un nodo que valide de forma independiente, descubrir pares, proponer un bloque, activar stake, desplegar código, presentar una prueba o impugnación y cambiar la gobernanza pueden tener reglas distintas.

La elegibilidad sin permisos no significa acceso gratuito, anónimo, igualmente influyente ni garantizado. Comisiones, saldos, stake, fianzas, hardware, ancho de banda, datos, disponibilidad, conocimientos, colas de activación y plazos son condiciones operativas o del protocolo, no listas blancas de identidad. RPC, frontends, builders, relays, pools de staking, secuenciadores, puentes, oráculos, administradores de contratos y gobernanza aún pueden imponer barreras prácticas o explícitas.

Cómo funciona

  1. Fije cadena, red, fork, despliegue, versión, actor y acción. Construya una matriz de permisos para lectura, envío de transacciones, validación local, descubrimiento de pares, propuesta de bloques, staking o minería, pruebas o impugnaciones, despliegue de código y gobierno de actualizaciones.
  2. Verifique la vía de lectura y validación. Distinga cliente completo o ligero de RPC o indexador, estado actual de historial archivado y disponibilidad del protocolo de retención, autenticación, límites y privacidad del proveedor.
  3. Siga el acceso de una transacción desde firma, fondos, nonce, gas y topes de comisión hasta admisión local, relay, selección por builder o proposer, inclusión, ejecución, fork choice, justificación y finalidad. Validez o acuse de un RPC no garantiza estados posteriores.
  4. Separe operación del nodo e influencia en consenso. Mapee clientes de ejecución y consenso, sincronización, almacenamiento, banda, descubrimiento y resistencia a eclipse; después, trabajo, stake, activación, claves, disponibilidad y slashing específicos para producir bloques.
  5. Mida concentración práctica en pools mineros o de staking, operadores, clientes, nubes, RPC, builders, relays y rutas privadas. La resistencia Sybil vincula influencia a un recurso escaso; no impide crear identidades baratas.
  6. Audite cada aplicación y dependencia de escalado. Desplegar contratos sin permiso no elimina owner, proxy, roles, pausa o allowlist. Pruebas, impugnaciones, secuenciadores, disponibilidad de datos, puentes y oráculos pueden tener fianzas, ventanas, claves o actores autorizados.
  7. Mapee gobernanza del protocolo, cliente y aplicación, poderes de emergencia y adopción de actualizaciones. Supervise inclusión, finalidad, concentración, fallos de acceso y privacidad; mantenga rutas propias o diversificadas cuando sea viable sin afirmar que son gratuitas o inmunes a censura.

Use la matriz de permisos, no una etiqueta binaria. Una red puede publicar estado y aceptar transacciones firmadas mientras restringe la producción de bloques; una capa base sin permisos puede alojar una aplicación con allowlist y administrador de upgrades. A la inversa, una red autorizada puede publicar datos verificables sin abrir membresía ni producción.

Público no significa privado. Las direcciones son seudónimas, mientras ledger, consultas RPC, conexiones, IP, tiempos y fondos pueden vincular actividad. Validación open source tampoco crea acuerdo instantáneo: aceptación local, propagación, inclusión, ejecución exitosa, fork choice canónico y finalidad son distintos.

Ejemplos

  • El acceso a transacciones conserva una barrera de comisión. Para gasUsed = 21,000, baseFee = 20 gwei, priorityFee = 2 gwei y maxFee = 30 gwei, el precio efectivo es min(30, 20 + 2) = 22 gwei. La comisión es 21,000 * 22 = 462,000 gwei = 0.000462 ETH. A 3,000 USD/ETH, son 1.386 USD. No se exige identidad, pero sí fondos y admisión local.
  • Validar no permite proponer bloques a voluntad. En un modelo proporcional didáctico con 3,200 ETH de stake efectivo activo, un operador con 64 ETH posee 64 / 3,200 = 2%. En 10,000 slots, las propuestas esperadas son 10,000 * 2% = 200; un nodo completo sin validator activado tiene peso de propuesta 0. Selección y recompensas reales siguen el protocolo desplegado.
  • Varias URL pueden compartir un dominio de fallo. Un frontend enumera 4 RPC URLs, pero 3 pertenecen a un operador y 1 es independiente. Las cuotas son 75% y 25%; el índice Herfindahl-Hirschman es 0.75^2 + 0.25^2 = 0.625 = 6,250. El protocolo puede ser abierto y la entrada de la aplicación concentrada.
  • Las identidades Sybil no crean peso de consenso gratis. Crear 1,000 P2P identities puede ser barato. Activar 1,000 Ethereum validator keys al mínimo indicado de 32 ETH exige 1,000 * 32 = 32,000 ETH, antes de colas, hardware y operación. El número de nodos no sustituye al peso de stake ni al control independiente.

Riesgos

  • Aplicar una etiqueta sin permisos a todas las acciones.
  • Cadena, red, fork, despliegue o reglas equivocados.
  • Autenticación, límites, censura, caída o estado obsoleto del RPC.
  • Restricciones de frontend, dominio, wallet, app store o geografía.
  • Política local del mempool rechaza o expulsa una transacción válida.
  • Tope de comisión, saldo, nonce, gas o calldata bloquea el envío.
  • Censura, poder de ordenación y MEV de builder o proposer.
  • Concentración o fallo de relay, builder u order flow privado.
  • Barreras de capital, activación, hardware y operación de validator.
  • Concentración de pool minero o de staking, custodio y operador.
  • Monocultura de cliente y fallos correlacionados.
  • Barreras de almacenamiento, banda, sincronización, historial y datos.
  • Bootnode, DNS, NAT, scoring, eclipse, Sybil y DoS de recursos.
  • Desanonimización por ledger, RPC, IP, tiempos, fondos y grafo.
  • Controles de owner, proxy, roles, pausa o allowlist del contrato.
  • Dependencias de oráculo, secuenciador, puente, DA o multisig.
  • Fallo de fianza, ventana, datos, cómputo o permiso de prueba o desafío.
  • Confundir aceptación, difusión, inclusión, validez y finalidad.
  • Mezclar gobernanza del protocolo, adopción de clientes y gobernanza de aplicación.
  • Restricciones legales, geográficas, ISP, cloud y suministro de hardware.

Errores comunes

  • Sin permisos significa gratis, inmediato e inclusión garantizada. Elimina una aprobación concreta; persisten límites económicos, técnicos y de ordenación.
  • Quien ejecuta un nodo puede proponer bloques a voluntad. Validación independiente y selección de autor son roles separados.
  • Elegibilidad implica participación fácil e igual influencia. Costes y poder ponderado por recursos pueden diferir mucho.
  • Público o seudónimo significa privado o anónimo. Metadatos onchain y de infraestructura pueden identificar patrones y actores.
  • Una capa base sin permisos hace toda aplicación igual. Contratos, rollups, puentes, frontends y gobernanza conservan controles propios.

Temas relacionados

Fuentes

Navegación

Buscar en la wiki...