May problema ang ZK infrastructure na hindi malulutas ng karaniwang computing power: walang halaga ang availability kung hindi maipapadala ang proof sa tamang oras. Maaaring magkaroon ng libu-libo ang GPU ng isang network at nananatili pa ring nahihirapan na suportahan ang isang application nang mas mahalaga ito. Maaaring available ang hardware, ngunit hindi compatible sa isang partikular na workload. Maaaring tanggapin ng isang machine ang isang job ngunit mabigo itong tapusin sa loob ng kinakailangang panahon. Kahit na matagumpay na nabuo ang proof, mas mababa ang kahalagahan nito kung ang koordinasyon ay nagdudulot ng hindi kinakailangang pagkakatigil. Ang tunay na hamon ay ang pagpapalit sa mga nakalat na computing resources sa isang sistema na kayang asahan ng mga developer. Ito ang nagiging dahilan kung bakit worth watching ang infrastructure layer sa likod ng zero-knowledge technology. Habang lumalawak ang ZK applications, lumalaki rin ang diversity ng proving requirements. Magkakaibang workload ay nangangailangan ng magkakaibang hardware capabilities, execution times, at resource allocations. Ang pagtrato sa bawat machine bilang magkakapareho ay nag-iisip na walang komplikasyon sa pagpapadala ng isang partikular na job mula sa request hanggang sa matagumpay na pagkumpleto. Si @fermah_xyz ay umuunlad sa hamong ito sa pamamagitan ng Froben, na nakatuon sa paggawa ng proving resources na accessible sa pamamagitan ng isang coordinated marketplace. Ang interesante ay hindi lamang ang pagkonekta ng applications sa mas maraming hardware. Ito ay ang pagpapabuti kung paano hanapin ng workloads ang angkop na resources, kung paano mag-ambag ang operators sa kanilang available capacity, at kung paano trato ng sistema ang execution kapag nagbabago ang mga kondisyon. Isipin kung ano ang ibig sabihin nito para sa isang lumalaking ZK project. Sa halip na bumuo ng sariling infrastructure para sa bawat posibleng workload, maaaring makakuha ang team ng mas malawak na pool ng proving resources. Samantala, mas maraming oportunidad ang mga operator na gamitin ang kanilang hardware para sa mga gawain na angkop sa kanilang kakayahan. Magkakabuti pareho dahil sa mas mabuting koordinasyon, ngunit lamang kung ang infrastructure ay kayang magbigay ng consistent na resulta. Dito nakasalalay ang tunay na competitive advantage. Dapat hinggin sa isang proving marketplace ang mga gawain nito na natapos, hindi ang mga hardware na itinatampok nito. Gaano katiyak nito ang pagpapares ng workloads sa mga angkop na machine? Gaano kaepeksiyente nito ang pagpapalit sa available resources sa natapos na proofs? Gaano kahusay nito ang pagpanatili ng performance habang nagbabago ang demand at mga kinakailangan ng workload? Ito ang mga tanong na naghihiwalay sa isang directory ng computing resources mula sa isang infrastructure na maaaring gamitin ng mga application. Para sa ZK ecosystem, mahalaga ang pagkakaiba na ito. Dapat nakatuon ang mga developer sa pagbuo ng mga kapaki-pakinabang na application, hindi sa patuloy na pag-aalala kung kaya ba ng proving layer na sumunod. Kung kayang gawin ni @fermah_xyz na mas accessible, coordinated, at dependable ang proof generation sa pamamagitan ng Froben, maaari itong tulungan alisin ang isang mahalagang hadlang sa pagtanggap ng ZK. Sapagkat ang susunod na yugto ng paglago ng ZK ay hindi depende lamang sa computing power. Ito ay depende kung gaano kaepeksiyente nai-organisa ang power para maging reliable na proof delivery.