[hiq]

> Sure, but smart contracts have totally different incentives and costs for creating interoperable services than e.g. mobile apps. I would say that Ethereum does help here.

Why would you say that? For what reasons?

To engage with your comment a bit more, regarding costs, it's very expensive to:

* write secure smart contracts (if possible at all)

* maintain a smart contract infrastructure (transaction fees)

There's no solution in sight for either of these.

[kybernetikos]

It's very expensive to write secure smart contracts, true, but it's also surprisingly expensive to write secure systems using more traditional technologies too.

I'm not sure exactly what you mean by it being expensive to maintain a smart contract infrastructure, because if your application suits it, you can literally deploy your smart contract and forget it, and people can use it into the future without you ever having to pay server costs - i.e. for the person deploying the smart contract it can be much cheaper. To the extent that it would be reasonable to hope people would deploy public infrastructure as smart contracts, even if they wouldn't want to deploy public infrastructure as cloud services. If you're worried about overall costs like transaction fees, it's not at all true that there's no solution in sight for them. There are minority cryptocurrencies now with no transaction fees, and even if you are skeptical about their promises, the largest smart contract ecosystem around (ethereum) has a plausible roadmap for dramatically reducing transaction fees. You can checkout the first few that are deployed here https://l2fees.info/ but significant improvements in this area are still expected over the next few years on ethereum.

The point about the incentives is that if you are asked to create a mobile app for a bank to manage mortgages, it is possible but extremely unlikely that you will put the effort in to make this accessible via API to the users or the rest of the ecosystem who might want to create tools that create visualisations, aggregate data for the user, certify that someone in the real world is prepared to lend them significant amounts of data, etc.

If on the other hand you create a blockchain solution to manage mortgages, it is extremely unlikely that you wouldn't create a reasonable externally accessible API - it's the default way of writing blockchain applications.

[hiq]

> without you ever having to pay server costs - i.e. for the person deploying the smart contract it can be much cheaper

That's just offloading the costs (or passing the costs down to the users), that's not a solution.

> it's the default way of writing blockchain applications

There's no default way of writing smart contracts, where does that come from? I've seen my share of smart contracts (tokens, stablecoins, NFTs) where one single address control everything, or where external approval is required for any interaction to happen. There's no "default" there.

Even if you manage to convince a bank or other financial institution to use a blockchain, they won't relinquish control over what they deploy there. There's just no incentive in favor of that, and so many against (regulations, complexity). But more to the point: "using blockchain" as a constraint doesn't change the incentives when it comes to interoperability.