Ethereum vs Ether

Ethereum vs. Ether: Picture Ethereum as a bustling digital city, and ether (ETH) as the currency people use within that city. While the city’s infrastructure might be booming, it doesn’t always mean the currency’s value is skyrocketing. Similarly, a digital network and its native token don’t always rise and fall together.

The relationship between a digital asset network and its native token is intricate, and their successes don’t always mirror each other. Some networks can offer significant utility, processing numerous intricate transactions daily, without necessarily enhancing the value for their token holders.

Conversely, some networks exhibit a more direct connection between the network’s activity and the value of its token. This dynamic is often referred to as “tokenomics,” a contraction of “token economics.” Tokenomics delves into how a network or application’s structure can generate economic benefits for its token holders.

Over recent years, the Ethereum network has experienced transformative changes that have reshaped its tokenomics. One notable change was the decision to burn a segment of transaction fees, termed the base fee, introduced in August 2021 through the Ethereum Improvement Proposal 1559 (EIP-1559).

Recommended: MEV Burn Ethereum: Greatest Supply Shock in ETH History?

When ether is burned, it’s essentially removed from existence, meaning every transaction on Ethereum reduces the total ether in circulation. Moreover, the shift from proof-of-work to proof-of-stake in September 2022 reduced the rate at which new tokens are introduced and introduced staking.

This staking process permits participants to earn returns in the form of tips, new token issuance, and maximal extractable value (MEV). These pivotal updates have redefined ether’s tokenomics, prompting a reevaluation of the bond between Ethereum and its native token, ether.

Understanding Tokenomics: The Value Dynamics of Ether

Ether’s value is intrinsically tied to its tokenomics, which can be broken down into three primary mechanisms that convert usage into value. Here’s how it works:

1. Transaction Fees: When users transact on Ethereum, they incur two types of fees: a base fee and a priority fee (also known as a tip). Additionally, transactions can create value opportunities for others through MEV (Maximum Extractable Value). This represents the maximum value a validator can gain by manipulating the sequence or selection of transactions during block creation.
2. Base Fee Dynamics: The base fee, which is paid in ether, is “burned” or permanently removed from circulation once it’s included in a block (a collection of transactions). This act of burning reduces the overall ether supply, creating a deflationary effect.
3. Priority Fee and MEV: The priority fee, or tip, is a reward given to validators, the entities or individuals tasked with updating the blockchain and ensuring its integrity. When validators create blocks, they’re motivated to prioritize transactions offering higher tips since this becomes a primary source of their earnings. Additionally, MEV opportunities, often arising from arbitrage, are typically introduced by users. In the current ecosystem, the majority of this MEV value is channeled to validators through competitive MEV markets.

These value-generating mechanisms can be likened to various revenue streams for the network. The burning of the base fee acts as a deflationary force, benefiting existing token holders by potentially increasing the value of their holdings.

On the other hand, the priority fee and MEV serve as compensation for validators, rewarding them for their crucial role in the network. In essence, as platform activity rises, so does the amount of ether burned and the rewards for validators, illustrating the dynamic relationship between usage and value in Ether’s tokenomics.

Investment Perspective: Ether’s Monetary Potential

Bitcoin is often framed as an emerging form of digital money. This naturally prompts the question: Can ether be seen in the same light?

While some might argue in favor, ether faces more challenges than bitcoin in its journey to be universally recognized as money.

Although ether shares many monetary characteristics with bitcoin and traditional currencies, its scarcity model and historical trajectory differ. Unlike bitcoin’s fixed supply, ether’s supply is dynamic, influenced by factors like validator count and the amount burned.

Additionally, Ethereum’s frequent network upgrades mean its code is constantly evolving, requiring time and scrutiny to establish a robust track record. This continuous evolution, while beneficial for innovation, can be a hurdle in building unwavering trust among stakeholders.

Also, many would argue that Ether is more security-like than Bitcoin in that it is more controlled by a few highly interested parties than Bitcoin. The Ethereum foundation (EF) is controlled by a handful of people. If the EF proposes protocol upgrades, even hard forks, these upgrades have a high chance of going through. The decentralization in terms of number of nodes and distribution of nodes globally is much less than Bitcoin.

Bitcoin, for many, represents the pinnacle of digital money due to its security, decentralization, and sound monetary principles. Any attempt to “better” it would involve compromises. However, the dominance of bitcoin as a digital monetary standard doesn’t preclude the existence of other forms of digital money tailored for specific markets, use cases, or communities.

Ethereum, for instance, offers functionalities not present in Bitcoin (at least on the base layer, although many functionalities, such as smart contracts and executing complex transactions, are already being implemented on Bitcoin layer 2s).

Mainstream applications built on Ethereum could naturally boost demand for ether, positioning it as a potential alternative form of money. Several real-world integrations with Ethereum are already evident:

• MakerDAO, an Ethereum-based project, invested in $500 million worth of Treasuries and bonds.
• A U.S. house was sold on Ethereum as a non-fungible token (NFT).
• The European Investment Bank issued bonds directly on the blockchain.
• Franklin Templeton’s money market fund leveraged Ethereum via Polygon for transaction processing and share ownership recording.

While these integrations are promising, widespread adoption of Ethereum for mainstream transactions might still be years away, requiring enhancements, regulatory clarity, and public education. Until then, ether might remain a specialized form of money.

In a way, Ethereum currently doesn’t have use cases beyond trading digital assets as can be seen in the current “Burn Leaderboard” on Ultrasound Money:

I’m not a huge proponent of “trading applications” because I believe it goes more in the direction of a zero-sum game. Where’s the value of swapping tokens on Uniswap or NFTs on OpenSea? Yet, I understand you could use similar arguments for much of the “real world” industry with banks, online marketplaces, and financial services providers.

Regulation is a significant concern for Ethereum’s future. Given that many major centralized exchanges holding and staking ether are U.S.-based, regulatory decisions in this jurisdiction could profoundly impact Ethereum’s valuation and overall health. Recent regulatory actions and shutdowns of crypto services in the U.S. underscore the gravity of this risk.

Ether’s Dual Monetary Roles: Store of Value and Medium of Exchange

Store of Value: A reliable store of value demands scarcity. While Bitcoin’s fixed supply of 21 million is well-established, ether’s issuance is more fluid, influenced by factors like validator activity and burn rates.

Future Ethereum upgrades could further complicate predictions about ether’s supply. Despite these complexities, current structures ensure ether’s annual inflation remains below 1.5%, assuming no transactions occur. With transaction revenue, Ethereum can even remain deflationary, meaning more ETH is burned than paid out to stakers each year.

However, the potential for future changes to ether’s supply dynamics contrasts sharply with Bitcoin’s steadfast supply narrative.

Means of Payment: Ether is already used for payments, especially for digital assets. Seemingly, Ethereum’s faster transaction finality compared to Bitcoin makes it an appealing payment option.

In reality, however, all payments will be made on second and third layers, such as Bitcoin lightning or Ethereum Polygon, which reduces practical transaction costs for even small payments to almost zero.

As more physical and digital assets integrate with blockchain ecosystems, ether, along with other tokens and stablecoins, could become more prevalent for payments, especially if transaction fees decrease due to the increasing infrastructure of the network application ecosystems.

Valuing Ether Based on Demand

Ether’s value could rise with increased Ethereum network adoption due to basic supply-demand principles. As Ethereum scales, understanding where new users originate and their sought-after use cases can provide insights into potential value trajectories.

Current data suggests that Ethereum’s base layer continues to attract consistent value, even as layer 2 solutions gain traction. However, ether’s value might be more influenced by network usage than mere asset holding.

In a recent article, I analyzed Bitcoin’s price based on Metcalfe’s Law and network effects and found there’s a positive relationship:

Recommended: Want Exploding Bitcoin Prices North of $500,000 per BTC? “Grow N” Says Metcalfe’s Law

A similar study has been done by Fidelity that found more evidence of Bitcoin’s price scaling exponentially with the number of addresses than Ethereum’s price. But the relationship is still there for both monetary networks (source):

The post Ethereum Investment Thesis appeared first on Be on the Right Side of Change.

Polygon, formerly known as Matic Network, is an interoperability and scaling framework designed for building Ethereum-compatible blockchains. Its native token, MATIC, serves multiple purposes, including governance, staking, and gas fees.

On the other hand, Ethereum is a well-known decentralized platform that enables the creation and execution of smart contracts and decentralized applications (dApps) using its native cryptocurrency, Ether (ETH).

Disclaimer: This is not financial advice. The author of this post holds both tokens. No guarantee of correctness – this is a complicated space and errors can be made easily. Also projects change over time.

When examining the connection between MATIC and ETH, it’s important to recognize that rather than competing, Polygon is designed to complement and enhance the Ethereum network.

By offering solutions for scalability and reducing transaction costs, Polygon emerges as a valuable ally for Ethereum in its journey to improve the overall crypto ecosystem.

Understanding Matic and Ethereum

Let’s dive into the connection between Matic (also known as Polygon) and Ethereum.

Matic, or Polygon, is an interoperability and scaling framework designed for building Ethereum-compatible blockchains.

While Ethereum is a well-known and widely-used platform for decentralized applications (dApps), it faces problems related to scalability and transaction fees. Polygon aims to resolve these issues by operating as a side-chain, or secondary layer, to the Ethereum main chain.

