¿Por qué Git no se considera una "cadena de bloques"?


174

La estructura de datos interna de Git es un árbol de objetos de datos, en el que cada objeto solo apunta a su predecesor. Cada bloque de datos es hash. Al modificar (error de bit o ataque) se notará un bloque intermedio cuando el hash guardado y el hash real se desvíen.

¿En qué se diferencia este concepto de la cadena de bloques?
Git no aparece como un ejemplo de cadenas de bloques, pero al menos en los resúmenes, ambas descripciones de la estructura de datos se parecen: bloque de datos, enlace inverso de una sola dirección, hashes, ...).

Entonces, ¿dónde está la diferencia, que Git no se llama una cadena de bloques?


2
Git no aparece en la lista como un ejemplo de cadenas de bloques. Cuando intenté por primera vez saber qué era una cadena de bloques, me referí a git como el ejemplo más destacado (no tengo el enlace exacto ahora, pero fue desde la parte superior de la cadena). lista devuelta por la búsqueda de Google para "blockchain")
Leon

2
Tanto Git como blockchain están utilizando árboles merkle como su estructura de datos subyacente fundamental. Pero eso por sí solo no convierte a Git en una cadena de bloques, ni al revés. - Si conoces a Git (y sus elementos internos), sí conoces los árboles de merkle, lo que puede ser una revelación muy útil para comprender cómo funcionan las cadenas de bloques.
meter

24
Estimados votantes cercanos, ¿pueden explicar sus razones? Veo 2 me gusta, buenos comentarios y una respuesta. ¿Por qué está basado en la opinión? Se trata de estructuras de datos y algoritmos, que parecen no calificar a Git como una cadena de bloques.
Paebbels

2
Es su opinión que "NO se considera ..." bitcoin.stackexchange.com/a/43627/77469
v.oddou

44
@ v.oddou Los árboles Merkle existen desde 1979. El hecho de que dos tecnologías estén usando los árboles Merkle de manera prominente como parte de su concepto, no los hace iguales. Es incorrecto reducir Git o bloquear cadenas solo para árboles merkle, ya que ninguno de ellos son árboles merkle. Solo los usan. Eso hace que la publicación vinculada sea completamente irrelevante, ya que en realidad se trata de árboles de merkle y no de cadenas de bloques.
meter

Respuestas:


53

git No es un ejemplo de tecnología blockchain por varias razones (estas fueron las primeras que se me ocurrieron):

  1. En una implementación de blockchain, cada bloque se verifica de forma independiente varias veces antes de agregarse a la cadena de bloques. De hecho, esta es una de las cosas más importantes sobre la tecnología blockchain y es lo que garantiza su "imposibilidad de respuesta". Por otro lado, muchos gitproyectos no requieren verificación independiente y, cuando lo hacen, solo requieren que una persona firme un cambio antes de que se envíe al repositorio. Por lo tanto, con a lo sumo un punto de validación en el que debe confiar, gitrompe uno de los principios básicos de la tecnología blockchain.

  2. Un gitrepositorio no está necesariamente duplicado en muchos servidores. Puede trabajar desde un gitrepositorio localmente y si su disco local estuviera dañado, lo perdería todo. La tecnología Blockchain implica la reproducción del libro mayor en los servidores.

  3. Puedes reescribir la githistoria. Un git push <remote> <branch> --forcedónde <branch>se establece en un estado anterior que en <remote>reescribiría el historial. En blockchains, el libro mayor es una historia inmutable.


104
"En blockchains, el libro mayor es una historia inmutable". - Así es la historia de git. Al "reescribir el historial", comienza desde un punto en el pasado y agrega nuevas confirmaciones. Lo mismo es posible con las cadenas de bloques y, de hecho, ocurre cada vez que ocurre una bifurcación, incluso si luego se abandona.
Holger Solo el

8
Hasta donde entiendo las cadenas de bloques frente a Git, también puede volver a escribir cadenas de bloques, a menos que resuelva el problema de colisión hash. Y para Git, sí, puedes reescribir, pero todos los controles remotos aún tienen la historia original. La reescritura del historial crea nuevos hashes y un árbol diferente. Si la cadena de bloques no supera esa operación, ese no es un argumento válido, porque podría implementarlo si quisiera. O a la inversa, puedo rechazar los empujes forzados estableciendo una rama como protegida.
Paebbels

44
@HolgerJust el historial de git es mutable. Al hacer una push --forceen una sola rama, está perdiendo referencias a confirmaciones que limpia el recolector de basura. Esto es diferente a una bifurcación que no es una reescritura de la historia, sino más bien una ruta de desarrollo alternativa.
houtanb

24
¿Podemos resumir que Git podría funcionar en un modo de cadena de bloques aplicando un flujo de trabajo especial y prohibiendo varias operaciones?
Paebbels

44
@ Paebbels sí, estaría de acuerdo con eso. Por defecto y en uso regular no lo es, pero con un flujo de trabajo especial lo sería.
houtanb

123

La razón por la que Git y blockchains parecen similares es porque ambos usan árboles de merkle como su estructura de datos subyacente. Un árbol de merkle es un árbol donde cada nodo está etiquetado con el valor hash criptográfico de sus contenidos, que incluye las etiquetas de sus elementos secundarios.

