Cómo puede tener modificaciones en la base de datos en tiempo real si las transacciones requieren la aceptación de todos los demás

Estoy tratando de comprender la implementación actual de contratos y transacciones inteligentes y me pregunto sobre el comportamiento en tiempo real. Leí que puede tomar hasta 10 minutos para que una transacción se convierta en parte de un bloque, y leí aquí que "tienes que crear una supuesta transacción que debe ser aceptada por todos los demás". Por lo tanto, no veo cómo podría tener transacciones en tiempo real y crear, por ejemplo, una aplicación de lista de tareas pendientes en la que cada vez que creara una tarea se guardaría instantáneamente en la base de datos y al actualizar estaría allí, y le cobraría al usuario por tarea. (digamos) inmediatamente. Preguntándose si esto es posible, o si se ha considerado, o por qué no es posible, o cómo manejaría una situación como esta.

Respuestas (1)

No estoy seguro de dónde descubrió que una transacción tardaría 10 minutos en estar en un bloque. No toma 10 minutos. Actualmente, el tiempo promedio es un poco menos de 20 segundos ( https://ethstats.net/ ).

Según la red, todo está listo una vez que se extrae una transacción en un bloque, pero el sistema de consenso dicta que un bloque en realidad nunca es definitivo. En teoría, incluso el primer bloque de la red podría revertirse debido a la reorganización de la cadena de consenso. En la práctica, aunque un bloque es definitivo después de que se extraen algunos otros bloques encima de él.

Básicamente, depende de usted decidir cuándo acepta que un bloque sea lo suficientemente definitivo con una certeza lo suficientemente grande. Algunos intercambios, por ejemplo, requieren 10 bloques (10 confirmaciones) encima del bloque para considerarlo lo suficientemente definitivo como para ser aceptado como una transacción no revertible.

Entonces, en teoría, la cadena de bloques está a unos "20 segundos del tiempo real". 20 segundos pueden no ser un intervalo demasiado largo para una aplicación de tareas pendientes. Pero siempre debe recordar que se debe hacer una compensación por consenso: cuántos bloques desea esperar antes de confiar en que el bloque sea lo suficientemente definitivo.

REMEDIOS

Hay formas de eludir este tiempo de transacción "lento". Por ejemplo:

1) Realice parte del procesamiento fuera de la cadena de bloques. Obviamente, todo ese procesamiento es mucho más rápido. Luego, simplemente actualice los datos en la cadena de bloques a ciertos intervalos más o menos.

2) Cadenas laterales/canales estatales. Estos son enfoques bastante nuevos, pero utilizan parcialmente el primer método; parte del procesamiento se realiza, por ejemplo, en una cadena lateral que funciona mucho más rápido. En su mayoría, estas soluciones son válidas solo para transacciones entre participantes conocidos (por lo tanto, muchas transacciones de ida y vuelta entre participantes conocidos) y no para transacciones "aleatorias" a participantes aleatorios.

Me pregunto si hay aplicaciones de ejemplo que demuestren cómo manejar esta latencia. Como, he visto juegos ( a y b ), no veo cómo podrían funcionar si tienen un retraso de 20 segundos.
Su enlace es sobre Bitcoin. Esto es Ethereum, una cadena de bloques completamente diferente. Edité mi respuesta para agregar algunos remedios. Puede encontrar más información sobre los remedios sugeridos en la web.
Pensamientos interesantes sobre los remedios. Me pregunto si conoce alguna cadena de bloques o investigación en la que no haya demora ( en tiempo real ), me interesaría ver cómo lo hicieron.
Por lo general, es una compensación entre descentralización + naturaleza sin confianza versus (parcialmente) centralizado + confiable. Entonces, cuanto más centralizado es algo, más rápido suele ser. Las bases de datos centralizadas son muy rápidas. Las cadenas de bloques descentralizadas son "muy" lentas. Así que solo depende de lo que estés buscando. Para mayor velocidad, solo use bases de datos centralizadas. Para propiedades sin confianza, use Ethereum. Y luego hay muchas opciones intermedias (por ejemplo, Ripple, Neo o BigChainDB)