This continued demand in DeFi protocols highlights the need for standards like ERC-4626, crucial for ensuring consistency.

In this article, I share my learnings and thoughts around ERC-4626, a standardization for tokenized vaults.

Here’s what we’ll cover.

• The Composability Nightmare Problem

• Why the USB-C Era for Token Vaults is Needed

• The 18 Methods of ERC-4626 (And two of the most important ones)

Before we dive into ERC-4626, here are some important terms that are helpful to understand:

Definitions

Interface: an "interface" acts as a control panel for a program, listing available functions, their required inputs (parameters), and the resulting outputs (return values).

Behavior: refers to how a system or component consistently manages its actions and status, responding to inputs and events.

Adapter Code: is customarily created to transform or adjust one interface or protocol into another, enabling systems or components originally designed to work separately to interact smoothly.

Connectors: serve as universal connection points between systems, enabling communication and data exchange. They act as bridges that link different systems or components.

Composability: represents the ability of various components or systems to seamlessly integrate and operate together, resulting in a harmonious and functional whole.

The Composability Nightmare Problem

Token vaults are used in DeFi to earn rewards on your crypto. They are smart contracts that accept deposits and earn yield (interest). Vaults implement complex strategies, like leveraging, auto-compounding, and diversifying across various protocols in order to get the best return.

This variance in strategy and implementations causes a few problems, putting you right in the middle of what I call a 'composability nightmare’.

In blockchain, composability is important because it allows different protocols and applications to interact seamlessly, creating a more interconnected and functional ecosystem. The way token vaults are currently implemented, with their varied requirements and behaviors, doesn't exactly help in enhancing this composability.

This is like having to buy a new charger every time you upgrade your phone because the old one is obsolete. Can you  imagine how filled your drawers would be? This situation was not only inconvenient but also both time-consuming and costly.

This is how vault tokens work today. Vaults are cell phones- and chargers represent the connectors.

Just as each new phone model often required a different charger back in 2008, DeFi protocols integrating token vaults must continually develop and update specialized ‘chargers’ (adapters and connectors) to accommodate the unique requirements of each vault

This current way has a few drawbacks:

• Increases the likelihood of errors in code. Protocol engineers must understand various implementations, adding complexity and risk of security costs due to buggy code.

• Requires increased resources. Time spent learning and implementing the code is an expense to the organization.

Why the USB-C Era for Token Vaults is Needed

ERC-4626 aims to provide a standardized interface and behavior for token vaults.

Let’s first start with illustrating a basic token vault. These are the basic functionalities we’d like to have:

1. Allow user to deposit

2. Allow user to withdraw

3. Read vault balance

4. Vault manage asset to share amount

Token vaults enter their USB-C era

ERC-4626 is a way to universally implement token vaults, so protocol engineers can easily integrate them with other dapps and tools.

As we've discussed, even basic functionalities in token vaults can be implemented in various ways, leading to complexities. For instance, when considering any standard function within these vaults, questions arise about its structure and parameters. What data should it accept? How should it handle different user scenarios?

You can appreciate how such nuances can quickly escalate into larger composability problems, especially as the vaults grow in complexity.

The 18 Methods of ERC-4626 (And two of the most important ones)

ERC-4626 offers 18 methods and 2 events for developers to easily inherit in their vaults. This standard provides developers a ‘feature ready’ concept. While not primarily focused on security, an increase in security emerged as a beneficial byproduct.

Developed through community proposals and votes, ERC-4626 adheres to good conventions and essential safeguards. It ensures functions have standardized meanings and behaviors. Safeguards, such as the checks and effects pattern, are implemented to prevent malicious actors from exploiting the contract logic before transactions are finalized.

We won’t be reviewing all 18 methods, but we will evaluate the deposit and withdraw methods.

Deposit

Let’s begin with a diagram illustrating the basic user flow of depositing assets into a vault.

I want to deposit $100 USDC. In exchange I will be issued vUSDC (vault tokens) that represent the shares I own in the vault.

1. Transfer assets to vault

2. Issue vault tokens

Sounds pretty basic, but let’s dive deeper and see what the code is actually doing. You can find the code to this method here.

1. Parameters

   The deposit function is called with two parameters, assets and receiver. assets are expected to be a number representing the amount of the token that the depositor wants to deposit. The receiver is the address that will receive the vault tokens.

2. Calculate and Validate Shares

   This check ensures that the amount of assets about to be deposited will result in the issuance of vault tokens. If the number is greater than 0, it moves onto the next line. If the number is 0, then the transaction will be reverted. Gas will still be paid up to this point.

3. Transfer Assets to Vault

   In order to securely transfer the assets from the user to the vault, the contract calls the safeTransferFrom method, which is inherited from the ERC-20 standard. Because it facilitates the transfer of assets from the user's control to the contract, the user must first call the approve method on the token contract to grant the vault contract an allowance to use their assets.

4. Issue Vault Tokens

   This involves another ERC-20 method, where _mint generates a new supply of vault tokens. The new supply, also known as shares, are then sent to the receiver.

5. Deposit Event

   The contract records the deposit details in an event, capturing the initiator, receiver, and the amounts of assets and shares. Frontend applications can listen to these events to trigger UI updates.

6. Optional Hook

   Is intended to execute some additional code after the deposit process (including asset transfer and share minting) has been completed.

This method's construction was no accident. It follows best practices by using secure asset transfer methods, implementing checks for share calculation, and utilizing event logging for transparency.

Withdraw

Let's start by visualizing the basic process of withdrawing assets from a vault.

I want to withdraw $50 USDC. When I initiate the transaction, the vault will then burn the corresponding vault tokens in comparison to the value of my request withdraw.

Here’s what happens on a high level.

1. Burn Vault Tokens

2. Transfer Assets

Let’s take a deep dive into the code. You can find the code to this method here.

1. Parameters

   The withdraw function takes three parameters: assets, receiver, and owner. Assets is the amount of USDC I wish to withdraw. The receiver is the address that will receive the assets, and owner is the address that owns the vault tokens to be burned

2. Calculate Shares for Assets

   First, the contract calculates the number of shares equivalent to the assets I want to withdraw using previewWithdraw(assets). This determines how many of my vault tokens (vUSDC) are needed for the withdrawal.

3. Ownership Verification

   The contract checks if I am the owner of the vault tokens. If not, it proceeds to the next step.

4. Authorized Withdrawal Check

   If I'm not the owner, the contract calculates how many shares I am authorized to withdraw on behalf of the owner. This step involves checking the allowance set by the owner for my address.

