He visto preguntas similares publicadas por todas partes, pero no he encontrado una respuesta que pueda comprender.
Ok, entonces el proceso de vinculación de 2 vías es:
¿Cómo funciona el paso 6?
suposiciones
Bajo estas suposiciones, ¿cómo puede un nodo completo que ejecuta la cadena principal reconocer que las monedas realmente desaparecieron de la cadena lateral (de lo cual no son conscientes explícitamente)? Recuerde, el nodo completo principal no es consciente del tipo de prueba de trabajo (si la hay) que ocurre en la cadena lateral, el esquema de direcciones, en realidad solo conoce y habla el lenguaje de Bitcoin, no el de la cadena lateral. Entonces, ¿cómo funciona el paso 6?
Su pregunta es acertada y plantea el problema principal de la interfaz de la cadena lateral: cómo demostrarle a alguna cadena (llámela "cadena principal") que un evento (como un depósito) tuvo lugar en una cadena remota (llámela "cadena lateral" ).
Hasta donde yo sé, hasta el momento no hay detalles específicos de cómo funciona esto, pero hay varios enfoques que se pueden tomar. El enfoque que generalmente se toma aquí es permitir que un conjunto de "funcionarios" o "pescadores" observen la transacción en la cadena lateral, esperen a que se confirme allí y luego respondan por el hecho de que tuvo lugar firmando una declaración. (un "certificado") que atestigua el hecho de que la transacción en la cadena lateral realmente tuvo lugar. Esto puede funcionar bien si hay algunos supuestos de honestidad acerca de los funcionarios, por ejemplo, que la mayoría de ellos son honestos. En ese caso, en la práctica, el retiro puede ser realmente un cheque multisig. Este enfoque funcionaría con la implementación de bitcoin existente.Plasma , Polkadot, Elementos.
Si no desea permanecer en el ámbito de bitcoin, existen soluciones más elegantes con diferentes suposiciones de confianza que se pueden realizar. Si no le gusta el modelo de amenazas de un grupo centralizado de funcionarios (o una "federación" de los mismos) y desea no confiar en nada, debe producir una prueba de un evento remoto de manera descentralizada. Esta prueba deberá tener la forma de una cadena simple que acredite el hecho de que algo sucedió en la cadena remota, incluso si los mineros locales no se conectan a esa cadena remota y no saben cómo funciona su consenso.
Si la cadena lateral tiene consenso de prueba de trabajo, entonces estas pruebas hacen una afirmación que atestigua el hecho de que se llevó a cabo suficiente prueba de trabajo para enterrar una transacción en la cadena remota. Como prueban que se realizó una prueba de trabajo, son "Pruebas de prueba de trabajo" (PoPoW). La verificación de tales pruebas no es una manera trivial y bitcoin no tiene un código de operación para hacer esto actualmente, ni se está planificando ningún soporte. Por lo tanto, tales esquemas serían posibles cuando la cadena principal es una cadena de bloques completa de Turing o admite un código de operación PoPoW (poco probable).
Por otro lado, la cadena lateral también debe admitir la generación de estas pruebas. Esto se puede incorporar a la cadena, como ERGO , WebDollar o Nimiq . Una cadena de bloques sin soporte PoPoW puede agregarla sin bifurcación suave y sin la aprobación del minero mediante la realización de una bifurcación de terciopelo adecuada .
Finalmente, estos PoPoW tienen que ser producidos por mantenedores de cadenas laterales en un intento de "una sola vez" que genera una cadena simple y no deberían requerir interacción, es decir, deberían ser Pruebas de prueba de trabajo no interactivas (NIPoPoW). Dados estos ingredientes, puede hacerlo de una manera completamente libre de confianza.
Todas las construcciones anteriores presuponen que la cadena lateral y la cadena principal sobreviven de forma segura e independiente. Por ejemplo, la cadena lateral debe tener un poder de cómputo mayoritario honesto si está basada en PoW.
Para resumir, bitcoin actualmente no tiene una forma de hacer lo que está pidiendo sin confianza, pero hay formas federadas/cotoridad para hacerlo. Si está dispuesto a trabajar en nuevos sistemas, puede hacerlo de forma descentralizada.
Descargo de responsabilidad: Soy uno de los coautores del documento Pruebas no interactivas de prueba de trabajo.
Lo primero que debe entender es que este método es una de las dos formas diferentes de mover monedas de un lado a otro entre dos cadenas. El otro se llama Federated Peg , que creo que tendrá más éxito a pesar de ser técnicamente menos sofisticado y más centralizado.
El primer paso es enviar una transacción en la cadena lateral que bloquea su dinero en su lugar. Una vez que esa transacción tiene algunas confirmaciones, crea la prueba SPV para enviar a la cadena principal.
Entremos en más detalles sobre ese último paso:
Cuando ejecuta un cliente SPV, su cliente no descarga bloques completos. Descarga encabezados. Luego, descarga las transacciones hacia o desde su billetera. Luego, descarga las ramas de merkle para conectar su transacción a uno de los encabezados de bloque.
Cuando crea una prueba de SPV, toma los encabezados de bloque que descargó y las ramas de Merkle que necesita conectar a su transacción, y su transacción especial de bloqueo de monedas, y los serializa en una sola estructura de datos.
… ¿no pueden los nodos que verifican la prueba de SPV pedir a los nodos de la cadena lateral que proporcionen los datos de SPV?
No, porque los nodos de la cadena lateral pueden responder de manera diferente a los diferentes nodos de la cadena principal. Eso daría como resultado una bifurcación de la cadena principal. Una prueba de SPV serializada será evaluada de la misma manera por todos los nodos de la cadena principal.
Si tengo mucho poder de minería, no necesito tener dinero en la cadena lateral para retirar dinero de las salidas de la cadena lateral en la cadena principal. (es decir, puedo falsificar un retiro de cadena lateral).
Así es como funciona: creo una transacción a partir de una salida falsa en la cadena lateral. Si transmitiera esto a la cadena lateral, todos los nodos lo rechazarían. Sin embargo, extraigo un bloque que contiene esta transacción y sigo adelante hasta que obtengo suficientes bloques para que la cadena principal confíe en mi prueba SPV.
Mitigaciones
Si está utilizando la cadena lateral para transacciones, terminará con más o menos que cuando comenzó. Sin embargo, se trata de un softfork, por lo que no podemos simplemente depositar todos los fondos entrantes en un solo bote. Todos los fondos se distribuyen en muchas salidas diferentes, y en Bitcoin, debe gastar por completo cualquier salida que reclame. (No puede reclamar parcialmente una salida). Hay dos soluciones para esto:
Bloquee la cantidad exacta de dinero de una salida en la cadena principal, luego reclame eso. Potencialmente hacer esto muchas veces. Esto es simple, pero tiene dos problemas: primero, usa más espacio de blockchain que nessary; en segundo lugar, si no hay un conjunto de resultados que sumen exactamente lo que está retirando, parte de su dinero quedará atrapado en la cadena lateral.
Permita que las personas reclamen una o más salidas y, opcionalmente, envíe el cambio a otra salida OP_SPVPROOFVERIFY. Esta solución es mucho más flexible, pero tiene algunos dientes ocultos. (¿Puedes enviar accidentalmente una tarifa de minero de 80 BTC porque arruinaste tu javascript ? ¿Tendrá la gente un incentivo para evitar las salidas de polvo, lo que lleva a un montón de salidas que nadie quiere pagar para canjear?)
Dado que se trata de una bifurcación suave, no todos los nodos tienen que actualizarse.
Dado que suponemos que estamos diseñando un nuevo código de operación desde cero, podemos hacer que admita muchas cosas diferentes. Podría admitir Scrypt, X11, cualquier algoritmo hash que queramos. No puede admitir la prueba de participación pura de manera significativa. Podría admitir múltiples tiempos objetivo diferentes, tipos de direcciones, etc.
Sin embargo, no puede admitir cambios imprevistos, por lo que si a alguien se le ocurre un cambio brillante que es visible para los clientes de SPV, no funcionará con lo anterior.
Bueno, eso no es del todo cierto. Podría crear dos instrucciones, OP_SPVPROOFCHECKERREGISTER y OP_SPVPROOFVERIFY. El primero registraría un script similar a ethereum que podría mantener el estado y verificaría todas las solicitudes de canje entrantes. El segundo comprometería una suma de dinero hasta que el guión anterior dijera que podría desbloquearse. Eso permitiría sistemas de prueba SPV arbitrarios (aunque todavía no permitiría sistemas PoS puros) a costa de una mayor complejidad.
Chan Ho Suh