지난 2년, 국내 Web3 개발자 커리어의 시작점은 대부분(아마 70% 이상은) GameFi였을 것입니다. 저 역시 2023년 P2E 내러티브가 뜨겁게 타오를 때 이 시장에 뛰어들었고, 최근 그 흐름이 텔레그램 미니앱이나 리워드 앱 형태로 옮겨가는 과정까지 최전선에서 목격했습니다.

아실분들은 아시겠지만, 저는 최근에 곰블에서부터 새로운 팀으로 이직한 상태입니다. 이번 이직에서 제가 결심했던 것 중 하나는 "이번엔 블록체인 게임 프로젝트로는 가지말자!" 였었습니다.

시장이 식어서라기보다는 제가 경험한 구조적 한계와, 그 안에서 느꼈던 개발자 혹은 직원로서의 갈증이 주요 원인인데요. 2025년을 마무리하면서 제가 GameFi를 떠나게 된 이유와, 그럼에도 불구하고 기대하는 이 시장의 미래를 회고해 봅니다.

1. '게임'과 '금융' 사이의 위태로운 줄타기

대다수의 프로젝트에서 블록체인 기반의 게임 제작이 어려운 이유는 '게임(재미)'과 '금융(수익)'이라는 상충되는 두 가치를 동시에 잡아야 하기 때문입니다.

• 게임의 본질
  유저의 몰입과 체류를 만드는데에 집중해야 합니다. 긴 시간 플레이해도 매번 다른 경험을 제공하며 밸런스를 맞춥니다. 일일 보상이나 패스를 판매해서 돈과 시간을 최대한 많이 들이도록 유도합니다.

• GameFi의 현실
  크립토 네이티브는 "이걸 얼마나 하면 원금 회수(ROI)가 되는가?"를 먼저 봅니다. 돈이 될거 같으면 빨리 스코어를 달성하고 다계정을 하고, 레퍼럴을 유도하고 싶어합니다.

크립토 유저들은 게임 자체보다 Backer(투자사)가 누구인지, 예상 시가총액은 얼마이고 상장에서 얼마나 먹여줄건지, 어떤 KOL이 불리쉬(Bullish)하는지를 더 중요하게 여깁니다.

이 지점에서 GameFi는 크립토 네이티브와 일반 리테일 유저 모두를 놓칩니다.

• 크립토 유저
  가령 요즘 국내에서 많이들 하시는 Perp-Dex를 예로 들면 주간 거래량을 채우거나(= 여러 거래소에서 봇으로 양빵을 잡기) 수수료만 녹이면 되는데, GameFi는 불확실한 에어드랍을 위해 몇 시간씩 붙잡고 단순 노동을 해야 하니 비효율적입니다.

• 일반 유저
  '재미'를 기대하고 왔다가, "OO 파쿠리 게임" 혹은 "XX 하위 호환" 과 같은 조약한 퀄리티와 화면을 가득 채운 레퍼럴(Referral) 대시보드에 질려 떠나갑니다. 이건 Web2의 큰 IP를 기반으로 서비스 하려는 시도들에도 마찬가지입니다.

2. VC의 압박

프로젝트 내부 사정은 더 복잡합니다. 아무리 좋은 Backer가 있어도, VC들은 '트렌드'와 '회수'를 강요합니다.

투자사들은 끊임없이 최신 유행을 요구합니다. 과거엔 P2E였고, 최근엔 ERC-402, Eliza 같은 AI Agent, 혹은 특정 체인으로의 마이그레이션이 그 대상입니다. 개발팀은 기존 인력으로 이를 급하게 소화해야 합니다.

이런 요구사항을 맞춰 프로덕트가 시장에 나올 즈음이면, 이미 수많은 경쟁자가 파이를 나눠 가진 뒤입니다. 결국 수익 창출은 어렵고 프로젝트는 폐기됩니다. 이 과정에서 게임의 형태도 변질되었습니다.

2-1. 점점 가벼워지는 게임과 기반 기술들

• 과거: Unity/Unreal 기반의 고퀄리티 PC 클라이언트 게임

• 현재: 텔레그램/라인 미니앱, 혹은 웹 기반의 '딸깍' 도박장 (Clicker)

이제는 엔진을 다루는 기술보다, DOM 기반의 클릭커 류 게임을 빠르게 찍어내는 능력이 더 요구되는 것이 현실입니다.

3. 직원으로써도 성장하지 못하는 반복 작업들 (개발자 시점)

