Casi hasta el final entendí que Babylon no estaba haciendo tres productos, sino el mismo problema de economía: resolvérselo de tres maneras en tres lugares.
Durante un tiempo creí que las tres capas del protocolo de Babylon—staking, timestamps y disponibilidad de datos—eran tres líneas de negocio independientes. Hasta que volví a pensar el nudo muerto del staking de la nueva cadena, me di cuenta de que, en el fondo, esas tres capas en realidad trataban de lo mismo.
El nudo muerto más típico de las nuevas cadenas PoS es que, cuando la capitalización del token es baja, el capital para staking resulta insuficiente; como el costo de atacar es tan bajo que cualquiera puede fastidiar, para atraer staking tienen que aumentar la inflación a lo loco. Pero esa inflación luego vuelve a arruinar el valor del token, creando un ciclo en el que uno se muerde la cola.
La solución de Babylon para la capa de staking consiste en prestar directamente el valor económico acumulado durante más de una década por Bitcoin, en lugar de que la nueva cadena tenga que empezar desde cero apilando confianza.
Pero hoy, de pronto, caí en que el carril de disponibilidad de datos es, en esencia, otra versión del mismo nudo muerto. Si una cadena nueva o un nuevo Rollup quiere construir su propia capa de disponibilidad de datos, también tiene que enfrentarse al problema de que la capitalización del token no es lo bastante alta como para sostener la seguridad económica. El costo de hacer daño mediante el ocultamiento malicioso de datos es igual de bajo. El protocolo de timestamps también obedece a la misma lógica: si una cadena nueva quiere protegerse de ataques de largo alcance apoyándose en su propio conjunto de validadores, el costo de que el conjunto de validadores haga mal al unísono también depende de cuánto vale el token de esa cadena; si no vale lo suficiente, la defensa es como papel.
Esto es lo que, en mi opinión, realmente vale la pena decir. Lo que construye Babylon no son tres líneas de producto separadas, sino el mismo principio de "rellenar el hueco de falta de capital de seguridad del nuevo ecosistema usando el valor económico de Bitcoin" aplicado a tres problemas que antes se consideraban carriles distintos: staking, timestamps y disponibilidad de datos.
En la línea de staking, ahora se bloquean más de 56.000 BTC; en una <a>prueba</a>net de menos de un año alcanzó una escala de 5.5000 millones de dólares. Es una prueba de que el principio por primera vez se cumple en la práctica. En las capas de disponibilidad de datos y timestamps aún no se ve un volumen de uso comparable a esa escala de forma real; si el principio es correcto, teóricamente, tarde o temprano, esas dos líneas también deberían mostrar curvas de adopción similares. Si no despegan durante mucho tiempo, quizá signifique que el éxito de la línea de staking tiene algo especial que hace que este principio no sea tan fácil de copiar.
$BABY #baby
Durante un tiempo creí que las tres capas del protocolo de Babylon—staking, timestamps y disponibilidad de datos—eran tres líneas de negocio independientes. Hasta que volví a pensar el nudo muerto del staking de la nueva cadena, me di cuenta de que, en el fondo, esas tres capas en realidad trataban de lo mismo.
El nudo muerto más típico de las nuevas cadenas PoS es que, cuando la capitalización del token es baja, el capital para staking resulta insuficiente; como el costo de atacar es tan bajo que cualquiera puede fastidiar, para atraer staking tienen que aumentar la inflación a lo loco. Pero esa inflación luego vuelve a arruinar el valor del token, creando un ciclo en el que uno se muerde la cola.
La solución de Babylon para la capa de staking consiste en prestar directamente el valor económico acumulado durante más de una década por Bitcoin, en lugar de que la nueva cadena tenga que empezar desde cero apilando confianza.
Pero hoy, de pronto, caí en que el carril de disponibilidad de datos es, en esencia, otra versión del mismo nudo muerto. Si una cadena nueva o un nuevo Rollup quiere construir su propia capa de disponibilidad de datos, también tiene que enfrentarse al problema de que la capitalización del token no es lo bastante alta como para sostener la seguridad económica. El costo de hacer daño mediante el ocultamiento malicioso de datos es igual de bajo. El protocolo de timestamps también obedece a la misma lógica: si una cadena nueva quiere protegerse de ataques de largo alcance apoyándose en su propio conjunto de validadores, el costo de que el conjunto de validadores haga mal al unísono también depende de cuánto vale el token de esa cadena; si no vale lo suficiente, la defensa es como papel.
Esto es lo que, en mi opinión, realmente vale la pena decir. Lo que construye Babylon no son tres líneas de producto separadas, sino el mismo principio de "rellenar el hueco de falta de capital de seguridad del nuevo ecosistema usando el valor económico de Bitcoin" aplicado a tres problemas que antes se consideraban carriles distintos: staking, timestamps y disponibilidad de datos.
En la línea de staking, ahora se bloquean más de 56.000 BTC; en una <a>prueba</a>net de menos de un año alcanzó una escala de 5.5000 millones de dólares. Es una prueba de que el principio por primera vez se cumple en la práctica. En las capas de disponibilidad de datos y timestamps aún no se ve un volumen de uso comparable a esa escala de forma real; si el principio es correcto, teóricamente, tarde o temprano, esas dos líneas también deberían mostrar curvas de adopción similares. Si no despegan durante mucho tiempo, quizá signifique que el éxito de la línea de staking tiene algo especial que hace que este principio no sea tan fácil de copiar.
$BABY #baby