As a developer, you’ll find it beneficial to work with Polygon since it’s compatible with Ethereum-based dApps and smart contracts. This compatibility means that you can easily integrate your work on Ethereum with the Polygon network. By doing so, you can take advantage of improved transaction speeds and lower fees without having to leave the Ethereum ecosystem.

The MATIC token plays a crucial role in the Polygon network. Originally an ERC-20 token on the Ethereum blockchain, MATIC serves as the native cryptocurrency of the Polygon network. It is used for governance, staking, and paying transaction fees within the platform. This dual existence of MATIC on both Ethereum and Polygon allows for seamless interaction between the two networks.

An essential component of the Polygon framework is its consensus protocol, which relies on Proof of Stake (PoS). In PoS systems, network participants called validators are randomly assigned to produce new blocks. These validators secure the network by staking their tokens, boosting the network’s security and performance. As a user in the Polygon ecosystem, you can also participate in the staking process to earn rewards and contribute to the platform’s stability.

Recommended: Polygon for Developers – A Simple Guide with Video

The Necessity of Matic

As you explore the crypto landscape, you might wonder why Matic token, now known as Polygon, emerged as an essential aspect of Ethereum’s ecosystem. To understand this, let’s dive into some of the limitations of the Ethereum network that led to the development of Matic.

Ethereum’s underlying technology has faced challenges in the form of high gas fees and network congestion. As more users and developers adopt the Ethereum platform, these issues have become more prominent. High gas fees make using Ethereum-based applications expensive, discouraging new users from joining the network. Moreover, network congestion slows down transaction processing times, leading to a less efficient user experience.

Recommended: Introduction to Ethereum’s Gas in Solidity Development

To address these limitations, Ethereum developers have been working on multiple upgrades focused on improving the network’s scalability, security, and energy efficiency. However, the transition is a gradual process, and during this time, solutions are needed to alleviate network constraints.

This is where Matic, now known as Polygon, comes into play. Polygon is an Ethereum-compatible Layer 2 scaling solution that enables fast, inexpensive, and secure off-chain transactions. By handling transactions off the main Ethereum chain, Polygon takes a significant load off the congested Ethereum network, thus mitigating the issues of high gas fees and network congestion.

Functionality of Matic

Matic, now known as Polygon, offers a layer-2 scaling solution for Ethereum, providing significant improvements in transaction speed and cost. As you explore the functionality of Matic, you’ll notice its role in enhancing Ethereum’s ecosystem, particularly in the DeFi space.

When it comes to assets, the Matic ecosystem supports various tokens and digital assets, as well as enables the creation of decentralized applications (dApps). With Matic, your transactions on the Ethereum-compatible sidechain experience faster execution and lower gas fees. These reduced transaction fees are possible due to Matic’s Plasma framework, a plasma chain designed for enhanced scalability and security.

The native token of this ecosystem is the MATIC token, which has multiple functions. For instance, MATIC is used for staking, allowing you to secure the network and earn rewards from the validation process. Furthermore, the token is employed for governance, enabling you to participate in protocol upgrades and other decisions that affect the ecosystem.

To interact with Matic and its supported dApps, you can use popular wallets such as MetaMask. Integration with these wallets provides a seamless and familiar experience for Ethereum users. Additionally, Matic is compatible with various DeFi platforms, like Aave, which can be easily accessed through the sidechain.

Important to note are the validators in the Matic network. Validators work by confirming transactions and adding them to the sidechain, ensuring smooth and efficient operations. Stakers, or token holders, can delegate their MATIC tokens to these validators, maintaining the network’s security while earning rewards from successful transaction confirmations.

How Matic Works

Matic, or now known as Polygon, is an Ethereum layer-2 scaling solution that provides a faster and more efficient network for Ethereum-based transactions. In this section, we will explain how Matic works, what it offers to users, and its benefits for the Ethereum ecosystem.

When using Ethereum, you may have encountered issues like high gas fees and slow transaction times, which can be off-putting for users and developers alike. Matic aims to address these problems by using a proof-of-stake consensus mechanism on its sidechain, which runs parallel to the Ethereum mainnet. By doing this, it can process transactions more quickly, with lower gas fees, and increased transaction finality.

To begin using Matic, you must first set up your MetaMask wallet to interact with the Matic sidechain. This process involves configuring the custom RPC settings in MetaMask, which allows you to connect to the Matic network seamlessly. Once your wallet is set up and connected, you can easily switch between Ethereum mainnet and Matic sidechain as needed.

Recommended: Can I Send MATIC Token to ETH Address? – A Crucial Guide for Crypto Users

The Matic network uses its native token, MATIC, which is also an ERC-20 token. This token is utilized for paying gas fees on the network, securing the network through staking, and participating in governance decisions. The proof-of-stake consensus mechanism keeps Matic secure and efficient, allowing it to support a higher transaction throughput compared to the Ethereum mainnet.

There are several scaling techniques that Matic uses to achieve its goals, including zk-rollups and plasma chains. Without delving too deep into the technical aspects, these methods help to bundle multiple transactions together into one single transaction, making them faster and more efficient, ultimately resulting in lower gas fees.

As Ethereum evolves with the introduction of Proof-of-Stake and Ethereum 2.0, Matic is expected to play a significant role in helping the network scale and overcome its challenges. By providing faster transaction speeds, reduced gas fees, and an overall improved user experience, Matic has made it possible for developers and users to interact with the Ethereum ecosystem more seamlessly, leading to increased adoption and growth.

It’s important to note that Matic does not compete with Ethereum, but rather, it acts as a complementary tool that helps the Ethereum network work more effectively and efficiently. With this mutual support, both Matic and Ethereum can continue to thrive and maintain their strong positions within the blockchain space.

Recommended: The State of Crypto in 2023

Architectural Design of Matic

Matic’s design consists of several key elements, including the Ethereum main chain, validators as a service, a security layer, and an execution layer. As you explore Matic’s architecture, you’ll notice that it was built to enhance Ethereum’s ecosystem while maintaining compatibility.

The Ethereum main chain plays a crucial role in Matic’s architecture. Matic acts as a layer-2 network, which means it is designed as an add-on layer to Ethereum without altering the original blockchain layer. It provides Ethereum with increased scalability, with technologies like zero-knowledge proofs, optimistic rollups, and fraud proofs.

Validators as a service are an essential aspect of Matic’s security layer. This service allows for a decentralized network of validators who stake Matic’s native token, MATIC, to participate in the proof-of-stake (PoS) consensus mechanism. This system ensures that the network remains secure and trustworthy while also providing users with an energy-efficient validation process.

Matic’s security layer is further reinforced through the integration of additional technologies such as zero-knowledge proofs, which help add an extra layer of privacy to transactions. Furthermore, optimistic rollups and fraud proofs work to enhance transaction processing and ensure data integrity.

The execution layer in Matic’s architecture is responsible for processing transactions and smart contracts. Built upon Ethereum’s virtual machine, it ensures that smart contracts are forward-compatible and can efficiently run on both Ethereum and Polygon networks. This compatibility is beneficial for developers looking to build decentralized applications (dApps) that can operate seamlessly across both ecosystems.

In summary, Matic’s architectural design focuses on enhancing Ethereum’s functionality while maintaining compatibility. By integrating components like the Ethereum main chain, validators as a service, a security layer, and an execution layer, Matic provides a robust and scalable layer-2 solution for Ethereum users and developers.

User Experience and Applications on Matic

In the realm of blockchain technology, the Polygon Network takes center stage as an interoperability and scaling framework for building Ethereum-compatible blockchains. Developed by Mihailo Bjelic, this solution addresses the challenges of slow transaction speeds and high gas fees typically associated with the Ethereum network.

As a user, you’ll find that the user experience on Polygon (formerly known as Matic Network) is seamless and hassle-free. With its sophisticated functionalities, Polygon enables you to interact with web3.0 applications effortlessly. The platform’s interoperable blockchains ensure compatibility with Ethereum-based decentralized apps (dApps) while significantly reducing transaction costs and improving the overall speed.

Security is a top priority on the Polygon Network. Fast, inexpensive, and secure off-chain transactions for payments and general interactions with off-chain smart contracts are made possible by its Layer 2 scaling solution. Even when you’re dealing with complex apps and high-value data, your transactions remain safe and secure.

To access the benefits of Polygon, you can download the network’s compatible wallets or simply use popular options like Coinbase, which allows you to store, trade, and manage the native MATIC token. As a participant in the ecosystem, you can leverage the MATIC token for governance, staking, and paying gas fees.

Frequently Asked Questions

How does Polygon complement Ethereum?

Polygon is an interoperability and scaling framework that helps expand the capabilities of Ethereum by building Ethereum-compatible blockchains. It enhances the Ethereum ecosystem by providing a faster, more scalable, and cost-effective solution for developers. By acting as a “Layer 2” solution, it improves the transaction throughput and reduces gas fees, all while maintaining compatibility with Ethereum’s infrastructure, thus complementing the Ethereum network.

What is the role of MATIC in the Polygon ecosystem?

MATIC is the native token of the Polygon network, serving various purposes within the ecosystem. It is used for governance, allowing token holders to participate in decision making and protocol upgrades. Additionally, MATIC is employed for staking to secure the network and validate transactions. Lastly, the token is utilized to pay gas fees, providing an incentive for validators to process transactions and maintain the network’s smooth operation.

How do Ethereum transaction fees compare to those on Polygon?

Ethereum transaction fees, or gas fees, are typically higher than those on Polygon. Due to Ethereum’s popularity and limited scalability, transaction fees can become expensive, especially during peak congestion periods. Polygon, as a Layer 2 solution, enables more transactions per second and, consequently, lowers the gas fees. Therefore, using Polygon can be significantly more cost-effective for developers and users compared to relying solely on Ethereum.

