A reason or excuse given to hide the real reason for something.

--Thunder Genesis Block(?)

Motivation

The current form of Bitcoin (BTC, currency) can be expanded—enough to handle every txn in the world! It just needs the correct combination of the 2nd layer.

This article will introduce "Thunder"—a large block sidechain network. When I say "large block sidechain," I mean a sidechain network that is essentially the same as its main chain network, but with larger block size/sigops limits.

A. Today's 2nd Layer

The Lightning Network provides some solutions, but if every user needs bytes from the 1st layer, the main scalability advantage of the 2nd layer will be lost (1) Custodial solutions (as initially envisioned by Satoshi and Hal Finney in 2010) also work well and are user-friendly… but users are responsible for the custodian.

Below is a table comparing Thunder with these two more prominent Layer 2 solutions (LN and Custodial):

• See here. 75/222=.337.

The main problem with custodial Bitcoin is that gold has already tried this strategy, and after a while, people no longer care about potential gold, but rather care about the custodian's ledger (i.e., the custodian's view of who owes how much money). More.

State chains are another 2nd layer with very interesting and unique properties. That is, they do not need bytes from the 1st layer to onboard each new user, but they do require that every UTXO used "in" the state chain be onboarded through the 1st layer. This is better than LN, but still has issues.

SNARKS are of no help for scalability, as they cannot solve the so-called "data availability problem." There is no way to use SNARK to recover the event sequence that led to its creation. There is also no way to audit SNARK to ensure it is functioning properly without needing all the raw data at hand. Therefore, SNARKS are not helpful for scalability and may only serve as an enhancement for SPV-level security.

B. New Framework

An old criticism, by scaling through block size increases, runs as follows:

It suggests that capacity increases are childish, unprincipled, undisciplined, and will degrade the quality of the entire network. In contrast, enforcing property rights (i.e., enforcing a 1MB block size limit) may seem harsh, but overall, this "tough love" is the only way to build a reliable, sustainable, high-quality system.

That criticism is accurate, I'm not trying to overturn it!

But I do want to tweak it a bit. Instead of making the choice "100% clean" vs "100% overcrowded," I'd rather people think of the situation as having different sections on the same train: first class, business class, coach, etc. In that model, passengers have different experiences in many important ways, but they also have some things in common.

First/Business class is small block "Layer 1"—expensive but high quality; cheap nodes, reliable access to the blockchain, high txn fees.

Coach will be the large block "scalable sidechain" of the 2nd layer—cheap to use; but more problematic full node experience, less decentralization.

But crucially, these two "classes" can benefit from sharing the same airplane. In the sidechain analogy, this is two chains sharing a 21 million coin limit, sharing hash power, and being interoperable (meaning people who usually ride first class can choose to downgrade to coach to save money, and people who usually ride coach can choose to upgrade their experience by paying for first class). In a world without sidechains, people would have to ride airplanes with only one seat for everyone.

Real-world transactions come in various forms and scales. Not all transactions require the same level of trust, and not all transactions can bear the same cost overhead. More.

C. Power Decentralization

A one-size-fits-all approach to full decentralization actually makes Bitcoin fragile. Committing to a "very decentralized" policy is a gamble. It's a bet that says: we live in a hostile world.

On the contrary, if the world is good, then we will lose that bet.

Decentralization is useful for those with power—governments, black-hats, oligarchs, tech giants, cancel culture, etc. To gain this valuable decentralization, Bitcoin must sacrifice other valuable things: usability, txn costs, engineering effort, etc.

Therefore, in a world friendly to promoting all cryptocurrencies, the advantage lies with less decentralized coins (ETH, BSV, etc).

Even worse, the "powerful" may realize this and use it against us. Initially, they can bide their time, allowing all cryptocurrencies to flourish, thereby (through network effects) allowing the least decentralized coins to leverage their natural advantage to eventually supplant others, including BTC. Once decentralization is removed from the cryptocurrency world, the "powerful" can then "tip-toe" in, seeing if they can safely escape (using network effects as an anchor). Once done, they can slowly tighten the noose from there. More.

