La escalabilidad en la blockchain está determinada por la velocidad de procesamiento de transacciones por segundo (TPS) y el costo de las mismas (tarifa de red).
El procesamiento de transacciones de la primera capa (L1) tiene limitación en la cantidad de recursos escasos, es decir su escalabilidad, impidiendo el crecimiento del ecosistema.
La primera capa es lo que llamamos blockchain, que es la red más segura y descentralizada, pero con menor rendimiento.
Si no se va a sacrificar la descentralización, el rendimiento nunca será suficiente para permitir que un gran número de personas utilice una red distribuida consensuada.
La L2 está diseñada para escalar, haciendo que las transacciones sean rápidas y económicas. Es casi como una red paralela.
¿Qué es Arbitrum?
Arbitrum, con su protocolo ArbOS que corre en la blockchain de Ethereum, permite mover la ejecución de contratos inteligentes fuera de la L1, de tal manera que los participantes pueden confiar en algunos validadores elegidos (también conocidos como gerentes).
En una red como Ethereum, que se basa en PoW, esto es sumamente importante ya que ejecutar contratos es costoso y requiere muchos recursos. Eso significa menos recursos para minar bloques. Por lo tanto, los validadores carecen de incentivos para validar transacciones costosas a expensas de la producción de bloques.
Al mover cálculos costosos fuera de la cadena principal y al mantener solo transiciones de estado baratas en la L1, Arbitrum puede aliviar la red en un factor importante: vuelve a validar solo transacciones básicas.
Para aprovechar las transacciones rápidas y las tarifas bajas de Arbitrum, un usuario de Ethereum debe enviar su token ETH o ERC20 al contrato de depósito de Arbitrum. Una vez que se confirma la transacción de depósito, el usuario puede acceder a sus monedas desde el ecosistema de Arbitrum.
Es importante diferenciar entre el ecosistema Arbitrum y Ethereum. Los proyectos que se ejecutan actualmente en Ethereum no se incluyen automáticamente en Arbitrum. Los desarrolladores tienen que construir su aplicación en Arbitrum si quieren que funcione allí.
Además, lo hace al proporcionar incentivos para que los gerentes de Arbitrum se comporten con honestidad de tal manera que sea suficiente tener al menos un gerente honesto (¡y disponible!) para que un contrato tenga un progreso legítimo.
Ten en cuenta que Arbitrum no libera realmente a la red del tráfico diario per se, ya que cualquier transición de los contratos aún debe publicarse en la cadena, y el establecimiento de una máquina virtual Arbitrum (A-VM) también requiere transacciones.
Sin embargo, logra su propósito, ya que reduce drásticamente la complejidad de la red L1 sin comprometer demasiado
¿Qué es Hydra?
Hydra utiliza canales de estado, que amplía el concepto de canales de pago, ya que tiene funcionalidad de programación. Las partes mantienen canales de estado, que pueden acordarse sin interacción con la primera capa.
Entonces Hydra no solo trata la transferencia de fondos, sino también la ejecución de contratos inteligentes. Por ejemplo, es posible crear un contrato inteligente en la primera capa, y transferirlo a la cabeza de Hydra donde se puede ejecutar.
Con Hydra, el canal es multipartito, isomórfico y viene con una gran seguridad.
El canal multipartito es una relación entre 2 o más participantes.
El “isomorfismo” significa que las transacciones que se ejecutan en una cabeza se pueden asignar a transacciones L1 y viceversa.
Eso es diferente de Arbitrum, ya que requiere que los contratos de Solidity se vuelvan a compilar en el código de bytes de Arbitrum Virtual Machine. Y tal VM es “sólo” capaz de ejecutar contratos.
Una cabeza de Hydra, por el contrario, puede procesar transacciones de Cardano en toda regla, con activos nativos, metadatos, scripts y demás.
Significa que los jefes de Hydra pueden aprovechar las reglas de libro mayor probadas en la L1, lo que brinda sólidas garantías de corrección. Además, facilita enormemente la interoperabilidad y el mantenimiento de la L2 a medida que cambia la L1.
Una cabeza es como una mini cadena de bloques, con un consenso más rápido.
Con una máquina virtual y un compilador dedicados creados desde cero, Arbitrum aborda un desafío arriesgado para un sistema financiero. Seguramente el equipo ha probado exhaustivamente sus componentes, pero dado el historial de fallas previas de contratos inteligentes en el espacio, la probabilidad de errores, permanece.
De hecho, Arbitrum realmente solo mueve las ejecuciones de contratos en la L2 (pero no el tráfico), mientras que Hydra mueve el tráfico real fuera de la L1. La ejecución del contrato en Arbitrum no será más rápida que en L1, y las transiciones aún están sujetas a los tiempos de liquidación de L1.
En una cabeza de Hydra, las transacciones se liquidan mucho más rápido que en la L1 subyacente.
Los canales de estado son generalmente malos para las plataformas con un estado global como Ethereum, porque en caso de disputa, todo el estado del canal debe estar en cadena para su verificación. No es el caso en Hydra.
En primer lugar, gracias al modelo eUTxO, no existe un estado global mutable que modifiquen los contratos. En Cardano, solo hay validadores estáticos que operan en eUTxO, esto significa que los scripts de Cardano se pueden validar de forma aislada.
En segundo lugar, una cabeza de Hydra solo avanza si todos los participantes han acordado explícitamente el progreso, no se puede mover dinero que no se ha acordado mover. Las disputas en Hydra se pueden resolver de manera totalmente automática y no hay necesidad de inflar la L1 con grandes volcados de estado.
En Arbitrum, la resolución de disputas está más involucrada. Debido a que el estado de la VM puede ser avanzado por cualquiera de los administradores de VM, una disputa requiere la mediación de la capa 1 y varios pasos para determinar quién es honesto.
En el lado positivo, una máquina virtual puede progresar con un solo nodo honesto.
Como dije, el objetivo principal de Arbitrum es aliviar la L1 de las costosas ejecuciones de contratos. Esto viene a eludir un problema conocido como “El dilema del verificador”: verificar los contratos requiere muchos recursos y los validadores pueden no tener un incentivo fuerte para verificar los contratos. Por lo tanto, esto puede conducir a ataques en los que los atacantes envían transacciones contractuales arbitrariamente complejas para mantener a otros validadores innecesariamente ocupados y, mientras tanto, obtener una ventaja en los bloques de minería.
¿Cómo maneja Cardano eso?
- Prueba de participación
- Garantías
Alonzo amplía las transacciones para incluir un nuevo componente llamado “insumos colaterales” (o simplemente, colaterales). Estas son entradas especiales que los pools pueden recopilar en caso de que se les proporcione una transacción con scripts que no se validan para compensar los recursos involucrados.
Si bien esto puede sonar un poco aterrador, recuerda que los scripts de Cardano se pueden validar completamente de forma estática, incluso antes de enviarse a la red. Por lo tanto, en la práctica, las billeteras con buen diseño no publicarán transacciones con scripts defectuosos y los atacantes serán castigados financieramente.
Palabras Finales
Para concluir, ambas soluciones son bastante diferentes porque también abordan problemas diferentes.
Hydra es una buena opción para transacciones baratas fuera de la red, mientras que Arbitrum realmente es una forma de mover la ejecución de contratos fuera de la capa 1.
Si bien los canales de estado son fuertemente criticados en el espacio PoW, sus compensaciones en las tierras PoS son bastante diferentes, y con Hydra, los investigadores encontraron un punto óptimo entre simplicidad, eficiencia y sólidas garantías de seguridad, y se adapta muy bien al modelo UTXO.
Las cabezas Hydra son solo un primer paso en la hoja de ruta de escalabilidad de Cardano, necesaria si queremos que el ecosistema crezca.