What are the advantages of building on Polygon over Ethereum?

Some of the main advantages of building on Polygon instead of directly on Ethereum include lower transaction costs, faster confirmation times, and increased scalability. Additionally, Polygon supports multiple consensus algorithms and provides developer-friendly SDKs and APIs. By being Ethereum-compatible, projects built on Polygon can easily integrate with the existing Ethereum infrastructure, tools, and applications, benefiting from the robustness and security of Ethereum while enjoying Polygon’s performance enhancements.

Can assets be transferred between Ethereum and Polygon networks?

Yes, assets can be transferred between Ethereum and Polygon networks through bridge technologies. These bridges facilitate seamless movement of assets, such as tokens and NFTs, between the two networks. For instance, the Polygon PoS Bridge allows swapping of assets between the Ethereum mainnet and the Polygon sidechain. By using bridges, users can enjoy the benefits of both networks, combining Ethereum’s security with Polygon’s speed and lower transaction costs.

How do Ethereum smart contracts interact with Polygon?

Ethereum smart contracts can interact with Polygon in multiple ways. One approach is by deploying Ethereum-compatible smart contracts directly on the Polygon network. This enables developers to leverage Polygon’s high-speed, low-cost environment while maintaining compatibility with Ethereum’s tools and infrastructure. Additionally, smart contracts on Ethereum can interact with Polygon through bridges or other cross-chain solutions, enabling seamless communication and asset transfer between the two networks.

The post What’s the Relation between Polygon and ETH appeared first on Be on the Right Side of Change.

A Few Words on Worldcoin

Worldcoin is a centralized startup launched by the founder of OpenAI Sam Altman. It is centralized because its major assets — such as the app, the WLD tokens, and the Orb device — are controlled by a small team of early investors and developers.

The Worldcoin marketing strategy is to distribute free tokens to every user who went through Worldcoin’s “Proof of Personhood” identity mechanism by means of scanning their biometric details (e.g., eyes) using the Orb device.

To prevent privacy leaks, Worldcoin uses “zero-knowledge proofs” so that your personal identity data is never sent to a central server once verified. Instead, the ZK-Proof represents a digital fingerprint of the data that isn’t supposed to leak personal information.

So the idea is that you can verify your humanity without revealing any personal information such as your biometric data.

In case you’re interested, we’ve published an in-depth article on ZK technology on the Finxter blog that’s relevant to this topic as well:

Recommended: What is a zkEVM Rollup? A Simplified Guide to Ethereum’s Most Promising Scaling Solution

Worldcoin Token Distribution

The plan of the Worldcoin Foundation is to distribute 10B (billion) WLD tokens within the first 15 years. After that, they plan for an annual inflation rate of 1.5%.

The Worldcoin foundation controls all 10B tokens, however, to spur initial growth, they plan to distribute 7.5B tokens to the Worldcoin Community, keeping 25% of all the tokens for the team and investors.

You can see their planned supply schedule in this graph:

You should be aware that the Worldcoin Foundation can change this token distribution at any time.

The Worldcoin Foundation has complete (centralized) control of all tokens and future token releases:

Interestingly, the Worldcoin Foundation raised its own token allocation from 20% to 25% due to unforeseen difficulties. As reason they state that development “[…] proved to be more complex and costly than […] initially anticipated”! This means they could (and already have in the past) increase their token allocation at any point in the future.

See the following screenshot from their whitepaper:

So now for the WLD token distribution.

The initial (one-time) token distribution of up to 10 billion WLD during the first 15 years will be distributed to new and existing Orb-verified individuals and Orb operators.

Universal Basic Income (UBI) using Worldcoin Token WLD?

Many view this as “UBI – Universal Basic Income” but due to the lack of long-term sustainability, Worldcoin uses the term “user grant”:

Now here comes the interesting part that answers the question of where the money for UBI actually comes from:

 Whitepaper: Long-term sustainability of user grants. To achieve the goal of providing WLD tokens to every living human being (subject to the “Availability” noted above), governance may also decide to phase out the recurring grants after a few years and only keep the Welcome grants, thereby reserving the remaining tokens for new users in the future. As explained above, 15 years after launch, governance may also decide on enacting an inflation rate of up to 1.5% per year, if this is deemed necessary to continue the user grants mechanism into the future.

While Worldcoin distributes initial user grants and may continue to do so using the annual inflation rate of 1.5% after 15 years, the Worldcoin Protocol itself does not have an explicit plan to generate profits and redistribute them via UBI.

Instead, it mentions that the UBI “requires a separate funding source,” such as “a share of the profits generated by an AI Lab”.

Neither the separate funding source nor the AI Lab is explicitly guaranteed in the whitepaper; Worldcoin strives only to provide “the globally-accessible digital financial rails” while solving the problem of a single human claiming multiple identities or an AI claiming one or multiple human identities.

However, if implemented, there is the possibility of setting an annual inflation rate of 1.5% and, thereby, essentially taxing existing WLD token holders to pay for the UBI. Ignoring all other protocol influences, such as internal growth or external fiat inflation rate, the existing token holders lose 1.5% of their value to fund the UBI.

TLDR: External funding mechanisms or donors, as well as existing token holders will pay the universal basic income (UBI) of Worldcoin.

Does This Work Long-Term?

Nobody knows. But let’s try to answer this question. I’m not very bullish on the long-term prospects of WLD compared to king crypto Bitcoin though.

A good way to analyze every crypto project is to examine the “steady-state” scenario where all tokens are distributed.

How does the project fund all operations without the initial token distribution rewards and overly-optimistic retail speculators pumping the price?

In this steady state scenario, either the UBI will be paid by (1) an external funding source (a possible “AI lab” is mentioned but could be any donor) or (2) by infinite inflation.

(1) Assuming the first case, i.e., there’s external capital available for the UBI. In that case there’s no need for the WLC token in the first place because we could also pay the token out using Bitcoin rails that are already proven and efficient using second-layer technologies without introducing an inflation rate.

From Silicon Valley founders, like Worldcoin’s Sam Altman, I have learned that to replace an existing technology with network effects, the new technology needs to be 10x better. But WLC as a stand-alone token is actually worse than BTC as a stand-alone token due to the inflation rate, so I don’t expect this to be the disruptive element of the Worldcoin Startup venture.

What may be innovative is the “proof of humanity” devices such as iris-scanning devices (The Orb). In order for the protocol to succeed and become a decentralized financial infrastructure (currently, it’s as centralized as it gets), the Orb technology needs to be open-sourced.

This is also the roadmap described in the whitepaper.

As soon as the proof of humanity technology is open-sourced, however, the moat around the protocol decreases, and existing decentralized payment protocols with massive network effects, i.e., Bitcoin, can also use the technology. We could easily imagine a layer two solution for UBI built on Bitcoin and paid for with explicit funding rather than inflation.

This leads us to case (2).

Of course, inflation is one option but it will cause the monetary unit of WLD to be inferior to BTC and capital naturally flowing from WLD grants (“UBI”) to Bitcoin as people sell WLD to buy Bitcoin.

But with billions of people dumping inflationary WLD to buy deflationary BTC, the protocol will quickly die out. The pump is over. The incentive to scan your iris and receive pennies is negligible.

This long-term risk scenario would likely kill the project.

I expect, however, that the hype for free money and the decade-long incentive scheme of Worldcoin will carry the protocol a couple of years into the future, paid for by stupid money, i.e., retail investors who purchase the WLD token for speculation.

While I like the general idea of using crypto for UBI, it seems that WLD is a high-quality and well-funded but completely centralized crypto project appealing to good-meaning retail investors with a carefully-crafted mid-term pump and dump scheme built into the protocol that ensures that early VCs can sell their premined tokens to retail before the incentive mechanism stops working, latest at the ~15y boundary.

This is only my humble opinion and I may be wrong. I think you’ll fair better with this project (no investment advice in this article though):

Recommended: Bitcoin Whitepaper Cheat Sheet (PDF Download)

The post Worldcoin – Who Pays for Universal Basic Income (UBI)? appeared first on Be on the Right Side of Change.

The following article is based on Adam’s CharmingData channel and GitHub repository.

In this tutorial, we will create, test, and deploy a smart contract called SimpleStorage. This contract will allow your users to create their own sentence and store it on the blockchain. It will also allow users to retrieve the last sentence stored and display it on the page.

Consider the following Solidity contract:

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.18;

contract SimpleStorage {
    // Define a string called storeTheSentence. This is a state variable, which will be permanently stored in the blockchain.
    string storeTheSentence;

    constructor(string memory initialSentence) {
        // Assign the value of initialSentence to the storeTheSentence variable
        storeTheSentence = initialSentence;
    }

    // Declares a function called getSentence
    // Solidity funcions visibility: public, private, internal and external
    // Solidity view functions: https://www.geeksforgeeks.org/solidity-view-and-pure-functions/
    function getSentence() public view returns (string memory) {
        return storeTheSentence;
    }

    // Declare a function called setSentence
    // The function takes 1 input parameter, a string named newSentence, with the calldata data location in the Ethereum Virtual Machine
    function setSentence(string calldata newSentence) external {
        // Assign the value of newSentence to the storeTheSentence variable
        storeTheSentence = newSentence;
    }
}

