Diferencia entre revisiones de «Cadena de bloques»

Contenido eliminado Contenido añadido
m Revertidos los cambios de Skylighter88 (disc.) a la última edición de UA31
Etiqueta: Reversión
Igm1990 (discusión · contribs.)
m Arregla faltas de ortografia y añade comas
Línea 51:
**En la propia estructura de la cadena existe una prueba de que nunca se puede gastar dos veces ya que cada transacción prueba que la suma de sus entradas es más grande que la suma de sus salidas.
**Cada transacción puede ser procesada en paralelo porque son totalmente independientes y no hay conflictos en las salidas.
:Sin embargo el problema de este tipo de cadenas es que solo son utilizables para aplicaciones donde cada salida es propiedad de uno y solo un individuo como por ejemplo es el caso de las monedas digitales. Una salida multipropietario sería muy lenta y no sería eficiente para aplicaciones de propósito general. Por ejemplo, supongamos un contrato inteligente que implementa un contador que puede ser incrementado. Imagina que hay algún incentivo económico para que cada nodo incremente en uno el contador, y que hay 1000 nodos activamente intentado incrementarlo. Usando este modelo de cadena de bloques tendríamos una salida con el valor del contador que sería solicitada por muchos nodos. Finalmente, un nodo tendría éxito y produciría una transacción con una nueva salida con el contador incrementado en una unidad más. El resto de los nodos estarían forzados a reintentar hasta que su transacción sea aceptada. Este sistema es muy lento e ineficiente. Esto es debido a que aun cuando se realiza la transacción se bloquea la salida, se realiza una transformación y finalmente se produce la nueva salida. EstaEstá claro que sería mucho más óptimo si se realizararealizará todo de una sola vez y se produjera directamente el estado resultante. Además, el problema puede estar no solo en el tiempo de la transacción, sino también en el de proceso. Supongamos que el contador tiene adjunto un buffer de 1MB cuyo valor cambia de forma determinista cada vez que el contador cambia. Se tendría que procesar 1MB cada vez que realizara una transacción.
*Basado en mensajes. En este caso, la cadena de bloques representa un consenso sobre el orden de los mensajes y el estado es derivado de forma determinísta a partir de estos mensajes. Este enfoque es utilizado por las cadenas de bloques de [[Steem]] y [[Bitshares]]. Por ejemplo, para implementar un contador cada usuario debería simplemente firmar un mensaje pidiendo el incremento en uno. No se necesita saber el estado actual del contador para que el mensaje sea válido. En este modelo si 1000 nodos envían la petición al mismo tiempo, el productor del bloque podría agregar todas lalas peticiones en un bloque y en un solo paso el contador pasaría de valer de cero a valer 1000. Una aplicación del mundo real que aprovecharía las cualidades de este modelo sería el siguiente:
::Se emite una orden de compra de productos financieros indicando un precio máximo y un volumen concreto. A partir de ahí hay una competición sobre esa salida entre los participanteparticipantes que quieren la solicitud al mismo tiempo. Supongamos que se desea realizar la transacción de forma que sea lo más beneficiosa posible realizando una subasta a la baja para que la solicitud compre activos por el menor precio.<ref name="UTXOmodel"/>
 
==Cadena lateral==