If users can choose their desired level of decentralization (which Thunder allows), then the entire risk can be avoided. In the Thunder-world, we don't need to worry about "losing" the bet ("the world is good"). If, on the contrary, "the world is good," then it just means that a larger portion of the BTC 21M coins will be on less decentralized sidechains. If the world shifts from good to mean, the coins will shift the network from less decentralized to more decentralized. It will never impact Bitcoin's competitiveness in the broader cryptocurrency market, and the Layer 1 main chain will never "collapse."

D. "Bitcoin VS. Banks"

The phrase "Bitcoin vs Banks" is a common Bitcoin slogan.

However, unless "Bitcoin" (in a broad sense) has a complex layered payment system—with many "layers" and a large amount of netting—it cannot pose a serious challenge to the traditional banking system.

For me, "money" is centered around payments. This explains why laypeople always ask: "Bitcoin… but who accepts it?". Money is our way of keeping track of who owes who favors. It is not a medium of exchange or a store of value, but a means of payment.

Similarly, this is not to say that small blockism is wrong. I am a small blocker—Bitcoin should strive to maintain its "Swiss bank account in your pocket" quality.

But unless Bitcoin has some way to scale to handle all transactions in the world, Bitcoin will never be able to fully realize its potential.

First, let's ask: How many transactions are we talking about?

How many transactions are we talking about?

A. USA

We can see from the 2019 Federal Reserve Payments Study, Table B1, that the average "card" payment in 2018 was $54. 131.2 billion payments were made in this manner.

We can also see from the 2018 FEDCPODCPC survey, Figure 7, that in terms of quantity, cash payments make up about 40% of "card" (credit and debit card) payments.

This means in the US, (131.2*1.40)=1836.80 billion payments (card+cash) are made annually. With 52,560 blocks per year, this equates to 3.5 million txns/block. If each txn is 250 bytes, this means a block space requirement of 875 million bytes, or 875MB.

We need to greatly exceed the "average rate" (transactions are not evenly distributed over 24 days—most occur during the day). However, the network's actual expected usage (determining bandwidth/storage/CPU requirements) is the average rate.

B. World

According to the World Payments Report (2018), Figure 1.1, non-cash txns in 2016 were 482.6 billion/year; and show an annual growth of 9.8%. (2)

At this rate, by 2021 there will be 770 billion non-cash transactions annually, equivalent to a TPS rate of just under 25,000 transactions per second. We can adjust again by 40% to include cash transactions, which would bring us to 35,000 TPS.

Of course, this number will grow over time, but we can use it as a benchmark for today.

How to achieve that level of Txn throughput?

A. Sidechain Teams

Of course, using all of our second layer at once.

But what I'm thinking of is: several large block sidechains, added in sequence. We start with one sidechain—it might have a 10MB block size, programmed to slowly rise to 1GB over 10 years.

If more capacity is needed, we can wait patiently (for the 10MB block size to rise to the final goal of 1GB over time). But more importantly, we can also add another sidechain at any time.

I call this strategy "Thunder," each sidechain being a "T-network."

B. How It Works

As I mentioned, over time, we can add more "thunders" in parallel.

Mainchain (Layer-1 SmallBlock Bitcoin)

|

--------|----------|------------|--------|--------|----------|---------|--------|------|--

Thunder Thunder.Asia T.Europe T.CN T.India T.Arabia T.Alt T.Africa T.USA

Time ---> 2023 2024 2028 2030 2034

To improve efficiency, the internal txns within Thunder should be much more numerous than those crossing Thunder. Therefore, it is obvious to mimic the past banking networks and divide the network by geographical region. See: OCA.

How do we move from our current position to a future with many large block sidechains?

It starts with creating the first large block sidechain. This sidechain eventually fills up. Therefore, a new second large block sidechain is needed.