직원, 특히 개발자 입장에서 GameFi는 '무한한 택갈이(Reskinning)의 굴레'처럼 느껴지기도 합니다.

1. NFT 유틸리티 연결

2. 리더보드 및 보상 분배

3. Off-chain 포인트의 On-chain 환전(Redeem)

4. 오라클 RNG를 활용한 가챠/카지노 로직

5. Daily 퀘스트 및 출석 체크

지난 3년간 저는 이 로직들을 수없이 반복해서 짰습니다.
이 지점에서 주변 동료들이 많이 힘들어하는 걸 봤습니다. 기본적으로 Web3로 온 개발자들이 계속 Web3 시장에 체류하는 경우가 드물기 때문입니다. 같은 연차에서 고민하는 영역과 너무 다른 고민들과 점점 벌어지는 도메인 지식에서 많은 불안함을 느낍니다.

제가 GameFi를 떠난 가장 큰 이유는 시야의 확장을 위해서입니다. 계속 만들어왔던 "그 기능들"(리더보드를 만들고 토큰을 정산해 주는 역할)을 넘어, "이 프로덕트가 왜 필요한가?", "어떤 문제를 해결하는가?"라는 본질적인 고민을 하고 싶었습니다. 같은 기능을 만들어도 더 넓은 시장에서, 실제 유저의 삶에 임팩트를 주는 서비스를 만들고 싶다는 갈망이 저를 새로운 도전으로 이끌었습니다.

4. 그럼에도 불구하고, GameFi의 미래는 있다

비록 저는 떠나지만, 이 산업이 가치 없다고 생각하지는 않습니다. 오히려 GameFi는 '가장 강력한 Web3 튜토리얼'이 될 잠재력이 있습니다.

미래의 GameFi는 국내보단 해외에서, 그리고 투기보다는 '교육과 경험'의 측면에서 빛을 발할 것이라 생각합니다. "NFT 가격이 90% 폭락했다"는 뉴스보다, 게임을 통해 "NFT가 내 아이템을 소유하게 해 주는구나"라는 효능감을 직관적으로 느끼게 해 줄 수 있는 건 여전히 게임뿐이기 때문입니다.

금융의 껍데기를 쓴 게임이 아니라, 블록체인의 복잡성을 숨기고 '실력 기반 보상'과 '진정한 소유권'을 가르쳐주는 웰메이드 프로젝트들이 이 시장의 다음 챕터를 열어주길 기대합니다.

이 글은 작성자의 기본적인 초안을 바탕으로 Gemini 3.0의 도움을 받아 작성되었음을 알립니다.

I’ve been developing DApps for about 3 years now. As of this writing (2025.10.01), a service called Legion and its YieldBasis deposit feature has been quite popular in Korean TG chats. The patterns of depositing stablecoins and yield farming are consistent with the recent low-risk DeFi trend that Vitalik often talks about, so I think it’s an interesting field to explore.

At the launch of most TGE sites or deposit services that attract a lot of attention, the sites are usually unstable. Legion is no exception. One user said they clicked for 1 hour and 40 minutes but still couldn’t even trigger the approve() function.

It’s easy to assume that the main resource of a DApp team is smart contract development, so problems like this must be chain-related. But in most cases, it’s actually a front-end RPC request optimization issue.

So, I’ll share some tips on how to make your service more reliable during traffic spikes (temporary surges in transactions or view requests). – There’s also a Wagmi-based code snippet included!

The Nightmare of Zero Day

Let’s talk about the Broken RPC situation, which most builders and users have probably experienced.

• 100K+ people flooding in within 10 minutes

• Everyone pressing the same button (“Mint”, “Buy”, “Claim”, “Deposit”)

• Multiple functions on the page trying to read variables from the contract

In these situations, the root cause is often frontend and RPC management, not the blockchain itself. Here are some common workarounds:

• Quickly spin up a private node (Infura, QuickNode, Alchemy) and replace your RPC.
  (But the 100M request cap can be filled in just 3 hours.)

• After an announcement (ANN), deploy optimizations as fast as possible.

• Even then, if you rely only on frontend cache invalidation, users won’t see fixes unless they refresh, so the damage may already be done.

Checklist: Check your stability

Here’s a checklist you can follow on the frontend side:

