1"use strict";(globalThis.webpackChunkpublic_docs=globalThis.webpackChunkpublic_docs||[]).push([[2615],{13490(e){e.exports=JSON.parse('{"permalink":"/posts/fusaka-devnet-5-bpo-analysis","source":"@site/blog/2025-09-18-fusaka-devnet-5-bpo-analysis/index.md","title":"Fusaka-Devnet-5 BPO Analysis","description":"Analysis of blob parameter optimization values from fusaka-devnet-5 to inform safe initial values for the Fusaka fork.","date":"2025-09-18T00:00:00.000Z","tags":[{"inline":true,"label":"fusaka","permalink":"/posts/tags/fusaka"}],"readingTime":12.2,"hasTruncateMarker":false,"authors":[{"name":"samcm","title":"DevOps Engineer","bio":"DevOps Engineer","url":"https://github.com/samcm","github":"https://github.com/samcm","twitter":"https://x.com/samcmAU","imageURL":"/img/team/samcm.jpeg","key":"samcm","page":null}],"frontMatter":{"slug":"fusaka-devnet-5-bpo-analysis","title":"Fusaka-Devnet-5 BPO Analysis","authors":["samcm"],"description":"Analysis of blob parameter optimization values from fusaka-devnet-5 to inform safe initial values for the Fusaka fork.","tags":["fusaka"],"image":"/img/blog/fusaka-devnet-5-bpo-analysis.jpg","relatedLinks":[{"name":"Fusaka-Devnet-5","url":"/networks/fusaka-devnet-5"},{"name":"Xatu Analysis","url":"https://github.com/ethpandaops/xatu-analysis"},{"name":"Fusaka Scheduling","url":"https://notes.ethereum.org/@jtraglia/fusaka_scheduling"}]},"unlisted":false,"prevItem":{"title":"Fusaka bandwidth estimation","permalink":"/posts/fusaka-bandwidth-estimation"},"nextItem":{"title":"Scaling Ethereum: The Path to 45M Gas Limit and Beyond","permalink":"/posts/gaslimit-scaling"}}')},28453(e,t,s){s.d(t,{R:()=>a,x:()=>l});var n=s(96540);const i={},o=n.createContext(i);function a(e){const t=n.useContext(o);return n.useMemo(function(){return"function"==typeof e?e(t):{...t,...e}},[t,e])}function l(e){let t;return t=e.disableParentContext?"function"==typeof e.components?e.components(i):e.components||i:a(e.components),n.createElement(o.Provider,{value:t},e.children)}},86734(e,t,s){s.r(t),s.d(t,{BlobViabilityRow:()=>d,RecoveryTable:()=>c,ViableOptions:()=>h,assets:()=>r,contentTitle:()=>l,default:()=>m,frontMatter:()=>a,metadata:()=>n,toc:()=>u});var n=s(13490),i=s(74848),o=s(28453);const a={slug:"fusaka-devnet-5-bpo-analysis",title:"Fusaka-Devnet-5 BPO Analysis",authors:["samcm"],description:"Analysis of blob parameter optimization values from fusaka-devnet-5 to inform safe initial values for the Fusaka fork.",tags:["fusaka"],image:"/img/blog/fusaka-devnet-5-bpo-analysis.jpg",relatedLinks:[{name:"Fusaka-Devnet-5",url:"/networks/fusaka-devnet-5"},{name:"Xatu Analysis",url:"https://github.com/ethpandaops/xatu-analysis"},{name:"Fusaka Scheduling",url:"https://notes.ethereum.org/@jtraglia/fusaka_scheduling"}]},l=void 0,r={authorsImageUrls:[void 0]},d=({items:e})=>{const t=e=>{switch(e){case"viable":return"#28a745";case"marginal":return"#ffc107";case"not-viable":return"#dc3545";default:return"#6c757d"}},s=e=>{switch(e){case"viable":return"\u2713";case"marginal":return"\u26a0";case"not-viable":return"\u2717";default:return"?"}},n=e=>{switch(e){case"viable":return"Viable";case"marginal":return"Marginal";case"not-viable":return"Not Viable";default:return"Unknown"}};return(0,i.jsx)("div",{style:{display:"grid",gridTemplateColumns:"repeat(3, 1fr)",gap:"12px",margin:"20px 0"},children:e.map((e,o)=>(0,i.jsxs)("div",{style:{display:"flex",alignItems:"center",gap:"10px",padding:"12px",backgroundColor:"var(--ifm-color-emphasis-100)",borderLeft:`4px solid ${t(e.status)}`,borderRadius:"4px",minHeight:"60px"},children:[(0,i.jsx)("div",{style:{width:"28px",height:"28px",borderRadius:"50%",backgroundColor:t(e.status),color:"white",display:"flex",alignItems:"center",justifyContent:"center",fontSize:"16px",fontWeight:"bold",flexShrink:0},children:s(e.status)}),(0,i.jsxs)("div",{style:{flex:1},children:[(0,i.jsxs)("div",{style:{fontWeight:"bold",fontSize:"0.95rem",color:t(e.status),marginBottom:"2px"},children:[e.count," Blobs"]}),(0,i.jsx)("div",{style:{fontSize:"0.85rem",color:"var(--ifm-color-emphasis-600)",lineHeight:1.2},children:n(e.status)})]})]},o))})},c=()=>{const e=[{slot:54989,correctness:87.4,blobs:32},{slot:54636,correctness:88.8,blobs:27},{slot:54606,correctness:89.6,blobs:30},{slot:54096,correctness:88.5,blobs:26},{slot:53689,correctness:89,blobs:27}];return(0,i.jsxs)("div",{style:{width:"100%",margin:"20px 0",borderRadius:"6px",overflow:"hidden",border:"1px solid var(--ifm-color-emphasis-200)"},children:[(0,i.jsxs)("div",{style:{display:"flex",backgroundColor:"var(--ifm-color-primary)",color:"white",padding:"12px 16px",fontWeight:600},children:[(0,i.jsx)("div",{style:{flex:"0 0 25%"},children:"Slot"}),(0,i.jsx)("div",{style:{flex:"0 0 30%",textAlign:"center"},children:"Head Correctness %"}),(0,i.jsx)("div",{style:{flex:"0 0 20%",textAlign:"center"},children:"Blob Count"}),(0,i.jsx)("div",{style:{flex:"0 0 25%",textAlign:"center"},children:"Status"})]}),e.map((t,s)=>(0,i.jsxs)("div",{style:{display:"flex",alignItems:"center",backgroundColor:s%2==0?"var(--ifm-background-surface-color)":"var(--ifm-color-emphasis-100)",padding:"10px 16px",borderBottom:s<e.length-1?"1px solid var(--ifm-color-emphasis-200)":"none",fontSize:"0.95rem"},children:[(0,i.jsx)("div",{style:{flex:"0 0 25%"},children:(0,i.jsx)("a",{href:`https://dora.fusaka-devnet-5.ethpandaops.io/slot/${t.slot}`,target:"_blank",children:t.slot})}),(0,i.jsxs)("div",{style:{flex:"0 0 30%",textAlign:"center"},children:[t.correctness,"%"]}),(0,i.jsx)("div",{style:{flex:"0 0 20%",textAlign:"center"},children:t.blobs}),(0,i.jsx)("div",{style:{flex:"0 0 25%",textAlign:"center"},children:(0,i.jsx)("span",{style:{color:"#28a745"},children:"\u2713 Recovered"})})]},s))]})},h=()=>(0,i.jsx)("div",{style:{margin:"40px 0",padding:"30px"},children:(0,i.jsx)("div",{style:{display:"grid",gridTemplateColumns:"repeat(auto-fit, minmax(280px, 1fr))",gap:"20px"},children:[{max:15,title:"",description:"A safe starting point",benefits:["\u2713 Full node local block proposals work reliably","\u2713 Supernodes handle all 128 columns comfortably","\u2713 Network recovery mechanisms function smoothly","\u2713 New nodes can sync without issues"]},{max:21,title:"",description:"Better data for future increases",benefits:["\u2713 Provides valuable data for future scaling","\u2713 40% more blob capacity than the 15 option","\u2713 Still within safe operational limits"]},{max:32,title:"",description:"Notable challenges ",benefits:["\u26a0 Full nodes struggle to publish blocks without the help of MEV Relays","\u2713 Supernodes handle the load adequately","\u2713 Network recovery still functional"]}].map((e,t)=>(0,i.jsxs)("div",{style:{padding:"24px",backgroundColor:e.notViable?"var(--ifm-color-danger-lightest)":"var(--ifm-background-surface-color)",borderRadius:"8px",border:"2px s
1olid "+(e.notViable?"var(--ifm-color-danger-light)":"var(--ifm-color-primary-lighter)"),position:"relative",opacity:e.notViable?.9:1},children:[(0,i.jsxs)("div",{style:{position:"absolute",top:"-15px",left:"20px",backgroundColor:e.notViable?"var(--ifm-color-danger)":"var(--ifm-color-primary)",color:"white",padding:"6px 16px",borderRadius:"20px",fontSize:"1.2rem",fontWeight:"bold"},children:["Max = ",e.max]}),e.notViable&&(0,i.jsx)("div",{style:{position:"absolute",top:"-15px",right:"20px",backgroundColor:"var(--ifm-color-danger)",color:"white",padding:"4px 12px",borderRadius:"12px",fontSize:"0.8rem",fontWeight:"bold",textTransform:"uppercase"},children:"Not Viable"}),(0,i.jsx)("h4",{style:{marginTop:"20px",marginBottom:"12px",color:"var(--ifm-heading-color)",fontSize:"1.1rem"},children:e.title}),(0,i.jsx)("p",{style:{marginBottom:"20px",fontSize:"0.95rem",color:"var(--ifm-color-emphasis-700)",lineHeight:1.5},children:e.description}),(0,i.jsxs)("div",{style:{marginBottom:"20px",padding:"16px",backgroundColor:"var(--ifm-color-emphasis-100)",borderRadius:"6px"},children:[(0,i.jsx)("h5",{style:{fontSize:"0.9rem",marginBottom:"12px",textTransform:"uppercase",color:"var(--ifm-color-emphasis-600)",fontWeight:600},children:"Test Results"}),(0,i.jsx)("div",{style:{fontSize:"0.9rem"},children:e.benefits.map((e,t)=>(0,i.jsx)("div",{style:{marginBottom:"8px",color:e.startsWith("\u26a0")?"#ff9800":"#28a745"},children:e},t))})]})]},t))})}),u=[{value:"Intro",id:"intro",level:2},{value:"Fusaka-Devnet-5",id:"fusaka-devnet-5",level:2},{value:"Analysis",id:"analysis",level:2},{value:"Test 1: Can a full node propose a block without MEV-Boost?",id:"test-1-can-a-full-node-propose-a-block-without-mev-boost",level:3},{value:"Data Filter",id:"data-filter",level:4},{value:"Results",id:"results",level:4},{value:"Outcome",id:"outcome",level:4},{value:"Test 2: Can supernodes see 128 columns at max blob count on time?",id:"test-2-can-supernodes-see-128-columns-at-max-blob-count-on-time",level:3},{value:"Data Filter:",id:"data-filter-1",level:4},{value:"Results",id:"results-1",level:4},{value:"Test 3: Can the network recover columns in time?",id:"test-3-can-the-network-recover-columns-in-time",level:3},{value:"Results",id:"results-2",level:4},{value:"Test 4: Can new nodes join the network?",id:"test-4-can-new-nodes-join-the-network",level:3},{value:"Results",id:"results-3",level:4},{value:"Conclusion",id:"conclusion",level:2},{value:"Potential Initial BPO Schedule",id:"potential-initial-bpo-schedule",level:3},{value:"Thanks",id:"thanks",level:2}];function p(e){const t={a:"a",blockquote:"blockquote",code:"code",em:"em",h2:"h2",h3:"h3",h4:"h4",li:"li",p:"p",strong:"strong",table:"table",tbody:"tbody",td:"td",th:"th",thead:"thead",tr:"tr",ul:"ul",...(0,o.R)(),...e.components},{ClickableImage:s}=t;return s||function(e,t){throw new Error("Expected "+(t?"component":"object")+" `"+e+"` to be defined: you likely forgot to import, pass, or provide it.")}("ClickableImage",!0),(0,i.jsxs)(i.Fragment,{children:[(0,i.jsx)(t.h2,{id:"intro",children:"Intro"}),"\n",(0,i.jsxs)(t.p,{children:["Fusaka is quickly approaching, and it's time to start picking ",(0,i.jsx)(t.strong,{children:"B"}),"lob ",(0,i.jsx)(t.strong,{children:"P"}),"arameter ",(0,i.jsx)(t.strong,{children:"O"}),"nly fork values. These are mini hard forks where the only thing that changes is the blob count. They provide a mechanism for core devs to safely scale the chain without the coordination overhead of a fully-fledged hard fork. The current idea amongst devs is to ship Fusaka with safe initial blob count values, collect data, then more aggressively scale up with more confidence shortly after."]}),"\n",(0,i.jsxs)(t.p,{children:["But what do we set those initial values to? We need to pick values that will be safe while also providing enough data to provide insight in to future BPO values. Enter ",(0,i.jsx)(t.code,{children:"fusaka-devnet-5"}),"."]}),"\n",(0,i.jsx)(t.h2,{id:"fusaka-devnet-5",children:"Fusaka-Devnet-5"}),"\n",(0,i.jsxs)(t.blockquote,{children:["\n",(0,i.jsxs)(t.p,{children:["In collaboration with ",(0,i.jsx)(t.a,{href:"https://x.com/testinprod_io",children:"Sunnyside Labs"})," \u2764\ufe0f"]}),"\n"]}),"\n",(0,i.jsx)(t.p,{children:"This network is more of a smoke test than anything. We\u2019re checking things work on a fundamental level but not much beyond that."}
1),"\n",(0,i.jsx)(t.p,{children:"The network has a high node count (1-2k) to help bridge this gap, but this is still ~1/8th of Mainnet. Unfortunately this brings a certain amount of chaos. Individually tending to nodes becomes unviable, and the holes in the ship quickly become insurmountable for humans to plug. As of time-of-writing there is between 50-100 nodes that are failing to attest correctly above a 50% rate."}),"\n",(0,i.jsx)(t.p,{children:"Throughout the lifecycle of this network we've also stepped on a few rakes:"}),"\n",(0,i.jsxs)(t.ul,{children:["\n",(0,i.jsxs)(t.li,{children:["\n",(0,i.jsx)(t.p,{children:(0,i.jsx)(t.strong,{children:"Node misconfigurations"})}),"\n",(0,i.jsxs)(t.p,{children:["Due to a misconfiguration in the Ansible on the ethPandaOps side, ",(0,i.jsx)(t.a,{href:"https://discord.com/channels/595666850260713488/892088344438255616/1417906013511876761",children:'~700 "full" nodes were custodying all columns while being bandwidth limited'}),". This was fixed around 6PM UTC 17/09/25."]}),"\n"]}),"\n",(0,i.jsxs)(t.li,{children:["\n",(0,i.jsx)(t.p,{children:(0,i.jsx)(t.strong,{children:"Multiple client bugs"})}),"\n",(0,i.jsx)(t.p,{children:"This is a great outcome - it's always better to find these in the devnet cycle, but it provides another layer of noise to the data that is challenging to cut through."}),"\n"]}),"\n"]}),"\n",(0,i.jsxs)(t.p,{children:[(0,i.jsx)(t.strong,{children:"Given the above there is only a relatively small window of usable data (~12hrs)."})," This is additionally challenging as some of the testing scenarios are relatively low volume. Given this landscape, we have fairly low confidence in the data found here, but it should do the job for unblocking us on initial testnet BPO values. ",(0,i.jsxs)(t.strong,{children:["We will likely run a ",(0,i.jsx)(t.code,{children:"fusaka-devnet-6"})," in the coming weeks to improve confidence in the numbers found here."]})]}),"\n",(0,i.jsxs)("center",{children:[(0,i.jsx)(t.strong,{children:"This data and analysis is merely a starting point."})," "]}),"\n",(0,i.jsx)(t.h2,{id:"analysis",children:"Analysis"}),"\n",(0,i.jsx)(t.p,{children:"We'll focus on the viability of these Max Blob Count options:"}),"\n",(0,i.jsx)(d,{items:[{count:15,status:"pending"},{count:21,status:"pending"},{count:32,status:"pending"}]}),"\n",(0,i.jsxs)(t.p,{children:["We utilize a metric called ",(0,i.jsx)(t.code,{children:"Head attestation immediately correct %"}),". We define this as an attestation that voted for the block in their duty slot (",(0,i.jsx)(t.em,{children:"not"})," a parent block). This means that the validator saw the block and the required columns before 4s. If an attester votes for a parent block it means they didn't see the block/columns in time. This bundles up a lot of the complexity within the network, like distributed blob building, propagation, block processing time, etc, into a
1nice single metric."]}),"\n",(0,i.jsx)(t.p,{children:'With Xatu we have the ability to filter and group this data on both the proposer side AND the attester side on multiple dimensions. E.g. "Show slots that were proposed by all supernodes and attested to by Lodestar regular nodes when proposed via mev-relay, grouped by proposer CL type"'}),"\n",(0,i.jsx)(t.h3,{id:"test-1-can-a-full-node-propose-a-block-without-mev-boost",children:"Test 1: Can a full node propose a block without MEV-Boost?"}),"\n",(0,i.jsxs)(t.p,{children:["As per ",(0,i.jsx)(t.a,{href:"https://eips.ethereum.org/EIPS/eip-7870",children:"EIP-7870"}),", full nodes have 50mb of upload bandwidth to play with. They have to gossip all 128 columns to their peers, and 66% of the slots attesters have to see those columns before 4s. This is a tough ask for our most bandwidth sensitive network contributors as the blob count scales, and we'd expect to hit a tipping point somewhere here."]}),"\n",(0,i.jsx)(t.h4,{id:"data-filter",children:"Data Filter"}),"\n",(0,i.jsxs)(t.ul,{children:["\n",(0,i.jsx)(t.li,{children:"12 hours of data"}),"\n",(0,i.jsx)(t.li,{children:(0,i.jsx)(t.strong,{children:"Only locally built blocks"})}),"\n",(0,i.jsxs)(t.li,{children:[(0,i.jsx)(t.strong,{children:"Proposed by full nodes"}),"\n",(0,i.jsxs)(t.ul,{children:["\n",(0,i.jsx)(t.li,{children:"Excluding Prysm as it had a block proposal bug throughout the time window"}),"\n",(0,i.jsx)(t.li,{children:"Excluding Nimbus as it is a severe outlier and indicates client specific issues"}),"\n"]}),"\n"]}),"\n",(0,i.jsxs)(t.li,{children:["Attested to by all node types (full + super)","\n",(0,i.jsxs)(t.ul,{children:["\n",(0,i.jsx)(t.li,{children:"Excluding Nimbus (same reason as above)"}),"\n",(0,i.jsx)(t.li,{children:"Excluding Lodestar as it has a sizable amount of nodes with issues throughout the time window"}),"\n"]}),"\n"]}),"\n"]}),"\n",(0,i.jsx)(t.p,{children:"This network only has 10% of the effective balance running on full nodes. Combined with needing to filter out Prysm & Nimbus proposals, which are 40% of our full node effective balance, we're really struggling for data. Nonetheless we can still dive in."}),"\n",(0,i.jsx)(t.h4,{id:"results",children:"Results"}),"\n",(0,i.jsxs)(t.p,{children:["Given the above, we only have 100 slots of data to work with. We're really only checking if these blob counts are ",(0,i.jsx)(t.em,{children:"fundamentally"})," possible though, which helps."]}),"\n",(0,i.jsx)(s,{src:"/img/blog/fusaka-devnet-5/test-1-proposers.jpg",alt:"Head Correctness grouped by proposer CL",caption:"Figure 2.1: Head Correctness grouped by proposer CL"}),"\n",(0,i.jsx)(t.p,{children:"Focusing on the proposer side here, there appears to be a fall off past 21 blobs. Lighthouse is a strong performer."}),"\n",(0,i.jsx)(s,{src:"/img/blog/fusaka-devnet-5/test-1-attesters.jpg",alt:"Head Correctness grouped by attester CL-EL",caption:"Figure 2.2: Head Correctness grouped by attester CL-EL"}),"\n",(0,i.jsx)(t.p,{children:"Looking at the attester side of the equation here. This is observed across all attester CL-EL combos which indicates that the proposers are under stress."}),"\n",(0,i.jsx)(s,{src:"/img/blog/fusaka-devnet-5/test-1-lighthouse-attesters.jpg",alt:"Head Correctness grouped by attester CL-EL",caption:"Figure 2.3: Head Correctness grouped by attester CL-EL for blocks proposed by only Lighthouse"}),"\n",(0,i.jsx)(t.p,{children:"We noticed strong proposed performance with Lighthouse earlier so we can zoom in on just their block proposals. Surprisingly, the 21-31 blob bucket is showing signs of life and is theoretically possible. This indicates that there may be more juice to squeeze out of clients when it comes to pushing the blob count for our bandwidth sensitive operators. Maybe theres something lurking in libp2p implementations? One for the philosophers."}),"\n",(0,i.jsx)(t.h4,{id:"outcome",children:"Outcome"}),"\n",(0,i.jsx)(d,{items:[{count:15,status:"viable"},{count:21,status:"viable"},{count:32,status:"marginal"}]}),"\n",(0,i.jsx)(t.h3,{id:"test-2-can-supernodes-see-128-columns-at-max-blob-count-on-time",children:"Test 2: Can supernodes see 128 columns at max blob count on time?"}),"\n",(0,i.jsx)(t.p,{children:"Nodes will only attest to a block once they see all the columns they're custodying. In the case of Supernodes, this is all 128 columns. We need to assert that these nodes can consistently see all c
1olumns well-before 4s. The worry is that it only takes 1 column to arrive late and a large % of validators won't attest to the block."}),"\n",(0,i.jsx)(t.h4,{id:"data-filter-1",children:"Data Filter:"}),"\n",(0,i.jsxs)(t.ul,{children:["\n",(0,i.jsx)(t.li,{children:"~14 hours of data"}),"\n",(0,i.jsx)(t.li,{children:"All block sources (local & mev relay)"}),"\n",(0,i.jsxs)(t.li,{children:["Proposed by supernodes","\n",(0,i.jsxs)(t.ul,{children:["\n",(0,i.jsx)(t.li,{children:"Excluding Prysm as it had a block proposal bug throughout the time window"}),"\n",(0,i.jsx)(t.li,{children:"Excluding Nimbus as it is a severe outlier and indicates client specific issues"}),"\n"]}),"\n"]}),"\n",(0,i.jsxs)(t.li,{children:[(0,i.jsx)(t.strong,{children:"Attested to by supernodes"}),"\n",(0,i.jsxs)(t.ul,{children:["\n",(0,i.jsx)(t.li,{children:"Excluding Nimbus (same reason as above)"}),"\n",(0,i.jsx)(t.li,{children:"Excluding Lodestar as it has a sizable amount of nodes with issues throughout the time window"}),"\n"]}),"\n"]}),"\n"]}),"\n",(0,i.jsx)(t.h4,{id:"results-1",children:"Results"}),"\n",(0,i.jsx)(s,{src:"/img/blog/fusaka-devnet-5/test-2-proposers.jpg",alt:"Head Correctness grouped by proposer CL",caption:"Figure 2.1: Head Correctness grouped by proposer CL"}),"\n",(0,i.jsx)(s,{src:"/img/blog/fusaka-devnet-5/test-2-attesters.jpg",alt:"Head Correctness grouped by attester CL+EL",caption:"Figure 2.2: Head Correctness grouped by attester CL+EL"}),"\n",(0,i.jsx)(t.p,{children:"Both sides of the equation here show strong results. We don't appear to be hitting any bottlenecks in this configuration as blob count increases."}),"\n",(0,i.jsx)(d,{items:[{count:15,status:"viable"},{count:21,status:"viable"},{count:32,status:"viable"}]}),"\n",(0,i.jsx)(t.h3,{id:"test-3-can-the-network-recover-columns-in-time",children:"Test 3: Can the network recover columns in time?"}),"\n",(0,i.jsx)(t.p,{children:"If the proposer fails to publish a single column, can the network recover that column in time to save the slot? Some Lighthouse nodes have been configured to randomly withhold a column when they propose blocks."}),"\n",(0,i.jsx)(t.h4,{id:"results-2",children:"Results"}),"\n","\n",(0,i.jsx)(c,{}),"\n",(0,i.jsxs)(t.p,{children:["All tested slots successfully recovered the withheld columns and became canonical, achieving ",(0,i.jsx)(t.em,{children:"immediate attestation correctness"})," that is around par for the network."]}),"\n",(0,i.jsx)(d,{items:[{count:15,status:"viable"},{count:21,status:"viable"},{count:32,status:"viable"}]}),"\n",(0,i.jsx)(t.h3,{id:"test-4-can-new-nodes-join-the-network",children:"Test 4: Can new nodes join the network?"}),"\n",(0,i.jsxs)(t.p,{children:[(0,i.jsx)(t.a,{href:"https://syncoor.fusaka-devnet-5.ethpandaops.io/#/?directory=Checkpoint+Sync+%2B+CL+Supernode&network=fusaka-devnet-5",children:"Syncoor"})," has been deployed to fusaka-devnet-5, and has been doing frequent sync tests. Shoutout to ",(0,i.jsx)(t.a,{href:"https://x.com/skylenet",children:"Skylenet"})," on our team for this shiny new tool! The Syncoor UI has in depth metrics around runtime and utilization."]}),"\n",(0,i.jsx)(t.h4,{id:"results-3",children:"Results"}),"\n",(0,i.jsx)(t.p,{children:"New nodes are able to join the network in a pretty linear time fashion across both full nodes and supernodes. Syncoor conducted ~3500 sync tests over the duration of the network \ud83d\udc51"}),"\n",(0,i.jsx)(s,{src:"/img/blog/fusaka-devnet-5/test-4-overview-full.jpg",alt:"Full nodes sync to head",caption:"Figure 4.1: Full nodes are able to sync to the head of the network"}),"\n",(0,i.jsx)(s,{src:"/img/blog/fusaka-devnet-5/test-4-overview-supernodes.jpg",alt:"Super nodes sync to head",caption:"Figure 4.2: Super nodes are able to sync to the head of the network"}),"\n",(0,i.jsx)(s,{src:"/img/blog/fusaka-devnet-5/test-4-erigon.jpg",alt:"Erigon sync times on fusaka-devnet-5",caption:"Figure 4.3: Erigon sync times on fusaka-devnet-5"}),"\n",(0,i.jsx)(t.p,{children:"Erigon is a bit of an outlier here. It's times are increasing at a substantial rate, and it is generally much slower than other ELs, but this is most likely related to the lack of torrent infrastru
1cture on the network. This is something we're working on and will be available in the near future."}),"\n",(0,i.jsx)(d,{items:[{count:15,status:"viable"},{count:21,status:"viable"},{count:32,status:"viable"}]}),"\n",(0,i.jsx)(t.h2,{id:"conclusion",children:"Conclusion"}),"\n",(0,i.jsxs)(t.p,{children:[(0,i.jsx)(t.code,{children:"fusaka-devnet-5"})," provided more challenges than we were hoping but still provided valuable insight in to how the network performs as the blob count increases. ",(0,i.jsxs)(t.strong,{children:["It must be reiterated that the data collected here has a small sample size, and that ",(0,i.jsx)(t.code,{children:"fusaka-devnet-5"})," does not represent Mainnet"]}),"."]}),"\n","\n",(0,i.jsx)(h,{}),"\n",(0,i.jsx)(t.h3,{id:"potential-initial-bpo-schedule",children:"Potential Initial BPO Schedule"}),"\n",(0,i.jsx)(t.p,{children:"Given the viability of the above, we propose a schedule that combines safety, throughput increases, and enough data to inform future BPO decisions. As we go through the testnet stage for Fusaka this may need to be adjusted as new data comes to light."}),"\n",(0,i.jsxs)(t.table,{children:[(0,i.jsx)(t.thead,{children:(0,i.jsxs)(t.tr,{children:[(0,i.jsx)(t.th,{children:"Phase"}),(0,i.jsx)(t.th,{style:{textAlign:"center"},children:"Target Blobs"}),(0,i.jsx)(t.th,{style:{textAlign:"center"},children:"Max Blobs"}),(0,i.jsx)(t.th,{style:{textAlign:"center"},children:"Change"}),(0,i.jsx)(t.th,{children:"Notes"})]})}),(0,i.jsxs)(t.tbody,{children:[(0,i.jsxs)(t.tr,{children:[(0,i.jsx)(t.td,{children:(0,i.jsx)(t.strong,{children:"Electra"})}),(0,i.jsx)(t.td,{style:{textAlign:"center"},children:"6"}),(0,i.jsx)(t.td,{style:{textAlign:"center"},children:"9"}),(0,i.jsx)(t.td,{style:{textAlign:"center"}}),(0,i.jsx)(t.td,{children:"Live now"})]}),(0,i.jsxs)(t.tr,{children:[(0,i.jsx)(t.td,{children:(0,i.jsx)(t.strong,{children:"Fusaka"})}),(0,i.jsx)(t.td,{style:{textAlign:"center"},children:"6"}),(0,i.jsx)(t.td,{style:{textAlign:"center"},children:"9"}),(0,i.jsx)(t.td,{style:{textAlign:"center"},children:"+0%"}),(0,i.jsx)(t.td,{children:"Initial PeerDAS activation"})]}),(0,i.jsxs)(t.tr,{children:[(0,i.jsx)(t.td,{children:(0,i.jsx)(t.strong,{children:"BPO 1"})}),(0,i.jsx)(t.td,{style:{textAlign:"center"},children:"10"}),(0,i.jsx)(t.td,{style:{textAlign:"center"},children:"15"}),(0,i.jsx)(t.td,{style:{textAlign:"center"},children:"+67%"}),(0,i.jsx)(t.td,{children:"Few weeks after Fusaka"})]}),(0,i.jsxs)(t.tr,{children:[(0,i.jsx)(t.td,{children:(0,i.jsx)(t.strong,{children:"BPO 2"})}),(0,i.jsx)(t.td,{style:{textAlign:"center"},children:"14"}),(0,i.jsx)(t.td,{style:{textAlign:"center"},children:"21"}),(0,i.jsx)(t.td,{style:{textAlign:"center"},children:"+40%"}),(0,i.jsx)(t.td,{children:"Few weeks after BPO 1"})]})]})]}),"\n",(0,i.jsx)(t.h2,{id:"thanks",children:"Thanks"}),"\n",(0,i.jsxs)(t.p,{children:["Shoutout to the client teams who worked closely with us throughout this devnet, and to the ",(0,i.jsx)(t.a,{href:"https://x.com/testinprod_io",children:"Sunnyside Labs"})," team who ran a large amount of nodes!"]}),"\n",(0,i.jsx)("div",{style:{textAlign:"center",marginTop:"40px",fontSize:"1.5rem",fontWeight:"bold"},children:(0,i.jsx)(t.p,{children:"\ud83d\ude80\ud83d\ude80\ud83d\ude80"})})]})}function m(e={}){const{wrapper:t}={...(0,o.R)(),...e.components};return t?(0,i.jsx)(t,{...e,children:(0,i.jsx)(p,{...e})}):p(e)}}}]);
Line numbers count LF bytes from the start of the resource, as the search results do. Vendor segments are library code the classifier recognised; they are stored but not indexed. Bytes are shown as Latin1 characters, one per byte.