El gráfico acíclico dirigido de Git es exactamente eso, un árbol de merkle donde cada nodo (etiqueta, commit, árbol u objeto blob) está etiquetado con el hash de su contenido y la etiqueta de su "hijo". Tenga en cuenta que para los commits, el término "hijo" entra en conflicto con la comprensión de Git de los padres: los commits de los padres son los hijos de los commits, solo necesita ver el gráfico como un árbol que sigue creciendo al volver a enraizarlo.

Las cadenas de bloques son muy similares a esto, ya que también siguen creciendo de esa manera, y también están utilizando su propiedad de árbol de merkle para garantizar la integridad de los datos. Pero generalmente, las cadenas de bloques se entienden como mucho más que merkle trees, que es donde se están separando del "estúpido rastreador de contenido" Git . Por ejemplo, blockchains generalmente también significa tener un sistema altamente descentralizado a nivel de bloque (no todos los bloques deben estar en el mismo lugar).

Comprender blockchains es un poco difícil (personalmente, todavía estoy lejos de entender todo al respecto), pero considero entender los componentes internos de Git como una buena manera de comprender los árboles de merkle que definitivamente ayudan a comprender una parte fundamental sobre blockchains.


24
Lo siento, pero ningún blockchains trae nada más que git. blockchains son exactamente tan estúpidos como git. Si no lo crees, estás sobrevalorado. La red de pares y los sistemas de consenso son una cosa separada.
v.oddou

2
los libros de contabilidad privados (blockchains) son conceptualmente idénticos a git
Munhitsu el

Por lo general, en un repositorio de git hay una confirmación de raíz, pero puede haber cualquier cantidad de ramas. Si ve el último commit en una rama como commit de raíz y los padres como hijos, tiene un árbol con muchas raíces que crecen ... Creo que es solo una variación del árbol de Merkle donde las referencias principales están en el contenido en lugar de referencias infantiles. Puede haber varios padres e hijos, por lo que ni siquiera es un árbol.
herman

22

Las monedas cibernéticas como Bitcoin, utilizan una cadena criptográfica de bloques de consenso distribuido (árbol de merkle). El uso común ha acortado esto a 'blockchain'

Mientras que git usa una cadena de bloques (árbol de merkle), carece de los componentes criptográficos de consenso distribuido que implica el uso común del término 'BlockChain'.


17

Blockchaines no sólo cualquier cadena de los bloques.

Blockchaines cuando hay una manera de determinar la cadena principal cuando se desvían dos o más , y cuando no se necesita una autoridad central para esa determinación.


17

A diferencia de las blockchains de criptomonedas ; git no tiene un mecanismo de consenso sin confianza p2p.


¿Por qué considera un sistema de consenso sin confianza como parte de una cadena de bloques? Hay muchas maneras de crear confianza en una cadena de bloques, por ejemplo, es solo que sabe que todo en su copia local no puede eliminarse en el siguiente tirón y especifica que desea los cambios en la copia remota. Solo necesita un consenso sin confianza cuando de otro modo no estaría claro qué es lo correcto. En git, varias ramas pueden ser "correctas" y fusionarse eventualmente.
allo

@allo GitHub generalmente se usa como la fuente central de la verdad, pero ¿qué impide que un administrador fuerce y anule la historia? Si no hubo GitHub y se separó de sus pares, ¿cómo maneja los conflictos de fusión? ¿Cómo se determina el derecho de quién?
Miguel Mota

1
Nada te impide empujar a la fuerza. Pero como me garantiza una cadena de bloques, puedo detectarla porque mi cadena no puede verificar que estas confirmaciones se basen en ella. Ese es el punto con una cadena de bloques, no el consentimiento descentralizado. Y en git, explícitamente no quiero tener un protocolo de consentimiento para lo que fusiono (el desarrollo no es una democracia), pero en realidad leo los nuevos compromisos al fusionarlos en mi cadena. Entonces, mi copia es correcta, porque consta de cosas que ya tengo y, por lo tanto, puedo verificar (es decir, al ver conflictos de fusión) y cosas que reviso y luego acepto.
allo

1
@allo tienes razón en ese sentido, sin embargo, dije en la respuesta "blockchain de criptomonedas", no blockchains en general, pero ahora que lo pienso, mi respuesta realmente no parece encajar con la pregunta que se me hizo porque estaba pensando en el sistema como un todo en lugar de las estructuras de datos subyacentes
Miguel Mota

Tiene toda la razón sobre la diferencia de las cadenas de bloques utilizadas en git y criptomonedas. Simplemente no es una respuesta a la pregunta de por qué (o si) git no se considera una cadena de bloques, cuando se usa el término rigurosamente. Incluso la respuesta actualmente aceptada es similar a su respuesta. Todavía prefiero la respuesta que obtuvo la recompensa.
allo

1

Los objetivos son diferentes para blockchain y git, aunque ambos usan árboles merkle como estructura de datos.