1. ✅ RPC Fallback

   Do you have a backup RPC to switch to when the main one fails?
   If an RPC breaks and keeps throwing errors without responding, your code should automatically fall back to another RPC.

   ✅ Frontend Caching

   Most Wagmi hooks use @tanstack/react-query for caching by default.
   By caching view function requests, you can reduce the risk of hitting RPC rate limits.

   ✅ Multicall

   If you’re calling multiple view functions from the same contract, bundle them into a single multicall() request. This reduces traffic and avoids rate limits.

   ✅ SSR Caching (if using SSR)

   If you’re regenerating pages from the server every time without caching, it can slow things down significantly. Regional caching of SSR responses improves load times.

   ✅ Pre-warm and Test

   Use load testing tools (e.g. k6, Artillery) before launch to simulate traffic spikes.

   (Off the record: I used to monitor service communities like Discord during zero-day launches. The result? Every post spammed with the 🚨SCAM emoji and the CEO raging. Not an experience I want to repeat.)

Example1: Fallback RPCs

Simple Shuffle your RPCs

Here’s a simple way to shuffle RPCs and create a fallback setup with Wagmi:

// the target chain: binance smart chain
import { bsc } from 'wagmi/chains';
import { createConfig } from 'wagmi';

export const SUPPORTED_CHAIN = bsc;

const PUBLIC_RPC = [
  '<https://bsc-dataseed3.binance.org>',
  '<https://bsc-dataseed4.binance.org>',
  '<https://bsc-dataseed1.defibit.io>',
  '<https://bsc-dataseed2.defibit.io>',
  '<https://bsc-dataseed3.defibit.io>',
  '<https://bsc-dataseed4.defibit.io>',
  '<https://bsc-dataseed1.ninicoin.io>',
  '<https://bsc-dataseed2.ninicoin.io>',
  '<https://bsc-dataseed3.ninicoin.io>',
  '<https://bsc-dataseed4.ninicoin.io>',
];

function shuffleRPCList() {
  const shuffledList = [...PUBLIC_RPC];
  for (let i = shuffledList.length - 1; i > 0; i--) {
    const j = Math.floor(Math.random() * (i + 1));
    [shuffledList[i], shuffledList[j]] = [shuffledList[j], shuffledList[i]]
  }

  return shuffledList
}

const createFallbackTransport = (timeout = 7000) => {
  const transports = shuffleRPCList().map((url) => http(url, { timeout }))

  return fallback(transports, {
    retryCount: PUBLIC_RPC.length,
    rank: false,
  })
};

export const config = createConfig({
  chains: [SUPPORT_CHAIN],
  transports: { [bsc.id]: createFallbackTransport() },
});

👉 fallback() (provided by Viem) retries failed RPCs according to retryCount, and you can decide whether to rank them or call sequentially.

(Good to know) How to check your blockchain stability

As some of you may know, there is a website with a great utility called CoinTool.

You can use it to get an idea of whether our service's network will suddenly spike in gas prices, or whether it will provide relatively stable traffic.

For example, my example BSC employs Proof of Staked Authority (PoSA), so it has a high TPS, and the gas fee is always fixed at 1 Gwei, so you can see that it's not going to be unexpected!

If Binanace Alpha is confirmed at TGE, there's no problem with the above code because the BSC chain uses BEP-20.

On the other hand, let's look at the Linea chain I built in the past.

Linea has been relatively stable in the recent past, but gas prices tend to spike at certain times. If your recent history is choppy, you might want to consider more RPC-optimized logic.

Example2: Multicall in Wagmi

All RPCs support multicall. With Wagmi, you can easily batch view functions.

Here’s my useBalance hook:

// /src/service/useBalance.ts

import { useReadContracts } from 'wagmi'
import { erc20Abi, Address } from 'viem'

export function useBalance(tokenAddress: Address, walletAddress: Address) {
  const { data, isLoading, isError } = useReadContracts({
    contracts: [
      {
        address: tokenAddress,
        abi: erc20Abi,
        functionName: 'balanceOf',
        args: [walletAddress],
      },
      {
        address: tokenAddress,
        abi: erc20Abi,
        functionName: 'symbol',
      },
      {
        address: tokenAddress,
        abi: erc20Abi,
        functionName: 'decimals',
      },
    ],
    query: {
      enabled: !!tokenAddress && !!walletAddress,
    },
  })

  if (!data) return { data: null, isLoading, isError }

  const [balanceResult, symbolResult, decimalsResult] = data

  const balanceBigInt = balanceResult?.result as bigint
  const symbol = symbolResult?.result as string
  const decimals = Number(decimalsResult?.result ?? 18)

  const formatted =
    balanceBigInt !== undefined
      ? (Number(balanceBigInt) / Math.pow(10, decimals)).toLocaleString('en-US', {
          minimumFractionDigits: 2,
          maximumFractionDigits: 4,
        })
      : '0.00'

  return {
    data: {
      value: balanceBigInt,
      formatted,
      symbol,
      decimals,
    },
    isLoading,
    isError,
  }
}