This is a simple smart contract written in Solidity, the most popular programming language for implementing smart contracts on the Ethereum blockchain. The contract’s name is SimpleStorage, and it primarily focuses on storing and retrieving a string (a sequence of characters).

Here’s a brief breakdown of the contract:

1. State variable (storeTheSentence): This is a string variable that will store a sentence. This variable’s value is stored on the blockchain, making it a permanent, unerasable record.
2. Constructor function: When the contract is first deployed to the Ethereum blockchain, the constructor function is executed once. This function accepts one argument, a string (initialSentence), and assigns its value to the state variable storeTheSentence.
3. getSentence() function: This function is a public view function, which means anyone can call it to read the value of storeTheSentence without changing any data or state in the contract. It does not cost any gas to call this function because it doesn’t change the state of the blockchain.
4. setSentence() function: This function is declared as external, meaning it can only be called from outside the contract. It accepts one string argument (newSentence) and assigns its value to storeTheSentence, effectively updating the stored sentence. As this function modifies the state of the contract, it requires a transaction to be sent and will cost gas to execute.

In essence, this contract allows anyone to store a sentence on the Ethereum blockchain and retrieve it. Due to the permanent and public nature of blockchain storage, the stored sentence would be visible to anyone and cannot be erased or modified once set (except by calling the setSentence function again).

Let’s learn how to set it up in a step-by-step manner next.

Backend

1. Open the terminal (command line), create two new folders called simple-storage and backend. Go into the backend folder.

mkdir simple-storage
cd simple-storage
mkdir backend
cd backend

2. Set up a Hardhat project. Install the necessary libraries, by typing in the terminal:

npm init --yes
npm install --save-dev --save-exact hardhat@2.14.0
npm install dotenv

3. This library might be necessary to install as well, especially if you’re a Windows user:

npm install --save-dev @nomicfoundation/hardhat-toolbox@2

4. Make sure you are still in the backend directory. Now, create a sample contract project by typing in the terminal:

npx hardhat

• Select Create a Javascript Project. Don’t change anything in the Hardhat project root, just click enter. Yes, add a .gitignore.

5. Open the backend folder and remove any present contracts inside the contracts folder. Insert your SimpleStorage contract.
6. Now, inside the scripts folder, replace the contect of the deploy.js file with the deploy.js code from this project.
7. Create a .env file inside the backend folder. This will be used to store your wallet key and your Quicknode endpoint. A QuickNode API endpoint gives you quick access to a network of nodes.

• Add these two lines inside the .env file, and update the content inside the quotation marks:

QUICKNODE_HTTP_URL="your-quicknode-http-provider-goes-here-inside-the-quotation-marks"
PRIVATE_KEY="your-wallet-private-key-goes-here-inside-the-quotation-marks"

8. Open the hardhat.config.js file inside the backend folder and replace its content with the hardhat.config.js code from this project.
9. Compile your Contract by going back to your terminal (ensure you are in the backend directory). And type:

npx hardhat compile

• Every time you modify your contract (SimpleStorage), you will have to repeat the above compile step.

10. With your contract compiled, now we can deploy it to the sepolia testnet. In your terminal type:

npx hardhat run scripts/deploy.js --network sepolia

Save the contract address that was printed out. Go to https://sepolia.etherscan.io/ and insert the contract address into the Explorer input field. Take some time to explore the transaction details of your contract.

• Save this address somewhere. Don’t lose it!

Testing

Every Contract should be tested before deployment. In this case we deployed first becuause it’s freaking exciting to see our contract deployed. But we need tests to make sure our contract has no bugs and is secure.

1. Open the test folder and remove any present files inside of it. Create a new file called testing.js, and insert the testing.js code from this project.
2. Go back to the terminal, make sure you’re in the backend directory, and type:

npx hardhat test

Frontend

In this section of the tutorial we’ll create a dApp (decentralized app) that will connect to your contract and its functions, allowing you to interact with it. In other words, we’re building an interface for the contract.

1. Open the terminal (command line) and go into the simple-storage directory. Create a sample Next app by typing:

npx create-next-app@13 frontend

• Make sure to choose these settings.

2. Before running the sample app, you’ll need to remove the .git file that was automatically created inside the new frontend folder. To remove the file, type this command inside the terminal:

# Linux / macOS
cd frontend
rm -rf .git

# Windows
cd frontend
rm -r -fo .git

3. Install these packages using your terminal (you should still be in the frontend directory).

npm install web3modal
npm install ethers@5

4. Create a new folder called constants within the frontend directory. Inside the constants folder create a new file called index.js. Add the following code inside index.js.

export const MY_CONTRACT_ADDRESS = "MY_CONTRACT_ADDRESS";
export const abi = MY_ABI;

• Replace the MY_ABI with the abi array that can be found in the following file: backend/artifacts/contracts/SimpleStorage.json
• Replace the MY_CONTRACT_ADDRESS with the address of the contract that you deployed in the Backend section of this tutorial.

5. Finally, to build the interface of the contract, open the index.js file under the pages folder (in the frontend folder) and replace its content with the index.js code from this project.
6. Add the Charming Data images using the instructions below. Once you understand how to add images to your app, feel free to replace with your own images, in which case you would need to update the images’ names inside the pages/index.js file (lines 143 & 154)

• Add the logo-charmingdata-small.ico and logocharmingdata.png to the public folder inside the frontend directory. Do not change image names.

7. Go back to your terminal; make sure your in the frontend directory and type:

npm run dev

Sharing your dApp with others

We will use Vercel to deploy the frontend of our contract. Before starting with Vercel you will need to create a GitHub account if you don’t have one and push your code into a GitHub repository:

1. Once your repositoy has been created in Github, go to Vercel and create an account by connecting your GitHub account.
2. Once your GitHub account is connected, click the button to add a new project in Vercel.

• add your repository (you might have to import it as well)

3. Select Next.js as the Framework Preset. In the Root Directory click Edit to select frontend.
4. Click Deploy, and wait a few minutes. When done, click your domain link to see your dApp.

The previous text was originally written by Adam from CharmingData.

The post Smart Contract to Store a Sentence on ETH appeared first on Be on the Right Side of Change.

Adam is the lead author of our book Plotly Dash — you can check it out here:

But first things first: What is Plotly Dash anyway? Dash is a Python framework for building analytical web applications, and Plotly is a graphing library for making interactive plots.

As you read through this tutorial, feel free to watch Adam’s excellent video explanation:

Let’s dive into the code from the GitHub, I’ll explain it in a minute. Here’s the high-level summary:

TLDR: This code is a Dash web application that displays live gas prices on the Ethereum blockchain, a line chart showing Ethereum’s value over time, and a line chart showing the number of active Ethereum addresses over time.

from dash import Dash, html, dcc, Input, Output, callback  # pip install dash
import dash_bootstrap_components as dbc                    # pip install dash-bootstrap-components
import plotly.express as px
import pandas as pd                                        # pip install pandas
from urllib.request import Request, urlopen
from dotenv import dotenv_values                           # pip install python-dotenv
import json


# get eth-to-usd dataset
df_eth_usd = pd.read_csv("https://raw.githubusercontent.com/Coding-with-Adam/Dash-by-Plotly/master/Analytic_Web_Apps/Blockchain-minimal/Gemini_ETHUSD_d.csv")
df_eth_usd['date'] = pd.to_datetime(df_eth_usd['date'])

# get eth-addresses dataset
df_eth_addr = pd.read_csv("https://raw.githubusercontent.com/Coding-with-Adam/Dash-by-Plotly/master/Analytic_Web_Apps/Blockchain-minimal/DailyActiveEthAddress.csv")
df_eth_addr['date'] = pd.to_datetime(df_eth_addr['date'])

# set up beaconchain api key for data on gas prices
config = dotenv_values(".env")
api_key = config['API_KEY']
# your .env file should have this line: API_KEY = "your-beaconchain-api-key"

# function to build one card for each gas price category
def make_card(key, get_data):
    return dbc.Card(
        [
            dbc.CardHeader(html.H2(key)),
            dbc.CardBody([
                html.H3(
                    f"{int(get_data[key] / 1000000000)} GWei",
                    id=key),
            ])
        ], className="text-center shadow")


# display app components on page
app = Dash(__name__, external_stylesheets=[dbc.themes.BOOTSTRAP])
app.layout = dbc.Container([
    html.H1("Live Gas Prices", style={'textAlign': 'center'}),
    dbc.Row(children=[], id='gas-data-display',className="my-4"),
    dbc.Row([
        dbc.Col([
            html.H3("Eth Value"),
            dcc.Dropdown(options=df_eth_usd.columns[3:], value='open', clearable=False, id='col_price'),
            dcc.Graph(figure={}, id='eth_usd_graph')
        ], width=6),
        dbc.Col([
            html.H3("Active Ethereum Addresses"),
            dcc.Dropdown(options=df_eth_addr.columns[1:], value='Unique Address Total Count', clearable=False, id='col_addr'),
            dcc.Graph(figure={}, id='eth_addr_graph')
        ], width=6)
    ]),
    dcc.Interval(id='update_trigger', interval=1000*4) # trigger every 4 seconds
])

# build the graphs based on dropdown value selected
@callback(
    Output(component_id='eth_usd_graph', component_property='figure'),
    Output('eth_addr_graph', component_property='figure'),
    Input('col_price', component_property='value'),
    Input('col_addr', component_property='value')
)
def udpate_graph(col_p_selected, col_a_selected):
    price_fig = px.line(data_frame=df_eth_usd, x='date', y=col_p_selected)
    addr_fig = px.line(data_frame=df_eth_addr, x='date', y=col_a_selected)
    return price_fig, addr_fig


