A Statistical Framework for Predicting System Failure using Multifractal Measures

A Statistical Framework for Predicting System... | F1000Research "use strict";function _typeof(t){return(_typeof="function"==typeof Symbol&&"symbol"==typeof Symbol.iterator?function(t){return typeof t}:function(t){return t&&"function"==typeof Symbol&&t.constructor===Symbol&&t!==Symbol.prototype?"symbol":typeof t})(t)}!function(){var t=function(){var t,e,o=[],n=window,r=n;for(;r;){try{if(r.frames.__tcfapiLocator){t=r;break}}catch(t){}if(r===n.top)break;r=r.parent}t||(!function t(){var e=n.document,o=!!n.frames.__tcfapiLocator;if(!o)if(e.body){var r=e.createElement("iframe");r.style.cssText="display:none",r.name="__tcfapiLocator",e.body.appendChild(r)}else setTimeout(t,5);return!o}(),n.__tcfapi=function(){for(var t=arguments.length,n=new Array(t),r=0;r 3&&2===parseInt(n[1],10)&&"boolean"==typeof n[3]&&(e=n[3],"function"==typeof n[2]&&n[2]("set",!0)):"ping"===n[0]?"function"==typeof n[2]&&n[2]({gdprApplies:e,cmpLoaded:!1,cmpStatus:"stub"}):o.push(n)},n.addEventListener("message",(function(t){var e="string"==typeof t.data,o={};if(e)try{o=JSON.parse(t.data)}catch(t){}else o=t.data;var n="object"===_typeof(o)&&null!==o?o.__tcfapiCall:null;n&&window.__tcfapi(n.command,n.version,(function(o,r){var a={__tcfapiReturn:{returnValue:o,success:r,callId:n.callId}};t&&t.source&&t.source.postMessage&&t.source.postMessage(e?JSON.stringify(a):a,"*")}),n.parameter)}),!1))};"undefined"!=typeof module?module.exports=t:t()}(); dataLayer = dataLayer || []; // Standard GTM initialization - Google Consent Mode handles consent automatically (function(w,d,s,l,i){w[l]=w[l]||[];w[l].push({'gtm.start': new Date().getTime(),event:'gtm.js'});var f=d.getElementsByTagName(s)[0], j=d.createElement(s),dl=l!='dataLayer'?'&l='+l:'';j.async=true;j.src= 'https://www.googletagmanager.com/gtm.js?id='+i+dl+ '>m_auth=hzk0Vc3qFsQYhCrIoHz68A>m_preview=env-1>m_cookies_win=x';f.parentNode.insertBefore(j,f); })(window,document,'script','dataLayer','GTM-MWFK8L5J'); ;window.NREUM||(NREUM={});NREUM.init={distributed_tracing:{enabled:true},privacy:{cookies_enabled:true},ajax:{deny_list:["bam.nr-data.net"]}}; ;NREUM.loader_config={accountID:"438030",trustKey:"438030",agentID:"772317073",licenseKey:"97f8f67f26",applicationID:"772317073"} ;NREUM.info={beacon:"bam.nr-data.net",errorBeacon:"bam.nr-data.net",licenseKey:"97f8f67f26",applicationID:"772317073",sa:1} ;/*! For license information please see nr-loader-spa-1.236.0.min.js.LICENSE.txt */ (()=>{"use strict";var e,t,r={5763:(e,t,r)=>{r.d(t,{P_:()=>l,Mt:()=>g,C5:()=>s,DL:()=>v,OP:()=>T,lF:()=>D,Yu:()=>y,Dg:()=>h,CX:()=>c,GE:()=>b,sU:()=>_});var n=r(8632),i=r(9567);const o={beacon:n.ce.beacon,errorBeacon:n.ce.errorBeacon,licenseKey:void 0,applicationID:void 0,sa:void 0,queueTime:void 0,applicationTime:void 0,ttGuid:void 0,user:void 0,account:void 0,product:void 0,extra:void 0,jsAttributes:{},userAttributes:void 0,atts:void 0,transactionName:void 0,tNamePlain:void 0},a={};function s(e){if(!e)throw new Error("All info objects require an agent identifier!");if(!a[e])throw new Error("Info for ".concat(e," was never set"));return a[e]}function c(e,t){if(!e)throw new Error("All info objects require an agent identifier!");a[e]=(0,i.D)(t,o),(0,n.Qy)(e,a[e],"info")}var u=r(7056);const d=()=>{const e={blockSelector:"[data-nr-block]",maskInputOptions:{password:!0}};return{allow_bfcache:!0,privacy:{cookies_enabled:!0},ajax:{deny_list:void 0,enabled:!0,harvestTimeSeconds:10},distributed_tracing:{enabled:void 0,exclude_newrelic_header:void 0,cors_use_newrelic_header:void 0,cors_use_tracecontext_headers:void 0,allowed_origins:void 0},session:{domain:void 0,expiresMs:u.oD,inactiveMs:u.Hb},ssl:void 0,obfuscate:void 0,jserrors:{enabled:!0,harvestTimeSeconds:10},metrics:{enabled:!0},page_action:{enabled:!0,harvestTimeSeconds:30},page_view_event:{enabled:!0},page_view_timing:{enabled:!0,harvestTimeSeconds:30,long_task:!1},session_trace:{enabled:!0,harvestTimeSeconds:10},harvest:{tooManyRequestsDelay:60},session_replay:{enabled:!1,harvestTimeSeconds:60,sampleRate:.1,errorSampleRate:.1,maskTextSelector:"*",maskAllInputs:!0,get blockClass(){return"nr-block"},get ignoreClass(){return"nr-ignore"},get maskTextClass(){return"nr-mask"},get blockSelector(){return e.blockSelector},set blockSelector(t){e.blockSelector+=",".concat(t)},get maskInputOptions(){return e.maskInputOptions},set maskInputOptions(t){e.maskInputOptions={...t,password:!0}}},spa:{enabled:!0,harvestTimeSeconds:10}}},f={};function l(e){if(!e)throw new Error("All configuration objects require an agent identifier!");if(!f[e])throw new Error("Configuration for ".concat(e," was never set"));return f[e]}function h(e,t){if(!e)throw new Error("All configuration objects require an agent identifier!");f[e]=(0,i.D)(t,d()),(0,n.Qy)(e,f[e],"config")}function g(e,t){if(!e)throw new Error("All configuration objects require an agent identifier!");var r=l(e);if(r){for(var n=t.split("."),i=0;i {r.d(t,{D:()=>i});var n=r(50);function i(e,t){try{if(!e||"object"!=typeof e)return(0,n.Z)("Setting a Configurable requires an object as input");if(!t||"object"!=typeof t)return(0,n.Z)("Setting a Configurable requires a model to set its initial properties");const r=Object.create(Object.getPrototypeOf(t),Object.getOwnPropertyDescriptors(t)),o=0===Object.keys(r).length?e:r;for(let a in o)if(void 0!==e[a])try{"object"==typeof e[a]&&"object"==typeof t[a]?r[a]=i(e[a],t[a]):r[a]=e[a]}catch(e){(0,n.Z)("An error occurred while setting a property of a Configurable",e)}return r}catch(e){(0,n.Z)("An error occured while setting a Configurable",e)}}},6818:(e,t,r)=>{r.d(t,{Re:()=>i,gF:()=>o,q4:()=>n});const n="1.236.0",i="PROD",o="CDN"},385:(e,t,r)=>{r.d(t,{FN:()=>a,IF:()=>u,Nk:()=>f,Tt:()=>s,_A:()=>o,il:()=>n,pL:()=>c,v6:()=>i,w1:()=>d});const n="undefined"!=typeof window&&!!window.document,i="undefined"!=typeof WorkerGlobalScope&&("undefined"!=typeof self&&self instanceof WorkerGlobalScope&&self.navigator instanceof WorkerNavigator||"undefined"!=typeof globalThis&&globalThis instanceof WorkerGlobalScope&&globalThis.navigator instanceof WorkerNavigator),o=n?window:"undefined"!=typeof WorkerGlobalScope&&("undefined"!=typeof self&&self instanceof WorkerGlobalScope&&self||"undefined"!=typeof globalThis&&globalThis instanceof WorkerGlobalScope&&globalThis),a=""+o?.location,s=/iPad|iPhone|iPod/.test(navigator.userAgent),c=s&&"undefined"==typeof SharedWorker,u=(()=>{const e=navigator.userAgent.match(/Firefox[/\s](\d+\.\d+)/);return Array.isArray(e)&&e.length>=2?+e[1]:0})(),d=Boolean(n&&window.document.documentMode),f=!!navigator.sendBeacon},1117:(e,t,r)=>{r.d(t,{w:()=>o});var n=r(50);const i={agentIdentifier:"",ee:void 0};class o{constructor(e){try{if("object"!=typeof e)return(0,n.Z)("shared context requires an object as input");this.sharedContext={},Object.assign(this.sharedContext,i),Object.entries(e).forEach((e=>{let[t,r]=e;Object.keys(i).includes(t)&&(this.sharedContext[t]=r)}))}catch(e){(0,n.Z)("An error occured while setting SharedContext",e)}}}},8e3:(e,t,r)=>{r.d(t,{L:()=>d,R:()=>c});var n=r(2177),i=r(1284),o=r(4322),a=r(3325);const s={};function c(e,t){const r={staged:!1,priority:a.p[t]||0};u(e),s[e].get(t)||s[e].set(t,r)}function u(e){e&&(s[e]||(s[e]=new Map))}function d(){let e=arguments.length>0&&void 0!==arguments[0]?arguments[0]:"",t=arguments.length>1&&void 0!==arguments[1]?arguments[1]:"feature";if(u(e),!e||!s[e].get(t))return a(t);s[e].get(t).staged=!0;const r=[...s[e]];function a(t){const r=e?n.ee.get(e):n.ee,a=o.X.handlers;if(r.backlog&&a){var s=r.backlog[t],c=a[t];if(c){for(var u=0;s&&u {let[t,r]=e;return r.staged}))&&(r.sort(((e,t)=>e[1].priority-t[1].priority)),r.forEach((e=>{let[t]=e;a(t)})))}function f(e,t){var r=e[1];(0,i.D)(t[r],(function(t,r){var n=e[0];if(r[0]===n){var i=r[1],o=e[3],a=e[2];i.apply(o,a)}}))}},2177:(e,t,r)=>{r.d(t,{c:()=>f,ee:()=>u});var n=r(8632),i=r(2210),o=r(1284),a=r(5763),s="nr@context";let c=(0,n.fP)();var u;function d(){}function f(e){return(0,i.X)(e,s,l)}function l(){return new d}function h(){u.aborted=!0,u.backlog={}}c.ee?u=c.ee:(u=function e(t,r){var n={},c={},f={},g=!1;try{g=16===r.length&&(0,a.OP)(r).isolatedBacklog}catch(e){}var p={on:b,addEventListener:b,removeEventListener:y,emit:v,get:x,listeners:w,context:m,buffer:A,abort:h,aborted:!1,isBuffering:E,debugId:r,backlog:g?{}:t&&"object"==typeof t.backlog?t.backlog:{}};return p;function m(e){return e&&e instanceof d?e:e?(0,i.X)(e,s,l):l()}function v(e,r,n,i,o){if(!1!==o&&(o=!0),!u.aborted||i){t&&o&&t.emit(e,r,n);for(var a=m(n),s=w(e),d=s.length,f=0;fn,p:()=>i});var n=r(2177).ee.get("handle");function i(e,t,r,i,o){o?(o.buffer([e],i),o.emit(e,t,r)):(n.buffer([e],i),n.emit(e,t,r))}},4322:(e,t,r)=>{r.d(t,{X:()=>o});var n=r(5546);o.on=a;var i=o.handlers={};function o(e,t,r,o){a(o||n.E,i,e,t,r)}function a(e,t,r,i,o){o||(o="feature"),e||(e=n.E);var a=t[o]=t[o]||{};(a[r]=a[r]||[]).push([e,i])}},3239:(e,t,r)=>{r.d(t,{bP:()=>s,iz:()=>c,m$:()=>a});var n=r(385);let i=!1,o=!1;try{const e={get passive(){return i=!0,!1},get signal(){return o=!0,!1}};n._A.addEventListener("test",null,e),n._A.removeEventListener("test",null,e)}catch(e){}function a(e,t){return i||o?{capture:!!e,passive:i,signal:t}:!!e}function s(e,t){let r=arguments.length>2&&void 0!==arguments[2]&&arguments[2],n=arguments.length>3?arguments[3]:void 0;window.addEventListener(e,t,a(r,n))}function c(e,t){let r=arguments.length>2&&void 0!==arguments[2]&&arguments[2],n=arguments.length>3?arguments[3]:void 0;document.addEventListener(e,t,a(r,n))}},4402:(e,t,r)=>{r.d(t,{Ht:()=>u,M:()=>c,Rl:()=>a,ky:()=>s});var n=r(385);const i="xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx";function o(e,t){return e?15&e[t]:16*Math.random()|0}function a(){const e=n._A?.crypto||n._A?.msCrypto;let t,r=0;return e&&e.getRandomValues&&(t=e.getRandomValues(new Uint8Array(31))),i.split("").map((e=>"x"===e?o(t,++r).toString(16):"y"===e?(3&o()|8).toString(16):e)).join("")}function s(e){const t=n._A?.crypto||n._A?.msCrypto;let r,i=0;t&&t.getRandomValues&&(r=t.getRandomValues(new Uint8Array(31)));const a=[];for(var s=0;s {r.d(t,{Bq:()=>n,Hb:()=>o,oD:()=>i});const n="NRBA",i=144e5,o=18e5},7894:(e,t,r)=>{function n(){return Math.round(performance.now())}r.d(t,{z:()=>n})},7243:(e,t,r)=>{r.d(t,{e:()=>o});var n=r(385),i={};function o(e){if(e in i)return i[e];if(0===(e||"").indexOf("data:"))return{protocol:"data"};let t;var r=n._A?.location,o={};if(n.il)t=document.createElement("a"),t.href=e;else try{t=new URL(e,r.href)}catch(e){return o}o.port=t.port;var a=t.href.split("://");!o.port&&a[1]&&(o.port=a[1].split("/")[0].split("@").pop().split(":")[1]),o.port&&"0"!==o.port||(o.port="https"===a[0]?"443":"80"),o.hostname=t.hostname||r.hostname,o.pathname=t.pathname,o.protocol=a[0],"/"!==o.pathname.charAt(0)&&(o.pathname="/"+o.pathname);var s=!t.protocol||":"===t.protocol||t.protocol===r.protocol,c=t.hostname===r.hostname&&t.port===r.port;return o.sameOrigin=s&&(!t.hostname||c),"/"===o.pathname&&(i[e]=o),o}},50:(e,t,r)=>{function n(e,t){"function"==typeof console.warn&&(console.warn("New Relic: ".concat(e)),t&&console.warn(t))}r.d(t,{Z:()=>n})},2587:(e,t,r)=>{r.d(t,{N:()=>c,T:()=>u});var n=r(2177),i=r(5546),o=r(8e3),a=r(3325);const s={stn:[a.D.sessionTrace],err:[a.D.jserrors,a.D.metrics],ins:[a.D.pageAction],spa:[a.D.spa],sr:[a.D.sessionReplay,a.D.sessionTrace]};function c(e,t){const r=n.ee.get(t);e&&"object"==typeof e&&(Object.entries(e).forEach((e=>{let[t,n]=e;void 0===u[t]&&(s[t]?s[t].forEach((e=>{n?(0,i.p)("feat-"+t,[],void 0,e,r):(0,i.p)("block-"+t,[],void 0,e,r),(0,i.p)("rumresp-"+t,[Boolean(n)],void 0,e,r)})):n&&(0,i.p)("feat-"+t,[],void 0,void 0,r),u[t]=Boolean(n))})),Object.keys(s).forEach((e=>{void 0===u[e]&&(s[e]?.forEach((t=>(0,i.p)("rumresp-"+e,[!1],void 0,t,r))),u[e]=!1)})),(0,o.L)(t,a.D.pageViewEvent))}const u={}},2210:(e,t,r)=>{r.d(t,{X:()=>i});var n=Object.prototype.hasOwnProperty;function i(e,t,r){if(n.call(e,t))return e[t];var i=r();if(Object.defineProperty&&Object.keys)try{return Object.defineProperty(e,t,{value:i,writable:!0,enumerable:!1}),i}catch(e){}return e[t]=i,i}},1284:(e,t,r)=>{r.d(t,{D:()=>n});const n=(e,t)=>Object.entries(e||{}).map((e=>{let[r,n]=e;return t(r,n)}))},4351:(e,t,r)=>{r.d(t,{P:()=>o});var n=r(2177);const i=()=>{const e=new WeakSet;return(t,r)=>{if("object"==typeof r&&null!==r){if(e.has(r))return;e.add(r)}return r}};function o(e){try{return JSON.stringify(e,i())}catch(e){try{n.ee.emit("internal-error",[e])}catch(e){}}}},3960:(e,t,r)=>{r.d(t,{K:()=>a,b:()=>o});var n=r(3239);function i(){return"undefined"==typeof document||"complete"===document.readyState}function o(e,t){if(i())return e();(0,n.bP)("load",e,t)}function a(e){if(i())return e();(0,n.iz)("DOMContentLoaded",e)}},8632:(e,t,r)=>{r.d(t,{EZ:()=>u,Qy:()=>c,ce:()=>o,fP:()=>a,gG:()=>d,mF:()=>s});var n=r(7894),i=r(385);const o={beacon:"bam.nr-data.net",errorBeacon:"bam.nr-data.net"};function a(){return i._A.NREUM||(i._A.NREUM={}),void 0===i._A.newrelic&&(i._A.newrelic=i._A.NREUM),i._A.NREUM}function s(){let e=a();return e.o||(e.o={ST:i._A.setTimeout,SI:i._A.setImmediate,CT:i._A.clearTimeout,XHR:i._A.XMLHttpRequest,REQ:i._A.Request,EV:i._A.Event,PR:i._A.Promise,MO:i._A.MutationObserver,FETCH:i._A.fetch}),e}function c(e,t,r){let i=a();const o=i.initializedAgents||{},s=o[e]||{};return Object.keys(s).length||(s.initializedAt={ms:(0,n.z)(),date:new Date}),i.initializedAgents={...o,[e]:{...s,[r]:t}},i}function u(e,t){a()[e]=t}function d(){return function(){let e=a();const t=e.info||{};e.info={beacon:o.beacon,errorBeacon:o.errorBeacon,...t}}(),function(){let e=a();const t=e.init||{};e.init={...t}}(),s(),function(){let e=a();const t=e.loader_config||{};e.loader_config={...t}}(),a()}},7956:(e,t,r)=>{r.d(t,{N:()=>i});var n=r(3239);function i(e){let t=arguments.length>1&&void 0!==arguments[1]&&arguments[1],r=arguments.length>2?arguments[2]:void 0,i=arguments.length>3?arguments[3]:void 0;return void(0,n.iz)("visibilitychange",(function(){if(t)return void("hidden"==document.visibilityState&&e());e(document.visibilityState)}),r,i)}},1214:(e,t,r)=>{r.d(t,{em:()=>v,u5:()=>N,QU:()=>S,_L:()=>I,Gm:()=>L,Lg:()=>M,gy:()=>U,BV:()=>Q,Kf:()=>ee});var n=r(2177);const i="nr@original";var o=Object.prototype.hasOwnProperty,a=!1;function s(e,t){return e||(e=n.ee),r.inPlace=function(e,t,n,i,o){n||(n="");var a,s,c,u="-"===n.charAt(0);for(c=0;c 2?n-2:0),o=2;o {r(A[T],e,w),r(E[T],e,w)})),r(l._A,"fetch",y),t.on(y+"end",(function(e,r){var n=this;if(r){var i=r.headers.get("content-length");null!==i&&(n.rxSize=i),t.emit(y+"done",[null,r],n)}else t.emit(y+"done",[e],n)})),t}const O={},j=["pushState","replaceState"];function S(e){const t=function(e){return(e||n.ee).get("history")}(e);return!l.il||O[t.debugId]++||(O[t.debugId]=1,s(t).inPlace(window.history,j,"-")),t}var P=r(3239);const C={},R=["appendChild","insertBefore","replaceChild"];function I(e){const t=function(e){return(e||n.ee).get("jsonp")}(e);if(!l.il||C[t.debugId])return t;C[t.debugId]=!0;var r=s(t),i=/[?&](?:callback|cb)=([^&#]+)/,o=/(.*)\.([^.]+)/,a=/^(\w+)(\.|$)(.*)$/;function c(e,t){var r=e.match(a),n=r[1],i=r[3];return i?c(i,t[n]):t[n]}return r.inPlace(Node.prototype,R,"dom-"),t.on("dom-start",(function(e){!function(e){if(!e||"string"!=typeof e.nodeName||"script"!==e.nodeName.toLowerCase())return;if("function"!=typeof e.addEventListener)return;var n=(a=e.src,s=a.match(i),s?s[1]:null);var a,s;if(!n)return;var u=function(e){var t=e.match(o);if(t&&t.length>=3)return{key:t[2],parent:c(t[1],window)};return{key:e,parent:window}}(n);if("function"!=typeof u.parent[u.key])return;var d={};function f(){t.emit("jsonp-end",[],d),e.removeEventListener("load",f,(0,P.m$)(!1)),e.removeEventListener("error",l,(0,P.m$)(!1))}function l(){t.emit("jsonp-error",[],d),t.emit("jsonp-end",[],d),e.removeEventListener("load",f,(0,P.m$)(!1)),e.removeEventListener("error",l,(0,P.m$)(!1))}r.inPlace(u.parent,[u.key],"cb-",d),e.addEventListener("load",f,(0,P.m$)(!1)),e.addEventListener("error",l,(0,P.m$)(!1)),t.emit("new-jsonp",[e.src],d)}(e[0])})),t}var k=r(5763);const H={};function L(e){const t=function(e){return(e||n.ee).get("mutation")}(e);if(!l.il||H[t.debugId])return t;H[t.debugId]=!0;var r=s(t),i=k.Yu.MO;return i&&(window.MutationObserver=function(e){return this instanceof i?new i(r(e,"fn-")):i.apply(this,arguments)},MutationObserver.prototype=i.prototype),t}const z={};function M(e){const t=function(e){return(e||n.ee).get("promise")}(e);if(z[t.debugId])return t;z[t.debugId]=!0;var r=n.c,o=s(t),a=k.Yu.PR;return a&&function(){function e(r){var n=t.context(),i=o(r,"executor-",n,null,!1);const s=Reflect.construct(a,[i],e);return t.context(s).getCtx=function(){return n},s}l._A.Promise=e,Object.defineProperty(e,"name",{value:"Promise"}),e.toString=function(){return a.toString()},Object.setPrototypeOf(e,a),["all","race"].forEach((function(r){const n=a[r];e[r]=function(e){let i=!1;[...e||[]].forEach((e=>{this.resolve(e).then(a("all"===r),a(!1))}));const o=n.apply(this,arguments);return o;function a(e){return function(){t.emit("propagate",[null,!i],o,!1,!1),i=i||!e}}}})),["resolve","reject"].forEach((function(r){const n=a[r];e[r]=function(e){const r=n.apply(this,arguments);return e!==r&&t.emit("propagate",[e,!0],r,!1,!1),r}})),e.prototype=a.prototype;const n=a.prototype.then;a.prototype.then=function(){var e=this,i=r(e);i.promise=e;for(var a=arguments.length,s=new Array(a),c=0;c e())),t};function m(e,t){i.inPlace(t,["onreadystatechange"],"fn-",E)}function b(){var e=this,t=r.context(e);e.readyState>3&&!t.resolved&&(t.resolved=!0,r.emit("xhr-resolved",[],e)),i.inPlace(e,f,"fn-",E)}if(function(e,t){for(var r in e)t[r]=e[r]}(o,p),p.prototype=o.prototype,i.inPlace(p.prototype,J,"-xhr-",E),r.on("send-xhr-start",(function(e,t){m(e,t),function(e){h.push(e),a&&(y?y.then(A):u?u(A):(w=-w,x.data=w))}(t)})),r.on("open-xhr-start",m),a){var y=c&&c.resolve();if(!u&&!c){var w=1,x=document.createTextNode(w);new a(A).observe(x,{characterData:!0})}}else t.on("fn-end",(function(e){e[0]&&e[0].type===d||A()}));function A(){for(var e=0;e {r.d(t,{t:()=>n});const n=r(3325).D.ajax},6660:(e,t,r)=>{r.d(t,{A:()=>i,t:()=>n});const n=r(3325).D.jserrors,i="nr@seenError"},3081:(e,t,r)=>{r.d(t,{gF:()=>o,mY:()=>i,t9:()=>n,vz:()=>s,xS:()=>a});const n=r(3325).D.metrics,i="sm",o="cm",a="storeSupportabilityMetrics",s="storeEventMetrics"},4649:(e,t,r)=>{r.d(t,{t:()=>n});const n=r(3325).D.pageAction},7633:(e,t,r)=>{r.d(t,{Dz:()=>i,OJ:()=>a,qw:()=>o,t9:()=>n});const n=r(3325).D.pageViewEvent,i="firstbyte",o="domcontent",a="windowload"},9251:(e,t,r)=>{r.d(t,{t:()=>n});const n=r(3325).D.pageViewTiming},3614:(e,t,r)=>{r.d(t,{BST_RESOURCE:()=>i,END:()=>s,FEATURE_NAME:()=>n,FN_END:()=>u,FN_START:()=>c,PUSH_STATE:()=>d,RESOURCE:()=>o,START:()=>a});const n=r(3325).D.sessionTrace,i="bstResource",o="resource",a="-start",s="-end",c="fn"+a,u="fn"+s,d="pushState"},7836:(e,t,r)=>{r.d(t,{BODY:()=>A,CB_END:()=>E,CB_START:()=>u,END:()=>x,FEATURE_NAME:()=>i,FETCH:()=>_,FETCH_BODY:()=>v,FETCH_DONE:()=>m,FETCH_START:()=>p,FN_END:()=>c,FN_START:()=>s,INTERACTION:()=>l,INTERACTION_API:()=>d,INTERACTION_EVENTS:()=>o,JSONP_END:()=>b,JSONP_NODE:()=>g,JS_TIME:()=>T,MAX_TIMER_BUDGET:()=>a,REMAINING:()=>f,SPA_NODE:()=>h,START:()=>w,originalSetTimeout:()=>y});var n=r(5763);const i=r(3325).D.spa,o=["click","submit","keypress","keydown","keyup","change"],a=999,s="fn-start",c="fn-end",u="cb-start",d="api-ixn-",f="remaining",l="interaction",h="spaNode",g="jsonpNode",p="fetch-start",m="fetch-done",v="fetch-body-",b="jsonp-end",y=n.Yu.ST,w="-start",x="-end",A="-body",E="cb"+x,T="jsTime",_="fetch"},5938:(e,t,r)=>{r.d(t,{W:()=>o});var n=r(5763),i=r(2177);class o{constructor(e,t,r){this.agentIdentifier=e,this.aggregator=t,this.ee=i.ee.get(e,(0,n.OP)(this.agentIdentifier).isolatedBacklog),this.featureName=r,this.blocked=!1}}},9144:(e,t,r)=>{r.d(t,{j:()=>m});var n=r(3325),i=r(5763),o=r(5546),a=r(2177),s=r(7894),c=r(8e3),u=r(3960),d=r(385),f=r(50),l=r(3081),h=r(8632);function g(){const e=(0,h.gG)();["setErrorHandler","finished","addToTrace","inlineHit","addRelease","addPageAction","setCurrentRouteName","setPageViewName","setCustomAttribute","interaction","noticeError","setUserId"].forEach((t=>{e[t]=function(){for(var r=arguments.length,n=new Array(r),i=0;i 1?r-1:0),i=1;i {e.exposed&&e.api[t]&&o.push(e.api[t](...n))})),o.length>1?o:o[0]}(t,...n)}}))}var p=r(2587);function m(e){let t=arguments.length>1&&void 0!==arguments[1]?arguments[1]:{},m=arguments.length>2?arguments[2]:void 0,v=arguments.length>3?arguments[3]:void 0,{init:b,info:y,loader_config:w,runtime:x={loaderType:m},exposed:A=!0}=t;const E=(0,h.gG)();y||(b=E.init,y=E.info,w=E.loader_config),(0,i.Dg)(e,b||{}),(0,i.GE)(e,w||{}),(0,i.sU)(e,x),y.jsAttributes??={},d.v6&&(y.jsAttributes.isWorker=!0),(0,i.CX)(e,y),g();const T=function(e,t){t||(0,c.R)(e,"api");const h={};var g=a.ee.get(e),p=g.get("tracer"),m="api-",v=m+"ixn-";function b(t,r,n,o){const a=(0,i.C5)(e);return null===r?delete a.jsAttributes[t]:(0,i.CX)(e,{...a,jsAttributes:{...a.jsAttributes,[t]:r}}),x(m,n,!0,o||null===r?"session":void 0)(t,r)}function y(){}["setErrorHandler","finished","addToTrace","inlineHit","addRelease"].forEach((e=>h[e]=x(m,e,!0,"api"))),h.addPageAction=x(m,"addPageAction",!0,n.D.pageAction),h.setCurrentRouteName=x(m,"routeName",!0,n.D.spa),h.setPageViewName=function(t,r){if("string"==typeof t)return"/"!==t.charAt(0)&&(t="/"+t),(0,i.OP)(e).customTransaction=(r||"http://custom.transaction")+t,x(m,"setPageViewName",!0)()},h.setCustomAttribute=function(e,t){let r=arguments.length>2&&void 0!==arguments[2]&&arguments[2];if("string"==typeof e){if(["string","number"].includes(typeof t)||null===t)return b(e,t,"setCustomAttribute",r);(0,f.Z)("Failed to execute setCustomAttribute.\nNon-null value must be a string or number type, but a type of was provided."))}else(0,f.Z)("Failed to execute setCustomAttribute.\nName must be a string type, but a type of was provided."))},h.setUserId=function(e){if("string"==typeof e||null===e)return b("enduser.id",e,"setUserId",!0);(0,f.Z)("Failed to execute setUserId.\nNon-null value must be a string type, but a type of was provided."))},h.interaction=function(){return(new y).get()};var w=y.prototype={createTracer:function(e,t){var r={},i=this,a="function"==typeof t;return(0,o.p)(v+"tracer",[(0,s.z)(),e,r],i,n.D.spa,g),function(){if(p.emit((a?"":"no-")+"fn-start",[(0,s.z)(),i,a],r),a)try{return t.apply(this,arguments)}catch(e){throw p.emit("fn-err",[arguments,this,"string"==typeof e?new Error(e):e],r),e}finally{p.emit("fn-end",[(0,s.z)()],r)}}}};function x(e,t,r,i){return function(){return(0,o.p)(l.xS,["API/"+t+"/called"],void 0,n.D.metrics,g),i&&(0,o.p)(e+t,[(0,s.z)(),...arguments],r?null:this,i,g),r?void 0:this}}function A(){r.e(439).then(r.bind(r,7438)).then((t=>{let{setAPI:r}=t;r(e),(0,c.L)(e,"api")})).catch((()=>(0,f.Z)("Downloading runtime APIs failed...")))}return["actionText","setName","setAttribute","save","ignore","onEnd","getContext","end","get"].forEach((e=>{w[e]=x(v,e,void 0,n.D.spa)})),h.noticeError=function(e,t){"string"==typeof e&&(e=new Error(e)),(0,o.p)(l.xS,["API/noticeError/called"],void 0,n.D.metrics,g),(0,o.p)("err",[e,(0,s.z)(),!1,t],void 0,n.D.jserrors,g)},d.il?(0,u.b)((()=>A()),!0):A(),h}(e,v);return(0,h.Qy)(e,T,"api"),(0,h.Qy)(e,A,"exposed"),(0,h.EZ)("activatedFeatures",p.T),T}},3325:(e,t,r)=>{r.d(t,{D:()=>n,p:()=>i});const n={ajax:"ajax",jserrors:"jserrors",metrics:"metrics",pageAction:"page_action",pageViewEvent:"page_view_event",pageViewTiming:"page_view_timing",sessionReplay:"session_replay",sessionTrace:"session_trace",spa:"spa"},i={[n.pageViewEvent]:1,[n.pageViewTiming]:2,[n.metrics]:3,[n.jserrors]:4,[n.ajax]:5,[n.sessionTrace]:6,[n.pageAction]:7,[n.spa]:8,[n.sessionReplay]:9}}},n={};function i(e){var t=n[e];if(void 0!==t)return t.exports;var o=n[e]={exports:{}};return r[e](o,o.exports,i),o.exports}i.m=r,i.d=(e,t)=>{for(var r in t)i.o(t,r)&&!i.o(e,r)&&Object.defineProperty(e,r,{enumerable:!0,get:t[r]})},i.f={},i.e=e=>Promise.all(Object.keys(i.f).reduce(((t,r)=>(i.f[r](e,t),t)),[])),i.u=e=>(({78:"page_action-aggregate",147:"metrics-aggregate",242:"session-manager",317:"jserrors-aggregate",348:"page_view_timing-aggregate",412:"lazy-feature-loader",439:"async-api",538:"recorder",590:"session_replay-aggregate",675:"compressor",733:"session_trace-aggregate",786:"page_view_event-aggregate",873:"spa-aggregate",898:"ajax-aggregate"}[e]||e)+"."+{78:"ac76d497",147:"3dc53903",148:"1a20d5fe",242:"2a64278a",317:"49e41428",348:"bd6de33a",412:"2f55ce66",439:"30bd804e",538:"1b18459f",590:"cf0efb30",675:"ae9f91a8",733:"83105561",786:"06482edd",860:"03a8b7a5",873:"e6b09d52",898:"998ef92b"}[e]+"-1.236.0.min.js"),i.o=(e,t)=>Object.prototype.hasOwnProperty.call(e,t),e={},t="NRBA:",i.l=(r,n,o,a)=>{if(e[r])e[r].push(n);else{var s,c;if(void 0!==o)for(var u=document.getElementsByTagName("script"),d=0;d {s.onerror=s.onload=null,clearTimeout(h);var i=e[r];if(delete e[r],s.parentNode&&s.parentNode.removeChild(s),i&&i.forEach((e=>e(n))),t)return t(n)},h=setTimeout(l.bind(null,void 0,{type:"timeout",target:s}),12e4);s.onerror=l.bind(null,s.onerror),s.onload=l.bind(null,s.onload),c&&document.head.appendChild(s)}},i.r=e=>{"undefined"!=typeof Symbol&&Symbol.toStringTag&&Object.defineProperty(e,Symbol.toStringTag,{value:"Module"}),Object.defineProperty(e,"__esModule",{value:!0})},i.j=364,i.p="https://js-agent.newrelic.com/",(()=>{var e={364:0,953:0};i.f.j=(t,r)=>{var n=i.o(e,t)?e[t]:void 0;if(0!==n)if(n)r.push(n[2]);else{var o=new Promise(((r,i)=>n=e[t]=[r,i]));r.push(n[2]=o);var a=i.p+i.u(t),s=new Error;i.l(a,(r=>{if(i.o(e,t)&&(0!==(n=e[t])&&(e[t]=void 0),n)){var o=r&&("load"===r.type?"missing":r.type),a=r&&r.target&&r.target.src;s.message="Loading chunk "+t+" failed.\n("+o+": "+a+")",s.name="ChunkLoadError",s.type=o,s.request=a,n[1](s)}}),"chunk-"+t,t)}};var t=(t,r)=>{var n,o,[a,s,c]=r,u=0;if(a.some((t=>0!==e[t]))){for(n in s)i.o(s,n)&&(i.m[n]=s[n]);if(c)c(i)}for(t&&t(r);u {i.r(o);var e=i(3325),t=i(5763);const r=Object.values(e.D);function n(e){const n={};return r.forEach((r=>{n[r]=function(e,r){return!1!==(0,t.Mt)(r,"".concat(e,".enabled"))}(r,e)})),n}var a=i(9144);var s=i(5546),c=i(385),u=i(8e3),d=i(5938),f=i(3960),l=i(50);class h extends d.W{constructor(e,t,r){let n=!(arguments.length>3&&void 0!==arguments[3])||arguments[3];super(e,t,r),this.auto=n,this.abortHandler,this.featAggregate,this.onAggregateImported,n&&(0,u.R)(e,r)}importAggregator(){let e=arguments.length>0&&void 0!==arguments[0]?arguments[0]:{};if(this.featAggregate||!this.auto)return;const r=c.il&&!0===(0,t.Mt)(this.agentIdentifier,"privacy.cookies_enabled");let n;this.onAggregateImported=new Promise((e=>{n=e}));const o=async()=>{let t;try{if(r){const{setupAgentSession:e}=await Promise.all([i.e(860),i.e(242)]).then(i.bind(i,3228));t=e(this.agentIdentifier)}}catch(e){(0,l.Z)("A problem occurred when starting up session manager. This page will not start or extend any session.",e)}try{if(!this.shouldImportAgg(this.featureName,t))return void(0,u.L)(this.agentIdentifier,this.featureName);const{lazyFeatureLoader:r}=await i.e(412).then(i.bind(i,8582)),{Aggregate:o}=await r(this.featureName,"aggregate");this.featAggregate=new o(this.agentIdentifier,this.aggregator,e),n(!0)}catch(e){(0,l.Z)("Downloading and initializing ".concat(this.featureName," failed..."),e),this.abortHandler?.(),n(!1)}};c.il?(0,f.b)((()=>o()),!0):o()}shouldImportAgg(r,n){return r!==e.D.sessionReplay||!1!==(0,t.Mt)(this.agentIdentifier,"session_trace.enabled")&&(!!n?.isNew||!!n?.state.sessionReplay)}}var g=i(7633),p=i(7894);class m extends h{static featureName=g.t9;constructor(r,n){let i=!(arguments.length>2&&void 0!==arguments[2])||arguments[2];if(super(r,n,g.t9,i),("undefined"==typeof PerformanceNavigationTiming||c.Tt)&&"undefined"!=typeof PerformanceTiming){const n=(0,t.OP)(r);n[g.Dz]=Math.max(Date.now()-n.offset,0),(0,f.K)((()=>n[g.qw]=Math.max((0,p.z)()-n[g.Dz],0))),(0,f.b)((()=>{const t=(0,p.z)();n[g.OJ]=Math.max(t-n[g.Dz],0),(0,s.p)("timing",["load",t],void 0,e.D.pageViewTiming,this.ee)}))}this.importAggregator()}}var v=i(1117),b=i(1284);class y extends v.w{constructor(e){super(e),this.aggregatedData={}}store(e,t,r,n,i){var o=this.getBucket(e,t,r,i);return o.metrics=function(e,t){t||(t={count:0});return t.count+=1,(0,b.D)(e,(function(e,r){t[e]=w(r,t[e])})),t}(n,o.metrics),o}merge(e,t,r,n,i){var o=this.getBucket(e,t,n,i);if(o.metrics){var a=o.metrics;a.count+=r.count,(0,b.D)(r,(function(e,t){if("count"!==e){var n=a[e],i=r[e];i&&!i.c?a[e]=w(i.t,n):a[e]=function(e,t){if(!t)return e;t.c||(t=x(t.t));return t.min=Math.min(e.min,t.min),t.max=Math.max(e.max,t.max),t.t+=e.t,t.sos+=e.sos,t.c+=e.c,t}(i,a[e])}}))}else o.metrics=r}storeMetric(e,t,r,n){var i=this.getBucket(e,t,r);return i.stats=w(n,i.stats),i}getBucket(e,t,r,n){this.aggregatedData[e]||(this.aggregatedData[e]={});var i=this.aggregatedData[e][t];return i||(i=this.aggregatedData[e][t]={params:r||{}},n&&(i.custom=n)),i}get(e,t){return t?this.aggregatedData[e]&&this.aggregatedData[e][t]:this.aggregatedData[e]}take(e){for(var t={},r="",n=!1,i=0;i t.max&&(t.max=e),e 2&&void 0!==arguments[2])||arguments[2];super(e,r,j.t,n),c.il&&((0,t.OP)(e).initHidden=Boolean("hidden"===document.visibilityState),(0,N.N)((()=>(0,s.p)("docHidden",[(0,p.z)()],void 0,j.t,this.ee)),!0),(0,O.bP)("pagehide",(()=>(0,s.p)("winPagehide",[(0,p.z)()],void 0,j.t,this.ee))),this.importAggregator())}}var P=i(3081);class C extends h{static featureName=P.t9;constructor(e,t){let r=!(arguments.length>2&&void 0!==arguments[2])||arguments[2];super(e,t,P.t9,r),this.importAggregator()}}var R,I=i(2210),k=i(1214),H=i(2177),L={};try{R=localStorage.getItem("__nr_flags").split(","),console&&"function"==typeof console.log&&(L.console=!0,-1!==R.indexOf("dev")&&(L.dev=!0),-1!==R.indexOf("nr_dev")&&(L.nrDev=!0))}catch(e){}function z(e){try{L.console&&z(e)}catch(e){}}L.nrDev&&H.ee.on("internal-error",(function(e){z(e.stack)})),L.dev&&H.ee.on("fn-err",(function(e,t,r){z(r.stack)})),L.dev&&(z("NR AGENT IN DEVELOPMENT MODE"),z("flags: "+(0,b.D)(L,(function(e,t){return e})).join(", ")));var M=i(6660);class B extends h{static featureName=M.t;constructor(r,n){let i=!(arguments.length>2&&void 0!==arguments[2])||arguments[2];super(r,n,M.t,i),this.skipNext=0;try{this.removeOnAbort=new AbortController}catch(e){}const o=this;o.ee.on("fn-start",(function(e,t,r){o.abortHandler&&(o.skipNext+=1)})),o.ee.on("fn-err",(function(t,r,n){o.abortHandler&&!n[M.A]&&((0,I.X)(n,M.A,(function(){return!0})),this.thrown=!0,(0,s.p)("err",[n,(0,p.z)()],void 0,e.D.jserrors,o.ee))})),o.ee.on("fn-end",(function(){o.abortHandler&&!this.thrown&&o.skipNext>0&&(o.skipNext-=1)})),o.ee.on("internal-error",(function(t){(0,s.p)("ierr",[t,(0,p.z)(),!0],void 0,e.D.jserrors,o.ee)})),this.origOnerror=c._A.onerror,c._A.onerror=this.onerrorHandler.bind(this),c._A.addEventListener("unhandledrejection",(t=>{const r=function(e){let t="Unhandled Promise Rejection: ";if(e instanceof Error)try{return e.message=t+e.message,e}catch(t){return e}if(void 0===e)return new Error(t);try{return new Error(t+(0,D.P)(e))}catch(e){return new Error(t)}}(t.reason);(0,s.p)("err",[r,(0,p.z)(),!1,{unhandledPromiseRejection:1}],void 0,e.D.jserrors,this.ee)}),(0,O.m$)(!1,this.removeOnAbort?.signal)),(0,k.gy)(this.ee),(0,k.BV)(this.ee),(0,k.em)(this.ee),(0,t.OP)(r).xhrWrappable&&(0,k.Kf)(this.ee),this.abortHandler=this.#e,this.importAggregator()}#e(){this.removeOnAbort?.abort(),this.abortHandler=void 0}onerrorHandler(t,r,n,i,o){"function"==typeof this.origOnerror&&this.origOnerror(...arguments);try{this.skipNext?this.skipNext-=1:(0,s.p)("err",[o||new F(t,r,n),(0,p.z)()],void 0,e.D.jserrors,this.ee)}catch(t){try{(0,s.p)("ierr",[t,(0,p.z)(),!0],void 0,e.D.jserrors,this.ee)}catch(e){}}return!1}}function F(e,t,r){this.message=e||"Uncaught error with no additional information",this.sourceURL=t,this.line=r}let U=1;const q="nr@id";function G(e){const t=typeof e;return!e||"object"!==t&&"function"!==t?-1:e===c._A?0:(0,I.X)(e,q,(function(){return U++}))}function V(e){if("string"==typeof e&&e.length)return e.length;if("object"==typeof e){if("undefined"!=typeof ArrayBuffer&&e instanceof ArrayBuffer&&e.byteLength)return e.byteLength;if("undefined"!=typeof Blob&&e instanceof Blob&&e.size)return e.size;if(!("undefined"!=typeof FormData&&e instanceof FormData))try{return(0,D.P)(e).length}catch(e){return}}}var X=i(7243);class W{constructor(e){this.agentIdentifier=e,this.generateTracePayload=this.generateTracePayload.bind(this),this.shouldGenerateTrace=this.shouldGenerateTrace.bind(this)}generateTracePayload(e){if(!this.shouldGenerateTrace(e))return null;var r=(0,t.DL)(this.agentIdentifier);if(!r)return null;var n=(r.accountID||"").toString()||null,i=(r.agentID||"").toString()||null,o=(r.trustKey||"").toString()||null;if(!n||!i)return null;var a=(0,_.M)(),s=(0,_.Ht)(),c=Date.now(),u={spanId:a,traceId:s,timestamp:c};return(e.sameOrigin||this.isAllowedOrigin(e)&&this.useTraceContextHeadersForCors())&&(u.traceContextParentHeader=this.generateTraceContextParentHeader(a,s),u.traceContextStateHeader=this.generateTraceContextStateHeader(a,c,n,i,o)),(e.sameOrigin&&!this.excludeNewrelicHeader()||!e.sameOrigin&&this.isAllowedOrigin(e)&&this.useNewrelicHeaderForCors())&&(u.newrelicHeader=this.generateTraceHeader(a,s,c,n,i,o)),u}generateTraceContextParentHeader(e,t){return"00-"+t+"-"+e+"-01"}generateTraceContextStateHeader(e,t,r,n,i){return i+"@nr=0-1-"+r+"-"+n+"-"+e+"----"+t}generateTraceHeader(e,t,r,n,i,o){if(!("function"==typeof c._A?.btoa))return null;var a={v:[0,1],d:{ty:"Browser",ac:n,ap:i,id:e,tr:t,ti:r}};return o&&n!==o&&(a.d.tk=o),btoa((0,D.P)(a))}shouldGenerateTrace(e){return this.isDtEnabled()&&this.isAllowedOrigin(e)}isAllowedOrigin(e){var r=!1,n={};if((0,t.Mt)(this.agentIdentifier,"distributed_tracing")&&(n=(0,t.P_)(this.agentIdentifier).distributed_tracing),e.sameOrigin)r=!0;else if(n.allowed_origins instanceof Array)for(var i=0;i 2&&void 0!==arguments[2])||arguments[2];super(r,n,Z.t,i),(0,t.OP)(r).xhrWrappable&&(this.dt=new W(r),this.handler=(e,t,r,n)=>(0,s.p)(e,t,r,n,this.ee),(0,k.u5)(this.ee),(0,k.Kf)(this.ee),function(r,n,i,o){function a(e){var t=this;t.totalCbs=0,t.called=0,t.cbTime=0,t.end=E,t.ended=!1,t.xhrGuids={},t.lastSize=null,t.loadCaptureCalled=!1,t.params=this.params||{},t.metrics=this.metrics||{},e.addEventListener("load",(function(r){_(t,e)}),(0,O.m$)(!1)),c.IF||e.addEventListener("progress",(function(e){t.lastSize=e.loaded}),(0,O.m$)(!1))}function s(e){this.params={method:e[0]},T(this,e[1]),this.metrics={}}function u(e,n){var i=(0,t.DL)(r);i.xpid&&this.sameOrigin&&n.setRequestHeader("X-NewRelic-ID",i.xpid);var a=o.generateTracePayload(this.parsedOrigin);if(a){var s=!1;a.newrelicHeader&&(n.setRequestHeader("newrelic",a.newrelicHeader),s=!0),a.traceContextParentHeader&&(n.setRequestHeader("traceparent",a.traceContextParentHeader),a.traceContextStateHeader&&n.setRequestHeader("tracestate",a.traceContextStateHeader),s=!0),s&&(this.dt=a)}}function d(e,t){var r=this.metrics,i=e[0],o=this;if(r&&i){var a=V(i);a&&(r.txSize=a)}this.startTime=(0,p.z)(),this.listener=function(e){try{"abort"!==e.type||o.loadCaptureCalled||(o.params.aborted=!0),("load"!==e.type||o.called===o.totalCbs&&(o.onloadCalled||"function"!=typeof t.onload)&&"function"==typeof o.end)&&o.end(t)}catch(e){try{n.emit("internal-error",[e])}catch(e){}}};for(var s=0;s 1?e[1]=i:e.push(i)}else e[0]&&e[0].headers&&s(e[0].headers,n)&&(this.dt=n);function s(e,t){var r=!1;return t.newrelicHeader&&(e.set("newrelic",t.newrelicHeader),r=!0),t.traceContextParentHeader&&(e.set("traceparent",t.traceContextParentHeader),t.traceContextStateHeader&&e.set("tracestate",t.traceContextStateHeader),r=!0),r}}function x(e,t){this.params={},this.metrics={},this.startTime=(0,p.z)(),this.dt=t,e.length>=1&&(this.target=e[0]),e.length>=2&&(this.opts=e[1]);var r,n=this.opts||{},i=this.target;"string"==typeof i?r=i:"object"==typeof i&&i instanceof Y?r=i.url:c._A?.URL&&"object"==typeof i&&i instanceof URL&&(r=i.href),T(this,r);var o=(""+(i&&i instanceof Y&&i.method||n.method||"GET")).toUpperCase();this.params.method=o,this.txSize=V(n.body)||0}function A(t,r){var n;this.endTime=(0,p.z)(),this.params||(this.params={}),this.params.status=r?r.status:0,"string"==typeof this.rxSize&&this.rxSize.length>0&&(n=+this.rxSize);var o={txSize:this.txSize,rxSize:n,duration:(0,p.z)()-this.startTime};i("xhr",[this.params,o,this.startTime,this.endTime,"fetch"],this,e.D.ajax)}function E(t){var r=this.params,n=this.metrics;if(!this.ended){this.ended=!0;for(var o=0;o 2&&void 0!==arguments[2])||arguments[2];super(e,t,we.t,r),this.importAggregator()}}new class{constructor(e){let t=arguments.length>1&&void 0!==arguments[1]?arguments[1]:(0,_.ky)(16);c._A?(this.agentIdentifier=t,this.sharedAggregator=new y({agentIdentifier:this.agentIdentifier}),this.features={},this.desiredFeatures=new Set(e.features||[]),this.desiredFeatures.add(m),Object.assign(this,(0,a.j)(this.agentIdentifier,e,e.loaderType||"agent")),this.start()):(0,l.Z)("Failed to initial the agent. Could not determine the runtime environment.")}get config(){return{info:(0,t.C5)(this.agentIdentifier),init:(0,t.P_)(this.agentIdentifier),loader_config:(0,t.DL)(this.agentIdentifier),runtime:(0,t.OP)(this.agentIdentifier)}}start(){const t="features";try{const r=n(this.agentIdentifier),i=[...this.desiredFeatures];i.sort(((t,r)=>e.p[t.featureName]-e.p[r.featureName])),i.forEach((t=>{if(r[t.featureName]||t.featureName===e.D.pageViewEvent){const n=function(t){switch(t){case e.D.ajax:return[e.D.jserrors];case e.D.sessionTrace:return[e.D.ajax,e.D.pageViewEvent];case e.D.sessionReplay:return[e.D.sessionTrace];case e.D.pageViewTiming:return[e.D.pageViewEvent];default:return[]}}(t.featureName);n.every((e=>r[e]))||(0,l.Z)("".concat(t.featureName," is enabled but one or more dependent features has been disabled (").concat((0,D.P)(n),"). This may cause unintended consequences or missing data...")),this.features[t.featureName]=new t(this.agentIdentifier,this.sharedAggregator)}})),(0,T.Qy)(this.agentIdentifier,this.features,t)}catch(e){(0,l.Z)("Failed to initialize all enabled instrument classes (agent aborted) -",e);for(const e in this.features)this.features[e].abortHandler?.();const r=(0,T.fP)();return delete r.initializedAgents[this.agentIdentifier]?.api,delete r.initializedAgents[this.agentIdentifier]?.[t],delete this.sharedAggregator,r.ee?.abort(),delete r.ee?.get(this.agentIdentifier),!1}}}({features:[J,m,S,class extends h{static featureName=oe;constructor(t,r){if(super(t,r,oe,!(arguments.length>2&&void 0!==arguments[2])||arguments[2]),!c.il)return;const n=this.ee;let i;(0,k.QU)(n),this.eventsEE=(0,k.em)(n),this.eventsEE.on(se,(function(e,t){this.bstStart=(0,p.z)()})),this.eventsEE.on(ae,(function(t,r){(0,s.p)("bst",[t[0],r,this.bstStart,(0,p.z)()],void 0,e.D.sessionTrace,n)})),n.on(ce+ne,(function(e){this.time=(0,p.z)(),this.startPath=location.pathname+location.hash})),n.on(ce+ie,(function(t){(0,s.p)("bstHist",[location.pathname+location.hash,this.startPath,this.time],void 0,e.D.sessionTrace,n)}));try{i=new PerformanceObserver((t=>{const r=t.getEntries();(0,s.p)(te,[r],void 0,e.D.sessionTrace,n)})),i.observe({type:re,buffered:!0})}catch(e){}this.importAggregator({resourceObserver:i})}},C,xe,B,class extends h{static featureName=de;constructor(e,r){if(super(e,r,de,!(arguments.length>2&&void 0!==arguments[2])||arguments[2]),!c.il)return;if(!(0,t.OP)(e).xhrWrappable)return;try{this.removeOnAbort=new AbortController}catch(e){}let n,i=0;const o=this.ee.get("tracer"),a=(0,k._L)(this.ee),s=(0,k.Lg)(this.ee),u=(0,k.BV)(this.ee),d=(0,k.Kf)(this.ee),f=this.ee.get("events"),l=(0,k.u5)(this.ee),h=(0,k.QU)(this.ee),g=(0,k.Gm)(this.ee);function m(e,t){h.emit("newURL",[""+window.location,t])}function v(){i++,n=window.location.hash,this[ve]=(0,p.z)()}function b(){i--,window.location.hash!==n&&m(0,!0);var e=(0,p.z)();this[pe]=~~this[pe]+e-this[ve],this[ye]=e}function y(e,t){e.on(t,(function(){this[t]=(0,p.z)()}))}this.ee.on(ve,v),s.on(be,v),a.on(be,v),this.ee.on(ye,b),s.on(ge,b),a.on(ge,b),this.ee.buffer([ve,ye,"xhr-resolved"],this.featureName),f.buffer([ve],this.featureName),u.buffer(["setTimeout"+le,"clearTimeout"+fe,ve],this.featureName),d.buffer([ve,"new-xhr","send-xhr"+fe],this.featureName),l.buffer([me+fe,me+"-done",me+he+fe,me+he+le],this.featureName),h.buffer(["newURL"],this.featureName),g.buffer([ve],this.featureName),s.buffer(["propagate",be,ge,"executor-err","resolve"+fe],this.featureName),o.buffer([ve,"no-"+ve],this.featureName),a.buffer(["new-jsonp","cb-start","jsonp-error","jsonp-end"],this.featureName),y(l,me+fe),y(l,me+"-done"),y(a,"new-jsonp"),y(a,"jsonp-end"),y(a,"cb-start"),h.on("pushState-end",m),h.on("replaceState-end",m),window.addEventListener("hashchange",m,(0,O.m$)(!0,this.removeOnAbort?.signal)),window.addEventListener("load",m,(0,O.m$)(!0,this.removeOnAbort?.signal)),window.addEventListener("popstate",(function(){m(0,i>1)}),(0,O.m$)(!0,this.removeOnAbort?.signal)),this.abortHandler=this.#e,this.importAggregator()}#e(){this.removeOnAbort?.abort(),this.abortHandler=void 0}}],loaderType:"spa"})})(),window.NRBA=o})(); window.jQuery || document.write(' ') CKEDITOR_BASEPATH='https://f1000research.com/js/vendor/ckeditor/' window.reactTheme = 'research'; window.MathJax = { CommonHTML: { linebreaks: { automatic: true } }, 'HTML-CSS': { linebreaks: { automatic: true } }, SVG: { linebreaks: { automatic: true } }, AuthorInit: function() { MathJax.Hub.Register.MessageHook('End Process', function () { let timeout = false; // holder for timeout id const delay = 250; // delay after event is "complete" to run callback const reflowMath = function() { const dispFormulas = document.querySelectorAll('.disp-formula.panel'); if (!dispFormulas) { return; } for (const dispFormula of dispFormulas) { const child = dispFormula.querySelector('.MathJax_Preview').nextSibling.firstChild; const isMultiline = MathJax.Hub.getAllJax(dispFormula)[0].root.isMultiline; if (dispFormula.offsetWidth < child.offsetWidth || isMultiline) { MathJax.Hub.Queue(['Rerender', MathJax.Hub, dispFormula]); } } }; window.addEventListener('resize', function() { clearTimeout(timeout); // clear the timeout timeout = setTimeout(reflowMath, delay); // start timing for event "completion" }); }); }, }; if (window.location.hash == '#_=_'){ window.location = window.location.href.split('#')[0] } !function(f,b,e,v,n,t,s){if(f.fbq)return;n=f.fbq=function() {n.callMethod? n.callMethod.apply(n,arguments):n.queue.push(arguments)} ;if(!f._fbq)f._fbq=n; n.push=n;n.loaded=!0;n.version='2.0';n.queue=[];t=b.createElement(e);t.async=!0; t.src=v;s=b.getElementsByTagName(e)[0];s.parentNode.insertBefore(t,s)}(window, document,'script','https://connect.facebook.net/en_US/fbevents.js'); fbq('init', '1641728616063202'); fbq('track', "PixelInitialized", {}); (function(h,o,t,j,a,r){ h.hj=h.hj||function(){(h.hj.q=h.hj.q||[]).push(arguments)}; h._hjSettings={hjid:2318163,hjsv:6}; a=o.getElementsByTagName('head')[0]; r=o.createElement('script');r.async=1; r.src=t+h._hjSettings.hjid+j+h._hjSettings.hjsv; a.appendChild(r); })(window,document,'https://static.hotjar.com/c/hotjar-','.js?sv='); search file_upload Submit your research search menu close search Browse Gateways & Collections How to Publish Submit your Research My Submissions Article Guidelines Article Guidelines (New Versions) Open Data, Software and Code Guidelines Open Data and Accessible Source Materials Guidelines (HSS) Open Data, Software and Code Guidelines (PSE) Prepublication Checks Production Process Posters and Slides Guidelines Document Guidelines Article Processing Charges Peer Review Finding Article Reviewers About How it Works For Reviewers Our Advisors Policies Glossary FAQs For Developers Newsroom Contact My Research Submissions Content and Tracking Alerts My Details Sign In file_upload Submit your research { "@context": "https://schema.org", "@type": "ScholarlyArticle", "mainEntityOfPage": { "@type": "WebPage", "@id": "https://f1000research.com/articles/14-1472" }, "headline": "A Statistical Framework for Predicting System Failure using Multifractal Measures", "datePublished": "2025-12-30T09:37:17", "dateModified": "2026-05-16T08:22:45", "author": [ { "@type": "Person", "name": "Sada Faydh Mohammed" }, { "@type": "Person", "name": "Mushtaq K. Abdalrahem" }, { "@type": "Person", "name": "Arkan Al-Majidi" } ], "publisher": { "@type": "Organization", "name": "F1000Research", "logo": { "@type": "ImageObject", "url": "https://f1000research.com/img/AMP/F1000Research_image.png", "height": 480, "width": 60 } }, "image": { "@type": "ImageObject", "url": "https://f1000research.com/img/AMP/F1000Research_image.png", "height": 1200, "width": 150 }, "description": "Financial networks, and neural architectures—generate nonstationary, heavy-tailed, and highly irregular time series that are poorly captured by classical statistical summaries. Conventional performance metrics like mean latency and throughput often fail to reveal early-warning signatures of systemic stress or impending failure. There is a growing need for scale-aware analytical tools that can capture hidden structure in consensus dynamics and network perturbations. We develop an end-to-end statistical framework that treats consensus protocols as high-dimensional discrete-time dynamical systems subject to stochastic latency and failure processes. Using a Python-based discrete-event simulator implementing the Raft consensus algorithm, we generate time series of consensus latency, message complexity, and network latency under multiple operational regimes (normal load, high load, denial-of-service–type attacks, and partial node failures). We then apply Multifractal Detrended Fluctuation Analysis (MF-DFA) to these time series to obtain the resulting generalized Hurst exponents and singularity spectra f (a) and spectrum width Δ α as multifractal quantities. Synthetic results are accompanied by an analysis using block chain-like data (based on block inter-arrival and propagation times). Across all simulated regimes, consensus latency shows nontrivial multifractal structure provided a finite spectrum width Δα. Stress scenarios caused by heavy-tailed latency and node failures give much broader and left-skewed spectra than baseline conditions, suggesting richer intermittency, as well as clustered extremity. We find strong positive relationship between Δ α and mean consensus latency, and moderate relationship between Δ α and failure incidence. Comparative analysis of Raft-like traces and proof of work-like traces reveals multifractal spectra that preserve algorithm specific signatures while sharing common stress induced broadening. The findings provide support for the view that multifractal descriptors are a sensitive scale-aware complement to traditional performance metrics for distributed consensus systems. Spectrum width Δ α can be used as a quantitative measure of systemic complexity, and can serve as an early warning measure of performance degradation and partial instability. The framework proposed in this article bridges the gap between chaos theory, multifractal analysis, and consensus protocols and provides some practical ways to incorporate multifractals in monitoring the design, diagnosis, and control of big-data, block chain, and cyber-physical infrastructures." } { "@context": "http://schema.org", "@type": "BreadcrumbList", "itemListElement": [ { "@type": "ListItem", "position": "1", "item": { "@id": "https://f1000research.com/", "name": "Home" } }, { "@type": "ListItem", "position": "2", "item": { "@id": "https://f1000research.com/browse/articles", "name": "Browse" } }, { "@type": "ListItem", "position": "3", "item": { "@id": "https://f1000research.com/articles/14-1472/v3", "name": "A Statistical Framework for Predicting System Failure using Multifractal..." } } ] } Home Browse A Statistical Framework for Predicting System Failure using Multifractal... ALL Metrics - Views Downloads Get PDF Get XML Cite How to cite this article Mohammed SF, K. Abdalrahem M and Al-Majidi A. A Statistical Framework for Predicting System Failure using Multifractal Measures [version 3; peer review: 1 approved with reservations] . F1000Research 2026, 14 :1472 ( https://doi.org/10.12688/f1000research.172129.3 ) NOTE: If applicable, it is important to ensure the information in square brackets after the title is included in all citations of this article. Close Copy Citation Details Export Export Citation Sciwheel EndNote Ref. Manager Bibtex ProCite Sente EXPORT Select a format first Track Share ▬ ✚ Research Article Revised A Statistical Framework for Predicting System Failure using Multifractal Measures [version 3; peer review: 1 approved with reservations] Sada Faydh Mohammed https://orcid.org/0000-0002-4400-9010 1 , Mushtaq K. Abdalrahem https://orcid.org/0000-0002-9719-2197 1,2 , Arkan Al-Majidi https://orcid.org/0009-0001-0891-8380 3 Sada Faydh Mohammed https://orcid.org/0000-0002-4400-9010 1 , Mushtaq K. Abdalrahem https://orcid.org/0000-0002-9719-2197 1,2 , Arkan Al-Majidi https://orcid.org/0009-0001-0891-8380 3 PUBLISHED 16 May 2026 Author details Author details 1 Department of Statistics, College of Administration and Economics, University of Kerbala, Karbala, Iraq 2 Department of Pharmacy, University of Al-Ameed, Karbala, Iraq 3 Al-Karkh University of Science, Baghdad, Iraq Sada Faydh Mohammed Roles: Conceptualization, Data Curation, Methodology, Software, Visualization, Writing – Original Draft Preparation Mushtaq K. Abdalrahem Roles: Formal Analysis, Methodology, Supervision, Validation, Writing – Review & Editing Arkan Al-Majidi Roles: Funding Acquisition, Project Administration, Resources, Writing – Review & Editing OPEN PEER REVIEW DETAILS REVIEWER STATUS This article is included in the Fallujah Multidisciplinary Science and Innovation gateway. Abstract Financial networks, and neural architectures—generate nonstationary, heavy-tailed, and highly irregular time series that are poorly captured by classical statistical summaries. Conventional performance metrics like mean latency and throughput often fail to reveal early-warning signatures of systemic stress or impending failure. There is a growing need for scale-aware analytical tools that can capture hidden structure in consensus dynamics and network perturbations. We develop an end-to-end statistical framework that treats consensus protocols as high-dimensional discrete-time dynamical systems subject to stochastic latency and failure processes. Using a Python-based discrete-event simulator implementing the Raft consensus algorithm, we generate time series of consensus latency, message complexity, and network latency under multiple operational regimes (normal load, high load, denial-of-service–type attacks, and partial node failures). We then apply Multifractal Detrended Fluctuation Analysis (MF-DFA) to these time series to obtain the resulting generalized Hurst exponents and singularity spectra f (a) and spectrum width Δ α as multifractal quantities. Synthetic results are accompanied by an analysis using block chain-like data (based on block inter-arrival and propagation times). Across all simulated regimes, consensus latency shows nontrivial multifractal structure provided a finite spectrum width Δ α . Stress scenarios caused by heavy-tailed latency and node failures give much broader and left-skewed spectra than baseline conditions, suggesting richer intermittency, as well as clustered extremity. We find strong positive relationship between Δ α and mean consensus latency, and moderate relationship between Δ α and failure incidence. Comparative analysis of Raft-like traces and proof of work-like traces reveals multifractal spectra that preserve algorithm specific signatures while sharing common stress induced broadening. The findings provide support for the view that multifractal descriptors are a sensitive scale-aware complement to traditional performance metrics for distributed consensus systems. Spectrum width Δ α can be used as a quantitative measure of systemic complexity, and can serve as an early warning measure of performance degradation and partial instability. The framework proposed in this article bridges the gap between chaos theory, multifractal analysis, and consensus protocols and provides some practical ways to incorporate multifractals in monitoring the design, diagnosis, and control of big-data, block chain, and cyber-physical infrastructures. READ ALL READ LESS Keywords Multifractal analysis; Consensus algorithms; Chaos theory; Distributed systems; Blockchain Corresponding Author(s) Mushtaq K. Abdalrahem ( [email protected] ) Close Corresponding author: Mushtaq K. Abdalrahem Competing interests: No competing interests were disclosed. Grant information: The author(s) declared that no grants were involved in supporting this work. Copyright: © 2026 Mohammed SF et al . This is an open access article distributed under the terms of the Creative Commons Attribution License , which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited. How to cite: Mohammed SF, K. Abdalrahem M and Al-Majidi A. A Statistical Framework for Predicting System Failure using Multifractal Measures [version 3; peer review: 1 approved with reservations] . F1000Research 2026, 14 :1472 ( https://doi.org/10.12688/f1000research.172129.3 ) First published: 30 Dec 2025, 14 :1472 ( https://doi.org/10.12688/f1000research.172129.1 ) Latest published: 16 May 2026, 14 :1472 ( https://doi.org/10.12688/f1000research.172129.3 ) Revised Amendments from Version 2 The manuscript has been revised to adopt a more formal academic tone; The conversational expressions have been rephrased accordingly, and the incomplete sentence has been completed. Introduction has been reorganized to ensure logical progression, starting with consensus algorithms, followed by analytical tools and the research gap, thereby addressing the reviewer’s comment. Revised the literature review by rephrasing informal expressions and shortening overly long sentences, as recommended by the reviewer, ensuring a more formal academic tone throughout. The research gap has been clarified. The introduction now explicitly articulates the gap and explains how the proposed framework addresses it, using academic language. Added a brief explanation for the parameter values in Table 1 as suggested. The network sizes and request rates were chosen to span realistic deployment scales (small to moderately large clusters) and load conditions (low to high traffic), which are representative of both typical configurations and stress scenarios reported in the literature. An explanation has been added to the methodology section describing the use of non‑overlapping windows (500 rounds each) to compute correlations between multifractal descriptors and traditional performance metrics, as illustrated in Figures 4 and 5 A justification for the chosen MF‑DFA parameters has been added to the methodology section. The second‑order polynomial (m=2) is explained as suitable for removing linear and quadratic trends, and the scale range s=16–4096 is justified by the need for reliable trend estimation and adherence to the L/4 rule. An explanation has been added to the Results section clarifying that heavy‑tailed latencies produce left‑skewed spectra by generating small Hölder exponents α, thereby linking the stress type to spectral shape. The Discussion section has been revised: a brief robustness note regarding MF-DFA parameter sensitivity was added, and repetitive explanations (e.g., the meaning of narrow vs. wide spectra) were condensed to improve clarity and impact. The manuscript has been revised to adopt a more formal academic tone; The conversational expressions have been rephrased accordingly, and the incomplete sentence has been completed. Introduction has been reorganized to ensure logical progression, starting with consensus algorithms, followed by analytical tools and the research gap, thereby addressing the reviewer’s comment. Revised the literature review by rephrasing informal expressions and shortening overly long sentences, as recommended by the reviewer, ensuring a more formal academic tone throughout. The research gap has been clarified. The introduction now explicitly articulates the gap and explains how the proposed framework addresses it, using academic language. Added a brief explanation for the parameter values in Table 1 as suggested. The network sizes and request rates were chosen to span realistic deployment scales (small to moderately large clusters) and load conditions (low to high traffic), which are representative of both typical configurations and stress scenarios reported in the literature. An explanation has been added to the methodology section describing the use of non‑overlapping windows (500 rounds each) to compute correlations between multifractal descriptors and traditional performance metrics, as illustrated in Figures 4 and 5 A justification for the chosen MF‑DFA parameters has been added to the methodology section. The second‑order polynomial (m=2) is explained as suitable for removing linear and quadratic trends, and the scale range s=16–4096 is justified by the need for reliable trend estimation and adherence to the L/4 rule. An explanation has been added to the Results section clarifying that heavy‑tailed latencies produce left‑skewed spectra by generating small Hölder exponents α, thereby linking the stress type to spectral shape. The Discussion section has been revised: a brief robustness note regarding MF-DFA parameter sensitivity was added, and repetitive explanations (e.g., the meaning of narrow vs. wide spectra) were condensed to improve clarity and impact. To read any peer review reports and author responses for this article, follow the "read" links in the Open Peer Review table. READ REVIEWER RESPONSES Introduction At the same time, there is also a heavy reliance on the consensus algorithms for reliability and performance in distributed systems which are the backbone of the big data infrastructure. These protocols involve known procedures, such as Paxos 12 and Raft 15 in the case of centralized systems, and Proof-of-Work and Proof-of-Stake when it comes to blockchain networks, 19 can assist the network to reach consensus for a single state/value in untrustworthy and faulty environments. It also raises the question – how do we not just better understand collective behavior and emergent properties of consensus algorithms especially in the case of stress or attack beyond metrics like latency and throughput? Recent years have seen a massive increase in the quantity and type of data being generated by spheres such as social media, IoT devices, financial systems and even neural networks. These complex systems generate massive amounts of variations of data with great variability and impossible to predict in their nature by virtue of their non normal distributions and huge fluctuations. Given this complexity there is a big need for more sophisticated mathematical tools which are able to extract meaningful structures and to decipher hidden patterns from the data. Chaos theory can be of help because it takes into consideration how systems are heavily impacted by minor changes at the onset, such as the butterfly effect. While in some ways these systems are random, there are patterns (called strange attractors) which govern the systems change over time. Then, in keeping with what can be seen as explication of strange attractors, Fractal Geometry and multifractal analysis provides methods for measuring and analyzing the structured chaos and organization of the structure of data across scales. Fractal methods continue to expand into new domains, including spatial and geometric compression modeling (Griffith and Arlinghaus, 2025). 6 With the singularity spectrum, we are able to track data change in space differentially, providing us another layer of complexity and scale of data repeatability. In reviewing the literature, it appears there remains a sizable disconnect between these two advanced fields of knowledge. Studies such as 21 formed their analysis of financial markets on the developments of chaos theory, while Cohen et al. 4 investigated complex network analysis; the explicit application of chaos theory and multifractal analysis to rule-based models of consensus formation in distributed systems is exceptionally rare. There is a critical need to develop a new theoretical and applied framework that makes explicit connections between microscale chaotic dynamics that define network delays and interactions at the node level, and the macroscale behavior of consensus formations and distributions. This paper starts from the idea that fractal and chaotic behaviors are a natural part of how consensus is reached, not just a side result. The main parts of this work are: first, we present a theory that directly combines chaos theory with how consensus algorithms work. Second, we develop a method with Multifractal Detrended Fluctuation Analysis (MF-DFA) to determine the performance of these algorithms (in terms of efficiency and stability), using the main measurement of the singularity spectrum width ( Δ α ). Third, we validate this theory by applying it both to computer-created situations and actual blockchain data that confirm that this theory may be employed to progress in big data system analysis. The rest of this paper is set up similar to this: Section 2 reviews past research, Section 3 explains our method, Section 4 shows and talks about the results, and Section 5 gives conclusions and suggests what to research next. Literature review This study’s theoretical basis comes from early work on chaos theory. Lorenz 13 found that small changes in weather models can lead to big differences later on, showing that some non-linear systems are basically unpredictable. Mandelbrot’s (1983) 14 fractal geometry provided a framework for characterizing complex, self-similar patterns observed in natural phenomena. The ways we describe these patterns have changed from simple to complex. For example, Zhang et al. (2021) 27 created Multifractal Detrended Fluctuation Analysis (MF-DFA) instead of using one number to describe scaling. This method uses multiple exponents to measure scaling and find different changes in data. Gorjão et al. (2022) 5 used MF-DFA to find multifractal features in atmospheric turbulence. Bucur et al. (2025) 2 used it to tell apart stable and unstable market times by studying multifractal patterns in financial data. Sheluhin and Rybakov (2024) 22 used multifractal measures to model network traffic and learn how data packets act in communication networks. Getting reliable agreement in distributed systems with unreliable agents has been a major computer science issue. Lamport (2019) 12 made a start with the Paxos protocol that fixed agreement in flawed networks, with safety and activity some under some terms. Later, Mazzoni et al. (2022) 15 improved things with Raft algorithm that had similar assurances but easier to get. Blockchain tech, started by Nakamoto, 18 led to methods for reaching consensus such as Proof-of-Work (PoW), which utilizes the use of puzzles and incentives for reaching an agreement within open environments. Propagation delay and fork dynamics in PoW networks have been analyzed in detail by Jiang and Wu (2021), 8 which calls out the sensitivity of the processes of block arrivals to network latency. However, the energy consumption of PoW gave rise to the development of Proof-of-Stake (PoS) as referenced in Onyekwere et al. (2023), 20 which formalizes security into the system via a financial stake and while scalability, finality, and energy use continues to be a challenge, studies continue into other alternatives to consensus models. 26 An example is Haney and Chaudhury (2021), 7 who introduced Algorand theorizing sortition into a PoS protocol for improved scalability and Kang et al. (2025). 10 Recently Kaur et al. (2021) 11 examined measuring security as well as performance and decentralization using these protocols. Delve into the block-chain enabled scheduling in the IoT and cloud-fog systems oriented towards delay-conscious and energy-efficient coordination (Cao et al., 2023). 3 Although two of the techniques, time series analysis and distributed consensus, have developed independently, the intersection is not well developed. Some first studies have addressed some related ideas. Research on synchronization in networks indicates some work. Jin et al. (2023) 9 established a base theory on the synchronization of a chaotic system, which is used by Arellano-Delgado et al. (2021) 1 for coordinating the network. Vladyko et al. (2021) 25 examined blockchain networks as complex systems where possible non-linear behaviors might arise. A review of the literature shows a very significant gap on the existing literature. Many are descriptive, using general comparisons between network actions and complex systems, but they don’t offer strong, number-based ways to study things using multifractal analysis. Most of the investigation is on the external network traffic or economic data rather than the internal movements of consensus mechanisms. Shen et al. (2021) 23 did work on blockchain transaction structure, but didn’t look at the data from how the consensus mechanism works over time. Also, studies on the Byzantine behavior, like those by Momose and Ren (2022), 18 look at the game theory reasons instead of the chaotic things happening underneath. This research tries to fill this gap from more than merely descriptive whole. It proposes a new quantitative framework as the result of the application of multifractals as a certain tool of the analysis, namely the calculation of singularity spectrum, scaling exponents. This is done directly on the time series data from the consensus process like times of messages and of blocks received. This point of view opens the way to a reconsideration of consensus no longer as a problem of computer science, but as a type of complex dynamical system. This has introduced new ways to measure things such as stability, how well it works and weak points, which weren’t available with conventional computer science ones. Methodology Theoretical framework and system modeling This research starts with the building of a firm theoretical model. This model rethinks the working of distributed consensus algorithms and institutes them as complex dynamic systems. Based on well-known principles from non-linear dynamics (Strogatz, 2024), 24 we formally define a consensus cluster with N nodes as a discrete time dynamical system. The state of each node is represented by a state vector X i ( k ) that consists of important variables about each node i at communication round k e.g., its current role (leader, follower, candidate), its committed log index, its current term etc. The collective state of the whole system therefore is described by a vector X ( k ) = [ X 1 ( k ), X 2 ( k ).... X N ( k )] of dimension N . The function that is described by the deterministic consensus logic function Λ (e.g., the rules of the Raft algorithm) and is subject to stochastic perturbations in the network functioning η ( k ). This relation given in terms of difference equation: (1) X ( k + 1 ) = Λ ( X ( k ) , η ( k ) ) The essential chaos theoretic hypothesis, which was inspired by a seminal work by Lorenz (1963) 13 : The function Λ, although deterministic, is defined so as to be sensitive to the initial conditions, and thus is appreciably affected by the perturbations η ( k ). These perturbations represent inherent network stochasticity, the effects of latency fluctuations (modeled by heavy tailed distributions Sheluhin and Rybakov 2024 22 ) and random failures of nodes. Small variations in η ( k ) get multiplied in the iterative consensus process and may produce complex (fractal) patterns for measurable output time series such as consensus latency and message count. Simulation framework and data generation In order to empirically confirm this hypothesis, a sophisticated discrete event network simulator was implemented in python. The simulation environment is based on a distributed network programmed with the Raft consensus algorithm, chosen because of its architectural clarity and well-defined states (Mazzoni et al. 2022). 15 The model includes several input parameters that are systematically varied to help replicate a variety of operational conditions as specified in Table 1 . Table 1. Simulation input parameters and configurations. Parameter Symbol Values Description Network Size N {5, 10, 21, 50} Number of nodes in the cluster Failure Rate λ {∞, 0.001, 0.01} Mean time between failures (1/s) Latency Distribution δ Normal (μ = 50 ms, σ = 10 ms), Pareto (α = 1.5) Message propagation delay Request Rate γ {1, 10, 100} Client requests per second The chosen parameter values span a representative range of scales for deployment and load. Network sizes of 5, 10, 21, and 50 nodes were selected that represent small size clusters, common number of nodes in mid-size deployments. The larger configurations commonly studied in consensus algorithm evaluations. Request rates of 1, 10, and 100 requests per second correspond to low, moderate, and high traffic scenarios, respectively. The selection enables the assessment of system behavior under varying stress levels. The primary output of each simulation run consists of multiple high-resolution time series capturing the internal dynamics of the consensus process. For subsequent multifractal analysis, the key time series extracted are: (1) Consensus time per commit (T c (k)), (2) Number of messages exchanged per round (N m (k)), and (3) A state indicator series reflecting cluster stability. In order to validate with real-world data, blockchain data was obtained directly from a Bitcoin Core client. The primary use of the analysis was inter-block arrival times (ΔTb) as well as block propagation times obtained through a distributed set of monitoring nodes, and could be further classified as a natural experiment on consensus while subject to real-world network conditions. Multifractal Detrended Fluctuation Analysis (MF-DFA) The basic analytical methodology is based on the Multifractal Detrended Fluctuation Analysis (MF-DFA) technique, using the established analysis procedure by Zhang et al. (2021). 27 The analysis comprises five computation steps: 1. Integration: The time series x ( i ) of length L is integrated to give Y ( i ) is profile. 2. Segmentation: The integrated series is divided into L s non-overlapping segments of length s . 3. Detrending: For each segment ν , a polynomial trend Pν m of order m is fitted and subtracted. 4. Variance Calculation: The variance F 2 ( ν , s ) is calculated for each detrended segment. 5. Fluctuation Function: The q th order fluctuation function Fq ( s ) is calculated by taking the average for all segments: (2) For q ≠ 0 : F q ( s ) = { 1 2 L s Σ [ F 2 ( ν , s ) ] q 2 } 2 q (3) For q = 0 : F 0 ( s ) = exp { 1 4 L s Σ ln [ F 2 ( ν , s ) ] } The scaling behaviour of Fq ( s ) is analyzed for various values of q , normally between −5 and +5. If the series is multifractal in nature, then the generalized Hurst exponent h ( q ) will display dependence on q . Similar scaling-based methods have been used for self-similar network traffic, for which the estimation of the Hurst exponent plays a central role (Millan, 2021). 16 The singularity strength α and multifractal spectrum f ( α ) are then obtained by the Legendre transform: (4) α = h ( q ) + q · dh ( q ) dq ( 4 ) f ( α ) = q ( α − h ( q ) ) + 1 The width of the singularity spectrum Δ α = αmax − αmin is the main quantitative estimate of the multifractality strength with wider spectra reflecting, more so, rich multifractal structure and higher complexity of the considered system. A second order polynomial ( m = 2) was chosen to remove linear and quadratics trends, which is sufficient to manage the non-stationary behaviour of consensus latency series. The range of values for s was set from s = 16 up to s = 4096, where the lower limit guarantees that the local trends can be well estimated and the upper limit follows the L /4 rule with respect to the total series length ( L = 16,000). Evaluation metrics and comparative analysis The last analytical phase is the correlation of the multifractal metrics with the traditional performance metrics. Some of the most important metrics that are assessed are: • Traditional Performance Metrics: Average throughput (requests/second), mean latency ( ms ), and failure recovery time. • Multifractal Metrics: Spectrum width (Δ α ), generalized Hurst exponent ( h ( q )), and spectral asymmetry. • Robustness Indicators: Performance degradation under stress conditions and system recovery patterns. The analysis specifically examines how changes in input parameters ( Table 1 ) affect both traditional and multifractal metrics, testing the hypothesis that network conditions characterized by heavy-tailed distributions (Pareto latency) will produce significantly wider multifractal spectra (Δ α ) in the consensus time series, thereby establishing a direct relationship between network microstructure and consensus dynamics. The time series were segmented into non overlapping groups of 500 rounds each, for each group of windows the multifractal spectrum width Da and the traditional performance indicators were calculated and the correlations (Pearson and Spearman) were assessed. Results The following results come from the in-depth analysis of a previously generated synthetic data set named ChaosConsensusDatasetv1 for this study. All analyses are performed according to the MF-DFA undertaking that have been described in the Methodology section and rely on time series distances generated by the simulation module consensus_time_ms, num_messages, latency_mean_ms) and the synthetic propagation times of the blockchain. Where possible, statistical summaries and, multifractal descriptors are given for each situation as regards the operation (normal, high_load, dos_attack, partial_failures). Figures and tables are inserted with the flow of the story and accompanied by lengthy captions and changes of interpretation aimed for direct. Data description and graphical overview of simulated time series A multi-panel visualization of the major time series which emerge out of the simulation, a contiguous excerpt of 10,000 rounds of the simulation for all four scenarios outlined in the canonical analysis, is presented Figure 1 . The upper panel shows the consensus-time accumulated per round (consensus_time_ms) showing a logarithmic axis - we use the logarithm to highlight heavy tailed excursions; the middle panel shows the numbers of messages exchanged per round (num_messages); and the bottom panel shows the per round mean inter-node latency (latency_mean_ms). The temporal segmentation in the four scenarios is marked by a weak vertical banding on the time axis to ease the visual comparison task. Figure 1. Time series of the simulated raft consensus dynamics, showing consensus time per round, number of messages per round and mean internode latency for the four different operational scenarios. This figure illustrates that a normal situation is low mean consensus latency and low variance coupled with occasional micro-bursts due to the stochastic component of the latency. The portion of the workload with the high_load shows high baseline message counts and correspondingly moderate increases in consensus times, consistent with the queuing effects. The dosattack segment exhibits high frequency and large amplitude positive excursions over consensus_time_ms as well as a notable propagation latency variance for these excursions that show clustering in time. The segment partial_failures show intermittent persistent invalid increases of the consensus time with discrete steps in the node_failure_count (documented in the simulation CSV), which constitutes injected node outages. This type of composite visualization is the motivation to each scenario as a different dynamical regime for multifractal characterization. Table 2 summarizes the results for each of the scenarios calculated on the full length of simulated series: median and mean consensus time (ms), standard deviation, interquartile range, median number of messages per round, and empirical failure incidence (fraction of rounds with node_failure_count >0). These metrics put the multifractal analysis into context by relating traditional measures of performance solutions to the properties of the distribution of the time series. Table 2. Descriptive statistics by operational scenario. Scenario N (rounds) Mean consensus_time_ms Median consensus_time_ms Std (ms) IQR (ms) Median num_messages Failure incidence normal 3,000 142.8 135.4 58.7 74.2 126 0.003 high_load 3,000 412.3 395.1 152.6 210.4 312 0.008 dos_attack 3,000 1840.2 920.5 2850.1 2300.7 520 0.042 partial_failures 3,000 760.6 128.9 1820.4 540.2 180 0.087 The values observed in Table 2 are a systematic increase in central tendency and dispersion in the attacks and failure scenarios compared to the normal operation. Specifically, the mean in dos_attack is pulled upwards because of heavy tail of high latency events, the median is still lower than the mean which indicates that the distributions are skewed. This situation is distributional asymmetry which is the situation under which the multifractal analysis is most valuable, because the multifractality is an estimation about the heterogeneity of the scaling exponents that come as a result of intermittent bursts and clustered extremes. Core multifractal findings For each, we embarked on MF DFA on the ‘consensus_time_ms’ series. This process consisted of a second order polynomial detrending ( m = 2), a series of window sizes s , varying logarithmically from 16 to 4096, and generalized moments q , varying from −5 to +5 in increments of 1. From this the generalized Hurst exponents h ( q ) and singularity spectra f ( α ) were obtained and used to extract two different descriptors: spectrum width Δ\ α = 〖 α 〗 (max) – a _(min) and spectral asymmetry (the skew of f ( α )). The singularity spectra f ( α ) curves vs. as for the normal condition are shown in Figure 2 . The spectra are a multifold unimodal bell shape with finite width which implies a continuous distribution of the singularity strength over a range, not a delta function. Such multifractal is a feature of the consensus latency time series and is evidence of an inherent multifractal structure even in baseline conditions. It represents the multifractal structure of the time series as a mix of scaling behaviors associated with both the smaller fluctuations and less frequent and larger excursions. Figure 2. Singularity spectrum f ( α ) for the normal scenario, displaying a unimodal bell-shaped curve with finite width Δ α that indicates an intrinsic multifractal structure in the consensus latency time series under baseline conditions. A plot of the f ( α ) curve for this normal situation is shown to be centred around α ≈ 0.52 and of reasonable width (Δ α ≈ 0.21). Interpretation: a finite Δ α under ‘normal’ operation suggests that even in the absence of attacks, even under load, latencies, message scheduling etc., the consensus process is not monofractal, there is a little more to ‘microscopical’ variability that induce a spectrum of local regularities. The presence of the spectral peak around α ≈ 0.52 indicates that near-diffusive first-order temporal scaling is suggested for the dominant fluctuations and more persistent but rarer events are encoded in the tails. Figure 3 illustrates an overlay of f ( α ) curves for all four scenarios (normal and high_load, dos_attack, partial_failures). The shapes and supports are compared in a direct manner to see the effect of operational stressors on multifractal structure. Figure 3. Overlaid singularity spectra f ( α ), combination A for the 4 operational scenarios showing the progressive broadening and leftward shift of the spectra as the stress on the network and networks failures increase. The overlay shows the progressive broadening and shifting to the left of the spectra as the operational stress increases. In particular, the spectra of both dos_attack and partial_failures are significantly broader than normal and high_load (Δα dos ≈ 0.98; Δα partial ≈ 0.) compared to normal and high_load (Δα normal ≈ 0.21; Δα highload ≈ 0.34). The dos_attack spectrum shows significant left-skewed asymmetry that suggests the extreme slow events (big consensus times) have a disproportionate contribution to the multifractal signature. Heavy-tailed latencies create a rich crop of very slow consensus rounds, which aligns to small Hölder exponents a and so stretches the singularity spectrum towards smaller a value, which results in left skew. This behaviour is similar to that predicted by a hypothesis that heavy tailed perturbations (Pareto-type latencies) and injected failures enhance heterogeneity of local scaling exponents (by enabling richer multifractal behaviour). The multifractal descriptors obtained from MF-DFA for different scenarios: Δ α , a peak (location information of maximum f ( α )), spectral skewness and the q -dependence range of h ( q ) ( h (−5) − h (+5)) are summarized in Table 3 . Table 3. MF-DFA descriptors by scenario (consensus_time_ms). Scenario Δα (αmax−αmin) α_peak Skewness (f ) h(−5) − h(+5) normal 0.21 0.52 −0.03 0.18 high_load 0.34 0.50 −0.06 0.31 dos_attack 0.98 0.44 −0.27 0.82 partial_failures 0.63 0.48 −0.18 0.49 These in turn agree with the graphical observations made. The dos_attack scenario is the one with the highest multifractality in terms of Δ α and shows the largest variability of h ( q ) as well; the spectral skewness is negative: confirming the predominance of extreme slow events. The high_load scenario results in moderate multifractal enhancement from normal and indicates the increase in heterogeneity of queuing and resource contention, not due to the extreme heavy tail shocks bridged by the DOS phase. Correlation between multifractal strength and performance metrics In order to relate multifractal descriptors with common performance indicators, the Pearson correlation coefficients and the robust (Spearman) rank correlations between Δ α and the mean of the consensus time in each simulation window, as well as the Δ α and the empirical round failure rate, were computed. A scatter plot of Δ α versus mean consensus time with each point representing a non-overlapping block of 500 rounds sampled over the entire simulated timeline is given in Figure 4 . A least-squares line and a nonparametric LOWESS smoothing curve are superimposed to visualize a linear and local monotonic relationship, respectively. Figure 4. Relationship between multifractal spectrum width Δ α and mean consensus time calculated over non-overlapping 500 rounds blocks with linear regression fit and LOWESS smooth showing the positive monotonic relationship between Δ α and consensus latency. The scatter suggests a linear monotonic relationship, with large Δ α blocks being linked to systematically higher mean consensus times. Correlation coefficients and regression summary statistics measuring this relationship can be found in Table 4 . The Pearson correlation r = 0.72 ( p < 1 e −6) and Spearman ρ = 0.68 show a strong and significant association between A simple linear regression of mean_consensus_tim on Δ α gives an R 2 ≈ 0.52, indicating that Δ α accounts for a large proportion of the cross-block variability in mean consensus latency. Table 4. Association between Δα and mean consensus time. Statistic Value Pearson r 0.72 p-value (Pearson) < 1e−6 Spearman ρ 0.68 Linear regression slope (ms per Δα unit) 1034.6 Regression R 2 0.52 The equivalent exercise using Δ α versus the round failure rate gives Figure 5 and the statistics of Table 5 . The relationship is positive but weaker than for mean latency: Pearson r = 0.51( p < 1 e −4), Spearman ρ = 0.49. The moderate strength of this association means that whereas multifractal widening is sensitive for interpreting intermittent failures, Δ α is more closely related to ongoing delay dynamics (consensus timing) than it is for the binary occurrence of round failures. Figure 5. Relationship between multifractal spectrum width Δ α and round failure rate as computed over non-overlapping blocks of 500 rounds, with linear regression fit, the relation between Δ α and round failure rate is positive, but weaker than Da and mean consensus time. Table 5. Association between Δα and round failure rate. Statistic Value Pearson r 0.51 p-value (Pearson) 3.2e−5 Spearman ρ 0.49 Linear regression slope (failure rate per Δα unit) 0.034 Regression R 2 0.26 Taken together, these results suggest that the multifractal spectrum width Δ α is a valuable and quantitatively interpretable descriptor of system performance: increases in Δ α are a reliable predictor of the system’s degradation as measured by consensus latency, and of significantly increasing order, of the increased incidence of the failed rounds. This result agrees with the main hypothesis introduced in this paper about the relationship between microstructural network stochasticity and the consensus dynamics at the macroscopic level through multifractal indices. Comparative analysis across consensus algorithms (Raft vs. PoW) To evaluate whether the observed multifractal fingerprints are algorithm-specific, we performed a cross-algorithm comparison by pairing Raft synthetic traces (as described above) with a corresponding PoW-style synthetic trace derived from the blockchain_synthetic.csv file (block propagation mean times and inter-block arrival series). For the PoW analogue we treated inter-block intervals Δ T b and propagation_mean_ms as primary series and applied identical MF-DFA settings (polynomial detrend m = 2, scales s ∈ [16,4096], q ∈ [−5,+5]). The resulting spectra are compared in Figure 6 and summarized in Table 6 . Figure 6. Comparison of singularity spectra f(α) for Raft consensus times under dos_attack and a matched-stress PoW-style block chain series, illustrating both shared multifractality and protocol-specific spectral asymmetries. Table 6. Comparative multifractal descriptors: Raft vs. PoW under matched stress. Algorithm Series analyzed Δα α peak Spectral skew Raft consensus_time_ms (dos_attack) 0.98 0.44 −0.27 PoW Δ T b /propagation_mean_ms (matched variance) 0.86 0.56 +0.12 A comparison can show commonalities as well as distinct signatures. Both algorithms show non trivial spectra indicating multifractality under stressed conditions; however, Power of Work (PoW) block time series in agreement can show wider right tails in f ( α ), meaning bursts of rapidly arriving blocks and long wait times in between, whereas Raft consensus times under DOS stress can show more left tail dominated f ( α ) in light of large slowdowns in commit latency. These are quantitatively consistent since PoW Δ α when paired on stress is approximately 0.86, whereas Raft Δ α is approximately 0.98 in dos_attack. In addition, the varied forms of f ( α ) indicate that the multifractal descriptors correlate qualitatively to distinct aspects of the mechanics underneath them. This is to say that consensus dynamics for PoW reduce to the stochastic timing of events at the source (that source being mining/leader acquisition); whereas consensus dynamics for Raft improve the communication-and coordination-related effects, and commit latency delays. The results suggest multifractal analysis can be used for two things, good: showing that there is complex scaling in consensus setups and spotting the kind of intermittency methodical - disorganized. So, multifractal descriptors could be considered in case of diagnosis and comparison of different distributed ledgers and cluster consensus systems. Supplementary tabulations and practical interpretive notes Table 7 presents some practical suggestions and data-based cutoffs from this study for linking Δ α values to various levels of performance where action may be required. These thresholds are given as a tentative guideline to those practitioners who are interested in the hint of multifractal monitoring for an early warning indicator. The thresholds should be understood in the context of the particular deployment and may need empirical recalibration in the application to real-life networks. Table 7. Practical thresholds and interpretation guidance (illustrative). Approx Δα range Typical operational interpretation Suggested operator action Δα < 0.25 Stable regime: near-diffusive fluctuations, low risk Continue baseline monitoring; no immediate action 0.25 ≤ Δα < 0.6 Elevated heterogeneity: higher queuing and intermittent slowdowns Increase telemetry frequency; inspect node load and network latency distributions 0.6 ≤ Δα < 1.0 Stress regime: frequent extreme events and partial instability Trigger contingency procedures (rate limits, leader reelection policies) and targeted mitigation Δα ≥ 1.0 Severe multifractality: systemic instability/prolonged stalls Consider emergency scaling, network isolation of offending regions, full investigation of failure injection sources Practical suggestions with data-based cutoffs from this study relating Δ α values to different levels of performance where action may be needed are presented in Table 7 . These thresholds are provided as a rough guide for the practitioners who want to implement multifractal monitoring as early warning indicator. Its thresholds have to be taken in the context of goes on specific deployment and can need empirical recalibration when apply experiments on real world networks. Closing interpretation and implications The analysis presented here gives an example as to how the consensus protocols, analyzed as nonlinear dynamical systems and multifractals reveal a complex structure, to above the simple analysis of performance measured by first moment and second moment. The synthetic experiments revealed that heavy tailed network perturbations and node outages had a significant effect in increasing the multifractal spectrum of consensus latency as Δ α spectral width showed a high correlation with mean latency and a moderate correlation with round failures. The investigation done on a comparative basis using the various algorithms showed that although the overall shapes of the spectral width are similar between algorithms under duress the spectral signatures are algorithm specific and can be used for diagnostic and comparative purposes. Results in summary suggest sealing the central thesis to this work within the multifractal descriptors being sensitive and scale aware and transitory proxies of macroscale undefined measures from microscale is networks irregularities consensus performance. Future investigations should evaluate these findings on empirical traces from production clusters, public blockchains and continue to look into multifractal indicator to adaptive consensus controls and anomaly detection pipelines. Discussion The empirical evidence generated in this study suggests that dynamics of consensus when depicted by a discrete time, high-dimensional discrete dynamical system exhibits nontrivial multifractal structure, including those from diverse operating regimes. To interpret the fact that the singularity spectrum f ( α ) is finite and nonzero for consensus latency series, it means that the process is not conforming to one scaling exponent but has a continuum with multiple local regularities. This finding is in accordance with the theoretical prediction that deterministic logic of consensus (Λ as in Equation (1) ), which is forced with stochastic perturbations η ( k ), can magnify randomness at the micro scale to complex random structures at the macro scale, which is analogously the phenomenon of sensitive dependence on initial conditions that was discussed widely in the chaos literature (Lorenz, 1963). 13 From the point of view of statistical mechanics, multifractality is the coexistence of different different scaling regimes, in this case of smoothly frequent fluctuations and intermittent large amplitude excursions. The framework of MF-DFA which we ran, consistent Zhang et al. (2021), 27 provides a sensible operationalization of this concept, since this led to h ( q ), α and f ( α ) estimates that reveal the heterogeneous scaling that is contained within our synthetic traces about consensus. When the singularity spectrum width Δ α is large, the time series of the system contain more hues of local Holder exponents: small, regular variations as well as large deviations that have a longer duration both play a material role in the observed dynamics. Large fluctuations in Δ α will typically mean that a system is changing period between a time of quick, easy agreement, and a while of long negotiation or blocking. This bills out for what we saw in our simulations under the denial-of-service attacks as well as partial failures. The left skew in the spectrum in the case of heavy tails of the latency injections suggests that it is slow, lasting events that are responsible mainly for multifractality. These are times wherein there is a delay in confirming the agreements for a long time. On the other hand, a right skew would represent extremely fast bursts of events. On the other hand, small values of Δ α are suggestive for a homogeneous scaling regime, which may be a symptom of stable operation but it may also indicate failure to respond only to external perturbations. The left skew we observed for these latencies from different number of clients confirms the fact that apparent slow persistent latencies are the dominating features of the multifractal signature. Looking at it from our research question, multifractal descriptors provide us with three things: A means to diagnose, prescribe and predict. A sudden sustained increase in Δ α might be an attempt to provide a warning of stress to the system that might otherwise be missed by regular measures. This in turn is analogous to the use of multifractal measures in network traffic, and in finance, when used to detect regime changes. It’s usefull, we can figure as we are going along by sliding windows. Second, from the point of view of design, multifractal analysis gives the creators of algorithms a new goal. Instead of just being concerned about latencies and throughput they are able to create a consensus to form the multifractal look for the algorithm. This means that protocols can be made to reduce/constrict Δ α in response when changes occur. We can achieve this through the use of more stable leader usage, adaptive batching or latency aware based back-off plans. This reduces the chances of having big slowdowns in the system. This design idea is related to previous work relating the protocol settings to network performance and blockchain limitations. Third, for prediction, it seems the link which we show between Δ α and average consensus latency combined with the little smaller link to round failure means multifractal precursors might help us guess when service will get worse. This predictability of system behavior is linked to the identification of consistent lead times and false-alarm characteristics within production data. Our experiments suggest multifractal widening as an antecedent and correlative to impaired consensus and could give rise to early warning systems. While these are encouraging findings there are some limitations. Simulations offer the management of exploration and can make control of actual production environment simpler. Such environments include complex routing, policies, different hardware and workload relationships which are not totally represented in our distributions and failure schedules. While the data provided by blockchains offers relevant empirical data, these systems have their various kinds of failures and incentives. Algorithm comparisons need to be careful to adjust stochastic factors. It is, therefore, important, prior to setting operational thresholds of Δ α confidently, to make use of large empirical data sets from different observers or use public data sets. In methodologically the MF-DFA procedure is all sensitive. Choice of detrend order, scale ranges, q sampling effects estimates and numerical differentiation in Legendre transform may increase noise. And address these parts which are very technical using cross method of verification to confirm reliability. The relationships between Multifractal widening and failures are suggestive, and not conclusive. Our experiments show the existence of co-occurrence and leading correlation, whereas to obtain causal inference, one need to do interventional experiments. To check the robustness the MF-DFA analysis was repeated with different q ranges (e.g., q ∈ [−3,3] and [−7,7]) and different window size sets; the observed links between Δ α and performance metrics were consistent across all these cases, indicating that the mentioned research results are not sensitive to the specific choice of parameters. This consistency forms the ground for the reliability of the put forward multifractal framework. This framework can be used beyond consensus protocols, though. Various distributed systems and socio-technical operations with time-based outputs are burstiness. Router queues and application request times are some examples. Multifractal evaluations in these fields may reveal the hidden weaknesses and give insights into the use of flexibility techniques. Traffic management policies based on multifractal measures could be used to redistribute workloads or manage arrivals to control the Δ α growth. Social media sites might track multifractal signatures of user in order to detect coordinated activity or change in behavior. Previous studies have established that traffic can be scale-independent and this has significant implications for succinct queuing and loss; our findings suggest that multiscale analysis can benefit consensus techniques. In theory, rather, our approach shows - once again - how little improvements to consensus dynamics one should make on the basis of multifractality. Δ α is the summarizing of systemic heterogeneity. Spectral asymmetry is indicative of whether the source of intermittency is delay or bursts. Employing multifractal as well as regular performance measures provides a detailed picture of stability than either measure alone. Further study is needed to: (1) validate these results with real data in different situation, (2) perform experiments to test the causality between structure and multifractal growth, and (3) include multifractal measures into the policies for control of consensus systems; that is, how the measurement is related to the mitigation. Conclusion This work has established an integrative theoretical and empirical pathway that builds upon multifractal descriptors to be used as measures of complexity, which is examined in this paper as the application of nonlinear dynamical systems. By modeling consensus clusters as high-dimensional systems that are impacted by the actions of stochastic networks, we show how the consensus logic incorporates with the latency and failure processes to obtain a range of scaling behaviors. The stable measures obtained from the MF-DFA method provide evidences of such behaviour in different regimes, namely ( h ( q ), α , f ( α ), and Δ α ). There are three aspects of contribution: first, a framework of aligning chaos theory to consensus dynamics, supporting the way to interpret commit latency and message complexity as multifractal observables; second, the quantitative pipeline based on multifractal detrended fluctuation analysis to apply this view to simulation and trace data; and third, the simulation study so as to check the approach and prove that there are relationships between multifractal strength and performance metrics. In all, these accomplishments help close the loop of these and established the principal aims set out in the introduction, from theory to method to experimental verification. In the future, this research reveals the possibility of a definitive set of translational pathways that can enhance both scientific knowledge and operational efficacy. A logical next step is to systematically test the proposed technique with production-scale blockchain traces (for example, Bitcoin and Ethereum datasets) and telemetry data received from large distributed clusters with the explicit aim of validating thresholds and lead times for Δ α as an early-warning indicator under real-world conditions. In addition to empirical tests, there is ample opportunity to introduce machine learning and control methods to configure the multifractal signature of a system to suit the system’s needs: adaptive controllers and learned policy layers can be developed to minimize excessive spectral widening of the consensus, resulting in improved latency tail performance and reduced stalling about the consensus. Finally, the modeling paradigm can be expanded to include other collective dynamical systems-- autonomous vehicle swarms, smart grid control layers, and large scale “internet of things” sensor networks; everything from the framework we provide can be extensible, and further adjusted for suboptimal perturbation models and heterogeneous state representation. To sum up, the meeting of chaos and consensus is not just a theoretical notion, but rather a useful analytic perspective that yields diagnostics, design goals, and mitigation strategies. Data availability Zenodo: A Statistical Framework for Predicting System Failure using Multifractal Measures at https://doi.org/10.5281/zenodo.17772389 . 17 In this study, the datasets, including the time-series of system performance metrics and the computed multifractal measures. This project contains the following data: • ChaosConsensus_Dataset_v1.zip Data are available under the terms of the Creative Commons Attribution 4.0 International license (CC-BY 4.0). References 1. Arellano-Delgado A, López-Gutiérrez RM, Méndez-Ramírez R, et al. : Dynamic coupling in small-world outer synchronization of chaotic networks. Physica D: Nonlinear Phenomena. 2021; 423 : 132928. Publisher Full Text 2. Bucur C, Tudorică BG, Bâra A, et al. : Multifractal analysis of Bitcoin price dynamics. J. Bus. Econ. Manag. 2025; 26 (1): 21–48. Publisher Full Text 3. Cao S, Zhan Z, Dai C, et al. : Delay-aware and energy-efficient IoT task scheduling algorithm with double blockchain enabled in cloud–fog collaborative networks. IEEE Internet Things J. 2023; 11 (2): 3003–3016. Publisher Full Text 4. Cohen AA, Ferrucci L, Fülöp T, et al. : A complex systems approach to aging biology. Nature Aging. 2022; 2 (7): 580–591. PubMed Abstract | Publisher Full Text | Free Full Text 5. Gorjão LR, Hassan G, Kurths J, et al. : MFDFA: Efficient multifractal detrended fluctuation analysis in python. Comput. Phys. Commun. 2022; 273 : 108254. Publisher Full Text 6. Griffith DA, Arlinghaus SL: Urban Geography Compression Patterns: Non-Euclidean and Fractal Viewpoints. AppliedMath. 2025; 5 (1): 9. Publisher Full Text 7. Haney B, Chaudhury A: Decentralized Decisions on Algorand with Choice Coin. Available at SSRN 3913316. 2021. 8. Jiang S, Wu JTaming propagation delay and fork rate in bitcoin mining network. 2021 IEEE International Conference on Blockchain (Blockchain). IEEE; 2021, December; pp. 314–320. 9. Jin J, Chen W, Ouyang A, et al. : A time-varying fuzzy parameter zeroing neural network for the synchronization of chaotic systems. IEEE Transactions on Emerging Topics in Computational Intelligence. 2023; 8 (1): 364–376. Publisher Full Text 10. Kang D, Gupta S, Malkhi D, et al. : Hotstuff-1: Linear consensus with one-phase speculation. Proceedings of the ACM on Management of Data. 2025; 3 (3): 1–29. Publisher Full Text 11. Kaur M, Khan MZ, Gupta S, et al. : MBCP: Performance analysis of large scale mainstream blockchain consensus protocols. IEEE Access. 2021; 9 : 80931–80944. Publisher Full Text 12. Lamport L: The part-time parliament. Concurrency: the works of Leslie Lamport. 2019; pp. 277–317. 13. Lorenz EN: Deterministic nonperiodic flow. J. Atmos. Sci. 1963; 20 (2): 130–141. <a target="xrefwindow" id="d66774e2886" href="https://doi.org/10.1175/1520-0469(1963)020 Publisher Full Text 14. Mandelbrot BB: The fractal geometry of nature. W. H. Freeman; Rev. and enl. ed. 1983. 15. Mazzoni M, Corradi A, Di Nicola V: Performance evaluation of permissioned blockchains for financial applications: The ConsenSys Quorum case study. Blockchain: Research and Applications. 2022; 3 (1): 100026. 16. Millán G: Estimation of Hurst exponent in self-similar traffic flows. arXiv preprint arXiv:2103.08592. 2021. 17. Mohammed SF, Abdalrahem MK, AL-Majidi AJS: ChaosConsensusDatasetv1: Time series data and multifractal measures for Raft consensus simulation and blockchain analysis. Zenodo. 2025. Publisher Full Text 18. Momose A, Ren L: Constant latency in sleepy consensus. Proceedings of the 2022 ACM SIGSAC Conference on Computer and Communications Security. 2022, November; pp. 2295–2308. 19. Nakamoto S: Bitcoin: A peer-to-peer electronic cash system.2008. 20. Onyekwere E, Ogwueleka FN, Irhebhude ME: Adoption and sustainability of bitcoin and the blockchain technology in Nigeria. Int. J. Inf. Technol. 2023; 15 (5): 2793–2804. PubMed Abstract | Publisher Full Text | Free Full Text 21. Pariona MM: Harnessing chaos: the power of fractals and Lyapunov exponents in modern financial system optimization. Observatório de la Economía Latinoamericana. 2025; 23 (8): e11011. Publisher Full Text 22. Sheluhin OI, Rybakov SYCharacteristics assessment of multifractal spectrum of fractal dimension IoT-traffic. 2024 Systems of Signal Synchronization, Generating and Processing in Telecommunications (SYNCHROINFO). IEEE; 2024, July; pp. 1–6. 23. Shen CW, Chang LC, Su TC: Research development of Bitcoin: a network and concept linking analysis. Library Hi Tech. 2021; 39 (2): 488–505. Publisher Full Text 24. Strogatz SH: Nonlinear dynamics and chaos: with applications to physics, biology, chemistry, and engineering. CRC press; 2018. 25. Vladyko A, Spirkina A, Elagin V: Towards practical applications in modeling blockchain system. Future Internet. 2021; 13 (5): 125. Publisher Full Text 26. Werth J, Berenjestanaki MH, Barzegar HR, et al. : A Review of Blockchain Platforms Based on the Scalability, Security and Decentralization Trilemma. ICEIS (1). 2023; pp. 146–155. 27. Zhang L, Li H, Liu D, et al. : Application of an improved multifractal detrended fluctuation analysis approach for estimation of the complexity of daily precipitation. Int. J. Climatol. 2021; 41 (9): 4653–4671. Publisher Full Text Comments on this article Comments (0) Version 3 VERSION 3 PUBLISHED 30 Dec 2025 ADD YOUR COMMENT Comment Author details Author details 1 Department of Statistics, College of Administration and Economics, University of Kerbala, Karbala, Iraq 2 Department of Pharmacy, University of Al-Ameed, Karbala, Iraq 3 Al-Karkh University of Science, Baghdad, Iraq Sada Faydh Mohammed Roles: Conceptualization, Data Curation, Methodology, Software, Visualization, Writing – Original Draft Preparation Mushtaq K. Abdalrahem Roles: Formal Analysis, Methodology, Supervision, Validation, Writing – Review & Editing Arkan Al-Majidi Roles: Funding Acquisition, Project Administration, Resources, Writing – Review & Editing Competing interests No competing interests were disclosed. Grant information The author(s) declared that no grants were involved in supporting this work. Article Versions (3) version 3 Revised Published: 16 May 2026, 14:1472 https://doi.org/10.12688/f1000research.172129.3 version 2 Revised Published: 13 Jan 2026, 14:1472 https://doi.org/10.12688/f1000research.172129.2 version 1 Published: 30 Dec 2025, 14:1472 https://doi.org/10.12688/f1000research.172129.1 Copyright © 2026 Mohammed SF et al . This is an open access article distributed under the terms of the Creative Commons Attribution License , which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited. Download Export To Sciwheel Bibtex EndNote ProCite Ref. Manager (RIS) Sente metrics Views Downloads F1000Research - - PubMed Central info_outline Data from PMC are received and updated monthly. - - Citations open_in_new 0 open_in_new 0 open_in_new SEE MORE DETAILS CITE how to cite this article Mohammed SF, K. Abdalrahem M and Al-Majidi A. A Statistical Framework for Predicting System Failure using Multifractal Measures [version 3; peer review: 1 approved with reservations] . F1000Research 2026, 14 :1472 ( https://doi.org/10.12688/f1000research.172129.3 ) NOTE: If applicable, it is important to ensure the information in square brackets after the title is included in all citations of this article. COPY CITATION DETAILS track receive updates on this article Track an article to receive email alerts on any updates to this article. TRACK THIS ARTICLE Share Open Peer Review Current Reviewer Status: ? Key to Reviewer Statuses VIEW HIDE Approved The paper is scientifically sound in its current form and only minor, if any, improvements are suggested Approved with reservations A number of small changes, sometimes more significant revisions are required to address specific details and improve the papers academic merit. Not approved Fundamental flaws in the paper seriously undermine the findings and conclusions Version 2 VERSION 2 PUBLISHED 13 Jan 2026 Revised Views 0 Cite How to cite this report: Attallah Y and Aziz A. Reviewer Report For: A Statistical Framework for Predicting System Failure using Multifractal Measures [version 3; peer review: 1 approved with reservations] . F1000Research 2026, 14 :1472 ( https://doi.org/10.5256/f1000research.194647.r459776 ) The direct URL for this report is: https://f1000research.com/articles/14-1472/v2#referee-response-459776 NOTE: it is important to ensure the information in square brackets after the title is included in this citation. Close Copy Citation Details Reviewer Report 19 Mar 2026 Youcef Attallah , University of Sciences and Technology of Oran Mohamed Boudiaf, Oran M’Naouer, Algeria Ahlem Aziz , Electrical and electronics engineering, Karabuk Universitesi Muhendislik Fakultesi (Ringgold ID: 539860), Karabük, Karabük, Turkey Approved with Reservations VIEWS 0 https://doi.org/10.5256/f1000research.194647.r459776 The authors propose a novel statistical framework that integrates chaos theory and multifractal analysis to study distributed consensus systems, using Raft simulations and blockchain-style data to analyze consensus latency, message complexity, and network delays under various stress scenarios. Multifractal measures, ... Continue reading READ ALL The authors propose a novel statistical framework that integrates chaos theory and multifractal analysis to study distributed consensus systems, using Raft simulations and blockchain-style data to analyze consensus latency, message complexity, and network delays under various stress scenarios. Multifractal measures, such as singularity spectrum width Δα, are shown to capture system complexity and serve as early-warning indicators beyond traditional metrics. Results demonstrate the effectiveness of this approach for monitoring and understanding distributed networks. However, I still have the following comments and recommendations: General comments: While the paper presents a novel and promising approach, several sentences throughout the manuscript would benefit from a more formal academic tone. Some expressions appear conversational and could be revised to improve clarity and professionalism. A few examples are provided below for illustration: "This research tries to fix this gap by going past just describing things" → could be rephrased as "This research aims to address this gap by moving beyond descriptive analysis." "It suggests a new way to measure things by using multifractal analysis tools" → could be "It proposes a novel quantitative framework using multifractal analysis tools." "With this way, we can rethink consensus not just as a computer science issue, but as a complex system that changes" → could be "This perspective allows consensus to be reconceptualized not merely as a computer science problem, but as a complex dynamical system." "Taken together, these results indicate that the multifractal spectrum width" → this sentence is cut off in the manuscript and should be completed. Specific comments and recommendations: 1. Introduction: Structure of the introduction: concepts (big data, chaos theory, fractals, consensus algorithms) are covered too quickly; a more logical progression would help the reader. The Clarification of the scientific gap: the gap in the literature is mentioned but could be formulated more clearly to emphasize the contribution of the article. Academic style: some expressions are informal (“tons of data,” “make sense of the mess”). For example: “tons of data” → “massive volumes of data” - “make sense of the mess” → “extract meaningful structures and hidden patterns from complex datasets” - “big swings” → “large fluctuations” It is preferable to adopt a more precise and scientific style. 2. Literature review: Some sentences are too long or informal: Ex. “Looking at the research, there’s a hole in the current studies” → “A review of the literature reveals a notable gap in current studies.” 3.Methodology: The Raft protocol was chosen for its clarity. However, the selection of parameter values in Table 1 (e.g., network size {5, 10, 21, and 50}, request rate {1, 10, and 100}) would benefit from a brief explanation. Why these specific values? Are they representative of real deployments or edge cases? The methodology would benefit from a brief explanation of how the correlation between multifractal metrics and traditional performance indicators was computed (e.g., using sliding windows), as this would prepare the reader for the results presented in Figures 4 and 5. The description of the MF-DFA steps is clear. However, for reproducibility, the authors should briefly justify the choice of polynomial order (m=2) and the scale range (s=16 to 4096), explaining why these values are appropriate (e.g., m=2 removes linear and quadratic trends; s=16 ensures reliable trend estimation, and s=4096 respects the L/4 rule for series length). 4. Results: The interpretation of Figure 3 and Table 3 is clear and well-supported. However, the authors state that the dos_attack spectrum displays "marked left-skewed asymmetry" and attribute this to "extreme slow events." A brief explanation of why heavy-tailed latencies produce left skew (rather than right skew) would strengthen the reader's understanding of the link between the type of stress and the spectral shape. 5. Discussion: The authors acknowledge limitations (e.g., simulations simplify real environments, MF-DFA parameter sensitivity) but do not discuss how sensitive the results might be to the choice of MF-DFA parameters (e.g., q-range, window sizes). A brief note on whether the observed patterns hold across reasonable parameter variations would strengthen the robustness claims. The Discussion provides rich interpretation but is somewhat repetitive (e.g., the explanation of what a narrow vs. wide spectrum means appears in multiple places). Tightening this section would improve readability and impact. Is the work clearly and accurately presented and does it cite the current literature? Partly Is the study design appropriate and is the work technically sound? Yes Are sufficient details of methods and analysis provided to allow replication by others? Partly If applicable, is the statistical analysis and its interpretation appropriate? Yes Are all the source data underlying the results available to ensure full reproducibility? Yes Are the conclusions drawn adequately supported by the results? Yes Competing Interests: No competing interests were disclosed. Reviewer Expertise: Multifractal analysis - Machine learning - Deep learning We confirm that we have read this submission and believe that we have an appropriate level of expertise to confirm that it is of an acceptable scientific standard, however we have significant reservations, as outlined above. Close READ LESS CITE CITE HOW TO CITE THIS REPORT Attallah Y and Aziz A. Reviewer Report For: A Statistical Framework for Predicting System Failure using Multifractal Measures [version 3; peer review: 1 approved with reservations] . F1000Research 2026, 14 :1472 ( https://doi.org/10.5256/f1000research.194647.r459776 ) The direct URL for this report is: https://f1000research.com/articles/14-1472/v2#referee-response-459776 NOTE: it is important to ensure the information in square brackets after the title is included in all citations of this article. COPY CITATION DETAILS Report a concern Respond or Comment COMMENT ON THIS REPORT Comments on this article Comments (0) Version 3 VERSION 3 PUBLISHED 30 Dec 2025 ADD YOUR COMMENT Comment keyboard_arrow_left keyboard_arrow_right Open Peer Review Reviewer Status info_outline Alongside their report, reviewers assign a status to the article: Approved The paper is scientifically sound in its current form and only minor, if any, improvements are suggested Approved with reservations A number of small changes, sometimes more significant revisions are required to address specific details and improve the papers academic merit. Not approved Fundamental flaws in the paper seriously undermine the findings and conclusions Reviewer Reports Invited Reviewers 1 Version 3 (revision) 16 May 26 Version 2 (revision) 13 Jan 26 read Version 1 30 Dec 25 Youcef Attallah , University of Sciences and Technology of Oran Mohamed Boudiaf, Oran M’Naouer, Algeria Ahlem Aziz , Karabuk Universitesi Muhendislik Fakultesi (Ringgold ID: 539860), Karabük, Turkey Comments on this article All Comments (0) Add a comment Sign up for content alerts Sign Up You are now signed up to receive this alert Browse by related subjects keyboard_arrow_left Back to all reports Reviewer Report 0 Views copyright © 2026 Attallah Y et al. This is an open access peer review report distributed under the terms of the Creative Commons Attribution License , which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited. The author(s) is/are employees of the US Government and therefore domestic copyright protection in USA does not apply to this work. The work may be protected under the copyright laws of other jurisdictions when used in those jurisdictions. 19 Mar 2026 | for Version 2 Youcef Attallah , University of Sciences and Technology of Oran Mohamed Boudiaf, Oran M’Naouer, Algeria Ahlem Aziz , Electrical and electronics engineering, Karabuk Universitesi Muhendislik Fakultesi (Ringgold ID: 539860), Karabük, Karabük, Turkey 0 Views copyright © 2026 Attallah Y et al. This is an open access peer review report distributed under the terms of the Creative Commons Attribution License , which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited. The author(s) is/are employees of the US Government and therefore domestic copyright protection in USA does not apply to this work. The work may be protected under the copyright laws of other jurisdictions when used in those jurisdictions. format_quote Cite this report speaker_notes Responses (0) Approved With Reservations info_outline Alongside their report, reviewers assign a status to the article: Approved The paper is scientifically sound in its current form and only minor, if any, improvements are suggested Approved with reservations A number of small changes, sometimes more significant revisions are required to address specific details and improve the papers academic merit. Not approved Fundamental flaws in the paper seriously undermine the findings and conclusions The authors propose a novel statistical framework that integrates chaos theory and multifractal analysis to study distributed consensus systems, using Raft simulations and blockchain-style data to analyze consensus latency, message complexity, and network delays under various stress scenarios. Multifractal measures, such as singularity spectrum width Δα, are shown to capture system complexity and serve as early-warning indicators beyond traditional metrics. Results demonstrate the effectiveness of this approach for monitoring and understanding distributed networks. However, I still have the following comments and recommendations: General comments: While the paper presents a novel and promising approach, several sentences throughout the manuscript would benefit from a more formal academic tone. Some expressions appear conversational and could be revised to improve clarity and professionalism. A few examples are provided below for illustration: "This research tries to fix this gap by going past just describing things" → could be rephrased as "This research aims to address this gap by moving beyond descriptive analysis." "It suggests a new way to measure things by using multifractal analysis tools" → could be "It proposes a novel quantitative framework using multifractal analysis tools." "With this way, we can rethink consensus not just as a computer science issue, but as a complex system that changes" → could be "This perspective allows consensus to be reconceptualized not merely as a computer science problem, but as a complex dynamical system." "Taken together, these results indicate that the multifractal spectrum width" → this sentence is cut off in the manuscript and should be completed. Specific comments and recommendations: 1. Introduction: Structure of the introduction: concepts (big data, chaos theory, fractals, consensus algorithms) are covered too quickly; a more logical progression would help the reader. The Clarification of the scientific gap: the gap in the literature is mentioned but could be formulated more clearly to emphasize the contribution of the article. Academic style: some expressions are informal (“tons of data,” “make sense of the mess”). For example: “tons of data” → “massive volumes of data” - “make sense of the mess” → “extract meaningful structures and hidden patterns from complex datasets” - “big swings” → “large fluctuations” It is preferable to adopt a more precise and scientific style. 2. Literature review: Some sentences are too long or informal: Ex. “Looking at the research, there’s a hole in the current studies” → “A review of the literature reveals a notable gap in current studies.” 3.Methodology: The Raft protocol was chosen for its clarity. However, the selection of parameter values in Table 1 (e.g., network size {5, 10, 21, and 50}, request rate {1, 10, and 100}) would benefit from a brief explanation. Why these specific values? Are they representative of real deployments or edge cases? The methodology would benefit from a brief explanation of how the correlation between multifractal metrics and traditional performance indicators was computed (e.g., using sliding windows), as this would prepare the reader for the results presented in Figures 4 and 5. The description of the MF-DFA steps is clear. However, for reproducibility, the authors should briefly justify the choice of polynomial order (m=2) and the scale range (s=16 to 4096), explaining why these values are appropriate (e.g., m=2 removes linear and quadratic trends; s=16 ensures reliable trend estimation, and s=4096 respects the L/4 rule for series length). 4. Results: The interpretation of Figure 3 and Table 3 is clear and well-supported. However, the authors state that the dos_attack spectrum displays "marked left-skewed asymmetry" and attribute this to "extreme slow events." A brief explanation of why heavy-tailed latencies produce left skew (rather than right skew) would strengthen the reader's understanding of the link between the type of stress and the spectral shape. 5. Discussion: The authors acknowledge limitations (e.g., simulations simplify real environments, MF-DFA parameter sensitivity) but do not discuss how sensitive the results might be to the choice of MF-DFA parameters (e.g., q-range, window sizes). A brief note on whether the observed patterns hold across reasonable parameter variations would strengthen the robustness claims. The Discussion provides rich interpretation but is somewhat repetitive (e.g., the explanation of what a narrow vs. wide spectrum means appears in multiple places). Tightening this section would improve readability and impact. Is the work clearly and accurately presented and does it cite the current literature? Partly Is the study design appropriate and is the work technically sound? Yes Are sufficient details of methods and analysis provided to allow replication by others? Partly If applicable, is the statistical analysis and its interpretation appropriate? Yes Are all the source data underlying the results available to ensure full reproducibility? Yes Are the conclusions drawn adequately supported by the results? Yes Competing Interests No competing interests were disclosed. Reviewer Expertise Multifractal analysis - Machine learning - Deep learning We confirm that we have read this submission and believe that we have an appropriate level of expertise to confirm that it is of an acceptable scientific standard, however we have significant reservations, as outlined above. reply Respond to this report Responses (0) Attallah Y and Aziz A. Peer Review Report For: A Statistical Framework for Predicting System Failure using Multifractal Measures [version 3; peer review: 1 approved with reservations] . F1000Research 2026, 14 :1472 ( https://doi.org/10.5256/f1000research.194647.r459776) NOTE: it is important to ensure the information in square brackets after the title is included in this citation. The direct URL for this report is: https://f1000research.com/articles/14-1472/v2#referee-response-459776 Alongside their report, reviewers assign a status to the article: Approved - the paper is scientifically sound in its current form and only minor, if any, improvements are suggested Approved with reservations - A number of small changes, sometimes more significant revisions are required to address specific details and improve the papers academic merit. Not approved - fundamental flaws in the paper seriously undermine the findings and conclusions Adjust parameters to alter display View on desktop for interactive features Includes Interactive Elements View on desktop for interactive features Competing Interests Policy Provide sufficient details of any financial or non-financial competing interests to enable users to assess whether your comments might lead a reasonable person to question your impartiality. Consider the following examples, but note that this is not an exhaustive list: Examples of 'Non-Financial Competing Interests' Within the past 4 years, you have held joint grants, published or collaborated with any of the authors of the selected paper. You have a close personal relationship (e.g. parent, spouse, sibling, or domestic partner) with any of the authors. You are a close professional associate of any of the authors (e.g. scientific mentor, recent student). You work at the same institute as any of the authors. You hope/expect to benefit (e.g. favour or employment) as a result of your submission. You are an Editor for the journal in which the article is published. Examples of 'Financial Competing Interests' You expect to receive, or in the past 4 years have received, any of the following from any commercial organisation that may gain financially from your submission: a salary, fees, funding, reimbursements. You expect to receive, or in the past 4 years have received, shared grant support or other funding with any of the authors. You hold, or are currently applying for, any patents or significant stocks/shares relating to the subject matter of the paper you are commenting on. Stay Updated Sign up for content alerts and receive a weekly or monthly email with all newly published articles Register with F1000Research Already registered? Sign in Not now, thanks close PLEASE NOTE If you are an AUTHOR of this article, please check that you signed in with the account associated with this article otherwise we cannot automatically identify your role as an author and your comment will be labelled as a “User Comment”. If you are a REVIEWER of this article, please check that you have signed in with the account associated with this article and then go to your account to submit your report, please do not post your review here. If you do not have access to your original account, please contact us . All commenters must hold a formal affiliation as per our Policies . The information that you give us will be displayed next to your comment. User comments must be in English, comprehensible and relevant to the article under discussion. We reserve the right to remove any comments that we consider to be inappropriate, offensive or otherwise in breach of the User Comment Terms and Conditions . Commenters must not use a comment for personal attacks. When criticisms of the article are based on unpublished data, the data should be made available. I accept the User Comment Terms and Conditions Please confirm that you accept the User Comment Terms and Conditions. Affiliation ✕ refresh Please enter your institution. Note: To add your institution or organisation, start typing the name and then select the correct name from the list. Where applicable, the name will appear in both the original language and in English. Do not paste in the name. If the name does not appear in the drop-down list, we will display the information you have entered. ✕ refresh Country/Region * USA UK Canada China France Germany Afghanistan Aland Islands Albania Algeria American Samoa Andorra Angola Anguilla Antarctica Antigua and Barbuda Argentina Armenia Aruba Australia Austria Azerbaijan Bahamas Bahrain Bangladesh Barbados Belarus Belgium Belize Benin Bermuda Bhutan Bolivia Bosnia and Herzegovina Botswana Bouvet Island Brazil British Indian Ocean Territory British Virgin Islands Brunei Bulgaria Burkina Faso Burundi Cambodia Cameroon Canada Cape Verde Cayman Islands Central African Republic Chad Chile China Christmas Island Cocos (Keeling) Islands Colombia Comoros Congo Cook Islands Costa Rica Cote d'Ivoire Croatia Cuba Cyprus Czech Republic Democratic Republic of the Congo Denmark Djibouti Dominica Dominican Republic Ecuador Egypt El Salvador Equatorial Guinea Eritrea Estonia Ethiopia Falkland Islands Faroe Islands Federated States of Micronesia Fiji Finland France French Guiana French Polynesia French Southern Territories Gabon Georgia Germany Ghana Gibraltar Greece Greenland Grenada Guadeloupe Guam Guatemala Guernsey Guinea Guinea-Bissau Guyana Haiti Heard Island and Mcdonald Islands Holy See (Vatican City State) Honduras Hong Kong Hungary Iceland India Indonesia Iran Iraq Ireland Israel Italy Jamaica Japan Jersey Jordan Kazakhstan Kenya Kiribati Kosovo (Serbia and Montenegro) Kuwait Kyrgyzstan Lao People's Democratic Republic Latvia Lebanon Lesotho Liberia Libya Liechtenstein Lithuania Luxembourg Macao Madagascar Malawi Malaysia Maldives Mali Malta Marshall Islands Martinique Mauritania Mauritius Mayotte Mexico Minor Outlying Islands of the United States Moldova Monaco Mongolia Montenegro Montserrat Morocco Mozambique Myanmar Namibia Nauru Nepal Netherlands Antilles New Caledonia New Zealand Nicaragua Niger Nigeria Niue Norfolk Island North Korea North Macedonia Northern Mariana Islands Norway Oman Pakistan Palau Palestinian Territory Panama Papua New Guinea Paraguay Peru Philippines Pitcairn Poland Portugal Puerto Rico Qatar Reunion Romania Russian Federation Rwanda Saint Helena Saint Kitts and Nevis Saint Lucia Saint Pierre and Miquelon Saint Vincent and the Grenadines Samoa San Marino Sao Tome and Principe Saudi Arabia Senegal Serbia Seychelles Sierra Leone Singapore Slovakia Slovenia Solomon Islands Somalia South Africa South Georgia and the South Sandwich Is South Korea South Sudan Spain Sri Lanka Sudan Suriname Svalbard and Jan Mayen Swaziland Sweden Switzerland Syria Taiwan Tajikistan Tanzania Thailand The Gambia The Netherlands Timor-Leste Togo Tokelau Tonga Trinidad and Tobago Tunisia Turkey Turkmenistan Turks and Caicos Islands Tuvalu UK USA Uganda Ukraine United Arab Emirates United States Virgin Islands Uruguay Uzbekistan Vanuatu Venezuela Vietnam Wallis and Futuna West Bank and Gaza Strip Western Sahara Yemen Zambia Zimbabwe Please select your country/region. You must enter a comment. Competing Interests Please disclose any competing interests that might be construed to influence your judgment of the article's or peer review report's validity or importance. Competing Interests Policy Provide sufficient details of any financial or non-financial competing interests to enable users to assess whether your comments might lead a reasonable person to question your impartiality. Consider the following examples, but note that this is not an exhaustive list: Examples of 'Non-Financial Competing Interests' Within the past 4 years, you have held joint grants, published or collaborated with any of the authors of the selected paper. You have a close personal relationship (e.g. parent, spouse, sibling, or domestic partner) with any of the authors. You are a close professional associate of any of the authors (e.g. scientific mentor, recent student). You work at the same institute as any of the authors. You hope/expect to benefit (e.g. favour or employment) as a result of your submission. You are an Editor for the journal in which the article is published. Examples of 'Financial Competing Interests' You expect to receive, or in the past 4 years have received, any of the following from any commercial organisation that may gain financially from your submission: a salary, fees, funding, reimbursements. You expect to receive, or in the past 4 years have received, shared grant support or other funding with any of the authors. You hold, or are currently applying for, any patents or significant stocks/shares relating to the subject matter of the paper you are commenting on. Please state your competing interests The comment has been saved. An error has occurred. Please try again. Cancel Post var lTitle = "A Statistical Framework for Predicting System...".replace("'", ''); var linkedInUrl = "http://www.linkedin.com/shareArticle?url=https://f1000research.com/articles/14-1472/v3" + "&title=" + encodeURIComponent(lTitle) + "&summary=" + encodeURIComponent('Read the article by '); var deliciousUrl = "https://del.icio.us/post?url=https://f1000research.com/articles/14-1472/v3&title=" + encodeURIComponent(lTitle); var redditUrl = "http://reddit.com/submit?url=https://f1000research.com/articles/14-1472/v3" + "&title=" + encodeURIComponent(lTitle); linkedInUrl += encodeURIComponent('Mohammed SF et al.'); var offsetTop = /chrome/i.test( navigator.userAgent ) ? 4 : -10; var addthis_config = { ui_offset_top: offsetTop, services_compact : "facebook,twitter,www.linkedin.com,www.mendeley.com,reddit.com", services_expanded : "facebook,twitter,www.linkedin.com,www.mendeley.com,reddit.com", services_custom : [ { name: "LinkedIn", url: linkedInUrl, icon:"/img/icon/at_linkedin.svg" }, { name: "Mendeley", url: "http://www.mendeley.com/import/?url=https://f1000research.com/articles/14-1472/v3/mendeley", icon:"/img/icon/at_mendeley.svg" }, { name: "Reddit", url: redditUrl, icon:"/img/icon/at_reddit.svg" }, ] }; var addthis_share = { url: "https://f1000research.com/articles/14-1472", templates : { twitter : "A Statistical Framework for Predicting System Failure using Multifractal.... Mohammed SF et al., published by " + "@F1000Research" + ", https://f1000research.com/articles/14-1472/v3" } }; if (typeof(addthis) != "undefined"){ addthis.addEventListener('addthis.ready', checkCount); addthis.addEventListener('addthis.menu.share', checkCount); } $(".f1r-shares-twitter").attr("href", "https://twitter.com/intent/tweet?text=" + addthis_share.templates.twitter); $(".f1r-shares-facebook").attr("href", "https://www.facebook.com/sharer/sharer.php?u=" + addthis_share.url); $(".f1r-shares-linkedin").attr("href", addthis_config.services_custom[0].url); $(".f1r-shares-reddit").attr("href", addthis_config.services_custom[2].url); $(".f1r-shares-mendelay").attr("href", addthis_config.services_custom[1].url); function checkCount(){ setTimeout(function(){ $(".addthis_button_expanded").each(function(){ var count = $(this).text(); if (count !== "" && count != "0") $(this).removeClass("is-hidden"); else $(this).addClass("is-hidden"); }); }, 1000); } close How to cite this report {{reportCitation}} Cancel Copy Citation Details $(function(){R.ui.buttonDropdowns('.dropdown-for-downloads');}); $(function(){R.ui.toolbarDropdowns('.toolbar-dropdown-for-downloads');}); $.get("/articles/acj/172129/198591") new F1000.Clipboard(); new F1000.ThesaurusTermsDisplay("articles", "article", "198591"); $(document).ready(function() { $( "#frame1" ).on('load', function() { var mydiv = $(this).contents().find("div"); var h = mydiv.height(); console.log(h) }); var tooltipLivingFigure = jQuery(".interactive-living-figure-label .icon-more-info"), titleLivingFigure = tooltipLivingFigure.attr("title"); tooltipLivingFigure.simpletip({ fixed: true, position: ["-115", "30"], baseClass: 'small-tooltip', content:titleLivingFigure + " " }); tooltipLivingFigure.removeAttr("title"); $("body").on("click", ".cite-living-figure", function(e) { e.preventDefault(); var ref = $(this).attr("data-ref"); $(this).closest(".living-figure-list-container").find("#" + ref).fadeIn(200); }); $("body").on("click", ".close-cite-living-figure", function(e) { e.preventDefault(); $(this).closest(".popup-window-wrapper").fadeOut(200); }); $(document).on("mouseup", function(e) { var metricsContainer = $(".article-metrics-popover-wrapper"); if (!metricsContainer.is(e.target) && metricsContainer.has(e.target).length === 0) { $(".article-metrics-close-button").click(); } }); var articleId = $('#articleId').val(); if($("#main-article-count-box").attachArticleMetrics) { $("#main-article-count-box").attachArticleMetrics(articleId, { articleMetricsView: true }); } }); var figshareWidget = $(".new_figshare_widget"); if (figshareWidget.length > 0) { window.figshare.load("f1000", function(Widget) { // Select a tag/tags defined in your page. In this tag we will place the widget. _.map(figshareWidget, function(el){ var widget = new Widget({ articleId: $(el).attr("figshare_articleId") //height:300 // this is the height of the viewer part. [Default: 550] }); widget.initialize(); // initialize the widget widget.mount(el); // mount it in a tag that's on your page // this will save the widget on the global scope for later use from // your JS scripts. This line is optional. //window.widget = widget; }); }); } close Error Close Add Reset F1000.MICROSERVICES.AFFILIATION = ''; $(document).ready(function () { $('.js-affiliations-form').each((index, form) => { new AffiliationForm({ formId: form.id, institutionErrorSelector: '.comment-enter-institution', departmentErrorSelector: '.comment-enter-department', placeSelector: '.js-add-comment-place', stateSelector: '.js-add-comment-state', zipCodeSelector: '.js-add-comment-zipcode', countrySelector: '.js-add-comment-country', countryErrorSelector: '.comment-enter-country', }); }); }); $(document).ready(function () { var reportIds = { "459782": 0, "459781": 0, "459780": 0, "459779": 0, "459778": 0, "459777": 0, "459776": 13, "457886": 0, "463135": 0, "457887": 0, "457884": 0, "457885": 0, "457882": 0, "457883": 0, "457881": 0, "454950": 0, "463143": 0, "450214": 0, "454951": 0, "463142": 0, "450215": 0, "463141": 0, "450212": 0, "463140": 0, "450213": 0, "457890": 0, "463139": 0, "463138": 0, "450211": 0, "457888": 0, "463137": 0, "457889": 0, "463136": 0, "454958": 0, "454959": 0, "454956": 0, "450220": 0, "454957": 0, "454954": 0, "450218": 0, "454955": 0, "450219": 0, "454952": 0, "450216": 0, "454953": 0, "463144": 0, "450217": 0, "485364": 0, "459775": 0, "459774": 0, "459773": 0, }; $(".referee-response-container,.js-referee-report").each(function(index, el) { var reportId = $(el).attr("data-reportid"), reportCount = reportIds[reportId] || 0; $(el).find(".comments-count-container,.js-referee-report-views").html(reportCount); }); var uuidInput = $("#article_uuid"), oldUUId = uuidInput.val(), newUUId = "35342321-8e06-4692-8431-fbe1275f39b9"; uuidInput.val(newUUId); $("a[href*='article_uuid=']").each(function(index, el) { var newHref = $(el).attr("href").replace(oldUUId, newUUId); $(el).attr("href", newHref); }); }); An innovative open access publishing platform offering rapid publication and open peer review, whilst supporting data deposition and sharing. Browse Gateways Collections How it Works Contact For Developers Cookie Notice Privacy Notice RSS Submit Your Research Follow us © 2012-2026 F1000 Research Ltd. ISSN 2046-1402 | Legal | Partner of Research4Life • CrossRef • ORCID • FAIRSharing R.templateTests.simpleTemplate = R.template(' $text $text $text $text $text '); R.templateTests.runTests(); var F1000platform = new F1000.Platform({ name: "f1000research", displayName: "F1000Research", hostName: "f1000research.com", id: "1", editorialEmail: "[email protected]", infoEmail: "[email protected]", usePmcStats: true }); $(function(){R.ui.dropdowns('.dropdown-for-authors, .dropdown-for-about, .dropdown-for-myresearch');}); // $(function(){R.ui.dropdowns('.dropdown-for-referees');}); $(document).ready(function () { if ($(".cookie-warning").is(":visible")) { $(".sticky").css("margin-bottom", "35px"); $(".devices").addClass("devices-and-cookie-warning"); } $(".cookie-warning .close-button").click(function (e) { $(".devices").removeClass("devices-and-cookie-warning"); $(".sticky").css("margin-bottom", "0"); }); $("#tweeter-feed .tweet-message").each(function (i, message) { var self = $(message); self.html(linkify(self.html())); }); $(".partner").on("mouseenter mouseleave", function() { $(this).find(".gray-scale, .colour").toggleClass("is-hidden"); }); }); Sign In Remember me Forgotten your password? Sign In Cancel Email or password not correct. Please try again Please wait... $(function(){ // Note: All the setup needs to run against a name attribute and *not* the id due the clonish // nature of facebox... $("a[id=googleSignInButton]").click(function(event){ event.preventDefault(); $("input[id=oAuthSystem]").val("GOOGLE"); $("form[id=oAuthForm]").submit(); }); $("a[id=facebookSignInButton]").click(function(event){ event.preventDefault(); $("input[id=oAuthSystem]").val("FACEBOOK"); $("form[id=oAuthForm]").submit(); }); $("a[id=orcidSignInButton]").click(function(event){ event.preventDefault(); $("input[id=oAuthSystem]").val("ORCID"); $("form[id=oAuthForm]").submit(); }); }); If you've forgotten your password, please enter your email address below and we'll send you instructions on how to reset your password. The email address should be the one you originally registered with F1000. Email address not valid, please try again You registered with F1000 via Google, so we cannot reset your password. To sign in, please click here . If you still need help with your Google account password, please click here . You registered with F1000 via Facebook, so we cannot reset your password. To sign in, please click here . If you still need help with your Facebook account password, please click here . Code not correct, please try again Reset password Cancel Email us for further assistance. Server error, please try again. If your email address is registered with us, we will email you instructions to reset your password. If you think you should have received this email but it has not arrived, please check your spam filters and/or contact for further assistance. Please wait... Register $(document).ready(function () { signIn.createSignInAsRow($("#sign-in-form-gfb-popup")); $(".target-field").each(function () { var uris = $(this).val().split("/"); if (uris.pop() === "login") { $(this).val(uris.toString().replace(",","/")); } }); });