Instead of making 3 separate calls for balanceOf, symbol, and decimals, this approach batches them into one request. This is especially useful in DeFi apps where polling is frequent (e.g., price quotes every second).

Wrapping Up

So you can see why most TGE sites (or service launches) feel like bullshit.

In Web2, load balancers can reliably handle massive traffic. In Web3, there’s an extra layer of blockchain RPC bottlenecks, so you need distributed RPC strategies.

As frontend developers, we don’t design tokenomics, but we do need to ensure that when a user presses “Claim,” it works reliably—even during a traffic surge.

I learned these lessons through painful trial and error. Hopefully, with this checklist, you won’t end up launching another “broken” DApp.

Thanks for reading. If you enjoyed this, stay tuned for the next post:
“Why Do We Keep Seeing 429 Errors? (A Crash Course on RPC Communication)” — where we’ll dive deeper into RPC.

Why Do We Need Auto-Trading?

The crypto industry recently experienced an incredible bull market. Bitcoin has been holding steady at $100k for several days, and with policies from the Trump administration, the outlook for the coming months seems even more optimistic.

So, did I make money during this boom? Unfortunately, no. Despite having plenty of time on my hands, I found it overwhelming to keep up with the flood of information from Twitter and Telegram. While I attempted to consolidate information and pick a few promising assets, I lacked the confidence to hold them long-term without solid justification.

Most centralized exchanges (CEXs) provide auto-trading functionalities. However, in my personal experience, these features seem designed to split pooled USDT or KRW into small chunks, maximizing fees for the platform. While the AI behind these features is undoubtedly more mathematically adept than I am and does yield profits, it’s disheartening to see a 50% profit potential reduced to 40% or even 30%.

This is why I propose an auto-trading system based on various technical indicators, with decision-making delegated to ChatGPT. Such a system could strike a balance between optimizing profits and providing a transparent rationale for its actions.

The indicators I’ve selected for this project include:

• Latest Google-Scraped News: While Twitter scraping is too costly, news headlines can still provide valuable sentiment insights.

• Fear and Greed Index: A classic gauge of market sentiment.

• OHLCV Indicators: Metrics like moving averages (MA), relative strength index (RSI), stochastic oscillator, MACD, and Bollinger Bands.

• Candlestick Data: 30 days of daily candlesticks and 24 hours of minute-level candlesticks.

These indicators form the backbone of the trading logic, and I plan to create scripts that feed this data into GPT for decision-making. While there are likely better indicators out there, these provide a solid starting point.

For this sample application, I decided to use Bithumb’s open API, as it is a prominent exchange in South Korea. While I considered decentralized exchanges (DEXs), the high gas fees on recent blockchain networks discouraged me from pursuing that route. Moreover, for automated trading and selling scripts, the APIs provided by CEXs are much more straightforward to work with.

The primary Bithumb API endpoints I plan to use are:

• [GET] /v1/accounts: To retrieve account information.

• [GET] /v1/ticker: For real-time price data.

• [POST] /v1/orders: To place buy or sell orders.

• [GET] /v1/orderbook: To access market depth information.

One thing to note: the popular CEX interface npm package ccxt has an outdated implementation for Bithumb. Since it is incompatible with the Bithumb API 2.0, I had to create a custom interface for connecting to the exchange.

Before using OpenAI’s chat.completion feature, you need to set up billing. OpenAI’s API requires you to create a project, generate an API key, and make a minimum payment of $10 to activate API usage.

Additionally, for news scraping, I used the SERP API, which provides 100 free API calls during the first month after registration. This makes it the most cost-effective choice for scraping Google News headlines.

• Stack: Node.js with TypeScript.

• Infrastructure: AWS EC2 for background running, with PM2 for process management.

The key part of this system is getting mathematical indicatiors from orderbook. I attatch my code snippet for everyone.

Here’s a brief explanation of the key indicators used:

• SMA 10 (Simple Moving Average): A simple average of the closing prices over the last 10 periods. It helps smooth out price action.

• EMA 10 (Exponential Moving Average): Similar to SMA but gives more weight to recent prices, making it more responsive to new information.