# interval component triggers the callback to pull the current gas prices
@callback(
    Output('gas-data-display','children'),
    Input('update_trigger','n_intervals')
)
def udpate_gas_price(_):
    gas_price = {"code":200,"data":{"rapid":31701870016,"fast":24753659720,"standard":24753659720,"slow":24753659720}}

    # req = Request(
    #     url=f'https://beaconcha.in/api/v1/execution/gasnow?apikey={api_key}',
    #     headers={'User-Agent': 'Mozilla/5.0'}
    # )
    # web_byte = urlopen(req).read()
    # gas_price_string = web_byte.decode('utf-8')
    # gas_price = json.loads(gas_price_string)  # convert string to dict
    # gas_price["data"].pop("timestamp")
    # gas_price["data"].pop("priceUSD")
    # print(gas_price)
    
    gas_cards = [dbc.Col(make_card(y, gas_price["data"])) for y in gas_price["data"]]
    return gas_cards


if __name__ == '__main__':
    app.run(debug=True)

Wow, just a few lines of code to build a beautiful dashboard app in the blockchain space!

Here’s a step-by-step explanation:

1. Import necessary libraries.
   • Dash is a productive Python framework for building web applications.
   • dash_bootstrap_components is a library for adding Bootstrap components to your Dash apps.
   • plotly.express is a simple syntax for complex charts.
   • pandas is a data manipulation and analysis library.
   • urllib.request is used to open URLs.
   • dotenv is used to pull the API key from a local .env file.
   • json is used to parse JSON formatted data.
2. Get and process the eth-to-usd dataset from a GitHub repository, changing the 'date' column to a datetime format. The same is done for the eth-addresses dataset.
3. Load the API key for beaconchain from a .env file, which is used to fetch Ethereum’s gas prices.
4. Define a function make_card(key, get_data). This function will build a Bootstrap card for each gas price category.
5. Set up the Dash application and define the layout of the app.
   • The layout is a Bootstrap container that includes a heading, rows of Bootstrap cards, and two columns each containing a dropdown and a graph. The dropdowns are populated with column headers from the two datasets.
   • The dcc.Interval component is used to trigger an update function every 4 seconds.
6. Define a callback function udpate_graph(col_p_selected, col_a_selected). This function takes as input the selected values from the two dropdowns, uses those to select columns from the two dataframes, and returns line charts of those columns.
7. Define another callback function udpate_gas_price(_). This function is triggered every time the Interval component completes a cycle (every 4 seconds). This function fetches the current gas prices, builds Bootstrap cards with these prices, and returns these cards as a list of columns to be displayed in the 'gas-data-display' row. The actual API request is commented out, so the function currently uses hardcoded data.
8. Finally, if the script is run directly (as opposed to being imported as a module), it starts the Dash server with debug mode on. This mode provides detailed error messages, and the server will automatically reload when it detects changes in the source code.

Please note that the code currently uses hardcoded data for gas prices. The commented-out section shows how you could fetch live data from an API using an API key stored in a .env file. To use this live data, you would need to uncomment the relevant section and provide your own API key.

Recommended: Python Plotly Dash Cheat Sheet

If you’re interested in learning more about how to create beautiful dashboard applications in Python, check out our new book Python Dash.

You’ve seen dashboards before; think election result visualizations you can update in real-time, or population maps you can filter by demographic.

With the Python Dash library, you’ll create analytic dashboards that present data in effective, usable, elegant ways in just a few lines of code.

Get the book on NoStarch or Amazon!

The post Build Your First ETH Dashboard App with Python Dash appeared first on Be on the Right Side of Change.

Disclaimer: The author holds securities mentioned in this article.

I just listened to a great podcast on the MEV-burn upgrade, so I thought to contribute a blog post on the topic.

This upgrade addresses the Maximum Extractable Value (MEV) issue and enhances the overall Ethereum ecosystem. The presence of MEV in Ethereum can lead to negative consequences for user experience and network finality. But don’t worry, there’s hope on the horizon with the upcoming MEV-burn upgrade.

In the expanding world of DeFi, MEV has become a growing force in the Ethereum ecosystem, resulting in toxic forms like frontrunning and sandwich attacks, which can be detrimental to transaction originators. The MEV-burn upgrade promises to mitigate these issues and further reduce Ethereum’s circulating supply, ensuring a better experience for users like yourself.

As Ethereum has completed its much-anticipated transition to Proof-of-Stake (PoS) consensus, the MEV issue becomes even more critical to address. The potential risks include validator centralization and other unforeseen challenges. Thankfully, the MEV-burn upgrade could play a crucial role in safeguarding the network, providing you and the rest of the Ethereum community with more confidence in its security and long-term stability.

Let’s start with a quick overview of the proposal — don’t worry if you don’t get it yet but keep reading. You’ll be smarter afterward!

High-Level Overview

The MEV-Burn proposal aims to reduce proposer centralization, make validator rewards smoother, and enable MEV smoothing for all ETH holders. It allows Ether to capture on-chain value and enhances its economic attributes by making ETH the currency for block building and protecting its monetary premium. MEV burning results in ETH burn of equivalent value for any extracted opportunity, regardless of the assets involved.

In this system, each validator has a chance to become an eligible proposer for a slot. The average number of eligible proposers per slot can bid to propose the next block. These bids determine how much ETH must be burned by the chosen execution block.

Proposers will likely bid up to the MEV amount, resulting in most MEV being burned. The protocol doesn’t measure MEV directly but allows a burn auction to occur every slot.

The proposal involves increasing slot time to 16 seconds, with the first 4 seconds as a “bidding period.” During this time, eligible proposers submit bids, committing to an execution block hash that must burn ETH equal to their bid.

After bidding ends, the slot proceeds, and the highest bidder reveals their block. Other bidders can also reveal blocks, but higher bidders’ blocks will be prioritized.

ETH protocol developer Justin Drake argues that the MEV Burn will have a significant impact on the number of ETH burned. It could essentially double the deflationary rate, i.e., burning 200k-400k ETH more per year on a current supply of roughly 120M ETH. This could add an additional deflationary “yield” of 0.2% per year!

For a scarce asset like ETH, the MEV-Burn could mean an absolute supply shock. In a bull market with lots of demand that would lead to exploding prices.

Wen MEV Burn?

If you’re wondering when the MEV burn will be hard-forked into the Ethereum chain, here’s my best guess based on people more credible than me:

In a recent bankless podcast interview, the Ethereum protocol researcher Justin Drake estimated that the MEV-Burn upgrade will take three to five years. If you take the average and adjust for unforeseen protocol issues, you should not expect MEV burn to come into effect before May 2027.

Understanding MEV and Ethereum

Ethereum Ecosystem

In the Ethereum ecosystem, a key concept you should know is MEV, or Maximal Extractable Value.

MEV is the amount of profit that miners, validators, and block builders can extract from a block by rearranging or including certain transactions. This can impact transaction costs, causing higher gas fees and delays for regular users like yourself.

Recommended: Introduction to Ethereum’s Gas in Solidity Development

MEV in Decentralized Finance

The concept of MEV has become more prominent with the explosion of DeFi (Decentralized Finance) in 2020 — and particularly with the merge, i.e., the move towards proof-of-stake consensus.

Recommended: Common Consensus Mechanisms in Blockchains

In DeFi, various financial applications are built on top of blockchain networks like Ethereum. MEV plays a crucial role in these applications, as it can affect transaction costs and user processing times.

Toxic forms of MEV, such as frontrunning and sandwich attacks, can result in negative settlements, which means you, the transaction originator, may face disadvantages when trading on DeFi platforms such as Uniswap.

I highly recommend you check out our academy course on Uniswap and DeFi if you plan to get a job in crypto — it’s fun and very profitable!

Academy Course: Uniswap Automated Finance for Blockchain Engineers

MEV Participants and Opportunities

The main participants involved with MEV are validators and block builders. These entities are responsible for securing the Ethereum network, validating transactions, and building new blocks. By leveraging MEV opportunities, these participants can increase their revenue.

For example:

• Miners: They
• Validators: Validators can reorder, include, or exclude transactions in a block to maximize their profits, i.e., rearranging transactions to benefit from MEV.
• Block builders: In a PoS (Proof of Stake) model, block builders can also extract value from MEV by optimizing transaction ordering.

Transaction Frontrunning Example (MEV)

An example of Ethereum MEV is when a validator reorders transactions to make a profit. For instance, a validator can extract MEV by reordering transactions in a way that benefits them financially.

Suppose a user wants to trade 1 ETH for 100 DAI, and another user wants to trade 1 ETH for 200 DAI. The validator can re-order the transactions so that the second user’s trade is executed first, and then the first user’s trade.

By doing so, the validator can extract the price difference between the two trades, which is 100 DAI, as a profit.

This practice is known as “transaction frontrunning” and is a common way for validators to extract MEV (source: CoinDesk).

Impact of MEV on Gas Prices and Transactions

EIP-1559 and Gas Prices

With the introduction of EIP-1559, Ethereum aimed to make gas price estimation more predictable for users. However, it is essential to consider MEV’s influence on gas prices. When MEV bots attempt to extract value from transactions, they can drive up the gas prices in two ways:

1. MEV bots pay higher gas fees to prioritize their transactions, creating a competitive market for the limited block space.
2. Non-MEV users also pay higher fees to place their transactions above MEV-extracted transactions, leading to a chain reaction.