5. Permission Validation

   The contract ensures I have the owner's permission to withdraw the specified amount. If the allowance is sufficient, it's reduced by the number of shares being withdrawn.

6. Optional Hook

   Before the actual withdrawal, an optional hook can execute additional logic.

7. Burn Vault Tokens

   Next, the contract burns the calculated number of vault tokens (vUSDC) from the owner's balance. This step reduces the total supply of vault tokens in circulation.

8. Withdraw Event

   The contract records the withdrawal details in an event, noting who initiated the withdrawal, who is receiving the assets, and the amounts involved. Frontend applications can listen to these events to trigger UI updates.

9. Transfer Assets

   Finally, the assets (USDC) are transferred from the vault to the receiver's address using the safeTransfer method. Unlike the deposit function, where safeTransferFrom is used to pull assets from the user's account with their permission, safeTransfer is employed here because the assets are being pushed from the vault's own balance to the receiver. This method simplifies the process, as it doesn't require the prior approval step that safeTransferFrom requires.

The withdraw method's design is intentional, ensuring security with strict checks and clear event logging, embodying best practices for efficient and transparent transactions.

Real Use Case

Now that we have looked at each part of the process, let's explore a real-world implementation of an ERC-4626 vault. We'll be reviewing the AaveV3ERC4626Reinvestment contract, which is deployed on the Polygon network. Aave is a well-known DeFi lending platform.

Aave's implementation in this contract demonstrates the process of earning additional rewards through Aave's liquidity mining programs.

We'll highlight the differences in these implementations.

In Solidity, when a function inherited from a parent contract is customized, it uses the 'override' keyword to indicate that the function in the child contract is intended to override a function from the parent contract. While the deposit function remains unchanged in this contract, the afterDeposit method – the optional hook we briefly discussed earlier – is overridden.

afterDeposit

Let’s begin by reviewing how afterDeposit receives custom logic to enhance the functionality of this vault.

1. Approval and Asset Transfer: Before depositing assets into Aave, the function first ensures that the vault contract has permission to use the user's assets. It does this by calling the safeApprove method on the token contract (asset). This step is essential because it allows the vault contract to move the user's assets.

2. Deposit into Aave: Once the approval is in place, the function calls the supply method on the lendingPool contract. This action deposits the specified assets into Aave, making them available for lending and yield generation within the Aave protocol. The address(this) parameter designates the vault contract as the depositor, and 0 indicates no additional specific instruction for this deposit.

Withdraw

Alright, now let's review the withdraw function; this function is also overridden, and you can see it's implementing custom functionality.

1. Approval and Asset Transfer: In this step, the afterDeposit function begins by ensuring that the vault contract has the necessary permission to use the user's assets. This is achieved by invoking the safeApprove method on the token contract (referred to as asset). The purpose of this step is to authorize the vault contract to manage the user's assets securely.

2. Asset Redemption: Following the approval, the function proceeds to deposit the specified assets into the Aave protocol. This is accomplished by calling the supply method on the lendingPool contract. This action effectively moves the assets into Aave, where they can be utilized for lending and yield generation within the Aave ecosystem.

Thoughts

I’m extremely bullish on this standard. It represents a significant step forward in addressing the complexities and fragmentation we currently see in DeFi.

Here is why:

1. L2 Adoption: ERC-4626 simplifies integration with L2 networks, enhancing the DeFi experience for users.

2. Trust and Innovation: It fosters trust and encourages innovation within the DeFi community by establishing common standards for security and functionality.

3. Streamlined Development: ERC-4626 simplifies the development process, enhances security, and allows developers to focus on refining strategies and building better DeFi applications.

Now we have gained a clear understanding of what token vaults are, recognized the importance of standardization, and grasped how ERC-4626 significantly contributes to enhancing consistency and efficiency within the DeFi ecosystem.

If you're curious about the adoption of this standard, currently, there are over 100 vaults that are ERC-4626 compliant.

This week, I wanted to build a token transfer dapp to demonstrate how to send assets from a Layer 2 (L2) to a Layer 1 (L1). I would compare an optimistic rollup with a zero knowledge (ZK) rollup but, as I was thinking about it more, it dawned on me that I didn’t actually know how I would go about doing that.

Was it as simple as changing the RPC endpoints as when working with an optimistic rollup? Could I still write a contract in Solidity? And wtf is the zkEVM?

Twenty minutes later, I found myself in the ZK rabbit hole. I'm still in it, so this is going to be the first installment in a series on ZK rollup articles.

This guide is unfinished, so you might finish reading and think that we missed a lot of principles and concepts, and you would be right. The goal of this guide is not to be an encyclopedia of ZK rollups, but rather to serve as a stepping stone, capturing the essentials as I traverse the learning curve alongside you.

This series could include three articles, or possibly ten.

We’ll see how deep I dig.

In this first piece, we'll be getting our feet wet with ZK terminology, exploring ZK rollups, and delving into ZK proofs.

Terminology

Before getting into the weeds, let’s cover some basic ZK terms.

Zero Knowledge (ZK): In cryptography, it's a concept where one party can prove to another party that they know a specific piece of information without revealing what that information is.

Zero Knowledge Proof (ZK Proof): This is the actual output by which zero knowledge is conveyed—you might think of zero knowledge as the concept and the zero knowledge proof as the outcome of that concept.

Prover: This entity attempts to convince another entity that a particular statement is true. The prover can be an individual or a system.

Commitment: A cryptographic technique to securely 'seal' a secret, which, when 'unsealed', allows verification of the original secret without prior disclosure.

Witness: This is the confidential information that enables the prover to generate a proof about a statement without revealing the witness itself.

Real-World Example

Imagine Alex needs to apply for a loan. The bank must verify that Alex has a good credit score without actually seeing it. Here’s how it goes:

Prover (Alex): Alex needs to convince the bank that her credit score is good without disclosing the exact figure.

Witness: This is Alex's actual credit score—the secret information she doesn't want to disclose.

Zero Knowledge Proof: Alex uses the witness to create a ZK proof, essentially asserting, "I can confirm my credit score meets the required level, but I won't reveal the exact score." The ZK proof is reliable enough for the bank to trust without seeing the actual score.

Commitment: Alex applies a cryptographic method to "seal" her credit score, much like placing it in a tamper-proof envelope. The bank can't see the score but can use this 'envelope' to verify its validity later, if necessary.