• RSI 14 (Relative Strength Index): A momentum oscillator that measures the speed and change of price movements over 14 periods. Values above 70 indicate overbought conditions, while values below 30 suggest oversold conditions.

• Stochastic K and D: These indicators measure the closing price relative to a price range over a set period.

  • Stochastic K (%K): Reflects the current closing price as a percentage of the high-low range over a specific period.

  • Stochastic D (%D): A smoothed version of %K, usually a 3-period moving average of %K.

• MACD (Moving Average Convergence Divergence): A trend-following momentum indicator that shows the relationship between two moving averages of a security’s price (typically 12-day EMA and 26-day EMA).

• Bollinger Bands: A volatility indicator consisting of three lines:

  • Middle Band: The 20-period simple moving average (SMA) of closing prices.

  • Upper Band: Two standard deviations above the middle band.

  • Lower Band: Two standard deviations below the middle band.

import {
  BollingerBands,
  EMA,
  MACD,
  RSI,
  SMA,
  Stochastic,
} from "technicalindicators";

function addTradingIndicator(data: CEX.OHLCV[]) {
	const closePrices = data.map((row) => row.close);
    const highPrices = data.map((row) => row.high);
    const lowPrices = data.map((row) => row.low);

    // Moving Averages
    const SMA_10 = SMA.calculate({ period: 10, values: closePrices });
    const EMA_10 = EMA.calculate({ period: 10, values: closePrices });

    // RSI
    const RSI_14 = RSI.calculate({ period: 14, values: closePrices });

    // Stochastic Oscillator
    const stochastic = Stochastic.calculate({
      high: highPrices,
      low: lowPrices,
      close: closePrices,
      period: 14,
      signalPeriod: 3,
    });

    // MACD
    const macd = MACD.calculate({
      values: closePrices,
      fastPeriod: 12,
      slowPeriod: 26,
      signalPeriod: 9,
      SimpleMAOscillator: false,
      SimpleMASignal: false,
    });

    // Bollinger Bands
    const bollingerBands = BollingerBands.calculate({
      period: 20,
      values: closePrices,
      stdDev: 2,
    });

    return data.map((row, i) => ({
      ...row,
      SMA_10: SMA_10[i] || null,
      EMA_10: EMA_10[i] || null,
      RSI_14: RSI_14[i] || null,
      Stochastic_K: stochastic[i]?.k || null,
      Stochastic_D: stochastic[i]?.d || null,
      MACD: macd[i]?.MACD || null,
      Signal_Line: macd[i]?.signal || null,
      MACD_Histogram: macd[i]?.histogram || null,
      Middle_Band: bollingerBands[i]?.middle || null,
      Upper_Band: bollingerBands[i]?.upper || null,
      Lower_Band: bollingerBands[i]?.lower || null,
    }));
}

After implenmenting calculations for OHLCV-based metrics and upper indicators, we need to analyze with Open AI's API. I constructed prompts that provide GPT with structured data and request trading recommendations.

askToGPT({
    recentNews,
    technicalAnalysis,
    lastDecisions,
    fnbIndex,
    myAccountStatus,
  }: {
    recentNews: string;
    technicalAnalysis: string;
    lastDecisions: string;
    fnbIndex: string;
    myAccountStatus: string;
  }) {
    const instructions = this.getInstructions();

    if (!instructions) {
      console.log("No instruction found");
      return;
    }

    try {
      const client = new OpenAI({
        apiKey: process.env.OPENAI_API_KEY,
      });
      const response = await client.chat.completions.create({
        model: "gpt-4o",
        messages: [
          { role: "system", content: instructions },
          { role: "user", content: recentNews },
          { role: "user", content: technicalAnalysis },
          { role: "user", content: lastDecisions },
          { role: "user", content: fnbIndex },
          { role: "user", content: myAccountStatus },
        ],
        response_format: { type: "json_object" },
      });
      return response.choices[0].message.content;
    } catch (error) {
		//...
    }
  }

Be aware of the response should be always structured json type. In my case, The response scripts are like this.

{
  "decision": "hold" | "buy" | "sell",
  "volume": number,
  "reason": string, 
}

With the trading logic finalized, I automated order placements via Bithumb's API.

