I have been extremely busy over the past month. So busy that I couldn't even post on my blog. The main reason is that I had to grasp various aspects as I started working within the EigenLayer ecosystem. Before starting, I thought EigenLayer was just about re-staking staked Ethereum assets to create another ecosystem or that a new DeFi world would open up with a new type of LRT token. I think this is how most people understand EigenLayer. However, it had a more concrete direction than I expected, and although I'm not sure if it will work out, I realized that in some ways, this ecosystem is very necessary. Since I work in the EigenLayer market, my views might be biased, but I'll try to write as objectively as possible.

EigenLayer aims to be the AWS of Web3. Just as Amazon created a database and cloud services while building an online bookstore, Web3 also needs such systems. To explain further for those who haven't done development, you can create an app with your code and release it to the market. However, there are many things to consider before releasing it to the market. For example, if too many people flock to it, how will you scale your servers? How will you prevent hacking attempts? How will you manage your database and store large files? How will you handle hosting? The details can get very complex. That's why Amazon's AWS service helps by providing the necessary components through buttons, allowing your app to run smoothly. This way, developers don't need a wide range of knowledge; they just need to know the code for their app. As a result, AWS's market share is over 40%. Thus, app developers can say that they create their app's servers through the cloud service AWS.

EigenLayer aims to be the cloud service of Web3. The difference from Web2 is that it can be verified. The reason it can be verified is that in Web3, app/web servers are thought to run as rollups.

If we talk about the differences between Web2 and Web3, it would be too lengthy, so I'll mention just the two most important points:

The verifying entities are decentralized.

The easiest example is Ethereum. In the Ethereum network, validators verify the network. If someone misbehaves, they have to pay a penalty from their staked funds. There are over a million validators, and the number of Ethers they guarantee is 32 million. Because there are many assets and many validators in Ethereum, its level of trust is very high, and many rollup chains have emerged to use Ethereum's trust. A more intuitive example is a bridge. Currently, many bridges are centralized and can be insecure to use. If I transfer $100 through a bridge, it's not a huge amount, so I might not get scammed. But if I transfer a million or ten million dollars (about 13 billion KRW) through a bridge, would I feel secure? The reason for the distrust is that even if the entity behind the bridge misbehaves, it's hard to verify it, and the group that provides the trust is not decentralized but centralized to the individual or company that created the bridge. If the bridge system was guaranteed by a million validators and 32 million Ethers like Ethereum, wouldn't it be easy to transfer 13 billion KRW? Of course, the conditions are again twofold:

It must be possible to verify malicious actions against the bridge.

The verifiers confirming the malicious actions must be decentralized.

In this case, malicious validators would lose their funds and fail to steal, while the 13 billion KRW would be safely transferred by other verifiers.

Though this is an example, it raises an important question: How do we verify? In Ethereum, the rules for misbehavior are quite narrow: whether the node is online or offline, whether the transactions in the block are real or fake, whether simultaneous verification is attempted, and so on. These are "verifiable" within Ethereum. However, many things in the world cannot be verified within Ethereum. For instance, whether the price of certain tokens is accurate, whether a Korean soccer game was won or lost, or whether a player in a game is a bot or a human. These are verifiable outside the blockchain network, and EigenLayer aims to address this. This is related to the EigenLayer token, which I plan to discuss in more detail in the next post.

Currently, services like bridges and oracles exist independently using new chains, but EigenLayer plans to turn them into rollups to make them "verifiable." The verifiers would be decentralized, ensuring the accuracy of prices provided by the services and preventing theft of 13 billion KRW. These services (AVS) will become hundreds, like AWS, and instead of developing new services, bridges and oracles will pay to use them. The revenue generated by AVS goes to the verifiers, adding to the profits of re-staking. Services like bridges and oracles no longer need to build trust; they can focus on competing on innovation.

This is the skeletal structure of EigenLayer as I understand it. Although the structure of re-staking and the operations/AVS are complex, I don't think it's necessary to post about it separately. I plan to continue writing about EigenLayer from a user's perspective in the future.

The World EigenLayer is Trying to Create

It's been about a month since the launch of Blast L2. Despite often finding airdrops tedious and being hesitant to deposit assets into new L2 solutions, I immediately started using Blast, depositing assets and exploring its various applications. This decision was influenced by my previous positive impressions of Blur, created by the same team behind Blast. Having admired Blur's structure, I was curious about how Blast differed from other L2 solutions and what unique features it offered. Direct experience is often the only way to fully grasp such innovations.

