¿Podría event watch () atravesar desde el último número de bloque (cola) hasta la cabeza?

Lo intentaré, porque las recompensas. :-)

Técnicamente, no, pero podrías crear un efecto similar.

Digo "no" porque la cadena de bloques es un conjunto bien ordenado de bloques, cada uno de los cuales contiene un conjunto bien ordenado de transacciones. Por extensión, la cadena de bloques es un conjunto bien ordenado de transacciones que comienza con la primera transacción en o después del bloque 0.

Aquí está el pateador.

Debe revisarse en orden debido al hecho de que un bloque después del bloque de génesis no se puede verificar de forma independiente sin hacer referencia al bloque anterior. En otras palabras, para saber que está viendo el bloque 50 auténtico (por consenso), debe tener conocimiento del bloque 49. Si comienza por el final, generalmente aplicará la lógica recursivamente hasta el bloque 0 , o deposite su confianza en algo que no sea su propia evaluación independiente.

Además, nunca puedes saber que tienes el último bloque. Lo máximo que puede saber es que tiene el último bloque que conoce (y probablemente haya uno aún más nuevo en camino). ¿Qué, sería el primero en una lista de eventos comenzando con el más nuevo primero? No duraría mucho.

Lograr algo similar a su caso de uso parece implicar escuchar todos los eventos conocidos e insertar continuamente nuevos bloques "más recientes" al comienzo de una lista. O (probablemente más eficiente) agregue el más nuevo al final de su propia lista y luego léalo al revés cuando lo necesite. Esto probablemente estaría relacionado con una preocupación fuera de la cadena (interfaz de usuario, caché, algo más...) - tal vez instantáneas de "punto en el tiempo" o actualizaciones en vivo a medida que se revelan nuevas entradas de registro "más recientes".

Es perfectamente justo mantener sus propias fuentes de datos fuera de la cadena por motivos de rendimiento y otros. Todavía puede obtener los beneficios de blockchain cuando los usuarios/clientes pueden verificar los hechos si así lo desean , confirmando los hechos contra su propia copia de la cadena. Esto es aproximadamente lo que sucede cuando usa exploradores de bloques en línea y otras aplicaciones que necesitan más rendimiento del que sería capaz de un nodo típico. Puedes ordenar ese tipo de cosas como quieras.

Espero eso ayude.

ACTUALIZAR

Existe un patrón para hacer esto de manera eficiente si diseña el contrato para respaldarlo. Utiliza migas de pan muy simples:

pragma solidity 0.5.1;

contract ReverseOrderEvents {

    uint lastEventBlock;

    event LogEvent(address sender, uint previousEvent);

    function doSomething() public {
        emit LogEvent(msg.sender, lastEventBlock);
        lastEventBlock = block.number;
    }
}

En el lado del cliente, cuando lastEvent != 0salte a ese bloque y "escuche" los eventos de interés. Este evento incluirá un puntero al bloque que contiene el evento anterior. Enjuague y repita. Cuando golpeas 0no hay eventos previos.

La técnica es simple y podría usar punteros separados para registros separados, usuarios separados, etc., según sea necesario para que los clientes puedan encontrar la información reciente más importante rápidamente.

Esto permite que un cliente comience con el más reciente y retroceda hasta donde esté interesado. El patrón se puede usar en diseños sin estado donde los datos están en el registro de eventos y posiblemente solo la entrada más reciente es importante.

En caso de que no quede claro, watch()no vaya al revés. Para usar esto, watch()solo necesitaría un bloque (que sería rápido), encontraría lo que necesita y luego watch()el siguiente bloque único de interés, siguiendo las pistas en orden inverso que estableció para usted mismo.