cómo resolver el problema asincrónico de solidez

La cadena de bloques en sí es efectivamente de un solo subproceso: las transacciones se ejecutan una por una, y el estado de la transacción anterior se modifica si la siguiente transacción hace referencia a ella. Entonces, por ejemplo, si desea asignar una identificación creciente a una serie de registros, puede estar seguro de que, en última instancia, cada identificación solo se asignará a un registro.

El problema es que cuando envías una transacción, no solo no sabes de antemano en qué orden ocurrirá en relación con otras transacciones, tampoco lo sabes inmediatamente después, porque el bloque que acaba de procesarlo puede quedar huérfano y ser reemplazado. por un bloque que tomaba transacciones en un orden diferente. Entonces, en nuestro ejemplo de ID, puede crear un registro enviando una transacción desde su código Javascript, ver cómo obtiene una ID, luego regresar más tarde y descubrir que la ID que pensó que se había asignado a su registro ahora pertenece a un registro diferente.

El resultado es que las cosas que requieren un orden estricto deben gestionarse dentro de la cadena de bloques, que en última instancia siempre es coherente consigo misma, y ​​no se puede asumir una coherencia inmediata con respecto a los sistemas externos.

No hay concurrencia en la cadena de bloques. Las transacciones son ordenadas por el nodo que crea el bloque de acuerdo con el orden en que ese nodo recibió las transacciones.

Por lo tanto, en un caso que podría parecer una condición de carrera, por ejemplo, un intercambio de fichas, en el que se pueden realizar muchas órdenes dentro del tiempo del bloque y de acuerdo con los valores del estado, como el precio visto en el bloque anterior, muchas transacciones podrían simplemente invalidarse porque ese precio se ajusta por orden de llegada en el grupo de TX.