It's easier to build more complex things on top of simpler primitives than vice versa. So a simpler base layer (say TCP/IP for the internet) opens the doors to more complex things on top (say http or JavaScript).
You don't want a Solidity bug (and there are many) to mess with the supply or ownership of Bitcoin. The limited/simple scripting language is there for a reason. It's easy to add complexity and more functionality at Bitcoin base layer: the decision to not do it is the hard (but in my view the right) choice.
Ethereum 2 is very different. It is proof of stake (PoS). This reuses the proof of work of Bitcoin (so very different properties for how hard it is to change blockchain history). Also, PoS has some bootstrapping issues where a new node cannot independently (without trusting other nodes) verify the history of blockchains.
Scalability properties are also very different. Eth2 tried the concepts of sharding between <pick a number> chains. That has issues around added complexity between the shards and contracts needing to execute on shards where other data/logic they need is already available (so gravitational pull towards a mega shard). Stacks has no shards and scales horizontally. FWIW, Eth2 seems to be doing a slow move away from the sharding concept towards layer-2 like scalability as well. They disabled code execution for shards and using them more for data availability in latest iterations.
What you are describing is similar to what Stacks 1.0 was i.e., directly on top of the Bitcoin chain -- a virtualchain. Every Stacks 1.0 transaction was a Bitcoin transaction.
The lessons we learned from that deployment for 2+ years is that (a) it doesn't scale that well and (b) it's very hard to modify Bitcoin and get new changes accepted (for good reason), so you end up with very limited scripting.
To fix the two limitations of Stacks 1.0, we worked on Stacks 2.0 which has a separate blockchain (so scalability independent of Bitcoin) where settlements still happen on Bitcoin and, more importantly, a full smart contract language without modifying Bitcoin itself: https://clarity-lang.org
The design can be thought of similar to a side chain but it's not really a side chain. It uses a new type of consensus, called Proof of Transfer (PoX). Stacks miners have visibility into both the Bitcoin chain and the Stacks chain. Leader election happens on Bitcoin and winning leader writes blocks on the Stacks chain. Details: https://blockstack.org/pox.pdf
Muneeb here, Stacks co-founder. So it does not use Bitcoin as oracle. It uses Bitcoin as a settlement layer. (Oracles like Chainlink can be, and are being, built using Clarity lang for Stacks blockchain itself.)
For using Bitcoin state on Ethereum, you'll need to implement Bitcoin SPV proofs. It's entirely possible but fairly complicated to do that given (a) Ethereum is a separate network that can fork independently from Bitcoin (Clarity contracts on Stacks fork with Bitcoin), and (b) Eth miners have no native visibility into Bitcoin state (Stacks miners have full visibility into Bitcoin state). Possible but more complicated. Further, any asset generation and transfers etc on such ERC20 asset would have nothing to with Bitcoin vs on Stacks all asset generation and transfers etc settle on Bitcoin and are secured by the Bitcoin main blockchain.
Bitcoin has limited scripting language (Bitcoin script) for security reasons. Having a general smart contract language could open up a larger attack surface area for Bitcoin.
The transaction costs will be low initially as they're a function of network traffic. The main thing here is to decouple scaling of transaction (as miroblocks on Stacks chain) from the scalability of Bitcoin (and Bitcoin is hard/impossible to change).
The Clarity smart contracts have direct visibility into Bitcoin state and developers can write logic around it. I do not think the headline implies you are changing Bitcoin to do this (don't think at this point anyone can change Bitcoin in any significant way).
99% of Bitcoin remains passively outside of smart contracts. Only about 5B on Ethereum. This can be a fairly large market and we're in early days. More use cases don't need to take anything away from Ethereum!
We received some push back for Stacks 1.0 as well! And for similar reasons i.e., you don't want to put a lot of additional data into the Bitcoin blockchain (makes it much harder to scale Bitcoin that way).
This was the primary reason why for Stacks 2.0, a hard design requirement was to make absolutely no changes to Bitcoin and to not put additional data in Bitcoin.
With Stacks thousands of STX transactions result in a single hash on Bitcoin (technically on the order of active miners on Bitcoin), so Stacks transactions automatically settle on Bitcoin every block.
Muneeb here, Stacks co-founder. Great question. You are right that Clarity smart contracts have direct visibility into Bitcoin, so you can write a contract that has logic triggered by pure Bitcoin transactions.
Moving Bitcoin to Stacks is a bit more complicated and there are several ways:
a) Wrapped assets. Tokensoft + Anchorage (custodian) have a solution that they're calling xBTC where a "wrapped Bitcoin" is issued on the Stacks chain. Such wrapped assets exist on other chains like Ethereum as well with one main difference that xBTC is secured by Bitcoin itself.
b) There are more decentralized solutions similar to Keep network, where threshold signatures can be used to move the assets by a group of nodes.
c) The most decentralized way of doing this is by locking your BTC directly on BTC chain, using Clarity to monitor funds, and then having Clarity trigger release of funds on Bitcoin chain. This requires Clarity logic to trigger Bitcoin state changes. This is theoretically possible but at R&D stage currently.
Can decentralized (i.e., user owned) storage help here? Instead of keeping data only at user device, it can be backed up in an encrypted and private way.
Gaia is one example: https://github.com/blockstack/gaia
(I've worked on Gaia so I'm biased but there are other such decentralized options as well.)
The pay outs are in Stacks (STX) tokens. Only the pilot phase was in USD/BTC which came from a developer growth/marketing budget that Blockstack PBC funded.
The point is global coordination without going through a big company like Facebook.
Take the Dmails app for example, you can email me there on muneeb.id -- this will not be possible with an offline app.
I hear you on the developer focus for Blockstack. We might start a different brand that is consumer-focused. Right now the best page for consumer info is: https://blockstack.org/try-blockstack
The source of money is newly minted tokens, just like in Bitcoin the miners operating the nodes and processing transactions get the newly minted tokens.
Dpage can be easily converted to a Desktop app. Most of the app logic is client-side anyway and hosting at a domain is mostly for convenience.
Blockstack's "centralized servers" doesn't really fully capture the technology at play here. The pointers to user data lockers are stored in the Stacks blockchain, and users can host their own private encrypted data lockers where they want. Blockstack PBC does provide a free service to host data lockers, as a way to help bootstrap initial usage.
The decentralization comes from (a) open-source GPLv3 code, (b) permissionless blockchain, (c) enabling users to host private data lockers, among other things.
The discussion on decentralization in our recent SEC offering circular -- page 49 and page 69 at https://stackstoken.com/circular -- is also relevant here.
I worked on this for free until we could raise venture capital to support the open-source development. Without venture capital, I'd probably be working on it in academia but I think that'd be less impactful given limited resources. Developers have been building apps on Blockstack since 2017, the App Mining program was introduced in late-2018. There is a genuine community of developers who'd work on this for free because they believe in the mission.
Users don't have any strings attached. There is a free username registration service for them (the default method) and the apps on https://app.co/blockstack provide real utlity while hiding blockchain-complexity. I don't think most users even realize that there is any blockchain involved.
Finally, no user is being paid to use any app. The App Mining program for developers is the only component in the ecosystem where any incentives/payments are involved. Apple had developer incentive programs for iOS for example. When launching a new platform you have the chicken & egg problem of users and apps. We're trying to get enough high-quality apps so users can get real utility. The App Mining program stops after the initial years.
It's easier to build more complex things on top of simpler primitives than vice versa. So a simpler base layer (say TCP/IP for the internet) opens the doors to more complex things on top (say http or JavaScript).
You don't want a Solidity bug (and there are many) to mess with the supply or ownership of Bitcoin. The limited/simple scripting language is there for a reason. It's easy to add complexity and more functionality at Bitcoin base layer: the decision to not do it is the hard (but in my view the right) choice.