¿Por qué la relación entre tx y block es de muchos a muchos?

Estaba revisando el código de ABE y descubrí que la relación de los bloques con las transacciones es de muchos a muchos.

¿Por qué algunas transacciones se almacenan en las listas de transacciones de varios bloques?

Respuestas (1)

Dentro de una cadena de bloques, cada transacción solo puede ocurrir una vez. Sin embargo, la estructura de datos que la gente llama con frecuencia "la cadena de bloques" es en realidad una estructura de árbol, con una raíz (el bloque de génesis) y diferentes ramas. La rama válida más larga de este árbol se denomina cadena de bloques activa, pero ocasionalmente, durante una reorganización, los nodos cambian a otra rama (generalmente solo cambian los últimos 1-2 bloques). Cualquier transacción que estaba en la sucursal anterior pero no en la nueva se intenta extraer nuevamente cuando sea posible. Esto da como resultado que una transacción esté en varios bloques dentro del árbol, pero no en la misma cadena.

Existía otra forma. Al principio, existía la posibilidad de que dos transacciones de base de monedas fueran idénticas. Esto ocurrió en los bloques en la altura 91842 y 91880. Desde entonces, se ha vuelto ilegal y luego imposible a través de BIP30 y BIP34 .

De acuerdo, entonces, cuando uso el RPC para "getblockhash 50000", digamos, luego abro ese bloque y tiene un tx con ID ae345, ¿podría abrir otro bloque (50001 o algo así) y encontrar el mismo tx ae345 enumerado allí? ¿El RPC de bitcoind obtiene su información de la red o de la cadena de bloques en mi computadora? ¿Cambia la cadena de bloques de mi computadora cuando se elimina la rama no válida? No estoy realmente seguro sobre el momento de aceptar bloques en la cadena de bloques, o la forma en que el cliente RPC accede a esos datos.
Cuando lo use getblockhash, le dará el hash del bloque en la cadena actualmente activa. Entonces no, a excepción de las bases de monedas duplicadas, nunca encontrará una transacción dos veces de esa manera. Necesitas buscar en bloques que no están en la cadena principal. El RPC consulta la base de datos local, que tiene todos los bloques (también los que no están en la cadena principal) que su nodo haya aceptado alguna vez, pero solo los activos están indexados y accesibles a través de getblockhash.
Lo siento, estoy un poco confundido con tu respuesta. Dijiste que no es posible encontrar una transacción dos veces llamando getblockhashlocalmente. Sin embargo, también dice getblockhashque le da un bloque en la cadena actualmente activa, pero "también aquellos que no están en la cadena principal", y que "tendría que buscar en bloques que no están en la cadena principal" para poder encontrar un transacción dos veces. ¿Puedes buscar específicamente bloques "que no estén en la cadena principal" con getblockhash?
getblockhashle da el hash de un bloque a una altura particular en la cadena actualmente activa. Cuando solicita un bloque real getblock, puede especificar cualquier hash de bloque, incluso de otros bloques.
getblockhashBien, entonces cuando lo haces a getblocktravés del RPC, ¿es posible ver dos transacciones en diferentes bloques?
No, ya que de esa manera solo alcanzará bloques en la cadena activa, y dentro de una cadena determinada, no es posible duplicar transacciones.
Ya veo. Entonces, ¿hay alguna manera de buscar transacciones duplicadas? Además, ¿por qué blockchain.info enumera algunas transacciones en varios bloques? ¿Cómo encuentran esas cadenas alternativas con la misma transacción en bloques separados? Perdón por hacer tantas preguntas, este es un tema muy confuso y poco claro.
Blockchain.info no usa bitcoind, mantienen muchos más índices que bitcoind. Los bloques inactivos no son interesantes para bitcoind y no están indexados. Si conoce el hash de un bloque inactivo, aún puede solicitarlo a través getblockde , pero no hay forma de obtener una lista de dichos bloques inactivos, por ejemplo.
¡Eso es interesante! Gracias por esa información. Esto ha sido desmitificado :)
¿Por qué la relación entre tx y block es de muchos a muchos?
RespuestasAquíPolítica de privacidad1y, 0v