async function buy(percentage: number) {
    try {
      const balances = await this.getBalance("sol");
      const tradePrice = await this.getCurrentPrice("SOL");
      if (!balances.krw.free || balances.krw.free <= 5000) {
        throw new Error("Not enough KRW");
      }

      const volume = (
        (balances.krw.free * (percentage / 100)) /
        tradePrice
      ).toFixed(4);
      const body = {
        market: "KRW-SOL",
        side: "bid",
        volume: volume,
        price: String(tradePrice),
        ord_type: "limit",
      };

      const query = querystring.encode(body);
      const hash = crypto.createHash("SHA512");
      const queryHash = hash.update(query, "utf-8").digest("hex");
      const payload = {
        access_key: config.bithumb.apiKey,
        nonce: uuidv4(),
        timestamp: Date.now(),
        query_hash: queryHash,
        query_hash_alg: "SHA512",
      };
      const token = jwt.sign(payload, config.bithumb.secretKey);

      const order = await bithumbClient.post("/v1/orders", body, {
        headers: {
          "Content-Type": "application/json",
          Authorization: `Bearer ${token}`,
        },
      });

      return order;
    } catch (error) {
      if (isAxiosError(error)) {
        throw { code: error.status, message: error.message };
      }
      throw error;
    }
  }

  async sell(percentage: number) {
    try {
      const balances = await this.getBalance("sol");
      const tradePrice = await this.getCurrentPrice("SOL");
      if (!balances.target.free) {
        throw new Error("Not enough SOL");
      }

      const amount = balances.target.free * (percentage / 100);
      if (tradePrice! * amount < 5000) {
        throw new Error("Less than minimum order volume");
      }

      const body = {
        market: "KRW-SOL",
        side: "ask",
        volume: String(amount),
        price: String(tradePrice),
        ord_type: "limit",
      };

      const query = new URLSearchParams(body).toString();
      const hash = crypto.createHash("SHA512");
      const queryHash = hash.update(query, "utf-8").digest("hex");
      const payload = {
        access_key: config.bithumb.apiKey,
        nonce: uuidv4(),
        timestamp: Date.now(),
        query_hash: queryHash,
        query_hash_alg: "SHA512",
      };
      const token = jwt.sign(payload, config.bithumb.secretKey);

      console.log(body);

      const order = await bithumbClient.post("/v1/orders", body, {
        headers: {
          "Content-Type": "application/json",
          Authorization: `Bearer ${token}`,
        },
      });
      return order;
    } catch (error) {
      if (isAxiosError(error)) {
        throw { code: error.status, message: error.message };
      }
      throw error;
    }
  }

The auto-trading system demonstrates a promising approach for retail investors overwhelmed by information overload and skeptical of generic CEX auto-trade functionalities. By integrating technical indicators with GPT’s advanced reasoning capabilities, the system strikes a balance between sophistication and simplicity.

• Improved Data Sources: Incorporating more granular sentiment analysis from platforms like Reddit or Twitter (if cost-effective).

• Advanced Trading Logic: Exploring reinforcement learning models that adapt over time.

• Multi-Exchange Support: Extending the system to operate across multiple exchanges for arbitrage opportunities.

• Perptual Futures Trading Support: Exploring futures trading to achieve more effective profit potential.

The journey to building a robust auto-trading system is ongoing, but the foundation is set. This project highlights how modern AI tools can empower individuals to navigate complex markets with confidence.

So, that is reason why I started Ethereum Development Bootcamp.

Ethereum, a smart contract platform for decentralized applications, relies heavily on encryption and signing mechanisms for its security and integrity. In this blog post, we will summarize the basics of Ethereum’s encryption and signing based on Alchemy's Week 1 lecture.

The output of a hash function is always of vert specific size. For example, in Ethereum, the SHA-256 algorithm generates a 256-bit (32-byte) hash, regardless of whether the input is a short string or a large file.

• Deterministic : it will always produce the same output. This ensures consistency, allowing systems to verify data by comparing hash values.

• pseudorandom : A small change in the input should result in a significantly different hash output. This is known as the avalanche effect.

• one-way: difficult to trace the original by comparing only the hash results

• fast to compute: Designed to be fast and efficient to compute, even for large amounts of data

• collision-resistant: Makes it extremely difficult to find two different inputs that produce the same hash output

• Commitments (Protocol & smart contract)

• Proof of Work

A single key for both encryption and decryption. Both the sender and receiver must have access to the same secret key. Follow the example below:

• Secret key: 324

• Plain text: Cat

• Cipher text: Fcx (C + 3: F, a + 2: C, t + 4: x)

• Example: AES (Advanced Encryption Standard)

Uses two different keys: a public key and a private key. The public key is used for encryption, while the private key is used for decryption. This can be using like below:

• Authenticate: One key signs, the other verifies

