Primera medicion real de los weights con frame-omni-bencher sobre el
propio blob WASM. El resultado no es un ajuste fino: los 19 extrinsics
de los 5 pallets custom declaraban MENOS de lo que cuestan.
EL PATRON SISTEMATICO. Se costeo el storage del pallet y se olvido el
que cuesta emitir un evento — System::Events, EventCount, ExecutionPhase
y Number son reads y writes reales en cada extrinsic que deposita
evento. Ejemplos medidos: attest_asset declaraba 4 reads / 1 write y
cuesta 7/3; submit_proposal declaraba 12 us y cuesta 62; register_agent_did
declaraba 3/2 y cuesta 6/4.
EL PEOR, Y ES UN ERROR MIO DOCUMENTADO AL REVES. proof_size valia 0 en
los 19. La cabecera de los interinos afirmaba que T::DbWeight "puebla
tanto ref_time como proof_size ... cerrando el hueco". Es falso y se
comprueba en la fuente: sp_weights::RuntimeDbWeight solo tiene los
campos read y write, y reads(r) devuelve from_parts(read * r, 0). Los
interinos arreglaron reads/writes y dejaron el proof_size exactamente
donde estaba. Un proof_size en cero miente al block-builder sobre el
peso PoV: es el vector de DoS que la nota decia haber cerrado. La
afirmacion sobrevivio mas de un mes sin que ninguna lectura la
desmintiera; la desmintio una medicion.
Cada fichero generado lleva ahora un guard GENERADO desde la lista real
de benchmarks que reprueba cualquier proof_size = 0 o ref_time = 0.
Verificado que sabe reprobar: contra los weights anteriores se pone rojo
con "`attest_asset` declara proof_size = 0".
ADVERTENCIA QUE VA EN EL CODIGO, NO SOLO AQUI: son numeros de un
MacBook Pro M3 Max, NO del banco de referencia BM V2. La forma
(reads/writes/proof_size) no depende del hardware y es correcta; el
ref_time si, y en un Pi 5 sera mayor. Un caso lo enseña solo:
attest_asset BAJA de 50 a 44 us, y es el extrinsic dominado por el
verify Ed25519, el mas sensible al silicio. Antes de mainnet hay que
regenerar en el Pi 5 con governor y aislamiento declarados — peticion
abierta a Laurha (request:66f500d54e28a80c) con el blob, el comando y
la version exacta del bencher.
RV12 -> RV13 (weights = consenso). TRANSACTION_VERSION intacto.
295 tests verde.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Durante meses la cabecera de los cinco weights.rs prometia que regenerar
"es mecanico". No lo era: no habia comando, ni plantilla, ni forma de
correrlo. La promesa costo lo que cuestan las promesas sin codigo — al
medir por primera vez, los 19 extrinsics estaban SUBDECLARADOS, los 19.
Tres piezas:
· scripts/bench/regen-weights.sh — construye el WASM con
runtime-benchmarks y mide los 5 pallets. SKIP_BUILD=1 + WASM=<ruta>
mide un blob YA construido: es el modo del banco de referencia, donde
el Pi 5 no compila Substrate sino que recibe el blob que se despliega,
de modo que el binario medido y el desplegado son el MISMO.
· scripts/bench/origin-weights-template.hbs — emite la forma de la casa
(trait + SubstrateWeight<T> + impl para ()) y, dentro, un guard
GENERADO a partir de los benchmarks reales que reprueba cualquier
proof_size = 0 o ref_time = 0. Generado, no escrito: no puede quedarse
corto cuando se anada un extrinsic.
· scripts/bench/HEADER.txt — la cabecera que va dentro de cada fichero
generado, diciendo que un weight es una latencia y que sin su hardware
y su perfil de potencia no se reproduce.
El script documenta ademas dos cosas medidas hoy que cuestan horas si no
estan escritas: (1) hay que usar frame-omni-bencher 0.15.0, porque la
0.23 trae sp-storage 25 contra el sp-storage 22 de este runtime y
TrackedStorageKey no decodifica al cruzar el FFI — falla con "unexpected
first byte decoding Option", que no se parece a "version equivocada";
(2) el governor ondemand arranca a 1600 MHz y sube a 2400, asi que las
primeras muestras salen ~50% lentas y el weight sale de la rampa.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
davidherranandClaude Opus 5