Old users may not want to leave their network, so in general, I would like the second largest group to create a new network in the crowded old network (see below). So, if the USA is an early adopter of Thunder, I would like them to stay on the "Thunder" network (the first and oldest network), just like the country code " +1" for American phones. Eventually, (assuming, in 2034, as shown above), the first network may become too crowded for non-American users (despite having many non-American networks), and non-American users will want the updated features, so a network centered around the USA will emerge very late.

Note that each time a new network is created, everyone's transaction fees will decrease (for example, when T. India is created, all Indian users will quickly migrate from "Thunder," "Thunder.Asia," and "T.CN" there).

The question of "who has to leave and start their own network, and who stays on the old network" may become a ZZ problem. But this conflict is likely to resolve itself. First, immigrants can start fresh with a new blockchain, getting all the latest technological improvements (like switching from 4G to 5G). Secondly, there is a non-ZZ standard—the members in the old network who can least tolerate high fees will be the ones motivated to move forward (and then they will take their trading partners with them). So, this process may be self-regulating.

C. Realism

This plan reflects the actual structure of today's monetary system. This may be a good sign.

Thunder Thunder.Asia

\ /

\ /

\ /

Mainchain (Layer-1 Bitcoin), Smallblock

/ \

/ \

/ \

T.Europe T.CN

US Federal Reserve Bank of Japan

\ /

\ /

\ /

Bank of International Settlements

/ \

/ \

/ \

European Central Bank People's Bank of CN

"It is clear from the map that, by this definition, the largest economies are the least open. But this is natural: because they are so large, most of their trade is internal."

From here.

Above image: Blackboard sketch of the banking network in the 1800s. Different local banks settle with each other at the central bill exchange. From this video.

Above image: Warcraft III server list (US East, US West, Europe, Asia). You can play on a server that matches your location to reduce latency, increase the likelihood of playing with players who speak your language, play in your time zone, etc. Start from here.

See also: Payments Just Want to Be Free

Other Interesting Features of Thunder

A. Automatic Capacity Management

When T.network txn fees grow too high, anyone can solve this problem by creating a new T.network. But if the sidechain is not truly needed, it will be unwelcome and fail.

B. Once-and-for-all Solution

The advantage of this solution is that it provides a once-and-for-all solution to scaling (or at least "capacity").