• Encryption: One key encrypts, the other decrypts

The key concept of public key cryptography is whenever user signs with own private key, we can check the public key, so can figure out the ownership of this transaction.

Let me check this with code snippet.

// How to sign message. using ethereum-cryptography
const secp = require("ethereum-cryptography/secp256k1");
const { keccak256 } = require("ethereum-cryptography/keccak");
const { utf8ToBytes } = require("ethereum-cryptography/utils");

const PRIVATE_KEY = "MY-PRIVATE-KEY";

// includes [signature, recoveryBit]
async function signMessage(msg) {
    const hashedMsg = hashMessage(msg);
    const signature = await secp.sign(hashedMsg, PRIVATE_KEY, { recovered: true });
    return signature
}

function hashMessage(message) {
    const hash = keccak256(utf8ToBytes(message));
    return hash
}

module.exports = signMessage;

The result of signMessage includes signature and recoveryBit. We.can use secep.recover() function and get the public key. (In normal case, it would be your crypto address)

Bitcoin and Ethereum both have a transformation process to take a public key and turn it into an address. For Bitcoin it includes a checksum and Base58 encoding. Ethereum's address transformation is quite a bit simpler, its address is the last 20 bytes of the hash of the public key.

The important thing to recognize here is that the address is differentiated from the public key, but you can always derive the address if you have the public key.

And for your information, Ethereum account address is 42 charaters. but you can check the public key has is over 42 chars. So we can usaully slice the public key after the first bit.

PoW is another component of Bitcoin that is essential to its success.
One of the first use cases of Proof of Work was to prevent spamming. The idea is you can make each action more difficult. This action can be architected managing the difficulty.

Let's take a simple example as following:

const SHA256 = require('crypto-js/sha256');
const TARGET_DIFFICULTY = BigInt(0x0fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff);
const MAX_TRANSACTIONS = 10;

const mempool = [];
const blocks = [];

function addTransaction(transaction) {
    mempool.push(transaction);
}

function mine() {
    const transactions = [];
    let count = 0;
    let nonce = 0;
    let block = { id: blocks.length, transactions, nonce };
    let hash = SHA256(JSON.stringify(block));
    
    while (mempool.length) {
        if (count >= MAX_TRANSACTIONS) break;
        transactions.push(mempool.shift());
        count++;
    }

    while (BigInt(`0x${hash}`) >= TARGET_DIFFICULTY) {
        nonce++;
        block = { id: blocks.length, transactions, nonce };
        hash = SHA256(JSON.stringify(block));
    }

    blocks.push({ ...block, hash })
}

module.exports = {
    TARGET_DIFFICULTY,
    MAX_TRANSACTIONS,
    addTransaction, 
    mine, 
    blocks,
    mempool
};

What our computer does is increasing nonce value by plus 1. We can set the difficulty value to adjust the difficultiy of mining.

Q. How do distributed p2p networks agree on what data is valid without a central administrator running the show?

A. Consensus mechanisms.

It means the bitcoin network decides validity of new data based on who is able to produce a valid proof of work

Q. How is the block hash calculated?

A: A hashing function takes data as input, and returns a unique hash.

Q. What is "valid" hash?

A. A valid hash for a blockchain is a hash that meets certain requirements.

1. Block index is one greater than latest block index

2. Block previous hash equal to latest block hash

3. Block hash meets difficulty requirement

4. Block hash is correctly calculated.

If you liked this post, please subscribe and share. Thank you for reading, and I'll see you next time!

Hi there! I'm @jio_jake, Web3 frontend developer in @Yooldo_Games.

I just started my tech blog sharing my techy lesson points to all Web3 beginners who feel nervous like my last year. Now I'm the one of the Web3 Ethereum builders but usually I have no idea of market stuff. But what I definitely can tell all crypto dev newbie is building in Web3 frontend is AWESOME and very clear. I want to share my tips from today so keep subscribing please 😆

First of all, In my personal opinion, there would be no superior or inferior between Web2 FE and Web3 FE. Please just think as one of the field of business.

Based on my experience, Frontend developer should have skills like below:

• UX(User Experience). Track the activity of users is always the key of frontend.

• Javascript. The world is consist of javascript. I swear.

• React-like framework. If you want to be hired in company, we have to accustomed to framework.

• Collaboration & Communication. Frontend is literally the end part of every tech and visual part. Sometimes, we have to align all team mates as one team.

• Problem Solving. This ability is based on how i know about our team business and knowing in-house tech structure