Verifier (Bank): The bank needs to be sure Alex's score surpasses a specific threshold without knowing the precise score, just that it is above the minimum.

Alex provides the bank with a commitment, which the bank can check to confirm whether his score meets their standards. The bank doesn't need to see the score itself—just that it satisfies their criteria.

Congratulations, you've just grasped the basics of how ZK proofs function.

Introduction to ZK Rollups

Definition of a ZK Rollup

A ZK rollup is a kind of L2 scaling solution that builds upon a L1 blockchain, such as Ethereum. Its purpose is to reduce the computational workload on the L1, thereby lowering gas fees and making transactions cheaper by eliminating the processing step involved in executing smart contracts and ultimately posting them onto Mainnet (Ethereum).

How ZK Rollups Work

When a smart contract is deployed on a L2, it operates on a network that acts like a L1. This is where transactions are processed and the current state of the system is updated, all taking place off-chain.

After the transactions have been processed by the sequencer, the sequencer generates the blocks. Multiple blocks are consolidated and committed on L1.

Different L2s have slightly different capacities, so the volume of transactions will slightly vary.

Next, a prover is responsible for taking this collective data structure (the batch), and generates what's known as a validity proof, a type of ZK proof. A validity proof confirms that all the transactions within the batch have been computed accurately and are in agreement with the L1 blockchain's rules and consensus mechanism. This is often referred to as proving the behavior, ie that the code behaves exactly on the L2 as it would on L1.

You might be curious about the identity of the prover. Typically, the prover is a network of nodes that run ZK circuits. These circuits are tasked with generating the proof.

A couple of disclaimers about L2s:

• The granularity of proving can vary, meaning proofs might be generated per transaction or in batches.

• I'm outlining the overarching concept here.

• The prover network for each L2 solution may function differently.

The prover submits this proof to the L1. The L1, relying on the validity proof, doesn't have to check each transaction individually to confirm their integrity. It can promptly affirm and record the batch of transactions. This leads to what's known as immediate finality, where the transactions are considered finalized right away. Every L2 has a verifier smart contract deployed on L1. This smart contract verifies the validity proof. If the contract can verify the proof, the L1 can assume that the transaction are valid.

The main difference between ZK rollups and optimistic rollups lies in when the transactions are verified to be published on the L1. ZK rollups immediately include the transactions on the L1 upon submission because the L1 accepts the validity proof as assurance that the L2's ZK rollup can be trusted.

Optimistic rollups operate differently from ZK rollups; they don't offer a pre-verification proof. Instead, there's a waiting period—usually seven days—where trusted entities on the network can review the transaction. If they detect anything malicious, they have the opportunity to create and submit a fraud proof.

ZK Proofs

Circuits

Circuits are the foundational elements of ZK proofs. Essentially, ZK proofs are results from mathematical expressions that execute a computation. Inputs are used to feed data into these expressions, which then process the information according to a set of predefined rules or logic gates within the circuit, ultimately yielding an output that validates the correctness of the assertion without revealing the underlying data itself.

ZK proofs can be written as arithmetic or polynomial.

ZK Proof with Circuits Example

Situation: You wish to access the ski lift at a resort, but you want to prove you own a valid ski ticket without displaying the ticket or any personal information.

Inputs:

• A unique identifier for each ski ticket, like a digital barcode.

• A secure, cryptographic representation of the ticket holder's identity.

Circuit Functionality:

• The system verifies against a secure database that the unique identifier corresponds to a legitimate, unexpired ski ticket.

• It then confirms that the cryptographic representation matches the stored identity associated with that ski ticket.

• If both conditions are met, the system outputs a verification token indicating a valid ticket without revealing any identity details.

Proof Process:

Prover (Ski Ticket Holder):

• Generates a ZK Proof using their ticket's unique identifier and their cryptographic identity representation.

• Submits this proof to the verifier via a secure, anonymous verification system.

