Signet
Fecha: June 7, 2019
Transcripción De: Bryan Bishop
Traducción Por: Blue Moon
Tags: Signet
Categoría: Core dev tech
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-March/016734.html
https://twitter.com/kanzure/status/1136980462524608512
Introducción
Voy a hablar un poco de signet. ¿Alguien no sabe lo que es signet? La idea es tener una firma del bloque o del bloque anterior. La idea es que testnet está horriblemente roto para probar cosas, especialmente para probar cosas a largo plazo. Hay grandes reorgs en testnet. ¿Qué pasa con testnet con un ajuste de dificultad menos roto? Testnet es realmente para probar mineros. Uno de los objetivos es que quieras una falta de fiabilidad predecible y no una falta de fiabilidad que destroce el mundo. Signet sería como una nueva serie de redes. Cualquiera puede crear una signet; es una red pública pero sólo las personas con la clave privada pueden crear bloques. Cualquiera puede crear bloques pero sería inválido si miras la coinbase. Podrías engañar a los clientes SPV supongo. Podrías tener una signet taproot y hacerla girar, o una signet Schnorr, o lo que quieras hacer.
Preguntas y respuestas.
PREGUNTAS Y RESPUESTAS
P: ¿Sigue haciendo proof-of-work?
R: El encabezamiento de bloque sigue siendo válido, sí. Sigue haciendo prueba de trabajo. La gente es perezosa y quiere incluir esto en su software, pero no quiere hackear su software de validación de consenso. En su lugar, pueden mantener esto como está. La forma de almacenar y descargar las cabeceras también sigue siendo la misma, no hay que cambiar esas cosas.
P: ¿Es este regtest una prueba de trabajo?
R: Es como la dificultad 1.
P: Entonces, ¿se le puede engañar fácilmente con cambios en las cabeceras?
R: Sí, se puede. Esto es para pruebas, así que no deberías estar conectado a nodos aleatorios.
Las implementaciones no necesitan implementar la comprobación de firma y funciona con todo el software existente. Tienes una salida de coinbase que tiene una firma que dice mi consenso está configurado y configuras cuál es la scriptpubkey para eso en el scriptsig. En vez de firmar la transacción firmas el bloque. Los cambios no son muy grandes en absoluto. Es lo mismo que firmar transacciones. Hay un nuevo firmante que toma un hash y se crea una firma. El hash es el blockhash.
P: ¿Su objetivo es que la gente cree signets al azar o que haya uno global?
R: Una idea es tener un sello fiable que la gente pueda utilizar para hacer pruebas. Este sello permanente tendría una interfaz web y podríamos pedirle que te gaste el doble o algo así y entonces gastaría el doble de tu dirección. Todo esto está fuera de la propuesta, esto es sólo una herramienta que lo hace. Es el doble gasto como servicio (DSaaS).
Tienes una dependencia circular- no puede ser el blockchain. La mejor manera sería eliminar el compromiso testigo manualmente. En segwit, lo ponen a 0000 en el merkle… Pero probablemente no quieras hacer eso aquí porque todavía quieres firmar tu coinbase. Podrías hacer algo como, calcular el posible blockhash si ese compromiso fuera eliminado, y entonces eso es lo que firmas. Cero o eliminado, de cualquier manera.
Podrías firmar el bloque anterior en lugar del bloque actual. Firmas todo excepto la propia firma, por supuesto, y probablemente el nonce en la cabecera. El problema con esto es que vas a tener que crear una firma cada vez, porque vas a hacer PoW y hacer una firma por nonce. Así que no se firma el nonce. Podrías hacer la firma, y luego tirar el nonce. Con dificultad 1, sólo vas a hacer uno de media de todos modos. Va a ser mainnet dificultad 1.
Regtest frente a signet
Regtest es malo, porque cualquiera puede ir y hacer mil millones de bloques. Tienes que conseguir las cabeceras y luego el bloque y luego comprobar la firma.
¿Qué tiene de malo que la firma esté en la cabecera? Todo el mundo tendría que cambiar su código de consenso para poder analizarlo y validarlo. Sería más fácil si no tuvieran que modificar ningún software para utilizarlo. O bien podría estar fuera de la caja, o hacen cambios para signet. Hay poca motivación para añadir la verificación de firmas a diferentes herramientas cuando esto no se utiliza en producción para nada. Es, literalmente, sólo para probar nuevos protocolos, o para probar su integración de intercambio para asegurarse de que está manejando reorgs correctamente - pero usted podría utilizar regtest para ese caso.
Puedes ejecutar bitcoind haciendo cumplir signet, y te conectas a tu propio nodo. Realmente no te importa que seas vulnerable, porque no estás comprobando, sólo estás recibiendo bloques de tu propio nodo. Lo mismo ocurre con regtest, pero cualquier otra persona que se conecte a esa red regtest puede acabar con tus bloques. Podrías usar regtest y sólo confiar en ciertos nodos, lo que significa que la retransmisión de bloques sería de un único nodo que ejecuta la cosa.
Sin embargo, no necesitas proteger una red signet. En signet, sigues conectado a un nodo que está validando. Un nodo que está validando en regtest verá el reorg y verá que todavía es válido y válido por consenso, a menos que hagas una lista blanca sólo para regtest, que todo el mundo tendría que configurar. Regtest es sensible al contexto. Los usuarios de Signet todavía necesitan validar firmas, te conectas a bitcoind ejecutando signet. Así que tienes que usar el software signet, pero no requieren otros cambios en sus otras pilas de software si el nuevo formato de encabezado rompe algo. Usted opta por un signet en particular sobre la base de su scriptsig. No importa qué software ejecutes internamente, pero usas bitcoind como enrutador de borde.
¿Qué tal tener una cabecera normal, y un conjunto separado de firma? Es el truco de segwit. ¿Cuántos cambios va a aceptar Bitcoin Core para esto de probar sólo la firma? Es super simple si es solo «una firma en un lugar determinado». Si no te gusta, no tienes que usarla. Bueno, si va a ser parte de Bitcoin Core entonces eso significa que estamos manteniendo.
¿Regtest no tiene prueba de trabajo? No, tiene proof-of-work pero es un bit de trabajo. Tienes que ponerlo a cero. La mitad de las veces, lo consigues en el primer intento.
Si tu objetivo es tener bloques de 10 minutos, no necesitas cambiar las reglas de dificultad en absoluto. Puedes usar las reglas de la red principal. Y entonces el firmante, si tienes un firmante de alto perfil en algún lugar, tienen 10 ASICs disponibles, pueden elegir una dificultad más alta si quieren y tendrá esa seguridad. La dificultad será exactamente la que el firmante elija o pueda producir. También puede elegir mínima y es menos seguro… El firmante puede tener un cronjob y hacer un bloque de dificultad mínima en ese momento. Sólo mina todo el tiempo y llega a cierta dificultad.
¿Cómo vas a hacer reorg bajo demanda si la dificultad es exactamente lo que pueden hacer? Bueno, tomará de 10 a 20 minutos hacer la reorg. Eso está bien. Sería bueno para reorgs más rápido. 10 minutos es sólo para el ajuste de la dificultad.
Tener una serialización chainparam y hacer que sea fácil enviar eso. Ese es el pull request que alguien estaba pensando - es una cadena personalizada como regtest pero puedes cambiar todos los chainparams a lo que quieras, como un genesis personalizado o lo que sea. Un arg configure o parámetro de línea de comandos que tiene el archivo para chainparams.
Aplicaciones
Creo que es superior en todos los sentidos a testnet. Para lo único que sirve testnet es para hacer pruebas de minería y probar el equipo de los mineros. Si quieres bloques realmente rápidos y reorgs realmente rápidos, entonces usa testnet.
Si estás probando protocolos como los de eltoo entre muchas personas diferentes, entonces regtest es demasiado frágil para eso, y testnet también es demasiado frágil para eso si quieres conseguir algo productivo. Pero aún así quieres poder hacer cosas como el doble gasto como servicio, porque eltoo necesita ser lo suficientemente robusto como para poder manejar reorgs esperados pero no necesariamente reorgs que hagan temblar la tierra. Otra aplicación es que, como intercambiador, siempre quise que mis clientes se unieran a regtest y probaran con mis reorgs arbitrarios.
Podemos tomar bip-taproot y simplemente meterlo ahí. Podríamos ejecutar la propia rama en signet… o el firmante puede aplicar otras reglas de consenso y ahora esas reglas de consenso están activas allí. Taproot puede ser un soft-fork y puedes simplemente decir que este soft-fork está habilitado en esta red, seguro. Durante el desarrollo de segwit, hubo algunas redes de prueba diferentes para segwit llamadas segnet. No es un error tipográfico, había segnet y ahora hay signet. Nadie se acuerda de segnet excepto Pieter.
También es útil para probar software de monederos. Digamos un intercambio que ejecuta un signet semi-privado. Es extremadamente común visitar intercambios y mirar el código de su monedero, y ni siquiera están comprobando los reorgs en absoluto. Así que aquí hay una manera fácil para ellos para comprobar su trabajo contra reorgs. Podría ser muy educativo.
Implementación
El pull request para signet está en el limbo. Estoy planeando volver a ello. Hay una implementación antigua que modifica los encabezados de bloque. Voy a reemplazarla con algo que no lo haga. No parece muy difícil de hacer.