La conexión con Bitcoin
En la sección anterior describimos a Stacks como una forma de llevar funcionalidad de contratos inteligentes a Bitcoin, sin modificar Bitcoin en sí, y explicamos un poco cómo funciona la cadena.
Es una gran promesa, pero ¿cómo cumple realmente Stacks con ella? ¿Y qué hace a Stacks único entre otras capas de Bitcoin y otras blockchains como Ethereum?
Antes de entrar en los detalles técnicos de cómo funciona Stacks, es importante obtener una visión general de alto nivel del problema que está resolviendo y cómo lo hace. Profundizaremos en algunos de estos temas a medida que avancemos por la documentación, pero es bueno tener un panorama general que integre todo.
Este tema es un poco un agujero de conejo, y esta sección es bastante larga, pero te dará una comprensión en profundidad de exactamente el problema que Stacks busca resolver, y cómo lo resuelve.
Vamos a ello.
¿Es Stacks una L2 de Bitcoin?
Stacks es una capa de Bitcoin para contratos inteligentes. La clasificación como capa-1 (L1) o capa-2 (L2) o sidechain realmente depende de la definición utilizada. Dicho esto, en términos generales las cadenas L1 son soberanas, lo que significa que (a) tienen su propio presupuesto de seguridad y (b) pueden sobrevivir sin la necesidad de ninguna otra cadena L1. Las cadenas L2 típicamente no tienen su propio presupuesto de seguridad y comparten la seguridad de la cadena L1 subyacente, y no pueden vivir sin la L1 subyacente. Existen muchos mecanismos de diseño diferentes que las L2 pueden usar, y cubrimos varios de ellos y cómo Stacks se compara en la Stacks entre otras capas de Bitcoin sección.
La versión inicial de Stacks a principios de 2021 tenía un presupuesto de seguridad separado del L1 de Bitcoin. Aunque la capa Stacks no podía funcionar sin el L1 de Bitcoin, los desarrolladores que trabajaban en el proyecto la describieron como un sistema diferente que no encaja perfectamente en las clasificaciones existentes, usando a veces el término capa 1.5 (ver este artículo de Decrypt por ejemplo).
La próxima versión planificada de Stacks, llamada la versión Nakamoto, ya no tendrá un presupuesto de seguridad separado de Bitcoin. En su lugar, el 100% de la potencia de hash de Bitcoin determinará la finalización en la capa Stacks. Después de la próxima actualización, para reorganizar bloques/transacciones de Stacks el atacante necesitará reorganizar el propio Bitcoin L1 (lo cual es muy difícil de hacer y por lo tanto una gran propiedad de seguridad para que tenga una capa de Bitcoin). Más detalles en el documento de Stacks.
La definición de L2 utilizada en Ethereum y otros ecosistemas más nuevos es diferente y se centra en la capacidad de retirar activos usando únicamente la seguridad de L1 y los mineros de L1. Según esa definición, la capa Stacks no es claramente una L2, dado que el conjunto de firmantes de peg-out determina si los usuarios pueden retirar sBTC. Bitcoin no puede soportar tal verificación sin cambios en Bitcoin L1 (lo cual puede suceder en el futuro). La definición de L2 de Ethereum tampoco se aplica tan claramente a las L2 de Bitcoin, dado que en el caso de Bitcoin se emiten nuevos activos en las L2 y no se emiten en L1 (solo BTC es el activo de L1). Por lo tanto, usar la definición de seguridad basada en la retirada de activos no es directamente aplicable dado que los activos se definen y usan en las L2 y no se retiran hacia Bitcoin L1 de todos modos (con la excepción del propio BTC). Más bien, lo que se vuelve más importante es el "asentamiento en Bitcoin", es decir, si los datos y el estado del contrato están asegurados por el 100% de la potencia de hash de Bitcoin o no.
Recuerda que las L2 en Bitcoin también deben cumplir el propósito adicional de ampliar tanto la funcionalidad como la escalabilidad, lo que significa que las L2 logran objetivos fundamentalmente diferentes dependiendo de la funcionalidad de la L1.
Usuarios y desarrolladores llaman orgánicamente a Stacks una L2 de Bitcoin, ya que es un concepto más sencillo de entender. Hay ciertas propiedades de la capa Stacks que también refuerzan el concepto de Stacks como una L2 de Bitcoin:
Finalidad de Bitcoin
El 100% de la potencia de hash de Bitcoin decide el orden de los bloques y la finalización de las transacciones.
El consenso se ejecuta en Bitcoin L1
El consenso de Stacks se ejecuta en Bitcoin L1, y la L2 de Stacks no puede operar ni sobrevivir sin Bitcoin L1.
sBTC y unidad económica
Con el próximo peg descentralizado de Bitcoin, llamado sBTC, la mayor parte de la economía en la capa Stacks probablemente usará BTC como unidad económica. Se espera que la mayoría de los usuarios simplemente usen Bitcoin en billeteras y aplicaciones y luego hagan peg-out de su BTC hacia Bitcoin L1.
Datos hasheados y almacenados en Bitcoin L1
Todos los datos y transacciones en Stacks se hashean automáticamente y se almacenan permanentemente en Bitcoin L1 en cada bloque de Bitcoin. Cualquiera puede verificar que ciertos datos en Stacks son válidos comprobando el hash correspondiente en Bitcoin L1. Este almacenamiento compacto de hashes en L1 es algo similar a los rollups (aunque hay otras diferencias). Puedes leer más sobre este proceso en el Bloque de Producción sección.
Los contratos pueden leer Bitcoin L1
Los contratos en la capa Stacks pueden leer transacciones de Bitcoin L1 y responder a ellas. Los activos en la capa Stacks pueden moverse simplemente mediante transacciones en Bitcoin L1.
Dado todos los detalles anteriores, ¿por qué algunas personas pensarían que Stacks no es una L2 de Bitcoin? Hay un par de razones por las que esta pregunta surge a menudo:
Material antiguo sobre el presupuesto de seguridad
La versión inicial de Stacks (lanzada a principios de 2021) tenía un presupuesto de seguridad separado que cambió para seguir el 100% de la potencia de hash de Bitcoin con la versión Nakamoto. Hay material antiguo y publicaciones de blog circulando que todavía hablan de la versión inicial de Stacks. Es probable que los materiales antiguos se actualicen con el tiempo.
La definición de retirada de L2 de Ethereum no se corresponde limpiamente
Según la definición de L2 de Ethereum, un usuario debería poder retirar sus activos de la capa base puramente realizando una transacción en L1 y confiando solo en la seguridad de L1 (esto es cierto para Lightning, por ejemplo). Esta definición no se aplica limpiamente a las L2 de Bitcoin porque los activos no están definidos en Bitcoin L1 sino en las L2. El único activo en el que esto importa es el activo BTC pegado desde Bitcoin L1, dado que todos los demás activos son nativos de las L2. En la próxima versión de Stacks, los usuarios pueden retirar su BTC enviando solo una transacción en Bitcoin L1, pero Bitcoin L1 no puede validar esa transacción compleja y una mayoría de los firmantes de peg-out necesitarán firmar la solicitud de peg-out. En un mundo ideal los mineros de Bitcoin podrían validar tales transacciones pero eso requeriría un cambio en Bitcoin L1. Por lo tanto, el diseño de Stacks se optimiza por un método que sea descentralizado y pueda desplegarse sin cambios en Bitcoin L1. Si en el futuro es posible realizar cambios en Bitcoin L1, la seguridad de la capa Stacks también podría beneficiarse de ello.
Escepticismo saludable en Bitcoin
Los miembros de la comunidad Bitcoin en general son escépticos ante afirmaciones y están al tanto de personas que hacen declaraciones de marketing falsas. Esto es generalmente algo saludable para el ecosistema Bitcoin y fortalece su sistema inmunológico. Algunos miembros de la comunidad pueden ser escépticos sobre Stacks como una capa o L2 de Bitcoin hasta que lean completamente los detalles técnicos y el razonamiento. Hay un buen hilo de Twitter sobre este tema también.
¿Por qué no usamos entonces el término "sidechain" para Stacks? Las sidechains en Bitcoin típicamente tienen un presupuesto de seguridad diferente al de Bitcoin L1, normalmente como un subconjunto de mineros de Bitcoin que participan en la sidechain (no siguen la finalidad del 100% de Bitcoin), su consenso se ejecuta en la sidechain (vs ejecutarse en Bitcoin L1), y no publican sus datos/hashes en Bitcoin L1. La capa Stacks no encaja bien en esa definición dado que el consenso se ejecuta en Bitcoin L1, sigue la finalidad de Bitcoin y publica datos/hashes en L1.
¿Puede la capa Stacks trabajar con rollups?
¡Sí! Ya existe un esfuerzo activo de I+D para integrar rollups con la capa Stacks. Tanto con la capa Stacks como con rollups soberanos, la parte técnicamente desafiante es cómo introducir y sacar BTC de la capa Stacks o del rollup soberano. El peg descentralizado de BTC, sBTC, se aplica tanto a la capa Stacks como a los rollups soberanos. Sin modificar Bitcoin L1, un diseño tipo sBTC con un grupo descentralizado y de membresía abierta de firmantes es la forma más minimizada en confianza de mover BTC dentro y fuera de las capas de Bitcoin. Una vez que se puedan realizar las actualizaciones necesarias en Bitcoin L1 para habilitar rollups de validez, es decir, que Bitcoin L1 pueda hacer cumplir la retirada de BTC desde una capa, entonces la capa Stacks también podrá actualizarse para beneficiarse de ello.
Dado que se necesita un activo minimizado en confianza como sBTC para los rollups soberanos, con el lanzamiento de sBTC dichos rollups soberanos se vuelven aún más interesantes de desplegar. La capa Stacks puede potencialmente proporcionar el grupo descentralizado de firmantes para un activo BTC minimizado en confianza que pueda usarse en un rollup soberano, y la disponibilidad de datos (DA) proviene directamente de Bitcoin L1, por ejemplo, con Ordinals.
¿Por qué necesita Stacks un token?
Esto nos lleva a una conversación filosófica central en el mundo de las criptomonedas y Bitcoin: si las blockchains necesitan o no tokens.
Comencemos mirando la razón fundamental por la que existen los tokens: financiar el mantenimiento y el progreso futuro de una blockchain.
Bitcoin es un token. Es una criptomoneda que se usa para incentivar a los mineros a añadir nuevos bloques a la cadena. En el caso de Bitcoin, las recompensas de minería están fijadas en un calendario predefinido, y una vez que esas recompensas de minería se agoten, la cadena tendrá que sobrevivir solo con las comisiones de las transacciones.
El propósito de una blockchain es tener un registro histórico permanente de cada transacción que haya ocurrido en la cadena. Las blockchains son básicamente libros contables. El aspecto del token se usa como un mecanismo de incentivo para asegurar y mantener la cadena.
Por eso redes como Lightning y otras redes P2P no necesitan tokens: no necesitan mantener un registro histórico. Las soluciones basadas en canales como Lightning dependen de que los usuarios abran multisigs 2-de-2 entre sí. Una vez que esos canales se cierran, el estado desaparece. Cuando hablamos de un sistema que se supone debe mantener un sistema financiero global, es importante que el mantenimiento de ese sistema esté incentivado correctamente.
Veamos este concepto en el contexto de Stacks y sus objetivos. Stacks busca proporcionar funcionalidad de contratos inteligentes a Bitcoin, para servir como los rieles de programación para construir una economía descentralizada encima de Bitcoin.
Muchos miembros de la comunidad Bitcoin son escépticos respecto a los nuevos tokens y con razón. Hay innumerables proyectos que obligan al uso de un token en su proyecto y en muchos casos un token en realidad no es necesario. El proyecto Stacks fue iniciado por desarrolladores de Bitcoin que tienen una larga historia construyendo aplicaciones y protocolos en Bitcoin L1 sin ningún token (por ejemplo, BNS se lanzó en 2015 en Bitcoin L1 y fue uno de los protocolos más grandes que usó OP_RETURN en Bitcoin L1). Entonces, ¿por qué un grupo de desarrolladores de Bitcoin decidió tener un token separado para la L2 de Stacks? ¡Buena pregunta! Vamos a profundizar en los detalles.
El token de Stacks (STX) está destinado principalmente a usarse para dos cosas:
Incentivos para mineros de la L2 de Stacks
Los STX recién emitidos se usan para incentivar la producción de bloques descentralizada en la L2 de Stacks.
Incentivos para los firmantes de peg-out
Los firmantes que participan en las operaciones de peg-out reciben incentivos en STX para alinearlos económicamente con las reglas del protocolo.
La única forma de eliminar el token es construir Stacks como una red federada como Liquid. En una federación, el grupo preseleccionado de empresas controla la minería y la producción de bloques y un grupo preseleccionado de empresas debe ser confiable para las transacciones de peg-out.
Los desarrolladores de Stacks querían diseñar un sistema abierto y sin permisos. La única manera de tener un proceso de minería descentralizado es mediante incentivos. Como se mencionó arriba, así es como funciona Bitcoin también, donde los BTC recién acuñados se usan como incentivos para minar nuevos bloques y cualquier persona en el mundo puede decidir convertirse en minero. Cualquiera con BTC puede minar la cadena L2 de Stacks; es abierta y sin permisos.
De manera similar, la forma en que sBTC está diseñado es que el grupo de firmantes es abierto y sin permisos (a diferencia de una federación). Estos firmantes tienen incentivos económicos para seguir correctamente el protocolo para las solicitudes de peg-out. En una federación, los usuarios deben confiar ciegamente en los miembros preestablecidos de la federación para sacar su BTC de la federación y devolverlo a Bitcoin L1. Los desarrolladores de Stacks querían tener una forma abierta, sin permisos y descentralizada de mover BTC desde Bitcoin L1 a la L2 de Stacks y de vuelta. Esto es posible mediante incentivos económicos, es decir, la necesidad de un token.
Además de estas dos razones, STX también se usa para pagar las tarifas de gas de las transacciones. Sin embargo, una vez que el próximo peg sBTC esté en funcionamiento, se espera que la mayor parte de la economía de la L2 de Stacks siga un estándar Bitcoin y funcione usando BTC como unidad económica. Se espera que los usuarios interactúen principalmente solo con Bitcoin y usen BTC en billeteras y aplicaciones (las tarifas de gas pueden pagarse con BTC usando intercambios atómicos en segundo plano). Es importante notar que BTC no puede usarse para incentivos de minería en la L2 de Stacks porque la única manera de incentivar la producción de bloques descentralizada es mediante activos recién emitidos por el protocolo (similar a cómo funciona Bitcoin en sí), es decir, la necesidad de un token.
La relación simbiótica entre Stacks y Bitcoin
Stacks y Bitcoin se complementan mutuamente. Stacks aprovecha la extrema descentralización de Bitcoin, su mecanismo de consenso PoW y su valor como criptomoneda.
Pero Stacks también complementa a Bitcoin desbloqueando casos de uso adicionales, aumentando así su valor con el tiempo. Esto también ayuda a resolver el problema adicional de la sostenibilidad futura de Bitcoin después de que las recompensas de la coinbase desaparezcan y Bitcoin tenga que funcionar solo con las comisiones de las transacciones.
Si Bitcoin se ve solo como una reserva de valor, la densidad económica, es decir, cuánto valor se intercambia, de cada transacción será mínima. Pero si Bitcoin es la base subyacente para toda una economía descentralizada, esas transacciones se vuelven mucho más valiosas, incrementando las comisiones de las transacciones. Esto es un incentivo crucial para que los mineros continúen asegurando la red a medida que las recompensas de la coinbase disminuyen.
Lectura del estado de Bitcoin
Una de las cosas que le da superpoderes a la cadena Stacks para conectarse con Bitcoin no es solo cómo se conecta a Bitcoin a nivel de protocolo, discutido más arriba, sino también cómo podemos utilizar ese Bitcoin a nivel programático.
Ahí es donde entra Clarity. Clarity es el lenguaje de contratos inteligentes para Stacks, y es como realmente construimos gran parte de la funcionalidad de la que hablamos aquí.
Una de las características frecuentemente promocionadas de Clarity es que tiene acceso al estado de la cadena Bitcoin incorporado, ¿pero cómo lo hace realmente? Debido al mecanismo PoX de Stacks, cada bloque de Stacks está conectado a un bloque de Bitcoin, y puede consultar los hashes de los encabezados de bloque de Bitcoin con la get-burn-block-info? función.
Esta función nos permite pasar una altura de bloque de Bitcoin y obtener de vuelta el hash del encabezado. La burn-block-height palabra clave de Clarity nos dará la altura de bloque actual de la cadena Bitcoin.
Sin embargo, get-burn-block-info? solo devuelve datos del bloque de Bitcoin en esa altura si ya ha sido procesado y fue creado después del lanzamiento de la cadena Stacks. Entonces, si queremos evaluar si algo ocurrió en Bitcoin, tenemos que esperar al menos un bloque más para hacerlo.
Este es el paso 1 para que los contratos Clarity puedan servir como la capa de programación para Bitcoin. Cuando se inicia una transacción BTC, lo primero que debe ocurrir es que un contrato Clarity tome conocimiento de ella. Esto puede suceder manualmente utilizando las funciones de Clarity discutidas arriba con la biblioteca BTC, como Catamaran Swaps hacen.
O podemos automatizarlo (aunque a costa de cierta centralización en nuestra dapp) usando una arquitectura basada en eventos con algo como los chainhooksde Hiro, lo que nos permitirá activar automáticamente una llamada a un contrato Clarity cuando se inicie cierta transacción BTC.
Este es el primer componente de usar Stacks para construir dapps de Bitcoin: el acceso de lectura a la cadena Bitcoin.
A continuación, profundicemos un poco más en cómo exactamente Stacks está "construido sobre Bitcoin" echando un vistazo al mecanismo de producción de bloques de Stacks, Proof of Transfer.
Última actualización
¿Te fue útil?