In contrast (for example), BCH must increase its block size through regular hard forks. This leads to many big problems. One problem is the risk of splitting (as happened with BSV) or the risk of ZZ strategies (as happened with BitcoinABC's "IFP").

In contrast, the extreme of MonochainBTC, which never hard forks, must hope that its current technical configuration will always work now and in the future. Or, it must hope that it can always successfully move forward through central planning (including the current central planners being able to pick competent successors). Both hopes are unfounded (the world is too complex, changes too fast, too chaotic).

C. Technical Debt/Overall Design Freedom

New T. Networks do not have to be soft forks of existing T.Networks. If desired, a new code fork can start completely from scratch.

For example, if we had Thunder in 2014, then SegWit might have been coded as a "hard fork." This "incompatible" SegWit version could never be merged into Layer1 Bitcoin Core, but it could easily be merged into any-Thunder-network-coming-line-in-in-2016. This is a big improvement in many ways: code review, code complexity, transparency to end users, likelihood of errors, engineering time/effort required, etc.

D. Future Protection/Hard Fork Desire/Competitive Development/Hardware

Since each new sidechain is a completely new software, there is complete design freedom.

Those concerned with scalability (such as Roger Ver or the "Bitcoin Foundation") can sponsor a competition to encourage new blockchain designs focused on scalability. The winner will be the person who produces the most productive software. We can even have "T. India.RogerVer" and "T.India.Blockstream"—competing software. (In fact, they are already competing with each other.)

This can even be seen as a competitive response to the mountain coins committed to regular upgrade strategies through hard forks (such as Monero/Cash). Now "Bitcoin" can do this too (if "Bitcoin" refers to including all BTC sidechains).

Additionally, each new sidechain can be paired with its own custom hardware.

ECDSA signature verification… I can imagine people

writing hardware that did ten million per second.

-Gavin Andresen, to Greg Maxwell; Nov 2015

Above image: Group discussion - DevCore Draper University 2015, 7:54

Supporters and critics of "hardware scaling" have overlooked the most important difference between Layer 1 and Layer 2. To resist bao politics, Layer 1 Bitcoin full node software must run on hardware that is easily obtainable (especially hardware that is easily obtainable for non-Bitcoin purposes). But this is not the case for Layer 2 software—Layer 2 software can be part of a custom software/hardware pair (thus, it can be more efficient).

See also:

• Peter Rizun demonstrated hardware scaling.
• Andrew Stone demonstrated software handling 256MB blocks.

See Appendix 2 for some thoughts on what the next T.network might contain.

Finally: a very interesting benefit.

Achieving Security through Geographical Distribution

How well can countries coordinate? If two countries hate each other, then each country's T.network can safely hide within the jurisdiction of the opposing country.

A. Introduction

To make the scheme effective it would be

important…to provide that banks in one

country be free to establish branches in

any of the others.

-F.A. Hayek, "Choice in Currency" (1976)

It's hard to imagine the Internet getting

segmented airtight. It would have to be a

country deliberately and totally cutting

itself off from the rest of the world.

Any node with access to both sides would

automatically flow the blockchain over…

It would only take one node to do it.

-Satoshi Nakamoto, "Re: Anonymity" (2010)

Above image: Here and here.

B. Robin ZZ Shelter

To improve efficiency, the network will be distributed geographically.

This distribution may trigger an incredible and most unexpected benefit: a cycle ZZ "shelter" for T. Networks.

Of course, the operation cost of a large block network is higher. But cost is not the main drawback of large blockism. On the contrary, the concern of large blockism is that large nodes must send/receive/ process a large amount of data, making it harder to hide the physical location of nodes. This in turn makes nodes vulnerable to harassment and subservience to local ZZ.

For example:

Above image: Comment from the Samorey Telegraph Group "This is Bitcoin." Bitcoin is anti-bao jun, pro-"resistance" and pro-"different naozi."

Now, consider what it would look like in a Thunder-supported Bitcoin world when jurisdiction and service areas do not overlap.

“Nigerian resistance to a sir bao” would use the "T.Africa" network—after all, they live in Africa. The Nigerian government is powerful—perhaps powerful enough to pursue everyone running a full node in Nigeria. But what about nodes in Cameroon? Or in Egypt? Or in Morocco? Nigerian citizens can start a node elsewhere and then tunnel in.

The Moroccan law enforcement may not care why some crazy Nigerian separatists want to stop some T.Africa payments. Will the Egyptian government shut down their own payment network to help foreign Nigerian separatists? I doubt it.

Politicians are obsessed with ZZ issues in their own country, but they hardly care about ZZ issues in neighboring countries.

C. "At Your Service!"

But it gets better! Can you imagine activists in the US and Europe running T.CN and T.Asia nodes? They can not only run nodes, but also servers to quickly create more nodes. Maybe these people are recent refugees from Russia/China; maybe they are just ZZ activists.

And there are always foreign companies. Amazon Web Services can always (indirectly) sell T.CN full nodes to Chinese people. They just need a tunnel and some coins!

And there are always foreign governments. If there is only one Bitcoin network, all the world's authoritarian governments might naturally unite against it; thus they are more likely to cooperate to destroy it. But if there are many different networks affecting each country differently, some countries will become natural enemies of each other. The US government might run a T.Asia node just to cause trouble for Vladimir Putin. Maybe the Iranian government (always a victim of financial sanctions) will run all the nodes out of spite; or the Mayor's Office of London/New York City (the world's financial capitals) will run all the nodes as a public service.

Above image: Game Civilization IV; your government can "liberate" citizens to make life difficult for rival governments. If many rivals adopt "liberation," then you are basically forced to adopt it. Start from here.

D. IN Summary

My point is: the main drawback of large block nodes is their high computational cost, making them more susceptible to local government bao politics. An unexpected benefit of having a large block node team is that local governments are actually fighting against the citizens using nodes in each jurisdiction.

(Especially with Drivechain's blind merge mining. In BMM, node operators "mine" and earn profits by offsetting the operating costs of the nodes. Generally, these balanced profits will be reduced to zero (even if there are only two competitors, each trying to BMM). However, if nodes are harassed existentially, the environment will no longer be fully competitive. Some node operators will succumb to existential harassment, but other node operators can easily ignore the harassment (giving them a comparative advantage and profit opportunity).)

Summing Up/Conclusion

A. How Many T. Networks Are Needed?

In Appendix 2 below, I estimate a representative T.networktxn can be shrunk to 197 bytes.

If all txns are 197 bytes, then 500MB of block space can accommodate 2.538 million txns. With one block every 10 minutes, this would be 4230 transactions per second. Above, we calculated the total global TPS in 2021 to be 35,000 transactions. In other words, just nine Thunder sidechains would allow Bitcoin to handle every transaction in the world, non-custodially.

B. How Much Does Each T.NETWORK Cost?

In Appendix 1 below, I estimate the upfront cost of a 1 GB Thunder node to be $6825.50, with a monthly cost of $386.98.

Is this cost prohibitive or negligible? It's best for you, the reader, to decide.

It's roughly equivalent to what an American spends on a car—several thousand dollars down and then a few hundred dollars per month.

Of course, it's small compared to running an exchange, mining operation, hiring software developers, or buying 2 BTC (which is one millionth of the total supply). It's small compared to the current state of USD, because currently we have no way to "run a full USD node" (so, there, the cost is infinite). On the other hand, it's high for an amateur enthusiast.

C. Why Not Consider Total Cost?

The total cost of nine telecom networks is certainly $61,429 upfront and $3482 per month.

But each user only needs to verify their own payments (especially the payments they receive). Similar to the Lightning Network, users can safely ignore txns that don't apply to them.

Users can insist on getting paid on their own network. That way, they only need to verify one T.network.

Appendix 1: USD Cost of a 1 GB Blocksize Node

Let's take a look at the requirements.

Note: I looked at these prices in mid-2020, and of course they are likely to change over time. But in any case, I have included the hyperlinks I used in mid-2020. Hopefully they remain accurate for a while.

A. Storage

I mentioned before that sidechains can discard old history (unlike the main chain). With clever UTXO commitments, it might be possible to discard block history older than 6 months.

Since there are 26,280 blocks every 6 months, a 1 GB block size would produce a total block storage requirement of 26.28 TB, plus more for storing UTXO data and other databases.

$3000 for hard drives

B. Bandwidth

1 GB every ten minutes, i.e., 8000 bits/600 seconds, i.e., 13.33 Mbps. Our requirements will be higher—we must consider block time variability and precious upstream bandwidth.

This Verizon Fios 1 Gbps service charges $215 per month

C. Computation

A typical 1MB block will contain approximately 2500 txns. So we can expect a 1 GB block to contain 2.5 million txns.

Jameson Lopp tested node performance and found a machine could sync the Bitcoin Core from genesis (January 3, 2009 - October 23, 2018) chain in 311 minutes. Most interestingly (for our purposes), this machine was apparently CPU bottlenecked.

Blockchain.info reported a total of 350,934,692 txns during this period (January 3, 2009 to October 23, 2018).

So: 350,934,692 txns/311 minutes = 11,284,073.7 txns every 10 minutes. Again, block time variability is large, so we need to be able to handle occasional "unlucky" blocks, but this machine's CPU can handle 4.514 times our baseline requirement (2.5 million txns every 10 minutes).

I can build a machine with twice the RAM (Jameson's), 15% faster CPU, for $3205.24.

D. Power

The computer's rated power is 1200W (i.e., 1.2kW). If we somehow need 100% power, 24/7, then we will consume 28.8 kWh per day. At $0.132 per kWh, this makes $3.8 per day, or $114 per month.

If we increase by 20%, it should be enough to cover the CPU and the huge array of hard drives.

So, $136.8 per month.

E. Total

If we add a 10% "candy factor" (for installation, labor, incidentals, etc.), then we have:

Upfront $6825.50

$386.98 per month

The real total ownership cost is almost certainly lower, as we have overestimated everything.

Appendix 2: Possibilities for the Next T.Network

A. SCHNORR/BLS

Native addition of Schnorr signatures (i.e., making all outputs Taproot-Script).

Or possibly: BLS signatures

B. Smaller TXNS

If the sidechain is to emphasize scalability, then we might try to make txns as small as possible.

Satoshi's txns actually have a bit of waste:

There are four "version bytes," allowing for billions of possible txn versions. However, out of these billions of versions, we only use three. So we can reduce these four bytes to one, saving three bytes.

The nLockTime field is usually not used. However, it consumes four bytes. We can specify its existence depending on a specific "version" value. So in most cases, we can save four bytes.

Most txns accept 5 or fewer inputs, pay to 5 or fewer outputs. However, two bytes are used to specify input/output information. We can predefine some version types to always describe txns adopting these "ordinary" forms (e.g., 1 input 2 output P2PKH). Thus, we can eliminate internal VarInts, and even eliminate internal scripts.

If Thunder intends to focus on on-chain txns, it doesn't need any features at all. Just send the minimum necessary for a txn.

For example, the "minimal" txn might look like this:

1 byte: version*

36 bytes: Input UTXO: TxID (32 bytes) + Position (4 bytes)

104 bytes: spend authorization

71 bytes: signature**

33 bytes: Compressed PubKey

28 bytes: output 1 -- value (8 bytes), Hash160 (20 bytes)

28 bytes: output 2 -- value (8 bytes), Hash160 (20 bytes)

See (*) and (**), below.

…Total of 197 bytes.

The version will specify # of inputs and outputs, in this case: (1,2). For 100 of the 256 version types, we can specify txns containing 1-10 inputs and 1-10 outputs.

See here and here, these are always 71 bytes or fewer now. [If fewer, can be zero-padded, if fails, let the interpreter redo.]

C. Other Opportunities

Currently, returning a "memo" through OP requires an output with a value of 0 (i.e., 8 bytes consisting only of zeros). Instead, certain version types can be predefined to always include a "memo" field at a specific position. This will avoid wasting these 8 bytes.

When new features are added to Bitcoin Core as "soft forks," they often involve awkward flags or indicator bytes. But when the next Thunder network is ready to be created, these features can be folded into a new txn version, spending zero marginal bytes (and without involving awkwardness).

D. Accumulators/Fraud Proofs

We can not only save bytes, but also enhance the security of SPV. One important method is to eliminate 4 classes of block flaws through accumulators, as I described here. This will allow Bitcoin to support fraud proofs. If any block is invalid in any way, SPV nodes can receive cheap, reliable, and immediate warnings. Therefore, SPV nodes will have the same security as full nodes (3). This is ideal, because (of course) in a large block system, most users will run SPV nodes.

E. Simple Malleability Fix

The "SegWit" method used by Bitcoin Core to fix transaction malleability is (unfortunately) very strange and complex. Instead, the "hard fork" method of simply editing the transaction serialization function would be much clearer.

F. Other

From the hard fork wishlist:

Byte order consistency (big-endian)

Elimination of redundancy in variable-length integer encoding, possibly switching to standard.

Footnotes

In fact, Lightning, due to the need for the first-layer bytes to onboard each new user and the periodic maintenance of the first-layer bytes, is only a "second layer" in terms of scalability. (The main advantage of LN is not scalability at all, but instant trustless payments, which can occur without a mining process or the rest of the Bitcoin network.)↩

This seems to be a credible figure. In 2016, there were 7.42 billion people, with only about 65% being adults. ~2 billion still live in extreme poverty, many without bank accounts in developing countries.↩

This is not to say that the entire network can now rely solely on SPV nodes (this is a mistake often articulated by LargeBlockers, especially BSV-ers). The data availability problem cannot be bypassed: someone has to "host" the blockchain's data… we can't all get it from someone else! (This is also why SNARKs as a scaling solution are inferior—they are essentially just opaque fraud proofs.)

免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。