Las segundas capas suelen presentarse como una versión más barata de la cadena de abajo, lo cual es cierto e inútil. La pregunta interesante es qué hacen distinto para ser más baratas, porque cada una de esas diferencias es también la fuente de un riesgo que no existe en la cadena base. Las comisiones son más bajas por razones, y son las razones lo que interesa.
Una cadena de bloques es cara porque cada participante verifica cada transacción y conserva el resultado para siempre. Esa redundancia es la seguridad, y también es el techo de coste: ninguna cantidad de ingeniería elimina el hecho de que miles de máquinas hacen el mismo trabajo.
Una segunda capa hace el trabajo una vez, en otro sitio, y luego inscribe en la cadena base un registro comprimido de lo ocurrido. La cadena base ya no ejecuta cada transacción; almacena información suficiente para que el resultado pueda reconstruirse o disputarse. Ese es todo el truco, y el ahorro es proporcional a lo que se deja fuera.
Eso convierte a la cadena base en una capa de liquidación en vez de una capa de ejecución, lo que es un cambio arquitectónico real y no un parche de escalado. También significa que las garantías que obtiene un usuario ya no son directamente las de la cadena base, sino lo que el mecanismo que une ambas logra preservar. Casi todas las diferencias prácticas se derivan de esa frase.
La cadena base deja de ejecutar su transacción y pasa a registrar que ocurrió. Todo lo que una segunda capa gana y todo lo que arriesga viene de esa sustitución.
La primera familia publica los datos de transacción y supone el resultado correcto mientras nadie pruebe lo contrario dentro de una ventana de impugnación. Cualquiera puede presentar la prueba de que un estado publicado es falso, y si nadie lo hace durante la ventana, el estado se trata como definitivo.
La segunda familia publica una prueba criptográfica de que el cálculo se realizó correctamente, que la cadena base verifica directamente. No hay nada que impugnar, ya que la corrección se demuestra en lugar de suponerse, y el carácter definitivo llega en cuanto la prueba se verifica.
El arbitraje se juega entre supuestos y coste. La primera familia es más barata de explotar y hereda un retraso más la exigencia de que alguien vigile y pueda impugnar. La segunda elimina el retraso y al vigilante, y lo paga con el coste de cómputo de producir pruebas, que ha bajado mucho y sigue siendo la restricción que limita lo que estos sistemas saben ejecutar.
El ahorro viene de dos sitios y conviene separarlos. La ejecución se hace una vez en la capa en lugar de hacerse en cada nodo de la cadena base, lo que retira la mayor parte del cómputo. Esa parte es sencilla, y es donde se detienen la mayoría de las explicaciones.
La segunda, mayor, es la amortización. El registro escrito en la cadena base cubre muchas transacciones a la vez, así que ese coste se reparte entre todos los del lote. Una capa concurrida tiene por tanto un coste por transacción más bajo que una tranquila, lo que es lo contrario de la intuición de que la congestión encarece las cosas.
La consecuencia práctica es que la comisión de una capa no es una propiedad fija de esa capa. Se mueve con la congestión de la cadena base, con lo llenos que estén los lotes, y con cuántos datos elige publicar la capa en lugar de conservarlos. Una comisión observada hoy describe hoy, y comparar capas con una sola observación compara dos instantes en vez de dos sistemas.
Alguien tiene que decidir el orden en que se ejecutan las transacciones antes de que el lote se inscriba, y en casi todas las segundas capas desplegadas hoy ese alguien es un operador único gestionado por el equipo que construyó la capa. Es la parte que más contradice la imagen mental de un sistema descentralizado.
Lo que un secuenciador único puede hacer es limitado pero real. Puede decidir el orden, lo que importa allí donde el orden tiene valor. Puede negarse a incluir una transacción, lo que es censura en el sentido técnico estrecho. Lo que en general no puede hacer es robar, porque las transiciones de estado deben seguir siendo válidas, y una inválida queda refutada o es imposible de probar según la familia.
La mayoría de los diseños prevé una salida de emergencia: una forma de enviar una transacción directamente a la cadena base y forzar su inclusión si el secuenciador se niega. Vale la pena saber si la capa que usa tiene una y si alguna vez se ha usado, porque un mecanismo que nunca se ha empleado de verdad es un diseño, no una garantía.
En la primera familia, la ventana de impugnación tiene que ser lo bastante larga para que una parte honesta note un estado falso y presente una prueba, incluso durante un periodo de congestión de la cadena base. Por eso los plazos de retirada se cuentan en días y no en minutos, y esa duración es un parámetro de seguridad, no una ineficiencia.
El plazo se aplica a la salida sin confianza, no a todas las salidas. Servicios de terceros le adelantan los fondos en la cadena base de inmediato y esperan la ventana por usted, cobrando el servicio y el capital. Es un producto útil que sustituye una garantía de protocolo por una contraparte, lo que es un riesgo distinto y no una ausencia de riesgo.
En la segunda familia el plazo es corto porque no hay nada que impugnar, sin ser instantáneo: hay que producir y verificar una prueba, y producirla lleva tiempo real y cómputo real. La brecha entre ambas familias en este punto concreto es la diferencia más visible para un usuario.
La fórmula se usa de forma laxa y tiene un sentido preciso. Lo que la cadena base asegura es que la capa no puede hacer definitiva una transición de estado inválida: no puede abonarle tokens que nunca se depositaron, ni dejar que alguien gaste lo que no tiene. Es una garantía fuerte y genuina.
Lo que no asegura es todo lo que queda fuera de esa definición. No garantiza que su transacción se incluya, que se incluya en el orden que preferiría, que los contratos de la capa estén libres de defectos, ni que el operador siga prestando el servicio. Cada uno de estos puntos ha fallado en la práctica en algún sitio sin que ningún estado inválido llegara a ser definitivo.
El resumen honesto es que la cadena base asegura la contabilidad y no el servicio. Esa es la distinción que hay que retener, porque explica que una capa pueda ser a la vez correcta e inutilizable, y por qué una caída en una capa es un suceso real aunque nadie pierda un saldo.
La cadena base asegura la contabilidad, no el servicio. Una capa puede ser perfectamente correcta y completamente inutilizable al mismo tiempo, y ambas cosas han ocurrido.
Cada capa es un entorno separado, con su propia copia de los activos y sus propias reservas. El mismo activo en dos capas son dos saldos distintos que comparten un nombre, y pasar de uno a otro supone un puente, con todos los modos de fallo que los puentes tienen.
Para quien opera, la consecuencia es que la profundidad queda dividida. Un activo con liquidez agregada sustancial puede estar fino en la capa concreta en la que está, y el precio que obtiene refleja la reserva que alcanzó y no el mercado en conjunto. Esa brecha es mayor exactamente cuando más importa, durante los movimientos rápidos.
También complica la aritmética del coste. Una transacción más barata en una capa con menos profundidad puede costar más en total que una transacción más cara donde está la profundidad, una vez contado el precio realmente obtenido. Comparar solo la comisión es el error, y es el error que fomenta el marketing de todas las capas.
Publicar todos los datos de transacción en la cadena base es lo que permite a cualquiera reconstruir el estado de forma independiente, y es también el mayor coste restante. Algunos sistemas lo reducen guardando los datos en otro sitio y publicando solo un compromiso sobre ellos, lo que es bastante más barato.
Esa elección cambia el modelo de seguridad en lugar de optimizarlo. Si los datos no están disponibles, el estado no puede ser reconstruido por un tercero, y los usuarios dependen de un comité o de una red separada para seguir sirviéndolos. Estos sistemas suelen llevar un nombre distinto por exactamente esa razón, y el nombre hace un trabajo real.
Que el intercambio sea aceptable depende de qué se guarda y durante cuánto tiempo. Es una elección defendible para actividad de mucho volumen y poco valor, y mala para saldos que alguien piensa dejar tranquilos un año. El error no es hacer el intercambio, es no saber cuál se hizo.
Cuatro puntos describen la situación con más utilidad que cualquier comparación de marcas. Si el secuenciador es un operador único y si existe una vía de inclusión forzada. Si los datos de transacción van a la cadena base o a otro sitio. Cuánto tarda una salida sin confianza. Y si los contratos pueden actualizarse, por quién, y con qué plazo.
El último está infravalorado. Muchas capas pueden actualizarse mediante una cartera de firmas múltiples, a veces con un bloqueo temporal y a veces sin él, y un contrato modificable que guarda su depósito es otro objeto distinto de uno inmutable. La existencia de una vía de actualización no descalifica; su ausencia en una descripción de seguridad sí.
Ninguno de estos puntos exige fiarse de un resumen. Los cuatro están publicados, los cuatro son verificables, y leerlos lleva menos tiempo que la primera operación que coloque. Un trader capaz de responder a los cuatro toma una decisión; quien no puede acepta las respuestas que resulten aplicarse.
La descentralización del secuenciador es el problema de ingeniería abierto, y existen varios diseños sin consenso establecido sobre cuál aguanta a escala. La dificultad es que el orden tiene valor, así que distribuir el derecho a ordenar es también distribuir un ingreso, y los mecanismos que lo hacen bien sin introducir nuevos retrasos siguen a prueba.
La interoperabilidad entre capas es el segundo. Pasar de una capa a otra supone hoy volver a la cadena base o confiar en un puente, y los estándares que permitirían a las capas liquidar directamente entre sí aún no están extendidos. Mientras no lo estén, la fragmentación descrita arriba es un rasgo estructural y no una enfermedad de juventud.
Ninguno de los dos es una predicción sobre lo que ocurrirá. Es la descripción de lo que no está resuelto, lo que resulta más útil, porque dice qué afirmaciones leer con escepticismo hoy. A una capa que dice haber resuelto alguno de los dos hay que preguntarle cómo, y la respuesta suele ser concreta y comprobable.
Dos razones. La ejecución ocurre una vez en la capa en lugar de en cada nodo de la cadena base, y el registro escrito en la cadena base cubre muchas transacciones a la vez, así que ese coste se reparte en el lote. El segundo efecto hace que una capa concurrida tenga un coste por transacción más bajo que una tranquila.
Una publica los datos de transacción y supone el resultado correcto mientras nadie pruebe lo contrario dentro de una ventana de impugnación. La otra publica una prueba criptográfica que la cadena base verifica directamente, así que no hay nada que impugnar. La primera hereda un retraso y necesita un vigilante; la segunda paga en coste de producir pruebas.
En casi todas las capas desplegadas hoy, un operador único gestionado por el equipo que la construyó. Puede decidir el orden y negarse a incluir una transacción, pero en general no puede robar, porque las transiciones de estado deben seguir siendo válidas. La mayoría de los diseños prevé forzar la inclusión por la cadena base.
En la familia basada en impugnación, la ventana debe ser lo bastante larga para que una parte honesta note un estado falso y lo pruebe, incluso durante congestión de la cadena base. Es un parámetro de seguridad, no una ineficiencia. Servicios de terceros adelantan los fondos de inmediato por una tarifa, lo que sustituye una garantía de protocolo por una contraparte.
Que la capa no puede hacer definitiva una transición de estado inválida: nada de abonar tokens nunca depositados ni gastar lo que no existe. No garantiza que su transacción se incluya, que los contratos de la capa carezcan de defectos, ni que el operador siga. La cadena base asegura la contabilidad, no el servicio.
No. Son dos saldos separados que comparten un nombre, cada uno con sus reservas, y pasar de uno a otro exige un puente. La profundidad queda dividida, así que un activo líquido en agregado puede estar fino en la capa en la que está, y esa brecha es mayor durante los movimientos rápidos.
Publicar todos los datos de transacción en la cadena base permite a cualquiera reconstruir el estado de forma independiente. Los sistemas que publican solo un compromiso y guardan los datos en otro sitio son más baratos, pero los usuarios dependen entonces de un comité o red separada para servirlos. Suelen llevar otro nombre, y ese nombre hace un trabajo real.
Si el secuenciador es un operador único y si existe inclusión forzada; si los datos de transacción van a la cadena base o a otro sitio; cuánto tarda una salida sin confianza; y si los contratos pueden actualizarse, por quién y con qué plazo. Los cuatro están publicados y son verificables.