Proof of Transfer (PoX)

En las secciones anteriores, echamos un vistazo a la visión y la ética de Stacks y hablamos mucho sobre su conexión con Bitcoin y cómo permite ampliar la funcionalidad sin modificar Bitcoin en sí.

En esta sección, repasaremos el mecanismo de producción de bloques que hace que eso suceda, la Prueba de Transferencia.

Esta sección será una visión conceptual de la Prueba de Transferencia. Para más detalles sobre exactamente cómo ocurre la producción de bloques a nivel técnico, consulta la sección sobre Bloque de Producción.

Los algoritmos de consenso para blockchains requieren recursos computacionales o financieros para asegurar la cadena. La práctica general del consenso descentralizado es hacer que sea prácticamente infactible para cualquier actor malicioso individual tener suficiente poder de cómputo o participación en propiedad para atacar la red.

Los mecanismos de consenso populares en las blockchains modernas incluyen la prueba de trabajo, en la que los nodos dedican recursos computacionales, y la prueba de participación, en la que los nodos dedican recursos financieros para asegurar la red.

La prueba de quema es otro mecanismo de consenso, menos utilizado, donde los mineros compiten ‘quemando’ (destruyendo) una criptomoneda de prueba de trabajo como sustituto de los recursos computacionales.

La Prueba de Transferencia (PoX) es una extensión del mecanismo de prueba de quema. PoX utiliza la criptomoneda de prueba de trabajo de una blockchain establecida (Bitcoin en este caso) para asegurar una nueva blockchain. Sin embargo, a diferencia de la prueba de quema, en lugar de quemar la criptomoneda, los mineros transfieren la criptomoneda comprometida a algunos otros participantes de la red (Stackers en este caso).

Esto permite a los participantes de la red asegurar la red criptográfica PoX y ganar una recompensa en la criptomoneda base (BTC). Por lo tanto, las blockchains PoX están ancladas en su cadena PoW elegida. Stacks utiliza Bitcoin como su cadena ancla.

¿Por qué Bitcoin?

Hay varias razones por las que Stacks eligió Bitcoin como la blockchain para impulsar el consenso. Es el protocolo de blockchain más antiguo, lanzado en 2009, y se ha convertido en un activo reconocido fuera de la comunidad de criptomonedas. BTC ha mantenido la mayor capitalización de mercado de cualquier criptomoneda durante la última década.

Bitcoin defiende la simplicidad y la estabilidad, y ha resistido la prueba del tiempo. Influir o atacar la red es infactible o poco práctico para posibles hackers. Es una de las pocas criptomonedas que ha captado la atención pública. Bitcoin es un nombre conocido y es reconocido como un activo por gobiernos, grandes corporaciones e instituciones bancarias tradicionales. Por último, Bitcoin se considera en gran medida un almacén de valor fiable y proporciona una infraestructura extensa para apoyar el mecanismo de consenso PoX.

SIP-001 proporciona un listado de razones por las que se eligió Bitcoin para asegurar Stacks.

Por cierto, SIP significa Propuesta de Mejora de Stacks, y es el proceso por el cual los miembros de la comunidad acuerdan realizar cambios en la red. Leer los SIP en detalle es una excelente manera de familiarizarse con Stacks a nivel de implementación. Todos los SIP están disponibles en la sección de SIPs de la documentación.

Desbloqueando el capital de Bitcoin

En la sección anterior hablamos sobre la capacidad de Stacks para permitirnos construir una economía descentralizada sobre Bitcoin y que PoX fue una pieza clave para poder hacer eso.

La razón es doble. Primero, como parte de este proceso de minería PoX que hemos cubierto aquí, se registra el hash de cada bloque de Stacks en el opcode OP_RETURN de una transacción de Bitcoin. Si no estás familiarizado, el opcode OP_RETURN nos permite almacenar hasta 40 bytes de datos arbitrarios en una transacción de Bitcoin.

Esta respuesta de Stack Exchange ofrece una buena visión general del razonamiento e historia de este opcode.

Esta es la primera parte de cómo Stacks hereda la seguridad de Bitcoin: su historia está anclada bloque por bloque a la cadena de Bitcoin. Cualquiera puede usar raíces de Merkle para verificar estos hashes y determinar si la historia es correcta.

Además, después de la Actualización Nakamoto, Stacks ya no hace fork por su cuenta. Se requiere a los mineros a nivel de protocolo que construyan sobre los últimos bloques minados de Stacks, lo que significa que Stacks está asegurado tanto por el 100% del hashrate de Bitcoin además del presupuesto de seguridad de Stacks procedente de sus mineros. Entraremos en este proceso con más detalle en la Bloque de Producción sección.

Además, parte de este proceso PoX implica que cada bloque de Stacks también conozca a qué bloque de Bitcoin está anclado. Clarity, el lenguaje de contratos inteligentes de Stacks, tiene funciones integradas para leer estos datos, como get-block-info, que devuelve, entre otras cosas, un campo llamado burnchain-header-hash, que nos da el hash del encabezado de Bitcoin correspondiente a este bloque de Stacks.

Esto nos permite hacer cosas realmente interesantes como desencadenar ciertos eventos en un contrato Clarity observando la cadena y verificando si ocurrieron ciertas transacciones. Puedes ver esto en acción en Catamaran Swaps, con otros proyectos interesantes como Zest que buscan ampliar esta funcionalidad.

El objetivo final de todo esto es habilitar la visión de web3: construir una economía descentralizada y permitir la verdadera propiedad de los usuarios sobre activos y datos, sobre Bitcoin como capa de liquidación, y usando Bitcoin como dinero descentralizado base.

Contratos y detalles técnicos de la Prueba de Transferencia

La funcionalidad de la Prueba de Transferencia está implementada en la cadena Stacks mediante un contrato inteligente Clarity. Un resumen de este contrato está disponible en la documentación.

Puedes ver el diseño original para stacking y prueba de transferencia leyendo el SIP relevante, SIP-007. También puedes utilizar la API de Hiro para obtener detalles de la prueba de transferencia incluyendo la dirección del contrato relevante.