Dr. Craig Wright introduced the idea of Bitcoin

Bitcoin as a base layer, as explained by Bitcoin inventor Craig Wright at BSV Global Blockchain Convention

In his keynote speech at the recently held BSV Global Blockchain Convention, Dr. Craig Wright introduced the idea of Bitcoin as a base layer for other blockchains. While his speech was a bit heated and slightly antagonizing in the same vein as Russel Crowe’s Maximus Decimus Meridius throwing down the gauntlet of challenge in the Roman colosseum, it did introduce a very interesting concept: that if a blockchain is scalable enough to process more transactions than another blockchain, then could it just run the second blockchain internally, so that the users of the second blockchain could enjoy the low cost and high transaction scalability of Bitcoin while still operating their apps in a context that is specific and familiar to them in their native second blockchain?

Put another way, can a bigger, more scalable blockchain simply subsume a smaller, slower blockchain?

If so, then this model of growth expansion seems to be the best path of adoption for BSV, considering some other blockchains like ETH already have large developed communities and tools created that support their ecosystem. If there was a migration path that meant that users of ETH apps could simply choose between running their programs on ETH or ETH over BSV (EoBSV) then we could build and run some EoBSV nodes and let simple economics do all the selling. Presumably, people will decide to use the network which can support what they want to do with the least amount of transaction fees or gas fees.

Dr. Craig Wright introduced the idea of Bitcoin

How will people’s existing balances and smart contracts work?

At this point, this is just my personal theory, but one way is to build a mirror ETH network, with everyone and every contract balances in ETH being represented. The EoBSV network will be run by a network of bridge nodes that operate a stock Ethereum EVM that listens to and validates ETH transactions. Instead of building blocks on ETH, it will just wrap ETH blocks into Bitcoin transactions and write them into BSV blocks. In this way, this node is acting as a standard ETH node. Except that when it needs to get sync’d with the network on the latest state of anything, it can use the BSV blockchain to retrieve the latest state as of the last ETH block. Because the state of ETH is stored in Bitcoin UTXOs, it does not have the scaling problem, as Bitcoin can prune off old unneeded versions of the ETH state graph snapshots. The UTXO model only keeps the latest version of the state for any contract or address.

Okay, so EoBSV is just a hybrid node, comprised of one part EVM node and one part BSV app service, which writes the state of all ETH blocks into BSV.

What good does this do over a stock ETH node? 

  1. It costs cheaper to write transactions to, given to the fact that gas on BSV is effectively free.
  2. It doesn’t have scaling issues in the form of having to store an ever-increasing state graph.
  3. It keeps up to sync with the existing ETH network for applications that are still using ETH nodes as their primary ledger of truth. 
  4. It uses its BSV UXTO store version of the ETH state for applications that have moved over to EoBSV and create transactions for them that do not communicate back to the legacy ETH network.

Dr. Craig Wright introduced the idea of Bitcoin

As an application looking to migrate, I would imagine this is a one-way process. 

Also, once a smart contract or a transaction committed on EoBSV has been made, then other users who are not using EoBSV aware wallets (and only ETH aware wallets) won’t see the updated state, which exists only on the EoBSV side. This will make application migrations a bit tricky and require coordination. However, once a user base has been moved over, if anyone who has yet to migrate complains about not seeing the up-to-date status of a contract or an account balance, the simple way to fix this is to have them update their wallet to an EoBSV aware one.

In this fashion, this is similar to how tokens work over BSV. When a user using a token-aware wallet sends tokens to someone who doesn’t have a token-aware wallet, they do not see the balance. Even if they cannot see it or spend it, it doesn’t mean that the tokens are ‘broken’ or lost. It just means that the recipient needs to update their app or wallet to one that can recognize the token format, and they will be instantly able to see and transact in the token.

Similarly, if, for instance, CryptoKitties3 were to port1 their service to send their transactions to EoBSV instead of ETH due to the lower fees, then they would start to send their ETH transactions with a corresponding BSV transaction (to pay the BSV miners), perhaps atomically swapped from their ETH balance. Because this fee is much too low to be processed on the ETH network, it likely gets rejected. But the EoBSV node picks it up and records it on the BSV blockchain instead. Henceforth if the users of CryptoKitties3 want to see their updates, they will have to update their wallet to a version that connects to an EoBSV node, which is the only place where they will have the correct balances and state.

In my opinion, what Dr. Wright is suggesting is not that ETH and BSV can be effectively run together as a bridged network, or ‘cross-chains’ as the popular term is these days, but BSV can be used as the scalable backend to run any other blockchain on top, such that migration to the “onBSV” version is a possible scaling strategy for applications and developers on ETH who have spent countless millions of dollars and man-hours developing a platform and business idea on a platform that they later on realized could not scale to meet the demand of their business model, due to the fact of their blockchain being ‘too crowded’ or ‘over used’ by other users and apps.

Dr. Craig Wright on GBC22

In the end, it is always possible to build a Proof of Stake system on top of a Proof of Work one, but not the other way around.

It is possible to build a private system on top of a public one2, but not the other way around.

It is possible to build an encrypted system on top of an unencrypted one3, but not the other way around.

It is possible to build an insecure system on top of a secure one, but not the other way around.

It is possible to build a non-scalable system on a scalable one, but not the other way around.

BSV is Proof of Work, public, unencrypted, secure, and scalable. It can act as the base layer for all other blockchain applications. 

I think this was the gist of Dr. Wright’s challenge to Ethereum.

Game on.

/Jerry Chan

***

NOTES:

[1] Recall that EoBSV nodes have up to date ETH balances for ALL ETH users and smart contracts by the fact that it listens to and keeps in sync with the ETH blockchain

[2] VPNs are private networks on top of a public internet, for instance.

[3] Just try building a non-encrypted system in one that is encrypted by default. While you are at it, try touching your forehead with your tongue.

Watch the BSV Global Blockchain Convention Dubai 2022 Day 1 here:

Watch the BSV Global Blockchain Convention Dubai 2022 Day 2 here:

Watch the BSV Global Blockchain Convention Dubai 2022 Day 3 here:

New to Bitcoin? Check out CoinGeek’s Bitcoin for Beginners section, the ultimate resource guide to learn more about Bitcoin—as originally envisioned by Satoshi Nakamoto—and blockchain.

[id^="_form"]
[id^="_form"]
[id$="_submit"]
[id$="_submit"]
[^;]
[^;]
[?&]
[?&]
[^&#]
[^&#]
[(d+)]
[(d+)]
[elem.name]
[elem.name]
[+_a-z0-9-'&=]
[+_a-z0-9-'&=]
[+_a-z0-9-']
[+_a-z0-9-']
[a-z0-9-]
[a-z0-9-]
[a-z]
[a-z]
[el.name]
[el.name]
[id^="_form"]
[id^="_form"]
[id$="_submit"]
[id$="_submit"]
[^;]
[^;]
[?&]
[?&]
[^&#]
[^&#]
[(d+)]
[(d+)]
[elem.name]
[elem.name]
[+_a-z0-9-'&=]
[+_a-z0-9-'&=]
[+_a-z0-9-']
[+_a-z0-9-']
[a-z0-9-]
[a-z0-9-]
[a-z]
[a-z]
[el.name]
[el.name]