This situation might result in an unexpected spike in transaction fees for Ethereum users, even with EIP-1559 in place.

MEV Bots and Network Congestion

MEV bots compete with each other to extract value from user transactions. In times of high network activity, they can contribute to network congestion. MEV bots flood the network with transactions, hoping to exploit profitable opportunities.

In turn, this creates the following scenarios:

• Longer transaction confirmation times
• An increase in the number of pending or dropped transactions
• Overall decline in the network’s performance

These factors affect the user experience for all Ethereum users, making it less predictable and, potentially, less efficient.

But it seems like MEV is a phenomenon that just comes with any complex monetary system and we just have to accept it. MEV burning at least attempts to use the energy to fuel the economic value of the ETH token.

Transaction Discrimination in MEV

One significant concern related to MEV is transaction discrimination.

MEV bots often target high-value transactions, such as those involving DeFi protocols or large trades. As a result, if your transaction falls into this category, it might be targeted and front-run by MEV bots. Also, MEV bots might sandwich your transaction, potentially causing you to receive a worse deal.

If your transaction is not considered valuable by MEV bots, they might still impact your experience indirectly.

For example, because of the increased gas prices and network congestion caused by MEV bots, your transaction might still be delayed or require higher transaction fees.

MEV-Burn: A Solution to MEV Issues

MEV-Smoothing Concept

As you dive into Ethereum, you’ll come across the concept of Maximal Extractable Value (MEV). Again, MEV refers to the profits derived from exploiting the ordering of transactions on the blockchain. The MEV-Smoothing concept aims to distribute these profits more fairly across the Ethereum ecosystem.

This innovative idea introduces mechanisms to “smooth” the revenues generated from MEV, ensuring that all participants, including ETH holders and mining pools, can benefit from the value being extracted from the network. It takes a collective approach to address the negative impacts of MEV and creates a more equitable environment for everyone involved.

Proposer-Builder Separation

As Ethereum transitions towards proof-of-stake (PoS) and staking, the proposer-builder separation is one of the key concepts introduced to help mitigate MEV-related issues.

Currently, miners have the power to both create and validate blocks, often leading to frontrunning and other malicious practices that exploit MEV.

With the proposer-builder separation, these roles are effectively split. Proposers become responsible for aggregating transactions and proposing blocks, while builders focus on executing and validating them. This separation reduces the ability of miners to exploit MEV, increasing fairness and trust in the Ethereum ecosystem.

Reducing MEV Profits and Sell Pressure

The introduction of MEV-burn aims to further align the incentives of individual miners with the rest of the Ethereum ecosystem. This innovative upgrade creates a mechanism to burn the MEV profits extracted by miners, reducing the sell pressure on ETH’s price and ultimately benefiting ETH holders.

As mining pools and stakers see their MEV profits channeled back into the system, they can expect a more equitable distribution of rewards. This process, in turn, helps strengthen the entire Ethereum ecosystem by curbing the negative effects of MEV and enabling a more sustainable growth trajectory for the network.

In conclusion, the implementation of MEV-burn, proposer-builder separation, and Mev-Smoothing concepts contribute significantly to addressing the MEV issue in Ethereum. By fostering a more equitable distribution of profits and reducing the ability of miners to exploit MEV, these solutions help ensure a brighter future for the Ethereum ecosystem and its participants.

Exploring Front-Running and Back-Running in MEV

In Ethereum and blockchain technology, front-running and back-running are common issues. As you delve into these topics, it’s important to understand how they can affect users and developers within the ecosystem.

Flashbots and Front-Running Attacks

Front-running occurs when someone—such as a miner or a node—takes advantage of their position within the network to exploit transaction orderings for their own benefit.

Flashbots are a recent development that aims to address this issue by introducing a fairer environment for all participants. These bots work by transparently allowing searchers to compete for MEV rewards through order flow auctions.

To avoid being a victim of front-running attacks, familiarize yourself with the concept of MEV activity and consider using tools that safeguard your transactions. Keep in mind that Ethereum developers are already addressing this issue through various mempool design improvements.

Back-Running and Chain Reorgs

Back-running, on the other hand, involves the execution of concurrent transactions that aim to capitalize on another user’s desired transaction. It poses a similar threat as front-running and is often tied to chain reorgs where multiple transactions are reorganized within the blockchain.

Knowledge about back-running can help you stay aware of potential risks associated with certain transactions, and may encourage you to engage with projects that actively combat these issues.

The expansion of Flash Boys 2.0 and other efforts focusing on the mitigation of front-running and back-running risks indicates that the Ethereum community is dedicated to addressing these concerns.

Addressing MEV Challenges

The Merge

The Merge has offered new opportunities to address MEV challenges. Ethereum researchers are working on the proposer-builder separation, which separates the role of validators into two distinct functions:

• Proposers: Responsible for creating blocks and providing transaction ordering
• Builders: Responsible for collecting and packaging transactions into block candidates

Separating these roles reduces the risk of validator centralization, and the incentives for harmful actions like eclipse attacks and DDoS attacks are minimized. This new structure will provide a level playing field for all validators, ensuring a healthier network for you and other Ethereum users.

Alternative Solutions to MEV Problems

Ethereum researchers are exploring alternative approaches to address MEV-related problems. One such solution is MEV smoothing.

MEV smoothing involves evenly distributing the MEV revenue to a larger group of participants, preventing any single validator from receiving a disproportionately high reward. This can help reduce validator centralization further and enhance the security of the Ethereum network.

For example, Rocketpool has already distributed a decentralized staking mechanism with smoothing pool for MEV.

Another solution currently under development is the MEV-burn upgrade, which aims to redistribute extracted value to Ethereum users by burning a portion of the MEV rather than passing it to validators. This upgrade is conceptually similar to EIP-1559 and aims to make the Ethereum network more equitable for its users.

Chain reorgs are another MEV-related concern. However, with the Proof-of-Stake model and the proposer-builder separation, the potential for chain reorgs should be significantly reduced. This will help maintain the integrity of the Ethereum network and protect your transactions from being manipulated.

In conclusion, addressing MEV challenges is a priority for Ethereum researchers, and various solutions are being developed to safeguard the network and improve your experience as an Ethereum user.

Recommended: Ethereum – Top 10 Articles to Get Started

The post MEV Burn Ethereum: Greatest Supply Shock in ETH History? appeared first on Be on the Right Side of Change.

Before beginning the process of transferring an ENS domain, ensure you have the following tools at hand. This includes :

• A current Ethereum wallet: This is the wallet containing the ENS domain that you want to transfer.
• A new Ethereum wallet: This is the wallet to which you want to transfer the ENS domain.
• Access to the ENS domain manager: This is where you’ll manage your ENS domain settings and perform the transfer (app.ens.domains).

Note that ENS domains work as non-fungible tokens (NFTs), so transferring ownership is similar to transferring other NFTs .

Attention: Simply sending the ENS domain NFT to the other wallet will only transfer the Registrant but not the Controller role of the domain. The controller manages ENS records and subdomains, while the registrant controls the controller address and registration transfers. Roughly speaking, the registrant is more powerful than the controller. But the controller is the address that gets the assets! For example, if the controller of domain aaa.eth has address 0x123 and the registrant has address 0x456 and you send funds to aaa.eth, the controller will get those funds but the registrant has ultimate control if they choose to.

Make sure you have control over both the current and new Ethereum wallets.

With these prerequisites in place, you are well-prepared to proceed with the transfer . Just follow the steps in the subsequent sections and your ENS domain will soon be transferred to your new Ethereum wallet.

Connecting Wallet

Before transferring your ENS domain, connect your wallet to the platform you’ll be using for the process. This is typically done on the ENS Domain Manager or other compatible platforms like Coinbase Wallet and MetaMask.

First, visit the chosen platform’s website or open its app and log in using your wallet credentials. Most platforms support popular wallets like MetaMask or Coinbase Wallet.

Once you’ve logged in, navigate to the settings or account section of the platform. Here, you should find an option to connect your wallet. Select the option and follow the on-screen instructions to complete your wallet connection. Some platforms may require additional verification steps, such as providing password authentication or approving the connection from your connected wallet.

After successfully connecting your wallet, you should have access to your ENS domain and be ready to transfer it to a new wallet. Connecting your wallet is a crucial step in transferring your ENS domain, as it ensures the proper ownership and control of your domain during the process.

Finding ENS Domain

In order to transfer an ENS domain, the first step is finding the desired domain. Fortunately, there are user-friendly tools that make this process simple and efficient.

The ENS Domain Manager application can be used for finding and managing domains. Simply visit the application and search for the desired domain to check its availability.

Once the domain is found, users can view additional details, such as the current owner, registration process, and more. The ENS domain system also offers compatibility with IPFS by including hashes in the domain records. This feature enables decentralized websites to be hosted seamlessly.

In order to complete domain-related actions smoothly, it is essential to have an Ethereum wallet connected, such as MetaMask. This connection allows for proper authentication and execution of transactions in the Ethereum Name Service ecosystem.

What is the Difference Between a Registrant and a Controller?

The distinction between a Registrant and a Controller in an Ethereum Name Service (ENS) allows for a more efficient management of domain names . To understand their roles, let’s start with a brief explanation of each.

A Registrant is the person or entity to whom the domain is registered . They are the ultimate owner of the domain and have complete control over it. The Registrant can transfer ownership to another account or a smart contract that manages subdomains, records, and more, while still being able to recover ownership if needed (ENS Documentation).

