¿Cómo utiliza Ethereum los filtros de floración?

Como se indica en el papel amarillo:

Recibo de la transacción. Para codificar información sobre una transacción sobre la cual puede ser útil formar una prueba de conocimiento cero, o indexar y buscar, codificamos un recibo de cada transacción que contiene cierta información relacionada con su ejecución. Cada recibo, denominado BR[i] para la i-ésima transacción) se coloca en un trie con clave de índice y la raíz se registra en el encabezado como He.

El recibo de la transacción es una tupla de cuatro elementos que comprende el estado posterior a la transacción, R, el gas acumulativo utilizado en el bloque que contiene el recibo de la transacción inmediatamente después de que se realizó la transacción, Ru, el conjunto de registros creados mediante la ejecución de la transacción , Rl y el filtro Bloom compuesto a partir de la información de esos registros, Rb:

R = (R;Ru;Rb;Rl)

¿Alguien puede dar más detalles sobre cómo Rlse estructuran estos (registros) y cómo Rbse construyen los (filtros de floración) a partir de ellos?

He estado investigando sobre los filtros de floración y Broder y Mitzenmacher afirman que:

Siempre que se use una lista o un conjunto, y el espacio sea escaso, considere usar un filtro Bloom si se puede mitigar el efecto de los falsos positivos.

Entonces, ¿cómo se relaciona esto con el diseño racional de Ethereum?

Respuestas (1)

Los eventos en el sistema Ethereum deben buscarse fácilmente, de modo que las aplicaciones puedan filtrar y mostrar eventos, incluidos los históricos, sin sobrecargas indebidas. Al mismo tiempo, el espacio de almacenamiento es costoso, por lo que no queremos almacenar muchos datos duplicados, como la lista de transacciones y los registros que generan. El filtro de floración de registros existe para resolver esto.

Cuando se genera o verifica un bloque, la dirección de cualquier contrato de registro y todos los campos indexados de los registros generados al ejecutar esas transacciones se agregan a un filtro de floración, que se incluye en el encabezado del bloque. Los registros reales no se incluyen en los datos del bloque, para ahorrar espacio.

Cuando una aplicación quiere encontrar todas las entradas de registro de un contrato determinado, o con campos indexados específicos (o ambos), el nodo puede escanear rápidamente el encabezado de cada bloque, verificando el filtro de floración para ver si puede contener registros relevantes. Si lo hace, el nodo vuelve a ejecutar las transacciones de ese bloque, regenerando los registros y devolviendo los relevantes a la aplicación.

gracias =]. ¿Sabe dónde puedo encontrar algún material que defina cómo se crea este filtro de floración y cómo Ethereum trata los falsos positivos?
@HenriqueBarcelos La creación del filtro de floración se describe en el papel amarillo, en y justo después de la sección que citó. La notación es un poco oscura, desafortunadamente. Los falsos positivos se manejan filtrando la lista de eventos generados al volver a ejecutar las transacciones contra los criterios de filtro originales.
Sí, ese es el problema. No encuentro ningún sentido a partir de la definición del papel amarillo. Esperaba conseguir algo "para tontos". De todos modos, seguiré investigando. ¡Muchos gracias!
@HenriqueBarcelos Es bastante sencillo: para la dirección y cada uno de los temas indexados, Keccac-256 los procesa, luego toma los primeros 11 bits de cada uno de los tres pares de bytes menos significativos del hash. Estos son los índices de los 3 bits en el filtro de floración que debe configurar.
Entiendo. Pero se supone que los filtros Bloom usan khashes, con k>=1, pero cuando k=1, se comporta exactamente como un hash. Si usamos solo Keccac-256, ¿cuáles son las ventajas?
@HenriqueBarcelos k hashes y k subconjuntos distintos de un hash más grande son equivalentes entre sí, porque todos los bits de un hash son independientes.
@NickJohnson: ¿Conoce algún código simple que tome una dirección y el filtro de floración del encabezado del bloque y devuelva verdadero/falso si la dirección está en el filtro de floración?
@NickJohnson Usted dice arriba: "Para la dirección y cada uno de los temas indexados, Keccac-256 los procesa, luego toma los primeros 11 bits de cada uno de los tres pares de bytes menos significativos del hash". Me sale la suya excepto por la primera parte. ¿Esto significa concatenar la dirección y cada tema que no esté vacío y luego compartirlos? Estoy bastante seguro de que eso es lo que significa, pero pensé en preguntar.
@NickJohnson Además, cuando "tomo los primeros 11 bits de los tres pares de bytes menos significativos", ¿qué hago con ellos? Confundido por 3 * 11 bits cuando se concatenan serían 33 bits, pero ¿dónde va eso en el filtro de 2048 bits? Debo estar perdiendo algo.
No los concatena: toma cada uno de forma independiente, lo codifica y lo inserta en el filtro de floración. Luego, use los 11 LSB del resultado como un índice en el filtro de floración.
¿No se descargan registros relevantes debajo de cada bloque sin ninguna ejecución (los mineros ya generaron la salida de los resultados de Tx)? ¿Bloom Filer también se usa para otros intentos (estado, transacción y recibo)? @Nick Johnson
¿Cómo utiliza Ethereum los filtros de floración?
RespuestasAquíPolítica de privacidad1y, 0v