Frontend engineers struggle to enhance user experience. This might involve translating complex business jargon into more user-friendly language or optimizing the user journey to reduce friction. However, in Web3 companies, the role of a frontend engineer takes on a slightly different approach when it comes to user-friendliness.

Very first time, I reviewed the projects in current team. But I can't get in anything. the terms are not explained well. but a lot of users are gathered and chatting in community. I want to know what makes these users gathered. The key point was in exclusive group culture.

Here are the ideal case of Web2 service user journey:

1. Users discover our services for the first time through advertisements, viral marketing, recommendation from friends or direct searches.

2. The newbie user comes to our service.

3. Our service fully take care about users. preventing outbound, recommend some contents or items suitable with user's taste.

4. This makes the user loyalty. He(She) becomes a big fan of our service.

But honestly, in normal Web3 service as following below:

Please note that your service is written on the premise that it has a huge number of fans and builders.

1. The user who in exclusive chat first heard about our service. The service announced a huge partnership and shouted out from KOL(Key Opinion Leader)

2. The newbie user decide to trust our service because of the reputation of the name of big partner.

3. The user spend some ethereum to participate the event. and connect the wallet in our service.

4. Those kind of things happened again, and WOW! we made the hype of project.

The interesting part as Frontend developer is that user voluntarily keep studying to use our services. This is such a amazing moment compared to web2 culture. because there are so many competing services in the web2 market that users can easily go away from even a little bit of barriers.

So, We don't need to caring about basic crypto wallet related tutorial and using our service. Then what is exactly user want for our service and what points should we have more weight on?

Related above question, The answer would be totally different by team condition. In my case, I'm now in the blockchain gaming field. we provide pretty nice games to users. Even if Saying a little bit distance off, there's no place in a blockchain gaming company that's as passionate about game as ours:

However, we are now living in the era of dophamine, and having a tendency easily feeling tired of long contents. degen and pre-degen(newbie who wanna be the degen) want to spend their time very efficiently. So we have to prepare really quick and easy interaction for most of our (potential) users. So that's why most of projects just focus on daily check-in or selling limited NFT collections. That's super easy. Only linking your wallet and clicking the mint button.

So, We need to focus on how quickly users can successfully interact with our dapp. Inducing users to only clicking mint button. and business logic should be place on the back side. It is kind of nice way to put complex work behind of service.

Let's see the example of paragraph

Have you ever seen this error?
This error occurs because of unsupported chain. Basically my MetaMask chain was Linea, so I have to switch my wallet chain to Ethereum Mainnet.

The point is I have to clicking top-left side button and select the networks. Most of Web3 users are really expertise in these kind of things happened, but this might be much easily solved.

It is usually good way to hide some unnecessary process behind action button. That's the key point to save users time spent.

I guess paragraph team used web3-modal for wallet connection.
All code below sourced from my assumption.

const SignInButton = () => {
  const { open: openWeb3Modal } = useWeb3Modal();
  const { address, isConnecting } = useAccount();
  const chainId = useChainId();
  const { switchChainAsync } = useSwitchChain();

  const handleOnclick = async () => {
    // check current user wallet chain is supportive or not
     if (!supportedChains.has(chainId)) {
       await switchChainAsync({ chainId: mainnet.id });
     }
     openWeb3Modal();
  }
  return (
    <button onClick={handleOnclick}>
     {isConnecting ? 'Awaiting Confirmation' : 'Signin'}
    </button>
  )
}

Web3-modal is based on Walletconnect, Viem and Wagmi. So we can get easily supports from many hooks which can enhance user wallet status. The one last detail is some of users trying to test our service. They tries to change the chain network just before transaction execution. And they reports (usually upload on twitter) their glory found just before. So the environment check is always important. Like below:

• Is user address is same as off-chain registered address?

• Is the chain user trying to connect is our supportive chain?

There are many tips during interacting smart contract. I'll share all of tips to this blog soon😃

As I mentioned earlier, I don't think Web3 frontend development is basically different from Web2 frontend development. In fact, the technical aspects of Web3 are often sharper and more defined than some of the more ambiguous blockchain usages in the market.
While Web3 services may sometimes feel less user-friendly, there is good opportunity for us to contribute by analyzing our target users, designing user journeys that meet user's needs, and refining the UX to optimize unnecessary friction.

Today, I shared a simple example related to UX of wallet action, but I'll also touch on some key areas that Web3 frontend developers should consider in near future.

If you liked this post, please subscribe and share. Thank you for reading, and I'll see you next time!