On the other hand, a Controller is someone who has been delegated with day-to-day control over the domain by the Registrant . This role can change the resolver and add or edit records. Some applications, like Fleek and OpenSea, set themselves as the Controller to update records on behalf of the Registrant (ENS App). A Controller’s role is similar to the operator of DNS servers for a domain name that is registered with a domain registrar like GoDaddy (Reddit ethdev).

The Registrant has the ultimate control over the name, while the Controller is responsible for handling everyday operations. Separating these roles makes it easier to build automated systems to update ENS efficiently and provide more flexibility in domain management .

Also note that even if you have moved the registrant and the controller to the new wallet address. The “Records” field of your ENS has an entry for ETH addresses that may still point to the old address causing the Ethereum explorers still believe that your_domain.eth points to the old wallet address.

But you can change it easily in the ENS dashboard:

Initiating Transfer Process

You can transfer the ENS domain to a new wallet in three steps:

Step 1: Connect your wallet that has both registrant and controller roles to the ENS website.

Step 2: Transfer the Registrant role by clicking the first Transfer button and confirming the transaction proposed by your wallet. This will cost some ETH fees because it is recorded in the blockchain. Make sure you have some ETH in your wallet for fees!

Step 3: Transfer the Controller role by clicking the second Transfer button and confirming the transaction.

Now you’re done! The new wallet address now has the ENS NFT and both the controller and registrant roles.

Verifying Transfer

After completing the process of transferring your ENS domain, it’s important to verify that the transfer has been successfully executed . This section will guide you through the steps to make sure everything went smoothly.

First and foremost, check your new wallet and make sure it now displays the transferred ENS domain (as an NFT). If the domain is visible, it’s a clear indication that the transfer has been successful . However, if the domain is not visible, do not panic; it might take a few minutes for the changes to reflect on the blockchain. Just give it some time .

In case you still cannot see the domain in the new wallet after a reasonable waiting period, head back to the ENS App and enter your ENS domain name in the search bar. This will provide you with detailed information, including the current Registrant and Controller addresses . Verify that these two addresses match the new wallet address that you intended to transfer the domain to. If they match, then the transfer has been successful, and you just need to wait a bit longer for your new wallet to reflect the changes.

You can also verify on an Ethereum blockchain explorer such as https://etherscan.io/ (see previous graphic).

Remember to keep track of any errors or irregularities you encounter during the process. In the rare case that you experience an issue that you cannot resolve, consider reaching out to the ENS support team or community forums for assistance . They’re always ready to help you with any problems related to ENS domain transfers.

Common Issues and Troubleshooting

When transferring an ENS domain, users may encounter some common issues. In this section, we’ll discuss a few of these problems and provide solutions to help make the process smoother.

One common issue is forgetting to change the Controller of the domain. The controller is the account that manages day-to-day operations of the domain, such as creating subdomains and setting resolvers . To resolve this, visit the ENS Domain Manager in your wallet and update the controller address.

Another issue that may arise is the inability to transfer the domain due to it being locked . This can occur if the domain is involved in a dispute or if it has been involved in illegal activities. To resolve this, contact the ENS administrators or an appropriate legal process for assistance.

Users might also face challenges in maintaining anonymity while transferring a domain. To maintain privacy, it is recommended to use an anonymous wallet or take additional steps like holding a fake sale on OpenSea and keeping the new address segregated from KYC services . More details can be found here.

Lastly, technical difficulties may occur while using the ENS Domain Manager. In such cases, ensure that you are using an updated browser version , have a stable internet connection , and consider trying a different browser or device if issues persist.

If you want to keep learning about exponential technologies, consider joining our free email academy (140,000 coders and tech enthusiasts). However, you should only join if you want to learn coding and tech!

Recommended: Ethereum – Top 10 Articles to Get Started

The post How to Transfer an ENS Domain: A Quick and Easy Guide appeared first on Be on the Right Side of Change.

Disclaimer: Some Finxter Creators hold securities mentioned in this article.

Developer Activity

Finxter is all about using code to leverage the power of infinite computing, so developer activity is the primary metric to determine the state of crypto. How many developers work for Bitcoin, Ethereum, Solana, and decentralized applications?

The following chart from the report (see above) shows the number of active developers building crypto projects on GitHub:

As you can see, developers have never really left during the bear market. They kept building!

Now compare this to the price chart between 2016 and 2023:

The crypto industry is not all about price — price is only one metric but not the most essential “leading metric”. Developers investing their time, careers, and lives into the crypto industry is a far more important metric to determine the state of the crypto industry.

That’s my view anyway.

Here’s the number of developers who engage with crypto-related open-source coding projects on GitHub:

A similar bullish outlook. Given that prices are down at the time of writing, the robust developer activity paints a bullish picture!

Smart Contracts

A similar “leading” metric is the number of developers deploying code on a public blockchain. You may find that this is a proxy for developer activity. The picture is similar:

We have seen a decline from the peak in 2022. However, the numbers hold steady, and smart contract deployers keep rolling out new dApps — a bullish sign!

Let’s confirm this with another chart showing the number of crypto applications launched:

Note that this is not a cumulative metric — or it would be monotonously increasing. More and more “Verified Smart Contracts” are launched every month. We are even at an all-time-high in this metric!

Crypto Tooling

Developers need tools to deploy decentralized applications. On Finxter, we have shared many tutorials on deploying dApps using various tools such as web3.js and ether.js. Click the links to learn more!

Here’s the number of downloads for developer tools such as Web3.js and Ether.js:

It keeps growing — we even reached an all-time-high last month. Again this confirms that developers have never really left. The new dapps built with those tools by those active developers may attract the next gigantic wave of new users in various industries such as NFT, gaming, and DeFi.

Recommended: Learn to Build Smart Contracts in React with web3.js: Here’s How! (1/2)

The Crypto Job Market

The interest for crypto-related jobs is clearly rising over the last couple of years. This chart is based on Google Trends:

Figure Description: “Aggregate interest over time score of worldwide searches for “blockchain jobs”, “crypto jobs”, “cryptocurrency jobs”, and “web3 jobs”. Scores are denormalized (and thus unbounded) using a method called Google Trends Anchor Bank.”

But the demand for skilled crypto developers outstrips the supply as can be seen in the percentage growth of salaries, that is 517% per year as reported by Hired.com:

Source: https://icoholder.com/blog/blockchain-developer-salaries-around-the-world/

Although this is based on 2021 data. Here’s some more recent data from dappuniversity:

This demand growth chart for different engineering roles is based on interviewbit.com:

Also, you may be interested in this 2023 summary of the crypto developer job market:

“Blockchain developers are in high demand. According to a LinkedIn study, blockchain developers are one of the fastest growing and most-sought after technical skills in 2023. Blockchain developers are making 50-100% more than traditional developers.” (source)

Tutorialspoint reports an average salary of $120,000 for junior developers. (source).

On our own blog post, we did some research — here’s our result of the average income of Blockchain developers:

Recommended: Blockchain Engineer – Income and Opportunity

Crypto Users

What is the usage of various blockchains in terms of number of users? Let’s examine the number of active addresses that can be seen as a proxy for number of unique users across various blockchains:

Up to the right! Even in the depth of the bear market, the number of active addresses keeps growing.

The number of transactions also supports this optimistic picture:

But is this all wash trading? Well, a metric that cannot be easily manipulated is the actual transaction fee paid. This is the actual blockspace revenue and it must be paid with cold hard moneary units!

Interesting! This metric clearly shows that we’re still deep in the bear market. Yes, the level of transaction fees in 2023 is much higher than last bear market between 2019 and 2020. However, the overall picture of this hard-to-manipulate metric is not as rosy as the other metrics.

This should give us some food for thought!

However, some developments in the crypto fee space are really encouraging such as the fees paid by layer 2 solutions such as Polygon, Arbitrum, and Optimism:

If this exponential trend persists, we’ll see a significant increase of Ethereum fees in the near future. Layer two solutions already make up 7% of all ETH fees paid — and they grow rapidly by >300% per year!

One of the primary “lights” in the Ethereum space is the development of scalable layer two solutions due to zero knowledge technology:

If you want to learn more about ZK-EVMs, feel free to check out our Finxter article.

Recommended: What is a zkEVM Rollup? A Simplified Guide to Ethereum’s Most Promising Scaling Solution

Seven Key Takeaways of “The State of Crypto in 2023”

Here are my key takeaways of the report:

1. Blockchain engagement surges, reaching 15 million active addresses due to diverse applications like on-chain games.
2. DeFi and NFTs gain traction with new applications; decentralized exchanges experience growth in trading volume.
3. Crypto developer count remains steady with nearly 30K contributors last month, a 60% increase in three years.
4. Blockchains scale through innovative protocols and projects, with L2 solutions making up 7% of Ethereum fees.
5. Rapid advancements in “zero knowledge” systems offer potential for scalability and privacy-protecting applications.
6. The U.S. loses web3 dominance, as its share of crypto developers decreases by 26% from 2018 to 2022.
7. Long-term trends show steady growth in market cap, developer activity, and funding, driven by price-innovation cycles.

If you want to boost your Blockchain development skills, create yourself a highly valuable and well-paid skill for the next decades, and certify your crypto skill with a personalized PDF course certificates, check out our crypto courses on the Finxter Academy — all free for Finxter Premium Members!