The phrase "L2 competition" has been in use for years, and only now can we truly say we're in the era of L2 competition, with a plethora of L2 solutions emerging. However, it's challenging to distinguish unique features among them. Most L2 revenue structures are derived from sequencers, which earn a profit from the difference between L2 and L1 gas fees. The native tokens of these platforms derive their utility from this revenue model. With similar structures across the board, each L2 typically hosts a version of Uniswap or its forks, as well as Aave or Compound forks, serving as the main distinction. The transition from expensive L1 fees to cheaper L2 fees seems the only significant shift, as there would be little reason to move assets from L1 to L2 if L1 gas fees were lower. Surviving the L2 competition requires offering functionalities not available on L1, especially considering only a few out of the many L2 solutions will prevail.

This curiosity about how the Blast team would navigate these challenges led me to actively engage with their platform for a month, noting several positive and negative aspects. On the downside, Blast still exhibits a high degree of centralization, with many assets managed by a few multi-signature wallets and a 14-day withdrawal period. This was demonstrated when 57,000 ETH were recovered following a hack in the NFT game Munchables, by freezing the hacker's accounts. While the recovery was fortunate, it highlighted Blast's centralized aspects. Normally, L2 development progresses from centralization towards decentralization, suggesting this aspect should evolve swiftly.

On the positive side, Blast innovatively increases Ethereum and stablecoin holdings automatically. Specifically, converting Ethereum to stETH within Blast yields a 3-4% interest, with automatic rebalancing increasing the amount of Ethereum. Similarly, stablecoins leverage on-chain T-Bills by DaoMaker for rebalancing. This setup not only provides a 3-4% annual return without needing to convert ETH to stETH but also avoids opportunity costs when using DApps. Normally, liquidity provision or lending ETH doesn't inherently increase holdings, necessitating conversions to stETH. Blast's native rebalancing allows for liquidity provision while simultaneously earning a 3-4% return on ETH, a novel utility in the L2 space. Moreover, with no intention to profit from sequencers and exploring other business models, Blast maintains low gas fees. The platform might switch from stETH to other restaking tokens, potentially offering even higher rebalancing percentages.

It's too early to conclude whether Blast will dominate the competition or its usability is exceptionally high. The business model and token utility remain unclear, making it difficult to make a definitive judgment. However, just as Blur overtook OpenSea by introducing a completely different structure, Blast's unique structure and usability could mark a significant shift in the L2 landscape, a prospect I find very encouraging. Despite unmentioned pros and cons, I'm more than willing to continue exploring Blast for several more months.

 The significance of Blast in the Layer 2 space

Building and deploying smart contracts often involved using Truffle or Hardhat, but these days, it seems that using Foundry is becoming more popular. Therefore, even for those who have never deployed a smart contract to the blockchain, I'll explain in a simple way how to do it using Foundry. You can install Foundry for Mac and deploy smart contracts, and it seems like a similar process would work for Windows as well.

Once installed, you can run foundryup. However, if you encounter an error like 'zsh: command not found: foundryup,' you can fix it as mentioned above. In my case, I ran 

 and then I was able to execute foundryup.



After running foundryup and installing Foundry, you can check the version by executing 

Now that Forge is installed, let's create a new project.



 followed by any project name of your choice.


If you open this project created as a folder in VSCode,


You can see it created like this. Let's deploy the already created Counter.sol to Polygon Mumbai. Create a .env file in the folder.


RPC_URL=https://polygon-mumbai-pokt.nodies.app and PRIVATE_KEY=""

You can obtain the private key from MetaMask. 

If you don't have Mumbai tokens, you can get them from https://mumbaifaucet.com/.

Add RPC_URL and PRIVATE_KEY to the .env file, and then open the terminal in VSCode.



Then, you can retrieve the RPC_URL value that was previously entered in the .env file.

Now, the only thing left to do is to deploy Counter.sol

The deployment is now complete. You can see the deployed contract by entering the 'Deployed to' address on MumbaiScan. Visit MumbaiScan at 

Image source: Generated through OpenAI's DALL·E.

How to Deploy Smart Contracts Using Foundry

More Articles

The World EigenLayer is Trying to Create

The significance of Blast in the Layer 2 space