This website uses cookies
We use cookies to personalise content and ads, to provide social media features and to analyse our traffic. We also share information about your use of our site with our social media, advertising and analytics partners who may combine it with other information that you’ve provided to them or that they’ve collected from your use of their services.
Consent Selection
Details
  • Necessary cookies help make a website usable by enabling basic functions like page navigation and access to secure areas of the website. The website cannot function properly without these cookies.

    • Learn more about this provideropens in a new window
      CookieConsentStores the user's cookie consent state for the current domain
      Maximum Storage Duration: 1 yearType: HTTP Cookie
    • Learn more about this provideropens in a new window
      bcookieUsed in order to detect spam and improve the website's security.
      Maximum Storage Duration: 1 yearType: HTTP Cookie
      li_gcStores the user's cookie consent state for the current domain
      Maximum Storage Duration: 180 daysType: HTTP Cookie
    • Learn more about this provideropens in a new window
      datadomeUsed in context with the website's BotManager. The BotManager detects, categorizes and compiles reports on potential bots trying to access the website.
      Maximum Storage Duration: 1 yearType: HTTP Cookie
    • _pk_testcookie_domainThis cookie determines whether the browser accepts cookies.
      Maximum Storage Duration: 1 dayType: HTTP Cookie
    • __cf_bm [x3]This cookie is used to distinguish between humans and bots. This is beneficial for the website, in order to make valid reports on the use of their website.
      Maximum Storage Duration: 1 dayType: HTTP Cookie
  • Preference cookies enable a website to remember information that changes the way the website behaves or looks, like your preferred language or the region that you are in.
    • Learn more about this provideropens in a new window
      lidcRegisters which server-cluster is serving the visitor. This is used in context with load balancing, in order to optimize user experience.
      Maximum Storage Duration: 1 dayType: HTTP Cookie
  • Statistic cookies help website owners to understand how visitors interact with websites by collecting and reporting information anonymously.
    • Learn more about this provideropens in a new window
      guestRegisters data on visitors' website-behaviour. This is used for internal analysis and website optimization.
      Maximum Storage Duration: 1 monthType: HTTP Cookie
    • Learn more about this provideropens in a new window
      personalization_idThis cookie is set by Twitter - The cookie allows the visitor to share content from the website onto their Twitter profile.
      Maximum Storage Duration: 400 daysType: HTTP Cookie
    • _pk_uidUsed by Piwik Analytics Platform to identify the visitor on repeat visits to the website.
      Maximum Storage Duration: 1 yearType: HTTP Cookie
      _pk_id#Collects statistics on the user's visits to the website, such as the number of visits, average time spent on the website and what pages have been read.
      Maximum Storage Duration: 1 yearType: HTTP Cookie
      _pk_ses#Used by Piwik Analytics Platform to track page requests from the visitor during the session.
      Maximum Storage Duration: 1 dayType: HTTP Cookie
    • FPGSIDRegisters statistical data on users' behaviour on the website. Used for internal analytics by the website operator.
      Maximum Storage Duration: 1 dayType: HTTP Cookie
      FPIDRegisters statistical data on users' behaviour on the website. Used for internal analytics by the website operator.
      Maximum Storage Duration: 400 daysType: HTTP Cookie
      FPLCRegisters a unique ID that is used to generate statistical data on how the visitor uses the website.
      Maximum Storage Duration: 1 dayType: HTTP Cookie
    • _gaRegisters a unique ID that is used to generate statistical data on how the visitor uses the website.
      Maximum Storage Duration: 2 yearsType: HTTP Cookie
      _ga_#Used by Google Analytics to collect data on the number of times a user has visited the website as well as dates for the first and most recent visit.
      Maximum Storage Duration: 2 yearsType: HTTP Cookie
  • Marketing cookies are used to track visitors across websites. The intention is to display ads that are relevant and engaging for the individual user and thereby more valuable for publishers and third party advertisers.
    • Learn more about this provideropens in a new window

      Some of the data collected by this provider is for the purposes of personalization and measuring advertising effectiveness. The provider may use the IP Addresses for ads measurement and ads personalization.

      ads/ga-audiencesUsed by Google AdWords to re-engage visitors that are likely to convert to customers based on the visitor's online behaviour across websites.
      Maximum Storage Duration: SessionType: Pixel Tracker
    • Learn more about this provideropens in a new window
      userRefererDetermines how the user accessed the website. This information is used by the website operator in order to measure the efficiency of their marketing.
      Maximum Storage Duration: 1 monthType: HTTP Cookie
    • Learn more about this provideropens in a new window
      #:session-dataTracks the individual sessions on the website, allowing the website to compile statistical data from multiple visits. This data can also be used to create leads for marketing purposes.
      Maximum Storage Duration: PersistentType: HTML Local Storage
      eng_mtTracks the conversion rate between the user and the advertisement banners on the website - This serves to optimise the relevance of the advertisements on the website.
      Maximum Storage Duration: PersistentType: HTML Local Storage
      t_gidThis cookie assigns a specific visitor ID, when the visitor interacts with ads or content from the website - this allows the website to target the visitor with similar ads or content.
      Maximum Storage Duration: 1 yearType: HTTP Cookie
      t_pt_gidCollects information on user preferences and/or interaction with web-campaign content - This is used on CRM-campaign-platform used by website owners for promoting events or products.
      Maximum Storage Duration: 1 yearType: HTTP Cookie
      taboola global:user-idSets a unique ID for the visitor, that allows third party advertisers to target the visitor with relevant advertisement. This pairing service is provided by third party advertisement hubs, which facilitates real-time bidding for advertisers.
      Maximum Storage Duration: PersistentType: HTML Local Storage
      taboola_session_idThis cookie is used to collect information on a visitor. This information will become an ID string with information on a specific visitor – ID information strings can be used to target groups with similar preferences, or can be used by third-party domains or ad-exchanges.
      Maximum Storage Duration: SessionType: HTTP Cookie
    • Learn more about this provideropens in a new window
      1/i/adsct [x2]Collects data on user behaviour and interaction in order to optimize the website and make advertisement on the website more relevant.
      Maximum Storage Duration: SessionType: Pixel Tracker
      muc_adsCollects data on user behaviour and interaction in order to optimize the website and make advertisement on the website more relevant.
      Maximum Storage Duration: 400 daysType: HTTP Cookie
      guest_idCollects data related to the user's visits to the website, such as the number of visits, average time spent on the website and which pages have been loaded, with the purpose of personalising and improving the Twitter service.
      Maximum Storage Duration: 400 daysType: HTTP Cookie
      guest_id_adsCollects information on user behaviour on multiple websites. This information is used in order to optimize the relevance of advertisement on the website.
      Maximum Storage Duration: 400 daysType: HTTP Cookie
      guest_id_marketingCollects information on user behaviour on multiple websites. This information is used in order to optimize the relevance of advertisement on the website.
      Maximum Storage Duration: 400 daysType: HTTP Cookie
    • _gcl_auUsed by Google AdSense for experimenting with advertisement efficiency across websites using their services.
      Maximum Storage Duration: 3 monthsType: HTTP Cookie
      _gcl_lsTracks the conversion rate between the user and the advertisement banners on the website - This serves to optimise the relevance of the advertisements on the website.
      Maximum Storage Duration: PersistentType: HTML Local Storage
    • pardot [x2]Used in context with Account-Based-Marketing (ABM). The cookie registers data such as IP-addresses, time spent on the website and page requests for the visit. This is used for retargeting of multiple users rooting from the same IP-addresses. ABM usually facilitates B2B marketing purposes.
      Maximum Storage Duration: SessionType: HTTP Cookie
  • Unclassified cookies are cookies that we are in the process of classifying, together with the providers of individual cookies.
    • cs_analytics_ip_blockedPending
      Maximum Storage Duration: SessionType: HTTP Cookie
      user_tokenPending
      Maximum Storage Duration: 1 yearType: HTTP Cookie
    • _twpidPending
      Maximum Storage Duration: SessionType: HTTP Cookie