• [Academy] Don’t Be Left in the Cold Wallet: Learn Building Ethereum ERC-20 Tokens!
• [Academy] Blockchain Development – Creating a React dApp to Sell eBooks
• [Academy] Chainlink Expert – Building dApps with Oracle Networks
• [Academy] Uniswap Automated Finance for Blockchain Engineers

Also, we have cryptolancing course that may be of interest to you — note all courses can be accessed with the premium membership!

The post The State of Crypto in 2023 appeared first on Be on the Right Side of Change.

It’s part of our long-standing tradition to make this (and other) articles a faithful companion or a supplement to the official Solidity documentation. We’ll base this article on the original Solidity programming language content.

Conceptual Overview

A constructor is a Solidity language feature that makes it possible to attach a specific behavior, i.e., a function, to the beginning of the smart contract lifecycle. It is executed only once – when a contract’s instance is created. A constructor is the right place to define the contract initialization code.

The initialization cycle starts with the state variables: in case of an inline initialization, they are set to their explicitly specified values. Otherwise, the state variables are set to their type-determined default value when inline initialization is omitted. The next step of the initialization cycle is the execution of the constructor code.

After the constructor execution concludes, the final code of the contract is ready and deployed to the blockchain. This is a good place for us to discuss the cost of the contract deployment, which is proportional to the length of the code.

When we say “code”, we imply all the functions that make up the public interface, i.e., functions whose visibility modifiers are public or external.

Besides, all the functions can be reached via function calls through the public interface functions. In contrast, the contract cost does not include the constructor code or the functions only called from the constructor and whose visibility is set to internal.

Recommended: Solidity Function Calls – Internal and External

Default Constructor

As with most of our examples in previous articles, if we omit the constructor, the compiler will imply there’s a default constructor, which has no arguments and no body: constructor() {}, as showcased in this simple example:

// SPDX-License-Identifier: GPL-3.0
pragma solidity >=0.7.0 <0.9.0;

// SPDX-License-Identifier: GPL-3.0
pragma solidity >=0.7.0 <0.9.0;

contract A {

    // A default constructor can be omitted.
    constructor() {}
}

The sole purpose of a default constructor is to initialize the state variables with their default, type-dependant values.

Note: Don’t forget to include the pragma directive before trying each of the following examples; I’m deliberately omitting it to avoid unnecessary code duplication.

Regular Constructor

First, we’ll take a look at a simplified example of a constructor that initializes the state variables to fixed values through a process called inline initialization:

contract A {
    uint public a;

    constructor() {
        a = 5;
    }
}

In this example, our state variable A is initialized to a fixed value of 5. Of course, this approach is excessive since we could have gotten exactly the same effect simply by doing the following:

contract A {
    uint public a = 6;
}

However, these two examples are hard-coded and don’t demonstrate the real usefulness of constructors, but I showed them for the sake of completeness and better understanding. The following example will start to unveil the true versatility and purpose behind using constructors:

contract A {
    uint public a;

    constructor(uint a_) {
        a = a_;
    }
}

contract B {
    A contract_A = new A(22);
    uint public a = contract_A.a();
}

Although more complex, this example shows how to declare a constructor that takes an argument via its parameter uint _a. This way, we can dynamically instantiate our contract, and that’s where the true power of parametrized constructors lies.

First, we declared contract A with a parametrized constructor. Then, we declared a new contract B in which we created an instance of contract A called contract_A by passing it argument 22. Finally, we assigned the value of the state variable contract_A.a to the state variable b by calling its getter function to confirm that contract_A is dynamically instantiated to the value of the given argument.

An even nicer, elegant example with the same effect can be achieved simply by deriving contract B from contract A by giving it an argument:

contract A {
    uint public a;

    constructor(uint a_) {
        a = a_;
    }
}

contract B is A(22) {
}

Conclusion

In this article, we learned about contract constructors.

First, we made a conceptual overview of a constructor in Solidity.

Second, we explained what a default constructor is.

Third, we showed how regular constructors can be declared and used through several illustrative, simple examples.

What’s Next?

This tutorial is part of our extended Solidity documentation with videos and more accessible examples and explanations. You can navigate the series here (all links open in a new tab):

Prev Tutorial

Syllabus

Next Tutorial

The post Solidity Function Constructors – A Helpful Simplified Guide with Video appeared first on Be on the Right Side of Change.

It’s part of our long-standing tradition to make this (and other) articles a faithful companion or a supplement to the official Solidity documentation. We’ll base this article on the original Solidity programming language content.

Overview

Function overloading is a feature that enables us to define more than one function with the same name but with different combinations of function parameters in terms of their number and type.

Roughly speaking, we’d usually go with the function overloading approach when we need:

• Different variants of the same base functionality or business logic, i.e. a function performing the addition of integers vs floating-point numbers;
• Specialized versions of one generalized base functionality, i.e., a function adding two integers instead of ten integers. In this case, a specialized version of the base functionality can be considered a function wrapper because it contains a call to the base function with some parameters commonly hardcoded to default values.

Note: In a sense, overloading can also be applied to inherited functions, but in that case, we refer to it as function overriding. When a function overrides an inherited function, it has the same signature as the overridden function, i.e., the same function name, parameter number, and parameter type. Effectively, the overriding function redefines the inherited (base) function behavior, but only on a sub-class level.

With that said, let’s just remember that function overloading produces more variants of the same-name function, while function overriding just redefines an inherited function.

Function overloading cannot be achieved by renaming the function parameters, i.e., function parameter names don’t affect the function signature and cannot produce an overloaded function.

Example – Function Overloading

The following example shows how function overloading works. As we always do, we’ll analyze it segment by segment.

// SPDX-License-Identifier: GPL-3.0
pragma solidity >=0.4.16 <0.9.0;

A regular contract defines two functions with the same name, but with a different number of parameters and parameter types.

contract A {

The first function f takes only one parameter, value, of type uint. The function behavior is extremely simple: it just returns the received parameter value by assigning it to the output parameter out.

    function f(uint value) public pure returns (uint out) {
        out = value;
    }

The second function f takes one more parameter, really, of type bool, but also keeps the same parameter from the first function f definition, value.

The function behavior is just a shade more complex: it conditionally returns the received parameter value by assigning it to the output parameter out, i.e., if the parameter really is set to true.

Otherwise, the parameter out returns the default value, determined from its variable type uint, which is 0.

    function f(uint value, bool really) public pure returns (uint out) {
        if (really)
            out = value;
    }
}

Example – Function Overloading in External Interface

Before we analyze another example of function overloading specific to external interfaces, let’s shortly discuss what’s so special about external interfaces.

Functions in external interfaces introduce two kinds of types: Solidity types and external (ABI) types. For instance, Solidity can have multiple address types, such as contract and address. However, from the ABI perspective, the mentioned types are regarded as the same type, which would cause an error during the compilation if used in an overloading attempt, as in our example:

// SPDX-License-Identifier: GPL-3.0
pragma solidity >=0.4.16 <0.9.0;

A very simple example showing an attempted function overloading with different Solidity types, but the same (after compilation) ABI types.

contract A {

Input and output type B is contract type from the Solidity perspective, but it’s also address type from an ABI perspective.

    function f(B value) public pure returns (B out) {
        out = value;
    }

Input and output parameter types address are the same from the Solidity perspective and from the ABI perspective in both overloaded functions.

    function f(address value) public pure returns (address out) {
        out = value;
    }
}

Declares the placeholder contract B for parameter typing purposes.

contract B {
}

After compilation, both functions are declared as public (public =  external + internal), take the same overloaded form and therefore cause an error, since they both have input and output parameter types declared as address, hence causing improper overloading from ABI (compiler output) perspective:

TypeError: Function overload clash during conversion to external types for arguments.

Implementation

Now that we know what function overloading is, let’s see how it works.

A function call to an overloaded function is resolved by the function name and argument matching, meaning the right function in the current scope is selected depending on its name and the arguments in the function call.

Specifically, overloaded functions are selected as candidates if their arguments are implicitly convertible to the expected parameter types. Of course, if the function parameter conversion fails for only one parameter, the resolution fails and the function candidate is entirely dismissed.

Note: Function return parameters (types) are not part of the function resolution process.

To make the story of implicit conversion more clear, we’ll look at the example below:

// SPDX-License-Identifier: GPL-3.0
pragma solidity >=0.4.16 <0.9.0;

contract A {
    function f(uint8 val) public pure returns (uint8 out) {
        out = val;
    }

    function f(uint256 val) public pure returns (uint256 out) {
        out = val;
    }
}

In this example, we have a function f overloaded in two instances: the first instance takes and returns a variable of uint8 type, while the other instance takes and returns a variable of uint256 type.

A call f(50) would return a type error because it’s ambiguous, i.e., it cannot precisely determine the right function instance since the argument 50 can be implicitly converted to match both functions. However, when we make a call f(256), a function f(uint256) is the only one that matches the result of the implicit conversion of argument 256, so this call proceeds without any errors.

Conclusion

This article taught us about function overloading and compared it with function overriding.

First, we made an overview to understand what we’re talking about.

Second, we went through an example showing how function overloading looks in its simplest form.

Third, we studied a bit more complex example of function overloading with regard to external interfaces.

Fourth, we went into just a bit more detail, showing how the overloaded function resolution works under the hood.

What’s Next?

This tutorial is part of our extended Solidity documentation with videos and more accessible examples and explanations. You can navigate the series here (all links open in a new tab):

Prev Tutorial

Syllabus

Next Tutorial

The post Solidity Function Overloading appeared first on Be on the Right Side of Change.