A blockchaines típicamente administrado por una red de igual a igual que se adhiere a un protocolo para la comunicación entre nodos y la validación de nuevos bloques. Una vez registrados, los datos en cualquier bloque dado no pueden ser alterados retroactivamente sin alterar todos los bloques posteriores, lo que requiere el consenso de la mayoría de la red.

Según el documento técnico de Bitcoin:

Una versión puramente de igual a igual del efectivo electrónico permitiría que los pagos en línea se envíen directamente de una parte a otra sin pasar por una institución financiera. Las firmas digitales proporcionan parte de la solución, pero los principales beneficios se pierden si aún se requiere un tercero de confianza para evitar el doble gasto. Proponemos una solución al problema de doble gasto utilizando una red de igual a igual. La red marca las transacciones al convertirlas en una cadena continua de prueba de trabajo basada en hash, formando un registro que no se puede cambiar sin rehacer la prueba de trabajo. La cadena más larga no solo sirve como prueba de la secuencia de eventos presenciados, sino que prueba que proviene del grupo más grande de potencia de CPU. Mientras la mayoría de la potencia de la CPU esté controlada por nodos que no cooperan para atacar la red, ellos ' Generaré la cadena más larga y atacaremos más allá. La red en sí misma requiere una estructura mínima. Los mensajes se transmiten con el mejor esfuerzo, y los nodos pueden salir y volver a unirse a la red a voluntad, aceptando la cadena de prueba de trabajo más larga como prueba de lo que sucedió mientras estaban fuera

Mientras que Gites un sistema de control de versiones distribuido para rastrear cambios en el código fuente durante el desarrollo de software, está diseñado para coordinar el trabajo entre los programadores, pero se puede usar para rastrear cambios en cualquier conjunto de archivos. Sus objetivos incluyen velocidad, integridad de datos y soporte para flujos de trabajo no lineales distribuidos.

Según Linus Torvalds:

En muchos sentidos, puede ver git como un sistema de archivos: es direccionable por contenido y tiene una noción de control de versiones, pero realmente lo diseñé abordando el problema desde el punto de vista de una persona del sistema de archivos (hey, los núcleos es lo que hago) , y en realidad no tengo absolutamente ningún interés en crear un sistema SCM tradicional.


0

Como poke dijo :

Git y Blockchains parecen similares porque ambos usan Merkle Trees para almacenar transacciones ordenadas con marca de tiempo. Un árbol de merkle es una estructura de datos de árbol donde cada nodo está etiquetado con el valor hash criptográfico de sus contenidos, que incluye las etiquetas de sus elementos secundarios.

La primera diferencia es la función Hash : Blockchain tiene una función hash muy costosa, por lo que cada bloque debe ser extraído, donde se puede crear un "bloque" Git con un simple mensaje de confirmación.

El propósito de Bitcoin es agregar confianza al orden de las transacciones. La atención se centra en la cadena más larga, ya que es más costoso de calcular y, por lo tanto, es más probable que sea la verdad.

Bitcoin logra esto al exigir que el hash cumpla con ciertos parámetros (comienza con un número específico de 0s), al incrementar un valor ("nonce") en el mensaje hasta que se encuentre un hash satisfactorio. Esto requiere esfuerzo para encontrar, pero solo 1 cálculo para verificar un nonce; y si múltiples nonces producen un hash satisfactorio, entonces uno será más bajo y se tomará como la verdad. Otros esquemas de autenticación hacen que el hash sea confiable al centralizar la emisión del hash a una autoridad, quizás votada por acuerdo de red, o algún otro método.

Los datos de la cadena de bloques se limitan a las transacciones, que deben cumplir con la validación. La transacción debe ser válida para ser incluida en el siguiente bloque. Una transacción de Bitcoin corresponde a algo importante en el mundo real que justifica el uso de un bloque costoso para registrar esta transferencia, como el intercambio de valor monetario. En realidad, no nos importa el libro final, es una metáfora de algo en el mundo real.

Por el contrario, los bloques Git son arbitrarios, ya que una confirmación puede contener cualquier cantidad de datos. El valor radica en los cambios de datos que se organizan en el árbol git porque nos importa el producto final, está validado por la existencia del repositorio git.

El propósito de Git es permitir que los "libros de contabilidad" baratos rastreen múltiples alternativas de productos. El "libro mayor" en Git es lo que nos importa, es nuestro producto final; Los datos de las transacciones solo registran cómo se construyó el producto. Queremos que sea muy barato hacer múltiples versiones de productos finales, lo suficiente para que el creador registre cómo construyeron este producto. No se realiza una validación explícita de los datos, usted mantiene el producto final si se ve bien, y esa existencia hace que sea útil tener la cadena de creación de este producto. Si el producto final es malo o el orden de las confirmaciones no es válido, este "libro mayor" se elimina durante la recolección de basura.

La segunda diferencia es que las transacciones de Blockchain deben provenir de una fuente válida anterior. En Git, no nos importa qué datos utilizas para extender el árbol. En Blockchain, las transacciones deben provenir de una fuente válida anterior. En ese sentido, Git rastrea la extensión de nuestro entorno, mientras que Blockchain rastrea el intercambio de valor dentro de un entorno cerrado.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.