Tres minutos para comprender el peso de la transacción en el marco de sustrato de Polkadot

Los recursos disponibles de la cadena son limitados. Los recursos incluyen uso de memoria, E/S de almacenamiento, cálculo, tamaño de transacción/bloque y tamaño de la base de datos de estado. Existen varios mecanismos para administrar el acceso a los recursos y evitar que los componentes individuales de la cadena consuman recursos excesivos. Los pesos son el mecanismo utilizado para administrar el tiempo que lleva validar bloques. En general, esto proviene de la limitación de E/S de almacenamiento y computación.

Nota: los pesos no se usan para restringir el acceso a otros recursos, como el almacenamiento en sí o la huella de memoria. Hay otros mecanismos para esto.

La cantidad de peso que puede contener un bloque es limitada, y el consumo de peso opcional (es decir, el peso que no necesita implementarse como parte de las fases de inicialización o finalización del bloque, ni el peso externo intrínseco para la aplicación) generalmente está limitado por medidas económicas, o En pocas palabras, limitar las tarifas de transacción. Las implicaciones de tarifas del sistema de ponderación están cubiertas en la documentación de tarifas de transacción (https://substrate.dev/docs/en/knowledgebase/runtime/fees).

Substrate define una unidad de peso como picosegundos (picosegundos) de tiempo de ejecución en hardware de referencia fijo (CPU Intel Core i7-7700K, 64 GB de RAM y SSD NVMe). La evaluación comparativa en el hardware de referencia hace que los pesos sean comparables entre los tiempos de ejecución, lo que permite la componibilidad de los componentes de software de diferentes fuentes. Para ajustar el tiempo de ejecución para diferentes suposiciones de hardware de validación, se pueden establecer diferentes pesos máximos de bloque. Por ejemplo, para permitir que los validadores participen a la mitad de la velocidad de la máquina de referencia, el peso máximo del bloque debe ser la mitad del valor predeterminado, manteniendo el tiempo de bloqueo predeterminado.

El peso máximo del bloque debe ser igual a un tercio del tiempo de bloque objetivo, con un tercio asignado para la construcción del bloque, un tercio para la propagación de la red y un tercio para la importación y validación. Al duplicar el tiempo de bloqueo, se duplica el peso máximo del bloque. Estas opciones de optimización proporcionan una manera para que los desarrolladores de tiempo de ejecución hagan las mejores compensaciones para sus escenarios entre transacciones por segundo y requisitos de hardware. Estas compensaciones se pueden ajustar a través de actualizaciones de tiempo de ejecución para mantenerse al día con las mejoras de hardware y software.

El peso representa la cantidad finita de tiempo que la cadena de bloques tiene para validar el bloque. Esto incluye ciclos de cómputo y E/S de almacenamiento. Las implementaciones personalizadas pueden usar estructuras complejas para representar esto. El peso del sustrato es solo un número (https://crates.parity.io/frame_support/weights/type.Weight.html).

El cálculo del peso siempre debe:

Computable antes del envío. Los generadores de bloques deberían poder verificar el peso despachable antes de decidir si aceptarlo.

Consume muy pocos recursos por sí mismo. No tiene sentido gastar los mismos recursos calculando pesos de transacción cuando se gastaría en ejecutarlos. Por lo tanto, el cálculo del peso debería ser mucho más ligero que la programación.

Capacidad para determinar los recursos utilizados sin consultar el estado de la cadena. Los pesos son buenos para representar medidas fijas o medidas basadas solo en los parámetros de una función programable sin requerir E/S costosas. El peso es menos útil cuando el costo depende del estado de la cadena.

En los casos en que el peso programable depende en gran medida del estado de la cadena, hay dos opciones disponibles:

Identificar o introducir un límite superior obligatorio al posible peso que se puede despachar. Si la diferencia entre el tope obligatorio y el peso mínimo posible programable es pequeña, se puede suponer que siempre estará en el tope de peso sin consultar al estado. Sin embargo, si la diferencia es demasiado grande, entonces el costo económico de realizar menos transacciones puede ser demasiado alto, distorsionando los incentivos y creando ineficiencias en el rendimiento.

Requiere que se pase un peso válido (o un precursor disponible para cálculos eficientes) como argumento para el envío. El peso cobrado se basará en estos parámetros, pero también incluye el tiempo requerido para verificar estos parámetros durante el envío. Se debe realizar una validación para garantizar que el parámetro de peso se corresponda exactamente con el estado en cadena y, de no ser así, la operación puede salir mal.

Varios factores afectan el tiempo de ejecución y, por lo tanto, los cálculos de peso. Un gran contribuyente es la cantidad de accesos a la base de datos que ejecuta un programador. Dado que el costo del acceso a la base de datos depende en gran medida del backend de la base de datos y del hardware de almacenamiento, el cálculo del peso se parametriza en lugar del costo del peso de las lecturas y escrituras de la base de datos. Estos costos se determinan comparando cada backend de base de datos disponible en algún hardware de referencia. Esto permite cambiar los backends de la base de datos sin cambiar todos los cálculos de peso.

Además de usar solo constantes para cálculos de peso preprogramados, los desarrolladores también pueden tener en cuenta los parámetros de entrada de un programable determinado. Esto es útil cuando el tiempo de ejecución depende, por ejemplo, de la longitud de un argumento. Es importante destacar que estos cálculos no requieren ningún trabajo significativo en sí mismos. El peso máximo preprogramado se puede calcular fácilmente a partir de los parámetros de entrada utilizando algunos algoritmos básicos.

El palet del Sistema se encarga de acumular el peso de cada bloque a medida que se ejecuta y de asegurarse de que no exceda el límite. La plataforma de pago de transacciones es responsable de interpretar estos pesos y deducir las tarifas en función de estos pesos. La funcionalidad de peso es parte del tiempo de ejecución, por lo que se puede actualizar según sea necesario.

En algunos casos, el peso real de un despachable no se puede calcular simplemente a partir de su entrada. Por ejemplo, el peso puede depender de rutas lógicas programables. Sin ninguna forma de corregir el peso después del envío, seguiríamos sobrevalorando estos despachables y luego cobrándolos de más porque teníamos que asumir lo peor antes del envío para mantener la cadena segura.

Los modificadores de peso posprogramados permiten que cualquier programable devuelva su peso real después de la ejecución. Este peso debe ser inferior o igual al peso en el peor de los casos antes del envío. Para permitir que los usuarios incluyan usuarios externos, aún deben poder pagar el peso máximo, aunque el pago final se basará en el peso real.

Además de afectar las tarifas, el objetivo principal del sistema de ponderación es evitar que un bloque se llene con transacciones que tardan demasiado en ejecutarse. Al procesar transacciones dentro de un bloque, el módulo del sistema suma la longitud total del bloque (la suma de las transacciones codificadas en bytes) y el peso total del bloque. Si cualquiera de estos dos números supera el límite, no se aceptan más transacciones para el bloque. Estos límites se definen en MaximumBlockLength y MaximumBlockWeight.

Una nota importante sobre estas limitaciones es que algunas de ellas están reservadas para la clase de programación operativa. Esta regla se aplica a ambos límites, la relación se puede encontrar en AvailableBlockRatio.

Por ejemplo, si la longitud del bloque está limitada a 1 megabyte y la proporción se establece en 80 %, todas las transacciones pueden llenar los primeros 800 kilobytes del bloque, mientras que los últimos 200 kilobytes solo pueden llenarse por clases de operación.

También hay una clase de envío obligatorio que se puede usar para garantizar que el exterior siempre esté contenido en el bloque, independientemente de su efecto en el peso del bloque. Consulte la documentación de tarifas de transacción (https://substrate.dev/docs/en/knowledgebase/runtime/fees) para obtener más información sobre las diferentes clases de programación y cuándo usarlas.

Siguiente

Más información

Hay ejemplos de pesos personalizados y tarifas de peso incluidos en el libro de cocina Substrate.

Módulo de ejemplo: https://github.com/paritytech/substrate/blob/master/frame/example/src/lib.rs

Vea un ejemplo de cómo agregar un peso de transacción a una función de tiempo de ejecución personalizada. https://substrate.dev/recipes/3-entrees/weights.html

Módulo de pago de transacciones: https://github.com/paritytech/substrate/blob/master/frame/transaction-payment/src/lib.rs

Pesos: https://github.com/paritytech/substrate/blob/master/frame/support/src/weights.rs

Original: https://substrate.dev/docs/en/knowledgebase/learn-substrate/weight

Traducción: Comunidad PolkaWorld

Tags：

Binance Download