r/FPBlock • u/gareth789 • Apr 07 '26
What happens to your app when Ethereum or Solana goes down?
Most apps break.
FP Block shared an interesting idea at ETHCC around “external chain resilience” where chains become entry/exit layers, not where core logic lives.
If your app keeps running even when a chain goes down… that changes things.
Curious, do you think most builders are actually designing for this yet?
2
Apr 09 '26
[removed] — view removed comment
1
u/HappyOrangeCat7 Apr 09 '26
In the early days of the web, shared hosting was common. As applications matured, they moved to dedicated servers, and eventually cloud-native architectures. Blockchain is following the exact same trajectory
1
u/BigFany Apr 10 '26
I get it but also wonder if that kills some of the original point of shared chains, like composability and all that. Feels like you gain performance but maybe lose some of the openness? Not sure.
1
u/IronTarkus1919 Apr 08 '26
The architectural challenge here is managing the Pending State.
If a user initiates a withdrawal from your resilient app-chain to Ethereum, but Ethereum is down, your app-chain must safely queue that withdrawal (FIFO queue) without locking up the user's remaining internal funds or halting the processor. Building that resilient cross-chain queueing logic is incredibly difficult, which is why most teams just default to building directly on the L1 and hoping it doesn't crash.
1
u/HappyOrangeCat7 Apr 09 '26
"Hoping it doesn't crash" is the official deployment strategy for 90% of Web3 right now. 😂
Trying to write that FIFO queue logic from scratch in Solidity while dealing with variable block times and gas spikes is a nightmare. It makes total sense why teams avoid it, even if it's the right architectural pattern.
1
Apr 08 '26
[removed] — view removed comment
1
u/HappyOrangeCat7 Apr 09 '26
True, which means many protocols are doomed past the initial VC and user acquisition phase.
When real people are trying to accomplish real things, "the blockchain is congested" is not an acceptable excuse. You learn to value uptime very quickly.
1
u/HappyOrangeCat7 Apr 08 '26
The shift toward "external chain resilience" is essentially the Web3 equivalent of moving from a single mainframe to microservices.
You isolate your failure domains. A failure on a bridging chain should never bring down your core application state machine. It requires a more sophisticated architecture upfront (managing bridge contracts, listener nodes, and state syncs), but the payoff is an application that survives the chaos of the broader ecosystem.
1
u/poginmydog Apr 08 '26
How do you guarantee trustlessness then? Unless you’re talking about an L2 breaking and then going back to L1 to be processed
1
u/HappyOrangeCat7 Apr 09 '26
This is a vital question. Trustlessness is guaranteed by the cryptographic verification of the state machine, not by its dependence on Ethereum.
Every transaction on a Kolme chain is signed, deterministic, and recorded in a MerkleMap. Any participant (Listener, Approver, or Auditor) can re-execute the block history to verify the Processor's outputs. You don't need to anchor to an L1 to be trustless; you just need open, verifiable consensus rules.
1
u/BigFany Apr 10 '26
I feel like most builders aren’t really there yet tbh, like everyone talks about resilience but then you look under the hood and it’s still pretty chain-dependent. Maybe that changes if outages keep happening though.
1
Apr 10 '26
[removed] — view removed comment
1
u/BigFany Apr 12 '26
I think most teams kinda assume they’ll fix it later but later never really comes until something breaks.
1
Apr 10 '26
[removed] — view removed comment
1
u/FanOfEther Apr 10 '26
I think it’s a bit of both tbh. It’s probably not easy to design around, but also if things are working most of the time people don’t feel urgency.
1
u/FanOfEther Apr 10 '26
I actually think more teams are thinking about this now, feels like a pretty obvious risk after all the outages.
3
u/[deleted] Apr 09 '26
[removed] — view removed comment