Cookie declaration last updated on 8/20/26 by Cookiebot
[#IABV2_TITLE#]
[#IABV2_BODY_INTRO#]
[#IABV2_BODY_LEGITIMATE_INTEREST_INTRO#]
[#IABV2_BODY_PREFERENCE_INTRO#]
[#IABV2_BODY_PURPOSES_INTRO#]
[#IABV2_BODY_PURPOSES#]
[#IABV2_BODY_FEATURES_INTRO#]
[#IABV2_BODY_FEATURES#]
[#IABV2_BODY_PARTNERS_INTRO#]
[#IABV2_BODY_PARTNERS#]
About
Cookies are small text files that can be used by websites to make a user's experience more efficient.

The law states that we can store cookies on your device if they are strictly necessary for the operation of this site. For all other types of cookies we need your permission.

This site uses different types of cookies. Some cookies are placed by third party services that appear on our pages.

You can at any time change or withdraw your consent from the Cookie Declaration on our website.

Learn more about who we are, how you can contact us and how we process personal data in our Privacy Policy.

Please state your consent ID and date when you contact us regarding your consent.

How Ethereum will Scale to One Million Transactions Per Second

Timer7 minuti di lettura

  • Finanza
  • Ethereum

Blockchains are powerful networks that provide users with a shared digital ledger. However, the architecture behind these ledgers leads to a trade-off between decentralisation, security and scalability. This issue, where a blockchain must choose two of these three guarantees, is known as the “blockchain trilemma”. Traditionally, most blockchains, like Bitcoin and Ethereum, have opted for decentralisation and security at the expense of scalability. In this report, we outline the steps Ethereum is taking to scale its blockchain without compromising on the other two attributes. We illustrate the blockchain trilemma trade-off below.

BlockchainSource: CoinShares

This trilemma has burdened the industry for years, with many alternative layer 1s opting to sacrifice decentralisation in favour of speed. While this trade-off has helped to make for a better user-experience, the outcome of centralised blockchains does not allow for the innovation, culture or benefits associated with a decentralised paradigm. There have been many attempts to solve this issue, including plasma and sidechains but these solutions also fell short of the design goals.

Ethereum’s modular approach

From a high-level perspective, blockchains perform three main tasks, execution, consensus and data availability. Execution is where all the transactions happen, consensus is where network participants agree on what has happened and data availability is guaranteeing that data is accessible to all. Since their inception, blockchains have been monolithic, that is, blockchains were expected to perform all three tasks under one chain. Over a decade later, there is now the rise of modular blockchain architectures. A modular blockchain utilises the concept of specialisation and chooses to separate these tasks into separate chains. When Ethereum upgrades to Proof of Stake (PoS), expected in September 2022, there will be different chains for each task. Consensus will be handled by the PoS Beacon Chain, data availability will be handled by the current Ethereum chain and execution will be handled by layer 2s. Layer 2’s are separate blockchains built on top of Ethereum (layer 1) that help to scale the layer 1 with faster throughput and lower fees all while preserving decentralisation and security.

Ethereum’s modular approachSource: CoinShares

Although there are already many layer 2s launched or in production, the scaling roadmap is far from complete. Ethereum currently handles around 10 TPS (transactions per second) so a 100,00x improvement is needed to achieve its scaling goals. For reference, a network like Visa can handle around 65,000 TPS2. In order to scale to 1 million TPS, Ethereum will need a further three implementations – improved rollups, sharding and increased bandwidth. We discuss these technologies in greater detail below.

Rollups – 100x increase in throughput

As mentioned above, Ethereum intends to scale its operation using rollups/layer 2s. Rollups/layer 2s are separate blockchains that absorb the burden of executing transactions so that Ethereum can focus on consensus and data availability. Many transactions are executed on layer 2 and then rolled up into a single transaction which is subsequently posted to the Ethereum blockchain for verification. Ninety-nine percent of the gas fees are related to execution, hence moving execution off-chain saves more than just time. Below we illustrate a simplified relationship between transactions of different rollups and an Ethereum block.

Ethereum Block NSource: CoinShares

Checking the validity of one bundled transaction can be an order of magnitude faster than executing each transaction individually. The bundling of many transactions into one, allows for more transactions per second (TPS), reduces network congestion and lowers gas fees for users. Moving the computation off-chain to a layer 2 provides greater scalability and allows for more optimisations around throughput and latency. Off-chain execution could scale the Ethereum network by a factor of 10x.

Furthermore, once roll-ups become decentralised, posting the transaction data back on-chain for verification, preserves the security and decentralisation benefits of the Ethereum network, hence resolving the issues around the blockchain trilemma. However, more optimisations are achievable with improved data compression techniques. Data compression involves reducing the number of details needed to represent the same underlying information. Posting compressed data to Ethereum further reduces the cost and could improve scalability by another 10x.

Data Sharding – 100x increase in throughput

As mentioned above, layer 2s will handle execution, while Ethereum will focus on consensus and data availability, which is a critical component to both security and scalability. Sharding is a network architecture designed to scale data availability. Currently, every consensus participant must download all of the data from a block and independently verify the data before signing off on a block. This is an inefficient process and a considerable bottleneck of the network. However, if this data is missing, the network will not be able to verify if blocks are valid. Hence data availability is the guarantee that the block proposer published all the necessary transaction data, and that the transaction data is available to other network participants. Sharding allows for network participants to only download a sample of all the data while simultaneously guaranteeing data availability. Given the complexity of this design, sharding will be completed in two phases, proto-danksharding and the full danksharding.

Proto-danksharding (also known as EIP-4844) is a proposal to implement most of the logic but not everything that makes up a complete danksharding specification. With proto-danksharding, each network participant must still independently verify that the whole set of data is still available. The primary innovation that proto-danksharding introduces is a new transaction type, referred to as a blob-carrying transaction. Blobs can be significantly cheaper for layer 2s to post to than the current transaction type and could improve scalability by a factor of 10x. Full danksharding introduces data availability sampling such that network participants only need a small fraction of the data to verify a block. The implementation of full danksharding could improve scalability by another 10x. Below we illustrate the relation between blobs and the Beacon chain.

Data ShardingSource: CoinShares

Bandwidth – 10x increase in throughput

There are various computational resources that a blockchain requires, namely, CPU cycles, storage, disk I/O and bandwidth. Ethereum intends to move to a stateless architecture, which does not need the first three resources but still requires bandwidth. This last component is different from the other two in the sense that it relies on the progress of external technological progress to help scale the network. This is because consumer bandwidth tends to increase by roughly 50% every year (similar to Moore’s law). Given this exponential growth, it would take approximately five to six years to realise a 10x increase in bandwidth (and another 5 years for a 100x improvement). There is good reason to believe that bandwidth will continue to improve at this current pace since bandwidth is an inherently parallelisable process. Below we show the growth of bandwidth from 1983 to 2019.

Megabits per secondSource: CoinShares

Conclusion

Given the importance of scalability needed for the mass adoption of Ethereum, these technologies will become the main priorities once the Merge has successfully materialised (expected September 2022). However, given that this technology is only several years away, and given the average yearly growth of bandwidth, we find it reasonable to expect 1 million TPS in the next six years.

References

(1) https://www.nngroup.com/articles/law-of-bandwidth/

(2) https://www.visa.co.uk/dam/VCOM/download/corporate/media/visanet-technology/aboutvisafactsheet.pdf

Pubblicato ilAgo 9th, 2022

Scrittore
CoinShares Author Logo
Marc Arjoon

Benvenuto to CoinShares

Dati personali

0102

Quando visiti il sito web di CoinShares, i cookie migliorano la tua esperienza. Ci aiutano a mostrarti contenuti più pertinenti. Alcuni cookie sono necessari per il funzionamento del sito e saranno sempre attivi. Bloccare alcuni tipi di cookie potrebbe influire sulla tua esperienza del sito web e sui servizi che offriamo sul nostro sito.

Utilizziamo i cookie sul nostro sito per ottimizzare i nostri servizi. Scopri di più sulla nostra politica sui cookie per l’UE o sulla nostra politica sui cookie per gli Stati Uniti.

  • Necessari
    Question circle icon
  • Preferences
    Question circle icon
  • Statistici
    Question circle icon
  • Marketing
    Question circle icon
I cookie necessari aiutano a rendere un sito web utilizzabile abilitando funzioni di base come la navigazione tra le pagine e l'accesso alle aree protette del sito. Il sito web non può funzionare correttamente senza questi cookie.
I cookie di preferenza permettono a un sito web di ricordare informazioni che modificano il modo in cui il sito si comporta o appare, come la lingua preferita o la regione in cui ti trovi.
I cookie statistici aiutano i proprietari del sito web a capire come i visitatori interagiscono con i siti raccogliendo e riportando informazioni in modo anonimo.
I cookie di marketing vengono utilizzati per tracciare i visitatori attraverso i siti web. L'intento è di mostrare annunci pertinenti e coinvolgenti per l'utente individuale, rendendoli così più preziosi per gli editori e gli inserzionisti di terze parti.