Verifier (Ski Lift Operator's System):

• Checks the proof without learning the ticket's details or the holder's identity.

• If the proof checks out, the lift system activates, allowing the holder to board the ski lift.

This mechanism ensures that the skier can access the ski lift with a valid ticket without ever revealing the ticket itself or any personal information, thus maintaining privacy and security.

Validity Proofs

To ensure a ZK rollup can successfully submit its batched transactions to L1, it must communicate that these transactions are legitimate. ZK rollups achieve this through the use of validity proofs, which are a form of ZK proofs.

Validity proofs are available in two flavors: zk-SNARKs and zk-STARKs.

SNARKs (Succinct Non-interactive Arguments of Knowledge): SNARKs are a type of ZK proof that is succinct (the proof size is small), non-interactive (it doesn't require active communication between the prover and verifier), and allows the prover to demonstrate knowledge of a secret without revealing it. SNARKs often rely on a setup phase that generates a common reference string (CRS) used by both the prover and the verifier. SNARKs can use both arithmetic and polynomial circuits.

STARKs (Scalable Transparent Arguments of Knowledge): STARKs are similar to SNARKs in that they provide ZK proofs without requiring interaction. However, they do not require a trusted setup (no CRS is needed) and are based on hash functions, making them post-quantum secure. STARKs utilize polynomial commitments and are transparent because they don't rely on any secret parameters.

Compatibility

EVM

The Ethereum Virtual Machine (EVM) is essentially the platform where smart contracts are executed on the Ethereum blockchain. Smart contracts are compiled into bytecode for the EVM to process, using basic instructions known as opcodes.

ZK proofs were not initially designed for compatibility with Ethereum. They originate in the field of cryptography, whereas Ethereum is part of the blockchain realm. Consequently, compatibility between ZK proofs and the EVM presents a significant challenge due to their complexities.

Zero Knowledge Ethereum Virtual Machine (zkEVM)

Ethereum, in its original form, doesn't inherently understand or validate ZK proofs. This incompatibility led to the development of the zkEVM . The zkEVM is an adapted virtual machine that's designed to interpret both the standard EVM opcodes and the specific requirements of ZK proofs.

The compatibility between the zkEVM and the standard EVM varies, and it can be considered a spectrum.

Beginning from the most compatible to the least, we will explore the current landscape, including the benefits and drawbacks of various approaches to integrating zkEVM with the standard EVM.

1. Full EVM Equivalence aims to recreate the entire Ethereum system, ensuring that everything from the high-level code to the low-level operations and the very structure of the machine is preserved.

2. Bytecode Equivalence focuses on the individual operations (opcodes) of the EVM but might allow some structural changes to the machine itself for efficiency

3. Language Equivalence aims to support Ethereum’s high-level language, Solidity or Vyper but recompiles contracts in the native VM language. The native VM language depends on the L2.

These levels of equivalence can be further broken down to highlight the specific ways they achieve compatibility with the EVM's operational framework.

• Type 1 (fully Ethereum-equivalent)

  • Benefit:

    • Perfect compatibility with Ethereum blocks

    • Ideal for rollups due to the ability to reuse a lot of Ethereum's infrastructure

  • Drawback:

    • Very long prover times since it replicates Ethereum exactly, which wasn't designed for ZK

• Type 2 (fully EVM-equivalent)

  • Benefit:

    • Perfect equivalence at the VM level allows existing applications to work seamlessly

    • Changes to data structures improve prover times compared to Type 1

  • Drawback:

    • Still has slower prover times due to inefficiencies inherent in the EVM that remain unaddressed

• Type 2.5 (EVM-equivalent, except for gas costs)

  • Benefit:

    • Improved prover times

    • Almost fully equivalent to EVM with slightly faster approval times

  • Drawback:

    • Potential reduction in developer tooling compatibility and the need to adjust some applications due to changed gas costs

    • Some precompiles are not supported

• Type 3 (almost EVM-equivalent)

  • Benefit:

    • Easier to build and faster prover times by removing features difficult to implement.

  • Drawback:

    • More incompatibility with existing applications, which may require re-writing to adjust to the removed features

• Type 4 (high-level-language equivalent)

  • Benefit:

    • High efficiency and faster prover times by redesigning from scratch with ZK proof friendliness in mind

    • Potential for greater scaling and lower costs due to optimized design

  • Drawback

    • Lower compatibility with the existing EVM infrastructure, requiring significant changes to existing applications

    • Developer experience may be impacted due to differences from the familiar EVM environment

Conclusion

We made it. By now, you've learned basic ZK terminology, the mechanics of ZK rollups, the different types of ZK proofs and the nuances of zkEVM with its compatibility quirks.

Hopefully by now you can explain what a ZK proof to someone like they’re 5.

If there’s something I didn’t cover that you’d like me to, or perhaps you’d like me to dig a little deeper, my DMs are always open.

Until next time!

Sources

https://vitalik.ca/general/2022/08/04/zkevm.html

https://ethereum.org/en/developers/docs/scaling/zk-rollups/#validity-proofs

https://hackmd.io/@yezhang/S1_KMMbGt#Why-possible-now

A few months ago, Vitalik published "The Three Transitions", which can be seen as a survival guide for Ethereum, focusing on scaling, security, privacy, and user experience. The crux of the narrative is that if Ethereum doesn't address its issues while enhancing user experience, its ngmi. In this article, we delve into Layer 2 solutions (L2s) which aim to remedy Ethereum's scaling dilemma, explaining not only how they work but also how they differ in terms of data availability, especially when contrasting Optimistic and Zero Knowledge Rollups. Additionally, we'll clarify why sidechains, although a type of scaling solution, are not categorized as L2s.

What’s the problem?

In 2021, Ethereum's scalability challenge hit the spotlight. With Ethereum’s price peaking at $4,864.06, the average gas fee soared to 173.89 gwei. Such high fees meant using the network became a luxury for many. Sometimes, the gas even exceeded the cost of the jpeg being minted—clearly unsustainable.

As Ethereum's popularity surged, so did its issues. Meeting the growing demands led to slower transactions and exorbitant gas fees. While Ethereum's decentralized foundation is its hallmark, it came at the expense of speed, leading to a traffic-jammed network. This puzzle, known as the blockchain trilemma, asserts a tricky proposition: a blockchain can't excel at scalability, decentralization, and security all at once.

Yet, there's a silver lining for Ethereum. On September 15, 2022, Ethereum made a significant shift to a more energy-efficient, proof-of-stake consensus—famously termed "the merge." This transition was monumental. Departing from the earlier proof-of-work mechanism, Ethereum slashed its energy use by a staggering 99%. A win not just for the platform, but for our planet. Fast forward to October 25, 2023, and the average gas fee stood at a much more reasonable 29.65 gwei.

Still, while it's a commendable leap forward, there's more ground to cover.

What are L2s?

An L2, or Layer 2, operates atop its foundational Layer 1 (L1) blockchain. It derives its security and data availability from this L1. The main mission of L2 is simple: ease the load on L1 during block creation.

By processing transactions off-chain, L2s help cut down the gas fees needed for operations on L1, all the while ensuring the data's integrity remains intact on L1.

Now, let’s talk about bridges. They're essential for enabling communication between different blockchains. Here's are a couple of bridges you should know:

1. Lock and mint: This method involves securing or freezing assets on the original chain, and then minting new, equivalent assets on the target chain. Think of it like wETH. These bridges transfer the value of the asset, not the asset itself.

2. Burn and mint: Here, assets from the starting chain are destroyed, and in their place, new, matching assets are created on the destination chain.

L2s rely on these bridges to shuffle data and assets between them.

How L2s work

Let’s break down the usual lifecycle of producing a block:

1. The transaction needs to be executed

2. The transaction needs to be processed

3. The transaction needs to be verified

4. The transaction needs to be published on-chain

The transaction is sent to the node operator, also known as a sequencer. This sequencer then executes, processes, and verifies the contract.

Upon verification, a rollup that bundles all transactions is created and published to the blockchain. This publication includes the new state root and calldata. Even though they aren't stored as part of Ethereum’s state, they remain on-chain in Ethereum’s historical logs.

However, not all rollups are created equal.

Rollups

Rollups are a crucial component of Layer 2 solutions. The two primary types are Optimistic and Zero Knowledge (zk) Rollups, each having unique approaches to data availability.

Rollups essentially bundle the transactions received by the sequencer. After verifying them, they batch everything into one transaction for submission to the L1.

Data availability pertains to the ease of accessing data. The trust placed in the Ethereum network’s decentralized ledger exceeds that in traditional banking systems. We have confidence that our data remains online, being permissionless and censorship-resistant. This foundational idea of data availability is adopted by L2s. It's an essential aspect of how L2s function.

For a new block to be created on the L1, Ethereum needs a way to ensure that the rollup it receives—this batch of bundled transactions—hasn't been maliciously altered.

There are two methods to achieve this.

Optimistic (trusted) rollups operate on a "trust, but verify" principle, echoing the sentiment of "innocent until proven guilty." Operators post data related to state updates on Ethereum, accompanied by the calldata and a fraud proof.

The exit strategy is such: a seven-day lock period follows before a block is finalized on the mainnet. This allows network participants the time to review and challenge any potential malicious activities by assessing the fraud proof. To put it in perspective, if you're transferring wETH from an L2 to a friend on the ETH network, your friend would need to wait 7 days for the transaction to settle.

One advantage of machines over humans is that we can program computers to be economically motivated to act correctly. Let me explain.

To manage transactions on an optimistic L2 network, nodes must post a bond. This financial commitment serves as a deterrent against any foul play, ensuring data reliability. For example, nodes can raise fault challenges if they believe the state root might be erroneous.

In such scenarios, transactions undergo partial execution on the L1 to compare state roots and calculate the fraud proof. If the proof holds, it indicates that the sequencer tried to introduce an inaccurate block.

Once this is established, the rollup re-executes. The sequencer or node found guilty of submitting the flawed block faces a penalty.

While optimistic rollups necessitate both data transaction and a fraud proof to be recorded on-chain.

Optimism, Base, and Arbitrum are notable examples of optimistic rollups.

ZK (trustless) rollups, in contrast, adhere to a "distrust until confirmed" principle, mirroring the notion of "guilty until proven innocent." These rollups enhance block publication speeds by conducting verifications prior to posting on Ethereum, making use of validity proofs.

Validity proofs function like a digital handshake. Their core purpose is to guarantee that only legitimate state changes occur on the network. Simply put, when a transaction is submitted, the network leverages cryptography to generate a proof confirming the transaction's validity without fully executing it.

By employing data compression techniques, zk-Rollups optimize on-chain data publication costs, thereby reducing fees for users. Transactions are batch-processed. A proving circuit runs through the batch, ensuring the sequence of updates and culminating in a definitive state root. Once verified, the L2 operator presents the calculated validity proof to the verifier contract on L1. If the pre-existing state root matches the root saved in the rollup contract and the proof is valid, the contract revises its state tree to reflect the rollup's modified state.

In practice, this means if you're transferring a confidential token between two participants, the legitimacy of the transaction can be confirmed without revealing specifics about the token.

To uphold the integrity of this cryptographic wonder, nodes engage in crafting these proofs, vouching for the authenticity of each transaction. If an anomaly arises, or if a rogue player tries any mischief, the proof will falter, and the transaction will be rejected.

As with optimistic rollups, incentives play a pivotal role here. To guarantee nodes act ethically and furnish accurate proofs, they're financially motivated. Any node producing an erroneous validity proof would incur penalties, ensuring they adhere to exemplary cryptographic standards.

While ZK rollups require these validity proofs, they bestow an additional perk of preserving data secrecy, truly embodying the "Zero-Knowledge" essence.

Some notable projects include zkSync, Aztec, Scroll, and zkEVM Polygon.

Tradeoffs

ZK-rollups deliver quicker transaction finality and trustless cryptographic security, but they necessitate specialized hardware for validity proofs. This could promote centralization and elevate expenses. Conversely, Optimistic rollups offer a smoother shift for Ethereum developers due to EVM compatibility and lean on fraud proofs for their security. This comes with the trade-off of postponed finality and potentially higher on-chain data expenses. The decision between the two might depend on a project's specific needs, like the urgency for instant finality, trustless security, or the simplicity of development and migration from Ethereum.

Sidechains

Sidechains operate independently alongside an L1, equipped with their distinct data availability and consensus mechanisms.

When a user executes a transaction on a sidechain, the transaction data remains on that sidechain. This contrasts with L2s, where the data is housed on the L1. As a result, the security level offered by Ethereum's network surpasses that of a sidechain.

Being entirely independent and parallel to an L1 means a sidechain has its unique consensus mechanisms, like Proof-of-authority and Delegated proof-of-stake. This autonomy provides sidechains a competitive edge over L2s. They can produce blocks at their chosen rate, uninfluenced by Ethereum's guidelines. Their flexibility in block size has contributed to their rising popularity.

However, this advantage carries a decentralization trade-off. To produce larger blocks more swiftly, greater computational power is essential. This translates to a need for pricier hardware to serve as a node operator, potentially limiting the pool of individuals who can operate a node.

Like other L2s, sidechains also interface with a layer 1 using a bridge, facilitating the transfer of asset values.

Conclusion

Ethereum's journey from grappling with scalability challenges to embracing energy-efficient consensus mechanisms underscores its evolving narrative. As we stand on the precipice of what many consider the 'broadband moment' for blockchain, Layer 2 solutions emerge as vital catalysts.

Through Optimistic rollups, Zero Knowledge rollups, or sidechains, we see glimpses of a future where transactional efficiency, decentralization, and user experience converge seamlessly. Each solution, with its distinct advantages and trade-offs, paints a vision of an optimized Ethereum ecosystem. Guided by cryptographic incentives, faster transaction times, and the quest for balance, these innovations collectively herald a transformative era for Ethereum, ensuring its continued relevance in the ever-evolving blockchain universe.

Resources:

• https://ethereum.org/en/developers/docs/scaling/zk-rollups/

• https://ethereum.org/en/developers/docs/scaling/optimistic-rollups/

• https://ethereum.org/en/developers/docs/scaling/sidechains/

• https://etherscan.io/chart/gasprice?output=csv

Know your memes:

• Gas Bad

• 58750000000000000000000

I’d like to begin by thanking Raza for pushing me to finish this post. I had decided to not post this due to my lack of understanding of some of the complex topics discussed in the original paper, so thank you for giving me the push I needed.

This had been written to the best of my understanding, so if anything is incorrect, kindly comment to not just educate me, but anyone who decides to read this.

If you haven’t already read the blog, you can reference it here.

Introduction

Father of Ethereum, Vitalik Buterin shared an inevitable roadmap for what Ethereum will need to undergo in order for it to be adopted by the masses. The Three Transitions, are references to the three technological changes that will need to be done in order for Ethereum to become scalable, secure, and private.

Why we need scalability, security, and privacy

Scalability

Scalability seems like a no-brainer, but if you’re new to Ethereum, let me explain wtf is gas and why scalability matters so much. If you were around during the last bull market when NFTs were all the rage, you could find yourself paying hundreds of dollars in gas just to mint a free NFT.

Por que?

Well, the way Ethereum works is like this: When you transact, ie, mint an NFT, transfer tokens, (think anything on-chain where a signature is required), work has to be done to be posted on the network. This work is paid in the way of gas. The higher demand on the network, the more gas will be required to complete the work.

The problem with this is that it's not scalable (lol). If we get our wish, and Ethereum is widely adopted, it won’t be accessible to everyone due to the cost just to interact with the network. Right now, Ethereum's mpg is like a 1990 Ford Bronco and we need mpg closer to a Toyota Prius. Regardless of what the cost of gas is, the amount of gas to take you to point A to point B (think transactions) will be too expensive for the typical user.

Security

For us, web3 natives, one of the major principles of blockchain is the sovereignty of having control over our assets. We understand the responsibility of having good key management practices and the differences between CeFi (Centralized Finance) and DeFi (decentralized finance) applications.

For the non-web3 native, they don’t, and those are the people we need to onboard for Ethereum’s success. Most people don’t trust themselves to hold and save a 24-word-seed phrase.

Hell, I even don’t trust myself to do that. I recently forgot the pin (because I never used it) to one of my wallets. Fortunately, I had imported accounts into it, so besides it being a major nuisance of digging up old private keys to re-do the whole process, it’s a shitty UX and I wouldn’t want to rely on tech like this to hold my life’s savings.

At this point in time, we still trust banks more than crypto wallets to secure our assets because, at the end of the day, there’s a safe proof way of accessing our funds. If I lose my seed phrase or private key, I am SOL. Unlike if I lose my bank cards, or forget passwords, worst case, I can always show up to a bank with a valid ID to prove I am who I am and get access to my accounts.

We need to be able to provide this level of security if we really want to replace our dependence on central banking.

Privacy

By default everything that is onchain is public for anyone to see. Sure you could whip up multiple anon addresses to transact with, but at the end of the day, you’re leaving a paper trail on the blockchain and with tools like AI, it probably wouldn’t take too long to connect the dots to find your transactions and link them to you.

Just as people prefer to make payments privately on Venmo, people want the same features onchain. However, this doesn’t just stop at payments.

One of the fun things about working in the web3 space is that at first glance, your identity is hidden. Between having a PFP that is a faux-crypto punk and a name like Vanes, most people don’t assume I’m a woman, and personally, I like it that way. I don’t correct those when they’re referencing me to bro, or man. I go with it (I have my own personal reasons, but we can save that for another post).

Having all your information on-chain is akin to driving with bumper stickers that publicly display everything you value, believe in, and support. Whether it's your NFTs, POAPs, or community affiliations, these identifying factors are like bumper stickers for everyone to see, reflecting aspects of who you are.

Maybe I don't want the world to instantly categorize me based on my personal choices or beliefs or identifying traits such as gender, race, and age. We're all prone to snap judgments when we see bumper stickers or symbols representing opinions we don't align with. It's human nature, and I've been guilty of it too.

Ethereum needs to take the default opt-in approach, or else it’s just ngmi.

The Domino Effect

These transitions come with three type of possible solutions that come with their own set of unique challenges:

Rollups solve the scaling problem.

Smart contract wallets solve the security problem.

Privacy-preserving fund transfers (partially) solve the privacy problem.

Let’s look at the proposed solutions and their challenges on a high level.

Rollups and Scalability

Rollups, also known as L2s, are the future. Let me try to explain what a rollup is. Earlier I explained how every time you interact with Ethereum (transaction), it needs to be posted to the blockchain. Now imagine that instead of each and every transaction getting posted right away to the network, you could put all these transactions into one notepad and once that notepad is full, it then gets posted to the network. That’s kind of how rollups work. Transactions get rolled into one and get posted once.

Back to our car and driving example, instead of having 5 cars on the road, you decide to carpool and now you have 5 people in each car, helping reduce traffic.

This is great, but because there are tons of different L2s, (Optimism, Arbitrum, zkSync, Scroll, etc) we now introduce a new problem: multiple addresses per user.

This leads us to our next problem, how do you figure out how to pay someone? With multiple accounts, the sender or receiver will need to be able to share what forms of payment they accept. It’s like going from using Visa everywhere (Ethereum), to now needing to have specific cards per merchant.

This is what a typical transaction object currently looks like:

{
  from: "0xEA674fdDe714fd979de3EdF0F56AA9716B898ec8",
  to: "0xac03bb73b6a9e108530aff4df5077c2b3d481e5a",
  gasLimit: "21000",
  maxFeePerGas: "300",
  maxPriorityFeePerGas: "10",
  nonce: "0",
  value: "10000000000"
}

Users will need more information than just to when completing transactions.

Key recovery will also get expensive because each account a user has will need to run a recovery process. Even though transacting on rollups will be less expensive than Ethereum, no one wants to pay fees for essentially resetting your password.

Smart Contract Wallets and Security

The TLDR about current wallet security really comes down to the fact that we, as humans, are prone to making mistakes and that includes forgetting our seed phrases and losing our private keys. There are two types of wallets, EOA (externally owned accounts), think MetaMask and Rainbow, and then there are smart contract wallets (Safe, Ambire).

The problem with smart contract wallets is that they also make it more difficult for users to have the same address for a few reasons:

1. Smart contract wallets, unlike externally owned accounts (EOAs) tied to a public key hash, introduce complexity due to varying code across networks, making consistent addresses harder to maintain

2. Smart contract wallets can have ownership changes through key modifications, which might lead to different addresses

3. Some Layer 2 technologies, like 'type 4 ZK-EVMs,' differ from Ethereum's main system (EVM). They may use unique languages, causing the same code to create different 'addresses' on various layers

This leads us to our next problem, onchain payments. Generally, transactions are sent with a gas limit of 21000 because generally there’s only so much data that comes with each transaction from an EOA. Smart contract wallets break this rule, so it will require wallets to adjust this limit. A referenced use case, such as NFT royalties, will also require that the receiver track when payments have been made from EOA and smart contract accounts because as it is, these types of marketplaces ban smart contract wallet owners.

Recovering keys from counterfactual addresses becomes even more complex! Counterfactual addressing refers to a concept where an address can be determined and known before the contract is actually deployed.

Wut?

Counterfactual addresses become useful in making transactions more efficient, flexible, and private, or in preparing for future actions without having to fully commit to them on the blockchain right away.

So, imagine, trying to recover a key from a contract address you don’t even have yet.

Internal Transfers and Privacy

We’ve touched on how L2s and smart contract wallets just make everything more complicated, well, now let’s add privacy to that mix, and let’s make it 100x more complicated.

Although having multiple accounts per user has been talked about as a bug (problem) for scaling and security, it’s actually a feature when it comes to privacy. The more accounts a user has, the higher likelihood that your degen transactions are likely to stay private (sort of).

Stealth addresses only make the multiple-address-per-user problem even worse because it’s a feature that allows a sender to create a unique, one-time address for every transaction on behalf of the recipient.

As it stands, there is no way to privately send someone funds in Ethereum. Contrary to popular belief (including mine), Tornado Cash doesn't allow users to send direct payments to each other; instead, a user sends and withdraws funds to and from a smart contract. Not exactly the same thing.

Lastly, key recovery is a complete nightmare. The perfect UX would be that with one click, you will be able to recover all of your accounts, but how can this be done in a way to preserve your identity? All the accounts would need to be linked, and this is exactly what we don’t want in a privacy-first world.

Conclusion

At the moment, Ethereum is a ship in the middle of the ocean carrying thousands and thousands of passengers and has to patch three parts of the ship, simultaneously, while trying to sail uninterrupted or else it will sink.

Needless to say, I’m skeptical whether or not Ethereum will actually be able to be successful in this. Not only will infrastructure need to change, but so will how applications interact with Ethereum.

However, considering how many developers and researchers are working in Ethereum, and the success of the merge, I lean in favor of the Ethereum community to “rise to the challenge” to solve these problems.

Final Thoughts

This article got me thinking: Why aren't we paying more attention to privacy-first L1s? Adding privacy to a network is complex, so why not build on networks like Namada and Aleo where privacy is treated as a first-class citizen?

Update: two weeks ago

This week started off rough. I had taken Friday off, and Monday was spent catching up on all the Slack threads, Discord, and Telegram messages. I was stressed out because it felt like the stack of requests was just increasing faster than I was finishing tasks. I decided to go for a walk, and while on the walk, I read that one of the engineers on the team had put together a really nice tech guide. My stomach started turning with slight panic.

Why did it take me so long to put together guides?

It took him just a couple of days. I paused. Let me give you some backstory.

When I was hired, I was the entire DevRel team. In the first six months, my responsibilities have included a variety of tasks like updating docs, creating technical guides, developing workshops, producing and editing YouTube tutorials, setting bounties, managing Discord, triaging GitHub issues, etc.

You get the idea. It probably goes without saying that it hasn't been easy. In fact, it's been a struggle. I'm doing it, but I'm not excelling at anything, and that's a disheartening feeling, especially when you're on a team with a bunch of rockstars.

Fast forward to the present day. There have been some team movements, some coming and some going, so since ETH Denver, the DevRel team is not just me. I have help. Two of our engineers, who I like to call Hybrid DevRels, officially hold engineering titles, but they're both DevRels at heart.

They're exceptional—almost too exceptional.

Here I am, overwhelmed (what's new), and my brain just goes into an autopilot self-destructive mode. I started thinking about how these guys have been on the team for a short time but have contributed more value than I felt like I had in the last six months. This went on for about five minutes before the tricks I have picked up from all the habit books I've read in my life helped me pull myself out of the mental grave I was digging.

I gave myself a mental slap across the face and shook myself a little bit.

I started thinking about how I shouldn't be trying to compete with them. There was no point in competing for a few reasons. One, they are already strong engineers. I knew I was capable of creating the technical guides they were, but it would just take me 2-3 times longer, and that was okay. Two, I needed to remember that I lead DevRel. I needed to think of the Hybrid DevRels as pieces of the overall DevRel puzzle to make it even stronger. Now that I had part of DevRel getting covered, I could focus my efforts on what I was good at, but what was that?

I sat on this question. While thinking about this, an ETHDenver memory came to mind. My team and I were wrapping up after a day at the conference. I mentioned going out after, and most of the team looked at me as if I were crazy to even suggest the idea of socializing with people after socializing with people all day.

I'm really good with people. I put this idea on a mental sticky note.

I looked at Telegram and the number of unread messages. I had messages dating back from October that I hadn't reviewed. If I'm going to lean into this people-person persona, then I probably should be better about getting back to people. One of the DevRels in the space who I look up to was so good about getting back. I remember thinking about how important that made me feel, and I wanted to make others feel important too.

I went through all my messages and left my inbox at zero. Something I learned about recently while taking some time off is—if you're in a conversation where the other party is waiting for your response, do one of two things. One, update my Telegram status to OOO so that people upfront know I'm not ignoring them, just offline. Two, if I'm in a scenario like the one above, I'm going to let people know I'll be OOO for a specific time just to set that expectation. After all, I would appreciate the same heads up.

This felt like I was moving in a positive direction. With my new DevRel Leader hat on, I decided I needed a plan. I needed goals, but not just goals; I also needed ways to measure those goals and determine whether I'm on track or not. Having absolutely no idea where to start, I headed to ChatGPT for some consulting. I got a pretty good outline of how to break up DevRel and examples of what would fall into these different categories.

I felt excited. I recalled a conversation I had with a team member in the first few months of joining. I was sharing my struggle of not knowing how or what to prioritize, and they told me to focus on where I could make the most impact. I realized how I had misunderstood this statement. Instead of focusing on what I could impact more, I thought of how DevRel could have the highest impact.

Let me explain how those are different. When I thought about how DevRel could have the biggest impact, my efforts went straight to the docs. I figured your dev experience really begins at the docs. Knowing from firsthand experience that our docs weren't exactly at the level of Vercel, I decided to pour myself into the docs. Writing good docs is hard. Weekly release updates on multiple products and platforms were daunting. While I was getting by with the docs, I wasn't excelling at this.

Thinking back at that question, I should have thought about where I could make the most impact. This question led me to dig deeper. Why did I want to work in web3? Why did I want to be a developer advocate? I wanted to be in the space for several reasons, including the passion I saw in others. This wasn't your typical Monday to Friday 9-5 schedule. People worked all the time because they genuinely loved what they were doing. Secondly, I loved how international web3 is. Unlike web2, where FAANG companies focused on where you went to college or leetcode, in web3, the barrier to entry isn't based on geography or accessibility to an expensive school; instead, it's all about the value you contribute to your community. It's beautiful.

Pinning those ideas, I started thinking about why I wanted to be a DevRel. I wanted to be a DevRel because I enjoy teaching and helping developers.

I decided to have an ad hoc meeting with one of the Hybrid engineers to see how I could be a better teammate. While explaining my recent epiphany about where I fit in the DevRel puzzle, I shared how I was feeling that he had done such a great job with content, I felt like I had no place there. He listened and apologized because he felt like he was overstepping. The day before, we had a DevRel meeting where he basically ran the show. He did it so well. I asked him how and where he learned to drive so well, and he shared his experience in marketing, community, and engineering over the span of six years. I've been engineering for two and doing DevRel for six months.

I often forget to keep my eyes on my own mat.

After we chatted, he suggested we meet later that week to brainstorm and talk through the new outline I had created. Leaving the huddle, I felt so lucky to work with such a kind human. I felt really fortunate to have a colleague with whom I could be vulnerable.

Update: It's Easter Sunday.

This past week felt like a lot of building blocks. I had to give hard feedback to a potential partner, create work boundaries, and explain to our founder and project manager why I no longer thought attending feature product meetings was a valuable way to spend my time.

I didn't exactly end the week strong. It was a short week (woohoo Easter), and towards the second half of the week, I woke up with a migraine. I hate those fuckers. My head feels like I mixed wine, beer, and gin together the night before, without any of the fun.

Love/Hate: my team works hard. Most of us are OOO for the holidays, but it's like Slack is still going crazy with updates. I get it. There is so much to do, so taking a day off feels crazy. I hate this because it feels like there is no turning off, but I love it because it's addicting to set challenging goals and accomplish them.

In that spirit, signing off here for some werk.

gm

Anyone who’s been on Twitter long enough has come across those influencer-type people shilling a protocol. They’re hosting Twitter spaces, leading workshops, and attending hackathons all over the world. Indeed, an extrovert's dream job. It was mine.

My name is Vanes. It’s pronounced ‘vuh-ness’ but if you prefer to call me veins, that’s cool too. Like most millennials, I have an unused undergraduate degree. I worked in corporate finance before attending a coding bootcamp which was how I got started in tech.

June 2021- I was about 9 months into my first dev job when I came across a JD for a developer advocate. The summary included things like, lead marketing campaigns, attend technical events, speak at events, and interact with developers. It seemed like the perfect job for someone with my skillset and interests.

May 2022 - I’m fully crypto-pilled and I’m starting to flirt with the idea of actually getting a job in web3. I thought about working as a front-end dev but didn’t think I had the technical skills to land a job. I figured I could try DevRel, after all, it seemed like it would be less technical than being a dev. Spoiler alert - it’s really not that much less technical.

ETH Global New York - June 2022 - I go to my first IRL web3 hackathon. It was crazy to observe how easily approachable and accessible everyone was. You had founders of these protocols sitting at their teams' booth handing out stickers and t-shirts. You really had no idea who you could be rubbing shoulders with. It also struck me just how international this industry was. Yeah, we were in New York, but hackers had come from all around the world to this event.

As the event was coming to its final days, I had absolutely made up my mind I no longer could stay at my web2 job. It’s impossible to go back to your web2 job after you experience an IRL web3 hackathon.

Some of my favorite people I met while in New York were either DevRels or aspiring DevRels. One of them being Steph. If you don’t know who she is, you should. She basically told me what I needed to do if I wanted to get a DevRel job in the space. TLDR: write a tutorial on the hackathon project you just built,  dm them, remind them about how you met at the hackathon, and let them know you’re interested in becoming their DevRel and share your blog. I loved the directness of this approach.

The recipe was well received. With that tutorial, and a few other pieces of content I had created, I dm’d the protocol I wanted to work at and after a few back and forths, I had an interview. Long story short, I didn’t pass the tech assessment. Lolz. I interviewed at a few more places but, truthfully I wasn’t excited about them. My web2 job had also become much more manageable because I was now working out of the Venice Beach office living in my van. I wasn’t in a rush to give up that setup unless a really cool opportunity came up.

ETH Mexico City - August 2022 - You could say going to hackathons can become a bit addictive. I spent my 20’s going to music festivals and taking drugs to stay up all night to dance with friends, and now, in my 30’s I was taking drugs to stay up all night and code with friends. One of my tasks in our hackathon team was to use WalletConenct for the wallet/dapp integration. I probably spent half an afternoon at their booth with questions because I just couldn’t seem to get their API to work. I felt so dumb that I couldn’t figure it out.

It’s finally Sunday and the hacking is over. We submit our projects and go on to demoing. Sleep-deprived and hungry, I’m kinda just nodding and smiling when I get asked if I was looking for a job. I thought he was just messing so, fucking around back, I nonchalantly say I’m looking for a DevRel job. We exchanged telegrams and I let jesus take the wheel.

Two weeks later, I accepted a position as a Senior Developer Advocate at WalletConnect. Lol - I know, I’m not a senior and they knew that too. It felt weird to have that be my official title, but they didn’t seem to care. It was just a title.

Today is March 24, 2023, and I’ve been working as a Developer Advocate for 6 months. Tbh, I thought by now I’d be killing it, but I’m not. Far from it actually.

Let me share my mental model with you. You’re either drowning, surviving, or thriving. I’ve mostly been drowning, but since ETH Denver, the mood has been shifting to surviving. I mean, it’s a good sign that I’ve finally made time to write this blog, am I right?

I’m also turning 31 today. Like most birthdays, the questions you receive are generally reflective ones like, What’s a goal you hope to accomplish this year? Normally I would answer with something like, “I want to actually be a morning person” or “I want to read 20 minutes every day” but it hit me. I need to iterate on these goals because every year I set them, but fail to actually do them.

I have a tendency to like to do hard things. Things that I may not even finish because I just like to see where “it” can take me. “It” can be anything, a course, a book, a workout plan, or a job. I’ve grown to enjoy the feeling of feeling uncomfortable (can you tell I listen to David Goggins), but even though these growing pains are familiar, it’s left me feeling like a huge impostor. I credit good timing and luck to a lot of my life’s accomplishments. Even getting this job, I was lucky to have won a scholarship to be at ETH Mexico City.

Working as a DevRel has provided me with some of the most remarkable experiences in my life. However, as with any aspect of life, there are also moments of balance, and while this career has given me some of the best experiences, it has also had its share of challenges, leaving me with some of my lowest moments. Negative self-talk can sometimes be the soundtrack to my day.

So for this year, I’m letting go of my self-doubt. How am I going to do this? I’m not totally sure, but for starters, I’m going to use this blog to share the wins and struggles of working as a web3 Developer Advocate.

I do have one ask of you. If you hear me shit-talking my tech skills, pls just tell me to stfu.

gn